一、功能安全概述
1.1 功能安全的定义
功能安全，说白了就是——当系统出故障时，它不能伤人。
别小看这句话。我做了十几年功能安全，见过太多人把「功能安全」和「产品质量」混为一谈。它们不是一回事。
产品质量关心的是「系统别坏」，功能安全关心的是「系统坏了也别出事」。你想想看，一个刹车系统，正常工作时谁都会设计。但要是电子控制器突然死机了呢？刹车还能不能踩下去？这才是功能安全要解决的问题。
ISO 26262 里给的定义很严谨：「不存在由电气/电子系统的功能异常表现所导致的危害」。嗯，翻译成人话就是——电子系统出错了，但不能出人命。
核心要点：
- 功能安全 ≠ 产品质量
- 功能安全 ≠ 可靠性
- 功能安全 = 系统在故障状态下仍能保证安全
1.2 发展历程：从「撞了再说」到「先算清楚」
功能安全不是凭空冒出来的。它的发展，说白了就是血的教训换来的。
上世纪 80-90 年代：汽车电子还很简单，一个 ECU 管一件事。那时候大家对安全的理解就是「多做测试」。我记得有老工程师跟我说过，当年他们做 ABS 系统，测试标准就是「跑够十万公里不出事」。听起来挺靠谱，但你想想看——测试永远不能覆盖所有场景。
2000 年左右：线控技术开始出现。油门不用拉线了，刹车也不用液压了，全靠电信号。这时候问题来了——电信号断了怎么办？我参与过一个早期的线控项目，当时团队里吵得不可开交：到底要不要加机械备份？加吧，成本高；不加吧，心里没底。
2011 年：ISO 26262 第一版发布。这是汽车行业第一次有了统一的功能安全标准。说实话，刚出来的时候很多人抵触——「我们做了这么多年车，不也没出大事吗？」但后来大家慢慢明白了，这不是束缚，是保护。
2018 年：第二版发布，加入了半导体、自动驾驶等内容。为什么？因为电子系统越来越复杂，一辆车上的代码量已经超过飞机了。你想想看，几千万行代码，靠人肉测试根本不可能。
我的个人体会：功能安全的发展，其实是从「事后补救」走向「事前预防」。我在项目中遇到过最典型的例子——一个客户说「我们产品从来没出过事故，所以不需要功能安全」。我反问他：「你没出事故，是因为运气好，还是因为设计得好？」
1.3 ISO 26262 标准简介
ISO 26262 的全称是「道路车辆功能安全标准」。它覆盖了从概念设计到生产报废的全生命周期。
标准分几个部分，我挑重点说：
| 部分 | 内容 | 我的理解 |
|---|---|---|
| Part 1 | 术语 | 先把话说清楚，避免鸡同鸭讲 |
| Part 3 | 概念阶段 | 想清楚要做什么，风险在哪 |
| Part 4 | 系统级开发 | 搭好骨架，定好接口 |
| Part 5 | 硬件级开发 | 芯片、电路怎么保证安全 |
| Part 6 | 软件级开发 | 代码怎么写才不容易出bug |
| Part 8 | 支持流程 | 配置管理、变更管理这些「后勤」 |
| Part 9 | ASIL 分解 | 怎么把高安全等级拆成低等级的 |
这里有个关键概念——ASIL（Automotive Safety Integrity Level，汽车安全完整性等级）。它分四个等级：A、B、C、D。ASIL D 是最严格的，比如刹车、转向这类系统。ASIL A 相对宽松，比如雨刮器、车窗。
避坑指南：我曾经见过一个团队，把所有功能都定为 ASIL D。理由是「安全第一」。结果呢？开发成本翻了三倍，项目延期半年。功能安全不是越严越好，而是「恰到好处」。你想想看，一个车窗控制器，有必要用 ASIL D 吗？
1.4 功能安全在汽车电子中的重要性
为什么功能安全越来越重要？三个原因：
- 电子系统越来越多。 以前一辆车只有几个 ECU，现在高端车有上百个。每个 ECU 都可能出故障。
- 系统越来越复杂。 自动驾驶、车联网、OTA 升级……这些新技术带来了新的风险。我参与过一个自动驾驶项目，最头疼的不是算法，而是「当算法出错时，系统怎么兜底」。
- 法规越来越严。 现在没有功能安全认证，很多车厂根本不让你供货。这不是选择题，是必答题。
说个真实案例。某知名品牌的车，因为一个软件 bug，导致刹车助力在特定条件下失效。虽然机械刹车还能用，但需要司机用更大的力气踩。如果司机是个力气小的老人呢？后果不堪设想。这就是功能安全要防止的事情。
一句话总结：功能安全不是成本，是保险。你希望你的车在关键时刻「掉链子」吗？
好了，第一章就讲到这里。下一章我们聊聊怎么做危害分析和风险评估——也就是怎么找出系统里「要命」的地方。