April 2016

DIN SPEC 91345

D
ICS 03.100.01; 25.040.01; 35.240.50

Reference Architecture Model Industrie 4.0 (RAMI4.0)

English translation of DIN SPEC 91345:2016-04

Referenzarchitekturmodell Industrie 4.0 (RAMI4.0)

Englische Übersetzung von DIN SPEC 91345:2016-04
Modèle de référence de l’architecture de l’industrie 4.0 (RAMI4.0)
Traduction anglaise de DIN SPEC 91345:2016-04

There are various procedures for developing a DIN SPEC:

This document has been developed in accordance with the PAS procedure.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Document comprises 40 pages

This DIN SPEC has been developed and approved by the authors named in the Foreword.

© No part of this translation may be reproduced without prior permission of

DIN Deutsches Institut für Normung e. V., Berlin. Beuth Verlag GmbH, 10772 Berlin, Germany,
has the exclusive right of sale for DIN Specifications.
www.din.de
www.beuth.de
!%S;]"
05.16 a 2482458
 DIN SPEC 91345:2016-04

A comma is used as the decimal marker.

Contents
Page

Foreword ................................................................................................................................................................................... 4
Introduction.............................................................................................................................................................................. 5
1 Scope ............................................................................................................................................................................ 6
2 Normative references ............................................................................................................................................ 6
3 Terms and definitions ............................................................................................................................................ 6
4 Assets in Industrie 4.0............................................................................................................................................ 9
4.1 The object world ...................................................................................................................................................... 9
4.2 Information carriers............................................................................................................................................... 9
4.3 Assets and the information world ................................................................................................................... 10
4.4 Life (“vita”) and characterization of an asset .............................................................................................. 11
4.5 Means by which an asset is presented, or made known in the information system ..................... 12
4.5.1 General ...................................................................................................................................................................... 12
4.5.2 Unknown assets ..................................................................................................................................................... 13
4.5.3 Anonymously known assets .............................................................................................................................. 13
4.5.4 Individually known assets .................................................................................................................................. 13
4.5.5 Assets administered as entities ........................................................................................................................ 13
4.6 State in the lifetime (“vita”) ............................................................................................................................... 14
4.6.1 General ...................................................................................................................................................................... 14
4.6.2 Type ............................................................................................................................................................................ 14
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

4.6.3 Instance ..................................................................................................................................................................... 15

4.7 Communication capability ................................................................................................................................. 15
4.7.1 Communication capability of assets in the physical world .................................................................... 15
4.7.2 Communication capability of assets in the information world............................................................. 16
4.8 Classification of assets in terms of presentation and communication capability.......................... 17
4.9 Representation by means of information and technical functionality .............................................. 18
5 Reference Architecture Model Industrie 4.0 (RAMI4.0) ......................................................................... 19
5.1 General ...................................................................................................................................................................... 19
5.2 Architecture axis (“Layers”) .............................................................................................................................. 20
5.2.1 Overview ................................................................................................................................................................... 20
5.2.2 Business layer ......................................................................................................................................................... 20
5.2.3 Functional layer ..................................................................................................................................................... 20
5.2.4 Information layer .................................................................................................................................................. 21
5.2.5 Communication layer ........................................................................................................................................... 21
5.2.6 Integration layer .................................................................................................................................................... 22
5.2.7 Asset layer ................................................................................................................................................................ 22
5.3 Life cycle & value stream axis ........................................................................................................................... 23
5.4 Hierarchy axis ......................................................................................................................................................... 23
6 Industrie 4.0 components................................................................................................................................... 24
6.1 General ...................................................................................................................................................................... 24
6.1.1 Overview ................................................................................................................................................................... 24
6.1.2 Properties of I4.0 components ......................................................................................................................... 24
6.1.3 Identifiability .......................................................................................................................................................... 25
6.1.4 State in the lifetime (“vita”) ............................................................................................................................... 25
6.1.5 Secure I4.0-compliant communication, services and quality of service ........................................... 25
6.1.6 Representation by information with I4.0-compliant semantics .......................................................... 26

2
 DIN SPEC 91345:2016-04

6.1.7 I4.0 system consisting of I4.0 components .................................................................................................. 27

6.1.8 Nestability ................................................................................................................................................................ 27
6.1.9 Encapsulability ....................................................................................................................................................... 28
6.1.10 Domain specific functionality and state model .......................................................................................... 29
6.2 Administration shell of I4.0 components ..................................................................................................... 30
6.2.1 General ...................................................................................................................................................................... 30
6.2.2 Basic structure of the administration shell ................................................................................................. 30
6.2.3 DF header and DF body ....................................................................................................................................... 30
6.2.4 Partial models and views.................................................................................................................................... 31
6.2.5 Properties................................................................................................................................................................. 33
6.2.6 Managing the administration shell ................................................................................................................. 35
6.2.7 Fundamental requirements for the administration shell ...................................................................... 37
6.3 Forms of I4.0 components .................................................................................................................................. 38
6.3.1 Different assets with administration shells................................................................................................. 38
6.3.2 Asset with multiple administration shells ................................................................................................... 39
6.3.3 Administration shell for multiple assets ...................................................................................................... 39
Bibliography ........................................................................................................................................................................... 40
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

3
 DIN SPEC 91345:2016-04

Foreword
This DIN SPEC has been developed according to the PAS (Publicly Available Specification) procedure. DIN
SPECs developed according to the PAS procedure are prepared in workshops that do not necessarily include
all stakeholders.
The following initiators and authors developed and approved this document 1):
 Plattform Industrie 4.0
Dr.-Ing. Peter Adolphs
 HARTING IT Software Development GmbH & Co KG
Dr. Stefan Berlik
 Bitkom Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V.
Wolfgang Dorst
 IBM Deutschland
Dr. Jochen Friedrich
 HARTING KGaA
Dr. Christoph Gericke
 Bosch Rexroth AG
Martin Hankel
 Kommunikationslösungen e. K.
Roland Heidel
 Festo AG & Co. KG
Dr. Michael Hoffmeister
 VDMA
Dr. Christian Mosch
 DKE Deutsche Kommission Elektrotechnik Elektronik Informationstechnik in DIN und VDE
Reinhold Pichler
 Fraunhofer IPA
Ursula Rauschecker
 GE Intelligent Platforms GmbH
Thomas Schulz
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

 Deutsche Telekom AG
Dr. Karsten Schweichhart, Ernst Joachim Steffens
 Cluster Industrie 4.0
Michael Taube
 Siemens AG
Ingo Weber
 Technische Universität Dresden
Prof. Martin Wollschlaeger, Stefan Mätzler
At present there are no standards on this topic.
DIN SPECs are not part of the body of German Standards.
No draft of this DIN SPEC has been published.
Despite every effort to ensure that technical and non-technical descriptions are correct, reliable and precise,
the workshop can neither explicitly nor implicitly guarantee that the content of the document is correct.
Users of this document shall be aware that the workshop cannot be held liable for any kind of damage or
loss. Application of this DIN SPEC does not absolve users of responsibility for their own actions, and they do
so, therefore, at their own risk.
Attention is drawn to the possibility that some elements of this document may be the subject of patent rights.
DIN [and/or DKE] shall not be held responsible for identifying any or all such patent rights.

Provision of this document free of charge as a PDF via the Beuth Webshop has been financed in advance.

1) All members of the workshop who voted to publish the DIN SPEC are named as authors in this foreword along with
the organizations to which they belong. The authors are listed in alphabetical order of their surnames. Any
workshop members who abstained or voted against the publication of the DIN SPEC are not named in this foreword.

4
 DIN SPEC 91345:2016-04

