基于信息物理系统的工业自动化方法

基于信息物理系统的工业自动化系统方法

1. 引言

工业自动化系统（IASs）由执行物理过程的物理工厂和用于监控和控制这些物理过程所需计算过程的嵌入式计算机网络组成。系统的信息部分由计算进程构成，这些进程从物理过程中接收输入，计算所需的输出，并将结果作用于物理工厂。这通常通过采用众所周知的扫描循环范式的时间触发控制来实现。

计算进程通常基于事实上的标准IEC 61131实现，该标准定义了一组用于可编程逻辑控制器（PLC）[1]编程的语言。这一标准已存在至少20年，并因在工业自动化领域通过功能块（FB）结构引入了面向对象的基本概念而受到认可[2]。然而，这项技术是否能够满足当今工业自动化系统[3]的新需求仍值得商榷。这主要是由于系统复杂性的增加以及对灵活性的需求。特别是，这些需求包括但不限于分布式、可移植性、可配置性、互操作性和重新配置，这些都被认为是未来自动化系统的高层次需求/要求[4]。

为了应对IEC 61131版本2.0所带来的限制，以及解决当今复杂工业自动化系统开发中的新挑战，国际电工委员会（IEC）制定了IEC 61499标准[5]。正如[6]所述，该标准“是针对当前占主导地位的IEC 61131标准所遇到的技术局限性而出现的”，其中IEC 61131被描述为“在满足当前工业对分布式、灵活自动化系统的需求方面严重不足”。

IEC 61499已广泛被学术界接受，产生了大量研究成果，并就其优缺点展开了积极讨论[7,8]。然而有趣的是，由于多种原因，该标准尚未被工业界接受[3]，其中包括目前工业中主流工具和环境缺乏对该标准的支持，以及缺少各类成熟的新工具和运行时环境来支持这一新标准。目前仍缺乏“成熟的工程工具、可靠的嵌入式控制硬件、经过验证的计算机设计方法论，以及经过培训的工程师”被认为是主要障碍，阻碍从业者采用IEC 61499[9]。

另一方面，IEC 61131最近已升级至新版本[10]。版本3.0提供了对面向对象（OO）范式的支持。CODESYS 3 [11] 已经实现了IEC 61131的面向对象版本，其他工业厂商如倍福[12]也正在向这一方向发展。然而，对于已经习惯使用IEC 61131版本2.0的工业自动化开发人员来说，采用面向对象方式进行编程并非易事。因此，转向完全的面向对象方法将需要较长时间。这一转变也将受到新进入该领域的开发人员的推动，特别是由于面向对象编程和UML/SysML已经被纳入大学和技术学校的课程中，例如，在德国，面向对象编程现在已成为技术人员课程中的必修内容[13]。

除了培训之外，特定的框架可能会促进这一转变，并有望在工业自动化领域带来应用面向对象范式和模型驱动工程[14,15]的好处。这些挑战已经引起了广泛的研究关注，已有大量论文发表于此方向[16–18]，仅举几例。目前普遍认为，工厂自动化行业正在缓慢但稳步地经历一场范式转变[19]；企业软件系统的技术和标准正越来越多地被应用于工业自动化系统的控制层[20]。此外，编程范式正从IEC 61131所采用的传统以设备为中心的模式，转向利用成熟的通用计算技术的以应用为中心的模式。这些技术目前已被整合为一套完整的体系，应用于工业物联网或工业4.0 [21]等工业自动化系统的范式中。

与此同时，针对工业自动化系统的传统开发过程存在大量批评，例如[22–24]。根据这种传统方法，系统的组成部分（即机械、电子和软件）被独立开发，然后再进行集成以构成系统。这种方法被认为不足以应对这些系统日益增加的复杂性。

本文采用在组件级别对机电一体化系统所涉及的各个学科进行协同集成的方法，旨在应对工业自动化系统中的新挑战。机电组件（MTC）由机械、电子和软件组成，被视为构成机电一体化系统的关键构造单元。

在此基础上，本文提出了一种基于信息物理系统的方案。该方法利用在机电或信息物理组件级别的可组合性与组合性[25]，通过在信息物理组件级别实施协同集成，来定义系统层级的功能性和非功能性属性。该方法采用面向对象的范式，并使用系统建模语言进行系统级建模，以及使用统一建模语言对系统的软件部分进行建模。

