📚 课程目录第3章汽车功能安全需求到 Stateflow 模型的映射

3. 汽车功能安全需求到 Stateflow 模型的映射

功能安全开发中最容易被低估的一步，不是写需求，也不是画状态机，而是把一条用自然语言写成的安全需求，稳定地翻译成 Stateflow 里可执行、可验证、可追溯的状态机结构。这一步做不好，后续的模型测试、代码生成和 ISO 26262 追溯都会变成“看起来有、实际上断”的假闭环。本节以电动车窗防夹控制为例，说明从安全目标、功能安全需求、技术安全需求到 Stateflow 状态机架构的分解方法。

三层安全需求与状态机元素的对应关系

ISO 26262 把安全需求分成三个层级，它们对 Stateflow 建模的约束粒度完全不同：

安全目标（Safety Goal）：顶层、整车级、不可分解的避免危害陈述。例如“避免电动车窗在上升过程中对乘员造成挤压伤害”。它不直接对应状态，而是决定状态机的安全状态集合与失效响应方向。
功能安全需求（FSR）：功能级、与具体功能行为绑定。例如“车窗上升过程中若检测到夹持力超过阈值，应在 100 ms 内停止上升并反向下降至少 50 mm”。它对应状态机中的功能状态、迁移条件和输出动作。
技术安全需求（TSR）：实现级、与传感器、执行器、时序、诊断绑定。例如“防夹检测周期 ≤ 10 ms，电流采样分辨率 ≤ 10 mA，反向下降由 H 桥方向引脚在 20 ms 内翻转”。它对应状态机中的输入事件、数据有效性判断、执行器输出接口和时序约束。

映射的核心原则是：安全目标决定“安全状态是什么”，FSR 决定“状态机怎么走”，TSR 决定“状态机靠什么信号走、走多快”。三者不能混写在同一层，否则状态机会出现“状态里塞了硬件参数”或“迁移条件里写了整车目标”的典型错误。

分解方法：从需求语句到状态机元素

把一条 FSR 拆成 Stateflow 元素，可以按“触发条件—状态响应—输出动作—时序约束”四段来切。以“车窗上升过程中若检测到夹持力超过 100 N，应在 100 ms 内停止上升并反向下降至少 50 mm”为例：

触发条件：夹持力 > 100 N。它对应迁移事件 PinchDetected，由防夹检测子系统在 Up 状态激活期间置位。
状态响应：从 Up 迁移到 AntiPinch，再进入 Down。这里不能把“停止”和“反向”塞进同一个状态，否则无法分别验证停止时间和反向行程。
输出动作：AntiPinch 的 entry 动作先切断上升方向输出，Down 的 entry 动作翻转 H 桥方向引脚。两个动作分开，便于在 SIL 测试中分别观测。
时序约束：100 ms 超时用 after(100, msec) 表达，50 mm 行程用位置传感器反馈 positionDelta >= 50 作为迁移条件。

这样分解后，每条 FSR 都能落到具体的状态、迁移、事件或动作上，形成可追溯的映射链。反过来，如果一条 FSR 找不到对应的状态机元素，说明模型缺功能；如果一个状态机元素找不到对应的 FSR 或 TSR，说明模型有多余逻辑，需要评审确认。

TSR 如何约束状态机的实现细节

TSR 不改变状态机的拓扑，但会改变状态机内部的数据类型、采样方式和接口定义。仍以电动车窗为例：

TSR 条目	Stateflow 实现约束
防夹检测周期 ≤ 10 ms	状态机采样时间设为 10 ms，或由触发子系统以 10 ms 周期调用
电流采样分辨率 ≤ 10 mA	输入端口数据类型为 `single` 或定点 `fixdt(1,16,10)`，避免量化误差淹没 100 N 阈值
H 桥方向翻转 ≤ 20 ms	`Down` 状态 entry 动作直接写方向引脚，不经过额外滤波或延时
位置反馈精度 ±2 mm	行程判断使用 `positionDelta >= 50`，并加入 2 mm 容差防止边界抖动

注意，TSR 中的“≤ 10 ms”是需求约束，不是实测结果。在模型阶段，我们只能保证状态机采样周期和接口满足该约束；实际是否达到，需要在 SIL/HIL 测试中用时间戳或示波器测量。教学示例中的 100 N、100 ms、50 mm 均为合理假设值，实际项目应按车窗电机特性、密封条刚度和法规要求标定。

安全状态与故障响应的状态机表达

安全目标要求“避免挤压伤害”，对应的安全状态是“电机停止或反向下降”。在 Stateflow 中，安全状态不能只靠一个 Fault 状态表达，而应区分三类失效：

防夹检测失效：电流传感器断线或信号超范围，迁移到 Fault，输出电机停止，禁止上升。
位置反馈失效：无法确认反向行程是否达到 50 mm，迁移到 Fault，保持停止并请求诊断。
执行器失效：H 桥方向引脚无响应，通过输出回读诊断检测，迁移到 Fault，切断电机供电。

这三类失效的共同点是最终都进入安全状态，但触发条件和诊断路径不同。把它们画成同一个迁移会让故障树分析无法展开，也不利于 FMEA 追溯。因此，状态机中应保留独立的故障迁移条件，例如 SensorFault、PositionFault、ActuatorFault，再统一汇聚到 Fault 状态。

映射检查口诀：每条 FSR 至少对应一个状态或迁移；每条 TSR 至少对应一个输入事件、数据类型或时序参数；每个安全状态至少有一条来自故障条件的迁移。三者缺一，追溯链就不完整。

可追溯映射表的示例

实际项目中，建议在需求管理工具与 Simulink 之间维护一张映射表，字段不必多，但要能双向查。以下为电动车窗防夹的示例片段：

需求ID     | 类型 | 需求描述                          | Stateflow元素
SG-01      | SG   | 避免车窗上升挤压乘员              | 安全状态: AntiPinch / Fault
FSR-01-01  | FSR  | 夹持力>100N时100ms内停止上升      | 迁移: Up -> AntiPinch, after(100,msec)
FSR-01-02  | FSR  | 停止后反向下降至少50mm            | 状态: Down, 迁移条件 positionDelta>=50
TSR-01-01  | TSR  | 防夹检测周期<=10ms                | 状态机采样时间: 0.01 s
TSR-01-02  | TSR  | H桥方向翻转<=20ms                 | Down.entry: direction = DOWN
TSR-01-03  | TSR  | 电流采样分辨率<=10mA              | 输入端口: fixdt(1,16,10)

这张表的价值在于：当 FSR 变更时，可以快速定位到需要修改的状态或迁移；当模型评审时，可以反向检查每个状态是否有需求来源。对于 ASIL B 的防夹功能，这种双向追溯是功能安全审核的必查项。

常见映射错误与修正

初学者最容易犯三类错误。第一类是把 FSR 直接写成状态名，例如把“防夹”画成一个状态，但内部没有停止和反向的时序区分，导致 100 ms 超时无法验证。修正方法是按“检测—停止—反向”拆成至少两个状态。第二类是把 TSR 的硬件参数写进迁移条件，例如在迁移上写“电流 > 2.5 A”，但 2.5 A 是标定值而非需求值，应改为 PinchDetected 事件，由标定参数模块提供阈值。第三类是故障响应全部汇入一个 Fault 状态，丢失了不同失效模式的诊断信息，修正方法是保留独立故障迁移条件，再汇聚到安全状态。

完成映射后，下一步才是用 Stateflow 编辑器把这些状态、迁移、事件和动作真正画出来，并配置采样时间、数据类型和代码生成选项。映射表是模型的地基，地基不稳，后面的测试和追溯都会反复返工。