一、ISO26262概述：功能安全背景、发展历程与核心概念
大家好，我是老张。在汽车电子这行摸爬滚打了十几年，今天咱们来聊聊功能安全。说实话，我刚入行那会儿，功能安全还是个挺小众的概念。现在不一样了，你出去面试，不懂ISO26262都不好意思说自己是做汽车电子的。
这一章，我打算从功能安全的背景讲起，带大家看看ISO26262是怎么一步步发展起来的，再把几个核心概念掰开揉碎了讲清楚。嗯，这些概念是后面所有内容的基础，就像盖楼的地基，必须得扎实。
1.1 为什么需要功能安全？
先问大家一个问题：你开车时，敢不敢让刹车系统完全依赖一个没有经过安全验证的软件？
不敢吧？这就是功能安全存在的意义。
汽车电子系统越来越复杂。以前的车，一个ECU控制一个功能，现在呢？一个域控制器管着几十个功能。系统越复杂，出错的概率就越大。我见过一个项目，因为软件中的一个整数溢出，导致ACC（自适应巡航）在高速上突然退出。幸好测试时发现了，不然后果不堪设想。
功能安全要解决的，就是系统在出现故障时，依然能保证人的安全。说白了，就是给系统穿上「防弹衣」。
核心观点：功能安全不是为了让系统不出错，而是让系统在出错时，不会伤害到人。
1.2 ISO26262的发展历程
ISO26262这个标准，不是凭空冒出来的。它的前身是IEC61508，那是工业领域的功能安全标准。但汽车有汽车的特点——批量大、成本敏感、开发周期短。所以，汽车行业需要自己的标准。
我记得2011年ISO26262第一版发布时，整个行业都沸腾了。那时候大家还在摸索，很多公司连「ASIL」是什么都没搞明白。我参加过几次标准解读的培训，讲师在上面讲，下面的人一脸懵。
到了2018年，第二版发布了。这次变化很大，加入了半导体、自动驾驶等内容。为什么？因为行业变了。L3级自动驾驶开始落地，对功能安全的要求更高了。
| 版本 | 发布时间 | 主要变化 |
|---|---|---|
| 第一版 | 2011年 | 覆盖乘用车，10个部分 |
| 第二版 | 2018年 | 加入半导体、自动驾驶、摩托车等 |
| 未来 | 预计2025+ | 可能加入AI安全、SOTIF融合 |
个人经验：我建议大家在项目中尽量使用2018版标准。虽然有些公司还在用2011版，但第二版对半导体的指导更清晰，尤其是做芯片开发的同事，一定要看第二版。
1.3 核心概念：Hazard、Risk、ASIL、Safety Goal
好，接下来是重点。这四个概念，你搞懂了，ISO26262就入门了一半。
1.3.1 Hazard（危害）
Hazard，说白了就是「什么情况会出人命」。比如，刹车失灵、转向卡死、气囊误爆，这些都是Hazard。
但注意，Hazard不是故障本身。故障是「刹车踏板传感器坏了」，Hazard是「刹车功能丧失导致车辆无法减速」。一个是原因，一个是后果。
我在项目中遇到过一种情况：工程师把Hazard和故障混为一谈，结果HARA（危害分析与风险评估）做得一塌糊涂。后来我让他们重新梳理，把「功能失效」和「系统故障」分开，才理清楚。
1.3.2 Risk（风险）
Risk = Hazard发生的概率 × 后果的严重程度。
举个例子：气囊误爆，后果很严重（可能造成人员受伤），但概率很低（因为有多重保护机制）。所以，它的风险不一定比「刹车助力失效」高。
ISO26262用三个参数来评估风险：
- Severity（严重度）：受伤程度，分S0、S1、S2、S3
- Exposure（暴露率）：场景出现的概率，分E0、E1、E2、E3、E4
- Controllability（可控性）：驾驶员能否控制，分C0、C1、C2、C3
这三个参数组合，就决定了ASIL等级。
避坑指南：我曾经见过一个团队，把Exposure评估得过高，导致ASIL等级虚高。结果开发成本翻倍，项目差点延期。记住：Exposure要基于实际场景，不要为了「安全」而过度设计。
1.3.3 ASIL（汽车安全完整性等级）
ASIL分四个等级：A、B、C、D。ASIL D最高，要求最严格；ASIL A最低。还有一个QM（质量管理），表示不需要额外安全措施。
怎么确定ASIL？看下面这个表：
| Severity | Exposure | Controllability | ASIL |
|---|---|---|---|
| S3 | E4 | C3 | D |
| S2 | E3 | C2 | B |
| S1 | E2 | C1 | A |
| S0 | E0 | C0 | QM |
你想想看，如果Severity是S3（致命伤害），Exposure是E4（几乎每次驾驶都会遇到），Controllability是C3（驾驶员几乎无法控制），那ASIL就是D。这就是为什么转向系统、制动系统通常要求ASIL D。
1.3.4 Safety Goal（安全目标）
Safety Goal，就是针对每个Hazard，我们要达到的安全要求。
比如，针对「刹车功能丧失」这个Hazard，Safety Goal可能是：「当刹车系统发生单点故障时，必须在100ms内检测到，并切换到冗余回路，保证制动力不低于正常值的50%。」
Safety Goal要满足三个条件：
- 可验证：能不能通过测试来证明它实现了？
- 可追溯：能不能追溯到具体的Hazard？
- 可分配：能不能分配到具体的系统、硬件、软件？
关键点：Safety Goal是功能安全开发的「宪法」。所有后续的设计、验证、测试，都要围绕它展开。我习惯在项目一开始就把Safety Goal写清楚，然后贴在墙上，每天看一眼。
1.4 小结
这一章，我们讲了功能安全的背景、ISO26262的发展历程，以及四个核心概念。嗯，内容不少，但都是干货。
最后说一句：功能安全不是束缚，而是保护。它保护的是用户的生命，也保护我们工程师的职业生涯。你想想看，如果因为你的代码导致事故，那后果...算了，不说了。
下一章，我们讲HARA（危害分析与风险评估）的具体做法。到时候我会拿一个实际项目案例来拆解，保证让你学完就能用。
课后思考：找一个你熟悉的汽车功能（比如雨刮器、车窗升降），试着分析它的Hazard、Risk、ASIL和Safety Goal。不用太复杂，关键是理解思路。