AutomationML
AutomationML is a comprehensive XML based object-oriented data modeling language. It allows the modelling, storage and exchange of engineering models covering a multitude of relevant aspects of engineering. AML provides a comprehensive set of flexible mechanisms and innovations to model today’s engineering aspects as well as future engineering aspects to come. Its language characteristics allow to model existing or new domain models.
Motivation behind AutomationML
The life cycle of production systems is and will be more and more digitalized, independent of the invention of the „Industrie 4.0“. Data has been playing an important role within the life cycle of production systems for ages.
In the context of the engineering of production systems, design data is specified step by step. Based on the first draft planning, design data is specified or enriched until it has reached a sufficient level of detail to physically realize the production system.
Within the phase of the physical realization of the production system the developed digital artifacts are applied and the realization results (and partially the required changes) are documented. A system documentation is thereby achieved that covers the complete system in a detailed structure, behavior and property representation.
The operating phase of the production system is characterized by the collection and processing of data that are either used to control the system/system element utilization or to document the system use (for example with regard to product or process quality achieved).
Data flow along the entire life cycle of a production system has increasingly been identified as a bottleneck in terms of achieving good engineering efficiency and quality. This is one of the main drivers for the development of ideas in Industrie 4.0. Engineering and constitutes one example of that.
Where to use AutomationML?
Basic architecture
AutomationML has a lean and distributed file architecture. It does not define any new file format but combines existing established XML data formats which have been proven in use for their specific domain. This is why the normative part of the IEC62714-1:2018 document consists of 32 pages only. The data formats for the following modelling domains are:
- object topologies including hierarchies, properties and relations of objects: CAEX according to IEC 62424
- geometries and kinematics of objects: COLLADA 1.4.1 and 1.5.0 (ISO/PAS 17506:2012)
- discrete behavior of objects: PLCopen XML 2.0 and 2.0.1; in addition, IEC62714-4 will allow the usage of IEC61131-10
CAEX according to IEC62424 forms the base of AutomationML. It stores object-oriented engineering information, e.g. a plant hierarchy structure (see AutomationML topology). Each CAEX object can contain properties and reference geometry, kinematics or logics information stored in third party XML files. This enables cross-domain modelling and is designed for future extension.
Getting Started
AutomationML presents challenges to new users that are not to be underestimated regarding the knowledge required for the successful application of AutomationML. These relate to very different areas of knowledge that are needed during the implementation of new applications.
Get to know the architecture
As a basis, a potential user must become familiar with the architecture of AutomationML. They need to understand how AutomationML maps specific data and how it can be applied and expanded. Core concepts are the role classes, the interface classes and the instance hierarchy with their internal elements.
- Role classes should be used to map the relevant concepts within an application domain and to give them the relevant properties in this domain (via attributes) and references to other concepts (via interfaces).
- Interface classes, in this context, depict the possible abstract relations between relevant concepts and their properties (via attributes).
- In the Instance Hierarchy, these role and interface classes are taken into account when creating internal elements and applied as semantic indicator.
Gain the necessary basic knowledge
Potential users should refer to existing examples as well as the publications of the AutomationML e. V. and its members. Here on the website you will find all documents published by the AutomationML e. V., the AutomationML Books and a list of specialist publications that provide information on various topics related to AutomationML. It may also make sense to book a training course with one of the AutomationML members during which not only basic knowledge but also first solution concepts of the potential user‘s specific application can be discussed.
Examine the use case
After exploring AutomationML as a technology, a detailed examination of the use case of AutomationML is required. At this stage, the user must be able to understand the application-specific data and, if necessary, to model the relevant data. This modeling forms the basis for the subsequent mapping of the application case using AutomationML.
Application-specific mapping and modeling
- The relevant modeling concepts are mapped using role classes that contain all the important properties.
- At the same time, the relations between the modelling concepts must be mapped via interface classes.
- Optionally, System Unit classes can now be designed as templates for reusable units.
- In theory, a validation of the modelling is recommended. The design artifacts that were found in the analysis of the specific application field should be mapped by means of AutomationML in the course of the validation.
It is recommended to execute the four steps in close cooperation with the members of the AutomationML e.V. and the AutomationML workshop team. They are able to identify information about possible inconsistencies and incompatibilities of the developed modeling with the developments in the AutomationML e.V. and to make appropriate suggestions for improvement. This is usually done without additional costs for the potential user as the AutomationML e.V. can validate the existing set of specification documents based on their application experience. This application experience can provide the basis for further standardization. This applies in particular to the developed role and interface class libraries.
Implementation phase
Application-specific modelling is followed by the implementation phase. In this phase, the necessary tool interfaces and other systems required for the desired AutomationML-based data logistics must be created (possibly using the examples created in the modeling). Both the existing and newly created interfaces can be used here. In case of newly created interfaces the AutomationML e.V. provides sample software. Being part of AutomationML e.V.‘s work, potential users can, of course, contact experienced users and exchange implementation experiences in order to avoid known mistakes.
When using the right approach, the implementation of the necessary software interfaces is one of the smaller problems of a potential user. This is due to the sample software available as well as the standardization of AutomationML Engines, which is promoted by AutomationML e.V., as software systems for reading and writing AutomationML files. Furthermore, providing the AutomationML object model facilitates the implementation. These engines should follow the Common API developed by the AutomationML e.V. as it provides comprehensive object management capabilities for AutomationML based data-systems.