On this page you will find an overview of the organisation of the AutomationML association as well as further information about the working groups.
Working Groups
Below you will find more information about the various working groups of the AutomationML Association.
Description/Mission
The aim of this joint working group (in cooperation with the sub working group “Asset Administration Shell” of
the Platform Industrie 4.0 Working Group “Reference Architectures, Standards and Norms “) is the cooperative development and maintenance of the AutomationML based serialization of the asset administration shell information and their integration with other serialisation means to be published as application recommendation as well as as part of the specification „Details of the Asset Administration Shell“.
Results
Description/Mission
The working group „Application scenarios“ deals with the identification, description and communication of best practice for the implementation and use of data exchange based on AutomationML.
It considers related technologies and processes including topics like:
- encryption
- data storing
- data management
- data exchange channels
This working group serves an overarching function and covers the activities of various sub-working groups (SWG).
Description/Mission
A very frequently occurring task within the planning process of production and automation systems is the exchange of automation project configuration information of automation system devices between electrical engineering and control programming systems.
As the electrical and control engineer usually attend the project at different times the automation project configuration of the plant must be defined in both tools. It depends on the organization of the project which engineer is taking the lead but in both possible cases the information obtained needs to be exchanged.
Even when electrical engineering and control programming tools have different views of automation system information they have a common ground, e.g. devices which are involved in automation systems and their wiring and relation to control variables.
Beyond the named engineering tools for electrical engineering and control programming, other tools are of interest as well in the common data set of both tools. For instance, tools for mechanical engineering could be interested in the amount of wired devices while documentation tools could be interested in the wiring structure.
AutomationML has developed an application recommendation taking up the common concepts of automation project configurations and mapping them to AutomationML concepts.These are the most relevant concepts:
- Automation project represents the complete, modelled automation system and aggregates all objects that belong to it,
- Device represents a collection in which the individual HW objects are brought together,
- Device item represents identifiable HW modules and sub modules (CPU, I/O module, rack, etc.) of a device,
- Tag represents the symbolic name of I/O data and provides the logical view on a channel of a module, and
- the channel representing a process interface (e.g. digital or analogue input/output), as well as further data structuring and concepts related to communication systems.
These common concepts are translated into role and interface classes with appropriate attributes compressed in common role and interface class libraries defined in the application recommendation.
Use Cases
Results
In addition to the Application Recommendation (AR) Automation Project Configuration, several Application Recommendation Extensions (ARE) were also developed as part of the working group.
These include:
- ARE ASi for APC
- ARE DRIVE-CLiQ for APC
- ARE Ethernet for APC
- ARE Extension Rack for APC
- ARE IO-Link for APC
- ARE Mpi for APC
- ARE Profibus for APC
You can download the documents via the following link…
Description/Mission
The Component Classification working group deals with the definition of an AutomationML model for a 360° automation component, integrating most aspects of AutomationML in one model and supporting different semantic classification systems.
Use Cases
Component related information is relevant in various engineering activities along the engineering chain of production systems. Within the engineering process of production systems, automation components can be defined in the single engineering phases exploiting various tools. Thereby, automation component information is created. This should subsequently be applied within the detailed design of devices and the device commissioning. Within the different engineering activities, specialized engineering tools are used and will have a relevant impact one the automation component information.
These tools will create and/or consume component related engineering information depending on the use case within the engineering chain.
Relevant use cases for the exchange of automation components are:
- Components description as device description
- Materials management and warehousing
- Component description as base for electrical, fluidic and mechanical design
- Components for simulation and virtual commissioning
- Support of Maintenance and documentation
Results
The working group Component Classification has already elaborated several results, including:
- Whitepaper – Description of AutomationML Components
- Role Class and Interface Class Library v.1.1
- Example for AutomationML Components
- AutomationML Component Checker
- AutomationML Component Editor
Description/Mission
The working group deals with the mechanical and mechatronic aspects of drive configurations. The defined model includes the definitions of load mechanisms, transmissions and loads including their parameters. Further it covers motion pattern and virtual dial gauges to described measured or calculated values between components of the power train.
Use Cases
- Motor Capacity Selection
- Power Train component selection across different vendors
- Linking mechanical to electrical aspects
Results
The Application Recommendation – Drive Configurations (M-CAD aspects) has been published.
Description/Mission
The Working Group „eCl@ss“ analyses how the product classification and description standard eCl@ss can be integrated in AutomationML
Description/Mission
The goal of the SWG Formal Desciption for AutomationML (FD4AML) is to create a way to check for the correct usage of correct library elements (4), valid hierarchy constraints (5) and additional semantic constraints (6) for ARs or BPRs. Currently these constraints are defined by natural language in PDFs. This workinggroup aims for a machine-readable interpretation and formalization as well as standardization of these constraints.
Description/Mission
The Working Group „Higher Automation Levels“ considers the usage of AutomationML on the higher levels of the autoamtion pyramid.
Description/Mission
The goal of this working group is to define a bijective mapping between a norm-conforming AutomationML file and a JSON file with semantically the same content. The mapping shall be defined in a way that using the mapping back and forth shall yield the exact same file contents as before the mapping process.
Description/Mission
The Material Handling working group deals with the needs of data exchange of layout planning, process description, simulation and visualization of material flow systems with the aim to be able to use AutomationML as a standard format for the definition of material flow related resources and processes.
For this purpose, an application recommendation as well as associated AutomationML role and interface class libraries have been developed and already published.
Results
Application Recommendation – Modelling of Materialhandling in AutomationML
This application recommendation proposes a modelling method of material handling systems, processes and transport units by means of the engineering data format AutomationML. It will describe the recommended use of role and interface classes as well as the recommended structures to be considered within the instance hierarchy of an AutomationML project.
Description/Mission
The joint working group of the AutomationML e.V. and the OPC Foundation deals since 2013 with the combination, integration, and harmonization of both standards AutomationML and OPC UA to create synergies and minimize the gap between engineering and operation.
Therefore we work on proposals how
- OPC UA relevant data can be stored in AutomationML and
- AutomationML relevant data can be transported by the OPC UA technology.
A short video about the combination of AutomationML and OPC UA can be found on Youtube.
Use Cases
One opportunity from combining AML and OPC Unified Architecture is to communicate and operationalise AML by means of OPC Unified Architecture. It is possible to simplify the creation of OPC Unified Architecture information models based on existing AML data. This is realised by an OPC Unified Architecture companion specification due to analogies between AML and the OPC Unified Architecture information model. The companion specification for AML consists of an object model including many specific semantics, which are exchanged via OPC Unified Architecture. Data management, online communication functionality, multi-user support, access methods, and security mechanism as specified by OPC Unified Architecture are used while combining AML with OPC Unified Architecture.
The second opportunity is the exchange of the OPC Unified Architecture system configuration within AML models. The manual exchange of OPC Unified Architecture server configuration data is replaced by a specified description in AML. Parameters to set up OPC Unified Architecture communication between tools are exchanged using AML. This realises consistent data, produces less errors, and results in an easier and faster configuration of OPC Unified Architecture clients.
OPC Unified Architecture benefits from the description of the communication network configuration and structure including communication system parameters, network system topology, quality of service, passive and active infrastructure elements.
Relevant use cases resulting from the combination of OPC UA and AutomationML as descripbed in DIN SPEC 16592 [DINSPEC] are:
- Use Case 1: Information lifecycle management
- Use Case 2: Up-to-date description of the system as-is
- Use Case 3: Information exchange (e.g. asset information, quality information, diagnostic data, etc.) with MES or SCADA systems for system operation
- Use Case 4: Lossless exchange of OPC Unified Architecture system configuration
- Use Case 5: Communicate/Operationalize AML by means of OPC Unified Architecture
- Use Case 6: Mixed simulation environments
- Use Case 7: Lossless storage and retrieval of system engineering information for system maintenance, repair, overhaul (MRO)
- Use Case 8: Manufacturing change management
- Use Case 9: Lossless storage and retrieval of system engineering information for manufacturing system reconfiguration
Results
- the Best Practice Recommendationn [BPR data 2017] Data Variable: It describes how to model OPC UA server configurationin AutomationML models.
- the OPC UA Companion Specification „AutomationML for OPC UA“ [AML UA 2016]: It describes rules how to transform AutomationML models into OPC UA information models. The DIN SPEC 16592 [DIN SPEC] adds additional use cases and extends the set of mapping rules. Both documents will be merged into the upcoming second edition of the OPC UA Companion Specification „AutomationML for OPC UA“.
[AML UA 2016] OPC Foundation/AutomationML e.V., Companion Specification „AutomationML for OPC UA“, https://opcfoundation.org/developer-tools/specifications-unified-architecture/opc-unified-architecture-for-automationml/, February 2016.
[BPR data 2017] AutomationML e.V., Best Practice Recommendations: DataVariable, Document Identifier: BPR DatVar, V 1.0.0, https://www.automationml.org/o.red/uploads/dateien/1494589220-BPR_007E_BPR_DataVariable_V1.0.0.zip, State: May 2017.
[DINSPEC] DIN SPEC 16592:2016-12, Combining OPC Unified Architecture and Automation Markup Language, December 2016.
Description/Mission
The AutomationML association is working in different working groups to find the best solutions for model components, layout information, electric hardware description and many more.
The SWG Toolchain & Industrialisation combines this solutions into one common data model suitable for typical industrial use cases. It also evaluates existing AutomationML interfaces of common tools.
This SWG communicates with other WGs, tool developer and the industry to mature AutomationML into a standard that can be used coherently in existing development tool chains.
The main target is to empower AutomationML to be used in industry!
Use cases
Roadmap
Description/Mission
AutomationML integrates different data formats and describes their relation to each other. It includes CAEX, COLLADA and PLCopen XML.
The working group „Architecture“ develops and maintains the AutomationML architecture as a basis for the data format and for all further applications.
Description/Mission
The working group „Communication“ intends to integrate the description of communication networks into the AutomationML data format.
Information which needs to be considered is:
- Network models
- Device descriptions
- Wiring plans
Description/Mission
The working group „Libraries“ defines role classes which are organized in role class libraries. Role class libraries which are defined in part 2 of the AutomationML specification are the AutomationML ManufacturingIndustryRoleClassLib, the AutomationML ControlSystemRoleClassLib and the AutomationML ExtendedRoleClassLib.
Furthermore, the general use of role classes and the definition of user-defined role classes are analyzed.
Description/Mission
The working group logic deals with the description of logic data in the engineering process. Therefore the working group logic specifies necessary additions for the data formats used within AutomationML (CAEX, COLLADA, PLCopen XML, also MathML) as well as the evaluation, selection and extension of further necessary formats concerning the use for PLC applications.
Information which needs to be considered is:
- Sequencing
- Behaviour
- Interlocking
- Communications
- Processes
Additionally, the working group gives attention to possibilities for checking for conformity relating to AutomationML specifications.
Description/Mission
The working group „Robotics“ is the definition of applications respectively possibly necessary additions of the AutomationML formats: CAEX, COLLADA, PLCopen XML, also MathML) concerning the use for robotic applications.
Information which needs to be considered is:
- Geometry
- Kinematics
- (Path Planning)
Additionally, the working group gives attention to possible extensions of the used data formats concerning mechanical planning information as well as sensor information.