An Ontological View of the RAMI4.0 Asset Administration Shell

Andreas W. Müller

, Irlán Grangel-González

and Christoph Lange

Data & Analytics Governance, Schaefﬂer AG, Herzogenaurach, Germany

Corporate Research, Robert Bosch GmbH, Renningen, Germany

Fraunhofer FIT, Sankt Augustin, Germany

Keywords:

Industry 4.0, Asset Administration Shell, Information Integration, Industrial Ontology.

Abstract:

Information interoperability is of paramount importance to Industry 4.0 (I4.0). To this end, the Reference

Architecture Model for I4.0 (RAMI4.0) deﬁnes the Asset Administration Shell (AS) concept as a core element

for interoperable descriptions of assets. Assets, such as Cyber-Physical Systems, are building blocks that

need to be interchangeable between various industrial systems but are heterogeneously modeled. In order to

achieve the required interoperability between these systems, semantics is key. Typically, two types of systems

occur in I4.0 scenarios: legacy systems not considering explicit semantics, and a new generation of ontology-

based systems. However, existing approaches for modeling the AS do not explicitly address this situation of

interoperability between systems of such different types. In this article, we develop an ontological view of the

AS concept to bridge the gap between these types of systems. This results in an ontology that is intended to

be likewise realizable with both ontology-based and non-ontology-based systems. We present this ontology

together with a suggested two-phase engineering process for its application.

1 INTRODUCTION

The digitization of industry requires integrated infor-

mation models describing the assets and information

sources of companies to enable semantic integration

and interoperable data exchange. The Industry 4.0 vi-

sion (Lee et al., 2015) aims at creating Smart Facto-

ries by combining Internet of Things (IoT), Internet

of Services (IoS) and Cyber-Physical Systems (CPS)

technology. Smart Factories promise to improve the

production process by adding intelligence to indus-

try data, such as orders or sensor data, and by coor-

dinating the way humans and machines collaborate.

Different standards, such as those published by bod-

ies such as ISO or IEC, are used to describe informa-

tion about manufacturing, security, identiﬁcation and

communication, among others.

Although the vision of digitizing production and

manufacturing has gained much traction lately, it is

still not clear how this vision can actually be imple-

mented in an interoperable way using concrete stan-

dards and technologies (Brettel et al., 2014). A key

challenge is to enable smart industrial devices to com-

municate and to understand each other as a prereq-

uisite for cooperation scenarios (Kharlamov et al.,

2016). Of paramount importance for achieving in-

teroperability in this context is the RAMI model

along with its Asset Administration Shell (AS) con-

cept (Marseu et al., 2017). The AS is intended as

a deﬁned access point to the variety of information

and functionality offered by smart devices. The con-

tribution of this article is to develop an ontological

formalization of the AS concept that supports real-

ization with and interoperability of different types of

information systems. To foster acceptance and imple-

mentation of the AS concept, we consider it essential

to design the AS in a way that can likewise be inte-

grated with existing systems and devices as well as

with future ontology-based systems. That way, im-

plementers can homogeneously extend their portfo-

lios without information breaches.

The paper is organized as follows. Section 2 pro-

vides a deﬁnition of the problem. Section 3 gives nec-

essary background information. Section 4 describes

related work in this ﬁeld. Section 5 introduces our

approach, while section 6 concludes the paper.

2 PROBLEM DEFINITION

Assets are viewed as industrial devices, ranging from

simple components to complex CPS. They exhibit

Müller, A., Grangel-González, I. and Lange, C.

An Ontological View of the RAMI4.0 Asset Administration Shell.

DOI: 10.5220/0010111101650172

In Proceedings of the 12th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2020) - Volume 2: KEOD, pages 165-172

ISBN: 978-989-758-474-9

165

(a) RAMI4.0.

(b) Administration Shell (AS).

Figure 1: The RAMI4.0 model and the Administration Shell. RAMI4.0 includes a three-dimensional model with core

processes and concepts for I4.0, e.g., the Administration Shell (AS) (Adolphs, et al., 2015); The manifest, the component

