一文带你全面了解功能安全软件监控方案_功能安全软件程序流控制

        引言：功能安全标准（ISO26262 Part6）提到了用于错误探测的安全机制，其中就有程序流监控，如图1所示；本文主要探讨在AUTOSAR CP以及AP的场景下，怎么实现程序流监控。

图1  ISO26262 Part6

 一、CP场景下的程序流监控

       CP场景下执行程序流监控的工作栈如图2所示，包含软件部分以及硬件部分。硬件部分就是通常所指的“硬件看门狗”，其本质是个定时器，初始阶段会被设置一个定时值，称为“timeout”。硬件看门狗被使能工作之后，便会开始计时，当超过时间阈值，“timeout”没有被重置（通常重置时间阈值的操作被称为“喂狗”），硬件看门狗便会复位MCU，进入安全状态。

图2 CP场景下的程序监控工作流

        程序监控以及“喂狗操作”需要软件部分的参与，软件堆栈参考的是AUTOSAR CP架构，包含三个部分：WdgM、WdgIf以及Wdg Driver：

        WdgM负责对软件进行监控，如果程序运行正确，则WdgM调用WdgIf提供的接口进行“喂狗”，WdgIf进一步调用Wdg Driver提供的接口进行“喂狗”，而最终的“喂狗”操作实际由Wdg Driver完成。

        如果WdgM监控到程序运行错误，则会引发相应的故障处理措施：通常是停止喂狗或者将硬件看门狗的定时值置为0，引发看门狗的立即复位。接下来，对此三个软件模块展开详细说明。

1、WdgM模块

       WdgM模块的作用是监控软件是否正常运行，如果软件正常运行，则WdgM调用WdgIf模块提供的接口进行喂狗；如果软件运行中出现错误，则执行相应的错误处理，主要包括：通过RTE将错误通知给软件，让其执行恢复处理、将错误报告给DEM（Diagnostic Event Manager）模块、停止喂狗、将timeout设置为0，MCU立即重置或发出中断信号。

相应术语解释

（1）SE：Supervised Entities ，监控实体

        一种软件实体，包括在WdgM的监控之下。每个受监控的实体只有一个标识符。监控实体表示软件组件或基础软件模块中的检查点集合。在软件组件或基础软件模块中可能有零个、一个或多个受监控的实体

        监控实体和AUTOSAR中的架构模块之间没有固定的关系，即SW-Cs、CDDs、RTE、BSW模块，但通常情况下，一个监督实体可以代表一个SW-C、一个BSW模块或CDD中的一个可运行对象  

（2）CP：Checkpoint，检查点

        被监控实体中的一个点，在那里活动被报告给WdgM

1）三种监控

      WdgM监控程序是否正常运行主要包括三种类型：

• Alive supervision：程序是否周期运行
• Deadline supervision：程序运行时间是否正确
• Logical supervision：程序的执行逻辑是否正确

2）本地状态和全局状态

      本地状态表示的是WdgM监控的单个SE的程序运行状态，主要包含以下几种：

• 状态一：OK：监控的SE未出现三种监控错误 
• 状态二：FAILED：监控的SE出现Alive错误，且错误没有超过Alive错误容忍值；同时，SE没有出现Deadline和Logical错误
• 状态三：EXPIRED：监控的SE出现Deadline或Logical错误，或者出现Alive错误并且Alive错误次数超出容忍值
• 状态四：DEACTIVATED：SE程序流监控没有使能

图3 本地状态转移关系

图4 本地状态转移情况说明

        全局状态表示的是WdgM监控的所有SE的状态汇总，主要包含以下几种：

• 状态一：DEACTIVATED：全局状态的初始值
• 状态二：OK： 所有SE的状态都为OK或者DEACTIVATED 
• 状态三：FAILED：至少一个SE的状态为FAILED且没有SE的状态为EXPIRED
• 状态四：EXPIRED：至少一个SE的状态为EXPIRED且次数没有超过监控错误容忍度值
• 状态五：STOPPED：至少一个SE的状态为EXPIRED且次数超过监控错误容忍度值

图5 全局状态转移关系

图6 全局状态转移情况说明

3）WdgM函数接口

图 7 初始化WdgM模块流程图

图8  WdgM_MainFunction与WdgM_CheckpointReached交互

2、WdgIf模块

        WdgIf模块的功能是为WdgM与看门狗驱动的交互提供函数接口。

3、Wdg Driver模块

        Wdg Driver模块的功能是与看门狗硬件通信，负责实际的喂狗操作。

二、AP场景下的程序流监控

        AP场景下实现程序流监控如图9所示，也包含软件部分和硬件部分。软件部分主要是AUTOSAR-AP协议栈的PHM、SM、EM软件模块，硬件部分则是硬件看门狗。

        AP场景进行程序流监控的相关术语、本地状态和全局状态、状态之间的转移关系和CP场景下的差不多，本文不再赘述。有区别的主要是执行程序流监控的软件模块和故障处理方式，接下来主要介绍这两方面的内容。

图9 AP场景下的程序监控工作流

1、AP软件模块

        AP中和程序流监控相关的主要软件模块是PHM、SM以及EM，具体来说，PHM负责执行具体的程序流监控，并基于监控的结果决定和其它模块的交互方式；SM负责状态管理；EM根据SM的状态切换请求执行具体的状态切换。

2、故障处理方式

        程序执行出现问题，存在三条故障处理链路。

链路一

        PHM监控到程序流出现问题，PHM报告给SM模块，SM根据注册的相应故障处理程序进行处理，包括停止出错的应用程序；重启出错的应用程序以及重启平台；

链路二

        如果SM超时没有将错误处理的结果返回给PHM，PHM则直接将故障上报给EM，EM处理也分三种不同的级别：停止应用程序、重启应用程序以及重启平台； 

链路三 

        如果EM出错，没有及时返回故障处理的结果，则PHM通知硬件看门狗复位整个平台。

三、程序流监控总结

        程序流监控的目的是避免程序在执行逻辑以及执行时序上出现非预期行为。程序流监控由软件来实现相应的监控逻辑，具体到CP以及AP端，采用的软件模块会有所不同，两者相同的是都会采用硬件看门狗复位的方式来处理故障。

        为了满足功能安全的要求，仅仅了解不同监控软件模块的功能以及硬件看门狗是不够的，还需要结合具体的系统设计（例如故障处理时间间隔  Fault Handling Time Interval ，FHTI）来正确设置不同的软硬件参数，达到最优的程序流监控效果。

        经纬恒润功能安全团队成立于2008年，系国内较早从事功能安全技术研究的团队。作为功能安全、预期功能安全国家标准委员会成员，经纬恒润的研发流程、生产流程已通过功能安全开发过程认证，功能安全开发过程达到ASIL-D，相关产品已成功服务于近百家国内外整车及零部件企业。

        经纬恒润功能安全软件团队可提供功能安全软件开发技术咨询服务，包括功能安全软件阶段流程/产品咨询、L2监控算法开发集成和L3安全机制（安全通信、隔离、监控、执行和芯片AOU）的开发集成，控制器覆盖动力域、底盘域、智驾域和车身域等。

        未来，经纬恒润将紧跟行业发展趋势和市场需求，结合自身汽车电子产品研发和国内外咨询实践，一如既往地坚持自主创新道路，为智能汽车安全保驾护航。

了解更多：请致电 010-64840808转6115 或发邮件至market_dept@hirain.com（联系时请说明来自CSDN）