如何证明 AI 生成的梯形图逻辑符合 IEC 61508 第 3 部分的严苛要求

为了根据 IEC 61508 第 3 部分评估 AI 生成的梯形图逻辑，工程师应通过仿真而非仅仅通过提示词（prompts）来测试确定性行为、故障响应和可追溯性。OLLA Lab 提供了一个边界明确的验证环境，逻辑可以在此针对真实的机器行为进行测试，在故障条件下进行观察，并记录为符合审计要求的执行证据。

AI 生成的梯形图逻辑之所以无法通过审计，并不是因为它是由“AI”生成的。其失败的原因在于功能安全要求行为必须是确定性的、可追溯的和可验证的，而大语言模型（LLM）的输出在工程师对其进行约束和验证之前，本质上是概率性的。

Ampergon Vallis 最近的一项内部分析发现，在模拟传感器丢失的条件下，500 个 AI 生成的电机控制程序中有 68% 未能通过边界可预测性筛查，直到由工程师手动进行约束 [方法论：n=500，在 OLLA Lab 仿真中测试了生成的电机启动及许可/联锁程序，基准比较器 = 源自预定义序列和故障响应预期的确定性验收标准，时间窗口 = 2026 年 1 月至 3 月]。这一指标仅支持一个狭窄的观点：未经约束的 AI 输出在仿真中往往违反可预测的故障行为。它并不支持关于所有 PLC 代码、所有供应商或正式认证结果的结论。

这种区别至关重要。你无法审计一个提示词。你只能审计生成的逻辑在模拟物理约束下的确定性执行情况。语法是廉价的，但可部署性并非如此。

AI 生成的逻辑无法通过 IEC 61508 第 3 部分审计，是因为该标准关注的是软件行为的系统完整性，而不是代码生成的快慢。IEC 61508-3 要求软件的规范、结构、验证和论证必须能够支持在定义的条件和定义的故障下进行可预测的操作。

核心冲突很简单。LLM 根据训练数据中的模式生成概率最高的下一个标记（token）。而安全软件必须在已知的过程条件下产生有界限、可解释的状态转换。一个是概率性生成，另一个是确定性问责。

这就是为什么提示词历史记录不能作为合规证据的原因。提示词可以解释意图，但它不能证明扫描周期行为、故障处理、安全状态转换或时序合规性。

控制工程师对实际的失效模式并不陌生：

• 许可条件（permissives）虽然能正确接通，但无法确定性地断开
• 锁存位在异常重启条件下存续，且没有明确的复位逻辑
• 报警处理检测到错误值，但未能强制执行安全响应
• 模拟量比较缺乏量程外处理
• 步进逻辑在理想路径下运行正常，但在异步输入下发生断裂
• 过度复杂的梯形图结构掩盖了验证过程

IEC 61508 在整个生命周期活动中使用不同的术语，但工程需求是一致的：软件行为必须是合理的、可测试的，并且可追溯到安全意图。AI 可以起草逻辑，但它不能通过热情来继承系统能力。

这就是 OLLA Lab 发挥实际作用的地方。它的作用不是认证 AI 代码，而是提供一个风险受控的环境，让工程师能够运行“生成-验证”循环，观察扫描行为，诱发故障，比较梯形图状态与模拟设备状态，并记录逻辑的实际执行情况。

“仿真就绪”意味着工程师可以在控制逻辑到达实际生产过程之前，证明、观察、诊断并强化其针对真实过程行为的控制能力。

这个定义是操作性的，而非理想化的。一名“仿真就绪”的工程师能够：

• 在测试开始前定义什么是正确的行为
• 针对机器或过程模型而非假设来运行逻辑
• 在执行过程中监控 I/O、内部位、模拟值和序列状态
• 注入异常条件，如传感器丢失、反馈滞后、电源循环和许可丢失
• 识别梯形图状态偏离预期设备行为的位置
• 修改逻辑并重新测试，直到行为是有界限且可解释的

