4 General information to AutomationML and OPC UA ToC Previous Next

4.1 Introduction to AutomationML ToC Previous Next

The AutomationML data format, developed by AutomationML e.V., standardised in IEC 62714, is an open, neutral, XML-based, and free data exchange format which enables a domain and company spanning transfer of engineering data of production systems in a heterogeneous engineering tool landscape. The goal of AutomationML is to interconnect engineering tools in their different disciplines, e.g. plant planning, mechanical engineering, electrical engineering, process engineering, process control engineering, HMI development, PLC programming, robot programming.

AutomationML stores engineering information following the object oriented paradigm and allows modelling of physical and logical plant components as data objects encapsulating different aspects. An object may consist of other sub-objects, and may itself be part of a larger composition or aggregation. Typical objects in plant automation comprise information on [topology](http://en.wikipedia.org/wiki/Topology” \o “Topology), [geometry](http://en.wikipedia.org/wiki/Geometry” \o “Geometry), [kinematics](http://en.wikipedia.org/wiki/Kinematics” \o “Kinematics), [logic](http://en.wikipedia.org/wiki/Logic” \o “Logic), and behaviour.

In addition, AutomationML follows a modular structure. AutomationML is based on IEC 62424 (CAEX) and integrates other already existing XML-based data formats (see Figure 1). These data formats are used on an “as-is” basis within their own specifications and are not branched for AutomationML needs.

Logically AutomationML is partitioned in:

  • description of the plant structure and communication systems expressed as a hierarchy of AutomationML objects and described by means of CAEX following IEC 62424
  • description of geometry and kinematics of the different AutomationML objects represented by means of COLLADA 1.4.1 and 1.5.0 (ISO/PAS 17506:2012)
  • description of control related logic data of the different AutomationML objects represented by means of PLCopen XML 2.0 and 2.0.1 (IEC61131-10)
  • description of relations among AutomationML objects and references to information that is stored in documents outside the top level format /

readme_files/image005.png

Figure 1 – AutomationML base structure

Due to the different aspects of AutomationML, the IEC 62714 series consists of different parts focussing on different aspects:

  • IEC 62714-1: Architecture and general requirements - This part specifies the general AutomationML architecture, the modelling of engineering data, classes, instances, relations, references, hierarchies, basic AutomationML libraries and extended AutomationML concepts. It describes the use of CAEX. It is the basis of all future parts and provides mechanisms to reference other sub-formats.
  • IEC 62714-2: Role class libraries - This part is intended to specify additional AutomationML libraries to derive necessary roles for semantic definition in individual application cases.
  • IEC 62714-3: Geometry and kinematics - This part is intended to specify the modelling of geometry and kinematics information based on COLLADA.
  • IEC 62714-4: Logic - This part is intended to specify the modelling of logics, sequencing, behaviour and control related information based on PLCopen XML. Further parts may be added in the future in order to interconnect additional data standards to AutomationML.

4.1.1 Top-level format CAEX ToC Previous Next

The foundation of AutomationML is the application of CAEX as the top level format. Furthermore, AutomationML defines an appropriate CAEX profile fulfilling all relevant needs of AutomationML to model engineering information of production systems. It integrates the three data formats CAEX, COLLADA, and PLCopenXML, and enables an extension, if necessary, in the future.

CAEX enables an object oriented approach (see Figure 2) where

  • semantics of system objects can be specified using roles defined and collected in role class libraries,
  • semantics of interfaces between system objects can be specified using interface classes defined and collected in interface class libraries,
  • classes of system objects can be specified using system unit classes (SUC) defined and collected in system unit class libraries, and
  • individual objects are modelled in an instance hierarchy (IH) as a hierarchy of internal elements (IE) referencing system unit classes they are derived from, role classes defining its semantics, and interface objects used to interlink objects among each other or with externally modelled information (e.g. COLLADA and PLCopenXML files). readme_files/image006.jpg

Figure 2 – AutomationML topology description architecture

Previous Next