manager, and the Asset are included as main parts of the AS.

various capabilities, e.g., communication or execution

of production steps, which may change during the

individual lifecycles. Hence, they may be equipped

with AS depending on the respective capability set.

ERP

MES

SCADA

PLC

I/O Device

Administration

Shell

Organization embedded in

dynamic Supply Chain

information flows (Supplier

or Customer role)

Used technologies/paradigms for

respective information systems of

level/discipline

Supplier

Customer

Asset: Motor

on field level

Figure 2: Role of the AS in manufacturing processes. The

AS plays a key role in the Manufacturing process on all lev-

els of the automation pyramid, while the associated asset

can be located on the ﬁeld level. The automation pyramid

denotes a main principle of organization of systems in the

industrial domain. The AS is key in the Product Life-cycle

Management (PLM) process as well as in Supply Chains.

For vertical and horizontal use it needs to be implemented

differently due to the predominantly used technologies and

paradigms on the respective layers. The numbers denote

(1) Semantic technologies; (2) Extensions of semantics to-

wards the ﬁeld-level, e.g., via OPC UA; (3) OO (-based

implementations); (4) Non-ontology, non-OO (-based im-

plementations); (5) PLM-supported changes in the organi-

zation; (6) Arrows indicate the relevance of the AS model

in various contexts. The dotted lines for Organization and

Customer/Supplier indicate respective variability over time.

The AS provides methods for interaction with an

asset and capabilities that are required for its use.

Hence, an AS depicts a smart interface to an asset,

which may vary in its asset-speciﬁc extent but always

provides a standard access point for knowledge dis-

covery and asset utilization.

Further, the information conveyed by the AS

needs to be horizontally and vertically used across all

layers of the automation pyramid (cf. Figure 2). Since

the systems on the different levels could be legacy or

ontology-based, AS manifestations also need to be ei-

ther object-oriented or ontology-based, respectively.

Hence, the AS structures need to be seamlessly appli-

cable to all layers and thus a common understanding

of information structures is required in this setting.

Considering the dynamics of assets with their ca-

pabilities and along their lifecycles, an AS needs to

be understood by all actors involved in handling an

asset (cf. Figure 2). Following this, and considering

the scenarios of AS usage (ZVEI, 2016) as well as

our own experience in the ﬁeld, we propose an AS

realization to meet two basic requirements: 1) The

AS requires an ontology that permits modeling with

both ontology-based and non-ontology-based systems

alike; and 2) The ontology shall permit separation of

the AS information from the description of the asset,

enabling independent reﬁnement of the models of AS

and assets.

3 BACKGROUND

RAMI4.0 describes basic aspects of Industry

4.0 (Adolphs, et al., 2015) (see Figure 1a). The

vertical axis (left) represents the IT perspective,

with layers ranging from the physical device (asset)

to complex functions in ERP systems (functional).

These layers correspond to the idea of decomposing

complex projects into smaller manageable parts.

The horizontal axis on the left indicates the product

lifecycle with Type and Instance as the main concepts.

In RAMI4.0, the AS concept is pivotal for achiev-

ing the desired interoperability between assets. An

KEOD 2020 - 12th International Conference on Knowledge Engineering and Ontology Development

166

asset is a physical or logical object that is managed by

an organization and has value for it (Adolphs, et al.,

2015; DIN, 2016). Further, an I4.0 component can be

a production system, a machine, or an assembly in-

side a machine. This comprises two basic elements:

an asset and its AS. Every asset that is equipped with

an AS becomes an I4.0 component. The AS should

be able to represent the different kinds of information

about an asset that occur during its lifecycle. Further,

the AS contains the integral parts manifest, i.e. a cata-

log of the meta-information about the AS, and compo-

nent manager, which serves as a basis for SOA-based

access to the I4.0-component (cf. Figure 1b).

The information systems used by the target au-

diences of RAMI4.0 are typically long-lived, het-

erogeneous and follow organizational principles such

as the automation systems pyramid or are integrated

in process networks such as supply chain manage-

ment. For these audiences ontology-based approaches

