4. 多核安全监控总体设计

在 Stellar 多核 MCU 中,安全监控不是单一模块的功能,而是一套跨越内核、总线、外设与系统时钟的协同机制。总体设计的核心任务,是把“监控什么、监控到什么程度、故障如何归类、系统进入什么状态、用什么策略恢复”这五个问题在架构层面一次性定义清楚。如果这五件事没有在项目早期确定,后续的软件分区、看门狗配置和故障注入测试都会失去统一依据。

监控层次:从内核到系统的四级纵深

Stellar 的安全监控通常划分为四个层次。第一层是内核级监控,包括锁步核比较、ECC 对寄存器与缓存的保护、以及内核自检逻辑;这一层响应最快,通常在几个时钟周期内即可发现瞬时故障。第二层是总线与存储级监控,通过 ECC、总线超时、访问权限检查来发现 SRAM、Flash 和互连上的数据损坏或非法访问。第三层是外设与 I/O 级监控,例如 ADC 冗余采样比对、CAN 报文超时、PWM 输出回读。第四层是系统级监控,由独立看门狗、时钟监控单元和外部安全监控芯片构成,负责判断整个系统是否仍在预期的时间窗口内运行。

这四层不是并列关系,而是纵深防御:越靠近内核,响应越快但覆盖范围越窄;越靠近系统,响应越慢但能捕获跨模块的协同失效。设计时要保证任一层被绕过时,仍有更高层能兜底。

监控粒度:时间、空间与数据三个维度

监控粒度决定了“监控到什么程度”。时间粒度上,内核锁步比较是逐周期,看门狗是毫秒到秒级,任务级监控则按调度周期。空间粒度上,可以按核、按存储区、按外设实例或按信号通道划分。数据粒度上,可以选择只监控关键控制字、监控整个数据块,或对安全相关变量做冗余副本比对。

粒度过细会带来 CPU 与总线开销,粒度过粗会漏掉关键故障。工程上常用的折中方式是:对安全目标(Safety Goal)直接相关的变量采用细粒度冗余比对,对一般状态量采用周期性校验,对非安全数据不做额外监控。例如,电机控制中的电流采样值属于安全相关,应做双通道比对;而人机界面的显示刷新计数则无需冗余。

故障分类:按持续时间与影响范围划分

故障分类是恢复策略选择的前提。按持续时间可分为瞬时故障(如宇宙射线引起的位翻转)和永久故障(如硬件损坏)。按影响范围可分为局部故障(单个外设或单个存储块)和全局故障(时钟失效、电源跌落、总线锁死)。按可恢复性又可分为可恢复故障与不可恢复故障。

在 Stellar 中,瞬时故障通常由 ECC 纠正或锁步核重同步处理;永久故障则需要隔离故障核或切换到冗余通道;全局故障往往触发系统级安全状态。分类的目的不是贴标签,而是让每一类故障都能映射到明确的检测机制和响应动作。

安全状态定义:从正常运行到安全停机的状态机

安全状态不是单一状态,而是一组按严重程度递进的状态。典型定义包括:Normal(正常运行)、Degraded(降级运行,部分功能受限但核心安全功能可用)、Safe Stop(安全停机,输出进入安全值)、Safe State(安全状态,系统进入最低风险配置)、Fault Latch(故障锁存,等待诊断与复位)。

状态迁移必须由明确的故障条件触发,并且迁移过程本身要可监控。例如,从 Normal 进入 Degraded 可能由单次 ECC 可纠正错误触发;从 Degraded 进入 Safe Stop 可能由同一存储区连续多次可纠正错误触发;从 Safe Stop 进入 Fault Latch 则通常由不可恢复故障或安全状态确认失败触发。

Stellar 多核安全监控状态迁移与恢复策略 Normal 全功能运行 Degraded 降级运行 Safe Stop 输出安全值 Fault Latch 故障锁存 可纠正错误 连续错误 不可恢复 自检通过 / 错误清除 安全状态确认 / 复位恢复 四级监控层次与故障分类映射 内核级监控 锁步比较 / ECC / 自检 总线与存储级 ECC / 超时 / 权限检查 外设与 I/O 级 冗余采样 / 回读 / 超时 系统级监控 看门狗 / 时钟监控 / 外部监控 瞬时故障 · 局部 瞬时/永久 · 局部 永久 · 局部 永久 · 全局 响应:周期级 响应:微秒级 响应:毫秒级 响应:十毫秒级

恢复策略选择:按故障类型匹配动作

恢复策略必须与故障分类一一对应,不能“一刀切”。对于瞬时故障,优先采用重试与纠正:ECC 自动纠正单比特错误,锁步核重新同步,外设通道重新采样。对于局部永久故障,采用隔离与降级:关闭故障外设,切换到冗余通道,系统进入 Degraded 状态并限制非安全功能。对于全局故障,采用安全停机与锁存:停止安全相关输出,进入 Safe Stop 或 Fault Latch,等待诊断和复位。

策略选择还要考虑恢复时间与安全完整性等级的匹配。ASIL D 级别的安全目标通常要求故障响应时间在几十毫秒以内,因此不能依赖软件轮询,而应使用硬件监控单元直接触发安全状态。ASIL B 级别可以允许软件参与判断,但必须有独立看门狗兜底。

设计检查要点:每一类故障是否都有明确的检测机制?每一个检测机制是否映射到唯一的安全状态?每一个安全状态是否有对应的恢复路径和退出条件?如果这三个问题中任何一个存在“不确定”,说明总体设计尚未闭环。

从设计到落地:一个配置示例

以 Stellar 中一个电机控制节点为例,安全目标要求“不得输出非预期转矩”。设计时可以做如下映射:内核级锁步比较检测 CPU 故障,触发 Safe Stop;SRAM ECC 可纠正错误触发 Degraded,连续两次触发 Safe Stop;CAN 通信超时触发 Degraded,超过 100 ms 未恢复则进入 Safe Stop;看门狗超时直接进入 Fault Latch。每个状态对应的 PWM 输出行为、故障标志和恢复条件都应在安全手册中明确记录。

安全状态映射示例(电机控制节点):
Normal      → PWM 正常输出,安全标志 = 0
Degraded    → PWM 限幅输出,安全标志 = 1,记录故障码
Safe Stop   → PWM 输出安全值(如 50% 占空比对应零转矩),安全标志 = 2
Fault Latch → PWM 关闭,安全标志 = 3,等待复位

故障触发条件示例:
- 锁步核比较失配          → Safe Stop
- SRAM 单比特 ECC 可纠正  → Degraded
- 同一地址连续两次可纠正  → Safe Stop
- CAN 接收超时 > 100 ms   → Safe Stop
- 看门狗超时              → Fault Latch

这套映射不是唯一的,但必须是显式的、可测试的。在故障注入测试中,应逐条验证每个触发条件是否真的把系统带入预期状态,并确认恢复路径不会引入新的风险。只有监控层次、粒度、分类、状态和策略五者形成闭环,多核安全监控的总体设计才算真正完成。