White Paper

Semantic interoperability: challenges in

the digital transformation age
Executive summary
Expansion of the digital transformation age is a key element of adaption for moving forward, but
generating entirely new businesses and markets. this requires the existence of information models
Urbanization, increased life expectancy, climate that are flexible and unambiguous. Standards can
change, the expanding reach of the global supply form the foundation for domain-based information
chain and the “digitalization of almost everything” models, and indeed a number of such standards
have become central to business models and already are in place. Thus, the issue of standards
capabilities across all industries. and their relation to semantic interoperability is
essential to assessing how machine understanding
Pressure is growing on companies and market
works and determining how to connect industry-
participants to use data from this digital revolution
related standards to effectively address this
to make the right decisions concerning investment,
concern.
research, market assessments and adaptions.
Furthermore, with the explosion of available Another aspect of this challenge involves
data and the resulting demand for increasingly understanding why semantic interoperability has
interactive systems, it is becoming more and moved forward so slowly and why there exists a
more difficult to build applications that can lack of semantic best practices. To address this
function conjointly in such a complex environment. challenge adequately, semantic best practices must
Semantic interoperability can help resolve some of be developed, embraced, adhered to and enforced
the challenges involved as a choice element of the in the same way that software development has
digital transformation age. matured to support object-oriented programming
(OOP), software patterns, libraries and application
Semantic interoperability influences the entire
programming interfaces (API). Furthermore, and
information life cycle, both horizontally between
to a much greater extent, because information
individual devices and systems and vertically
models are shared (at least in interoperability
across dissimilar systems. In this white paper, it is
scenarios), best practices must be extended to
assumed that the interoperability considered in this
include aspects of model development.
document is among two or more systems whose
information models and syntaxes are mutually This white paper offers an assessment of current and
different. It is defined as “the ability of computer future challenges involving semantic interoperability
systems to exchange data with unambiguous, in industrial domains and related industry-based
shared meaning” and as “a requirement to enable standards. The main goal of the paper is to identify
machine computable logic, inferencing, knowledge conditions in which the application of ontology-
discovery, and data federation between information based semantic technologies, together with
systems.”1 already existing information models, can be used
to improve interoperability within and between
With the digitization of functions at every level,
applications and domains, and to formulate
providing systems with the means to handle
recommendations based on a review of use cases
more of their day-to-day operations without direct
versus existing technology and standards.
human control or brittle programming constitutes

1 en.wikipedia.org/wiki/Semantic_interoperability

3
Executive summary

This white paper addresses its content to a broad framework of 5 to 10 years. This presentation also
audience. As noted above, semantic interoperability indicates where the emphasis should lie in modelling
influences the entire information life cycle, both resource expenditure efforts by the responsible
horizontally between devices and systems, and management. Those involved in the life cycle
vertically across dissimilar systems. Because of management of product and system engineering
the distinct points of view held by these various can identify appropriate main use cases and derive
stakeholders, the white paper provides a variety decisions concerning the strategic use of standard
of viewpoints and levels of detail in the individual or company-specific solutions.
sections in order to address the different concerns
Section 4 recapitulates experiences from the
and interests of these stakeholders. Persons who
semantic interoperability scenarios as they relate
can benefit from reading this white paper include:
to the use case information modelling and provides
§§ IEC decision makers relevant hints to ontology developers and semantic
technologists.
§§ Managers charged with deciding whether to
provide resources for information modelling/ This white paper formulates recommendations
knowledge representation based on a review of use cases versus
existing technology and standards. Section 5
§§ Persons responsible for life cycle management
outlines the challenges involved in achieving
of both products and systems engineering
semantic interoperability and Section 6 offers
§§ Ontology developers and semantic technolo- recommendations to the IEC and its committees
gists as well as to industry and consortia.
§§ Engineers involved in developing standards- As one of the globally recognized de jure standards
based semantic interoperability in tools organizations, the IEC is in a unique position to
Section 1 begins by describing what interoperability drive semantic interoperability forward and to
involves, what semantics and ontologies consist identify conditions under which the application
of, and what “understanding” means in the context of ontology-based semantic technologies can be
of knowledge processing. This is followed by a used to improve and achieve interoperability within
description of the digitalization process. and between applications.

Section 2 discusses the state of the art of information Important recommendations include:
modelling in the industrial production life cycle. §§ Initiate the elaboration of semantic
Because this includes findings fundamental to interoperability standards for both the
understanding the requirements associated with development of information models as well as
semantic interoperability, it is recommended that their management
all readers with a technical background read this
§§ Request the IEC Standardization Management
section carefully. The paragraphs dedicated to the
Board (SMB) to consider forming a working
state of the art include references to existing IEC
group to develop a semantic interoperability
Standards. These aspects are of special interest for
best practices guideline including a survey
engineers who develop semantic interoperability in
among IEC and ISO standardization groups.
tools.
The survey should ask which semantically
Examples of industrial use cases are presented interoperable standards these groups are
in Section 3. These serve to illustrate semantic responsible for, or which they intend to develop
interoperability requirements and discuss soon, and how these standards relate to one
gaps between the current state of the art and another (resource map)
requirements introduced within a projective

4
Executive summary

§§ Glossary/vocabulary: The challenge of

semantic interoperability is to ensure that
information exchanged is understood not only
by the human beings involved on both ends
of the ICT communication channel but also by
the computer systems and their associated
software. Several projects in ISO/IEC JTC 1/
SC 41 and TC 65/WG 23 deal with semantics-
related terms, with enough input available to
start standardization of these terms

As it is foreseen that semantic interoperability will

be of fundamental importance across countless
industries and will constitute one of the driving
forces of the fourth industrial revolution, the
standardization community will play a critical
role in shaping its future. Building upon its long
track record in ensuring safety and reliability, the
IEC can be an instrumental partner in achieving
this goal and fulfilling the promise of the digital
transformation age.

5
Executive summary

Acknowledgments

This white paper has been prepared by the semantic Mr Weilin Liu, Global Energy Interconnection
ontologies project team in the IEC Market Strategy Research Institute Europe GmbH, Germany
Board (MSB), with major contributions from the
Mr Mark Verheyen, Eaton Corporation
project partner, Prof Dr-Ing Christian Diedrich, ifak
e.V. Magdeburg (Germany) and the project leader, Dr Martin Knechtel, SAP SE
Siemens AG. Dr Qikai Zhuang, Global Energy Interconnection
The project team was directed by Dr Jan Mrosik, Research Institute Europe GmbH, Germany
Siemens AG, CEO Digital Factory Division and an Mrs Lan Yamashita, Toshiba Corporation
MSB member. The project team is listed below:
Mr Masatake Sakuma, Toshiba Corporation
Prof Dr-Ing Christian Diedrich, ifak e.V.
Mr Peter Lanctot, IEC, Project Administrator
Magdeburg, Project Partner Lead

Mr Karsten Schneider, Siemens AG,

Assistant Project Director

Dr Jack Hodges, Siemens AG

Dr Darko Anicic, Siemens AG

Mr Frank Jankowiak, Siemens AG

Mr Eui Suk Jeong, KERIS, South Korea

Mr Gernot Rossi, Siemens AG

Mr Yun Chao Hu, Huawei

Mr Di Wang, Huawei

Dr Florian Michahelles, Siemens AG

Mr Wolfgang Jedich, Siemens AG

Prof Jaeho Lee, University of Seoul,

South Korea

Mr Johannes Kalhoff, Phoenix Contact, Germany

Mr Shitao Li, Huawei

Mr Ulrich Kleber, Huawei

Mr Juergen Diller, Huawei

Dr Kunlun Gao, Global Energy Interconnection

Research Institute Co. Ltd., China

Dr Bo Chai, Global Energy Interconnection

Research Institute Co. Ltd., China

6
Table of contents

Executive summary 3

List of abbreviations 11

Glossary14

Section 1 Introduction 17
1.1 Background 17
1.2 General interoperability scenarios 18
1.3 How semantics can be used to enhance interoperability 19
1.4 How industry base standards can be employed to enhance semantic interoperability 20
1.5 Goals of the white paper 20

Section 2 Semantic interoperability: current models, future objectives

and state of the art 23
2.1 What is understanding 23
2.1.1 How do humans understand the world 23
2.1.2 How do machines understand the world 24
2.1.3 Experience, knowledge, and meaning 24
2.1.4 What is context and how does it help remove uncertainty of meaning 25
2.2 The current state of semantic interoperability 26
2.2.1 Mapping the real world into the information world 26
2.2.2 Understanding and human-generated descriptions 29
2.2.3 Cross-domain understanding (missing supporting information models;
either depth or breadth; reusability) 30
2.2.4 Integrate machine learning into cross-domain understanding 35

Section 3 Challenges and motivation of semantic interoperability:

7 use cases 37
3.1 Application fields of the use cases 37
3.2 Use case 1: UC-MDA-01 Acquisition of models and data from human-centric documents 40
3.2.1 Use case description 40
3.2.2 Requirements 41
3.2.3 Gaps 41

7
Table of contents

3.3 Use case 2: UC-AA-02 Access to objects/assets with integrated semantic information models 41
3.3.1 Use case description 41
3.3.2 Requirements 41
3.3.3 Gaps 41
3.4 Use case 3: UC-BS-03 System bootstrapping 42
3.4.1 Use case description 42
3.4.2 Requirements 43
3.4.3 Gaps 43
3.5 Use case 4: UC-SE-04 System engineering 43
3.5.1 Use case description of a part of a chemical plant 43
3.5.2 Requirements 44
3.5.3 Gaps 44
3.6 Use case 5: UC-AS-05 Matching of engineering requirements and asset skills 44
3.6.1 Use case description 44
3.6.2 Requirements 46
3.6.3 Gaps 46
3.7 Use case 6: UC-FD-06 Diagnostics with semantics-based failure detection 46
3.7.1 Use case description 47
3.7.2 Requirements 47
3.7.3 Gaps 47
3.8 Use case: UC-PM-06b Semantics to facilitate preventive maintenance in electric grids 47
3.8.1 Use case description 48
3.8.2 Requirements 48
3.8.3 Gaps 48
3.9 Use case 7: UC-CC-07 System cooperation/collaboration 48
3.9.1 Use case description 49
3.9.2 Requirements 50
3.9.3 Gaps 50

Section 4 Semantic interoperability scenarios as they relate

to the use cases 51
4.1 General requirements for semantic interoperability 51
4.2 General gaps that complicate semantic interoperability 52
Table of contents

Section 5 Challenges involved in achieving semantic interoperability 55

5.1 Technical considerations regarding the design of semantic interoperable information models 55
5.2 Topics which need more structuring/work in order to propose precise actions 55
5.3 Topics which need more research 56
5.4 Overall view of semantic interoperability for integrated application and technologies 57

Section 6 Recommendations 59
6.1 Recommendations addressed to the IEC and its committees 59
6.1.1 Recommendations concerning the organization of the semantic
interoperable information model design 59
6.1.2 General recommendations to the IEC and other standardization bodies 60
6.1.3 Technical recommendations for the design of semantic interoperable
information models 60
6.2 Recommendations to industry and consortia 61
6.3 Recommendations concerning regulation needs 62
6.3.1 Considerations in addition to technical requirements 62
6.3.2 Automated use of semantic interoperable information models requires
reliability of the models, contents and interfaces 62
6.3.3 Automated use of semantic interoperable information models requires
reliable availability in the provision of the models and an automated business
relationship for the use of the standards 62
6.3.4 Products, systems and services are marketed and used internationally 62

Annex A Detailed use case descriptions 63

A.1 “Find and update something” use cases 63
A.1.1 Use case description of a part of a chemical plant engineering 63
A.2 Derive information models and data from human-designed information sources 67
A.2.1 Use case: Human and machine understanding of human-designed descriptions 67
A.2.2 Use cases in electric grids 70
A.2.3 Use case: Graphical data conversion into information models 73
A.2.4 Use case: Composite devices 73
A.3 Requirements 77

9
Table of contents

Annex B Levels of formalization – XML schema and OWL 79

B.1 Structured representation language – a choice based on need 79
B.2 The choices 79
B.3 The big difference 80
B.4 The small differences 80
B.4.1 The strengths of the XML schema 80
B.4.2 The weaknesses of XML schema 80
B.4.3 The strengths of OWL 80
B.4.4 The weaknesses of OWL 80
B.5 Summary 81

Annex C General concepts to enable semantic interoperability –

a case for system-agnostic information models 83
C.1 Basic model 83
C.2 Single and universal information model 83
C.3 Direct integration of many models 85
C.4 Indirect integration of many models 86
C.5 Summary 87

Annex D Relations to existing standardization projects 89

D.1 ETSI TR 103 535 V0.2.2 (2019-03) 89
D.2 ISO/IEC 21823-3 in preparation (JTC 1/SC 41/66/CD) 90

Bibliography93

10
List of abbreviations
Technical and AI artificial intelligence
scientific terms AML automated machine learning

API application programming interface

ASCII American Standard Code for Information Interchange

AutomationML Automation markup language

BOM bill of material

BOP bill of products

CAx computer-aided technologies

CDD common data dictionary (IEC)2

CGMES common grid model exchange specification

CIM common information model

co-xx  ooperation, collaboration, conflicting, competition

c
and complementary functions

CPU central processing unit

CRUD create, read, update, delete

DCS distributed control system

E-CAD electronic computer-aided design

eCl@ss  orldwide ISO/IEC-compliant reference-data standard

w
for the classification and unambiguous description
of products and services3

EDD electronic device description

EDDL electronic device description language

EM engineering mechanics

ICT information and communications technology

IEV international electrotechnical vocabulary (IEC)

IFC industry foundation classes

IO input/output

2 cdd.iec.ch
3 www.eclass.eu/en.html

11
List of abbreviations

IoT Internet of Things

IoT-O Internet of Things ontology

IT information technology

JSON JavaScript Object Notation

JSON-LD JavaScript Object Notation for Linked Data

JTC joint technical committee (ISO/IEC)

LwM2M lightweight M2M

MAC media access control

M2M machine-to-machine

ML machine learning

OOP object-oriented programming

OPC UA open platform communications unified architecture 4

OT operational technology

OWL web ontology language

P&ID piping and instrumentation diagram

PLC programmable logic controller

QUDT quantities, units, dimensions and datatypes ontology5

RDF resource description framework

RDFS resource description framework schema

SAIM system-agnostic information model

SAREF Smart Appliances REFerence ontology 6

SDO standards development organization

SME small and medium-sized enterprise

SOSA sensor, observation, sample, and actuator ontology

SPARQL SPARQL protocol and RDF query language

SQL structured query language

SSN semantic sensor network ontology

TC technical committee (IEC)

TSO transmission system operator

4 opcfoundation.org
5 www.qudt.org
6 ontology.tno.nl/saref

12
List of abbreviations

UAV unmanned aerial vehicle

WG working group

XML extensible markup language

XSD XML scheme definition

Organizations, ENTSO-e European Network of Transmission System Operators for Electricity

institutions and
ETSI European Telecommunications Standards Institute
companies
IEC International Electrotechnical Commission

ISO International Organization for Standardization

KERIS Korea Education & Research Information Service

MSB Market Strategy Board (IEC)

OCF Open Connectivity Foundation

SMB Standardization Management Board (IEC)

UNECE United Nations Economic Commission for Europe

W3C World Wide Web Consortium

13
Glossary
adapter cooperation
mapping or integration between a core set of ability of group agents to understand and to act on
ontologies and a system ontology, or between two that understanding in a manner that benefits both
system ontologies the individual agent’s and the group’s goals
Note 1 to entry: As opposed, for example, to accommodation
asset or competition.

thing of value for a user

data object
bridge representation of technical information (smallest
graph that integrates two or more ontologies piece of an information model), a model instance
Note 1 to entry: See also mapping (a bridge is also referred (i.e. instantiated model)
to as a mapping).

Note 2 to entry: A bridge is often used in the context of a data structure

system-agnostic core set of ontologies, whereas an adapter arrangement and organization of interrelated data
is used in the context of mapping a system-agnostic set of
ontologies to a system-specific (or legacy) model.
elements/objects in an information model

brown field device

existing things; legacy things functional artefact
Note 1 to entry: A device is a thing (as defined below) with at
least one designed function.
capability
functionality in context
domain
Note 1 to entry: See skill.
defined technical area

collaboration
information model
ability of group agents to understand and to act on
set of data object types and their dependency
that understanding in a manner that benefits the
relations which, together, define meaning
group’s goals
Note 1 to entry: An information model can also be considered
Note 1 to entry: Similar to cooperation and contrasted with as semantic data (a semantic data model).
accommodation or competition.

instance
context
unique thing that can refer to a single virtual
all of the information and information models that
machine in a virtualized or cloud computing
are available at a given moment in time and assist
environment that provides operating-system-level
in understanding and acting upon data
virtualization, unambiguously defined in the IoT
Example: a MAC address

14
Glossary

interoperability
capability of two or more functional units to process
data collaboratively or cooperatively

mapping
relation between data objects/ontologies
Note 1 to entry: See bridge and adapter.

ontology
specification of concrete or abstract things, and
the relationships among them, in a prescribed
domain of knowledge
Note 1 to entry: The specification should be computer
processable.

[SOURCE: ISO/IEC 19763-3:2010]

relation
specification of how data objects are related to
other data objects in an ontology

semantic
meaning of concepts, often expressed through
classes and their properties as data structures

semantic network
concept-based knowledge representation in which
objects or states appear as nodes connected
with links that indicate the relationships between
various nodes

skill
a function applied in context
Note 1 to entry: See capability.

thing
physical object, device, actuator, sensor, electronic
document, electronic catalogue, file, real or
conceptional/data object, artefact

15
Section 1
Introduction

This white paper offers an assessment of current concerns meaning, there is no source of information
and future challenges concerning semantic indicating how this meaning is achieved using
interoperability in industrial domains. The semantics. In fact, semantic models are linked
main goal of the paper is to identify conditions structures onto which we map data and then
in which the application of ontology-based propagate it across these structures to produce
semantic technologies can be used to improve new data. This is called inferencing. When we
and achieve interoperability within and between map data to semantic structures the data takes
applications. We do this by first looking at the on whatever meaning is represented by those
general difficulties faced by industrial systems and structures. So, for example, if we map a floating-
then provide examples that can be addressed point number onto a structure that represents a
with semantic models. The examples address the Celsius temperature unit, then that floating-point
entire asset life cycle in manufacturing, including number represents a Celsius temperature value,
planning, commissioning, simulation and resource whereas before it was just a floating-point value.
management and maintenance. Also referenced Digitization helps to understand this process.
are data acquisition/import, analysis, verification
As such there are an increasing number of systems,
and validation based on information models.
devices, and components that contain and share
While semantic interoperability is essential to data, but generally no commensurate increase
success in modern manufacturing automation due in the number of people available to monitor and
to digital transformation, there remain gaps to be manage them. Even when people are available,
closed before fulfilling its promised potential. To the complexity of the system is continually
explain this, four interoperability scenarios for data enhanced, elevating human/machine risk as well
models are presented: as maintenance costs and delivery times. These
are neither scalable nor sustainable. As a result, it
§§ General interoperability scenarios
is becoming increasingly important that systems,
§§ Scenarios indicating how semantics can be devices, and components be able to interact and
used to enhance interoperability understand each other to some extent (within the
§§ Scenarios indicating how standards can be context of their intended collaboration, such as
employed to enhance semantic interoperability two machines operating on a factory shop floor or
analysis and maintenance of tools using machines).
§§ Scenarios indicating how ontologies can be
This requires that the systems understand their role
used to implement semantic interoperability
in the collaboration: for example, what services
they provide and what the scope and limitations
1.1 Background
of those services are. Although it is possible to
We speak of semantics and semantic develop software for these interactions, developing
interoperability as though the world understands and managing such complex software is difficult
what we mean by these terms. Although semantics and would require even more human resources.

