简介：IEC 61508-1:2010《电气/电子/可编程电子安全相关系统的功能安全 第1部分：一般要求》是功能安全领域的基础性国际标准，面向汽车电子、工业控制、轨道交通等行业的系统工程师、安全评估人员及合规认证从业者。该标准确立了E/E/PE安全相关系统的总体框架，涵盖风险评估、安全生命周期管理、系统架构设计、可靠性分析、软件开发质量保证、验证与确认、变更管理、人员资质及文档记录等通用要求，并作为基本安全出版物指导各产品与应用领域标准的制定。资源为高清可复制PDF，非扫描版，共1个文件，压缩包约2.11MB，便于检索引用与二次编辑。目前已有616人学习下载，适合需要深入理解功能安全通用要求、开展安全完整性等级评估或准备认证审核的读者参考使用。
1. 功能安全不是把东西做可靠：IEC 61508-1 真正在管什么
很多人第一次翻 IEC 61508-1 会失望：它几乎不告诉你任何具体电路怎么画、代码怎么写。它反复出现的是生命周期、管理、文档、评估、验证。于是有人得出结论——这是一份流程文件，跟技术无关。这个结论恰好反了。IEC 61508-1 之所以看起来“不谈技术”，是因为它要解决的不是某个器件可不可靠，而是一个更棘手的问题：当安全依赖于电气/电子/可编程电子系统时，我们凭什么相信它在该动作时一定动作、不该动作时一定不动作？可靠性只是其中一个变量，而且不是最根本的那个。真正难的是把“安全”从一句愿望，变成可分解、可分配、可验证、可追溯的工程对象。Part 1 就是这套对象体系的定义层，后面 Part 2 到 Part 7 才是硬件、软件、方法、术语的具体展开。搞懂 Part 1，等于拿到了整套功能安全方法论的坐标系；跳过它直接看 Part 2 的失效率数字，很容易把安全做成堆冗余的玄学。
2. 整体安全生命周期：为什么标准要强行规定“先做什么后做什么”
2.1 生命周期不是流程装饰，是风险传递的轨道
IEC 61508-1 第 7 章给出了一张贯穿始终的图——整体安全生命周期（Overall Safety Lifecycle）。从概念、整体范围定义、危害与风险分析，到整体安全要求、要求分配、各阶段计划、E/E/PE 实现、安装调试、整体安全确认、运行维护修理、修改改造，直到退役处置，最后用验证（Verification）和功能安全评估（Functional Safety Assessment）两条横切线贯穿。很多人把它当成一张“项目阶段图”，这是误读。它的本质是一条风险传递轨道：危害分析产出的风险，被翻译成安全要求；安全要求被分配到 E/E/PE 系统、其他风险降低措施、外部设施三类载体上；每一类载体再向下分解到子系统和组件；每一层分解都必须能反向追溯回最初的危害。没有这条轨道，风险在传递过程中会不断“蒸发”——设计者只看到自己那一小块要求，没人能回答“这个要求是从哪个危害来的、漏了会怎样”。
标准把生命周期写成强制顺序，是因为顺序本身携带信息。危害与风险分析必须在整体安全要求之前，整体安全要求必须在分配之前，分配必须在实现之前。一旦顺序被打乱，比如先选型再补风险分析，风险分析就会退化成给已有方案找理由，安全完整性等级（SIL）也会被“凑”出来。常见的实现思路是：把每个生命周期阶段定义成有明确输入、输出、验证活动的盒子，前一阶段的输出是后一阶段的输入，验证活动检查这个输入是否完整、是否正确。这样任何阶段的遗漏都会在下一阶段的入口被拦住，而不是等到现场出事才暴露。
2.2 三条并行的生命周期：整体、E/E/PE 系统、软件
图 2、图 3、图 4 分别给出整体安全生命周期、实现阶段的 E/E/PE 系统安全生命周期、软件安全生命周期。三者不是替代关系，而是嵌套关系。整体生命周期管的是“整个安全功能从生到死”；E/E/PE 系统生命周期管的是“实现阶段里，E/E/PE 这部分怎么从要求变成实物”；软件生命周期再嵌套在 E/E/PE 系统生命周期内部，管“软件这部分怎么从要求变成可执行代码”。这种嵌套设计解决了一个现实问题：一个安全功能往往同时由传感器、逻辑控制器、执行器、软件、外部风险降低措施共同承担，如果只用一个生命周期，责任边界会糊成一团。拆成三层后，每一层都有自己的要求规格、自己的验证、自己的评估，层与层之间通过“安全要求分配”这个动作衔接。
我一般会这么理解这三层的关系：整体生命周期是总账，E/E/PE 系统生命周期是明细账，软件生命周期是明细账里的一个科目。总账要求“这个安全功能要达到 SIL 2”，明细账把它拆成“传感器子系统 SIL 2、逻辑子系统 SIL 2、执行器子系统 SIL 2”，软件科目再把它拆成“软件安全要求、软件架构、软件单元”。任何一层对不上，追溯链就断了。标准第 7.6 节专门讲整体安全要求分配，就是这条追溯链最关键的接口。
2.3 验证与功能安全评估：两条横切线为什么不能合并
生命周期图上有两条横切线：验证（7.18）和功能安全评估（第 8 章）。很多人分不清，觉得都是“检查”。区别在于：验证是阶段性的、由执行活动的人或同团队的人做，检查“这一阶段的输出是否符合它的输入要求”；功能安全评估是全局性的、由独立于项目团队的人做，检查“整个安全功能是否达到了所要求的 SIL”。验证回答“做对了没有”，评估回答“做的是不是对的事”。标准要求评估人员的独立性随 SIL 升高而提高，SIL 1 可以是同公司不同部门，SIL 3 以上往往要求独立组织。这个独立性梯度不是官僚主义，而是因为越高的 SIL 意味着越低的允许失效概率，内部人越容易对自己的设计产生盲区。把验证和评估合并，等于让运动员给自己当裁判，追溯链上的系统性错误就没人能发现了。
3. 安全完整性等级 SIL：一个数字背后到底约束了什么
3.1 SIL 不是可靠性指标，是风险降低的目标
SIL（Safety Integrity Level）在 Part 1 里被定义为安全功能的一种离散等级，用于规定安全完整性要求。它分 SIL 1 到 SIL 4，数字越高，要求的安全完整性越高。这里最容易翻车的地方是把它当成“可靠性等级”。可靠性高不等于安全完整性高。一个设备可以平均无故障时间很长，但如果它的失效模式是“该动作时不动作”且没有诊断覆盖，它的安全完整性可能很低。SIL 约束的是安全功能在要求时失效的概率（低要求模式）或每小时危险失效概率（高要求模式），而不是笼统的“不容易坏”。Part 1 第 7.5 节要求整体安全要求必须为每个安全功能指定 SIL，这个 SIL 是从危害与风险分析里推出来的，不是选出来的。
常见的实现思路是：先做危害与风险分析，用风险图或类似方法确定每个安全功能需要的风险降低量，再把这个降低量映射到 SIL。映射过程要考虑风险后果的严重程度、暴露在危险中的频率和持续时间、避免危险的可能性。这三个参数共同决定目标 SIL。所以同一个安全功能，在不同应用场景下可能要求不同的 SIL。把 SIL 当成产品固有属性去宣传，是典型的误用。
3.2 低要求模式与高要求模式：两种失效概率口径
Part 1 明确区分低要求模式和高要求模式。低要求模式指安全功能被要求的频率不大于每年一次、也不大于两倍检验测试频率；高要求模式指要求频率高于这个界限，或连续运行。两种模式下，SIL 对应的目标失效概率口径不同：低要求模式看“要求时失效概率”（PFD），高要求模式看“每小时危险失效概率”（PFH）。这个区分不是学术洁癖，它直接影响架构设计。低要求模式下，检验测试周期是控制 PFD 的关键杠杆，因为很多危险失效只有在检验测试时才能暴露；高要求模式下，诊断覆盖率和在线检测变得更重要，因为系统没有“空闲”时间让你定期体检。如果搞错模式，用低要求模式的架构去套高要求场景，或者反过来，算出来的 SIL 就是纸面上的。
3.3 安全要求规格：SIL 必须落到可验证的语句
SIL 定下来之后，必须写进安全要求规格（Safety Requirements Specification）。Part 1 第 7.10 节专门讲 E/E/PE 系统安全要求规格，要求它包含安全功能描述、SIL、安全状态、失效模式、诊断要求、检验测试周期等。这里的关键是“可验证”。写“系统应安全可靠”不是安全要求，写“当检测到超速信号超过阈值持续 100 ms 时，系统应在 200 ms 内切断动力输出，且该功能的 SIL 为 2”才是。可验证意味着每一条要求都能对应到一个测试或分析活动。标准反复强调文档和追溯，本质上是为了让每一条安全要求都能被验证，而不是为了留痕而留痕。
4. 危害与风险分析：整条链路的起点为什么不能外包
4.1 危害分析的质量决定后面所有工作的上限
Part 1 第 7.4 节把危害与风险分析放在整体安全要求之前，逻辑很直白：不知道危险从哪来，就不知道要防什么。这一步的质量直接决定后面所有工作的上限。如果危害分析漏了一个危险场景，后面再严谨的 SIL 分配、再冗余的架构、再完整的验证，都防不住那个被漏掉的场景。常见的实现思路是：用多种分析技术交叉验证，比如初步危害分析（PHA）先扫一遍，再用失效模式与影响分析（FMEA）或危害与可操作性分析（HAZOP）深挖，最后用风险图或定量方法定 SIL。单一方法容易有盲区，交叉验证能提高覆盖率。这一步不能外包给不熟悉工艺的人，因为危害往往藏在工艺细节里，不在标准条款里。
4.2 风险降低的分配：E/E/PE 不是唯一手段
第 7.6 节讲整体安全要求分配，核心思想是：风险降低不一定要全部由 E/E/PE 系统承担。其他风险降低措施（比如机械防护、泄压装置、管理程序）和外部风险降低设施也可以分担。分配时要考虑每种措施能降低多少风险、它的可靠性如何、它和 E/E/PE 系统之间是否有共因失效。共因失效是这里最容易被忽略的坑：如果机械防护和 E/E/PE 系统共用同一个电源，电源一挂两个一起失效，那它们就不是独立的，分配时不能简单相加。标准要求分配结果必须形成文档，并且可追溯回危害分析。这个文档就是后面 E/E/PE 系统安全要求规格的输入。
4.3 从风险到 SIL：映射过程要留可审查的痕迹
风险分析产出的是风险等级，SIL 是安全完整性等级，两者之间需要一个映射。Part 1 没有强制规定映射方法，但要求映射过程可审查。常见的做法是用风险图：把后果严重度、暴露频率、避免可能性三个维度画成图，每个格子对应一个 SIL 或“不需要 E/E/PE 安全功能”。风险图的好处是直观、可复现，不同人用同一张图应该得到相近结果。坏处是粒度粗，边界情况容易有争议。定量方法（比如层保护分析 LOPA）粒度细，但需要更多数据。无论用哪种，关键是留下可审查的痕迹：为什么这个危害定这个 SIL，依据是什么，谁评审的。没有痕迹，SIL 就成了拍脑袋的数字，后面所有验证都失去基准。
5. 避坑与排查：功能安全落地时最容易翻车的几个地方
5.1 把 SIL 当产品标签，先选型后补分析
现象：项目一开始就选定了某个号称“SIL 3 认证”的控制器，然后倒推风险分析，让分析结果刚好匹配这个选型。原因：把 SIL 当成了产品固有属性，而不是安全功能的目标要求。解决：先做危害与风险分析，定出每个安全功能的目标 SIL，再根据目标 SIL 去选型或设计。选型时看的是“这个组件在目标架构下能否支撑所需 SIL”，而不是“它有没有 SIL 证书”。证书只说明组件本身的能力，不说明它用在这个安全功能里是否合适。
5.2 生命周期阶段顺序被打乱，验证活动形同虚设
现象：设计做完了才补安全要求规格，验证活动变成“对照已有设计写符合性说明”。原因：把生命周期当成文档模板，而不是风险传递轨道。解决：强制每个阶段的输出作为下一阶段的输入，验证活动检查输入完整性。如果发现某个阶段的输入不完整，停下来补，不要带着缺口往下走。缺口不会自己消失，只会在后面放大。
5.3 低要求模式和高要求模式混用，失效概率算错
现象：一个连续运行的安全功能，却用低要求模式的 PFD 来证明 SIL。原因：没区分安全功能被要求的频率，或者没注意检验测试周期和运行模式的关系。解决：先确定安全功能是低要求还是高要求模式，再选对应的失效概率口径。低要求模式看 PFD，高要求模式看 PFH。如果拿不准，按更严格的口径算，并在文档里说明理由。
5.4 共因失效没识别，冗余设计变成纸面冗余
现象：设计了双通道冗余，但两个通道共用同一个电源和同一个时钟，电源一挂全挂。原因：只做了架构上的冗余，没做共因失效分析。解决：在分配安全要求时，识别冗余通道之间的共因因素，比如共用电源、共用时钟、共用通信总线、同一制造批次、同一维护人员。对识别出的共因因素，要么消除，要么量化其影响，要么增加多样性。没有共因分析的冗余，只是增加了成本，没有增加安全完整性。
5.5 功能安全评估独立性不足，系统性错误没人发现
现象：功能安全评估由项目组内部人员做，评估结论全是“符合”。原因：独立性不够，评估人员对设计有先入为主的认同，或者有进度压力。解决：按目标 SIL 确定评估独立性要求，SIL 越高，评估人员越要独立于项目团队。评估不是走过场，要能提出“这个要求从哪个危害来”“这个诊断覆盖率怎么证明”这类追溯性问题。如果评估人员回答不了，说明追溯链有断点。
6. 文档、管理与评估：为什么“软”要求才是功能安全的硬骨头
6.1 文档不是交付物，是追溯链的物理载体
Part 1 第 5 章专门讲文档，要求功能安全相关的文档必须包含哪些信息、由谁编制、由谁评审、如何修改。很多人把文档当成项目结束时要交的一堆纸，这是误解。文档是追溯链的物理载体。危害分析、安全要求、分配结果、验证记录、评估报告，这些文档串起来，才能回答“这个安全功能为什么是这个 SIL”“这个诊断为什么够用”“这个修改为什么没引入新风险”。没有文档，追溯链只存在于人的脑子里，人一换就断了。标准要求文档在安全生命周期内持续维护，修改要受控，就是因为追溯链是活的，不是一次性的。
6.2 功能安全管理：把安全当成一个可管理的对象
第 6 章讲功能安全管理，要求建立功能安全管理体系，明确职责、能力、沟通、变更管理、评估安排。这一章看起来最“软”，但恰恰是功能安全能不能落地的分水岭。技术措施再到位，如果没人负责、没人评审、变更没人控制，安全完整性会在日常运维中慢慢流失。常见的实现思路是：指定功能安全经理，建立安全计划，把每个生命周期阶段的活动、责任人、输出、验证方式写清楚，定期审查。安全计划不是摆设，它是把标准要求映射到具体项目的桥梁。没有安全计划，标准条款就只是一堆抽象要求，落不到具体活动上。
6.3 人员能力与变更管理：两个最容易被低估的变量
Part 1 要求参与功能安全活动的人员具备必要的能力，并且要求对安全相关系统的修改进行严格控制。这两个要求经常被低估。人员能力不是看学历或证书，而是看是否理解所负责活动的原理和风险。一个没做过危害分析的人，即使有证书，也可能漏掉关键场景。变更管理不是走审批流程，而是评估变更对安全完整性的影响。一个看似无关的软件补丁，可能改变诊断时序，进而影响诊断覆盖率。变更管理要能识别这种影响，并决定是否需要重新验证或重新评估。这两个变量管不好，前面所有技术工作都可能被慢慢侵蚀。
6.4 整体安全确认：最后一道关口为什么不能省
第 7.14 节讲整体安全确认，要求在安装调试完成后、正式运行前，对整体安全功能进行确认，证明它达到了安全要求规格。这一步不能省，也不能用组件测试代替。组件测试证明每个组件符合自己的规格，整体安全确认证明整个安全功能在实际运行环境下符合整体安全要求。实际运行环境可能带来组件测试覆盖不到的因素，比如温度、振动、电磁干扰、操作习惯。整体安全确认要把这些因素考虑进去，用实际或模拟的实际工况验证。确认通过后，才能进入运行阶段。跳过这一步，等于把风险留到现场。
7. 从 Part 1 到落地：怎么用这份标准而不被它淹没
IEC 61508-1 是基本安全出版物，它的定位是给产品和应用部门标准提供框架。这意味着它故意写得抽象，把具体技术细节留给下游标准。用它的正确姿势不是逐条对照打勾，而是把它当成一套思考工具：危害分析时用它提醒自己覆盖全生命周期，分配要求时用它提醒自己考虑共因失效，设计架构时用它提醒自己区分低要求和高要求模式，做评估时用它提醒自己保持独立性。我一般会这么理解：Part 1 定义的是“问题空间”，Part 2 到 Part 7 定义的是“解决方案空间”。先搞清楚问题空间，再去找解决方案，顺序不能反。
一个实用的验证方法是：拿一个你正在做的安全功能，试着回答四个问题。第一，这个安全功能对应的危害是什么，从哪份分析文档来？第二，它的目标 SIL 是多少，怎么推出来的？第三，这个 SIL 被分配到了哪些载体上，E/E/PE 承担了多少，其他措施承担了多少，它们之间有没有共因？第四，怎么证明它达到了目标 SIL，验证和评估的记录在哪？四个问题都能答上来，说明追溯链是完整的；有一个答不上来，那个地方就是需要补的缺口。这个方法不需要额外工具，但能快速暴露功能安全落地中最常见的断点。
设计取舍上，IEC 61508-1 选择用生命周期和文档来约束过程，而不是直接规定技术方案，是因为安全相关系统的应用场景太分散，统一的技术方案会要么过严要么过松。用过程约束换取适用性，代价是执行成本高、对人员能力要求高。这个取舍是否值得，取决于应用的风险等级和监管要求。对于高风险场景，过程约束带来的追溯能力是值得的；对于低风险场景，全套生命周期可能过重，可以裁剪，但裁剪要有依据并记录。标准本身也允许裁剪，前提是能证明裁剪不影响安全完整性。
从那以后我每次接触功能安全项目，都强制先走一遍危害分析到 SIL 分配的追溯链，再去看具体技术方案。追溯链不通，技术方案再漂亮也不敢用。希望帮到你。
本文还有配套的精品资源，点击获取
