如何处理 PLC 厂商扩展：IEC 61131-3 中的 UDT 与 USER_DEFINED

IEC 61131-3 标准化了 PLC 编程语言，但并未统一完整的跨厂商运行时行为。复杂数据结构（如 UDT、DUT 以及厂商特定的用户自定义类型）在内存布局和块访问方面仍具有实现依赖性。OLLA Lab 提供了一个受限的仿真环境，用于在部署到特定厂商设备前，练习数据映射、标签结构化和逻辑验证。

符合 IEC 61131-3 标准并不等同于代码可移植性。该标准定义了语言系列和核心语义，但将重要的运行时和内存细节留给了各厂商自行实现，而这恰恰是跨平台迁移容易失败的地方。

一个实用的修正观点是：大多数迁移失败并非由启动电机的梯形图引起，而是由包裹在它周围的结构引起的。在 Ampergon Vallis 的一项内部基准测试中，68% 的模拟跨平台迁移失败与嵌套用户自定义数据结构不匹配、填充冲突或地址模型假设有关，而非核心梯形图语法错误 [方法论：n=512 次模拟迁移任务，涉及多标签结构和 I/O 重映射；基准比较器 = 仅语法梯形图验收；时间窗口 = 2025 年 1 月至 2026 年 2 月]。这支持了一个狭义的结论：数据建模是迁移演练中的主要故障点，但这并不证明存在一个普遍的行业失败率。

这种区别至关重要，因为语法易于理解却难于部署。内存布局是一个更隐蔽的问题，通常在调试阶段才会显现。

IEC 61131-3 标准化的是编程语言，而非完全一致的厂商行为。它定义了梯形图 (LD)、功能块图 (FBD)、结构化文本 (ST)、顺序功能图 (SFC) 等语言及相关类型概念，但允许在影响执行、存储和互操作性的领域存在实现依赖性。

在实践中，“实现依赖性”绝非脚注，而是厂商在以下方面做出不同决策的关键点：

• 数据对齐和填充，
• 字节序和存储约定，
• 优化访问与绝对内存访问，
• 编译器对结构体和嵌套类型的处理，
• 保持性行为，
• 库特定的功能块实现。

这就是为什么两个控制器都可以被称为符合 IEC 61131-3 标准，但在复杂结构的存储或寻址方式上却可能存在分歧。

由此得出一个有用的工程定义：可移植逻辑并非指在两处都能编译的逻辑，而是指其数据假设、执行假设和接口假设在两个编译器下均能成立的逻辑。 这比大多数营销语言所暗示的标准要高得多。

标准实际上留下了哪些开放空间？

该标准在多个与数据结构和互操作性相关的领域为厂商特定的实现留下了空间。根据版本和厂商文档，这通常包括：

• 数据类型的内部表示，
• 结构体打包和对齐，
• 变量和块的访问方法，
• 任务和扫描行为细节，
• 库和运行时扩展。

结果很直接：类型声明看起来可能符合标准，但底层的内存行为却并非如此。

为什么这在实际系统中很重要？

这很重要，因为外部接口不会与你的假设进行协商。Modbus 寄存器映射、OPC UA 客户端、HMI 面板或 PLC 间的数据交换都期望对数据有稳定的解释。如果一方填充了 `BOOL` 字段或为了优化访问而重新排列了结构，逻辑可能仍然可以编译，但过程数据却可能在底层发生了偏移。

这类错误往往能通过代码审查，却在启动时暴露出来。

关键区别不仅在于命名，还在于各厂商如何将自定义类型绑定到内存、访问规则和工具行为上。

不同的生态系统对大致相同的概念使用不同的术语：

厂商术语细分

- Rockwell Automation (Studio 5000):

• 使用 用户自定义数据类型 (UDTs)。
• UDT 是 Logix 标签建模的核心。
• 内存行为和成员对齐遵循厂商特定的编译器规则。
• 集成商在与非 Rockwell 系统交换打包数据时，经常会遇到对齐假设问题。

- Siemens (TIA Portal):

• 在通用工程语言中使用 PLC 数据类型 和 UDTs。
• “优化的块访问”可能会改变数据在内部的排列方式。
• 这提高了 Siemens 环境内部的效率，但可能会破坏依赖于固定绝对偏移量的工作流。
• 如果外部系统期望旧式的固定地址，优化访问将无济于事。

