Towards automating Service Matching for Manufacturing Systems: Exemplifying Knowledge-Driven Architecture Composition

Abstract

Manufacturing systems are currently being equipped with high-level application interfaces (e.g. OPC UA). Although these information models can be standardized by using domain-dependent standards (e.g. PLCopen), the semantics of services is hard to formalize. Especially in the industrial automation domain, current semantic service descriptions (e.g. SAWSDL) are not applicable as they are 1) too cumbersome to maintain & 2) not reusable. In this paper we show how component-based coupling mechanisms can be utilized by a novel bottom-up integration approach. This approach allows for (semi-) automated service coupling by relying on case-based component integration. A proof-of-concept is provided to show the technical feasibility.

Full text

ScienceDirect
Available online at www.sciencedirect.com
Available online at www.sciencedirect.com
ScienceDirect
Procedia CIRP 00 (2017) 000–000
www.elsevier.com/locate/procedia
2212-8271 © 2017 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 28th C IRP Design Conference 2018.
28th CIRP Design Conference, May 2018, Nantes, France
A new methodology to analyze the functional and physical architecture of
existing products for an assembly oriented product family identification
Paul Stief *, Jean-Yves Dantan, Alain Etienne, Ali Siadat
École Nationale Supérieure d’Arts et Métiers, Arts et Métiers ParisTech, LCFC EA 4495, 4 Rue Augustin Fresnel, Metz 57078, France
* Corresponding author. Tel.: +33 3 87 37 54 30; E-mail address: paul.stief@ensam.eu
Abstract
In today’s business environment, the trend towards more product variety and customization is unbroken. Due to this development, the need of
agile and reconfigurable production systems emerged to cope with various products and product families. To design and optimize production
systems as well as to choose the optimal product matches, product analysis methods are needed. Indeed, most of the known methods aim to
analyze a product or one product family on the physical level. Different product families, however, may differ largely in terms of the number and
nature of components. This fact impedes an efficient comparison and choice of appropriate product family combinations for the production
system. A new methodology is proposed to analyze existing products in view of their functional and physical architecture. The aim is to cluster
these products in new assembly oriented product families for the optimization of existing assembly lines and the creation of future reconfigurable
assembly systems. Based on Datum Flow Chain, the physical structure of the products is analyzed. Functional subassemblies are identified, and
a functional analysis is performed. Moreover, a hybrid functional and physical architecture graph (HyFPAG) is the output which depicts the
similarity between product families by providing design support to both, production system planners and product designers. An illustrative
example of a nail-clipper is used to explain the proposed methodology. An industrial case study on two product families of steering columns of
thyssenkrupp Presta France is then carried out to give a first industrial evaluation of the proposed approach.
© 2017 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018.
Keywords: Assembly; Design method; Family identification
1. Introduction
Due to the fast development in the domain of
communication and an ongoing trend of digitization and
digitalization, manufacturing enterprises are facing important
challenges in today’s market environments: a continuing
tendency towards reduction of product development times and
shortened product lifecycles. In addition, there is an increasing
demand of customization, being at the same time in a global
competition with competitors all over the world. This trend,
which is inducing the development from macro to micro
markets, results in diminished lot sizes due to augmenting
product varieties (high-volume to low-volume production) [1].
To cope with this augmenting variety as well as to be able to
identify possible optimization potentials in the existing
production system, it is important to have a precise knowledge
of the product range and characteristics manufactured and/or
assembled in this system. In this context, the main challenge in
modelling and analysis is now not only to cope with single
products, a limited product range or existing product families,
but also to be able to analyze and to compare products to define
new product families. It can be observed that classical existing
product families are regrouped in function of clients or features.
However, assembly oriented product families are hardly to find.
On the product family level, products differ mainly in two
main characteristics: (i) the number of components and (ii) the
type of components (e.g. mechanical, electrical, electronical).
Classical methodologies considering mainly single products
or solitary, already existing product families analyze the
product structure on a physical level (components level) which
causes difficulties regarding an efficient definition and
comparison of different product families. Addressing this
Procedia CIRP 72 (2018) 707–713
2212-8271 © 2018 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 51st CIRP Conference on Manufacturing Systems.
10.1016/j.procir.2018.03.044
Available online at www.sciencedirect.com
ScienceDirect
Procedia CIRP 00 (2018) 000–000
www.elsevier.com/locate/procedia
2212-8271 © 2018 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 51st CIRP Conference on Manufacturing Systems.
51st CIRP Conference on Manufacturing Systems
Towards automating Service Matching for Manufacturing Systems:
Exemplifying Knowledge-Driven Architecture Composition
Fabian Burzlaffa,*, Christian Bartelta und Lukas Adlera
aInstitute for Enterprise Systems (InES), University of Mannheim, L15 1-6, 68159 Mannheim, Germany
* Corresponding author. Tel.: +49 621 181 2368; E-mail address: burzlaff@es.uni-mannheim.de
Abstract
Manufacturing systems are currently being equipped with high-level application interfaces (e.g. OPC UA). Although these
information models can be standardized by using domain-dependent standards (e.g. PLCopen), the semantics of services is hard to
formalize. Especially in the industrial automation domain, current semantic service descriptions (e.g. SAWSDL) are not applicable
as they are 1) too cumbersome to maintain & 2) not reusable. In this paper we show how component-based coupling mechanisms
can be utilized by a novel bottom-up integration approach. This approach allows for (semi-) automated service coupling by relying
on case-based component integration. A proof-of-concept is provided to show the technical feasibility.
© 2018 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 51st CIRP Conference on Manufacturing Systems.
Keywords: Knowledge-driven Architecture Composition, Semantic Integration, Adaptable Systems, Interoperability
1. Introduction
Trends like the Internet of Things or Artificial Intelligence
are currently challenging classical design and engineering
processes for manufacturing systems. As manufacturing
systems (e.g. embedded devices or cyber-physical systems [1])
are being equipped with internet-compatible communication
protocols, coordination effort for service orchestration or
choreography is drastically increasing. One way to reduce this
effort is using semantic service descriptions that allow for
automated service coupling. Therefore, manufacturing systems
in general require for their software part technical, syntactical
and semantic specifications. On the technical layer a
manageable amount of protocols are currently being used either
as a cold/consensual standard (e.g. HTTP or OPC UA1) or are
already declared as strict norms (ISO/IEC 2). Within this
1 https://opcfoundatio n.org/about/opc-technologies/opc -ua/
2 https://webstore.iec.ch/publication/21987
standardization process, the syntactical layer is simultaneously
codified in terms of domain-dependent standards (e.g.
PLCopen 3). As a last step, domain element semantics are
informally tied by describing them with textual descriptions
(e.g. companion specification for OPC UA and
AutomationML 4). As a result, the self-sustaining software
architect can ensure interoperability between devices.
However, such standardization processes tend to be slow. Even
worse, informal specification are not designed to be machine-
readable. In fact, extracting crisp and unambiguous semantics
from text with current natural language processing techniques
may not work out of the box. As one solution to this problem,
industry practitioners introduced formal ontologies to formally
define semantic relationships between different information
models [2]. Consequently, independent developed devices
could be integrated easily. However, reading and writing values
3 http://www.plcopen.org/
4 https://opcfoundatio n.org/markets-colla boration/automation-ml/

