基于ISO26262混合ASIL系统设计应用研究

谢凌云

(上海汽车变速器有限公司， 上海 201800)

0 引言

随着汽车电动化、智能化和网联化的推进，汽车俨然正在从一个传统的代步工具过渡为一个行走的智能终端。电驱控制、辅助驾驶、智能座舱和域控制器的开发成为汽车行业争相竞逐的风向标，这些功能的问世无不需要强大的软硬件支持，“软件定义汽车”的时代正悄然到来。随着这些技术的复杂性和软件内容的增加，随之而带来的是各种系统性失效和硬件随机失效的可能性，导致汽车功能失效的环节也从机械和电子逐步转变为更多的软件问题，如何解决汽车安全问题成为迈入“软件定义汽车”新时代需要去反复思考的新问题。

道路车辆功能安全标准正是以解决汽车开发过程中的安全问题为目的而制定的，其中规范的第六部分对于软件层面的描述强调了用软件分区实现软件组件间免于干扰[1]：要求一个软件分区内的任务彼此之间不能免于干扰；一个软件分区不能改变其他软件分区的代码和数据，也不能控制其他软件分区的非共享资源；一个软件分区从共享资源获取的服务不能被另一个软件分区影响。

总的来说，在AUTOSAR架构下开展对软件组件间免于干扰设计的研究有重要的应用价值和意义，是确保车辆软件安全可靠的有效途径。

1 软件分区设计

如果对初始安全要求的ASIL分解导致将分解后的要求分配给预期功能及相关安全机制，则相关安全机制宜被赋予分解后的最高ASIL等级[2]，也就是说按照汽车安全完整性等级要求，如果一个功能按照ASIL D等级开发，要使整个系统都达到ASIL D要求，其他不需要这么高等级的功能模块也需要按照最高等级要求开发，这会大大增加开发时间和成本。为解决以上提到的“ASIL等级提升效应”问题，功能安全标准允许通过软件分区的形式来实现不同安全等级的软件组件之间的隔离和共存。

符合AUTOSAR标准的软件提供了软件分区的应用，操作系统OS提供的分区由任务、中断、报警器、定时器、调度表和钩子函数等构成。本文在Vector提供的MICROSAR软件包的基础上，基于主控芯片英飞凌TriCore277设计的混合ASIL系统如图1所示，每个核都包含一个非信任和一个受信任的分区：非信任的分区运行在用户模式下，运行时受访问存储和OS API等限制；受信任的分区运行在特权模式下，运行时可以访问所有内存区域和OS API等。

图1 混合ASIL系统分区设计

2 免于干扰实现

软件分区的设计是实现免于干扰需求的前提架构，具体落实到软件实现，包含内存保护、时序保护和通讯保护等方面。

2.1 内存保护

合理的软件分区设计，可以抑制不同安全等级软件组件之间的交互影响，内存越界保护是实现软件模块之间边界保护的重要途径，主要使用微控制器内存保护单元(Memory Protect Unit，MPU)对内存区域的访问进行限制。

英飞凌TriCore277主控芯片的每一个核都拥有16个数据保护单元用于规定数据的读写访问权限和8个代码保护单元用于规定代码指令集的操作权限。同时拥有四个保护集(Protection Set，PS)，保护集搜集了该保护区域的读/写/执行权限，分区切换过程中通过选择不同的保护集从而实现快速切换访问权限的功能。

在MICROSAR软件平台的基础上，将OS的伸缩性等级配置为SC3，使其开启内存保护功能，通过配置多个Memory Region来实现分区之间的内存保护。如图2所示，每个Memory Region可配置的选项包含起始地址、终止地址、访问权限、所属保护集ID、所属内存和所属分区等。

图2 MICROSAR内存区域配置

如果未配置所属分区，该内存区域被认为是静态的，反之则是动态的。静态MPU区域在系统启动时就被设定好了，在OS运行过程中不再重新设置，通常用于多核访问权限的配置；动态MPU区域在OS运行过程中会随着分区的切换动态设置。

除了用户配置的区域保护外，同时MICROSAR软件对于任务或者中断栈的溢出保护也采用了MPU机制，在栈顶会留有MPU可识别的最小地址长度，该栈的使用者没有写入权限，当系统检测到该区域有数据写入，会触发MPU保护，根据用户需求选择Shutdown OS或者进入安全模式。

软件设计的混合ASIL系统内存保护按照如下表1方式配置，在兼顾系统易用的角度出发，重点对软件组件间的RAM数据交互进行保护。

表1 内存保护单元访问权限配置

2.2 时序保护

