1. 功能安全概述：什么是功能安全？为什么需要功能安全？
大家好，我是你们这门课的老朋友。咱们今天聊点实在的——功能安全。
很多人第一次听到这个词，以为是要给设备装个保险柜，或者搞什么网络安全防火墙。其实不是。功能安全，说白了就是：当系统出故障时，它不能乱来，必须安全地停下来，或者继续安全地运行。
我举个例子。你开车时踩刹车，ABS（防抱死系统）突然抽风了。这时候你是希望它“彻底失灵”还是“胡乱抱死”？都不对。你希望它——即便内部芯片算错了，也能让刹车力度别太过分，别让车翻掉。这就是功能安全要干的事。
核心定义：功能安全是系统整体安全的一部分，它依赖于系统对输入的正确响应，以及在发生故障时能够将风险降低到可接受的水平。
1.1 为什么我们需要功能安全？
你想想看，现在的汽车、医疗设备、工业机器人，哪个不是电子系统堆出来的？一个刹车指令，从你踩踏板到轮子制动，中间要经过传感器、ECU、执行器、总线……几十个环节。任何一个环节出问题，都可能要命。
我记得2015年有个真实案例：某款车型的定速巡航在高速上突然锁死，驾驶员怎么踩刹车都降不了速，最后是靠撞护栏才停下来的。事后调查发现，是软件里一个计数器溢出，导致刹车信号被覆盖了。这种问题，如果当时按ISO 26262做了安全分析和测试，是完全可以避免的。
所以，功能安全不是“锦上添花”，而是“雪中送炭”。它解决的是三个核心问题：
- 识别风险：系统哪些地方可能出故障？后果有多严重？
- 降低风险：通过硬件冗余、软件监控、故障诊断等手段，把风险压到可接受范围。
- 证明安全：拿出证据，告诉监管机构、客户、用户——我这系统是安全的。
个人经验：我刚开始做功能安全时，总觉得“证明安全”这步最烦人。写文档、做测试、搞评审，感觉像在写论文。但后来有一次，客户审计时翻出我三年前的一份FMEA（失效模式与影响分析），指着其中一条说：“你们这个故障模式当时没覆盖全。” 那一刻我才明白——文档不是给别人看的，是给自己留底的。
1.2 功能安全标准体系概览
功能安全不是拍脑袋想出来的，它有一整套国际标准在支撑。这些标准就像一本本“安全操作手册”，告诉你该怎么做、做到什么程度。
咱们先看一张总览图，把几个核心标准的关系理清楚。
这张图里，最上面那个蓝色的 IEC 61508 是所有功能安全标准的“老祖宗”。它是个通用标准，覆盖工业控制、铁路、机械等各个领域。下面那些彩色的，是各个行业根据自己的特点，从 IEC 61508 派生出来的专用标准。
咱们重点说说最常用的三个：
| 标准编号 | 适用领域 | 核心安全等级 | 我的评价 |
|---|---|---|---|
| IEC 61508 | 通用工业（化工、电力、机械等） | SIL 1 ~ SIL 4 | 最全面，但太“重”了，直接套用会累死人 |
| ISO 26262 | 道路车辆（乘用车、商用车） | ASIL A ~ ASIL D | 汽车圈必学，我这些年主要就在搞这个 |
| IEC 62304 | 医疗设备软件 | 软件安全等级 A/B/C | 医疗软件的生命周期管理，比汽车还严格 |
1.3 三个标准的核心差异
你可能会问：“既然都是功能安全，学一个不就行了？” 嗯，还真不行。每个标准都有自己的“脾气”。
IEC 61508 是“万金油”。它定义了安全生命周期、风险分析、SIL等级、冗余架构……什么都讲，但什么都不细。它更像一本“安全哲学书”，告诉你原理，具体怎么做你自己琢磨。
ISO 26262 是“汽车特供版”。它把 IEC 61508 的 SIL 改成了 ASIL（Automotive Safety Integrity Level），并且针对汽车电子电气系统做了大量细化。比如它要求做“硬件随机失效度量”、“软件单元测试覆盖率”、“安全机制诊断覆盖率”……这些都是汽车行业特有的。
我记得有一次，我们给一个 Tier 1 供应商做 ISO 26262 培训。对方工程师问：“我们以前做工业控制器，SIL 2 就够了。现在做汽车，ASIL B 是不是差不多？” 我说：“差远了。ASIL B 的软件测试覆盖率要求是 90% 语句覆盖 + 70% 分支覆盖，而 SIL 2 根本没这么细的要求。” 他们当场就懵了。
IEC 62304 是“医疗软件专用”。它最狠的地方在于——它把软件安全等级和硬件脱钩了。什么意思？就是说，哪怕你的硬件是 SIL 3 的，如果你的软件写成一坨屎，照样过不了审。而且 IEC 62304 要求你必须做“软件异常处理”、“软件单元测试”、“软件集成测试”，每一步都要有文档、有记录、有评审。
避坑指南：我曾经见过一个团队，拿着 ISO 26262 的流程硬套到医疗设备项目上。结果审计时被开了 20 多个不符合项。为什么？因为 ISO 26262 要求做“硬件随机失效度量”，但医疗设备里很多是纯软件功能，根本不需要硬件度量。所以，选对标准，比做对流程更重要。
1.4 功能安全的核心思想
不管哪个标准，底层逻辑都是一样的。我把它总结成三句话：
- 风险是源头：先搞清楚系统可能出什么故障，后果有多严重。这叫“危害分析与风险评估”（HARA）。
- 安全目标是靶子：根据风险等级，定出安全目标。比如“刹车失灵的概率不能超过 10^-8 每小时”。
- 安全机制是子弹：设计各种机制来达到安全目标。比如双路冗余、自检程序、看门狗定时器……
说白了，功能安全就是一套“防呆”机制。它假设系统一定会出故障，然后提前想好——出故障时怎么办。
个人习惯：我每次开始一个新项目，第一件事不是写代码，而是拉上系统、硬件、软件工程师一起做 HARA。很多人觉得这步浪费时间，但我的经验是——HARA 做得越细，后面返工越少。有一次我们在 HARA 里发现了一个“转向助力突然消失”的风险，当时觉得概率极低，没当回事。结果半年后，供应商的电机驱动芯片真出了 bug，导致助力失效。幸好我们提前设计了“机械备份转向”机制，才没出大事。
1.5 本章小结
咱们这一章，把功能安全的基本概念、为什么需要它、以及标准体系都过了一遍。你记住几个关键点就行：
- 功能安全不是“不出故障”，而是“出故障时不出事”。
- IEC 61508 是基础，ISO 26262 是汽车版，IEC 62304 是医疗版。
- 安全等级越高，开发流程越严格，测试覆盖率要求越高。
- HARA 是功能安全的起点，千万别跳过。
下一章，咱们会深入讲 ISO 26262 的完整开发流程，从概念阶段到生产发布，每一步该做什么、怎么做。到时候我会拿一个真实的汽车电子项目做例子，带你们走一遍。
好，今天就到这儿。有什么问题，咱们课程群里聊。