1. ISO 26262概述：功能安全的历史背景、起源与发展

1.1 为什么我们需要功能安全？

说实话，我刚入行那会儿，对功能安全也没什么概念。觉得车能跑、刹车能停、灯能亮，不就够了吗？直到有一次，我参与了一个项目——客户反馈说，车辆在高速行驶时，仪表盘突然黑屏了。后来一查，是软件跑飞了，看门狗没喂上。

嗯，这还算轻的。你想想看，如果黑屏的是刹车控制器呢？或者油门卡住了呢？

这就是功能安全要解决的问题——当系统发生故障时，它不能伤害到人。说白了，就是给汽车电子系统上一道“保险”。

1.2 功能安全的历史背景

功能安全这个概念，其实最早不是汽车行业提出来的。我记得最早是化工、核电这些领域在搞。为什么呢？因为这些行业一旦出事，后果太严重了。

到了20世纪80年代，工业自动化领域开始制定通用的安全标准——IEC 61508。这是功能安全的“老祖宗”。我当年学功能安全时，第一件事就是啃IEC 61508，那叫一个枯燥。

但没办法，它是所有行业功能安全标准的基础。汽车行业的ISO 26262，说白了就是IEC 61508在汽车领域的“定制版”。

1.3 ISO 26262的起源与发展

汽车行业真正开始重视功能安全，是在2000年以后。为什么？因为电子系统越来越复杂了。以前的车，一个ECU管一件事。现在的车，一个域控制器管十几件事。

我记得2010年左右，我参与的一个项目，光是软件代码量就超过了50万行。你想想看，这么多代码，出bug的概率有多大？

ISO 26262第一版是在2011年发布的。当时我还在德国做项目，记得大家拿到标准时，第一反应是——这玩意儿怎么落地？

后来2018年发布了第二版，增加了半导体、自动驾驶等内容。我个人的感觉是，第二版更接地气了，尤其是对软件开发的指导更具体。

1.4 标准的核心目标

ISO 26262的核心目标，用一句话概括就是：把风险降到可接受的水平。

怎么降？通过一套完整的安全生命周期管理。从概念阶段，到开发、生产、运行，再到报废，每个阶段都有对应的安全活动。

我经常跟团队说，ISO 26262不是让你写一堆文档就完事了。它的本质是让你思考：

• 系统可能会出什么故障？
• 故障会导致什么后果？
• 怎么预防或处理这些故障？

举个例子，我在做某个ADAS项目时，发现摄像头在夜间识别率下降。按照ISO 26262的要求，我们需要分析：识别率下降是否会导致功能失效？失效后系统有没有降级策略？

这就是功能安全的思考方式——不是假设系统永远不出错，而是假设它一定会出错，然后提前想好对策。

1.5 适用范围

ISO 26262适用于所有安装在量产乘用车上的电子电气系统。包括：

• 动力系统（发动机、变速箱控制）
• 底盘系统（制动、转向）
• 车身系统（灯光、门窗）
• ADAS和自动驾驶系统

但要注意，它不适用于非量产车、摩托车、商用车（这些有另外的标准）。

1.6 一个常见的误解

很多人以为，功能安全就是“加冗余”。比如两个传感器、两路通信、两个处理器。

其实不完全对。冗余只是手段之一，而且不是所有场景都需要冗余。我见过一个项目，为了满足ASIL D，硬是加了三个冗余通道，结果成本翻了三倍，可靠性反而下降了——因为系统太复杂了。

功能安全的核心是“合理”。合理的风险分析、合理的安全措施、合理的验证方法。不是越复杂越好。

1.7 本章小结

ISO 26262不是一本“天书”，它是一套方法论。它的核心是：

1. 识别风险
2. 定义安全目标
3. 设计安全措施
4. 验证安全效果

说白了，就是让你在开发过程中，时刻问自己一句：“如果这里出问题了，人会受伤吗？”

下一章，我们会深入ASIL等级的定义和分解。这是ISO 26262最核心的概念之一，也是很多工程师容易搞混的地方。到时候我会分享一些实际项目中的案例，帮你真正理解ASIL是怎么用的。

---

公众号:蓝海资料掘金营，微信deep3321