AMLBook1: 初学者指南 | 第二章 2.2 The CAEX 3.0 元数据模型 [翻译]

最新推荐文章于 2022-10-05 10:06:31 发布

殷光甫

最新推荐文章于 2022-10-05 10:06:31 发布

阅读量820

点赞数

分类专栏： AutomationML 文章标签：统一建模语言

AutomationML 专栏收录该内容

9 篇文章 22 订阅

订阅专栏

2.2.1 关于CAEX作为元数据模型 About CAEX as meta data model

对象和对象层次在AML中起着核心作用。下面的章节将全面介绍CAEX。CAEX最初是为过程工程和控制规划工具之间的控制相关信息的数据交换而开发的[EPP03], [DrFe04a][DrFe04b]。但CAEX是一种通用的面向对象数据的建模语言。它的语言元素不限于过程工程，也可以不受限制地用于其他领域，例如生产规划或建筑自动化。它支持静态对象结构的建模，并有一个强大的库概念，允许存储经过验证的组件、接口、需求和角色。CAEX最初在[IEC 62424:Ed1]中被标准化。最新的标准是[IEC 62424:Ed2]。
CAEX是一个元模型。经常被误解，"元 "是一个非常自然的概念。与传统的数据模型相比，元模型有很大的优势。

传统数据模型的例子
考虑一个以传统方式建模的地址簿：每个地址都提供预定义的姓名、地址、电话号码等字段。每个地址都遵循一个固定的建筑计划。但是如果你想添加一个新的字段，例如 “GPS坐标”，你很可能不能。一个变通的办法是将其添加到一个注释字段中，但这个字段不知道其含义，当你点击它时不会打开一个导航工具。数据模型通常是固定的，不可扩展的。如果立即进行扩展，就需要改变模型，这很快就会导致版本管理的挑战。

元模型是不同的。我们不是具体地预先定义所需的数据字段，而是在一个更高的抽象层次上对数据进行建模。我们每天都在使用元模型。一个非常常见的元格式是我们的口语，例如德语或英语。句子遵循抽象的规则：语法、正字法、句子结构，所使用的词也有语义。口语是可扩展的，它们每天都在扩展和改变其词汇和语义。一个元概念比静态模型更能遵循人类的直觉。

元模型的例子
在我们的地址簿的例子中，元模型不会预先定义一套固定的地址相关的字段。相反，它将只有一个名为field的字段，它有诸如名称、值和语义等通用属性。元模型是抽象的；它超越了具体的项目，而是抽象的项目。这使得地址簿的架构非常简单：它可以存储无限多的地址条目，每个地址条目都可以持有字段，不管有多少，而字段的语义被存储在一个库中，这个库又是可扩展的。这个概念可以被扩展，每个字段的含义都可以被明确地模拟出来。它涵盖了所有即将到来的地址条目，甚至是未知的。地址簿模型可以在不改变元模型的情况下被扩展。

2.2.2 CAEX模型的持久化: CAEX文件 Persistence of a CAEX model: CAEX files

CAEX定义了面向对象的数据建模的构造规则。在CAEX文件中建立对象信息模型的能力是存储、归档或提交信息的一个重要选择。然而，作为文件的存储只是传输对象模型的一种选择；对象模型也可以保存在内存中，或者通过软件服务的方式，在没有任何文件的情况下传输。传统上，将数据存储为文件的能力被称为持久性或序列化。

CAEX建模语言的构造规则被定义在一个XML模式文件CAEX_ClassModel_V.3.0.xml中。这个文件遵循XML模式的惯例，包含了CAEX构造规则的电子计划。如果一个软件包生成了一个CAEX文件，就需要CAEX模式来检查这个文件。在这方面，模式文件必须始终与CAEX文件一起提供。可选的是，CAEX文件可以分布在几个文件中。例如，如果一个库被存储在一个单独的文件中，这就很有用。图2-3说明了这一点：一个CAEX模型通常是一组文件：至少有两个：文档和模式文件。

CAEX 3.0模式是由IEC 62424 Ed. 2的标准，定义了所有CAEX数据类型的结构。该模式文件可以下载[BookLink@]，也可以由AutomationML编辑器生成，如5.5.7节所述。CAEX模式文件被命名为CAEX_ClassModel_V.3.0.xsd。每个CAEX的XML文件必须符合模式定义。这些CAEX构件（随后被称为CAEX元素）决定了类、接口、属性、实例和所有其他元素必须如何在语法上进行结构化。

CAEX模式作为CAEX文档的 “蓝图”，允许自动检查CAEX文档是否与该蓝图相一致。这个程序是XML的一个基本功能，并且得到了世界上广泛的工具的支持。
下一节介绍了基本的CAEX元素并解释了它们的应用。关于CAEX的规范性条款，请参考[IEC 62424:Ed2]。

2.2.3 CAEX建模的一般原则 General CAEX modelling principles

2.2.3.1 CAEX 架构

图2-4通过其模式定义说明了CAEX 3.0的一般架构。

CAEX元素代表CAEX文档的根节点。一个CAEX文档只有一个根节点。
、、、和是用来模拟文档组织信息的元素，例如版本信息。关于如何对版本信息进行建模的细节在2.2.13节中描述。
这个元素允许对外部CAEX文件的引用进行建模。它是将对象模型分割成不同文件的基础，并通过重新使用单独存储的库信息来最小化模型大小。
是项目数据的根节点。它持有一个对象实例的层次结构。允许有多个层次结构。更多细节在2.2.3.5和2.2.4.2中给出。
2.2.4.2.
CAEX元素、、和是用于建模不同库类型的容器元素。它们是可扩展的，允许对用户定义的或规范的类进行建模。

2.2.3.2 CAEX结构示例

图2-5通过CAEX文档的一个部分来说明CAEX架构，其中包含一个库MySystemUnitLib和一个对象层次结构MyHierarchy。在图片的右边，相应的CAEX元素被突出显示。

CAEX元素是CAEX文档的起始点。它持有关于文件的版本信息。
CAEX元素及其类型的类描述了一个预定义的类库。一个CAEX文档可以包含任意数量的类库，这些类库在文档中用唯一的名称来区分。除了这些类库，CAEX还支持接口库和角色库，这在第2.2.8节和第2.2.9节有解释。系统单元类库通常被用来为供应商的特定产品目录建模。它们的内容是专有的，库的所有权属于一家公司。在这个例子中，该库定义了两个机器人类。
CAEX元素代表一个对象树的根节点。它由一个任意深度嵌套的类型的对象的层次结构组成。一个CAEX文档可以存储任意数量的层次结构。
CAEX元素描述了一个真实或逻辑的植物对象及其属性和交叉点。的结构与的结构相同。这允许通过复制类来创建实例树中的对象，或者反过来说，将实例层次结构的一部分运回类库中。在这个例子中，它描述了一个带有机器人、PLC和传送带的站。

2.2.3.3 实例和类的区分 Identification of instances and classes

在一个异质的工具环境中，不同的工程工具使用不同的概念来识别对象，例如一个唯一的名称、唯一的标识符或唯一的路径。有些工具允许在生命周期内改变标识符，有些则不允许。CAEX中和了这种多样性，定义了一个强制性的对象识别概念。

CAEX类或类型（RoleClasses、InterfaceClasses、SystemUnitClasses和AttributeTypes）、属性、库和CAEX InstanceHierarchy是由它们的CAEX标签Name识别的。每个名称在其同级中必须是唯一的。这个概念保证了通过路径引用一个库、一个类、一个类型或一个属性会产生一个唯一的结果。类的引用是通过完整的路径来完成的，使用相应的路径分隔符，按照0。

所有CAEX实例（InternalElements和ExternalInterfaces）都由它们的CAEX标签ID识别。一旦创建，同一个InternalElement或ExternalInterface的标识符在相应对象的生命周期内不得改变。为了实现这一点，CAEX建议标识符应该是UUID，尤其是GUID。允许使用大括号、小括号、破折号或空格，但忽略不计。