17
Introduction

What is needed is a curated and declarative (i.e.

semantic) model of the machine world: one that
Query
does not require the intervention of the developer
to be maintained, and which describes the
machines and their interactions accurately enough
Model_A Model_B
for them to interact unambiguously. Unfortunately,
System_A System_B
a problem posed by today’s information models is
that they are developed in-house, so they satisfy
enterprise functional requirements but are no a) Find
more interoperable than traditional data models.
The way forward involves basing interoperability Data

scenarios on existing and still-to-be developed

standards. Today’s standards are more-or-less well
documented, are consensus-based and provide Model_A Model_B

a viable and appropriate breeding ground for System_A System_A System_B System_B

declarative versions that could serve as a starting

point for curated semantic models.
b) Update

1.2 General interoperability Data

scenarios
In most modern systems, humans are responsible Action_A Action_B

for developing both the information model and Model_A Model_B

the operations on data. Yet, each of the tasks System_A System_B

illustrated in Figure 1-1 makes use of data models

in different ways. These three interoperability
c) Operate
scenarios7 are applied between machines without
human interference and demonstrate four different
approaches that interacting systems use to share Figure 1-1 | General interoperability scenarios
data and operations on data.

In each scenario the systems interoperate in the

following manner: This scenario is most often used in discovery
and identification tasks.
§§ Figure 1-1a) Understand something: This
involves matching data to a model as best one §§ Figure 1-1b) Update something: Data is
can, often using other information to interpret provided using matching and assignment,
the data in the context in which it is found/ which then updates values in a repository for
used. This scenario is used in interpretation subsequent use. This scenario can be used
and understanding tasks. in design, configuration, (de)commissioning,
maintenance, import/export tasks, etc.
§§ Figure 1-1a) Find something: Querying and
matching is used to locate something, on the §§ Figure 1-1c) Operate on something: Using data
basis of specific given information and often and matching to perform operations on items.
requires traversing models to identify a match. The operations can range from very simple

7 It is safe to assume that, for any of these scenarios, one of the “systems” can be removed, and the scenario remains valid.

18
Introduction

tasks, such as value checking, to verification, For example, if System A represents a measurement
validation, simulation, diagnostics, planning, device and System B represents a motor, System
reasoning, etc., depending on the complexity A has to have some understanding of electrical
of the operation. power to associate the amperage it measures
to the motor, and System B has to have some
In most modern systems, humans are responsible
understanding of observation and measurement to
for developing both the information model and the
understand the sensor values. Given this degree
operations on data. It is the purpose of this white
of interoperability, System A and System B can
paper to articulate how best practices in information
interact and collaborate more independently.
management can lead to improvements in many
engineering tasks by focusing on and addressing In Figure 1-3, which illustrates aspects of
semantic interoperability. These interoperability interoperability, information models (labelled
scenarios illustrate how data is shared and as semantic data), and their relations to the
understood between systems, and use case behaviour of the object/asset8, are one of the
examples shown in Section 3 each invoke one of interoperability elements. The communication
these scenarios. transport between the objects/assets, with
defined syntax and standardized communication
1.3 How semantics can be used systems, are well-defined and mature aspects of
to enhance interoperability interoperability. Policies around the value chains
performed outside of the object/asset network are
Semantic interoperability can be defined as the
the organizational and business aspects that must
ability of two or more assets (e.g. agents, machines,
be considered for interoperable systems.
systems) to exchange and understand each other’s
data correctly, as shown in Figure 1-2.

Interoperability is classically thought of solely

in terms of data exchange, but semantic
interoperability extends this notion to include the
meaning of data, and thus a data model translation Semantic data Policy
becomes part of the solution. What is meant by
“correctly” is that the objects/assets understand
what data means without additional programming.
Interoperability

Syntactic Behavioural

Data
System_A System_B
exchange

Model_A
Model
Model_B Transport
translation

Figure 1-2 | Generic semantic Figure 1-3 | Generic semantic

interoperability scenario interoperability scenario

8 The item of interest can be physical or conceptual – this is represented by the term “object”; the term must be of value for the
user – this is represented by the term “asset”.

19
Introduction

Semantic interoperability is a key enabler for Standards provide the necessary basis of any
allowing interacting systems9 to understand and interoperability. The IEC technical committees
act upon data. Interacting systems represent represent vertical technical areas (vertical
components and tools in the life cycles of products, domains), maintain domain-specific semantics
machines and plants in industrial production. They (product-related terminology) and help to realize
interact horizontally among components and tools interoperable functions and services inside their
that follow one another in the chain of processes, respective domains. A more holistic (i.e. horizontal)
or vertically within the structure of machines, plants information exchange across different domains
and the automation architecture. (e.g. grid, building, factory and logistics) is required
for smart infrastructures to emerge. This leads
Scaling up the number of systems that need to
to a demand for more universal interoperability,
network without scaling up the workforce requires
leading in turn to information models based on
more than simple data exchange, since such
common cross-domain semantic and ontological
exchange relies on human oversight to enforce
foundations. Expressing such information models
the meaning. Rather, semantic interoperability
in standards will enhance the importance of the IEC
provides the means for two systems to understand
and the relevance of its standards in supporting
each other’s conventions and functions behind the
interoperability to industries and businesses.
data, in the context in which it is used. This can be
achieved with different representation languages,
but it amounts to either a) a sharing of information 1.5 Goals of the white paper
models, or b) a conversion of information models,
Figure 1-1 and Figure 1-2 illustrate engineering
the former being the more scalable approach.
task-based interoperability scenarios and
how semantics can be applied to general
1.4 How industry base standards interoperability. Unfortunately, applying semantics
can be employed to enhance in an unambiguous way to interoperability scenarios
semantic interoperability brings to light several gaps between what the
state of the art currently supports and what it
Standards provide one means of achieving
must support in the future to solve the kinds of
semantic interoperability because they provide
engineering problems semantics can successfully
well-defined and agreed-upon data requirements,
be applied to. This white paper introduces the
although these are often so narrowly defined
notion of semantic interoperability and discusses
that they cannot provide a complete information
current practice and requirements. This leads to
model needed for interoperability. That said,
the identification of gaps in existing standards,
the models associated with standards can be
models and methods, and to recommendations for
aggregated/integrated to provide a broad enough
how to address these gaps and future needs. The
domain model to be of value. For example, the
recommendations on how to address the gaps are
IEC Technical Committee 65: Industrial-process
centered by referral to international standardization
measurement, control and automation, publishes
and are derived from the evaluation of use cases
a series of standards for the engineering and
which rely on semantic interoperability.
operation of industrial measurement and control of
production systems.

9 The systems are assets, i.e. things which have a value in the industrial domain.

20
Introduction

This white paper also addresses issues related to

the following questions:

§§ What needs to be done with existing information

models to improve semantic interoperability
between systems?

§§ What role does standardization play in semantic

interoperability?

§§ What benefits are gained by using ontologies?

§§ What is the best way to manage ontologies

and their life cycles?

§§ What role do/should humans play in semantic

applications?

§§ What role do ontologies play in digital twins?

§§ How can semantic technologies and machine

learning be effectively combined?

21
Section 2
Semantic interoperability: current models,
future objectives and state of the art

The motivation for addressing manufacturing 2.1.1 How do humans understand

interoperability tasks using semantics has been the world
presented in Section 1. However, nothing has been
When humans interact in dialogue, every word we
said about how semantic interoperability works.
utter must be understood by everyone engaging
Where do semantic models come from, and how do
in the dialogue, or at least understood sufficiently
they collaborate to support engineering tasks? For
to follow the essence of the conversation, where
the purposes of general understanding, this section
“essence” represents the overall meaning in the
addresses the five questions below to help explain
context of the dialogue regardless of grammatical
why the subjects they raise are important to explore
correctness. The thing we understand (i.e. the object
as examples illustrating the need for semantic
of our understanding) takes the form of a concept,
models, the current state of the art in semantic
and the way we describe this concept is with
interoperability and the gaps between the two:
words, or with other modes of communication10.
§§ What is understanding? People are very competent in carrying out this
process because we humans use context (i.e.
§§ How do humans understand the world?
every available piece of information, knowledge
§§ How might machines understand the world? and experience) to constrain the meaning of words
§§ What is the relation between experience, or concepts to a point where we can make good
knowledge and meaning? guesses as to the meaning involved, even when
we do not understand the words and when the
§§ What is context and how does it help
grammar utilized may even be incorrect. That is,
disambiguate meaning?
humans do not need grammar or, in many cases,
even a common lexicon/dictionary. We can also
2.1 What is understanding
take advantage of other information outside the
To address the concept of understanding, we begin words themselves, such as voice tone, pauses,
by differentiating human understanding from that facial expressions, body expressions, etc.
of machines. In either case, semantic technologies
For the time being, let us assume that machines11
constitute a way of representing meaning and
either do not have access to these other forms of
using meaning to articulate our understanding. In
perception/communication or, if they do, cannot
order to talk about understanding and semantic
take advantage of them in the same way people
technologies, it is important to have at our disposal
do. This leaves us with words and context. When
a common definition of the word “understanding”
we hear a spoken word or read it on a page,
and for this we need a definition of “concept”.

10 It is beyond the scope of this white paper to discuss how concepts are represented in human brains or how they are acquired.
11 The term “machine” is used in the general sense of a physical or conceptual asset that is represented by and is acting according
to its digital representation in the information world.

23
Semantic interoperability: current models, future objectives and state of the art

we “map” that word (the characters) to some philosophical paradigms of materialism and ide-
concept in memory. Many concepts may exist alism were born of this distinction. Ancient Greek
that use the same word, so we utilize the words philosophy sought to present a comprehensive
around it to identify the context, and we use the description of the world, i.e. of “that which exists”.
context to constrain which meaning of the word is Hence the introduction of the term ontology. Con-
appropriate. This is called disambiguation (i.e. the temporary philosophers do not agree on a com-
act of choosing the right meaning). mon definition of ontology, however in computer
science the term has been adopted to establish a
Part of the context is a shared understanding of
formal and explicit digital specification (conceptu-
intent. If we can use the intention of the conversation
alization) of a domain of interest. Within this frame-
as a guide, then we can ignore word meanings that
work, a domain of interest can be specified by
do not support that intention. For example, if in
terms, their relationships and their dependencies.
talking about a manufacturing cell the word “drill”
This signifies that ontology is a means of defining
is used, then in our minds we may think of drill as a
semantically relevant descriptions, which can be
machine, as a function, as an exercise, or even as
used to interpret data. The semantically relevant
a test, but in the context of a manufacturing cell,
description with which data complies is known as
only the first two meanings make sense, so we can
an information model of the object/asset. Under-
ignore the other possible meanings. If we then see
standing data amounts to matching it to an appro-
the words “wood” or “workpiece” it is increasingly
priate information model.
likely that the word “drill” is referring not to the
device but to the function. Although this is really
2.1.3 Experience, knowledge,
the purview of natural language understanding,
and meaning
the same requirements hold and are even more
important for machine-to-machine interaction and How are concepts acquired and understood by
collaboration. humans? During childhood, adults describe the
world to children. For example, if children are told
2.1.2 How do machines understand that the cooking stove is “hot”, they understand this
the world term if they have experienced it directly by holding
their hands near the hot stove or even touching it.
Machines understand the world using data and
This involves a stimulus and response associated
information models as well as algorithms to
with a word. Following this experience, the term
manipulate them. In traditional computer science
“hot” in the context of a stove has a particular
these models were implemented in programming
meaning: that the stove is potentially dangerous,
languages. In more recent times, at least in terms
and one must avoid it, i.e. not touch it, unless
of interoperability, models, and even some of
one wants to repeat the experienced response.
the algorithms, have been implemented using
The meaning of the term “hot” is connected to
declarative representations and languages. For
the consequence of action. This is the intention
the purposes of this white paper we use the term
of the adult in saying that the stove is hot. This
ontology to refer to declarative models of discrete
concept of hot can be related to a physical
logic that can represent things and logic.
phenomenon involving heat and temperature. We
The term “ontology” originated with the ancient can understand “heat” by the causal reaction the
Greek philosophers. They wanted to understand temperature produces when applied to our hand.
the real world and to recognize that a difference “Understanding” is a similar phenomenon. We have
exists between the reality of the world and what to experience a result, reaction or consequence at
humans see and think about it. The fundamental

24
Semantic interoperability: current models, future objectives and state of the art

least once in order to “understand” it. That is, we asset effected with a temperature sensor. To
must relate everything we experience to everything understand how to respond to this measurement,
we already know. When the child grows older and the object/asset model must have a defined
becomes an adult, he or she no longer needs to operating temperature range, a high-temperature
touch, but now has gained many experiences limit and a causal relationship between the object/
and can “simulate” or reason about hot things asset function and temperature. Then, if the
according to his/her combined experience and operating temperature is exceeded, the operation
knowledge, making it possible to imagine/find of the object/asset can be changed to mitigate the
possible consequences. Although humans can temperature, such as by reducing torque or speed,
generalize on the basis of a sample set of one, or by turning the object/asset off. The information
this so-called episodic knowledge can often be model is used to bind the temperature to the device
incorrect and can result in improper actions. This model and navigate through the model to the causal
means that understanding as a path drawing on prediction of what to do. The machine understands
knowledge and experience is necessary for action temperature insomuch as it is part of the machine
but cannot guarantee correct performance. model. If different applications calculate the same
result for a certain temperature value on this type
By analogy, ontologies define information models,
of device, they have the same understanding (i.e.
and information models can describe causal
the temperature model supports interoperability
dependencies. Matching data to the information
between these systems).
model allows us to understand the data, and using
that knowledge to simulate outcomes enables
2.1.4 What is context and how does it help
predictions to be made that can be compared
remove uncertainty of meaning
with sensing data. This is also highlighted in Figure
1-3’s reference to semantic data and behaviour. It To apply these general findings to more
is this meaning of interoperability that we choose complex (human) examples, the symbols must
to convey in this white paper. be disambiguated against multiple possible
meanings (and thus representations), and this is
As a technical example of this process, consider
made possible by the introduction of context. For
the temperature measurement of a certain object/
example, consider the diagram in Figure 2-1.

Context

Symbol drill hole wood

Conceptual
Device Function Exercise Test Concavity Workpiece
class

ref Workpiece ref Person ref Person

Conceptual ref Device ref Activity ref Topic
dependency
ref State

ref Function
ref Goal

Figure 2-1 | Natural language example for “context”

25
Semantic interoperability: current models, future objectives and state of the art

In this figure, the “drill” is presented in an utterance, §§ Many machine applications have no explicit
and the utterance provides the context allowing to information model that “they” can use to
determine which of the four meanings presented evaluate data
(device, function, exercise, test) is the actual/
§§ Machine information models generally cover a
contextual meaning of this utterance. The context
single knowledge domain
here is everything that is not the drill, so “hole”
(i.e. a concavity), and “wood” (i.e. a workpiece) §§ Learning is not generally integrated into
are both contexts. In fact, if there were more information models
context available, we could invoke other forms Each of these realities will be addressed using
of knowledge that are connected to these in the examples.
aggregated information model. If we look at these
words/symbols one at a time, the only expectations 2.2.1 Mapping the real world into the
(i.e. conceptual dependencies) we can arrive at are information world
those that are identified below the concept. We see
that the only meaning that is bound to the context State of the art
is the drill function, because we expect a reference
Example 1: The quality of an information
to a concavity, a device, and a workpiece.
model is limited to the knowledge of its
This artificially constructed utterance injects ambi- designer
guity to demonstrate the need for and value of con-
The information model of a real-world asset is
text to disambiguate between four potential mean-
no better than 1) the knowledge of the human
ings of “drill”. For machine-to-machine interactions
modelling the asset, and 2) the modelling skills
ambiguity can still be present, but misunderstand-
possessed by that person, which are required
ing the meaning leads to unacceptable results.
to transform his/her implicit knowledge into
an explicit representation form.
2.2 The current state of semantic
interoperability Today’s interactions between humans and the
Fundamental to semantic interoperability is the real world, and the interactions between technical
semantic model. Where do semantic models come assets (also known as machine-to-machine or
from and how might they be used in engineering M2M interactions), are strongly associated with
tasks and, more specifically, in semantic information models. Data is always represented in
interoperability? This subsection introduces six terms of the information model to which it conforms,
realities associated with information modelling and, in most cases, it is the information model
that affect the state of the art for semantic underlying data that allows for any interoperability
interoperability: at all.

§§ The quality of an information model is limited to The digital starting point of all data is its datatype
the knowledge of its designer representation in the form of strings, Booleans
and numbers, the so-called primitive xsd simple
§§ Human knowledge is normally represented in
data types12. This data accumulates additional
non-machine-interpretable ways
descriptions (such as encodings, default values
§§ Humans share core knowledge and thus can and value ranges) which become a structured
correlate information across domains information model (i.e. a multi-attribute data

12 There are approximately 45 xsd simple data types, see www.w3.org/TR/xmlschema-2.

26
Semantic interoperability: current models, future objectives and state of the art

Explicit
knowledge

Knowledge

Information
model

Information Data
Data
world (strings, boolean, numbers, ...)

Implict
Real world knowledge

Things

Figure 2-2 | Mapping of the real world into the information world

structure or class). Over time, the way data is the problems being addressed through use of a
represented, stored, and conveyed has changed, machine, or even the ethics of using machines at
evolving from text to tabular data to various all. This knowledge is based on information models
structured data forms as shown in Figure 2-2, but which describe data coming from the real world.
humans have always shouldered the responsibility To this end, the attempt is made to transfer implicit
of interpreting the data at either end of the knowledge of the real world, encapsulated by
interaction. humans into explicit knowledge, in a form that can
be used by machines. The process of digitizing
In other words, humans, rather than the machines
real-world things contains these mentioned
sending or receiving the information, are
abstraction levels.
responsible for “mapping” data to the information
model used, verifying the data that is transferred This digitization process has traditionally been
and developing business logic to use the data. designed and implemented by humans, see Figure
Relating back to the example presented in 2.1.4, 2-3. Humans use specific concepts to map real-
the symbol represents the transferred data, and the world things into their own ad hoc information
conceptual classes contain the information model, models (see 1 in Figure 2-3). These representation
including dependencies that can be mapped to the models are derived from the individual knowledge
context. of the specific humans involved and not necessarily
from a collective understanding of the associated
These digital information models constitute the
concepts. Such models take the form of naming,
basic building blocks necessary for understanding
assigning characteristics to things and identifying
and manipulating things. They can be used to
dependencies between things. The resulting
represent knowledge about things at any level
representations are machine-readable and human-
of abstraction, from basic properties, such as
interpretable information in the form of files, data
mass, length and time, up to the level of defining

27
Semantic interoperability: current models, future objectives and state of the art