这就是梯形图语法与调试判断之间的真正区别。很多人都能画出一个梯级，但很少有人能解释为什么泵在故障验证失败后应拒绝重启，或者为什么许可条件必须在故障后无条件否决运行命令。

下方的“16 个支柱”是源自 IEC 61508-3 软件安全生命周期预期的实用工程综合，特别是该标准对正确性、可验证性、故障规避和严谨设计的强调。它们并非标准中逐字列出的清单，而是用于评估 AI 生成的梯形图逻辑是否正朝着可审计的严谨性迈进的工作框架。

第 1 组：架构与确定性

涵盖所有定义的运行模式、启动状态、停机状态和异常状态。

• 1. 完整性

逻辑符合预期的控制哲学和安全要求。

• 2. 正确性

在相同条件下，执行行为是有界限且可重复的。

• 3. 可预测性

设计避免了内部矛盾、意外锁存、类似死锁的序列停滞以及不稳定的状态交互。

• 4. 无内在故障

最大限度地降低复杂性，以确保逻辑保持可审查和可测试。AI 在这一点上往往会失败，因为它生成的逻辑虽然能编译，但过于繁琐，难以论证。

• 5. 简洁性

第 2 组：故障容错与响应

逻辑能够处理无效、噪声、缺失或量程外的输入，而不会产生未定义的行为。

• 6. 鲁棒性

程序能够主动识别故障传感器、缺失的证明信号、错误的模拟值或相关的通信丢失。

• 7. 故障检测

当违反安全条件时，通过确定性否决逻辑消除危险输出。

• 8. 安全状态转换

非关键功能以受控方式失效，同时保留基本安全行为。

• 9. 优雅降级

变量、保持状态和关键值受到保护，防止意外损坏或滥用。

• 10. 数据完整性

逻辑在要求的过程安全时间内响应，且不依赖于无界的执行假设。

• 11. 时序约束

第 3 组：验证与可追溯性

每个与安全相关的梯级、联锁、报警或序列步骤都映射回定义的规范或危险控制。

• 12. 可追溯性

功能被分区，以便可以独立审查和测试。

• 13. 模块化

逻辑可以在定义的场景下进行演练，并证明其符合预期结果。

• 14. 可验证性

未来的工程师能够理解、排查并安全地修改代码。

• 15. 可维护性

在软件完整性与网络安全实践（包括 IEC 62443 关注点）重叠的地方，考虑防止未经授权的强制操作或不安全修改。

• 16. 安全感知控制完整性

这些支柱之所以重要，是因为 IEC 61508 不会因为代码“通常能用”而留下深刻印象。安全软件的评判标准是其在定义的压力下的定义行为。

可审计的工件不是截图、提示词日志或模糊的测试笔记。在此背景下，它应定义为一份带时间戳的仿真报告，对比预期的控制序列行为与诱发故障条件下的观察状态变化。

该定义使证据与执行过程紧密相连，同时也限制了产品声明的范围。OLLA Lab 通过提供仿真、变量可见性、场景结构和真实的机器模型，支持此类证据的生成。它本身并非合规性授权机构。

一份有用的可审计工件应包括：

1. 系统描述 正在控制的设备或过程，包括主要 I/O、序列意图和运行模式。
2. 正确行为的操作定义 正常运行和异常条件下的预期行为。
3. 梯形图逻辑与模拟设备状态 测试中的梯级逻辑以及仿真中相应的机器或过程响应。
4. 注入的故障案例 引入的确切异常条件，如断线、证明信号失败、模拟量超量程或电源循环恢复。
5. 所做的修订 观察到故障后逻辑中发生了什么变化。
6. 经验教训 故障揭示了关于假设、序列设计、联锁或可维护性的哪些问题。

这种六部分结构产生的是工程证据，而不是截图库。审计员和高级审查员需要决策轨迹。后续接手代码的人员也同样需要。

文档应是验证的副产品，而不是事后的清理工作。如果测试过程结构合理，证据包可以从工作流本身组装而成。

