AutomationML 学习心得
断断续续地学习AutomationML（下面简称AML），其内容很多。概念，术语与与其它建模语言有类似之处，也有不同。同时涉及了一大堆标准。
- CAEX（IEC 62424）
- COLLADA 几何、动力学模型
- PLCopen XML
但是，在生搬硬套的同时，也感到疑惑，为什么要建立这样的语言来实现数据交换，没有其它的方法么？既然现在又大量推荐工业4.0 管理壳，OPC UA 等标准。AutomationML还有存在的意义么？
AML的用途
AML 是用于工程数据交换的建模语言。
在制造领域的工程中，由多个学科的工程师参与其中。不同的学科将会使用大量不同的工程设计软件。
AML 数据格式由 AutomationML eV 开发，在 IEC 62714 中标准化。它是一种开放、中立、基于 XML 的免费数据交换格式，支持在异构工程工具环境中跨领域和公司跨域和公司传输生产系统的工程数据。AutomationML的目标是互连不同学科的工程工具，例如工厂规划、机械工程、电气工程、过程工程、过程控制工程、HMI开发、PLC编程、机器人编程。
这些工程工具处理的数据文档种类繁多，五花八门。
不同工具数据之间的数据交换的工作量非常大。当工程公司为多个客户工作时，为了接受每个客户的工程数据时，就需要拥有客户使用的工程工具，工程工具的许可费用就会激增。并且需要熟悉这些工具的专家。在机械加工厂，客户发来的CAD 图纸是各种CAD软件导出的，机械加工厂工程师要将这些图纸转换成为内部CAD工具的格式。然后编写工艺文件和CNC G代码。这些工作增加了制造成本。对于小批量加工而言，是不小的开支。
工程的特点是历史上成长起来的强大的分工，在过去被分为独立的阶段或行业。在每一个阶段中，工程师都会继续改变工程数据。在这样做的同时，所有不同的工具的数据都会发生分歧，工程数据在工程过程中会不断地、反复地被充实和改变。这不是工作流程或工程方法上的错误，而是工程的本质。为了保持工程工具之间的数据同步和一致，需要做出巨大的努力，这是AML能够发挥作用的地方。
CAEX模型
AML 基于 IEC 62424 (CAEX)，并集成了其他现有的基于 XML 的数据格式。
CAEX 的全称为计算机辅助交换（computer aided exchange）。
CAEX的架构
包含了三种类 SystemUnitClass，InterfaceClass，RoleClass或者Attribute 类型。类的实例称为内部单元（Internal Element）。
系统单元类（System Unit Class）
在工程中，设备通常是在指定了相关要求后手动选择的。在工程中，设备通常是在指定了相关要求后手动选择的。比如指定一个厂商的储存罐A，而储存罐A是通过SystemUnit类描述的。
角色类（Role Class）
最费解的是RoleClass ，它的名称直译为“角色类似”，它到底是什么？为什么要设置一个角色类型呢？
这要从系统构建过程说起，设计一个系统，类似于电影的编剧编写一个电影脚本，编剧首先要设想一些角色（role），比如设想了一个公主的角色，按面向对象的思想，相当于设计了一个公主的类。编剧描述了公主的特点，例如金色的头发，细腰，蓝眼睛。这些是公主类型的属性。
同样地，在工程设计中，首先通过一系列抽象的角色来描述一个制造过程，它独立于其具体的技术实现。例如输送机、机器人、转台和一个PLC。
在下一步，工程师们定义需求，并逐步细化。这些要求被用来识别和指定在技术上实现所需功能的具体设备（比如某一个厂商的设备）。这样的设计过程符合实用、迭代、工程和人类的思维方式。
角色概念遵循了成熟的设计过程，将规范和实施阶段脱钩。
在下图中：
Computational independent Model（CIM）计算无关的模型
Platform Independent Model（PIM） 应该就是角色类。
Platform Specific Model(PSM) 应该是SystemUnitClass
Platform Specific Implementation(PSMI) 应该是Internal Element
角色类的定义
一个角色是一个描述抽象功能却未定义底层技术实现的类。
可以将角色类理解为某个单元的“技术要求”，例如在生产线中需要一个机器人角色，技术要求为“最大负荷<2t”。
角色类并不指定特定的产品。而是标准化定义抽象模型。例如：motor 是电机的角色模型，并不是具体哪个厂商的电机产品。
角色类库的标准
IEC 62714-2 角色类库（Role Class Libraries）在该标准中制定了：
- 离散制造业的AML 角色类库
- 连续制造业的AML角色类库
- 批制造业的AML角色类库
- 控制系统的AML角色库
内部单元（InterElement）
AML 采用了基于模型设计的工程设计思想，以模型的实例构建工程数据。在AML 中，实例称为内部元素（Internal Element）。Internal Element 是角色类型（RoleClass）和系统单元类(System Unit Class)的实例，也可以引用角色类进行建模。
COLLADA 几何和运动学模型
COLLADA 是KHRONOS 协会在SONY 的领导下 作为游戏行业数字内容创作领域交换格式开发的。COLLADA 允许3D 场景下3D对象的可视化，包括对象动画的相关视觉，运动和动态属性。
为什么AML 会选择游戏行业的交换格式呢？工程对象中几何模型是基本的工程数据。在几何模型的可视化中，需要动画展示组件的运动和动态特性。而大多数三维模型格式并不包括动画特性（比如 step 格式）。
COLLADA 其实被废弃了。造成这种情况的原因有很多：
- 该规范并不复杂，但解析基于 XML 的格式可能很麻烦，因为所有数据类型都需要从文本转换。实现者更喜欢库来完成这项工作，但不存在好的库。FCollada 停产了，OpenCollada 被证明比大多数游戏引擎都大。
- 该规范在许多方面都非常模糊，例如必须如何导出数据、骨架、混合形状等。它还为导出者提供了很大的自由度，包括使用的单位以及世界变换规范（例如，哪个轴向上）。所有这些都为任何想要解析格式的人带来了巨大的工作。
- 直到今天，大多数出口商都破产了。在某些 ID 中不是唯一的，不遵守规范规定的部分顺序，并且经常缺少信息。
- Collada 是一种文本格式，因此加载大文件的速度很慢。
- Autodesk（有意或无意）通过在其产品中包含不完整且有缺陷的导出器来反对采用格式。直到今天，大量的开发人员认为 Collada 无法实现它实际上的很多功能。
- Blender（有意或无意）通过采用不完整的导出器来反对该格式。
KHRONOS 提出了GLTF 3D模型格式。
glTF™ 是一种免版税规范，用于高效传输和加载 3D 场景和 按发动机和应用分类的模型。glTF 最小化了 3D 资产的大小和运行时 需要进行处理才能打开包装和使用它们。glTF 定义了一种可扩展的发布格式，该格式 通过实现 3D 的可互操作使用，简化创作工作流和交互式服务 整个行业的内容。glTF 2.0 已作为 ISO/IEC 12113：2022 国际发布 标准。
不知道AML 是否会转向glTF。
行为模型（PLCopen）
所谓行为是指为了达到系统的目的，模型的状态和输出如何做出改变的规则。
为了达到某一种目的，需要通过行为模型人为地编排事物的行为。目前，自动化行业的控制设备仍然是以PLC为主的。所以行为模型是以PLC 为基础构建的。PLCopen是目前重要的PLC 程序编排的标准。
PLCopen由PLCopen协会开发的。使用XML语言描述。PLCopen 在1992年成立，距今已有32年的历史，总部设立在荷兰。在美国，日本和中国有分支机构。PLCopen 主要的贡献：
- 支持PLC 编程语言的标准-IEC 61131-3
- 支持标准的运动控制库
网络上已经有大量的文章介绍PLCopen，这里就不再赘婿了。
工程设计过程
- 系统采用分层架构组织数据，第一步定义系统中的对象（例如机器人-1）。
- 从角色库中分配一个合适的（这里是机器人）角色类型.
- SystemUnitClass库中选择合适的候选对象，具体的技术方式实现
一个CAEX对象与两个类有关系：抽象角色和具体对象类型。
工程数据模型的标准化流程
- a) 每个参与的工程工具或领域的专家小组必须提出他们的 “自己的概念 own concepts”。
- b) 所有参与者必须就 "共同概念 common concepts "达成一致。
- c) 必须定义一个中立的语义数据模型 neutral semantic data model，涵盖共同的概念，例如使用 UML 的对象模型。
- d) 必须就通用数据模型 common data model 的中性语法 neutral syntax 达成一致，例如，使用 XML。
- e) 必须编写一份文件，描述
- 商定的共同概念、
- 语义数据模型
- 和语法实现，例如，在标准文本或白皮书中。
- f) 在工业界，必须有足够的了解该标准的专家，以便通过数据输出和输入器将其实施到各自的工程工具中。
- g) 工业界必须提供足够的支持该标准的输出和输入软件。
- h) 应用的经验反馈到（a）。
AutomationML应用
标准通过软件普及
和其它信息化标准一样，AML 也只有通过软件工具来普及。尽管AutomationML 也提供了一些基础的工具软件，比如 AMLEditor和AML Hub 。但是它们的用户体验并不完美。也不符合工程师的使用习惯。只有将AML 标准嵌入到工程管理软件和平台中，才能能够普及。
相关的软件是设计文档管理系统，PLM 系统等软件。打开西门子的网站，展示了琳琅满目的工业软件，可以看出西门子公司正在大踏步地转向以软件为中心的数字化制造。但是它的3D 模型并不是COLLADA 而是JT模型，PLM 软件teamcenter 中只字未提AutomationML ，而是自家的XML 建模方案。但是其设计理念与automationML 异曲同工之妙。
个人觉得发展工业软件应该坚持问题导向的原则，解决工业界的问题是关键所在。当时机成熟，将自家的方言转成标准语言并不是太难的事情。构建开放自动化系统因该自顶向下的设计方式。根据需求设计软件，将AutomationML 等标准内嵌到软件之中，没有软件谈标准总觉得比较空。
对于初创企业和小公司而言，更多应该采取跟随战略。标准就是大公司给我们流出来的一条缝，可以让你的产品钻进去。比如OPCUA 就是这样的一条缝隙。当下该好好珍惜。
短期受累，长期受益
构建基于AML 语言的工程，需要使用大量的类库，角色类，工程单元类和接口类。如果缺乏这些类库的支持，平地而起来构造AML 模型的是非常耗费时间的。所以AML更适合成熟的工业设计院和企业首先采纳。这些大企业和大院所已经积累了大量基于行业的数据文档。使用AML 语言为这些文档构建基于AML 的数据模型，能够提升工程设计过程中数据交换的效率，避免差错。这是一项短期效果不明显，甚至麻烦的事情，但是长期受益。
中小型企业只有利用外部的资源才能够推广使用AML。例如各种类库和软件。
大企业或者大型设计公司AML 的模型和类库可能沿着供应链扩散到与其合作的中小型企业。
精通AML的专业软件公司和咨询公司能够为大型设计院和大型企业提供构建AML 架构的咨询服务。
选择恐惧症
ML，ECL@SS，OPCUA和AAS 各种标准相互交叉，在实际应用中如何选择，使人犹豫不决。
目前，面对数字化制造的潮流，各种标准都起头并进，互相交织在一起。有些职能是重叠的。比如 AML，工业4.0的管理壳AAS，E-CL@SS ，OPCUA 都相互重叠。我们应该如何选择？完全被动的模仿也许是不行的。我国制造业采用数字化模型的时间还刚刚起步。没有历史包袱。我们在采用和推广国际标准时，能否采取更加实用主义思想，甚至“弯道超车“？这是值得思考的，尽管许多人并不喜欢“弯道超车“的说法。
比如说，AML，ECL@SS和AAS 有重叠的部分。它们都是为制造业建立统一的模型。最终都能够映射成为OPCUA 模型 。能否越过AML ，直接发展管理壳AAS+OPC UA 呢？
（本文的内容参考了AMLBook1: 初学者指南 | 第一章 1 What is AutomationML）