1. 功能安全概述：基本概念、发展历史、核心目标与价值

1.1 什么是功能安全？

功能安全，说白了就是——系统出故障时，也不能伤到人。

我刚开始接触这个概念时，总觉得它跟「产品质量」是一回事。后来踩了坑才明白：质量是保证系统正常工作时不出错，而功能安全是保证系统即使出错了，后果也在可接受范围内。

举个例子：你开车时刹车突然失灵，这是故障。但如果系统能检测到刹车失效，自动启动电子制动，同时警告驾驶员——这就是功能安全在起作用。

嗯，这里要注意：功能安全不关心「系统会不会坏」，它关心的是「系统坏了以后，会不会出人命」。

1.2 发展历史：从事故中长出的规矩

功能安全不是凭空想出来的。它背后是一串血淋淋的事故。

年代	事件	影响
1970s	核电站控制系统误动作	催生核工业安全标准
1980s	医疗设备辐射过量	医疗电气设备安全标准出台
1990s	飞机自动驾驶软件故障	航空领域功能安全规范成型
2000s	丰田「 unintended acceleration 」事件	汽车功能安全标准 ISO 26262 诞生

我记得2010年左右，丰田那件事闹得特别大。一个油门踏板的软件bug，导致多起致命事故。从那以后，汽车行业才开始认真对待功能安全。

为什么会这样？因为电子系统越来越复杂。以前一个刹车系统全是机械的，坏了就是坏了，你踩不动就知道有问题。现在全是线控、电控，软件一崩，你连故障都感觉不到。

1.3 核心目标：把风险控制在可接受水平

功能安全的核心目标，用一句话概括就是：把风险降到足够低。

什么叫「足够低」？不是零风险。零风险不存在。你想想看，就算你所有系统都冗余、都自检，还有可能被雷劈呢。

功能安全用的是「可接受风险」的概念。具体来说，分三步走：

1. 识别危害——系统哪些故障会伤人？
2. 评估风险——这个故障发生的概率多大？后果多严重？
3. 降低风险——通过安全机制，把风险压到可接受水平

我在项目中遇到过一件事：一个客户要求所有功能都做到 ASIL D。我说没必要。你一个车窗升降系统，夹到手最多疼一下，跟刹车失灵能比吗？后来我们做了危害分析，把车窗降到 ASIL A，省了一大半开发成本。

1.4 功能安全的价值：不只是合规

很多人觉得功能安全就是「为了过认证」。其实它的价值远不止于此。

• 保护人命——这是最根本的。我见过太多事故报告，每次看完都后背发凉。
• 降低企业风险——一次产品召回，可能让一家公司破产。功能安全是保险。
• 提升产品质量——功能安全要求系统化开发，这本身就能减少很多低级bug。
• 市场准入——现在很多行业，没有功能安全认证，产品根本卖不出去。

1.5 功能安全与其他安全的关系

这里要区分几个容易混淆的概念：

安全类型	关注点	举例
功能安全	系统故障导致的危害	刹车失灵、过压保护失效
信息安全	恶意攻击导致的危害	黑客远程控制车辆
基本安全	正常使用中的物理危害	触电、烫伤、机械伤害

说白了，功能安全管的是「系统自己犯错」，信息安全管的是「别人故意搞破坏」，基本安全管的是「你正常用也会受伤」。三者有重叠，但思路完全不同。

我个人习惯在做项目时，先把这三类安全需求分开列出来，再找交集。不然很容易漏掉。

1.6 小结

功能安全不是什么高深莫测的东西。它就是一个朴素的道理：系统可以坏，但不能因为坏了就伤人。

接下来的章节，我们会深入讲怎么分析危害、怎么定安全目标、怎么写安全需求。但在此之前，先把这些基本概念吃透。地基打不牢，后面盖再高的楼也是危房。