本文主要关注系统的信息部分建模，特别是软件部分。文中讨论了所提出设计的两种替代实现方案：一种基于用于可编程逻辑控制器的IEC 61131 3.0；另一种基于通用的面向对象编程语言，以便利用近年来市场上出现的各类主要基于ARM处理器的嵌入式板卡。整个设计及原型实现均在一个面向学生和工业从业者的教育框架下进行阐述。我们强调使用更高层次的抽象，以及这两种方法之间的差异实现替代方案，以成功：（a）实现向面向对象范式的转变，以及（b）应用模型驱动开发（MDD）范式。此外，我们特别注重澄清在可编程逻辑控制器编程中广泛使用的扫描循环模型，因为嵌入式板卡的用户通常习惯于事件触发的编程范式。该框架的目标是支持（i）调度抽象[26]，使开发人员能够忽略组件的调度问题，以及（ii）时间抽象，使开发人员能够忽略时间问题，转而专注于因果关系。

为了说明我们方法的所有步骤，从系统层级开始逐步深入到可执行代码，我们使用了利口酒厂系统，该系统最初在[3]中被使用。信息部分的模型是从系统级模型导出的，并根据所提出的方法进行细化，包括：（a）信息物理组件的信息部分，以及（b）被建模为信息组件的过程控制器。采用分层架构风格来构建信息物理组件，而系统组件之间信息接口的集成则采用基于REST的网络架构风格。另外，在系统组件之间需要更紧密耦合的情况下，也可以使用SOAP[20]，甚至传统的中间件技术如CORBA。原型实现的软件部分使用Java和扫描循环模型实现，并通过物理工厂的仿真器进行了测试。Java被认为是一种可能加快通用计算领域的进步在工业自动化系统领域应用的技术[27]。

本文的其余部分组织如下。第2节进一步讨论了相关工作。第3节描述了所使用的案例研究，并简要介绍了基于系统的方法的基本概念。第4节描述了本文提出的系统信息部分的结构。第5节讨论了两种实现方案，最后第6节给出了结论。

2. 相关工作

通用计算领域的进步引起了工业自动化系统领域内工业界和学术界的关注。迄今为止，已提出多种利用新技术的方法；其中，面向对象与面向服务、基于组件和模型驱动开发被广泛推广，因为它们能够改进该领域的开发过程。

面向对象（OO）已经引起了研究界的关注，并提出了多种方法来在此领域中利用面向对象，例如[28,29]。然而，正如[30]中所指出的，大多数这些方法并未考虑IEC 61131的面向对象特性，也没有朝着扩展以支持面向对象范式的方向发展。这导致了关于IEC 61131模型的面向对象扩展的建议效率低下。

面向服务架构（SOA）已经引起了工业自动化领域研究人员的兴趣，例如[19,31–34]，并且厂商也正在朝着利用物联网（IoT）的方向发展，例如[35]。为了支持构成信息物理系统的实体的能力发现与组合及其即时装配，文献[36]中的作者描述了一种在该领域中应用SOA方法的途径。

统一建模语言和系统建模语言均被用于工业自动化系统，例如，[16,18,25,38]。系统建模语言被定义为统一建模语言的扩展，用于系统建模，并在近年来逐步取代统一建模语言在机电一体化系统建模中的应用，例如，[24,37]。它可用于不仅以面向对象的方式，而且以过程化的方式对系统进行建模。然而，大多数基于UML和系统建模语言的方法并未提高建模的抽象层次，从而难以促进该领域的开发过程。我们认为，有效使用UML和系统建模语言应支持构建比IEC 61131结构更抽象的模型；本文采用了这一方法。文献[13]中的作者报告了他们在评估基于UML与基于IEC 61131‐3标准的软件工程方法在可编程逻辑控制器编程教学中应用的经验。尽管比较了软件规范中两个不同层次的抽象，但研究结果非常有趣，可用于推动工业自动化系统开发向面向对象编程范式的转变。

