1. 课程导入

各位工程师朋友，咱们今天聊聊功能安全。说实话，我刚入行那会儿，觉得功能安全就是个「玄学」——一堆文档、一堆流程，跟写代码、调参数好像没啥关系。直到有一次，我在台架上测一个电驱控制器的过流保护，结果保护逻辑在特定工况下没触发，电机直接冒烟了……嗯，从那以后，我才真正理解功能安全不是「纸上谈兵」，而是实打实的保命手段。

1.1 ISO 26262 标准背景

ISO 26262 这个标准，全称叫「道路车辆功能安全」。它脱胎于工业领域的 IEC 61508，但专门针对汽车电子电气系统做了裁剪和强化。我个人习惯把它理解为「汽车电子系统的安全宪法」——它不教你具体怎么设计电路、怎么写代码，而是告诉你：你凭什么证明你的系统是安全的？

这个标准最早在 2011 年发布第一版，2018 年出了第二版。第二版最大的变化，是把半导体、摩托车、多核处理器这些新东西都纳入了范围。我记得当时有个项目，芯片供应商说他们的 MCU 符合 ISO 26262，结果我一看，只做了硬件随机失效分析，软件部分完全没覆盖……这就是典型的「半吊子安全」。所以，搞功能安全，一定要看全貌。

1.2 ASIL 等级定义

ASIL，全称 Automotive Safety Integrity Level，中文叫「汽车安全完整性等级」。说白了，就是给系统的风险程度「打分」。分四个等级：ASIL A、B、C、D，D 是最严苛的。还有一个 QM（Quality Management），意思是「不需要额外安全措施，按质量管理做就行」。

怎么定 ASIL 等级？标准给了三个参数：

• Severity（严重度）：出事了，人伤得多重？
• Exposure（暴露率）：这个危险场景出现的概率高不高？
• Controllability（可控性）：驾驶员能不能在出事前挽救一下？

这三个参数组合起来，查表就能得到 ASIL 等级。举个例子：电驱控制器的非预期加速，如果发生在高速公路上，严重度是 S3（生命危险），暴露率是 E4（几乎每次开车都会遇到），可控性是 C2（普通驾驶员很难控制）——查表，妥妥的 ASIL D。

参数	等级	说明
Severity (S)	S0 ~ S3	S0: 无伤害；S3: 生命危险
Exposure (E)	E0 ~ E4	E0: 几乎不可能；E4: 每次驾驶都可能
Controllability (C)	C0 ~ C3	C0: 完全可控；C3: 几乎不可控

1.3 功能安全生命周期

功能安全生命周期，是 ISO 26262 的「骨架」。它把整个开发过程分成三个阶段：概念阶段、产品开发阶段、生产与运行阶段。每个阶段都有明确的输入、输出和活动。

我个人觉得，理解生命周期最好的方式，是把它想象成「从想法到报废」的全过程管理。你想想看，一个电驱控制器，从最初的需求定义，到硬件设计、软件编码、集成测试，再到装车、售后维护，每一步都可能引入风险。生命周期就是告诉你：每个阶段该做什么安全活动，才能把风险管住。

概念阶段

• 项目定义：明确系统的功能、边界、接口。
• HARA（危害分析与风险评估）：识别危险事件，定 ASIL 等级。
• 功能安全概念：定义安全目标和安全机制。

产品开发阶段

• 系统级：技术安全概念、系统架构设计、集成测试。
• 硬件级：硬件设计、FMEDA（失效模式影响与诊断分析）、硬件集成测试。
• 软件级：软件架构设计、单元实现、软件测试。

生产与运行阶段

• 生产：确保生产过程不引入安全缺陷。
• 运行与维护：监控现场故障，处理售后问题。
• 报废：确保安全功能在生命周期结束时不会引发新风险。

下面这张图，是我自己画的功能安全生命周期概览。你可以把它当作「路线图」，后续每一章都会对应到其中的某个环节。

这张图里，三个阶段的箭头是单向的，但底部有一条虚线反馈回路——这代表功能安全不是「做完就完事」的。现场反馈回来的故障数据，可能会触发安全机制的更新，甚至导致安全目标的重新定义。我见过一个项目，因为售后发现某个故障模式的发生频率远超预期，不得不把 ASIL 等级从 B 提升到 C，整个硬件诊断方案都重做了。所以，功能安全是活的，不是死的。