AMLBook1: 初学者指南 | 第二章 2.6 AutomationML概念的拓展 Extended AutomationML Concepts [翻译]

与工业伙伴合作，AutomationML协会开发了几个有用的扩展概念。

• AML Port conceptAML端口的概念允许对复杂的接口进行高级描述。AML端口由一组AML它们属于接口组成，类似于插头或插座。
• AML Facets conceptAML Facets概念允许存储AML对象属性及接口子集。它们可视为工程数据的视图。
• AML Group conceptAML允许组的概念AML单独的视图存储在物体的子集上。它们可用于过滤不同工程工具的植物树对象。
• AML PPR concept AML PPR概念（PPR=过程工艺 Process-产品 Product-资源 Resource）允许在以过程为中心、以产品为中心或以资源为中心的综合视图综合视图(包括它们之间的关系)的基础上高层次结构化。
• AML multilingual expressionsAML多语言表达允许用不同的语言存储文本表达。
• Lists and attribute arraysAML允许列表和属性数组建模属性列表或属性数组。
• AML containerAML容器格式允许将多个文件包装成一个包。

利用建模规则CAEX 3.0建模嵌套接口的能力。端口建模需要以下步骤：

1.   以端口建模为相关AML对象的CAEX接口必须直接或间接地从接口开始AML标准接口端口衍生。 

2.  建模嵌套接口。它们可以是任何类型的。嵌套接口可再次嵌套，层次深度无限制。 

3.  在两个端口之间创建一个，以连接两个端口CAEX内部链接。该链接本身意味着嵌套接口正确连接，无需进一步链接。 

4.  嵌套接口之间的连接可以单独建模。 

5.  可选择设置端口的属性Direction；允许的值是In、Out和InOut。这现自动方向兼容。 

6.  可选择设置属性Cardinality，它允许建模连接的最小或最大次数。 

7.  可选择设置属性Category来指定端口的类别。语法是用户定义的。这对于自动兼容性检查很有用。 

图2-81给出了一个关于图2-81的信息AML以端口概念为例。对象Station包括子对象Module A和Module B，两个子对象都有一个带嵌套接口的端口。每个端口都是通过端口接口建模的，端口接口是从AML标准的InterfaceClass从端口衍生出来的，包括一组嵌套接口。使用标准接口CAEX内部链接（CAEX InternalLink）连接的。这种关系意味着两个端口相互连接。子接口的内部链接没有详细建模，只有端口连接。除此之外，AML建模和存储对子接口之间的每个单独链接。 图2-82描述了对象模型，图2-83描述了图2-81中描述的示例系统AML实现。

facet概念背后的想法是，AML对象可能有数百个属性或接口，但对于一个项目任务，只有一个子集是有意义的。如果我们能够以一种方式准备数据，使外部软件算法（AutomationML此外，很容易只获得重要的数据，这将是非常实用的。 例如，考虑对象的属性，命名一个有用的对象PLC代码模板，接口将描述该模板的输入或输出。因此，只需要模板名称、输入和输出PLC可以自动生成代码生成算法PLC代码。 这种外部算法所需要的是一个表面。这是一个AML对象关于父亲的对象AML对象的属性或接口的子视图。该概念用于过滤属性和接口，并且只关注特殊数据。AutomationML定义了AML RoleClass Facet。

一面的建模规则是：

• 识别AutomationML InternalElement或SystemUnitClass这些属性和接口具有特殊意义，应过滤。
• 将该面作为CAEX InternalElement的模型，与RoleClass Facet有直接或间接的关联。AML Facet对象必须是相关的InternalElement或SystemUnitClass子对象。
• 一个InternalElement或SystemUnitClass可以有任何数量Facet对象。
• Facet它是唯一的ID识别。他们的名字只显示名字。
• 每个Facet属性将反映父对象任意数量的现有属性。镜像父对象中的子属性和其他从属性是可能的。
• 一个AML Facet对象必须只包含镜像属性或镜像接口(见第一) 2.2.12.了解更多关于镜像概念的细节)。
• Facets可以有任何数量Facet attributes和Facet interfaces。
• 不属于父对象的，不允许不属于父对象。Facet attributes。
• 每个Facet interface 必须镜像父对象的现有接口。可以镜像父对象中的嵌套接口。
• 不属于父对象的，不允许不属于父对象。Facets。
• Facets新的子对象、属性或界面不或界面。
• Facet objects不能嵌套。
• Facets现有属性或接口不得修改。

