3. 故障管理需求到Stateflow模型的映射

故障管理需求通常以自然语言或需求管理工具中的条目形式存在，例如“当电机温度传感器信号超出有效范围持续200ms后，应确认传感器故障，并在50ms内将电机扭矩限制为0”。这类需求描述的是系统级行为，而Stateflow模型描述的是控制逻辑内部的状态与迁移。两者之间需要一次结构化的映射：把需求中的触发条件、确认时间、响应动作和安全目标，分别落到Stateflow的输入事件、状态迁移条件、状态动作和输出接口上。映射质量直接决定后续模型能否被验证、能否生成可追溯的代码。

需求分解的四个层次

一条完整的故障管理需求可以拆成四个层次，它们对应Stateflow模型中不同位置的元素。

故障检测层回答“什么信号、什么条件算异常”。它对应Stateflow的输入数据与迁移条件中的布尔表达式。例如温度传感器信号范围0.5V～4.5V，超出即置位原始故障标志 rawTempFault。这一层通常不放在状态机内部，而是由上游信号处理模块完成，Stateflow只接收已经过初步判断的布尔量或枚举量。

故障确认层回答“异常持续多久才认定为真故障”。它对应Stateflow中的计时状态或计数器。常见做法是设置一个“待确认”状态，进入后启动计时器，若在确认时间内异常消失则返回正常状态，若持续到阈值则迁移到“已确认”状态。确认时间参数应作为可标定量，而不是硬编码在迁移条件中。

故障响应层回答“确认故障后系统做什么”。它对应Stateflow中的动作状态或输出赋值。响应可能是降级、限功率、切换备用通道或请求进入安全状态。响应动作应通过输出接口表达，而不是直接操作底层硬件寄存器。

安全状态进入层回答“什么条件下必须进入安全状态、进入哪个安全状态”。它对应Stateflow中的顶层安全状态或并行区域中的安全监控子状态机。安全状态进入通常具有最高优先级，需要覆盖其他响应逻辑。

状态机接口定义的关键约定

接口定义是映射中最容易出问题的地方。输入接口应只接收已经过信号处理层判断的布尔量或枚举量，避免在Stateflow内部直接做模拟量比较。例如 rawTempFault 由上游模块根据0.5V～4.5V范围判断后给出，Stateflow只负责确认和响应。输出接口应使用语义明确的命名，如 faultConfirmed、torqueLimit、safeStateReq，而不是直接输出硬件控制字。

确认时间、响应时限、安全状态进入条件中的阈值，都应定义为可标定量或参数，通过输入接口或模型参数传入。这样在标定阶段可以调整200ms、50ms等数值，而不需要修改状态机结构。对于安全状态请求，建议使用独立的布尔输出，由下游安全逻辑决定具体执行哪个安全动作，Stateflow只负责发出请求。

一个完整的映射示例

以“电机温度传感器故障”为例，需求条目为：当温度传感器信号超出0.5V～4.5V范围持续200ms后，确认传感器故障，并在50ms内将电机扭矩限制为0；若同时存在过流故障，则直接请求进入安全停机状态。

映射到Stateflow后，输入接口包括 rawTempFault、rawOverCurrentFault、tempValid。确认子状态机在 rawTempFault == true 时从“正常”迁移到“待确认”，启动计时器 tConfirm；若 tConfirm >= 200ms 则迁移到“已确认”，输出 faultConfirmed = true。响应状态机在收到 faultConfirmed 后，于下一个执行周期将 torqueLimit 置0，满足50ms响应时限。安全状态监控并行运行，当 faultConfirmed && rawOverCurrentFault 同时为真时，置位 safeStateReq = true，并迁移到安全停机状态。

需求到模型的追溯关系

为了支持后续验证和变更管理，每条需求条目应与Stateflow中的具体元素建立追溯链接。检测需求追溯到输入接口和迁移条件；确认需求追溯到计时状态和确认阈值参数；响应需求追溯到响应状态机的动作和输出接口；安全状态需求追溯到安全状态及其迁移条件。这样当需求变更时，可以快速定位需要修改的模型元素，而不是重新通读整个状态机。

映射过程中还需要注意执行顺序与优先级。安全状态进入应具有最高优先级，通常放在并行区域的顶层或使用状态机的默认迁移优先级控制。确认子状态机和响应状态机可以并行运行，但响应动作应等待确认结果，避免在故障尚未确认时就执行降级。对于多故障并发场景，应明确故障之间的优先级关系，例如过流故障优先于温度故障，安全停机优先于降级运行。

完成映射后，建议用一张接口清单固定输入输出信号、数据类型、单位、取值范围和默认值，作为模型与上下游模块的契约。这份清单也是后续生成代码和编写测试用例的直接依据。