一个实用的工作流如下：

1. 定义预期的序列和安全响应 说明设备在运行、停止、启动、停机和故障条件下的应有表现。
2. 构建或导入梯形图逻辑 这可能包括 AI 生成的草稿逻辑，但草稿只是起点。
3. 在仿真模式下运行逻辑 在监控输入、输出、内部标签、模拟值和序列位的同时执行程序。
4. 刻意注入故障 使用变量控制来模拟断线、限位失败、证明信号滞后、许可丢失、模拟量偏移或重启条件。
5. 比较预期行为与观察行为 记录模拟设备是否进入了正确的安全状态，以及内部逻辑是否符合控制哲学。
6. 修订逻辑并重新测试 根据需要添加确定性否决、复位处理、故障锁存或序列保护。
7. 导出测试记录 保留场景目标、故障案例、观察到的状态变化和最终接受的逻辑行为。

在 OLLA Lab 中，此工作流由梯形图编辑器、仿真模式、变量面板、场景结构和数字孪生环境支持。关键点不在于平台本身是否合规，而在于它提供了一个确定性的观察环境，使软件行为能够针对真实的过程条件进行测试。

下方是一个确定性否决逻辑的简要示例：

[语言: 梯形图 (Ladder Diagram)] // 示例：覆盖生成运行逻辑的确定性否决 // 如果 AI_Run_Cmd 为真，但 Safety_Permissive 丢失， // Motor_Out 必须无条件取消锁存。

|---[ AI_Run_Cmd ]----[ Safety_Permissive ]-----------( Motor_Out )---| | | |---[/Safety_Permissive ]--------------------------------(U Motor_Out)-|

这里重要的不是风格上的优雅，而是许可条件的丢失具有明确的、可测试的、无条件的后果。

OLLA Lab 验证的是行为，而非认证状态。这是正确的边界。

IEC 61508 中的系统能力取决于减少系统性故障的严谨开发和验证实践。基于 Web 的仿真器本身无法赋予系统能力，但它可以提供观察已实现逻辑的行为是否符合这些严谨实践所需的环境。

实际上，OLLA Lab 通过以下方式支持这一点：

• 使用包括触点、线圈、定时器、计数器、比较器、数学函数和 PID 指令在内的标准控制元素构建梯形图逻辑
• 在没有物理硬件的情况下进行仿真执行
• 监控和操作变量、I/O、模拟值和 PID 相关参数
• 针对真实的工业场景而非抽象的玩具问题测试逻辑
• 在可用时将梯形图状态与 3D 或 WebXR 设备行为进行比较
• 演练在实际工厂中诱发会不安全或昂贵的异常条件

这一点很重要，因为数学上的单元正确性对于工业控制来说是不够的。一个梯级在语法上可能是有效的，但仍可能在过程中失败。数字孪生验证之所以有用，正是因为它揭示了软件状态与模拟物理状态之间的交互。

在操作上，此处的数字孪生验证意味着将梯形图逻辑针对真实的机器或过程模型运行，并观察在正常和故障条件下是否发生了预期的设备行为、序列进展、联锁、报警和安全状态转换。

真实的场景会暴露通用练习所隐藏的控制假设。电机启动教程可以教授自保持逻辑，但通常不会教授证明信号失败、重启抑制、主从切换、模拟报警死区，或者当操作员命令与跳闸条件冲突时会发生什么。

这就是场景上下文的重要性所在。OLLA Lab 在水处理、废水处理、暖通空调（HVAC）、制造、仓储、食品饮料、公用事业、化工和制药等领域记录的预设场景之所以有用，不是因为它们数量众多，而是因为它们迫使逻辑进入操作上下文。

不同的场景教授不同的安全和调试模式：

• 泵送系统教授主从轮换、低液位保护、启动失败检测和溢流风险。
• 输送机和包装线教授堵塞检测、序列许可和协调停止行为。
• 暖通空调和空气处理系统教授联锁、风机证明、风门位置逻辑和报警处理。
• 过程撬块教授模拟量阈值、PID 交互、跳闸逻辑和受控停机。
• 水和废水处理系统教授液位控制、占空比循环、报警优先级和设备故障下的过程连续性。