图2-84通过例子解释AML Facet概念：对象 "Conveyor1 "包括属性A和B接口X和Y。分配的Facet对象PLCFacet指属性A和接口X，而分配的Facet对象HMIFacet指属性B和接口Y。

Use case属性A可能是供应商特定的PLC代码模板的名称，描述对象Conveyor自动化功能1X可能是该代码模板所需的输入信号的名称。属性B可能是输送机的特定HMI模板的名称，接口Y可能是应该在HMI上呈现的信号。有了这些信息，PLC或HMI生成器就能自动生成一个HMI屏幕。相关的AML结构如图2-85所示。

组概念背后的想法是，一个实例层次可能包括数百个不同的AutomationML对象，但对于某项工程任务来说，只有其中的一个子集是感兴趣的。如果我们能够以一种方式准备这些对象，使外部软件算法（AutomationML之外的）能够很容易地只获得对他们的任务很重要的对象，这将是非常实用的。 例如，考虑一个工程算法寻找一个工厂的所有输送机，以便自动生成相关的输送机功能块。因此，如果我们能提供一个工厂的特定视图，只提供它所需要的对象，这对该算法会很有帮助。 组正是提供了这一点：以单独的方式构造已经存在的对象，允许软件算法轻松获得对它来说很重要的层次结构。

一个AML组的建模规则是:

• 在现有的对象模型中识别出感兴趣的对象。
• 将一个AML组建模为CAEX内部元素，与RoleClass组有直接或间接的关联。
• 一个AML组对象可以在InstanceHierarchy或SystemUnitClass的任意位置进行建模。
• 组是由其唯一的ID来识别的。他们的名字只是显示名称。
• 一个InternalElement或SystemUnitClass可以有任意数量的Group对象。
• 一个AML组对象只包含镜像的InternalElements和/或进一步的Group对象（关于镜像概念的更多细节，见2.2.12.6）。
• 组对象可以被嵌套，但不应被用来描述植物层次结构。
• 一个AML组对象可以存储额外的信息作为属性或接口，以描述组的具体信息。这些额外的属性或接口与所包含的镜像对象的属性或接口不完全相同。
• 不允许改变镜像对象的现有属性、接口或端口，也不允许向镜像对象添加额外信息。
• 如果使用，属性AssociatedFacet必须有一个值，提供每个镜像对象的现有Facet的有效名称。这个属性的应用在2.6.5中描述。

图2-86说明了该组的概念。它由一个站台组成，该站台包含对象 Conveyor1, Conveyor2, Robot 和 PLC。此外，对象Group1和Group2反映了所关注的对象。Group1只提供了一个关于输送机的重点视图，而Group2只包含PLC的相关对象。 AML模型如图2-87所示.

组和面的概念都有助于外部工程工具从他们的特殊角度获得提供的数据。这两个概念的结合使其更有价值。如果一个算法可以很容易地找到感兴趣的对象（在组中）和它们各自的属性和界面（在面中），那就非常实用了。 例如，考虑一个工程算法，寻找一个工厂的所有输送机，以自动生成相关的输送机功能块。然后，它需要输送机的某些属性或接口来实现功能块的互连。因此，如果能提供工厂的某个视图，只提供它所需要的对象，这对该算法会很有帮助。 组和面的概念之间的关联是通过属性AssociatedFacet来模拟的。想象一下，一个算法为所有的传送带自动生成HMI模板。它寻找一个只提供输送机的组，并找到AssociatedFacet属性，提供感兴趣的面的名称。然后，对于每个传送带，该算法将进入面对象，立即找到属性和接口，准备使用。

图2-88是一个结合了组和面概念的例子。所示的实例层次描述了一个由AML对象 Conveyor1和 Conveyor2组成的AML对象Station。这些输送机各自拥有两个属性A和B以及两个接口X和Y。此外，两个面PLCFacet和HMIFacet过滤感兴趣的属性和接口。 AML对象Groups提出了嵌套组Group1和Group2。两者都指的是输送机对象，但有不同的Facet关联。 现在，PLC代码生成算法可以通过实例层次结构运行，识别所有与PLCFacet有关联的组，然后通过评估引用的PLCFacet来执行代码生成。 以类似的方式，HMI生成算法可以通过实例的层次结构来识别所有与HMIFacet有关联的组，然后通过评估引用的HMIFacet来执行HMI生成。 这个例子的AML模型可在[BookLink@]下载。

