CHAIR OF

PRODUCTION SYSTEMS

AND AUTOMATION

AutomationML getting ready for full use

May 2016 In 2006, the development of the data exchange format AutomationML started, with the IAF being involved right from the beginning. It took only 10 years to create a data exchange technology (Automation Markup Language = AutomationML) that is able to find answers for a large variety of questions concerning the data management when designing production systems.

The design of production systems is a complex process, involving various engineers from different designing areas who carry out different designing activities and apply/draft different designing artifacts. These artifacts are essential tools when it comes to designing, using and maintaining a production system.

Different investigations have shown that the design of production systems to a large extent comprises manual activities which, however, include the repetition of designing steps performed by different designing tools. This is caused by the lack of suitable devices for a data exchange between these tools.

In order to guarantee a consistent data transfer various approaches were considered, ranging from the use of complex, self-contained tool systems for the entire designing chain to the use of individual tools linked via data transfer formats. Each of them has their particular advantages and disadvantages. Since designing organizations have to be increasingly flexible, though, the importance of tool links via data transfer formats turns out to be highly significant.

As for a data transfer format used in the context of designing production systems, there is a number of (sometimes contradictory) requirements that have to be fulfilled:

• The data format should be adjustable and flexible as regards extensions and modifications.
• The data presentation should be efficient.
• The data presentation should be readable for humans.
• The data presentation should be based on international standards.

These conditions are easily met by XML-based data formats.

The data transfer between designing tools has to be considered in two different standardization levels, that is syntactic and semantic level. The syntactic level contains the correct informational presentation of the data objects within the data transfer format. Here, the vocabulary of the data transfer is provided. In contrast to that, the semantic level deals with the interpretation of data objects, that is their relevance for the conceptualization of objects within the designing chains.

Data transfer formats might approach the implementation of these two levels in two different ways. Either syntax and semantics are defined together, as was done for the development of STEP, or syntax and semantics are defined separately, as was done for the realization of AutomationML. Since the separate definition of semantics promises higher flexibility and adjustability of the data transfer format in practical cases, this approach appears to be the preferred one.

For the time being, AutomationML provides both syntax and semantics for the exchange of information relevant for at least two designing activities of the production system’s designing processes, and can therefore be used for at least two tools of the tool chain:

• Topology information: This amount of information describes the hierarchical structuring of the production system from the production system level via cell and resource levels down to the levels of devices and mechanical components. Besides the individual hierarchical elements, it also covers their relations and characterizing features.
• Information related to mechanical properties: This amount of information describes the mechanical construction of the production system including its geometrical and kinematic properties. Usually, it is drafted as a technical drawing of an MCAD tool. In addition, this amount of information includes physical properties of the production system and its parts such as force, speed and rotation angle as well as mechanical properties like material information.
• Information related to electrical, pneumatic and hydraulic properties: This amount of information includes the electrical and fluidic construction of the production system including wiring and piping, as can be developed by means of ECAD and FCAD tools. On the one hand it comprises the linked components, while one the other hand it includes the connections between them, with their interfaces and the respective properties related to electrics and fluidics.
• Information related to functions of the production system: This amount of information serves the purpose of characterizing the functions of the production system and its components. For that reason it includes behavior models of the uncontrolled (physically/chemically/etc. possible) behavior as well as of the controlled behavior, added by functional and technical parameters. The functions observed for this information amount are not only related to the functions required in production but also to all the necessary support, diagnosis, maintenance and other functions.
• Information related to the control of the production system: This amount of information includes all the information related to control devices. In particular, these are hardware configuration, control code and control parameter.
• Additional information: This amount of information comprises other essential information such as economically relevant information like item numbers by the manufacturer and prices, or organizational information like assembly and maintenance instructions, manuals, etc.

Picture 1: Amounts of information

When modeling designing information, AutomationML uses an object-oriented approach, thus enabling the description of physical and logical plant components as data objects that comprise different aspects. Objects may form a hierarchy in this respect, i.e. an object can consist of several sub-objects and might be a part of a larger component itself. Typical objects in factory automation contain information about the structure (topology), geometry and kinematics as well as the behavior.

Here, AutomationML features a modular setup, integrating and adapting various already existing XMLbased data formats under one roof, the so-called roof format (see picture 6). These data formats are applied “as-is” and were not branched for AutomationML requirements. However, AutomationML does define application rules.

Picture 2: Structure of an AutomationML project

In terms of logic, AutomationML is divided into the description of the plant structure and the communication systems by using CAEX IEC 62424, the description of geometry and kinematics by using COLLADA 1.4.1 and 1.5.0 (ISO/PAS 17506:2012), the description of the control referring to logical data by using PLCopen XML 2.0 and 2.0.1 and the description of the interrelations between the AutomationML objects and references about information archived in documents outside the data format.

Currently, AutomationML is being standardized in the IEC 62714 standards series.

The fundamental basis of AutomationML is the use of CAEX as roof format and the definition of a suitable CAEX profile which complies with all the relevant requirements for modeling designing information of a production system, for the integration of the three mentioned data formats CAEX, COLLADA and PLCopen XML and, if need be in the future, for means of expansion.

Picture 3: AutomationML topology description

CAEX enables the object-oriented approach mentioned above. It allows to determine the semantics of the system objects by using role classes which are defined and listed in RoleClassLibraries. Interfaces between system objects are specified by using interface classes which are defined and listed in InterfaceClassLibraries. Based on both types of classes (and the respective libraries), classes of system objects are modeled by using SystemUnitClasses (SUC) which are defined and listed in SystemUnitClassLibraries. Ultimately, all the modeled classes serve the purpose of modeling the actual project information, that is the individual objects of the modeled production system, in semantically clear manner. This is done by way of one (or several) InstanceHierarchies (IH) as a hierarchy of InternalElements (IE) referring to both SystemUnitClasses which they were derived from and RoleClasses which determine their semantics. In order to link with each other or with externally modeled information (such as COLLADA and PLCopen XML data), they might contain interfaces. The specific properties of objects, SystemUnitclasses, roles and interfaces are imaged with the help of attributes.

For more details refer to the AutomationML Whitepaper on www.automationML.org as well as the „AutomationML in a Nutshell“ document issued by IAF.

Contact: apl. Prof. Dr.-Ing. habil. Arndt Lüder