Human user of the data

and information model
Information
e.g. motor, temperature ˚C

1 Add context and other 4

Knowledge Information
model A meta-information

Human designing the

information model Data
3
Data conversion
Digitation
of signals
to data
Information world
Analog digital converter 2
Real world

Electric signal

Access and understand

data using information
models
Sensor
Manual work design and Temperature
implement the mapping

Physical signals and

other data

Figure 2-3 | The digitization process of the real world

bases or perceptual forms, such as information then needs to be associated with the sensor
visually rendered on a display. These information performing the measurement and the device whose
models make it possible to receive machine temperature is being measured (as opposed to
data and perform operations on it. Humans use ambient temperature of the air, or temperature of
predefined patterns to connect the data in the another motor a few meters away, ...), and of course
current situation to a known set of potential as the measurement takes place in time, the exact
activities according to previously learned schemas time the temperature was measured also needs to
and can understand the data by how it fits these be represented. All of this together forms part of the
patterns. overall context (see 4). Only if all of this information
is available can a person understand whether the
Consider, for example, the temperature of a motor
motor temperature is in the nominal range, or is too
in a machine. The temperature must be digitalized
high or too low, and only then if these ranges have
so that motor performance can be monitored and
been defined for the motor. “Understanding” in this
evaluated. The analogue signal from the machine
example means that for this specific motor, in this
must be converted from an electrical signal to a
application and in the specific mode defined the
digital numeric value, such as a floating-point
temperature value is compared with the nominal
number. This is usually done by an analogue-to-
range. This understanding is necessary in order
digital converter (see 2 and 3). The type of quantity
to determine whether a correction is required. An
(i.e. temperature) is undeniably important, as is
individual with knowledge of electromechanics can
the unit of measurement (e.g. °F or °C). Thus, the
define and implement all of these details.
measurement quantity can be represented as a
3-tuple sequence (i.e. a triple). The temperature

28
Semantic interoperability: current models, future objectives and state of the art

2.2.2 Understanding and human-generated descriptions

State of the art

Example 2: Human knowledge is normally represented in non-machine-interpretable ways

Human knowledge is usually presented in digital format, mostly as files including informal text, tables,
drawings, mathematical expressions and other information representations. The design and usage
of machines are based on these documentation types. Most of the descriptions involved must be
understood by humans and transformed into different representations, such as machine-readable
configuration files, source code subsets, data base content and more. This is time-consuming and can
even be a source of misinterpretations that result in errors. But machine-readable information models
are a necessary condition for machine-interpretable information models, which require an additional
step in the direction of higher degrees of formalism.

Examples of machine-readable descriptions that already form part of standards include:

§§ EDD (electronic device description – see IEC 61804, Parts 3 to 5), which is purchased together with
process control measurement and actuation devices. The EDD contains metadata, business logic
and user interface descriptions in a machine-interpretable format

§§ OPC UA (OPC unified architecture – see IEC 62541) is an interface description for operation data
of plants including an information model. In addition to the meta model, the information model
provides a standardized serialization, so that the type and instance descriptions (the so-called
node set) are machine-readable. The information model is designed by human individuals for the
device that is connected to the OPC UA server

Common knowledge 5

2
6

4
3
Mapped or merged Implicit
Implicit Information Information
information knowledge
knowledge model A model C
models

Digitation
Digitation
of human
Information world of motor signals
knowledge

Real world

Access and understand

data using information
model 1
Technical
Manual work design and descriptions
implement the mapping
Implicit
Physical signals or knowledge
human-like messages and
information

Figure 2-4 | Machine-interpretable information model of technical descriptions

A huge body (or volume) of technical descriptions form, as well as tables, figures, audio, video and
has been produced by and for human consumption, even 3D in virtual reality (see 1 in Figure 2-4).
e.g. manuals, standards, web pages in document

29
Semantic interoperability: current models, future objectives and state of the art

It is highly desirable that this information be standards and integrating that information into the
machine-interpretable without the need for human design and development process is performed
interpretation or translation, because this could by software developers (see 2). Humans can
allow machines to interoperate more independently. understand information even from another domain,
For example, an international standard, such as if they have the associated common knowledge
an OPC UA companion specification, contains (see 5). Therefore, a manual mapping between the
information (e.g. a power supply signal format) that original information and that used for a machine
must be integrated into products in order for these must be provided (see 3 and 4). Then another
to be certified as compliant with the standard. application can understand the design information
The OPC UA information model represents (in this of a particular part of the machine (see 6).
example) knowledge about the automation device’s
Another example involves collecting the knowledge
frequency converter, which is common for the
and experiences of operators, maintenance staff
automation domain but not outside that domain. If
and other industrial employees. This knowledge
this specification can be integrated into the motor
is implicit in the minds of the staff but needs to
model, then the system can manage data without
be explicitly represented in an information model
having compliance code built into the application.
as well. This is explained further in Section 3,
The design and development process of a product
concerning use cases.
such as a motor is highly dependent nowadays
on software tools. Extracting information from the

2.2.3 Cross-domain understanding (missing supporting information models; either depth

or breadth; reusability)

State of the art

Example 3: Humans share core knowledge and thus can correlate information across domains

Information models designed for human usage can be understood even across knowledge domains,
because humans possess knowledge about multiple domains and can derive missing information
from this common knowledge in order to connect it with the set of consequences in the context of
application.

Factory automation devices are connected to the control system via industrial communication systems.
These communication systems are also known as fieldbuses. The information models of the devices are
informally described in so-called fieldbus profiles. Unfortunately, the information models differ from one
fieldbus to another. Consequently, automation devices with differing fieldbuses are not interoperable
at the level of application data and functions. End users select a variety of fieldbuses in their plants
according to different preferences, business considerations and legacy needs. As a result, device
manufacturers offer the same device with different fieldbus communication interfaces.

For example, in the production domain there exist a variety of communication interfaces, such as
PROFINET, CAN, IOLink and EthernetIP. The user organizations of these fieldbuses have defined
device profiles specifying operation and configuration parameters with their metadata, i.e. a fieldbus-
specific information model of the devices. A device manufacturer has to map the data for its device
into different information models. A measurement value can be named as “output”, “process value” or
“measurement value”.

30
Semantic interoperability: current models, future objectives and state of the art

The data type can be float or unsigned integer 32 and differs for other metadata as well. Consequently,
the automation device user has to interpret different information models depending on the fieldbus.
If there are multiple fieldbuses in one plant application, mappings are needed between the fieldbus-
dependent device information models, because no semantic interoperability exists.

IEC TR 62390 has suggested a common device information model and a way to harmonize fieldbus
profiles. Unfortunately, this technical report is presently not in use due to fieldbus legacy models and
fieldbus organization policy, and thus the potential benefits for users and manufacturers are lost.
Additionally, this information model is informally described and not machine-readable. Before usage it
needs be extended by an according ontology model.

Common knowledge 4

Knowledge Information Information Information Knowledge

model B Knowledge
model C model D
1 2 3
Digitation Digitation Digitation
Information world of signals to of signals to of signals to
data data data

Real world

Access and understand

data using information
model

Manual work design and

implement the mapping

Physical signals and

other data

Figure 2-5 | Principle of the digitization of the real world – different concepts based on different
knowledge result in different information models

Usually multiple digitization processes of different understand the cell component data, and only
components (such as for motors, robots and if the information models of all components are
working cells, see Figure 2-5) are performed commonly represented (see 4 in Figure 2-5) can
simultaneously. they effectively use the models to understand the
data.
Engineers who plan and operate a working cell
work with all the components, and mainly with the The example involving the temperature and the
data and information models connected to these motor showed that there can be any number
components. Only if they have shared explicit of model relations needed to understand both
knowledge of the cell components can they temperature and motor together in different

31
Semantic interoperability: current models, future objectives and state of the art

contexts (e.g. temperature value, name, unit, time, some of the same model elements might appear
location, motor, motor operating temperature in models for a motor (see 1), a robot (see 2) and
range, etc.). These relations have to be described a conveyor (see 3), but it would be best if these
in the digital world and constitute important parts models were common to each component rather
of the information model. Only if there are well- than re-implemented, possibly differently, in each
defined relations between all parts of the context component model. In this example, the individual
can interoperability take place. quantity models, unit models, etc. become a
shared or common model.
If one aggregates all this information into a
single ontology, the model can become very To make matters worse, if machines try to cooperate
complex. Additionally, the ontology cannot be independently of humans, they can only draw on
easily supported and managed, due, among the models provided to them and cannot make
other things, to model changes and life cycle guesses about missing information and relations,
adjustments. But as has been learned in software as humans might/could do (see Figure 2-6). They
engineering, it is best to encapsulate information can potentially identify the information names/
into reusable components, so that the concepts of labels, but they cannot relate those labels with their
quantity, unit, dimension, device, and function can information model (except where programmers
be defined independently, in their own ontologies, have assigned associations directly to data values).
and then related by their (causal) dependencies This relation within the information model is
to the component models (e.g. sensor and motor). necessary, because the usage of data depends on
They can then be used in contexts other than motor this position in the information model. The usage
temperature, as needed. For example, in Figure 2-5 of data means that if the position in the information

Control Knowledge
programme

1
x
Digitation Digitation
of motor of conveyor
Information world
signals signals

Real world

Don’t understand data from

unknown information models

Access and use them

according to the control
programme

Manual work design and

implement the mapping

Physical signals

Figure 2-6 | Data can only be processed in a control programme if its meaning is understood
by the programmers

32
Semantic interoperability: current models, future objectives and state of the art

model is clear (i.e. the context is identified), the

machines can derive the intended activities. That State of the art
is, the data only indicates what happened, but the Example 4: Many machine applications
application can use the information model, and the have no explicit information model that
data provided, to infer what the intention was. This “they” can use to evaluate data
is semantic interoperability, and in this context, it
Many machine applications have no explicit
can be said “the machine understands” (see red
information model that “they” can use to
line at 1 in Figure 2-6).
evaluate, understand and respond to new
In the example depicted in Figure 2-6, the information, as their algorithms are too rigidly
motor information is not interoperable with the defined to be estimated for this purpose.
information model of the robot and conveyor belt. The usage of real-world data is programmed
The information provided by the motor cannot into the application software algorithmically.
be interpreted by the controller of the robot and Changes in the real-world asset require
conveyor belt in the same way a human would, reprogramming in the machine application
who can use his/her general technical knowledge software.
to conclude something from other information
The implication of this lack is longer re-
models. Based on such a conclusion, for example,
certification times, a higher likelihood of errors
the human can react to reduce motor speed or
that increase the risk of misinterpretation of
torque, if the temperature is too high, by initiating
data, the need for increased expertise on the
an action. Unlike the human, the robot and
part of developers, etc., all of which results at
conveyor control programme is tightly-coupled to
least in less competitive software.
the robot and conveyor belt information model.
In the example, the robot/conveyor might receive
the value which is labelled “temperature”, but it
Machine-interpretable information models for
would not be clear to the robot/conveyor’s control
different application domains are highly desirable
programme exactly where the temperature value
(see Figure 2-7). One reason for this is the existence
has been measured, and since the unit is not
today of highly distributed supply chains covering
available, the machine cannot know that the value
logistics, production and packaging across different
is in fact a motor temperature, let alone whether
enterprises and countries, or complex engineering
the value is in the nominal operating range or is
processes covering different working fields, such
too high. Even if the robot/conveyor controller
as mechanics, electronics and control. One option
has implemented a clear algorithm for operating
is to bring together the knowledge of the different
range and alarm values, the relation between the
information models (see 1, 2 and 3 in Figure 2-7),
value and the right part of the algorithm cannot be
so that the different kinds of data involved can
derived. The reason for this is that the controller
be interpreted independently of their source. This
information model is limited and excludes the
mapping or merging of models (see 4) is guided by
motor information model. The only way the robot/
humans. Consequently, a machine (see 1) that can
conveyor controller can react appropriately to the
access the mapped or merged information model
motor is if it has access to the motor information
of other domains (e.g. different kinds of machines)
model, like the human does.
can understand the data related to those domains/
machines.13

13 Please refer to the “Babel Fish” of Douglas Adams book Hitchhiker’s Guide to the Galaxy, in which the Babel Fish represents a
universal language translator. In this case, it is more a universal language than a universal language translator that we are talking
about.

33
Semantic interoperability: current models, future objectives and state of the art

Common knowledge
4

Mapped or merged
information models

2 1 3
Knowledge Information Information Knowledge Information Knowledge
model A model B model C

Digitation Digitation Digitation

of motor of conveyor of working cell
Information world signals signals signals

Real world

Access and understand

data using information
model

Manual work design and

implement the mapping

Physical signals

Figure 2-7 | Cross-domain usage of digital information based on understanding different

digitization concepts

State of the art

Example 5: Machine information models generally cover a single knowledge domain

Information models designed for machine usage often cover a single knowledge domain. If a machine
needs to understand data from another machine, a direct usage of that machine’s information model
is often not possible. This is an illustration of failed semantic interoperability, because an additional
mapping or integration between information models must be designed manually by humans who have
the knowledge common to both machines.

One example of a response to this problem is IEC 61131-3 covering the PLC programming language,
which is general for PLC programming. The organization PLCopen has specified domain-specific
libraries, such as for motion and safety. These contain semantically relevant content which is expressed
in a machine-interpretable language. When the PLC model is related to these domains, interoperability
is increased, because a general model and a more specific model are now integrated in order to
accommodate greater variety.

Another good interoperability-increasing example is the use of IEC 62541 covering OPC UA (see state
of the art example 2). So-called companion specifications also exist, which specify domain-specific
knowledge in terms of the OPC UA metamodel. Examples of these domains include robots, extruders
and drives, but also IEC 61131-3 and AutomationML (IEC 62714). The configuration of OPC UA contains
explicit domain knowledge and is based on discovery functions of OPC UA. These become machine-
interpretable, which improves interoperability.

34
Semantic interoperability: current models, future objectives and state of the art

One more good example: If the domain-specific specifications would use a common IEC CDD vocabulary,
as is already provided for some domains, this could enhance semantic interoperability. The IEC CDD
Standards for example provide application- and system-agnostic definitions. These definitions can be
used in different information models, so applications which are using different information models can
rely on the interpretations of the standard definitions.

2.2.4 Integrate machine learning into cross-domain understanding

State of the art

Example 6: Learning is not generally integrated into information models

Self-adaptation of information models during their lifetime is not yet state of the art. This capacity is still
a focus of research activities.

Machine learning (ML) is a technology that can be used to classify or predict events. It does not
involve a knowledge-based approach and cannot explain how/why a classification or prediction was
construed. It can analyze very large amounts of data statistically. Knowledge representation does not
lend itself to learning but is very time-consuming to build models for and to extend. So model extension
could benefit from ML, and both tools and approaches exist autonomously at the present time.

3 4
Explicit Map knowledge Common Map knowledge Explicit
knowledge model A to common explicit machine model C to common knowledge
model A machine model knowledge machine model model C

Learn from Learn from

information @/'%"#%$&
information
2 )"#$%&'()$" &$-/, A
model A model C
1
Implicit Information Information Implicit Information Implicit
knowledge model A model B knowledge model C knowledge

Digitation Digitation Digitation

of motor of conveyor of working cell
Information world signals signals signals

Real world

Access and understand

data using information
model

Manual work design and

implement the mapping

Physical signals

Figure 2-8 | Learning to understand different digitization concepts and integrating these
into the digitization concept of a specific machine or plant

35
Semantic interoperability: current models, future objectives and state of the art

Human-guided/manual ontology mapping or Figure 2-8 illustrates that new digitalization of motor
integration is a very time-consuming and resource- signals (for example, see 1 in Figure 2-8) might be
intensive process. Learning about the world helps used to augment knowledge Model A through the
us humans to understand one another. Therefore, use of learning (see 2), and that the model can be
if machine learning could be used to learn from mapped to the common motor model (see 3 and 4).
existing information models in order to extend The same approach could be applied to all of the
knowledge and bring this new knowledge into the machines.
common information model, this would represent
an advanced step. Like humans, machines that
continue to learn about their common world might
better understand one another (see Figure 2-8).

36
Section 3
Challenges and motivation of semantic
interoperability: 7 use cases

We have presented the notions of interoperability, factories involve similar tools and approaches
semantic interoperability and the current state of (such as BOP and BOM).
the art in semantic interoperability. We now turn
In the same way, the production of machine parts
our attention to a few industry use cases that
and machines in a plant and factory14 (see 2) have
demonstrate these concepts in greater detail,
their own similar tools and approaches. The entire
while identifying gaps between the state of the
life cycle of the design and development phases,
art and what is additionally needed to implement
being preparatory to production, occur in the
these use cases.
information world, where humans work with their
specialized tools. The production phases have
3.1 Application fields of the use both real-world aspects (see 2, i.e. the production
cases of goods) and information world aspects
This white paper focuses on industrial automation, (see 3), such as control and supervision. Different
in which design and development (see 1 in Figure kinds of knowledge are involved in these design,
3-1) of machine parts, machines, plants and even development and production processing phases,

Part of a machine
Part design and
development 1 Part production control and supervision 3
Construction information Delivery of parts
Machine

Machine design and

development
1 Machine production control and supervision 3
Construction information Delivery of machines

Factory
Information Factory design and Production in the factory control and
world development 1 supervision 3

Real world
Part production 2
Machine production 2
Things
Production in the factory 2

Processes in life cycle phases

Figure 3-1 | General industry processes

14 This organization (e.g. logistics, inventory control, human resources) and hierarchical structure is modelled, among other places
in IEC 62264/ISA-95.

37
Challenges and motivation of semantic interoperability: 7 use cases

such as mechanical and electrical engineering, between parts, machines and factories mentioned
electronics, pneumatics, measurement, actuator above. Some processes within an electrical grid,
engineering, control theory, and many others. The such as market coupling, grid dispatch and grid
engineering partners acting within or between planning, are applied to the entire grid (i.e. asset
processing phases, or between process chains, portfolio). Moreover, grid operation and grid
need to interact and be interoperable. For example, renewal/upgrade are applied on asset systems,
no matter how a part is used in an engineering tool, while grid maintenance is applied on (specific types
it remains the same part and should be referenced of) assets. Among these, market coupling, grid
as such. As a result, the interactions between the dispatch and grid operation are more automated,
tools must extend beyond data conveyance to while different information models have been
include data understanding, in order to support developed separately for different processes. As
application interoperability. This is true for humans a result, interaction between the processes has
working with a design, development, control or become a major challenge. See A.2.2.1 for more
supervisory tool, and for a machine reacting directly details.
to incoming data. The trend that involves large
Industrial semantic interoperability-related use
companies cooperating to provide comprehensive
cases focus on engineering processes crossing
services to their customers requires semantic
different life cycle phases and knowledge domains.
interoperability for seamless data flow.
Illustrative engineering use cases are shown in
As an example, an electricity grid contains a Figure 3-2.
physical hierarchy of parts, assets (e.g. cables,
The seven engineering use case examples
transformers), asset systems (e.g. connection,
illustrated in Figure 3-2 are itemized below and
substation) and an asset portfolio (e.g. a high
examined in greater detail.
voltage grid), which is similar to the relationship

1 5
6 Model and data acquisition into Automated matching of
Maintenance and semantic- information models engineering requirements with
based failure detection asset skills

