2. 功能安全基础
在汽车电子电气系统开发中，功能安全不是“附加功能”，而是一套贯穿需求、设计、实现、验证、生产与运行的系统性工程方法。ISO 26262 是道路车辆功能安全的国际标准，它把“避免由电子电气系统故障导致的不可接受风险”转化为可执行、可验证、可追溯的工程活动。对于 S32K 这类面向车身、底盘与安全相关控制器的微控制器，理解 ISO 26262 的标准体系、ASIL 等级划分、安全生命周期，以及功能安全（FuSa）与预期功能安全（SOTIF）的区别与联系，是后续故障监控设计的基础。
2.1 ISO 26262 标准体系概览
ISO 26262 采用“按部件与按阶段”结合的结构。它覆盖从概念阶段到报废阶段的完整安全生命周期，并针对不同对象给出专门要求。其核心部分可概括为：
- 第 1 部分：术语——统一功能安全、危害、风险、ASIL 等基础概念。
- 第 2 部分：功能安全管理——规定组织级与项目级安全管理、安全文化、能力管理、确认措施。
- 第 3 部分：概念阶段——完成相关项定义、危害分析与风险评估（HARA）、安全目标与功能安全概念。
- 第 4 部分：系统级产品开发——把安全目标分解为技术安全需求，定义系统架构、安全机制与验证策略。
- 第 5 部分：硬件级产品开发——关注硬件失效模式、诊断覆盖率、失效率指标与硬件架构度量。
- 第 6 部分：软件级产品开发——规定软件安全需求、架构设计、单元设计与实现、集成与测试。
- 第 7 部分：生产、运行、服务与报废——确保安全相关特性在量产与售后阶段持续受控。
- 第 8 部分：支持过程——包括需求管理、配置管理、变更管理、验证确认、文档管理。
- 第 9 部分：ASIL 导向与安全导向分析——提供 FMEA、FTA、DFA 等分析方法要求。
- 第 10 部分：指南——给出实施建议与解释性说明。
- 第 11 部分：半导体应用指南——针对芯片级功能安全开发，如 S32K 的 SEooC 开发、安全手册、FMEDA 与诊断覆盖。
- 第 12 部分：摩托车——面向两轮车的适配要求。
对 MCU 工程师而言，最常接触的是第 5、6、11 部分：硬件安全机制、软件安全机制以及芯片安全手册。S32K 的功能安全资料通常以安全手册、FMEDA、安全分析报告和诊断库形式提供，帮助系统集成商完成安全论证。
2.2 ASIL 等级划分：从危害到开发严格度
ASIL（Automotive Safety Integrity Level）是 ISO 26262 中用于表示安全完整性等级的核心参数，分为 A、B、C、D 四个等级，D 最高。ASIL 不是直接由“故障后果”单一决定，而是通过 HARA 对危害事件从三个维度进行评估：
- 严重度 S：S0 至 S3，描述伤害程度。
- 暴露率 E：E0 至 E4，描述运行场景出现的概率。
- 可控性 C：C0 至 C3，描述驾驶员或其他人员避免伤害的能力。
三者组合后映射为 QM（质量管理）或 ASIL A/B/C/D。ASIL 越高，对开发流程、验证方法、硬件失效率指标、软件架构约束和文档追溯的要求越严格。例如 ASIL D 通常要求更高的诊断覆盖率、更严格的独立性与冗余措施，以及更完整的确认评审。
| 等级 | 典型风险含义 | 开发严格度 | S32K 场景示例 |
|---|---|---|---|
| QM | 无功能安全要求，按质量管理 | 常规开发 | 普通车身灯光控制 |
| ASIL A | 较低伤害风险 | 基础安全活动 | 后视镜调节 |
| ASIL B | 中等伤害风险 | 较完整安全机制 | 仪表报警显示 |
| ASIL C | 较高伤害风险 | 高诊断覆盖与冗余 | 电子驻车制动 |
| ASIL D | 最高伤害风险 | 最高完整性要求 | 安全气囊、EPS 扭矩控制 |
2.3 安全生命周期：从概念到报废的闭环
安全生命周期是 ISO 26262 的骨架，它把功能安全活动按时间顺序组织起来，并强调“先定义、再分解、后验证、持续维护”。典型阶段包括：
- 相关项定义：明确系统边界、功能、接口、运行环境与依赖关系。
- 危害分析与风险评估（HARA）：识别危害事件，评估 S/E/C，确定 ASIL 与安全目标。
- 功能安全概念：把安全目标转化为功能安全需求，分配初步安全机制。
- 技术安全需求：在系统、硬件、软件层面细化安全需求与安全机制。
- 系统与软硬件开发：设计、实现、集成，并执行安全分析（FMEA、FTA、DFA）。
- 安全验证与确认：通过测试、评审、分析证明安全目标达成。
- 生产与运行：确保量产一致性、诊断覆盖、现场监控与维护。
- 报废与退役：处理安全相关数据与功能退出。
在 S32K 项目中，安全生命周期通常体现为：安全需求 → 安全机制配置（如 FCCU、ECC、看门狗、时钟监控）→ 诊断库集成 → 故障注入测试 → 安全手册符合性检查 → 现场监控与失效报告。整个过程需要双向追溯：从安全目标追溯到测试用例，从故障现象追溯到安全需求。
2.4 功能安全与预期功能安全的区别与联系
功能安全（FuSa）与预期功能安全（SOTIF）常被混淆。两者都服务于“系统安全”，但关注点不同：
- FuSa 关注由电子电气系统故障引起的危害，例如 MCU 内部寄存器翻转、时钟漂移、电源异常、通信丢帧。它通过安全机制、诊断覆盖、冗余与安全状态切换来降低风险，标准是 ISO 26262。
- SOTIF 关注在没有系统故障的情况下，由于性能局限、环境感知不足或可预见误用导致的不安全行为。例如 AEB 在逆光下未识别行人、雷达对静止车辆误判。标准是 ISO 21448，强调场景覆盖、边界识别与验证确认。
两者的联系在于：它们共同构成“系统安全”的完整拼图。FuSa 解决“系统坏了怎么办”，SOTIF 解决“系统没坏但能力不够怎么办”。在 S32K 这类安全控制器中，FuSa 体现为 FCCU、ECC、看门狗、时钟监控等机制；而 SOTIF 更多由上层感知、决策与整车功能定义负责，但 MCU 需要提供足够的诊断与安全状态接口，支持上层完成安全降级。
2.5 案例与复盘：S32K 安全开发中的关键检查点
假设某 EPS 项目安全目标为 ASIL D，要求“避免非预期助力扭矩”。在 S32K 上，典型安全机制包括：
安全机制配置示例（概念级）：
- FCCU：监控内核、时钟、电源、ECC 故障
- ECC：Flash/RAM 单比特纠错、双比特报错
- SWT/WDOG：程序流监控与超时复位
- 时钟监控：CMU 检测时钟失锁与频率漂移
- 电压监控：PMC 低压/高压检测
- 诊断库：周期性 RAM/Flash 自检、寄存器自检
- 安全状态：关闭 PWM 输出、进入安全扭矩限制复盘时需检查：安全目标是否完整分解到软硬件需求；每条安全机制是否有对应的诊断覆盖证据；故障注入是否覆盖单点故障与潜伏故障；安全手册中的假设条件是否在系统集成中得到满足；生产与运行阶段是否有持续监控与失效报告机制。只有形成“需求—设计—实现—验证—运行”的闭环，功能安全才真正落地。