模块化装置的配置的制作方法

1.本发明涉及在模块建造阶段中为模块化装置的模块提供控制软件配置以及在装置建造阶段中配置模块化装置。


背景技术：

2.模块化装置是工业4.0的既定方面，不仅在开发成本方面提供效益，而且在时间和材料工作量方面也有好处。模块化装置结构的整体层由称为pea(工艺设备组装)的预先制造的且经过充分测试的模块组成，这些模块可以很容易地以不同的组合进行组装以实现不同的目标系统。pea通常具有自己的智能，以提供安全分散操作所需的所有功能。pea之间的数据交换经由被称为模块化类型封装(mtp)的标准化接口描述实现。mtp途径为模块与编排系统之间的互操作性创建了框架，从而使得工艺装置能够以更加模块化的方式构建和建造，其中目标是简化工艺装置建造和生命周期管理。


技术实现要素：

3.尽管期望模块化，但是发明人已经意外地认识到装置所有者通常单独设计、创建和校准他们自己的模块，从而常常在整个装置中的这些模块的后续组装中花费大量精力。然后，将这些模块绑定到特定控制系统，以用于模块内部功能的自动化。由于自动化供应商绑定，所以几乎不可能重复使用pea的软件。借助于控制器和嵌入式opc ua服务器，每个pea通常都有自己的智能。控制器用于使来自pea的过程功能自动化，并且使用面向服务的体系架构和针对监控系统的基于状态的控制来公开功能。将pea绑定到特定硬件并为每个pea添加控制器都会带来高投资成本和供应商依赖性。
4.发明人已经认识到解决这些问题中的一些或全部问题会更有利。因此，本发明提供了一种向模块化装置的模块提供控制软件配置的方法和一种配置模块化装置的方法，以及一种计算机和计算机程序产品，如所附权利要求所限定的。可选特征在从属权利要求中陈述。
5.在第一方面中，提供了一种向模块化装置的模块提供控制软件配置的方法，该方法包括在模块建造阶段中：接收针对所述模块的用户定义；以及基于用户定义来自动生成针对所述模块的控制软件配置，该控制软件配置包括指定针对所述模块的不特定于任何目标系统的参数，以及提供控制软件配置作为控制器不可知的配置文件，以供当所述模块在装置建造阶段期间被集成到目标系统中时，将根据控制器不可知的配置文件实例化的控制器软件随后绑定到所述模块的硬件控制器。
6.在第二方面中，提供了一种配置模块化装置的方法，该方法包括在装置建造阶段：接收针对作为目标系统的模块化装置的用户定义，该定义标识根据用户定义要集成到模块化装置中的模块，其中至少一个所述模块与控制器不可知的配置文件相关联，该控制器不可知的配置文件指定针对所述模块的不特定于任何目标系统的参数；以及将根据控制器不可知的配置文件实例化的控制器软件自动绑定到目标系统的所述模块的硬件控制器，该绑
定包括根据用户定义将参数自动适配到目标系统。
[0007]“控制器不可知的”意指配置文件尚未绑定到控制软件要在其上运行的特定硬件控制器，也没有绑定到该硬件控制器构成其一部分的目标系统。因此，配置文件以及控制软件配置本身可以被描述为相对于控制器/硬件/模块/目标系统(的细节)不可知/独立或从中提取。换句话说，控制软件配置和配置文件仅包括可以适用于任何这种元件的控制器/硬件/模块/目标系统的通用细节和/或仅包括将通过一定类别/类型/种类的任何这种元件所展示的关于该类别/类型/种类的控制器/硬件/模块/目标系统的细节。控制软件配置还可以被称为自动化软件配置。在下文所进一步描述的一个示例中，控制软件配置由虚拟pea/功能模块提供，并且控制器不可知的配置文件由通用mtp提供。因此，控制软件配置作为与软件将在其上运行的硬件控制器解耦的控制软件的定义而存在，从而促进软件的可重用性、减少或消除供应商依赖性，并且降低开发/投资成本。
[0008]
控制器不可知性可以以以下创新方式提供：从配置文件中省略控制器特定参数和/或控制器特定逻辑功能，和/或在配置文件中提供默认参数和/或默认逻辑功能，以供在装置建造期间进行后期适配到特定控制器/硬件/模块/目标系统，和/或提供参数和/或默认逻辑功能，因为这些参数和/或默认逻辑功能应用于所有控制器/硬件/模块/目标系统(或特定类型的所有控制器/硬件/模块/目标系统)，所以它们是静态/恒定的，并且因此将在后续装置建造期间将保持不变，尽管模块集成到目标系统中。参数指定定义要由所述模块执行的应用的状态机的状态。因此，在一个示例中，参数包括以下各项中的一项或多项：(i)在装置建造期间用于到目标系统的适配的默认参数、或(ii)在装置建造期间将保持不变的静态参数。附加地或可替代地，要由所述模块执行的应用定义预定为独立于定义应用的状态机而可执行的逻辑，换言之，该逻辑独立于服务和控制服务的状态机的(的细节)而可执行，因此独立于目标系统的细节而可执行。
[0009]
在一个示例中，控制器不可知的配置文件还有利地指定所述模块的以下各项中的一项或多项：(i)一个或多个参数、(ii)一个或多个变量、(iii)一个或多个视图、(iv)一个或多个状态机、(v)一个或多个应用、(vi)一个或多个事件、(vii)一个或多个方法、(viii)一个或多个信号参考、(ix)一个或多个信号输出。
[0010]
在一个示例中，绑定还包括：匹配输入/输出信号。绑定可以包括以下各项中的一项或多项：(i)将根据另一这种控制器不可知的配置文件实例化的控制器软件的另一实例指派给所述模块的相同硬件控制器，以及(ii)将控制器软件附加指派到目标系统的另一模块的硬件控制器。这种灵活性在模块固有绑定到特定控制系统的现有系统中不存在。
[0011]
在第一方面的示例中，该方法还包括：在用于测试的虚拟控制环境中模拟所述模块的执行。虚拟控制环境可以包括以下各项中的一项或多项：(i)特定目标系统的软控制器、(ii)所述模块的软件表示、(iii)调试功能。通过尚未绑定到任何特定硬件控制器的所描述的控制软件配置的控制器不可知性质，促进了在虚拟环境中执行这种测试的能力以及虚拟装置编排。
[0012]
在一个示例中，所述模块包括工艺设备组件(pea)。在一个示例中，pea可以形成分布式控制节点(dcn)的一部分。在这些示例中的任一个或其他示例中，控制器不可知的配置文件可以包括定义pea/dcn的模块化类型封装(mtp)，例如，作为通用mtp。
[0013]
在第一方面的一个示例中，该方法还包括在用于项目执行的工作流程中：测试如
由控制器不可知的配置文件定义的控制软件配置；将输入/输出配置附接到模块化装置处的控制软件配置；结合虚拟控制器上的控制软件配置来测试输入/输出配置；将硬件控制器指派给根据控制器不可知的配置文件实例化的软件控制器的实例；向硬件控制器和软件控制器实例添加物理输入/输出；以及针对装置控制添加预先测试的监督控制和/或编排。因此，本文中所描述的控制器不可知性极大地促进了项目执行。
[0014]
在第三方面中，提供了一种计算机，该计算机包括处理器，该处理器被配置为执行任何前述方面的方法。
[0015]
在第四方面中，提供了一种计算机程序产品，该计算机程序产品包括指令，当该程序由计算机的处理器执行时，这些指令使得该计算机执行第一方面和第二方面中的任一方面的方法。
[0016]
在第五方面中，提供了一种数据结构，该数据结构定义了针对模块化装置的模块的控制软件配置，该控制软件配置指定针对所述模块的不特定于任何目标系统的参数，该数据结构被格式化为控制器不可知的配置文件，以供当所述模块在装置建造阶段期间被集成到目标系统中时，将根据控制器不可知的配置文件实例化的控制器软件随后绑定到所述模块的硬件控制器。在一个示例中，本文中所描述的虚拟pea/功能模块可以被视为定义用于模块化装置的模块的所描述的控制软件配置的数据结构。数据结构可以包括体现为本文中所描述的虚拟pea/功能模块的控制软件配置的所有和任何方面和要素。就这点而言，数据结构提供用来控制处理数据的模块的操作的功能数据，因此固有地包括模块的对应技术特征。
[0017]
参考下文所描述的实施例，本发明的其他方面和示例将变得显而易见并且得以阐明。
附图说明
[0018]
下文参考以下附图对示例性实施例进行描述。
[0019]
图1图示了针对模块化装置的建造工作流程；
[0020]
图2a和图2b图示了模块类型的建造工作流程；
[0021]
图3a和图3b图示了装置建造工作流程；
[0022]
图4图示了模块类型建造工作流程中的hmi定义；
[0023]
图5图示了模块类型建造工作流程中的标签定义；
[0024]
图6图示了模块类型建造工作流程中的服务定义；
[0025]
图7图示了模块类型建造工作流程中的状态定义；
[0026]
图8图示了装置建造工作流程中的拓扑定义；
[0027]
图9图示了虚拟pea/功能模块的内容；
[0028]
图10图示了使用虚拟pea/功能模块执行的建造工作流程；
[0029]
图11图示了使用虚拟pea/功能模块的项目执行；
[0030]
图12图示了opaf架构中功能模块的使用。
具体实施方式
[0031]
如所示，可以建造模块化装置。建造工作流程100分为两部分：(项目无关)模块类
型建造工作流程108和(项目相关)装置建造工作流程110。模块类型建造工作流程108可以由模块供应商或由模块化装置的所有者承担。装置建造工作流程110可以由装置所有者承担。
[0032]
在模块类型建造工作流程108内，完成了模块类型/pea 102的所有建造，意指：仪表制造、电气制造、控制制造；内工艺设备的物理连接；i/o编组和控制器硬件的选择；工厂验收测试。模块类型102在其在112处创建后准备在装置内使用，因为它提供了可以用于控制它的自有智能和opc ua服务器接口。每个模块类型102的接口通过例如根据iec63280 ed1 acd在114处生成mtp 106来描述。每个模块类型102使用服务将其内部功能暴露于监督控制系统作为服务。可以使用面向服务的架构。在每个服务的背后，执行所定义的状态机并且暴露状态。
[0033]
mtp 106稍后用于第二部分(装置建造工作流程110)，其中在118处集成到装置自动化中之前，导入116模块类型102的mtp 106并且创建针对模块类型102的实例。不同模块类型102的分散式自动化被集成在流程编排层(pol)104中。
[0034]
图2a和图2b更详细地图示了模块类型建造工作流程108。为了建造模块类型102，首先，在201处，定义模块类型的人机界面(hmi)，其可能类似于比如管道和仪表图的建造。在202处，从hmi中自动导出标签列表。标签列表包含自动化系统内使用的所有标签。在标签列表中，用户可以改变标签的参数。标签类型和参数两者均可以符合iec 63280 ed1 acd。在第三步骤203中，定义模块类型102的服务。这开始于添加服务并且附加地在203a处添加应当暴露于监督控制系统的必要服务参数。服务参数可能例如是针对服务“填充”的“量”，其用于告知“填充”服务应当向模块填充多少。在定义了服务之后，底层状态机的状态在203b、203c处用逻辑填充。该逻辑定义仍没有绑定到目标系统，但稍后在步骤204a和204b中用于创建目标系统特定信息。在步骤204a中，目标系统特定信息被创建并且可以用于模块类型102的自动化。现在，这绑定到目标系统并且目标系统不能稍后在装置建造期间被交换。在步骤204b中，创建描述模块类型102的接口的目标系统特定mtp 106。
[0035]
图3a和图3b更详细地图示了装置建造工作流程110。该装置建造工作流程110也遵循四步途径，其中在第一步骤301中，装置中所需的所有模块类型102都被添加到模块库。在添加由模块类型102的mtp 106定义的模块类型102之后，通过在建造工具中创建模块实例并且借助于材料和信息流将它们连接起来，这些模块类型可以在302处用于创建模块化装置的拓扑。在303处，模块实例可以用于基于它们的服务来定义可以由监督控制系统pol 104执行的序列。监督控制系统104在最后步骤304中根据来自建造工具的信息而被创建。
[0036]
图4图示了与模块类型建造工作流程108的步骤201相对应的模块类型102的hmi定义400。hmi编辑器404结合符号库402和属性编辑器406帮助用户定义hmi。自动生成设备列表410并且说明模块可视化的结构408。
[0037]
图5图示了与步骤202相对应的、模块类型建造工作流程108中的标签定义500(标签列表的建造)。标签编辑器502从hmi生成标签列表506并且根据相关标准呈现属性508，从而允许用户在504处设置属性值。
[0038]
图6图示了与模块类型建造工作流程108的步骤203a和203b相对应的、包括服务和服务参数的定义的模块类型的服务定义600。用户能够在604处定义服务的状态机，从可用服务列表606进行选取，并且能够使用服务参数编辑器604设置服务参数。
[0039]
图7图示了根据模块类型建造工作流程108的步骤203c的、针对模块类型102的服务状态机的状态的状态定义700。状态编辑器702允许用户从各种定义的状态710中进行选取，定义进入或离开状态时的动作712，指定原因714、作为原因的参数718、针对每个状态的跳变点716和互锁逻辑708、以及结果704、作为结果的过渡706、以及结果命令720。
[0040]
图8图示了根据装置建造工作流程110的步骤302的模块化装置的拓扑定义800，其中用户可以使用属性编辑器802和拓扑编辑器804以对先前定义的模块类型库806进行工作以定义建造结构808。
[0041]
图9示出了虚拟pea/功能模块900的内容。发明人开发了虚拟pea/功能模块900作为模块类型102的软件描述。概括地说，虚拟pea/功能模块900用作针对模块化装置的模块102的控制软件配置，其指定所述模块的不特定于任何目标系统的参数，诸如默认参数。用作控制软件配置的虚拟pea/功能模块900作为控制器不可知的配置文件(换言之，目标系统无关的配置文件，在一个示例中为通用mtp106)提供，以供当在装置建造期间将所述模块集成到目标系统中时，将根据控制器不可知的配置文件实例化的控制器软件随后绑定到所述模块的硬件控制器。
[0042]
更具体地，代替绑定到特定目标系统，虚拟pea/功能模块900仅包含目标系统应该包含的功能的描述。例如，除了关于在服务状态(图9中的应用914)内执行的逻辑的信息之外，虚拟pea/功能模块900还可以包含与上述模块类型102相同的信息。应用914包括在总体状态机中执行的状态。只有状态机是外部可见的。至于上文所描述的模块类型102，状态被定义为扩展的因果矩阵。应用914可选地还包含预先确定为独立于状态机可执行的逻辑。在设备保护的一个示例中，例如，如果阀门关闭，则必须停止所有后续泵以防止它们干转。预先确定为独立于状态机可执行的逻辑的其他示例包括：响应于容器中的压力变得过高，打开释放阀门，以及响应于气体管道中的压力过高，打开释放阀门以张开。这种类型的逻辑必须始终独立于服务和控制服务的状态机(的细节)而执行。其他这样的示例对于技术人员而言是显而易见的并且被本公开所涵盖，其不应被视为局限于任何一个这种示例。因为应当在状态内执行的应用914尚未绑定到任何目标系统，所以这使得虚拟pea/功能模块900能够移植到不同种类的目标系统。参数还可以指定目标模块102的通信。
[0043]
对于模块中使用的每个控制设备(传感器、阀门等)，定义参数集合。可能有针对模块的不同种类的参数，这些参数并非特定于任何目标系统，如下文的非限制性示例一样。其他这样的示例对技术人员而言是显而易见的并且被本公开所涵盖，其不应被视为局限于任何一个这种示例。
[0044]
例如，传感器具有一定范围，这意味着它可以测量1巴
…
10巴。这些参数取决于最终使用的硬件，传感器不能在其测量范围外进行测量。稍后(在装置建造期间)指派目标系统和设备时，那些参数设置一次，并且保持不变。当在功能模块的不同实例中使用不同的传感器类型来测量压力时，稍后会在目标硬件和设备被指派给功能模块实例(作为根据控制器不可知的配置文件实例化的软件控制器的实例)时(例如，在装置建造期间)调整该参数。控制传感器的块可以指定限制。限制是软件定义的数字，该软件定义的数字必须在测量范围内。如果测量值超过/低于所定义的限制，则该测量值用于发出警报。这些限制可以在应用的任何地方进行参数化。在一个非限制性示例中，为了提供不特定于任何目标系统的参数，可以设置默认限制，并且稍后在必要时发生改变。典型情况如下，在启动期间，限制设置
得更宽，以避免警报泛滥，并且一旦模块正在在稳定状态下运行，限制就会缩小以保持过程处于最佳操作状态。
[0045]
服务可能具有配置它应该如何执行的参数，例如，过程值在模块内部测量或来自其他地方。配置参数可以显示使用了哪个源。在不特定于任何目标系统的参数的一个非限制性示例中，可以指定默认源，以便为不执行其他参数化的情况提供所定义的状态。可替代地，该参数可能在调整期间被遗忘。在另一非限制性示例中，可以为设定点给出默认服务参数，例如，填充服务应当将容器填充到50％。
[0046]
所有上文所描述的参数类型通常由模块的opc ua服务器公开为opc ua变量。由于opc ua服务器不存在于虚拟pea/功能模块900中，并且只是后来添加到功能模块实例中，因此工程师可以为参数设置默认值。这些可以(i)随后在装置建造期间发生改变，(ii)由所指派的目标系统的实际opc ua服务器提供，或(iii)针对状态机的每个状态或针对每个服务或模块范围而设置(即仅给出了一个用于所有操作状态的参数值)。
[0047]
如图9所示，作为例如形式为通用mtp 106的控制器不可知的配置文件提供的虚拟pea/功能模块900为目标模块102指定以下各项中的一项或多项：(i)一个或多个参数906、(ii)一个或多个变量908、(iii)一个或多个视图910、(iv)一个或多个状态机912、(v)一个或多个应用914、(vi)一个或多个事件916、(vii)一个或多个方法904、(viii)一个或多个信号参考902、(ix)一个或多个信号输出918。
[0048]
因此，虚拟pea/功能模块900提供不具有嵌入式控制器和opc ua服务器的pea的自动化。虚拟pea/功能模块900的自动化可以在中央控制系统或分布式控制系统中执行，并且可以在一个控制器上具有几个虚拟pea/功能模块900。虚拟pea/功能模块900将控制应用软件与pea的控制器和输入/输出硬件解耦合。取代将控制应用软件绑定到硬件作为控制器，可以在稍后步骤中执行输入和输出硬件设计。软件描述可以作为虚拟pea/功能模块900导出到控制器不可知(换言之，与硬件无关)的mtp 106中。在装置建造期间，虚拟pea/功能模块900然后可以指派给控制器，并且输入信号/输出信号可以被匹配。因此，还可以将几个虚拟pea/功能模块900指派给单个控制器并且稍后与另一供应商或目标系统一起重新使用虚拟pea/功能模块900。
[0049]
图10图示了如使用功能模块900执行的建造工作流程100。在该示例中，功能模块建造工作流程1004由装置建造工具1002执行。功能模块建造1004与装置建造工具1002之间的接口可以由功能模块900的控制器不可知的mtp 106提供。
[0050]
使用虚拟pea/功能模块900的功能模块建造工作流程1004与上文所描述的模块类型建造工作流程108相同，不同之处在于不执行模块类型建造工作流程108的步骤204a，并且还在于步骤204b(考虑了目标系统未知，并且并非是生成目标系统特定mtp)包括生成没有目标系统特定信息的mtp 106。然后，使用该通用mtp 106来描述功能模块。mtp 106可以是基于xml的。在图10中，功能模块建造工作流程1004的步骤(a)与模块类型建造工作流程108的步骤201至203相对应。步骤1004(b)与步骤204b相对应，不同之处在于生成通用mtp 106。步骤204b/1004(b)可以由计算机执行。概括地说，功能模块建造工作流程1004涉及一种提供模块化装置的模块的控制软件配置的方法，该方法包括：接收所述模块的用户定义；并且基于用户定义来自动生成(1004(b))所述模块的控制软件配置(例如，虚拟pea/功能模块900)，该控制软件配置包括指定所述模块的不特定于任何目标系统的参数，并且提供控
制软件配置作为控制器不可知的配置文件(例如，通用mtp 106)，以供当所述模块在装置建造阶段期间集成到目标系统中时，将根据控制器不可知的配置文件实例化的控制器软件随后绑定到所述模块的硬件控制器。
[0051]
如上文所描述的，进行使用功能模块900的装置建造工作流程1006，除了步骤304还与模块化装置内部使用的功能模块900的实例相关地被执行。步骤1006(a)包括：向装置添加功能模块实例(作为根据相应的控制器不可知的配置文件实例化的软件控制器的实例)。通过参数循环，如上文所描述的，参数适应装置的需要。结果是功能模块实例(仍然是纯软件)的拓扑结构，其示出了这些实例如何物理连接以及实例参数如何适应装置的需求。在步骤1006(b)中，创建配方(recipe)，该配方示出了何时要执行、停止、暂停等哪个模块的哪个服务。工程师可以按顺序定义功能模块实例的编排，这些功能模块实例稍后可以在装置自动化系统执行。在步骤1006(c)中，选择执行功能模块实例的(硬件)控制器。功能模块实例可以在不同类型(甚至不同厂商)的单独控制器上执行，或多个功能模块实例可以在同一控制器上执行。特定功能模块实例的控制软件配置会自动下载或导出到所选择的控制器。一旦指派了控制器，特定控制系统所需的控制器特定参数就会自动添加到相应功能模块实例中。另外，过程设备指派给功能模块实例中定义的传感器和设备。例如，在这里，诸如激光水准仪发射器之类的物理传感器指派给来自功能模块实例的计划项目。附加地，设备特定参数会根据其默认设置(例如，如上所述的测量范围)自动调整。概括地说，装置建造工作流程1006涉及一种配置模块化装置的方法，该方法包括在装置建造阶段中：接收作为目标系统的模块化装置的用户定义，该定义标识根据用户定义要集成到模块化装置中的模块，其中至少一个所述模块与控制器不可知的配置文件相关联，该控制器不可知的配置文件指定所述模块的不特定于任何目标系统的参数；以及将根据控制器不可知的配置文件实例化的控制器软件自动绑定到目标系统的所述模块的硬件控制器，该绑定包括根据用户定义将参数自动适配到目标系统。因此，在装置建造内，虚拟pea/功能模块900的每个实例被指派给特定目标系统，这是建造工作流程中的新步骤。然后，与生成操作环境(装置建造工作流程110中的步骤304/1006(c))同时地，在最后步骤中执行到目标系统的实际绑定。这种非常晚的绑定具有以下优点：虚拟pea/功能模块900不绑定到任何目标系统并且可以指派到任何支持的目标系统。附加地，多个虚拟pea/功能模块900可以指派给单个目标系统，从而节省硬件成本。
[0052]
图11图示了使用虚拟pea/功能模块900的项目执行1100。功能模块1108首先在办公室1102中开发并且在虚拟控制环境1106中“上演”，虚拟控制环境1106可能涉及模拟、目标系统的仿真器或其他调试环境，并且可能涉及工厂验收测试(fat)1110。可选地使用存储功能模块(例如，1132、1134、1136)的模块库1130开发模块，这些功能模块已经在其他项目/装置内建造并且能够在正在开发的装置内重复使用。在开发它们之后，功能模块1108被移交给场地1112，在该场地1112中，必要的物理i/o 1116、1117指派给功能模块1108。例如，可以使用diced途径在1114处指派i/o：具有自动检测、询问、配置、启用和记载的i/o。在指派物理i/o之前，可以在虚拟控制环境1106中进行开发。附加地，假设功能模块作为纯软件存在，借助于虚拟编排1104(如图10所示，装置建造步骤1006(b))，编排可以至少部分地进行/准备。在场地1112中，功能模块1108与物理i/o 1116、1117一起在1118处进行测试并且一切都在现场装运，其中目标系统绑定最终使用装置控制1124/编排建造1122来执行，以在它们
在1126处进入生产之前，将功能模块1108绑定到硬件控制器1120。该工作流程可以在1128处以功能模块逐个按顺序开发的方式执行。然而，还可以实现高度并行化，从而实现快速项目执行。
[0053]
可以结合当前标准化活动来对功能模块900进行讨论。一个突出示例为opaf。在opaf中，功能模块/虚拟pea可以被视为分布式控制节点(dcn)的一部分，该部分可以针对滑橇(skid)、封装单元或其他类型的模块而被执行。图12在1200处图示了opaf架构中本文所述种类的功能模块1244的用途。在dcn 1242内，可以执行若干功能模块1244，这些功能模块1244可以用于若干滑橇1274、封装单元1284或其他类型的模块1286的自动化，若干滑橇1274、封装单元1284或其他类型的模块1286中的每个例如包括设备i/o 1276、i/o 1278、过程自动化设备信息模型(pa-dim)1280、以及i/o条件1282(io if 1282)。在区域1288内，示出了功能模块1244并且示出了与物理实例的连接。opaf中的用途可能补充opaf中pea的用途。本领域的读者将熟悉图12中出现的其他要素，诸如：包括erp 1234、质量1236和其他1238的应用1232，其形成例如企业it 1230的一部分；具有应用1206、控件1208和数据存储库1210的过程操作1204，该应用1206包括生产1212、维护1214、操作/hmi 1216，该控件1208包括逻辑1218、互锁和序列1220，该数据储存库1210包括mtp库1222、信息模型1224和历史1226；滑橇(skid)1258、封装单元1270和其他模块类型1272，它们包括pea mtp 1260、i/o 1262、内部控制1264、服务1266和数据1268。各种要素由opc ua
–
mtp信息模型1256汇集在一起。
[0054]
发明人所做的开发包括pea控制应用的虚拟化。取代pea软件与特定目标系统之间具有硬性绑定，虚拟pea包含非常晚绑定到目标系统所需的所有信息。绑定在装置建造期间完成，并且虚拟pea可以指派给所需的目标系统。相同的pea类型可以指派给不同的目标系统。可以在同一个控制器上执行多个虚拟pea。发明人所做的开发可以概括如下：
[0055]
1、虚拟pea/功能模块的概念：
[0056]
οpea的虚拟定义，其被描述为目标系统无关mtp。
[0057]
ο虚拟pea的信息，其包括参数、变量、视图、状态机、应用、事件、方法、信号参考、信号输出。
[0058]
2、在用于测试的虚拟控制环境中执行虚拟pea的概念：
[0059]
ο虚拟控制环境可能是特定目标系统的软控制器。
[0060]
ο虚拟控制环境可能是pea的软件表示。
[0061]
ο虚拟控制环境可能是另一类型(比如，调试功能)。
[0062]
3、将虚拟pea随后绑定到目标系统的概念：
[0063]
ο装置/编排建造期间的绑定。
[0064]
ο在单个控制器上指派几个虚拟pea。
[0065]
ο将虚拟pea的相同实例指派给不同的控制系统硬件(例如，ac800m和ac500)。
[0066]
ο将输入输出信号指派给虚拟pea。
[0067]
4、使用虚拟pea/功能模块执行项目的工作流程：
[0068]
ο步骤1：在虚拟环境中建造虚拟pea。
[0069]
ο步骤2：测试虚拟pea。
[0070]
ο步骤3：将所需i/o(pa-dim)附接到场地处的虚拟pea实例。
[0071]
ο步骤4：结合虚拟控制器上的虚拟pea测试i/o配置。
[0072]
ο步骤5：将控制器指派给虚拟pea实例。
[0073]
ο步骤6：将物理i/o添加到控制器和虚拟pea实例。
[0074]
ο步骤7：为装置控制添加预先测试的监督控制/编排。
[0075]
根据上文可以清楚地看出，可以提供包括机器可读指令的一个或多个计算机程序，这些机器可读指令当在一个或多个计算机上执行时，使得该一个或多个计算机执行所述方法的自动执行的步骤。此外，根据上文可以清楚地看出，非暂态计算机存储介质或计算机程序产品和/或下载产品可以包括一个或多个计算机程序。一个或多个计算机然后可以使用该一个或多个计算机程序进行操作。然后，一个或多个计算机可以包括非暂态计算机存储介质/计算机程序产品和/或下载产品。
[0076]
虽然在附图和前面描述中对本发明进行了详细说明和描述，但是这样的说明和描述被认为是说明性的或示例性的而非限制性的。本发明不限于所公开的实施例。通过研究附图、公开内容和从属权利要求，本领域技术人员在实践所要求保护的发明时可以理解并实现对所公开的实施例的其他变化。