Semantic-driven engineering
incl. discovery, configuration,
and orchestration of
automation systems System
7
4 cooperation/collaboration

Access to assets with

Semantic-driven bootstraping integrated semantic
information models
3 2

Figure 3-2 | Interoperability-driven tasks during industrial engineering and production

38
Challenges and motivation of semantic interoperability: 7 use cases

§§ UC-MDA-01 Acquisition of models and Underlying themes of the use case types include
data from human-centric documents: four general requirements and gaps that apply
Semantics can be used to convert information across all of the cases:
from traditional forms of media into machine-
§§ Model development and best practices:
understandable models
Those who develop models must be able to
§§ UC-AA-02 Access to objects/assets with read and understand them
integrated semantic information models
–T
he identified gaps are associated with
(see 3.2 and 2.3.6): Semantics can be helpful
inconsistent semantic best practices, includ-
in discovery and understanding
ing those affecting naming conventions,
§§ UC-BS-03 System bootstrapping: Seman- design practices, metadata
tics can help configure and deploy devices into
§§ Model integration: Those who integrate
automation systems
models need techniques and procedures with
§§ UC-SE-04 System engineering: Semantics which to do so
can help bridge different verticals, such as
–T
 he associated gaps concern the application
engineering and procurement, planning,
and use of such techniques. No such tools
facilities, operation, asset management,
exist yet to assist in this process
maintenance, etc.
§§ Model management: Those who curate
§§ UC-AS-05 Matching of engineering re-
standards should take control of the information
quirements and asset skills: Semantics
models associated with those standards
can help in binding data to complex integrated
models – Many curated15 standards contain no official
(standardized) information models
§§ UC-FD-06 Diagnostics with semantics-
based failure detection: Similar to the –C
 urated standard information models need
previous case, semantics can be used to bind coordinated integration to create domain
data to predict or explain behaviour models (S_A ➞ S_B)

§§ UC-CC-07 System cooperation/collabo- §§ Model creation and standardization: Many

ration: Semantics can help machines interact standards rely on knowledge that will never
by understanding each other’s capabilities and take the form of standards but is “standard-
roles in an industrial process ized” by universal acclaim (e.g. in textbooks)

Each of these use cases will be described and –S

 tandards bodies should consider
illustrated, along with their requirements and any broadening the information model ecosystem
discovered gaps in the ability to implement them to include “book knowledge” such as that
using current technology. provided in engineering physics (perhaps by
funding universities to extend models)
More detailed versions of use cases appear in
Annexes A and B.

15 Standards need a lifelong accompanying process i.e. correction of faults, observation of the domain and improvement or
adaptation of the content. In this white paper the term “to curate a standard” is used to describe this process.

39
Challenges and motivation of semantic interoperability: 7 use cases

3.2 Use case 1: UC-MDA-01 In order to be able to access and reason about the
Acquisition of models and data various components in the plant and about their
from human-centric documents interactions, information which is commonly found
in human-centric documents and their associated
Although model and data acquisition is not explicitly
models (see 1 to 6 in Figure 3-3) must be made
a semantic interoperability use case, it drives many
available in machine-understandable forms (see 7
such cases, in that semantics cannot support
to 12), and then aggregated into a common model
industrial automation if no semantic models exist,
(see 13), so that they can be cross-referenced
and much of the technical know-how available is
and used in engineering tasks such as design
dispersed in a myriad of documents. Use case
and operation. Some specific document types
1 is based on the “find and update something”
shown in this figure include a general model of
scenario b of Figure 1-1.
chemical reactions (see 1), a measurement point
in the piping and instrumentation diagram (P&ID)
3.2.1 Use case description
(IEC 62424) (see 2), a control diagram (see 3) and a
This use case can be associated with semantic wiring diagram (see 4). See Annex A for a detailed
interoperability and with industrial automation discussion of this and the following two use cases.
through an example of system engineering in a
chemical processing plant, as shown in Figure 3-3.

Common knowledge
7

Mapped or merged
information
models

1 2 3 4 5 6
Information Information Information Information Information Information
model A model B model C model D model E model F

Digitation of technical Digitation of super-

Digitation of Digitation of Digitation of Digitation of
resources and visory graphical
chemical reaction plant structure DCS wiring in DCS control logic
user interface

8 9 10 11 12 13
Pre-product 1

Chemical
reaction T Ethernet/PROFINET

I
Resulting T
B
1
PROFIdrive
Identsystems

product 3 I PN/P A
0
Pre-product 2
PROFIBUS

B 2
1 T
DP/PA
link
0
PROFIBUS

I
3 C PROFIBUS PA
B PROFIBUS PA

1
0
4 PROFIBUS PA

Access and understand

data using information
model
Manual work design and
implement the mapping
Physical signals

Figure 3-3 | Multiple-domain information is bound to human-centric documents

40
Challenges and motivation of semantic interoperability: 7 use cases

3.2.2 Requirements that information concerning the reactor, plant, etc.

is currently found in human-centric documents.
Two requirements are necessary in order to move
Assuming that these documents can be converted
away from human-centric documents in systems
to machine-understandable models (see 7 to 12
engineering:
in Figure 3-3), they cannot be completely useful
§§ Models: Information models capable of in systems engineering tasks (e.g. design and
representing the knowledge and data conveyed operation) unless they are available as an integrated
in human-centric (unstructured) documents whole or common model. Referring again to the
must exist and be queryable diagram, the general chemical reaction model
§§ Model/data migration: Techniques for (see 7) is needed so that proper temperature for
parsing unstructured documents to underlying the reaction can be monitored and controlled.
models are required Additionally, plant mechanical data (see 8), DCS
(see 9), electrical (see 10), control logic (see 11) and
3.2.3 Gaps supervision (see 12) must all be available to the
system model (see 13). See Annex A for a detailed
§§ Information models representing the conceptu-
discussion of this and the following use case.
al information that is conveyed by human-cen-
tric (unstructured) documents do not exist
3.3.2 Requirements
§§ Mechanisms to parse human-centric (unstruc-
Three requirements are necessary in order to move
tured) documents into their constituent se-
away from individual/localized models in systems
mantic parts and relations have not been de-
engineering:
veloped
§§ Integrated models: Information models
3.3 Use case 2: UC-AA-02 representing depth and breadth of use case,
Access to objects/assets integrated so that the various models act as a
with integrated semantic single model
information models §§ Integration: Mechanisms and policies for
This is the most general of semantic interoperability integrating ontologies
use cases, based on the “find and update §§ Access: There must be mechanisms in place
something” scenarios a and b in Figure 1-1, in which to traverse information models and to perform
we query against a model and a repository to find database-like CRUD16 operations
out about an instance or instances that satisfy the
query constraints. It is, in fact, the way we discover 3.3.3 Gaps
what the capabilities and limitations of an ontology
§§ There exist insufficient information models
are, or test a model implementation, and it forms
in reusable chunks. No accepted method
the basis for all model-based reasoning.
is available for integrating ontologies, other
than to create larger ontologies. The glue
3.3.1 Use case description
(or commonality) necessary for integrating
Returning to the chemical processing plant, as individual models is often physics, and no
presented in Figure 3-3, consider the reactor. In common ontologies exist for engineering
the previous use case, the focus was on the fact physics

16 SPARQL supports repository CRUD operations: create, read, update, delete. In SPARQL they would be referred to as construct,
select, insert, delete. In fact, in SQL the names are the same.

41
Challenges and motivation of semantic interoperability: 7 use cases

§§ The lack of sufficient skills for developing The control application (see 3) runs and is expected
reusable queries against the model requires to continue its functionality after adding the new
the development of expertise that is not yet device. Values from existing sensors and actuators
uniformly available are exposed over a controller and integrated into a
vertical system (see 4) thanks to existing standards
3.4 Use case 3: UC-BS-03 System (e.g. IEC 61804, IEC 61784, IEC 62769, IEC 62453,
bootstrapping etc., see 5). These standards specify the semantics
of device properties and data. Let us assume
When a new device is added into an existing
that our goal is to develop a new application that
automation system, a “smart” system should
requires an additional device. Suppose that we
support “plug and automate” capability, by which
need to add a new temperature sensor for the new
the system recognizes, understands and can begin
device, and that the information model of the new
interactions with the new device. This bootstrapping
temperature sensor (see 6) is not compatible with
capability is represented by the scenarios b and c
the vertically integrated automation system. On the
of Figure 1-1 (b for the model interoperability, and c
other hand, we just want to be able to plug the
for the interactions thus enabled). See Annex A for
new device in and to make it available for the new
a detailed discussion of this use case.
application as simply as possible.

3.4.1 Use case description The only way that the automation system can
understand a new device is if the new device
Automation systems evolve over time. A common
information model is already known or is added
cause for such evolution is introduction of a new
into the system when the device appears.
functionality that needs to be provided. Figure 3-4
depicts an existing automation system (see 1) and
a new device (see 2) that needs to be added to the
system.

Edge/cloud apps
4

Network
1

Industrial Ethernet communication

Drive device
Ident systems
3 Coupler
2
Link
Sensor/actor bus

Field device
Field device Semantic models of
installed Semantic model of
5 instrumentation new device 6
Fieldbus Field device

Figure 3-4 | Bootstrapping a new device to an existing automation system

42
Challenges and motivation of semantic interoperability: 7 use cases

3.4.2 Requirements §§ No semantic best practices exist indicating how

to integrate ontologies to suit an integration
§§ Adoptable semantic device models: A
problem
system information model can be adapted
to the new device model (i.e. semantically
compatible with respect to the plug and
3.5 Use case 4: UC-SE-04 System
operate task)
engineering
Most industrial automation use cases boil down
§§ Mapping between semantic models:
to creating or analyzing data to support a task. In
Mechanisms for building mappings between
terms of semantic interoperability, this is based on
ontologies are needed
the “update something” or “operate on something”
§§ Human expertise in building semantic scenarios b and c of Figure 1-1.
models: Expertise in building mappings
between information models is needed 3.5.1 Use case description of a part of a
chemical plant
3.4.3 Gaps
The example we have been examining is the
§§ Most engineering systems are built from shallow reactor in a chemical processing plant, as shown
semantic models, and this makes it very difficult in Figure 3-5.
to add unknown devices into a system

Pre-product 1
1 Product 3
Chemical
reaction

Pre-product 2

Engineering
Equipment/technical Information processing resources -
2 resource 4 automation system

3
TI
B102
Industrial Ethernet communication

Drive device
Ident systems

Coupler

DP/PA
Link Sensor/actor bus

6
Field device
5 Field device

Fieldbus
Field device

Figure 3-5 | Engineering of a chemical process

43
Challenges and motivation of semantic interoperability: 7 use cases

Figure 3-5 illustrates aspects of a chemical 3.5.3 Gaps

processing plant that typify system engineering in
§§ A combination of standardized and non-
general, in which the engineering team (see 4) must
standardized information models is needed,
coordinate the design, operation and maintenance
which, when integrated, provide access to all
of the plant and its control system. These data-
the knowledge domains required
centric, operational tasks can be modelled and
run at different levels of granularity and depend on §§ Historically the logic models are separate from
integrated models, the ability to match data to the the information model
integrated model and the ability to reason over the §§ Moreover, no standardized information mod-
whole in different ways. el17 exists describing the relation between the
The engineering process starts by defining a knowledge domains, for example, showing for
chemical reaction which combines (in our example) the temperature sensor the mechanical prop-
two pre-products 1 and 2 and results in product erties, such as bolt diameter, or the electrical
3 (see 1 in Figure 3-5). This chemical process properties, such as internal resistance. Their
is performed by a plant (shown as a schematic representation in the PLC programme or in the
at 2) which details a reactor, represented by a symbols of the supervisory system is not yet
so-called P&ID. The P&ID describes all of the used in the engineering domain
technical resources of the plant (i.e. pipes, valves,
vessels, pumps, heat exchanger, etc.), as well 3.6 Use case 5: UC-AS-05
as the requirements for the automation system Matching of engineering
in terms of measurement and actuation points. requirements and asset skills
These measurement and actuation points have to Identifying a candidate device by matching
be implemented by suitable automation devices its skills/capabilities with provided data such
(see 5), which become parts (see 6) of a control as requirements is a classic case of the “find
system (see 3). See Annex A for a detailed something” and “update something” interoperability
discussion of this use case. scenarios a and b of Figure 1-1.

3.5.2 Requirements 3.6.1 Use case description

Two requirements are needed to support a variety Consider a situation in which functional
of system engineering tasks: requirements have been provided (see 1 in Figure
§§ Data matching: In order to analyze data, 3-6) for some aspect of automation, such as turbine
one must be able to map the data into the maintenance, where it might be necessary to swap
information model using pattern matching out a worn shaft bearing and to identify bearings
(see 2) that meet turbine design requirements (e.g.
§§ Analysis: In order to perform operational
maximum speed, lubrication type, bearing type). If a
tasks, one must be able to apply logic, which
match can be found, the candidate bearing, bound
requires that logic be developed either as
to the known attribute values and requirements,
an integral part of the information model or
would be made available for processing.
separate from it

17 A few ad hoc engineering semantic models are available.

44
Challenges and motivation of semantic interoperability: 7 use cases

1
Requirement Match requirements
data and device skills

2a 2b 2c 2d
Information Information Information Information
model A model B model C model D

Figure 3-6 | Skill use case

Skill-EM_Bridge Engineering QUDT-EM_Bridge

ontology mechanics ontology

3
Skill-QUDT_Bridge
system agnostic Skills QUDT
ontology

T-Skill_Bridge 5 Req-Skill_Bridge Requirements

ontology ontology ontology
4

locally defined Turbine ontology Requirements data

2 1

EM: Engineering mechanics

T: Turbine
QUDT: Ontology schema which provides semantic specifications for units of measure, quantity kind, dimensions and data types

Figure 3-7 | Data matching to model and vocabulary creation

45
Challenges and motivation of semantic interoperability: 7 use cases

Figure 3-7 shows what is required to achieve this §§ Model integration: Historically the logic
goal. Input to the process is a set of requirements models are separate from the information
(in the form of data) specific to the task (see 1 models
in Figure 3-7), and the associated device and
§§ Ad hoc vs system-agnostic models: In
component models are available to the process,
order to get the most out of information
some possibly defined in standards and others
models, it would be necessary to separate
defined by the turbine company.
locally defined models from more general
If the skill model is embedded in the device model, and reusable models, the latter becoming a
then each device must implement a skill model. If reusable information corpus
the skill model is separated and integrated with the
turbine model (such as depicted at 3 to 5), then
3.6.3 Gaps
it can be used to define skills across all devices.
That is, it implements a modular approach similar §§ Skill in developing multi-ontology SPARQL
to object-oriented encapsulation. The same can be queries, functions is lacking
said of requirements for any other model. §§ General-knowledge information models span-
Suppose that the company-defined turbine model ning the knowledge required for the use case
only models parts such as turbine blades, rotor, do not exist
stators, housing, and bearings as a set of connected §§ Models have defined uses limited to a particular
components. Each of these components has one use-case solution and might not be reusable
or more skills or capabilities that could be modelled
§§ Interoperability with other systems will require
with a skills model (see 3), if it is separate from the
direct mapping (which is inefficient, time-
device model.
consuming and involves heavy maintenance
This scenario illustrates semantic interoperability cost)
because it requires multiple dependent and
interacting models and a pattern matching 3.7 Use case 6: UC-FD-06
capability to match the requirements to those Diagnostics with semantics-
models. based failure detection
Identifying a problem before it occurs or explaining
3.6.2 Requirements it after it has occurred both require matching of
Two firm and one optional requirements are needed data to models, and the use of reasoning. The
to support a variety of system engineering tasks first aspect of this problem was articulated in the
that match data to complex and possibly curated previous use case and thus will not be covered
(i.e. immutable) information models: here again. Reasoning is a classic case of the
“operate on something” interoperability scenario
§§ Data matching: In order to analyze the
c in Figure 1-1. Whether this involves prediction
requirements data, one must be able to map
(modus ponens) or explanation (modus tollens), it
it into a (requirements) information model using
utilizes the same inferencing mechanism, so we
some form of pattern matching
will focus on prediction, which involves forward
inferencing and simulation.

46
Challenges and motivation of semantic interoperability: 7 use cases

3.7.1 Use case description 3.7.2 Requirements

Devices and components can fail. This causes Failure detection requires access to data, a
downtime of machines or plants and requires dynamic functional/behavioural device model and
additional effort for repair and restarting of the the ability to reason over the dynamic model, given
plant. It is desirable that potential failures and errors the data. In addition to the three requirements from
can be detected before they occur. This is possible the previous use case, two additional requirements
if a simulation or analysis of the running device are needed to make semantic inferences about
(or component) exists based on online data and data for prediction and explanation:
a functional/behavioural information model of the
§§ Semantic reasoning: Match data to a
device or component. A larger set of components
dynamic model (e.g. a rule), produce a result
is frequently used in industry, such as pumps,
and iterate the process until a solution is found
heat exchangers, welding or gluing tools, conveyor
belts, turn tables and many other elements. §§ Knowledge-based reasoning: These mod-
Each component has its own function/behaviour els include all/most forms of dynamic logic
model built on top of generalized function/
behaviour models (and even engineering physics). 3.7.3 Gaps
These models have contextual dependencies §§ Reasoning engines are brittle, because they
(enablements, disablements, initiating and termi- exist in a separate system, requiring translation
nating conditions, etc.) coming from sensors and to and from the information repository
other contextual information.
§§ Logic implementations are limited to known
For example, a pump which has a defined function interactions and cannot be easily adapted to
to increase fluid flow rate, or increase pressure, changing information dependencies
can be supervised by the pump input and output
pressure, flow rate and temperature (these are 3.8 Use case: UC-PM-06b
process variables of the pump and the variables Semantics to facilitate
which have to be used during the calculation of the preventive maintenance
pump analysis). The task is currently/commonly in electric grids
solved by binding the algorithm variables with
Maintenance in the grid can be reactive or proactive,
the sensor data. This is mostly done manually,
but its information model always depends on
because the access path to the variable is hidden
asset models. In most cases, different assets (i.e.
in the application programming interface (API).
from different manufacturers or different systems)
If the pump information model were semantically are incompatible in data exchange18 and require
interoperable, an automatic connection between human involvement to convert data from one
algorithm and measurement data would be device or system to another. The present use case
possible. To configure the reasoning algorithm, a illustrates aspects of the previous two use cases
binding of sensors to pump must be effected. The that implement the “understand something”, “find
sensors are part of the overall automation system, something”, “update something”, and “operate
are located somewhere and are connected in the on something” interoperability scenarios a to c in
control system. Figure 1-1. The business background of this use
case can be found in A.2.2.1 of Annex A.

18 Meaning that data for devices that do the same thing cannot be shared between systems.

47
Challenges and motivation of semantic interoperability: 7 use cases

3.8.1 Use case description §§ Semantic risk identification and assess-