to RAMI4.0 constitute disruptions in existing ap-

plication architectures. Hence, with regard to the

long-term focus of RAMI4.0 and the endeavours re-

quired to realize a universal AS model, we provide an

implementation-agnostic basic structural design that

can meet current system architectures and can thus be

applied to various types of interoperating information

systems based on different technological foundations.

4 RELATED WORK

Grangel-González et al. have implemented the AS

concept in the context of the RAMI as an ontol-

ogy (Grangel-González et al., 2016). The ontology

considers the AS in relation with the asset according

to the ﬁrst speciﬁcation of the RAMI model (Adolphs,

et al., 2015). Further, classiﬁcations of data are in-

troduced as classes, e.g., application data, structural

data are related to the asset to represent distinct types

of data to which an asset should be related to. Core

concepts of the AS speciﬁcation, e.g., the manifest,

header, and body were not considered in this work.

Tantik et al. (Tantik and Anderl, 2017) proposed an

integrated data model and structure for the AS in I4.0

contexts. Pethig et al. (Pethig et al., 2017) developed

a data model for the AS to be applied in conditioning

monitoring services for I4.0. Diedrich et al. (Diedrich

et al., 2017) proposed a model for semantic interoper-

ability for communication of assets within the smart

factories context. In (Platform Industrie 4.0, 2019) a

broad and detailed overview of AS representation, but

without formal logical foundations, is given.

As shown above, most studies examined the se-

mantic modeling of the AS concept. So far, however,

there has been little discussion regarding the AS as a

smart interface capable to deal with ontology-based

systems.

5 METHODOLOGY

This section presents the steps and design choices

taken to develop an ontology of the AS that meets the

requirements given in Section 2.

5.1 General Approach

In creating our design we followed 1) the speciﬁca-

tion of the RAMI4.0 (DIN, 2016) as the normative

guideline, and 2) an approach driven by initial object-

oriented analysis and design (OOAD) (Booch et al.,

2008), inspired by a similar conceptual approach (Ne-

gri et al., 2017), instead of mainly ontology-oriented

approaches, such as competency question-driven au-

thoring (Ren et al., 2014). This we consider essen-

tial for acceptance in the industrial community to fos-

ter integration into today’s predominantly OO-based

industrial system landscapes as well as to provide a

bridge to ontology-based systems in the ﬁeld.

In this sense, we ﬁrst identiﬁed class candidates

in the textual descriptions and deﬁnitions of the

RAMI4.0 speciﬁcation from nouns, and candidates

for interrelations and attributes from verbs and ad-

jectives, respectively. Generalizations, associations

and parthood roles were constructed from textual in-

dicators such as is a, of, or consists of, respectively.

Following (Bradner, 1997), cardinalities were derived

from textual qualiﬁers such as must, can, or similar

for distinguishing mandatory from optional parts or

interrelations. From this, an initial view, correspond-

ing to an analytical model in OOAD, for the AS was

derived, i.e., the basic set of terms, classes and their

conﬁguration was identiﬁed. In view of the suggested

AS usage scenarios in (ZVEI, 2016), we reﬁned and

extended this model, and cross-checked with different

descriptions of the AS in further non-normative pub-

lications. This reﬁned model corresponds to a design

model in the OOAD sense.

We then provided semantic grounding for the on-

tology following (Berardi et al., 2005) for seamless

use with ontology-based systems as well as OO sys-

tems. During the entire course, best practices for

ontology building and naming guidelines for entities

were followed with regard to long-term usability of

the ontology.

An Ontological View of the RAMI4.0 Asset Administration Shell

167

5.2 Terms and Interrelations

With the basic idea of the AS as an interface, two

separate initial terms/classes can be identiﬁed, i.e.,

AS and Asset. The AS represents the Asset within

an I4.0 system (third class). It is assumed that these

classes denote different, individually manageable en-

tities. With the notion of the presence of an associated

AS enabling an Asset to become an I4.0 component

(fourth class), which may be part of an I4.0 system,

these four classes constitute the core of the target on-

tology (cf. Figure 3).

Figure 3: Initial analytical view of the four core terms of the

