如何为 IEC 61508 第 3 版系统能力审计准备 PLC 逻辑

为了准备 IEC 61508 第 3 版系统能力审计，工程师需要提供行为证据，证明软件在定义的故障条件下能够确定性且安全地响应。可以使用 OLLA Lab 等仿真环境作为受限验证沙箱，在正式审计和物理验证之前测试安全属性、记录故障处理过程并强化逻辑。

IEC 61508 下的软件安全主要不是关于代码看起来是否整洁，而是关于能否证明逻辑在过程不再“循规蹈矩”时，依然能够表现出正确、可重复且安全的行为。

这种区别在第 3 版中尤为重要，因为人们预期围绕软件系统行为的举证责任将会收紧，而非放松。硬件故障分析仍然围绕 PFD 和 PFH 等概率性故障指标展开。软件不会因为在机柜中老化而失效；它失效的原因是系统性的，源于设计错误、规范漏洞、意外交互和未经测试的边缘情况。

Ampergon Vallis 最近的一项内部基准测试支持了这一观点。在 OLLA Lab 对 500 个模拟安全仪表功能 (SIF) 测试用例进行的内部分析中，68% 的初始逻辑草稿在经受模拟漂移、陈旧状态输入行为或超范围强制时未能通过鲁棒性检查 [方法论：n=500，涵盖泵、输送机、暖通空调和过程撬块场景的模拟 SIF 验证任务；基准比较器 = 修订前的初稿；时间窗口 = 2026 年 1 月至 2 月]。这支持了“初稿逻辑往往忽略异常状态处理”的观点，但并不支持任何关于行业范围缺陷率或正式合规结果的结论。

实际的变化在于更加强调通过可重现的证据来证明“系统能力”，而不仅仅是声称遵循了生命周期。

IEC 61508 一直将软件与硬件区别对待，因为软件故障是系统性的而非随机的。在实践中，这意味着第 3 版的讨论重点在于开发和验证过程能否证明软件安全需求已被转化为受控、可测试的行为。“我们仔细审查了代码”并不是一句废话，但它已不再是充分的证据。

第二个变化是人们越来越期望将软件保证与网络安全、配置控制和工具链规范等相关问题集成在一起。这并不会将 IEC 61508 合并为 IEC 62443，但某些团队所偏好的那种界限分明的处理方式已不再适用。

第 2 版与第 3 版软件期望对比

| 主题 | 第 2 版重点 | 第 3 版发展方向 | |---|---|---| | 软件保证 | 生命周期遵循、审查规范、结构化测试 | 更强的行为证据、可重现的验证、尽可能实现机器可测试的证明 | | 故障处理 | 通常以叙述形式记录 | 对显式异常状态测试和可追溯结果的压力增加 | | 工具支持 | 有帮助但非核心 | 在工具能提高可重复性、可追溯性和测试覆盖率的情况下变得更重要 | | 网络安全关系 | 通常单独处理 | 与安全开发和系统完整性问题有更明确的交互 | | 系统能力证据 | 以过程为主的演示 | 过程加上可观察的证明，即逻辑在定义的边缘情况下表现安全 |

重要的修正点在于：第 3 版并不意味着软件现在可以像硬件那样获得某种“魔法公式”。它意味着软件声明需要更强有力的证据支持。

系统能力是指开发过程及最终逻辑在避免、检测和控制系统性故障方面，达到目标安全功能所需水平的证明能力。

对于 PLC 工程师而言，当转化为可观察的行为时，该定义变得具体：

• 安全逻辑以可预测且受限的方式执行。
• 状态转换是明确且可恢复的。
• 故障将系统驱动至定义的安全状态。
• 非安全逻辑不会破坏或延迟安全行为。
• 测试证据是可重现的，且可追溯至需求。

这就是语法与可部署性之间形成鲜明对比的地方。一段梯形图逻辑在语法上可能是有效的，但在调试时却可能是不安全的。

系统能力也不是一种产品徽章。它不是通过使用仿真器、代码生成器或 AI 助手就能获得的。它是通过规范的规格说明、实现、验证、文档记录以及真实保证工作流中的最终验证来确立的。

具体的分组可能因方法论而异，但在高级功能安全工作中使用的实用软件安全属性集包括以下工程师必须能够测试和解释的行为。

16 项安全属性的操作定义