- 基于 Codesys 的平台（包括许多实现中的 Beckhoff 和 WAGO）:

• 通常使用通过 `TYPE ... END_TYPE` 声明的 DUTs (Data Unit Types)。
• 语法风格是标准化的，但运行时打包和目标行为仍取决于平台和编译器。
• 跨目标的可移植性仍然是有条件的，而非自动的。

- 其他厂商环境:

• 可能使用 `STRUCT`、`USER_DEFINED`、自定义记录类型或平台特定的对象模型等术语。
• 命名差异远不如由此产生的存储和访问行为重要。

工程师应关注的操作性区别是什么？

操作性的区别在于：用户自定义类型不仅仅是一种命名便利，它是一份关于数据形状、成员顺序和访问预期的契约。 如果两个系统对该契约存在分歧，即使梯形图本身完全正常，围绕该数据的逻辑也会变得不可靠。

工程师往往在这里混淆了语言兼容性和可部署性。前者是文本层面的，后者是物理层面的。

内存填充通过改变结构体内字段的预期位置来破坏标准化逻辑。逻辑可能在语法上仍然有效，但任何假设不同字节或字布局的接口都可能读取到错误的值。

考虑以下简化声明：

TYPE Motor_Control_DUT : STRUCT Start_Cmd : BOOL; ( 根据厂商可能存在填充 ) Speed_Ref : REAL; ( 32 位 ) Fault_Code : INT; ( 16 位 ) END_STRUCT END_TYPE

此声明看起来很简单，但在内存中并非普遍简单。

一个编译器可能会将 `Start_Cmd` 放入打包的位位置，并将 `Speed_Ref` 紧接在下一个有效边界之后。另一个编译器可能会将 `REAL` 对齐在 32 位边界上，并在 `BOOL` 之后插入填充。第三个编译器可能会以一种使绝对偏移量对外部消费者不安全的方式优化块内的结构。

一个具体的故障模式

一种常见的故障模式出现在基于寄存器的通信中。

• 发送控制器将结构暴露给 Modbus TCP 映射。
• 工程师假设 `Start_Cmd`、`Speed_Ref` 和 `Fault_Code` 占据连续的预期偏移量。
• 接收控制器使用其自身的编译器规则导入或重构相同的概念结构。
• 由于第一个平台填充了 `BOOL` 字段，`REAL` 落在了一个不同的偏移量上。
• 接收端现在读取到损坏的速度参考数据，或者将浮点值的一部分解释为故障代码。

梯形图可以是“正确”的，但机器的行为仍然可能不正确。这就是数据不对齐的实际后果。

为什么嵌套类型使情况更糟

嵌套结构会成倍增加风险，因为每个子结构都可能引入其自身的对齐行为。一个简单的电机对象可能易于管理，但一个包含命令、允许条件、报警、模拟量值、PID 参数和状态字的过程撬块对象则变得脆弱得多。

故障模式是可以预测的：

• 父结构层面的一个错误假设，
• 子结构中隐藏的一个对齐规则，
• 基于绝对偏移量构建的一个外部映射，
• 一个漫长的调试日。

实际差异体现在工程师定义、访问和交换结构化数据的方式上。

Rockwell Automation

Rockwell UDT 被大量用于可重用的设备模型、面板和 AOI 相关的标签组织。在实践中，工程师通常围绕 Logix 标签结构进行设计，这些结构在 Rockwell 生态系统内部非常整洁，但在暴露给第三方系统时需要刻意进行重映射。

实际影响包括：

• Logix 项目内部的强一致性，
• 在电机、阀门和设备对象模式中的频繁使用，
• 映射到外部协议或非 Rockwell 消费者时需要格外小心，
• 应验证而非猜测对齐和打包假设。

Siemens

Siemens 在标准风格访问和优化块访问之间引入了重要区别。优化访问可以改善内存使用和内部性能，但对于期望固定偏移量的外部系统，它降低了地址透明度。

实际影响包括：

• 结构化数据的高效内部处理，
• 旧式绝对地址假设的可靠性降低，
• 需要明确决定外部互操作性或内部优化孰轻孰重，
• 在集成期望稳定地址的 HMI、历史数据库或对等 PLC 时需格外谨慎。

Codesys 及相关平台

Codesys 风格的 DUT 提供了一种熟悉且灵活的类型声明模型。它们对于结构化工程、可重用库和机器抽象非常强大。然而，它们并不能保证另一个目标会以相同方式存储该结构。

