AutomationML (AML) is an international standard governed by the AutomationML association (legally AutomationML e.V., see AutomationML.org). AutomationML is a data exchange solution focusing on automation engineering. The data exchange format is defined in the IEC 62714-1series, “Engineering data exchange format for use in industrial automation systems engineering”.
The goal of AutomationML is to interconnect the engineering software tools from the different phases of the lifecycle and overall industrial automation disciplines (mechanical, electrical, process engineering, process control, HMI development, controller programming, etc.). It thereby forms an interoperable data space from a heterogeneous landscape. Using an object-oriented paradigm, AutomationML stores engineering information from the different disciplines to allow the modelling of physical and logical AutomationComponents.
An object in AutomationML is the data representation of an automation object or a group of automation objects. An object can consist of other sub-objects and may even be a part of a larger object. AutomationML supports many different hierarchies of objects. These objects can be representations of plant automation supporting information topology, geometry, kinematics, etc. Logical objects generally represent sequencing, behaviour, control, etc.
At the top level, AutomationML uses the CAEX data format, which provides the mechanisms for modelling user-defined data. Overall, AutomationML uses many industry data formats designed for the storage and exchange of different aspects of engineering information. These data formats are not changed for use in AutomationML but rather are used “as-is” from their respective specifications. CAEX is used to interconnect the different data formats.
An AutomationML Container is used to transport an AutomationML project consisting of multiple AutomationML documents and other non_AutomationML documents (supplemental information). Open Packaging Conventions specification is used as the container format. The file extension for an AutomationML Container is “.amlx”.
For the reader’s convenience, this informative appendix introduces a few basic concepts of AutomationML in a very concise manner. Further and more detailed information for AutomationML can be found at AutomationML.org. The reference white paper “AutomationML in a Nutshell” provides a primer for AutomationML. Note that all AutomationML whitepapers and recommendations are available to the general public free of charge at AutomationML.org.
AutomationML is a data format that uses XML files to convey data. While the basis of the AutomationML file follows CAEX in its makeup (see H.2), an important feature of AutomationML is its extensibility. AutomationML objects can link to other objects inside the same or other AutomationML files. Furthermore, it is possible to link to any other URI-addressable external resource from an AutomationML file. This allows for easy incorporation of proprietary formats into AutomationML since the language itself does not need to be expanded in order to link to any sources.
In addition, AutomationML is inherently robust to extension. AutomationML-compatible tools are required to ignore any data they come across that they cannot process. Thus, a heterogeneous mass of engineering data can be conveyed in a single format. Any tool that cannot process PLC programs, e.g., will ignore the sections of a file devoted to this kind of data. This, again, makes using AutomationML for new applications easy, as compatibility with existing tools does not have to be ensured in any specific way to keep engineering toolchains intact. The only issue that has to be addressed is, of course, the ability of tools to ingest the information they are supposed to ingest.
As mentioned above, AutomationML uses the concepts of CAEX for its base structure and thus has an object-oriented approach. What computer scientists should be aware of is that the inheritance CAEX and, thereby, AutomationML use is a template-instance concept as opposed to a generalization concept like higher programming languages like C++/C# or Java use it. AutomationML objects can inherit from other objects. However, the fact that an inheritance took place does not guarantee the presence of certain attributes in objects. In AutomationML, it is legal that attributes of objects might be erased and altered over the course of the engineering process. For more information on this, consult the AutomationML Whitepaper.
AutomationML objects fall into four different categories. Each of these categories allows for attributes to be contained in the object. The categories have inherent meaning in the correlation of AutomationML objects. Internal Elements are used to represent a concrete entity on a shop floor. System Unit Classes, on the other hand, are templates that can be used for instantiating Internal Elements, so this category can be used for types of products, e.g., Role Classes represent abstract automation objects such as electric motors in general, modelling their relevant attributes without the need to refer to a concrete device. The fourth category is Interface Classes, which model relationships between objects in the other categories. Interface classes can have attributes that allow the representation of complex relationships between AutomationML objects.
Again, if you seek more information on these concepts, “Whitepaper AutomationML in a Nutshell” from AutomationML.org provides a good starting point and is freely available.