ment: A mechanism must be in place for
An essential responsibility of operating an
simulating causal events or explaining how an
electric grid is to manage the (un)availability of
event might have occurred
its assets and asset systems. There are multiple
scenarios which can affect grid part availability.
Traditionally, the low- and middle-voltage grids 3.8.3 Gaps
follow a corrective methodology, which waits until
§§ Prognostic information models are currently
the protections isolate a failure or a client reports
developed in an ad hoc way and not unified
an issue. The high-voltage grid tends to plan
even for the assets of the same grid operator.
unavailability through preventive maintenance,
Failure modes are seldom standardized to the
while a safe period/frequency of maintenance is
extent of asset specifications despite following
suggested by prognostic information such as asset
well-defined theoretical and academic content
age, inspection or diagnoses. In either case, data
is matched against asset and failure models, and §§ Maintenance plans do not comply across grid
actions are suggested and later performed on the operator infrastructures, despite the existence
actual hardware and systems. of standards such as IEC 60300-3-11.
Interoperability in maintenance will continue to
The vast majority/proportion of prognostic
have to be realized manually in the next decade
information is currently processed by humans.
Nevertheless, many use cases in the electric §§ When explaining individual hazardous events
grids involve machines gathering prognostic as links in casual chains, a standard information
information. In one case, the output from model is lacking
multiple visual inspection methods, such as on- §§ Reasoning engines are brittle, because they
site staff, robots, drones (UAVs) or helicopters, exist in a separate system, requiring translation
is harmonized to provide clear, consistent and to and from the information repository
machine-understandable commands to the (more
automated) operations side.
3.9 Use case 7: UC-CC-07 System
cooperation/collaboration
3.8.2 Requirements
Cooperation and collaboration are essential as-
The semantic requirements for preventative pects of modern automation, where machines need
maintenance are fourfold: to interact and understand each other minimally
§§ Semantic asset models: Either consistent in terms of their capabilities and scheduling
asset information models or common models availability. For future applications, conflicts,
with adapters to legacy models must exist competition and complementary functions will
have to be addressed. Only then can they act
§§ Semantic failure mode models: Information
autonomously of humans at the manufacturing cell
models must exist that represent asset
level. Cooperation and collaboration in this context
function and use, and thereby capture events
involve messaging, understanding the message,
that disable desirable functionality
and acting on the knowledge conveyed in the
§§ Semantic maintenance plans: A model of message. This represents a combination of the
action plan (i.e. planning model) is necessary interoperability scenarios a, b and c of Figure 1-1.
and an integration of the planning model with For this white paper we focus on cooperation to
the device usage models derive the requirements and gaps.

48
Challenges and motivation of semantic interoperability: 7 use cases

3.9.1 Use case description the other robot (System B) to drill a slightly larger
hole in a door, to better align it to the vehicle.
Suppose that we have a manufacturing cell for
System A has to take the detailed properties of
assembling automobiles, comprising two assembly
the door, the vehicle, the original diameter and
robots, a conveyor and a vehicle being assembled.
placement of the existing hole, the alignment error,
It is important that both robots know what their
etc. from available door, vehicle and project data
roles in the assembly are (e.g. attaching the driver
(and associated and possibly shared information
door to the vehicle) and how to perform their
model (see 1)) and start a request process
tasks (i.e. basic understanding about attachment,
(see 2) to other systems.
and associated information about fasteners,
connection, alignment, etc.), as well as the roles of System A is in a waiting state for potential answers.
the other machines in the cell, what those roles are, There can be multiple other systems which are
and what to expect from them (usage, capability, in a position to drill a hole, but perhaps not this
and skill). Additionally, since these machines kind of hole, or in this material, or in the required
act as a soft (i.e. functional) unit, the scheduling realignment. The example in Figure 3-8 shows only
information (and information model) needs to be one System B. System B has to be in a state of
available to them as well. awareness concerning a possible request (see 2).
If a request comes to System B, logic must exist
This use case goes beyond previous use cases
in order to check (see 3) the intended drilling task
and extends the information models via function
properties against its drill skill information model
and behaviour descriptions. One example can
(see 4). For semantic interoperability, System B
be that a robot (e.g. System A in Figure 3-8) asks

Robot Robot
system A system B

Request 2
algorithms RequestDrilling (Property1, Property2, …)
3
Checking
algorithms
1 5
ResponseToDrillling (Property1, Property2, …) Information model B
4
Information model A

Decision Function
6 algorithms model B
Order (Property1, Property2, …) 8
Function 7
model A Reject ()

Figure 3-8 | System cooperation based on scenario “operate on something”

49
Challenges and motivation of semantic interoperability: 7 use cases

has to match the properties to its skill model and 3.9.2 Requirements
has to recognize the correct logic. The matching
§§ Information models including algorithms:
logic can involve a simulation, can start a function
Identification of the intended algorithm to be
for the comparison of the internal skills with
performed and data related to algorithms
the requested capabilities, or can forward the
are part of the information models (e.g.
request to a human or another system. If System
capabilities, skills, task scheduling, goals,
B does not recognize that this matching logic is
action, requirements, etc.)
requested, it has understood the message. This is
a combination of the “find something” and “operate §§ Connection of semantic behaviour
on something” scenarios a and c in Figure 1-1. If models: The information models have to be
System B functionality supports the requested connected to behaviour models
hole properties, then it can generate an answer §§ Semantic model of interaction pattern:
(see 5) and send the proposal to the requesting The partner systems have to know the general
System A. System B has to block the production interaction pattern
capacity for the offered task as long as the time
§§ Learn cooperation: Systems can learn co-
duration of the proposal is valid. Then System B
operation, collaboration, conflicts, competition
is in a waiting state for a potential order. System A
and complementary functions incrementally
has to check the incoming data with the instance
data of its internal model (see 8) and has to decide
3.9.3 Gaps
(see 6) if it is suitable (in the drilling example,
whether a specific diameter can be drilled, §§ Connections between the functional informa-
whether the material can be drilled, whether the tion models and the semantic protocols19 at
robot can reach the position, etc.) or not. Semantic the level of ontologies are not common
interoperability is supported if the properties can §§ When a mapping between information model
be matched to the information model of System elements at the level of concepts/terms exists,
A and the proposal can be identified to start the the link allowing to know what to do if the term/
decision logic. Similar to System B, the algorithm concept is identified is often missing
can be an easy function, an optimization algorithm
or a request to a human. Depending on the
decision, the answer is given (see 7) to System B. If
System B does not receive the order it can release
the blocked production capacity. If it receives the
order, the function has to be invoked.

19 Protocols between applications with machine-understandable content of the protocol messages.

50
Section 4
Semantic interoperability scenarios as they relate
to the use cases

The general semantic interoperability scenario –A

 d hoc vs system-agnostic models:
involves data being conveyed between two In order to get the most out of information
systems, each of which has its own information models, it would be necessary to separate
model and business logic. In Subsection 1.2 four locally-defined models from more general
semantic interoperability scenarios are introduced, and reusable models, the latter becoming a
which are referenced at each use case in Section reusable information corpus
3. The scenarios are arranged successively in such
–S
 emantic asset models: Either consistent
a way that “understanding something” (i.e. “having”
asset information models or common models
a model) is a prerequisite to “finding something”,
with adapters to legacy models must exist
which is a prerequisite to “changing something”,
which is a prerequisite to “operating on something”. –S
 emantic failure mode models: Informa-
tion models must exist that represent asset
4.1 General requirements for function and use and thereby capture events
semantic interoperability that disable desirable functionality

The requirements which are indicated in the use –S

 emantic maintenance plans: A model
cases are summarized in the order of the scenarios of action plan (i.e. a planning model) and an
as follows. The requirements occur if there is integration of the planning model with the
machine-to-machine interaction. Humans are no device usage models must be effected
longer in the loop. §§ Find something (see a of Figure 1-1)
§§ Understand something (see a of Figure 1-1) – M odel/data migration: Techniques for
– M odels: Information models capable of parsing unstructured documents to underly-
representing the knowledge and data ing models are required
conveyed in human-centric (unstructured) – I ntegrated models: Information models
documents must exist and be queryable representing depth and breadth of use cases
–D
ata matching for requirements: In must be integrated, so that the models act
order to analyze the requirements data, one as a single model
must be able to map it into a (requirements) – I ntegration: Mechanisms and policies for
information model using pattern matching integrating ontologies must be developed
– M odel integration: Requirements, skills – Data matching: In order to analyze data,
and other generic information models must one must be able to map it into an information
exist in addition to the use case specific model using pattern matching
domain models
– E xpertise: In building mappings between
information models is needed

51
Semantic interoperability scenarios as they relate to the use cases

§§ Update something (see b of Figure 1-1) 4.2 General gaps that complicate
– Access: Mechanisms must be put in place to semantic interoperability
traverse information models and to perform The gaps which are indicated in the use cases
database-like CRUD operations are summarized in the order of the scenarios as
–A
 doptable semantic device models: A follows. The gaps occur if there is machine-to-
system information model can be adapted machine interaction. Humans are no longer in the
to the new device model (i.e. can be made loop.
semantically compatible with respect to the §§ Understand something (see a of Figure 1-1)
plug and operate task)
–T
here exists no formal or standardized
– L earn cooperation: Systems can learn information model for a given collection of
cooperation, collaboration, conflicting, com- concepts for industrial engineering and
petition and complementary functions incre- operation in general
mentally
• he auxiliary or accompanying models
T
§§ Operate on something (see c of Figure 1-1) (so-called ad hoc models) that exist are
– A nalysis: In order to perform operational not standardized
tasks, one must be able to execute logic, •  odels certainly exist which describe
M
which requires that logic be developed and fundamental or basic structures and
invocable behaviour, and which are not yet
– S emantic reasoning: This mechanism standardized. Perhaps an effort could be
must involve matching data to a dynamic made to identify these and, if needed, to
model (e.g. a rule), producing a result and develop a model
iterating the process until a solution is found –G
eneral knowledge concerning issues
– K nowledge-based reasoning: Models such as physical phenomena is described
are needed that include all/most forms of differently across models. Information
dynamic logic models of common knowledge are not used
frequently enough
–S
emantic prediction or explanation:
A mechanism must be put in place for •  process is needed that recognizes
A
simulating causal events or explaining how general/common knowledge in specific
an event might have occurred standards and makes it widely available

– I
nformation models including algo- • Information models outside the IEC/ISO
rithms: Identification of the intended algo- standardization framework have to be
rithm to be performed and data related to considered as well, such as QUDT, SSN/
algorithms must be part of the information SOSA, etc.
models (e.g. capabilities, skills, task sched- –T
 he degree of formalization of the information
uling, goals, action, requirement, etc.) models is not sufficiently high (see Annex B)
–C
 onnect semantic behaviour models: • I nformation models need to be transformed
The information models must be connected into a formal description allowing matching
to behaviour models and reasoning to take place uniformly
–S
 emantic model of interaction pattern:
The partner systems must know the general
interaction pattern

52
Semantic interoperability scenarios as they relate to the use cases

§§ Find something (see a of Figure 1-1) §§ Operate on something (see c of Figure 1-1)

–T
 he vocabulary differs in information –S
tandardized and curated functional and
models designed for different knowledge operational models are not used in the
domains or different uses. This means that standardization mainstream. Additionally,
different descriptions of the same piece data and functional models need to be
exist (homonymous) or the same or similar designed and used together. A strategy is
information uses different vocabularies needed to determine how system-agnostic
(synonymous). Common vocabularies are functions can be identified and standardized
not used frequently enough
–C
 onnections between the information
•  discovery and evaluation strategy is
A functional models and the semantic
needed which evaluates standards as to protocols at the level of ontologies are not
whether an existing vocabulary is used in common
the correct way and which identifies new
vocabularies

–T
he use of human-centric documents is
still dominant in systems engineering, i.e.
curated standardized information models
are missing

• A campaign20 is needed to identify system-

agnostic phenomena and to determine
how they can be brought into a set of
connected information models in which
formal queries can be applied

–A
 strategy concerning how to combine small
curated and standardized ontologies to de-
scribe complete domain-specific standards
is lacking

•  ridging ontologies should be preferred to

B
building large comprehensive ontologies

§§ Update something (see b of Figure 1-1)

–M
 odels describing the relationships between
physical domains such as mechanics, elec-
tronics and pneumatics are missing, making
it impossible to derive engineering results
automatically

–P
attern matching and instantiations are
needed

20 Reconciled efforts by various stakeholders such as standardization bodies, academia and funding authorities is necessary to
increase the formalization of technical knowledge.

53
Section 5
Challenges involved in achieving
semantic interoperability

5.1 Technical considerations §§ Functions must be described in a formal way,

regarding the design of specifically the following functions:
semantic interoperable – “ If”-“then” rules
information models – Mathematical equations
The challenge of semantic interoperability is to – Is there a common set of “verbs” which
ensure that information exchanged is understood represent functions?
not only by the human beings on both ends of –A
re there common rules and functions
the ICT communication channel but also by the which apply independently of the application
computer systems and their associated software. domain?
Physical phenomena in common
• 
The following topics related to such exchanges
Units (e.g. kPa, kg)
• 
can be brought directly into standardization:
Physical relationships, such as position,
• 
§§ Glossary location and orientation, which depend
–S
 everal projects in ISO/IEC JTC 1/SC 41 on context but are otherwise domain-
and IEC TC 65/WG 23 dealing with seman- independent
tics-related terms include enough input Physical behaviours, such as motion,
• 

available to initiate standardization, i.e. in connection, force transfer, energy

the international electrotechnical vocabulary storage, elastic and plastic deformation
(IEV) (for mechanics and analogues in other
engineering fields), etc.
§§ System-agnostic ontologies for physical
–H
 ow to identify domain-specific rules/func-
phenomena
tions?
–E
 ven though standards and de facto stan- In
•  academic textbooks physical phenom-
dards exist in this field, a single consistent ena are explained (e.g. how hydraulics,
and comprehensive set of standards is pneumatics, valves, electrical devices,
missing which can serve as the reference for etc., work)
all standards using related concepts
Information
•  models need to be composed
out of the bricks of which the world itself
5.2 Topics which need more is composed (see Figure 5-1)
structuring/work in order
W ho
•  should be involved in bringing this
to propose precise actions
common knowledge, which is available
Not enough attention has been paid to function, in textbooks, into machine-interpretable
behaviour and usage models that are used to models?
glue more domain-specific models and standards
together.

55
Challenges involved in achieving semantic interoperability

Universal models
(upper ontology)
Cross domain models
(physics, chemistry, mathematics, time, units, naming)
Domain generic models
(mechanics, control, materials, electromagnetism)
Domain models
(statics, dynamics, kinematics, electromechanics)

Generic asset models

(devices, sensors, actuators, controllers)

Manufacturer specific models

(Siemens Design CC)

Figure 5-1 | Model layers from universal to manufacturer-specific

> In fact, the engineering world we live in 5.3 Topics which need more
is itself a layered model. We acquire very research
general concepts (which are themselves
§§ Changing semantic definitions (e.g. along the
about concepts) at an early age (upper
version path)
ontology) and slowly construct our
model of everything from there. Most §§ How to handle potential changes in the
engineering efforts intentionally ignore semantic models
this layering, because it is assumed that §§ How this can be identified and how the process
humans will be in the loop and that they and description can be designed
bring their knowledge to the task. But in
§§ Establishing an automatic check of semantic
the case of a machine, that knowledge
changes
needs to be developed. The good news
is that we know how humans learn §§ Automatic derivation of resulting actions (e.g.
these concepts (via books, teachers, building a bridge to allow users to work with a
professors, labs, etc.) and the only model independent of the version)
thing missing is the necessary effort to
§§ How to deal with changing semantic models
translate these concepts into information
from the user’s point of view
models

56
Challenges involved in achieving semantic interoperability

5.4 Overall view of semantic if necessary. The QUDT ontology (see 5) addresses
interoperability for integrated physical phenomena and is a best-practice
application and technologies example of these universal information models
defined in IT standardization. Cross-domain (see
An analysis of the current state of the art and the
2) and domain-specific (see 3) standards are well
gaps of semantic interoperability have made it clear
represented in industrial domains. This constitutes
that industrial and IT standardization are proceeding
a solid basis for semantic interoperability. For the
along different paths (see 9 of Figure 5-2).
most part, the level of formalization (see 16) is
The above assertion suggests that the needed insufficiently high. Formal ontologies at the cross-
standards can be identified as relating to three domain (see 6) and domain-specific (see 7) levels
basic categories: domain-independent models are currently available in IT standards. But existing
(see 1, 5 and 12 of Figure 5-2), cross-domain standards in both domains are not really integrated
models (see 2, 6 and 13 of Figure 5-2) and domain- (see 9).
specific models (see 3, 7 and 14 of Figure 5-2)21.
Step by step these two different worlds must be
Physical related domain-independent (universal) brought together (see 10 and 11). As suggested
information models (see 1) are not yet available in above, domain-independent phenomena have
the form of ontologies for most industrial standards to be separated into chunks and standardized
(see 4). Theses aspects are integrated in cross- (see  12). Cross-domain standards (see 13) have
domain (see 2) or domain-specific (see 3) standards, to be derived from existing ones by increasing the

15 Future standards
16
Domain-specific models
14 e.g.
14a = spec + 12a + 12b + 13x
Increase formalization

14a tbd

13a 13b … 13x e.g.

13 tbd
Cross-domain models
12a 12b … … e.g.
12 12x
QUDT
Domain-independent models
11
Industrial information model standards 10 IT information model standards
4 8
Domain-specific models e.g. P&ID, Domain-specific models e.g. Schema.org
properties,
3 smart grid,... 7
Cross-domain models e.g. PLC, Cross-domain models e.g. SSN/SOSA
automationML, ontology
2 9 6
Domain-independent Not yet defined Domain-independent e.g. QUDT
1 models (physical e.g. 5 models (physical e.g.
electrics, mechanics,...) electrics, mechanics,...)

Figure 5-2 | Strategic path for future common OT and IT standardization for semantical
interoperability

21 The eight layers of Figure 5-1 are abstracted for better readability.

57
Challenges involved in achieving semantic interoperability

formalization, if necessary. In the future (see 15),

domain-specific standards must be built by using
existing ones and must be extended by including
other domain-specific issues (in equation 14a, spec
means domain-specific issues). All future work
needs to emphasize a high level of formalization
(see 16) of the information model description.

15
Future Standards
14 Domain-specific models
14a
e.g., tbd
11a = spec + 9b + 9b + 10b

13a 13b 13x

13 … e.g., tbd

Cross-domain models
12a 12b 12x
12
e.g.,
Domain independent …
models … QUDT

11

4 Industrial Standards 10 8
IT Standards
3 Domain-specific models e.g., P&ID, Proper�es,
Smart Grid, …
7 Domain-specific models e.g., Schema.org

2 Cross-domain models e.g., PLC, Automal�onML,

9 6 Cross-domain models e.g., Sensor Ontology
Domain independent models Domain independent models
1
(physical e.g., electrics,
mechanics, …) e.g., ?
5 5
(physical e.g., electrics,
mechanics, …) e.g., QUDT

Common knowledge
2 4
System A Data 6 System A

7 Seamless along life cycle

8 Seamless cross-domain

9 Vertical AND horizontal

1 Information Information 3 Knowledge
Knowledge Knowledge model D
model B

Digitation Digitation
Information world of signals to of signals to
data data

Real world

Access and understand

data using information
model

Manual work design and

implement the mapping

Physical signals and

other data

Figure 5-3 | Semantic interoperability based on common OT and IT standardization

