3. 需求到Stateflow模型的映射

需求到Stateflow模型的映射，本质上是把自然语言描述的系统行为，逐步转化为可执行、可验证的状态机结构。这个过程不是一次性翻译，而是经过条目化拆分、状态机识别、事件与条件定义、追溯矩阵建立四个相互衔接的环节。每个环节都有明确的输入、处理规则和输出物，下面逐一展开。

需求条目化：把段落拆成可建模的原子单元

原始需求文档通常以段落形式描述功能，例如“当车速超过30km/h且驾驶员未系安全带时，仪表应在2秒内点亮安全带警告灯，直至车速降至25km/h以下或安全带系好”。这样一段话包含多个可独立建模的要素：触发条件、判断条件、动作、持续时间、解除条件。条目化的目标就是把这些要素拆成编号唯一、语义单一、可追溯的需求条目。

条目化遵循三条规则：单一职责——每条只描述一个行为或一个约束；可判定——每条都能用真/假或具体数值判断是否满足；可追溯——每条有唯一ID，便于后续映射到状态、迁移或动作。以上述需求为例，可拆为：

• REQ-001：车速信号有效，量程0～200km/h，周期10ms。
• REQ-002：安全带状态信号有效，取值{已系,未系}。
• REQ-003：当车速>30km/h且安全带=未系时，进入警告状态。
• REQ-004：警告状态下，警告灯输出=ON，响应时间≤2s。
• REQ-005：当车速<25km/h或安全带=已系时，退出警告状态，警告灯输出=OFF。

条目化完成后，每条需求都对应一个明确的建模对象：信号类需求对应输入/输出端口，行为类需求对应状态或迁移，约束类需求对应迁移条件或动作属性。

状态机识别：从需求条目中提取状态与迁移

状态机识别的核心是回答三个问题：系统有哪些稳定状态？状态之间在什么条件下迁移？每个状态下执行什么动作？对于上述安全带警告功能，可以识别出两个稳定状态：Normal（警告灯OFF）和Warning（警告灯ON）。迁移关系为：Normal→Warning，条件为车速>30且未系；Warning→Normal，条件为车速<25或已系。

识别过程中需要注意几个工程细节。第一，状态命名要反映系统可观测的稳定模式，而不是动作本身。例如“点亮警告灯”是动作，不是状态；状态应命名为“WarningActive”或“Warning”。第二，迁移条件要覆盖所有可能的分支，避免出现条件不完整导致状态机卡死。第三，默认迁移和互斥条件要明确，例如车速在25～30km/h之间时，应保持当前状态不变，这需要在迁移条件中显式表达为“无迁移”或使用历史节点。

对于复杂功能，状态机可能呈现层次结构。例如整车控制器中，顶层状态为PowerOff、Standby、Ready、Fault，每个顶层状态下又有子状态。识别时先建立顶层状态骨架，再逐层细化，避免一开始就陷入细节。

事件与条件定义：区分触发源与判断逻辑

Stateflow中，事件（Event）和条件（Condition）承担不同角色。事件是触发状态机求值的信号，可以是输入信号变化、周期触发或消息到达；条件是迁移上的布尔表达式，决定迁移是否发生。在安全带警告示例中，车速信号和安全带状态信号都是输入事件源，而“车速>30且未系”是迁移条件。

定义事件时，需要明确以下属性：

• 事件名称：与需求条目中的信号名一致，如VehicleSpeed、SeatBeltStatus。
• 触发方式：上升沿、下降沿、任一变化或周期采样。车速信号通常采用周期采样，安全带状态可采用任一变化。
• 数据类型与量程：车速为uint16，单位km/h，量程0～200；安全带状态为boolean或枚举。
• 采样周期：与信号实际更新周期一致，示例中为10ms。

条件定义则要避免两个常见错误：一是条件中混入动作，例如把“点亮警告灯”写在条件里；二是条件边界不清晰，例如“车速>30”和“车速≥30”在临界点行为不同，必须与需求原文严格对齐。对于25km/h和30km/h之间的滞回区间，条件应写成“VehicleSpeed > 30”和“VehicleSpeed < 25”，中间区间不触发迁移，从而形成滞回特性。

需求追溯矩阵建立：让每条需求都有模型落点

追溯矩阵（Requirements Traceability Matrix, RTM）是需求到模型映射的收口环节。它的作用不是应付评审，而是在模型变更、需求变更和测试覆盖分析时，快速定位影响范围。一个实用的RTM至少包含以下列：需求ID、需求描述摘要、模型对象类型（状态/迁移/动作/输入输出）、模型对象路径、验证方式、当前状态。

以安全带警告功能为例，追溯关系如下表所示：

建立RTM时，有三个实操要点。第一，模型对象路径要写到可定位的层级，例如“SeatBeltWarning.Warning.entry”比“Warning状态”更利于在Simulink中直接跳转。第二，验证方式要与需求属性匹配，时序类需求用输出时序测试，边界类需求用边界值测试，不能全部写成“仿真验证”。第三，RTM要随模型迭代同步更新，建议在Stateflow模型中使用需求链接（Requirement Link）功能，把需求ID直接挂到状态或迁移上，这样RTM可以从模型自动导出，减少手工维护偏差。

映射过程中的常见偏差与校正

实际项目中，需求到模型的映射容易出现三类偏差。第一类是状态遗漏，例如只识别了Normal和Warning，忽略了系统上电初始化阶段或故障降级状态。校正方法是回到需求原文，检查是否有“初始化”“故障”“默认”等描述，补充Initial和Fault状态。第二类是条件边界错位，例如需求写“车速超过30”，模型写成“车速≥30”，在30km/h临界点行为不一致。校正方法是逐条核对比较运算符，并在RTM中标注边界测试用例。第三类是事件周期不匹配，例如车速信号实际更新周期为20ms，模型却按10ms采样，导致响应时间计算偏差。校正方法是与信号数据库对齐周期参数，并在模型配置中显式设置采样时间。

完成映射后，建议做一次反向检查：从Stateflow模型中的每个状态、迁移和动作出发，反查是否有对应的需求条目。如果存在没有需求来源的模型对象，要么是需求遗漏，要么是模型冗余，两种情况都需要在评审中澄清。反向检查能有效发现“模型做了需求没要求的事”或“需求要求了模型没做的事”，是保证映射完整性的最后一道关口。