ios press automationml ontology: modeling cyber-physical ... · undeﬁned 1 (2009) 1–5 1 ios...

Undefined 1 (2009) 1–5 1IOS Press

AutomationML Ontology: ModelingCyber-Physical Systems for Industry 4.0Olga Kovalenko a Irlán Grangel-González b Marta Sabou a Arndt Lüder d Stefan Biffl a Sören Auer c

Maria-Esther Vidal ca Vienna University of Technology e-mail: {firstname.lastname}@tuwien.ac.atb University of Bonn and Fraunhofer IAIS e-mail: {[email protected]}c German National Library of Science and Technology e-mail: {soeren.auer|maria.vidal}@tib.eud Otto-von-Guericke-University Magdeburg, Institute of Ergonomics, Manufacturing Systems and Automation IAFe-mail: {arndt.lueder}@ovgu.de

Abstract. We present an AutomationML ontology (AMLO)that covers the CAEX part of the AutomationML standard.The AutomationML data format facilitates the engineeringdata exchange during industrial systems design. Having a se-mantic representation of the AutomationML standard allowsindustrial practitioners to interlink and integrate heteroge-neous data more efficiently and to benefit from the Seman-tic Web tools and technology stack, while at the same time,using a familiar domain-specific conceptualization. Com-pared to earlier efforts for semantically representing Au-tomationML, AMLO (a) covers the entire CAEX standard,and not just portions relevant for a use case; (b) has beendeveloped following best practices for ontology engineer-ing; and (c) is made openly available for the community byfollowing latest guidelines on resource sharing and publish-ing. We describe AMLO and demonstrate its use in real-life scenarios for improving engineering processes in Cyber-Physical System design.

Keywords: AutomationML, industrial automation, OntologyEngineering, ontology design patterns, Industry 4.0

1. Introduction

The vision of smart manufacturing is currently sup-ported and investigated as part of various initiativesworldwide, including Germany’s Industrie 4.0 ap-proach [3], the “Factory of the Future” initiative inFrance and the UK [30] and the “Industrial Inter-net Consortium”1 in the USA. Core to these initia-tives is enabling more flexible and efficient indus-

1http://www.iiconsortium.org

trial production through a higher degree of digitiza-tion of the entire manufacturing value-chain. In par-ticular, plants and factories (more generically referredto as production systems) will benefit from this digi-tization to evolve into cyber-physical production sys-tems (CPPS). CPSS combine physical sensing withcyber-elements (i.e., software-based control) to moretimely and accurately influence their behavior. Theyare complex mechatronic systems as, in their realiza-tion, they require input from several engineering dis-ciplines, such as mechanical, electric and software en-gineering. To respond to fast-changing market needs,the design and engineering of CPPS needs to be fasterwhile leading to results that are of high quality andcomplexity.

During the engineering of complex mechatronicsystems such as CPPS, stakeholders typically belong-ing to different engineering disciplines, have to collab-orate efficiently in order to deliver a high-quality endproduct (e.g., a complete production plant design) andto satisfy strict time frames. The presence of variousengineering disciplines leads to a highly complex andsoftware intensive environment, which is characterizedby a) a multitude of engineering tools that were not de-signed to cooperate with each other; b) a variety of en-gineering domain-specific representations and data ex-change formats applied; and c) differences in adoptedworkflows across the involved disciplines. Therefore, akey challenge for realizing CPPS relies on solving dataintegration challenges among the various systems, or-ganizations and stakeholders involved in the engineer-ing and operation of CPPS both across engineering do-

0000-0000/09/$00.00 c© 2009 – IOS Press and the authors. All rights reserved

2 O. Kovalenko et al. /

main boundaries (horizontal integration) and betweendifferent abstraction levels (business, engineering, op-eration) of the system (vertical integration) [5].

An approach for addressing data integration duringthe engineering of complex systems is the automationmarkup language AutomationML [18], the emergingIEC 62714 standard for facilitating uniform data ex-change between engineering tools. AutomationML isan open (specification and schema are available), neu-tral (manufacturer independent without proprietary in-terfaces or libraries) and XML-based data exchangeformat that aims to ensure consistent and lossless dataexchange during manufacturing systems design. Au-tomationML enjoys intense industry interest and adop-tion, yet, as an XML-based standard lacks a formal se-mantic basis that is increasingly necessary in industrialprojects [23,25].

In fact, the use of knowledge-based approaches ingeneral, and semantic technologies in particular, isa growing trend in the area of CPPS engineering.This development materializes in a number of ap-proaches [19,33] that benefit from the following char-acteristics of semantic and knowledge representationtechnologies:

– formal and flexible semantic modeling with on-tologies;

– intelligent, web-scale knowledge integration thanksto linked data mechanisms and ontology align-ment techniques;

– browsing and exploration of distributed data sets;– querying and reasoning based data validation and

consistency checking; and– knowledge reuse across diverse projects [32,34].

Our work aims to realize these benefits and supporta wide-scale adoption of semantic technologies inAutomationML-enabled CPPS engineering by provid-ing a comprehensive ontology based representation ofthe standard.

An ontology-based representation of the Automa-tionML standard enables the following improvements:

– flexible schema refinement and heterogeneousdata linking and integration;

– using the semantic technology stack to enhancethe engineering processes in CPPS engineering;

– connecting to other industrial standards that al-ready have semantic representation, e.g., eCl@sscatalog [9] or the GoodRelations [16] ontologythrough ontology reuse or linked data mecha-nisms; and

– connecting to representations from other do-mains, e.g., eCore in Model-Driven engineering.

Several approaches already aimed to provide a se-mantic representation of AutomationML [1,6,12,17,21,26], as detailed in Section 6. However, these effortshave the following shortcomings:

1. they are not covering the complete standard andare not tailored for specific use cases;

2. they are not developed according to best practicesfor ontology design; and

3. they are not openly available for consultation, ex-tension or improving current design.

The AutomationML Ontology (AMLO) described inthis paper advances the state of the art by address-ing the issues above as follows. Firstly, AMLO isan OWL ontology that covers the entire emergingdata exchange standard in the CPPS engineering field.Secondly, we followed several ontology engineeringbest practices during the design of AMLO, such asadopting the Uschold and King ontology engineeringmethodology [37]. We took as input two ontologies,developed independently of each other as initial ef-forts to cover the AutomationML standard for spe-cific applications. The first one was created using atop-down modeling approach [22], with the focus oncapturing the major concepts (i.e. classes and rela-tions between them) and with the goal of enabling con-sistency checking between different AutomationMLfiles. However, the property coverage was not suffi-cient to match the AutomationML XSD schema speci-fication, especially for data properties. The second on-tology was developed as a part of the Alligator ap-proach [13] following a bottom-up modeling approachand had a well elaborated property structure, but waslimited w.r.t. a class hierarchy. Combining both on-tologies allowed for better class and property cover-age w.r.t. the AutomationML XSD schema as well asfor the AutomationML standard specification. Thirdly,AMLO is openly available due to following best prac-tices for ontology sharing and publishing, in particu-lar those described in [14]. As a result, AMLO cov-ers 21 classes, 51 object properties and 48 data prop-erties, and is aligned with three well-known vocabu-laries, i.e., Provenance ontology, ontology of Units ofMeasure, and skos vocabulary.