Introduction
The fundamental purpose of Industrie 4.0 is to facilitate cooperation and collaboration between technical
objects, which means they have to be virtually represented and connected. In this context, a technical object
is an object that is of value to an organization, which therefore not only means physically tangible objects,
but also intangible objects such as ideas, archives and software. The concept of Industrie 4.0 is intended to
create digital description rules for a technical object throughout its entire lifetime, and for the associated
changes in value, in the form of the Reference Architecture Model for Industrie 4.0 “RAMI4.0”. The purpose
of this model is to represent the technical object, and all aspects relevant to it, from its development,
production and use right through to its disposal. The Industrie 4.0 component provides a digital description
of the object, making it possible to represent that object virtually.

Technical objects are intentionally manufactured in order to fulfil a specific purpose. They possess common
characteristics in terms of their lifetime and the associated changes in value. Technical objects for which a
“change in value” or an “owner” are important aspects are also referred to as “technical assets”. Because this
is almost always the case, the terms “technical object” and “technical asset” can be regarded as synonymous.
In this document, the term “technical asset”, or simply “asset” is used.

This document describes two fundamental reference models for the Industrie 4.0 concept:

 The reference architecture model RAMI4.0 is a reference model for an Industrie 4.0 reference
architecture and gives a structured description of fundamental ideas.

 The I4.0 component reference model provides digital access to this description.

The central concept of Industrie 4.0 is that assets can be combined in any way, and these assets are formally
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

described in sufficient detail for use in the digital world. This methodology not only enables sufficiently
generic descriptions of a configuration, but through an increasing degree of detail also allows for very
specific descriptions. This is a core concept regardless of the way in which the asset is used.

To virtually represent configurations of assets and the connections between them, the “principle of recursive
description of assets” is used to characterize an asset as follows:

 The structural description is compliant with RAMI4.0;

 A configuration of two or more assets collectively forms a new asset, which is described using RAMI4.0;

 Components of an asset can themselves represent separate assets that are described with RAMI4.0;

 The asset description is provided as structured information in the administration shell of the I4.0
component that acts as a virtual representation of an asset.

This means that any configuration can be digitally represented to any degree of granularity by describing
structured assets, and combinations thereof, using RAMI4.0.

5
 DIN SPEC 91345:2016-04

1 Scope
This DIN SPEC describes a reference architecture model in the form of a cubic layer model, which provides
an architecture for technical objects (assets) in the form of layers, and allows them to be described, tracked
over their entire lifetime (or “vita”) and assigned to technical and/or organizational hierarchies.

It also describes the structure and function of Industrie 4.0 components as essential parts of the virtual
representation of assets.

2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.

DIN EN 61360-1, Standard data element types with associated classification scheme for electric components —
Part 1: Definitions — Principles and methods (IEC 61360-1)

DIN EN 61360-2, Standard data element types with associated classification scheme for electric components —
Part 2: EXPRESS dictionary schema (IEC 61360-2)

IEC/TR 62794, Industrial-process measurement, control and automation — Reference model for
representation of production facilities (Digital Factory)

IEC/TS 62832-1, Industrial-process measurement, control and automation — Digital Factory framework —
Part 1: General principles
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

3 Terms and definitions

For the purposes of this document, the following terms and definitions apply:

3.1
architecture
combination of elements of a model based on principles and rules for constructing, refining and using it

3.2
archive world
all the information in the digital world which is no longer valid or up-to-date and which therefore can no
longer be changed

Note 1 to entry: Information which is no longer valid or up-to-date is transferred to the archive world.

Note 2 to entry: No statement is made on when the information is transferred from the model world or state world
to the archive world.

3.3
asset
object which has a value for an organization

6
 DIN SPEC 91345:2016-04

3.4
service
separate scope of functions offered by an entity or organization via interfaces

Note 1 to entry: This definition is not the same as the definition of services by the OASIS-RM (“Services are the
mechanism by which needs and capabilities are brought together”).

3.5
entity
uniquely identifiable object which is administered in the information world due to its importance

3.6
information world
(also: digital world or cyber world)
ideas, concepts, algorithms, models and entirety of representations of physical objects and people in the
virtual environment

Note 1 to entry: The framework for considering each entirety needs to be defined.

Note 2 to entry: The elements of the information world can be semantically related to each other.

3.7
component manager
organizer of autonomous administration and access to resources of the relevant I4.0 component, such as the
I4.0 component itself, object, technical functionality, virtual representation

Note 1 to entry: In many documents the component manager is referred to as the resource manager, but this should
be called the component manager in future.

3.8
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

manifest
externally accessible, defined set of meta-information on the functional and non-functional properties of the
relevant I4.0 component

Note 1 to entry: The manifest can be regarded as similar to the manifest in information technology.

3.9
physical world
all actually existing objects and people

Note 1 to entry: The real world is the same as the physical world.

Note 2 to entry: Loaded or stored software is part of the physical world.

Note 3 to entry: The framework for considering each entirety needs to be defined.

7
 DIN SPEC 91345:2016-04

3.10
reference architecture
model for an architecture description (for I4.0) which is generally used and recognized as being suitable (has
reference character)

Note 1 to entry: A reference architecture can be defined on the basis of a reference model.

3.11
reference model
model that is generally used and recognized as being suitable (has recommendation character) for deriving
specific models

3.12
administration shell
virtual digital and active representation of an I4.0 component in the I4.0 system

Note 1 to entry: An administration shell contains the manifest and the component manager.

3.13
value-added chain
sequence of processes that add value (linear or hierarchical, which formally means acyclically aligned)

Note 1 to entry: Company boundaries are not necessarily relevant for a value-added chain or value chain.

3.14
value-added system
network or system of value-added chains that can include connections and dependencies between them

3.15
value-added process
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

process during which a commodity can be created which is valuable for a customer

Note 1 to entry: The commodity does not have to be tangible (such as a raw material or manufactured product), but
can also be intangible (such as knowledge, information or a service).

Note 2 to entry: The determination of value or price is not considered here.

Note 3 to entry: Value-added processes are value activities according to Porter.

8
 DIN SPEC 91345:2016-04

4 Assets in Industrie 4.0

4.1 The object world

Figure 1 shows the structure of the object worlds. In the object world of Industrie 4.0, assets from the
information world and the physical world are considered. Besides these assets, people (the human world)
also play an important part. The information world is divided into the model world, the state world and the
archive world. The model world contains objects such as meta-documents, models, concepts, technical
documentation, production plans and procedural descriptions. The state world describes the current state.
The archive world contains the recorded state and life cycle information of processes that have taken place.
These can be production processes, development processes, maintenance processes and so on.

The physical world includes all physical products, installations, resources, IT systems, loaded programs, etc.
When classifying software, it should be noted that the algorithm itself belongs to the information world, but
the executable program loaded to a system is part of the physical world. People are part of the physical
world and participate in the information world. Because of their intelligence and freedom to make decisions
human beings have a special status.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Figure 1 — Structure of the object worlds with examples

4.2 Information carriers

Figure 2 shows examples of various carriers of information. A plan, for example, can be stored as an xml or
pdf file on a computer. It can also be inside somebody’s head or printed out on a piece of paper. In each case,
the information asset “plan” is the same. The character of the physical carrier does not alter the information
asset. If the carrier is destroyed, so is all the information stored on it. To prevent information from being lost,
copies of it can be made on multiple carriers. However, they are all still the same asset.

9
 DIN SPEC 91345:2016-04

Figure 2 — Assets in the information world and their physical carriers

4.3 Assets and the information world

Every asset has a value for an organization. It represents an artefact that is specifically intended to perform a
particular role in a particular system. Assets are intentionally manufactured in order to fulfil a specific
purpose. They possess a common “vita”, or lifetime, and the associated change in value. Assets for which a
“change in value” or an “owner” are important aspects are also referred to as “technical assets”.