AS model with their basic associations.

From the lifecycle and utilization perspectives

both Assets and ASs may exist independently in terms

of management by information systems. The mem-

bership of an Asset in the class of I4.0 components

depends on its classiﬁcation according to the com-

munication capabilities and publicity level (CP) ma-

trix (Adolphs et al., 2016). An Asset does not have to

meet the requirements of an I4.0 component from the

very beginning. Instead, it may be later equipped with

properties or capabilities that permit its CP reclassiﬁ-

cation as I4.0 component, which only then requires an

AS to be present. Additionally, I4.0 systems may con-

tain Assets that are not I4.0 components. Hence, in-

formation systems must be able to identify and man-

age such non-I4.0 components as well. Using this

initial analytical model, the requirements for the AS

(cf. (Adolphs et al., 2016)), together with its scenar-

ios for utilization described by (ZVEI, 2016), are now

examined. This results in the following observations

and considerations. From these, competency ques-

tions (CQ) are derived for the basic tasks of subse-

quent validation and model checking of the target on-

tology and thus for AS handling.

• Both Asset and AS are separately identiﬁable.

CQ1: Which AS refer to an associated Asset?

• The AS consists of a Header and a Body, with

the Body containing information about the I4.0-

component, while the Header contains informa-

tion about its utilization. Hence, both Header and

Body are viewed mandatory. CQ2: Does an AS

contain both Header and Body?

• The AS contains the Component Manager. There

is a looseness in the speciﬁcation: While the Com-

ponent Manager is mostly described as a manda-

tory singleton, there are examples that imply that

in situations no dedicated Component Manager

needs to be deﬁned as part of an AS. Instead, an

AS could act as a proxy to the AS containing the

Component Manager to be used. CQ3: Does the

AS contain the Manifest? CQ4: Which ASs con-

tain a Component Manager?

• An I4.0 component exposes domain-speciﬁc

functionality and a continuous State Model, mak-

ing it accessible in a combined fashion (Adolphs

et al., 2016). For this, the mechanism of the AS’s

Component Manager is assumed. CQ5: Does a

given Component Manager offer the State Model?

• The AS uses different views for exposing the

properties and functions of the represented Asset

to the client. CQ6: Does the AS offer views that

organize properties and functions of the Asset?

• An AS contains multiple Partial Models com-

posed from hierarchical Properties referring to

data and functions of the Asset. CQ7: Does the

AS contain Partial Models with hierarchically or-

ganized Properties that refer to data or functions

of the associated Asset?

• Following the requirements of nesting and com-

bining an AS may access or be part of other ASs,

or may combine many Assets with various CP

classiﬁcations. CQ8: Can an AS be nested with

another AS? CQ9: Can an AS refer to Assets with

different CP classiﬁcations?

• An Asset as an I4.0 component may be linked to

more than one AS during its lifecycle, implying

versioning. CQ10: Is a given Asset identiﬁable

as an I4.0-component? CQ11: Can the relation

between an Asset and its AS be redeﬁned?

• An AS shall be extensible by various types of

properties or models for exposing speciﬁc aspects

of an asset. CQ12: Does the AS permit integra-

tion of speciﬁc models for exposing aspects of the

Asset?

From these observations, the revised, larger ana-

lytical model as shown in Figure 4 is derived.

Figure 4: Extended analytical view of the basic terms.

KEOD 2020 - 12th International Conference on Knowledge Engineering and Ontology Development

168

5.3 Modes of Use

The functions of I4.0 components and modes of use

for the AS are described in (Adolphs, et al., 2015;

DIN, 2016). The following scenarios are considered

to capture the dynamics of the AS during the lifecycle

of an asset.

An AS may be supplemented to an existing asset:

AS v ≥ 1 refers_to.Asset

a : Asset

as : AS u ∃refers_to.{a}

(1)

An AS may be replaced by a newer version:

as1 : AS u ∃refers_to.{a}

as2 : AS u ∃refers_to.{a}

(2)

with the as1 : ∃refers_to.a needing to be retracted in