The reminder of this article is structured as follows.Section 2 introduces the AutomationML standard, ex-plains its main constructs, and, additionally, presentsan example on how a compound device can be mod-

O. Kovalenko et al. / 3

eled in AutomationML. Section 3 describes the usedmethodology for ontology design, depicts the designprocess in detail, and also explains major design de-cisions taken. Section 4 gives an overview of AMLOstructure, main classes and properties and importantimplementation details, i.e., ontology design patternsrelevant in the ontology context, alignment to exist-ing vocabularies and following best practices for shar-ing and reusability. Section 5 showcases two applica-tion examples for the AMLO. Section 6 presents therelated work and positions the AMLO in the context ofother semantic representations in automation engineer-ing. Finally, Section 7 concludes and gives an overviewof directions for future work.

2. AutomationML and Engineering Design

The AutomationML standard[18] enables modelingsystems from single automation components to entirelarge and complex production systems and supportsrepresentation of the various aspects of such systems,i.e., system’s topology, geometry, kinematics, and con-trol behavior [8]. AutomationML is currently well rec-ognized by major manufacturing companies such asDaimler, Audi and Siemens and continues gaining ac-ceptance from the manufacturing market players.

AutomationML is not a completely new format, butrather consists of existing formats, which were ex-tended, adapted, and combined appropriately. It al-lows modeling manufacturing system data sequen-tially, i.e., starting from the plant structure design,and then adding the geometry and kinematics infor-mation up to process sequences and logical depen-dencies following the sequence of engineering dis-ciplines involved in the engineering chain. The toplevel of AutomationML is represented in terms of theComputer Aided Engineering Exchange (CAEX, IEC62424) format for plant topology, which is used forstoring hierarchical object information, properties, andlibraries [10]. The geometry (mechanical drawings)and kinematics (physical properties such as force,speed, or torsion) are implemented with the COLLAb-orative Design Activity (COLLADA) format [2]. Fur-ther, the logic, i.e., sequencing, behavior, and controlinformation is implemented with PLCopen XML (IEC61131).

In this article, we focus on modeling topology infor-mation by means of the CAEX format. AutomationMLis based on the following CAEX concepts:

RoleClassLibrary contains a collection of possiblefunctionalities that can be provided by the plant equip-ment. A role class (RC) defines a physical or a logi-cal object as an abstraction of a concrete technical re-alization, which is vendor independent, e.g., a robot ora sensor. This way a functional semantics is assignedto an object, enabling an automatic interpretation bya tool. RCs can also define attributes that are gener-ally expected for this object type, e.g., a payload for arobot RC. Additionally, RCs can be assigned to objectswithin the SystemUnitClassLibrary and InstanceHier-archy to specify an object type.

SystemUnitClassLibrary comprises collections ofvendor specific solution equipment objects. Those ob-jects can be matched with the system requirements,defined by the role classes, and used to implementthe plant design. A system unit class (SUC) defines aconcrete technical realization of a physical or logicalobject, thus representing a specific instantiation for aRC. System unit classes are instantiated within the In-stanceHierachy.

InterfaceClassLibrary defines all interfaces re-quired to describe the plant model. An interface class(IC) can be used either a) for specifying relations be-tween objects of a plant topology, e.g., to connect asensor with a programmable logic controller (PLC);or b) for specifying references to information that isstored outside of the CAEX file, e.g., to assign a 3Ddescription to an object.

InstanceHierarchy describes the plant topology,including the concrete equipment of an actual project- the instance data. The instance hierarchy contains alldata including properties, interfaces, role classes, rela-tions, as well as references.

Applying AutomationML in engineering projects isalready an important improvement, as it facilitates dataexchange between the project stakeholders and de-fines a project-specific vocabulary to which all engi-neers can relate. Nevertheless, there is still a lack ofinfrastructure for supporting advanced engineering ac-tivities across the various engineering disciplines andtheir corresponding tools, e.g., data linking, changepropagation across connected datasets, data analysisand consistency checking. Having an ontology for Au-tomationML will help to address these gaps.

2.1. An AutomationML Modeling Example

To illustrate how a CPSS is represented in Automa-tionML, we developed an example using the Automa-


(a) RoleClassLibrary (b) SystemUnitClassLibrary (c) InterfaceClassLibrary

Fig. 1. Sample AutomationML modeling example. Conveyor consisting of a frame, a band, an inductive sensor and a motor. (a) SampleRole-ClassLib contains role classes that define vendor independent functionalities for the conveyor. (b) SampleSystemUnitClassLib lists vendor spe-cific device realizations options for the sample conveyor. (c) SampleInterfaceClassLib comprises Interface classes for the conveyor.

tionML Editor 4.7.0.2, which allows browsing and de-veloping AutomationML files. The example systemmodels a conveyor that consists of a frame, a band, aninductive sensor and a motor.

The RoleClassLibrary contains classes to repre-sent the basic functionalities for the system com-ponents, in our case Motor, InductiveSensor, Bandand Frame. The Frame and Motor extend the basicclass MechatronicAssembly that is defined within Au-tomationMLBaseRoleClassLib. Different types of sen-sors are represented by the RCs MagneticSensor andInductiveSensor, all of which are derived from themore general Sensor RC (cf. Figure 1a). The roleclasses are vendor independent and do not compriseimplementation-specific details, e.g., a role class Mo-tor means "something that can fulfill motor function".

The SystemUnitClassLibrary contains componentrealizations that can be used to implement the func-tionalities, defined by RCs in a real system. SUCs arevendor specific, e.g., Motor_TypeA represents a spe-cific device with the motor functionality produced byManufacturer1 (cf. Figure 1b). RCs are assigned toSUCs to specify the functionalities that a specific de-vice can fulfill. E.g., Sensor_TypeA has the RC Sensorassigned, meaning that it can be used to implement thefunctionality defined by Sensor RC.

The InterfaceClassLibrary contains interface classesrepresenting various relations between the systemcomponents. These relations can be of different nature:mechanical ones, e.g., Bolting and Gearing; electrical,e.g., PowerConnectionPlug and PowerSupplySocket;

2https://www.automationml.org/o.red.c/dateien.html

of software and control related, e.g., SignalInterface(cf. Figure 1c).

Additionally, attributes are specified for the SUCsproviding further details for the specific devices.For example, ConveyorBand_TypeB has the attributesWeight, Material, MaxPayload and MaxSpeed defined.For each attribute a description, a measurement unit, adata type and value can be specified. For example, onecan see that the ConveyorBand_TypeB has the maxi-mum payload of two kilograms (cf. Figure 2).

Fig. 2. MaxPayload Attribute of the ConveyorBand Conveyor-Band_TypeB Values of the MaxPayload attribute of the Convey-orBand_TypeB in the sample system, i.e., Unit, AttributeDataTypeand actual Value of the Attribute are shown. Other attributes of thesystem such as Material, Weight and MaxSpeed are also depicted.

