企业官网建设流程全解析

简介：ISO/TR 22100-1:2021技术报告是机械安全领域的关键参考资料，面向机械设计师、制造商、安全工程师及认证审查人员，系统阐明ISO 12100作为A类基础标准与B类、C类通用/专用标准之间的层级关系与应用逻辑，帮助读者解决“何时选用哪类标准、如何组合实施”的现实问题。该文件为单个完整英文版PDF，共21页，体积仅1.21MB，便于跨设备阅读、检索与标注。报告依次覆盖范围、规范性引用、术语定义，以及机械安全标准体系的总体结构，重点介绍ISO 12100如何为B1、B2与C类标准提供基础框架；同时说明各标准在风险评估、风险减小、安全设计与验证中的角色与交互，并探讨标准间的互补性，指导如何根据具体机械或应用场景灵活选择最合适的标准。对参与机械设计、生产、检查和认证的专业人士而言，该报告既是理解国际标准体系的实用指南，也是开展合规性评估的重要依据。目前已有102人学习/下载，适合机械安全标准化从业者及中高级工程师作为案头参考。

1. 一份21页的技术报告，如何决定你机器的合规结论

做出口设备的人大概都遇到过这个场景：安全审核员问你“这台机器的C类标准依据是什么”，你翻遍手头标准清单，发现只有ISO 12100和几个Type-B标准可用。对方摇摇头，在审核记录上写下一句“未识别相关C类标准”。你当然知道ISO 12100是风险评估的底法，但问题在于：它没有给出任何具体的数值要求——安全距离取多少、光栅响应时间多快、控制回路需要什么性能等级，全都需要其他标准来补。ISO/TR 22100-1:2021这份只有21页的技术报告，解决的就是“ISO 12100这台总纲，如何通过Type-B和Type-C标准逐级落地”的问题。

它不是设计指南，也没有告诉你某个参数取多少。它更像一张地图，标注了A类、B类、C类标准之间的引用路径、优先级和冲突处理规则。读懂它，你才能回答审核员那句最刁钻的追问：“你凭什么认为这套标准组合覆盖了这台机器的全部重大危险？”本文按“原理→实现→流程→验证”的顺序，把这21页背后的工程判断拆开讲清楚。

2. 从ISO 12100到Type-B/C：标准之间的责任分配逻辑

2.1 为什么ISO 12100做不了“唯一依据”

ISO 12100是A类标准，即基础安全标准。它定义了一套通用的风险评估与风险降低流程：确定机器限制、识别危险、估计风险、评价风险、降低风险，然后迭代。每个环节都有方法论指导，但它刻意不给出量化指标。原因很简单：一台注塑机和一台木工数控铣床的夹伤风险、粉尘爆炸风险、切削液飞溅风险差别太大，A类标准不可能统一规定。

这一点在设计院里经常被误解。很多机械工程师觉得“我按ISO 12100做了风险评估，标准合规就完成了”。实际上ISO 12100的条款大量使用“应”“宜”这种模糊措辞，比如“应通过设计消除危险”——但没有数值。真正可验证的量化要求分布在Type-B和Type-C标准里。审核员和认证机构看的不是你有没有风险评估报告，而是你的风险降低措施是否落实到具体标准条款。ISO/TR 22100-1:2021存在的意义，就是把这条“从原则到数值”的链路用一张图说清楚。

2.2 标准的三层金字塔如何分派责任

整个机械安全标准体系呈金字塔形。顶层是A类（ISO 12100），中间是Type-B类，底部是Type-C类。Type-B再细分为B1和B2：B1是通用安全要求，比如EN ISO 13849-1（控制系统安全相关部件PL等级）、IEC 62061（安全相关电气控制系统SIL等级）、EN IEC 60204-1（机械电气设备通用安全要求）；B2是通用防护要求，比如ISO 13857（安全距离）、ISO 13855（防护装置定位）、ISO 14120（固定式和活动式防护装置设计与制造）。

责任分配遵循一条原则：越往下越具体。ISO 12100第6.2条要求“本质安全设计措施优先”，但什么是本质安全设计，落实到具体场景必须靠Type-B和Type-C给出定义。而Type-B标准本身也有取舍问题——ISO 13857管距离，ISO 13855管响应时间，两者同时适用时哪个优先？ISO/TR 22100-1给了一个决策树逻辑：有Type-C标准时优先用Type-C；没有Type-C时，防护距离类问题优先看Type-B2，控制性能类问题优先看Type-B1；当某个具体危险没有任何标准覆盖时，才用ISO 12100的原则做工程判断。

2.2.1 标准矩阵的前身：条款归属表