基于组件的开发已被多个研究团队提出，以提高开发过程的灵活性和有效性[39–41]。可组合性和组合性被定义为基于组件的开发中的主要属性[25]。可组合性确保当组件被正确集成以构成系统时，其属性不会发生变化。组合性确保系统的属性可以从组件的属性中计算得出。这两个属性是实现高效基于组件的开发过程的前提条件。

模型驱动开发已被提出作为一种范式，以提高工业自动化系统开发过程的有效性，例如[39,41,42]。文献[43]定义了三个设计层，并将信息物理对象分配到物理层。本文提出的信息物理系统高层建模方法与[22]的不同之处在于：（a）它将信息物理组件视为来自三个层级（即物理、电子和软件）实体的集成；（b）信息物理组件被分配至位于MIM架构这三个层级之上的机电一体化或信息物理层。通过这种方式，信息物理组件的构造封装了不同学科组成部分之间的异构交互，从而促进了系统层级上的组件集成。

巴希尔等人在[3]中描述了一种用于建模工业自动化系统信息部分的方法。他们提出对IEC 61131模型进行扩展，以支持基于事件的执行顺序，据作者称，这与IEC 61499标准的方式类似。作者定义了由两种类型功能块组成的信息部分结构。设备功能块（DFB）用于实现需要访问I/O现场信号的基本功能。操作功能块（OFB）则用于实现利用DFB提供的功能来执行特定工作周期的操作。为了便于开发分布式自动化系统并避免IEC 61499标准的缺点，作者还采用监控控制来解决并发功能块行为的编程问题，从而满足期望的顺序和逻辑约束。在控制器的建模方面，他们使用佩特里网。我们的方法基于开发人员所熟悉的面向对象范式中广泛使用的统一建模语言（UML）状态图和活动图符号。此外，该方法通过在系统层将信息物理系统分解为信息物理组件和信息组件，并采用物联网作为信息接口的连接手段，天然地支持分布式。由于该方法基于明确定义的信息物理组件并通过物联网在系统层提供其服务，因此也天然支持面向服务的范式的应用。此外，该方法解决了上述方法中的多个不足之处，可被视为对上述方法的补充。

机电一体化系统三个学科流的协同集成，即物料传递、能量转换和信息处理，许多研究人员提出将信息处理作为应对该领域日益增长的复杂性的一种工具。传统开发过程受到批评，例如，[22–24]，被认为不足以应对这些系统日益增加的复杂性。[44]中的作者声称，机电一体化系统各组件之间的动态耦合需要一种集成方法，而不是分别且顺序地考虑各个领域。

系统集成被视为大规模信息物理系统中“瓷器店里的大象”[43]。[14]的作者指出，“缺乏整体集成视角常常迫使开发人员实现次优解决方案”，这些解决方案不必要地重复代码、违反关键架构原则，并使软件开发过程中的系统演化和质量保证变得复杂。这一观点在应用于系统开发过程时更为突出，正如本文所提出的这种方法一样。

3. 一种基于信息物理系统的系统开发方法

3.1. 利口酒厂案例研究

本文所使用的案例研究基于[3]中使用的案例研究。进一步假设该工厂用于生产两种类型的利口酒，因此称之为利口酒厂。

图1展示了该工厂的机械部分，即执行物理过程的目标系统的物理部分。该工厂由四个通过管道连接的料仓组成。每个料仓i均有一个进料阀INi和一个出料阀OUTi，用于循环地填充和排空液体。它还配备了一个用于检测低液位的传感器Ei和一个用于检测高液位的传感器Fi。料仓2和4装有加热电阻Ri以加热液体，并配有传感器Ti来监测温度。料仓3和4装有搅拌器Mi，用于混合其内容物。

假设对工厂中执行的两个进程进行简化描述。料仓S1和S4用于生产A型利口酒。原料液体在S1中经历基本工艺，然后倒入S4，在S4中进一步加工，即被加热并随后混合。料仓S2和S3用于生产B型利口酒。原料液体在S2中被加热至设定温度，然后转移到S3中，并在其中混合设定时间。两个利口酒生成过程相互独立，并行执行，前提是它们以独占方式使用管道。此外，由于电源消耗的限制，不允许同时在料仓S3和S4中混合液体。

3.2. 系统层级建模进程