708 Fabian Burzlaff et al. / Procedia CIRP 72 (2018) 707–713
2 Fabian Burzlaff et al. / Procedia CIRP 00 (2018) 000–000
to an integrated information model may not be a good servant
for flexible production scenarios as production services often
require not only one but several input parameters. For instance,
system behavior in versatile production environments must not
only deal with heterogeneous information models but also with
functional semantics. In accordance to the definition of an
Administrator-Shell and the reference architecture RAMI 4.0
[3], components should be able to semantically connect to each
other at the functional/service layer as well (see Figure 1).
Therefore, this paper will introduce an initial solution to the
following semantic service integration requirements:
 Functions and Services should be semantically describable
 Independent semantic service descriptions should be
matched according to domain-specific rules
 Several services can be integrated into a service composite
 Integration knowledge should be reused
To realize these requirements, the remainder of this paper is
structured as follows: In chapter 2, an example in the context of
a multi-product production line that utilizes automated
horizontal web service coupling mechanisms is introduced. In
Chapter 3 the conceptual solution for reusing architectural
integration knowledge is described. Chapter 4 realizes
knowledge-driven architecture composition by using OPC UA,
SAWSDL [4] and an extended version of the SAWSDL-MX
matcher [5]. Finally, chapter 5 recapitulates our implementation
experience and chapter 6 provides a summarizing conclusion.
2. Supporting solution approaches
Semantic component integration is a well-established
interdisciplinary research area [6, 7]. In order to automate
component coupling mechanisms, various approaches from the
software engineering as well as the semantic web community
have been proposed [8]–[10]. Formally describing the
semantics of a web service or a component interface is a
necessary step when components should be integrated in an
(semi-) automated way. However, the Internet of Things and
Services (IoTS) cannot be designed in a classical top-down
engineering process. Even within industry domains various
heterogeneous and open standards will be present [2]. As a
consequence, mappings between different sets of properties,
data formats and company singularities must be created and
maintained in order to be able to automatically change
production lines and processes. As IoTS-provider will
formalize their services independent from each other, the
workload for system integrators will shift from implementing
point-to-point adapters between component interfaces (i.e. no
machine-readable component description that externalizes the
functionality present) towards integrating different functional
descriptions. Even worse, as functional dependability of
software components must be guaranteed, changing the
semantic service descriptions may be prohibited by regulations
or is technically not possible.
Imagine for example a versatile production scenario where
one machine offers a drilling service (see Figure 2).
Figure 1: Service descriptions for I4.0-Component
In order to utilize this device functionality in an existing
production process, the provided semantic service description
is being evaluated by the communication system (e.g. a
middleware realizing a manufacturing service bus) and then
registered as a new service available for usage. As soon as a
production process step needs the offered drilling functionality,
it can be search for, instantiated and bound. Overall, in this
vertical usage scenario the process itself is controlling its
correct execution in a top down manner (see Figure 1). In
practice, the visualized layers are typically highly interlinked.
For example, a service invocation manipulates information
elements during their execution. Although these dependencies
exist, we will focus only on service description for the rest of
the paper, as our theoretical approach is particular focusing on
integration issues on the horizontal layer.
Figure 2: Interface descriptions for I4.0-Component
As production scenarios could also be configured in a
bottom-up way (e.g. dynamic service composition at runtime),
the correct horizontal communication between machines must
also be ensured. In this case, it will most likely be the case that
device manufacturer will describe their interfaces in different
ways. This may cause problems as current semantic interface
matcher are only designed to match descriptions in a fuzzy
manner (e.g. offering different levels of accuracy). In addition,
these matchers offer no possibility to incrementally incorporate
use-case specific integration knowledge that can be reused in
case a service description does not match exactly. Overall,
semantic service matchers for coupling web-services in
manufacturing systems should support the following range of
functionality:
 Semantic service matcher must only support match/no
match mentality in production scenarios for efficiency
reasons to ensure correct system behavior
 System integrators must not be required to adapt formal
service descriptions
 System integration knowledge should be reusable and
adaptable
Fabian Burzlaff et al./ Procedia CIRP 00 (2018) 000–000 3
 Semantic transformations rules enabling interface
interoperability should be machine-readable
3. A system architecture enabling Knowledge-driven
Architecture composition
Today´s internet-native systems are generally composed out of
different fine-grained services [11]. Methods and techniques
like Platform-as-a-Service or Microservices allow for a rapid
system evolution. As soon as an adapted version of a
(composed) service is needed, a new deployment including the
necessary changes is made. However, this process relies on
having a common practice (i.e. having unambiguous syntax
and semantics) for defining each service. Due to the
circumstance that technology-driven innovations are currently
ahead of classical standardization efforts, there exist a
knowledge gap. This knowledge gap hinders for example self-
adaptive system behaviour where mission-critical services are
dynamically composed at runtime. One promising approach to
tackle this problem is a knowledge-driven architecture
composition (KDAC) [12,13]. In order to dynamically
compose industrial services at runtime, integration knowledge
from within a company should be formalized from bottom-up
(see Figure 3). This approach can close the knowledge gap until
a suitable standard is available. As common sense in a domain
about the semantics of a specific functionality is hard to
achieve, the semantics regarding the functionality in the given
context (e.g. company-wide) must be attached in a formalized
way.
According to the KDAC-Approach device manufacturers,
system integrators and site operators are involved in the
engineering process. Furthermore, the engineering process is
subdivided into design time, integration time and run time.
Figure 4: Exemplary Interface Interoperability Error Resolution
During design time of the components, a device manufacturer
constructs the device physically and deploys all needed
software components (see Figure 1). The externally available
interfaces of these components are formally described with an
interface definition language that also supports semantic
properties.
During runtime, the site operator can change the production
process as needed and can reuse (e.g. by using inference
properties of logic-based languages) the domain-specific
integration knowledge automatically. This means that the site
operator must only call a system integrator if a needed
communication between things cannot be established.
During integration time, all needed but failed matches are
evaluated. In case there is no exact match, a communication
between two things is not possible at runtime. Thus, the system
integrator hast to manually evaluate the device incompatibility
and formalize the missing integration knowledge. Here, the
system integrator aims at improving the matching result to an
exact match so that the systems can be coupled. This process is
visualized in Figure 4.
Figure 3: Knowledge-Driven Architecture Composition (adapted from [12])
In case of no exact match by the semantic service matcher, the
system integrator inserts knowledge about needed
transformations into a knowledge base. For example, he can
specify that all values of type speed equals two times the value
of type torque.
In comparison to classical top-down engineering processes,
this approach allows for the following optimization steps:
1. The matching process can be improved by domain-specific
usage knowledge
2. Formalized integration knowledge can be reused during
the matching process
3. By incrementally extending the knowledge base, service
compositions can be defined and executed in an automated
way without relying on predefined standards
As the knowledge base is created in a bottom up manner, it
can also serve as an indicator for future standardization
requirements. Hence, this approach does not try to replace
traditional standardization efforts but rather it complements
them by providing an engineering process when functionality
of independently developed software components must be
made machine-readable from the beginning.
Our contribution in the following chapter is two-folded: On
the hand, we will apply our approach to the topic of web service
coupling. On the other hand, we will show how current
semantic service matching approaches can be adapted to enable
automated web service coupling for manufacturing systems.
4. Realizing automated service coupling with KDAC
In the following, we will apply our conceptual approach to
the domain of industrial manufacturing systems and provide an
experimental evaluation when semantic web service matchers
are applied in an industrial setting. In order to integrate
different open-source technologies, we have chosen the Eclipse
IDE as a development platform. Next, we have evaluated