把ISO 12100的目录摊开，可以看到很多条款并没有规定“由谁承接”。我在项目里习惯先做一张“条款归属表”，把所有可能涉及的危险映射到承接方。下面是一个可运行的最小示例：

from collections import defaultdict iso12100_clauses = { "5.3": ("确定机器限制", "designer", "设计者结合规格书自行判断"), "5.4": ("危险识别", "b2", "优先查Type-B2的防护清单"), "5.5": ("风险估计", "b1", "控制回路的PLr评估依赖Type-B1"), "6.2": ("本质安全设计", "designer", "几何形状、材料选择等设计输入"), "6.3": ("安全防护", "b2", "护罩尺寸和距离按Type-B2"), "6.4": ("使用信息", "designer", "警示标志、说明书等交付物"), } def build_assignment_table(clause_map): table = [] for num, (title, owner, reason) in clause_map.items(): table.append(f"ISO 12100-{num} | {title} | {owner} | {reason}") return table for row in build_assignment_table(iso12100_clauses): print(row)

这个脚本把ISO 12100的关键章节映射到三个承接方：designer（设计者判断）、b1（Type-B1）、b2（Type-B2）。输出结果是下一步写标准矩阵的原料。它的作用不是自动化判断，而是强迫你在项目启动前就思考每个章节“谁来负责落地、拿什么标准来验证”。参数说明：clause_map的键是ISO 12100条款号，值是一个三元组；当你遇到ISO 12100里某个章节写不出来承接方时，就等于提前暴露了标准缺口。

提示：ISR/TR 22100-1真正想纠正的误区是“标准越多越安全”。当多个B类标准同时适用时，冲突几乎是必然的，比如某防护门同时涉及ISO 14120（结构强度）和ISO 13857（安全距离），正确的处理是先看有没有Type-C，再看是防护问题还是控制问题。

2.3 避免标准堆砌：从“都有”到“够用”

很多设计院的安全文档列了十几项标准，看着很全，实际上互相之间没有逻辑关联。ISO/TR 22100-1把这种状态叫“引用但没有集成”。审核员拿到一份标准清单，会逐个追问：这条标准覆盖了哪个危险源？它在你的设计里对应哪个具体措施？如果你的清单回答不了这两个问题，那就是标准堆砌。

用条款归属表的方式，你在列标准时就必须逐条对应到ISO 12100的章节，形成“风险→标准条款→设计措施→验证方法”的链。这听起来繁琐，但本质上就是把ISO 12100当成数据库主表，把B类和C类标准当成子表，用外键关联起来。第4章会展示这个映射在实际C类标准里长什么样。

3. Type-B标准的选型：B1与B2如何协同而不是竞争

3.1 分清“控制类”和“防护类”是选型的第一步

工程上最常见的错误是拿到Type-B标准列表后随机排列组合。实际上只分两类：B1管控制系统和电气安全，B2管物理防护和距离。做一个简单的对比表即可区分：

B1和B2的关系不是排他，而是互补。一个典型场景是安全光栅：光栅本身的安装距离按ISO 13855计算（B2），但光栅接入控制回路的PL等级按EN ISO 13849-1核算（B1）。缺了B2，光栅可能装得太近导致停机距离不足；缺了B1，光栅信号即使触发了也可能无法可靠断停。

3.2 冲突处理：当B1和B2的结论打架时

出现冲突最常见的形式有两种：防护距离够了但控制回路性能不足；控制性能很高但物理防护距离不够。ISO/TR 22100-1给出的解决思路很明确：不能简单取两者中的高值，而要回到风险本身重新判断。

比如一台冲压机，B2标准算出来安全距离需要500mm，但设备布局只能提供350mm。这时把PL等级从PLc提到PLe并不能直接补足距离缺口，因为两者防范的危险源不同。正确的做法是：要么重新布局提供距离，要么增加额外的防护结构（如后围栏），要么重新评估风险等级。我习惯的处理方式是把这类冲突写进“偏离记录”，给出替代措施并在风险评估矩阵中重新打分，然后提交技术评审签字。

建议用下列方式记录冲突决策：

3.3 沿着Type-B标准向上找齐C类的路径

一台设备往往涉及多个危险源，每个危险源对应不同的Type-B组合。比如一台自动化包装线：机器人上下料区域按ISO 10218-1（Type-C）执行，但机器人夹具的气动回路安全按EN ISO 13849-1（Type-B1）评估，输送带防护罩按ISO 14120（Type-B2）设计。

在缺乏Type-C标准覆盖的领域，标准矩阵就是这组组合的载体。下一章将从Type-C标准的内部结构出发，说明其如何逐条引用ISO 12100的条款，以及当引用不清楚时如何回到B类/A类兜底。