advance and AS instances being subject to versioning.

An AS may be created together with an I4.0 com-

ponent representation:

as : AS u ∃refers_to.{a}

i : I4.0_Component u ∃has_part.{as}

(3)

An AS may be extended to functionally cover ad-

ditional I4.0 components:

AS v (≥ 1 refers_to.Asset) u(≥ 0 accesses.AS) u

(= 1 has_part

–

.I4.0_Component)

a1 : Asset

a2 : Asset

as1 : AS u ∃refers_to.{a1}

as2 : AS u ∃refers_to.{a2}

(4)

It is assumed that both a1 and a2 qualify as I4.0 com-

ponents, thus this inference shall be possible:

i1 : I4.0_Component u ∃has_part.{as1}

i2 : I4.0_Component u ∃has_part.{as2}

as2 : ∃accesses.{as1} u ∃has_part

–

.{i2}

|= i2 : ∃has_part.{as1}

(5)

ASs may be nested:

AS v ∃accesses.AS

as1 : AS

as2 : AS u ∃accesses.{as1}

(6)

An AS may be (un-)linked from/to another AS:

This scenario is basically identical to the nesting sce-

nario. However, for unlinking, asserted knowledge

needs to be retracted ﬁrst.

The AS as well as other involved entities are mod-

eled as distinct individuals for easy information man-

agement.

5.4 Ontological Representation

A principle followed in this work is that textual part-

hood indicators such as contains, consists of, has part

can be modeled via a closure leading to meet the

desired requirements while neglecting the distinction

between structural and functional parthood for now.

First, we addressed the question of how to model

an asset as the basic entity for an information system.

Here, a partitioning problem exists since an asset shall

at any time be either a template or instance while be-

ing at the same time either tangible or intangible, each

being mutually exclusive. This allows for different in-

terpretations and hence OOA models.

With regard to the intended uniform cross-

technology knowledge representation, the expected

large numbers of assets and types to be managed, the

possible modiﬁcations an asset and its representation

may be subject to during its lifecycle, and the long-

term use of the resulting ontology, we found that only

one individual should be required to model an asset.

Hence, we opted for preserving the distinction of as-

sets as tangible or intangible. This classiﬁcation re-

mains static during the entire lifecycle of an asset.

Speciﬁcation of an asset as a template or an instance

that can be individually managed and tracked is ex-

pressed via an is_template ﬂag. That way, an asset can

be modeled using a single individual. Evolution of

assets can be expressed by the is_directly_based_on

role (see Figure 5

, following the semantics for UML

class diagrams (Berardi et al., 2005)). This asset con-

cept can be extended to employ further models for

representing the data, functions and facets of assets

(outside the scope of this paper).

Figure 5: Selected approach for modeling an Asset.

Asset v (Intangible_Asset t Tangible_Asset) u

(≤ 1 is_directly_based_on.Asset)

Template v Asset u

(≤ 1 is_directly_based_on.Asset) u

∃

∀

is_template.{true}

Instance v ¬Template.

An asset is the ﬁrst entity to be considered in the

process of AS management. Thus, we developed the

overall ontology as follows. According to RAMI4.0

an Asset may be classiﬁed by its CP levels as well

Here and in the following we employ

∃

∀

r.C as a short-

hand notation for ∃r.C u ∀r.C.

An Ontological View of the RAMI4.0 Asset Administration Shell

169

as by the layer and hierarchy levels it is assigned

to. For being classiﬁed as an I4.0 component, the

CP classiﬁcation is mandatory. We introduced an ab-

stract superclass Managed Representative as the dis-

joint union of I4.0 components and non-I4.0 compo-

nents. (Non-)I4.0 components can be modeled as well

as I4.0 systems, which are I4.0 components with at

least one other I4.0 component and may also contain

non-I4.0 components. Hence, only I4.0 components

are equipped with AS while all Managed Representa-

tives refer to underlying assets. This can be axioma-

tized as follows.

RAMI_Communication_Capability_Level ≡

{Active_Communication,

Industry4.0_Communication,

No_Communication,

Passive_Communication}