车辆功能安全规范要求对于高安全等级的软件实体需要实施相应的时序保护。关于时间限制，每个软件分区中执行的软件要素可考虑如下所列的故障影响[3]：

* 执行阻塞；

* 死锁；

* 活锁；

* 执行时间的不正确分配；

* 软件要素间的不正确同步。

AUTOSAR中对运行实体时序的保护通过程序流监控机制实现，包括监控执行时序和时间间隔两个方面。该监控机制的实现由软件看门狗模块和硬件看门狗配合完成，当看门狗监测到运行实体中任何不符合预期的行为将触发看门狗复位，让系统回归到正确的执行路径，保证系统处于安全模式下。本文描述的实现方式应用于TriCore277+TLF35584的芯片组合。

根据前面提到的分区设计，高安全等级的软件组件分布于每个核，为支持多核运行实体的监控，并做到每个核互不干扰，每一个核都会有单独的看门狗管理模块负责时序监控，并给出是否满足喂狗的条件，由GPT触发的定时中断会根据喂狗条件来决定是否喂狗操作。将喂狗操作放在中断执行是因为中断优先级高于OS任务，以防止OS任务抢占机制影响喂狗触发时机，导致提前或延迟喂狗，这种情况多发于系统启动过程中。

AUTOSAR软件对于喂狗条件的判定，提供了程序流保护机制(Program Flow Supervision，PFS)，它包含Alive Supervision、Deadline Supervision和Program Flow三种检查方式。监控机制通过检查点(Checkpoint，CP)来标记软件执行位置，通过这些检查点的执行来获取软件执行次序和执行时间。

(1) Alive Supervision

用于监控周期处理函数的执行频率，在周期处理函数中插入一个检查点，程序在检查点位置会通知看门狗管理程序周期函数已执行，以表征程序处于激活状态。该方式可以识别软件的执行阻塞、死锁、活锁，保证关键信号的周期获取或关键算法的周期运行。

(2) Deadline Supervision

用于监控两个检查点之间的运行时间是否符合预期，可以在软件两个状态点插入检查点，看门狗程序可以获取检查点到达的时间，从而得到程序片段执行时间。该方式可以识别软件执行时间的不正确分配，对于执行时间的考量，可以检测出系统不易察觉的随机或者不规律的跳动。

(3) Program Flow

用于监控多个检查点的执行顺序是否符合预期，可以在关键算法插入多个检查点，看门狗管理程序通过获取检查点到达的顺序，从而判断程序是否符合预期状态运行。该方式可以识别软件要素间的不正确同步。

2.3 通信保护

同样在混合ASIL系统中，对于高安全等级的软件实体需要实施相应的通信保护机制，与程序流监控类似，需要在程序运行过程中检测出可能的失效状态，并及时做出相应的后处理，以遏制因信号质量差导致问题的进一步蔓延，将系统始终控制在安全状态下。

(1)故障来源

通信故障来源于硬件和软件两个层面，硬件产生的随机故障通常来自电气过载、老化或受外部条件的影响。由硬件引起的通信故障主要包含以下三种失效方式[4]：

* 硬件通信网络失效；

* 通信网络存在电磁干扰；

* 发生在上下文切换或者多核通信间的芯片内核故障。

而软件产生的通信故障大部分是有迹可循的，但有部分隐藏的错误需要在特定的条件下才能触发，在软件测试无法完全覆盖的情况下，采取恰当的通信保护措施来识别错误的发生是非常有必要的。参照AUTOSAR标准开发的软件通信故障主要由以下四个方面引起[4]：

* RTE通信故障；

* COM模块引起的故障；

* 通信网络协议栈引起的故障；

* IOC或OS引起的故障。

(2)错误类型

关于信息交换，针对每个发送方或接收方，可考虑如下所列各故障的原因或故障的影响[1]：

* 信息重复；

* 信息丢失；

* 信息延迟;

* 信息插入；

* 信息伪装或信息的不正确寻址；

* 信息次序不正确

* 信息损坏；

* 从发送方传送到多个接收方信息不对称；

* 发送方发送的信息只能被部分接收方接受；

* 通信信道阻塞。

而AUTOSAR端到端(End-to-End，E2E)的保护机制正是针对以上通讯错误类型而设计的。

(3)E2E通信保护机制

E2E机制通过发送和接受计数器来识别信息重复、丢失、插入、次序不正确和阻塞；通过某几个迟滞用途的计数器来识别信息丢失、延迟和阻塞；通过数据标识符和CRC来识别伪装或信息的不正确寻址和插入；通过CRC来识别信息损坏和信息的不对称等。

以应用E2E Profile01保护非信任分区和信任分区软件组件间的RTE通信为例，发送端保护机制如图3所示，发送方可参照如下方式实现数据保护。

