4、SysML语言入门：九种图的用途与符号

SysML（Systems Modeling Language，系统建模语言）是国际系统工程学会（INCOSE）与OMG（对象管理组织）在UML 2.0基础上扩展而来的标准建模语言，专为系统工程师设计。在汽车MBSE实践中，SysML的九种图是描述系统需求、结构、行为与参数约束的四大支柱。本章将逐一拆解每种图的用途、核心符号、适用场景及常见误区，帮助你在搭建汽车系统模型时选对图、画对符号、传对信息。

SysML九种图分类框架（汽车MBSE视角） 结构图（4种） 行为图（4种） 需求图（1种） 参数图（1种） 块定义图（BDD） 内部块图（IBD） 包图（Pkg） 用例图（UC） 活动图（Act） 序列图（Seq） 状态机图（STM） 需求图（Req） 参数图（Par） 汽车MBSE典型应用映射 • 需求图：捕获客户需求、法规要求（如ISO 26262）、系统需求，并建立追溯关系 • 块定义图：定义ECU、传感器、执行器、整车、子系统等模块层级与接口 • 内部块图：展示ECU内部软件组件、硬件端口、CAN/LIN/以太网信号流 • 用例图：描述驾驶员、乘客、维修人员与ADAS、座舱、热管理等系统的交互 • 活动图：建模AEB自动紧急制动、自动泊车等功能的控制流与数据流 • 序列图：展示ECU间CAN报文时序、诊断会话、OTA升级的交互顺序 • 状态机图：建模车门锁、电池充电状态、自动驾驶模式切换等状态逻辑 • 参数图：约束电池容量、电机功率、车速、续航之间的数学关系 • 包图：组织模型文件的命名空间，管理整车、子系统、测试用例等模型元素 提示：BDD与IBD是结构核心，Req与Par贯穿全生命周期，行为图按需选用。 在汽车领域，通常先建Req→BDD→IBD→活动图/序列图→参数图，形成完整追溯链。

上图展示了SysML九种图在汽车MBSE中的整体分类与典型应用。下面我们按“结构—行为—需求—参数”四个维度逐一深入。

4.1 结构图：块定义图（BDD）、内部块图（IBD）、包图（Pkg）

4.1.1 核心原理

结构图描述系统的静态组成。块定义图（BDD）用于定义系统层级中的“块”（Block），即系统中具有属性、操作和接口的模块化单元。在汽车领域，一个“块”可以是整车、域控制器、传感器、软件组件或物理连接器。BDD强调“是什么”和“谁包含谁”。内部块图（IBD）则深入块的内部，展示端口、连接器和部件之间的信号流、能量流或物质流，回答“内部如何连接”。包图（Pkg）用于组织模型文件，将相关模型元素分组到命名空间，便于团队协作和版本管理。