Finally, the InstanceHierarchy contains the designof the real-life system - the conveyor consisting ofa band myConveyorBand, a motor myMotor to movethe band, a frame myConveyorFrame, and an induc-


tive sensor myInductiveSensor to identify positioningof the object on the band (cf. Figure 3).

Fig. 3. Instance hierarchy classes for the sample system. myCon-veyor is defined via four IEs: myConveyorBand, myMotor, myCon-veyorFrame, myInductiveSensor, each representing a specific devicefor the conveyor design.

3. Ontology Design: Methodology and ModelingDecisions

In this section, we describe the modeling processfor the AutomationML Ontology (AMLO). Section 3.1presents the design methodology and explains the on-tology engineering process in detail. Section 3.2 de-scribes major design alternatives and design choicesmade for the AMLO.

3.1. Methodology

The AMLO was designed following the "Process-based design" methodology of Uschold and King [37].As the main purpose for ontology creation we formu-lated the following points:

– AMLO should be maximally compatible with theAutomationML XSD schema and the Automa-tionML standard;

– The vocabulary used by AMLO should be asclose as possible to the terminology in the stan-dard, to allow an intuitive understanding of theontology by users from industry who are famil-iar with the standard, but not with Semantic Webtechnologies.

– To facilitate ontology reuse by other parties,AMLO should be easy to find, access and reuse.

As a starting point for ontology development we re-lied on two ontologies, initially designed with the in-

tention to provide semantic representation for the Au-tomationML standard for specific applications.

The first ontology was built at TU Vienna using top-down modeling approach [21]. The result was a light-weight ontology capturing the major design decisionsin terms of classes and relations between Automa-tionML elements. The intended application was con-sistency checking between different AutomationMLfiles in multidisciplinary engineering projects. How-ever, property coverage was weakly elaborated and didnot completely cover the AutomationML XSD schemaspecification, particularly for data properties.

The second ontology was built following the bottom-up modeling approach as part of the Alligator projectat the University of Bonn [13]. The intended appli-cation was the automatic semantic integration of Au-tomationML documents. This ontology had a wellelaborated data property structure, but a less developedhierarchy for classes and relations.

The conceptualization phase of AMLO was there-fore accomplished by combining both ontologies andrefining the conflicting concepts, where necessary.This allowed for better class and property coveragew.r.t. the AutomationML XSD schema and the Au-tomationML standard specification.

While working on the AMLO we put especial em-phasis on following the best practices for ontology de-sign [27,29]. Namely, we make use of Ontology De-sign Patterns (see Section 4.2), reuse constructs fromthe already existing semantic sources (see Section 4.3)and ensure that the ontology is fully available and doc-umented (see Section 4.4).

With the goal of validating the ontology resultingfrom the previous steps we applied the following ap-proach. First, we performed two iterations of struc-ture validation with domain experts. For this we askedthe support of colleagues in the Otto-von-GuerickeUniversity (Magdeburg), who are actively involvedin the development of the AutomationML standardand are, therefore, deeply familiar with the semanticsof the AutomationML constructs. Second, we man-ually implemented several AutomationML data sam-ples, provided on the official AutomationML web-site3

by means of the AMLO. This guaranteed that variousmodeling situations supported by the standard can beindeed described by means of AMLO.

3https://www.automationml.org/


3.2. Design Decisions

(D1) Flexibility of the standardIn order to support a wide adoption among indus-

trial practitioners, the standard creators intentionallyavoided including too many constraints in the Automa-tionML standard specification level. For instance, thegeneral design approach in AutomationML assumesthat one first defines the functional capabilities for afuture system using role classes (RCs) and then one se-lects and assigns suitable system unit classes (SUCs),which will be a concrete realization of those capabili-ties defined via RCs. However, it is also possible (andwill not be an error) if one defines a system directlyusing the SUC libraries. This way the tool vendors thattypically would have elaborated SUC structures, butonly limited (if any) hierarchies of general functional-ities, could use AutomationML without having to sig-nificantly adjust their workflows.

With the aim to support the flexibility of the Au-tomationML standard in the designed ontology, we de-cided to keep the amount of predefined restrictions toa minimum. This way, modeling with the AMLO willhave the same flexibility as when using the Automa-tionML standard.

(D2) Modeling hierarchies of ICs, RCs and SUCsThere were three major options to model the hier-

archies of interface classes (ICs), RCs and SUCs inAMLO.

First, one can build class hierarchies to capture hi-erarchical relations between the elements of IC-, RC-and SUC- libraries in AutomationML. For example,MagneticSensor and InductiveSensor are both sub-classes of Sensor, which is a subclass of a RoleClass.Instances of InductiveSensor describe specific roles as-signed to a certain device (represented via instance ofan InternalElement class). For example, InductiveSen-sor role assigned to a specific device myInductiveSen-sor in the instance hierarchy (see modeling example inSection 2.1).

Secondly, all roles can be modeled as instances ofthe RC concept. In this case, the further hierarchicalrelations between the individual roles should be mod-eled via additional constructs in the ontology, whichwould relate the RC instances to each other.

The third option consists in capturing different rolesvia relations, e.g., hasSensor that would connect in-stances of InternalElement (corresponding to specificdevices) to instances of RoleClass. The hierarchical re-lations between the roles are then modeled using thesubproperty mechanism, e.g., hasMagneticSensor and

hasCurrentSensor being subproperties of hasSensor.These three possibilities for modeling the same seman-tics are compatible, i.e., rules can be defined to auto-matically transform one into another [31].

Inspired by the experiences in building the Ontol-ogy of Units of Measure [31] we opted for the first ap-proach for modeling the IC, RC, and SUC hierarchi-cal relations in AMLO. We also found this approachthe most intuitive in terms of similarity to the Automa-tionML representation.

(D3) Splitting up multiple-use properties withrdfs:subPropertyOf

There are some relations in AutomationML thatcapture the same semantics, but for different objecttypes. For example, an AutomationML file can containall four AutomationML main object collections: In-stanceHierarchy, InterfaceClassLib, RoleClassLib andSystemUnitClassLib. In this case, the contains prop-erty holds the same semantics for all four constructs,meaning ‘having this structure within the file’. There-fore, the straight-forward way of modeling this sce-nario would be simply defining contains Object prop-erty that would relate instances of a CAEXFile to theinstances of RoleClassLib, SystemUnitClassLib, Inter-faceClassLib, and InstanceHierarchy. However, thiscan potentially cause problems during reasoning andinference tasks, because of the Open Word Assump-tion logic implied by reasoners. To tackle this prob-lem, we decided to model such relations in the fol-lowing way: a) a super property is defined capturingthe general relation semantics and does not explicitlyspecify a certain class for its range. E.g., the domainof the contains property is the CAEXFile, but nothingis specified for the range; b) subproperties are definedto describe each specific case for the property range,e.g., hasRoleClassLib, hasSystemUnitClassLib, hasIn-terfaceClassLib, and hasInstanceHierarchy are sub-properties of contains.