(7)

RAMI_Publicity_Level ≡

{Known_Anonymously, Known_Individually,

Managed_As_Entity, Unknown}

(8)

I4.0_Component ≡

Managed_Representative u ∃refers_to.(Asset u

∃

∀

has_RAMI_C_Level.(Passive_Communication t

Active_Communication t

Industry4.0_Communication)

∃

∀

has_RAMI_P_Level.Managed_As_Entity)

u (= 1 contains_Shell.Administration_Shell)

(9)

Although this information can be inferred, explicit

modeling for easier information management is pro-

posed. In view of its use in information systems, the

AS is modeled to consist of Header, Body and Mani-

fest only. That way, a client can browse the AS since

Header and Manifest are intended for directory pur-

poses only. The Component_Manager is modeled to

be contained by the Body. Additionally, the Com-

ponent_Manager contains the required State_Model

along with the set of Partial_Models. Basically, all

three elements Header, Manifest and Partial_Model

contain Propertys. In accordance with the speciﬁca-

tion, only the Manifest exposes the whole set of Prop-

ertys, while the others expose only partial sets and

combinations thereof. A Property, with its four de-

ﬁned subtypes, is considered a representative of either

a data element or a function of the referenced Asset.

View offers an extensible set of predeﬁned subtypes

for providing logical groupings of Propertys.

Since an AS may logically contain other AS, this

is expressed via the accesses relationship. For this,

implementations need to prevent cycles. In OWL this

is supported by deﬁning the relationship as irreﬂexive

and transitive

. Figure 6 shows the followed model-

ing approach.

Figure 6: Basic model of the RAMI4.0 AS.

The AS concept can be axiomatized as follows:

Administration_Shell v (= 1 contains_Shell

–

I4.0_Component) u

(= 1 has_Shell_Part.Header) u

(= 1 has_Shell_Part.Body) u

(= 1 offers_Manifest.Manifest)

(10)

5.5 Application

With the AS as an interface to an asset, the existence

of the latter is a prerequisite for modeling the former.

Further, both models are subject to changes during

their individual lifecycles. With regard to the intended

usability of the ontology for model-based systems en-

gineering, we propose to explicitly distinguish two

separate engineering phases in providing an AS for

an asset (cf. Figure 7).

The ﬁrst phase is called asset engineering phase.

In this, an asset is modeled according to its require-

ments. Typically, such representations would involve

speciﬁc standards, which might only be internally vis-

ible and thus result in asset-speciﬁc structures only.

In this phase the asset is also unaware of its potential

classiﬁcation as an I4.0 component, as this depends

on its capabilities. The result of this phase is required

to be a self-contained model of the asset.

The OWL implementation can be obtained from

https://ﬁgshare.com/articles/dataset/rami_as/6808988.

KEOD 2020 - 12th International Conference on Knowledge Engineering and Ontology Development

170

Figure 7: Conceptual phases for AS engineering. The exis-

tence of an engineered asset is prerequisite for the engineer-

ing of its associated AS.

The second phase is referred to as AS engineer-

ing phase. In this, the model of the asset is evaluated,

i.e., capability-tested, according to the criteria for I4.0

components (this process is not in scope of this pa-

per). If the asset qualiﬁes as an I4.0 component, the

AS model can be created, along with its mandatory

structural parts. Further, AS elements such as proper-

ties or views are added and linked to the underlying

elements of the asset model, effectively resulting in

the AS as a wrapper. The outcome of this phase is

a self-contained AS with its elements linked to those

elements of the asset that it needs to expose in order

to be usable as I4.0 component.

This two-step process decouples asset modeling

from AS modeling, allowing for independent engi-

neering, management and distributions of assets, their

AS and combinations thereof.

5.6 Evaluation

In Section 5.2, main CQs for basic AS model check-

ing are identiﬁed. These are to ensure that AS in-

stances transferred between ontology-based and non-

ontology-based systems follow identical structures.

We analyze how these CQs can be answered by the

developed ontology with its intended application (cf.

Figure 6). Table 1 reports on the results for each CQ.