• 完整性 (Completeness) — 定义了每一个所需的操作模式、转换、跳闸路径和恢复路径。
• 正确性 (Correctness) — 实现的逻辑与既定的安全需求和控制理念相匹配。
• 一致性 (Consistency) — 标签、状态、转换和联锁在整个程序中表现统一。
• 确定性 (Determinism) — 在相同的条件下，相同的输入在要求的执行范围内产生相同的输出。
• 鲁棒性 (Robustness) — 逻辑在处理错误、噪声、陈旧、缺失或超范围输入时不会出现不安全行为。
• 免受干扰 (Freedom from interference) — 非安全任务、HMI 操作、诊断或辅助逻辑不会不当地改变安全行为。
• 可追溯性 (Traceability) — 需求、梯级、标签、测试和结果之间可以无猜测地链接。
• 可验证性 (Verifiability) — 代码结构允许独立测试和明确的通过/失败判断。
• 可维护性 (Maintainability) — 未来的编辑可以在不产生隐藏安全回归的情况下进行。
• 简洁性 (Simplicity) — 设计避免了掩盖意图或增加故障风险的不必要复杂性。
• 防御性 (Defensiveness) — 逻辑预判无效状态并显式处理它们。
• 可恢复性 (Recoverability) — 故障发生后，系统仅通过受控且定义的复位条件返回。
• 有界性 (Boundedness) — 定时器、计数器、模拟量缩放和状态转换保持在已知限制内。
• 可观察性 (Observability) — 在验证过程中可以检查内部状态和决策点。
• 故障安全行为 (Fail-safe behavior) — 信号丢失、不一致或无效的过程状态在需要时驱动安全响应。
• 可测试性 (Testability) — 工程师可以注入条件并确认预期结果，无歧义。

PLC 团队通常低估的五项属性

• 确定性： 扫描行为必须在所有相关输入组合下保持可预测。
• 鲁棒性： 模拟量漂移、触点抖动和陈旧的通信值不得导致不安全的状态保持。
• 完整性： 每个状态机转换都需要一个进入条件和一个安全退出条件。
• 免受干扰： 显示逻辑、消息传递和便利功能不得干扰安全执行。
• 可验证性： 如果架构无法进行清晰的测试，那么审计问题在现场问题出现之前就已经开始了。

这些都是工程行为。如果团队无法在受控的测试条件下证明它们，审计讨论就会变得比应有的更具解释性。

“仿真就绪”应从操作层面而非装饰层面来定义。

一名“仿真就绪”的工程师能够在逻辑到达实际过程之前，证明、观察、诊断并强化控制逻辑以应对现实的过程行为。这不仅仅是编写梯形图语法，还包括：

• 将 I/O 映射到预期的设备行为，
• 在测试前定义“正确”的含义，
• 强制模拟正常和异常条件，
• 通过标签和状态追踪因果关系，
• 识别故障模式，
• 在故障后修改逻辑，
• 以及比较模拟设备状态与梯形图状态。

这就是绘制梯级与演练调试判断之间的区别。

虚拟仿真通过使执行行为在可重复的条件下变得可观察，从而验证确定性。

在受限的仿真环境中，工程师可以运行逻辑、保持条件恒定、按受控顺序切换输入，并观察输出和内部状态是否完全按预期变化。重点在于可重复性。

使用 OLLA Lab，该验证工作流可以包括：

• 在没有物理硬件的情况下以仿真模式运行梯形图逻辑，
• 切换离散输入并强制模拟量值，
• 通过变量面板监控标签状态，
• 将梯级行为与场景目标和设备响应进行比较，
• 并在每次修订后重复相同的测试。

对于确定性检查，工程师至少应测试以下情况：

• 多次重复相同的输入序列，
• 转换边界附近的异步输入变化，
• 依赖于定时器的转换，
• 复位和重启行为，
• 允许条件的丢失和恢复，
• 带有噪声或漂移的模拟量阈值交叉。

一个常见的误解是仿真只能证明基本功能。如果使用得当，它还可以显示逻辑是否具有稳定的行为边界。

OLLA Lab 应被定位为风险受控的验证沙箱，而非认证引擎。

其操作价值显而易见：工程师可以在基于 Web 的编辑器中构建梯形图逻辑，在仿真中运行它，检查变量和 I/O 行为，并在物理调试前根据基于场景的机器模型和数字孪生验证逻辑。这使其对于审计前的强化、故障演练和证据捕获非常有用。

在这一受限角色内，OLLA Lab 支持多项相关验证任务：