This approach allows using a less complex vocab-ulary for the applications where only querying is im-portant. That is, one can define all the relations usingthe general contains Object property without havingto learn the property name for each specific case. Atthe same time, if the intended application involves rea-soning or inference one can use more elaborated anddetailed vocabulary (i.e., subproperty labels) to avoidpotential conflicts.

(D4) TerminologyWe stayed as close as possible to the labels used in

the AutomationML standard while choosing terms fornaming classes and properties in AMLO. The main in-


tention is to facilitate the understanding of the ontol-ogy constructs and their semantics for users that arealready familiar with the AutomationML standard, butmight not possess deep knowledge of Semantic Webtechnologies.

(D5) Linking to eCl@ss and domain-specificstandards

An important feature of AutomationML is the abil-ity to link to eCl@ss4 - the standardized catalogue fordescribing products and services. In AutomationML,semantics of RCs and Attributes can be specified bylinking them to corresponding eCl@ss definitions.Namely, Attributes are semantically equivalent if theyshare the same value for the refSemantic attribute;and RCs are semantically equivalent whenever theyshare the same eCl@ss references for the Automa-tionML attributes eClassVersion, eClassClassification,and eClassIRDI [35].

AMLO also supports linking to the eCl@ss stan-dard via the class ExternalStandard and object prop-erty hasRefSemantic, which has ExternalStandard asits range. Following the strategy explained in (D3) twosubproperties of the hasRefSemantic are further de-fined, with RoleClass and Attribute as a domain andExternalStandard as a range.

Thanks to the general nature of this linking mecha-nism, one can also link to other domain specific stan-dards. To this end a corresponding instance of theclass ExternalStandard should be created. Linking isthen done in a similar way as described above for theeCl@ss standard.

4. Ontology Development

In this section we discuss the development aspectsof AMLO. Firstly, Section 4.1 gives an overview onontology structure and major classes and properties.Secondly, Section 4.2 discusses what are the relevantontology design patterns (ODPs) in the context of Au-tomationML and how they are reflected in AMLO.Next, Section 4.3 describes the existing vocabulariesthat have been reused in AMLO. Finally, Section 4.4documents our efforts to ensure that AMLO followsbest practices for ontology sharing and publishing. Asummary of the main ontology details is provided inTable 1.

4eCl@ss standard: https://www.eclass.eu/en/standard

4.1. Ontology Overview

By considering the aforementioned design deci-sions, we modeled AMLO with focus on the mainAutomationML elements. AMLO covers all the ma-jor constructs of the CAEX XSD schema, with oneexception for the family types for RCs, SUCs andICs, i.e., RoleFamilyType, SystemUnitFamilyType andInterfaceFamilyType. Those are XML related struc-tural concepts that are needed in XML to specify theparent-child hierarchical relations. Since OWL pro-vides means to model such relations explicitly therewas no need to keep those construct in the ontology.Figure 4 shows the main entities of the ontology.

CAEXFile represents the AutomationML docu-ment and is the core element of the ontology. To de-scribe the metadata related to the document, the classAdditionalInformation was connected to the CAEXFileclass. It comprises data about the version, writer iden-tification, name, release, vendor as well as the projectto which the document belongs.

Container classes InterfaceClassLib, RoleClassLib,SystemUnitClassLib and InstanceHierarchy are con-tainer concepts, i.e., classes grouping other classes.These classes describe containers for InterfaceClass,RoleClass, SystemUnitClass and InternalElement re-spectively and are linked to the CAEXFile class viacontains property.

RoleClass represents the AutomationML role classconcept and defines a vendor independent functional-ity that can be provided by equipment elements. Role-Classes are used to assign generic functional semanticsto instances of InternalElement and SystemUnitClass,i.e., to describe the functional capabilities of equip-ment elements. This is done via properties hasSupport-edRoleClass and hasRoleRequirements.

SystemUnitClass represents the AutomationMLsystem unit class concept and defines a vendor-specifictechnical realization of a physical or logical object. In-stances of the SystemUnitClass can contain (or be apart of) other system unit classes. This is defined viaproperties hasPart and isPartOf respectively.

InterfaceClass represents the interface class con-cept in the AutomationML and in general is used tospecify either a) relations between the different topol-ogy elements; or b) references to various externalinformation sources. Interfaces can be linked to theinstances of RoleClass, SystemUnitClass and Inter-nalElement via the hasInterface property. ExternalIn-terface is a subclass of InterfaceClass.


Table 1AMLO Ontology details.

General Name: AutomationML Ontology (AMLO)Size 21 classes, 51 object properties, 46 data propertiesDL Expressivity ALHIF+(D)

Availability PersistentURI https://w3id.org/i40/aml

GitHub https://github.com/i40-Tools/AutomationMLOntology

Licence Creative CommonsReusability VoCol Instance http://vocol.iais.fraunhofer.de/aml/

Technical Ont. Eng. Methodology King and Uschold [37]Quality Reused Ontologies PROV-O, Units of Measure

Reused ODPs transitive PartOf ODPDocumentation By means of skos:definition, skos:altLabel, skos:prefLabel

InternalElement represents the InternalElementconcept in the AutomationML and defines concreteequipment of an actual project, i.e., devices used ina concrete plant. Similar to the SystemUnitClass, In-ternalElements can contain (and be part of) other In-ternalElements. This is defined via properties hasPartand isPartOf. One can additionally define what Syste-mUnitClass is instantiated by a specific InternalEle-ment via the hasBaseSystemUnitClass property.

Attribute expresses the actual properties of CPPSsuch as length, size, temperature, speed, etc. Attributescan be defined for the instances of RoleClass, Inter-faceClass, SystemUnitClass via the hasAttribute prop-erty. Classes om:Measure and om:Unit_of_measureare imported from the Ontology of Units of Measure-ment to formally define the units of measure for at-tributes.

InternalLink is an interesting element of Automa-tionML that represents a directed connection betweentwo constructs. Each InternalLink references two Ex-ternalInterfaces and two constructional elements, i.e.,either InternalElements or SystemUnitClasses, de-pending on which level of abstraction a given connec-tion is specified. This is done via properties hasRef-erencePartnerSide(A/B)_Interface to link to the Exter-nalInterfaces, and via properties hasReferencePartner-Side(A/B)_Object to link to InternalElements and Sys-temUnitClasss. The direction is important here, i.e.,"from A to B".

4.2. Ontology Design Patterns

Ontology design patterns (ODPs) are reusable mod-eling building blocks providing solutions to recurrentdomain modeling problems [11]. ODPs are an impor-tant means to improve the quality of an ontology de-sign as they represent best practices in ontology mod-eling frequently used by ontology developers.

Sabou et al. distinguished three major groups of pat-terns that are important in the engineering context: a)part-whole relations; b) connections between compo-nents; and c) component roles [34]. We hereby discussthese groups of patterns and how they were applied tosupport our modeling.

Part-whole relations are important for modelingcontainment hierarchies. In AMLO we decided to usethe transitive version of partOf relation that corre-sponds to the PartOf ODP5. We selected this optionfor part-whole relation, because in the context of en-gineering system design a potentially important appli-cation is recursively getting all parts and their sub-parts for a specific object. We did not use the Com-ponency ODP6 (nontransitive version of part-whole)or the TimeIndexedPartOf ODP7 (part-whole relationholding only for a specific time interval) in AMLO,since there are no relations with similar semantics inthe AutomationML standard.