This strategy paves the way to reaching the basis for data exchange and understanding
standardized and curated common knowledge (see between systems (see 6 and Systems A and B).
5 in Figure 5-3) and builds the basis for the design Both the domain-independent and cross-domain
of information models (see 2 and 4) supporting information models comprise a solid foundation for
semantic interoperability. seamless semantic interoperability along the life
cycle (see 7) and across domains (see 8) as well as
These common models need to be constructed
for both vertical and horizontal data understanding.
according to specific aspects to build the
individual information models (see 1 and 3) that are

58
Section 6
Recommendations

Based on the findings contained in this white §§ Recommendations derived from the use cases
paper, several opportunities exist to move semantic presented in this white paper include:
interoperability forward, endowing systems with
–C  reate a registry for system-agnostic model
the means to handle more of their day-to-day
chunks and provide a means of model
operation without direct human control.
discovery
– Develop standards and tools for model
6.1 Recommendations addressed integration
to the IEC and its committees – O rganize expertise in standardization com-
The IEC, as one of the globally recognized de jure mittees and create means for standards
standards organizations, is in a unique position users to work with query languages
to drive semantic interoperability forward and to – Conduct studies to determine whether
identify conditions under which the application required information models and asset
of semantic technologies can be used to improve information models can be matched without
and achieve interoperability within and between additional means. If not, these means must
applications. be identified and standardized
– Undertake a commitment to move away
6.1.1 Recommendations concerning from ad hoc, one-off information models
the organization of the semantic toward a model that is institutional or even
interoperable information model industry-wide
design – Design and publish integration mechanisms
for information models in the form of best
§§ Initiate the elaboration of semantic interopera-
practice examples
bility standards for both the development of in-
– Initiate an effort to develop a survey about
formation models as well as their management
common cooperative, collaborative, conflic-
§§ Request the IEC Standardization Management tive, competitive and complementary plan-
Board (SMB) to consider forming a working ning patterns; and derive recommendations
group to develop a semantic interoperability from this survey concerning semantic proto-
best practices guideline, including conducting col standardization
a survey among IEC and ISO standardization
§§ Semantic interoperability best practice
groups. The survey should ask respondents
recommendations further include development
which semantically interoperable standards
of the following tools:
they are currently responsible for, which they
intend to develop in the near future and how –E
 xplicit description of the minimum
these various standards relate to one another consistent metadata for applications such
(resource map) as maintenance tools

59
Recommendations

– In-class comments and documentation –T

 he IEC should offer semantically interop-
– Naming conventions (folders, files, classes, erable information models and ontologies to
properties, instances, etc.) the public in order to test conditions
– Design guidelines (restrictions, other axioms,
properties, taxonomies, enumerations, con- 6.1.2 General recommendations to the IEC
trolled vocabularies) and other standardization bodies
– Logic implementation (validation constraints,
§§ Standardization bodies should:
rules, functions, examples)
– t ake control of the information models of the
§§ Based on the above-mentioned best practices
standards they manage/curate
guideline, develop information models for well-
– take control of the integration of their
known but non-standardized knowledge (i.e.
standard information models
textbook learning) and for existing standardized
– propose best practices that will form the
information models that today are not machine-
basis of building information models for the
interpretable
standards they curate
§§ Encourage development of tools for – propose best practices for integrating the
managing ontologies, not just GitHub but information models and ontologies of their
ontology prefix and import dependencies, standards
including version management (i.e. Maven for – consider broadening the information model
ontologies). This would include: ecosystem to include “book knowledge”
such as that provided in engineering physics
–C
 ontent discovery (and steps to identify
(this could include funding the efforts of
ontology relevance to a problem)
universities to extend models)
–
A pplication development (by SMEs) and
deployment §§ The owners of the models (the various tech-
nical committees) should work more closely
§§ The IEC must manage semantically interoper-
with one another with the objective of facilitat-
able information models, ontologies and data
ing the five co-xx (cooperation, collaboration,
dictionaries developed in the IEC and ISO
conflicting, competition and complementary)
–T he IEC needs to organize tools and functions
resources to handle ontologies and data
§§ The IEC should seek and initiate agreements
dictionaries, with the technical committees
with other standardization organizations to
and working groups being responsible for
develop and maintain common ontologies
the content
– T he IEC needs to ensure systematically that
6.1.3 Technical recommendations for the
information models and ontologies become
design of semantic interoperable
discoverable and that these provide data
information models
libraries including an API
– T he IEC should manage the semantically §§ General recommendations:
interoperable information models, ontologies
–S eparate the knowledge into reusable
and data dictionaries in such a way that the
chunks
model life cycle evolution can be machine-
– Look for existing chunks in curated standards
interpreted
– Define the glue between these chunks in
terms of the domain-specific use cases or
applications

60
Recommendations

– Add formal descriptions to the specification of –P ossibly augment information models to

information models in general (see Annex B) include logic that can be triggered by data
– Find or develop models representing the (such as during construction)
content in human-centric (unstructured) doc- – Locate, develop, and standardize dynamic
uments in a machine-understandable form models
such as XML or OWL/RDFS (see Annex B) – Design and standardize the connections
– Define machine-understandable information between information models including
models of requirements, including their functions and semantic protocols
constraints, in such a way that they can be
§§ Recommendations for the use of sematic
matched with the system information models
interoperable systems
which have to implement the requirements
–U se the reasoning opportunities that
§§ Information models – cross-domain
are available in the triple stores for logic
–S
elect a set of engineering models that processing
represent a seamless chain along the – Initiate the development of a survey concern-
system life cycle and define and standardize ing the relations between ML and semantic
bridges between these engineering-related interoperability to identify standardization is-
information models sues
–
Standardize failure modes of theoretical
§§ Organize a multi-SDO study group to consider
well-defined phenomena, e.g. mechanics,
latest trends and technologies
electrics, pneumatics, etc.
–
Design and standardize semantic bridges
6.2 Recommendations to industry
crossing grid domains and domains
and consortia
interacting with electric grids
–
Design and standardize semantic bridges At present, unconnected industrial and consortium
between electric grid information and activities are being implemented related to
function models to enable risk assessments semantic interoperability. This situation creates
along an event chain challenges for optimizing standardization but
–
Design and standardize system-agnostic also opportunities for creating a more positive
deep information models about well-defined standardization ecosystem that will support the
measurement and actuation phenomena needs of governments, the private sector and users.
and technologies This ecosystem should be the focus of collabo-
ration across the spectrum of industry and consortia
§§ Information models – integrate function/be-
as outlined in the following recommendations.
haviour/dynamics
§§ Identify simple use cases involving the intro-
– Include behaviour models in the information
duction of semantic interoperability technolo-
models in the form of one consistent model
gies that provide added value to the use case
for theoretically well-defined phenomena
owner. For example, two applications that
– Integrate algorithms for capabilities, skills,
share content represented in only a few inte-
task scheduling, goals, action, requirements
grated IEC (or other) Standards can be shown
and other elements more extensively into the
to be interoperable by mapping through the in-
information models
tegrated IEC (or other) information models and
– Provide semantic bridges between functional
ontologies. This is an O(n) mapping
and information models

61
Recommendations

§§ Support standardization of ontology specifi- claiming automatable processing. This requires a

cations: common activities spare efforts in the high and proven qualification of the results (models,
long-term because the tasks involved must be contents, interfaces).
performed with or without standards
6.3.3 Automated use of semantic
§§ Convert existing IEC Standards into ontologies
interoperable information models
using best practices described above
requires reliable availability in the
§§ Integrate standard ontologies into domain provision of the models and an
models using best practices automated business relationship
§§ Initiate and provide training for engineers to for the use of the standards
develop semantic interoperability skills This necessarily involves automated access to
§§ Offer projects about semantic information the data and procedures for legal use (automated
modelling to academics contract).

6.3 Recommendations concerning 6.3.4 Products, systems and services are

regulation needs marketed and used internationally

6.3.1 Considerations in addition to In addition to the internationality of the standards,

technical requirements internationally effective regulation is also necessary,
allowing a secure basis for the future use of
For a progressively automated future using semantic
standards by users and manufacturers. The main
models and their contents, economic, legal and
legal questions to be answered in this context are:
regulatory conditions should be considered in
addition to the technical requirements. §§ What constitutes liability in the event
of misinterpretation due to errors in the
Automated use requires a standardized data
information model?
structure of semantic interoperable information
models and exchange procedures (interaction §§ What constitutes liability with regard to the
models, interfaces between engineering software results of systems (e.g. tools) in which different
and automation systems). automatic semantic models are used?

This requires standardization of the implementa- Answering these questions inevitably involves the
tion, provision (e.g. via open source implementa- development of new requirements for the creation
tions) of the models to be used, and automatable of standards and for the testing, validation and ver-
use throughout the life cycle. ification of standards and tools. This effort must
also be accompanied by the elaboration of pro-
6.3.2 Automated use of semantic cesses (e.g. V-model with requirement, validation,
interoperable information models verification). Interfaces (data and communication
requires reliability of the models, structure) must also be considered for automation.
contents and interfaces

Standardized semantic interoperable information

models and related interfaces become parts of
value chains, engineering systems and products

62
Annex A
Detailed use case descriptions

A.1 “Find and update something” commissioning and operation, described at 3. The
use cases engineering process starts by defining a chemical
reaction which combines (in our example) two pre-
A.1.1 Use case description of a part
products 1 and 2 and results in resulting-product
of a chemical plant engineering
3 (see 1). This chemical process is performed by a
One example of system engineering is chemical plant (see 2), which details a reactor, represented
processing (see Figure 3-5, repeated here below as by a so-called P&ID as defined in IEC 62424. The
Figure A-1), in which an abstract chemical reaction P&ID describes all technical resources of a plant
is describe at 1, and in which the engineering (i.e. pipes, valves, vessels, pumps, heat exchanger
team must coordinate the plant design, perhaps and numerous other components), as well as the
captured in a diagram (such as at 2), the control requirements for the automation system in terms
system and ultimately the plant construction, of measurement and actuation points. These

Pre-product 1
1 Resulting product 3

Chemical
reaction

Pre-product 2

Engineering
Equipment/technical Information processing resources -
2 resource 4 automation system

3
TI
B102
Industrial Ethernet communication

Drive device
Ident systems

Coupler

DP/PA
Link Sensor/actor bus

6
Field device
5 Field device

Fieldbus
Field device

Figure A-1 | Engineering of a chemical process

63
Detailed use case descriptions

measurement and actuation points have to be semantic models in the future. Today, however,
implemented by suitable automation devices (see many steps are performed manually, because the
5), which become part (see 6) of a control system common knowledge (see 7) necessary to come
(see 3). The chemical process (i.e. the products to the right decisions is not available in machine-
and the reaction) constitute the building blocks interpretable information models. The following
for the design of the plant and the control system. describes the engineering issues more in detail.
The engineering staff (see 4) currently designs,
To initiate the chemical reaction, the reactor
operates, and maintains the plant and the control
must contain the reactants (pre-product, see
system.
8) and reach a specific temperature (property
The reactor is part of the overall plant structure. of the reaction, see 8). The temperature has to
Let us take a reactor temperature measurement be measured with a temperature measurement
as a sub-example, because the measurement is device consisting of a sensor and a transmitter,
required for proper reactor function. It is desirable which is normally mounted to the reactor vessel
that consistency checks, or even generation (measurement point in the P&ID (IEC 62424) see
of possible solutions fulfilling all constraints of 9). For this connection, mechanical and geometric
chemical reaction (see 1 in Figure A-2), mechanical models are necessary to define the right mounting
(see 2), DCS (see 3), electrical (see 4), control logic location and the mounting style (e.g. bolt the sensor
(see 5), and supervision (see 6), be possible using to the vessel flange – not visualized in Figure A-2).

Common knowledge
7

Mapped or merged
information
models

1 2 3 4 5 6
Information Information Information Information Information Information
model A model B model C model D model E model F

Digitation of technical Digitation of super-

Digitation of Digitation of Digitation of Digitation of
resources and visory graphical
chemical reaction plant structure DCS wiring in DCS control logic
user interface

8 9 10 11 12 13
Pre-product 1

Chemical
reaction T Ethernet/PROFINET

I
Resulting T
B
1
PROFIdrive
Identsystems

product 3 I PN/P A
0
Pre-product 2
PROFIBUS

B 2
1 T
DP/PA
link
0
PROFIBUS

I
3 C PROFIBUS PA
B PROFIBUS PA

1
0
4 PROFIBUS PA

Access and understand

data using information
model
Manual work design and
implement the mapping
Physical signals

Figure A-2 | Multiple domain semantic interoperability is necessary for engineering – Use case:
Semantic interoperability for failure detection and diagnosis

64
Detailed use case descriptions

Additionally, the sensor needs a housing designed in Figure A-2). The design engineer has to check
to withstand the temperature range the reactor will and compare properties such as cable and input
experience (also not visualized in Figure A-2). The module matching resistance ranges and dumping
design engineer has to check and compare many of the cable related to the distance. The result is
properties, such as metal-liquid compatibility, the E-CAD plan and the electrical portions of the
sensor housing and flange mount screw diameter/ communication network. These tasks of the use
pitch, and reactor/sensor temperature ranges. case are based on both the “find and update
For this example, we assume that the transmitter something” scenario b of Figure 1-1 (extract data
is mounted within the sensor housing. The result from the design documents, e.g. type of electrical
is the structure of the plant consisting of all and mechanical interface of the sensor) and the
resources and their relations. The data value of the “operate on something” scenario c of Figure 1-1
temperature property is bound to the model of the (calculate resulting design decisions, such as the
chemical reaction. This is described by the chemical right cable and cable length).
reaction information model. This temperature
The control system consists of many measurement
value has to be in the range of temperature which
and actuation devices, remote IOs, the controller,
is measurable by the transmitter. This range is
bridging devices, network switches (for Ethernet-
described by the transmitter information model.
based communication), edge gateways, and many
The human, or hopefully in future the engineering
more components. Together they comprise the
tool, has to compare the necessary temperature
automation and supervision system (also known as
value of the reaction and the range values of the
distributed control system (DCS)) whose structure
transmitter. This task of the use case is based
has to be designed and configured according to
on the “find something” scenario b of Figure 1-1.
plant requirements (example structure at 10 in
Finding the right sensor bolt and other mechanical
Figure A-2). The design engineer has to check and
and functional properties performs the same
compare device properties against environmental
scenario pattern. Just to highlight this here: all data
condition ranges such as dust, humidity, and
in the system engineering use cases is currently
temperature. All necessary controller input and
located in design documents. This means that
output modules need to be defined. These are fed
the information models are models from technical
back to the electrical system because the devices
descriptions. Real-world devices or components
need a power supply with cabling and sufficient
are not present in these design steps.
power. The result is the structure of the DCS, i.e. the
With an appropriate temperature measurement devices, their connections to the communication
selected, the measurement cannot be used network, all resources, and their relations. As
unless it is provided power and a way to send before, these tasks of the use case are based on
the temperature data from the transmitter to both the “find and updating something” scenario
the controller. An electrical connection from the b of Figure 1-1 (extract data from the design
transmitter to the fieldbus or directly to an input documents, such as allowed ranges of humidity
module of a remote IO or controller is needed. and dust) and the “operate in something” scenario c
This requires electrical models to select the right of Figure 1-1 (calculate resulting design decisions,
cable type, the allowed cable length and electric such as calculation of fieldbus or IP addresses and
characteristics for the input module (wiring plan, many other decisions).
see 11). To lay cables requires mechanical know-
If the temperature sensor is electrically connected
how and models that define cable characteristics
to the controller, a control programme has to be
such as minimum bending radius (not visualised
written that can process the temperature value

65
Detailed use case descriptions

(see 12 in Figure A-2). In the most popular controller the data generated by the plant and generate
languages satisfying IEC 61131-3 on programming new control and supervision logic knowledge to
language for programmable logic controllers optimize the control of the plant. For example,
(PLCs), the variable symbolic name has to be more fine-tuned temperature thresholds could be
connected to one port of an input module of the set based on historical data, or the supervisory
PLC. The programming engineer allocates the port station could learn to correlate alarms in order to
ID to the symbolic name, e.g. Temperature Reactor identify the root fault to be resolved. This would
1 to PLC input module 1 port 3. The result is the require the engineer to provide analysis logic to
PLC programme. These tasks of the use case are the system, and the system could further generate
mostly based on the “updating something” scenario new control logic to replace the previous one.
b of Figure 1-1 (such as compare properties of These tasks of the use case are based on the “find
both models, electric input and symbolic names of and update something” scenario b of Figure 1-1
control software programme). (extract analysis logic from control optimization
documents) and the “operate on something”
The supervisory station is configured using
scenario c of Figure 1-1 (update logic of the control
graphical symbols (e.g. a reactor with a sensor at 13
system or supervisory station).
in Figure A-2) and is connected to the variables out
of the PLC. The PLC, according to IEC 61131-3, has Engineering has to design the plant mechanical
a specific information model which is used by the and geometric structure, the DCS with its devices,
supervisory station to access variables. This needs components and wirings, and the software within
to be known by the programming engineer so that the PLC and supervisory stations based on the
he can address the PLC variables. Additionally, for intended chemical reaction (see requirements in
monitoring alarms in the supervisory station it is Subsection 3.5.2). In this context, many different
necessary to know upper and lower temperature kinds of knowledge work closely together because
thresholds required for the chemical reaction. the sensor selected must fit all of the mechanical,
Reaction know-how is necessary to define the electrical, geometrical, control and environmental
related threshold variables in the supervisory conditions at the place of work.
station. The engineer has to understand the
Devices and components can fail. This causes
chemical reaction description to find the right
downtime of machines or plants and additional
information for the evaluation of the process
efforts for repair and restart of the plant. It is
variables (here the temperature of the reactor) in the
desirable that potential failure and errors be
supervisory station. The result is the configuration
detected before they occur. This is possible if there
of the supervisory station. This tasks of the use
is a simulation or analysis of the running device or
case are based on both the “find and updating
component based on online data and a functional/
something” scenario b of Figure 1-1 (extract data
behavioural model of the device or component.
from the chemical reaction design documents) and
There exists a larger set of components that are
the “operate on something” scenario c of Figure 1-1
frequently used in industry, such as pumps, heat
to assign control programme variables with the
exchangers, welding or gluing tools, conveyor
threshold values of the reaction.
belts, turntables, etc. Each component has a basic
Normally, the information needed by the superv- behaviour model with a fixed set of input variables
isory station as well as the logic of the control coming from the related sensors.
system are provided through human-generated
For example, a pump has a defined behaviour
materials. Besides relying on this pre-acquired
which can be supervised by monitoring the pump
knowledge, one might expect the existence of an
input and output pressure, flow and temperature
analysis system or function which could analyze

66
Detailed use case descriptions

(these are the process variables of the pump which something” scenario illustrated in b of Figure 1-1.
have to be used during the calculation of the pump On top of the data lake is positioned the analysis
analysis). The task is to implement the analysis algorithm. The process variables have to be
algorithms in an analyzing station and connect understood as the variables in the algorithm. This
the variable of the algorithm with the sensor data. means a match needs to be performed between
Today this is mostly performed manually, because the process variable and the formal algorithm
the access path to the variable is hidden in the API. variable. In other words, the behaviour model has
If the information model of the pump were semantic- to be linked to the models of the devices and the
interoperable, an automatic connection would be pump. This is the “operate on something” scenario
possible. For the configuration of the algorithm it illustrated in d of Figure 1-1. The values cross
is necessary to know which sensor belongs to the multiple domain borders with different information
individual pump. The sensors form part of the overall models. The relations between the information
automation system and are located and connected models have to be defined, so that at the end a
somewhere in the control system. The values valid match exists between the process variable
have to cross different devices and subsystems and the algorithm variable.
until they are available to the analytic algorithm.
At the beginning, a sensor measures the desired A.2 Derive information models and
value and provides it to a measurement device data from human-designed
(e.g. a transmitter), which converts the real world information sources
signal into a data stream (composed of analogue
Human knowledge is represented in different
values in a time row of sampled digital values).
formats, such as technical descriptions, natural
This device possesses its own information model
language or graphics. This knowledge needs to
describing the process variable, e.g. with a name,
be provided in the form of information models
time stamp and associated unit. The measurement
for integration in the semantic interoperability
device is connected to a gateway or an edge
scenarios. This subsection provides various
device. This often also has its own information
examples of this transformation.
model with another process variable description
for the device, variable in the device, name and
A.2.1 Use case: Human and machine
unit. The unit can always be coded according to
understanding of human-designed
UNECE or ISO 80000 or IEC CDD. The data is
descriptions
then forwarded to a data lake that in turn has its
own information model. It would be of great help A massive number of technical documents22
if the different information models used the same exist containing important information which is
model for the process variable. This is the “find needed in the development process of machine
something” scenario illustrated in a of Figure 1-1. parts, machines, plants, and factories, as well
Understanding the process variable is not enough. as in products. The content contained in these
It needs to be associated with the structure of the technical document descriptions is necessary for
plant, i.e. the variables have to be connected to the design, development or even implementation
the right input and output of the pump, and thus of operational steps that also work with software
integrated in the information model of the pump. tools. The state of the art involves technical
A mapping between the sensor models and the document descriptions being edited using software
pump model is also necessary. This is the “update tools. The content of such documents is mostly
informal or even unstructured, i.e. the information

22 Note that these also constitute assets with data to be used in different applications.

67
Detailed use case descriptions

is recorded in text, lists, equations and formulae, §§ A data source exists, which is a technical
tables, figures, graphs, and mixtures of all of these description (see 1 in Figure A-3), that provides
forms. The software tools or machines which human-centered knowledge, and a user such
need this information cannot understand them. as a human or machine (see 2) needs to access
Humans have to understand these descriptions the data and information
and maintain them in appropriate tool databases.
§§ The main goal is to enable process step tools
In industrial automation, it is necessary to
or machines to be interpreted without human
acquire both the model information behind these
interference
documents, and the associated data content in the
form of semantic models. This is even the case for §§ This use case is based on the “understand
many international standards that describe facts something” scenario introduced in a of Figure
informally. Users have to find, extract, and maintain 1-1
the information found in such standard documents An example of this use case is provided by
to meet their needs. Some standards, such as IEC 60381-1, which defines among other things
IEC CDD, provide an additional machine-readable the 4-20 mA signal. This includes minimum current
version of their specification, such as IEC 62424 value (4 mA), maximum current value (20 mA), error
on P&ID, or IEC 62714 on AutomationML. This is a current value (3,5 mA), burden (of the consumer),
good starting point. wire length (e.g. up to 1 000 m) and a description
This use case can be summarized as follows and of other elements. It must be made clear that all
as shown in Figure A-3. this data belongs to the signal, that the burden

2 2

Process

Information Knowledge
model

Digitalization of
Information world technical document

Real world
Access and understand
data using information
model
Manual work design and
implement the mapping
-
Technical
Physical signals or descriptions
human-like messages and
1
information -

Figure A-3 | Machine-interpretable digital information as result of purely human work

68
Detailed use case descriptions

involved is a resistor belonging to the user, and so as “shall”, “should”, “should not”, “may”, “need
on. The standard document describes all of this not”, “will”, “will not”, “can” and “cannot”. These
in informal text. An engineering tool is needed to terms give clear hints concerning the obligations
handle all this data, because the sensor providing related to the specification details, but the details
the standard signal and the input modules of a themselves are often hidden in informal text or
PLC consuming the signal have to fit together. This tables and in other text layout formats. Machine-
must be provided by the engineering tool without interpretable versions are often missing altogether.
human interference. The tool developers currently Automatic model and data acquisition will continue
have to integrate the related information model into to be targeted and will probably continue to be
their tool manually. elusive for some time to come, but it can be partially
addressed through a combination of automation
A.2.1.1 Requirements and human-in-the-loop acquisition.

Technical descriptions have to be exported to a Knowledge modelling: There are many hu-
machine-interpretable information model. There man-created, machine-interpretable descriptions
is a need for reliable means of extracting the that range in clarity and standardization, and these
information from arbitrarily complex descriptions introduce quality gaps in information modelling.
into information model-compliant repositories. What constitutes a good model that would/could
lend itself to semantic interoperability? Some ex-
A.2.1.2 Gaps amples demonstrate the range of these gaps. The
Semantic Sensor Network Ontology 23 is a general
Two types of gaps are associated with human-
model for sensors and actuators. It has been stan-
centric information sources: 1) gaps in knowledge
dardized by the W3C and is structured using good
acquisition and 2) gaps in knowledge modelling.
best practices in ontology design. Another, the
The former concerns automating the acquisition of
QUDT ontology for quantities, units, dimensions
models and data from humans or human-generated
and datatypes24 is compliant with several interna-
documents. The latter concerns humans creating
tional standards (but is not itself standardized) and
models.
is also implemented with best practices. Another
Automatic model/data acquisition: Automatic “ontology”, schema.org, is a collection of structures
knowledge extraction has long been the holy grail that are neither standardized nor standards-com-
of artificial intelligence. The industry is getting pliant. And finally, in the automation domain (mainly
better at extracting information from unstructured in IEC TC 65), a number of standards, such as OPC
documents, formulae, graphs and tables but is UA, eCl@ss, AML, and EDDL are used frequently
nowhere near 100% reliable with regard to these in automation and have some structure. The sheer
document types, and other document forms, range of quality of information models makes it
such as wiring diagrams, flow charts, histograms, clear that before semantic interoperability can be
photographs, etc., have yet to be tackled at all. In achieved, these modelling best practices must be
the best-case scenario, a machine-interpretable normalized. Even when there exist transformations
description of properties, facts and behaviours is to OWL, these are not frequently used in system
incomplete or missing, because the domain experts engineering praxis.
provide technical descriptions in an informal
Ontologies such as SAREF or the Smart Device
format. For example, in standards rules may define
Template of the oneM2M standard offer a general
the applicability of a statement using terms such

