关于开放自动化的思考：模型，协议与算法_aas 语言和建模

        研究开放自动化要以OT的思维方式思考，不然的话，你会是一头雾水。AutomationML，AAS，OPC UA ，PLCOpen，IEC61131，IEC61499 各种标准琳琅满目。而且每一个标准的都内容繁多。要搞清楚它们并非易事。

     本博文谈谈这些开放自动化标准背后的逻辑：模型，协议与算法。

模型

        所谓模型是对事物的抽象，并且使用形式化语言来描述。OT 工程认为，机器之间要相互通信，不仅需要使用标准化的协议，而且需要标准化的语言规范化。协议定义了交换信息的方式，而语义定义了信息的含义。OT工程重视模型的构建和语义的规范化，而IT工程师更倾向与可编程和灵活性。相比之下，IT行业的国际化标准没有OT行业那么多。

        构建模型的重要性是不言而喻的。只有语义的标准化，才能够实现即插即用的目标。

          构建的标准需要使用规范化语义来描述。IT 行业为了实现模型的描述，提出了面向对象程序设计的思以及描述复杂结构化数据的XML，JSON语言。OT 行业主要采用了XML语言来描述模型。并且吸取了面向对象程序设计的思想。

        AutomationML 是目前最活跃的自动化行业数据模型模型。 它使用XML 作为模型描述语言。以面向对象的程序设计思想构建模型，系统由系统单元类，角色类等构成，每个类中包括了属性，变量，接口等。

        模型是一种形式化描述文档，目的是程序能够读取其中的含义。形式上它们只是一些静态的XML 文件。它们是工业软件的文档。目前我们看到了大多数是这些文档的格式标准。，并不是工业软件本身。

          构建模型最大的难点是使用这些建模语言来构建工业领域各种设备的模型。这是一项十分艰巨和长期的工作。而且目前没有更好的商业模式来推动行业领域建模工作。

          全世界使用统一的语言，在世界范围内消除人类语言交流的障碍，这是人类的美好愿望。记得过去还有人推广所谓世界语，但是并没有成功。构建数字化模型统一的建模语言如同构建世界语一样困难。在开放自动化发展的早期，可以采用渐进的方式来推进建模工程。使用未来的标准来解决当下的问题才能寻找到一个商业化发展的模式。

          在笔者上一篇博文中提到，我们尝试在专业领域使用一台网关设备来实现传统PLC 设备的开放自动化改造。

    OPC UA 网关的架构如下：硬件是一个小型的Arm处理器构建，上面运行Linux OS，在OS 之上，运行一个OPC UA 协议栈。该程序还包括一个运行时，承担模型数据的访问以及与PLC 通信的modbus协议栈。实时完成PLC内存状态与模型之间的数据更新。

     由于网关上的程序是纯软件实现的，实时程序在PLC 中运行。网关上的程序可以实现AutomationML ，AAS 等数据模型。也能够实现本地化历史数据的保存。几乎大多数开放自动化程序可以在这个设备上运行。当技术成熟后，这些程序可以移植到PLC 内部运行，也可以作为一个PLC 扩展模块。 

  我们可以使用AutomationML 构建系统信息模型，也可以使用类似OPC UA 中提及的信息模型。甚至使用简化的内部模型。

  比如下面是我们使用的一种内部模型架构。它们能够转换成为OPC UA的信息模型。事实上我们曾经使用OPC UA 信息模型作为设备内部的模型。后来发现它们太零散和麻烦。从而采取更简单的模型来替代。