Another pattern, which is often discussed in the con-text of part-whole relations, and is also relevant inthe AutomationML context is modeling constituency.Constituency refers to relations without a clear part-of relationship. Typical example is representing a ma-terial from which an object is made, e.g., several typesof wood constitute a table. There is a special ODP de-fined for modeling constituency - Constituency ODP8.In the context of AutomationML, constituency is typ-ically represented by an attribute hasMaterial or sim-ilar defined for SUCs or IEs. Since the attribute hier-archy is not intended to be stable, but rather can varyfrom one AutomationML file to another, we decidedto model this aspect as follows: a) an object propertyhasConstituent is included in the ontology; b) after

5 http://ontologydesignpatterns.org/wiki/Submissions:PartOf6http://ontologydesignpatterns.org/wiki/Submissions:Componency7 http://ontologydesignpatterns.org/wiki/Submissions:TimeIndexedPartOf8 http://ontologydesignpatterns.org/wiki/Submissions:Constituency

https://w3id.org/i40/aml

https://github.com/i40-Tools/AutomationMLOntology

http://vocol.iais.fraunhofer.de/aml/


Fig. 4. Core classes and properties of the AMLO Core AML concepts are represented in AMLO. Classes and relations of the Ontology aredepicted in blue. White classes represent reused classes from important ontologies such as PROV and OM.

a specific AutomationML file is transformed into theAMLO, and, therefore, a certain property hierarchy isformed under the hasAttribute property, one can alignthe specific attribute, e.g., hasMaterial with the has-Constituent, specifying that these two have similar orthe same semantics.

Connections between system components representinteractions between its parts, such as flows of energy,matter or signals [36]. In AutomationML connectionsare modeled via ICs, which allow specifying connec-tion elements (between which the connection is es-tablished), direction, and connection type (e.g., signaltransfer for control variables or different kinds of me-chanical linking between the hardware elements). ICsas they are modeled in the AutomationML allow for adetailed and flexible definition of various connectionsin an engineering system. Therefore, we decided notto use additional ODPs in the ontology for modelingconnections.

Component roles represent functionality and be-havior associated with a component in a system [34].In AutomationML such information is represented viaRCs. A RC is specified for an IE or SUC to definewhat kind of functionality in a system this componenthas. Hence, we did not use any additional ODPs tomodel these kind of relations, since they can be mod-eled directly by means of AutomationML constructsthat AMLO derives from the standard.

4.3. Reusing Existing Ontologies

Reusing existing and recognized ontologies is con-sidered a good practice for ontology building [24,28]9.There is a rich variety of data sources in semantic for-mats available for the engineering domain, which canbe potentially used to improve the quality of engineer-

9https://www.w3.org/TR/ld-bp/#VOCABULARIES


ing data and allows more comprehensive analyses. Ex-amples are ontologies that cover engineering and re-lated topics, or domain-specific sources, e.g., productcatalogues like eCl@ss [9]. Once having the seman-tic representation of the original AutomationML data,existing semantic data sources can be used to enrichoriginal data structures with additional information.

Even though AutomationML comprises very spe-cific concepts and relations, we have reused some well-known ontologies such as the skos vocabulary, the on-tology of Unit of Measure [31], as well as the Prove-nance ontology (PROV-O)10.

The Provenance ontology is used to represent the in-formation about a tool that has generated the given Au-tomationML documents. The skos vocabulary is usedto encode additional information about concepts andproperty related to documenting, e.g., definitions forAMLO constructs or alternative labels. The Ontologyof Units of Measure (OM) is used to bring formalsemantics for encoding units or measurement, whichare originally represented as strings in AutomationML.Since the problem of the disambiguation of units ofmeasure is very common and relevant for the engineer-ing domain, we will focus on it in more detail. Belowwe show how OM can be exploited in AMLO to se-mantically decsribe units of measurement.

In CPPS environments, units of measurement areof crucial importance for the correct functioning andcoordination of the associated processes. They are re-quired for the specification of products as well as forrepresenting the data produced by measuring devices.Commonly, data related to units of measurement arecodified as simple strings, thus, losing the semanticsassociated with them. The Ontology of Units of Mea-surements (OM) has been proposed to bring semanticsto this domain [31]. The OM ontology provides a com-plete and comprehensive set of units of measurement.

In AutomationML, attributes are used to expressproperties of different objects. For instance, let’s con-sider the motor from the sample conveyor system pre-sented in the Section 2.1. An important attribute of amotor is a rotational speed, which can be measuredboth in radians per second and in revolutions per sec-ond. If represented informally as a string, both of thoseunits can be expressed as "r/s". Listing 1 depicts a frag-ment of an AutomationML document showing an at-tribute setting the rotational speed of the motor. Theintended meaning of "r/s" in this case is radians per

10https://www.w3.org/TR/prov-o/

second, but could be also interpreted as revolutionsper second. This example demonstrates the importanceof semantically representing units of measurement toavoid ambiguity as well as to express the correct se-mantics of the attribute.

1 <Attribute Name="RotationalSpeed" Unit="r/s"AttributeDataType="xs:float">

2 <Value>16.6</Value>3 </Attribute>

Listing 1:Fragment of the RotationalSpeed attribute ofthe motor myMotor. A fragment of the attributeRotationalSpeed encoded in the AML standardrepresenting the Unit, the AttributeDataType as wellas the value.

As a solution, Listing 2 depicts an example whereAML and OM were used together to describe units ofmeasure.

1 prefix om:<http://www.wurvoc.org/vocabularies/om-1.8/> .2 prefix aml:<https://w3id.org/i40/aml/> .34 aml:SpeedAttribute a aml:Attribute,5 aml:hasNameAttribute "RotationalSpeed"@en,6 om:value aml:spMeasurement;7 aml:RotationalSpeed a om:Rotational_speed,8 om:phenomenon aml:SpeedAttribute;9 aml:spMeasurement a om:Measure,

10 om:unit om:radian_per_second-time,11 om:numerical_value 16.6.

Listing 2: Representing units using the OMontology. Representing the unit of measure of theRotationalSpeed attribute, i.e., radians per secondby combining AML and OM ontologies.

4.4. Following Best Practices for Ontology Sharingand Reusability

While designing AMLO, we followed the guide-lines for ontology sharing and reuse created for theISWC2016 Resources Track [14]. The major focushere was on performing all necessary steps to en-sure high-quality documentation and availability of theontology for other interested parties, thus, facilitat-ing ontology reuse. There are three big parts in theguidelines: 1) steps related to reusability (denoted with"R.x"); 2) steps related to availability (denoted with"A.x") of the ontology; and 3) design and technicalquality (denoted with "DTQ.x"). Below we describehow we followed those steps for AMLO.

(R.1) How easy it is to (re)use the ontology (e.g.,is there documentation or tutorials available?). There


