3. 汽车电子系统需求建模

在SysML中，需求图（Requirement Diagram）是唯一以“需求”本身作为核心模型元素的图型。它不描述系统如何运行，而是回答三个问题：系统必须满足什么、这些要求从何而来、以及当需求变化时哪些设计会受影响。对于汽车电子系统而言，需求来源分散在整车功能规范、法规、企业标准与安全分析中，需求图的价值正是把这些分散的约束组织成可追溯、可变更管理的模型。

需求图的核心元素

需求图由三类基本元素构成：需求（Requirement）、需求关系和承载需求的模型元素。需求本身是一个带唯一标识的矩形框，框内可包含id与text两个属性：id是追溯用的稳定标识，text是需求正文。SysML定义了多种需求关系，最常用的是：

• 包含（containment）：复合需求分解为子需求，用带十字圆圈的虚线表示；
• 派生（deriveReqt）：下层需求由上层需求推导而来，用«deriveReqt»虚线箭头表示；
• 满足（satisfy）：设计元素满足某条需求，用«satisfy»虚线箭头从设计元素指向需求；
• 验证（verify）：测试用例验证某条需求，用«verify»虚线箭头从测试用例指向需求；
• 细化（refine）：用例、活动等细化需求描述，用«refine»表示。

在汽车电子项目中，需求通常按功能需求、性能需求、安全需求三类组织。功能需求描述“做什么”，例如“车门模块应在收到解锁指令后200ms内驱动门锁电机”；性能需求描述“做到什么程度”，例如“门锁电机驱动电流峰值不超过3.5A”；安全需求来自ISO 26262的危害分析与风险评估，例如“门锁意外锁止故障应被检测并在100ms内进入安全状态”。三类需求在需求图中可以放在同一包内，但通过id前缀或构造型区分，便于后续追溯与变更影响分析。

从需求文本到可追溯模型

需求图建模的第一步不是画图，而是把需求写成可建模的条目。一条合格的需求应包含稳定id、正文、来源与验证方法。以门锁功能需求为例，可写成：

REQ-FUN-021
text: 当BCM收到有效的遥控解锁指令时，门锁控制ECU应在200ms内
      驱动门锁电机完成解锁动作。
source: 整车功能规范 VF-2024-017
verifyMethod: Test
riskLevel: QM

性能需求则必须带可测量的阈值与条件。例如“驱动电流峰值不超过3.5A”需要补充测试条件：在12V标称电压、25℃环境、电机堵转条件下测量。安全需求来自危害分析，通常带ASIL等级与安全状态定义。例如“意外锁止”被识别为S2/E3/C2，对应ASIL B，安全状态为“停止驱动并上报故障”。

建模时，把顶层需求放在需求包中，用«deriveReqt»把功能、性能、安全需求挂到顶层需求下。随后在系统架构包中建立门锁控制ECU的Block，用«satisfy»从Block指向它满足的需求。测试用例则用«verify»指向被验证的需求。这样，需求图就同时承载了“需求分解”和“需求—设计—验证”两条追溯链。

需求追溯关系的建立与检查

追溯关系不是画完就结束，必须做完整性检查。常用的检查规则包括：每条需求至少有一条«satisfy»或«verify»；每个设计元素至少满足一条需求；每条安全需求必须能追溯到危害分析条目；每条派生需求必须能追溯到父需求。在工具中可以用矩阵视图或查询脚本自动检查。例如在Cameo Systems Modeler中，可对需求包运行“未满足需求”查询，列出所有没有«satisfy»入边的需求。

追溯关系还决定了变更影响范围。当REQ-FUN-021的200ms被改为150ms时，沿«deriveReqt»向上可找到顶层需求，沿«satisfy»向下可找到门锁控制ECU，沿«verify»可找到TC-DL-012测试用例。变更影响分析就是沿这些关系边做一次图遍历，输出受影响的模型元素清单。

需求变更管理

汽车电子项目的需求变更频繁，需求图必须与变更流程配合。推荐做法是：每条需求带version与status属性，status可取draft、reviewed、approved、changed、deprecated。变更时不在原需求上直接改text，而是新建一条需求并建立«deriveReqt»或«refine»关系，保留历史版本。这样需求图同时成为变更记录的可视化载体。

变更影响分析可按下述顺序执行：先定位变更需求，再沿«deriveReqt»向上找父需求、沿«satisfy»找设计元素、沿«verify»找测试用例，最后检查安全需求是否受影响。若变更涉及安全需求，必须重新评估ASIL等级与安全目标，并更新相关的危害分析条目。变更完成后，需求图应重新运行完整性检查，确保没有孤立需求或断链。

一个可执行的需求图建模检查清单

需求图不是一次性文档，而是贯穿概念、设计、测试与变更的活模型。把功能、性能、安全三类需求放进同一张可追溯的需求图，并在每次变更后重新检查追溯链，才能让需求真正成为汽车电子系统开发的约束基线，而不是散落在文档中的文字。