AUTOSAR中的硬件诊断技术

在《Overview of Functional Safety Measures in AUTOSAR》文档中，提到了AUTOSAR架构中的两种硬件诊断技术，Core Test和RAM Test。本文介绍这两种诊断技术以及它们与ISO26262的联系。

Core Test 内核测试

Core Test用于测试处理器内核组成的各个单元失效，如通用寄存器、ALU、MMU/MPU等。处理器内核测试部分属于AUTOSAR的Basic software module，可以直接访问微控制器内核，没有中间间软件层。

内核测试对芯片内部的不同单元分别测试，测试要求与被测单元对应关系如下：

ID	处理单元组成	内核测试要求
001	ALU数据路径	内核ALU测试
002	Registers (通用寄存器库，DMA tran-sfer registers…), 内部RAM	内核寄存器测试
003	地址计算（加载/存储单元、DMA寻址逻辑、存储器和总线接口）。	内核地址生成器  内核内存接口  内存管理/保护单元（MMU/MPU） 高速缓存控制器
004	中断处理	内核中断和异常检测
005	控制逻辑(序列器、编码和执行逻辑，包括标志寄存器和堆栈控制)	-
006	配置寄存器	-
007	其它类别的元素	-

Core Test的局限性：

• Core Test是对处理器内核的硬件资源进行测试，与硬件处理器底层相关密切，无法与AUTOSAR其它软件任务和硬件实体共享CPU，或者仅限于共享不共用的测试资源（ALU和CPU寄存器）。由于这种限制，可能Core Test会被限制仅在上电/启动时运行。
• AUTOSAR对处理器内核各单元无法做到全面的覆盖测试，Core Test对硬件资源进行分时分片进行测试，无法检测soft error，例如当其它软件任务调用ALU或读写寄存器发生了瞬态故障，Core Test检测不到，需要补充其它检测方法。
• Core Test不能可靠地报告检测到的故障，存在处理器本身就发生了故障，因此不能将故障报给诊断事件管理器（DEM）
  
• 需要创建如硬件资源访问管理的任务对Core Test任务进行管理。

Core Test任务的周期调度

Core Test任务拆分的子任务需要高优先级，禁止其它中断

此外，Core Test软件模块还要依赖于上层软件架构来保证该软件模块的运行和输出结果的正确性，采用

• 校验和和签名保护
  
• 使用前检查Core Test Code完整性
  
• 校验和/签名的冗余存储
  
• 测试结果的外部决策执行

与Core Test有关的调用逻辑有：

1. 初始化：用于对Core Test软件模块进行初始化
   
   

2.取消初始化：取消Core Test模块的初始化

3.1 后台运行测试——Core Test模块在后台运行测试

3.2 后台运行测试——Core Test模块提供给调用实体的签名，可以用于调用方验证Core Test软件模块的完整性

RAM Test RAM测试

RAM Test功能用于测试易失性存储器RAM的永久性失效，RAM测试部分属于AUTOSAR的Basic software module，可以直接访问微控制器内核，没有中间间软件层。

存在不同的软件算法用于RAM测试，不同算法针对的故障模型集不同，实现不同等级的覆盖率，运行时间也不同。AUTOSAR没有指定特定的RAM测试算法，根据ISO26262-11对RAM的推荐诊断方法，有以下诊断技术可选：

RAM测试驱动程序支持被称为"前台测试"的同步测试和被称为"后台测试"的异步测试。在RAM测试算法的执行过程中，不允许其他软件修改被测试的RAM区域。

RAM Test的局限性：

• 无法检测瞬态错误，可以用来检测上电和周期运行时的永久性错误，瞬态错误和间歇性soft error无法检测
• RAM Test执行过程中，不允许其它软件和硬件修改被测试的RAM区域，RAM测试模块不能保证数据的一致性，运行过程中禁止其它任务访问被测试的RAM地址块
• 由于RAM Test会读写被测RAM区域，将导致被测RAM区域的数据内容被破坏，应考虑在测试前将被测RAM数据搬到其它RAM区域
• 当在多核系统中测试共享RAM时，可能无法通过中断锁定多个内存单元的独占访问，这种情况下，共享内存的测试配置使用仅限于前台测试和特定ECU状态

与RAM Test有关的调用逻辑有：

完整的调用过程：初始化、前台运行完整测试请求、错误报告和循环调用后台测试

后台调用过程，增加了挂起和恢复交互

总结

Core Test和RAM Test属于功能安全系统设计中底层的诊断技术，在ISO26262中有专门的技术条款要求，用于处理器内部各单元和RAM测试，参考AUTOSAR功能安全机制中对这两项硬件诊断技术的需求，使我们更易于理解Core Test和RAM Test的基本要求、测试过程和技术局限性，归纳下来有以下几点：

• 用于测试永久性错误，无法检测soft error；
• 具有硬件独占性，需要调度器协调与其它软件任务，避免破坏正常的CPU操作和数据区域；
• 周期执行位于后台运行，分段进行测试；
• 根据ASIL等级的不同诊断覆盖率要求，选择适合的诊断算法。

至于具体算法的实现，不在AUTOSAR规定的范围内，就要实现其软件模块的厂商各显神通了，在项目开发，有以下建议方法：

• 首先，需要选择一种合适的符合ASIL等级要求的诊断算法，把算法原理搞清楚了，实现层面不是太复杂，但是需要开发工程师懂得所选择硬件平台CPU的底层编程语言，能够对底层的寄存器进行操作；
• 其次，完整的RAM测试占用的时间比较长，如果系统对上电时间要求严格，不建议上电进行完整的RAM测试，可以结合标准中推荐其它诊断方法；
  
• 需要小心协调自检算法与其它软件任务的调度关系，正如AUTOSAR规范中所说，自检算法具有独占特性，处理不好把正常的数据区域破坏了，需要对算法进行全面的测试以保证其实现的正确性。