如何在仿真就绪的文档中应用 NAMUR NE 107 PLC 命名规范

为了在 PLC 文档中应用 NAMUR NE 107 命名规范，工程师应构建诊断标签，使设备状态能够直观地显示为“故障 (Failure)”、“功能检查 (Function Check)”、“超出规格 (Out of Specification)”或“需要维护 (Maintenance Required)”。这减少了故障排除过程中的歧义，支持报警解读，并使联锁逻辑在现场调试前的仿真中更易于验证。

PLC 命名规范常被视为琐事，这是第一个误区。在实际工厂中，含义模糊的标签不仅是杂乱无章，甚至可能带来危险，因为它们会减慢故障识别速度，诱导错误的强制操作决策，并掩盖设备究竟是发生了故障、漂移，还是仅仅处于维护状态。

在对 OLLA Lab 的 50 多种工业预设进行内部验证期间，初级用户在使用结构化的 NAMUR 风格诊断标签（而非临时命名）时，识别仿真传感器漂移状况的速度提高了 41%。方法论：n=34 名学员和初级工程师；任务=仅使用标签名称和实时变量行为，在预设场景中识别并分类仿真漂移和设备状态故障；基准比较器=具有等效逻辑的非结构化标签字典；时间窗口=2026 年第一季度内部验证会议。这支持了标准化命名可提高仿真中故障识别能力的结论。但这本身并不能证明其能降低现场工厂的事故率。

在本文中，“仿真就绪 (Simulation-Ready)”意味着工程师可以构建标签字典，将其映射到数字孪生体，并仅通过标签命名法追踪仿真故障级联，而无需依赖外部手册。这比仅仅能够编写梯形图语法有着更严格的标准。

标准化的 PLC 命名规范至关重要，因为维护和操作决策通常是在时间紧迫、可见度有限且交接质量参差不齐的情况下做出的。标签名称往往是技术人员看到的第一个诊断工件。如果它含糊不清、负载过重或是在本地临时编造的，那么控制系统在最需要解读的时候反而变得难以解读。

其安全机制非常直接：

• 模糊的标签增加了诊断延迟，
• 诊断延迟增加了错误强制或旁路操作的几率，
• 错误的强制操作可能会破坏许可、跳闸或联锁，
• 被破坏的联锁可能会使人员和设备暴露于危险状态。

这并非纯粹的理论。OSHA（美国职业安全与健康管理局）的挂牌/上锁 (LOTO) 执行历史和事故叙述反复表明，设备状态识别错误、隔离清晰度差以及维护期间的错误假设会导致严重的事故和伤亡 (OSHA, n.d.)。ISA-18.2 也将清晰的报警识别、优先级排序和操作员解读视为有效报警管理的一部分，而非装饰性标签 (ISA, 2016)。

一个常见的误解是命名标准主要是为了代码审查的整洁。事实并非如此。它们是为了解决凌晨 2 点的维护难题：技术人员看到 `Reg_Bit_4`、`Aux_2` 或 `MTR_Aux1`，必须判断该位代表的是故障、旁路、仿真标志、许可还是陈旧的遗留工件。

凌晨 2 点的维护难题

实际的危险出现在异常状态下，而非平静的设计审查期间。

考虑两个标签：

• `Reg_Bit_4`
• `VLV101_F_Stuck`

第一个标签几乎无法向技术人员传达任何信息。第二个标签则传达了：

• 设备标识：`VLV101`
• 诊断类别：`F` 代表故障 (Failure)
• 具体状况：`Stuck`（卡死）

这种差异会改变行为。阅读 `VLV101_F_Stuck` 的技术人员不太可能将硬故障与维护模式或软建议混淆。清晰的命名法不能取代程序、许可或 LOTO。它可以在这些控制措施生效前，降低做出错误决策的几率。

“拯救生命”在工程术语中意味着什么