4. Type-C标准如何引用ISO 12100：条款映射与缺口识别

4.1 Type-C标准的骨架结构

一本典型的Type-C标准（如ISO 10218-1机器人安全、ISO 16090-1机床安全）在章节编排上有相对固定的套路：范围声明、规范性引用文件、术语定义、重大危险清单、安全要求和措施、验证方法、使用信息。其中关键在“范围声明”和“重大危险清单”。

范围声明决定一台机器是否落在该C类标准覆盖范围内。审核员首先看的就是：你的机器类型、额定参数是否在范围内，是否有排除条款。比如某个C类标准明确写了“不适用于额定功率小于XX的机器”，你的设备如果低于该阈值，就直接失去了引用资格。这一步需要对机器工作原理的理解足够深——不能因为产品名称相近就套用，很可能存在的工艺差异导致数据参数完全不同。

4.2 用脚本生成条款映射表

拿到一本C类标准后，第一步是绘制“C类标准条款 ↔ ISO 12100条款”的双向映射。这个工作手工做也不难，但在标准版本升级或批量评估多个C类标准时，脚本明显更可靠：

import csv # C类标准中的重大危险清单与对应ISO 12100条款 c_standard_risks = [ ("5.2.1", "机械危险：挤压", "5.4", "危险识别"), ("5.2.2", "机械危险：剪切", "5.4", "危险识别"), ("5.3.1", "控制失效", "6.2.5", "本质安全设计-控制"), ("5.4.1", "防护装置缺失", "6.3.2", "防护装置要求"), ("5.4.2", "防护距离不足", "6.3.2", "防护装置要求"), ] def build_mapping(risk_list, iso12100_refs): mapping = [] for c_clause, hazard, iso_ref, iso_desc in risk_list: matched = [(r[0], r[1]) for r in iso12100_refs if r[0] == iso_ref] if matched: mapping.append((c_clause, hazard, iso_ref, iso_desc, "已映射")) else: mapping.append((c_clause, hazard, iso_ref, "未找到对应条款", "缺口")) return mapping iso12100_refs = [ ("5.4", "危险识别"), ("6.2.5", "本质安全设计-控制"), ("6.3.2", "防护装置要求"), ] rows = build_mapping(c_standard_risks, iso12100_refs) for r in rows: print("\t".join(r)) # 同时输出CSV供评审使用 with open("mapping_result.csv", "w", newline="", encoding="utf-8") as f: writer = csv.writer(f) writer.writerow(["C标准条款", "危险", "ISO 12100条款", "ISO描述", "状态"]) writer.writerows(rows)

执行后会得到一个映射表，其中“缺口”状态表示该C类标准条款没有在ISO 12100里找到明确的对应来源。有两种可能：一是C类标准自行提出了更高的要求（这是允许的）；二是C类标准漏写了引用，此时需要人工介入确认是否补引用Type-B标准。参数说明：c_standard_risks中的第四列是ISO 12100条款号，与iso12100_refs的键匹配；匹配成功就标记“已映射”，否则标记“缺口”。CSV导出是为了让评审会议可以直接打开文件逐条过，不需要另做转录。

4.3 当C类标准明说“本条款不适用”

C类标准中经常出现“本条款不适用于XX工况”或某章节标注“不适用”。这一般说明该C类标准作者未覆盖某特定工况，而不是这个危险不存在。TR 22100-1的实践意图是：不适用出现在条款层面时，要回到ISO 12100重新评估该工况，必要时引用Type-B标准补上。

比如某C类标准对固定式护罩的要求不适用于“需频繁清理的料斗区域”，此时应回到ISO 12100第6.3条，借助ISO 14120选用带联锁的可移动护罩，并按ISO 13857重算安全距离。工程上把这个过程称作“C类标准缺口回退”。

4.4 反向追溯：从C类标准回到机器设计

映射表建好以后，真正面向设计的形态是“每个危险都指向具体条款值”。比如ISO 10218-1里的某个条款要求“机器人末端执行器配备防护装置”，具体哪种防护装置要看ISO 14120和ISO 13857。下一章要讨论的是：这些映射关系如何整合进从概念到交付的整个开发流程，而不仅仅停留在合规文档里。

5. 机械开发流程中的标准矩阵：把风险映射变成设计输入

5.1 从BOM和功能列表生成标准矩阵

标准矩阵不是安全文档，它是设计输入的一部分。我见过很多企业内部把安全标准管理归档成一份独立表格，工程师画图时根本不会去翻——这种文档再全也没有用。标准矩阵的正确做法是把它跟BOM或功能列表对齐，让标准成为零件和功能的一张属性表。

