企业官网建设流程全解析

简介：这份文档是 ISO 3691-4-2020 表1「安全回路 PL 要求」的中文翻译整理，面向叉车与工业车辆安全控制系统的设计、认证及功能安全工程师，帮助读者快速理解标准对安全功能最低性能等级（PL）的约束。内容围绕刹车系统、速度控制、速度监测、ESPE 安全检测区域、自动充电、负载搬运、转向、稳定性、急停、人员检测系统以及自动/手动/维修模式等条款展开，逐项列出安全功能描述、主要风险备注与最低 PL 要求，并标注了 d、c、b 等不同等级及 0.3m/s、0.7m/s 等速度限值条件。资源包为 1 个 docx 文件，约 27KB，以表格化条款对照形式呈现，便于按分项条款检索与对照原文。目前已有 343 人学习下载，适合需要将标准要求落地到安全回路设计、PL 评估与合规审查的读者参考使用。

1. ISO 3691-4 表1 安全回路PL要求：一份被低估的翻译活

做无人叉车或AGV功能安全的同行，大概率都经历过这个场景：项目要过CE认证，公告机构发来一份差异表，指着ISO 3691-4:2020的Table 1问“你们每个安全功能的PL等级是怎么定的”。你翻出标准原文，发现表1只有几列缩写和数字，没有解释、没有推导过程，甚至连“PL”和“安全回路”之间的对应关系都要自己去ISO 13849-1里翻。更麻烦的是，这份标准目前没有官方中文版本，团队里做电气、做软件、做整机认证的人各看各的，理解经常对不上。这篇笔记就是把我自己翻译和落地表1的过程拆开讲清楚：表1到底在要求什么、每个安全功能对应的PL怎么查、翻译时哪些词不能随便翻、以及怎么把这张表变成能直接写进安全需求规格书的东西。适合正在做无人车辆安全回路设计、准备认证材料、或者需要把标准要求转成工程语言的人。

2. 表1到底在说什么：从安全功能到PL等级的映射逻辑

2.1 表1的结构拆解：四列信息各管什么

ISO 3691-4:2020的Table 1标题是“Safety functions and required performance levels”，核心就四列：安全功能描述、对应条款、所需PL等级、以及备注。第一列列出的是无人驾驶工业车辆在运行中必须实现的各项安全功能，比如“行驶速度限制”“人员检测与避让”“紧急停止”“制动系统监控”等。第二列指向标准正文里对该功能的具体要求条款。第三列是这张表最核心的信息——每个安全功能对应的PL等级，从PL a到PL e不等。第四列备注里偶尔会写一些特殊条件，比如“仅适用于特定运行模式”或“与车辆类型有关”。

翻译这张表最容易翻车的地方，是把第一列的功能描述当成通用术语直接译。实际上每个功能名称在标准正文里都有严格定义，翻译时必须和正文条款对照，否则会出现“翻译对了词、翻错了义”的情况。比如“speed control”和“speed limitation”在表1里是两个不同的安全功能，对应不同的PL等级，如果都译成“速度控制”，下游做安全需求分解的人就会懵。

2.2 PL等级不是拍脑袋定的：ISO 13849-1的输入参数

表1里每个安全功能后面标的PL等级，不是标准编写组随便填的。它的底层逻辑来自ISO 13849-1的风险评估方法：先确定每个安全功能的所需性能等级（PLr），再通过架构类别（Category）、平均危险失效时间（MTTFd）、诊断覆盖率（DC）和共因失效（CCF）四个参数来验证实际达到的PL是否满足PLr。

表1直接给出了PLr，相当于帮你省掉了风险评估的第一步。但这里有个坑：表1给的是最低要求，实际设计中你可以做更高，但不能做更低。而且PL等级和Category不是一回事，PL d可以通过Category 3实现，也可以通过Category 4实现，成本和复杂度差别很大。翻译时如果只翻出“PL d”三个字，不把背后的Category和MTTFd要求一起交代，电气工程师按PL d去选器件时很可能选错架构。

2.3 翻译前必须锁定的三个术语基准

在动手翻译表1之前，我一般会先锁定三个术语的译法，不然后面会反复改。第一个是“safety function”，统一译“安全功能”，不译“安全机能”或“安全函数”。第二个是“performance level”，统一译“性能等级”，缩写保留PL，不译“表现水平”。第三个是“detection”，在人员检测场景译“检测”，在故障检测场景译“诊断”或“探测”，要根据上下文区分。