所采用的开发过程基于MTS‐V模型[37]中描述的、抽象程度逐级降低的模型细化。使用系统建模语言（SysML）需求图和核心用例进行需求建模。开发人员在系统层级上以系统职责的形式捕获所需的系统级功能，以及所需的服务质量（QoS）特性。随后，利用该需求模型构建系统架构，该架构将系统定义为组件和连接器的组合，如图2所示，其中展示了所提出的信息物理系统（CPSs）的系统层级架构。信息物理系统组件（CyberPhysical‐SystemComponent）可以是信息物理组件（CyberPhysicalComponent）、信息组件（CyberComponent）或物理组件（PhysicalComponent），即构成信息物理系统（CPS）的各类组件。

系统架构师必须将包含物理处理的系统级功能划分为子系统或组件级别的功能模块。包含物理处理的系统级功能模块应分配给信息物理组件，并在图2中表示为CyberPhysicalComponent。需识别出可能由已存在的信息物理组件提供的系统级功能模块。例如，为满足原料液体生成利口酒的相关需求所需的混合和加热功能，可能由一个加热和混合罐信息物理组件提供。基于此，系统的架构被定义为现有或明确定义的信息物理组件及其互连所需连接器的组合。信息物理系统通常与人类进行交互，并可被视为由多个子系统组成，如图2所示。

希望信息物理组件的供应商已经开发出具备这些功能的组件，并以机器可读的方式将使用这些组件所需的信息发布在语义网上。开发人员可以使用浏览器查找合适的组件[31]。他们需要下载虚拟的信息物理组件，即用仿真器代替真实世界机械部分的组件。通过适当的开发环境，他们集成这些虚拟组件并构建虚拟工厂。这可用于模型分析以及验证。随后，真实的 信息物理组件可以被订购并集成以构建目标系统，即真实的工厂。

根据上述进程，利口酒厂在架构模型的第一抽象层次上被定义为以下信息物理组件的组合：（a）普通罐（Silo），（b）加热罐（HSilo），（c）混合罐（MSilo），（d）混合加热罐（MHSilo）以及（e）管道（Pipe）。精细化的系统架构模型（如图3部分所示）还包含了网络组件，这些网络组件用于捕获构成的信息物理组件之间的协调逻辑，以满足系统级需求。这些网络组件可以以静态或动态方式来捕获协调逻辑。在后一种情况下，可在信息物理组件级别作为服务提供的功能可以被编排，以定义所需的系统级功能。例如，生成A型利口酒所涉及的特定组件协作或服务编排代表了系统特有的逻辑，该逻辑由网络组件GenLiqueurA进行捕获，GenLiqueurA利用了罐1和罐4所提供的服务，如图3所示。

管道被表示为一个信息物理组件，该组件定义为信息组件公共资源的特化，用于捕获获取和释放公共资源的逻辑，因为决定通过软件来实现此逻辑。各种进程的公共结构和行为已被捕获在液化过程信息组件中（见图2中的信息组件），生成液化B信息组件（未在图3中显示）也将继承该组件，以捕获生成B型利口酒的协调逻辑。信息组件工厂控制器捕获了各个工厂过程的协调逻辑。

3.3. 所提出的架构用于信息物理组件

图4展示了以MHSilo为例的信息物理组件的 proposed 架构。该信息物理组件由物理部分（即其物理单元）和信息部分（即其信息部分）组成。信息物理组件的信息部分进一步分解为：（a）软件部分（其 S‐part），表示将物理单元转变为智能单元所需的软件；（b）电子部分（其 E‐part），表示执行软件部分所需的处理节点。如下一节所述，软件部分将进一步分解为表示软件的组成部分。

系统建模语言端口[45]用于表示信息物理组件与其环境的交互点。端口的类型通过连接器指定可供外部实体使用以及向外部实体请求的功能。例如，MHSilo 的其过程端口是过程端口类型，它指定了其内部部件其控制器通过到 MHSilo 环境的外部连接器对外可见的功能。应当注意到过程端口是代理端口类型，因为它充当其控制器的其过程端口的代理。另一方面，其控制器部件边界上的其过程端口是完整端口，因为它用自己的特性定义了其边界上的交互点。端口设计空间结构的实现将在下一节中描述。图4未捕捉信息物理组件各组成部分之间的交互。

