流程工业自动化的未来展望

在IT技术飞跃发展的年代，流程工业自动化的传统控制系统DCS正在步入“老态龙钟”。它的封闭性和专用性，极大地阻碍了OT与IT的深入高效的融合。

一个幽灵正在接近工业自动化的传统地盘。它巨大的潜力，将致使工业自动化厂商长期保有的业务模型变得日趋陈旧，不得不升级和转型。它还会要求厂商采用正在如潮水涌来的软件技术和来自云计算领域的实践。可以肯定的是，这一颠覆将被几乎整个新的软件技术，而非硬件技术所驱动。当这一颠覆第一次冲击连续过程自动化的时候，这些新颖的软件技术的力量和价值，将推动流程工业以及其新兴的业务模型进入许多其它的领域，包括工厂自动化FA和工业物联网IIoT。驱动这一颠覆的一个重要因素就是软件应用的容器化（containerization）。

流程工业自动化的百年新芽

自上个世纪二十年代，流程工业开始了气动仪表和气动控制器的生产现场应用，最早是在1959年出现了单回路电子控制器。上世纪70年代8回路数字式控制器出现，流程工业已经运用生产数据的历史记录、现场总线网络、灵活的系统组态和规模不大的人机界面。

80年代之后，100回路规模的数字式控制系统DCS开始出现，在L1层开始运用功能块、顺序控制和自诊断技术；在L2层已经有了按生产的需要配置不同规模的系统，大大提高了系统的可用性；在L3层相关的计算机系统已经接近当时的最新水平。

到了2000年，1000回路规模的数字式控制系统DCS成为主流。流程工业在L1层普遍运用高性能、多功能的DCS系统，配有HART或FF现场总线；而在L3层大量使用低成本的服务器。

图1：DCS的主要进化史

之后的发展，特别是近些年来，DCS面临着一些亟待解决的三个重要问题。一个是老龄化。许多正在运行的DCS系统已经服役二三十年，备品备件所需的元器件已经停产或改型，如何低成本且不停产或少停产的进行升级改造，这是最终用户十分关心的问题。第二是继承性。经过几十年运行，控制系统积累了大量的生产运行数据和智能运营的知识库，在控制系统的升级改造的过程中如何继承和保护这些软资产，不容回避。第三是融合性。在IT技术以高度密集和高速度的方式进入流程工业的今天，OT技术不得不紧跟IT的步伐，不失时机的与之融合。

等不及供应商的动作了。

这一次，是一些有远见的最终用户开始打破僵局，采取大刀阔斧的举措。在他们的积极推动下，流程自动化行业出现了开发下一代开放的分布式自动化技术的全新局面。未来的控制系统追求的目标很具体：能够低成本替代原有控制系统，且可按现场需要配置系统；运用先进的边缘设备，但仍可沿用原有的I/O及其电缆布线；具备良好的APP工业软件的可移植性；方便与一流的部件和第三方软件集成。还要求用高可用性的实时数据中心构成虚拟化的系统，既要向下有效连接边缘端与I/O端口，向上又要方便OT与IT的融合。

而这些颠覆性的技术，强烈地受到近些年来IT行业并发的若干个重要技术的影响和推动。其中最重要是大量应用的系统虚拟化，以及云计算、运用广泛的开源软件（OSS）、新软件技术集成和软件开发和部署（DevOps），以及超高可用性的部署平台。

一百年的老树，正迸发出全新的枝桠。

重现当年小型机现象

自1970年PLC和DCS进入自动化领域之后，处于ISA 95的L1和L2的控制层的自动化硬件和软件结构一直没有变动，迄今为止自动化市场的结构也一直围绕着捆绑式的自动化硬件和软件在演进。

每一个自动化的供应商都开发自己的软件环境，并将这种软件环境转交给最终用户，而通常他们并不能深入这一软件环境，只能通过供应商提供的控制器组态软件工具与控制器交互。这一种结构方式与1970年的小型计算机市场非常类似，几乎每一个小型机的供应商都是以硬件软件捆绑的应用方式和软件工具，以及自己的渠道伙伴和软件供应商进入和占领市场。

企业控制的系统集成国际标准IEC/ISO 62264脱胎于ISA 95。虽然这一标准是在普度CIMS模型的基础上发展起来的，适用于流程工业、离散制造业和批量过程工业，但毕竟最先获得流程工业的普遍支持和实践应用。工业4.0的RAMI4.0参考架构模型中的“Hierarchy Levels”的维度，主要是借鉴了ISA 95的概念。由于最终用户对此ISA 95参考模型的认可和青睐，在美国和欧洲工业软件的开发厂商一般都以此模型为依据。为了更好地服务于智能制造和IIoT的需要，如图1所示，ISA 95在原来的L0至L4的层级之上增加了L5级（企业接入云系统的集成）。

