1. 功能安全概述：ISO 26262的起源与发展
大家好，我是老张。做汽车电子这行快十五年了，今天咱们聊聊功能安全。说实话，我刚入行那会儿，国内还没几个人提ISO 26262。那时候做ECU，大家更关心的是“能不能跑”、“会不会死机”，至于“失效了会不会出人命”——嗯，想得不多。
直到2011年，ISO 26262第一版正式发布。我记得当时公司组织培训，我还在心里嘀咕：这不就是IEC 61508的汽车版吗？后来真干起来才发现，事情没那么简单。
1.1 从IEC 61508到ISO 26262
功能安全这个概念，最早是从工业领域来的。IEC 61508是它的老祖宗，覆盖范围很广——化工、核电、机械、汽车都能用。但问题也出在这里：太通用，落地难。
汽车行业有自己的特点：
- 批量大——一个平台几十万辆车，出问题就是大规模召回
- 供应链长——Tier1、Tier2、芯片厂、软件公司，责任划分复杂
- 更新快——车型迭代周期越来越短，安全开发不能拖后腿
所以ISO 26262干脆从IEC 61508里独立出来，专门针对道路车辆。2011年第一版覆盖了3.5吨以下乘用车，2018年第二版扩展到卡车、巴士、摩托车，还加上了半导体的指导。
核心变化：ISO 26262不是重新发明轮子，而是把IEC 61508的通用要求，翻译成了汽车工程师能看懂、能执行的语言。
1.2 功能安全的核心概念
讲概念之前，我先问个问题：你觉得“安全”是什么？
很多人第一反应是“不出事”。但功能安全的角度不一样——它关心的是：系统出了故障，还能不能保证安全？
三个词必须搞明白：Hazard、Risk、Safety Goal。我在项目里见过不少新人把这几个概念混着用，结果评审的时候被怼得很惨。
Hazard（危害）
Hazard是系统本身可能导致的伤害源。比如：
- 刹车系统意外失效 → 车辆无法减速
- 转向系统误动作 → 车辆偏离车道
- 电池热失控 → 起火
注意，Hazard不等于事故。它只是“潜在的危险条件”。
Risk（风险）
Risk = 危害发生的概率 × 伤害的严重程度。说白了，就是“这事儿有多大概率发生，发生了有多严重”。
举个例子：
- 刹车完全失效 → 严重程度高（可能致命），但概率低（有冗余设计）
- 车窗升降卡住 → 严重程度低，概率高也没人管
功能安全只处理合理可预见的风险。你不可能消除所有风险，但必须把风险降到可接受的水平。
Safety Goal（安全目标）
Safety Goal是针对每个Hazard制定的顶层安全要求。它回答一个问题：系统必须做什么，才能避免这个Hazard导致伤害？
比如：
- Hazard：刹车助力失效，制动力不足
- Safety Goal：在刹车助力完全失效时，驾驶员仍能通过机械连接实现至少0.4g的减速度
我的习惯：写Safety Goal的时候，一定要带上可验证的量化指标。光说“保证安全”没用，评审专家会追问：“你怎么证明你保证了？”
1.3 ASIL等级定义
ASIL（Automotive Safety Integrity Level）是ISO 26262里最出圈的概念。很多人一上来就问：“我这个功能是ASIL B还是ASIL D？”
但ASIL不是拍脑袋定的。它由三个参数决定：
| 参数 | 英文 | 含义 | 等级 |
|---|---|---|---|
| Severity (S) | 严重度 | 伤害的严重程度 | S0（无伤害）~ S3（致命） |
| Exposure (E) | 暴露率 | 危险场景发生的概率 | E0（几乎不）~ E4（非常高） |
| Controllability (C) | 可控性 | 驾驶员能否避免伤害 | C0（完全可控）~ C3（不可控） |
三个参数组合，查表得到ASIL等级：
| Severity | Exposure | Controllability | ASIL |
|---|---|---|---|
| S3 | E4 | C3 | ASIL D |
| S3 | E3 | C2 | ASIL B |
| S2 | E4 | C1 | ASIL A |
| S1 | E2 | C0 | QM |
避坑指南：我曾经在一个项目里看到，团队把ASIL B的功能硬生生定成了ASIL D，理由是“安全第一，越高越好”。结果开发成本翻了三倍，周期拖了半年。ASIL不是越高越好，是够用就好。定高了，你付出的代价可能远超收益。
1.4 ASIL等级与开发要求
不同ASIL等级，对开发过程的要求也不同。简单说：
- QM：普通质量管理，不需要额外安全措施
- ASIL A：轻度安全要求，比如增加一些监控
- ASIL B：中等要求，需要系统性的安全分析
- ASIL C：较高要求，需要更严格的验证
- ASIL D：最高要求，几乎每个环节都要双重保障
举个例子，同样是软件单元测试：
- ASIL A：可以只做语句覆盖
- ASIL B：需要分支覆盖
- ASIL C：需要MC/DC覆盖
- ASIL D：需要MC/DC覆盖 + 背靠背测试
你想想看，从A到D，测试工作量可能是指数级增长的。
1.5 知识体系总览
下面这张图，是我自己总结的ISO 26262核心知识框架。每次带新人，我都会先让他们看这张图——搞清楚自己在哪个位置，才知道该干什么。
这张图你看懂了吗？从上到下，就是ISO 26262的典型工作流：先做概念阶段，搞清楚系统是干什么的；然后做HARA，识别危害、评估风险；根据风险定ASIL；最后把安全要求分解到功能、系统、硬件、软件各个层面。
嗯，这里要注意：ASIL等级一旦确定，会贯穿整个开发过程。硬件设计、软件架构、测试策略，全都要跟着ASIL走。所以定级的时候一定要慎重，别拍脑袋，也别为了省事故意定低——那是给自己埋雷。
一句话总结：功能安全不是“加一堆安全功能”，而是用系统化的方法，把风险控制在可接受的水平。ISO 26262给了你一套工具，但怎么用、用多深，取决于你对Hazard、Risk、Safety Goal和ASIL的理解。