工业自动化中的传统通信技术可用于信息物理组件和网络组件的集成。然而，为了将物联网的优势引入工业自动化领域，采用物联网内网实现网络组件和信息物理组件的集成。

4. 网络部分的设计

本文所述针对系统信息部分的设计方法也可应用于传统开发过程，在该过程中，软件被视为系统的整体部分。在这种情况下，软件部分可以与机械和电子部分的开发同步进行，也可以在这些部分已经开发并集成后进行开发。本节描述了本文采用的多学科组件设计方法的应用，以及传统开发过程的应用。

4.1. 系统作为一种由信息物理组件构成的组合

当系统被视为由信息物理组件构成时，系统信息部分的初步设计源自系统建模语言视图模型。这构成了系统的 信息视图，并通过将用 系统建模语言 表达的系统模型投影到信息领域而生成。该 信息视图 可以被视为系统的 软件视图，原因如下：（a）没有任何功能模块被分配给电子部分；全部控制功能均被分配给软件；（b）在此建模阶段，系统模型仅包含系统级功能。当前的趋势是将控制器的所有功能都分配给软件部分，并使用通用用途的嵌入式板卡或可编程逻辑控制器仅用于执行软件部分。由于该方法，这一方法导致信息物理系统的电子部分在这些早期设计文档中未被捕捉。

在系统级模型的每个信息物理组件对应的 信息视图 中都会生成一个信息组件。该信息组件被赋予控制物理组件执行在 组件级别 定义的服务的行为。因此，MHSilo 信息组件被赋予了控制 MHSilo 物理组件执行 填充()、清空()、加热至温度() 和 混合() 操作的行为，这些操作已分配给相应的 MHSilo 信息物理组件。此外，系统建模语言 视图中的每个信息组件都会对应到 信息视图 中的一个组件。GenLiqueurA 组件就是此类组件的一个示例。

所创建的架构将进一步细化，以便能够有效地实现。在定义所提出的方法以进一步细化自动化系统的软件部分时，模块化和复用是首要考虑的因素。如果正确使用特定的UML设计结构，将为半自动化细化过程提供一个坚实的框架，同时也将提供用于自动化生成实现代码所需的信息。系统层级中每个信息‐物理组件的软件组件进一步分解为：(a) 软件代表（SR）和 (b) 控制器。

SR 是相应物理部分在软件领域中的代表。它充当现实世界对象在软件领域中的代理，并封装了与现实世界对象的所有接口细节。需要注意的是，SR 并未为现实世界对象所提供的功能添加任何额外功能。它不仅捕获属性，还捕获系统软件部分可能感兴趣的现实世界对象的其他信息，例如型号、制造商、序列号、尺寸等。例如，图4中类型为 SiloSR 的其软件域是物理罐在软件领域中的代表。

控制器捕捉了将物理部分执行的底层操作转换为信息物理组件级别提供的高级操作所需的逻辑。图4中的itsController就是此类组件的一个示例。MHSiloController可用于实现fill()、empty()、混合()和加热至温度()等操作。换句话说，控制器将物理对象转化为智能对象。

在图5中，给出了系统信息视图的一部分。该部分描述了用于实现生成A型利口酒过程的软件结构。如图5所示，信息组件仅由其软件构成部分表示。然而，如果开发人员决定将系统级功能模块分配给电子组件，则这些组件应在该规范层级的系统信息视图中出现。

有两种方法可以捕获所提出框架的基本结构。一种是通过预定义的通用类来捕获该知识，并允许开发人员通过泛化‐特化机制重用它。在基于此方法的图5中，类Process和Controller以及接口ProcessIf和ControllerIf表示用于捕获框架采用的基本结构的预定义设计结构。开发人员使用这些类来定义其系统的类。因此，GenLiqueurA被定义为继承Process类，而SipleSiloIf被定义为继承接口ControllerIf。使用接口允许GenLiqueurA类的定义独立于料仓的具体实现。基于此，GenLiqueurA类可与任何实现了特定接口的信息‐物理料仓结合使用。在高液位，ProcessIf的使用在进程与工厂控制器信息组件之间实现了低耦合。

