第2章：标准体系解读：ISO 26262、IEC 61508、IEC 62304的适用范围与核心差异
做功能安全这些年，我经常被问到同一个问题：
「这三个标准到底有啥区别？我该学哪个？」
说实话，我刚入行时也晕过。ISO 26262、IEC 61508、IEC 62304，名字长得像，内容也有交叉。但它们的定位完全不同。今天我就把这三个标准掰开揉碎了讲清楚。
2.1 IEC 61508：功能安全的「老祖宗」
IEC 61508是通用功能安全标准。它发布于1998年，后来经过修订。你可以把它理解为功能安全的「宪法」。
为什么这么说？因为所有行业的功能安全标准，几乎都是从它派生出来的。ISO 26262、IEC 62304、IEC 61511（过程工业）、ISO 13849（机械安全）……这些全是IEC 61508的孩子。
核心定位：通用、基础、行业无关。
它不针对任何特定领域。你造汽车、做医疗器械、搞工业自动化，都能用它。但正因为它太通用，具体落地时往往需要行业标准来细化。
我记得有一次，一个做工业控制器的朋友问我：「我能不能直接用IEC 61508做认证？」我说可以，但你要做好心理准备——你得自己解释每个条款在你的场景下怎么实现。没有行业指南，全靠自己悟。
IEC 61508的关键概念：
- 安全完整性等级（SIL）：SIL 1到SIL 4，数字越大越严格。SIL 4对应的事故概率要求是10-8到10-9每小时，几乎不可能达到。
- E/E/PE系统：电气/电子/可编程电子系统。这是它的覆盖范围。
- 安全生命周期：从概念到退役的全过程管理。
嗯，这里要注意：IEC 61508对软件的要求相对宽松。它更多关注硬件随机失效和系统失效。软件部分虽然有，但不如后来的标准那么细致。
2.2 ISO 26262：道路车辆的「专属定制」
ISO 26262是IEC 61508在汽车行业的「定制版」。它发布于2011年，2018年出了第二版。
说白了，汽车行业觉得IEC 61508太笼统，不够用。于是搞了个自己的标准。ISO 26262的核心理念和IEC 61508一致，但针对汽车的特点做了大量细化。
个人经验：我参与过一个ADAS项目，客户要求符合ISO 26262 ASIL D。刚开始我们想偷懒，直接套用IEC 61508的方法。结果评审时被专家怼了回来——ISO 26262对软件架构、单元测试、覆盖率的要求比IEC 61508严格得多。后来老老实实按ISO 26262重新做了一遍。
ISO 26262的关键差异：
- ASIL等级：A、B、C、D，对应IEC 61508的SIL。但ASIL D比SIL 3更严格，接近SIL 4。
- 危害分析与风险评估（HARA）：这是ISO 26262独有的。它要求你分析每个功能失效会带来什么后果，然后确定ASIL等级。
- 软件安全要求：比IEC 61508详细得多。比如代码覆盖率要求、工具置信度等级、软件单元测试的深度。
- 硬件随机失效度量：引入了PMHF（概率度量）和SPFM/LFM（单点/潜伏故障度量）。
你想想看，汽车上那么多电子控制单元（ECU），每个都可能失效。ISO 26262就是告诉你：怎么分析、怎么设计、怎么验证，才能把风险降到可接受的水平。
适用范围：乘用车、商用车、摩托车（第二版新增）。不适用于非道路车辆（比如工程机械）。
2.3 IEC 62304：医疗软件的「生命线」
IEC 62304是专门针对医疗设备软件的标准。它发布于2006年，2015年修订。
这个标准很有意思。它不像ISO 26262那样强调硬件失效，而是聚焦在软件本身。为什么？因为医疗设备的核心功能往往由软件实现。一个输液泵的软件bug，可能直接导致病人死亡。
避坑指南：我曾经帮一家医疗设备公司做咨询。他们想用ISO 26262的方法来做IEC 62304的软件安全。结果发现完全行不通。ISO 26262的ASIL等级是基于危害分析得出的，而IEC 62304的软件安全等级（A、B、C）是基于软件对患者、操作者、他人的伤害程度来定的。两者的逻辑完全不同。
IEC 62304的关键概念：
- 软件安全等级：A（无伤害）、B（非严重伤害）、C（严重伤害或死亡）。注意，这里没有D级。
- 软件生命周期：从开发计划到维护，但比ISO 26262简单。
- 软件单元测试：要求100%语句覆盖和分支覆盖（对于等级C）。
- 异常处理：特别强调软件对异常情况的处理能力。
说白了，IEC 62304的核心思想是：软件不能出bug。如果出了bug，系统必须能安全地处理它。比如一个CT机，如果软件崩溃了，机器必须能安全停机，不能把病人夹在里面。
2.4 核心差异对比
我把三个标准的核心差异整理成了一张表。这张表我每次培训都会用，你直接拿去用就行。
| 维度 | IEC 61508 | ISO 26262 | IEC 62304 |
|---|---|---|---|
| 行业 | 通用（工业、过程、机械等） | 道路车辆 | 医疗设备 |
| 安全等级 | SIL 1-4 | ASIL A-D | A、B、C |
| 核心关注点 | 硬件随机失效 + 系统失效 | 硬件随机失效 + 系统失效 + 软件 | 软件失效 |
| 危害分析 | 通用方法（如HAZOP） | HARA（危害分析与风险评估） | 基于软件对患者的伤害 |
| 软件要求 | 较宽松 | 严格（覆盖率、工具置信度等） | 非常严格（100%语句/分支覆盖） |
| 硬件要求 | 详细（失效率、冗余等） | 详细（PMHF、SPFM、LFM） | 较少（主要依赖软件） |
| 生命周期 | 完整（概念到退役） | 完整（概念到退役） | 完整（但更聚焦开发阶段） |
| 认证难度 | 中等（需要行业解读） | 高（细节多、要求严） | 高（软件测试要求苛刻） |
2.5 我的建议：怎么选？
如果你刚接触功能安全，我建议从IEC 61508开始。它是基础，理解了它，其他标准就很容易上手。
如果你做汽车电子，直接学ISO 26262。别浪费时间在IEC 61508上，除非你想了解历史渊源。
如果你做医疗设备软件，IEC 62304是必修课。但要注意，很多医疗设备也包含硬件，所以你可能还需要参考IEC 60601（医疗设备通用安全标准）。
一个小技巧：在实际项目中，我经常把三个标准结合起来用。比如做汽车ADAS的软件部分，我会用ISO 26262的框架，但软件测试的覆盖率要求会参考IEC 62304。为什么？因为ISO 26262对软件测试的要求虽然严格，但不如IEC 62304那么「死板」。而医疗设备软件对bug的零容忍态度，其实对汽车软件也有借鉴意义。
好了，这一章就到这里。下一章我会讲怎么从零开始写系统级安全需求。到时候我会用一个实际案例来演示，保证你听完就能上手。