AutomationML in a continuous products life cycle:a technical implementation of RAMI 4.0

Markus KieselFaculty of engineering

Albstadt-Sigmaringen UniversityAlbstadt, Germanykiesel@hs-albsig.de

Nicolai BeisheimFaculty of engineering

Albstadt-Sigmaringen UniversityAlbstadt, Germany

beisheim@hs-albsig.de

Abstract—The global market for manufacturing companiesis highly competitive, especially the differences between low-wage and high-wage countries lead to various market strategies.The focus of companies in high-wage countries is often on thepreservation of a technical advantage, or prime quality products[1]. The technical advantage often come from the core areas ofthe manufacturers, such as machining technologies, but currentlynew technologies are increasingly emerging from the informationtechnology sector. In Germany, this trend, which has been goingon for several years now, is summarized under the keyword“Industrie 4.0”. By setting the focus on such technologies, thereis a high chance of increasing key factors e.g. productivity orflexibility [2]. To maintain an interoperability between the, byinformation technology enhanced, systems there are currentlymultiple concepts such as the Reference Architecture ModelIndustry 4.0 (RAMI 4.0) [3] or the Industrial Internet ReferenceArchitecture (IIRA) [4]. While IIRA focuses on interdisciplinaryinteroperability, the German RAMI 4.0 is particularly suitablefor production-intensive industries. The RAMI 4.0 concept re-quires the introduction of an Asset Administration Shell foreach material and immaterial object (asset), which providesseveral functionalities such as communication or identification.The Asset Administration Shell is connected with the assetthroughout the whole product life cycle. Thus it needs to beable to save the heterogeneous data which is generated ineach step of the product life cycle. Therefore an approach isnecessary which is able to provide such a flexibility within thedata structure and also provide the functionality to communicaterange of RAMI 4.0. This contribution presents the approach of anAutomationML-based Asset Administration Shell, which is ableto handle the heterogeneous data due to the AutomationML basis,provides an RAMI 4.0 compatible communication functionalityand is extensible for further features. The implementation of theframework is platform-independent, which enables integrationin classic PLC systems (e.g. Beckhoff) as well as several IOTPlatforms (e.g. Raspberry PI).

Index Terms—component, formatting, style, styling, insert

I. INTRODUCTION

In most common development processes, the individualdepartments are separated according to their specific focus,which leads to various intersections with other departments,especially regarding information and data. Since the respectivedepartment communicates predominantly among itself as wellas with other departments of similar fields, the data formats arealso adapted to this purpose. Due to increasing digitalization,however, the boundaries between the departments are becom-ing increasingly blurred. In these area of conflict it is difficult

to maintain a persistent and complete data model throughoutthe complete product lifecycle, as the generated data is highlyheterogeneous. For this reason the use of a universal data for-mat which can contain the heterogeneous data of the individualdomains is therefore increasingly necessary in the future.One example for such a format is AutomationML. However,digitization does not only affect the departments of a companyor the cooperation between them. The machines themselvesare also increasingly changed by digitization. One exampleis the distribution of intelligence to individual assemblies inorder to achieve the most modular structure possible. Here,too, standards are an important factor, since the integrationof external modules can otherwise involve a great deal ofeffort. Several approaches are currently available to counteractthis impending problem as early as possible. One promisingapproach is the reference architecture model Industry 4.0,which, like AutomationML, enables a very flexible structure.

II. RELEVANT WORK

For a better understanding of the following explanations,some basic information is discussed in the following section.

A. Reference Architecture Model Industry 4.0

In order to give Industry 4.0 a tangible structure andto ensure the interoperability of the systems, the GermanElectrical and Electronic Manufacturers’ Association (ZVEI)developed the reference architecture model Industrie 4.0 incooperation with various industrial companies.

1) Layer model: The core of the reference model is athree-axis layer model which is depicted in figure 1. Itprovides the possibility to represent any state of an arbitrarytechnical asset within the product life cycle.

2) CP-Classification: The CP Classification is intendedto enable a simple classification of technical objects in thegrid of the reference architecture model Industry 4.0. Thematrix of the CP classification is shown in Figure 2. TheX-axis shows the communication capability and the Y-axisthe recognition in the system.

Fig. 1. Layer model of RAMI4.0 [3]

unkown

not

11

2

2

3

3

4

4

passiv

active

I4.0compliant

anonymously known

indivudell known

administrated as an entity

communication capabilites

Awarenessinthe

inform

ationsystem

Fig. 2. CP classification of RAMI4.0 [3]

3) Asset Administration Shell: In order to depict a technicalobject in the digital world, the concept of administration shellsis introduced in the reference architecture Industry 4.0. Thecombination of administration shell and technical object isreferred to as Industry 4.0 component. According to the CPclassification, which was already discussed earlier, industry4.0 components therefore correspond to a CP classification ofCP43 or CP44. In this paper, therefore, only elements of thischaracteristic are considered. The administration shell not onlymanages the data of the technical object but can also make itsown functions available. These are made available as digitalservices in accordance with the reference architecture model.An example of such a service can be the execution of a diagno-sis of the technical object by the corresponding administrationshell. For example, statements about the remaining service lifeor the next service assignment are then calculated on the basisof the data collected.