实际影响包括：

• 清晰的类型声明语法，
• 在受限平台假设内的可移植性，
• 目标特定的运行时差异仍然相关，
• 跨厂商边界时需要进行明确验证。

“直接迁移”通常会失败，因为工业控制软件与硬件行为、内存模型、I/O 约定、扫描假设和厂商工具紧密耦合。逻辑只是系统的一层。

迁移通常要求工程师协调至少五个方面：

• 类型系统： UDT、DUT、结构体和块约定各不相同。
• 寻址模型： 绝对寻址、符号寻址、优化寻址和协议暴露布局各不相同。
• 指令行为： 定时器、计数器、PID 块和库函数在语义上并不总是完全一致。
• I/O 绑定： 现场设备、缩放和诊断位是平台特定的。
• 调试假设： 启动顺序、故障复位行为和允许条件处理通常编码在厂商原生的模式中。

因此，诚实的说法是：工业界不存在值得在实时流程上信任的“复制粘贴式迁移”。只有翻译、验证和风险降低。

仿真就绪应从操作层面而非理想层面来定义。一名具备仿真就绪能力的工程师能够在控制逻辑到达实际流程之前，证明、观察、诊断并强化控制逻辑以应对现实的过程行为。

对于跨平台数据结构工作，这意味着工程师能够：

• 清晰地定义结构化标签和嵌套成员，
• 追踪梯形图状态与设备状态之间的因果关系，
• 验证在正常和异常条件下的预期行为，
• 识别数据假设在何处依赖于厂商特定的打包或访问规则，
• 在注入故障后修改逻辑或映射，
• 在部署前记录“正确”的定义。

这与仅仅能够编写梯形图是不同的。语法是必要的，但不是终点。

这种框架与关于基于仿真的验证、工业系统中数字孪生的使用以及作为复杂自动化环境中风险降低措施的预部署验证的更广泛工程文献相一致（例如 Fuller 等人，2020 年；Jones 等人，2020 年；以及 IEC 61508 关于系统性风险降低的原则）。

OLLA Lab 通过提供一个受限环境来帮助工程师在进入厂商特定的 IDE 约束之前，演练结构化标签设计、仿真和故障感知验证。它不是一个通用的代码翻译器，也不应被视为翻译器。

它的价值在于更狭窄且更可信的领域：它让工程师能够练习迁移工作真正需要的工程习惯。

OLLA Lab 在此工作流中的作用

在产品记录的范围内，OLLA Lab 提供：

• 基于 Web 的梯形图逻辑编辑器，
• 用于运行和停止逻辑的仿真模式，
• 用于监控和调整标签、I/O、模拟量值及相关状态的变量面板，
• 基于场景的工业练习，
• 用于根据建模设备验证行为的数字孪生式仿真上下文。

对于本文的用例，变量面板最为重要，因为它允许工程师在面对厂商特定的编译和映射规则之前，在硬件无关的环境中定义和检查结构化变量。

此处“厂商无关”的含义

厂商无关并不意味着厂商无关的部署。它意味着练习环境不会强迫学生在学习因果关系、顺序和标签架构的同时，还要一次性学习 Rockwell、Siemens 和 Codesys 的内存规则。

这种分离很有用，因为初学者和初级工程师往往会同时因为两个原因而失败：

• 他们还不理解控制行为，
• 且他们已经深陷于平台特定的细节中。

工作流是先建模控制行为，再建模数据形状，最后在仿真下验证因果关系。

第 1 步：定义原始控制逻辑

在编辑器中使用场景所需的指令集构建梯形图逻辑：

• 常开/常闭触点和线圈，
• 定时器和计数器，
• 比较器和数学块，
• 相关情况下的模拟量和 PID 元素。

在此阶段，专注于顺序和因果关系。电机启动允许链在担心特定厂商如何填充子结构之前，应先表现正确。

第 2 步：在变量面板中构建结构化标签

使用变量面板创建反映设备或过程对象的嵌套标签模型。例如：

• `Motor_Status.Running`
• `Motor_Status.Faulted`
• `Motor_Command.Start`
• `Motor_Command.Stop`
• `Motor_Analog.Speed_Ref`
• `Motor_Alarm.Overload`