Fabian Burzlaff et al. / Procedia CIRP 72 (2018) 707–713 709
2 Fabian Burzlaff et al. / Procedia CIRP 00 (2018) 000–000
to an integrated information model may not be a good servant
for flexible production scenarios as production services often
require not only one but several input parameters. For instance,
system behavior in versatile production environments must not
only deal with heterogeneous information models but also with
functional semantics. In accordance to the definition of an
Administrator-Shell and the reference architecture RAMI 4.0
[3], components should be able to semantically connect to each
other at the functional/service layer as well (see Figure 1).
Therefore, this paper will introduce an initial solution to the
following semantic service integration requirements:
 Functions and Services should be semantically describable
 Independent semantic service descriptions should be
matched according to domain-specific rules
 Several services can be integrated into a service composite
 Integration knowledge should be reused
To realize these requirements, the remainder of this paper is
structured as follows: In chapter 2, an example in the context of
a multi-product production line that utilizes automated
horizontal web service coupling mechanisms is introduced. In
Chapter 3 the conceptual solution for reusing architectural
integration knowledge is described. Chapter 4 realizes
knowledge-driven architecture composition by using OPC UA,
SAWSDL [4] and an extended version of the SAWSDL-MX
matcher [5]. Finally, chapter 5 recapitulates our implementation
experience and chapter 6 provides a summarizing conclusion.
2. Supporting solution approaches
Semantic component integration is a well-established
interdisciplinary research area [6, 7]. In order to automate
component coupling mechanisms, various approaches from the
software engineering as well as the semantic web community
have been proposed [8]–[10]. Formally describing the
semantics of a web service or a component interface is a
necessary step when components should be integrated in an
(semi-) automated way. However, the Internet of Things and
Services (IoTS) cannot be designed in a classical top-down
engineering process. Even within industry domains various
heterogeneous and open standards will be present [2]. As a
consequence, mappings between different sets of properties,
data formats and company singularities must be created and
maintained in order to be able to automatically change
production lines and processes. As IoTS-provider will
formalize their services independent from each other, the
workload for system integrators will shift from implementing
point-to-point adapters between component interfaces (i.e. no
machine-readable component description that externalizes the
functionality present) towards integrating different functional
descriptions. Even worse, as functional dependability of
software components must be guaranteed, changing the
semantic service descriptions may be prohibited by regulations
or is technically not possible.
Imagine for example a versatile production scenario where
one machine offers a drilling service (see Figure 2).
Figure 1: Service descriptions for I4.0-Component
In order to utilize this device functionality in an existing
production process, the provided semantic service description
is being evaluated by the communication system (e.g. a
middleware realizing a manufacturing service bus) and then
registered as a new service available for usage. As soon as a
production process step needs the offered drilling functionality,
it can be search for, instantiated and bound. Overall, in this
vertical usage scenario the process itself is controlling its
correct execution in a top down manner (see Figure 1). In
practice, the visualized layers are typically highly interlinked.
For example, a service invocation manipulates information
elements during their execution. Although these dependencies
exist, we will focus only on service description for the rest of
the paper, as our theoretical approach is particular focusing on
integration issues on the horizontal layer.
Figure 2: Interface descriptions for I4.0-Component
As production scenarios could also be configured in a
bottom-up way (e.g. dynamic service composition at runtime),
the correct horizontal communication between machines must
also be ensured. In this case, it will most likely be the case that
device manufacturer will describe their interfaces in different
ways. This may cause problems as current semantic interface
matcher are only designed to match descriptions in a fuzzy
manner (e.g. offering different levels of accuracy). In addition,
these matchers offer no possibility to incrementally incorporate
use-case specific integration knowledge that can be reused in
case a service description does not match exactly. Overall,
semantic service matchers for coupling web-services in
manufacturing systems should support the following range of
functionality:
 Semantic service matcher must only support match/no
match mentality in production scenarios for efficiency
reasons to ensure correct system behavior
 System integrators must not be required to adapt formal
service descriptions
 System integration knowledge should be reusable and
adaptable
Fabian Burzlaff et al./ Procedia CIRP 00 (2018) 000–000 3
 Semantic transformations rules enabling interface
interoperability should be machine-readable
3. A system architecture enabling Knowledge-driven
Architecture composition
Today´s internet-native systems are generally composed out of
different fine-grained services [11]. Methods and techniques
like Platform-as-a-Service or Microservices allow for a rapid
system evolution. As soon as an adapted version of a
(composed) service is needed, a new deployment including the
necessary changes is made. However, this process relies on
having a common practice (i.e. having unambiguous syntax
and semantics) for defining each service. Due to the
circumstance that technology-driven innovations are currently
ahead of classical standardization efforts, there exist a
knowledge gap. This knowledge gap hinders for example self-
adaptive system behaviour where mission-critical services are
dynamically composed at runtime. One promising approach to
tackle this problem is a knowledge-driven architecture
composition (KDAC) [12,13]. In order to dynamically
compose industrial services at runtime, integration knowledge
from within a company should be formalized from bottom-up
(see Figure 3). This approach can close the knowledge gap until
a suitable standard is available. As common sense in a domain
about the semantics of a specific functionality is hard to
achieve, the semantics regarding the functionality in the given
context (e.g. company-wide) must be attached in a formalized
way.
According to the KDAC-Approach device manufacturers,
system integrators and site operators are involved in the
engineering process. Furthermore, the engineering process is
subdivided into design time, integration time and run time.
Figure 4: Exemplary Interface Interoperability Error Resolution
During design time of the components, a device manufacturer
constructs the device physically and deploys all needed
software components (see Figure 1). The externally available
interfaces of these components are formally described with an
interface definition language that also supports semantic
properties.
During runtime, the site operator can change the production
process as needed and can reuse (e.g. by using inference
properties of logic-based languages) the domain-specific
integration knowledge automatically. This means that the site
operator must only call a system integrator if a needed
communication between things cannot be established.
During integration time, all needed but failed matches are
evaluated. In case there is no exact match, a communication
between two things is not possible at runtime. Thus, the system
integrator hast to manually evaluate the device incompatibility
and formalize the missing integration knowledge. Here, the
system integrator aims at improving the matching result to an
exact match so that the systems can be coupled. This process is
visualized in Figure 4.
Figure 3: Knowledge-Driven Architecture Composition (adapted from [12])
In case of no exact match by the semantic service matcher, the
system integrator inserts knowledge about needed
transformations into a knowledge base. For example, he can
specify that all values of type speed equals two times the value
of type torque.
In comparison to classical top-down engineering processes,
this approach allows for the following optimization steps:
1. The matching process can be improved by domain-specific
usage knowledge
2. Formalized integration knowledge can be reused during
the matching process
3. By incrementally extending the knowledge base, service
compositions can be defined and executed in an automated
way without relying on predefined standards
As the knowledge base is created in a bottom up manner, it
can also serve as an indicator for future standardization
requirements. Hence, this approach does not try to replace
traditional standardization efforts but rather it complements
them by providing an engineering process when functionality
of independently developed software components must be
made machine-readable from the beginning.
Our contribution in the following chapter is two-folded: On
the hand, we will apply our approach to the topic of web service
coupling. On the other hand, we will show how current
semantic service matching approaches can be adapted to enable
automated web service coupling for manufacturing systems.
4. Realizing automated service coupling with KDAC
In the following, we will apply our conceptual approach to
the domain of industrial manufacturing systems and provide an
experimental evaluation when semantic web service matchers
are applied in an industrial setting. In order to integrate
different open-source technologies, we have chosen the Eclipse
IDE as a development platform. Next, we have evaluated