The list, however, shows that it is not possible to an-

swer CQ10 by the ontology itself. Rather, additional

business logic is needed for performing the required

tests. Valid AS instances can then be handled us-

ing structurally identical query patterns on ontology-

based and OO systems. This is exempliﬁed by the

access path in Listing 1 for accessing an asset’s AS’s

Performance_View. This further reveals the need for

additional but in (DIN, 2016) insufﬁciently speciﬁed

explicit access to overall views on an asset via an AS’s

Header.

Listing 1: SPARQL access.

SELECT ? pv WHERE {

? a a : A d m i n i s t r a t i o n _ S h e l l ;

: has [ a : Body ;

: ha s [ a : Component_Manager ;

: ha s [ a : P a r t i a l _ M o d e l ;

: ha s ? pv ] ] ] .

? pv a : Pe rf o rm an c e_ Vi e w . }

Table 1: Competency questions and answers.

CQ Answers to CQs

CQ1 An AS is part of an I4.0 component, which is subclass of an identiﬁable representative that is associated with an Asset.

CQ2 Header and Body are parts of an AS.

CQ3 Manifest is part of an AS.

CQ4 An AS may access other AS. An AS contains a Body. A Body can contain a Component Manager.

CQ5 A State Model is part of a Component Manager.

CQ6 An AS contains a Body, which may contain a Component Manager, which contains Partial Models. A Partial Model

is composed of Properties and Views, with the latter referring to the former.

CQ7 An AS contains a Body, which may contain a Component Manager, which contains Partial Models. A Partial Model

is composed of Properties. A Property references data elements or functions of the Asset associated with the AS, and

it may have a Property that is its superProperty.

CQ8 An AS may access other AS or be part of another AS.

CQ9 An AS may refer to more than one Asset at one time.

CQ10 Via testing, an Asset with its characteristics can be examined for its RAMI Communication Capability Level and its

RAMI Publicity Level. The results of this examination can be stored as part of the Asset. According to these levels, a

Managed Representative, which can be classiﬁed as I4.0 component, can be assigned to the Asset.

CQ11 An AS is part of an I4.0 component, which is a subclass of Managed Representative. This holds the reference to the

associated Asset. This reference can be retracted and reasserted.

CQ12 Via Body and Component Manager, an AS contains Partial Models. Speciﬁc models can be integrated as special-

izations of Partial Model, which may contain Properties and Views that reference speciﬁc functions or data of the

Asset.

An Ontological View of the RAMI4.0 Asset Administration Shell

171

6 CONCLUSION AND FUTURE

WORK

In this article, we presented an ontology for the

RAMI4.0 AS concept. This ontology can be used

with systems based on different technologies or

paradigms. By applying OOAD to the descriptions

in the RAMI4.0 standard documents we developed

the ontology to be implementable with OO systems.

Afterwards, we extended it with its logical under-

pinnings to bridge the gap to ontology-based sys-

tems, permitting a structurally identical implementa-

tion. The approach introduces a strict separation of

the concepts of Asset and AS and of their respec-

tive models, using only loose couplings in between.

In an attempt to create and manage these models,

we deﬁned them to be engineered in two consecutive

phases, which enables selective exposure of Asset in-

formation via the AS.

We see this approach as an extensible basis for

information systems to enhance the interoperability

of assets from different manufacturers as well as the

supply of necessary asset information to customers.

For future developments we consider the provision of

standard software components, which encapsulate the

required functionality so that the involved complex

model-based processing becomes easily usable. This

is essential for a wide acceptance of the AS concept.

REFERENCES

Adolphs, P., Auer, S., Billmann, M., Hankel, M., Heidel,

R., Hoffmeister, M., Huhle, H., Jochem, M., Kiele,

M., Koschnick, G., Koziolek, H., Linke, L., Pichler,

R., Schewe, F., Schneider, K., and Waser, B. (2016).

Structure of the administration shell. Status report,

ZVEI and VDI.

Adolphs, et al. (2015). Reference Architecture Model In-

dustrie 4.0 (RAMI4.0). Status report, ZVEI and VDI.