“拯救生命”应从机械角度而非戏剧化角度来理解。清晰的命名法有助于防止技术人员在故障排除、维护和重启过程中旁路主动安全逻辑或误读危险的设备状态。这才是至关重要的链条。

NAMUR NE 107 为现场设备的自监测和诊断定义了四种标准化的设备状态类别。其目的是以一种在不同系统和供应商之间保持一致、可识别且具有操作价值的形式呈现诊断信息 (NAMUR, 2012)。

NAMUR NE 107 诊断类别

• 故障 (Failure, F)： 由于故障，信号或设备功能无效。例如：断线、传感器电子故障、执行器故障。
• 功能检查 (Function Check, C)： 由于设备处于测试、维护或校准状态，信号暂时无效。例如：回路校准激活、仿真模式启用、设备正在进行验证测试。
• 超出规格 (Out of Specification, S)： 设备在预期的环境或过程限制之外运行，但不一定发生了故障。例如：变送器内部温度过高、过程变量超出验证范围。
• 需要维护 (Maintenance Required, M)： 信号保持有效，但设备指示需要即将进行的服务或处于性能下降状态。例如：阀门摩擦力增加、行程计数超限、传感器污染警告。

这些类别之所以重要，是因为它们区分了“现在无效”、“有意无效”、“仍在工作但超出限制”以及“正在工作但性能下降”。这种区分决定了正确的响应是跳闸、下达工单、校准记录还是进一步调查。

为什么 NE 107 非常适合 PLC 文档

NE 107 起源于现场设备诊断，但其逻辑在 PLC 标签字典中非常适用，因为 PLC 程序正是诊断状态变得可操作的地方。一旦这些类别反映在标签中，控制叙述在以下方面将变得更易于阅读：

• 报警处理，
• 联锁逻辑，
• HMI 报警显示，
• 维护故障排除，
• 仿真和数字孪生验证。

谨慎使用时，这会在仪表、控制和维护团队之间建立一种共享的诊断语法。

符合 NAMUR 标准的标签字典应以稳定、可读的格式编码设备标识、诊断类别和具体故障状况。在本文中，推荐的结构是：

Ampergon Vallis 标准标签结构

| 格式 | 含义 | 示例 | |---|---|---| | `[EquipmentID]_[NAMUR_Status]_[SpecificFault]` | 设备 + 诊断类别 + 明确状况 | `PMP202_F_Overload` | | `[EquipmentID]_[NAMUR_Status]_[SpecificFault]` | 设备 + 超出规格状态 | `VLV104_S_HighFriction` | | `[EquipmentID]_[NAMUR_Status]_[SpecificFault]` | 设备 + 功能检查状态 | `LIT301_C_SimMode` | | `[EquipmentID]_[NAMUR_Status]_[SpecificFault]` | 设备 + 需要维护状态 | `FIT210_M_Fouling` |

这种结构刻意保持简洁。它有三个优点：

• 无需打开注释或手册即可直观显示诊断类别，
• 将故障语义与资产绑定，
• 支持在变量工作区中进行过滤、排序和仿真审查。

在 OLLA Lab 中，这在“变量面板 (Variables Panel)”内变得非常实用，用户可以在该面板中监控实时标签、切换输入、检查模拟行为，并观察诊断状态如何通过梯形图逻辑和仿真设备行为进行传播。

构建字典的实用规则

如果您希望字典在调试和故障审查期间保持可读性，请遵循以下规则：

• 保持设备 ID 稳定。 不要在一个屏幕中将 `PMP202` 命名为 `Pump2_Main`，而在另一个屏幕中命名为 `P202`。
• 每个标签使用一个诊断类别。 避免使用 `PMP202_FaultWarn` 这种合并语义。如果一个标签可能代表两种含义，它最终就会产生歧义。
• 命名实际状况，而非实现细节。 优先使用 `PMP202_F_Overload` 而非 `PMP202_F_Bit7`。
• 将过程状态与诊断状态分离。 `PMP202_RunFb` 和 `PMP202_F_Overload` 不应合并为一个重载标签族。
• 明确预留仿真和维护标记。 像 `LIT301_C_SimMode` 这样的功能检查状态应该是明确无误的。
• 尽可能统一 HMI、PLC 和文档语言。 翻译层会滋生错误。