下面的例子描述了一个算法的虚构功能，该算法要从HMI模板中生成一个用户界面。为此，该算法必须识别工厂中的输送机，为每个输送机实例化一个模板，然后分配信号和属性。 我们假设，一个AML传送带对象的属性B包含一个HMI面板的名称，该面板将被用作可视化传送带和所需的过程变量的基础。 一个工程算法确定了所有要在用户界面上进行可视化的对象，并找到了传送带1和传送带2。 基于两个传送带的单独接口Y，工程算法将模板B实例化两次，代表两个传送带，并连接相应的实例接口Y。

PPR概念已被证明是掌握复杂规划结构的有效手段。它是各种工业应用的基础，

• 例如物流处理（参考工业食谱（见[DRA21]第13章），
• 复杂的工业工具链（见[DRA21]第20章），
• 基于AML的企业控制系统集成（见[DRA21]第25章），
• 或研究活动（见[DRA21]第30、33、34、35章）。

PPR概念起源于数字工厂和相关的电子化描述生产过程中涉及的所有计划数据的必要性。

在这里，资源、过程和产品数据的三部分划分已在实践中得到证明，并已在数字工厂软件工具中得到应用[SCDR09]。资源、产品和过程是相互关联的；一个产品是用资源处理的，而资源又是执行过程的。这种三视图的概念（见图2-91）在其他项目和领域也得到了追求，例如，在制造执行系统（MES）领域，ISA95与此模型类似（也见[IEC 62264]和[AKS+07]） 在生产工程中，重点往往是要制造的产品。这决定了哪些工艺适用于所使用的材料和中间产品，以及它们需要哪些资源或机器、系统或部件。资源用于运输、处理和将部分产品加工成离散的最终产品。生产过程的结果是由例如生产单位的数量来衡量的。 这种分类可以转移到过程工程中，不同的是，通常没有离散的最终产品或件数。在工艺工程中，诸如锅炉、泵或阀门等资源，通过管道或软管相互连接，将起始材料连续或不连续地以所谓的批次加工成最终产品。这些可以是液体或固体材料，例如饮料、食品或化学品，其中生产的特点是化学或生物技术过程和反应。最终产品不是以离散的数量来衡量，而是以体积或质量来衡量。

在AutomationML中，一个资源resource指的是参与生产的设施。例子包括系统、机器人、工具、机器、设备，以及软件和相关的状态，甚至可能是信息。这与数字工厂中资源的使用和指定相呼应。因此，按照这里的理解，资源既可以是生产系统的硬件组件，如机器或输送技术，也可以是相关的软件系统，如过程可视化。在AutomationML中，资源是由工厂的拓扑结构表示的，它被映射为CAEX的对象层次。 在AutomationML中，产品product被理解为生产的部分、中间或最终产品。这可以是分层的结构。一个例子是一辆汽车，有车身、车轮、变速箱、发动机等子产品。产品包括测试和检查结果，以及产品数据和相应的文件。在AutomationML中，产品不一定是件商品；液体也是产品，可以用滚筒进行分类和系统地存储。 在AutomationML中，一个过程process代表一个生产过程，包括相关的子过程。它描述了由资源执行的行动。这包括过程参数、过程流和工程。在技术领域[BRO07]，一个流程被称为改变结构的过程。这也与AutomationML中的使用相对应。在生产工程中，最终产品是由各种子产品制造出来的，在过程工程中，例如，对物质进行化学转换。

• 在以资源为中心的观点 resource centric view中，资源构成了模型中的核心部分：它们执行流程并处理产品。在AML中，资源是一个参与生产的实体，包括工厂、机器人、机器、它们的状态、设备、可能的信息等等。据此，资源可以是生产系统的硬件组件，也可以是软件系统，例如SCADA系统。在AML中，资源通常在工厂的层次结构中建模，形成工厂的拓扑结构。
• 在以产品为中心的观点 product centric view中，生产的产品是考虑的重点。它决定了哪些工艺应该应用于材料或中间产品，哪些设备应该被使用。这在连续、离散或批量控制领域都是有效的。AML中的产品描述了生产出来的货物。它可以分层次地建立起来。重要的是，产品不一定是最终产品。测试结果属于产品，也属于产品数据和相应的文件。
• 在以过程为中心的观点 process centric view中，过程构成了模型的中心项目。AML中的一个流程代表了一个包括子流程的生产过程。过程参数、过程链和过程规划构成了过程的一部分。在技术上，流程改变了产品。这与AML中的用法相对应，因为最终产品是由不同的子产品生产出来的，或者化学处理改变了物质。然而，过程与资源有关系，反之亦然。

