2. ST Stellar 硬件架构与安全机制

ST Stellar 面向汽车功能安全域控制器与区域控制器，其硬件安全架构的核心思路是：在性能核之外，用独立的硬件监控与冗余通道，把“可能出错的执行”变成“可被检测、可被响应、可被证明安全”的执行。理解这些机制，不能只停留在名词层面，而要看清它们各自监控什么、失效时如何反应、以及在软件上需要做哪些配置与验证。

一、多核锁步：把“算得对”变成“算得一致”

Stellar 系列中的安全核通常采用锁步（Lockstep）结构：一个主核（Master Core）和一个校验核（Checker Core）接收相同的输入、执行相同的指令流，并在每个时钟周期或流水线阶段比较关键输出。若两者结果不一致，比较逻辑会立即产生故障信号，交由安全控制单元处理。锁步并不保证计算结果绝对正确，它保证的是“两个独立物理通道在同一时刻得出相同结果”，从而把瞬态故障和部分永久故障暴露出来。

在配置层面，锁步通常涉及以下要点：

• 锁步使能与比较延迟：部分器件允许配置比较采样点或延迟周期，需与时钟频率和流水线深度匹配，避免误报。
• 故障注入测试：通过寄存器注入一位翻转，验证比较逻辑能否正确报错，这是安全机制“可被证明有效”的关键步骤。
• 错误响应路径：锁步错误通常触发 NMI 或安全状态机，软件需在启动阶段注册对应处理入口，并确保响应时间满足 FTTI（故障容忍时间间隔）。

二、ECC：让存储错误可纠正、可上报

Stellar 的 Flash、SRAM 以及部分总线接口普遍支持 ECC。以 SRAM 为例，常见配置为 SECDED（单错纠正、双错检测）：每 32 位数据附加 7 位校验位，可纠正 1 位错误，检测 2 位错误。Flash 侧通常采用更强的纠错能力，以应对长期数据保持与擦写退化。

ECC 的配置与使用需要注意三点。第一，初始化：上电后 SRAM 内容随机，必须先按 ECC 规则写入全区域，否则读取时会因校验位不匹配产生“伪错误”。第二，错误分类：可纠正错误（CE）通常只计数并上报，不可纠正错误（UE）必须触发安全响应。第三，错误注入：通过 ECC 错误注入寄存器人为制造 CE/UE，验证中断路径、错误计数器和安全状态切换是否按预期工作。

/* 示例：SRAM ECC 初始化与错误状态读取（伪代码，参数为示例值） */
for (addr = SRAM_BASE; addr < SRAM_END; addr += 4) {
    *(uint32_t *)addr = 0x00000000;   /* 按 ECC 规则写入，建立合法校验位 */
}
ecc_status = ECC_SRAM->STATUS;
if (ecc_status & ECC_CE_FLAG) {
    ecc_ce_count++;                   /* 可纠正错误计数，用于趋势监控 */
}
if (ecc_status & ECC_UE_FLAG) {
    Safety_EnterSafeState(ECC_UE);    /* 不可纠正错误，进入安全状态 */
}

三、时钟监控与电压监控：守住运行的“边界条件”

时钟监控通常由 CMU（Clock Monitoring Unit）实现，它用独立参考时钟对 PLL 输出、系统时钟和关键外设时钟进行频率窗口比较。若频率超出上下限，说明时钟丢失、漂移或 PLL 失锁，CMU 会触发故障。配置时需设定合理的频率窗口和去抖时间，既要覆盖真实故障，又要避免因时钟抖动造成误报。

电压监控由 PMU/VD 模块完成，对核心电压、IO 电压和 ADC 参考电压进行欠压、过压检测。电压异常会直接影响锁步比较和 ECC 判定的可靠性，因此电压监控往往与复位控制、安全状态机联动。典型配置包括：欠压阈值、过压阈值、滤波时间以及触发后的响应动作（中断、复位或安全输出关断）。

四、看门狗：从“程序跑飞”到“可恢复的安全状态”

Stellar 通常提供内部看门狗（WDG）和外部看门狗（EWDG）两条路径。内部看门狗由软件周期性喂狗，若超时未喂则触发复位或中断；外部看门狗则通过独立引脚与外部监控芯片交互，形成更独立的监控通道。安全设计中，喂狗动作本身也应受到保护：例如只有在关键任务全部完成、且通过合理性检查后才允许喂狗，避免“程序跑飞但仍在喂狗”的失效模式。

五、机制之间的协同与配置顺序

这些安全机制不是孤立工作的。锁步比较依赖稳定的时钟和电压；ECC 的判定依赖正确的参考电压；看门狗的喂狗条件又依赖关键任务和 ECC 状态。因此，合理的配置顺序通常是：先建立时钟与电压监控，确保运行边界可控；再初始化存储 ECC，建立合法校验环境；然后使能锁步并完成故障注入验证；最后配置看门狗与安全状态机，把各类故障统一收敛到安全响应路径。

六、一个可参考的验证检查表

实际项目中，建议把上述验证结果与安全案例中的诊断覆盖率声明一一对应，形成可追溯的证据链。只有这样，硬件安全机制才不只是“配置过”，而是“被证明有效”。