简介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 目标失效量的经典分段SILPFH 目标区间每小时危险失效概率SIL 1≥ 1E-6 且 1E-5SIL 2≥ 1E-7 且 1E-6SIL 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(f60% 诊断覆盖率后 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 3SFF 通常需要达到 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 完整性自检再谈选型与量化计算效果比直接翻条款好得多。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/25 8:53:21 · 阅读 1.2k IEC 62061功能安全标准解析：从SIL到PFH的量化设计与落地避坑
简介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 目标失效量的经典分段SILPFH 目标区间每小时危险失效概率SIL 1≥ 1E-6 且 1E-5SIL 2≥ 1E-7 且 1E-6SIL 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(f60% 诊断覆盖率后 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 3SFF 通常需要达到 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 完整性自检再谈选型与量化计算效果比直接翻条款好得多。希望帮到你。本文还有配套的精品资源点击获取