2.2.3.4 建立对象语义的模型–CAEX的角色概念

除了面向对象的软件编程中已知的类和实例外，CAEX还提供了一个特殊的概念，它是为了在抽象层面上描述系统而发明的，甚至在具体设备被选中之前就已经存在了：角色概念。图2-6通过两个层次说明了角色概念的价值。

左边的层次结构只是内部元素的层次结构，但意义没有被模拟出来。它需要额外的知识来理解其含义，通常是人为解释。左边的结构是机器可读的，但不是机器可解释的。在右边的结构中，它的作用对于每个实例都是明确建模的。一个软件包可以根据功能呈现不同的图标，或者可以提供搜索或分析功能。
角色概念是一个非常自然的概念。我们每天都在使用它，而且它在历史上已经很成熟了，不需要叫它角色概念。一个例子说明了这一点。著名作曲家沃尔夫冈-阿玛迪斯-莫扎特在创作他的歌剧时直观地使用了角色概念，在歌剧中，演员在舞台上扮演不同的角色。创作歌剧的过程与设计工厂的过程非常相似。例如，在第一步，莫扎特设想了一个公主的角色，而没有提到一个具体的人。这个角色在歌剧中具有一定的功能，后来由一个具体的女演员来实现。在下一步，莫扎特为这个角色制定了要求，例如，“应该能够唱高C调”，“应该有一头金色的长发”，“应该能够骑马”。几个世纪后，今天的导演仍然使用这些要求来宣传公主的角色，并选择一个合适的女演员。从技术上讲，女演员 "实现 "了这个角色。

系统工程师也是这样进行的。工程的出发点是通过组合抽象的角色来描述一个制造过程，仍然独立于其具体的技术实现，例如输送机、机器人、转台和一个PLC。在下一步，工程师们定义需求，并逐步细化。这些要求被用来识别和指定在技术上实现所需功能的具体设备。这样的程序符合实用、迭代、工程和人类的思维方式。因此，角色概念遵循了一个成熟的程序，将规范和实施阶段脱钩。

所有的三个阶段都在图2-7中进行了说明。阶段（1）与CAEX的映射是，首先将类型为的无意义对象（例如RB_100）分配到实例层次中。在第（2）阶段，工程师从角色库中分配一个合适的（这里是机器人）。这里的要求（例如：“最大负荷<2t”）可以被记录下来；它们随后构成了选择合适候选人的基础。一旦找到合适的候选人，就可以在第(3)阶段对进行引用。因此，该实例是以具体的技术方式实现的。因此，一个CAEX对象与两个类有关系：抽象角色和具体对象类型。所描述的CAEX模型可参见[BookLink@]。

角色库的一个主要优势是它们可以被标准化，而工业制造商的产品目录（系统单元类库）则不能。它们是多方面的，并且会有永久性的变化和进一步的发展。但是你可以用很少的角色来描述制造业或流程工业的工业流程。这些可以在角色库中被预定义和标准化。对象甚至可以扮演多个角色。如何做到这一点将在2.2.5.9中描述。

总结
CAEX角色概念用于对象的语义识别，对于数据的计算处理、需求的建模和规划步骤的自动化尤为重要。所谓 "自动化的自动化 "是工程研究的一个关键目标，参见[GWF08]、[YAB+06]或[SCEP07]。

2.2.3.5 如何用CAEX对技术系统进行分析和建模 How to analyse and model a technical system with CAEX

为了理解与面向图纸的工程相比，用CAEX进行面向对象的数据建模，建议进行面向对象的分析。表2-2显示了对工程主题进行面向对象分析的典型步骤，并说明了CAEX的映射。

一旦你确定了相关的对象和它们的成分，在源工程工具中确定相关的工程对象，并将它们导出到CAEX。按部就班地进行，不要让未知的东西出现。
在两者之间检查相关信息是否被映射到CAEX，以及CAEX文档是否正确到达接收者手中。如果信息缺失或不正确，纠正源工程工具中的类和实例模型，并重复进行数据交换。
检查产生的CAEX模型是否一致和完整。模型中的错误总是反映了源工具或数据导出中的错误，因为CAEX本身只映射数据，但没有检查功能。工程工具要对工程信息的完整性和正确性负责。

2.2.4 实例层次结构 The instance hierarchy

2.2.4.1 Overview

CAEX实例层次用于存储个人和项目相关的工程信息。它们构成了对象模型的中心，包含所有的数据对象，包括属性、接口、关系和引用。图2-8显示了一个制造单元的实例层次结构的简单例子（在[BookLink@]下载）。CAEX元素是一个具体项目的根节点，包括所有需要的层次结构级别和对象。AML可以灵活地持有不同的层次结构。实例本身可以有属性和接口，用于其各自的参数化。实例层次描述了一个具体工厂的拓扑结构、子工厂或包括内部关系的视图。

图2-9说明了实例层次结构的CAEX模型。

它由一个类型为的CAEX元素表示。它的嵌套子对象是类型的嵌套对象，它们都必须有一个全球唯一标识符（GUID）。

2.2.4.2 对实例层次结构进行建模的三种方法

实例分层是CAEX中存储具体工程数据的根节点。实例层次结构的一般建模规则是:

CAEX不限制层次结构的深度。
CAEX不限制层次结构的架构规则。
CAEX不定义层次结构的命名规则。

有三种不同的方式来模拟实例层次，对不同的应用情况很有用：没有任何类，只有类和混合方式:

**Modelling without classes没有类的建模: **实例可以直接在实例层次中以对象树的形式嵌套InternalElements进行建模。对于每个单一的对象，所有需要的属性、接口和链接等都在实例层次上定义。这个工作流程支持完全没有类的数据建模。例如，如果现有的库不是数据交换的目标，这就很有用。在许多数据交换的工业案例中，不建议传输没有类型的数据。但作为基本工程或初始需求建模的起点，它是明确允许的，也是有用的。
**Modelling with classes only:只用类来建模: **所需的工厂层次结构是由InstanceHierarchy中的一个InternalElement定义的。这个InternalElement引用一个SystemUnitClass，定义了完整的工厂层次结构。如果工厂或单元结构的目标是成为一个准备重复使用的标准解决方案，那么这个工作流程就很有用。通过这种方式，可以对解决方案库进行建模。
Mixed workflow 混合工作流程: 这是实际使用的典型工作流程。典型的组件被定义为SystemUnitClasses，它们的子结构通过聚合对象定义为InternalElements。属性可以被预定义，默认的属性值也可以被设置。InstanceHierarchy被用于植物拓扑结构的定义。在下一步，每个定义的内部分层元素可以与一个角色类相关联，以便对这个对象定义要求。最后，它可以与描述该对象的技术实现的SystemUnitClass相关联。

CAEX中对继承的一个重要限制是，一个类的变化不会自动传播到所有的实例。在CAEX中，一个类的功能是 “复制模板”；当实例化时，考虑到所有的继承关系，它的整个内部结构都被复制到实例层次中。然后，该实例可以被自由修改、参数化、补充或调整。然而，该实例引用了它的类；这种引用允许工具或用户追踪该实例的来源，以确定必要时的变化，并执行自动更新。

2.2.5 如何为CAEX内部元素建模 InternalElement (IE)

2.2.5.1 Example

让我们假设我们想用CAEX建立一个B1储罐模型。它的最小体积应该是12立方米，并且应该由某种混凝土罐型实现（见图2-10）。

2.2.5.2 内部元素的结构 The architecture of an InternalElement

为了给Tank B1建模，首先我们需要了解CAEX内部元素数据模型的结构。这在图2-11中显示，包括以下一般属性。

Attributes：允许指定对象的属性
ExternalInterfaces：允许规范对象的接口
InternalElements：允许规范嵌套的内部元素
SupportedRoleClass：允许指定支持的角色类别
InternalLinks：允许规范接口之间的关系

