3、SysML概览：SysML图类型及其在需求建模中的角色

SysML（Systems Modeling Language，系统建模语言）是OMG（对象管理组织）在UML 2.0基础上扩展而来的通用系统建模语言，专为系统工程领域设计。与UML侧重于软件系统不同，SysML强化了对需求、结构、行为、参数约束以及系统层级分解的建模能力。在汽车需求工程实践中，SysML提供了一套标准化的可视化语言，使需求工程师、系统架构师、软件/硬件工程师以及测试验证团队能够在同一语义框架下协同工作。本章将系统梳理SysML的九种核心图类型，并重点阐述每种图在汽车需求建模中的具体角色与适用场景。

3.1 需求图（Requirements Diagram）

核心原理：需求图是SysML中专门用于表达需求及其关系的图类型，它弥补了UML在需求建模方面的不足。需求图以«requirement»构造型表示需求元素，每个需求节点包含唯一的ID、文本描述以及可选的验证状态、优先级、来源等属性。需求图支持四种核心关系：包含（Containment）用于表达需求层级分解，派生（Derive）用于表达子需求从父需求推导而来，满足（Satisfy）用于表达设计元素满足某条需求，验证（Verify）用于表达测试用例验证某条需求。

在需求建模中的角色：需求图是汽车需求工程的核心载体。在ADAS（高级驾驶辅助系统）项目中，需求工程师可以使用需求图将顶层安全需求（如"车辆应能在100km/h内自动紧急制动"）逐层分解为系统级需求、子系统级需求和组件级需求。每条需求都可以通过«derive»关系追溯其来源，通过«satisfy»关系关联到具体的架构元素（如摄像头模块、ECU、执行器），通过«verify»关系关联到测试用例。

3.2 用例图（Use Case Diagram）

核心原理：用例图从用户视角描述系统的功能行为，展示参与者（Actor）与用例（Use Case）之间的交互关系。在SysML中，用例图与UML保持一致，但更强调与需求图和块定义图的关联。用例图支持包含（«include»）、扩展（«extend»）和泛化（Generalization）三种关系。

在需求建模中的角色：用例图是需求获取阶段的重要工具。在汽车座舱域控制器项目中，用例图可以清晰表达不同角色（驾驶员、乘客、维修技师）与系统功能（语音控制、手势识别、OTA升级）之间的关系。每个用例都可以关联到需求图中的具体需求条目，从而建立"用户场景→功能需求→系统设计"的完整追溯链。

案例拆解：以某OEM的自动泊车系统（APA）为例，用例图包含"驾驶员"和"车辆"两个参与者。核心用例包括"搜索车位"、"执行泊车"、"取消泊车"和"障碍物报警"。其中"执行泊车"用例«include»了"路径规划"和"速度控制"两个子用例，而"障碍物报警"用例«extend»了"执行泊车"用例（在检测到突发障碍物时触发）。这些用例直接映射到需求图中的功能需求条目，确保每个用户可感知的功能都有明确的用例来源。

3.3 块定义图（Block Definition Diagram, BDD）

核心原理：块定义图是SysML中定义系统结构的主要图类型，使用«block»构造型表示系统中的模块。块可以代表物理组件（如ECU、传感器）、软件组件（如算法模块、通信协议栈）或逻辑实体（如整车、子系统）。BDD支持组合（Composition）、聚合（Aggregation）、泛化（Generalization）和关联（Association）四种关系，并可以定义块的属性（值属性、部件属性、引用属性）和操作。

在需求建模中的角色：BDD用于建立系统的静态结构模型，是需求向设计过渡的桥梁。在新能源汽车BMS（电池管理系统）项目中，BDD可以定义BMS主控模块、从控模块、电流传感器、温度传感器、高压继电器等块，并明确它们之间的组合关系和关联关系。每条需求都可以通过«satisfy»关系关联到具体的块，从而回答"哪个组件负责实现这条需求"的问题。

操作流程：在创建BDD时，建议遵循以下步骤：第一步，从需求图中提取关键名词，识别候选块；第二步，确定块之间的层级关系（组合/聚合）；第三步，定义块的属性（如工作电压、通信速率、精度）；第四步，建立块与需求之间的«satisfy»追溯关系。

3.4 内部块图（Internal Block Diagram, IBD）

核心原理：内部块图描述块内部的结构细节，展示块内部的部件、端口和连接器。IBD使用端口（Port）定义块与外部环境的交互点，使用连接器（Connector）定义部件之间的连接关系。在SysML中，端口分为标准端口（Standard Port）和流端口（Flow Port），后者用于描述物质、能量或数据的流动。