23 www.w3.org/TR/vocab-ssn
24 qudt.org

69
Detailed use case descriptions

set of device-related concepts and their relations. market coupling and grid operation, and grid
These ontologies have origins in the building investment and maintenance. Specifically, in the
automation domain. Complex devices such as first row of Figure A-4, a TSO dispatches the
variable-speed drives with frequency controllers, loads according to clearing results from the bulk
Remote IOs with a huge number of variants, module electricity market at the grid level, while operating
configurations, or machines with a component the grid through commands at the asset system
and device hierarchy, and electric, kinematic and level. In the second row, a TSO plans its grid
behavioural descriptions, are not modelled to any physically and financially according to historical
current standard, so all implementations are ad dispatches, manages the capacity and availability
hoc models. of its asset systems and executes maintenance
plans on its assets. These processes can generate
A.2.2 Use cases in electric grids data and information that is readable to machines
at different degrees. Generally speaking, according
A.2.2.1 Background of use case UC-PM-06b
to the experience of the authors of this white paper:
Semantics to facilitate preventive
maintenance in electric grids §§ A deregulated electricity bulk market nowadays
runs fully digitally, and the grid couples with
An electric grid is physically composed of parts
the market in a highly automatic manner, within
(e.g. conductor, insulator), assets (e.g. cable,
the framework of which the information model
transformer), asset systems (e.g. connection,
is frequently specified by regional/national
substation) and asset portfolio (e.g. a high voltage
authorities
grid).
§§ The operation on the grid is half automated,
A transmission system operator (TSO) concentrates
i.e. is being transformed from a human control
essentially on two clusters of processes, namely

Market coupling and grid operation

Bulk electricity Operation on grids

Grid dispatch
market and asset systems

Grid investment and maintenance

Management of Life cycle activities

Grid planning and asset systems on assets
investment (e.g. renewal plan, (e.g. maintenance
repair intervals) in field)

using using using using using

Information Information
Information
model of the model of
model of assets
grid asset systems

Compatible with CIM, Specific to asset type

Compatible with
but further specified by e.g. IEC 62271-3 for
IEC 61850
grid operations switchgear

Figure A-4 | Essential processes and information models of a transmission system

in a deregulated electricity market

70
Detailed use case descriptions

approach to a human-supervised automatic A.2.2.2 Use case: Initiating a process with

failure detection/dispatch. Such transformation natural language in distribution grids
appears first in high voltage grids, and only
In this use case, natural language processing is
then in medium and low voltage grids, due to
used to assist a medium- and low-voltage grid
cost constraints. In Europe, the grid models
operator (i.e. distribution grid operator) to classify
developed by individual grid operators should
the requests from a client and, if applicable, match
comply with the CGMES from ENTSO-e based
them with an asset within the grid. The semantic
on CIM (IEC 61970 and IEC 61968). At the level
component of this task is an understanding and
of asset systems, IEC 61850 is widely followed
finding capability as represented in scenario a of
§§ The grid investment (incl. replacement, Figure 1-1.
expansion, etc.) and maintenance are highly
manual, with limited, mutually isolated data Description
sources which are currently manually coupled
This use case concerns an automatic service
within the scope of the asset management
hotline system of an electricity grid. In the system,
system. Partly reflecting this situation, standard
requests from clients regarding power outages,
information models for assets are available
repairs, inquiries, complaints, feedback, profile
for only a few types, such as IEC 62271-3 for
changes, information releases, etc., are collected
switchgears
through phone calls. The calls are answered by
–S
pecifically, the use case UC-PM-06b voices generated by AI-empowered machines,
belongs to “the management of asset during which the intention of the client is identified,
systems”, in which “maintenance plan” is a and the most relevant internal process is initiated
typical “life cycle activity”, as illustrated in accordingly. As Figure A-5 shows, two systems
Figure A-4 generate the dialogue and interact directly with the
client:

AI integrated hotline system

Which (A module of)

Navigation system Front-end system
scenario?

e.g. register failure

Client of an asset

General Scenario-specific
dialogue dialogue
Information
management management
model of assets

Conversion between
voices and semantics

Figure A-5 | A simplified interaction between the hotline system and a client who reports
a failure

71
Detailed use case descriptions

§§ The navigation subsystem receives phone §§ conversion between voices and seman-
calls at the starting point, grasps the client tics: as a fundamental function of all voice-
request category (called a “scenario”, which based applications, allowing the machine
can concern a technical problem, client profile to listen to and speak human language in a
management, legal issues, etc.) from the phone call
dialogue and redirects the call to a scenario-
§§ dialogue management: in order to continue
specific module of the front-end system
the dialogue with a client until sufficient
§§ The front-end subsystem is composed of information is collected to determine the
specific modules. Each module is designed for scenario (in the navigation system) or concretize
a specific scenario and corresponds to one or the internal process (in the front-end system)
a few internal processes which aim to respond
§§ vocabulary management: must extract
to these requests
new ontologies and semantics from existing
Interoperability occurs when a front-end module dialogue data
gets a request which can automatically initiate an
Moreover, within dialogue and vocabulary
internal process, such as registering the failure of
management, words, phrases and sentences from
an asset and generating a work order accordingly
natural language need to be mapped with internal
(illustrated at the right side of Figure A-5). The
processes as well as internal identities (e.g. an
front-end module should map the oral inputs from
asset in Figure A-5), so that internal processes
clients to the parameters necessary to launch an
can be initiated automatically by client requests.
internal process. For example, the client should
In this sense, semantic finding capabilities are a
be asked to specify his/her electricity meter, if
prerequisite.
the maintenance staff needs to visit the client’s
house. From a data prospective, an asset (e.g. an
Gaps
electricity meter) needs to be identified based on
an unstructured description from a client. Semantics from natural language are generated
through analyses of AI. The rapid evolution of
As a backup, the phone call will be redirected to
AI models has delayed the appearance of an
human personnel when either navigation system
information model accepted by most applications.
fails to determine the scenario, or a front-end
The only IEC Standard on this topic, namely
module fails to concretize the request. Moreover,
one issued by ISO/IEC JTC 1/SC 42 provides a
it is worth noting that not all internal processes
general framework for the JTC 1, IEC, and ISO
can be initiated automatically. For example, if the
committees to develop AI applications rather than
scenario involves legal issues, client requests are
a standard interface for its users. Moreover, natural
handled manually.
language processing techniques aim to handle
the human language with fuzzy meaning, which
Requirements
prevents semantics from human language from
A back-end subsystem is empowered by natural being standardized. Without a widely accepted
language processing technology (as a subset information model or semantics from non-expert
of AI) and supports the navigation and the front- language, the interoperability in this use case could
end subsystems with regard to the three aspects hardly be achieved in an unmanned manner in the
below, in order to make the human and the machine short term.
understand each other in a phone call:

72
Detailed use case descriptions

A.2.3 Use case: Graphical data conversion Already a mechanical three-pole switching
into information models device (Figure A-6), which consists of multiple
electronic elements such as a motor (S00830),
For the digital engineering of control cabinets within
a switch (S00254) and other components) poses
CAx engineering tools, much complementary
a real challenge for an unambiguous machine-
data is needed and necessary. This includes
readable taxonomy with the aim of describing the
technical data such as CPU performance, power
connections and dependencies between the single
loss diagnosis data, but also properties such as
functional elements.
torque for the configuration of a drive train or the
temperature in a chemical reactor. The next level of refinement would be an even
more complex interconnection of the above-
This data can be provided in machine-readable
mentioned electronic devices, resulting in a circuit
ways and comes in standard configurations and
diagram. The description of these interconnections
formats, e.g. IEC CDD or eCl@ss Advanced or
via an unambiguous (mathematical) model would
tool-specific. But other data exists with graphical
constitute a special challenge.
origins, such as 2D- and/or 3D-diagrams (e.g. *.dxf,
*.step, *.jt), circuit diagrams, motor characteristic Figure A-7 and Figure A-8 are examples of such
curves, etc. a circuit diagram, consisting of typical complex
interconnections between electronic devices.
Consider the example of circuit diagrams.
These consist of single electronic elements or The following requirement can be derived:
components, such as capacitors, switches,
§§ A method is necessary for transforming
resistors, inductors, semiconductors, etc. that
graphical descriptions into machine-
are electronically connected. These connections
understandable information models (e.g.
are designed with typical CAx tools such as
hierarchical interaction)
Automation Designer 25 and EPLAN26. Humans
are always involved, either to generate or to read
A.2.4 Use case: Composite devices
and interpret the graphical data, and to combine
this data with the other technical and machine- The mechanical construction of a part of a
readable data formats using their knowledge of machine such as a traction system or pump is
electrical engineering. accompanied by the construction of information
models containing all details of all components of
In this context the question arises as to whether it
the system. An overview of information necessary
is necessary to convert this graphical knowledge
for these components is offered in Figure A-9.
into a machine-readable format, so that it can be
The dimensioning of these components needs
interpreted and used in a semantically interoperable
semantic interoperability between all the involved
application.
information models. This represents semantic
IEC 60617 represents an attempt to do so. For interoperability in the sense of scenario b “update
every single electronic element there is a graphical something” of Figure 1-1. Bringing together the
representation of an electronic component, information models of several parts of a system is
and each has a unique identifier attached. The also known as “onboarding”.
electronic components are described with names
and are assigned to an application class. Table A.1
provides some examples.

25 Automation Designer is a commercial tool of Siemens AG.

26 EPLAN is a commercial tool of EPLAN Software & Service GmbH & Co. KG.

73
Detailed use case descriptions

Table A.1 | Identifier-based representation of graphical construction elements (example taken

from IEC 60617)

Symbol Identity Number Name Application Class

Circuit diagrams, Connection

S00567 Capacitor, general symbol
diagrams, Function diagrams

Circuit diagrams, Connection

S00583 Coil, general symbol
diagrams, Function diagrams
Switch, manually operated,
Circuit diagrams, Connection
S00254 push-button, automatic
diagrams, Function diagrams
return

Change-over contact Circuit diagrams, Connection

S00231
with off-position diagrams, Function diagrams

Circuit diagrams, Connection

S00362 Fuse, general symbol
diagrams, Function diagrams

S00830 Series motor, three-phase Circuit diagrams

Circuit diagrams, Connection

S00555 Resistor, general symbol
diagrams, Function diagrams
NPN transistor with
S00664 collector connected to the Circuit diagrams
envelope

Figure A-6 | Graphical representation of a mechanical switching device, three-pole,

S00295 according to IEC 60617

74
Detailed use case descriptions

Figure A-7 | Example 1 of a more complex circuit diagram

Figure A-8 | Example 2 of a more complex circuit diagram

75
Detailed use case descriptions

Firmware

0˚..

Information element
Information unit
0˚..
IDL BA::Property Manual
(leaf) CAx information
0˚..

Data sheet
Certificate
0˚..

0˚.. 0˚.. 0˚.. 0˚.. 0˚..

Characteristic Simulation CAD Graphic Relationship

curve information knowledge

Behaviour Function Symbol Vector graphic

Figure A-9 | Information categories for CAx

A traction system, for example, consists of a motor, Limiting factors in the combination/configuration of
gear, power electronics and a wheel, while a pump the components to the system can include physical
consists of a motor, a valve with wheel, power constraints, e.g. that the housing, plugs and
electronics and flanges. The requirements of these connectors prohibit certain combinations or might
systems determine the detailed properties and be given additionally at the software/firmware level.
functions of the components, which are offered
Consider another example of a modular
in different sizes, power ranges and connection
connector (known as remote IO) which combines
types. These properties and functions have
signal-converting modules in a rack via digital
relations among one another and rules that govern
communication connection. The total number
their interaction. To ensure a correct dimensioning
of possible combinations rapidly rises into the
of the system, the customer needs considerable
thousands.
data about each individual component and the
rules applied between them. These data and rules The product manufacturer possesses a description
are usually hidden in the manufacturer-specific of all modules, variants of the rack and the
tools offered with the systems. combination rules. For the manufacturer it is simply

76
Detailed use case descriptions

not possible to describe and maintain every single

combination of all modules with all variants in one
monolithic information model. In this concrete case,
the approach adopted is to describe each single
module with a property standard according to
IEC 61360 (e.g. IEC CDD or eCl@ss Advanced).
These types of standards have only limited
possibilities to describe relations or rules among the
components and their properties. For this purpose,
an additional description means is necessary.
This could be the Automation Markup Language
(AutomationML). AutomationML offers the
opportunity to describe relations between system
elements, for instance in our example modules
such as the allowed/not allowed neighbourhood.
AutomationML contains an unspecific property
information model. Thus the integration of both
models, the AutomationML information model
and the property information model according to
IEC 61360 increases the expressiveness. Then the
engineering tool for the system construction can
verify the user-selected combination against the
relations in the information model and determine
the property data. The combination of both
standards, eCl@ss and AutomationML, makes
is possible for every customer to easily find and
configure the composite devices needed to satisfy
the customer’s need for a certain functionality.