is a detailed description of AMLO structure avail-able at https://w3id.org/i40/aml. In addi-tion, the documentation regarding the ontology is pub-licly available via a VoCol instance11. VoCol is a plat-form to support the collaborative development processof ontologies based on version control systems, git andgithub in this case [15]. After every push to the githubrepository, VoCol automatically provides features suchas documentation generation, evolution of changes, vi-sualization, ontology validation, etc.

(R.2) Possibility to apply in a wide set of scenarios.We did not make application specific design decisionsduring the AMLO development. The major goal was tofully cover the standard while preserving its flexibilityin the ontology. Therefore, AMLO can be used in awide range of scenarios.

(R.3) Potential for extensibility. AMLO can bealigned to other standards using the ExternalStandardclass and the object property hasRefSemantic.

(A.1) Publishing at a persistent URI. AMLO is pub-lished at the w3id12.

(A.2) License specification. AMLO has the CreativeCommons license.

(A.3) Is the resource publicly available / findable?The source code for the AMLO as well as its evolutiontrack is publicly available on GitHub13.

(DTQ.1) Following best practices for ontology de-sign. We followed the design methodology of Ursholdand King[37] (see Section 3.1 for details).

(DTQ.2) Reuse or extension of high-quality re-sources (e.g., ODPs or well-known ontologies). TheAMLO design process covered both the reuse of ODPs(see Section 4.1) and the reuse of well-known ontolo-gies (see Section 4.2).

(DTQ.3) Being self-explanatory (e.g., are there ap-propriate human and machine readable descriptions?).With the objective to ensure that the AMLO is self-explanatory we included the following skos constructs:a) skos:definition to explain the meaning ofmain entities; b) skos:altLabel to include the al-ternative names for ontology entities, e.g., "SUC" for"System Unit Class"; and c) skos:prefLabel toinclude the most commonly used name for ontologyentities.

11http://vocol.iais.fraunhofer.de/aml/12https://w3id.org/i40/aml13https://github.com/i40-Tools/AutomationMLOntology

5. Applying AMLO for CPPS System Engineering

In this section, we present three representative usecases supported by AMLO. The first use case aims forthe integration of AutomationML documents acrossdifferent engineering disciplines (Section 5.1). Thesecond and third use cases show how querying (Sec-tion 5.2) and reasoning (Section 5.3) can be applied ontop of integrated AMLO data.

The context for the all three use cases is developingan automation system, e.g., a production plant and thecorresponding control system. Such engineering set-ting is characterized by a rich variety of engineeringtools, terminologies, heterogeneous data models, anddata formats applied by project stakeholders. Stake-holders work on the same engineered system, but con-sider it from different points of view, e.g., plant plan-ning, mechanical engineering, electrical wiring or con-trol system implementation. Therefore, this is a com-plex and data-rich setting, with high demand for effec-tive and efficient data integration and advanced analyt-ics within and across the invilved disciplines. Projectparticipants apply AutomationML as a common vo-cabulary for data exchange, which is a first step to fa-cilitate data exchange and communication. However,there is still need for tool-support and technologies,which would allow a) data integration across the dif-ferent engineering disciplines and b) comprehensiveand flexible analytics over the system’s engineeringdata. Semantic technologies possess rich capabilitiesfor both tasks, e.g., by offering comprehensive query-ing with SPARQL and inference and reasoning facili-ties.

5.1. UC1 - Integration of Multi-disciplinaryAutomationML Documents

AutomationML is used to describe CPSS compo-nents and to facilitate their integration in the contextof multi-disciplinary engineering of CPPS. In this con-text, AutomationML documents are developed fromdifferent expertise, i.e., mechanic, electric and soft-ware. Different expertise generate different views overthe same elements described in AutomationML and,thus, semantic heterogeneity when integrating CPPScomponents [4,20]. Semantic heterogeneity needs tobe solved while keeping the meaning of the CPSScomponents. In the Alligator approach [13], this prob-lem is tackled by defining an RDF-based representa-tion of AutomationML documents which are based onAMLO. AMLO is used here as a canonical represen-

https://w3id.org/i40/aml


tation defining the semantics of the elements with re-spect to the AutomationML standard. Based on this,a Datalog-based representation of the AutomationMLinput documents, and a set of rules for identifying se-mantic heterogeneity conflicts are developed. A deduc-tive engine is used to resolve the conflicts, to merge theinput documents and produce an integrated Automa-tionML document.

5.2. UC2 - Inconsistency Checking in EngineeringDesign

After the AutomationML data from various disci-plines have been integrated (e.g., in Alligator approachdescribed above), SPARQL can be used to performanalyses on the top of engineering data.

Hereinafter we present the example consistencycheck that was implemented in the use case of our in-dustry partner, a power plant system integrator, basedon the AMLO. In the example we leverage the formalfoundations of AMLO to access the device character-istics transitively to gather the overall system statistics.

Assume there are maximum weight and electricalconsumption thresholds specified by a customer forthe system under design based on the location settingswhere the system will be deployed. Project engineerscan run the following SPARQL query over the engi-neering data to obtain this information:

1 SELECT (SUM(xsd:integer(?deviceWeight)) AS ?systemWeight)(SUM(xsd:integer(?devicePowerConsumption)) AS ?

systemPowerConsumption)2 WHERE {3 aml:myConveyor aml:hasPart* ?device4 ?device a aml:InternalElement .5 ?device aml:hasAttribute ?attribute .6 ?attribute aml:hasAttributeName "Weight" .7 ?attribute aml:hasValue ?deviceWeight .8 ?device aml:hasAttribute ?attribute .9 ?attribute aml:hasName "PowerConsumption".

10 ?attribute aml:hasValue ?devicePowerConsumption . }

Listing 3: Returning the weight and powerconsumption of the production model. SPARQLquery returning the overall weight and powerconsumption of the production model by using dataannotated according to AMLO.

5.3. UC3 - Flexible Hierarchy Adaptation usingReasoning

Assume there is the following requirement definedby a project engineer: "All controller devices in a pro-duction system must have exactly one connection toautomation object defined". However, the "controller"

role was not defined explicitly in the project and mustbe defined separately for each topology of roles.

The ontology-based representation of AutomationMLdata allows flexible reconfiguration of the definedstructures. Reasoning can be applied to the roles hi-erarchy in order to enrich the existing classification,e.g., the following SWRL rule can be defined toautomatically classify the controllers (assuming thatthe marker for being a controller is supporting the"Ro_MechatronicAssembly" role):

1 SystemUnitClass(?device_type) Λ RoleClass(?role) ΛhasSupportedRole(?device_type, ?role) ΛRo_MechatronicAssembly → Controller(?device)

Listing 4: SWRL rule for reclassification ofthe RoleClass hierarchy The rule relies of thesemantics encoded in AMLO for reclassifying theRoleClass hierarchy.

This rule enriches the existing Roles hierarchy. Thenewly derived triples (i.e., knowledge) can be then ei-ther saved into the ontology (then the new classifica-tion will be available for all later check executions) orstay in memory (therefore being only available duringthe current checking session). All the devices in theproduction system can be now automatically checkedfor being controllers or not. After re-classification hasbeen performed, one can run a SPARQL query tocheck whether all controller devices in the system havethe required property.

