新闻中心
工业控制即服务
工业控制即服务 （ICaaS） 的概念有可能会将 IT 和 OT 世界更紧密地结合在一起。 它产生是为了让工厂所有者/运营商缩短产品的上市时间并降低其复杂性，同时还希望可以轻松集成 AI 等先进技术于其内。本文将介绍不同 ICaaS 的概念验证。此外也概括了其未来的机会。
当前的生产工厂所有者/运营商面临着调试、维护和管理日益复杂的自动化系统的挑战。根据过往的经历，现在的自动化系统必须满足越来越多的要求，包括实时通信、架构灵活性、跨供应商兼容性到 AI 集成、OT 安全、符合 NIS 2 法规等。与此同时，对市场趋势做出更快、更精确反应的愿望正在推动降低其自动化系统的复杂性、减少新品上市时间、重新配置和更新的时间。简而言之：未来的自动化系统在应该更强大的同时，还需要简化系统的调试和维持的方法。
我们可以通过之前发表的文章来查阅ICaaS的概念是如何能够支持上述目标的实现。本文我们来看一下对其概念的验证，即从实施结果来总结一下 ICaaS 概念的经验教训。
ICAAS 的要求和概念
当今各类经典的可编程逻辑控制器（PLC）或软 PLC 应用程序主要通过优化来使其尽可能可靠。问题在于由此所产生的架构往往使新技术难以适应、扩展或集成到自动化系统中。因此，多数的行业公司越来越想寻找能够快速 调试、更新和扩展现代化的系统，以便在更短的时间内更快地响应市场趋势。
特别是，当前 IT 和 OT 仍有众多使用不合适的软件和硬件结构的情况，这使得从现场到企业资源规划（ERP）层级的端到端自动化系统管理变得非常困难。与此同时，大规模使用模型预测控制 （MPC）或 AI 等高技术功能则要求显著增加自动化系统的存储和计算资源。尽管如此，传统 PLC 系统的核心要求，如高性能系统、可靠性和实时运算能力仍然必须得到满足。
ICaaS 方法的特点在于其取消了经典的自动化金字塔结构，取而代之的是完全容器化的结构（见图 1）。这种方法通过将 PLC 的集中处理和功能移植到了云或基于服务器的环境中，并彻底改变了 PLC 的概念。让符合 IEC 61131-3 标准的 PLC 运行系统、人机界面（HMI）系统、数据库和云端连接器完全闭环。服务器基础设施可以位于公司内部（本地）和异地（off-premises）上。在这个云中，自动化元素不一定必须排列在金字塔的刚性分层中。相反，自动化组件之间的逻辑安排和交互可以根据具体应用进行优化
从技术上讲，ICaaS 可通过云端方法在本地或异地实施设置来有效保护该虚拟网络。在这个网络中必要的软件组件能够根据需要激活，并且可以使用标准化的通信协议彼此交换数据。对于最终用户，这意味着企业的 PLC、SCADA 或 DCS 系统的所有活动的或非活动的实例都会清晰地显示，让这些实例可以单独或分组进行管理。ICaaS 和传统控制系统之间最大的区别在于传感器和执行系统的连接方式。在最简单的场景中，前者会通过以太网进行连接，而不是直接或通过远程 I/O 连接到物理设备，在外部应用场景中，该以太网也可以使用互联网，例如采用通过安全的 VPN 连接，或通过 MQTT（TLS）的安全 OPC UA 来发布/订阅信息。然而，在工业环境中，通常还需要更复杂的通信设置来满足实际系统应用的各种要求。其他通信渠道，如 5G 在内也是可能选用的。这里唯一的限制因素是可容忍的最大延迟时间，在生产过程行业中对此要求通常很低，通常允许的周期时间为 30ms-500ms。
此外，ICaaS 概念还需要和已有的概念兼容，例如通过模块类型包（MTP）共同实现自动化的模块化工厂。目前正在开发的标准，如时间敏感网络也要求可以集成在内。由此衍生出数种理论或行业方法来实施 ICaaS 系统。
尽管已有各类的研究出版物和项目，但 ICaaS 迄今尚未在行业中得到广泛采用 。一个核心问题是容器化或“X-as-a-Service“，这对于生产行业来说并不那么熟悉。另一个问题是所用技术的感知就绪水准（TRL），ICaaS给人的印象是，该应用到今天还无法满足行业所需要的可靠性和性能，其实施标准存疑。
使用案例：ICAAS
为了调查上述 ICaaS 概念的全球化优势和局限性，我们选择了一个 ICaaS 用例。该用例旨在开发一个完全由云控制的模块化流程自动化系统。选择一种垂直栽培模型来论证这一点（见图 2）。为了尽可能简化 ICaaS 系统的部署，几乎所有的智能设备都从系统移除。 只剩下传感器、执行器、人机界面和远程 I/O（RIO），这意味着该模块可以预连线方式交付，用户只需将在安装后其连接到互联网。然后 RIO 自动将其连接至在云上的 MQTT 代理，然后 MQTT 代理又再连接到运行软 PLC 的云服务器上。在每个控制周期中，RIO 会从传感器收集信息，并通过 OPC UA Pub/Sub 将 MQTT 格式的信息通信到云上的软 PLC。该 PLC 会处理这些数据并输出执行相关的控制，并将控制信号发送回 RIO，最后RIO 将它们分配给执行机构。
但是，为什么会首先选择 OPC UA Pub/Sub 呢？目的之一是降低控制系统的复杂性。从图 1 中可以看出，不同的自动化的组件 （Control，SCADA，MES 等）应以更紧密、更无缝地工作为准则。因此，通过一个标准的通用协议进行通讯显然是明智的选择。IT 行业已经确立将以太网与 TCP/IP 协议一起作为其众多组件的通用标准。让人高兴的是传统的控制技术可以通过各种技术进行通信，以太网包含其中。这类信息交互的协议之一就是 OPC UA，它有包含信息模型，允许对整个系统的信息分层表述，并可满足互联网通信所需的安全要求。
在 OPC UA 上使用MQTT 的发布/订阅架构可以带来额外的优势。使用 MQTT 代理会有一个集中通信中心。这样，对带有身份验证和授权数据访问的处理就不必在（受限制的）现场设备上进行，而只要在代理上处理即可。不仅如此，它还具有优于客户端/服务器方法的传输性能。因此，基于 MQTT 的 OPC UA PubSub 可将主权信息建模与轻量级通信性能相结合。
在 RIO 内包括有一个紧凑的边缘设备作为 IoT 耦合器，这可以实现关键逻辑运算例如本地互锁功能。这意味着关键的逻辑控制并不严格依赖外部云端资源，确保可以在通信失联的情况下继续使用本地计算资源进行工作。
可以从 RIO 的本地人机面板上的任意浏览器进行系统显示和作业。该响应模式设计使其可以在任意支持浏览器的设备（如智能手机或平板电脑）上显示。因此，此用例提供了一种非常灵活的轻松安装和扩展HMI 解决方案。
如图 3 所示，该架构还可用于实施支持应用 MTP 的控制环境。它可通过 MQTT 代理来支持 RIO，该功能也可按 MTP 标准使用其功能和服务，并将它们从硬件中抽象建模。让 MTP 模块实例可以动态创建，然后集成到流程编排层 （POL），创建独立于供应商所提供硬件之外的模块组合。
此外，该方案还可以实现容器化的解决方案，这会使其部署过程更加简单。这个方法确保了可优化可用计算能力的使用，同时仍然使模块独立提供给 POL。让未曾使用的模块可以在需要时关闭并重新启动。
经验教训
案例研究表明，在不久的将来，将有可能完全从云端控制过程生产工厂。现场设备不再需要执行大部分的控制逻辑，而专注于数据和信息输入和输出工作。系统仅需连接到云端的原生技术堆栈即可正常运行。尽管如此，研究中提出的垂直栽培模型仍要求具备非常低的延迟要求。而过程工业中的其他生产系统则要求更严格的循环时间，通常在 30-500 毫秒之间。
同样明显的是，这些用例可以通过标准产品和 TRL 不断地增加其产品组合来实现。此外所实施的系统可以满足上述广泛的要求。尽管如此，这些系统的可靠性以及纳入更高级的 CI/CD 功能后仍可能需要进一步的改善。
总结与展望
前述强调了如何在不断增加的 TRL（目前大致为 TRL 4-5）的情况下实施 ICaaS 方法，以及目前什么是能够现实的。这些结果证明目前还仅允许在某些特定的、特别是具有较低的延迟要求的应用上才能够部署此类系统。未来应当可能还需要了解应用于过程生产工业之外场景的延迟要求。如此才可以对其可能的应用进行更全面的概述。
未来也需要进一步研究 ICaaS 系统的运行稳定性，因为它们在很大程度是依赖于给定的本地条件的可用性和可靠性上。在 IT 领域也已经可以找到类似的方案， 如 PACE20。但需要进一步的工作来检查与 ICaaS 概念的集成。