【看门狗软件设计】"喂狗"真那么简单吗?

1、聊一聊

     一首清新、熟悉、自然的曲子，分享一下。

     今天看到群内有小伙伴讨论看门狗的软件设计问题，于是分享一个之前项目的看门狗设计方案，也欢迎大家在文末分享留言讨论！

2、看门狗需求

    对于看门狗的bug菌在很早就聊到这个话题，所以一些基础知识大家可以直接看早期文章链接:

    大家在里面可以学习到什么是"独立看门狗"和"窗口看门狗"，以及一些看门狗使用的一些小技巧，然后再接着看本文内容。

  图片来源于 Pixabay

    可能在很多小伙伴目前接手的一些项目中根本没有使用到看门狗，前面的文章也说了，并不是每个项目都适合使用看门狗，特别是一些不能强制复位的项目，比如一些拥有复杂关机时序处理的项目，强制复位会带来经济上损失或者人身的安全。

使用看门狗的几点理由：

• 大部分的项目如果没有使用到看门狗对软件的运行把控会有所降低；
  
• 拥有一个强大的看门狗软件也能够快速暴露软件隐藏的问题，并且做好系统故障的收尾工作；
  
• 对于处于恶劣的环境中的系统可能会造成一些无法预知的问题，然而系统复位能够缓和这样的异常情况；
• 复位系统并不会带来负面的问题，那对系统的持续工作是有帮助的，比如很多智能的电表等等测量设备都是会有定期的复位，让系统持续工作。
  

3、看门狗设计

    看门狗软件设计可以非常复杂，也是非常简单，对于看门狗的印象大部分小伙伴基本上可以总结为:“定期喂狗，狗就不会咬你”。

    然而这句话的更多的把重点落在了"喂狗"和"狗咬你"这两个动作上，但看门狗软件的设计却是要达到如何喂狗来使得狗来监督整个系统的稳定性和可预见性上。

看门狗软件设计的考虑点：

• 什么时间喂狗比较合适 ? 
  
•  多长时间喂狗一次比较合适 ?
  
•  什么位置喂狗恰当 ?
  
• 如果涉及到多任务优先级系统，在低优先级任务喂狗还是在高优先级喂狗?
  
• 在中断中喂狗还是在任务中喂狗?
  
• 一旦触发看门狗系统如何进行数据的保存和最后的处理?
  

   。。。。。。

    以上这些问题根据具体的系统都会有不同的处理方案，比如喂狗时间太长无法监控到短时间的异常；喂狗位置单一无法监控到全局的软件运行情况；单一任务喂狗出现其他任务挂掉的问题。。。。。。

    bug菌就不一一例举，下面看一个之前项目的这块的设计方案，供大家参考 :

4、一个看门狗软件设计方案

    下面bug菌画一个简图描述下这个方案 :

总体分析：

• 上图通过安插在程序中不同的监控点进行运行信息的上报；
• 信息监督中心进行各个监控点的信息采集，然后对信息进行分类，识别和处理，并与预期的信息状态进行比对，判断是否存在异常的监控点。
  
• 如果存在异常监控点，看是否能够进行补救措施重新初始化相关数据来获得正确运行，并做好日志信息登记等处理，方便后期故障排查和bug定位，当然得记得喂狗。
  
• 如果没法补救，只能进入触发看门狗中断服务进行最后的数据保存等收尾工作，最终复位系统。

使用细节分析：

• 监控点最简单的就是每个任务一个上报点，当然也可以一个任务根据不同的状态安装多个监控点，使得软件更加符合我们的想法运行。
• 根据每个监控点的特点，比如有些任务执行得快，有些任务执行得慢；有些优先级高，有些优先级低等等，信息监督中心可以对慢速不重要的任务放松监控条件，对于紧急的任务加强监控条件等等。
• 信息监督中心一般会放在定时器中断中进行分析处理，一般中断的触发相对比较稳定，且中断处理优先级较高，所以会作为喂狗管控中心。
• 由于是系统复位并非上电复位，相关重要的数据其实可以直接通过RAM里面获得，这样可以加快机器复原速度，相关文章可以参考:<【√】以后复位芯片，数据再也不会丢了(理论篇)>，<【√】以后复位芯片，数据再也不会丢了(实战篇)>。

5、最后小结

    这种看门狗设计方案就为大家介绍到这里，细节处理还是挺多的，大家可以参考设计，从简到繁，各个击破！大家也可以把自己设计经验分享到下面的留言问答，共同交流学习！

    好了，这里是公众号:“最后一个bug”，一个为大家打造的技术知识提升基地。

推荐好文  点击蓝色字体即可跳转