图2：ISA 95的参考模型增加了L5企业云集成

关心现有系统运用新技术的升级迁移是现有的工厂和成套设备又一个关键的问题。制造厂不允许按整个规模替代已安装和运行多年的ICS工业控制系统，这可能会对运行造成很大的破坏。而现有系统的数据库积累和容纳了大量具有智能特性的数据，由于这些都是在专有系统中实现的，很难用文件描述，或者难以升级迁移到新的平台。制造厂需要非破坏性的路径使他们能够对现有系统进行更新和升级改造。

以埃克森美孚为例，其炼化工厂每天从500万个变量（tags）中产生13亿个数据记录！每天13亿，这还不包括机械数据。存取这么多数据的能力，以及将数据进行分析利用并转换为活跃的可起作用的信息，是业务的关键需要。

企业迫切需要从系统到边缘再到云端实现分析的APPs，可是目前却不那么容易完成。供应商应对难题的解决方案，似乎落后了一大截。举一个现实的例子。美国埃克森美孚公司曾大量使用Honeywell的DCS系统TDC 3000，这些服役二、三十年的系统其备品备件最多可用到2025年。也就是说大约还有五六年的时间，不得不面临升级改造的严重问题。而且为了让这些老系统能够利用Honeywell的云基开放虚拟工程平台，使TDC的环境虚拟化，还能够支持与WirelessHART等无线变送器、仪表的联接，利用低成本、小资源的仿真系统等，他们用了七年时间开发了Experion LCN R501.1，可以仿真TDC老系统的系统软件，实现100%的二进制兼容和互操作。花了那么长的时间在技术上得以实现，其成本可想而知。

开放的架构

多年前埃克森美孚的研究和工程部门公开倡议开发一个全新的、基于标准的过程控制架构。2014年他们编创了一个基本特性文件，在2015年的ARC论坛上分发，受到相当的关注，引发了热烈讨论，也得到具有相同要求的其它最终用户的支持。由于美国开放集团（The Open Group）在为其它工业部门创建标准方面的专业性和成功表现，埃克森美孚决定委托这个非盈利的第三方，组织一个新的标准化活动，面向流程控制工业中业务和技术的挑战，开发一个新的系列标准。

The Open Group创建了开放流程自动化论坛OPAF（the Open Process Automation™ Forum），吸收一批最初的成员，并于2016年11月在旧金山召开了第一次会议。截止到2018年底，该组织已经有超过133个团体成员，包括最终用户、硬件和软件供应商、系统集成商、学术单位和标准化组织。显然这是一个以大型的最终用户为主及其支持者流程自动化供应商组成的共同体。

这个组织的使命就是维新。已经20多年没有变动的DCS的架构，在迅速发展的IT技术面前，将如何重生？它覆盖了最新的分布式云计算技术和虚拟化技术重新定义DCS和PLC，以及与优化运营密切相关的先进控制和MES（参见图3）。

图3：开放流程自动化OPAF的范围

图4给出OPAF的架构图。OPAF所定义的DCN表示分布式控制节点，它是由DCF（分布式控制框架）和DCP（分布式物理基础设施）所组成。图中黄色所标的均为OPAF所定义的部件和模块；海蓝色所标的则是非OPAF定义的其它系统，如传统的DCS、PLC、分析仪表系统、电气系统、机监控系统、……，但它们都可以经由DCN接入OPAF所定义的联接性框架OCF。

图4：OPAF的架构图

即使是处理企业业务的事务性平台（企业的IT数据中心）和其它非OPAF环境的系统，都能经由DCN接入OCF。至于执行ISA 95的L2和L3功能（如先进控制算法、MES等）的OT数据中心直接与OCF相联，这一先进计算平台采用容器化的软件技术，将不同功能的APP组织容纳在不同的容器中，形成高效执行软件子系统。

关键使命

作为老牌的实时操作系统的开发商风河（Wind River），已经定义并完成了一个新一代的平台产品Titanium Control Platform，其中工业控制系统的“虚拟化”和“软件定义”已经运用娴熟。针对那些日趋老化的传统工业控制系统不能支持与工业物联网连接的问题，这一平台承担了预置云规模的基础架构，将几个关键基础架构公司的平台软件（工业级云管理中间件open stack，工业级Linux，工业级存贮集群ceph）协调组合，分别构成控制节点、计算节点和存贮节点的协调管理，从而以高性价比的方式为传统控制系统提供升级改造的可能（详见图5）。

