系统可靠性概述：嵌入式系统故障模型、可靠性指标与看门狗的作用
各位工程师朋友，今天我们来聊聊系统可靠性。这个话题，说白了就是回答一个问题：你的设备会不会挂？挂了之后能不能自己活过来？
我在VxWorks项目里摸爬滚打这么多年，见过太多因为可靠性没做好，导致现场翻车的案例。有一次，一个远程基站设备在野外运行了三个月，突然死机，现场工程师坐了两天火车赶过去，结果只是按了一下复位键。嗯，从那以后，我就特别重视看门狗这个看似简单的机制。
嵌入式系统的故障模型
要谈可靠性，先得知道系统会怎么坏。我习惯把嵌入式系统的故障分成三类：
- 硬件故障：比如电源波动、晶振停振、内存位翻转（bit flip）。这类故障往往是物理层面的，不可预测。
- 软件故障：比如死循环、内存泄漏、任务优先级反转导致死锁。这类故障，说白了就是代码写得不严谨。
- 环境干扰：比如电磁干扰（EMI）、温度过高、振动。我在一个工业控制项目中遇到过，电机启动瞬间的电磁干扰直接把CPU的PC指针打飞了，程序跑飞到了未定义区域。
你想想看，这些故障一旦发生，系统如果没有自恢复能力，就只能等人去手动复位。这在无人值守的场景下，是不可接受的。
可靠性指标：MTBF与MTTR
衡量系统可靠性，有两个核心指标：
| 指标 | 全称 | 含义 | 我的理解 |
|---|---|---|---|
| MTBF | Mean Time Between Failures | 平均无故障工作时间 | 系统能稳定跑多久才出一次问题 |
| MTTR | Mean Time To Repair | 平均修复时间 | 出问题后，系统需要多久才能恢复正常 |
举个例子，如果一个系统的MTBF是10000小时，MTTR是1小时，那么它的可用性（Availability）就是 MTBF / (MTBF + MTTR) ≈ 99.99%。
我个人习惯在设计初期就定下这两个目标。比如，对于车载ECU，MTBF通常要求达到几万小时，而MTTR则希望控制在毫秒级——说白了，就是系统挂了要能瞬间自己恢复。
看门狗在可靠性中的作用
看门狗（Watchdog Timer）是提升可靠性的最经典手段。它的作用其实很简单：
- 如果系统正常运行，会定期“喂狗”（重置定时器）。
- 如果系统卡死或跑飞，没有及时喂狗，看门狗超时后就会触发系统复位。
这样一来，MTTR就从“人工到场修复”的几小时，缩短到了“自动复位”的几百毫秒。我曾经在一个项目中，因为任务调度器死锁，系统每隔几小时就挂一次。加上看门狗后，系统在100ms内自动恢复，用户几乎感知不到故障。
核心观点：看门狗不是用来防止故障的，而是用来缩短故障恢复时间的。它把MTTR从“人工干预”降到了“自动复位”。
VxWorks中的看门狗实现
在VxWorks中，看门狗通常通过硬件定时器实现。我常用的做法是：
/* 创建一个看门狗任务 */
void watchdogTask(void)
{
while (1)
{
/* 喂狗操作，复位硬件看门狗定时器 */
sysWatchdogReset();
/* 任务休眠一段时间，模拟正常工作 */
taskDelay(sysClkRateGet() / 2); /* 每500ms喂一次 */
}
}这里要注意，喂狗的频率必须大于看门狗的超时时间。比如看门狗超时设为1秒，那么喂狗间隔就不能超过1秒。我建议留出50%的余量，比如每500ms喂一次。
避坑指南：我曾经在一个项目中，把喂狗任务放在了低优先级任务里。结果高优先级任务占用了大量CPU时间，导致喂狗任务被饿死，看门狗频繁复位。后来我把喂狗任务优先级提到最高，问题就解决了。
看门狗的局限性
看门狗不是万能的。它只能处理“系统完全卡死”的情况。如果系统只是部分功能异常，但主循环还在跑，看门狗可能检测不到。比如，一个通信任务死锁了，但喂狗任务还在正常运行，看门狗就不会复位。
所以，我建议在关键路径上增加“健康检查”机制。比如，让通信任务定期向喂狗任务发送心跳信号，如果心跳丢失，喂狗任务就主动触发复位。
警告：不要过度依赖看门狗。它只是最后一道防线。真正的可靠性，还是要靠代码质量、冗余设计和充分的测试来保证。
总结
系统可靠性设计，说白了就是两件事：延长MTBF，缩短MTTR。看门狗是缩短MTTR的利器，但它不是银弹。我个人的经验是，把看门狗和任务健康检查、异常日志、冗余备份结合起来，才能构建真正可靠的嵌入式系统。
下一章，我们会深入VxWorks看门狗的具体API和配置细节。到时候我会分享一些实际项目中的调试技巧，敬请期待。
公众号:蓝海资料掘金营，微信deep3321