4. 汽车电子系统用例建模
在汽车电子系统开发中，用例建模是把“用户想要什么”转化为“系统该做什么”的第一道结构化关口。SysML 的用例图（Use Case Diagram）虽然符号简单，但它承载的信息量取决于我们如何识别参与者、如何界定系统边界、如何把场景写实、如何把用例与需求挂接。本节围绕这四个动作展开，并以一个车身域控制器（BDC，Body Domain Controller）为例贯穿讲解。
一、先划边界，再找参与者
参与者（Actor）是“与系统交互的外部实体”，它可以是人，也可以是另一个 ECU、一个诊断仪、一个云端服务，甚至是一个外部总线信号源。识别参与者的前提是先确定系统边界：边界之内是我们正在建模的系统（本例为 BDC），边界之外的一切交互方都是候选参与者。
以 BDC 为例，典型参与者包括：
- 驾驶员：通过门把手开关、钥匙、中控锁按键、雨刮拨杆等操作车身功能。
- 乘客：通过车门内把手、车窗升降开关、阅读灯开关等操作。
- 其他 ECU：如 BCM（车身控制模块）、PEPS（无钥匙进入与启动系统）、网关、座椅模块，通过 CAN/LIN 报文与 BDC 交互。
- 诊断仪：通过 UDS over CAN 或 DoIP 读取故障码、执行例程。
- 外部环境：如雨量传感器、光照传感器，作为信号提供者参与。
识别参与者时容易犯两类错误：一是把系统内部模块误当成参与者（例如把 BDC 内部的“门锁控制逻辑”列为参与者），二是遗漏非人类参与者（例如网关、诊断仪）。判断标准很简单：它是否跨越系统边界与系统交换信息或能量。若答案是肯定的，它就是参与者。
二、定义用例：从参与者目标出发
用例（Use Case）是系统为参与者提供的一个完整、有价值的功能单元。定义用例时，建议用“参与者 + 动词 + 对象”的句式，例如“驾驶员锁止所有车门”“乘客升降车窗”“诊断仪读取故障码”。避免把用例写成“门锁模块”“车窗控制”这类名词短语，因为那描述的是模块，不是目标。
在 BDC 中，可整理出如下用例集合（示例）：
- UC-01 驾驶员遥控锁止/解锁车门
- UC-02 驾驶员一键升降车窗
- UC-03 乘客独立控制车窗
- UC-04 驾驶员控制雨刮速度
- UC-05 诊断仪读取车身故障码
- UC-06 网关转发车身状态报文
用例之间还存在关系：包含（include）表示某用例必然使用另一用例，例如“遥控锁止”包含“验证钥匙合法性”；扩展（extend）表示在特定条件下才发生，例如“锁止车门”在检测到车门未关时扩展出“发出未关报警”；泛化（generalization）表示特化，例如“遥控解锁”与“无钥匙解锁”可泛化为“解锁车门”。这些关系在 SysML 用例图中用虚线箭头和构造型标注，是后续需求分解的重要线索。
三、描述用例场景：把“一句话”展开成可验证的交互
用例图只给出“谁做什么”，真正让工程师能设计、能测试的是用例场景（Scenario）。场景通常分为主成功场景（Basic Flow）和若干备选/异常场景（Alternative Flow）。描述时建议包含：触发条件、前置条件、主流程步骤、后置条件、异常分支。
以 UC-01“驾驶员遥控锁止/解锁车门”为例，主成功场景可写为：
- 驾驶员按下遥控钥匙锁止键，钥匙通过 RF 发送含滚动码的锁止请求。
- BDC 接收 RF 报文，校验滚动码与钥匙 ID 是否匹配。
- 校验通过后，BDC 向四个车门锁执行器输出锁止驱动信号。
- BDC 读取门锁状态反馈，确认四门均处于锁止位置。
- BDC 通过 CAN 向网关发送“车门已锁止”状态报文，并点亮转向灯一次作为提示。
备选场景包括：滚动码校验失败（不执行锁止，记录安全事件）、某车门未关到位（锁止失败，发出蜂鸣报警）、钥匙电量低（RF 信号弱，需靠近车辆重试）。这些分支正是后续状态机与诊断需求的重要来源。
四、关联需求：让用例成为需求的可追溯锚点
用例本身不是需求，但它是需求的“使用语境”。在 SysML 中，常用 «trace» 或 «deriveReqt» 关系把用例与需求连接起来。例如：
| 用例 | 关联需求 | 关系类型 | 验证方式 |
|---|---|---|---|
| UC-01 遥控锁止/解锁 | REQ-BDC-012 锁止响应 ≤ 200 ms | «trace» | HIL 台架计时 |
| UC-02 一键升降车窗 | REQ-BDC-020 防夹力 ≤ 100 N | «deriveReqt» | 防夹力传感器测试 |
| UC-05 读取故障码 | REQ-BDC-031 支持 UDS 0x19 服务 | «trace» | 诊断仪实测 |
关联需求时要注意两点：一是方向性，通常是用例 trace 到需求，表示“该用例覆盖了这条需求”；二是完整性，每条安全相关需求都应至少被一个用例场景覆盖，否则说明需求没有落到具体交互上。反过来，每个用例也应能回答“它支撑了哪条需求”，否则该用例可能缺乏工程价值。
五、从用例到后续建模的衔接
完成用例建模后，下一步通常是把每个用例场景展开为活动图或序列图，明确消息顺序与时间约束；再把用例中的对象映射为块定义图（BDD）中的块与接口；最后把用例与需求矩阵导入需求管理工具，形成“需求—用例—场景—测试用例”的追溯链。这样，用例图就不只是几张椭圆和火柴人，而是整个汽车电子系统开发可追溯性的起点。
在实际项目中，建议为每个用例维护一份轻量级场景表，字段包括：用例编号、参与者、触发条件、前置条件、主流程、备选流程、后置条件、关联需求、验证方法。这份表可以直接作为后续测试用例设计的输入，也能在评审时快速暴露遗漏的异常分支。