3. 功能安全与信息安全标准映射
在 Stellar 多核 MCU 上做安全监控与故障恢复，绕不开三份标准：ISO 26262（道路车辆功能安全）、IEC 61508（电气/电子/可编程电子安全相关系统功能安全）、ISO/SAE 21434（道路车辆网络安全工程）。它们不是三套互不相干的规则，而是从不同角度约束同一套硬件与软件机制。理解它们的关键，不是背条款编号，而是看清每条要求最终落到 Stellar 的哪个硬件单元、哪段软件逻辑、哪个可观测信号上。
三份标准的定位差异
IEC 61508 是功能安全的“母标准”，定义了安全生命周期、SIL 等级、安全完整性、随机硬件失效与系统性失效的基本框架。ISO 26262 是它在汽车行业的派生标准，把 SIL 映射为 ASIL（A/B/C/D），并针对汽车电子增加了硬件架构度量（SPFM、LFM、PMHF）和软件架构要求。ISO 21434 则完全不同：它不关心“失效导致功能失控”，而关心“恶意攻击导致功能被篡改或劫持”，其核心是 TARA（威胁分析与风险评估）、资产识别、攻击路径与安全目标。
对 Stellar 而言，这三者的交汇点非常具体：多核锁步、ECC、时钟监控、电压监控、看门狗、内存保护单元（MPU）、安全启动、密钥存储、调试口保护。功能安全标准要求这些机制“在随机失效时能检测并进入安全状态”，信息安全标准要求这些机制“不能被绕过、篡改或降级”。
多核监控在标准中的映射关系
Stellar 的多核架构通常包含锁步核对（Lockstep Core Pair）与独立监控核。ISO 26262 对锁步的要求集中在“共因失效”与“诊断覆盖率”：锁步比较器必须能检测单点故障，且比较逻辑本身要有独立时钟或独立供电域，否则共因失效会同时打掉主核与校验核。IEC 61508 则更强调诊断测试间隔（Diagnostic Test Interval）与证明测试（Proof Test），要求锁步比较器在安全生命周期内定期验证其检测能力。ISO 21434 关注的是锁步配置寄存器是否可被非安全核写入、比较器输出是否可被屏蔽、调试接口是否能强制关闭锁步。
落地时，这三条要求会收敛到同一组寄存器与信号：锁步使能位、比较器状态位、故障注入测试位、调试认证位。功能安全要求这些位在运行期不可被应用核随意改写，信息安全要求这些位只能由安全核在认证后写入。因此，Stellar 的典型做法是把这些控制位放在安全核独占的外设域，应用核只能读取状态，不能修改配置。
故障恢复路径的标准约束
故障恢复不是“重启就好”。ISO 26262 要求故障恢复必须进入并保持在安全状态，且恢复过程本身不能引入新的危害。IEC 61508 要求恢复路径的失效概率纳入整体安全完整性计算。ISO 21434 要求恢复逻辑不能被攻击者利用为“强制降级”或“拒绝服务”的入口。
在 Stellar 上，一条可落地的恢复链通常包含：故障检测（锁步比较器、ECC 双位错、时钟丢失、电压越限）→ 故障分类（瞬态/永久、单核/多核、安全相关/非安全相关）→ 恢复动作（核复位、域复位、系统复位、进入安全状态）→ 恢复后自检（锁步重新同步、ECC 重扫、看门狗重初始化）。每一步都要有对应的标准证据：功能安全要诊断覆盖率与 FTTI（故障容忍时间间隔），信息安全要防篡改与防重放。
从标准条款到寄存器配置的落地方式
以锁步比较器为例，ISO 26262 要求 ASIL D 下 SPFM ≥ 99%、LFM ≥ 90%。在 Stellar 上，这通常通过以下配置达成：使能锁步比较器、配置比较器故障响应为“触发安全核中断 + 记录故障寄存器”、使能周期性故障注入测试、将比较器状态位映射到安全核可读的故障状态寄存器。IEC 61508 则要求证明测试间隔不超过安全生命周期的一定比例，因此需要在软件中安排定期自检任务，例如每 10 ms 执行一次锁步比较器自检，每 100 ms 执行一次 ECC 全内存扫描。
ISO 21434 的落地更偏向“不可绕过”。例如，锁步使能位必须位于安全核独占的寄存器空间，应用核只能通过安全核提供的只读接口查询状态；调试口必须在安全启动完成后由安全核根据认证结果决定是否解锁；密钥存储区必须禁止应用核直接读取，只能通过安全核的加密引擎间接使用。这些措施在功能安全标准中可能只是“防止系统性失效”的一部分，但在信息安全标准中是明确的攻击面收敛要求。
一个可参考的映射检查表
下表给出 Stellar 多核监控与故障恢复中，三标准对同一机制的不同要求与验证方式。表中参数为教学示例，实际项目需根据 ASIL 等级与 TARA 结果调整。
| 机制 | ISO 26262 要求 | IEC 61508 要求 | ISO 21434 要求 | 验证方式 |
|---|---|---|---|---|
| 锁步比较器 | SPFM ≥ 99%，共因失效分析 | 诊断测试间隔 ≤ 10 ms | 使能位不可被应用核改写 | 故障注入 + 寄存器写保护测试 |
| ECC 内存 | 双位错检测，SECDED | 证明测试覆盖全内存 | 错误注入不可屏蔽告警 | 全内存扫描 + 告警日志检查 |
| 看门狗 | 独立时钟源，窗口模式 | 证明测试验证超时响应 | 喂狗序列不可预测 | 超时注入 + 序列重放测试 |
| 安全启动 | 启动自检覆盖关键外设 | 启动路径纳入安全生命周期 | 逐级验签，防回滚 | 篡改镜像 + 版本回退测试 |
| 调试口 | 生产件默认关闭 | 调试访问需授权 | 认证后限时解锁 | 未认证访问 + 超时锁定测试 |
常见误区与工程判断
第一个误区是把 ISO 21434 当成“额外加一层加密”。实际上，信息安全要求往往改变功能安全机制的设计方式：例如，功能安全只要求看门狗能复位，信息安全要求喂狗序列不可被预测，否则攻击者可以维持系统“假活”。第二个误区是认为 IEC 61508 只适用于非汽车领域。在 Stellar 项目中，如果产品同时面向工业与汽车，IEC 61508 的证明测试与安全生命周期文档往往成为功能安全证据的补充。
工程判断上，建议先做 TARA，识别出关键资产（锁步配置、密钥、恢复逻辑），再对照 ISO 26262 的 ASIL 等级确定诊断覆盖率与 FTTI 目标，最后用 IEC 61508 的证明测试思路设计周期性自检。三者的输出最终汇聚到同一份安全案例（Safety Case）与网络安全案例（Cybersecurity Case）中，而不是各自独立成文。