
简介ISO 13849-1:2015 是国际标准化组织发布的机械安全领域核心标准英文原版全称为《机械安全——控制系统安全相关部分——第1部分设计通用原则》共93页面向机械设计工程师、安全认证人员、自动化设备制造商及高校相关专业师生用于指导控制系统安全相关部分的设计、验证与风险评估。资源为PDF格式单文件压缩包约27.02MB内容完整涵盖前言、范围、规范性引用文件、术语定义与符号缩略语、设计考虑等章节并深入阐述安全功能、平均故障间隔时间、诊断覆盖率、性能等级PL与安全完整性等级SIL等关键概念以及风险评估、冗余设计、架构选型与验证方法。目前已有145人学习下载。该标准第三版为现行有效版本可帮助读者系统掌握从设计到实施的安全准则理解不同架构系统如何满足安全要求是从事机械设备设计、制造、维护与认证工作的重要参考依据。1. 安全回路设计为什么总在验收时翻车一台包装机在出厂验收时连续运行了七十二小时没出任何故障到客户现场第三周安全门被频繁触发后突然失效——继电器触点粘死了。事后复盘发现设计阶段只算了平均危险失效时间却没考虑触点粘连这种共因失效。ISO 13849-1 就是解决这类问题的它不只看单个元件坏不坏而是看整个安全功能在架构上能不能扛住故障累积。这份标准的核心产出是性能等级PL从 PLa 到 PLe 五档对应每小时危险失效概率的倒数区间。机械安全、自动化产线、协作机器人、电梯控制只要涉及安全相关控制系统都绕不开它。适合谁读做电气设计的、写安全 PLC 程序的、负责 CE 认证的以及被客户问过“你这个回路到底能不能达到 PLd”的人。下面按“先算清楚、再搭出来、最后验得过”的顺序拆。2. 从风险图到 PL 等级参数怎么定才不返工2.1 风险图的三个输入量到底怎么取值ISO 13849-1 附录 A 给了一张风险图三个轴分别是伤害严重度 S、暴露频率 F、可避免性 P。S 只有两档S1 轻微通常指可恢复的擦伤、淤青S2 严重不可逆伤害或死亡。F 两档F1 暴露频率低且时间短F2 频繁或持续暴露。P 两档P1 在特定条件下可能避免P2 几乎不可能避免。取值时最容易翻车的是 F 和 P 的边界。我一般会问三个问题操作工每班次接触危险区域超过一次吗接触时是否必须伸手进入危险区有没有防呆工装或双手操作装置如果三个答案分别是“是、是、没有”那 F2P2 基本跑不掉。反过来如果只是调试时偶尔打开防护门且有钥匙开关管控F1P1 才成立。注意S 的取值不要按“最坏情况”拍脑袋要看实际伤害类型。冲压机合模区域取 S2 没争议但一台贴标机的胶带滚轮即使夹到手指也极少造成不可逆伤害取 S1 更合理。取高了会导致 PL 要求虚高成本翻倍。2.2 从 PL 反推架构类别和 MTTFd风险图输出的是 PLr所需性能等级。接下来要选架构类别Category B、1、2、3、4和计算 MTTFd平均危险失效时间。这两者是耦合的Category 3 要求双通道且覆盖 60% 的诊断覆盖率Category 4 要求双通道且累积失效前必须检测到。一个典型计算流程# ISO 13849-1 简化 MTTFd 计算示例 # 假设单通道由三个元件串联急停按钮、安全继电器、接触器 # 每个元件的 MTTFd 来自厂家数据或附录 C 查表 mttf_components { 急停按钮: 100000, # 单位小时B10d200000每天操作2次 安全继电器: 500000, 接触器: 150000 } # 串联系统 MTTFd 倒数相加 inv_sum sum(1/m for m in mttf_components.values()) mttf_system 1 / inv_sum print(f单通道 MTTFd {mttf_system:.0f} 小时) # 查表MTTFd 分档 # 3年~10年 低10~30年 中30~100年 高 years mttf_system / (24*365) print(f折合 {years:.1f} 年)逻辑说明串联系统的危险失效时间按倒数相加因为任何一个元件失效都会导致安全功能丧失。参数说明B10d 是元件在 10% 失效前的操作次数厂家数据手册里通常给出。如果查不到附录 C 有典型值表但用表值时要留余量。MTTFd 分档后结合 Category 和 DC诊断覆盖率查附录 K 的表得到实际 PL。2.3 诊断覆盖率 DC 不是越高越好DC 分四档无DCavg 60%、低60%~90%、中90%~99%、高≥99%。Category 3 要求 DCavg 至少 60%Category 4 要求高。但 DC 不是随便填的每个诊断措施对应一个覆盖率值比如诊断措施典型 DC周期测试脉冲90%触点反馈监控99%逻辑监控双通道比较99%无诊断0%如果回路里只有急停按钮的常闭触点串联没有脉冲测试或反馈DC 就是 0Category 3 不成立。很多设计在这里翻车图纸上画了双通道但两个通道共用同一个电源模块共因失效没算实际还是 Category 2 的水平。3. 用 SISTEMA 把安全回路算到可交付3.1 建一个最小可用的 SISTEMA 项目SISTEMA 是德国 IFA 出的免费工具做 ISO 13849-1 计算绕不开。新建项目后先建子系统SB再在子系统下建通道Kanal。一个急停回路的典型结构项目包装机安全门监控 └── 子系统 SB1安全门开关 ├── 通道 1门开关触点 1 → 安全继电器输入 1 └── 通道 2门开关触点 2 → 安全继电器输入 2 └── 子系统 SB2接触器反馈 ├── 通道 1接触器辅助触点 → 安全继电器反馈输入每个元件填 MTTFd、B10d、DC、CCF共因失效。CCF 是一张打分表满分 100达到 65 分才能用 Category 3 或 4。打分项包括分离不同物理位置、多样性不同技术、经验同类型用了多久、环境温湿度防护等。3.2 参数填错时 SISTEMA 会怎么报常见报错和含义“MTTFd 超出范围”填了 0 或负数或者单位选错小时 vs 年。“CCF 分数不足”双通道设计但分离、多样性、经验三项都没得分总分低于 65。“PL 低于 PLr”算出来的 PL 不满足风险图要求需要加诊断或换更高 MTTFd 的元件。我一般会先跑一遍“最坏情况”所有 DC 填 0CCF 填 0看 PL 掉到多少。如果掉到 PLc 以下说明架构本身有问题不是靠调参数能救的。然后再逐项加诊断措施看 PL 怎么爬升。这个过程比直接填“理想值”有用得多因为你能知道哪个诊断措施贡献最大。3.3 导出报告前必须检查的三个数SISTEMA 能导出 PDF 报告但直接导会漏掉一些关键信息。导出前手动核对每个子系统的 MTTFd 是否取整到分档值。比如算出 28 年分档是“中”10~30年报告里要写“中”不能写 28 年。DCavg 是否按加权平均算。如果子系统里有多个元件DC 不同要按 MTTFd 加权不是简单平均。CCF 打分表是否附在报告后。认证机构会查这张表没有的话会被打回。提示SISTEMA 的项目文件是 .sistema 格式建议和电气图纸一起归档。改版时不要覆盖旧文件新建版本号否则追溯时说不清。4. 避坑安全回路设计里最容易翻车的五件事4.1 现象双通道回路验收时被判为单通道原因两个通道的输入信号来自同一个 PLC 的相邻输出点或者共用同一根多芯电缆。共因失效没被识别CCF 打分低于 65。解决通道间物理分离——不同电缆、不同接插件、不同电源。如果做不到至少用不同品牌的元件并在 CCF 表里如实填写“多样性”得分。不要为了凑分虚报。4.2 现象MTTFd 算出来很高但现场故障率明显偏高原因用了厂家给的“典型值”而不是“B10d 实测值”。典型值通常是在实验室理想条件下测的现场有粉尘、振动、温度循环实际寿命可能只有一半。解决关键元件急停按钮、安全继电器、接触器优先用有 B10d 实测数据的型号。查不到就按附录 C 的保守值取并在设计文档里注明“待实测数据更新后复核”。4.3 现象Category 4 回路在单点故障时仍然失效原因Category 4 要求“累积失效前检测”但诊断测试周期设得太长。比如接触器反馈监控每 24 小时才测一次如果接触器在两次测试之间粘连安全功能就丢了。解决诊断测试周期必须小于危险失效的累积时间。对于高频操作的安全门测试周期建议不超过 1 小时或者改用连续脉冲测试。4.4 现象安全 PLC 的看门狗和 ISO 13849-1 的 DC 对不上原因安全 PLC 的看门狗能检测 CPU 失效但标准里的 DC 是针对“安全功能通道”的诊断覆盖率。看门狗算不算 DC取决于它是否覆盖了从输入到输出的完整链路。解决查安全 PLC 的功能安全手册看厂家声明的 DC 值。如果手册里没写默认按 0 算然后外加独立的诊断措施如输出反馈。4.5 现象验证测试只测了正常功能没测故障注入原因验收时只按了急停按钮看机器停不停。但标准要求验证“故障情况下的响应”比如断开一个通道的线看系统是否进入安全状态。解决验证清单里必须包含单通道断线、交叉短路、触点粘连模拟、电源跌落。每项测试记录实际响应时间和状态。这份记录是 CE 认证的技术文件之一不能省。5. 把 PL 验证做成可复用的检查表5.1 用 Python 批量核对 B10d 和操作频率现场设备多的时候手动算 MTTFd 容易漏。我一般写个小脚本从 CSV 读元件清单自动算每个子系统的 MTTFd 和 PLimport csv # 输入 CSV 格式子系统,元件,B10d,每天操作次数,DC # 输出每个子系统的 MTTFd 和分档 def calc_mttfd(b10d, ops_per_day): B10d 转 MTTFd小时 if ops_per_day 0: return float(inf) # MTTFd B10d / (0.1 * 每天操作次数 * 365 * 24) return b10d / (0.1 * ops_per_day * 365 * 24) def mttfd_bucket(mttfd_hours): years mttfd_hours / (24 * 365) if years 3: return 低 elif years 10: return 中低 elif years 30: return 中 elif years 100: return 高 else: return 超高 with open(components.csv, newline) as f: reader csv.DictReader(f) subsystems {} for row in reader: sub row[子系统] mttfd calc_mttfd(float(row[B10d]), float(row[每天操作次数])) if sub not in subsystems: subsystems[sub] [] subsystems[sub].append(mttfd) for sub, mttfds in subsystems.items(): inv_sum sum(1/m for m in mttfds if m 0) if inv_sum 0: print(f{sub}: 无有效数据) continue sys_mttfd 1 / inv_sum print(f{sub}: MTTFd{sys_mttfd:.0f}h, 分档{mttfd_bucket(sys_mttfd)})逻辑说明B10d 是 10% 失效前的操作次数除以 0.1 得到平均失效前操作次数再除以每天操作次数和 365×24得到小时数。参数说明每天操作次数要按最忙班次算不要取平均值。如果某个元件是持续通电的如安全继电器线圈操作次数按“每次断电再上电”算不是按小时算。5.2 验证报告里必须出现的四个数不管用 SISTEMA 还是手算最终报告里这四个数缺一不可项目含义常见错误PLr风险图输出的所需等级取高了浪费成本取低了过不了认证PL实际达到的等级没算 CCF 或 DC 虚高MTTFd每个子系统的平均危险失效时间单位混用年 vs 小时DCavg诊断覆盖率加权平均简单平均而非按 MTTFd 加权5.3 一个我常犯的错误早期做安全回路时我总想把 PL 算得“刚好达标”觉得这样成本最优。后来发现认证机构会留余量审查如果 PL 刚好卡在边界比如 PLd 要求 10^-7你算出 1.1×10^-7他们会要求你提供更多证据。现在我一般会留一档余量要求 PLd 的按 PLe 的架构去设计但报告里写 PLd。多出来的成本主要是诊断措施和元件选型但省掉了反复整改的时间。这个习惯让我在三个项目上避免了验收延期。希望帮到你。本文还有配套的精品资源点击获取