这三种观点都有各自的理由，没有一个是领先的。PPR概念包括以平行和独立的方式对所有三种观点进行完全建模。然后，资源、产品和过程的所有表征都是相互联系的。结果，我们得到了一个建模网络，在任何时候都能提供有关信息。

• 什么过程利用了什么资源来处理什么产品。
• 什么资源参与了什么产品的哪个过程。
• 什么产品在哪个过程中使用什么资源被处理。

反之，如果一个部件出现故障，可以立即做出反应。

• 如果一个过程发生故障：哪些资源和哪些产品受到影响？
• 如果一个资源发生故障：哪个过程和哪个产品受到影响？
• 如果一个产品发生故障：哪个资源和哪个过程受到影响？

最后，在三个独立的层次中进行划分是非常有帮助的。综合企业建模[BMS06]也考虑了这种划分。在研究项目Modale[ABH04]以及研究项目ProduFlexil[EOB07]、[SBO+08]中，也对资源、产品和流程进行了区分。一个产品是，例如，一个控制台或一个车身；一个过程是，例如，一个焊接过程或输送过程；和一个资源是，例如，一个运输系统或一个转盘。另外[YGC+07]以及[DYM+07]都涉及到将所有涉及的部件划分为过程、产品和资源。常见定义的例子可以在[MIC05]中找到。[SoOl02]论述了基于特征的产品、过程和资源的整合，并引用了关于这一主题的其他资料。

用图2-92所示的具体例子来解释这个概念。它包括一个进料和出料输送带C1和C2，以及一个转盘TT1和一个机器人RB1作为工厂的资源。机器人将车轮安装在车体上。轮子和车体（有轮子和无轮子）都被显示为产品。本例中的生产过程是运输、车削和装配。 在图2-93中，传送带、转台和我们例子中的机器人被分配到资源角色。带轮子的车身和不带轮子的车身，以及轮子本身，被分配给产品角色。过程角色对应于运输、车削和装配的过程。所有的元素都作为一个独立的实例层次结构存储在相应的子树中 例子中的每个元素都有一个PPRConnector接口。图 2-94 表示该例子的完整链接。实线表示从资源到过程的链接，虚线表示从过程到产品的链接，虚线表示资源和产品之间的链接。这显示了其复杂性。因此，可以省略多余的连接。

在第一步中，必须创建三个内部元素，与标准角色类ProductStructure、ProcessStructure或ResourceStructure相关联（见图2-95）。 第二步，需要对确定的产品、流程步骤和资源进行建模（见图2-96）。 为了能够对元素之间的连接进行建模，所有的元素都有一个PPRConnector接口（见图2-97）。通过这个接口，CAEX s 可以用来创建元素之间的连接，从而从语义上回答谁与谁有关的问题。举几个例子：一个资源可以链接到它可以处理的产品；或者一个资源可以描述可以在该资源上执行的过程。在应用实例中，每个元素都有这样一个PPRConnector接口。 链接的数量很快就会变得混乱；这可以通过省略多余的链接来减少。 在最后一步，必须对相关流程步骤、产品和资源之间的联系进行建模。AML模型可在[BookLink@]找到。

工程数据通常是用几种语言规划的。在国际团队中即时切换语言以实现全球合作是很有帮助的，但在建模和交换数据时需要多语言支持。多语言表达式的概念旨在将多语言信息存储在同一个AML文件中。

多语言表达式的建模规则是:

• 一个多语言属性被建模为一个CAEX属性。这个属性的值是默认的表达方式，如果没有要求特定的语言或者要求的语言没有被建模，就会使用这个表达方式。
• 一个语言表达的属性被建模为一个嵌套的属性，它引用AutomationML标准属性类型LocalizedAttribute。
• 每个子属性的名称应是符合RFC 1766的语言表达，例如，de代表德语，fr代表法语，en代表英语。语言属性的值应是相关语言的翻译文本。
• 复合语言的缩写是，例如en-US代表美国英语，fr-CA代表加拿大法语。
• 缩写列表可在https://docs.microsoft.com/en-us/windows/ win32/wmformat/language-strings中找到。