The key task in Industrie 4.0 is to take technical assets from the physical world and virtually represent them
in the information world. The physical world is to be understood to mean the entirety of all real assets and
people.

The following applies to every asset:

Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

 The asset is designed, created, used and disposed of;

 The asset can be an idea, a software program, an archive, a service or any physical item (in other words
it does not have to exist in a physical form);

 The asset has a lifetime;

 The asset is clearly identifiable;

 The asset is represented in the virtual world by its administration shell;

 The asset can have multiple virtual representations specified according to the rules of Industrie 4.0 for
different purposes;

 Assets can be combined to create new assets with different properties;

 The asset is characterized in a process by means of time, location and state;

 Each piece of information has a carrier;

 The asset’s characteristics are described using Industrie 4.0 vocabulary that includes a collection of
terms which describe properties.

EXAMPLE Assets in the context of Industrie 4.0 are whole installations or parts thereof, electronic modules,
subsystems and systems, machinery, plants and networks, services, concepts and ideas, plans, archives and programs.

10
 DIN SPEC 91345:2016-04

Figure 3 — Life (“vita”) of an asset

4.4 Life (“vita”) and characterization of an asset

Each asset has a specific lifetime, during which it serves the purpose for which it was specifically created
(see Figure 3). The way it is created depends on the type of asset. Creation can mean development (of a
type), engineering (of a plant), measurement (of a status), construction (of an installation) or production (of
a product). In this context, these are all creation processes. Once an asset is created, it exists, but it is not yet
ready to use. The provision phase includes all processes between the time the product is created and the
time it is ready and working at the place of use. Provision processes include shipping, transport,
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

warehousing, configuration and assembly, and for software assets, processes such as release, downloading
and installation. After provision, the asset is installed and ready to use on site, in other words, it is ready to
perform its intended role as a technical device. In the subsequent phase, two different uses of the asset must
be taken into account: usage and maintenance. When being used, the asset is part of the technical system for
carrying out the desired technical (production or usage) processes. During maintenance, the asset is still a
product whose functionality must be maintained or restored. Maintenance can be carried out by the user, by
an external workshop or by the manufacturer. The work can take place on site, by remote maintenance or
(for example after it is removed) at a workshop. Certain maintenance procedures can be regarded as a loop,
involving a renewed manufacturing phase and recommissioning, while others are simply a change of status
of the asset in use.

As regards the information world, an asset can be characterized as shown in Figure 4. It:

 is presented, or made known, in a certain way (i.e. is known or not known to a certain degree);

 has a specific state within its life (at least a type or instance);

 has communication capability;

 is represented by means of information (data);

 has technical functionality.

11
 DIN SPEC 91345:2016-04
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Figure 4 — Concepts of an asset

4.5 Means by which an asset is actively presented, or made known, in the information
system

4.5.1 General

An asset exists in itself and has a specific lifetime. This is true for all types of asset. Initially, however, the
existence of the physical asset, its identity, state and lifetime (“vita”) are not known in the information
system. One of the most important questions of system design is whether and to what extent this
information is made known to the information system, and how much of that information is presented in the
system.

An asset in the information world is at the very least known in its own information system. If information on
physical assets is contained within the information system, then the administration objects that manage the
asset need to be created and supplied with information. An asset can be classified as follows, depending on
the amount of information available in the information system:

 unknown;

 anonymously known;

 individually known;

 administered as an entity.

12
 DIN SPEC 91345:2016-04

4.5.2 Unknown assets

An unknown asset is one that is not known in the information world.

4.5.3 Anonymously known assets

An anonymously, not individually known asset is one which can only be recognized in the information world
as an asset of a particular type at a particular place.

EXAMPLE A screw is in a box with other screws. Even if the number of screws in the box is known, no individual
properties can be assigned to any of the screws other than the general ones common to that type. If an asset that is not
individually identifiable is included in a system, then it can be indirectly identified by means of its location. If a screw is
installed in a plant, then it can be determined that precisely that screw installed at that particular location is rusty and
has to be replaced. However, this is only true as long as the screw is installed. Once it is removed, it ends up in the scrap
bucket and can no longer be identified. The same goes for products such as punched parts. During the punching process
it is possible to identify which punched part is in which section of the matrix. After it is discharged, the part is no longer
individually identifiable, but the information system still knows that this punched part exists and is in the discharge
container.

4.5.4 Individually known assets

An individually known asset is unambiguously identifiable. It has a unique name that is known in the
information world. The system has an identification method with which the asset can be identified in the
physical world and assigned to the name object.

NOTE Here it is irrelevant which technology is used for identification: it can be an ID code physically attached to
the asset (nameplate with serial number, barcode, RFID, etc.), an analysis of characteristic physical properties
(fingerprint etc.) or a deterministic and systematic tracking strategy in the system (coil, batch, etc.). In each case, the
detected asset can be assigned unambiguously to the name object in the information world.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

4.5.5 Assets administered as entities

An entity is an unambiguously identifiable asset which, due to its importance, is administered in the
information world.

Entities are assets that possess objects of their own so that they can be administered and used, in other
words they are represented by information.

Their representation by information means that data on the asset is kept. This data can be kept either on or
in the relevant I4.0 component (as described in Clause 6) and can be made available to the outside world
using I4.0-compliant communication. Alternatively, the data can be kept on a (higher-level) IT system that
makes it available to the outside world by means of I4.0-compliant communication.

I4.0-compliant communication must take place in such a way that it is possible to access the information of a
representation of the relevant I4.0 component either in the asset itself or in a (higher-level) IT system.

The functionality thus available in the information system goes far beyond mere identification. It includes
functions for purposes such as tracking assets, recording lifetime data, operational management of the
company’s own production process, and automated monitoring and quality assurance. If the administration
functions are encapsulated in a functional unit and carry out their tasks proactively, the functional unit is
known as a component manager (see Figure 5).

13
 DIN SPEC 91345:2016-04

Whether or not an asset is regarded as an entity is a design decision in each individual case. As shown in
Figure 5, entities can not only be assets in the physical world, but also assets in the information world.

EXAMPLE The lifetime of a radar probe is documented on the left of Figure 5. The radar probe is regarded as an
entity and is given its own component manager. The example on the right documents the lifetime (creation, release and
maintenance processes) of a diagram (P&ID). The P&ID becomes an entity and is also given its own component
manager. In the model used here, the asset itself is conceptually separate from its administration.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Figure 5 — Component manager for administering entities

4.6 State in an asset’s lifetime (“vita”)

4.6.1 General

Throughout its lifetime, an asset has a particular state at a particular time at a particular location. This state
can be described more precisely using additional information. When observing an asset, a distinction is
made between type and instance. Depending on how the asset is used in the value-added chain, the
properties and state of its type or of its specific instance are relevant. Both types and individual instances are
subject to usage and maintenance.

4.6.2 Type

The type of an asset defines the sum of the properties which are characteristic for all instances of that
particular asset. The type of an asset is unambiguously identifiable and arises with the initial idea, in other
words when it is created, e.g. during the development phase. This means, for example, ordering,
development and testing, right up to the initial sample and prototype production. Once all tests required for
validation are completed, the type is released for series production, which means that instances of that type
can be produced.

14
 DIN SPEC 91345:2016-04

4.6.3 Instance

An instance is a specific, unambiguously identifiable asset that is characterized by the properties of a type.
An instance always has a unambiguously relationship to its type.

For a physical asset, concrete assets are created in production on the basis of the type. Each manufactured
asset represents an instance of a type and can be utilized. The instances can be sold, delivered to customers,
used by customers and maintained.

For an asset in the information world, instances are created on the basis of the type, for example by
allocating and initialising data structures, which are used, modified and later released again.