一个系统单元类库由一个系统单元类的层次结构组成。以同样的方式，实例由内部元素的层次结构组成。

2.2.5.3 步骤1：最小实例的建模 a minimal instance

由于我们现在知道了CAEX InternalElement的结构，让我们对这个例子进行建模。第一步，我们创建一个新的CAEX 并命名为B1（见图2-12）。起初，这个对象没有任何意义，没有进一步的细节或定义；它只是作为实例层次结构中某个地方的占位符。

2.2.5.4 步骤2：如何通过关联角色来模拟对象的意义 How to model the meaning of an object by associating a role

根据CAEX schema，每个InternalElement都有一个可选的CAEX元素，这允许它对角色类的引用进行建模，并对所需的属性或接口进行建模。在这个例子中，我们通过将ProcessRoleClassLib/Tank这个类的路径写进CAEX属性RefBaseRoleClassPath的值中，重新使用与Tank这个角色相关的现有角色类库。这种关联意味着InternalElement B1扮演了Tank的角色。

2.2.5.5 步骤3：如何对属性进行建模 How to model attributes

Value: 该元素允许定义属性值，例如 “3.5”。小数点的分隔符应根据AttributeDataType的定义来选择，例如 "xs:float “需要一个”. "作为小数点的分隔符。
Unit: 这个元素定义了属性的单位，例如 “m”。
AttributeDataType。这个元素定义了属性的数据类型。如果没有定义这个可选的属性，数据类型将被假定为 “xs:string”，而 "xs "代表XML命名空间 “http://www.w3.org/2001/XMLSchema”。如果定义了该属性，其值必须使用标准的XML数据类型，例如 “xs:布尔”、"xs:整数 "和 “xs:浮点数”。与数据类型相对应，属性的值必须符合XML规则，例如，"xs:boolean "期望值为 "true "或 “false”，而 "TRUE "或 "FALSE "则不符合。
RefAttributeType。这个元素存储对AttributeTypeLib中定义的属性类型的路径引用。如果被引用的属性类型是基于XML数据类型的，AttributeDataType应提供被引用属性的基本类型。如果被引用的属性类型不是基于XML标准的基本类型，AttributeDataType可以保持空或不存在。
DefaultValue: 这个元素允许定义属性的初始值。它可以被值的定义所覆盖。
Constraints限制条件: 这个元素允许定义约束。CAEX支持三种约束类型。OrdinalScaledType，NominalScaledType和UnknownType。
- OrdinalScaledType允许定义 “必需值”、"最大值 "和 “最小值”。
- NominalScaledType允许定义一个离散的值范围，例如，属性 "safe "的允许值范围可能有 "yes "和 “no”。
- UnknownType允许指定未知的约束，例如正则表达式。它们是CAEX标准之外的，必须由数据交换伙伴单独同意。
RefSemantic。该元素允许定义对规范性或非正式字典的语义参考，例如SI单位、IEC 61987-1、NE150、IEC CCD或专有网站。
Attribute: 该元素允许定义属性，这些属性可能包含更多的属性。这使得描述分层嵌套的属性结构成为可能。

一个属性的语义通常在外部公共或专有标准中定义。属性的正确性不在CAEX的范围内。最小的属性定义只是定义了一个名称。因此，AutomationML可以简单地模拟一个属性列表。所有进一步的元素都是可选的。图2-14展示了属性的不同方面。

2.2.5.6 步骤4：如何为需求建模 How to model a requirement

除了内部元素的具体属性（它们实际拥有的属性或接口），角色概念允许对需求requirements（内部元素实际应该拥有的属性或接口）进行建模。
需求requirements与CAEX元素相关。在这个例子中，tank的最小容积应该是12立方米。图2-15显示了数据模型。一个属性与CAEX元素相关联，约束条件将这个属性定义为最小值12m3。

2.2.5.7 步骤5：如何引用一个系统单元类 How to reference a system unit class

在工程中，设备通常是在指定了相关要求后手动选择的。图2-16展示了如何对此进行建模。将CAEX属性RefBaseSystemUnitPath的值设置为所选系统单元类的路径，所有需要的属性都被转移；在这个例子中，体积为15立方米。这个值是供应商的保证

2.2.5.8 步骤6：如何将需求映射到保证：MappingObject

图2-17显示了整个例子：内部元素B1被要求是一个最小体积为12立方米的坦克。基于这一要求，工程师选择了混凝土的VendorA_Tank37。混凝土储罐保证容积为15立方米，符合要求。
问题是：这可以自动处理吗？由于需求和供应商保证的属性命名不一定相同，所以应该对映射进行建模。为此，CAEX引入了。当需求和供应商保证应该被自动处理时，映射对象是有用的，例如，自动设备选择。图2-17通过Tank B1说明了这一点。

映射对象的建模准则是:

如果相关属性的名称（或嵌套属性的路径）是相同的，则不需要映射对象。
如果名称不同，则向InternalElement添加一个CAEX映射对象。
对于每个名字的映射，在MappingObject中添加一个CAEX元素AttributeNameMapping。在CAEX元素RoleAttributeName中定义角色属性的名称。在元素SystemUnitAttributeName中定义InternalElement（或SystemUnitClass）的相关属性名称。
对于每个接口映射，在MappingObject中添加一个CAEX元素InterfaceIDMapping。在CAEX元素RoleInterfaceID中定义角色接口的ID。在元素SystemUnitInterfaceID中定义InternalElement（或SystemUnitClass）的相关接口的ID。

2.2.5.9 如何将多个角色关联到一个实例上 How to associate multiple roles to an instance

CAEX支持引用多种角色，以支持可以扮演多种角色的工业设备。
一个例子是一个多功能设备，它同时是一个扫描仪、打印机或传真设备。在下面的模型中，我们假设在一个库中提供了传真机、打印机和扫描器等角色。
图2-18为MultiDevice01对象建模，该对象具有三个属性：FaxBaudRate、PrintSpeed和FaxSpeed，以及两个接口PowerSupply和USB。因为这个对象可以同时扮演三个角色，所以InternalElement MultiDevice01建立了三个独立的CAEX角色需求模型，分别引用打印机、传真机和扫描仪的角色。三个不同角色的要求被分别建模，并通过打印机、传真机和扫描仪的个别角色属性速度和目前的角色接口来说明。
对于每个CAEX RoleRequirement，一个可选的CAEX 允许定义相应角色的哪个属性或接口与相关InternalElement的哪个属性或接口相关联。MappingObject中给出的角色属性名称是相对于被引用的角色类而言的，因此每个RoleRequirement形成了自己的上下文。这个例子的相应XML代码可以在[BookLink@]下载。

2.2.6 CAEX库和类的类型 library and class types

2.2.6.1 Overview

面向对象的一个主要概念是实例instances和类classes之间的区别。

实例是具体的单个对象concrete individual objects，
而类是抽象的类型abstract types ，可以理解为预定义的模板predefined templates。

术语类class和类型type是同义的。
如果不重复使用经过验证的模板，加工和制造行业中复杂工厂的工程在经济上就不再可行了。带有预定义类的库对工程效率的提高起着重要作用，这是面向对象的一个成功案例。

因此，CAEX的主要优势是一个全面的库概念。
库将自己理解为一个类目录，持有可重用的类。在类库内关系的帮助下，这些类可以被进一步完善，例如通过继承inheritance或聚合aggregation。

CAEX的库概念区分了几种类型的库：

、
、
和
以及它们各自的类（见图2-19）。

CAEX可以对任何数量的这些库进行建模，据此，各个类可以被映射为其库中的层次结构，例如，对用户定义的树状结构进行建模。然而，类之间的父子关系是没有语义的。这意味着同一类型的类可以相互继承，从而形成类的层次结构，甚至跨库或CAEX文档。