梯形图逻辑中的简洁示例

文本示例：

• 梯级 1：NAMUR 故障联锁
• 如果 `PMP101_F_Vibration_High` 激活，则复位运行命令。
• `XIC(PMP101_F_Vibration_High) OTL(PMP101_Safety_Latch)`
• `XIC(PMP101_Safety_Latch) OTU(PMP101_Run_Command)`

这个例子很简单，但命名起到了实际作用。审查者无需对每个上游条件进行逆向工程，即可推断出联锁的目的。

文档标准只有在能够针对行为进行测试时才有用。OLLA Lab 的变量面板提供了一个受限环境，工程师可以在其中观察标签名称在逻辑运行、故障注入和设备状态在仿真中发生变化时是否依然清晰易懂。

这一点很重要，因为在电子表格中看起来不错的命名规范在动态条件下可能会失效。静态的整洁并非验证。

变量面板让您能够验证的内容

在 OLLA Lab 中，用户可以：

• 监控实时输入、输出和内部标签状态，
• 切换离散输入并观察输出响应，
• 检查模拟值和报警阈值，
• 查看包含回路行为场景中的 PID 相关变量，
• 比较梯形图状态与仿真设备行为，
• 测试标签字典在异常事件期间是否保持可解释性。

例如，在泵调试场景中，用户可以激活故障或漂移状况，并观察 `PMP202_F_Overload`、`PIT220_S_High` 或 `LIT301_C_SimMode` 等标签是否在没有外部注释的情况下传达了足够的含义来诊断事件。这就是操作测试。

为什么这是一个文档问题，而不仅仅是编程问题

糟糕的命名往往能存活下来，因为梯形图逻辑依然有效。电机启动，阀门打开，顺序推进。然后故障发生，逻辑在压力下变得无法阅读。因此，文档质量不能由成功的额定运行来证明，而是由故障的可读性来证明。

这正是 OLLA Lab 的可信价值所在：它不是通往能力的捷径，而是针对难以在实时系统上练习的高风险任务的排练空间。用户可以映射标签、强制条件、检查因果关系，并在仿真故障后修改逻辑，而不会危及设备或人员。

命名规范通过使报警源、状态类别和设备状况在 PLC、HMI 和维护工作流中更易于一致地解读，从而支持报警管理。ISA-18.2 强调报警系统应帮助操作员正确响应异常情况；模糊的源命名违背了这一目标 (ISA, 2016)。

实用的命名规范通过以下几种方式改进报警处理：

• 由于设备状况更清晰，使报警合理化变得更容易，
• 有助于区分维护状态与实际故障，
• 减少了报警洪峰期间的滋扰性解读错误，
• 支持事后审查，因为诊断意图在历史记录和逻辑中是可见的。

这也改进了数字孪生验证。如果仿真故障级联产生的标签在语义上是清晰的，工程团队不仅可以验证逻辑是否跳闸，还可以验证文档在跳闸期间是否仍然具有可操作性。

命名示例：糟糕与可用

弱标签

• `Alarm_12`
• `FaultBit3`
• `PumpAux`
• `SensorBad`

可用标签

• `PMP202_F_Overload`
• `LIT301_S_HighTemp`
• `FIT210_M_Fouling`
• `AIT110_C_Calibration`

第二组标签并非完美无缺，它们只是易于阅读、排序，并且可由未参加最初设计会议的人员进行审查。

在本文中，“仿真就绪”意味着工程师可以在逻辑到达实际过程之前，证明、观察、诊断并强化控制逻辑以应对真实的过程行为。对于文档而言，这意味着标签字典足够强大，能够支持使用标签名称本身作为主要诊断线索在数字孪生体中进行故障追踪。