在需求建模中的角色：IBD用于验证需求中的接口要求。在自动驾驶域控制器项目中，IBD可以展示摄像头接口（MIPI CSI-2）、雷达接口（CAN FD）、GPS接口（UART）以及电源接口之间的连接关系。通过IBD，需求工程师可以检查接口需求是否完整（如供电电压、信号类型、通信协议），并识别潜在的接口冲突。

3.5 活动图（Activity Diagram）

核心原理：活动图描述系统的业务流程、控制流和数据流。它使用活动节点（Activity Node）表示动作或任务，使用控制流（Control Flow）表示执行顺序，使用对象流（Object Flow）表示数据传递。活动图支持分支（Decision）、分叉（Fork）、汇合（Join）等并发控制结构。

在需求建模中的角色：活动图用于建模功能需求的业务流程。在车身控制模块（BCM）项目中，活动图可以描述"遥控钥匙解锁"的完整流程：接收钥匙信号→验证身份→控制门锁电机→激活迎宾灯→更新车辆状态。通过活动图，需求工程师可以与功能安全团队一起分析流程中的潜在失效点，为FMEA（失效模式与影响分析）提供输入。

3.6 序列图（Sequence Diagram）

核心原理：序列图描述对象之间按时间顺序的消息交互。它使用生命线（Lifeline）表示参与交互的实例，使用消息（Message）表示对象之间的通信，使用执行规格（Execution Specification）表示对象执行动作的时间段。

在需求建模中的角色：序列图用于建模时间相关的行为需求。在V2X（车路协同）通信场景中，序列图可以精确描述"车辆发送BSM消息→路侧单元接收并处理→下发SPAT消息→车辆接收并显示"的完整时序。这对于定义通信延迟、超时重传等非功能需求至关重要。

3.7 状态机图（State Machine Diagram）

核心原理：状态机图描述对象在其生命周期中的状态变化以及触发状态迁移的事件。它使用状态（State）表示对象在特定时间满足的条件，使用迁移（Transition）表示状态之间的转换，使用事件（Event）、守卫条件（Guard）和动作（Action）定义迁移的触发条件。

在需求建模中的角色：状态机图是建模状态相关需求的核心工具。在电子换挡器（Shift-by-Wire）系统中，状态机图可以定义P/R/N/D各挡位状态之间的合法迁移路径，以及非法迁移的保护逻辑（如车速>5km/h时禁止从D挡直接切换到R挡）。这些状态需求直接关联到功能安全目标（ISO 26262 ASIL等级）。

3.8 参数图（Parametric Diagram）

核心原理：参数图是SysML特有的图类型，用于表达系统参数之间的约束关系。它使用约束属性（Constraint Property）表示数学方程或逻辑约束，使用绑定连接器（Binding Connector）将约束参数与块的属性绑定。参数图支持连续系统仿真和工程计算。

在需求建模中的角色：参数图用于验证性能需求的可实现性。在动力电池热管理系统中，参数图可以建立"电池温度 = f(冷却液流量, 环境温度, 放电功率)"的约束模型。通过参数图，需求工程师可以快速评估不同工况下电池温度是否满足"最高温度≤45℃"的需求，从而在需求阶段就发现潜在的矛盾。

3.9 包图（Package Diagram）

核心原理：包图用于组织和管理模型元素，将相关的需求、块、用例等元素分组到不同的包中。包图支持包导入（Package Import）和包合并（Package Merge）关系，便于模型的模块化管理和复用。

在需求建模中的角色：包图用于需求分类和模型组织。在整车需求建模中，可以按照功能域（动力域、底盘域、座舱域、智驾域）或开发阶段（用户需求、系统需求、子系统需求）建立包结构。良好的包结构可以显著提升大型团队协作效率，减少模型冲突。

3.10 综合应用：多图协作的需求建模方法

核心原理：在实际汽车需求工程中，九种图类型并非孤立使用，而是相互协作、互为补充。需求工程师需要根据建模目的选择合适的图类型，并建立图之间的追溯关系。例如，一条"自动紧急制动（AEB）功能需求"可以同时关联到用例图（AEB触发场景）、活动图（AEB控制流程）、状态机图（AEB激活/退出状态）、块定义图（AEB相关ECU和传感器）以及参数图（制动距离与车速的约束关系）。

操作流程：推荐采用"需求→用例→结构→行为→参数"的建模路径。首先使用需求图建立需求基线，然后通过用例图明确功能场景，接着用BDD/IBD定义系统结构，再用活动图/序列图/状态机图细化行为需求，最后通过参数图验证性能约束。在整个过程中，包图负责组织和管理所有模型元素。