库的命名的一般建模规则是:

库和实例层次是由它们的名字来识别的。
具有相同名称的库被禁止存储在同一个CAEX文件中。这确保了CAEX文件中库名的唯一性。

2.2.6.2 SystemUnitClassLib

类型的类描述了物理或逻辑工厂对象的类型或它们的组合（所谓的单元），例如混凝土机器人、阀门或水箱的类型。它们也可以模拟其技术实现，包括其内部结构、属性、接口、嵌套的内部元素和内部元素之间的连接。因此，一个内部元素可以包含更多的元素，这允许通过层次结构描述任何复杂的对象结构。
或其实例的role or function 由与抽象的的关联来定义。
系统单元类SystemUnitClasses被组合在的类型中。例如，在它们的帮助下，产品或解决方案目录可以被建模、发布、分发或以电子方式销售。

2.2.6.3 InterfaceClassLib

类型的类描述了一个接口类型，例如，一个法兰、一个信号、一个电接口、一个喷嘴或一个普通产品节点。
接口是用来映射对象之间的关系。它们被分组在类型的库中。

2.2.6.4 RoleClassLib

类型的类也描述物理或逻辑工厂对象，但在抽象的层面上，独立于具体的技术实现。
角色是系统单元的语义对应物semantic counterpart。

系统单元类通常用于映射供应商特定的设备类型，而角色则是对各种技术实现的抽象，只映射一组组件的基本功能。

角色可以作为工厂工程中的占位符placeholders ，支持与实施无关的基本规划。
角色的例子有资源、机器人或PLC。角色的概念在第2.2.3.4节中有详细解释角色类被分组在类型的库中。

2.2.6.5 AttributeTypeLib

类型的类描述了一个属性类型，可以用来为属性（例如 “长度”）建模，包括其值、单位和描述。属性类型被分组在类型的库中。它们允许对专有或标准字典进行建模，并且是属性的语义解释的基础。

2.2.7 如何为CAEX系统单元类建模 How to model CAEX system unit classes

2.2.7.1 Example

让我们假设我们想为一个机器人家族的产品目录建模。该库应该为一个抽象类RobotClass建模，该类为所有机器人的通用属性建模，应该明确支持机器人的角色。第二个机器人应该是从通用的机器人类派生出来的，并且应该提供特殊化。然后，我们想为一个由两个具体机器人组成的合作机器人系统建模。图2-20显示了预定的库，我们将在接下来的小节中逐步建立模型。

2.2.7.2 Step 1: 对一个最小的系统单元类进行建模 Modelling a minimal system unit class

图2-21展示了一个由库和一个类组成的最小系统单元类库。类或库的名称在兄弟姐妹之间必须是唯一的。ID是可选的，而类的实际标识符是名称（正确来说是全路径）。

2.2.7.3 Step 2: 如何对属性进行建模 How to model attributes

图2-22说明了类属性的建模。在对最小的类进行建模后，我们按照2.2.10.9中描述的属性架构添加一个版本号和一些属性。

2.2.7.4 Step 3: 如何对派生进行建模 How to model derivations

为了派生出一个系统单元类，我们只需在库中的一个任意位置对另一个类进行建模。分层的位置没有语义。派生是通过CAEX标签RefBaseClassPath来模拟的，它包含通往父类的路径。新类确实继承了父类的所有属性，为了避免冗余，这些属性不再被建模。新类可以被扩展、修改和重写。图2-23通过从RobotClass派生的SpecialRobotClass说明了这一点。这里，属性Weight被添加到继承的数据中。

2.2.7.5 Step 4: 如何对聚合进行建模 How to model aggregations

我们的机器人系统由两个预定义机器人类别的实例组成。图2-24说明了该模型的建立。新的CooperativeRobotsClass由两个内部元素Robot01和Robot02组成。

2.2.7.6 Step 5: 如何为系统单元类的层次结构建模 How to model a system unit class hierarchy

图2-25展示了一个系统单元类库的结果层次结构。

请记住，类的层次结构本身没有任何意义；它只是为了结构化。

继承性Inheritance必须被明确地建模。

在层次结构的第一层建立所有类的模型是绝对可以接受的。

对于产品树的建模，建议在一个共同的父类上建模共同的属性，然后再细化这些类来描述产品的变体。重要的是。不要混淆子内部元素和子类。子内部元素被烘烤到类中。与属性类似，子内部元素是类的一个重要部分，如果类被继承，就会出现。它们对类的内部技术实现进行建模。然而，子类不会出现，也不是上层类的一部分，因为类的层次结构没有进一步的意义。

2.2.7.7 如何对支持的角色类进行建模 How to model supported role classes

由于SystemUnitClass大多属于公司所有，而角色类通常是标准化的对象，因此对它们之间的映射进行建模是很有帮助的。
为了支持这一点，CAEX 定义了一个子元素，它允许每个类定义它支持哪些角色类。这使得计算机能够为某个角色类选择合适的SystemUnitClasses。

2.2.7.8 系统单元类的一般架构和建模规则 General architecture and modelling rules of a system unit class

图2-27显示了一个系统单元类的结构。一般的建模规则是:

一个SystemUnitClass可以支持任意数量的RoleClasses。
被支持的RoleClass的子类或父类不被自动支持，因为它们可能与SystemUnitClass不兼容。如果一个SystemUnitClass也支持一个RoleClass的子类，它们必须被添加到SupportedRoleClass定义中。
对于每个支持的RoleClass，可以定义一个映射对象，允许定义相应的属性名称和接口之间的映射。
系统单元类的分层模型没有语义，它对组织目的很有用。
继承是通过引用父类来明确建模的。

2.2.8 如何为CAEX接口类建模 How to model CAEX interface classes

2.2.8.1 Example

假设我们想为一个接口类库建模；我们需要一个喷嘴、一个专门的喷嘴、一个数字输入和一个数字输出。图2-28说明了预期的结果。

2.2.8.2 Step 1: 对一个最小的接口类进行建模 Modelling a minimal interface class

图2-29说明了一个最小的接口类库，由库MyInterfaceClassLib和一个角色类Nozzle组成。两者都是由它们的名字来识别的。类的名称在兄弟姐妹之间必须是唯一的。每个接口类必须由AutomationML基接口类或其派生类中的一个派生。在这种情况下，我们从标准接口类AutomationMLBaseInterface派生出Nozzle。

2.2.8.3 Step 2: 如何对接口属性进行建模 How to model interface attributes

图2-30说明了接口类属性的建模。在这个例子中，我们添加了三个属性。

2.2.8.4 Step 3: 如何对派生进行建模 How to model derivations

为了派生一个接口类，我们只需在接口类库中的任意位置为另一个接口类建模。真正的分层位置没有语义。派生是通过CAEX标签RefBaseClassPath来模拟的，它的值代表了通往父类的路径。新类确实继承了父类的所有属性，为了避免冗余，这些属性没有被再次建模。新类可以被扩展，属性可以被重写。图2-31通过派生自Nozzle类的SpecialNozzle说明了这一点。

2.2.8.5 Step 5: 如何对嵌套接口进行建模 How to model nested interfaces

接口可能包含嵌套接口。一个例子是一个有内部引脚的USB端口。图2-32说明了这一点，在Nozzle上添加一个嵌套的数字输出信号，提供有关喷嘴的信息。
重要的是。不要混淆子接口child interfaces和嵌套接口nested interfaces。嵌套接口必须被视为类的一部分，如果接口类被实例化就会出现。一旦接口类被实例化，子接口就不会出现。

2.2.8.6 Step 4: 如何对接口类的层次结构进行建模 How to model an interface class hierarchy

图2-33说明了一个层次化的接口类库，包含了一个喷嘴、一个特殊喷嘴、一个数字输入和一个数字输出的类。对于类层次结构的建模，请记住类层次结构没有任何意义，它们只是用于结构化。继承必须被明确地建模。将所有的接口类建模在库层次结构的第一层是绝对可以接受的。