图5：风河的Titanium控制平台

风河在实时操作系统的长期经验与宽泛的低延迟虚拟化和预置的云计算技术组合起来，在OPAF主导的以任务为关键的（mission critical）验证性项目应用中获得成功。所谓以任务为关键就是需要每天24小时不间断运行，譬如电信系统、航空管理系统、医疗系统、金融分析系统等。同样，用于流程工业的DCS，也是属于必须不间断运行的控制系统。

趋之若鹜

在The Open Group的管理下，该创新项目谋求定义一个可以运用于多个流程工业（化工、炼化、发电、制药、冶金、纸浆和造纸等）的流程控制架构，满足标准化、充分安全性和互操作性的要求。当今工厂中所用的任意DCS和PLC的功能，都可以被这些由服务器和许许多多计算资源和存储资源要求足够小的自动化边缘设备组成的新系统所替代。图6给出了从现有已在役的DCS/PLC系统逐步地升级迁移到这些小的边缘设备，以及预置的高可用性的服务器的发展趋势。

图6：新一代分布式控制系统

OPAF的目标是对ISA 95的L1和L2的功能标准化  这些功能是：现场设备和仪表的基本的输入和输出，以及执行调节控制的功能块。目前这些功能都是由专用的DCS和PLC来完成的，规模约为100至1000个PID功能块。埃克森美孚和其它一些最终用户深信不疑可以用更多但更小的边缘设备作为过程控制器。这些小的硬件设备每台可以控制少到一两个回路，实际上执行过程自动化的微服务。

经过验证的系统使这一创新项目由可能实现进展为现实。OPAF与洛克希德马丁公司和其它公司的一个团队紧密合作，在OPAF架构和由OPAF所选择使用的工业标准的基础上开发了一个原型系统，进行验证。

参与这一概念验证系统工作的OPAF成员包括：R.STAHL（提供常规I/O），施耐德电气（提供智能I/O），Intel（提供分布式控制节点DCNs），NXT control（已被施耐德收购，提供DCNs和软件控制器，ABB（提供软件控制器），AspenTech（提供先进控制软件APC），Inductive Automation（提供人机界面HMI），ANSYS（提供另一个HMI），Wind River（提供实时先进计算平台RTAC）。

验证的结果令人欣喜，这表明OPAF架构已经由概念转化为正在运行的概念验证的系统。在工业自动化界已经讨论了十多年的开放自动化系统的可能性，正在一步一步的变为现实。对于流程自动化的行业这不啻为一件激动人心的事件。在2019年二月该组织正式推出了新标准的第一版O-PAS Version1.0，给出了一个与供应商无关的参考架构；而且还计划2020年在埃克森美孚和其它至少两个现场进行试验。

容器化软件技术

发源于UNIX的软件容器化技术，经过LINUX开源软件的大力推动，业已大大降低了门槛，成为可以较普遍掌握和运用的技术。对于软件开发商和最终用户，软件容器提供两个巨大价值：1）软件容器技术可为任意数量的机器、物理或虚拟对象，提供自动的配置、部署和管理分布式应用的方法和手段。（2）容器软件开发的过程创建了一个“容器图像”的存贮库，在软件交付时，这一容器图像形式可在不同于原来开发的软硬件环境的另一种环境中协调地创建，同时还自动建立了包括运行应用软件所要求的所有的软工作环境。

开发容器图像的过程已经完成了一种高度的抽象，使它独立于异构的多CPU、操作系统、软件版本，以及在开发期间运行的环境。由于容器图像划定的范围仅容纳在一个应用软件内，所以容器会将开发者的注意力从管理计算机转移到去管理应用。这极大地改善了应用的部署能力和可见性。容器的开发、部署和业务流程的软件工具在前五到十年中已经臻于成熟。显而易见，传统的嵌入式系统软件技术在交付和管理分布式和高可用性的应用软件的能力方面，根本无法与容器软件技术相抗衡。

目前在工业自动化行业和汽车、电信这些大行业中，正在为分布式自动化或功能性创建参考架构，甚至在创建特定的解决方案。

