第2章：ISO 26262标准介绍
大家好，欢迎来到第二章。这一章我们聊聊ISO 26262这个标准本身。说实话，我刚入行那会儿，看到这个标准编号就觉得头大——26262，什么鬼？后来做项目做多了才发现，它其实就是一本「安全驾驶手册」，只不过对象不是人，而是汽车上的电子系统。
2.1 ISO 26262的起源
ISO 26262的诞生，说白了是被「逼」出来的。
早些年，汽车电子系统没那么复杂。一个ECU管一个功能，出了问题大不了那个功能不能用。但后来不行了——线控转向、自动紧急刹车、自适应巡航……这些系统一旦出问题，是要出人命的。
我记得2010年左右，行业内出了几起跟电子系统相关的安全事故。虽然具体细节不便多说，但大家心里都清楚：必须有个统一的标准来管这事儿了。
于是，ISO 26262在2011年正式发布。它的前身是IEC 61508，那是工业领域的功能安全标准。但汽车行业有自己的特点——批量大、成本敏感、开发周期短。所以ISO 26262在IEC 61508的基础上做了大量裁剪和定制。
2018年，第二版发布，把适用范围从乘用车扩展到了卡车、巴士、摩托车，还加上了半导体和自动驾驶的内容。嗯，这个我们后面会细说。
核心要点：ISO 26262不是凭空造出来的，它是从IEC 61508演化而来，专门针对汽车行业的「功能安全圣经」。
2.2 ISO 26262的组成部分
ISO 26262一共12个部分。你想想看，一个标准能写12个部分，说明它真的把安全这件事掰开揉碎了。
| 部分 | 内容 | 我的理解 |
|---|---|---|
| Part 1 | 术语 | 先把话说清楚，避免鸡同鸭讲 |
| Part 2 | 管理 | 安全不是一个人的事，是组织的事 |
| Part 3 | 概念阶段 | 想清楚再动手 |
| Part 4 | 系统级开发 | 搭框架 |
| Part 5 | 硬件级开发 | 选芯片、算失效率 |
| Part 6 | 软件级开发 | 写代码、做测试 |
| Part 7 | 生产和运维 | 车造出来之后怎么办 |
| Part 8 | 支持过程 | 工具、配置、文档这些杂活 |
| Part 9 | ASIL和安全分析 | 核心方法论 |
| Part 10 | 指南 | 看不懂前面？看这个 |
| Part 11 | 半导体指南（2018新增） | 专门讲芯片怎么做安全 |
| Part 12 | 摩托车（2018新增） | 两轮车也有安全需求 |
我个人习惯把Part 3到Part 7叫做「核心开发流程」，Part 8和Part 9是「支撑工具」，Part 10到Part 12是「扩展和补充」。这样记起来方便。
2.3 ISO 26262的关键概念
这部分很重要。我建议你把这几个概念刻在脑子里，因为后面所有章节都在围绕它们转。
2.3.1 功能安全
什么是功能安全？官方定义很绕：「不存在由电气/电子系统的功能异常表现引起的不可接受的风险」。
说白了就是：系统出故障了，但不能出人命。
举个例子：你的刹车踏板踩下去，刹车片应该夹紧。但如果电子信号出错了，刹车没反应——这就是功能安全问题。功能安全要做的就是：即使信号出错了，刹车也得有办法停下来。
我的经验：很多新手把功能安全和「系统不出错」混为一谈。其实不是。功能安全承认系统会出错，但要求出错后后果可控。这是根本区别。
2.3.2 安全目标
安全目标，英文叫Safety Goal。它是整个安全工作的「最高指令」。
每个安全目标对应一个具体的危险事件。比如：
- 「车辆在行驶中不能发生非预期的加速」——这是一个安全目标
- 「转向系统不能丧失助力功能」——这是另一个安全目标
每个安全目标都会分配一个ASIL等级（A、B、C、D）。ASIL D是最严格的，比如刹车、转向这类系统。ASIL A相对宽松，比如车窗升降。
我曾经在一个项目里遇到过一个问题：客户给了我们一个安全目标，但描述得太模糊了，比如「系统要安全」。这根本没法做。后来我们花了两周时间，把每个安全目标拆成了可验证的条目。嗯，这个坑我替你们踩过了。
2.3.3 安全状态
安全状态，就是系统出故障后，应该进入的一个「不会造成伤害」的状态。
常见的例子：
- 电机驱动系统出故障 → 切断动力，进入安全状态
- 电池管理系统检测到过温 → 降低功率，进入安全状态
- 自动驾驶系统感知失效 → 请求驾驶员接管，或者安全停车
这里有个关键点：安全状态不是唯一的。同一个系统可能有多个安全状态，取决于故障的类型和严重程度。
注意：安全状态本身也需要被验证。我曾经见过一个设计，故障后系统进入了「安全状态」，但那个状态本身就有问题——比如切断了所有电源，结果连故障指示灯都点不亮了。这算哪门子安全？
2.3.4 其他关键概念
还有几个概念，我简单提一下：
- 故障容错时间间隔（FTTI）：从故障发生到系统必须进入安全状态的时间窗口。比如刹车系统的FTTI可能只有几十毫秒。
- 安全机制：用来检测故障、或者把系统带入安全状态的手段。比如看门狗定时器、ECC校验、冗余设计等。
- ASIL分解：把一个高ASIL要求拆成多个低ASIL要求。比如ASIL D可以分解成ASIL C + ASIL A。但要注意，分解不是白给的，有严格的规则。
2.4 ISO 26262的适用范围
这个问题经常有人问：ISO 26262到底管哪些东西？
第一版（2011）只覆盖乘用车，而且只覆盖「量产」的电子电气系统。概念车、原型车、非量产车不管。
第二版（2018）扩展了：
- 乘用车（继续覆盖）
- 卡车、巴士（新增）
- 摩托车（新增）
- 半导体（新增，Part 11专门讲这个）
- 自动驾驶（新增，但只覆盖到SAE L3，L4/L5还在讨论中）
另外要注意：ISO 26262不覆盖「功能本身」的安全。什么意思？比如你设计了一个自动泊车系统，ISO 26262管的是这个系统「如果出故障了怎么办」，但它不管「这个自动泊车算法好不好用、会不会撞墙」。后者是SOTIF（ISO 21448）的范畴。
一句话总结：ISO 26262管的是「电子系统出故障后的安全性」，不是「功能好不好用」。这两个容易搞混，我见过不少团队在这上面栽跟头。
2.5 本章小结
这一章我们聊了ISO 26262的来龙去脉、它的12个组成部分、以及几个核心概念——功能安全、安全目标、安全状态。这些是后面所有章节的基础。
下一章我们会进入实战：怎么在项目里落地ISO 26262。到时候我会拿一个真实项目做例子，带你们走一遍完整的流程。
好，今天就到这里。有什么问题，欢迎在评论区留言。