710 Fabian Burzlaff et al. / Procedia CIRP 72 (2018) 707–713
4 Fabian Burzlaff et al. / Procedia CIRP 00 (2018) 000–000
different semantic service matcher regarding their matching
process. As a result, we have chosen the SAWSDL-MX service
matcher [14] as this matcher incorporates an ontology handler
that can evaluate multiple ontologies regarding their logical
correctness.
Furthermore, this matcher also supports syntactic operation
matching by using user-specified similarity measures. The
unique results can be aggregated in a hybrid way (e.g. using
syntactic similarity measures first when no logic-based
correspondence applies). In the end, all aggregated results are
ranked according to their interoperability with the following
order-based degrees: exact > plug-in > subsumes > subsumed-
by > fail. For instance, an exact logical match filter requires
that all required input and output types can be mapped to the
same element in an ontology without any sub-types or type
transformations.
For defining domain-specific integration rules, we have
chosen the web ontology language OWL-DL5 in combination
with the semantic web rule language SWRL6.
To simulate different embedded devices, we have set up
several embedded devices, which are represented by artificial
OPC UA Server. To implement these OPC UA server, we have
chosen the Eclipse Milo framework7. Next we have formally
described methods like drillHole(..) (see Figure 4) with
semantic annotations for web service description languages
called SAWSDL. The SAWSDL8 format can be consumed by
the semantic service matcher SAWSDL-MX [5].
The conceptual architecture is displayed in Figure 5.
Figure 5: Conceptual Software Architecture supporting our approach
Now, imagine a production line that consists of a drill
device, an automated guided vehicle (AGV) and a high-
resolution video camera. The drill device does have two
sensors in order to detect whether a wood piece is present or
not. The video camera supervises if no obstacles are present.
This situation is depicted in Figure 6.
As the AGV is approaching the drill device, it requests the
height of the workbench from the drill. The AGV adjusts its lift
5 https://www.w3.org/OWL/
6 https://www.w3.org/Submission/SWRL/
7 https://github.com/eclipse/milo
arm accordingly and the drill machine confirms the correct
placement of the wood piece as soon as it receives the values
from its detection sensors. This case is now assumed to be the
standard case for such a transportation scenario. For both
devices (i.e. drill and AGV) and all additionally required and
provided interfaces, a SAWSDL description is present and can
be automatically matched by the service matcher SAWSDL-
MX. In case of an exact match, a communication between both
devices can be established (e.g. SOAP support for OPC UA9).
Figure 6: Use-Case Scenario
In case of no exact match, no communication can be
established as the semantics and/or syntax of one of these
services is different. In the case of SAWSDL-MX this means
that one of the interface descriptions must be adapted
accordingly and the new service description must be integrated
into the existing service provider landscape. By using the
KDAC approach, this circumstance is tackled by an
engineering process that does not rely on a standard. First, the
system integrator evaluates the reasons for the mismatch. If he
can solve the mismatch by a company-wide accepted
transformation rule, he can formalize this transformation by
defining the respective SWRL rule.
Returning to our example, a transformation could include
the usage of the high-resolution camera for supporting the
placement task of the wood onto the workbench.
If an integrated distance sensor from the drilling machine is
broken, the AGV cannot perform the placing task. However,
the correct position of the wood piece could also be determined
by the camera by identifying the wood object within the video
frame. By calculating the current position using height, width
and depth from the object as well as its distance to the drill
workbench, the AGV is re-enabled to perform its placement
task.
Although this example is highly artificial, it exemplifies
another important problem for automatic service coupling in
the context of the industrial IoTS: As more and more
heterogeneous devices are connected even across domains, it is
hard to anticipate all possible future use cases during design
time of the manufacturing device.
In our example, the needed domain-specific integration
knowledge is formalized using SWRL and OWL-DL. In Figure
7, the semantic service descriptions which is anchored at the
service layer is displayed. Inside this SAWSDL excerpt, a
8 https://www.w3.org/TR/sawsdl/
9 http://documentation.unified-
automation.com/uasdkdotnet/2.5.5/htm l/L2OpcUaSoftwareLayers.html
Fabian Burzlaff et al./ Procedia CIRP 00 (2018) 000–000 5
variable “torque” is used. This variable is represented by its
lexicographical identical OWL element from the knowledge
base. Inside the grey box, an SWRL rule has been inserted into
the knowledge base that transforms the torque value into the
speed value (c.f. Figure 4). This rule was inserted by a system
integrator due to a previous matching failure between speed
and torque value. Due to the system architecture, this rule can
now be applied in addition to the matching rules defined by
SAWSDL-MX and both service description can finally be
coupled if no other matching inaccuracy are present. Additional
integration rules such as unit transformations or service
compositions can also be inserted by the system integrator.
Figure 7: SWRL Integration rules for Interface Descriptions
If this error would reoccur at another drilling machine, this
knowledge and the matching result is consumed by the Case-
Based Linker plugin. This plugin automatically evaluates
whether the matching result provided by the SAWSDL matcher
can be improved towards an exact match based on the available
integration knowledge. As a consequence, the two systems can
be coupled in an automated way without changing their
interfaces but still relying on a reliable matching process.
Furthermore, it is also possible to reuse only the conceptual
integration construct of “using a camera for detecting
distances” and only adjust the use-case specific calculation
steps.
4.1. Evaluation
We tested our approach with the test data set TC310. This
test set serves as an official test set within the semantic web
service matching community. In this test set, there exists 51
queries, 1083 service descriptions described with SAWSDL,
43 ontologies and their respective domain descriptions.
Overall, there are 14 ontologies for various use cases such as
wine and food or books. In order to evaluate the tool support
for our approach, we extend this test set with the following
artefacts required by the drill example: 9 queries, 3 services and
4 ontologies. In order to improve the matching result returned
from the SAWSDL-MX matcher, we had to insert two
individuals for both, the provided and the required service. In
addition, two translation rules were created. The creation of
individuals and translation rules can be interpreted as the work
carried out by system integrators. Although these integration
rules are highly use-case specific, our bottom-up engineering
approach was successfully supported by existing technologies.
10 https://github.com/kmi/sws-test-collections
The resulting prototype is seen as the “automation” component
for bottom-up service integration.
By pursuing this approach experimentally, we could notice an
improvement for matching results whenever a use-case which
has been enriched with domain-specific integration knowledge
reoccurred (e.g. drillHole(..)). In addition, general unit
transformation for input parameters could also be reused in
related use-cases.
A simplified software architecture, which was used for testing
is displayed in Figure 8. The color green indicates newly
created software components and the color blue indicates the
reuse of existing components such as the SAWSDL-MX
matcher.
Figure 8: Technical Realization of Software Architecture
As we only tested the technical feasibility of our proposed
software architecture, multiple points remain open for further
investigation. In the following, we provide an incomplete list
with open issues from our point of view:
 It must be assured that “enough” integration knowledge
