简介：IEC 62061:2021是国际电工委员会发布的机械安全领域功能安全核心标准，面向机械制造商、控制系统设计人员及安全评估工程师，用于指导安全相关电气、电子和可编程控制系统（SRP/CS）的功能安全设计与验证。这份高清英文版PDF共1个文件，压缩包大小7.03MB，便于打印存档或电子阅读。标准第二版系统规定了SRP/CS从需求分析、设计、实施到运行、维护及退役的完整生命周期要求，涵盖危险与风险分析、安全完整性等级（SIL）评定、硬件与软件开发、验证和确认等关键环节，并引入FMEA、FTA等故障分析技术，同时强调文件记录、人员资格与培训等管理要素。读者可获取完整英文原版条款，便于对照标准要求开展机械安全评估与功能安全认证准备。目前已有209人学习，适合从事机械安全、功能安全认证及工业自动化控制的人员研读与实践参考。
1. IEC 62061-2021：为什么功能安全从"评审结论"变成了一堆能算的数字
IEC 62061-2021 英文原版把机械安全里的"功能安全"从一个评审结论变成了一套可以计算、可以验证、可以争论的数字。第二版发布于 2021 年 3 月，相比第一版最大的变化，是明确把 SIL（安全完整性等级）目标挂在 PFH（每小时危险失效概率）这个物理量上：你的安全回路到底有多安全，不再靠"选了几个安全继电器"这种直觉来判断，而是靠失效率、诊断覆盖率、架构约束算出来。这份标准专门写给安全相关电气、电子和可编程电子控制系统，也就是机器制造商口中常说的 SRP/CS。搞懂这条链路，你再看它的目录时，就不再是"查条款"，而是顺着一条设计主线往下走：识别风险，翻译成需求，算 PFH，再验证实现。
2. 安全生命周期与子系统分解：标准为什么先管流程，再管电路
2.1 功能安全计划与配置管理：防止"改坏"的底层机制
IEC 62061 的第 4 章讲的是 SCS 的设计过程和功能安全管理，许多工程师会直接跳过这一章去看 SIL 计算，但这一章恰恰决定了后面所有数字是否可信。标准要求先建立功能安全计划，把需求分析、设计、实施、验证、确认这些阶段的活动、责任人和交付物排进一条时间线。目的不是增加文档工作量，而是让"安全论证"这件事可以被追溯：审核员拿到你的安全档案时，能顺着计划找到每一份证据。人员资格、培训、经验这些管理要素也被写进标准，因为一个不会做失效模式分析的工程师，可以把任何流程做成形式主义。
配置管理和修改控制放在 4.4 和 4.5。这里的底层动机是防止"改坏"：安全系统最危险的时刻不是初次设计，而是几年后的电气改造、换料、改程序时，有人悄悄改变了一个安全参数。标准要求任何修改都触发"影响分析 → 重算 PFH → 回归验证"的闭环，而不是只做一次常规测试。常见的实现思路是把安全相关项和非安全相关项分开管理，安全相关项的每一条变更都要走一遍完整评估。跳过这一步的典型后果是：设备验收时一切正常，半年后安全功能在某个边缘工况下失效，而谁都说不清是哪次改动引入了它，安全档案彻底变成一个黑匣子。
2.2 子系统自顶向下分解：SRP/CS 从设备到安全回路的切法
标准第 6 章引入子系统（subsystem）概念，这是理解整份标准的骨架。一个安全相关控制系统不是单台设备，而是一条从检测到响应再到执行的信号链。标准要求采用自顶向下的分解：先把一个安全功能拆成若干子功能，再给每个子功能分配子系统——典型是输入子系统、逻辑子系统、输出子系统三段式。每个子系统还能继续分解为子系统元素，比如传感器、比较器、接触器主触点。6.3.4 节还专门讲到"预设计子系统"的复用：采购来的安全模块本身可能已评估过 SIL 能力，但你必须确认它的失效数据、使用环境限制和你这条安全回路匹配，不能把模块认证直接等同于系统认证。
这种"先分再合"的设计方法背后是计算逻辑：整条安全回路的 PFH 不是由性能最好的那个元件决定，而是由各子系统按结构组合出来的。如果是串联架构，危险失效率近似相加，最薄弱的那一段直接拖累整体；如果是带冗余的架构，又要处理共因失效项。所以标准不允许把某个"安全等级高"的模块直接装进系统就说系统达标——它只给了你一个子系统能力的上限，最终 SIL 还得由整体架构和量化结果决定。
2.3 安全需求规格 SRS：把风险目标翻译成可验证的条目
5.2 节对安全需求规格的要求，核心是三块：功能需求规格、需求模式估计、安全完整性需求规格。功能需求要写的是"安全状态是什么、响应时间多长、之后如何复位"，不是产品功能列表。很多项目翻车就翻在这里：SRS 写成了"支持急停、支持门锁、支持双手启动"这种功能清单，却没有"急停按下后，电机必须在 200ms 内进入安全转矩关断状态"这样可验证的语句。
需求模式是关键判断项：安全功能是按需触发（比如安全门开关，一年触发不了几次），还是持续或高频工作（比如安全力矩限制，每次启动都在运行）。这个判断直接决定后续 SIL 参数的取法，高频连续任务如果按低需求设计，PFH 目标就选错了档。安全完整性需求规格则要写明目标 SIL、目标 PFH 上限，以及分配在各子系统上的完整性要求。SRS 是后续验证与确认的基准，基准本身模糊，验证做得再多也无法证明安全。这三部分本质上是一条递进的翻译链：风险分析结论 → 功能需求 → 完整性需求 → 可验证指标。
3. SIL 与 PFH：功能安全量化的核心计算机制
3.1 需求模式先行：先判断安全功能"多久被叫一次"
IEC 62061 沿用了 IEC 61508 的 SIL 概念，SIL 1 到 SIL 4，等级越高要求越严。机械安全领域通常只用到 SIL 3，因为 SIL 4 对应的 PFH 目标对常规工业器件来说几乎无法经济地实现。SIL 不是自评出来的，它由两部分约束构成：一是随机硬件失效的量化结果，二是系统性安全完整性——也就是架构、软件过程、故障控制这些"软约束"。
注意，不要把"多久发生一次安全事故"和"安全功能多久被要求执行一次"搞混。低需求模式的经典定义是安全功能每年被要求的次数不超过一次，超过这个频次就要按高需求或连续模式评估。低需求模式看的是按需失效概率，需要结合测试间隔求平均；高需求或连续模式看的是每小时危险失效概率 PFH。单位不同、物理意义不同，但都换算成"危险失效导致风险不可接受"。下面是高需求或连续模式下 SIL 与 PFH 目标失效量的经典分段：
| SIL | PFH 目标区间（每小时危险失效概率） |
|---|---|
| SIL 1 | ≥ 1E-6 且 < 1E-5 |
| SIL 2 | ≥ 1E-7 且 < 1E-6 |
| SIL 3 | ≥ 1E-8 且 < 1E-7 |
提示：这张表给出的是目标区间边界，机械应用中通常以 SIL 3 封顶，实际目标可以比表中更严格，但不能更宽松。
PFH 的物理含义是"系统每小时发生危险失效的平均概率"。它不像 MTBF 那样是"多久坏一次"的平均预期，而是把失效按安全失效与危险失效分开后，只统计会直接导致安全功能丢失的那一部分。很多元件手册只给总失效率，不给危险失效率，这正是后面避坑章节里最常见的问题来源。
3.2 PFH 估算：从元件失效率到每小时危险失效概率
7.6 节给出了 PFH 的估算路径。最常规的做法是先对每个子系统元素做失效模式分析，得到危险失效率 λ_du，也就是危险失效且未被诊断覆盖的那一部分，再根据子系统架构组合。拿最简单的 1oo1 单通道结构来说，PFH 近似等于 λ_du；如果通道内部有诊断功能，被诊断测到的危险失效 λ_dd 在失效后可以触发系统进入安全状态，所以真正进入 PFH 的只有 λ_du。这也是为什么同样一个传感器，配上诊断逻辑后系统的 SIL 能力能明显上移。
下面用一个近似模型演示单通道在有无诊断时的区别：
# 简化 PFH 估算演示：单通道 vs 带诊断单通道 lambda_danger = 1.0e-6 # 总危险失效率，单位 1/h dc = 0.6 # 诊断覆盖率 60% lambda_du = lambda_danger * (1 - dc) # 未被诊断覆盖的危险失效 lambda_dd = lambda_danger * dc # 被诊断覆盖，失效后可进安全状态 pfh_1oo1 = lambda_danger # 无诊断：所有危险失效都计入 pfh_1oo1_diag = lambda_du # 有诊断：只剩未覆盖的部分 print(f"无诊断 PFH = {pfh_1oo1:.2e}/h") print(f"60% 诊断覆盖率后 PFH = {pfh_1oo1_diag:.2e}/h")这个例子不是标准给出的精确公式，而是理解标准精神的最小模型：诊断覆盖率 DC 是后面 SFF 计算的核心输入，也是设计阶段最容易通过增删诊断措施来调整的杠杆。标准真正要求的是把每个元素的失效数据、诊断措施、共因评估都写进安全档案，而不是只给最终 PFH 数字——审核时看不到过程，数字就只是一行没有证据的断言。λ_du 和 λ_dd 的划分必须建立在失效模式与影响分析（FMEA）基础上，配合故障树分析（FTA）把"哪个失效会致命"拆清楚，而不是拍脑袋定一个比例。
3.3 架构约束与 SFF：为什么高 SIL 不能靠堆高可靠元件
到这里会出现标准里最反直觉的一条规则：即使你把 PFH 算到了 SIL 3 区间，系统依然可能拿不到 SIL 3 的完整性声明，因为还有一道"架构约束"关卡。7.4 节要求先估算安全失效分数 SFF，再据此限制子系统能达到的最高 SIL。SFF 的定义是安全失效与被诊断覆盖失效之和占全部失效的比例，它衡量的是子系统对自己失效行为的感知与处理能力：
SFF = (安全失效率 + 被诊断覆盖的危险失效率) / 总失效率
一个单通道子系统，SFF 低于 60% 时，架构约束通常只到 SIL 1；就算单个元件失效率低到惊人，也一样受限。要做到 SIL 3，SFF 通常需要达到 90% 以上，且硬件故障裕度要足够——要么冗余，要么高诊断。同时标准 7.5 节列出的基本子系统架构，比如 1oo1、1oo2、2oo2，每种结构都有对应的 PFH 组合规则和诊断需求，不能随意套用。
我一般会这么理解这条约束：它防止了一种懒惰设计，即用一个极可靠的元件单通道扛起高风险场景。一旦这个"极高可靠"假设里混入共因失效、系统性缺陷、误用等因素，整个安全论证就塌了。SFF 和硬件故障裕度的组合，强制设计者用冗余、诊断、多样性去承担不确定性。由此引出下一章要拆的内容：故障诊断与共因失效，它们正是 SFF 和冗余结构能成立的前提。
4. 故障诊断、共因失效与周期测试：另一半安全完整性的实现
4.1 故障考虑与故障排除：哪些失效可以"不算数"
7.3.3 节是标准里争议最多、也最容易被滥用的部分：故障考虑与故障排除。标准并不要求把所有失效都纳入量化模型，有些失效如果物理上不可能发生，或通过设计手段可以彻底排除，可以声明为故障排除，不进入 PFH 计算。典型的例子：传感器引线被正确固定且布线通道有防护，那么"引线因外部机械应力断开"可以被合理地排除。
这条机制的设计动机是控制成本：如果每个物理上不现实的失效都要算进冗余结构，系统复杂度会爆炸。但它对使用者有一个隐含要求——故障排除必须给出理由，且理由要经得起审核。最常见的翻车方式是拿"概率很低"当"物理上不可能"。一个继电器触点因磨损而粘连，不是物理上不可能，只是概率低，把它排除掉就等于把最常见的安全事故模式赶出了模型。标准本意是配合 FMEA 和 FTA 把故障集合收敛到"合理可预见"的范围内，而不是靠排除条款凑出好看的 PFH。
4.2 共因失效 CCF 简化估算：冗余为什么同时失效
冗余是提升 PFH 的主要手段，但冗余结构有一个天然的敌人——共因失效。两个传感器用同一个电源、同一根线束、同一块板上的同一批次元件，某一种环境扰动，比如电网浪涌、温度冲击、电磁干扰，可能让它们同时失效。标准在 7.6.3 给出了简化方法：通过一组抗 CCF 措施打分，达到分数后允许在 PFH 模型中取一个较低的共因因子，否则就证明不了"冗余是真的冗余"。
常见的措施列表包括：物理分离、通道间电气隔离、元件与软件多样性、对共同时钟或电源的独立保护、以及能探测两通道不一致的诊断。每项措施按强度给分，总分超过阈值才允许共因因子取低档位。这种做法的实质是：冗余的随机失效收益可以用概率公式算，但系统性失效只会被设计措施压掉，无法被公式算掉——CCF 评分表就是那套"把设计质量折算进概率模型"的接口。这一段是标准里最像工程实践的机制，因为它逼着设计者把"理论上冗余"和"实际上独立"两件事对齐。
4.3 周期性测试：低需求安全功能的时间衰减
6.9 节关于周期性测试的要求，往往被低估。低需求模式下，按需失效概率是在两次测试之间累积的：第一次测试后故障清零，之后危险失效慢慢积累，到下次测试前达到峰值。测试间隔拉长，平均失效概率就抬高，这就是时间衰减效应的来源。标准要求对安全功能的测试做计划，明确测试间隔、测试覆盖率和可接受的测试盲区，本质上是在说：安全完整性不是设计时的一次快照，而是需要持续维护的东西。
常见实现思路是依据 PFH 预算倒推测试周期：把安全功能允许的失效概率预算按测试间隔均摊，再检查现有诊断覆盖是否满足。若诊断覆盖不够，就只能缩短人工测试周期，或增加在线诊断。血泪经验是很多项目把测试计划写成了"开机自检加年度例行维护"，没有覆盖那些平时不动作的安全路径，结果隐患在验收后的第一次真实需求下才暴露出来。这种翻车比计算错误更难追责，因为测试记录上每一栏都打了勾。
5. 避坑指南：IEC 62061 落地时最常见的五个坑
5.1 三个量化与架构上的坑
第一条，失效数据张冠李戴。现象：安全档案里写的 PFH 来自元件手册的总失效率，甚至直接从 MTBF 换算。原因：总失效率包含安全失效和不影响安全功能的失效，与危险失效率是两个概念；用 MTBF 换算还混入了定期维修后恢复的假设。解决：必须按失效模式拆分，明确安全失效率、被诊断覆盖的危险失效率和未被覆盖的危险失效率三者各自的值，PFH 计算只允许使用危险失效部分。
第二条，故障排除被当成"不用算"的橡皮擦。现象：一些团队把检测不到、维修困难的失效统统放进故障排除清单，冗余结构越省越薄。原因：混淆了"物理上不可能"和"工程上不划算"。解决：每个排除项写一条成立理由，按标准要求评估合理可预见性；审核时被追问一条就补一条，直到理由站不住为止。补不出来的那一项，回到模型里去。
第三条，SIL 目标与架构约束脱节。现象：PFH 算出来到 SIL 3，但子系统是单通道、SFF 不足，最终评估结果只到 SIL 2。原因：只看了随机失效量化，忽略了 SFF 与硬件故障裕度对最高 SIL 的限制。解决：先按 7.4 做架构约束判断，再回头优化诊断设计与冗余结构，而不是在最后阶段才发现限制。
5.2 两个流程与验证上的坑
第四条，SRS 只写了功能，没写安全状态。现象：需求文档一页纸，写了"防护门打开时停止运行"，但没有安全状态定义、响应时间、复位方式、测试间隔。原因：把安全需求规格当产品说明书写。解决：按 5.2 的三段式——功能需求、需求模式、完整性需求——逐项填写，让每一句需求都能被某个验证活动对应上。
第五条，软件验证只做功能测试。现象：软件反复测了功能正常，但集成到安全回路后整体失效；手动参数化配置改了一个阈值，没人知道它会影响哪个 SIL 参数。原因：忽视了软件等级对应的验证深度，以及基于软件的手动参数化本身也是一个安全相关过程。解决：按软件安全生命周期做模块级、集成级、系统级的分层验证，参数化工具与配置流程纳入验证范围，改参数走变更管理而不是顺手改。
提示：避坑的核心不是记住条款，而是重新检查安全论证的每一环是否有证据支撑。没有证据的 PFH，和没有校准的仪表一样，只能当估计值使用。
6. 软件等级与参数化：标准留给实现者的窄门
6.1 软件等级划分：SIL 如何映射到开发严格度
第 8 章把软件按承担安全功能的强度划分等级，等级越高，软件安全生命周期要求越严：从需求到模块设计再到编码，每一层都要有对应的验证。软件不能像硬件那样靠"冗余一个副本"提升可靠性，因为副本带有同样的系统性缺陷。所以标准的应对不是堆冗余，而是堆过程质量——结构化设计、评审、测试覆盖，用开发严格度对抗软件固有的系统性失效。这一点和硬件的量化思路完全不同。
6.2 基于软件的手动参数化：为什么工具也要验证
6.7 节专门处理靠软件配置参数的场景，比如通过上位机修改安全相关参数。风险在于：错误参数可能在运行时安静地降低安全完整性，而系统诊断认为一切正常。标准要求对参数化工具本身做验证，并确保参数值在传输、存储、运行时都不会被误改。常见实现思路是参数校验和、双重确认、把参数版本纳入配置管理，同时参考 6.8 安全方面的要求，防止未授权修改通过调试接口进入系统。这一点容易被当成工具问题跳过，但它直接决定安全参数是否可信。
6.3 与 IEC 61508 的配合：把标准用活的取舍
IEC 62061 本质上是 IEC 61508 在机械安全领域的行业裁剪：61508 给出通用框架，62061 把它落到机械的子系统架构和软件实现上。实际项目中，元件层的失效数据往往要回溯 61508 的方法论，而安全功能的验收逻辑以 62061 为主。遇到新器件、新架构时，我一般会回到 61508 的概念层去核对需求模式、系统性能力和 SIL 分解这些基础概念，避免在 62061 的条款细节里迷路。
我最早把这份标准读成考试大纲时，总觉得 PFH、SFF、CCF 是一堆相互独立的计算题；后来做完一个被审核打回三次的模拟项目 X，才意识到它们是一条证据链的环节——从危险识别到需求模式，到失效率拆分，到诊断与共因控制，再到软件验证，每一步都服务于同一个问题：这个安全功能失效时，后果我们算过没有。从那以后，我每次做安全相关控制系统的评审，都会强制先走一遍需求模式判断和 SRS 完整性自检，再谈选型与量化计算，效果比直接翻条款好得多。希望帮到你。
本文还有配套的精品资源，点击获取