这三个词定下来之后，表1里其他术语的翻译就有了锚点。比如“muting”译“屏蔽”，“enabling device”译“使能装置”，“limited speed”译“受限速度”。这些译法不是唯一的，但必须在项目内部统一，否则同一份认证材料里出现两种译法，公告机构会直接开不符合项。

3. 把表1翻译成可执行的安全需求：步骤与参数落地

3.1 从PDF到可编辑表格：提取与对齐的实操

标准原文是PDF，表1跨了两页，直接复制会乱。我一般用Python的pdfplumber做提取，再手工对齐。下面这段代码是把表1所在页的表格抽出来存成CSV的最小示例：

import pdfplumber import csv # 打开标准PDF，定位到表1所在页码 # 页码需要根据实际PDF调整，这里假设表1在第23和24页 with pdfplumber.open("ISO_3691-4_2020.pdf") as pdf: all_rows = [] for page_num in [22, 23]: # 0-indexed page = pdf.pages[page_num] # extract_table会自动识别表格线，无框线表格需要调参数 table = page.extract_table({ "vertical_strategy": "text", "horizontal_strategy": "text" }) if table: for row in table: # 过滤空行和页眉重复行 if any(cell and cell.strip() for cell in row): all_rows.append(row) # 写入CSV，方便后续逐行翻译和标注 with open("table1_raw.csv", "w", newline="", encoding="utf-8") as f: writer = csv.writer(f) writer.writerows(all_rows) print(f"提取到 {len(all_rows)} 行")

这段代码的关键在extract_table的参数。ISO标准PDF的表格经常没有完整框线，用默认参数会漏行。vertical_strategy设为text表示按文字位置推断列边界，horizontal_strategy同理。如果提取结果仍然错位，可以改用lines策略并手动指定explicit_vertical_lines。提取完不要直接机翻，先人工核对每一行的功能名称和PL等级是否对应正确，因为PDF跨页时表头可能重复，导致数据行错位。

3.2 逐行翻译的检查清单：功能名、条款号、PL值

提取出原始表格后，逐行翻译时我固定检查三件事。第一，功能名称是否和标准正文的条款标题一致。比如表1里写“Personnel detection”，正文第4.5.2条的标题可能是“Detection of persons in the path of travel”，翻译时要统一成“行驶路径内人员检测”，不能简写成“人员检测”。第二，条款号是否准确。表1第二列可能只写“4.5.2”，但正文里该条款可能有多个子条款，翻译时要标注完整路径，比如“4.5.2.3”。第三，PL值是否抄对。PL b和PL c在PDF里容易看混，尤其是扫描版，建议放大到200%逐字核对。

下面是一个翻译后的行示例，用表格呈现：

这张表翻译完后，不要直接发给电气团队。先让做风险评估的人确认PL等级和条款对应关系，再让做安全回路设计的人确认PL d是否可以通过现有架构实现。两个角色都签字后，这张表才能作为安全需求规格书的输入。

3.3 把PL要求转成安全回路参数：Category、MTTFd、DC怎么填

表1只给PL，不给Category。实际做安全回路设计时，需要根据PL反推Category和MTTFd。ISO 13849-1附录里有一张对照表，但工程上常用的简化规则是：PL c通常用Category 1或2，PL d用Category 3，PL e用Category 4。但这不是绝对的，Category 3加高DC也可以做到PL e。

下面这段Python代码是根据PL等级和Category反查所需MTTFd范围的简化实现，用于快速筛选安全继电器和传感器：

# PL与Category、MTTFd的简化对照 # 数据来源：ISO 13849-1 Table 6的简化归纳 # 实际认证时必须以标准原文和SISTEMA计算结果为准 pl_requirements = { "PL c": { "Cat 1": {"MTTFd": (30, 100), "DC": "无"}, "Cat 2": {"MTTFd": (30, 100), "DC": "低"}, }, "PL d": { "Cat 3": {"MTTFd": (30, 100), "DC": "中"}, "Cat 4": {"MTTFd": (30, 100), "DC": "高"}, }, "PL e": { "Cat 4": {"MTTFd": (30, 100), "DC": "高"}, } } def check_pl(pl, category, mttfd, dc): """检查给定参数是否满足PL要求""" req = pl_requirements.get(pl, {}).get(category) if not req: return f"{pl} 无法通过 {category} 实现" low, high = req["MTTFd"] if not (low <= mttfd <= high): return f"MTTFd {mttfd} 年不在 {low}-{high} 年范围内" if dc != req["DC"]: return f"DC 需要 {req['DC']}，当前为 {dc}" return f"满足 {pl} 要求" # 示例：PL d，Category 3，MTTFd 50年，DC中 print(check_pl("PL d", "Cat 3", 50, "中")) # 输出：满足 PL d 要求

