AUTOSAR图解==＞AUTOSAR_SRS_CoreTest
AUTOSAR CoreTest模块详解
目录
- 1. 概述
- 1.1 核心测试的定义与作用
- 1.2 核心的组成部分
- 1.3 测试模式类型
- 2. AUTOSAR CoreTest架构设计
- 2.1 整体架构图
- 2.2 CoreTest与AUTOSAR层次结构的关系
- 2.3 测试资源与资源管理
- 3. CoreTest测试模式与状态转换
- 3.1 测试模式状态图
- 3.2 前台与后台测试模式对比
- 3.3 测试状态转换与异常处理
- 4. CoreTest测试执行流程
- 4.1 测试序列流程图
- 4.2 前台测试执行机制
- 4.3 后台测试执行机制
- 4.4 结果处理与报告机制
- 5. CoreTest API设计与实现
- 5.1 API接口结构图
- 5.2 配置参数与状态管理
- 5.3 测试功能API详解
- 5.4 结果获取与错误处理
- 6. 多核支持与架构考量
- 6.1 多核环境下的CoreTest工作模式
- 6.2 资源分配与管理挑战
- 7. 总结与最佳实践
- 7.1 CoreTest模块应用场景
- 7.2 实施建议与注意事项
1. 概述
1.1 核心测试的定义与作用
AUTOSAR CoreTest模块是为满足汽车标准要求而设计的核心测试API规范，用于在运行时检测硬件核心组件的静态错误。CoreTest作为AUTOSAR标准的一部分，主要职责是定期或在启动时执行对CPU核心及其相关资源的测试，确保ECU核心功能的正常运行。
CoreTest在整体安全概念中发挥着重要作用，但需要注意的是，它本身并不提供完整的诊断覆盖率，而是作为更大安全概念的组成部分。该模块专注于检测静态硬件错误，而非瞬态故障或间歇性故障。
1.2 核心的组成部分
在AUTOSAR标准中，"核心(Core)"被定义为中央处理单元(CPU)以及所有专用内存、总线接口和专用支持功能的总称。具体包括：
- 中央处理单元(CPU)：执行指令的核心部件
- 内存保护单元(MPU)：控制内存访问权限
- 指令缓存与数据缓存：提升数据访问速度
- 中断控制器：管理中断请求和处理
- 调试接口：提供调试支持
- 系统总线接口：连接系统其他部分
- 紧密耦合内存接口：连接专用高速内存
核心测试会覆盖这些组件，主要通过执行特定指令序列并验证其行为来确保硬件功能正常。
1.3 测试模式类型
CoreTest支持两种主要的测试模式：
- 前台测试模式：由用户直接调用，一次性执行完整测试，不可中断。适用于在执行关键任务前进行核心功能验证。
- 后台测试模式：由调度器周期性调用，将完整测试分解为多个可中断的原子测试序列，每个序列完成后可让出处理器资源。适合在实时操作系统环境下运行。
这两种模式不能同时运行，如果在后台测试运行时请求前台测试，后台测试应在当前原子序列结束后被取消。
测试执行通常包括两个步骤：
- 运行专用指令序列以刺激门和触发器，并计算校验和/签名
- 将计算的校验和与参考值(“黄金参考值”)比较，判断测试是否通过
2. AUTOSAR CoreTest架构设计
2.1 整体架构图
以下架构图展示了AUTOSAR CoreTest模块在整体系统中的位置及其与其他组件的关系：
从架构图中可以看出，CoreTest驱动位于MCAL(微控制器抽象层)中，属于AUTOSAR基础软件的一部分。它向上提供API接口给应用层和系统服务模块，向下与核心硬件资源直接交互执行测试操作。
2.2 CoreTest与AUTOSAR层次结构的关系
CoreTest作为MCAL层的驱动模块，具有以下特点：
- 位置：位于AUTOSAR基础软件的MCAL层
- 上层接口：向应用软件组件和ECU状态管理器提供服务
- 下层交互：直接与核心硬件资源进行交互
- 结果报告：通过诊断事件管理器(DEM)报告测试结果
作为本地MCAL驱动，CoreTest没有系统架构的水平视图，也不了解其他微控制器或上层服务。它专注于执行本地核心测试功能，由上层实体决定何时调用测试及如何处理测试结果。
2.3 测试资源与资源管理
CoreTest驱动需要访问各种核心资源进行测试，包括：
- CPU执行单元
- 内存保护单元(MPU)
- 指令和数据缓存
- 中断控制器
- 总线接口和内存接口
在测试过程中，这些资源可能需要临时从应用程序使用中释放，以避免测试和应用程序之间的干扰。然而，AUTOSAR架构中目前没有管理实体可以主动处理这一资源管理需求，这给CoreTest的实现带来挑战。
因此，CoreTest实现可能限于以下场景：
- 在上电/启动时执行，此时核心资源未被应用任务共享
- 仅测试运行时不共享的资源(如CPU本身)
3. CoreTest测试模式与状态转换
3.1 测试模式状态图
下图展示了CoreTest测试模式的状态转换关系：
该状态图清晰展示了CoreTest的不同工作状态及其转换关系：
- 空闲状态：系统初始化后的默认状态，等待测试请求
- 后台测试模式：
- 初始化后台测试
- 执行原子测试序列
- 处理中断请求（挂起/恢复）
- 完成测试并返回结果
- 前台测试模式：
- 初始化前台测试
- 执行完整测试（不可中断）
- 完成测试并返回结果
- 错误处理：
- 记录错误信息
- 向DEM报告诊断事件
3.2 前台与后台测试模式对比
前台和后台测试模式各有特点和适用场景：
前台测试模式：
- 由用户直接调用启动
- 一次性完成整个测试过程，不可中断
- 适合在执行关键任务前验证核心功能
- 可用于测试整个核心或选定功能块
- 执行时间可预测但较长
后台测试模式：
- 由调度器周期性调用
- 将完整测试分解为多个原子序列
- 每个原子序列完成后可被中断
- 适合在实时操作系统环境下运行
- 总执行时间较长但对实时性影响小
3.3 测试状态转换与异常处理
CoreTest模块在状态转换过程中需要处理多种情况：
- 模式切换：不允许同时运行前台和后台测试。如果后台测试运行时请求前台测试，应取消后台测试。
- 中断处理：后台测试模式下，每个原子序列完成后可以被中断，完成中断处理后可以恢复测试。
- 错误处理：任何测试失败都会触发错误处理流程，包括记录错误信息和向DEM报告诊断事件。
- 结果处理：测试完成后，需要根据测试结果设置相应状态，并可能通过DEM报告事件。
4. CoreTest测试执行流程
4.1 测试序列流程图
以下序列图详细展示了CoreTest测试执行的交互流程：
序列图展示了CoreTest在前台和后台两种测试模式下的执行流程，以及各个组件之间的交互关系。
4.2 前台测试执行机制
前台测试执行流程：
- 应用通过调用
CoreTest_TestCpu()等API启动前台测试 - CoreTest API接收请求并初始化前台测试环境
- CoreTest执行完整的指令序列测试核心资源
- 测试完成后计算校验和/签名
- 将计算结果与参考值比较，确定测试是否通过
- 根据测试结果向DEM报告相应的诊断事件
- 返回测试结果给调用者
前台测试一旦启动，将一次性完成整个测试过程，不会中途返回控制权。这种特性使其适合在执行关键任务前验证核心功能，但可能导致较长的响应延迟。
4.3 后台测试执行机制
后台测试执行流程：
- 应用通过调用
CoreTest_TestCpuBist()启动后台测试 - CoreTest API初始化后台测试环境并设置状态为RUNNING
- 周期性调度器调用
CoreTest_MainFunction()执行下一个原子测试序列 - 每执行完一个原子序列，都会：
- 计算该序列的校验和/签名
- 保存中间结果
- 返回控制权给调度器
- 当所有原子序列完成后：
- 设置状态为FINISHED
- 向DEM报告测试结果
- 通知调用者测试完成
后台测试将完整测试分解为多个原子序列，每个序列执行完成后都会返回控制权，使得其他任务能够在测试期间执行，适合在实时操作系统环境下运行。
4.4 结果处理与报告机制
CoreTest提供两种结果处理机制：
-
通过/失败状态报告：
- 测试完成后返回通过/失败状态
- 通过DEM API报告诊断事件（
Dem_SetEventStatus()） - 上层应用根据返回状态决定后续操作
-
校验和/签名提供：
- 测试完成后计算并存储校验和/签名
- 通过
CoreTest_GetTestSignature()提供签名给调用者 - 由调用者决定如何使用和验证签名
这种灵活的结果报告机制允许更高度的测试和监督概念实现。例如，调用者可以是运行在不同CPU上的软件组件或外部设备，它们可以根据自己的需求使用这些测试结果。
5. CoreTest API设计与实现
5.1 API接口结构图
下图展示了CoreTest模块的API结构和类关系：
类图展示了CoreTest模块的主要组成部分：
- 枚举类型：定义测试状态、结果和错误类型
- 配置类型：提供测试配置参数
- 核心API接口：提供状态管理、测试功能和结果获取
- 与DEM的接口：用于报告诊断事件
5.2 配置参数与状态管理
CoreTest模块提供以下配置和状态管理功能：
配置参数：
CoreTestNumberOfCores：指定核心数量CoreTestRefValue：提供用于比较的参考值CoreTestTimeout：设置测试超时时间CoreTestReportDem：启用/禁用DEM事件报告
状态管理API：
CoreTest_Init()：使用指定配置初始化CoreTest模块CoreTest_DeInit()：去初始化CoreTest模块CoreTest_GetState()：获取当前测试状态
状态类型：
CORETEST_UNINIT：未初始化状态CORETEST_IDLE：空闲状态，可以启动新测试CORETEST_RUNNING：测试正在运行CORETEST_SUSPENDED：测试被挂起CORETEST_FINISHED：测试已完成
5.3 测试功能API详解
CoreTest提供两类主要测试功能API：
前台测试API：
CoreTest_TestCpu()：测试CPU功能CoreTest_TestMpu()：测试内存保护单元CoreTest_TestCache()：测试缓存功能CoreTest_TestBusInterface()：测试总线接口
这些API在调用后会同步执行完整测试，并返回测试结果。
后台测试API：
CoreTest_TestCpuBist()：启动CPU后台测试CoreTest_MainFunction()：执行下一个原子测试序列CoreTest_CancelTest()：取消正在运行的后台测试
后台测试API允许将测试分解为多个可中断的部分，适合在实时系统中使用。
5.4 结果获取与错误处理
CoreTest提供以下结果获取和错误处理机制：
结果获取API：
CoreTest_GetTestSignature()：获取测试签名/校验和CoreTest_GetErrorDetails()：获取详细错误信息
结果类型：
CORETEST_OK：测试通过CORETEST_NOT_OK：测试失败CORETEST_PENDING：测试正在进行
错误类型：
CORETEST_E_OK：无错误CORETEST_E_NOT_OK：一般错误CORETEST_E_PARAM_POINTER：参数指针错误CORETEST_E_STATE：状态错误CORETEST_E_INIT_FAILED：初始化失败
6. 多核支持与架构考量
6.1 多核环境下的CoreTest工作模式
在多核环境中，CoreTest模块遵循以下工作模式：
- 在硅片设备内的每个相同核心实例上都可以执行核心测试
- CoreTest本身不需要了解系统架构，因为它是位于较低AUTOSAR层的驱动程序
- CoreTest不必了解系统中共存的核心数量，只专注于单个核心实体
- 对于多核系统，用户应用程序需要为每个核心调度相同的测试
需要明确区分"多微控制器"和"多核心"概念：
- 多微控制器系统设计超出了核心测试和其驱动API的范围
- CoreTest设计用于测试单个核心实体，不关注系统中的其他核心
6.2 资源分配与管理挑战
CoreTest面临的主要架构挑战是资源管理：
- AUTOSAR上层没有可用的资源管理实体(例如ISO 7层模型中的会话管理)
- 需要临时释放本地核心资源(如中断控制器)以避免测试和应用程序之间的干扰
- AUTOSAR架构中没有实体可以在启动核心测试前主动处理这一要求
- MCAL驱动由于位于较低AUTOSAR层，无法处理资源管理
由于这些限制，CoreTest实现可能被限制为：
- 在上电/启动时执行，此时核心资源未被应用任务共享
- 仅测试运行时不共享的资源(如CPU本身)
此外，AUTOSAR目前不支持运行时测试，因此在上层架构中没有测试管理实体。这导致CoreTest无法直接访问在其他核心上执行的测试结果，需要在上层架构中添加测试管理实体以处理测试结果处理和相关反应。
7. 总结与最佳实践
7.1 CoreTest模块应用场景
CoreTest模块适用于以下场景：
- 启动时测试：在系统启动阶段验证核心硬件功能
- 关键任务前验证：在执行关键任务前验证核心功能完整性
- 周期性健康检查：通过后台测试模式在运行时周期性验证核心功能
- 诊断需求支持：满足汽车安全标准对运行时诊断的要求
- 多核环境验证：独立验证多核系统中每个核心的功能
7.2 实施建议与注意事项
在实施CoreTest时，建议遵循以下最佳实践：
- 资源管理：明确定义CoreTest测试时的资源使用策略，避免与应用程序冲突
- 测试时机选择：
- 前台测试应在关键任务执行前调用
- 后台测试应在系统负载较低时执行
- 多核配置：为多核系统中的每个核心配置单独的CoreTest实例
- 结果处理策略：根据系统安全需求，定义清晰的测试结果处理策略
- 集成考虑：
- 确保CoreTest与DEM正确集成
- 配置适当的诊断事件和故障码
- 性能影响：评估CoreTest对系统性能的影响，尤其是后台测试模式
- 限制认知：了解CoreTest的局限性，如不能检测瞬态或间歇性故障
CoreTest作为AUTOSAR安全概念的组成部分，提供了对核心硬件功能的基本测试能力，但它不能解决所有硬件相关的安全问题。因此，应将其作为更大安全概念的一部分，与其他安全机制结合使用，以提供全面的系统安全保障。