全球的汽车工业目前正在努力开发一种参考架构，谋求使一辆汽车兼具安全、自动驾驶、远程服务、信息娱乐和舒适的性能。这包括定义一个专门的被称为汽车级的Linux（Automotive Grade Linux ）的Linux软件集。在电信行业，许多公司正在开发包括信号收发基站的基础NFV（网络功能虚拟化），以及和电信中央交换器的虚拟化处理功能CORD（Central Office Re-architected as a Datacenter）。

为迎接数字化转型的挑战，这些新创项目具有许多共同的特点：要求大规模而且长生命周期的远程部署软件的管理，在工业软件的开发、部署和维护，以及所有类型的硬件（包括嵌入式设备）都有所突破，而不是渐近的改进。

这些突破正在顺利进行或已经完成。一些领先的软件容器管理和协调配置的开源工具已经具有实时进行分布式应用软件的部署和管理的能力，而且在商业上达到可以提供的水平。可以预期，同样的软件工具将也能融合到开放过程自动化的创新项目中。

图7释出容器化软件的原理框图，图中表示Docker将应用软件分隔为若干个可管理的APP功能模块，并将它们打包在一个容器中。Docker集成Linux的容器化技术的目的，一方面是为了解决应用软件的开发能适应每一种开发环境，另一方面是为了解决代码依赖性的跟踪、应用软件的可扩可缩，以及仅仅修改升级个别APP而不会影响整个的应用软件等问题。

图7：Docker公司开发的容器软件技术框图

图8则表示将容器技术如何运用于OPAF的架构，构成一个分布式控制节点DCN。根据实际的需要，可在在一个DCN容器中容纳所需要的各种APP，如监控和管理DCN的APP、现场总线和工业以太网的APP、现有的过程控制算法APP、新开发的过程控制算法APP等等。

图8：运用容器技术构成分布式控制节点DCN

从技术成熟度来讲，基于容器的软件部署已经高度标准化了，以开源的形式提供使用。它运用广泛，并为许多不同类型的平台所成功运用，从非常的大的系统（Google）到最小的计算机系统（树莓派，Raspberry Pi），都已经得到现场运用的验证。

软件开发的三大类别

从发展过程看，软件开发已经分成了三个主要的类别：企业软件（业务运行）；嵌入式软件（运行于设备、模块等“物”中）；最近一些年形成的云软件（运行于第三方的云资源上）。尽管这三类软件存在着一些重叠，但它们各自有自身独特的开发及其工具环境。

软件开发的三个类别

在下一个五年或更多一些时间内，云软件开发技术相比其它形式的软件开发，显然会成为主要的形式，而且这三种软件开发将会极大地融合汇聚。更值得关注的是，这一融合汇聚将会被迅速发展的开源软件的步伐所推动，而不是由目前工业自动化工业所采用的软件开发方法迈着缓慢的步伐在前行。

这一融合汇聚的第一阶段将是所谓原生云软件（cloud-native software）的开发，开发常规企业软件与云软件的融合。当云原生软件以向下扩展的形式聚焦嵌入式软件在物联网，特别是工业物联网的要求时，这将推动第二阶段的融合。工业自动化已迈开了这样的步伐，在过去的两年中已经在许多工业产品导入了Docker和Linux容器的技术。除此而外，一种正在云执行平台上出现、并被称为单核与嵌入式软件开发低资源的专业组合的云技术，也不容忽视。单核技术目前还活跃在许多研究领域中，但很快会转入应用。事实上风险投资已经在向为企业和工业IoT市场开发单核产品的方向投资。

云计算是一个有2500亿美元的研发投资的大业务。它正在迅速增长，并主要被诸如亚马逊、阿里巴巴、微软、Google、IBM及相关巨头所掌控和关注，竞争非常激烈。有理由期望用于云计算业务的开源软件技术将会快速发展和推广。不出5年时间所有软件的开发将会使用云软件开发的方法。在软件的“食物链”内，如果“软件正在吞噬世界”，那么吞噬软件开发的软件则是云软件开发及其工具。甚至在嵌入式软件的特殊的领域内开发几乎会被当前和未来的云软件技术所左右，或者说被当前和未来的云软件技术所吞没。

统一与分歧

下一代的DCS和PLC正在向开放、分布式、具有充分的互操作性和内在的信息安全的架构发展。而要有效地实现这样的架构，需要大量地采用开源的云计算软件技术。在今后的分布式控制系统DCS和PLC的自动化应用，容器软件技术一定会大放异彩。可以毫不夸张地说，有效的运用容器部署和业务流程编排软件很可能成为未来过程自动化系统成功的关键因素。