• 梯形图编辑器： 使用标准指令类型构建和修订控制逻辑，包括定时器、计数器、比较器、数学运算、逻辑和 PID。
• 仿真模式： 安全地执行逻辑，停止并重新运行测试，并在不接触硬件的情况下强制输入条件。
• 变量面板和 I/O 可视化： 在追踪因果关系的同时检查标签、输出、模拟量值和回路行为。
• 3D/WebXR/VR 场景： 在真实的操作环境中比较梯形图行为与机器或过程响应。
• 数字孪生验证： 测试预期序列是否确实针对虚拟设备模型正确运行。
• 基于场景的调试练习： 演练联锁、报警、验证反馈、跳闸、允许条件和复位逻辑。
• GeniAI 实验室指南： 在学习和测试准备期间提供指导支持和梯形图辅助。

最后一点需要设定界限。AI 辅助可以加速起草和解释，但它不能取代确定性审查、独立验证或安全判断。

数字孪生验证意味着针对设备或过程行为的虚拟表示来测试控制逻辑，以确认逻辑的决策产生了预期的系统响应。

在安全相关的工作中，这意味着要提出诸如以下的问题：

• 跳闸条件是否强制执行了预期的安全状态？
• 验证反馈超时是否表现正确？
• 手动复位是否在所有允许条件健康之前保持锁定？
• 模拟量故障处理是否防止了错误重启或隐藏的不安全持续运行？
• 序列在异常停止后是否能干净地恢复？

这就是 OLLA Lab 发挥操作价值的地方。该平台的场景结构、I/O 可视化和数字孪生框架允许工程师测试行为，而不仅仅是检查语法。

话虽如此，数字孪生验证并不能替代最终的现场验收、设备验证或认证的安全生命周期活动。它是一个预调试的证据层。

工程师应测试那些暴露逻辑中隐藏假设的故障案例，特别是在状态保持、允许条件和模拟量解释可能静默失效的地方。

一套实用的审计前故障集包括：

• 传感器超范围： 低值、高值、NaN 等效值或不可信的值
• 模拟量漂移： 跨越报警和跳闸阈值的缓慢移动
• 离散输入抖动： 限位开关或反馈上的重复转换噪声
• 陈旧状态输入： 当过程条件应该改变时值却冻结
• 允许条件丢失： 电机启动器反馈丢失、阀门验证缺失、压力未建立
• 电源循环或重启条件： 保持位和启动状态验证
• 手动复位误用： 在危险清除前即可复位
• 序列中断： 在步骤转换期间停止或跳闸
• 通信丢失替代： 来自从属子系统的冻结或无效状态
• 联锁不一致： 在反馈与预期设备状态矛盾时发出指令

这些测试之所以重要，是因为许多危险的故障并不剧烈。它们是梯形图逻辑所认为的与设备实际正在执行的操作之间的静默不匹配。

一份符合审计要求的证据包应记录工程推理和行为证明，而不仅仅是截图。

对于每个与安全相关的场景或功能，请使用以下紧凑结构：

1. 系统描述 定义设备、过程目的、操作模式和安全角色。
2. “正确”的操作定义 陈述确切的预期行为，包括允许条件、跳闸、复位条件、时序和安全状态。
3. 梯形图逻辑和模拟设备状态 展示相关的梯级、标签映射以及仿真中使用的设备或过程状态。
4. 注入的故障案例 记录引入的异常条件、强制方式及其重要性。
5. 所做的修订 记录测试后所做的逻辑更改、参数调整或状态处理修正。
6. 经验教训 捕获工程见解：隐藏的假设、缺失的允许条件、模糊的复位路径、时序问题或干扰风险。

这种结构是刻意简化的。审计员和审查员通常更喜欢他们无需进行解释性考古就能理解的证据。

工程师可以使用 OLLA Lab 通过将每个测试与场景、一组强制条件、可观察的标签行为和记录在案的修订联系起来，从而生成可重现的审计前工件。

一个实用的工作流如下：

1. 选择具有明确操作目标的场景 例如，急停链、主/备泵控制、输送机序列、AHU 允许条件集。
2. 在测试前定义预期的安全行为 陈述在跳闸、复位和异常输入时必须发生的情况。
3. 在仿真模式下运行梯形图 首先使用编辑器和仿真控件在正常条件下执行逻辑。
4. 通过变量面板强制故障 注入超范围模拟量值、移除验证反馈、切换联锁或模拟陈旧状态。
5. 观察并记录响应 确认输出、状态、报警和复位路径是否按定义表现。
6. 修订逻辑并重新运行确切的案例 这是重要部分。没有修订历史的证据通常只是日记。
7. 捕获场景参数和结果摘要 保留测试条件，以便其他审查员可以重现结果。