4.7 Communication capability

4.7.1 Communication capability of assets in the physical world

4.7.1.1 General

Assets in the physical world can have a physical application (e.g. a pipe, or a cable), can function as
information carriers (e.g. a server) or do both together (e.g. an “intelligent” field device). Because they carry
information, assets in the physical world must be integrated in the technological information network of a
system for communication purposes. Communication capability always refers to the ability to communicate
using digital communication systems (such as field bus or TCP/IP communication).

Assets can be placed in the following categories according to their communication capability:

 assets without communication capability;

Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

 assets with passive communication capability;

 assets with active communication capability (basic component);

 assets with I4.0-compliant communication capability (I4.0 component).

4.7.1.2 Assets without communication capability

A physical asset has no communication capability if it either has no functionality as an information carrier at
all (such as screw, cable or tank) or if it has information carrier functionality but no digital interface (such as
a smart conventional washing machine or a smart 4-20mA field device without HART).

4.7.1.3 Assets with passive communication capability

If an asset has an information carrier which can be read via interfaces, it has passive communication
capability. The information carrier itself is passive, but allows its data to be read and the asset to be
identified, for example (RFID, barcode, etc.).

4.7.1.4 Assets with active communication capability (basic components)

A physical asset that is capable of actively taking part in network communication is regarded as a basic
component in terms of digital communication. It actively identifies itself on making contact with the network
and logs in to participate in communication.

15
 DIN SPEC 91345:2016-04

4.7.1.5 Assets with I4.0-compliant communication capability (I4.0 components)

An asset that has all the capabilities of an I4.0 service system user is known as an I4.0 component due to its
special role in the I4.0 system. I4.0 components whose software and hardware form a unit are called
autonomous I4.0 components.

For an I4.0 component to be able to provide information, it must at least have a connection to the asset via an
information system. This means that passive communication capability is a minimum prerequisite. To also
be able to integrate an asset that is passively or actively capable of communication, but not I4.0-compliant, a
higher-level IT system can be used as proxy for I4.0-compliant communication based on a service-oriented
architecture (SOA).

EXAMPLE In this way, an identifiable terminal block can become an I4.0 component.

4.7.2 Communication capability of assets in the information world

4.7.2.1 General

In addition to the physical components, assets from the information world can also be classified according to
the same scheme.

4.7.2.2 Assets without communication capability

The data carrier is not capable of communication. All the data on it is not capable of communication.

EXAMPLE Physical nameplate of a device, P&ID information as paper printout.

4.7.2.3 Assets with passive communication capability

Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

The asset does not communicate actively. However, the data is stored on the carrier in a form that can be
read (and possibly written) in the system.

4.7.2.4 Assets with active communication capability

The data is administered in an active software component. The software component is able to actively take
part in system communication. The software component identifies itself when activated and logs in to
participate in the exchange of information in the system.

4.7.2.5 Assets with I4.0-compliant communication capability (I4.0 components)

An I4.0 component which represents an asset has all the capabilities of an I4.0 service system user. Unlike an
I4.0 component representing an asset from the physical world, this kind of I4.0 component represents an
I4.0 software component.

NOTE Both 4.7.1.5 and 4.7.2.5 describe I4.0 components.

16
 DIN SPEC 91345:2016-04

4.8 Classification of assets in terms of presentation and communication capability

The means by which an object is administered in the information system, and thus its presentation, or
“publicity”, in that system, are independent of its communication capability. This means that an important
unit in the system, for example an engine, can be administered as an entity, even if it is entirely incapable of
communication. It must then be tracked and its state recorded using external measurement and
identification systems or by human beings in person.

NOTE 1 In order to administer an entity it is useful if the entity asset is at least capable of passive communication
(for example using signal interfaces or RFID), but this is not a prerequisite.

Figure 6 illustrates the classification system. The administration class of each object – i.e. its presentation , or
“publicity”, in the information system – can be freely chosen and is a design decision.

Communication capability is useful, but not essential, for administering the object. Conversely however, a
particular communication capability requires that the object be sufficiently identifiable, in other words it has
to be sufficiently known, in the information system.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Figure 6 — Active presentation of an asset in the information system

and its communication capability

Because of the importance of an object’s communication capability and presentation, or “publicity”, its
assignment to a certain class can be expressed using “CP” and a number. CP stands for “Communication” and
“Presentation”. This type of notation is similar to such widely used notation systems as that for IP protection
classes. Figure 7 illustrates the CP notation system.

EXAMPLE CP33 denotes an individually known component capable of active communication, for example a
classical field device with a field bus connection. The CP class for a security container which is monitored throughout its
life but is not capable of any kind of communication would be CP14.

NOTE 2 According to the system shown in Figure 7, an I4.0 component is either a CP24, CP34 or CP44 component.

17
 DIN SPEC 91345:2016-04

Figure 7 — CP notation system for classifying according to

communication capability and presentation (“publicity”)

In order to assign data and functions to an asset, it has to exist as an entity.

NOTE 3 Software, which in the conventional sense can be delivered both physically and non-physically, is also an
asset. Ideas, archives and concepts are also assets in this sense.

NOTE 4 Because the purpose of an I4.0-compliant asset is to provide data and functions within an information
system, individually known assets are entities by their very nature.

4.9 Representation by means of information and technical functionality

Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Representation by means of information encompasses all data and properties which characterize an
associated asset or represent important information for other assets.

The functions of an asset represent its actual “technical” functionality.

18
 DIN SPEC 91345:2016-04

5 Reference Architecture Model Industrie 4.0 (RAMI4.0)

5.1 General
The reference architecture model Industrie 4.0 (RAMI4.0) provides a structured description of the main
elements of an asset using a level model consisting of three axes, as shown in Figure 8. Complex
interrelationships can thus be broken down into smaller, more manageable sections by combining all three
axes at each point in the asset’s life to represent each relevant aspect.

The three axes are:

 The architecture axis (“Layers”), with six layers to represent the information that is relevant to the role
of the asset;
 The “Life cycle & value stream” axis to represent the lifetime of an asset and the value-added process,
based on IEC 62890;
 The “Hierarchy levels” axis for assigning functional models to specific levels, based on the
DIN EN 62264-1 and DIN EN 61512-1 standards.

The aim of the reference architecture model Industrie 4.0 (RAMI4.0) is to describe assets and combinations
of assets with sufficient precision.

The description in RAMI4.0 is a purely logical one. The actual implementation can be different from the
logical description. For example, an MES function for a machine is logically described on the hierarchical
level “Work centres”. However, when it is implemented, this function might be implemented in the
hierarchical level “Station”.

Security is an elementary aspect of RAMI4.0 and must always be included in the description of each section
of the three axes.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Figure 8 — Reference architecture model Industrie 4.0 (RAMI4.0)

19
 DIN SPEC 91345:2016-04

5.2 Architecture axis (“Layers”)

5.2.1 Overview
The vertical axis describes the architecture in terms of properties and system structures with their functions
and function-specific data in the form of layers.

The six architectural layers are used on the vertical axis to describe the structural properties of an asset or
combination of assets:
 Business;
 Functional;
 Information;
 Communication;
 Integration;
 Asset.
Layers do not always have to have content.

There is a loose connection between the layers. Interactions may only take place between two adjacent
layers or within a layer. Layers are never skipped. Interactions may be passed through.

5.2.2 Business layer

The “Business” layer describes the commercial view. This includes:
 General organizational boundary conditions (such as order commissioning, general ordering conditions
or regulatory provisions);
 Monetary conditions (price, availability of resources, discounts, etc.);
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

 Ensuring the integrity of functions in the value-added chain;

 Modelling rules that the I4.0 system must follow;
 Mapping business models and the resulting business processes;
 General legal and regulatory conditions;
 Orchestration of services on the “Functional” layer;
 Links between different business processes;
 Receipt of events in order for a business process to go to the next stage.
