3. 项目启动与需求建模

项目启动阶段最容易被低估的工作，不是搭模型，而是把“系统需求”翻译成“Simulink 能承载的结构”。很多团队在需求评审通过后立刻打开 Simulink 画框图，结果到集成阶段才发现：需求条目找不到对应模块，接口信号对不上，变更时不知道改哪里。根因在于缺少一层“需求—架构—模型”的映射设计。本节围绕这一层展开，目标是让每条需求都能落到具体的模型元素上，并形成可维护的追溯矩阵。

一、先明确三类对象的边界

需求建模不是把需求文档抄进模型注释，而是建立三类对象的对应关系：

• 需求条目（Requirement）：来自系统需求规格，具有唯一编号、文本描述、验收准则。例如 SYS-FUN-012：“当车速大于 30 km/h 且驾驶员未踩制动时，巡航控制器应保持设定车速，误差不超过 ±2 km/h”。
• 架构元素（Architecture Element）：承担该需求的逻辑单元，如 CruiseController、SpeedEstimator、BrakeInterface。架构元素是模型层级的“骨架”。
• 模型元素（Model Element）：Simulink 中真实存在的对象，如子系统、Stateflow 状态机、Gain 模块、信号线、数据字典条目。它是可被工具定位和检查的最小单元。

追溯矩阵的本质，就是记录“需求条目 → 架构元素 → 模型元素”的链路，并标注验证方式。链路完整，变更影响分析才有依据。

二、从需求到架构：功能分解与接口定义

拿到一组需求后，先做功能分解，而不是直接分配模块。以巡航控制为例，可分解为：车速采集与估计、目标车速管理、控制律计算、执行器指令输出、安全监控。每个功能对应一个架构元素，并明确其输入输出信号。此时应同步定义接口：信号名、数据类型、单位、采样周期、取值范围。例如 VehicleSpeed：single，单位 km/h，周期 10 ms，范围 [0, 300]；BrakePedal：boolean，周期 10 ms。

接口定义建议直接落到 Simulink 数据字典或 Simulink.Bus 对象中，而不是散落在各子系统的端口注释里。这样模型架构与接口契约同步固化，后续追溯矩阵中的“模型元素”才能稳定引用。

三、模型架构的落地形态

在 Simulink 中，架构元素通常体现为顶层子系统或模型引用（Model Reference）。推荐做法是：顶层模型只做集成与调度，各架构元素以 Model Reference 形式挂载，接口通过 Bus 传递。这样每个架构元素可独立开发、独立测试，也便于追溯矩阵按模型文件粒度管理。

对于带状态逻辑的需求（如“未踩制动且车速大于 30 时进入巡航”），应使用 Stateflow 或 Enabled Subsystem 显式表达状态与迁移条件，而不是用大量 Switch 模块堆叠。状态机的状态名、迁移条件应能对应到需求中的条件描述，这是后续追溯的关键锚点。

四、追溯矩阵的建立与维护

追溯矩阵不建议手工维护在 Excel 中，因为模型一旦重构，手工表很快失效。推荐两种可落地方式：

1. 基于 Simulink Requirements 工具：在需求条目与模型元素之间建立链接（Link），工具自动生成追溯矩阵，并支持覆盖率检查。链接可指向子系统、Stateflow 状态、甚至具体信号线。
2. 基于脚本扫描：若未使用 Requirements 工具箱，可在模型元素命名或自定义属性中嵌入需求编号，用 MATLAB 脚本遍历模型，输出 CSV 追溯表。例如约定子系统描述字段格式为 [SYS-FUN-012]，脚本用 find_system 配合 get_param 提取。

无论哪种方式，追溯矩阵至少应包含：需求编号、需求简述、架构元素、模型元素路径、验证方式、验证状态、变更记录。验证方式要与需求验收准则对应，例如“误差不超过 ±2 km/h”对应 MIL 测试中的稳态误差检查项。

五、一个可执行的启动检查清单

项目启动与需求建模阶段结束时，建议逐项确认：

完成上述工作后，模型架构不再是“凭经验搭出来的框图”，而是需求的可执行映射。后续的模型开发、测试用例设计、变更影响分析，都可以沿着追溯链路展开。下一阶段进入模型详细设计与编码规范时，这套追溯关系将直接决定变更成本和验证效率。