3. SysML语言基础与汽车电子建模

SysML（Systems Modeling Language）是在UML基础上为系统工程扩展而来的建模语言。它并不是把UML简单改名，而是针对“系统”这一层级重新组织了语义：一方面保留UML中成熟的用例、活动、序列、状态等行为描述能力，另一方面新增了块（Block）、内部块图、参数图等面向结构与工程约束的图型。对汽车电子而言，SysML的价值在于把“需求—结构—行为—参数—验证”串成一条可追溯的链，而不是分散在文档、表格和代码注释里。

SysML共定义九种图，通常按“结构”和“行为”两大类理解。结构类包括块定义图（BDD）、内部块图（IBD）和包图；行为类包括用例图、活动图、序列图、状态机图；此外还有贯穿结构与行为的参数图，以及用于需求追溯的需求图。汽车电子建模中，最常用的组合是：用BDD定义整车/系统/ECU/传感器的块层级，用IBD描述ECU之间的接口与信号连接，用活动图或序列图描述功能执行顺序，用状态机图描述ECU工作模式，用参数图绑定扭矩、电压、温度等工程约束，最后用需求图把安全目标与设计元素关联起来。

理解九图之后，关键是把它们落到汽车电子的真实对象上。以电子驻车制动（EPB）为例：BDD中，顶层块是“EPB系统”，其下分解出EPB_ECU、左/右卡钳电机、轮速传感器、坡度传感器等子块，每个块拥有自己的属性，如EPB_ECU的供电电压范围9～16 V、工作温度-40～85 ℃。IBD则把EPB_ECU的端口画出来：CAN端口连接整车控制器VCU，PWM端口连接卡钳电机，模拟输入端口连接坡度传感器。端口之间的连接线代表信号或能量流，方向必须与真实电气拓扑一致，例如PWM是ECU输出到电机，轮速信号是传感器输入到ECU。

行为图解决“功能怎么执行”。活动图适合描述带判断和并行的流程，例如驻车请求处理：接收请求后先判断车速是否低于阈值（如3 km/h），若满足则驱动电机夹紧，同时监测电流；若不满足则拒绝并置故障。序列图适合描述ECU之间的交互时序，例如EPB_ECU与VCU通过CAN报文交互：VCU发送驻车请求帧（ID 0x2A0，周期20 ms），EPB_ECU回复状态帧（ID 0x2A1），序列图能清晰表达消息顺序、同步/异步以及超时约束。状态机图则描述EPB_ECU自身的模式迁移：Init→Standby→Parking→Released→Fault，迁移条件包括点火状态、请求信号、电机电流反馈和故障计数。

参数图是汽车电子中容易被忽视但极其重要的一类图。它把工程约束以方程形式绑定到块属性上。例如夹紧力约束可写为 F_clamp = k·I_motor·η / r_arm，其中k为电机常数、η为传动效率、r_arm为力臂半径。参数图把这些参数与BDD中的块属性关联，当设计变更时（如更换电机），约束方程会自动检查是否仍满足F_clamp ≥ 15 kN的安全要求。需求图则把安全目标（如“防止意外驻车”）与状态机、测试用例关联，形成追溯链，便于功能安全审核。

实际建模时还需注意几点。第一，块命名要统一，建议采用“对象_类型”格式，如EPB_ECU、WheelSpeed_Sensor，避免中英文混用导致工具解析困难。第二，端口方向要严格区分in/out/inout，汽车电子中CAN常为inout，PWM为out，模拟采样为in。第三，活动图的判断节点要写清条件表达式，例如[vehicleSpeed < 3]，而不是只写“车速低”。第四，状态机的迁移事件要区分触发事件与守卫条件，例如“evParkRequest [speed<3]”。第五，参数图方程中的单位要统一，建议采用SI单位并在块属性中标注，避免N与kN混用导致约束失效。

从工具落地角度看，主流MBSE工具（如Rhapsody、MagicDraw/Cameo、Enterprise Architect）都支持SysML九图，但汽车电子项目通常还需要与AUTOSAR、Simulink、CAN数据库（DBC）对接。常见做法是：BDD/IBD中的端口和接口映射到AUTOSAR的SWC端口；活动图/状态机图导出为Simulink Stateflow或C代码框架；参数图方程与Simulink参数表或FMI接口绑定。这样模型不仅是文档，还能驱动仿真和代码生成，真正发挥MBSE的价值。

最后需要强调，SysML图不是越多越好。一个EPB项目，BDD可能只有2～3张，IBD按ECU数量展开，活动图和序列图各3～5张覆盖主要场景，状态机图每个ECU一张，参数图按关键约束1～2张，需求图1张总览即可。图的数量取决于系统复杂度和追溯需求，而不是图型齐全度。建模的目标是让团队对系统有一致、可验证的理解，而不是完成一套漂亮的图形作业。