6. Related Work

In recent years, much attention has been paid torepresent the knowledge regarding the automation do-main by using ontologies [7]. Concretely, the Automa-tionML standard has been at the core of many effortsin this regard. The main focus of these works has beenin formalizing the CAEX format into an ontology asfollows. Abele et al. [1] present an ontology for thevalidation of plant models, e.g., attribute consistencychecking and correctness of internal links. The on-tology covers base concepts of AutomationML, i.e.,CAEX, and how they are mapped to OWL; Björkelundet al. [6] model an ontology exploiting core conceptsof AutomationML and utilize the resulting ontologyas a common vocabulary to transform AutomationMLmodels into RDF. [26] describes a knowledge integra-tion framework for robotics. In this context, the knowl-edge is represented in AutomationML and transformed


Table 2Comparison of existing semantic representations of the AML standard. Comparison of existing AutomationML ontologies with AMLO;Comparison is performed regarding the use of ontology engineering methodology, the inclusion of ODPs, the reuse of terms from other ontolo-gies, the availability of ontology sources, the source used to develop the ontology, the ontology formalization as well as the generality of the usecase in which the ontology is utilized.

Approach Methodology ODPs Reuse Availability Source Formalization Use CaseAbele et al. [1] No No No - CAEX OWL Plant ValidationBjörkelund et al. [6] No - - - - - Knowledge and Skill RepresentationGlawe et al. [12] No No No - - - Security in AutomationPersson et al. [26] No No No - - - Knowledge IntegrationHua et al. [17] No No Yes - - - A Model-driven Approach for RoboticsAMLO Yes Yes Yes Yes CAEX OWL General applicability

to RDF to publish the RDF data according to Linked-Data principles. To this end, they propose an ontologycovering the main CAEX concepts. Another definitionof a CAEX ontology is developed in the context of us-ing knowledge to support the engineering process ofautomation systems [12]. While the focus of this workis on security, core concepts of the CAEX scheme aredesigned as an OWL ontology. Further, SWRL rulesare introduced to logically connect CAEX elements.Hua et al. [17] developed a semantic-based approachto software engineering of industrial robotics. Authorspropose an approach to deal with robotic componentsand how they can be classified and modeled with Au-tomationML. Further, how AutomationML models canbe processed by means of an ontology is demonstratedin this work. To this end, an AutomationML ontologycovering main aspects of AutomationML is created.

To analyze existing works for an AutomationMLontology, aspects considered of crucial importance forontology development are investigated (cf. Table 2),namely: a) The utilization of an Ontology Engineer-ing methodology; b) the inclusion of Ontology DesignPatterns (ODPs); c) the reuse of existing well-knownontologies; d) the availability of ontology resources,i.e., on Github, or Linked Open Vocabularies (LOV)14;e) the language used as an input for the ontology, e.g.,CAEX, f) the language utilized to describe the ontol-ogy, e.g. OWL, and, finally g) the main use case inwhich the ontology is used.

Overall, existing works lack common desirable fea-tures for an AutomationML ontology. First, previousontologies are tailored for specific use cases and do notconsider all the details of the AutomationML standard.Second, most of the existing ontologies are designedwithout considering any methodology for ontology de-sign or best practices such as the inclusion of ontol-ogy design patterns or reusing well-known vocabular-

14Linked Open Vocabularies: http://lov.okfn.org/dataset/lov

ies. Lastly, besides being described in papers existingontologies are not available for consulting or reusing.We addressed all these gaps with AMLO.

7. Conclusions

We presented the AutomationML ontology (AMLO)that covers the AutomationML data exchange standardin the industrial engineering domain. AMLO providesconcepts to support the design of an engineering sys-tem - components and subcomponents, required andsupported functionality of the components, various at-tributes (e.g., mechanical, electrical of logical ones),logical and physical connections between the systemelements, to name the main ones. The ontology de-sign process was based on domain-specific and onto-logical requirements that were identified for the Au-tomationML context. Particular attention during theAMLO design was given to following the best prac-tices for ontology design (acc. to [14]). The resultingontology covers completely the XSD schema for Au-tomationML and provides means for enhancing the en-gineering data with additional resources (e.g., by in-cluding the Ontology of Units of Measure). We alsoshowed how the AMLO can be used in real life scenar-ios to improve the engineering processes during sys-tem design.

Future work includes extending the ontology withthe COLLADA and PLCOpen fragments of the Au-tomationML standard. Additionally, we will explorewhat other resources in the industrial engineering areahave semantic representations available and would beuseful to link with the AMLO to provide more possi-bilities for enhancing the original AutomationML datacontent and data structure.


References

[1] L. Abele, C. Legat, S. Grimm, and A. W. Müller. Ontology-based validation of plant models. In INDIN, pages 236–241.IEEE, 2013.

[2] M. Barnes and E. L. Finch. COLLADA-Digital Asset SchemaRelease 1.5. 0 specification. Technical report, Khronos Group,Sony Computer Entertainment Inc, 2008.

[3] T. Bauernhansl, M. ten Hompel, and B. Vogel-Heuser. Indus-trie 4.0 in Produktion, Automatisierung und Logistik: Anwen-dung, Technologien. Migration. Wiesbaden: Springer Vieweg,2014.

[4] S. Biffl, O. Kovalenko, A. Lüder, N. Schmidt, andR. Rosendahl. Semantic mapping support for Mechatronic Ob-jects in AutomationML. In AutomationML User Conference,Blomberg, Germany. IEEE, 2014.

[5] S. Biffl, A. Lüder, and D. Winkler. Multi-disciplinary engi-neering for industrie 4.0: Semantic challenges and needs. InS. Bill and M. Sabou, editors, Semantic Web for Intelligent En-gineering Applications, pages 17–51. Springer, Springer Inter-national Publishing, 2016.

[6] A. Björkelund, J. Malec, K. Nilsson, and P. Nugues. Knowl-edge and skill representations for robotized production. In Pro-ceedings of the 18th IFAC Congress, Milan, 2011.

[7] V. Damjanovic, W. Behrendt, M. Plößnig, and M. Holzapfel.Developing ontologies for collaborative engineering in mecha-tronics. In The Semantic Web: Research and Applications, 4thEuropean Semantic Web Conference, ESWC, Innsbruck, Aus-tria, June 3-7, Proceedings, pages 190–204, 2007.

[8] R. Drath. Datenaustausch in der Anlagenplanung mit Au-tomationML: Integration von CAEX, PLCopen XML und COL-LADA. Springer-Verlag, 2009.

[9] eClass e.V. eCl@ss - Standardized Material and Service Clas-sification, 2016. http://www.eclass.eu/.

[10] M. Fedai, U. Epple, R. Drath, and A. Fay. A metamodel forgeneric data exchange between various cae systems. In Pro-ceedings of 4th mathmod conference, volume 24, pages 1247–1256, 2003.

[11] A. Gangemi and V. Presutti. Ontology Design Patterns. InHandbook on Ontologies, pages 221–243. 2009.

