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

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

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

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

元模型的例子
在我们地址簿的例子中，元模型不会提前定义与固定地址相关的字段。相反，它只有一个名字field具有名称、值、语义等通用属性的字段。元模型是抽象的；它超越了特定的项目，而是抽象的项目。这使得地址簿的结构非常简单：它可以存储无限的地址条目，每个地址条目都可以持有字段，无论有多少字段，字段的语义都存储在图书馆中，图书馆可以扩展。这个概念可以扩展，每个字段的含义都可以清晰地模拟。它涵盖了所有即将到来的地址条目，甚至是未知的。在不改变元模型的情况下，可以扩展地址簿模型。

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-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-5通过CAEX解释文档的一部分CAEX结构包括一个库MySystemUnitLib对象层次结构MyHierarchy。在图片的右应CAEX突出显示元素。

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

在异质工具环境中，不同的工程工具使用不同的概念来识别对象，如唯一的名称、唯一的标识符或唯一的路径。有些工具允许在生命周期内更改标识符，而另一些工具则不允许。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]。

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

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

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

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

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

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

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

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

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

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

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

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

• Attributes：允许指定对象的属性
• ExternalInterfaces：允许规范对象的接口
• InternalElements：允许规范嵌套的内部元素
• SupportedRoleClass：允许指定支持的角色类别
• InternalLinks：允许规范接口之间的关系
  
  一个系统单元类库由一个系统单元类的层次结构组成。以同样的方式，实例由内部元素的层次结构组成。

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

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

• 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展示了属性的不同方面。

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

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

图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。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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.

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

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

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

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

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

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

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

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

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

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

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

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

路径paths的建模规则是:

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

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

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

父-子关系（见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-8（见2.2.3.5节）显示了实例层次结构中的父子关系。
父-子关系在实例层次结构和所有的类库中都有使用。图2-51说明了类库中的这种关系。 ParentChildRelationExampleClassLib包含一个ParentClass类，它又包含一个ChildClass类。

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

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

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

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

• 类之间允许继承。一个类可以有任意数量的子类，但只有一个父类。一个类中的所有变化都会被所有子类自动反映出来。
• 继承意味着所有可用的父类和祖类的属性、接口、内部元素、映射对象或进一步的内容都会自动出现在子对象中。
• 继承的类可以在类的层面上用新的属性、接口等进行扩展。
• 存储Storage继承数据。继承的数据对子数据是有效的，可以选择在
  复制到XML文档中的子对象上。为了覆盖或扩展继承的信息，重新定义和存储已经继承的数据是可能的和有用的。如果数据被从父类物理复制到子类，并且后来在父类上有所改变，那么复制的子类数据应被更新。
• 覆盖Overriding继承的数据。通过在子对象中用更新的值重新定义相应的数据，可以