NOTE The functionality of the “Business” layer is not related to specific solutions, such as Enterprise Resource
Planning (ERP). ERP functions are typically assigned to the “Functional” layer.

5.2.3 Functional layer

The “Functional” layer describes (logical) functions of an asset (technical functionality) with regard to its
role in the Industrie 4.0 system.

These include the:

 formal, digital description of functions;
 platform for horizontal integration of different functions;
 runtime and modelling environment for services and business processes;
 runtime environment for applications and technical functionality.

20
 DIN SPEC 91345:2016-04

5.2.4 Information layer

The “Information” layer describes the data that is used, generated or modified by the technical functionality
of the asset.

This includes the:

 runtime environment for (pre-)processing the event;

 execution of rules;

 formal description of models and rules;

 persisting of data represented by the models;

 ensuring the integrity of data;

 consistent integration of different data;

 acquiring new, higher quality data (data, information, knowledge);

 providing structured data via service interfaces;

 receiving events and transforming them into a suitable form for the data available to the functional
layer;

 context pre-processing.

NOTE Context pre-processing is, for example, when one or more events have rules applied to them to generate one
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

or more other events which then initiate processing in the functional layer.

5.2.5 Communication layer

The “Communication” layer describes Industrie 4.0-compliant access to information and functions of a
connected asset by other assets. In other words, it describes which data is used, where it is used and when it
is distributed.

NOTE 1 Current field buses, RFID, QR codes, etc. are not part of the “Communication” layer, but part of the
“Integration” layer.

NOTE 2 The transferred information and functions are not only of essential importance during their (operational)
utilization, but also in all other phases of the asset’s lifetime.

EXAMPLE

 Standardized I4.0 communication using a uniform data format;

 Providing services, for example as information functions based on a service-oriented architecture (SOA).

21
 DIN SPEC 91345:2016-04

5.2.6 Integration layer

The “Integration” layer represents the transition from the physical world to the information world. It
describes the infrastructure that exists in order to implement a function (resource). This layer is where the
properties and process-related functions that make the asset usable for its intended purpose are stored.

NOTE The advantage of structuring in the asset layer and the integration layer is that in the higher layers it does
not matter whether a subfunction is carried out in the physical world, i.e. physically in the integration layer, or in the
form of software, in other words as a program in the functional layer.

The content of the integration layer includes:

 Providing the representation of the actual resource of an asset by means of information on assets,
physical objects, hardware, documents, software/firmware, etc.;

 Describing the technical elements, such as RFID readers, sensors, human-machine interfaces (HMI) and
signal converters;

 Computer-aided control of technical (sub)processes;

 Generating events from real assets;

 A human-machine interface (HMI).

Each important event in the real world generates an event in the virtual world, in other words in the
integration layer and possibly higher layers too. If reality changes in the physical world, this event is
reported to the integration layer.

Relevant events can therefore trigger events in the information layer and higher layers via the
communication layer.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

5.2.7 Asset layer

The “Asset” layer represents reality, i.e. the asset that actually exists in the physical world. It is the material
reality which is virtually represented in the layers above it.

For every relevant item in the “Asset” layer, an item must exist in the higher-level layers of the digital world.
However, not every relevant item in the digital world has a corresponding item in the “Asset” layer.

EXAMPLE A relevant property of an existent machine part appears as a representation in the “Integration” layer.
If the machine part is scrapped, it disappears from the physical world, but remains, for example, as a plan in the archives
in the information world of the “Integration” layer or the “Information” layer.

The “Asset” layer represents

 the physical world, that is all real, existing assets as defined by Industrie 4.0 and by humans, e.g. physical
elements such as linear axes and sheet metal parts, services, documents, circuit diagrams, ideas and
archives,

 the interface between humans and the information world, and

 the connection of the assets to the “Integration” layer.

Multiple assets described according to RAMI4.0 in the “Asset” layer can be combined to form a more complex
asset. For this, all the individual assets and the new, more complex asset must be described according to the
rules of the reference architecture model.

22
 DIN SPEC 91345:2016-04

5.3 Life cycle & value stream axis

The “Life cycle & value stream” axis is used to describe an asset at a particular point in time during its
lifetime, from its production and value-added use right up to its disposal.

On this axis, the asset is characterized by its state at a particular time at a particular location.

5.4 Hierarchy axis

The “Hierarchy” axis is based on the reference architecture model for a factory along the lines of
DIN EN 62264-1 (IEC 62264-1) and DIN EN 61512-1 (IEC 61512-1), the standards for integrating enterprise
IT and control systems. To ensure a consistent consideration across as many sectors as possible from factory
automation to the process industry, the terms “enterprise”, “work centres”, “station” and “control device”
have been taken from the above-mentioned standards (see Figure 9). The following hierarchy levels have
been modified and supplemented to reflect the needs of Industrie 4.0:

 “Connected world” describes the relationship between an asset or combination of assets (such as an
installation or company) and another asset or combination of assets (another installation or company),
in other words, for example, a network of factories;

 “Field device” has been added as a hierarchical level;

 “Product” denotes the cooperating or collaborating product to be manufactured as an integral part of an

Industrie 4.0 value-added process.

NOTE For the asset “production plant” for example, the reference architecture model Industrie 4.0 thus enables a
homogeneous consideration of the product to be manufactured and the production plant, with all their dependencies
and relationships.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Figure 9 — Hierarchical levels of RAMI4.0

23
 DIN SPEC 91345:2016-04

6 Industrie 4.0 components

6.1 General

6.1.1 Overview

Industrie 4.0 components (I4.0 components) are globally and uniquely identifiable participants capable of
communication, and consist of the administration shell and the asset (as in Figure 10) with a digital
connection within an I4.0 system (corresponding to CP24, CP34 or CP44), and offer services there with
defined quality of service (QoS) properties.

Assets of different types with different communication capabilities can be implemented as I4.0 components.
I4.0 components offer graduated protection for services and data, including information security, at a level
appropriate to their use.

In industrial applications, an I4.0 component can be a production system, an individual machine or unit, or a
module within a machine.

Figure 10 shows that an asset is not necessarily an I4.0 component. Only if it is an entity, has at least passive
communication capability and has been equipped with an “administration shell” does an asset become an
I4.0 component.

The administration shell includes the relevant information for representing the asset and its technical
functionality. It provides the information world with information on the asset or multiple assets, structured
according to RAMI4.0.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Figure 10 — An I4.0 component as a necessary connection between the asset

and the administration shell

6.1.2 Properties of I4.0 components

The term “component” is a general one. It denotes an asset in the physical world or the information world
which performs or is intended for a specific role in its system environment. A component can be a pipe, a
PLC function module, a lamp or a valve to an intelligent drive unit, for example. What is important is that it
be viewed as a unit, and the role (technical functionality) that an I4.0 component should perform or already
performs in a system. An I4.0 component is a special type of component. I4.0 components are characterized
by the fact that they meet certain requirements with regard to the classification properties described above.

24
 DIN SPEC 91345:2016-04

NOTE An I4.0 system can also include components that do not meet I4.0 requirements and are therefore not I4.0
components.

To present information on its assets in the information world, an I4.0 component has the following
properties based on the specifications in 4.4. It is:

 clearly identifiable as an entity,

 either a “type” or an “instance” in terms of a specific point in its lifetime,

 capable of active or passive I4.0-compliant communication (digital connection within an I4.0 system),

 a representation of an asset by means of information, and

 may have a technical functionality

with a level of protection appropriate for its use. The security capabilities of an asset must comply with the
required security capabilities of the administration shell.

