1. 功能安全概述：ISO26262背景、功能安全定义、ECU开发中的安全痛点

1.1 为什么我们需要功能安全？——ISO26262的诞生背景

说起功能安全，得先聊聊它的“出身”。

早些年，汽车电子还没这么复杂。一个ECU管一件事，坏了也就坏了。但到了2000年以后，情况变了。线控转向、电子刹车、ACC自适应巡航……这些系统一旦出问题，就不是“车开不动”那么简单了——是要命的事。

我记得2010年左右，我参与过一个项目。客户抱怨某款车的电子助力转向在高速上偶尔会“卡一下”。后来排查发现，是软件里一个变量溢出导致扭矩指令跳变。幸好没出大事，但那个项目之后，整个团队对安全的态度彻底变了。

ISO26262就是在这样的背景下诞生的。它脱胎于工业领域的IEC61508，专门为道路车辆量身定制。2011年发布第一版，2018年更新到第二版。说白了，它就是一套“如何把车上的电子电气系统做得足够安全”的方法论。

1.2 功能安全到底在讲什么？——定义与核心概念

功能安全的官方定义很绕口：“不存在由电子电气系统功能异常行为导致的危害”。

你想想看，这句话其实说了两件事：

• 功能异常行为——系统没按设计意图工作。比如该刹车时没刹车，不该刹车时却刹了。
• 危害——对人身造成的伤害。比如撞车、翻车、电击。

所以功能安全的目标很明确：即使系统出了故障，也不能让人受伤。

这里有几个关键概念，我建议你记牢：

术语	我的理解	举个栗子
Hazard（危害）	系统异常可能造成的伤害事件	刹车失灵导致追尾
Risk（风险）	危害发生的概率 × 严重程度	高速上刹车失灵 vs 停车场刹车失灵
ASIL（汽车安全完整性等级）	风险等级，从A到D，D最高	安全气囊ECU通常是ASIL D
Safety Goal（安全目标）	系统必须满足的安全要求	“刹车指令必须在100ms内响应”
Fault / Error / Failure	故障→错误→失效的因果链	电阻虚焊（Fault）→电压异常（Error）→ECU死机（Failure）

1.3 ECU开发中的安全痛点——我踩过的坑

做ECU开发这么多年，我见过太多“安全翻车”的案例。这里挑几个典型的痛点说说。

痛点一：安全需求来得太晚

很多项目是“先画板子、写代码，再补安全文档”。结果呢？安全分析发现某个故障模式需要硬件冗余，但PCB已经投板了。改？来不及。不改？ASIL等级过不去。

我曾经在一个BMS项目中，因为安全需求没提前对齐，导致最后不得不飞线加一个看门狗芯片。那画面，别提多狼狈了。

痛点二：ASIL分解搞不清楚

ASIL D的要求很苛刻。很多人以为“把ASIL D分解成两个ASIL B就完事了”。但分解不是简单的“一人一半”。它要求独立性——两个ASIL B的模块不能有共因失效。

说白了，你不能用一个芯片的两个核来做分解，因为共因失效（比如电源纹波、时钟抖动）会同时影响两个核。

痛点三：软件安全机制与功能逻辑打架

安全机制是要“侵入”正常功能的。比如ECC校验、CRC检查、双核锁步……这些都会消耗CPU时间、增加内存开销。

我见过一个项目，安全团队要求每10ms做一次全内存校验，结果导致控制周期抖动超标。最后两边吵了两个月才妥协：改成“分块校验+触发式全检”。

痛点四：测试覆盖率“纸上谈兵”

ISO26262要求结构覆盖率（语句覆盖、分支覆盖、MC/DC覆盖）。很多团队用工具跑一遍报告，覆盖率达标就交差了。

但工具报告“覆盖了”不代表真的测到了。比如某个分支条件永远为真，工具统计时把它算作“已覆盖”，但实际上那个分支的false路径从来没执行过。

我的建议： 别只看数字，要人工审查测试用例是否真的“有意义”。

1.4 本章知识体系：一张图看懂

下面这张图是我自己梳理的。它把ISO26262的背景、定义和痛点串在了一起。你保存下来，后面每章都可以回来对照。

1.5 本章小结

这一章我们聊了三件事：

1. ISO26262为什么来？——因为电子系统越来越复杂，不出事则已，一出事就是大事。
2. 功能安全是什么？——不是“不出故障”，而是“出了故障也不伤人”。
3. ECU开发中哪些地方容易翻车？——需求晚、分解乱、机制冲突、测试虚。

嗯，这些都是我这些年亲眼见过、亲手改过的坑。后面的章节，咱们一个一个来填。