图3 发送方端到端保护

① 运行实体依据软件逻辑更新待发送的数据；

② 调用E2E_P01Protect接口保护数据，E2E库会根据用户配置更新待发送的数据；

③ 通过调用RTE接口将新的数据发送出去。

接收端保护机制如图4所示，接受方可参照如下方式实现数据检查。

图4 接受方端到端保护

① 运行实体通过调用RTE接口获取数据；

② 调用E2E_P01Check接口，检查接受到的数据，E2E库会根据用户配置检查数据的有效性，并返回检查状态；

③ 软件根据获取到的状态执行不同的逻辑策略，不同的失效状态会触发对应的失效后处理，有效的数据才允许参与到后续的软件策略里，从而保证系统的安全。

3 测试和验证

基于以上系统设计，将测试程序烧写到控制板上，配合PLS软件调试设备分别完成了MPU、PFS和E2E等测试。

3.1 MPU内存保护

测试示例如图5所示，非信任分区中QM等级的运行实体在Tlib_En_Cpu1Mpu为真时，有访问可信分区ASIL D软件模块变量Tlib_Ct_Cpu1Trust的风险。如果此类问题发生在车辆行进过程中，重要的扭矩或转速信号被非法篡改，将可能导致严重的行车安全。

图5 MPU测试示例

调试上位机UDE使能测试条件Tlib_En_Cpu1Mpu为真时，低安全等级的运行实体尝试对变量Tlib_Ct_Cpu1Trust写操作，触发MPU例外保护，回调Shutdown_Hook函数，在该函数中可执行相应后处理，以保证系统安全。

图6 MPU故障注入后数据

3.2 PFS时序保护

(1)Alive Supervision

图7为Alive Supervision的测试示例，软件配置不允许测试检查点在监督周期运行次数超过两次，否则将认为软件逻辑存在潜在风险。

图7 Alive Supervision测试示例

图8和图9分别是故障注入前后的数据，设置Tlib_Ct_Wdg0Alive为2，检查点将连续运行两次，WdgM识别到故障，会将喂狗条件Wdg_30_Sbc_TrgCnd_conditionFlag置为不满足，从而会中断对TLF35584的喂狗操作，触发复位机制。

图8 Alive Supervision故障注入前数据

图9 Alive Supervision故障输入后数据

(2)Deadline Supervision

图10为Deadline Supervision的测试示例，软件配置不允许测试检查点CP0到CP1的运行时间超过10 ms，否则系统会认为逻辑执行时间超过预期，触发看门狗保护。

图10 Deadline Supervision测试示例

图11和图12分别是故障注入前后数据，故障注入后，触发了看门狗保护。

图11 Deadline Supervision故障注入前数据

图12 Deadline Supervision故障注入后数据

(3)Program Flow

图13为Program Flow的测试示例，软件逻辑执行顺序配置如下，通过Tlib_En_Wdg1Switch切换检查点，Tlib_En_Wdg1Inhibit抑制CP2的运行。

图13 Program Flow测试示例

注入故障，将Tlib_En_Wdg1Inhibit置为1，WdgM识别到不符合预期的运行逻辑，将触发看门狗保护，见图14和图15故障注入前后数据。Program Flow保护可以有效地监督逻辑时序，属于功能安全高推荐使用的机制之一。

图14 Program Flow故障注入前数据

图15 Program Flow故障注入后数据

3.3 E2E通信保护

根据2.3章节设计的测试示例如下，将保护可信分区从非信任分区获取数据的可靠性。

图16 E2E测试示例

高安全等级的软件组件需要获取低等级的变量Tlib_Num_E2E，该数组变量长度为4字节，根据E2E配置，前两个字节为需要传递的应用数据，比如重要信号扭矩和转速，第三个字节为发送计数器，最后一个为CRC校验值。测试变量Tlib_En_E2E激活可以在RTE接口数据传输过程中篡改第二个字节数据。见图17，故障注入后E2E库成功识别到故障状态为E2E_P01STATUS_WRONGCRC，软件可以根据不同的返回状态制定不同的后处理策略，以保证系统安全。

图17 E2E故障注入后数据

4 结论

基于Vector MICROSAR软件架构，设计了符合车辆功能安全免于干扰需求的混合ASIL系统软件，并在英飞凌TriCore277控制板上验证了MPU、PFS和E2E等功能，表明了该应用研究对于车辆的安全保护具有重要的意义。同时在获得上海市科研计划项目(19XD1432000 SH32E1N三合一电桥总成研发项目)资助下，成功地将本文的研究成果应用到了功能安全量产产品中。