协议

        协议是通信双方之间的约定，包括传输帧的结构和过程。底层网络的协议对承载的内容没有做出规范，例如互联网中最流行协议是TCP/IP和UDP 。而建立在TCP/IP 之上的HTTP协议，对内容做出了更进一步的规范。在OT行业，普遍采纳了IT行业的通信协议，但是他们对内容规定了详细的规范，实现了所谓语义化协议。

        为了实现通信协议的语义化，需要构建信息模型。比如OPC UA 是目前最被看好的开放自动化协议。它提出了完整的信息模型。在信息模型的基础之上，可以构建各种实体的数字化模型。应该指出的是OPC UA的信息模型只是为了协议而定义。系统的信息模型与通信协议的模型可以是不同。系统的信息模型可以更复杂，或者更简单。AutomationML 模型是一种系统建模规范，它还包含了3D 模型和运动模型等等。 设备也可以设计专用的内部信息模型。为了方便地映射到OPC UA 协议中，要考虑系统模型与通信协议之间的兼容性问题。

      如果使用automationML 来构建系统信息模型，当采用OPC UA与外部交换信息时，需要将automationML 的模型转换成为OPC UA的信息模型。

        OPC UA 是否会成为未来的现场总线协议？ OPC UA 是这么想的，他们已经提出了OPC UA to the field: OPC UA for Field eXchange (FX)的提议。如果那样的化，PLC 将会变得十分臃肿，实时处理OPC UA 信息模型将增加PLC 的处理器开销。 这些问题只有在实际应用中才能够做出正确的判断。

        使用OPC UA 作为现场总线的PLC 大概会长成下面这个样子吧？PLC还是原来的PLC，周期扫描内存数据和IO端口。执行IECC611311-3 的程序。OPC UA 的模型与内存数据建立映射关系。这种结构保留了PLC 原来的使用方式。

      OPC UA 要成为现场总线，必须保证实时性。因此人们又提出了OPC UA Over tsn 的概念，希望采纳时间敏感网络来保证OPC UA 的实时性。

算法（程序）

        算法是控制系统的控制方法，它们使用程序设计语言来描述。通用的程序设计语言包括C++，Java，Python 等。在OT行业，程序设计语言更倾向于使用基于图形的程序设计方法，例如PLC 中的IEC61131-3中的梯形图，IEC61499 的功能块网络。

        程序能够部署在系统的各个设备中。有人说能够利用信息化模型来编排程序。我不认同这样的观点。我估计他们是指在Client/Server 架构中，通过服务器端的编程方式来实现编程。比如在SCADA 服务器上使用图形语言或者程序设计语言来编排程序。server端通过OPC UA 协议来实现对设备的控制。OPC UA 只是协议而已，编写程序是少不了的。

模型，协议和算法的关系

        前面提到，模型，协议和算法都吸取了基于模型设计，面向对象设计的思想。它们的内容，术语相互交叉，容易引起混淆。比如 OPC UA也具有信息模型。有人将它描述成为信息建模语言。甚至认为它是一种编程方式。也有人将IEC61499 认为是一种建模语言（的确，我也这么认为，但是它更是一种编程方法。况且哪一种程序设计语言不是建模语言呢？）按笔者看来，在工业系统的构建中，模型，协议和算法应该有清晰的区分。

        模型是静态的格式化文档，例如一个XML 文件，它是真实物体的数字模型的描述。静态数据只能被程序引用。这里的程序并不是应用程序，而是平台运行时程序。例如控制器运行时读取CNC 机床的AutomationML 模型文件，实现与内部设备和外部系统实现信息交换。

        协议实现设备之间的信息交换。并且将设备内部信息模型的数据映射到通信协议的信息模型中。

        算法（程序）实现控制系统的控制逻辑。它们可以在服务器，边缘服务器或者各种控制器这个运行。这些算法使用通用语言编程（C#，C++，java等等），或者OT行业的IEC61131-3，PLCopen，IEC61499  来编程。对于系统模型而言，算法可以认为是一个数据对象。模型的规范中没有做出限定，所以设备的算法可以是二进制可执行程序，也可以是其它格式的程序。

下面是一个控制器的概念示意图，表示了模型，协议和程序的关系。

        控制系统中的运行时访问模型实例的数据，读取设备的数据，使其与模型实例的数据同步。并且通过协议与外部交换信息。设备能够执行应用程序，例如IEC61131-3 或者IEC-61499，它们通过系统模型下载和更新。

下面清晰地表达模型，协议和算法的关系：

         模型 -automationML

         协议-OPC UA

         算法-IEC-61131-3，IEC61499

结束语

         如果我们结合具体的应用来研究工业软件的实现。会更加深入地体会开放自动化系统背后的逻辑。这些东西单从标准和白皮书上是肤浅的。

        如何化繁为简，逐步实现开放自动化系统的各种标准，并且构建模型库是一个巨大的挑战。本人的看法是采取渐进的方式推进，使用未来的技术解决当下的问题。不要让开放自动化空转太久。