2.2.8.7 接口类的一般架构和建模规则 General architecture and modelling rules of an interface class

图2-34显示了一个接口类的一般结构。一般的建模规则是:

接口不具有方向属性。如果需要，必须作为接口的CAEX属性添加。
接口类的分层模型没有语义，但可以用来描述用户的库结构。
继承是通过引用父类来明确建模的。

2.2.9 如何为CAEX角色类建模 How to model CAEX role classes

2.2.9.1 Example

让我们假设我们想使用制造单元建模所需的典型角色来为我们自己的目的建立一个角色类库。我们需要一个机器人、一个传送带、一个传感器和一个转台的角色。图2-35说明了预期的结果。

2.2.9.2 Step 1: 建立一个最小的角色类模型 Modelling a minimal role class

图2-36展示了一个最小的角色类库，包括库MyRoleClassLib和一个角色类Robot。两者都是由它们的名字来识别的。类的名称在兄弟姐妹之间必须是唯一的。在这种情况下，我们从2.4.2.4节中描述的预定义的AML标准角色类资源中派生出机器人。

2.2.9.3 Step 2: 如何对角色属性和接口进行建模 How to model role attributes and interfaces

图2-37说明了角色类属性和接口的建模。在这个例子中，我们添加了三个属性和一个数字输入信号。

2.2.9.4 Step 3: 如何对派生进行建模 How to model derivations

为了派生一个角色类，我们只需在库中的任意位置建立另一个角色类模型。分层的位置hierarchical position没有语义。

派生是通过CAEX标签RefBaseClassPath来模拟的，其值代表了通往父类的路径。

新的类继承了父类的所有属性，为了避免冗余，这些属性不会被再次建模。新类可以被扩展，属性也可以被重写。图2-38通过从机器人派生的FastRobot说明了这一点。

2.2.9.5 Step 4: 如何对角色类的层次结构进行建模 How to model a role class hierarchy

图2-39展示了所产生的分层角色类库，包含了机器人、激光传感器、转台和传送带的类及其专门的子类。请记住，类的层次结构没有任何意义，它只是用于结构化。继承性必须被明确地建模。在层次结构的第一层建立所有角色类的模型是绝对可以接受的。
角色类对对象的意义进行建模。

角色可以是实体词（例如机器人），以便对对象角色（世界上的事物）进行建模，
也可以是动词，以便对技能能力或功能进行建模（例如运输）。

这使得事物库和技能库的开发和标准化成为可能。一旦一个角色类被分配给InternalElement，该对象的含义就变得可被机器读取。然而，在将一个角色类关联到一个InternalElement之后，所属的角色属性和接口对内部元素本身没有影响，它们只是对需求进行建模。换句话说，需求的属性和接口是与InternalElement的属性和接口分开建模的，它们甚至可能是冲突的。
选择不符合要求的设备是一个有效的冲突。AutomationML允许对这种冲突进行建模，因为它严格区分了需求和供应商的保证。

例子
如果在歌剧中授予一个金发公主的角色，被选中的黑发女演员并不会因为这个选择而自动变成金发。

需求和实际属性的矛盾是以后要澄清的问题，因为它可能是故意的，也可能是一个错误。找到这样的矛盾是一个自动一致性检查的主题，由分离的数据建模实现。

2.2.9.6 角色类的一般架构和建模规则 General architecture and modelling rules of a role class

图2-40显示了一个角色类的一般架构。建模规则是:

角色类不包含嵌套的角色。
角色类的层次模型没有语义；它只对组织目的有用。
继承是通过引用父类来明确建模的。

2.2.10 如何为CAEX属性类型建模 How to model CAEX attribute types

2.2.10.1 Example

让我们假设我们想为一个一般工业用途的属性类型库建模。图2-41说明了预期的结果。

2.2.10.2 Step 1: 最小属性类型的建模 Modelling of a minimal attribute type

首先，我们需要对属性类型库进行建模。建议用属性类型库来模拟特定用户、特定公司、特定地区、特定国家等或与当前或未来属性标准相关的属性语义方面的规范性国际标准。这是对商定的属性语义进行存储的基础，并且能够独立于语言和命名惯例。
图2-42说明了一个由GenericIndustrialAttributeTypeLib库和一个属性类型Level组成的最小属性类型库。两者都是由它们的名字来识别的。属性类型的名称在同级之间必须是唯一的。

2.2.10.3 Step 2: 属性类型的属性 Properties of an attribute type

一个属性的最小定义只是它的名字。如果应该交换属性名称的列表，这已经很有用了。但在大多数情况下，进一步的属性是有意义的，但所有这些都是可选的：它们可以被使用，但不是必须的:

Value: 该元素允许定义属性值，例如 “3.5”。小数点的分隔符应根据AttributeDataType的定义来选择，例如 "xs:float “需要一个”. "作为小数点的分隔符。
Unit: 这个元素定义了属性的单位，例如 “m”。
AttributeDataType。这个元素定义了属性的数据类型。如果没有定义这个可选的属性，数据类型将被假定为 “xs:string”，而 "xs "代表XML命名空间 “http://www.w3.org/2001/XMLSchema”。如果定义了该属性，其值必须使用标准的XML数据类型，例如 “xs:布尔”、"xs:整数 "和 “xs:浮点数”。与数据类型相对应，属性的值必须符合XML规则，例如，"xs:boolean "期望值为 "true "或 “false”，而 "TRUE "或 "FALSE "则不符合。
RefAttributeType。这个元素存储对AttributeTypeLib中定义的属性类型的路径引用。如果被引用的属性类型是基于XML数据类型的，AttributeDataType应提供被引用属性的基本类型。如果被引用的属性类型不是基于XML标准的基本类型，AttributeDataType可以保持空或不存在。
DefaultValue: 这个元素允许定义属性的初始值。它可以被值的定义所覆盖。
Constraints限制条件: 这个元素允许定义约束。见第2.2.10.5节。CAEX支持三种约束类型。OrdinalScaledType，NominalScaledType和UnknownType。
- OrdinalScaledType允许定义 “必需值”、"最大值 "和 “最小值”。
- NominalScaledType允许定义一个离散的值范围，例如，属性 "safe "的允许值范围可能有 "yes "和 “no”。
- UnknownType允许指定未知的约束，例如正则表达式。它们是CAEX标准之外的，必须由数据交换伙伴单独同意。
RefSemantic。该元素允许定义对规范性或非正式字典的语义参考，例如SI单位、IEC 61987-1、NE150、IEC CCD或专有网站。该元素允许定义语义引用，见2.2.10.4节。
Attribute: 该元素允许定义属性，这些属性可能包含更多的属性。这使得描述分层嵌套的属性结构成为可能。见第 2.2.10.7.

2.2.10.4 Step 3: 如何对属性的语义进行建模 RefSemantic - How to model the semantics of attributes

机器可读性需要语义；要么是事先已经知道并同意的，要么是被引用的。CAEX支持语义引用；每个属性都有一个元素，可以容纳对规范性或非正式字典的语义引用，例如SI单位、IEC 61987-1、网站等。这种链接的语法不是CAEX标准的一部分，而是必须由语义库所有者提供。图2-43通过属性类型IPCode说明了这一点，IPCode是对IEC通用数据字典（CDD）的引用模型。

链接的语法是根据CDD的规格来确定的。如果在另一个语义库中也定义了相同的属性，那么也可以将其添加进去，因为语义链接的列表允许对多个引用进行建模。这个概念允许CAEX参考当前或未来的语义库，并且可以灵活地适应公司标准或即将到来的新语义库。

优点
这种技术的一个主要好处是，属性的名称变得无关紧要。你可以随心所欲地命名这些类型；关键是引用，而不是名称。

2.2.10.5 Step 4: 如何对属性约束进行建模 How to model attribute constraints

