1. 课程导入与工程全景

在汽车电子电气架构快速向集中式、域控化演进的今天，整车对功能安全与故障可恢复性的要求已经从"单点容错"升级为"系统级持续可用"。ST Stellar系列微控制器正是面向这一需求设计的车规级多核平台，它把多个运算核心、硬件安全机制、通信外设与电源管理集成在同一颗芯片上，使"监控—判定—恢复"这条链路能够在芯片内部闭环完成。本课程要解决的，就是如何在这类多核平台上把安全监控与故障恢复真正做成可运行、可验证、可量产的工程能力。

一、课程目标与工程范围

本课程的目标可以概括为三句话：看得见故障、判得准状态、恢复得回来。具体而言，学完本课程后，你应当能够：

• 理解ST Stellar多核架构中安全相关核心（如锁步核、检查核）与主运算核的分工，明确哪些任务必须放在安全核上执行；
• 掌握基于硬件看门狗、ECC、时钟监控、电压监控等机制构建分层监控体系的方法；
• 能够设计故障注入测试用例，验证监控路径是否真正生效，而不是停留在"配置了就算完成"；
• 能够实现从故障检测、故障分类到降级运行或安全停机的完整恢复策略，并给出可观测的恢复证据。

课程范围覆盖芯片级安全机制、板级监控电路、软件层安全监控框架以及故障恢复状态机四个层次。不涉及具体整车网络协议栈的完整实现，也不展开ISO 26262认证流程的全部文档工作，但会在关键节点说明这些工程活动与标准要求之间的对应关系。

二、关键术语约定

为避免后续章节出现理解偏差，先统一几个核心术语在本课程中的含义：

这里需要特别强调"故障—错误—失效"三者的递进关系：故障是原因，错误是表现，失效是后果。安全监控的价值就在于在错误阶段就把它截住，不让它演化为失效。

三、整体架构与信号链

ST Stellar多核安全监控与故障恢复的整体架构，可以理解为一条从"物理异常"到"恢复动作"的信号链。下图展示了这条链路上的关键对象、监控信号流向以及恢复决策的分支关系。

从图中可以看到，应用核与安全核并不是简单的"主从"关系，而是通过硬件监控单元形成交叉校验：应用核输出运行状态，安全核输出监控配置，硬件监控单元负责采集和比对，再把故障事件交给故障分类模块。分类结果决定恢复决策走向"降级运行"还是"安全停机"，而恢复动作的结果又会反馈给安全核，形成闭环。

四、学习路线与工程方法

本课程按"先建立监控能力，再建立恢复能力，最后做验证闭环"的顺序推进。前一部分聚焦于如何把ST Stellar提供的硬件安全机制用起来，包括锁步核的初始化与比对窗口设置、ECC的使能与错误注入、看门狗的喂狗策略与超时窗口计算。中间部分进入软件层，讨论如何设计安全监控任务、如何定义故障分类表、如何实现恢复状态机。后一部分则回到工程验证，通过故障注入和覆盖率分析确认监控路径真的有效。

这里给出一个贯穿课程的示例参数约定，后续章节会反复用到：假设某ST Stellar多核控制器运行在200 MHz主频下，安全监控任务周期为5 ms，看门狗超时窗口设为20 ms，锁步比对窗口为每100个时钟周期比对一次。这些数值属于教学示例，实际项目中需要根据芯片手册和系统安全需求重新计算。以看门狗为例，若监控任务周期为5 ms，超时窗口20 ms意味着允许连续3次任务未按时执行才触发复位，这个余量既避免了偶发调度抖动导致误复位，又能在真正卡死时及时响应。

五、从"配置完成"到"验证通过"

工程实践中最常见的误区，是把安全机制的寄存器配置完成当作任务结束。实际上，配置只是起点。一个可交付的安全监控与故障恢复方案，至少需要提供三类证据：监控路径的触发证据（故障注入后确实产生了预期中断或复位）、恢复动作的执行证据（状态机确实进入了目标状态）、以及恢复后的功能证据（降级运行下安全功能仍然可用）。本课程后续每一章都会围绕"如何产生这些证据"展开，而不是停留在机制介绍层面。

当你完成本课程的学习，应当能够独立完成一颗ST Stellar多核控制器的安全监控方案设计、故障恢复策略实现与验证用例编写，并能够清晰地向项目团队说明：哪些故障被覆盖、哪些没有被覆盖、为什么可以接受。这正是本课程希望达到的工程全景。