AutomationML - story
Regarding automation control and robotics efforts today nearly 60% of all factory automation costs are caused by engineering and commissioning. In the past, optimisation strategies had addressed the bought-in parts; nowadays optimisation of the engineering process is worth striving for (see Figure 1).
Figure 1: Cost structure analysis of robotics and controls, AIDA 2005
Based on the results of the AIDA study Daimler started a project with the goal to reduce engineering costs by half. Further researches had shown that important costs were caused by transferring data between tools; and the frequent data transfer is caused by the existing heterogonous tool landscape, e.g. engineers want to use their familiar tools (‘Best in class-tool’). Here, most data is available stored in proprietary files which are only openable with a limited number of tools; in most cases vendor specific tools. Does not even such an interface exist the data has to be entered and maintained in tools manually, quasi a transfer via a paper interface. All in all, this leads to a very inefficient and error-prone engineering process. For example, within the plant planning phase hall plans (e.g. created in MicroStation) are manually redrawn in another tool for line planning; or in logics development where mechanical engineers develop time schedules in Microsoft Office tools which are only re-used manually for PLC programming.
After evaluating some data exchange formats Daimler initiated the development and standardisation of AutomationML as an intermediate format for the ‘Digital Factory’ in October 2006; The companies ABB, KUKA, Rockwell Automation, Siemens, NetAllied, Zühlke, and the universities of Karlsruhe and Magdeburg participated in that project. In spring 2009, this industry consortium opened up and founded a registered association: AutomationML e.V.
With AutomationML as an open, neutral, XML based, standardised, and free data format the data can be exported and imported by tools correctly and without any loss. Hence, the data quality is improved - also because of the possibility to simulate/test the engineering data earlier within the engineering process - which leads to a time and cost reduction. Another fact is that AutomationML can be used within the entire engineering process because of its structure. All plant engineering specific data can be stored within this format: plant structure, geometry and kinematics, logic descriptions, relations between objects, and network related data (communication, electric ...). The data is kept consistently, semantically unambiguous, and can also be kept in a mechatronically oriented way. Figure 2 shows the base structure of AutomationML. The top level format references externally stored data, e.g. the geometry of a plant module in a COLLADA file. The developed structure enables the extension of the data format as well as its adaption of different applications cases without losing significant and semantical correctness and clearness.
Figure 2: AutomationML base structure
Right from the beginning, AutomationML e.V. had the goal to not invent a new data format. Instead existing data formats should be used and combined in a proper way which also should accelerate the development. For that reason cooperations were made with other organisation that developed a format suitable for AutomationML purposes. Together with the KHRONOS Group AutomationML e.V. adapted the COLLADA format for the geometry and kinematic descriptions; and with the PLCopen AutomationML e.V. adapted the PLCopen XML format to be useable for all logic descriptions which are defined in Part 4. In 2013, further three cooperations were established: An aim of the cooperation with eCl@ss e.V. will be the development of rules defining, on the one hand, how eCl@ss descriptions can be used to syntactically standardise information with the data exchange format AutomationML, and, on the other hand, how they can be exchanged - semantically unambiguously. An aim of the cooperation with and OPC Foundation will be the development of an applicable structure to transmit AutomationML structured information by use of OPC technology. An aim of the cooperation with ProSTEP iViP will be about intensifying cooperation between both parties with regard to the AutomationML (IEC 62714), JT (ISO 14306) and STEP AP 242 (ISO 10303-242), and by this to strive towards the harmonisation of these specifications. In 2016, another liaison with the FDT Group was established. One objective is to define an AutomationML application profile to describe the topology and the relation of devices of an automation project. All cooperations are displayed in figure 3.
Figure 3: Liaisons of AutomationML e.V.
A requirement for using AutomationML in a tool chain is that the tools are equipped with an AutomationML interface. Some tools already provide it and the underlying open standards (PLCopen XML and COLLADA) are field-proven in multibillion businesses.
In recent time AutomationML has become a widely used technology as proven by AIDA, NAMUR, VDMA, and others.