1. 课程导入与功能安全总览
在汽车电子控制单元（ECU）的开发中，“功能安全”并不是一个附加功能，而是与产品能否合法上路、能否被整车厂接受直接相关的硬性约束。ISO 26262 是道路车辆功能安全的国际标准，它要回答的核心问题是：当电子电气系统发生随机硬件失效或系统性失效时，如何把对人员造成伤害的风险控制在可接受范围内。本课程围绕 ST 的 Stellar 系列车规微控制器，讲解如何从概念设计一路走到量产验证，而本节先建立全局认知：标准在讲什么、ASIL 等级如何划分、Stellar 在 ECU 中处于什么位置、它的功能安全目标是什么。
ISO 26262 的核心概念
ISO 26262 以“相关项（Item）”为分析起点。相关项可以是一个功能、一个系统或一个 ECU，例如“电子驻车制动 ECU”。围绕相关项，标准定义了三个层层递进的概念：
- 危害（Hazard）：由相关项功能异常导致的潜在伤害来源，例如制动意外释放。
- 安全目标（Safety Goal）：针对危害提出的顶层安全要求，例如“避免非预期的制动力释放”。安全目标带有 ASIL 等级，是后续所有设计的最高约束。
- 功能安全概念（FSC）与安全机制：把安全目标分解为功能层面的安全要求，再落到具体的检测、冗余、降级等安全机制上。
标准还区分了两类失效：系统性失效（设计缺陷、软件错误，靠流程和验证消除）与随机硬件失效（器件老化、位翻转，靠诊断覆盖率和冗余控制）。理解这一区分很重要，因为它决定了后续工作中“流程证据”和“硬件指标”两条主线。
ASIL 等级划分
ASIL（Automotive Safety Integrity Level）由三个维度共同决定：严重度 S（伤害程度，S0–S3）、暴露率 E（运行场景出现概率，E0–E4）、可控性 C（驾驶员或其他人员避免伤害的可能性，C0–C3）。三者组合后映射为 QM、ASIL A、B、C、D 五个等级，D 最严格。QM 表示仅需常规质量管理，不承担功能安全要求。
ASIL 等级不是标签，而是会直接改变开发方式：等级越高，对硬件失效率指标（如单点故障度量 SPFM、潜伏故障度量 LFM）、诊断覆盖率、验证深度、独立评审的要求越严。下表给出一个便于记忆的对照示例（数值为教学示例，实际项目须按标准表格与安全分析确定）：
| ASIL | 典型场景示例 | SPFM 目标（示例） | 典型安全机制强度 |
|---|---|---|---|
| QM | 车内氛围灯 | 不要求 | 常规质量流程 |
| A | 后视镜调节 | ≥90% | 基础诊断 |
| B | 车窗防夹 | ≥90% | 诊断 + 有限冗余 |
| C | 自适应巡航 | ≥97% | 锁步核 + 监控 |
| D | 电动助力转向、制动 | ≥99% | 高覆盖诊断 + 冗余通道 |
ST Stellar 系列在汽车 ECU 中的定位
ST 的 Stellar 系列是面向汽车域控制器与高集成 ECU 的车规微控制器家族，典型特征包括多核架构、内嵌硬件安全机制（如锁步核、ECC、看门狗、时钟与电压监控）以及符合 ISO 26262 的开发流程支持。它通常位于整车电子电气架构的“执行与协调层”：向上通过 CAN/CAN-FD、以太网等总线接收整车控制指令，向下驱动功率级或执行器，同时自身承担安全相关的实时控制任务。
把 Stellar 放进一个典型安全相关 ECU 的信号链中，可以更清楚地看到它的职责边界与安全机制落点。下图给出一个面向 ASIL D 场景的简化信号链与安全机制分布示意：
图中可以看到，Stellar 并不是孤立芯片，而是信号链中的“决策与安全仲裁中心”：它接收冗余传感输入，在主核与锁步核之间做一致性比较，通过安全机制层持续自检，最终决定是否允许功率级输出。一旦检测到不可恢复故障，它必须能在规定时间内把执行器带入安全状态——这正是安全目标在硬件上的具体体现。
Stellar 的功能安全目标
对 Stellar 而言，功能安全目标可以归纳为三条主线：
- 正确性：在无故障时，控制输出必须与预期一致，不能因软件或配置错误产生非预期动作。
- 可检测性：发生随机硬件失效时，安全机制必须在故障容错时间内检测到，并给出明确故障标志。
- 可控降级：检测到故障后，系统必须能进入定义好的安全状态（如关断输出、限功率、切换备份通道），而不是失控或静默失效。
这三条主线会贯穿后续所有章节：从安全需求分解、硬件指标计算，到软件安全机制实现、诊断覆盖评估，再到量产阶段的测试与追溯。学习本课程时，建议始终带着一个问题：当前这一步工作，是在为哪条安全目标提供证据？ 只有把每个设计动作与安全目标对应起来，功能安全开发才不会变成一堆孤立文档。