4. 故障监控核心概念

在功能安全工程中，故障监控不是“看到异常就报警”这么简单。要设计出可验证、可追溯的安全机制，必须先厘清三个基础术语：故障（Fault）、错误（Error）、失效（Failure）。它们描述的是同一异常事件在时间轴上的不同阶段，而不是三个可以互换的同义词。理解这条因果链，是后续设计故障容错时间间隔、安全机制覆盖范围和诊断覆盖率的前提。

一、故障、错误、失效的定义与因果链

ISO 26262 对三者的定义可以这样理解：

• 故障（Fault）：系统或部件中可能导致错误的异常状态或缺陷。它可以是硬件老化、软件缺陷、电磁干扰、接插件松动、存储器位翻转等。故障是“原因”，可能潜伏很久而不被察觉。
• 错误（Error）：故障在运行中实际导致内部状态或数据偏离正确值。例如 RAM 某位翻转后，变量值从 0x10 变成 0x90，这就是错误。错误是“中间状态”，它可能被检测、纠正，也可能继续传播。
• 失效（Failure）：系统或功能在规定的条件下无法完成规定功能，表现为输出错误、功能中断或安全目标被违反。失效是“结果”，是用户或整车层面可观察到的异常。

三者的关系可以概括为：故障 → 错误 → 失效。一个故障可能引发多个错误，一个错误也可能传播为多个失效；反之，如果安全机制在错误阶段及时介入，就可以阻断“错误 → 失效”的转化。这正是故障监控的核心价值。

二、故障容错时间间隔（FTTI）

故障容错时间间隔（Fault Tolerant Time Interval，FTTI）是功能安全中非常关键的时间参数。它定义为：从故障发生开始，到必须采取安全措施、避免违反安全目标为止，所允许的最大时间窗口。FTTI 不是某一个器件的响应时间，而是整个“故障发生 → 错误传播 → 安全机制响应 → 进入安全状态”链路的总预算。

在 S32K 这类 MCU 中，FTTI 通常被分解为几个部分：故障检测时间、故障响应时间、安全状态进入时间。例如，一个电机控制应用中，若 FTTI 为 100 ms，则从电流采样异常到 PWM 输出被关断，整个链路必须小于 100 ms。工程上常用如下关系估算：

FTTI ≥ 故障检测时间 + 故障响应时间 + 安全状态进入时间
其中：
  故障检测时间 = 采样周期 + 诊断算法执行时间 + 去抖时间
  故障响应时间 = 中断延迟 + 安全逻辑判断时间
  安全状态进入时间 = 执行器关断 / 降级 / 复位所需时间

如果实际响应时间超过 FTTI，即使诊断覆盖率很高，系统仍然可能失效。因此，FTTI 是安全机制设计的时间约束，也是诊断覆盖率之外必须同步验证的指标。

三、安全机制覆盖范围与诊断覆盖率

安全机制覆盖范围（Safety Mechanism Coverage）描述的是：某个安全机制能够覆盖哪些故障模式、哪些硬件模块、哪些运行场景。它回答的是“这个机制管什么、不管什么”。例如，看门狗覆盖的是程序跑飞和任务超时，但不覆盖 RAM 位翻转；ECC 覆盖的是存储器位错误，但不覆盖传感器断线。

诊断覆盖率（Diagnostic Coverage，DC）则是一个量化指标，表示被安全机制检测到的故障比例。通常分为低、中、高三个等级：低覆盖率约 60%，中覆盖率约 90%，高覆盖率约 99%。在 ISO 26262 中，DC 与硬件架构度量（如 SPFM、LFM）直接相关，是计算 ASIL 等级的重要输入。

四、案例与场景：S32K 中的故障监控链路

以 S32K 微控制器在车身控制模块中的应用为例。假设安全目标是“避免车灯在行驶中意外熄灭”。可能的故障包括：MCU 内部 RAM 位翻转、看门狗时钟异常、输出驱动 MOSFET 短路、CAN 通信丢失。对应的错误可能是：控制变量被篡改、任务调度超时、输出引脚电平错误、报文超时。对应的失效则是：车灯熄灭或闪烁异常。

工程上会这样布置安全机制：用 ECC 覆盖 RAM 和 Flash，用看门狗覆盖程序流，用输出回读覆盖驱动级，用 CAN 超时监控覆盖通信。每个机制都有自己的覆盖范围和诊断覆盖率。最终要验证的是：从任一故障发生，到系统进入安全状态（如车灯保持常亮或降级为固定亮度），总时间是否小于 FTTI。

五、常见误区与复盘

• 误区一：把故障等同于失效。故障是原因，失效是结果。只关注失效现象，会漏掉大量潜伏故障。
• 误区二：只算诊断覆盖率，不算 FTTI。覆盖率再高，响应太慢也无法阻止安全目标被违反。
• 误区三：安全机制覆盖范围写得太宽。一个机制不可能覆盖所有故障模式，必须明确边界和假设条件。
• 误区四：忽略错误传播路径。错误可能从一个模块传播到另一个模块，监控点应尽量靠近故障源。