这段代码的用途是在选型阶段快速排除明显不满足的组合。比如你选了一个Category 2的安全继电器，想做到PL d，代码会直接告诉你“PL d 无法通过 Cat 2 实现”。但要注意，MTTFd的范围是简化值，实际计算要用SISTEMA或类似工具，把每个子系统的MTTFd、DC、CCF都输进去，才能得出最终PL。翻译表1时如果能把这一层对应关系也标注出来，下游做安全回路设计的人会省很多沟通成本。

4. 翻译和落地过程中最容易踩的五个坑

4.1 把PL等级当成Category等级用

现象：电气工程师看到表1写PL d，直接选了一个Category 4的安全模块，成本翻倍。原因：PL和Category是两个维度，PL d可以用Category 3实现，不一定非要Category 4。解决：在翻译表1时加一列备注，写明“PL d可通过Cat 3+DC中实现”，并附上ISO 13849-1的对照表页码。

4.2 功能名称翻译不一致导致需求遗漏

现象：表1译成“人员检测”，正文译成“行人识别”，安全需求规格书里两个词都出现，评审时被质疑漏了一个功能。原因：翻译时没有建立术语表，不同人翻不同章节。解决：翻译前先做一份术语对照表，所有参与翻译的人共用，表1里的功能名称必须和正文条款标题逐字对应。

4.3 忽略备注列的特殊条件

现象：表1某行备注写“仅适用于自动模式”，翻译时漏了，结果手动模式下也按PL d设计，增加了不必要的成本。原因：备注列字体小、位置偏，容易被忽略。解决：提取表格时把备注列单独拉出来，逐条翻译并标注适用条件，在安全需求规格书里作为前置条件写明。

4.4 条款号只写一级编号

现象：表1写“4.5.2”，翻译时也只写“4.5.2”，但正文里4.5.2有五个子条款，分别对应不同的检测区域和响应时间。原因：表1受限于排版只写一级编号，翻译时没有展开。解决：翻译时查正文，把子条款号补全，比如“4.5.2.3”，并在备注里写明该子条款的具体要求。

4.5 直接机翻后不做术语回译校验

现象：机翻把“enabling device”译成“使能设备”，但团队内部一直用“使能装置”，导致文档不一致。原因：机翻没有项目术语库。解决：机翻后做一次回译，把译文再翻回英文，看是否和原文一致。不一致的地方人工修正，并更新术语表。

5. 进阶：把表1变成安全需求规格书的自动化检查脚本

翻译完表1只是第一步，真正省时间的是把表1的结构化数据变成可检查的脚本。我一般会把翻译后的CSV导入Python，做两件事：一是检查每个安全功能是否都有对应的PL等级和条款号，二是检查PL等级是否在允许范围内。

import csv # 读取翻译后的表1 with open("table1_translated.csv", "r", encoding="utf-8") as f: reader = csv.DictReader(f) rows = list(reader) # 检查1：必填字段是否完整 required_fields = ["安全功能", "对应条款", "所需PL"] for i, row in enumerate(rows, start=2): # 从第2行开始，第1行是表头 for field in required_fields: if not row.get(field, "").strip(): print(f"第{i}行缺少 {field}") # 检查2：PL等级是否在合法范围 valid_pl = {"PL a", "PL b", "PL c", "PL d", "PL e"} for i, row in enumerate(rows, start=2): pl = row.get("所需PL", "").strip() if pl and pl not in valid_pl: print(f"第{i}行PL等级非法：{pl}") # 检查3：条款号格式是否为 x.x.x import re pattern = re.compile(r"^\d+\.\d+(\.\d+)?$") for i, row in enumerate(rows, start=2): clause = row.get("对应条款", "").strip() if clause and not pattern.match(clause): print(f"第{i}行条款号格式异常：{clause}") print("检查完成")

这个脚本跑一遍，能把翻译过程中的低级错误全筛出来。比如某行PL写成“PL D”大写，或者条款号写成“4.5.2.3.1”多了一级，都会报出来。更进一步，可以把表1的PL要求和实际安全回路设计文档做交叉检查：设计文档里每个安全功能标注的PL是否大于等于表1要求。这个检查用pandas做merge就行，不展开写了。

最后说一个我自己的习惯：翻译标准表格时，永远保留一份中英对照的原始文件，不要只留译文。因为认证过程中公告机构可能会问“这个功能原文怎么写的”，你翻回英文时如果只凭记忆，很容易和原文有出入。中英对照文件放在项目共享目录里，谁需要谁查，比反复翻PDF快得多。希望帮到你。

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