在操作层面，一套仿真就绪的文档集允许工程师：

• 将标签映射到仿真 I/O 和设备状态，
• 区分正常状态、维护状态和故障状态，
• 通过联锁和报警追踪异常状况，
• 在观察到困惑或歧义后修改逻辑或命名，
• 重新运行场景并验证修订后的命名法是否改进了诊断。

这比“标签在某处有文档记录”的标准要好。文档可以存在，但仍然毫无用处。

工程师应将命名规范技能记录为紧凑的工程证据。截图库证明不了什么。重要的是工程师能否定义正确性、注入故障、修改逻辑或字典，并解释结果。

使用以下结构：

1. 系统描述： 识别过程单元或场景、受控设备和操作目标。
2. 正确行为的操作定义： 用可观察的术语说明成功行为的含义：启动条件、许可、报警行为、跳闸行为和预期的设备反馈。
3. 梯形图逻辑和仿真设备状态： 展示相关的梯级、标签字典以及用于验证的仿真机器或过程状态。
4. 注入的故障案例： 定义引入的异常状况：过载、阀门卡死、传感器漂移、反馈丢失、校准模式或超出范围的模拟输入。
5. 所做的修订： 记录审查后发生的变化：标签重命名、联锁调整、报警阈值校正，或改进了 `F`、`C`、`S` 和 `M` 状态之间的区分。
6. 经验教训： 解释原始命名掩盖了什么，修订后的结构如何改进了诊断，以及还有什么问题未解决或处于边界状态。

这种格式在培训、设计审查和招聘审查中非常有用，因为它展示了故障条件下的推理能力。

OLLA Lab 通过提供一个基于 Web 的环境，帮助工程师排练 NAMUR 风格的文档，在该环境中可以一起测试梯形图逻辑、仿真 I/O、变量、模拟行为和基于场景的设备模型。其价值在于边界明确且实用。

在此边界内，用户可以：

• 在浏览器中构建或编辑梯形图逻辑，
• 实时检查标签和变量状态，
• 运行包含联锁、报警、模拟信号和 PID 行为的场景，
• 在 3D 或支持 WebXR 的上下文中比较梯形图状态与仿真设备行为，
• 练习故障注入并审查标签字典是否保持可解释性。

这对初级工程师尤其有用，因为现场调试很少提供反复犯错的安全空间。一个可信的用例是泵或阀门场景，学习者必须：

• 映射 `F`、`C`、`S` 和 `M` 诊断标签，
• 触发故障或维护状况，
• 观察逻辑如何响应，
• 修改模糊的名称，
• 重新运行场景，直到仅通过标签字典即可看清故障路径。

这是对调试判断力的排练，而不是对现场资格、认证或受监督现场能力的替代。

NAMUR NE 107 命名规范通过将诊断状态转化为维护和控制人员能够快速且一致地解读的内容，从而改进了 PLC 文档。这四个类别——故障、功能检查、超出规格和需要维护——不仅仅是标签。它们是针对异常状况的紧凑决策框架。

实际的测试很简单：技术人员或初级工程师能否在仿真故障期间仅通过标签追踪故障状态？如果不能，那么无论电子表格看起来多么精美，文档都没有准备好。

如果使用得当，OLLA Lab 提供了一个运行该测试的安全场所。它位于验证工作流中：构建标签、运行逻辑、注入故障、观察设备响应、修订命名法并再次验证。这就是命名规范如何从“风格”转变为“风险控制”的方式。

- 向上 (Pillar Hub): 探索支柱指南 - 横向: 相关文章 1 - 横向: 相关文章 2 - 向下 (商业/CTA): 在 OLLA Lab 中构建您的下一个项目

- NAMUR NE 107 建议 - ANSI/ISA-18.2 报警管理 - OSHA 危险能源控制（挂牌/上锁） - IEC 61508 功能安全标准系列