3. 故障、错误与失效模型

在可靠性工程中，故障（Fault）、错误（Error）与失效（Failure）是三个必须严格区分的概念。故障是系统内部潜在的缺陷或异常原因，例如一段被篡改的指令、一个位翻转的内存单元、一条被错误配置的中断向量；错误是故障在系统运行过程中被激活后所呈现的不正确状态，例如寄存器值偏离预期、任务堆栈被破坏；失效则是错误传播到系统外部、导致系统无法提供规定服务的结果，例如看门狗复位、任务挂死或输出数据错误。三者构成“原因—状态—后果”的因果链，在VxWorks这类实时嵌入式操作系统中，这条链的传播路径与时间窗口尤其关键。

故障分类在VxWorks中的映射

按持续时间，故障可分为永久故障、间歇故障与瞬态故障。在VxWorks场景下，永久故障的典型代表是Flash中固化的启动参数被破坏、BSP中某个外设寄存器地址映射错误；间歇故障常出现在连接器接触不良、DDR时序裕量不足导致的偶发读写错误；瞬态故障则多由空间辐射、电源毛刺或电磁干扰引起，表现为单粒子翻转（SEU）造成的位翻转。按来源，又可分为硬件故障、软件故障与设计故障。软件故障在VxWorks中尤为常见，例如优先级反转未处理、信号量误用、中断服务程序（ISR）中调用了不可重入函数。

按边界，故障还可分为内部故障与外部故障。内部故障如任务栈溢出、内存池耗尽；外部故障如网络报文异常、传感器输入超范围。VxWorks的taskSpawn创建任务时若未指定足够的栈空间，运行中就可能因栈溢出破坏相邻内存，这属于典型的内部软件故障。理解分类的意义在于：不同类别故障的注入方式、检测手段与容错策略完全不同。

错误传播路径与建模

错误不会静止不动，它会沿数据流、控制流或资源依赖关系传播。在VxWorks中，一条典型传播路径是：内存位翻转 → 任务读取到错误数据 → 计算结果错误 → 通过消息队列发送给另一任务 → 另一任务基于错误数据做出错误决策 → 最终输出失效。这条链可能跨越任务、中断、驱动和网络协议栈多个层次。建模时，我们通常用故障—错误—失效传播图描述节点与边：节点表示系统状态或组件，边表示数据/控制依赖，故障注入点作为源，失效作为汇。

失效模式与VxWorks的对应关系

失效模式描述系统“怎样坏”。在VxWorks中，常见的失效模式包括：任务级失效（任务挂死、死锁、优先级反转导致高优先级任务饿死）、系统级失效（内核崩溃、内存耗尽、看门狗复位）、通信失效（网络丢包、消息队列溢出、串口帧错误）以及数据失效（计算结果错误但系统仍在运行，即静默数据损坏）。其中静默数据损坏最危险，因为系统表面正常，但输出已不可信。例如，一个控制任务因内存位翻转导致PID参数被篡改，系统仍周期运行，但控制量持续偏离，最终导致执行机构误动作。

失效模式与故障分类之间存在映射关系：瞬态故障常导致间歇性失效，永久故障导致确定性失效，而软件设计故障往往在特定时序或负载条件下才暴露，表现为偶发失效。建模时，我们为每种失效模式定义可观测的判据，例如任务心跳超时、看门狗未喂、CRC校验失败、输出越界等。

建模方法与实操要点

在VxWorks上建立故障—错误—失效模型，通常分四步。第一步，识别关键组件与依赖关系，绘制系统架构图，标注任务、中断、驱动、内存区域和通信通道。第二步，定义故障注入点与注入方式：硬件层可用JTAG或调试器修改内存；软件层可用taskHook在任务切换时注入错误；接口层可构造异常报文。第三步，定义错误检测点与传播边，例如在消息队列收发处增加校验，在关键计算前后增加断言。第四步，定义失效判据与恢复策略，例如看门狗超时后记录日志并重启任务。

一个可参考的建模参数表如下（示例参数，非实测）：

最后需要强调，模型的价值在于指导注入与观测。没有明确的失效判据，故障注入就只是“制造混乱”；没有传播路径分析，容错设计就只是“盲目加固”。在VxWorks实时系统中，时间约束使传播窗口极短，因此检测点应尽量靠近故障源，恢复策略应尽量局部化，避免全局重启带来的服务中断。