B. AutomationML

Due to the rising complexity of Industry 4.0 based produc-tion systems it is obligatory that engineering teams of differentdepartments can exchange information efficiently. One formatwhich can handle heterogeneous data is the XML based dataformat AutomationML (see e. g. [6], [7]]). It can contain muchmore information than for example a typical CAD exchangeformat like STEP or IGES. To make AutomationML easyaccessible it incorporates several standards.

The open standards, which are used by AutomationML, areshown in Figure 3. The AutomationML file itself is based on

Fig. 3. AutomationML Overview [5]

the CAEX Format (IEC 62424) which is just slightly enriched.As it is XML-based and due to the possibility to referenceother files, it is easy expandable. The present components,the hierarchical structure as well as the connection betweenthe components are described with the CAEX Format. TheCOLLADA standard provides the functionality for the repre-sentation of geometry. It is capable of saving geometry as aboundary representation (typically for CAD software) as wellas a triangulated mesh representation. Besides the geometry,COLLADA can also contain information about the kinematicsand physics of an object, as well as other geometry relatedinformation. The PLCopen XML format is also included intoAutomationML and makes it especially interesting for virtualcommissioning purposes. Since it is based on the IEC61131-3, it adds the functionality to store and transfer programminglanguages for PLCs, embedded controls and industrial PCs.

This data can be evaluated on software or hardware in theloop systems typically required for virtual commissioning.Also shown in Figure 3 is the ability to incorporate furtherformats to add special functionality to AutomationML.

III. AUTOMATIONML BASED ASSET ADMINISTRATIONSHELLS

An administration shell accompanies a technical object overthe entire duration of the product life cycle. A wide varietyof data is generated, in the design phase, for example, thisis predominantly planning data such as 3D CAD data. Assoon as the technical object is used as an instance, the typeof additional data also changes, in this case measurementdata, for example, as well as service and service life datais generated. In order to enable the persistent collection ofthis highly heterogeneous data, it is necessary to select a veryflexible system or format for the asset administration shell.

A. Implementation overview

The reference architecture model Industry 4.0 provides abasic overview of the objectives to be achieved with themodel. For the majority of the components, however, noimplementation recommendations can be derived. The authorstherefore make some assumptions in the following, whichserve as a basis for the later implementation.

• runtime environmentThe software-technical execution of the administrationshells can be very varying. On the one hand, it is possibleto centrally store the data and the runtime environmentof the administration shells in a database-orientedsystem. Depending on the choice of the database,however, restrictions can arise with regard to the typeand structure of the data. Another possibility is to embedthe administration shells decentralized, for exampledirectly on the managed technical object. As there areplausible use cases for both application scenarios, apossibility should be chosen that enables both scenariosequally.

• data repositoryAs already mentioned in the runtime environment, datacan be stored central or decentral. In particular, thechoice of the data format in which the data is madeavailable plays a central role. A proprietary data formatcan lead to integration problems with external systems,especially due to there large variance in the softwareproducts available. It is therefore advisable to choosean open standard in order not to restrict the use of anadministration shell. The chosen data format must beable to contain the already mentioned heterogeneousdata, which is generated during the product lifecycle.

• communicationThe communication capability of an administration shellis elementary and should therefore receive special at-tention. In the reference architecture model, the term,,service-oriented architecture” is used at this point. Com-munication based on such an architecture has provenitself in various software projects in recent years and istherefore also recommended here. However, the authorsare of the opinion that a further communication optionthat is closer to the machine would facilitate the inte-gration of the administration shells at the machine level.Therefore, two forms of communication are considered.

The resulting layer-like structure is shown in Figure 4.In this figure, the individual layers are already occupiedwith technologies that can fulfil the assumptions made. Afundamental consideration which has to be addressed withthe selected programming language is the compatibilitywith different execution systems. Therefor an approach wasselected which allows the execution of the code on differentplatforms such as Windows or Linux environments. ThusJava as programming language was selected, which allowsdue to the Java Virtual Machine to run the same code ondifferent platforms.

B. Java AutomationML Framework

The framework provided by AutomationML e.V. is currentlyonly available on the basis of the .Net programming languageC#. A use in Java is therefore not possible. For this reason,

Runtime LayerJava Virtual Machine

Data LayerAutomationML

Business Logic LayerFramework

Communication LayerREST, OpcUA

Fig. 4. Implementation Layer Structure

a Java-based AutomationML Framework is required for theapproach described above, which allows the effective use ofAutomationML under Java. Since this AutomationML frame-work is to be used in particular for the use in connection withthe administration shells, some additional requirements haveto be fulfilled.

• Easy integration of additional service life dataThe main task of the framework to be created is theintegration of additional data that is generated during theproduct lifecycle. It should be possible to integrate anykind of additional data into the AutomationML file.

• Complete serialization and deserializationIn order to make the data more robust against malfunc-tions and to reduce memory requirements, the data mustbe able to be both saved and loaded as AutomationMLfiles (*.aml). This requires a serialization and deserializa-tion mechanism.