属性通常是受约束的；一个level应该在最大和最小值之内，或者一个颜色应该是蓝色或黄色。CAEX属性支持三种约束类型。OrdinalScaledType、NominalScaledType和UnknowType。
OrdinalScaledType允许定义 “要求值”、"最大值 "和 “最小值”。NominalScaledType允许定义一个离散的值范围，例如，属性 "safe "的允许值范围可能有 "yes "和 “no”。
UnknownType允许定义任何约束；其语法没有定义。

图2-44说明了我们的属性Level的建模情况。在这种情况下，水平应该在2…200mm的范围内，预期水平大约是50mm。

2.2.10.6 Step 5: 如何对派生进行建模 How to model derivations

为了推导出一个属性类型，我们只需在库中的任意位置为另一个属性类型建模。真正的层次位置没有语义。派生是通过CAEX标签RefAttributeType来模拟的，它的值代表了通往父类的路径。新的类继承了父属性类型的所有属性，为了避免冗余，这些属性没有被再次建模。新的类型可以被扩展，属性也可以被重写。图2-45通过从Colour派生的RGB说明了这一点。

2.2.10.7 Step 6: 如何对嵌套属性进行建模 How to model nested attributes

在许多情况下，属性需要一个层次结构。这是由嵌套属性来模拟的。一个例子是一个需要对x、y和z位置进行建模的点属性。图2-32通过向RGB属性类型添加嵌套属性Red、Green和Blue来说明这一点。
重要的是。不要混淆子属性类型和嵌套属性。嵌套属性是属性类型的结构部分，如果属性类型被实例化就会出现。当父属性类型被实例化时，子属性将不会出现。

这种技术是2.6.7中描述的多语言属性的基础。
由于嵌套的属性可以再次嵌套，因此可以对任意的分层属性结构进行建模，这允许对多维数组进行定义。
列表和数组的建模将在2.6.8中描述。

2.2.10.8 Step 7: 如何为属性类层次结构建模 How to model an attribute class hierarchy

图2-47说明了一个包含一般工业用途的属性类型的分层属性类型库。对于属性类型层次结构的建模，请记住层次结构本身没有任何意义，只用于结构化。继承性必须被明确地建模。在层次结构的第一层建立所有属性类型的模型是绝对可以接受的。

2.2.10.9 一个属性类型的一般结构 General architecture of an attribute type

2.2.11 如何对路径进行建模 How to model paths

路径Paths 是引用类或属性类型的基础，需要定义不同路径元素之间的分隔符separators 。CAEX区分了两种分隔符类型：别名分离器和对象分离器:

Alias separator别名分隔符（用于别名之后）。“@”
Object separator对象分隔符（用于对象层次之间）。“/”

表2-3描述了几个应用案例的建模规则和例子。

路径paths的建模规则是:

如果定义的分隔符可能是对象名称的有效部分，应使用以下语法：
- 所有路径元素必须用方括号"[" "]"分隔。这允许同时使用原始名称和定义的分隔符。
如果出现冲突的情况，所述的方括号是对象名称的一部分，对象名称中的方括号应通过通用的XML转义序列来转义。
在没有任何冲突的情况下，也允许使用括号。
如果被引用的类或属性位于引用项的下一个较高的层次结构中，则允许使用短路径。它包括类或属性类型的名称或只包括属性。

CAEX不检查路径的有效性，也不检查规范的分隔符的使用，也不检查引用的项目是否存在。符合本标准需要正确使用路径和定义的分隔符。

2.2.12 关系的建模 Modelling of relations

2.2.12.1 Overview

对技术系统进行建模，需要有机制来设置数据对象之间的关系。一个关系表达了对象之间的物理或逻辑关联。这种依赖关系可能是物理性的，也可能是逻辑性的。

父-子关系（见2.2.12.2节）

parent-child relations between CAEX objects
parent-child relations between CAEX classes

继承关系（见第2.2.12.3节）

inheritance relations between SystemUnitClasses
inheritance relations between RoleClasses
inheritance relations between InterfaceClasses
inheritance relations between AttributeTypes

类与实例的关系（见2.2.12.4节）

relations between a SystemUnitClass and an instance of it
relations between a RoleClass and the assigned InternalElement
relations between an InterfaceClass and an instance of it
relations between an AttributeType and Attribute

实例-实例的关系（见2.2.12.5和2.2.12.6节）

relations between CAEX ExternalInterface
relations between CAEX InternalElements

图2-49通过一个层次结构的例子说明了这些类型的关系。更详细的描述将在下面的章节中给出。相关的XML模型显示在图2-50中。

2.2.12.2 父-子关系 Parent-child relation

对象实例之间或类之间的父子关系被用来表示层次化的对象结构。因此，一个机器人对象可以包含子对象的手臂和抓手。子对象被建模在其父对象之下，其本身可以包含子对象。通过这种方式，有可能对任何深度的对象层次结构进行建模。删除一个对象也适用于子对象。图2-8（见2.2.3.5节）显示了实例层次结构中的父子关系。
父-子关系在实例层次结构和所有的类库中都有使用。图2-51说明了类库中的这种关系。 ParentChildRelationExampleClassLib包含一个ParentClass类，它又包含一个ChildClass类。

与直观的预期相反，类之间的父子关系并不代表继承关系，而只是用来表示用户定义的库结构。

继承关系是使用CAEX标签RefBaseClassPath来映射的，并且不限于下一个更高的层次结构级别。总之，对象实例之间的父子关系代表一种 "原样as-is "关系。

类之间的父-子关系没有任何意义，只是用来映射用户定义的层次结构。

2.2.12.3 继承关系 Inheritance relations

CAEX支持两个类之间的继承关系。继承关系是由一个引用来定义的。每个CAEX类都拥有一个属性RefBaseClassPath，它指定了相应父类的路径。继承的概念对于InterfaceClasses、RoleClasses、SystemUnitClasses和AttributeTypes是相同的。
图2-52用一个例子说明了这一点，其中SpecialRobot1234类继承于Robot1234类。正如第2.2.4.2节所解释的，CAEX支持同一类型的两个类之间的继承。
继承关系的进一步建模规则是

类之间允许继承。一个类可以有任意数量的子类，但只有一个父类。一个类中的所有变化都会被所有子类自动反映出来。
继承意味着所有可用的父类和祖类的属性、接口、内部元素、映射对象或进一步的内容都会自动出现在子对象中。
继承的类可以在类的层面上用新的属性、接口等进行扩展。
存储Storage继承数据。继承的数据对子数据是有效的，可以选择在
复制到XML文档中的子对象上。为了覆盖或扩展继承的信息，重新定义和存储已经继承的数据是可能的和有用的。如果数据被从父类物理复制到子类，并且后来在父类上有所改变，那么复制的子类数据应被更新。
覆盖Overriding继承的数据。通过在子对象中用更新的值重新定义相应的数据，可以覆盖继承的属性。只要在父类中定义了给定的属性约束，被覆盖的数据应满足这些要求。
删除Deleting继承的数据。通过在子对象中再次重新定义相应的数据，并将ChangeMode属性设置为 “删除”，就可以删除继承的属性。
继承是以线性方式支持的。一个子类可以继承自一个父类，同时也可以是其他类的父类。CAEX允许以这种方式定义父类、子类和孙类的任意深度。这样，孙子就继承了父母和祖父母等。CAEX只支持从一个父辈继承。
如果需要继承，父类在CAEX标签RefBaseClassPath中指定类的完整路径。确保被引用的类是有效的并且存在。
如果所需的父类被置于子类之上的一个层次，可以通过在CAEX标签RefBaseClassPath中存储父类的名称来指定父类，而不提供完整的路径。
不允许交叉继承；例如，一个SystemUnitClass只能继承自另一个SystemUnitClass。
继承是可选的。如果不需要继承，让引用属性RefBaseClassPath为空或根本不存在。
当然，一个类不能从它自己或它的衍生物中继承。
CAEX不提供有效继承关系或引用项有效存在的一致性检查。

