1. 课程导入与故障管理全景
在嵌入式控制系统中，故障管理并不是“出问题再处理”的补丁逻辑，而是一套贯穿需求、设计、实现与验证的安全机制。Stateflow 作为 MATLAB/Simulink 环境中的状态机与流程图建模工具，恰好处于这套机制的“决策中枢”位置：它接收来自传感器、诊断模块和通信总线的故障信号，依据当前系统状态与故障等级，决定系统是继续运行、降级运行、进入安全状态，还是执行受控停机。本课程围绕这一核心定位展开，目标是让读者能够独立设计可验证、可追溯、可复现的故障管理与安全状态机。
Stateflow 在故障管理中的位置
要理解 Stateflow 的定位，需要先看清一条完整的故障处理链路。以典型的电机控制系统为例：底层驱动采集电流、温度、转速等物理量，诊断模块（如 Simulink 中的监测子系统或外部诊断服务）对原始信号做阈值判断、合理性校验和故障确认，输出标准化的故障标志与故障等级；Stateflow 状态机则消费这些故障信息，结合运行模式、使能条件和操作员指令，输出模式切换命令、功率限制系数、继电器控制信号等执行动作；执行结果再通过监控与标定环节反馈回诊断模块，形成闭环。
这条链路中，Stateflow 承担的是“判断与决策”职责，而不是信号采集或数值计算。它最擅长表达的是：在什么状态下、满足什么条件、发生什么故障时，系统应当迁移到哪个状态、执行哪些动作。这种“状态—事件—动作”的表达方式，比用 if-else 堆叠的代码更接近安全工程师的思维模型，也更便于评审和验证。
学习目标与知识框架
本课程的学习目标可以归纳为四个层次。第一层是概念层：理解故障、失效、安全状态、降级运行等术语在功能安全语境下的准确含义，区分“故障检测”与“故障响应”的边界。第二层是建模层：掌握 Stateflow 中状态、迁移、条件、动作、并行状态、历史节点等核心元素的语义，能够把一段故障处理需求转化为可执行的状态机模型。第三层是设计层：能够根据故障等级设计分层响应策略，处理故障恢复、故障叠加、状态冲突等复杂场景。第四层是验证层：能够通过仿真、测试用例和覆盖度分析，证明状态机在各类故障注入下都能进入预期的安全状态。
整体知识框架按照“需求—设计—实现—验证—复盘”的工程实践路线组织。需求阶段关注故障清单、故障等级划分和安全目标；设计阶段关注状态机架构、状态层级和迁移逻辑；实现阶段关注 Stateflow 建模规范、数据类型、代码生成配置；验证阶段关注测试用例设计、故障注入和覆盖度指标；复盘阶段关注典型失效模式、设计评审要点和持续改进。这条路线不是线性的一次性过程，而是随着项目迭代不断回流的闭环。
工程实践路线与关键约定
在实际项目中，故障管理状态机的设计通常从一份故障清单开始。清单中每条故障至少包含：故障名称、触发条件、确认时间、故障等级、期望响应、恢复条件和恢复时间。例如，某电机控制器定义“母线过压”故障：当母线电压持续超过 420 V 达 100 ms 时确认，等级为严重，期望响应为在 50 ms 内将功率限制到 0 并断开主继电器，恢复条件为电压回落至 400 V 以下并保持 500 ms。这些参数不是随意设定的，而是来自系统安全分析和硬件耐受能力评估。
Stateflow 建模时，建议采用“顶层模式 + 故障响应子状态”的分层结构。顶层模式表达系统运行模式（初始化、待机、运行、故障处理、停机），故障响应子状态表达不同故障等级下的具体行为。这样做的原因是：运行模式与故障响应是两个正交的关注点，分层后可以独立修改，避免状态爆炸。对于需要同时处理多个故障的场景，可以使用并行状态或优先级仲裁，但必须明确优先级规则，例如“安全停机优先于降级运行，硬件故障优先于通信故障”。
Run_Normal、Run_Degraded、Fault_SafeStop；迁移条件中故障标志统一使用 flt_ 前缀，如 flt_overVoltage；状态动作中输出变量统一使用 cmd_ 前缀，如 cmd_powerLimit。这些约定在团队协作和代码生成时能显著降低沟通成本。
验证环节需要特别强调“故障注入”的完整性。一个常见的误区是只测试单故障场景，而实际系统中最危险的是故障叠加和故障恢复过程中的瞬态。例如，系统在降级运行期间又发生通信故障，此时状态机应当如何迁移？如果设计时没有明确规则，就可能出现状态振荡或输出不确定。建议在测试用例中覆盖：单故障确认与恢复、多故障同时发生、故障在迁移过程中发生、故障信号抖动、故障恢复后重新进入运行模式等场景。