to support automatic service composition is available.
This means that a system integrator must insert his
interface integration knowledge based on a machine-
readable language (e.g. OWL-S). However, there exist
no service test set for Industry 4.0 scenarios.
 As the integration knowledge has to be formalized, the
system integrator must be familiar with formal,
declarative languages that support automated
reasoning. This may be a major usability obstacle in
industrial case studies.
 It is critical to ensure semantic equality for integration
knowledge from different use-cases. Using test-based
verification methods seem to be a suitable candidate
towards solving this problem.
Last, please note that we have chosen the AGV example for
illustrating the problem that system integrators cannot
formalize all possible use-cases at design time. However, this
example only serves as a context for the technical evaluation of
our prototype and not as the main target of our evaluation. The
main target of our evaluation was the technical realization and
a possible configuration carried out by one of our students
enrolled in the master program “Business Informatics”.

Fabian Burzlaff et al. / Procedia CIRP 72 (2018) 707–713 711
4 Fabian Burzlaff et al. / Procedia CIRP 00 (2018) 000–000
different semantic service matcher regarding their matching
process. As a result, we have chosen the SAWSDL-MX service
matcher [14] as this matcher incorporates an ontology handler
that can evaluate multiple ontologies regarding their logical
correctness.
Furthermore, this matcher also supports syntactic operation
matching by using user-specified similarity measures. The
unique results can be aggregated in a hybrid way (e.g. using
syntactic similarity measures first when no logic-based
correspondence applies). In the end, all aggregated results are
ranked according to their interoperability with the following
order-based degrees: exact > plug-in > subsumes > subsumed-
by > fail. For instance, an exact logical match filter requires
that all required input and output types can be mapped to the
same element in an ontology without any sub-types or type
transformations.
For defining domain-specific integration rules, we have
chosen the web ontology language OWL-DL5 in combination
with the semantic web rule language SWRL6.
To simulate different embedded devices, we have set up
several embedded devices, which are represented by artificial
OPC UA Server. To implement these OPC UA server, we have
chosen the Eclipse Milo framework7. Next we have formally
described methods like drillHole(..) (see Figure 4) with
semantic annotations for web service description languages
called SAWSDL. The SAWSDL8 format can be consumed by
the semantic service matcher SAWSDL-MX [5].
The conceptual architecture is displayed in Figure 5.
Figure 5: Conceptual Software Architecture supporting our approach
Now, imagine a production line that consists of a drill
device, an automated guided vehicle (AGV) and a high-
resolution video camera. The drill device does have two
sensors in order to detect whether a wood piece is present or
not. The video camera supervises if no obstacles are present.
This situation is depicted in Figure 6.
As the AGV is approaching the drill device, it requests the
height of the workbench from the drill. The AGV adjusts its lift
5 https://www.w3.org/OWL/
6 https://www.w3.org/Submission/SWRL/
7 https://github.com/eclipse/milo
arm accordingly and the drill machine confirms the correct
placement of the wood piece as soon as it receives the values
from its detection sensors. This case is now assumed to be the
standard case for such a transportation scenario. For both
devices (i.e. drill and AGV) and all additionally required and
provided interfaces, a SAWSDL description is present and can
be automatically matched by the service matcher SAWSDL-
MX. In case of an exact match, a communication between both
devices can be established (e.g. SOAP support for OPC UA9).
Figure 6: Use-Case Scenario
In case of no exact match, no communication can be
established as the semantics and/or syntax of one of these
services is different. In the case of SAWSDL-MX this means
that one of the interface descriptions must be adapted
accordingly and the new service description must be integrated
into the existing service provider landscape. By using the
KDAC approach, this circumstance is tackled by an
engineering process that does not rely on a standard. First, the
system integrator evaluates the reasons for the mismatch. If he
can solve the mismatch by a company-wide accepted
transformation rule, he can formalize this transformation by
defining the respective SWRL rule.
Returning to our example, a transformation could include
the usage of the high-resolution camera for supporting the
placement task of the wood onto the workbench.
If an integrated distance sensor from the drilling machine is
broken, the AGV cannot perform the placing task. However,
the correct position of the wood piece could also be determined
by the camera by identifying the wood object within the video
frame. By calculating the current position using height, width
and depth from the object as well as its distance to the drill
workbench, the AGV is re-enabled to perform its placement
task.
Although this example is highly artificial, it exemplifies
another important problem for automatic service coupling in
the context of the industrial IoTS: As more and more
heterogeneous devices are connected even across domains, it is
hard to anticipate all possible future use cases during design
time of the manufacturing device.
In our example, the needed domain-specific integration
knowledge is formalized using SWRL and OWL-DL. In Figure
7, the semantic service descriptions which is anchored at the
service layer is displayed. Inside this SAWSDL excerpt, a
8 https://www.w3.org/TR/sawsdl/
9 http://documentation.unified-
automation.com/uasdkdotnet/2.5.5/htm l/L2OpcUaSoftwareLayers.html
Fabian Burzlaff et al./ Procedia CIRP 00 (2018) 000–000 5
variable “torque” is used. This variable is represented by its
lexicographical identical OWL element from the knowledge
base. Inside the grey box, an SWRL rule has been inserted into
the knowledge base that transforms the torque value into the
speed value (c.f. Figure 4). This rule was inserted by a system
integrator due to a previous matching failure between speed
and torque value. Due to the system architecture, this rule can
now be applied in addition to the matching rules defined by
SAWSDL-MX and both service description can finally be
coupled if no other matching inaccuracy are present. Additional
integration rules such as unit transformations or service
compositions can also be inserted by the system integrator.
Figure 7: SWRL Integration rules for Interface Descriptions
If this error would reoccur at another drilling machine, this
knowledge and the matching result is consumed by the Case-
Based Linker plugin. This plugin automatically evaluates
whether the matching result provided by the SAWSDL matcher
can be improved towards an exact match based on the available
integration knowledge. As a consequence, the two systems can
be coupled in an automated way without changing their
interfaces but still relying on a reliable matching process.
Furthermore, it is also possible to reuse only the conceptual
integration construct of “using a camera for detecting
distances” and only adjust the use-case specific calculation
steps.
4.1. Evaluation
We tested our approach with the test data set TC310. This
test set serves as an official test set within the semantic web
service matching community. In this test set, there exists 51
queries, 1083 service descriptions described with SAWSDL,
43 ontologies and their respective domain descriptions.
Overall, there are 14 ontologies for various use cases such as
wine and food or books. In order to evaluate the tool support
for our approach, we extend this test set with the following
artefacts required by the drill example: 9 queries, 3 services and
4 ontologies. In order to improve the matching result returned
from the SAWSDL-MX matcher, we had to insert two
individuals for both, the provided and the required service. In
addition, two translation rules were created. The creation of
individuals and translation rules can be interpreted as the work
carried out by system integrators. Although these integration
rules are highly use-case specific, our bottom-up engineering
approach was successfully supported by existing technologies.
10 https://github.com/kmi/sws-test-collec tions
The resulting prototype is seen as the “automation” component
for bottom-up service integration.
By pursuing this approach experimentally, we could notice an
improvement for matching results whenever a use-case which
has been enriched with domain-specific integration knowledge
reoccurred (e.g. drillHole(..)). In addition, general unit
transformation for input parameters could also be reused in
related use-cases.
A simplified software architecture, which was used for testing
is displayed in Figure 8. The color green indicates newly
created software components and the color blue indicates the
reuse of existing components such as the SAWSDL-MX
matcher.
Figure 8: Technical Realization of Software Architecture
As we only tested the technical feasibility of our proposed
software architecture, multiple points remain open for further
investigation. In the following, we provide an incomplete list
with open issues from our point of view:
 It must be assured that “enough” integration knowledge