2.2.12.4 类-实例关系 Class-instance relation

实例Instances的特点是有一个唯一的标识符unique identifier和一个参数集parameter set。
关于类-实例关系，适用以下规定。CAEX明确定义了类-实例关系不是继承关系，这一点在第2.1.4节中讨论过。

创建实例的一个例子是将复制到一个新的中，然后将该类的完整路径分配给实例的CAEX标记RefBaseSystemUnitPath。

图 2-53 通过对象 ObjectA 展示了这一点，它引用了库 mySystemUnitClassLib 中的源类 generic_Valve。在复制过程中，实例本身可以自由改变。

如果一个实例的源类发生了变化，这并不意味着该实例也会发生变化。

根据改变后的源类自动反映或更新实例数据是一种工具功能(要自己开发)，不属于IEC 62424的范围。目前通往源类的路径支持这一功能。
这种基于模板的面向对象的方式与经典的面向对象的软件编程不同，但在工程中是需要的。CAEX建议，一个已发布的类的变化应该被建模为该类的新版本，它使用CAEX标签OldVersion来引用旧版本。这使得在数据交换期间跟踪类库的变化成为可能。

CAEX标签RefBaseSystemUnitPath不一定要引用一个类，**也可以引用一个实例。**这符合CAEX的要求，也是IEC 62424标准中 "镜像概念 "的基础。被引用的实例被称为主对象，而引用的对象只作为原始对象的镜像，因此被称为 “镜像对象”。两个对象都被认为是相同的，但只能对原始对象进行修改，这些修改在镜像对象中被 "镜像 "出来。这允许一个相同的对象被放在几个层次中。因此，可以映射出具有互锁结构的复杂对象网络。

关于类-实例关系的进一步建模规则是:

CAEX InternalElement或CAEX ExternalInterface可以是一个没有与任何类关系的**单子singleton **。
如果一个CAEX InternalElement与一个SystemUnitClass有类-实例关系，它将被创建为这个SystemUnitClass的副本，包括该类的内部结构和当前所有继承的信息。为了进一步使用，复制的源类在实例的CAEX标签RefBaseSystemUnitPath中被引用。这个标签包括源类的完整路径和名称。只有一个SystemUnitClass可以被引用。一个类以这种方式充当模板。
如果一个CAEX外部接口与一个InterfaceClass有类-实例关系，那么它就被创建为这个类的副本，包括该类的内部结构和目前所有的继承信息。为了进一步使用，复制的源类在ExternalInterface的CAEX标签 "RefBaseClassPath "中被指明。这个标签包括源类的完整路径和名称。只有一个InterfaceClass可以被引用。
CAEX InternalElement和RoleClass之间的关系由属于CAEX RoleRequirement的CAEX标签RefBaseRoleClassPath表示。所有的角色类规范必须被复制到相应的CAEX对象中。如果一个角色类的属性没有值，如果不需要，它可以从实例数据中删除。
CAEX Attribute和CAEX AttributeType之间的关系由CAEX标签RefAttributeType表示。所有的类型规格必须被复制到相应的CAEX Attribute。如果属性类型规范的某个属性没有值，如果需要，可以从CAEX属性中删除。
在将类数据复制到实例的过程中，实例中所有有ID的对象都应得到一个新的唯一ID。类不会被改变。在整个CAEX文件中，所有使用旧ID的引用都应相应更新。
与源类相比，允许扩展或减少实例的数据。

2.2.12.5 CAEX接口之间的实例-实例关系 Instance-instance relations between CAEX Interfaces

对象实例之间的关系是通过用的连接对象接口来建模的。所有符合AML标准的接口必须直接或间接地派生自AML标准接口类。
图2-54使用一个例子结构来说明这一点，其中来自R1机器人的启动信号被连接到IO-Board Board01的信号输入通道Channel01，图2-55是XML结构。

建议将对象之间的链接存储在顶部的公共父对象上。
另外，将所有链接存储在整个实例层次结构的最顶层对象中也是有意义的。

2.2.12.6 实例-实例关系-镜像概念 Instance-Instance relations – the mirror concept

CAEX支持同时对多个层次结构进行建模。由于不同的层次结构可能以不同的方式描述相同的数据，因此可能出现一个实例需要成为多个层次结构的一部分的情况。CAEX通过一个 "镜像概念 "来支持这种情况。
图2-56通过两个例子结构LocationHierarchy和Resource Hierarchy以及相应的库系统单元类DemoLib来解释这个概念。内部元素Tank1是C_Tank类的一个实例。这个对象有第二个代表Tank1*，它被定位在第二个层次结构中。主对象Tank1引用其C_Tank类，而Tank1引用CAEX内部元素Tank1。因此，对象Tank1充当 “主对象”，而Tank1充当 “镜像对象”。在结果中，一个CAEX对象出现在两个位置。

镜像概念可以以同样的方式应用于CAEX接口和属性。图2-57通过对象Tank或Pump的属性Price说明了这一点。同样的价格在另一个层次结构的对象 "价格 "中被建模，该对象引用了相应的主属性。此外，这个图说明了镜像对象如何在另一个结构中进行重组。但是，根据定义，所有镜像对象总是在对象树中形成叶子。

镜像概念的建模规则是：

如果需要一个以上的CAEX InternalElement、CAEX ExternalInterface或CAEX Attribute的表示，它们中的每一个都必须在所需的位置被建模为相应的CAEX InternalElement、CAEX ExternalInterface或CAEX Attribute。
它们中的一个应作为 “主对象”。这个主对象持有所有需要的信息，如头信息、属性、接口和内部元素，并可能与CAEX类或类型有实例类关系。
其他对象作为 “镜像对象”，引用 “主对象”。一个 "镜像对象 "作为一个指向 "主对象 “的指针。为此，CAEX InternalElements应在CAEX标记RefBaseSystemUnitPath中存储主对象的ID，CAEX ExternalInter- faces应在CAEX标记RefBaseClassPath中存储主对象的ID，而CAEX Attributes应在CAEX标记RefAttributeType中存储主属性父实例的ID，后面是分隔符字符串”/"和属性的路径。
镜像对象不得引用任何类或类型。
一个主对象不能有对其镜像对象之一的反向引用。
如果需要，反向引用必须由一个软件工具来处理。
镜像对象不能有孩子，也不能存储与对象有关的信息，除了对主对象的引用或ChangeMode。镜像对象的变化和修改必须完全在主对象上进行建模。
镜像对象可以有一个与主对象不同的名字，并且可以有自己的头信息。
镜像CAEX InternalElement或ExternalInterface必须有一个自己的唯一ID。镜像对象被认为是与主对象相同的。独立的ID支持将镜像代表与主对象区分开来。
如果一个主对象被删除，所有相应的镜像对象也应被删除，以避免不一致。但这是CAEX或AutomationML范围外的工具功能。
可以用主控对象替换其中的一个镜像对象，并删除旧的主控对象。
如果一个镜像对象被删除，主对象不应受到影响。
CAEX内部链路只能与主对象相互连接。
一个主控对象及其相关的镜像对象应被定位在一个或几个CAEX实例层次中，一个SystemUnitClass中，或一个InterfaceClass中。
主控对象和相关的镜像对象不应跨越类的边界。
角色类不包含镜像对象。

2.2.13 覆盖继承的信息 Overriding inherited information

2.2.13.1 总体概念

继承使得数据的使用更加经济，因为已经继承的信息在物理上并不存储在子对象中。这是面向对象的数据建模背后的一个关键思想：共同的数据被存储在最顶层的类中，而个人的特征被建模在子类中。在一个类的实例化过程中，继承的数据是沿着继承链从父类那里收集（溶解）的。这就是为什么类会自动反映父类中的变化。
CAEX明确支持对已经继承的信息进行重写，并允许扩展、移除或修改继承的数据。覆盖是通过 "覆盖 "来解决的，并通过将继承的CAEX信息实际复制到子类中来完成。对于测试和开发的目的，这可以手动完成，但这可能是一个复杂的任务，应该由软件来计算。在这之后，复制的数据可以被自由修改。