4.1.2 判断方法或操作流程

  • 何时用BDD：当需要定义系统架构层级、模块复用关系、接口类型时，优先使用BDD。例如，定义“整车—动力域—电池管理系统（BMS）—电芯监测单元”的组成关系。
  • 何时用IBD：当需要展示块内部端口之间的连接、数据流方向、物理连接（如CAN总线、高压线束）时，使用IBD。IBD必须基于BDD中已定义的块。
  • 何时用包图：当模型文件数量增多，需要按子系统、按功能域或按开发团队划分模型空间时，使用包图。

    • 4.1.3 案例拆解：动力电池系统BDD与IBD建模

    假设某新能源车型需要建模动力电池系统。初始目标：明确电池包、模组、电芯、BMS主控、从控之间的层级与信号连接。约束：BMS需支持ISO 26262 ASIL-C功能安全等级，且需兼容两种不同电芯供应商。

    操作步骤：

    1. 在BDD中定义块：BatteryPack（电池包）、Module（模组）、Cell（电芯）、BMS_Master、BMS_Slave。为每个块添加属性（如容量、电压、温度范围）和操作（如readVoltage()）。
    2. 建立组合关系：BatteryPack包含4个Module，每个Module包含12个Cell，BMS_Master与BMS_Slave通过CAN通信。
    3. 在IBD中，为BMS_Master定义CAN端口（CAN_H、CAN_L），连接至BMS_Slave的对应端口；为每个Module定义高压连接器端口（HV_POS、HV_NEG）和低压采集线端口（TEMP_SENSE）。
    4. 检查端口类型匹配：CAN端口使用CAN_Bus接口类型，高压端口使用HV_Connector类型，确保信号方向正确。

    结果：BDD提供了清晰的模块复用视图，IBD暴露了信号连接细节，后续可在此基础上进行线束长度估算和信号完整性分析。风险：若BDD中未定义端口类型，IBD连接时可能出现类型不匹配，导致模型校验失败。

    经验提醒：在BDD中尽量使用“块”而非“类”，因为SysML的块支持流端口（Flow Port）和标准端口（Standard Port），更适合描述物理信号与能量流。在IBD中，务必为每条连接线标注信号名称和方向，避免歧义。

    4.1.4 常见误区或总结复盘

    • 误区1：将BDD画成UML类图，使用“类”而非“块”。SysML的块更强调系统级物理与逻辑交互。
    • 误区2：IBD中直接画线连接两个块，而不通过端口。这会导致模型无法进行接口一致性检查。
    • 误区3：包图仅用于文件管理，忽略其命名空间对模型元素唯一性的约束作用。
    对比维度BDDIBD包图
    核心问题系统由哪些块组成？块内部如何连接？模型元素如何组织？
    主要符号块、组合、聚合、泛化端口、连接器、部件包、依赖、导入
    汽车应用整车层级、ECU清单ECU内部信号流、线束连接按域划分模型包
    验证重点属性完整性、关系正确性端口类型匹配、连接方向依赖无循环、命名唯一

    4.2 行为图：用例图、活动图、序列图、状态机图

    4.2.1 核心原理

    行为图描述系统的动态特征。用例图（UC）从外部参与者（Actor）视角描述系统提供的功能，回答“系统为谁做什么”。活动图（Act）建模控制流和数据流，适合描述复杂的算法逻辑和业务流程。序列图（Seq）强调时间顺序上的消息交互，适合展示ECU之间的通信时序。状态机图（STM）描述对象在生命周期内状态的变化及触发事件，适合建模模式切换和状态依赖逻辑。

    4.2.2 判断方法或操作流程

    • 用例图：当需要与客户或利益相关者确认功能范围时，先画用例图。识别参与者（驾驶员、云端服务器、维修技师）和用例（自动泊车、远程诊断、OTA升级）。
    • 活动图：当需要描述一个操作的详细步骤、决策分支、并行行为时，使用活动图。例如，AEB（自动紧急制动）的决策逻辑：感知→融合→决策→执行。
    • 序列图：当需要展示多个对象之间的消息交互顺序，特别是时间关键场景（如安全气囊弹出时序）时，使用序列图。
    • 状态机图：当对象具有明确的状态集合，且状态间存在转移条件时，使用状态机图。例如，电池充电状态：空闲→预充→恒流充电→恒压充电→满充→涓流。

    4.2.3 案例拆解：AEB功能行为建模

    背景：某Tier1供应商需为整车厂开发AEB功能，要求满足Euro NCAP测试标准。初始现象：功能需求文档中仅描述了“当碰撞风险高时自动制动”，但未定义具体逻辑。目标：建立可执行的行为模型，用于仿真验证。

    关键输入数据：雷达探测距离（0.5-50m）、摄像头识别置信度（0-100%）、车速（0-120km/h）、制动减速度（最大-8m/s²）。

    分析过程：

    1. 绘制用例图：参与者为“驾驶员”和“AEB控制器”，用例包括“检测前方障碍物”、“评估碰撞风险”、“触发部分制动”、“触发全力制动”。
    2. 绘制活动图：从“读取传感器数据”开始，经过“数据融合”节点，进入“风险计算”决策节点。若风险值>0.8，则并行执行“发出警告”和“预充制动压力”；若风险值>0.95，则执行“全力制动”。
    3. 绘制序列图：展示Camera、Radar、Fusion_ECU、Brake_ECU之间的消息顺序：Camera.sendObjectList() → Radar.sendObjectList() → Fusion_ECU.fuseData() → Fusion_ECU.calculateRisk() → Brake_ECU.applyBrake(force)。
    4. 绘制状态机图：AEB控制器状态包括“待机”、“主动监测”、“警告”、“部分制动”、“全力制动”、“故障”。转移条件如“风险值>0.8且车速>30km/h”触发从“主动监测”到“警告”的转移。

    结果：行为模型通过仿真验证，发现原需求中未定义“驾驶员踩油门时是否抑制AEB”的逻辑，通过状态机补充了“驾驶员干预”状态。风险：活动图若未定义并发分支，可能导致仿真死锁。

    风险提醒：序列图不要画成“面条图”，消息线交叉过多会降低可读性。建议按参与者或子系统分区，使用ref引用子序列图来简化。

    4.2.4 常见误区或总结复盘

    • 误区1：用例图包含过多技术细节，如数据库操作、API调用。用例应聚焦用户价值。
    • 误区2：活动图与流程图混淆。活动图支持对象节点、流终节点、中断区域等语义，比传统流程图更严谨。
    • 误区3：状态机图缺少初始状态和终止状态，导致模型不完整。
    行为图类型适用场景关键符号汽车案例
    用例图功能范围界定参与者、用例、包含/扩展远程泊车功能
    活动图算法流程、业务流活动节点、决策、分叉/汇合电池热管理策略
    序列图消息时序交互生命线、消息、执行发生OTA升级流程
    状态机图状态转移逻辑状态、转移、事件、守卫自动驾驶模式切换

    4.3 需求图（Req）与参数图（Par）

    4.3.1 核心原理

    需求图（Req）是SysML区别于UML的重要扩展，用于表示需求之间的追溯关系（派生、满足、验证、细化）以及需求与设计元素（块、活动、状态）的映射。在汽车开发中，需求图是连接客户需求、系统需求、功能安全需求（如ASIL等级）和测试用例的桥梁。参数图（Par）基于约束块（Constraint Block）定义参数之间的数学关系，如续航里程 = 电池能量 / 能耗率。参数图支持工程计算和权衡分析。

    4.3.2 判断方法或操作流程

    • 需求图：当需要管理需求变更影响分析、验证需求覆盖率时，使用需求图。操作流程：定义需求类型（客户需求、系统需求、功能需求）→ 建立派生关系（deriveReqt）→ 建立满足关系（satisfy）→ 关联验证活动（verify）。
    • 参数图：当需要约束多个参数之间的数值关系，且这些参数来自不同块时，使用参数图。例如，电机功率、电池电压、电流、扭矩之间的关系。

    4.3.3 案例拆解：续航里程参数约束与需求追溯

    背景：某车型开发中，客户需求为“NEDC续航≥500km”。系统工程师需验证该需求是否可满足。关键输入：电池容量（75kWh）、整车能耗（14kWh/100km）、电机效率（90%）、附件功耗（0.5kW）。

    分析过程：

    1. 在需求图中创建客户需求REQ-001: NEDC续航≥500km，派生系统需求REQ-101: 电池容量≥75kWh和REQ-102: 整车能耗≤14kWh/100km。
    2. 建立satisfy关系：BatteryPack块满足REQ-101，Vehicle块满足REQ-102。
    3. 在参数图中定义约束块RangeConstraint，参数：BatteryCapacity、EnergyConsumption、Range。约束表达式：Range = BatteryCapacity / EnergyConsumption * 100。
    4. 绑定参数：将BatteryPack.capacity绑定到BatteryCapacity，将Vehicle.energyConsumption绑定到EnergyConsumption。
    5. 执行权衡：若电池容量降至70kWh，则续航变为500km（70/14*100=500），刚好满足；若能耗升至15kWh/100km，则续航降至466km，不满足需求。

    结果：参数图揭示了关键敏感参数，需求图提供了追溯证据。风险：参数图若未定义单位，可能导致计算错误。

    实战要点：参数图是MBSE中“数学仿真”的核心入口。在汽车领域，常与Modelica、Simulink联合使用，将参数图导出为仿真模型。但注意，参数图只定义约束关系，不定义求解顺序。

    4.3.4 常见误区或总结复盘

    • 误区1：需求图只画需求，不画追溯关系，导致需求图退化为需求列表。
    • 误区2：参数图与IBD混淆。IBD描述物理连接，参数图描述数学约束。两者可以共存，但语义不同。
    • 误区3：忽略需求图的“验证”关系，导致测试用例无法追溯到需求。
    图类型核心元素关系/约束汽车典型应用
    需求图需求、派生、满足、验证deriveReqt, satisfy, verifyISO 26262安全需求追溯
    参数图约束块、参数、绑定连接约束表达式、绑定续航计算、制动距离计算

    4.4 九种图的协同使用与建模策略

    在汽车MBSE项目中，九种图并非孤立使用。通常的建模路径是：先以需求图捕获利益相关者期望，再用BDD定义系统架构，用IBD细化内部连接，用用例图确认功能范围，用活动图/序列图/状态机图描述动态行为，最后用参数图进行性能权衡。包图则贯穿始终，管理模型的组织结构。

    例如，在ADAS域控制器开发中：

    1. 需求图：定义“支持L2+级自动驾驶”的客户需求，派生“前向碰撞预警”等功能需求。
    2. BDD：定义ADAS_ECU、Camera、Radar、Fusion_Algorithm等块。
    3. IBD：展示Camera通过GMSL2接口连接至ADAS_ECU的CSI-2端口。
    4. 用例图：确认“驾驶员”与“ADAS_ECU”的交互用例。
    5. 活动图：建模传感器数据融合流程。
    6. 序列图：展示Camera→Fusion_Algorithm→Brake_ECU的消息时序。
    7. 状态机图：建模ADAS系统的“Off/Standby/Active/Fault”状态。
    8. 参数图：约束“制动距离 = f(车速, 摩擦系数, 制动压力)”。
    9. 包图：按“感知”、“决策”、“执行”分包管理模型。
    建模策略建议：不要试图在一张图中表达所有信息。每个图聚焦一个视角，通过模型元素的引用（如ref）保持一致性。在团队协作中，建议使用基于模型的配置管理工具（如Teamcenter、Polarion）来管理九种图的版本和基线。

    最后，回顾九种图的核心记忆点：结构图回答“系统是什么”，行为图回答“系统如何运作”，需求图回答“为什么这样做”，参数图回答“性能是否达标”。掌握这四类问题的边界，你就能在汽车MBSE建模中游刃有余。

    ← 上一章 📖 返回目录 下一章 →