6.1.3 Identifiability

An I4.0 component is uniquely identifiable in the network, which means that the physical asset it represents
can be found using a unique identifier (ID). If it is a CP34 or CP44 component (as described in 4.8), it can be
contacted via a communication address (such as an IP address). An active I4.0 component can perform
I4.0-compliant communication by itself, while for a passive I4.0 component this is done by the necessary
infrastructure.

6.1.4 State in the lifetime (“vita”)

Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

The information in Subclause 4.6 applies here.

Because each I4.0 component is part of a network with particular tasks, and these tasks have to be carried
out in processes in a coordinated manner, it must be possible at all times for other users to query the state of
each I4.0 component in an I4.0-compliant communication network. This information is used, for example, for
local administration of other I4.0 components and global administration for coordinating processes.

NOTE A distinction must be made between types and instances of assets, so that a relationship can also be
established between component producers and users that makes it possible to pass on refinements of assets as a type to
users when required, and conversely to pass on feedback from users to the producer.

6.1.5 Secure I4.0-compliant communication, services and quality of service

I4.0 components communicate with each other on the basis of a service-oriented architecture (SOA),
including common I4.0-compliant semantics. An I4.0 component provides information about itself using
services based on a service model. An appropriate profile for an I4.0 component describes which services are
implemented, and what technology is used for this.

It must be possible for I4.0 components to use different communication protocols. Therefore, it should be
possible to load optional protocols and application functions later on.

A distinction is to be made between the addressing of the I4.0 component and the addressing of its
(application) objects. These are addressed using a globally unique ID that is independent of the
manufacturer.

25
 DIN SPEC 91345:2016-04

I4.0 components support the generally standardized (and also subsequently loadable) service functions and
states for an I4.0 system. They possess the properties required for this task in the form of qualities of service
(QoS), which also include (information) security properties. With regard to use in automation technology,
these must be properties which are agreed or stored in a profile, such as:

 the real-time range for productive communication, e.g. determinism with real time capability of D1 ms;

 maximum fail-safe security as regards the surrounding network architecture (robustness);

 sufficiently granular clock synchronization;

 interoperability;

 diagnosis and engineering based on uniform rules;

 establishment of ad hoc connections.

Depending on the requirements for the administration shell and associated assets, the following is essential
for security:

 The confidentiality, integrity of the data, functions and availability of the technical functionality must be
ensured, also as regards the functions of the associated asset (CIA: confidentiality, integrity, availability).
This also applies to saved information which is to be transferred;

 When using data beyond company boundaries (for example in the cloud), pseudo- or full anonymization
of personal data is to be taken into account, as is any inter-company system of identity and rights
management.

6.1.6 Representation by information with I4.0-compliant semantics

Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

An I4.0 component provides its representation, including its dynamic behaviour, using standardized, I4.0-
compliant semantics.

This information is generated according to RAMI4.0 as a virtual, structured representation of the real asset
in an I4.0-compliant data format. One part of this representation is the manifest, which must have I4.0-
compliant semantics.

The properties and functions of the asset are classified using the following data elements:

 general business conditions (Business);

 mechanics (Construction);

 functionality (Function);

 place (Location);

 capability (Performance).

26
 DIN SPEC 91345:2016-04

IEC/TR 62794 applies to the specification of data elements, and DIN EN 61360-1 (IEC 61360-1) and
DIN EN 61360-2 (IEC 61360-2) apply to the specification of properties.

Each I4.0 component has a minimum infrastructure for ensuring the (information) security function.
Because security is only assured if the production process is included in the considerations, the security
infrastructure of an I4.0 component is a necessary functionality, but not in itself sufficient. The requirements
of the “security by design” principle (SbD) must be fulfilled.

In addition, applications for functional safety also require an infrastructure where functional safety and
information security cannot negatively affect each other.

6.1.7 I4.0 system consisting of I4.0 components

An I4.0 system consists of I4.0 components and components of a lower CP classification;

 it serves a particular purpose,

 has specified properties and

 supports standardized services and states.

Such an I4.0 system can be an I4.0 component of its own in another I4.0 system.

A network of I4.0 components must be structured in such a way that connections are possible between
different end points (I4.0 components). The I4.0 components and their content comply with a common
semantic model. Assets which are combined can form any kind of system. If they are I4.0 components, they
form an I4.0 system. From the point of view of the system, I4.0 components have the following important
properties:
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

 nestability;

 encapsulability.

6.1.8 Nestability

As shown in Figure 11, any I4.0 component can consist of other I4.0 components, which means an I4.0
component can be logically nested (including temporarily if necessary). Higher-level systems should have
limitable, purpose-related access to all I4.0 components, even if they are (temporarily) logically assigned.

NOTE In the context of this document, I4.0 components represent assets such as production systems, machinery,
units and conceptually important parts, such as machine modules. This means a machine can be an I4.0 component. It
can itself consist of separate I4.0 components. In turn, individual machine modules can be composed of I4.0
components. From a technical point of view, this can be implemented in such a way that the higher-level asset (such as
the machine) has two I4.0-compliant communication interfaces, so that there is a clear logical and physical separation
between higher-level and subordinate I4.0 components (see Figure 11, no. 1). Another option is that I4.0-compliant
communication upwards and downwards are physically the same thing, but logically separated from each other (see the
dotted line in Figure 11, no. 2). To organize a logical assignment of subordinate I4.0 components, the administration
shell can contain its own component manager. It can then represent the state of the machine appropriately in the level
above, for example.

27
 DIN SPEC 91345:2016-04
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Figure 11 — Nestability of I4.0 components

6.1.9 Encapsulability

The I4.0 component should be able to establish all necessary connections within an I4.0 system (see
Figure 12, no. 1). However, connections must not lead to any restriction of the core functionality (see Figure
12, no. 2). The ability to retain this core functionality unimpaired even if the external network is disrupted is
called “encapsulability”. The I4.0 component, in particular its administration shell, the functionality
contained in it and the associated protocols, must be capable of encapsulation. Communications can take
place via a single connection (see Figure 12, no. 3).

28
 DIN SPEC 91345:2016-04

Figure 12 — Encapsulability of I4.0-compliant and deterministic real-time communication

6.1.10 Domain specific functionality and state model

An I4.0 component possesses a technical functionality necessary to exercise its role.

EXAMPLE
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

 General functionality of the asset;

 Software for “local planning” in conjunction with the asset, such as welding planning, software for labelling
terminal blocks, etc.;

 Software for project planning, configuration, operation, maintenance;

 Manuals and documentation;

 Technical functionalities relevant to the execution of business logic.

The state of an I4.0 component can be read by other users of an I4.0 system based on a defined state model.

The state model must have state variables which provide a detailed view of the state of the asset and its
technical functionality, in order to allow consistent querying of the state of the I4.0 component at a
particular point in time (for example for the purposes of statistically correct data analysis).

29
 DIN SPEC 91345:2016-04

6.2 Administration shell of I4.0 components

6.2.1 General

The administration shell is what converts an asset into an I4.0 component. It is the virtual digital and active
representation of an asset in an I4.0 system.

In an asset implemented as an embedded system, the administration shell and its objects can be stored in the
asset itself (provided it has active, I4.0-compliant communication capability) or it can be distributed on one
or more IT systems.

The administration shell records life cycle data of the asset and converts it into information (e.g. the present
position and currents of a servo drive). The associated information should be accessible in the form of views
(as described in 6.2.4.3). The services of the component manager are provided by the I4.0-compliant service-
oriented API (Application Programming Interface).

6.2.2 Basic structure of the administration shell