to support automatic service composition is available.
This means that a system integrator must insert his
interface integration knowledge based on a machine-
readable language (e.g. OWL-S). However, there exist
no service test set for Industry 4.0 scenarios.
 As the integration knowledge has to be formalized, the
system integrator must be familiar with formal,
declarative languages that support automated
reasoning. This may be a major usability obstacle in
industrial case studies.
 It is critical to ensure semantic equality for integration
knowledge from different use-cases. Using test-based
verification methods seem to be a suitable candidate
towards solving this problem.
Last, please note that we have chosen the AGV example for
illustrating the problem that system integrators cannot
formalize all possible use-cases at design time. However, this
example only serves as a context for the technical evaluation of
our prototype and not as the main target of our evaluation. The
main target of our evaluation was the technical realization and
a possible configuration carried out by one of our students
enrolled in the master program “Business Informatics”.

712 Fabian Burzlaff et al. / Procedia CIRP 72 (2018) 707–713
6 Fabian Burzlaff et al. / Procedia CIRP 00 (2018) 000–000
4.2. Technical limitations
Smart manufacturing systems are not trivial to build as
different system models have to be connect between and in-
between each other. Realizing such systems requires
professionals with different backgrounds to cooperate. As we
intended to show the feasibility from a software engineering
point of view, we utilized fundamental research results from
the semantic web service community. However, semantic web
service descriptions are not widely used in practice. One reason
for this might be that service provider must execute the service
formalization process in addition to implementing the desired
functionality. In the context of web services, there is no damage
done when two interfaces do not match. By applying semantic
web services to an artificial production scenario, the motivation
for defining semantic interface descriptions correctly increases
as the physical working environment may be negatively
affected. Still, SAWSDL and SAWSDL-MX may rather be
used in the context of coupling an embedded device with a non-
mission-critical communication tasks rather than executing a
production process. In addition, WSDL and its semantic
extension heavily rely on the Simple Object Access Protocol
(SOAP) [15]. Although this protocol is supported by the
official .NET OPC UA implementation 11 , other
communication protocols may be fitting more accurately to its
requirements. Notwithstanding these circumstances, this does
not hinder the conceptual applicability of the proposed
approach.
5. Assessing Automated Web Service Coupling
Approaches for Manufacturing Systems from 1000 feet
When applying the KDAC approach, we have assumed that
all services are accessible by a web communication protocol
(e.g. SOAP over HTTP). Furthermore, these services are
described by the device manufacturer in a suitable language
(e.g. SAWSDL). However, by relying on these predefined
service descriptions the system integration process also
becomes inflexible as an adaptation of the overall integration
may be easier (e.g. changing an ontology or a referenced model
element instead of formalizing an integration rule).
Nonetheless, creating semantic service description for all
possible use case scenarios would result in a high formalization
effort without the guarantee that this effort pays off. As
integration knowledge is automatically reused, services with
minimal interface specification can still be matched and
composed. Evidences supporting this claim are a high diversity
of niche specialist in local manufacturing domains (e.g.
Germany) and the circumstance that industrial manufacturing
is facing high dependability requirements compared to other
industry branches.
One promising solution for reducing the integration effort
would be interface description languages that allow for
incomplete service specifications. Incomplete in this context
means not that service descriptions do expose an invalid
11 http://documentatio n.unified-
automation.com/uasdkdotnet/2.5.5/htm l/L2OpcUaSoftwareLayers.html
syntactic structure but only describe the structure and behavior
of a component for a minimal set of use-cases. This means that
semantic service matcher for web services (e.g. SAWSDL-
MX) or software components (e.g. MatchBox [16]) cannot
support such inferred service compositions as they can only
match what´s described. Nevertheless, using incomplete
service descriptions do rarely produce an exact match and
provide more often a probability score that externalizes the
confidence of an approach using a certain algorithm. Yet, this
probability is hindering a dynamic system evolution.
A possible way to solve this challenge are logic-based
inference methods from the field of artificial intelligence. To
capture integration knowledge efficiently, languages like
OWL-DL were designed to solve semantic data integration
issues. However, they do not respect runtime behavior of
software components or can effectively be used for service
composition. Hence, symbolic languages with a higher
expressiveness to formally calculate (composite) service
semantics may be more suitable. Although available, this raises
not only again the challenge of a high formalization effort for
realizing the integration knowledge base, but also requires
highly-specialized employees.
Nevertheless, we believe that logic-based domain-specific
languages for formalizing integration rules can increase the
usability of this approach to a satisfying level.
5.1. Future Work
As a first step, we plan to modify the language for capturing
integration knowledge. This language should be able to deal
with incomplete service descriptions (i.e. use-case based
formalization) for describing the interface of software
components and inserting integration rules into the knowledge
base.
Next, we plan to evaluate our approach with engineers from
the manufacturing domain. In order to successfully apply this
approach to industrial settings, it must be assessed how much
integration knowledge is needed to 1) automate service
coupling mechanisms and 2) compare our approach to existing
approaches. A comparison metric could be the time to
formalize integration rules or how many unforeseen use cases
can be automatically integrated.
Another question to be answered is how integration
knowledge is managed. On the one hand, this approach requires
enough integration rules for automating service coupling even
for unanticipated integration cases. On the other hand, logical
consistency of multiple knowledge bases must be ensured.
Hence it will be also critical to remove knowledge from the
knowledge base as soon as a suitable standard can be
established (e.g. when integration knowledge is identical and
present in multiple knowledge bases across cooperating
companies).
Fabian Burzlaff et al./ Procedia CIRP 00 (2018) 000–000 7
6. Conclusion
In this paper, we have applied a novel engineering approach
for semantic service integration that allows for (semi-)
automated web service coupling in the context of
manufacturing systems. Therefore, we utilized current
semantic web service interface matchers and outlined
shortcomings of such matcher in the domain of manufacturing
systems and the Industrial Internet of Things and Services.
Next, we evaluated our conceptual architecture composition
approach by extending a semantic service matcher that allows
for specifying domain-specific integration rules. We tested our
prototype in the context of an artificial production site
experimentally. By formalizing integration knowledge for
manufacturing systems in a bottom-up way, the effort spent for
formalizing component interfaces is minimized without
dropping the ability for automated web service coupling. As a
last contribution, we stated several future challenges for
semantic service integration in the context of intelligently
connected manufacturing systems.
By using a knowledge-driven architecture composition
approach, the knowledge gap between new technological
innovations and realizing a domain standard can be closed.
This allows for dynamic system compositions at runtime
without relying on predefined and informal service semantics.
References
[1] J. Lee, B. Bagheri, and H.-A. Kao, “A Cyber-Physical Systems
architecture for Industry 4.0-based manufacturing systems,” Manuf.
Lett., vol. 3, pp. 18–23, Jan. 2015.
[2] U. Döbrich, M. Hankel, R. Heidel, and M. Hoffmeister, Basiswissen
RAMI 4.0: Referenzarchitekturmodell und Industrie 4.0-Komponente
Industrie 4.0. Beuth Verlag, 2017.
[3] H. Lasi, P. Fettke, H.-G. Kemper, T. Feld, and M. Hoffmann, “Industry
4.0,” Bus. Inf. Syst. Eng., vol. 6, no. 4, pp. 239–242, Aug. 2014.
[4] “SAWSDL: Semantic Annotations for WSDL and XML Schema -
IEEE Journals & Magazine.” [Online]. Available:
http://ieeexplore.ieee.org/abstract/document/4376229/. [Accessed: 12-
Dec-2017].
[5] M. Klusch and P. Kapahnke, “Semantic Web Service Selection with
SAWSDL-MX,” in Proceedings of the Second International
Conference on Service Matchmaking and Resource Retrieval in the
Semantic Web - Volume 416, Aachen, Germany, Germany, 2008, pp. 2–
16.
[6] T. Vale, I. Crnkovic, E. S. de Almeida, P. A. da M. Silveira Neto, Y. C.
Cavalcanti, and S. R. de L. Meira, “Twenty-eight years of component-
based software engineering,” J. Syst. Softw., vol. 111, pp. 128–148, Jan.
2016.
[7] A. L. Lemos, F. Daniel, and B. Benatallah, “Web Service Composition:
A Survey of Techniques and Tools,” ACM Comput Surv, vol. 48, no. 3,
p. 33:1–33:41, Dezember 2015.
[8] S. N. Han, G. M. Lee, and N. Crespi, “Semantic Context-Aware
Service Composition for Building Automation System,” IEEE Trans.
Ind. Inform., vol. 10, no. 1, pp. 752–761, Feb. 2014.
[9] R. Al Ali et al., “DEECo: An Ecosystem for Cyber-physical Systems,”
in Companion Proceedings of the 36th International Conference on
Software Engineering, New York, NY, USA, 2014, pp. 610–611.
[10] V. Issarny, G. Bouloukakis, N. Georgantas, and B. Billet, “Revisiting
Service-Oriented Architecture for the IoT: A Middleware Perspective,”
in Service-Oriented Computing, 2016, pp. 3–17.
[11] E. Woods, “Software Architecture in a Changing World,” IEEE Softw.,
vol. 33, no. 6, pp. 94–97, Nov. 2016.
[12] F. Burzlaff and C. Bartelt, “Knowledge-Driven Architecture
Composition: Case-Based Formalization of Integration Knowledge to
Enable Automated Component Coupling,” in 2017 IEEE International
Conference on Software Architecture Workshops (ICSAW), 2017, pp.
108–111.
[13] F. Burzlaff, Knowledge-driven Architecture Composition. Gesellschaft
für Informatik, Bonn, 2017.
[14] “I2S Team: Software.” [Online]. Available:
https://www.dfki.de/~klusch/i2s/html/software.html#sawsdlmx.
[Accessed: 19-Dec-2017].
[15] D. Box et al., Simple object access protocol (SOAP) 1.1. 2000.
[16] M. C. Platenius, W. Schäfer, and S. Arifulina, “MatchBox: A
Framework for Dynamic Configuration of Service Matching
Processes,” in Proceedings of the 18th International ACM SIGSOFT
Symposium on Component-Based Software Engineering, New York,
NY, USA, 2015, pp. 75–84.

