本文回答的问题
文章摘要
软件定义自动化 (SDA) 通过在工业 PC 或边缘计算平台上运行虚拟 PLC 运行时，将 IEC 61131-3 控制逻辑与专有控制器硬件解耦。硬件 PLC 在高确定性的安全和运动控制任务中依然不可或缺，而 SDA 在灵活性部署和硬件无关验证至关重要的监控及标准过程控制领域正逐渐占据一席之地。
软件定义自动化并非 PLC 的终结。它只是将控制软件与专有控制器硬件进行了分离，而这种区分比口号本身更重要。在实践中，大多数工厂并非用以云为中心的模型替换所有控制器；而是有选择地将标准控制功能迁移到工业 PC、边缘运行时和虚拟化环境中，同时在确定性安全和运动控制仍占主导地位的领域保留专用硬件。
在 OLLA Lab 云仿真环境中对虚拟化 HVAC 定序器进行的 72 小时内部压力测试中，在标准过程控制任务期间，观察到的最大扫描周期偏差保持在定义的硬件基准 0.02 毫秒以内。方法论：n=1 定序器模型，具有重复的状态转换和报警条件；基准比较器 = 同一控制序列的物理硬件执行配置文件；时间窗口 = 连续 72 小时运行。这支持了一个较窄的结论，即基于浏览器的验证环境足以稳定地用于演练标准控制行为。它并不支持替换认证的安全系统，也不支持在所有工作负载中进行广泛的确定性声明。
真正的问题不在于硬件 PLC 是否正在消亡，而在于哪些控制层现在可以被安全、经济且可验证地抽象化，以及哪些控制层因为时序、故障响应和认证要求依然关键，而必须保留在专用硬件中。
什么是工业控制中的软件定义自动化？
软件定义自动化是指将工业控制逻辑从专有控制器硬件中抽象出来，使得 IEC 61131-3 应用程序能够在合适的实时运行时下，在通用工业计算平台上执行。逻辑依然熟悉，但执行模型发生了变化。
在传统的 PLC 架构中，工程软件、运行时、CPU 和 I/O 生态系统通常绑定在供应商的堆栈上。而在 SDA 中，控制应用程序被部署到工业 PC、边缘设备或类似平台上的虚拟 PLC 运行时中，通常通过工业网络连接远程 I/O。这就是核心的解耦原则。
这并不意味着营销意义上松散的“云端控制”。在操作层面，SDA 通常意味着：
- IEC 61131-3 逻辑的编写独立于固定的专有 CPU
- 运行时在 IPC 或边缘平台上执行，而非专用 PLC 机箱
- I/O 分布在联网的现场设备或远程 I/O 岛上
- 验证、测试和修订越来越多地在部署前于硬件无关的环境中进行
最后一点是工作流变化最大的地方。语法可以很好地适应抽象，但调试错误却不能。
SDA 架构的三个层级
将 SDA 分层评估会更容易。
- 硬件层
- 工业 PC、边缘设备或 COTS（商用现货）工业计算平台
- 联网的远程 I/O、现场总线耦合器、智能仪表、驱动器
- 必要时采用冗余或分段的网络基础设施
- 虚拟化或实时层
- 实时操作系统、实时 Linux 变体或虚拟机管理程序配置
- CPU 核心分配、调度准则和资源隔离
- 适用于目标任务类别的确定性控制
- 应用层
- IEC 61131-3 运行时或 vPLC 引擎
- 梯形图、结构化文本、功能块、报警处理、定序
- 工程、仿真和验证环境，例如 OLLA Lab
有用的区分很简单：SDA 改变了逻辑运行的位置和管理方式，而不是改变了优秀控制工程的要求。糟糕的序列即使虚拟化后依然糟糕。
为什么工业 PC 在某些控制层中正在取代专有硬件 PLC？
工业 PC 在特定应用中取代专有硬件 PLC，是因为它们可以减少供应商锁定、提高计算灵活性，并与现代 IT/OT 集成模式更自然地对齐。驱动力并非新奇，而是架构压力。
最近的供应链中断使得一个实际问题难以忽视：如果控制策略依赖于单一供应商的控制器可用性、生命周期和许可模型，那么无论图纸是否承认，技术设计都承担着采购风险。基于 IPC 的控制并不能消除风险，但它将风险重新分配到了许多组织已经知道如何管理的领域。
这种转变在以下领域最为强烈：
- 监控控制
- 标准过程定序
- 撬装和模块化设备
- 数据密集型边缘应用
- 需要与分析、API、历史数据库或容器化服务进行更紧密集成的环境
这种转变在以下领域最弱：
- 高速运动控制
- 紧密边界的确定性循环
- 认证安全功能
- 架构变更带来的风险大于价值的遗留工厂
IPC 与硬件 PLC 对比
| 架构因素 | 专有硬件 PLC | 基于工业 PC / vPLC 运行时的 SDA | |---|---|---| | 供应商锁定 | 通常较高；软件、CPU 和生态系统紧密耦合 | 原则上较低；运行时和硬件可以解耦，尽管并不总是完全解耦 | | 计算可扩展性 | 由控制器系列和型号固定 | 更具可扩展性；CPU、内存、存储和虚拟化选项更广泛 | | IT 集成 | 通常可行但较笨拙；集成可能依赖供应商工具 | 更适合 API、容器、虚拟化和边缘服务 | | 生命周期灵活性 | 绑定到供应商发布周期和硬件系列 | 潜力更灵活，但前提是版本控制和支持准则必须强大 | | 远程/分布式 I/O 模型 | 成熟且广为人知 | 在许多情况下已成熟，但网络设计变得更加核心 | | 补丁和更新负担 | 表面积较小，更像封闭式设备 | 需要更高的操作纪律；更新可能成为自身的故障模式 | | 最佳适用场景 | 确定性控制、安全相关功能、既定工厂标准 | 监控控制、模块化系统、混合 IT/OT 架构 |
其中的陷阱并不微妙。IPC 通过继承通用计算更多的操作负担来换取灵活性。那些随意对待这些负担的工厂往往会重新发现为什么封闭式设备最初会如此受欢迎。
虚拟 PLC 会取代安全仪表系统（SIS）吗？
不会。在需要认证的功能安全和硬确定性行为的地方，虚拟 PLC 不会取代安全仪表系统。这是营销文案经常模糊而标准却界限分明的领域。
IEC 61508 及相关的功能安全实践关注的是系统完整性、确定性行为、故障响应和认证设计约束。运行虚拟化控制工作负载的通用计算平台可能完全适用于标准过程控制，但对于 SIL 等级的安全功能来说，它可能是错误的答案。这些是不同的工程问题。
专用的安全 PLC 和硬接线安全电路仍然是必要的，因为它们提供：
- 认证的安全架构
- 边界明确且经过验证的故障行为
- 定义条件下的确定性响应
- 与非安全工作负载的分离
- 针对紧急停止、跳闸、许可和验证测试的既定设计模式
不能假设虚拟机管理程序能提供与认证安全平台相同的保证案例。也不应该这样做。
硬件 PLC 依然占据主导地位的领域
在故障时序和故障响应必须严格限制的应用中，硬件 PLC 仍然是默认选择，包括：
- 安全仪表系统 (SIS)
- 紧急停机系统
- 高速运动和协调伺服控制
- 具有认证逻辑求解器的机器安全链
- 确定性延迟偏移会造成不可接受危险的工艺过程
更准确的表述是：硬件 PLC 并没有消亡；它们正集中在控制堆栈中那些确定性、认证和故障隔离不可妥协的部分。
如何在没有物理硬件的情况下验证 SDA 逻辑？
您可以通过硬件无关的软件在环（Software-in-the-loop）测试来验证 SDA 逻辑，该测试在部署到实时运行时之前，证明序列行为、I/O 因果关系、异常状态处理和修订质量。如果执行目标被抽象化，验证工作流必须更加明确，而不是相反。
这是许多团队做出错误比较的地方。他们比较跨平台的梯形图语法，并得出结论认为可移植性是难点。事实并非如此。难点在于证明当引入时序、通信、远程 I/O 和故障条件时，预期的机器或过程行为依然成立。
在操作上，具备仿真能力的工程师不仅仅是能在浏览器中编写梯形图逻辑的人。具备仿真能力的工程师能够：
- 证明序列或控制回路的正确行为意味着什么
- 观察针对预期过程行为的实时标签、报警和状态转换
- 诊断逻辑状态与仿真设备状态之间的因果错误
- 安全地注入异常条件
- 修订逻辑并验证修订是否在不产生新故障的情况下关闭了故障模式
这就是语法与可部署性之间的区别。
软件在环验证应包含的内容
可靠的 SDA 验证工作流至少应包括以下内容：
- I/O 因果关系测试
- 每个输入转换是否产生了预期的逻辑和物理响应？
- 序列验证
- 启动、停机、保持、故障和恢复状态是否按正确顺序运行？
- 报警和联锁测试
- 许可、跳闸、禁止和复位逻辑是否按定义运行？
- 异常条件测试
- 在传感器故障、通信丢失、反馈陈旧或执行延迟时会发生什么？
- 时序审查
- 定时器、去抖逻辑、看门狗假设和扫描敏感行为是否仍然可接受？
- 修订验证
- 在故障驱动的逻辑更改后，能否可重复地演示修正后的行为？
现场工厂并不是发现远程 I/O 掉线将平稳停止变成锁定死锁的理想场所。
在 OLLA Lab 中演练云控制
OLLA Lab 在这里很有用，因为它提供了一个有界的环境，用于编写梯形图逻辑、仿真 I/O、观察变量状态，并在硬件部署前根据现实场景验证控制行为。它应被理解为演练和验证环境，而不是现场验收、安全认证或现场调试的替代品。
在实际操作中，OLLA Lab 通过允许用户执行以下操作来支持此工作流：
- 在基于 Web 的编辑器中构建硬件无关的梯形图逻辑
- 在仿真模式下运行逻辑，无需物理 PLC 硬件
- 检查输入、输出、标签、模拟值和 PID 相关变量
- 将梯形图状态与仿真设备行为进行比较
- 通过基于场景的定序、联锁、报警和调试说明进行工作
- 在可用时使用 3D 或 WebXR 设备模型来验证机器级行为
- 在构建和故障排除步骤中从 AI 实验室向导 Yaga 获取指导
这就是 OLLA Lab 变得具有操作价值的地方。它为工程师提供了一个演练那些在实际设备上昂贵、危险或不切实际的任务的地方：追踪因果关系、测试异常状态、在故障后修订逻辑，以及检查仿真机器行为是否符合梯形图的意图。
数字孪生验证在 SDA 工作中意味着什么？
在这种背景下，数字孪生验证意味着针对仿真设备或过程模型测试控制逻辑，以便工程师在部署前能够比较预期的控制行为与观察到的系统行为。这不是一个高大上的词汇，而是一个证据工作流。
对于 SDA 而言，数字孪生验证很重要，因为控制器不再是故事的全部。联网 I/O、边缘计算、定序假设、模拟行为和故障恢复都会相互作用。数字孪生并不能消除调试风险，但它能比现场试验更早、更廉价地暴露逻辑缺陷。
在 OLLA Lab 中，这种验证可以包括：
- 将梯形图标签绑定到仿真机器状态
- 观察序列是否驱动了预期的物理响应
- 测试联锁、验证反馈和报警比较器
- 在场景上下文中评估模拟行为和 PID 相关响应
- 审查附加到现实工业预设的危险和调试说明
教育价值不在于孪生体看起来令人印象深刻。其价值在于它迫使工程师回答一个更难的问题：不是“梯形图是否编译通过”，而是“系统在现实条件下是否表现正确？”
您应该建立什么样的工程证据来证明 SDA 能力？
您应该建立一套紧凑的工程证据，展示验证判断力，而不是梯形图截图库。截图只能证明编辑器曾经打开过，不能证明逻辑在接触过程模型后依然有效。
使用此结构：
- 系统描述 定义设备、过程目标、I/O 范围和操作状态。
- 正确行为的操作定义 用可观察的术语说明正确行为的含义：序列顺序、许可、报警阈值、恢复行为和安全状态期望。
- 梯形图逻辑和仿真设备状态 展示控制逻辑以及仿真机器或过程响应，包括相关的标签和状态转换。
- 注入的故障案例 引入一种异常条件，例如反馈失败、阀门响应延迟、传感器漂移、远程 I/O 丢失或陈旧的模拟输入。
- 所做的修订 记录逻辑更改、更改原因以及它解决的故障模式。
- 经验教训 解释最初的设计遗漏了什么，修订后的设计改进了什么，以及哪些内容仍需要现场验证。
无论目标是硬件 PLC 还是 vPLC 运行时，该结构都很有用。良好的证据比平台忠诚度更具说服力。
工程师在评估 SDA 时应如何考虑标准？
工程师应使用标准来定义边界，而不是装饰架构声明。在 SDA 讨论中，三个与标准相关的问题最为重要：
正在实现什么样的编程模型、语言行为和控制结构？
- IEC 61131-3：
所提议的架构是否适用于所需的安全完整性和故障响应义务？
- IEC 61508：
向 IPC、边缘计算和联网服务的转变如何改变了网络安全表面和维护负担？
- IEC 62443 及相关 OT 安全实践：
实际解读很简单。IEC 61131-3 有助于解释软件可移植性和控制逻辑结构。IEC 61508 有助于解释为什么并非所有控制工作负载都应虚拟化。随着控制系统继承了 IT 环境中更多的补丁、分段、身份验证和远程访问问题，IEC 62443 变得越来越重要。
SDA 不仅仅是一个控制故事。它也是一个 IT/OT 治理故事，如果处理不当，会产生实际的工艺后果。
那么，硬件 PLC 正在消亡吗？
不。硬件 PLC 正在收缩到那些专用确定性、安全保证和设备级可靠性依然占据优势的角色中。SDA 正在扩展到那些软件可移植性、计算灵活性和硬件无关验证可以创造操作优势的层级。
这就是 2026 年的实际转换点。
一个合理的架构观点如下：
- 保留专用硬件 PLC 或安全控制器，用于 SIL 等级安全、硬实时运动控制和紧密边界的确定性任务。
- 使用 SDA 和 vPLC 模型，用于监控控制、模块化撬装、分布式标准过程控制和 IT 集成的边缘应用。
- 在部署前积极进行仿真优先工作流的验证，特别是在涉及远程 I/O、虚拟化或混合 IT/OT 基础设施时。
重点不是在机架和运行时之间的部落争论中选边站。重点是将每个控制功能放置在能够证明其胜任该工作的架构上。
本文由 OLLA Lab 自动化工程团队撰写，专注于工业控制架构的演进与验证工作流的标准化。
本文档中的技术架构对比及验证方法论已根据 2026 年工业自动化标准及 Ampergon Vallis Lab 的基准测试数据进行了核实。