Figure 13 shows the basic structure of the I4.0 administration shell. It is divided into the DF header and the
DF body. The prefix DF unambiguously assigns the partial models to a domain (DF = Digital Factory). The
distinction between header and body follows the specifications of IEC/TS 62832-1. At the very least, the
administration shell contains the administration shell management in the form of the component manager
and the manifest.

The administration shell is divided into partial models for different purposes. Each partial model contains
information in the header and body sections.

6.2.3 DF header and DF body

Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

The header carries information to identify and designate the specific asset in the I4.0 system and contains
information on the administration and use of the asset. It refers to selected capabilities of the asset and to
views. The header information (including identification of the administration shell and assets) must be
regarded as properties in the sense of requirements for graduated security (as in 6.2.5, e)).

The body is where the actual information on the asset is stored. This information is not directly dependent
on the utilization specific to a factory or process plant. This means the body is the actual information carrier.

30
 DIN SPEC 91345:2016-04

Figure 13 — Diagram of an I4.0 administration shell

The administration shell contains separate partial models with properties and functions from different
domains, which are updated with different version numbers independently of each other. The partial models
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

are created in compliance with I4.0, which means using RAMI4.0 and in terms of properties and functions,
using the data elements described in 6.1.6.

Security requirements may necessitate a graduated security model for properties, even in different partial
models.

6.2.4 Partial models and views

6.2.4.1 General

The administration shell can contain any number of I4.0-compliant partial models. Each partial model has
hierarchically organized properties referring to individual data and functions.

6.2.4.2 Creating the partial models

The upcoming Industrie 4.0 reference models propose partial models specified by experts with experience in
the domain. Each partial model specifies its properties, data and functions according to uniform rules for the
header and the body separately. Agreed partial models are available for system-wide I4.0 integration in the
administration shells. Figure 14 shows examples of partial models for various horizontal and vertical
domains.

31
 DIN SPEC 91345:2016-04

Figure 14 — Examples of domain specific models

6.2.4.3 Views in partial models

Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Each partial model must provide at least the basic views by means of properties, data and functions.
Figure 15 shows how views are created.

Figure 15 — Diagram of how views are created

Table 1 shows the basic views which are mandatory for all partial models. Additional views can be created
if needed.

32
 DIN SPEC 91345:2016-04

Table 1 — Basic views of a partial model

Basic view Best practice / examples

Data and functions are stored which make the component suitable and effective for the
Business life cycle phases of procurement, design, operation and utilization. Examples: prices,
terms of delivery, ordering codes.
Contains properties that are relevant to the use of the component, i.e. for selection and
structuring. Contains a structure classification and numerous properties for physical
dimensions and for input, processing and output variables of the component (see
Design
DIN EN 81346 (IEC 81346)). Contains a modular view of partial components and a
device structure. Allows an automation view with inputs and outputs of various signal
types.
Describes performance and behaviour properties to allow summary assessment and
Performance
virtual commissioning (VCOM) of a system as a whole.
Makes statements on the function (see DIN EN 81346 (IEC 81346)) and on the function
of the partial components. Localization of the individual functions of the technical
Functional
functionality also take place here, i.e. the skills and the design, commissioning,
calculation or diagnostic functions of the component.
Makes statements on positions and local context of the component, its parts, or its
Local
inputs and outputs. The actual position of the component is part of the header data.
Can flag a property as relevant to security. This property should be included in any
Security
assessment of security.
Makes statements on the electrical, fluid, material flow and logical connection of the
Network view
component
Contains data on the current state and past use throughout the lifetime of the
Life cycle
component. Examples: Assignment to production, maintenance logs, past uses.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

In all views, properties, data and functions should be prepared in such a way that
Human human users can understand individual elements, relationships and can control causal
chains.

6.2.5 Properties

Meaningful values of I4.0-compliant “basic properties” ensure that all I4.0 components and other systems
can access and use these basic properties, values and functions of the administration shell. In addition, there
are the following property classes: mandatory properties, optional properties and free properties. Table 2
shows their characteristics.

Table 2 — Property classes

Property class Explanation

I4.0-compliant properties which are mandatory and standardized for all
Basic properties
administration shells.
I4.0-compliant properties which are mandatory and standardized for partial
Mandatory properties
models of administration shells.
I4.0-compliant properties which are standardized but not mandatory for partial
Optional properties
models of administration shells.
Properties for partial models of administration shells, such as manufacturer-
Free properties specific properties, which are not standardized and not mandatory. These may
not be used by different manufacturers.

33
 DIN SPEC 91345:2016-04

Without restricting general applicability, the concept is established that the manifest (as described in 6.2.6.3)
of the administration shell manages information elements in the form of properties, and that the
administration shell itself can also include data objects and technical functionality.

The following applies to individual properties, data and functions:

a) It must be possible to use the properties and other information elements in the administration shell for
types and instances.

Just like the administration shell as a whole, the individual properties and other data and functions must
be suitable for allowing a distinction between types and instances of administration shells for the asset
in question. In specific cases, this can mean that individual properties of an instance keep a record of
whether they are added, modified or deleted for this instance, or whether it should be ensured that the
information is identical to the data in the type administration shell.

b) Hierarchical and enumerable structuring of properties must be possible.

The number of properties to be organized is already large and will further increase as Industrie 4.0
develops. To make them manageable for people and machines, properties must be structured
hierarchically. Because a property can contain multiple equal-ranking alternatives or detailed
information, for example a list of languages or certificates, there should be enumerable structures, such
as fields.

c) Properties must be able to reference other properties, including those in other administration shells.

As with the administration shell as a whole, the individual properties must also be able to reference I4.0-
compliant entities and information outside their own administration shell. Thus information can be
linked and becomes knowledge. In the same way, different knowledge domains (for example properties
from different standards) can be linked to each other.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

NOTE 1 Specifically, this makes views possible by representing the view or information hierarchically (see 6.2.5,
b)), and the other views link to it by referencing.

NOTE 2 This requirement should also make it possible to make links using designated relationships (as required
with semantic technologies).

d) Properties must be able to reference data and functions of an administration shell (at least within it).

As part of the manifest, properties must be able to reference data and functions within the
administration shell. In this way, standardized properties can act as anchor points for different data. In
the same way, it can be ensured that the functions of the technical functionality of an asset can be found,
described and accessed.

e) Properties must fulfil aspects of information security for graduated availability, integrity,
confidentiality, visibility and authenticity.

Properties, data and functions will also carry information which not every participant within a value-
added network or organizational unit should be able to access, or whose integrity and availability
should be maintained. Therefore, right from the start, the structure of the administration shell should
take into account aspects such as access protection, visibility, identity and rights management,
confidentiality and integrity. According to the graduation, a “No security” state can be implemented, if
risk assessment results allow this. It should be possible to differentiate these aspects using profiles and
views later.

34
 DIN SPEC 91345:2016-04

6.2.6 Managing the administration shell

6.2.6.1 General

The information in the administration shell with its partial models must be administered and organized. This
is done by the component manager and the manifest.

6.2.6.2 Component manager

The component manager directly or indirectly forms an expanded service that carries out both the lifelong
maintenance of the information contained, as well as enabling powerful querying options based on service-
oriented architecture (SOA). It is the link between the IT technical services of the I4.0 component which
provide external access to the information of the representation and to the technical functionality of the
asset. It organizes the addressing and identification of the administration shells and assets. It organizes the
autonomous administration and access to the resources of the I4.0 component and ensures protection
appropriate to the asset’s use. Another of its tasks is lifelong maintenance of the properties, data and
functions within the administration shell. Based on a service-oriented architecture, it provides an API
(Application Programming Interface) for powerful services for querying information on the asset (such as
view support, tolerant searching, synonym searches and searching for similarity relationships).

The component manager can thus connect a service-oriented architecture (SOA) or integrate the
administration shell into a repository.