在该工作流中，OLLA Lab 的价值不在于它能独自证明合规性。其价值在于它帮助工程师在正式审计提交之前，以及在实时设备成为测试台之前，创建了一套可重现的行为证据。

防御性急停实现应强制执行故障安全丢失行为、显式手动复位，并防止被绑死或过早重启的情况。

[语言：梯形图 - IEC 61131-3]

|----[/] E_STOP_OK ----+-------------------------------( ) SAFE_TRIP_ACTIVE | | |----[/] SAFETY_RELAY_FB-+

|----[ ] E_STOP_OK ----[ ] SAFETY_RELAY_FB ----[ ] RESET_PB ----[/] SAFE_TRIP_ACTIVE ----[TON ANTI_TIEDOWN 500ms] |------------------------------------------------------------------------------------------------------------( ) RESET_PERMISSIVE

|----[ ] RESET_PERMISSIVE ----[ ] ALL_PERMISSIVES_OK ----[ ] NO_ACTIVE_FAULTS ----[/] START_INHIBIT ----( ) SAFETY_ENABLE

|----[/] SAFETY_ENABLE ------------------------------------------------------------------------------------( ) MOTOR_RUN_CMD

为什么这种模式很重要

• 完整性： 重启需要定义的健康条件，而不仅仅是急停恢复。
• 鲁棒性： 安全继电器反馈或急停健康的丢失会强制执行跳闸行为。
• 可恢复性： 复位是手动的且有条件的。
• 故障安全行为： 缺少健康的安全输入会移除使能。
• 免受干扰： 安全路径是显式的，且可与便利逻辑分离。

在实践中，确切的实现取决于平台、安全架构和认证的硬件路径。这里的重点是结构性的：安全恢复应该是通过努力获得的，而不是假设的。

3D 和 VR 仿真在提高过程后果的可观察性时是有帮助的，而不是仅仅增加视觉效果。

在 OLLA Lab 中，3D/WebXR/VR 场景可以帮助工程师比较梯形图状态与可见的设备响应。这在测试以下内容时非常有用：

• 序列进度，
• 执行器时序，
• 验证反馈依赖关系，
• 报警条件，
• 联锁运动，
• 以及操作员复位后果。

工程上的好处是，当虚拟设备由于可追溯的原因做出明显错误的操作时，逻辑错误更容易被发现。

话虽如此，证据仍然保留在软件端和仿真受限范围内。它加强了预调试验证，但不能替代物理验证、认证的设备行为或正式的安全案例。

团队应在起草和解释层面使用 AI 辅助进行加速，然后在决策层面应用确定性的人工审查。

在 OLLA Lab 中，GeniAI 可以帮助进行入职培训、梯级解释、纠正建议和梯形图起草支持。这对于结构化学习和早期迭代非常有用。它减少了摩擦，但减少摩擦并不等同于安全保证。

对于安全相关的逻辑，团队应要求：

• 明确的需求映射，
• 对生成的逻辑进行独立审查，
• 故障注入仿真，
• 失败案例后的文档化修订，
• 以及由项目安全生命周期内的合格工程师进行最终批准。

令人难忘的对比很简单：草稿生成与确定性否决。后者才是工作所在。

工程师应首先将抽象的安全声明转化为可重现的测试用例。

一个实用的顺序是：

• 识别 PLC 范围内的安全相关功能，
• 定义正常、跳闸、复位和异常状态下的正确行为，
• 将每个功能映射到一小组安全属性，
• 在硬件测试前运行故障注入仿真，
• 在紧凑的证据包中记录修订，
• 并保留现场调试用于验证，而非首次发现。

如果你们当前的工作流仍然将异常状态测试视为面板通电后才发生的事情，那么这个过程就已经滞后了。

_图片替代文本：OLLA Lab 变量面板的截图，展示了一项系统能力测试。模拟量输入被强制超出范围，逻辑转换为安全状态，说明了在模拟 IEC 61508 审计工作流中的鲁棒性属性。_

Ampergon Vallis Lab 致力于通过数字孪生和仿真技术，提升工业控制系统的安全性和可验证性。

本文内容基于 IEC 61508 第 3 版标准框架及 Ampergon Vallis 内部仿真基准测试数据。

- IEC 61131-3: 可编程控制器 — 第 3 部分：编程语言 - IEC 61508 概述（功能安全） - NIST AI 风险管理框架 (AI RMF 1.0) - 制造业中的数字孪生：分类文献综述与分类 (IFAC, DOI) - 工业中的数字孪生：最先进技术 (IEEE, DOI)