基于重用框架知识的第二种替代方案，使用配置文件来定义特定的构造型，例如‘控制器’、‘controllerIf’、‘过程’和‘processIf’。 图6展示了利用适当配置文件的利口酒厂系统信息部分架构的一部分。显然，配置文件机制简化了设计规范，并使设计过程对开发人员更加友好。

4.2. 系统作为信息与物理部分的集成体构成

在机电一体化系统的传统开发进程中，软件是在硬件部件的开发。在这种情况下，已开发系统部分的结构被用作定义软件结构的基础。在软件架构的高度抽象层次上，每个物理单元和每个工厂过程都有一个对应的软件组件。显然，与 3+1 系统建模语言视图模型方法相比，此情况下定义软件层级的约束更多，因为已实现的软件现在必须符合已经实现的硬件，而该硬件定义了系统服务必须在其上实现的基础设施。这种方法可被称为中端出发方法，因为所实现的软件不仅需要满足来自系统层规范的要求，还必须满足来自已定义的底层服务的要求，软件必须利用这些底层服务来满足系统需求。另一方面，在自上而下方法中，当系统被视为信息物理组件的组合时，软件与电子和机械部分协同并行开发，以满足系统层级的需求。该方法不会像中端出发方法那样对软件解空间施加限制。

5. 实现方案

工业自动化软件通常基于扫描循环模型实现。根据该模型，读取工厂输入，基于这些输入执行控制器代码，并将生成的输出写入物理工厂以影响其运行。这被称为读取‐执行‐写入循环，是时间触发控制的一种实现方式。必须正确定义周期时间，以满足物理工厂所规定的响应时间要求。

在本节中，本文提出的方案展示了两种实现方式。一种基于广泛使用的IEC 61131标准，更具体地说是该标准的版本3.0，该版本支持面向对象编程；另一种基于通用面向对象语言，选择Java作为此类语言。这两种实现均基于扫描循环模型。这些实现中的一个关键问题是该框架已嵌入应用程序的高级控制流程，因此开发人员只需专注于构成系统的组件选择及其集成。这极大地简化了此类系统的构建。高级控制流程往往会引入多个错误，并使得这些系统的编程难以理解。Java 实现有助于更好地与先进技术集成，并更轻松地过渡到新的工业范式，在该范式中，分布式、可重构性、可移植性、可演化性和可扩展性是主要需求。例如，基于 CoAP 的物联网基础设施目前已支持 Java 语言。一个典型的例子是 Californium[46]，这是一个 CoAP 的 Java 实现，为工厂组件的集成提供了基础。另一方面，为了充分利用物联网基础设施，需要为 IEC 61131 实现开发特定的封装程序。

5.1. A Java 实现

所提出的设计可以用Java实现，并在近期市场上出现的各类基于 ARM处理器的嵌入式板卡上运行。本节提出了一种映射到Java结构的方法，以实现基于扫描周期的执行。信息物理系统的软件部分设计已使用Java实现，并通过利口酒厂的仿真器进行运行，以验证该设计的有效性。该系统已被开发为教学工具，可用于相关课程的实验教学。此实现的可执行版本可从作者的网站下载。

图7展示了该实现的一个快照，其中料仓S1、S2和S4已被实例化。通过该系统，学生可以理解基于传统Java的工厂控制器实现与基于扫描周期的实现之间的差异，并识别出为这两种实现实现提供解决方案的挑战和技术。学生可以接触到更高层次的抽象，以及实现环境中用于解决传统Java事件驱动实现中出现的互斥问题的各种机制，并将其与PLC系统中采用的时间触发实现进行比较。扫描周期基于 Java 的实现 是 基于 使用 Java 定时器 。这实际上是 IEC 61131 模型中 任务 结构 的 实现。

在此实现中，LiqueurPlantSystem 被定义为信息物理组件的组合。可视化框架用于实例化所需的虚拟信息物理组件以及工厂过程，例如 GenLiqueurA 和 生成液化B。电源被建模为资源，以重用已开发的通用基础设施来管理作为公共资源的管道。工厂控制器设置定时器，并通过控制器定时器任务的执行操作来定义该定时器应执行的操作，如下所示：