NOTE 1 It is possible to represent the component manager by means of a central service, for example if the I4.0
component is kept in a repository.

NOTE 2 The service is understood here as a technical IT service, unlike the functions of the technical functionality of
an asset.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

NOTE 3 There must be access rights and protection adequate for the use of the asset.

NOTE 4 SPARQL support is conceivable.

6.2.6.3 Manifest

The manifest can be regarded as similar to the manifest in information technology. It contains mandatory
information on the I4.0 component, including on connection to the asset or assets by means of appropriate
identification. It acts as a uniquely identifiable table of contents with all the information, data and functions
of the administration shell, and includes the externally accessible, defined set of meta-information on the
functional and non-functional properties of the I4.0 component. It also contains mandatory information on
the I4.0 component, such as how it is connected to the real asset by appropriately secure identification.

The parts of the manifest include:

 characteristic properties of the asset,

 information on how the properties are interrelated,

 relationships between I4.0 components which are relevant to products, production and production
processes, based on IEC/TR 62794 and

 the formal description of relevant functions of the asset, as well as relevant procedures.

What makes the manifest different from normal administration objects is that it contains information that
must be publicly known in order to implement an I4.0 system with adequate protection for its use. Normal

35
 DIN SPEC 91345:2016-04

administration objects can also contain information where the manufacturer is free to decide what is
disclosed, and in which form.

The property structures of the manifest comply with the standardized format of the I4.0 rules according to
DIN EN 61360-1 and DIN EN 61360-2 (IEC 61360-1 and IEC 61360-2). The manifest is usually composed of
properties from the header and the body.

6.2.6.4 Identifiers

Not only the individual administration shells but also the associated assets have a unique identifier (ID),
which means the asset and the administration shell are unambiguously identifiable at all times. This ensures
the connection between the assets and their administration shells, even if they are stored in one or more
distributed digital repositories, or even among different participants in the value-added process. On the left,
Figure 16 shows two assets with the administration shells stored in a (logical) repository composed of any
kind of physical storage media, and on the right an administration shell attached to the asset.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Figure 16 — Availability of administration shells via repository or directly via the represented assets

36
 DIN SPEC 91345:2016-04

6.2.6.5 Identification of types and instances

Administration shells can be characterized as types and instances of assets.

6.2.6.6 References to other administration shells or I4.0 information

For linking information so that it becomes knowledge, it is important that this can take place universally.
This means, for example, that an I4.0 component can model the dependencies of other I4.0 components or
keep a directory which refers to other I4.0 components.

6.2.6.7 Non-I4.0-compliant information

The administration shell of an I4.0 component should be able to support free and proprietary information
content so that free, non-I4.0-compliant information can be agreed and integrated.

6.2.7 Fundamental requirements for the administration shell

a) The administration shell consists of the body and the header.

b) The body contains information on the asset in question.

c) The header contains information on how the asset is used.

d) The administration shell contains the key elements, the manifest and the component manager.

e) The information in the administration shell must be accessible using service-oriented architecture
(SOA) and must take the corresponding security requirements into account.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

f) The administration shell represents information on application aspects.

g) The administration shell is structured using views.

h) The administration has a unique ID.

i) The asset has a unique ID.

j) Even a factory can be an asset that has an administration shell and can be addressed using its ID. It
should be possible to apply the concept of nesting.

k) Types and instances must be indicated as such.

l) The administration shell can contain references to other administration shells or I4.0 information.

m) Additional properties, such as manufacturer-specific ones, must be possible.

n) A reliable minimum set of properties must be defined for each administration shell.

37
 DIN SPEC 91345:2016-04

6.3 Forms of I4.0 components

6.3.1 Different assets with administration shells

Figure 17 shows various assets in a logical view that can be represented in compliance with I4.0 using an
administration shell. With regard to the distribution view, the asset and the administration shell can be at
different locations. For example, administration shells of assets capable of passive communication only, the
administration shell can be stored in a higher-level IT system (see Figure 16). Using the asset’s passive
communication capability and I4.0-compliant communication of the higher-level IT system, the connection
between the asset and the administration shell is ensured. With I4.0-compliant communication capability,
the administration shell can also be stored in or on the asset (for example stored in the control system of a
machine and delivered via the network interface). In terms of the “I4.0 component” concept, all these
alternatives are equally valid. A suitable reference model must be used to ensure that a higher-level IT
system provides the administration shell in compliance with I4.0.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Figure 17 — Different assets that become I4.0 components by adding the administration shell

38
 DIN SPEC 91345:2016-04

6.3.2 Asset with multiple administration shells

An asset can also be represented by multiple I4.0-compliant administration shells, in other words, an I4.0
component can have more than one administration shell for different purposes, as shown in Figure 18.

Figure 18 — Representation of an asset by means of multiple administration shells

If there are multiple administration shells for an asset, they must refer to each other. In particular, portions
of an administration shell should be able to act as a “copy” of the corresponding portions of another
administration shell.

Individual (partial) administration shells can be recombined into a single administration shell while
maintaining their structure.
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

6.3.3 Administration shell for multiple assets

The administration shell of an I4.0 component can also represent more than one asset (see Figure 19).

Figure 19 — Representation of multiple assets

39
 DIN SPEC 91345:2016-04

Bibliography

DIN EN 61512-1, Batch control — Part 1: Models and terminology (IEC 61512-1)

DIN EN 61987-10, Industrial-process measurement and control — Data structures and elements in process
equipment catalogues — Part 10: Lists of properties (LOPs) for industrial-process measurement and control for
electronic data exchange — Fundamentals (IEC 61987-10)

DIN EN 62264-1, Enterprise-control system integration — Part 1: Models and terminology (IEC 62264-1)

DIN EN 81346 (all parts), Industrial systems, installations and equipment and industrial products —
Structuring principles and reference designations (IEC 81346)

IEC 62890, Life cycle management for systems and products used in industrial-process measurement, control
and automation

Status report: Industrie 4.0 — Auf dem Weg zu einem Referenzmodell (Industry 4.0 — Towards a reference
model) (2014) 2)

Status report: Industrie 4.0 — Gegenstände, Entitäten, Komponenten (Industry 4.0 — Objects, entities,
components) (2014)2)

Status report: Industrie 4.0 — Technical Assets — Grundlegende Begriffe, Konzepte, Lebenszyklen und
Verwaltung (Industry 4.0 — Technical Assets — Basic terms, concepts, life cycles and administration)
(2015)2)
Normen-Download-DIN Media-Christian Backe-KdNr.8450913-ID.dR5lf4oIriikd9zHnmOI_3XjWrDCTCqSMKeLcTzy-2025-04-01 13:25:14

Status report: Industrie 4.0 — Wertschöpfungsketten (Industry 4.0 — Value-added chains) (2014)2)

Umsetzungsempfehlungen für das Zukunftsprojekt Industrie 4.0 (Recommendations for implementing the
future project Industry 4.0) (2013) 3)

Umsetzungsstrategie Industry 4.0: Ergebnisbericht der Plattform Industrie 4.0 (Industry 4.0 implementation
strategy: results report for the Industry 4.0 platform) (2015) 4)

2) Obtainable from: VDI e. V. (Association of German Engineers), VDI/VDE-Gesellschaft Mess- und Automatisierungs-
technik (GMA), 40468 Düsseldorf
3) Obtainable from: acatech – Deutsche Akademie der Technikwissenschaften e. V., 80333 München
4) Obtainable from: BITKOM e. V. (Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V.),
10117 Berlin; VDMA e. V. (Verband Deutscher Maschinen- und Anlagenbau e. V.), 60528 Frankfurt am Main;
ZVEI e. V. (Zentralverband Elektrotechnik- und Elektronikindustrie e. V.), 60528 Frankfurt am Main

40