[12] M. Glawe, C. Tebbe, A. Fay, and K. Niemann. Knowledge-based engineering of automation systems using ontologies andengineering data. In KEOD Proceedings of the InternationalConference on Knowledge Engineering and Ontology Devel-opment, Volume 2, Lisbon, Portugal, November 12-14, pages291–300, 2015.

[13] I. Grangel-González, D. Collarana, L. Halilaj, S. Lohmann,C. Lange, M.-E. Vidal, and S. Auer. Alligator: A deductive ap-proach for the integration of industry 4.0 standards. In F. Vitaliand E. Blomqvist, editors, Knowledge Engineering and Knowl-edge Management - 20th International Conference, EKAW,Bologna, Italy, November 19-23. Proceedings. Springer, 2016.

[14] A. Gray and M. Sabou. ISWC resources track review instruc-tions. ISWC, 2016. https://dx.doi.org/10.6084/m9.figshare.2016852.

[15] L. Halilaj, N. Petersen, I. Grangel-González, C. Lange,S. Auer, G. Coskun, and S. Lohmann. Vocol: An integratedenvironment to support version-controlled vocabulary devel-opment. In Knowledge Engineering and Knowledge Manage-ment - 20th International Conference, EKAW, Bologna, Italy,November 19-23, 2016, Proceedings, pages 303–319, 2016.

[16] M. Hepp. Goodrelations: An Ontology for describing Productsand Services Offers on the web. In Knowledge Engineering:Practice and Patterns, 16th International Conference, EKAW2008, Acitrezza, Italy, September 29 - October 2, 2008. Pro-ceedings, pages 329–346, 2008.

[17] Y. Hua, S. Zander, M. Bordignon, and B. Hein. From automa-tionml to ROS: A model-driven approach for software engi-neering of industrial robotics using ontological reasoning. In21st IEEE International Conference on Emerging Technolo-gies and Factory Automation, ETFA 2016, Berlin, Germany,September 6-9, 2016, pages 1–8, 2016.

[18] IEC. Iec 62714-1:2014 engineering data exchange format foruse in industrial automation systems engineering - automationmarkup language, 2014.

[19] E. Kharlamov, B. C. Grau, E. Jiménez-Ruiz, S. Lamparter,G. Mehdi, M. Ringsquandl, Y. Nenov, S. Grimm, M. Roshchin,and I. Horrocks. Capturing industrial information models withontologies and constraints. In P. Groth, E. Simperl, A. Gray,M. Sabou, M. Krötzsch, F. Lecue, F. Flöck, and Y. Gil, editors,The Semantic Web – ISWC 2016: 15th International SemanticWeb Conference, Kobe, Japan, October 17–21, 2016, Proceed-ings, Part II, pages 325–343. Springer International Publish-ing, 2016.

[20] O. Kovalenko and J. Euzenat. Semantic matching of engineer-ing data structures. In S. Bill and M. Sabou, editors, SemanticWeb for Intelligent Engineering Applications. Springer, 2016.

[21] O. Kovalenko, M. Wimmer, M. Sabou, A. Lüder, F. J. Ekapu-tra, and S. Biffl. Modeling automationml: Semantic web tech-nologies vs. model-driven engineering. In ETFA, pages 1–4.IEEE, 2015.

[22] O. Kovalenko, M. Wimmer, M. Sabou, A. Lüder, F. J. Ekapu-tra, and S. Biffl. Modeling automationml: Semantic web tech-nologies vs. model-driven engineering. In 20th IEEE Confer-ence on Emerging Technologies & Factory Automation, ETFA2015, Luxembourg, September 8-11, 2015, pages 1–4, 2015.

[23] S. Liu, J. Mei, A. Yue, and Z. Lin. XSDL: Making XML Seman-tics Explicit, pages 64–83. Springer Berlin Heidelberg, 2005.

[24] C. Pedrinaci, J. Cardoso, and T. Leidig. Linked usdl: a vo-cabulary for web-scale service trading. In The Semantic Web:Trends and Challenges, pages 68–82. Springer, 2014.

[25] S. Peroni, A. Gangemi, and F. Vitali. Dealing with markupsemantics. In Proceedings of the 7th International Conferenceon Semantic Systems, I-Semantics ’11, pages 111–118, NewYork, NY, USA, 2011. ACM.

[26] J. Persson, A. Gallois, A. Björkelund, L. Hafdell, M. Haage,J. Malec, K. Nilsson, and P. Nugues. A knowledge integrationframework for robotics. In ISR/ROBOTIK 2010, Proceedingsfor the joint conference of ISR 2010 (41st Internationel Sympo-sium on Robotics) und ROBOTIK 2010 (6th German Confer-ence on Robotics), 7-9 June 2010, Munich, Germany - Parallelto AUTOMATICA, pages 1–8, 2010.

[27] H. S. Pinto and J. P. Martins. Ontologies: How can they bebuilt? Knowledge and Information Systems, 6(4):441–464,2004.

[28] M. Poveda-Villalón. A reuse-based lightweight method fordeveloping linked data ontologies and vocabularies. In TheSemantic Web: Research and Applications, pages 833–837.Springer, 2012.

[29] V. Presutti, E. Blomqvist, E. Daga, and A. Gangemi. Pattern-based ontology design. In M. C. Suárez-Figueroa, A. Gómez-Pérez, E. Motta, and A. Gangemi, editors, Ontology Engineer-

http://www.eclass.eu/

https://dx.doi.org/10.6084/m9.figshare.2016852

https://dx.doi.org/10.6084/m9.figshare.2016852


ing in a Networked World, pages 35–64. Springer Berlin Hei-delberg, 2012.

[30] K. Ridgway, C. Clegg, and D. Williams. The Factory of the Fu-ture, Future Manufacturing Project: Evidence Paper 29. Lon-don: Foresight, Government Office for Science, 2013.

[31] H. Rijgersberg, M. van Assem, and J. L. Top. Ontology of unitsof measure and related concepts. Semantic Web, 4(1):3–13,2013.

[32] M. Sabou. An introduction to semantic web technologies. InS. Biffl and M. Sabou, editors, Semantic Web Technologies forIntelligent Engineering Applications, pages 53–81. SpringerInternational Publishing, 2016.

[33] M. Sabou, O. Kovalenko, F. J. Ekaputra, and S. Biffl. Semanticweb solutions in engineering. In S. Biffl and M. Sabou, ed-

itors, Semantic Web Technologies for Intelligent EngineeringApplications, pages 281–296. Springer International Publish-ing, 2016.

[34] M. Sabou, O. Kovalenko, and P. Novák. Semantic modellingand acquisition of engineering knowledge. In Semantic WebTechnologies for Intelligent Engineering Applications, pages105–136. Springer, 2016.

[35] N. Schmidt and A. Lüder. AutomationML and eClass integra-tion, 2015.

[36] T. Tudorache. Employing ontologies for an improved develop-ment process in collaborative engineering. 2006.

[37] M. Uschold and M. King. Towards a methodology for buildingontologies. Citeseer, 1995.