Berardi, D., Calvanese, D., and De Giacomo, G. (2005).

Reasoning on UML class diagrams. Artif. Intell.,

168(1-2):70–118.

Booch, G., Maksimchuk, R. A., Engle, M. W., Young, B. J.,

Conallen, J., and Houston, K. A. (2008). Object-

oriented analysis and design with applications, third

edition. ACM SIGSOFT Software Engineering Notes,

33(5).

Bradner, S. (1997). Key words for use in RFCs to indicate

requirement levels. RFC 2119, Internet Engineering

Task Force (IETF).

Brettel, M., Friederichsen, N., Keller, M., and Rosen-

berg, M. (2014). How virtualization, decentralization

and network building change the manufacturing land-

scape: An industry 4.0 perspective. Int. Journal of

Mechanical, Aerospace, Industrial and Mechatronics

Engineering, 8(1):37–44.

Diedrich, C., Belyaev, A., Schroder, T., Vialkowitsch, J.,

Willmann, A., Usländer, T., Koziolek, H., Wende, J.,

Pethig, F., and Niggemann, O. (2017). Semantic in-

teroperability for asset communication within smart

factories. In 22nd IEEE Int. Conf. on Emerging Tech-

nologies and Factory Automation, ETFA, Limassol,

Cyprus, September 12-15, pages 1–8.

DIN (2016). DIN SPEC 91345: Reference Architecture

Model Industrie 4.0 (RAMI 4.0). Technical report,

DIN.

Grangel-González, I., Halilaj, L., Coskun, G., Auer, S., Col-

larana, D., and Hoffmeister, M. (2016). Towards a

Semantic Administrative Shell for Industry 4.0 Com-

ponents. In Tenth IEEE Int. Conf. on Semantic Com-

puting, ICSC Laguna Hills, CA, USA, February 4-6,

pages 230–237.

Kharlamov, E., Grau, B. C., Jiménez-Ruiz, E., Lamparter,

S., Mehdi, G., Ringsquandl, M., Nenov, Y., Grimm,

S., Roshchin, M., and Horrocks, I. (2016). Captur-

ing industrial information models with ontologies and

constraints. In 15th Int. Semantic Web Conf. (ISWC),

pages 325–343.

Lee, J., Bagheri, B., and Kao, H.-A. (2015). A cyber-

physical systems architecture for industry 4.0-based

manufacturing systems. Manufacturing Letters, 3:18–

23.

Marseu, E., Kolberg, D., and Weyer, S. (2017). Exemplary

transfer of the RAMI 4.0 Administration Shell to the

SmartFactory KL System Architecture for Industrie

4.0 Production Systems. White paper, SmartFacto-

ryKL.

Negri, E., Perotti, S., Fumagalli, L., Marchet, G., and

Garetti, M. (2017). Modelling internal logistics sys-

tems through ontologies. Computers in Industry,

88:19–34.

Pethig, F., Niggemann, O., and Walter, A. (2017). To-

wards industrie 4.0 compliant conﬁguration of condi-

tion monitoring services. In 15th IEEE Int. Conf. on

Industrial Informatics, INDIN Emden, Germany, July

24-26, pages 271–276.

Platform Industrie 4.0 (2019). Details of the Asset Admin-

istration Shell. Speciﬁcation, Platform Industrie 4.0.

Ren, Y., Parvizi, A., Mellish, C., Pan, J. Z., van Deemter,

K., and Stevens, R. (2014). Towards competency

question-driven ontology authoring. In The Semantic

Web: Trends and Challenges - 11th Int. Conf., ESWC,

Anissaras, Crete, Greece, May 25-29. Proceedings,

pages 752–767.

Tantik, E. and Anderl, R. (2017). Integrated data model and

structure for the asset administration shell in Industrie

4.0. Procedia CIRP, 60:86–91.

ZVEI (2016). Beispiele zur Verwaltungsschale der Indus-

trie 4.0-Komponente – Basisteil. White paper, ZVEI.

KEOD 2020 - 12th International Conference on Knowledge Engineering and Ontology Development

172