4. RH850 启动与自检软件架构
在 RH850 功能安全软件架构中，启动阶段是安全机制最密集、时序约束最严格的窗口。上电后，MCU 从复位向量开始执行，此时 RAM 尚未初始化、时钟尚未稳定、外设尚未配置，而安全目标要求系统必须在进入应用主循环之前完成对关键硬件与软件完整性的可信验证。因此，启动与自检架构的核心任务不是“跑一段初始化代码”，而是建立一条从复位到应用可运行状态的可信链，并在链路的每个节点上安排恰当的自检动作。
启动时序与阶段划分
RH850 的启动过程通常可划分为四个阶段：复位释放与启动固件执行、硬件自检、软件自检与安全启动链验证、应用初始化与移交。复位释放后，CPU 首先从固定复位向量取指，执行芯片内固化的启动固件（Boot Firmware）。该固件负责最基础的时钟切换、看门狗配置和启动模式判断。此阶段不宜执行复杂自检，因为 RAM 尚未完成初始化，堆栈不可用，任何依赖 C 运行时的检测都无法安全执行。
进入硬件自检阶段后，软件开始对 CPU 内核、RAM、Flash、时钟、电源监控、看门狗等安全相关硬件执行检测。RH850 通常提供 CPU 自检库（如 Cortex 类内核的 STL，或 RH850 自有的自检例程），用于检测 ALU、寄存器组、PC、SP 等关键资源。RAM 检测采用 March C- 或 March SS 等算法，按块扫描并记录故障地址。Flash 检测则通过 CRC 或签名校验验证代码区完整性。此阶段的关键约束是：检测必须在有限时间内完成，且不能破坏后续启动所需的资源。
软件自检与安全启动链验证阶段，系统开始验证应用代码与配置数据的真实性。典型做法是对 Flash 中的应用程序段计算 CRC32 或验证 ECDSA 签名，并与预置的参考值比对。若验证失败，系统应进入安全状态，例如停留在 Bootloader 中、点亮故障指示灯或通过 CAN 发送诊断故障码。验证通过后，启动链将控制权移交给应用入口。
最后是应用初始化与移交阶段。此时安全机制已建立，系统配置 MPU、初始化外设、启动任务调度器，并进入周期性自检模式。启动阶段的自检结果应被记录到非易失存储或诊断事件缓冲区，供后续诊断读取。
硬件自检与软件自检的分工
硬件自检与软件自检并非互相替代，而是覆盖不同故障类型与时间窗口。硬件自检由芯片内置的安全机制自动执行，例如 RH850 的锁步 CPU 比较、Flash ECC、RAM ECC、时钟监控、电源电压监控等。这些机制在启动阶段即开始工作，无需软件显式调用，响应速度快，适合检测永久性故障和部分瞬态故障。但其覆盖范围受硬件设计限制，无法检测所有外设寄存器和通信路径。
软件自检则由启动代码或自检库主动调用，典型包括 RAM March 测试、Flash CRC 校验、CPU 寄存器测试、外设寄存器回读、ADC 参考电压检测等。软件自检的优点是灵活可配、覆盖范围可扩展，缺点是消耗启动时间和 CPU 资源。在功能安全架构中，通常将软件自检安排在硬件自检之后、安全启动链验证之前，确保基础硬件可信后再进行更深入的检测。
安全启动链的实现要点
安全启动链的核心是“逐级验证、逐级移交”。以 RH850 为例，启动固件首先验证 Bootloader 的签名，Bootloader 验证通过后再验证应用程序的签名。每一级验证都使用非对称密码算法（如 ECDSA P-256）或对称 CRC 校验。密钥必须存储在受保护的区域，例如芯片内的安全存储区或外部安全元件中，不能以明文形式出现在普通 Flash 中。
验证失败时的处理策略需要根据安全目标确定。对于高安全等级（如 ASIL D），验证失败应导致系统进入安全状态，例如停止应用执行、点亮故障灯、通过 CAN 发送 DTC。对于较低安全等级，可以允许降级运行，但必须记录故障并限制功能。无论哪种策略，验证结果都必须可追溯，写入非易失存储或诊断事件缓冲区。
启动自检的集成与验证
在实际工程中，启动自检的集成需要关注三个问题：时间预算、资源冲突和结果记录。时间预算方面，启动自检必须在整车或系统要求的启动时间内完成。例如，若系统要求 100 ms 内进入应用，则硬件自检、软件自检和安全启动链验证的总时间必须控制在 80 ms 以内，留出余量。资源冲突方面，自检使用的 RAM 区域不能与后续应用冲突，自检完成后应释放或标记为可用。结果记录方面，自检结果应写入诊断事件缓冲区，供后续读取和分析。
验证启动自检架构是否有效，通常采用故障注入测试。例如，在 RAM 中人为写入错误数据，观察 March 测试是否能检测到；在 Flash 中修改一个字节，观察 CRC 校验是否失败；在启动链中替换签名，观察系统是否进入安全状态。这些测试应在台架上完成，并记录检测时间、检测覆盖率和误报率。只有通过故障注入验证的自检架构，才能被认为满足功能安全要求。