图2-98以一个机器人为例说明了这一点，该机器人的属性Price是以不同语言存储的。

我们建议在属性数据类型库中对多语言表达进行建模，这可以帮助消除冗余的内容。一旦被定义，这些多语言属性就可以被实例化，并且可以从实例中删除翻译。

总结 这种技术的一个主要好处是，一个属性的语言变体在属性类型库中只存储一次。

图2-99通过重塑图2-98的属性来说明这一点。

AML库可以作为单独的文件来存储，这就减少了项目文件的复杂性，简化了重复使用。起始点是一个包含项目数据和属性类型库的AML文件。手动外化多语言属性类型库的步骤是:

• 步骤1：创建一个项目AML文件的副本。对AML文件的副本进行以下操作。
• 适当地重命名该副本，例如 “MultiLanguageAttributes.aml”。
• 打开该文件，除了感兴趣的属性类型库外，删除任何不相关的内容。
• 第二步：在原始文件中。
• 删除属性类型库。
• 创建一个新的CAEX 。
• 创建一个别名，命名该别名并存储外部AML文件的路径。
• 通过用新的别名替换原始路径来更新所有来自属性的引用。

在结果中，我们有两个文件：没有库的项目文件，和第二个只有多语言库的AML文件。

列表由相同数据类型的项目组成，并且可以包含更多的列表，从而可以对任意尺寸的数组进行建模。 一个列表在AML中被建模为一个包含嵌套子属性的列表属性。列表属性充当了列表的容器。CAEX属性并不明确地对项目的顺序进行建模。因此，有序的列表和无序的列表需要被显式地建模。列表的建模规则是:

• 对于一个没有排序的列表，创建一个CAEX属性并引用AML标准属性ListType。对于一个排序的列表，参考AML标准属性OrderedListType。这个CAEX属性没有Value、DefaultValue或Unit。允许有标题信息。
• 将项目建模为列表的子属性。所有项目必须有相同的类型。
• 未排序的条目在列表中必须有唯一的名称。已排序的条目必须由一个领先的连续数字标识：1、2等。允许使用前导零 0001, 0002, 等等。

一个数组被建模为一个列表的列表。数组的建模规则是:

• 创建一个CAEX属性并引用AML标准属性ListType或OrderedListType。这个CAEX属性没有Value、DefaultValue或Unit。允许有标题信息。
• 将数组的行作为列表的子属性。所有项目都是ListType或OrderedListType的类型。
• 将数组的列建模为每个子列表项的子属性。
• 这个技术可以多次使用，以便为多维数组建模。

图2-101用一个机器人的例子说明了这一点，这个机器人的位置随着时间的推移被存储在一个数组Positions中。每个位置有4个条目。时间、X、Y、Z。

由于一个AML文件可能由许多子文件组成（例如外部CAEX库、参考的几何文件、手册、图标、标识等），AML支持遵循开放包装公约（OPC）的容器格式。容器格式将多个相关文件打包成一个文件。它是一个遵循ECMA OPC惯例的压缩文件。

按照OPC惯例，AutomationML标准根据表2-29定义了关系类型。一般的建模规则是:

• 一个AML容器被存储为ECMA OPC档案，提供数据压缩。
• 一个AML容器必须是独立的或与环境相连的。
• 一个独立的AML容器必须包括所有相关的文件，这些文件之间只有局部的相互联系。
• 一个环境连接的AML容器可以包含与AML容器之外的公共文件的URI的链接。
• AML容器文档的文件扩展名是".amlx"。

让我们假设一个简单的AML项目结构，所有的AML标准库都外包在一个外部AML文件中；导致一个项目由两个AML组成。两者都被打包成一个amlx文件。图2-102说明了这一结果：我们没有处理多个文件，而是得到一个包含所有内容的容器文件。 扩展名amlx是一个ZIP压缩文件。

图2-103说明了*.amlx文件的内容：我们发现预期的部分文件和额外的组织文件。

现在让我们来看看组织文件。文件[Content_Types].xml根据MIMEType的定义，定义了已知的后缀及其类型（见图2-104）。

文件夹_rels包括另外两个文件：隐藏文件.rels和文件AMLContainerExample.aml.rels（见图2-105）。

文件.rels提供了所有包含文件的列表，并定义了每个文件的类型、文件名和标识符（见图2-106）。

图2-107显示了文件AMLContainerExample.aml.rels的内容。它包含了根AML文件和相互连接的独立库文件之间的关系。