1. ISO 26262 概述：功能安全背景、道路车辆功能安全标准发展历程、ISO 26262 核心概念
大家好，我是你们这趟功能安全之旅的向导。说实话，每次讲这门课的开头，我都挺感慨的。十年前我刚接触功能安全时，国内懂这个的人掰着手指头都能数过来。现在呢？几乎每个做汽车电子的工程师，简历上都得写上“熟悉ISO 26262”。
这一章，咱们先把地基打牢。我会带着大家把功能安全到底是个啥、这个标准是怎么一步步长成今天这样的、以及那几个绕不开的核心概念（ASIL、安全生命周期）给捋清楚。别急，咱们慢慢来。
1.1 功能安全背景：为什么我们需要它？
先问大家一个问题：你开车时，最怕什么？
怕刹车失灵，怕方向盘突然锁死，怕油门自己踩到底。对吧？
这些场景，说白了就是“电子系统的功能出了问题，导致了人身伤害”。这就是功能安全要解决的核心问题——防止因系统故障（包括硬件故障和软件故障）导致的人员伤亡。
功能安全的定义（ISO 26262-1）：
不存在由电子/电气系统的功能异常表现所引起的危害而导致的不合理风险。
我个人的理解更直白一些：功能安全 = 系统在出故障时，也要保证人的安全。
你想想看，一个ADAS摄像头如果因为软件bug，把前方的卡车识别成了白云，然后ACC（自适应巡航）系统一脚油门撞上去——这就是功能安全没做好。我在2018年参与过一个L2级项目的评审，当时就发现了一个类似的感知融合逻辑漏洞。嗯，那一次差点就放行了，幸亏多审了一轮。
所以，功能安全不是“锦上添花”，而是“雪中送炭”。它是汽车电子开发的底线。
1.2 道路车辆功能安全标准发展历程
这个标准不是一天建成的。我把它分成几个关键节点，大家看这张表就清楚了：
| 年份 | 里程碑 | 说明 |
|---|---|---|
| 1998 | IEC 61508 发布 | 通用功能安全标准，所有行业的基础 |
| 2005 | ISO 26262 立项 | 汽车行业开始制定自己的功能安全标准 |
| 2011 | ISO 26262 第一版发布 | 覆盖乘用车，最大3.5吨 |
| 2018 | ISO 26262 第二版发布 | 扩展至卡车、巴士、摩托车，新增半导体指南 |
| 2023+ | 第三版讨论中 | 重点：AI安全、自动驾驶、SOTIF融合 |
这里我想多说一句。2011年第一版刚出来时，很多公司是“被迫”接轨的——客户要求，不做不给订单。但到了2018年第二版，情况完全变了。大家开始主动研究，因为发现功能安全做得好，不仅能减少召回，还能提升品牌信任度。
我记得2015年帮一家Tier 1做MCU层面的安全监控软件，那时候连个像样的工具链都没有，全靠手写汇编做LBIST（逻辑内建自测试）的调度。现在回头看，真是“小米加步枪”的时代。
1.3 ISO 26262 核心概念
好，接下来是重头戏。三个概念你必须刻在脑子里：功能安全、ASIL、安全生命周期。
1.3.1 功能安全（Functional Safety）
前面已经讲过了，这里再强调一点：功能安全不是“不出故障”，而是“故障了也不伤人”。
举个例子：一个EPS（电动助力转向）系统，如果电机驱动芯片短路了，系统必须能检测到这个故障，并在一段时间内切换到安全状态（比如降级为手动转向，或者直接切断助力）。这就是功能安全机制在起作用。
我的经验：很多刚入行的工程师容易把“功能安全”和“功能正确性”搞混。功能正确性是说“系统该干啥就干啥”，功能安全是说“系统出错了也不能害人”。两者有交集，但不等同。
1.3.2 ASIL（汽车安全完整性等级）
ASIL 是 ISO 26262 的灵魂。它定义了系统需要达到的安全等级，从低到高分别是：QM、ASIL A、ASIL B、ASIL C、ASIL D。
怎么确定一个功能该定哪个等级？看四个参数：
- Severity (S)：伤害的严重程度（S0~S3）
- Exposure (E)：暴露在危险场景中的概率（E0~E4）
- Controllability (C)：驾驶员或其他人控制局面的能力（C0~C3）
然后查表：
| 严重度 (S) | 暴露率 (E) | 可控性 (C) | ASIL 等级 |
|---|---|---|---|
| S3 | E4 | C3 | ASIL D |
| S3 | E3 | C2 | ASIL B |
| S2 | E2 | C2 | ASIL A |
| S1 | E1 | C1 | QM |
举个例子：刹车系统的电子踏板。如果刹车信号丢失，后果是S3（致命伤害），暴露概率E4（每次开车都会用到），可控性C3（驾驶员几乎无法补救）。查表：ASIL D。所以刹车系统的软件，必须按照ASIL D的要求来开发。
注意：ASIL 等级不是“越高越好”。ASIL D 的开发成本是 QM 的 5~10 倍。我曾经见过一个项目，把雨刮器的 ASIL 定到了 B，结果评审时被客户骂了一顿——没必要。合理分配 ASIL 等级，是系统架构师的基本功。
1.3.3 安全生命周期（Safety Lifecycle）
安全生命周期，说白了就是“从想法到报废，安全贯穿始终”。ISO 26262 把它分成了几个阶段：
- 概念阶段：定义功能、识别危害、确定安全目标
- 产品开发阶段：系统级、硬件级、软件级的设计与验证
- 生产与运行阶段：制造、测试、维护、报废
咱们这门课，重点放在产品开发阶段中的软件层面。也就是从软件安全需求，到软件架构设计、单元实现、集成测试、验证确认这一整条链。
下面这张图，是我自己画的 ISO 26262 安全生命周期概览，大家可以对照着看：
这张图里，我特意把反馈箭头画出来了。为什么？因为安全生命周期不是一条直线走到底的。你在软件集成测试时发现了一个架构层面的安全漏洞，就得回到架构设计阶段去改。这种迭代，在项目中非常常见。
我记得有一次做EPS的软件集成测试，发现一个内存保护机制在特定时序下会失效。查到最后，是软件架构设计时没有考虑多核访问冲突。那一次，我们不得不把整个安全架构重新评审了一遍，多花了三周时间。但说实话，这三周花得值——否则一旦量产，后果不堪设想。
1.4 本章小结
好，咱们把这一章的核心点串一下：
- 功能安全：系统出故障时，也要保证人的安全。
- ASIL：通过S、E、C三个参数查表确定，QM到ASIL D逐级递增。
- 安全生命周期：从概念到报废，安全贯穿始终，且允许迭代反馈。
下一章，我们会深入软件安全需求的定义与分解。到时候我会拿一个真实项目的安全目标来拆解，告诉大家怎么把ASIL D的需求一步步分解到软件组件上。那才是真正“动手”的开始。
今天就到这里。有什么问题，咱们课堂上随时交流。