1. 功能安全基础：什么是功能安全？为什么需要功能安全？功能安全标准概览
各位同学，咱们今天聊点实在的。功能安全这个词，听起来挺高大上，对吧？其实说白了，就是让系统出故障的时候，别伤人、别毁物、别给环境惹麻烦。我做了十几年安全审计，见过太多“以为没问题”的项目，结果一查，漏洞百出。嗯，咱们先从最基础的说起。
1.1 什么是功能安全？
功能安全，不是指“功能本身安不安全”。比如你开车，刹车踏板踩下去，车能停住——这是功能正常。但如果刹车线断了，车停不住，这时候系统能不能通过某种机制（比如电子制动辅助）让车安全停下来？这就是功能安全要管的事。
我习惯用一个简单的定义：功能安全是系统在发生故障时，仍然能维持安全状态的能力。它关注的是“万一出事了怎么办”，而不是“正常情况下怎么工作”。
核心要点：功能安全 ≠ 功能正确。功能正确是“该做的事做到了”，功能安全是“不该发生的事没发生”。
举个例子。你想想看，一个医疗输液泵，如果软件死机了，它应该怎么办？是继续输液（可能过量），还是立即停止（可能延误治疗）？功能安全就是要定义这种“故障后的行为”，并且确保这个行为是可预测、可接受的。
1.2 为什么需要功能安全？
这个问题，我每次培训都会问学员。答案其实很直接：因为故障不可避免。
硬件会老化，软件有bug，人为会误操作。你不可能造出一个永远不出错的系统。那怎么办？只能让系统在出错时，把伤害降到最低。这就是功能安全存在的意义。
我在项目中遇到过一件事。一个工业机器人项目，团队花了大量精力优化运动控制算法，结果忽略了安全联锁电路的设计。有一次调试，传感器误报，机器人直接撞上了操作员——幸好当时人离得远，没出大事。但那次之后，整个团队都明白了：功能安全不是“锦上添花”，而是“雪中送炭”。
- 保护人身安全：这是最根本的。汽车刹车失灵、医疗设备误操作、工厂机器失控，都可能要人命。
- 避免财产损失：设备损坏、生产停摆、法律诉讼，这些成本往往比开发安全功能高得多。
- 满足法规要求：现在很多行业（汽车、医疗、核电）都强制要求功能安全认证。没有认证，产品根本不能上市。
- 提升品牌信誉：一次安全事故，可能毁掉一个品牌多年的积累。你想想看，丰田的“刹车门”事件，影响有多大？
避坑指南：我曾经见过一个团队，为了赶进度，把安全测试挪到了项目最后两周。结果发现安全机制根本不起作用，不得不重新设计硬件——项目延期了三个月。记住：功能安全不是“最后贴上去的标签”，而是要从需求阶段就开始规划。
1.3 功能安全标准概览
说到标准，很多人头就大了。其实不用怕，标准就是一套“怎么做才安全”的共识。我把它分成三个层次来讲。
1.3.1 IEC 61508：功能安全的“老祖宗”
IEC 61508 是功能安全的通用标准，1998年发布，后来成了很多行业标准的基础。它覆盖了电气、电子、可编程电子安全相关系统（E/E/PE）。说白了，只要你的系统里用了电子元件来实现安全功能，就绕不开它。
这个标准的核心概念是安全完整性等级（SIL），从 SIL 1 到 SIL 4，等级越高，要求越严格。SIL 4 是什么概念？核电站的反应堆保护系统，就是 SIL 4 级别的——出错的概率低到几乎不可能。
| SIL 等级 | 每小时危险失效概率（PFH） | 典型应用 |
|---|---|---|
| SIL 1 | ≥ 10⁻⁶ 且 < 10⁻⁵ | 家用电器安全保护 |
| SIL 2 | ≥ 10⁻⁷ 且 < 10⁻⁶ | 工业过程控制 |
| SIL 3 | ≥ 10⁻⁸ 且 < 10⁻⁷ | 铁路信号系统、工业机器人 |
| SIL 4 | ≥ 10⁻⁹ 且 < 10⁻⁸ | 核电、航空飞行控制 |
我个人习惯把 IEC 61508 看作一本“安全字典”。它不告诉你具体怎么做，但告诉你“应该考虑哪些方面”。比如：风险管理、系统架构、硬件故障率计算、软件开发生命周期……这些概念，后来都被其他标准借用了。
1.3.2 ISO 26262：汽车行业的“安全圣经”
ISO 26262 是从 IEC 61508 衍生出来的，专门针对汽车行业。2011年发布第一版，2018年更新了第二版。现在只要你想做汽车电子零部件（ECU、传感器、执行器），就必须懂它。
它的核心概念是汽车安全完整性等级（ASIL），从 ASIL A 到 ASIL D。ASIL D 是最严格的，比如刹车系统、转向系统。ASIL A 相对宽松，比如车窗升降、座椅调节。
我记得有一次做认证审计，一个团队开发的是 ASIL B 级别的系统，但他们用了 ASIL D 的开发流程。我说：“你们这是杀鸡用牛刀，成本翻倍，但安全收益并没有增加。” 反过来，也有团队把 ASIL D 的系统当成 ASIL B 来做——那问题就大了，审计直接不通过。
小技巧：ASIL 等级不是拍脑袋定的，而是通过“危害分析与风险评估（HARA）”算出来的。评估三个因素：严重度（S）、暴露概率（E）、可控性（C）。公式是：ASIL = max(S, E, C) 的组合。具体怎么算，咱们后面章节会详细讲。
ISO 26262 还引入了“安全目标”、“功能安全概念”、“技术安全概念”这些术语。说白了，就是一层层把“安全需求”分解下去，直到能落地实现。我见过很多团队，安全目标写得很漂亮，但到了代码层面就全忘了——这就是典型的“纸上安全”。
1.3.3 IEC 62304：医疗器械的“安全守则”
IEC 62304 是专门针对医疗器械软件的标准。2006年发布，2015年更新。如果你做的是医疗设备（比如输液泵、呼吸机、CT机），这个标准就是你的“必修课”。
它的核心是软件安全等级（Software Safety Class），分为 A、B、C 三级。C 级最严格，比如生命支持设备。A 级最宽松，比如没有伤害风险的软件。
这个标准有个特点：它特别强调软件开发生命周期。从需求、设计、实现、测试，到维护，每个阶段都有明确要求。而且它要求“软件单元测试”必须覆盖所有代码路径——这一点，很多团队都做不到。
我在审计一个医疗项目时，发现他们的测试覆盖率只有 60%。团队负责人说：“剩下的代码不会被执行到。” 我说：“你怎么知道？万一某个异常路径触发了呢？” 后来他们补了测试，果然发现了一个隐藏的数组越界 bug。嗯，这就是标准的意义——它逼着你把该做的事做到位。
三个标准的对比：
- IEC 61508：通用标准，适用于所有 E/E/PE 系统。SIL 1-4 等级。
- ISO 26262：汽车专用，从 IEC 61508 衍生。ASIL A-D 等级。
- IEC 62304：医疗器械专用，聚焦软件。Class A-C 等级。
它们的关系是：IEC 61508 是“爸爸”，ISO 26262 和 IEC 62304 是“儿子”。但每个“儿子”都有自己的脾气，不能混用。
1.4 小结
这一章咱们讲了功能安全的基础。说白了，就是三件事：
- 什么是功能安全：系统在故障时还能保持安全的能力。
- 为什么需要它：因为故障不可避免，而后果可能很严重。
- 标准概览：IEC 61508 是通用基础，ISO 26262 管汽车，IEC 62304 管医疗。
下一章，咱们会深入讲“危害分析与风险评估（HARA）”——这可是功能安全的“起手式”，做不好，后面全白搭。到时候我会拿一个真实项目案例来拆解，保证你听完就能上手。
课后思考：你手头的产品，如果发生故障，最严重的后果是什么？你觉得它应该达到哪个安全等级？试着用 HARA 的思路想一想，下节课咱们讨论。