Fabian Burzlaff et al. / Procedia CIRP 72 (2018) 707–713 713
6 Fabian Burzlaff et al. / Procedia CIRP 00 (2018) 000–000
4.2. Technical limitations
Smart manufacturing systems are not trivial to build as
different system models have to be connect between and in-
between each other. Realizing such systems requires
professionals with different backgrounds to cooperate. As we
intended to show the feasibility from a software engineering
point of view, we utilized fundamental research results from
the semantic web service community. However, semantic web
service descriptions are not widely used in practice. One reason
for this might be that service provider must execute the service
formalization process in addition to implementing the desired
functionality. In the context of web services, there is no damage
done when two interfaces do not match. By applying semantic
web services to an artificial production scenario, the motivation
for defining semantic interface descriptions correctly increases
as the physical working environment may be negatively
affected. Still, SAWSDL and SAWSDL-MX may rather be
used in the context of coupling an embedded device with a non-
mission-critical communication tasks rather than executing a
production process. In addition, WSDL and its semantic
extension heavily rely on the Simple Object Access Protocol
(SOAP) [15]. Although this protocol is supported by the
official .NET OPC UA implementation 11 , other
communication protocols may be fitting more accurately to its
requirements. Notwithstanding these circumstances, this does
not hinder the conceptual applicability of the proposed
approach.
5. Assessing Automated Web Service Coupling
Approaches for Manufacturing Systems from 1000 feet
When applying the KDAC approach, we have assumed that
all services are accessible by a web communication protocol
(e.g. SOAP over HTTP). Furthermore, these services are
described by the device manufacturer in a suitable language
(e.g. SAWSDL). However, by relying on these predefined
service descriptions the system integration process also
becomes inflexible as an adaptation of the overall integration
may be easier (e.g. changing an ontology or a referenced model
element instead of formalizing an integration rule).
Nonetheless, creating semantic service description for all
possible use case scenarios would result in a high formalization
effort without the guarantee that this effort pays off. As
integration knowledge is automatically reused, services with
minimal interface specification can still be matched and
composed. Evidences supporting this claim are a high diversity
of niche specialist in local manufacturing domains (e.g.
Germany) and the circumstance that industrial manufacturing
is facing high dependability requirements compared to other
industry branches.
One promising solution for reducing the integration effort
would be interface description languages that allow for
incomplete service specifications. Incomplete in this context
means not that service descriptions do expose an invalid
11 http://documentatio n.unified-
automation.com/uasdkdotnet/2.5.5/htm l/L2OpcUaSoftwareLayers.html
syntactic structure but only describe the structure and behavior
of a component for a minimal set of use-cases. This means that
semantic service matcher for web services (e.g. SAWSDL-
MX) or software components (e.g. MatchBox [16]) cannot
support such inferred service compositions as they can only
match what´s described. Nevertheless, using incomplete
service descriptions do rarely produce an exact match and
provide more often a probability score that externalizes the
confidence of an approach using a certain algorithm. Yet, this
probability is hindering a dynamic system evolution.
A possible way to solve this challenge are logic-based
inference methods from the field of artificial intelligence. To
capture integration knowledge efficiently, languages like
OWL-DL were designed to solve semantic data integration
issues. However, they do not respect runtime behavior of
software components or can effectively be used for service
composition. Hence, symbolic languages with a higher
expressiveness to formally calculate (composite) service
semantics may be more suitable. Although available, this raises
not only again the challenge of a high formalization effort for
realizing the integration knowledge base, but also requires
highly-specialized employees.
Nevertheless, we believe that logic-based domain-specific
languages for formalizing integration rules can increase the
usability of this approach to a satisfying level.
5.1. Future Work
As a first step, we plan to modify the language for capturing
integration knowledge. This language should be able to deal
with incomplete service descriptions (i.e. use-case based
formalization) for describing the interface of software
components and inserting integration rules into the knowledge
base.
Next, we plan to evaluate our approach with engineers from
the manufacturing domain. In order to successfully apply this
approach to industrial settings, it must be assessed how much
integration knowledge is needed to 1) automate service
coupling mechanisms and 2) compare our approach to existing
approaches. A comparison metric could be the time to
formalize integration rules or how many unforeseen use cases
can be automatically integrated.
Another question to be answered is how integration
knowledge is managed. On the one hand, this approach requires
enough integration rules for automating service coupling even
for unanticipated integration cases. On the other hand, logical
consistency of multiple knowledge bases must be ensured.
Hence it will be also critical to remove knowledge from the
knowledge base as soon as a suitable standard can be
established (e.g. when integration knowledge is identical and
present in multiple knowledge bases across cooperating
companies).
Fabian Burzlaff et al./ Procedia CIRP 00 (2018) 000–000 7
6. Conclusion
In this paper, we have applied a novel engineering approach
for semantic service integration that allows for (semi-)
automated web service coupling in the context of
manufacturing systems. Therefore, we utilized current
semantic web service interface matchers and outlined
shortcomings of such matcher in the domain of manufacturing
systems and the Industrial Internet of Things and Services.
Next, we evaluated our conceptual architecture composition
approach by extending a semantic service matcher that allows
for specifying domain-specific integration rules. We tested our
prototype in the context of an artificial production site
experimentally. By formalizing integration knowledge for
manufacturing systems in a bottom-up way, the effort spent for
formalizing component interfaces is minimized without
dropping the ability for automated web service coupling. As a
last contribution, we stated several future challenges for
semantic service integration in the context of intelligently
connected manufacturing systems.
By using a knowledge-driven architecture composition
approach, the knowledge gap between new technological
innovations and realizing a domain standard can be closed.
This allows for dynamic system compositions at runtime
without relying on predefined and informal service semantics.
References
[1] J. Lee, B. Bagheri, and H.-A. Kao, “A Cyber-Physical Systems
architecture for Industry 4.0-based manufacturing systems,” Manuf.
Lett., vol. 3, pp. 18–23, Jan. 2015.
[2] U. Döbrich, M. Hankel, R. Heidel, and M. Hoffmeister, Basiswissen
RAMI 4.0: Referenzarchitekturmodell und Industrie 4.0-Komponente
Industrie 4.0. Beuth Verlag, 2017.
[3] H. Lasi, P. Fettke, H.-G. Kemper, T. Feld, and M. Hoffmann, “Industry
4.0,” Bus. Inf. Syst. Eng., vol. 6, no. 4, pp. 239–242, Aug. 2014.
[4] “SAWSDL: Semantic Annotations for WSDL and XML Schema -
IEEE Journals & Magazine.” [Online]. Available:
http://ieeexplore.ieee.org/abstract/document/4376229/. [Accessed: 12-
Dec-2017].
[5] M. Klusch and P. Kapahnke, “Semantic Web Service Selection with
SAWSDL-MX,” in Proceedings of the Second International
Conference on Service Matchmaking and Resource Retrieval in the
Semantic Web - Volume 416, Aachen, Germany, Germany, 2008, pp. 2–
16.
[6] T. Vale, I. Crnkovic, E. S. de Almeida, P. A. da M. Silveira Neto, Y. C.
Cavalcanti, and S. R. de L. Meira, “Twenty-eight years of component-
based software engineering,” J. Syst. Softw., vol. 111, pp. 128–148, Jan.
2016.
[7] A. L. Lemos, F. Daniel, and B. Benatallah, “Web Service Composition:
A Survey of Techniques and Tools,” ACM Comput Surv, vol. 48, no. 3,
p. 33:1–33:41, Dezember 2015.
[8] S. N. Han, G. M. Lee, and N. Crespi, “Semantic Context-Aware
Service Composition for Building Automation System,” IEEE Trans.
Ind. Inform., vol. 10, no. 1, pp. 752–761, Feb. 2014.
[9] R. Al Ali et al., “DEECo: An Ecosystem for Cyber-physical Systems,”
in Companion Proceedings of the 36th International Conference on
Software Engineering, New York, NY, USA, 2014, pp. 610–611.
[10] V. Issarny, G. Bouloukakis, N. Georgantas, and B. Billet, “Revisiting
Service-Oriented Architecture for the IoT: A Middleware Perspective,”
in Service-Oriented Computing, 2016, pp. 3–17.
[11] E. Woods, “Software Architecture in a Changing World,” IEEE Softw.,
vol. 33, no. 6, pp. 94–97, Nov. 2016.
[12] F. Burzlaff and C. Bartelt, “Knowledge-Driven Architecture
Composition: Case-Based Formalization of Integration Knowledge to
Enable Automated Component Coupling,” in 2017 IEEE International
Conference on Software Architecture Workshops (ICSAW), 2017, pp.
108–111.
[13] F. Burzlaff, Knowledge-driven Architecture Composition. Gesellschaft
für Informatik, Bonn, 2017.
[14] “I2S Team: Software.” [Online]. Available:
https://www.dfki.de/~klusch/i2s/html/software.html#sawsdlmx.
[Accessed: 19-Dec-2017].
[15] D. Box et al., Simple object access protocol (SOAP) 1.1. 2000.
[16] M. C. Platenius, W. Schäfer, and S. Arifulina, “MatchBox: A
Framework for Dynamic Configuration of Service Matching
Processes,” in Proceedings of the 18th International ACM SIGSOFT
Symposium on Component-Based Software Engineering, New York,
NY, USA, 2015, pp. 75–84.