从看门狗到Dual MCU监控

如今车辆上的汽车电子控制单元越来越多，软件结构也越来越复杂，如何保证软件运行过程中“不出错”，这是值得深思的。

 

首先要回答一个问题：何谓“不出错”？

总而言之，统而言之，软件完全按照设计需求运行即不出错。

 

但是怎么来衡量“完全”呢？ MCDC 100%的coverage，也不能说是“完全”。即使花特别特别多的人力物力，穷举了软件的所有可能性且都通过过了测试，我们就能说完全吗？我的答案是“NO”。

 

软件的载体是什么？是硬件，是芯片（MCU/DSP/FPGA……），如果芯片在运行过程中因各种各样的内外部条件发生错误或者对芯片的配置错误，软件也可能完全运行失控。因此，这就需要一种机制来发现这种错误并且试图把软件给救回来。

 

 

上图是Infineon的经典芯片XC164的体系架构，假定有如下情况发生：

1.外部时钟停止工作/时钟频率不正确

2.PMU单元故障

3.中断频繁嵌套且系统堆栈设置不够，堆栈溢出

4.定时器故障会导致什么后果？？？软件跑回他老外婆家里喝高云里雾里了。

 

为了能够把这个识别这种故障并试图把软件救回来，因此就需要用到各种各样的狗和监控策略。

 

（一） 软件（内部）看门狗

很多MCU都有专用的WatchDogTimer，不带WDT的芯片也可以用通用的定时器来实现软件看门狗的功能，其基本原理为需要应用软件在定时器发生溢出之前重设Timer的值（所谓的踢狗），让Timer永远不溢出。

一旦Timer溢出，说明软件没有正确的运行到，在Timer的溢出中断中做SoftReset。这种策略对于软件跑飞是有效的，但对于外部时钟停止工作/时钟周期不正确是无能为力的。

 

（二）硬件（外部）看门狗

硬件看门狗跟软件看门狗比较类似，不过被喂的狗从芯片的内部移到了芯片的外部，一般是另外一个WDT芯片（现在一般都集成在LDO里面），MCU的一根GPIO通过软件定时的踢狗，如果在一定时间窗口内WDT没有收到喂狗信号，就通过连接到MCU Reset管脚的连线进行硬件复位。使用外部狗对软件跑飞、外部时钟停止工作都能起到监控。但是对于软件内部运行顺序不正确、时钟变快或变慢都无能为力。

 

（三）主辅MCU监控

主辅MCU监控的思路是用另一个MCU来监控主MCU。

 

 

两个MCU之间采用串行（比如SPI、IIC等）通讯，将主MCU的应用软件分成若干个时间片，在每个时间片内主MCU依次通过串行通讯向辅助MCU发送不同的接头信号（如：天王盖地虎、开飞机的舒克等等），进行如下监控：

1.用辅助MCU的时钟信号检测主MCU通讯线路的CLK信号，如协议栈中规定采用1MHZ的通讯频率，辅助MCU检测通讯真实周期，如偏差太大，说明主MCU的时钟周期有问题（其实也有可能是辅助MCU本身的时钟周期有问题，但并不影响软件的策略），硬件Reset主MCU

2.辅助MCU检测串行通讯线路上是否收到了正确接头信号，接收到接头信号以后，往主MCU上发送应答（如收到天王盖地虎则回发小鸡炖蘑菇，收到开飞机的舒克则回发开坦克的贝塔等），如没有收到正确的接头信号或接头信号的顺序不对，则应将Reset主MCU

3.主MCU同样检查辅助MCU的应答，应答不正确则硬件Reset辅助MCU

 

（四）Dual MCU监控

DUAL MCU监控是主辅MCU监控的升级版，这个可开篇作为一个专题另讲，可以完成ASIL要求的更多的功能：

1.传感器的信号冗余监控

2.执行机构冗余控制

3.两个MCU实现不同的分工，协作完成系统功能

4.冗余软件监控（针对CPU运算单元故障、用不同的实现方式在两个MCU内实现相同的功能并进行比较）

 

关于Reset之后的处理，不同应用场合的软件会有不同的做法。一般来说，对安全等级要求比较低的系统，Reset之后可以让软件重新自检一遍，如果正常工作的条件具备，则让系统恢复正常工作；对安全等级要求比较高的系统，Reset之后让系统进入FailSafe状态，只有驾驶员有停车、重新Ignition的动作以后，才执行另一遍自检，如正常工作的条件具备，恢复正常工作。