这就是 OLLA Lab 具有操作价值的地方。工程师可以练习命名规范、对逻辑相关成员进行分组，并观察梯形图状态如何映射到设备状态。

第 3 步：仿真并观察状态变化

运行仿真并切换输入，同时观察输出和变量。

检查：

• 预期的转换，
• 失败的允许条件，
• 报警行为，
• 模拟量响应，
• 顺序定时，
• 预期状态与实际标签行为之间的不匹配。

一次好的仿真会话回答了一个简单的问题：当过程发生变化时，逻辑是否因正确的原因而改变？

第 4 步：注入异常条件

引入故障案例，例如：

• 证明反馈失败，
• 模拟量高高报警跳闸，
• 运行期间允许条件丢失，
• 启动确认延迟，
• 命令状态陈旧。

目的是验证当过程不再配合时，结构和逻辑是否仍然合理。

第 5 步：修改逻辑并记录映射假设

在故障出现后调整梯形图、标签分组或状态处理。然后记录哪些假设是可移植的，哪些在以后需要厂商特定的处理。

最后这一步是练习与证据的区别。

初级工程师应该建立一套紧凑的工程证据，展示推理、验证和修订过程。截图是辅助工件，它们不是论点本身。

使用以下结构：

1. 系统描述 定义机器或过程对象、其目的、主要状态和关键 I/O。
2. “正确”的操作定义 用可观察的术语说明正确行为的含义。例如：“泵仅在主使能、低吸入跳闸清除且远程启动命令为真时启动；故障保持锁定直到复位。”
3. 梯形图逻辑和仿真设备状态 展示相关的梯形图以及标签、输出或建模设备中相应的仿真状态变化。
4. 注入的故障案例 描述引入的异常条件以及它在操作上为何重要。
5. 所做的修订 解释在观察到故障后，逻辑、标签结构或顺序处理发生了什么变化。
6. 经验教训 记录工程结论，特别是在数据建模、顺序或接口假设产生风险的地方。

这种格式在培训中很有用，因为它展示了调试判断力，而不仅仅是图表识读能力。雇主不需要更多绿色位的截图，他们需要证据证明工程师在过程出现异常时能够进行思考。

数字孪生验证在被定义为部署前针对真实机器或过程模型进行行为检查时才有用。当它被视为附加在未经测试的逻辑上的装饰性 3D 场景时，它是没有用的。

在 OLLA Lab 等受限培训环境中，数字孪生式仿真有助于工程师比较：

• 梯形图状态，
• I/O 状态，
• 模拟量行为，
• 顺序进度，
• 以及建模设备的响应。

这种比较很重要，因为调试失败往往是关联性的。梯形图在孤立状态下看起来没问题，但过程顺序却有问题。

工业数字孪生和基于仿真的工程研究一致支持虚拟验证在降低后期集成风险、提高系统理解力以及在适当范围内支持操作员或工程师培训方面的价值（Fuller 等人，2020 年；Tao 等人，2019 年）。功能安全指南也强化了一个更广泛的原则：系统性故障应通过严谨的设计和验证尽早发现，而不是在工厂现场才被发现（IEC 61508；exida，2024 年）。

现场翻译很简单：如果故障能在启动前被发现，那就是发现它的正确时间。

工程师应将 OLLA Lab 视为演练环境，然后在部署前执行明确的厂商特定翻译和验证。

使用此移交清单：

• 确认目标平台的类型系统和命名约定，
• 验证结构打包和对齐行为，
• 决定外部系统是否需要固定寻址，
• 审查优化访问与标准块访问设置，
• 明确映射协议暴露的数据，
• 验证模拟量缩放和工程单位，
• 对比定时器、计数器和 PID 行为与目标语义，
• 在厂商环境中再次运行故障案例，
• 记录翻译过程中发生变化的任何假设。

这是从仿真到部署的严谨路径。它比一厢情愿慢，但比糟糕的启动快。

- 向下： 在 OLLA Lab 中练习此工作流。

• 向上： 探索完整的梯形图逻辑掌握中心。
• 横向： 相关文章 1。
• 横向： 相关文章 2。
• 横向： 相关文章 3。

- IEC 61131-3: 可编程控制器 — 第 3 部分 - IEC 61508 功能安全标准系列 - exida 功能安全与验证资源 - NAMUR NE 107 状态信号推荐 - 工业中的数字孪生：最新技术 (DOI)