技术上可以说是大势所趋。但在业务模式上却出现两种对立的观点。OPAF发布的业务指南中指出，关键的利益攸关者是多元化的，包括最终用户、系统集成商、硬件供应商、分系统供应商、软件供应商和服务提供商。在下一代的流程自动化系统中，系统集成商/分系统集成商的角色将越来越关键。从现在的单一的DCS供应商转换为系统集成商，将是一次流程自动化格局的重塑。

然而以DCS系统主要厂商之一的艾默生则并不想要如此复杂的局面。它坚持认为，用户宁愿依赖一两个战略性的的供应商，而不是依靠少数几个协议和系统集成商的能力，去将几千个智能设备集成起来。艾默生这一派期望继续沿袭流程工业迄今为止惯用的方法，即一个巨大的工程项目只能由一两个有完全能力的战略承包商负责。由于意见不合，艾默生于2018年还退出了OPAF这一组织。

另辟蹊径的德国人

在美国人牵头的OPAF重新定义现有DCS、PLC之后，德国流程工业用户组织NAMUR提出了另一类的开放架构NOA，并计划在2021年至2022年以IEC的标准发布。

德国NAMUR倡议的NOA（见图9），坚持在原有的工业信息化、自动化金字塔结构的前提下，引入确有实效的IT技术，与OT技术深度融合，提升运行维护的优化能力。

图9：NAMUR的开放架构

由图9可以清晰地发现：（1）NOA开放架构其顶层设计的出发点和目标都是围绕不改动现有的流程工业自动化、信息化的金字塔结构考虑的。因此其开放架构的构想是在原有的基础上引入云计算技术和其它新的IT技术，以加强和充实原有架构开放性不足的缺陷，又不至于由于开放而丧失信息安全的内在保证。（2）NOA所设计的范围涵盖由现场级、基础自动化级、MES级到ERP级，而不像OPAF仅涉及L1和L2。（3）充分考虑用户已有资产的可用性和安全性，在进行IT与OT融合升级时不会伤筋动骨。（4）作为德国提出的流程工业的开放架构，NOA还需要充分考虑与德国工业4.0的对接，因此增加了按工业4.0资产管理壳的理念和方法对现场设备进行管理。（5）但NOA没有对现有的DCS如何升级迁移作出任何考虑，面对现有在役DCS日益老化，备品备件难以长期供应的困境，没有给出解决方案。

笔者认为，作为从不吸收自动化制造厂商参加的纯用户组织，NAMUR更多地是从用户目前的利益出发，其合理性表现在尽量挖掘现有系统的潜力，能少花钱就不多花钱。

图10：NAMUR的NOA架构框图

图10进一步诠释了NOA架构的构想。在这个体系中，核心的过程控制是具有确定性的控制系统DCS，这是现存的专用系统，不具备开放性。为实现运维监控和优化，NOA的解决方案是在流程工业的装置这一级引入具有开放性和可靠性的IT基础架构，这是一个相关工业软件APP平台，执行作业调度、先进过程控制、报警管理，同时也实现对工业4.0设备的管理（即按工业4.0要求完成资产管理壳的管理）；为配合优化和预测性维护所加装的低成本多参数的传感器和对生产装置监控的振动检测系统，全都纳入这一系统。现存的的DCS系统通过开放的OPC UA与装置级M+O系统连接。在此基础上再在多个已建成的装置级M+O系统之上，建立集中的全局的M+O系统，执行排产、先进的分析、历史记录、可靠性管理、集中的HMI，以及生产网络的仿真等功能。这同样应该是一个开放可靠的相关工业软件的APP平台。虽然现有的DCS系统只有专用的接口，但为了与集中的M+O系统连接，需要将其转换为开放性的接口。这样的设计达到了NAMUR不对现有DCS系统加以改动的初衷。

小记：两行白鹭上青天

尽管在如何实现开放性上，特别是DCS如何升级迁移上，OPAF与NOA大相庭径，不过他们还是找到了基础要求的共同点，即他们都需要完善的描述现场设备的信息模型。在这一点上，他们都支持由现场通信集团（FieldComm GROUP） 、OPC基金会和ProfiBUS/ProfiNET国际组织正在合作开发的流程自动化现场设备的信息模型PA-DIM。

另外，这些年不事声张在开发的先进物理层协议APL也大有进展，利用单根双绞线传输10MHz以太网信号同时为现场设备供电的技术，已经日趋成熟。

自此，在世界范围内围绕流程工业开放自动化的未来发展，已经出现了两条明显不同但大有潜力的技术路线。流程工业自动化完整的未来蓝图，基本成型。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删