这也是引导式构建说明发挥作用的地方。快速启动、I/O 映射、控制哲学说明、联锁、标签字典和验证步骤为工程师证明行为提供了结构化基础。这比把人扔进一个空白编辑器并称之为“现实主义”要有用得多。

故障测试应围绕可观察的过程风险进行设计，而不是围绕 AI 碰巧生成的任何内容。正确的问题不是“代码是否运行”，而是“当过程撒谎、停滞或消失时会发生什么？”

一套严谨的故障测试集至少应包括：

• 主动运行期间许可条件的丢失
• 反馈或证明信号失败
• 模拟信号高、低、冻结或超出范围
• 存在保持位时的电源循环或重启
• 序列转换期间的异步操作员命令
• 适用的通信丢失或数据滞后
• 存在冗余或确认信号时的传感器不一致

对于每种情况，工程师都应定义：

• 预期的安全响应
• 最大可接受响应时间
• 要观察的标签和输出
• 通过、失败和修订的标准

OLLA Lab 中的变量面板在这里非常有用，因为它允许在执行过程中直接操作输入和观察状态。这支持了故障注入、标签观察和可重复的重新测试。同样，其价值是有界的：它是一个用于高风险调试任务的受控验证环境，不能替代正式的现场验收、硬件验证或对实际过程的胜任能力。

决策包是解释为什么最终逻辑可以接受的组装证明。在本文中，代理编排（agentic orchestration）应被狭义地理解为工程师监督生成逻辑、针对定义场景进行测试、拒绝不安全行为并保留已接受修订背后的推理过程。

一个可辩护的决策包应包含：

• 控制目标
• 与安全相关的要求或危险缓解措施
• 梯形图逻辑修订历史
• 所使用的仿真场景
• 注入的故障案例
• 观察到的结果
• 最终接受的行为
• 未解决的假设或限制
• 进入下一审查阶段的签字依据

OLLA Lab 通过引导式场景、变量可见性、仿真执行和数字孪生环境，为构建和验证循环提供结构，从而为该包做出贡献。它帮助工程师生成可供审查的证据。这就是有用的阈值。

AI 可以加速草稿生成，但它不会减轻证明的负担。在与安全相关的软件中，没有证据的速度只是通往未经验证逻辑的更快途径。

实用的规则很简单：

• 将生成的梯形图逻辑视为草稿，绝非公认的真理
• 在测试前定义正确的行为
• 针对过程行为进行验证，而不仅仅是梯级外观
• 刻意注入故障
• 保留预期响应与观察响应的带时间戳证据
• 为确定性、可读性和可追溯性进行修订
• 让人类工程师对验收负责

这就是真正的“生成-验证”循环。它不像“AI 编写 PLC 代码”的说法那样引人注目，但在安全工作中却更有用。

- 阅读《确定性否决：编程安全 PLC》（The Deterministic Veto: Programming Safety PLCs），深入了解硬联锁和无条件安全状态逻辑。

• 返回“自动化未来中心”（Future of Automation Hub），了解更多关于弹性工程工作流和仿真主导验证的内容。
• 如果您的自动化工作流还必须满足新兴的 AI 治理要求，请查阅《欧盟 AI 法案高风险合规指南》（EU AI Act High-Risk Compliance）。
• 准备好直接测试故障行为了吗？打开 OLLA Lab 中的“安全联锁场景”，针对模拟机器模型验证逻辑。

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

本文由 Ampergon Vallis Lab 的工程团队编写，旨在探讨在工业自动化中应用生成式 AI 的严谨性与合规性。

本文内容已根据 IEC 61508-3 的软件安全生命周期要求进行了内部审查，并由 OLLA Lab 的仿真专家验证了其在数字孪生环境下的可操作性。