功能安全（Functional Safety）是一项系统特性，由于基于功能安全的设计会影响到系统设计，所以从系统开发初始阶段就要进行考虑。由于软件的复杂度会影响 到功能安全的设计，所以在AUTOSAR规范中，包含了部分与功能安全相关的需求，这些新技术和概念能够帮助降低功能安全相关组件的复杂度。不过需要强调的是，AUTOSAR虽然通过提供安全措施和机制来支持基于功能安全产品开发，但这些独立的安全措施（Safety Measure）并不能形成整体的安全解决方案。
在功能安全标准（ISO 26262 2018, Part 6）中，提到了要避免软件相关元素之间干扰（Freedom from Interference between software elements）。软件之间的相互干扰主要集中在软件的执行时间（Timing），软件间的死锁（Dead locks，Live locks），内存使用（Memory），信息交换（Information Exchange）。
本文主要介绍一下AUTOSAR规范中对于软件执行时间的保护措施。
软件的执行时间是嵌入式产品一项非常重要的属性。安全（Safety）的行为需要系统能够在正确的时机响应外部触发。正确的时机可以描述为一系列对于响应时间的限制条件。但即使基于AUTOSAR的软件，也无法由软件自身来保障正确响应时间，这依赖于合理的使用AUTOSAR RTE和BSW组件。在集成过程中，需要保障对AUTOSAR软件的执行时间限制。
在ISO 26262中与软件执行时间相关的失效模式有如下几种：
阻塞执行（Block of Execution）
死锁（Dead Locks）
活锁（Live Locks）
不正确的执行时间分配（Incorrect allocation of execution time）
软件组件间的错误同步（Incorrect synchronization between software elements）
时间保护与监控可以描述为监控如下的软件属性：监控任务是否在指定时间内进行了分配，任务是否在其时间预算内正确执行，是否存在大量占用系统资源的情况。为了保障功能安全相关的功能满足这些时间限制条件，任务（Task）对于CPU资源的使用情况需要进行监控。
AUTOSAR系统中，提供了如下2种执行时间保护机制：
基于AUTOSAR操作系统的执行时间保护机制，包括执行时间保护、阻塞时间保护和间隔时间保护；
基于Watchdog Manager的程序流监护机制，包括心跳检测、Deadline检测和执行逻辑检测。
监管对象是指由Watchdog Manager监管的在ECU运行的一系列应用软件。这些应用软件之间（包括和AUTOSAR组件之间），不需要存在特定的架构上的联系。典型的监管对象可以是SWC, CDD, BSW Module，完全取决于应用开发人员的需求。监管的要点在于监管对象中存在的一系列检查点，监管对象的代码和检查点的代码一般的交错在一起的，检查点用于触发针对Watchdog Manager的函数调用。
Watchdog Manager是AUTOSAR BSW中的组件。Watchdog Manager负责触发真实的Watchdog硬件，用于监控软件的执行。一旦针对预定的执行时间或执行逻辑的异常发生，则会触发一系列预先设置恢复措施（如，重启）。
基于Watchdog Manager的监控措施有几种：
心跳监控 周期性运行的监管对象对于执行的频率有限定性要求。Watchdog Manager通过周期性的检查监管对象触发的检查点，可以监控监管对象是否存在执行频率过高或者过低的问题
Deadline监控 非周期性运行的监管对象，在检查点之间，具有独立的执行逻辑限制。通过Deadline监控，Watchdog Manager检查2个检查点之间的执行时间是否在允许的范围内
3 基于操作系统的执行时间保护
在实时系统中（Real-time），时间故障经常发生在任务或者中断没能在指定的时间内触发。AUTOSAR OS不提供基于Deadline监控的执行时间保护机制，主要是违反Deadline监控的原因通常是由于其它一些非相关的任务或者中断的执行（这里可以参考AUTOSAR OS的规范）。
在一个抢占式的系统中，任务或者中断能否达成Deadline的限定取决以下几个方面：
任务或者中断的执行时间
任务或者中断被低优先级任务的阻塞时间
任务或者中断执行的间隔
为了达到安全和精确执行时间保护，操作系统要能够实时控制这些可能的因素，来确保任务和中断能够达成Deadline的限制条件。
AUTOSAR OS提供基于如下措施：
执行时间保护（Execution Time Protection） 针对任务及CAT2的中断，系统设置了执行时间的预算（Execution Budget），OS通过监控执行情况，可以阻止相关的执行时间错误
加锁时间保护（Locking Time Protection） 针对资源加锁的时间，中断的加锁和挂起时间设置上限，也由OS进行监控.
间隔时间保护（Inter-Arrival Time Protection) 针对任务触发时间和CAT2中断间隔时间设置最小间隔，由OS进行监控并保护。
Watchdog Manager提供了3种用于程序执行时间和逻辑的监控机制。这些机制需要事先经过静态配置，另外，多个监控机制可以同时部署。
基于任一机制的检测结果，针对特定监管对象的状态可以被计算出来（通常以计数器的形式表示，称为Local Status）。当所有的监管对象的状态计算完毕，则整个ECU的全局状态也就确定了。
基于这些监管对象的状态和ECU的全局状态，Watchdog Manager使用几种安全机制来恢复异常的监控状态，包括针恢复单个监控对象的状态到Reset整个ECU：
监控对象内部的错误处理（Error Handling in the Supervised Entity）
如果被监控的对象是Swc或者Cdd，Watchdog Manager可以通过RTE的状态（Mode）机制通知监控对象，监控对象可以通过预定义的动作恢复正常状态。
Watchdog Manager也可以注册回调到Dem中，这样恢复的动作也可以为Dem触发。
关闭分区（Partition Shutdown）
如果Watchdog Manager检测到出错的监测对象位于non-trusted分区中，Watchdog Manager可以通过BswM关闭这个non-trusted分区。
通过Watchdog硬件重启ECU （Reset by Hardware Watchdog）
Watchdog Manager停止通过Watchdog Interface更新Watchdog硬件，在超时之后，Watchdog硬件重启ECU或者MCU，则包括软件和硬件在内的都会被重新初始化。
ECU立即重启（Immediate MCU Reset）
如果判断需要执行全局的立即重启，Watchdog Manager可以直接触发MCU重启的动作。MCU重启可以重新初始化MCU内部的硬件和软件，但外部硬件不执行初始化动作。
AUTOSAR提供的保护机制中有如下的限制：
检查点的粒度不固定，但检查点的粒度过粗会影响Watchdog Manager的检测能力。例如一个Swc只有一个检查点的情况下，Watchdog Manager只能监控到Swc内的Runnable在执行，以及是否满足限定的时间的要求；如果在Swc内部Runnable的每个代码段或分支中，都有相应的检查点，则可以监控Runnable控制流是否有问题。不过，细粒度的检查点可能会导致针对Watchdog Manager的配置变得十分复杂难以维护
基于Deadline的监护有个弱点，即只能检测到特定的任务是否存在Delay（一次执行时，最后一个检查点被执行到），但不能检测到超时（如，检查点根本没被执行）
不支持嵌套的Deadline检测
基于心跳的检测一般只使用一个检测点，多于一个的情况在AUTOSAR规范中并未指定
在重启一个AUTOSAR分区时，分区内的其它监管对象也要进行相应的动作
以Library形式组入的组件不能调用BSW的接口，所以Library不能监控，但可以使用Deadline监控，因为Deadline的检查点可以在执行完Library接口后调用。
大众ID.4X的ECU接口梳理
浅析J1939协议 |附下载
大众ID.4 X网络架构详解
汽车芯片为什么会出现短缺？
学习笔记——NVM数据处理机制
学习笔记——AUTOSAR NVM基础知识
浅析特斯拉Model 3的热管理策略
基于UDS的Bootloder详解
关于整车上下电流程的理解
一文详解奥迪e-tron内部系统 |附下载
ID.3 和大众的电气化平台 |附下载
一文详解CAN总线错误帧|附下载
DoIP协议介绍，资料分享！
详解车载网络 OTA系统的开发|文末附下载
一文了解汽车嵌入式AUTOSAR架构|附下载
特斯拉Autopilot系统安全研究|附dbc下载