2.2.13.2 重写类的属性 Overriding attributes of a class

重写一个类的属性是通过将该属性从继承的元素中物理复制到该类中来实现的。在这里，它可以被自由修改。继承和重写属性之间的特征是它的名字，当它被重写时，它的名字不能被改变。如果属性约束是在父类中定义的，被覆盖的数据应满足这些要求，因为约束也是继承的。然而，这些约束也可以被重写。这个覆盖属性的一般概念适用于所有CAEX类的类型。

图2-58通过一个SystemUnitClass来说明这一点，这里的属性Width是在RobotClass中定义的，而这个属性的值在子类SpecialRobotClass中被覆盖。重写一个继承的InternalElement的属性是对相关InternalElement的修改。这将在2.2.13.3节中描述。

2.2.13.3 重写InternalElements或ExternalInterfaces

为了覆盖一个继承的InternalElement或ExternalInterface，它必须从继承的元素中物理复制。如果InternalElement是一个层次结构的子元素，从相关的InternalElement开始向上的整体父分支必须被复制到SystemUnitClass中。然后，为了避免冗余，所有未改变的信息可以从副本中移除。随后，复制的信息可以被自由修改。继承项和重载项之间的特征还是它的名字，当它被重载时，它的名字不能被改变。

2.2.13.4 扩展继承的数据 Extending inherited data

为了扩展继承的数据，可以自由添加新的属性、接口、元素或链接。如果所需的父节点不存在，它必须被物理地复制到类中，如果需要的话，包括节点的父分支。

2.2.13.5 排除继承的数据 Excluding inherited data

为了排除继承的数据，它必须被实际复制到类中，并且ChangeMode必须被设置为 “删除”。

2.2.13.6 撤销覆盖 Undo overriding

为了撤销重写，必须将类中物理复制的部分物理删除。然后，原来的继承就生效了，覆盖也就撤销了。

2.2.14 建立版本信息的模型 Modelling version information

2.2.14.1 Overview

版本信息对于可追踪的和透明的数据交换是有帮助的，对于追踪信息流和在不同版本的信息洪流中导航也是很有力的。由于库、类或实例很快就会被修改，版本信息对于区分新旧数据和处理修改至关重要。CAEX支持多方面的版本信息，对各种与版本有关的方面都很有用（见表2-4）。这些都被深度整合到CAEX中。这些方面将在下面的章节中详细讨论。

2.2.14.2 Version information for libraries, classes, instances, attributes

CAEX数据模型中的一个核心元素是CAEX

。它被嵌入到CAEX库、类、实例、属性等的数据模型中。这个元素有特定的子元素来存储相关对象的版本信息。CAEX头是CAEX基础类型的一部分，它是每个CAEX元素的根基类。

提供以下数据元素。

ChangeMode: ChangeMode的值可以是状态、创建、删除和改变。值state用于自上次数据交换以来没有改变的对象。创建值用于已经创建的新对象。如果一个对象要被删除，则使用删除值。因此，该对象没有从CAEX文件中实际删除，但被标记为将被删除。如果对象发生了变化，则使用值change。ChangeMode只对项目本身有效；例如，如果一个属性改变了它的值，只有它的值被标记为ChangeMode值 “change”，而不是该属性的主机对象的值。
Description描述、Version版本、Revision修订、Copyright版权。这些属性和元素允许存储每个对象的版本信息。
AdditionalInformation。这个属性允许存储任何类型的任意附加信息。
SourceObjectInformation、OriginID和SourceObjID：这些CAEX项目允许存储关于每个CAEX对象的来源的组织信息。详情在2.2.14.3和2.2.14.4中规定。

库、类、实例或属性的版本相关信息的一般建模规则是:

CAEX没有定义版本号的语法或语义，它有一个字符串数据类型。
库的版本管理是强制性的，每个CAEX库必须利用CAEX元素Version来定义其版本号。将这个元素的值设置为一个适当的字符串，例如 “1.0”。
CAEX库只能通过其名称来识别，因此禁止在同一个AML文件中存储具有相同名称但不同版本号的库。
类、实例或属性的版本划分是可选的。如果需要，CAEX类必须利用CAEX元素Version来定义其版本号，例如 “3.0”。
一个类的新版本应该被建模为一个有另一个名字的新类。在新类中，类的旧版本的完整路径应该被存储在CAEX元素Revision的CAEX标签OldVersion中。这一规定支持跟踪一个类的不同版本的变化。
CAEX 文档的创建者必须确保只引用版本兼容的类和外部文档。

2.2.14.3 关于AML源工具的元信息 Meta information about the AML source tool(s)

为了能够解释AML文件中的数据，对来源的参考是很有用的。由于CAEX只提供中性语法，并允许基于库的语义定义，它可以容纳多种语义模型的混合，利用标准化以及专有数据。因此，了解它是否来自西门子、ABB、EPLAN或COMOS等是很重要的。为此，每个AML文件都有字段用于存储识别其来源工具的信息。
图2-61说明了这一点。我们假设一个工具A将数据输出到一个CAEX文件。为了识别数据的所有者，CAEX提供了一个字段SourceDocumentInformation，它规定了识别源工具的专用字段。

源文件信息source document information的一般建模规则是:

每个CAEX文件都必须提供有关来源的信息。这个信息相当于一张名片；它可以识别信息的来源。
来源信息的值必须由创建CAEX文档的工具嵌入，并且必须是xs:string类型。
一个CAEX文档可以容纳任意数量的源标识符。在一个数据交换工具链中，所有参与的工具必须在CAEX文档中添加它们的来源信息。因此，一个CAEX文档可能包含一个数据交换工具链的多个源工具的信息。
一个工具可以删除其他工具的来源信息。这可能会阻碍与其他工具的迭代数据交换；因此，不建议删除其他工具的起源信息。
原产地信息必须通过CAEX文档根对象的CAEX元素SourceDocumentInformation来存储。SourceDocumentInformation对各方面进行建模，相关属性列在表2-5中。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qH7Vtg49-1658748592085)(https://cdn.nlark.com/yuque/0/2022/png/12809208/1642054771340-7f1bdf9d-b628-47f6-be9a-ae6572ed6755.png#clientId=uacf723ce-1ff8-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=586&id=u125e45ee&margin=%5Bobject%20Object%5D&name=image.png&originHeight=586&originWidth=952&originalType=binary&ratio=1&rotation=0&showTitle=false&size=120398&status=done&style=none&taskId=u417ba897-9f60-420d-b4fa-57ff0c56a24&title=&width=952)]
图2-62通过一个例子说明了CAEX SourceDocumentInformation的应用。

2.2.14.4 关于源对象的元信息 Meta information about source objects

CAEX对象通常代表在其原始工具中创建的源对象。特别是在迭代工程中，当把数据导出到CAEX的过程发生时，每个CAEX对象都能准确地知道它来自哪里，这是非常有用的。根据IEC62424（见第2.2.14.3节），每个CAEX文件都提供作为AML数据来源的源工具的信息。关于源对象的元信息更进一步。AML允许在源工具内对原始源对象的信息进行建模。建模的规则是:

CAEX建议使用可选的CAEX元素SourceObjectInformation及其属性OriginID和SourceObjID来识别每个CAEX对象的源工具，例如库、类、实例、属性。
OriginID 对应于 2.2.14.3 中描述的 SourceDocumentInfo 的 OriginID。
SourceObjID对应于源工具中的专有标识符。

图2-63说明了这个概念：在导出过程中，AML对象被告知它们各自的来源。这支持差异计算和迭代工程工作流程中的重复输出。