控制器定时器 = new 定时器(); 控制器定时器. schedule(new 控制器定时器Task(), 0, 500);

其中 控制器 已定义为扩展 TimerTask ，并重写其 run 方法。

5.2. 基于IEC 61131 的实现

IEC 61131 的新版本，即 3.0 版本，支持面向对象编程，允许更直接地将 SysML/UML 设计规范映射到实现语言结构。然而，也可以映射到当今广泛使用的IEC 61131，利用该标准版本2.0中已提供的基于对象编程的支持。[3]中给出了此类实现的一个示例。

IEC 61131的功能块和类结构用于实现设计规范中的类，而接口结构用于实现接口。 图8展示了从设计规范自动生成的示例IEC 61131代码。

类型为‘过程’的网络组件可以托管在提供所需服务质量的托管服务的信息‐物理组件中，或者可以分配到共享或专用的执行环境中。在本节的其余部分，介绍了端口设计结构的实现。

所提出的端口构造方法在系统组件之间提供了非常低的耦合度。 图9展示了图 4中所示的MHSilo控制器的两个端口如何基于所提出的方法实现。

一个端口，即其过程端口，用于将控制器与其进程进行互连，类型为 MHSiloProcessPort，该类型继承了Controller2‐ProcessPort并实现了MHSilo接口。该端口还包含数据成员itsProcess，MHSilo组件通过该成员访问其所需的来自过程层级对应组件的服务，该组件将互连到此端口。这些所需的服务由 itsProcess数据成员的类型指定，其类型为Process2MHSiloIf，如图 10所示。

另一个端口 itsDriverPort（在图4中未显示）用于在信息物理组件的信息部分也需要更高模块化时，将控制器与相应的SR互连。该端口实现了 MHSiloCtrl2DriverIf，并包含一个类型为 MHSiloDriver2ControllerIf 的数据成员 itsDriver（见图 11）。需要注意的是，由于物理部分与其SR之间存在高耦合，因此第一级可重用性位于SR之上。然而，在大多数情况下，SR与控制器之间的耦合度也很高。由于控制器与SR之间的这种高耦合导致在此级别上的可重用性潜力较低，因此认为在此级别上通过端口进行接口是无效的。这也是为什么将信息物理组件级别视为有效的可重用性级别，并采用比SR与控制器之间端口实现更有效的接口方式。

符合要求的端口可以通过连接器进行互连。建立连接器意味着要设置所连接端口的相应数据成员。

6. 结论

从可编程逻辑控制器和传统的基于IEC 61131的开发过程转向IEC 61131的面向对象版本，对于长期习惯于该编程范式的工业开发者而言是一项复杂的任务。虽然需要掌握面向对象范式的基本概念，但即便如此，这一转变仍然相当复杂。本文提出了一种基于信息物理系统的方案，可极大地简化这一过程。具体而言，我们为信息物理组件设计了一种分层架构，并采用基于REST的网络架构风格，实现系统层级信息物理组件与实现工厂的工艺流程的网络组件之间的集成。值得注意的是，所提出的方案还支持基于SOAP和XML的更紧密耦合的实现方式。

一个示例应用已作为实验练习开发，供学生和工业开发者使用。其目的是帮助他们理解如何在系统建模中使用UML/SysML表达的更高层次抽象，以及如何利用IEC 61131和物联网等先进技术实现这些抽象。我们的方法还可用于在近期市场上出现的各种基于ARM的嵌入式板卡上生成实现。这将简化来自通用计算领域的新兴技术的采用，并促进对物联网的更充分利用。

所提出的架构可能会被批评为引入了性能开销，但与此同时，它极大地简化了开发过程，并提高了生成代码的质量和健壮性。本文的重点是基于系统的方法。然而需要注意的是，该方法也支持这些系统的传统开发方式，从而能够将其应用于遗留系统。

对于IEC 61131的情况，我们计划将物联网通信基础设施完全集成到功能块模型中，以方便工业开发者进行系统集成。特别是，我们的重点在于生成胶水代码，以实现过程网络组件与相应的信息物理组件的集成，这些组件用于实现工厂的工艺流程。在此背景下，将提供支持为向信息物理组件上传新行为提供支持，以满足当今工业自动化系统中优先级较高的可重构性需求。