具体字段设计可以这样规划：

有了这个结构，标准矩阵就能跟BOM建立对应关系。物料清单上的某个护罩零件，对应到标准矩阵里的一行或多行；标准里某个定量参数变更，可以直接影响BOM中的选型甚至订单成本。

5.2 多角色评审：谁维护、谁确认、谁签字

标准矩阵贯穿了概念设计、详细设计、装配调试、验收四个阶段，职责至少涉及四个角色。

矩阵评审建议按“设计变更→矩阵修订→各方会签”的节奏走，特别是当设计变更导致安全距离或性能等级变化时，不更新矩阵就等于合规链条断裂。我通常把标准矩阵挂在PLM系统的“安全特性”对象上，同一部件设计改版时矩阵跟着升版，这样审核时可以打印出一张“设计版本↔标准矩阵版本”的对应表。

5.3 从标准矩阵到安全需求规格的转化

标准矩阵是表格，工程师需要的是可以签入图纸的需求。解决方式是把矩阵行转成安全需求条目，写入需求管理工具或设计规格书。例如：

matrix_items = [ {"id": "FN-0032", "hazard": "夹伤", "std": "ISO 13855", "param": "距离≥500mm"}, {"id": "FN-0105", "hazard": "电击", "std": "EN IEC 60204-1", "param": "防护等级IP54"}, ] def generate_safety_requirements(items): for idx, item in enumerate(items, 1): print(f"SR-{idx:03d} [来源: {item['std']}] {item['hazard']}: {item['param']}") print(f" 验收标准: 设计/测量/测试证明满足 {item['param']}") generate_safety_requirements(matrix_items)

输出的是带有编号的可追踪安全需求条目，每条都标注了引用自哪条标准及验收标准。这样到试制阶段，每个需求都可以转化为具体的检查项。

提示：标准矩阵最容易垮掉的地方是“剩一行没人认领”。每个部件ID必须有一个明确的责任人，否则矩阵形同虚设。

5.4 标准矩阵在电气与机械交接处的边界

机械工程师负责的物理防护在矩阵里体现为距离、尺寸、材质；电气工程师负责的控制回路体现为PL/SIL等级、安全逻辑、响应时间。两者在同一行里往往有强耦合，比如光栅安装在250mm处，意味着光栅信号必须在50ms内切断动力，这两个参数分别来自B2和B1，但必须同时验证。矩阵中的“验证方法”字段最好写成联合验证，不要分开测。断开两套标准协作关系是审核时最容易暴露的不符合项。

6. 验证与证据链：用条款倒查法确认标准矩阵完整性

6.1 构建可审计的证据链

矩阵里的条目最终都要变成证据，否则矩阵只是纸面推演。按“标准矩阵→测试记录→审核结论”的顺序组织证据链，审核员才能从任意一条标准追踪到具体测试报告。推荐的证据链形式：

工程做法是每完成一项验证，就把报告编号填入矩阵对应行的“验证状态”字段，并附上文件路径。这样月底汇总时，打开矩阵就能看到哪些条目已完成、哪些还欠证据。

6.2 条款倒查法：从矩阵反查标准覆盖完整性

标准矩阵的常规检查是“标准→设计→验证”的正向追踪，但更高效的检查是倒查：对每台机器，列出一条条危险事件，再逐一反查矩阵里是否有对应的标准条款和设计措施。

步骤如下：

1. 列出全部危险事件（挤压、剪切、触电、高温、噪音等）。
2. 对每个危险事件问一个问题：“哪个标准条款要求我控制这件事？”
3. 如果找到了对应条款，继续检查是否有明确的定量参数和对应的设计措施。
4. 如果找不到对应条款，写出偏离原因和替代措施。

这个方法能快速找出矩阵中的空行。很多项目里“高频噪音超过85dB”这种危险源经常没有对应标准条款，因为大家都在电器安全上花了很多精力，噪音反而被遗漏了。通过倒查，这类空白会立刻暴露。

6.3 矩阵关闭的最终判据

矩阵中每一项的最终状态只有两种：已关闭或带偏离关闭。已关闭意味着“标准条款→设计措施→验证记录”三点连线完整。带偏离关闭需要有书面审批记录，说明为什么偏离、用什么替代方案、残余风险是否被接受。

我在项目收尾时还会做一次抽样复核，随机挑选约10%的已关闭条目，重新查阅原始设计记录和测试报告，确认不是“纸面关闭”。毕竟矩阵本身是人工维护的，只有验证记录才能证明它真正闭环了。

本文还有配套的精品资源，点击获取