A.3 Requirements
§§ Combinations of information models with
different strengths and weaknesses in order to
construct more expressive models are needed

§§ Cooperation and collaboration among the

models are also required

77
Annex B
Levels of formalization – XML schema and OWL

B.1 Structured representation values represent viable temperatures and to

language – a choice based perform the necessary logic on temperatures
on need within our programmes. This constitutes the
most basic level of need and forms the backbone
Data exchange between systems has existed for
of data exchange. The same model has been
decades and has slowly been changing to suit
used in cases where systems interact, but with
our computational needs and capabilities. In the
significant negative consequences. As mentioned,
early days of computing, programmes were written
data exchange involves concomitant parsing
and provided with ASCII text files for data. ASCII,
and validation, and logic development generates
being unstructured, required the parsing of both
maintenance requirements, and as the number of
structure and content. That is, everything was on
interacting systems increases, the need for them
the shoulders of the software developer.
to be more autonomous, more adaptable, and
Later came comma-separated and tab-delimited more robust also grows. This renders the classic
text, which allowed us to assume a certain degree model inadequate, in which developers provide the
of structure, but it was still necessary to parse the parsing, validation, logic development and code
content into structures before processing it. Thirty- maintenance capabilities directly, because they
five years ago XML was introduced. A language in simply cannot keep up with the scaling.
its own right, XML provided much more structure
to data and, importantly, provided parsing and B.2 The choices
validation mechanisms, so that data could be
Three languages are currently in widespread use
validated and parsed because it complied with
that play different roles in interoperability: JSON,
the XML language. This was followed by the XML
XML, and RDF. JSON is the language that makes
schema, which provided a layer of reusability
the fewest commitments to structure, in that it
on top of XML, so that XML templates could be
contains only a handful of definitions, mainly for the
created and shared. Twenty-five years ago the
purpose of representing arrays, dictionaries, keys
OWL language was created. The development of
and values, and has a very limited syntax, grammar,
a language that improves on the strengths and
and language semantics. Because it makes very
removes some of the limitations of OWL is long
few structural commitments, it is a highly flexible
overdue, but this synopsis is about XML schema
language and is excellent for serializing structured
and OWL.
data. A recent set of extensions to JSON, JSON-LD,
Ultimately, the use of a data exchange language has provided more structure to the language, but
is all about need, where need can be defined its strength is still considered its simplicity/flexibility.
according to several metrics. One metric involves
XML is the serialization of XML schema which, as
conveying or exchanging information. For example,
previously noted, provides a much deeper set of
if temperature values need to be integrated into
commitments to structure and thus has a much
a programme, it suffices to check whether the

79
Levels of formalization – XML schema and OWL

richer syntax, grammar and language semantics. B.4.1 The strengths of the XML schema
It is also able to represent content associations.
§§ Supports import
RDF is a serialization of OWL, which is very closely §§ Supports namespaces
related to object-oriented programming (OOP) and
§§ Supports simple and complex types for
makes the richest syntax, grammar, and language
reusability
semantics to date.
§§ Supports restrictions such as cardinality and
Because all of these languages provide value
serializations, they are all useful for data exchange to
differing degrees. But they all come with overhead B.4.2 The weaknesses of XML schema
with respect to understanding the information they
§§ Does not support inheritance
are conveying.
§§ Does not support classes
B.3 The big difference §§ Does not support taxonomies

Ultimately, the most significant difference between §§ Does not support class/instance relationships
languages such as JSON and XML on the one §§ Does not support embedded logic
hand and RDF on the other, is that the former are §§ Makes no commitment to the meaning of
intended to characterize syntactic structure, while content
the latter is intended to characterize semantic §§ Contains no embedded procedural model for
structure (or meaning). rules
In a world in which countless numbers of systems §§ Contains no basic array or hash table model
are communicating with one another and §§ Contains no notion of shape for bounding
exchanging data, it has become essential that interoperability
the focus move away from mere data exchange
and toward data understanding. In this context B.4.3 The strengths of OWL
a language must convey meaning in addition to
syntax, grammar and language-level semantics, §§ Supports inheritance
and OWL is the only one of these three languages §§ Supports classes and taxonomies
that can meet this requirement.
§§ Supports class/instance relationships
For a further discussion of the differences involved,
§§ Supports embedded logic
see the following articles:
§§ Makes specific commitments to the meaning
www.w3.org/DesignIssues/RDF-XML 27
of content
www.cambridgesemantics.com/blog/
semantic-university/learn-rdf/rdf-vs-xml B.4.4 The weaknesses of OWL

§§ Contains no embedded procedural model for

B.4 The small differences
rules
As mentioned, the XML schema provides the §§ Contains no basic array and hash table model
ability to represent the structure of information
§§ Contains no notion of shape for bounding
and furnishes mechanisms (parsers) to ensure that
interoperability
data conveyed between systems complies with
that structure.

27 This article, written by Tim Berners Lee, provides an excellent explanation.

80
Levels of formalization – XML schema and OWL

B.5 Summary
Significant differences exist between the XML
schema and OWL that make OWL implementations
look and act more like object-oriented objects.

The biggest difference between the languages

is the focus on structure (XML) as opposed to
meaning (OWL). An XML schema may dictate a
sequence of types or items, or a selection amongst
types or items, but it does not ensure that the
content in the XML (which is compliant with the
XML schema definition) satisfies the spirit of the
XML schema definition (i.e. the reason for modelling
something in the first place). The reason for this
is that XML schema is a structural model rather
than an information model. If a field is defined in
XML schema as constituting a string, or any other
type of object, then as long as the structure is filled
according to the defined type, it does not matter
what the content represents. It is up to the agent
who receives the XML to validate the content, and
as a result, someone has to write code and the
interoperability problem persists.

81
Annex C
General concepts to enable semantic interoperability –
a case for system-agnostic information models

C.1 Basic model There are three ways to implement the semantic
interoperability scenario:
Semantic interoperability involves how the meaning
of something is conveyed between systems and §§ A single, universal model that is adopted by
does not relate solely to data exchange. A general everyone
view of the semantic interoperability problem §§ A direct integration of many models
between systems is shown in Figure C-1.
§§ An indirect integration of many models
The problem arises in many engineering scenarios
or use cases. Four are shown below: C.2 Single and universal
§§ Share data or logic between systems (this is information model
the data interoperability use case) The overall best solution is one in which the entire
§§ Integrate data used in different ways on world would agree to use a single (universal)
different systems information model, which is so expressive that it
represents everything, and everyone approves it,
§§ Perform the same task (e.g. verify and validate)
as shown in Figure C-3.
on different systems
In this approach no translation is ever required,
§§ Perform different tasks on different systems
because everyone already uses the single model.
These four scenarios are shown diagrammatically The problem with this approach is that it can never
in Figure C-2. be implemented. There will never be universal

System_A System_B
Model
Model_A translation Model_B

Figure C-1 | General semantic interoperability problem

83
General concepts to enable semantic interoperability – a case for system-agnostic information models

Data Action1 Data Action1

Share logic Perform the same task
between systems System1 System2 System1 System2 on different systems

Integrate data used in Model1 Data Model2 Action1 Data Action2 Perform different tasks on
different ways on different systems
different systems System1 System2 System1 System2

Figure C-2 | Several engineering semantic interoperability scenarios

System 2

Shared model

System 1
System 4
Shared model
Shared model

Shared model Shared model

System 5 System 3

Figure C-3 | The universal information model requires no translation

84
General concepts to enable semantic interoperability – a case for system-agnostic information models

agreement to adopt a single information model, maintained as the individual models change), that
and even if such agreement could be reached, all in practice no one ever implements it. Instead,
of the existing models would need to be converted. users stick with their siloed enterprise information
So, despite its theoretical perfection, this approach models and skip interoperability.
is not going to be implemented.
The problem can be mitigated somewhat by using
standards instead of enterprise models, but the
C.3 Direct integration of many number of adapters required does not change.
models
A modification of this approach can be envisaged,
The simplest solution available is to take the
in which all of the models are integrated under a
existing models and integrate them one-on-one,
single ontology, but it still does not change the
as shown in Figure C-4.
number of required integrations and remains as
This approach can (and does) work, however it brittle as before.
results in so many adapters being developed for
legacy models (N2-N adapters that have to be

System 2

Model 2

System 1
System 4
Model 1
Model 4

Model 5 Model 3
System 5 System 3

Figure C-4 | Direct integration of models results in N 2-N adapters

85
General concepts to enable semantic interoperability – a case for system-agnostic information models

C.4 Indirect integration of many So what is a SAIM and how is it developed? A

models SAIM is illustrated in Figure C6.

A third approach creates what is called a system- A SAIM, to the greatest extent possible, is
agnostic information model (SAIM), which is constructed of curated standards. The greatest
an aggregate consisting mostly of integrated impact this has on SAIM development is that
standards (hence the term system-agnostic) and the ontologies cannot be modified, so bridge
their integrations, as shown in Figure C-5. ontology mappings are required for each semantic
integration deemed necessary for the model.
In this approach, if we ignore the construction of
Examples of these curated standards are QUDT
the SAIM for the moment, adapters need only be
for physical phenomena and companion standards
constructed between the individual system models
for OPC UA, such as the drive library with property
and the SAIM, resulting in N adapters. Because
and behaviour descriptions. The advantage here
the SAIM is constructed based on standards, it
is that, unlike in the direct integration of system
will change slowly, so the enterprises create and
models shown in Figure C-4, an N2-N set of
maintain their own adapters and the process is
bridge mappings is never necessary, because the
much simpler.
standards have conceptual dependencies (e.g.

System 2

Model 2

System 1
System 4
Model 1
Model 4

Shared model

Model 5 Model 3
System 5 System 3

Figure C-5 | Indirect integration of many models, N adapters

86
General concepts to enable semantic interoperability – a case for system-agnostic information models

two building models, such as IFC and SAREF, do The first two benefits have already been discussed.
not need to be integrated directly because they The effort and risk involved in developing and
can be integrated indirectly to a quantity model maintaining a translation is reduced, because
such as QUDT or to a sensor model such as SSN). only the enterprise side really changes. The
Moreover, these mappings, like the ontologies they SAIM side is comparatively stable as long as the
integrate, change very slowly, and they themselves standard remains stable (and standards change
are curated by the SAIM owner. This is why the in small ways). The development time for software
SAIM can be considered a black box and why the is reduced, because all the standards-based
number of adapters to legacy systems is N. compliance code can be removed, since the SAIM
implements the standard and data validators can
Five clear benefits to this approach can be
be attached directly to the SAIM.
mentioned:

§§ Reduced number of translations to existing C.5 Summary

systems models
Given the need for semantic interoperability
§§ Responsibility for managing/maintaining the between systems, the problems associated with the
SAIM is likely assigned to someone else universal and direct model integration approaches
§§ Reduced effort/risk to develop a translation and the strengths/benefits of indirect integration,
the search continues for a common information
§§ Reduced effort/risk in maintaining translations
model as well as efforts to develop adapters from
§§ Faster software development time legacy system models to such a model.

Standard_N

M_N_Bridge ontology

Standard_M N_O_Bridge ontology

M_O_Bridge ontology

Standard_O

Figure C-6 | SAIM model development

87
Annex D
Relations to existing standardization projects

D.1 ETSI TR 103 535 V0.2.2 §§ Already existing ontologies should be used for
(2019-03) new projects

The ETSI technical report Guidelines for using –S

 ee recommendation 6.1.3, in particular the
semantic interoperability in the industry by the bullet points “Separate the knowledge into
SmartM2M committee describes its objective reusable chunks” and “Look for existing
as follows: “The main objective of the present chunks in curated standards”
document is to push semantic interoperability in IoT –T
 his is a key element for convergence evo-
forward in raising awareness about its importance lution of a common machine understanding
in industry in order to unlock the potential economic
The following findings of this white paper address
value of IoT. A major focus is on the development of
additional aspects:
guidelines on how to use semantic interoperability
in the industry.” §§ Many semantically-relevant information models
already exist in industry, public, or consortium
The report describes the state of the art and
standards which provide a basis for semantic
references existing solutions from academia,
interoperability. These models are not in the
standards, and industry. The main focus is drawn
scope of the ETSI TR
from European and consortium projects. Only a few
standards are mentioned. The authors conclude –S
 ee the Bibliography for a list of semantic
that the benefits of semantic interoperability are relevant standards integrated in the deriva-
not yet exploited in such a way as to contribute to a tion of the gaps and recommendations
maturing of the necessary technology. They mostly
§§ The notion of semantic interoperability given
describe organizational and subjective reasons for
in the ETSI TR reflects the information world
this situation and provide recommendations on
only. It seems that the ETSI TR focuses
how to overcome the limitations.
only on vertical information flow to data-
The following are common findings of this white consuming applications. The industrial domain
paper and the ETSI TR: also involves horizontal data flow and has to
consider the reaction of the real world as well
§§ Public policy support is of great benefit for
creating awareness of semantic interoperability, –S
 ee the use case descriptions in Section 3
in particular standardization and Annex A

–S
 ee the first bullet point of recommendation The ETSI TR seems to focus solely on
6.1.1 which mainly focuses on initiatives to operation time. The life cycle of products and
improve the perception of theimportance of plants, extending from design and planning
semantic interoperability and development to operation and maintenance is only partly
of the necessary standards and technologies reflected

–S
ee especially the engineering use case
descriptions in Subsection 3.5

89
Relations to existing standardization projects

D.2 ISO/IEC 21823-3 in preparation §§ Sensor Model Language (SensorML)

(JTC 1/SC 41/66/CD) §§ IoT-O
ISO/IEC JTC 1/SC 41 has drafted part 3: Semantic §§ Open Connectivity Foundation (OCF) Ontology
interoperability of ISO/IEC 21823, Internet of Things
§§ Smart Appliances REFerence (SAREF) ontol-
(IoT) – Interoperability for internet of things systems.
ogy
It defines sematic interoperability as the “ability for
data shared by systems to be understood at the The following are common findings of this white
level of fully-defined domain concepts (Source: paper and ISO/IEC 21823-3:
ISO 18308:2011, 3.45)”. The scope of the document
§§ Heterogeneity of the cross-domain information
reads: “In this specification, an ontology-driven
models must be overcome
approach for semantic interoperability is specified
so that the sensors, devices, systems and §§ The multi-ontology and hybrid ontology
services can express their contextual information approaches with a domain-specific top-level
and data by applying the ontologies to achieve ontology and underlying are favoured
semantic interoperability.” The work is based on –F
or both findings see primarily the bullet
ISO/IEC 30141, which is modelled as an ontology points entitled “Separate the knowledge
and focuses on the five facets of semantic into reusable chunks” and “Look for
interoperability of ISO 21823-1, namely transport, existing chunks in curated standards” in
syntactic, semantic, behavioural, and policy recommendation 6.1.3
interoperability. The following problem is addressed
§§ The domain-based IoT reference model is
in the document: “There are multiple commercial
accompanied with a formal machine-readable
IoT platforms such as oneM2M [xx], OCF [xxx],
description
LwM2M [xxx] and AllJoyn [xx]. Also, multiple IoT
platforms are coexisting and competing with –S
 ee recommendations 6.1.1 concerning the
each other in IoT environments. In particular, each organization of the semantic interoperable
industry vertical application (e.g. smart factory, information model design, particularly the
smart city, and so on) has developed its own fourth bullet point
specific heterogeneity, which makes it difficult for The following findings of this white paper cover
application providers to develop IoT service. This additional aspects:
heterogeneity makes it difficult for application
providers to develop IoT service”. Additionally, hints §§ The focus of IoT in terms of the vertical
for the management of ontologies are described. integration and system operation phase seems
The main contribution offered by this semantic to be too restricted with regard to semantic
interoperability part involves: interoperability in industry. This white paper
shows that multiple lifecycle phases need to
§§ a domain-based IoT reference model be covered by semantic interoperability
accompanied by an OWL specification of the
IoT reference architecture –S
ee especially the engineering use case
descriptions in Subsection 3.5
The following ontologies are briefly described:
§§ It is necessary to show how the semantically
§§ W3C Semantic Sensor Network Ontology relevant content of existing standards can be
§§ W3C IoT-Lite Ontology integrated in ontologies. It is not clear what gaps
exist between the existing standards and the
§§ oneM2M Base Ontology

90
Relations to existing standardization projects

introduced “domain-based reference model”.

For example, what are the relations between
the PLCopen drive libraries of IEC 61131-3 and
the reference model, and what are the relations
of OPC UA companion specifications to the
reference model? These are standards dealing
with every day industrial solutions which must
be brought into semantically interoperable
applications

91
Bibliography
The following standards are referenced in this white paper:

IEC 60300-3-11:2009, Dependability management – Part 3-11: Application guide – Reliability centred
maintenance

IEC 60381-1:1982, Analogue signals for process control systems – Part 1: Direct current signals

IEC 60617:2012 DB, Graphical symbols for diagrams

IEC 61131-3:2013, Programmable controllers – Part 3: Programming languages

IEC 61360 (all parts), Standard data element types with associated classification scheme

IEC 61784 (all parts), Industrial communication networks

IEC 61804 (all parts), Function blocks (FB) for process control and electronic device description language
(EDDL)

IEC 61850 (all parts), Communication networks and systems for power utility automation

IEC 61968 (all parts), Application integration at electric utilities – System interfaces for distribution management

IEC 61970 (all parts), IEC 61970 – Energy management system application program interface (EMS-API)

IEC 62264 (all parts), Enterprise-control system integration

IEC 62271-3:2015, High-voltage switchgear and controlgear – Part 3: Digital interfaces based on IEC 61850

IEC TR 62390:2005, Common automation device – Profile guideline

IEC 62424:2016, Representation of process control engineering – Requests in P&I diagrams and data
exchange between P&ID tools and PCE-CAE tools

IEC 62453 (all parts), Field device tool (FDT) interface specification

IEC 62541 (all parts), OPC unified architecture

IEC 62714 (all parts), Engineering data exchange format for use in industrial automation systems engineering –
Automation markup language

IEC 62769 (all parts), Field device integration (FDI)

ISO/IEC 19763-3:2010, Information technology – Metamodel framework for interoperability (MFI) – Part 3:
Metamodel for ontology registration

ISO/IEC 21823-1:2019, Internet of things (IoT) – Interoperability for internet of things systems – Part 1:
Framework

ISO/IEC 21823-3 (in preparation), Internet of things (IoT) – Interoperability for internet of things systems –
Part 3: Semantic interoperability

ISO/IEC 30141:2018, Internet of Things (IoT) – Reference architecture

93
Bibliography

ISO 18308:2011, Health informatics – Requirements for an electronic health record architecture

ISO 80000 (all parts), Quantities and units

ETSI TR 103 535 V0.2.2 (2019-03), Guidelines for using semantic interoperability in the industry

94
Notes
Notes
 ISBN 978-2-8322-7321-0

International
Electrotechnical
® Commission CHF 50.-
IEC WP Semantic interoperability:2019-10(en)

3 rue de Varembé T +41 22 919 0211

PO Box 131 [email protected]
CH-1211 Geneva 20 www.iec.ch
Switzerland

® Registered trademark of the International Electrotechnical Commission. Copyright © IEC, Geneva, Switzerland 2019