• Toolkit for mathematical operations based on theFrameAttributeType attributesPositions and rotations of individual components can bestored in AutomationML as FrameAttributeType. ThisFrameAttributeType attribute contains the position androtation of an element. The rotation is held in Eulerangles, which is especially problematic for complexmathematical operations in 3d space. Therefore two newclasses are introduced for the arithmetic operations basedon the FrameAttributeType attributes.The FramePosition element contains the position portionof the FrameAttributeType attribute.The FrameRotation element contains the rotation part ofthe FrameAttributeType attribute, which is converted intoa quaternion FrameRotation In order not to violate therotation sequence defined by AutomationML e.V. (XYZ),the conversion is performed as shown in equation 1.

qx ∗ qy ∗ qz = qres (1)

The indices indicate the rotation around the individualaxes. By converting the rotations into quaternions, therequired arithmetic operations for spatial calculations arereduced and the mathematical problem of the ”gimballock” (see also [8]) is avoided. Rotating a position p0

by a given quaternion qn can then be expressed in thefollowing way.

p1 = qn ∗ p0 (2)

This system makes it easy to perform complex mathe-matical operations based on the FrameAttribute type.

• Integrated Toolkit for creating and modifyingPlcOpenXML dataIn order to enable an administration shell and thusalso the managed technical object to react adaptivelyto changed boundary conditions, it may be necessaryto adapt the PLC program used. The open standardPlcOpenXML is integrated in the AutomationMLstandard for the purpose of managing PLC programs. Inorder to simplify the modification of these programs, atoolkit is implemented which enables the semanticallyand syntactically correct modification of PlcOpenXMLdata.

C. Asset Administration Shell Framework

As shown in Figure 4, the administration shell frameworkis located between the communication layer and the data layerand represents the actual business logic. The mapping of thedata to the communication is basically possible in two differentforms.

1) Division of an AutomationML structure into individualdata elements

2) Mapping of the complete AutomationML structure as asingle data element

1 is particularly suitable for communication forms thatrequire such a granular division, e.g. machine controls. Usuallythis is necessary for runtime-variable data. Variant 2 is e.g.suitable for planning data which should be imported into asoftware and extended if necessary.

1) Machine to Machine Communication: On aspect ofindustry 4.0 is the relocation of intelligence by embeddingcontrol units into subassemblies to form independent objects.This increases the need of a standardized machine to machinecommunication. Therefor the Asset Administration Shellhas to able to communicate in this standardized way. Inthe recent past the OpcUA standard proves itself as validcompetitor for future standardized machine to machinecommunication. Thus this standard was implement in theSmart Asset Administration Shell Framework.

2) Human-Machine-Communication: As even in highly au-tomated processes the influence of an operator is necessary, theHuman-Machine-Communication has to be in a comparablequality as the machine to machine communication. To providea Human-Machine-Communication there are several optionsavailable. One typical option nowadays is to embed a displaywithin the technical system, e.g. the control panel at a toolingmachine. As this is probably the best option for machines withone single control unit, it can hardly be applied to machines

which consist of dozens of control units. Therefor the Human-Machine-Communication is realized comparably to a service-oriented architecture, to enable a user to easily interact witharbitrary control units or Asset Adminstration Shells.

IV. CONCLUSION AND FURTHER RESEARCH

The acceptance of industry 4.0 components and the refer-ence architecture model industry 4.0 will depend strongly onwhether the manufacturers of the systems find a common datatechnology basis. The combination of AutomationML and thereference architecture model industry 4.0 could represent sucha data technical basis and thus contribute to the improvedinteroperability of these systems. In order to confirm thisassumption, however, further research is necessary in thefuture.

REFERENCES

[1] G. Schuh, Ed., ,,Excellence in Production: Festschrift fur Walter Ever-sheim.” Aachen: Apprimus-Verl., 2007.

[2] M. Brettel, M. Klein, and N. Friederichsen, ,,The Relevance of Man-ufacturing Flexibility in the Context of Industrie 4.0”, Procedia CIRP,vol. 41, pp. 105–110, 2016.

[3] ,,Referenzarchitektur Industrie 4.0” (RAMI4.0), 91345, 2016.[4] S.-W. Lin et al., ,,The Industrial Internet of Things Volume G1: Ref-

erence Architecture.” [Online] Available: https://www.iiconsortium.org/IIC PUB G1 V1.80 2017-01-31.pdf.

[5] AutomationML e.V., ”AutomationML data representation,” [Online].Available: http://automationml.org/. [Accessed 18 10 2016].

[6] R. Draht, A. Luder, J. Peschke and L. Hundt, AutomationML - the gluefor seamless automation engineering, IEEE International Conference onEmerging Technologies and Factory Automation, 2008.

[7] A. Luder, L. Hundt and A. Keibel, Description of manufacturingprocesses using AutomationML, IEEE Conference on Emerging

[8] E. Hemingway, O. Reilly, ,,Perspectives on Euler Angle Singular-ities, Gimbal Lock, and the Orthogonality of Applied Forces andApplied Moments”, [Online] Available: http://dynamics.berkeley.edu/assets/Gimbal-Lock-Final.pdf [Accessed 11 09 2018].