Adapting an Agile Manufacturing Concept to the Reference Architecture Model Industry 4.0: a survey and case study

Abstract

Industry 4.0 architecture has been studied in a large number of publications in the fields of Industrial Internet of Things, Cyber Physical Production Systems, Enterprise Architectures, Enterprise Integration and Cloud Manufacturing. A large number of architectures have been proposed, but none of them has been adopted by a large number of research groups. Two major Industry 4.0 reference architectures have been developed by industry-driven initiatives, namely the German Industry 4.0 and the US-led Industrial Internet Consortium. These are the Reference Architecture Model Industry 4.0 and Industrial Internet Reference Architecture, which are being standardized by the International Electrotechnical Commission and the Object Management Group, respectively. The first research goal of this article is to survey the literature on Industry 4.0 architectures in a factory context and assess awareness and compatibility with Reference Architecture Model Industry 4.0 and Industrial Internet Reference Architecture. The second research goal is to adapt a previously proposed advanced manufacturing concept to Reference Architecture Model Industry 4.0. With respect to the first research goal, it was discovered that only a minority of researchers were aware of the said reference architectures and that in general authors offered no discussion about the compatibility of their proposals with any internationally standardized reference architecture for Industry 4.0. With respect to the second research goal, it was discovered that Reference Architecture Model Industry 4.0 was mature with respect to communication and information sharing in the scope of the connected world, that further standardization enabling interoperability of different vendors’ technology is still under development and that technology standardization enabling executable business processes between networked enterprises was lacking.

Full text

Adapting an Agile Manufacturing Concept to the Reference
Architecture Model Industry 4.0
Matti Yli-Ojanperä, Seppo Sierla, Nikolaos Papakonstantinou, Valeriy Vyatkin
Abstract
Industry 4.0 architecture has been studied in a large number of publications in the fields of Industrial
Internet of Things, Cyber Physical Production Systems, Enterprise Architectures, Enterprise Integration
and Cloud Manufacturing. A large number of architectures have been proposed, but none of them has
been adopted by a large number of research groups. Two major Industry 4.0 reference architectures
have been developed by industry-driven initiatives, namely Plattform Industrie 4.0 and the Industrial
Internet Consortium. These are the Reference Architecture Model Industry 4.0 and Industrial Internet
Reference Architecture, which are being standardized by the International Electrotechnical Commission
and the Object Management Group, respectively. The first research goal of this article is to survey the
literature on Industry 4.0 architectures in a factory context and assess awareness and compatibility with
Reference Architecture Model Industry 4.0 and Industrial Internet Reference Architecture. The second
research goal is to adapt a previously proposed advanced manufacturing concept to Reference
Architecture Model Industry 4.0. With respect to the first research goal, it was discovered that only a
minority of researchers were aware of the said reference architectures and that in general authors
offered no discussion about the compatibility of their proposals with any internationally standardized
reference architecture for Industry 4.0. With respect to the second research goal, it was discovered that
Reference Architecture Model Industry 4.0 was mature with respect to communication and information
sharing in the scope of the connected world, that further standardization enabling interoperability of
different vendors’ technology is still under development and that technology standardization enabling
executable business processes between networked enterprises was lacking.
Keywords: Industry 4.0, RAMI 4.0, Reference architecture, OPC UA, Industrial Internet of Things, Cyber-
Physical Production Systems
1 Introduction
Industry 4.0 is expected to revolutionize, dissolve or flatten the automation pyramid architecture that
has been established for several decades in the manufacturing industry [1,2,3,4,5,6,7,8,9,10]. This raises
the question that what will be the new architecture to underpin Industry 4.0. A thorough survey of the
scientific literature in Industry 4.0 identifies five paradigms that are being applied: Internet of Things
(IoT), Cyber Physical System (CPS), Information and Communications Technology (ICT), Enterprise
Architecture (EA), and Enterprise Integration (EI) [11]. The reader may get the impression that the
Industry 4.0 Working Group did not define an architecture, since no such architecture emerged from
studying the surveyed works. However, a Reference Architecture Model Industry 4.0 (RAMI 4.0) has

been developed by BITCOM (the German Association for IT, Telecommunications and New Media),
VDMA (Mechanical Engineering Industry Association) and ZWEI (German Electrical and Electronic
Manufacturers' Association) [12]. Since Germany is recognized as the leader for Industry 4.0 in Europe
[13], it is to be expected that this architecture will become broadly established in the industry, at least in
Europe. International standardization of various aspects of RAMI 4.0 relies on the IEC (International
Electrotechnical Commission) [12]. Another major reference architecture is the Industrial Internet
Reference Architecture (IIRA) developed by the US-led Industrial Internet Consortium (IIC), which is
globally the main driver behind worldwide adoption of IIoT (Industrial IoT). IIRA standardization relies on
the OMG (Object Management Group). An architecture alignment effort between RAMI 4.0 and IIRA is
also underway [14].
Notable Industry 4.0 activity outside Germany and the US include initiatives in Japan, China, Korea and
the UK. The Japanese manufacturing industry’s IVI (Industrial Value Chain Initiative) [15,16] has defined
the IVRA (Industrial Value Chain Reference Architecture); loose coupling between IVRA and RAMI 4.0 is
presented in [17]. Unlike the German and Japanese Industry 4.0 efforts aiming at keeping or reshoring
manufacturing jobs, the Chinese “Made-in-China 2025” plan aims to transition China from a low-wage
manufacturing country to a technology leader [18] The Chinese have defined their own Intelligent
Manufacturing System Architecture (IMSA) [19]; however, the country is very open to adopt German
Industry 4.0 technology [3]. Currently RAMI 4.0 and IMSA are mutually recognized and alignment work
has been undertaken [20]. South Korea is making a coordinated effort involving the technology, political,
social and economic sectors [21,22]. The government led Manufacturing 3.0 project and Smart Factory
Initiative can be seen as counterparts to the German Industry 4.0; however, since Korea’s industrial
focus is not on factory equipment or automation technology, there is openness to cooperate with and
adopt technology from Germany, including RAMI 4.0 [3]. While the Industry 4.0 focus in Germany has a
strong technology focus, the UK is recognized as a leader of the smart services aspect of Industry 4.0
[3,23]. Thus, the UK has been identified as a strong candidate for RAMI 4.0 adoption, especially due to
the collaboration between the British Standards Institution (BSI) and the German Institute for
Standardization (DIN) [3]. Common shared key characteristics between RAMI 4.0, IIRA, IVRA and IMSA
include:
1. dissolution of the automation pyramid
2. a communication solution that makes data available to all parties in real time
3. the addition of a dimension that captures the lifecycle of the product and production facility
4. assets such as products and production resources have cyber counterparts
Many industrialized nations are not striving to be leaders in Industry 4.0, and their preparedness to
adopt this technology is an important area of research. There are several possible perspectives to such
research, depending on the current technological and economic situation in a particular country. In
Brazil, [24] identified a subset of Industry 4.0 technology that the local industry is currently ready to
adopt. A survey to members of the New Zealand Manufacturers and Exporters Association explored the
general awareness of Industry 4.0 and perceived benefits, challenges and obstacles related to it [25].
Using India as their case, [26,27] have studied the possibility to adopt Industry 4.0 technology in a
country which has not yet properly exploited the Industry 3.0 technology, namely computer-integrated
manufacturing. [28] describe a Columbian education modernization effort to teach the practical skills
required from engineers working in an Industry 4.0 environment. However, none of these works
demonstrates explicit awareness for RAMI 4.0, IIRA or any other architecture with similar scope, so for

now the dominance of one or more reference architectures, the related standards and the standard
compliant products and services is being established in the nations that are leading the Industry 4.0
revolution.
Due to the business power of the organizations behind RAMI 4.0 and IIRA, it is foreseeable that these
architectures will gain extensive traction in the industry, so the academic community will face great
difficulty in attempting the technology transfer of architectures that have been developed without
explicit regard to RAMI 4.0 or IIRA. Based on recent surveys that were made several years after the
publication of these reference architectures, the large majority of the published literature is ignoring or
unaware of them, while numerous paradigms such as IoT, CPS, CPPS (Cyber Physical Production
Systems), EA, EI and Cloud Manufacturing (CM) are being studied by different communities of
researchers [11,29]. In fact, RAMI 4.0 and IIRA could be considered to follow several or even all of the
above mentioned paradigms, but the reverse does not hold: Industry 4.0 architectures inspired by these
paradigms will not necessarily be compatible with RAMI 4.0 or IIRA. Thus, our first research goal is as
follows:
RG1: to survey the literature on architectures proposed under the paradigms of IIoT, CPPS, EA, EI
and CM in a factory context and assess their awareness and compatibility with RAMI 4.0 or IIRA.
Any innovative manufacturing concepts will face an adoption barrier if they have not been developed
and demonstrated on an industrially accepted reference architecture. However, it is currently difficult
for researchers to avoid this situation. The body of scientific literature on Industry 4.0 remains ‘non-
consensual or ill defined’ according to a recent survey [29]. More research is needed, which explicitly
applies one of these reference architectures to a proposed Industry 4.0 manufacturing concept. Readers
need to understand what kind of alignment of concepts and application of IT standards was involved.
Additionally, a proof of concept will clarify any implementation issues, since Industry 4.0 technology and
standards are evolving, and it will enable readers to gain the technical understanding needed to apply
the lessons learned to their own applications. To this end, our second research goal is to apply one of
these reference architectures to a previously proposed agile manufacturing method:
RG2: in previous work, a system for concurrent product design and assembly planning was
proposed in a networked enterprises context, but the proof-of-concept was a single Java
application [30]. In this paper, applications of RAMI 4.0 concepts and technologies to this system
are demonstrated.
2 Related research
In this section, research about Industry 4.0 architecture is reviewed. The review is grouped under the
following categories: IIoT, CPPS, EA, EI and CM. Articles not mentioning these keywords will also be
considered, for example an article about CPS in factory automation will be considered relevant even if
the keywords Industry 4.0 and CPPS are not used. As per RG1, each of the reviewed papers is reviewed
for awareness and compatibility with RAMI 4.0 or IIRA.
2.1 Industrial IoT
A disruptive development in Industry 4.0 and IIC’s IIoT is the real-time availability of data to all users in
the connected world. The RAMI 4.0 standard technology for this is OPC UA (Open Platform
Communications Unified Architecture) and its counterpart in IIRA is DDS (Data Distribution Service).

These will be discussed in more detail later in the paper, but it is notable that the major part of
academic research on these technologies ignores these industry driven initiatives, the fact that IIC is
trying to appropriate the IIoT name, and that OPC UA has been developed by the archrivals of the
industry consortium behind IIoT. A few examples are as follows: [31] proposes an IIoT architecture
based on OPC UA. [32] proposes the Industrial Internet-of-Things Hub (IIhub) - OPC UA and DDS are
mentioned but not used. IIhub covers part of the scope of RAMI 4.0 or IIRA, which are not mentioned.
[33] evaluates the OPC UA as a core communication technology for IIoT frameworks.
Irrespective of the IIC, the academic community has done significant work on IIoT architecture.
However, this work lacks coordination and researchers are not in agreement about how many layers the
architecture should have and what are the names and functionality at each layer [34]. Several important
aspects of IIoT architecture have been developed, but IIRA is not recognized and there is a lack of a
common reference architecture to integrate these works. A few notable examples are as follows. [35]
proposes an analysis framework for IIoT devices and a classification schema. [36] proposes an IIoT-based
framework, which supports the definition, commissioning and operation phases of services in IPSSs
(Industrial Product-Service Systems) for manufacturing environments. The impact of IIoT on business
models for manufacturing companies is evaluated in [37]. The IIoT-related experiences of 76 companies
help establish a framework with the key business model elements for the Industry 4.0 era – however,
the support for business process automation in RAMI 4.0 and IIRA is not considered.
The lack of an established IIoT reference architecture has resulted in application developers being forced
to develop home-grown solutions to common tasks that would ideally be addressed by standards-based
technologies in the IIRA framework, which explicitly supports manufacturing and a number of other
domains such as healthcare. Examples are as follows. [38] explores IIoT applications enabling product
quality monitoring and providing data on machine utilization, condition monitoring and power usage.
These applications are based on an IIoT-enabled machine-to-machine network using a stochastic
embedding approach and parallel computing. [39] focuses on health monitoring applications of IIoT and
defines a Healthcare IIoT (HealthIIoT) framework. Health-related data are collected by mobile devices
and sent securely over the cloud to health professionals. [40] focusses on the advantages of low-latency
5G communication IIoT networks for covering the data transfer rate, data reliability and time-sensitive
requirements of cyber-physical manufacturing systems (CPMS).
2.2 Cyber-Physical Production Systems
A central problem in CPS in a factory context is the standardization of data collection. Several authors
propose web ontology language (OWL) ontologies for purposes including prognostics [41], decision
support [42], digital twins [43], flawed data management [44], autonomous decision making for
intelligent machines [45], open-knowledge-driven manufacturing execution systems [46], automating
the engineering of batch process plants [47] and feeding data from the production process to the
product design process [48]. This is in contrast to the RAMI 4.0 approach, in which an OPC UA address
space would be defined and standardized as a companion specification [49]. [43] mentions RAMI 4.0 but
does not recognize the role of OPC UA or describe in any detail how the proposed approach would
comply with RAMI 4.0. Otherwise, the said authors do not mention RAMI 4.0, IIRA, IVRA or IMSA and
thus they do not reflect on the implications of not following these architectures.
Numerous research groups have produced proposals for CPPS architecture. [50] proposes CPPS
architecture design through 3 viewpoints: Implementation, functional and operational. [51] proposes a

5-layer architecture for CPS-based Industry 4.0 manufacturing systems. Based on an extensive CPPS
literature review, [52] propose a Five-layer configuration architecture (Cognition-Configuration-
Connection-Conversion-Computation). [53] proposes a multi-agent system architecture for CPPS with
self-organizing and self-adaptive capabilities. Most CPPS architectures do not have an explicit lifecycle
dimension as in RAMI 4.0, but the digital-twin shop-floor proposed in [54] is an exception in this regard.
None of these architectures has any obvious mapping to RAMI 4.0, IIRA, IVRA or IMSA, and although the
authors do not mention these reference architectures, the proposed architectures could be considered
to cover a subset of the scope of these industry reference architectures. In contrast, the anthropocentric
cyber-physical system (ACPS) reference model for factory automation [55] and the framework for
operative and social sustainability functionalities in Human-Centric CPPSs proposed in [56] are
fundamentally different from the said reference architectures due to the prominent human dimension.
[2] demonstrate full awareness of the role of RAMI 4.0 and OPC UA, but a lack of awareness of Industry
4.0 Component Model, a key aspect RAMI 4.0 [12,49], so they propose a novel proprietary model
vueOne to accomplish a similar purpose. Finally, [57] presents an expert discussion on how the CPPS
concepts are mapped to RAMI 4.0 and how the industry is gradually migrating to this architecture.
Although IIRA has not been explicitly mentioned in any of the reviewed CPPS architecture related
publications, its key technology standard DDS (Data Distribution Service) has been incorporated to some
proposals. [58] proposes a CPPS architecture based on distributed databases using DDS as the
communication solution; further works that assess and endorse DDS as the CPPS communication
solution include [59,60]. Although IIRA is not mentioned in any of these scientific articles, DDS occupies
a central place in IIRA similar to OPC UA in RAMI 4.0. However, the industry commitments to OPC UA
and DDS by Plattform Industrie 4.0 and IIC, respectively, are such that the RAMI 4.0 and IIRA
architecture alignment working group suggests that both could be deployed to the same devices [14].
[61] performs a comparative evaluation of OPC UA and DDS after recognizing their roles in RAMI 4.0 and
the US driven Industrial Internet (without mentioning IIRA).
2.3 Enterprise Architecture and Enterprise Integration
The top layers of RAMI 4.0 architecture, the ‘business’ and ‘functional’ layers, are expected to provide
standard runtimes for executable business processes in the connected world [12], but so far there is a
lack of standardization to this direction. In the area of enterprise architecture and enterprise application
integration, much work on similar topics has already been done before Industry 4.0 related to platforms
for eCommerce. These works could be categorized to web services-based approaches [62,63] and
various competing XML schema-based standards such as universal business language (UBL), Open
Applications Group Integration Specification (OAGIS), eXtensible Business Reporting Language (XBRL),
XML Common Business Library (xCBL) and commerce eXtensible Markup Language (cXML)
[64,65,66,67,68,69,70,71].
Only a minority of work in EA and EI explicitly mention Industry 4.0. [72,73,74] argue how EA meets the
requirements of Industry 4.0 without proposing how traditional EA approaches could be extended to
plant floor devices and automation systems. This trend of EA researchers to make claims in the area of
Industry 4.0 while overlooking challenges resulting from integrating physical systems is identified and
criticized by [35]. In contrast, [75] describe proprietary solutions for integrating EA to embedded
systems, but acknowledge the lack of standardization in this area. [76] argues how properly designed EA
can exploit the ability of expert workers to assess situations and make decisions, a concern that is

central to Industry 4.0 although not obviously addressed by RAMI 4.0. EA research on Industry 4.0 may
also clearly violate RAMI 4.0; for example [77] proposes extensions to the automation pyramid. None of
the reviewed works on EA and EI demonstrate awareness on RAMI 4.0. Research on the ‘business’ layer
of RAMI 4.0 is nearly non-existent and not affiliated with the entities involved in RAMI 4.0
standardization; [78] positions itself on the ‘business’ layer, but due to the lack of RAMI 4.0-specific
technology standardization, resorts to using Business Process Modeling and Notation (BPMN) as will be
done also in this article.
2.4 Cloud Manufacturing
The Cloud manufacturing concept was first proposed by [79] as a new manufacturing paradigm based on
IIoT and advanced computing technologies. The main feature is the transformation of manufacturing
resources and capabilities to services. A recent survey [80] does not mention RAMI 4.0, IIRA, OPC UA or
DDS. Another recent survey [81] details the CM’s community’s original work on definitions,
architectures, characteristics and previous case studies. [82] and [83] consider interoperability as a
significant challenge for CM. [83] explicitly recognizes IIRA and RAMI 4.0 as standards-based solutions to
this problem while [82] proposes an original service-oriented, interoperable cloud manufacturing
system.
Several CM applications have been proposed, in which authors either propose original architectures or
ignore architectural aspects. [84] proposes an architecture to support holistic quality assurance services.
[85] and [86] propose cloud manufacturing-based scheduling services for dynamic collaborative
manufacturing environments. [87] proposes a reliability assessment model of CM systems, assuming a
service oriented architecture that is not specified in more detail. Agent-based manufacturing methods
have been adapted to the cloud, aiming at advantages in virtual manufacturing cell formation [88] and
improved performance in energy consumption, scheduling, resource allocation and real time data
collection [89]. [90] propose a distributed blockchain-based architecture to handle the trust and security
issues in a scalable manner. None of these works mention RAMI 4.0, IIRA, OPC UA or DDS, and authors
do not offer any discussion about whether their proposal would be applicable in the context of such
established reference architectures.
2.5 RAMI 4.0 specific work
This section concludes the literature review with a discussion of notable bodies of literature not related
to IIoT, CPPS, EI, EA and CM. Over two hundred articles on OPC UA have been published by the IEEE,
mainly in conferences of the Industrial Electronics Society. These include works on key Industry 4.0
architecture aspects such as service orientation for the industry [91], migration support for legacy
systems [92,93,94], cloud manufacturing [95,96] and plug-and-play of components into a CPPS [97]. In
addition to OPC UA, another key standard for RAMI 4.0 is the Industry 4.0 Component Model, which
defines an administration shell for each component, permitting the interoperability of technology from
different vendors. This standard is still in the early phases, but the concept has recently been used by
several research groups to support their innovative Industry 4.0 proposals (e.g. [98,99,100]).
3 System concept
In this section, RG2 is addressed. In [30], a system and method for concurrent product design and
assembly planning was proposed. While the research was motivated by a scenario involving several
organizations, the UML (Unified Modeling Language) descriptions of the proposed system and method,

as well as the implementation as a single Java project, require further work on how the method could be
applied across organizational boundaries. This is the first step towards addressing RG2, and an overview
is presented in Figure 1.
Figure 1 Concurrent product design and assembly planning in a networked enterprises concept
The next step towards addressing RG2 is identifying how the procedure in Figure 1 can be mapped to
RAMI 4.0. Figure 2 shows the 6-layer RAMI 4.0. The layers that this article focusses on are highlighted in
orange. The procedure in Figure 1 crosses the hierarchy levels “Enterprise” and “Connected world”. The
steps 1-6 in Figure 1 belong to the “Development (Type)” phase of the RAMI 4.0 product life cycle, since
they are done entirely in simulation and aim at improving the product design from the product assembly
perspective. Step 7 in Figure 1 marks the transition to the “Production (Instance)” phase of the RAMI 4.0
product life cycle.

Figure 2 Reference Architecture Model Industry 4.0 adapted from [12]. This article focusses on the layers that are highlighted in
orange.
The next step towards addressing RG2 is identifying how the procedure in Figure 1 can be split between
the RAMI 4.0 layers. In the business layer, the business processes are defined and especially links
between business processes in different organizations are established [12]. This has been done with
BPMN (Business Process Model and Notation) in Figure 3. As opposed to Figure 1, in which the
procedure is illustrated with three manufacturer candidates, Figure 3 shows only one manufacturer
candidate, to reduce clutter. An arbitrary number of candidates is possible, and identical communication
is conducted with each candidate. This diagram shows the key aspects of the process and further work
may focus on details such as negotiation for price, lead time and throughput. The horizontal sections are
pools, not swimlanes, meaning that they cross organizational boundaries, in which case messages
(dotted arrow) are sent. In terms of RAMI 4.0 hierarchy levels, each pool is at the “Enterprise” level, and
the entire BPMN is at the “Connected world” level. From left to right, the progression in Figure 3
corresponds to the Value Stream dimension of RAMI 4.0 as follows. The Virtual assembly corresponds to
RAMI 4.0 Development (Type). Physical assembly corresponds to RAMI 4.0 Production (Instance).

Figure 3 Business processes defined on the "Business" layer of RAMI 4.0
The next step of addressing RG2 is to refine the business process in Figure 3 to the other layers of the
RAMI 4.0 in a general way that avoids proprietary solutions. Looking at Figure 2 and moving down from
the “Business” layer, next is the “Functional” layer. The functions that comprise the business processes
are formalized on this layer, so that they can be executed on a runtime that enables horizontal
integration of the functions across organizations and organizational units [12]. However, at the time of
writing this article, this layer of RAMI 4.0 is not yet mature, so this layer shall be addressed in further
research. Moving down one layer brings us to the “Information” layer. Here the content of the
information to be exchanged is defined in a machine readable and non-proprietary way. The
standardized technology for this purpose is OPC UA (Open Platform Communications Unified
Architecture), and especially its mechanism for defining address spaces [49]. In this article, the relevant
information content is the digital product description, for which an OPC UA address space will be
defined below. The next layer is the ‘Communication’ layer that allows any entities to exchange the
necessary information in real time. In this article, the communication between the OEM and
manufacturers (step 1 in Figure 1) is implemented as OPC UA client-server communication. At the time
of writing, OPC UA is the only technology available for realizing the ‘Communication’ layer [49].
In this article, the two lowest layers of RAMI 4.0 were not addressed, since the scope of this research is
to apply the manufacturing concept in [30] in a simulation environment without addressing all the
details related to integrating technology from several vendors. These details should be addressed on the
“Integation layer”. The application of OPC UA is a partial solution to this problem, but the application of
the Industry 4.0 standard Component Model is also required [49]. This is an important area of further
research.
In the remainder of this section, RG2 will be addressed in more detail regarding the development of an
OPC UA address space on the “Information layer”. Figure 4 shows the OPC UA reference type hierarchy
and our extensions to it in orange. With these reference types, it is possible for the OEM to construct
the kind of digital product description used by the agile production cell proposed in [30], capable of
performing automatic assembly planning based on this description. This capability depends on part
types such as CAD models being augmented with coordinates of connection points as well as
connections between connection points of two parts to be assembled. The two orange reference types
in Figure 4 are used for this purpose.

Figure 4 Extensions to OPC UA reference type hierarchy. Extensions are in orange. Adapted from [101]
Figure 5 shows the OPC UA address space that was defined. [30] presents an automatic assembly
planning capacity for digital product descriptions consisting either of CAD parts or of lego blocks. In case
of CAD parts, the capacity is mainly relevant for parts that can be assembled in top-down fashion. The
industrial applicability for the research with lego blocks was limited to certain toy manufacturers, but
certain ambitious research ideas could be demonstrated with these simple part types. In particular, with
30 square or rectangle lego blocks, a virtually unlimited number of assemblies can be defined, and the
method in [30] was able to perform automatic assembly planning for a large subset of them, including
collision detection and connecting a part to the assembly from below.
This idea of defining digital product descriptions from CAD components and lego blocks is formalized in
Figure 5. The product is an instance of “DigitalTwinType” defined in the top right corner, i.e. the
“DigitalTwin” object. This name is due to the concept proposed in [30], in which a digital twin is
generated from the digital product description. The twin then orchestrates the production resources to
manufacture product, in which case the control software of the production resources does not have any
hardcoded logic about what kind of product is being assembled, resulting in a highly versatile assembly
cell. The twin consists of several parts in a folder called “Parts”. At this point, especially readers with
background in UML should appreciate that in an OPC UA address space, type and instance definitions
are mixed, so Figure 5 should not be read as an UML class diagram consisting of type definitions only.
The content of the “Parts” folder is specific to the digital product description of a specific product, while
the rest of Figure 5 is a general framework that can be used to define any product instance consisting of
the said part types: CAD parts, square lego blocks and rectangle lego blocks. To reduce clutter, the
diagram omits the rectangle lego type definitions and subtype definitions of “CadPartType”.

Figure 5 OPC UA address space defined using reference types in Figure 4
The final step in addressing RG2 is to actually define a digital product description in the OPC UA server
address space. To reduce clutter in Figure 5, only one “DigitalTwin” object is defined, so only one digital
product description is present on the server. In the “Parts” folder, only one “SquareLego” object is
included. Figure 6 shows an excerpt of an OPC UA address space that complements Figure 5 with the
one digital product description. To keep the diagram readable, the product is very simple: a lego tower
consisting of four square lego blocks one on top of each other. However, more complex products have
been defined and will be discussed further in the remainder of this section.

Figure 6 Excerpt of an OPC UA address space related to one digital product description
4 Implementation
4.1 Server side
The OPC UA server side corresponds to the ‘OEM’ in Figure 1 and Figure 3.
The concept in section 3 was implemented with Prosys OPC UA Java SDK 3.1.2 client-server. First, our
custom reference types shown in Figure 4 and our custom object types in Figure 5 are defined in XML
according to the XML schema http://opcfoundation.org/UA/2011/03/UANodeSet.xsd defined by OPC
Foundation. The following snippet shows the definition for “HasConnectionPoint” in Figure 4.
<UAReferenceType NodeId="ns=1;i=97" BrowseName="HasConnectionPoint">
<DisplayName>HasConnectionPoint</DisplayName>
<Description>The type for reference from node to its connection point.
</Description>
<References>
<Reference ReferenceType="HasSubtype" IsForward="false">i=47</Reference>
</References>
<InverseName>ConnectionPointOf</InverseName>
</UAReferenceType>
The reference is a subtype of the reference with alias 47, which according to the following snippet is
“HasComponent”. Accordingly in Figure 4, “HasConnectionPoint” is a subtype of “HasComponent”.

<Alias Alias="HasComponent">i=47</Alias>
The following snippet is an example of a new object type definition:
<UAObjectType NodeId="ns=1;i=10" BrowseName="CadPartType">
<DisplayName>CadPartType</DisplayName>
<References>
<Reference ReferenceType="HasSubtype" IsForward="false">ns=1;i=102</Reference>
<Reference ReferenceType="HasComponent">ns=1;i=10201</Reference>
<Reference ReferenceType="HasProperty">ns=1;i=10202</Reference>
<Reference ReferenceType="HasProperty">ns=1;i=10301</Reference>
<Reference ReferenceType="HasProperty">ns=1;i=10203</Reference>
<Reference ReferenceType="HasProperty">ns=1;i=11</Reference>
</References>
</UAObjectType>
This specifies that “CadPartType” is a subtype of the node with node id “ns=1;i=102”. According to
Figure 5, “CadPartType” is a subtype of “DigitalPartType”. From the following snippet it can be
confirmed that the node id of “DigitalPartType” is indeed “ns=1;i=102”.
<UAObjectType NodeId="ns=1;i=102" BrowseName="DigitalPartType">
The full XML file containing the definitions is 1400 lines. A code generator included in the Prosys OPC
SDK was used to generate Java source code for classes corresponding to our custom defined reference
and object types. On the OPC server side Java code, digital product specifications are now created.
Below is a snippet for a function createProduct0() which creates a lego tower. A subassembly of the lego
tower consists of 4 yellow square legos stacked on top of each other, as in Figure 6. The snippet below
includes only the code for creating this subassembly. The comments in the snippet identify 4 steps,
which accomplish the following:
1. An object of DigitalTwinType is created corresponding to the yellow “DigitalTwin” box in Figure
5 and the yellow “LegoTower” box in Figure 6. This node as well as a reference to the address
space’s top level folder “objectsFolder” is added to the address space. The DigitalTwinType class
that was automatically created from the XML is utilized here.
2. For objects of SquareLegoType are created, corresponding to the yellow “SquareLego” boxes in
Figure 6. As can be seen in Figure 6, each of these objects has a variable “Color”. The
automatically generated Java code has a setter method “setColor()” for this variable, which is
used to assign the value of the variable. Finally, the objects are stored in a hashmap for step 3.
3. As can be seen in Figure 6, the “top” connection point of one lego is connected to the “bottom”
connection point of the lego above it using our custom defined reference type “HasConnection”.
The first two lines of Java code retrieve these connection point objects. The third line creates
the reference of type “HasConnection” between the connection points.
protected void createProduct0() throws StatusException, ServiceException {
// step 1
final NodeId digitalTwinId = new NodeId(namespaceIndex, 20);
DigitalTwinType digitalTwin = createInstance(DigitalTwinType.class, "lego.txt", digitalTwinId);
addNodeAndReference(objectsFolder, digitalTwin, Identifiers.Organizes);
// step 2
Map<String, SquareLegoType> squares = new HashMap<String, SquareLegoType>();
for (int i = 0; i < 4; i++) {

final NodeId legoSquareId = new NodeId(getNamespaceIndex(), UUID.randomUUID());
SquareLegoType squareLego = createInstance(SquareLegoType.class, "Square"+(1+i),
legoSquareId);
squareLego.setColor("yellow");
addNodeAndReference(digitalTwin.getDigitalPartsNode(), squareLego, Identifiers.HasComponent);
squares.put("Square" + (1 + i), squareLego);
}
for (int i = 1; i < 4; i++) {
UaNode sourceNode = squares.get("Square" + i).getBottomNode();
UaNode targetNode = squares.get("Square" + (1 + i)).getTopNode();
addReference(sourceNode, targetNode, hasConnectionId, false);
}
}
4.2 Client side
The OPC UA client side corresponds to the ‘Manufacturer’ in Figure 1 and Figure 3. In Figure 3, there is a
message line from the OEM’s activity ‘Develop and send digital product description’ to the
Manufacturer’s ‘Perform virtual assembly’ activity. How this is implemented with OPC UA will be
elaborated in this section. It is assumed that the Manufacturer knows the OPC UA node id of the digital
twin object (e.g. the yellow box ‘LegoTower’ in the simple product description in Figure 6). When the
technology standardization of the Functional layer of RAMI 4.0 (see Figure 2) is more mature, executable
business processes at this level could communicate this node id across organizations. In our proof-of-
concept, the node id is simply given as input to the client side software. After connecting to the server,
the client retrieves the digital twin object using the said id (‘digitalTwinId’ in the following snippet).
Then, using the getter methods that were autogenerated from our XML descriptions, all of the parts in
the ‘Parts’ folder are retrieved and added to a list. An explicit type casting from ‘UaNode’ to
‘DigitalPartType’ node is then performed; the class definition for ‘DigitalPartType’ was autogenerated
from our XML descriptions and corresponds to the green box ‘DigitalPartType’ in Figure 5.
List<DigitalPartType> parts = new ArrayList<DigitalPartType>();
DigitalTwinType digitalTwin = (DigitalTwinType) client.getAddressSpace().getNode(digitalTwinId);
UaNode partsNode = digitalTwin.getDigitalPartsNode();
UaNode[] nodes = partsNode.getComponents();
for (UaNode node : nodes) {
parts.add((DigitalPartType) node);
}
Next, for each part, the connection points are obtained. The following snippet assumes that the node id
of the reference type ‘hasConnectionPoint’ (see Figure 4 and Figure 5) has been previously obtained
from the server and stored in ‘hasConnectionPointId’. The first line in the snippet gets all the references
of this type pointing from this part to some other object. The second line creates an array of type
‘CoordinateType’ (this type being autogenerated from the XML specifications corresponding to Figure
5). The number of elements in this array is the number of references that were obtained by the first line
of code. The for loop gets the target node of each reference, i.e. a connection point, and stores that in
the array.
UaReference[] refs = part.getForwardReferences(hasConnectionPointId);
CoordinateType[] connectionPoints = new CoordinateType[refs.length];
for(int i=0; i<refs.length; i++) {
connectionPoints[i] = (CoordinateType) refs[i].getTargetNode();
}

Next, the connection points are examined in order to find the connections between point. The node id
of the reference type ‘hasConnection’ (see Figure 4) has been previously obtained from the server and
stored in ‘hasConnectionId’. Figure 6 shows some examples of this this type of reference is used to link
connection points of two parts. The snippet below loops through all of the connection points obtained
from the previous snippet and looks for references of type ‘hasConnection’. The methodology in [30]
does not specify any direction to the connections, but OPC UA requires that all references have a
direction, thus the loop looks for forward as well as inverse references.
Set<UaReference> connections = new HashSet<UaReference>();
for(CoordinateType connectionPoint : connectionPoints) {
UaReference forwardConnection = connectionPoint.getReference(hasConnectionId, false);
if(forwardConnection != null) {
connections.add(forwardConnection);
}
UaReference inverseConnection = connectionPoint.getReference(hasConnectionId, true);
if(inverseConnection != null) {
connections.add(inverseConnection);
}
}
Naturally, these snippets are a very minor part of the code. Based on these examples, a computer
science expert who consults the documentation of the OPC UA SDK should be able to develop
applications that exchange digital product descriptions across organizational boundaries, either
according to the address space proposed in section 3 or some other user defined address space. The
server side and client side software is deployed in different applications that may be run on the local
host for testing purposes or on different machines anywhere in the Internet as long as the firewall
settings allow the client to connect to the server. Once the digital product description data is exchanged,
the system developed in [30] is used to perform the virtual and physical assembly and to complete the
proof-of-concept.
5 Results
First, the server side application is run. After the server is running, before starting the client, it is possible
to browse the server address space with a visual third party tool to ensure that the expected
information is present. This is also a good way to check that the implementation indeed conforms to the
OPC UA standard and is accessible to any client side application, not only the one that was developed by
the authors. The free UaExpert tool was used for this purpose. The tool is available from:
https://www.unified-automation.com/products/development-tools/uaexpert.html
Figure 7 shows a screenshot from UaExpert after the server has been connected. In the ‘Address Space’
pane on the left, one can see the ‘Objects’ folder, which is the top level folder of the server’s address
space. In the folder, that are two object of type ‘DigitalTwin’: ‘lego tower’ and ‘cranfield’. The former is a
more complex version of the example in Figure 6. The latter is the Cranfield assembly benchmark [102]
consisting of 6 different types of CAD components. The ‘Parts’ folder of ‘lego tower’ is open. In it, the
details of the part ‘Square1’ are open. The ‘Color’ variable has been dragged to the ‘Data Access View’
pane, in which the value pink can be read and modified.

Figure 7 Browsing the server with UaExpert
Figure 8 shows a sequence of screenshots from the virtual assembly of the Cranfield assembly
benchmark, clockwise starting from top left. On the top left, an assembly station with the parts and a
Cartesian robot with an additional two rotting joints is ready to begin the virtual assembly. The
remaining screenshots show how, based solely on the digital product description information from the
OPC UA server, the method from [30] is able to perform the assembly with correct assembly sequence
planning, inserting the green shaft to the center before the yellow pendulum (top right), and inserting
all the green bolts before the top faceplace (bottom right).

Figure 8 Sequence of screenshots from the virtual assembly of the Cranfield benchmark: clockwise starting from top-left
6 Conclusion
6.1 Research goal 1
Regarding RG1, the literature review in section 2 revealed a worrisome disconnection between the
industry-led technology standardization and the main bulk of academic research on Industry 4.0. In
particular, the great majority of authors proposing new Industry 4.0 architectures did not demonstrate
awareness of RAMI 4.0 or IIRA or any other industrially recognized architecture such as IMSA or IVRA.
Certainly, academics are not required to base their work on architectures originating from the industry,
but it is unfortunate that these research works lacked a discussion about any compatibility issues of
their proposal with the industrially accepted architectures and about the implications of any such issues
on the eventual industrial impact of the research. This is especially problematic due to the fact that the
only Industry 4.0 architectures that have been taken up by major international standardization
organizations are RAMI 4.0 and IIRA, which are being standardized by the IEC and OMG, respectively.
Further, the academic community seems to use the terms IIoT and CPPS interchangeably, evinced by the
similarity of the literature reviews for IIoT and CPPS in section 2. The IIC’s IIoT reference architecture
IIRA is ignored by the academic community and individual researchers frequently do not explain their
choice of term between IIoT and CPPS. Numerous individual researchers have proposed their own IIoT
or CPPS architectures, but there is a lack of any coordinated effort by a large number of groups from
several countries.

Research goal 2
The findings with respect to RG2 will be assessed by considering the layers of RAMI 4.0 (see Figure 2)
starting from the bottom. The lowest 2 layers were not specifically addressed in this simulation based
work. In any further research in a physical environment with equipment and systems from different
vendors, the OPC UA would need to be complemented with hardware and software components that
support the Industry 4.0 Component Model [49]. As noted in section 2.5, the Component Model is still at
an early stage and there is no standard ready to support technology implementation. For the
communication layer, a straightforward application of OPC UA was performed; the technology for this
layer of RAMI 4.0 was found to be mature. In the “Information” layer the content of the information to
be exchanged is defined in a machine readable and non-proprietary way. The literature review in section
2 revealed that a large number of researchers in IIoT and CPPS are applying ontologies for this purpose,
but in RAMI 4.0, OPC UA address spaces are defined using XML, as illustrated in section 4.1, instead of
ontology technology such as OWL [49]. It would be very desirable that other researchers and
practitioners would publish detailed proposals on OPC UA address spaces for digital product
descriptions, as it would lead to having critical mass for defining an OPC UA companion specification to
ensure consistent modeling across organizational boundaries. Finally, the top two layers of RAMI 4.0
were not included in the implementation, since no technology standardization is yet underway. Thus,
only a non-executable BPMN business process was proposed in Figure 3; a similar approach was taken in
[78].
6.3 Outlook
The developments related to the top two layers of RAMI 4.0 will significantly influence the true extent of
the Fourth Industrial Revolution beyond the current progress with OPC UA. Numerous publications cited
in this article anticipate a radical flattening or dissolution of the automation pyramid architecture, which
would indeed be the case if RAMI 4.0 were fully implemented. However, there is a lack of research
addressing the role of ERP and MES systems in an era that would follow a complete dismantling of the
automation pyramid. It is interesting to note that the dominant German ERP vendor SAP has taken a
leading role in competing efforts at the Industrial Internet Consortium [103], which may be a part of the
reason behind the slow progress in the RAMI 4.0 upper layers. One possible architecture that could
emerge would be a hybrid consisting of the lowest four layers of RAMI 4.0 and the top of the
automation pyramid consisting of the ERP and possibly also the MES. Such a future is not being
predicted by the majority of the literature reviewed in this paper, but neither did the majority of the
research offer insights to the future role of the dominant MES and ERP players in a CPPS, IIoT or RAMI
4.0 architecture. Thus, the minority of researchers in EA and EI reviewed in section 2.3 may yet prove to
be correct in their unwillingness to predict revolutionary developments to the top part of the
automation pyramid.
References
[1] V. Krueger, A. Chazoule, M. Crosby, A. Lasnier, M.R. Pedersen, F. Rovida, L. Nalpantidis, R
Petrick, C. Toscano, G. Veiga, A Vertical and Cyber–Physical Integration of Cognitive Robots in
Manufacturing, Proc. IEEE. 104(5) (2016) 1114-1127.
[2] R. Harrison, D. Vera, B. Ahmad, Engineering Methods and Tools for Cyber–Physical Automation
Systems, Proc. IEEE. 104(5) (2016) 973-985.

[3] H. Kagermann, R. Anderl, J. Gausemeier, G. Schuh, W. Wahlster (Eds.), Industrie 4.0 in a Global
Context: Strategies for Cooperating with International Partners (acatech STUDY), Herbert Utz
Verlag, Munich, 2016.
[4] C. Faller, M. Höftmann, Service-oriented communication model for cyber-physical-production-
systems, Procedia CIRP. 67 (2018) 156–161.
[5] M. Riedl, H. Zipper, M. Meier, C. Diedrich, Automation meets CPS, IFAC Proc. Vol. 46(7) (2013)
216-221.
[6] D. Bauer, D. Stock, T. Bauernhansl, Movement towards service-orientation and app-orientation
in manufacturing IT, Procedia CIRP. 62 (2017) 199–204.
[7] J. Krüger, L. Wang, A. Verl, T. Bauernhansl, E. Carpanzano, S. Makris, J. Fleischer, G. Reinhart, J.
Franke, S. Pellegrinelli, Innovative control of assembly systems and lines, CIRP Ann. 66(2) (2017)
707-730.
[8] C. Block, D. Lins, B. Kuhlenkötter, Approach for a simulation-based and event-driven production
planning and control in decentralized manufacturing execution systems, Procedia CIRP. 72
(2018) 1351-1356.
[9] B. Götz, D. Schel, D. Bauer, C. Henkel, P. Einberger, T. Bauernhansl, Challenges of Production
Microservices, Procedia CIRP, 67 (2018) 167-172.
[10] A.J. Isaksson, I. Harjunkoski, G. Sand, The impact of digitalization on the future of control and
operations, Comput. Chem. Eng. 114 (2018) 122-129.
[11] Y. Lu, Industry 4.0: A survey on technologies, applications and open research issues, J. Ind. Inf.
Integr. 6 (2017) 1-10.
[12] F. Zezulka, P. Marcon, I. Vesely, O. Sajdl, Industry 4.0 – An Introduction in the phenomenon,
IFAC-PapersOnLine, 49(25) (2016) 8-12.
[13] C. Santos, A. Mehrsai, A.C. Barros, M. Araújo, E. Ares, Towards Industry 4.0: an overview of
European strategic roadmaps, Procedia Manuf. 13 (2017) 972-979.
[14] S.W. Lin, B. Murphy, E. Clauer, U. Loewen, R. Neubert, G. Bachmann, M. Pai, M. Hankel,
Architecture Alignment and Interoperability: An Industrial Internet Consortium and Plattform
Industrie 4.0 Joint Whitepaper, Industrial Internet Consortium, 2017.
[15] A. Nishioka, A.H. Saleck, The IVI Approach to IoT and Current Manufacturing Projects, IoT Solut.
World Congr. Barcelona, 25-27 Oct 2016.
[16] Y. Nishioka, The Industrial Value Chain Initiative: A Japanese contribution to Smart
Manufacturing, Hannover Messe. Hannover, Germany, 28 Apr 2016.
[17] Y. Nishioka, Industrial Value Chain Reference Architecture, Hannover Messe. Hannover,
Germany, 24 Apr 2017.
[18] L. Li, China's manufacturing locus in 2025: With a comparison of “Made-in-China 2025” and
“Industry 4.0”, Technol. Forecast. Soc. Change. (In press)
[19] S. Wei, J. Hu, Y. Cheng, Y. Ma, Y. Yu, The essential elements of intelligent Manufacturing System
Architecture, 13th IEEE Conf. Autom. Sci. Eng. (CASE). Xi'an, China, 20-23 Aug 2017, pp. 1006-
1011.
[20] Sino-German Industrie 4.0/Intelligent Manufacturing Standardisation Sub-Working Group,
Alignment Report for Reference Architectural Model for Industrie 4.0/ Intelligent
Manufacturing System Architecture, Federal Ministry of Economic Affairs and Energy, Berlin,
2018.

[21] H.S. Kang, J.Y. Lee, S. Choi, H. Kim, J.H. Park, J.Y. Son, B.H. Kim, S.D. Noh, Smart Manufacturing:
Past Research, Present Findings and Future Directions, Intern. J. Precis. Eng. Manuf.-Green
Technol. 3(1) (2016) 111-128.
[22] T.K. Sung (2018) Industry 4.0: A Korea perspective, Technol. Forecast. Soc. Change. 132 (2018)
40-45.
[23] J. Huxtable, D. Schaefer, On Servitization of the Manufacturing Industry in the UK, Procedia CIRP.
52 (2016) 46-51.
[24] L.S. Dalenogare, G.B. Benitez, N.F. Ayala, A.G. Frank, The expected contribution of Industry 4.0
technologies for industrial performance, Int. J. Prod. Econ. 204 (2018) 383-394.
[25] R. Hamzeh, R. Zhong, X.W. Xu, A Survey Study on Industry 4.0 for New Zealand Manufacturing,
Procedia Manuf. 26 (2018) 49-57.
[26] S.S. Kamble, A. Gunasekaran, R. Sharma, Analysis of the driving and dependence power of
barriers to adopt industry 4.0 in Indian manufacturing industry, Comput. Ind., Volume 101,
(2018) 107-119.
[27] A. Iyer, Moving from Industry 2.0 to Industry 4.0: A case study from India on leapfrogging in
smart manufacturing, Procedia Manuf. 21 (2018) 663-670.
[28] F. Baena, A. Guarin, J. Mora, J. Sauza, S. Retat, Learning Factory: The Path to Industry 4.0,
Procedia Manuf. 9 (2017) 73-80.
[29] A.C. Pereira, F. Romero, A review of the meanings and the implications of the Industry 4.0
concept, Procedia Manuf. 13 (2017) 1206-1214.
[30] S. Sierla, V. Kyrki, P. Aarnio, V. Vyatkin, Automatic assembly planning based on digital product
descriptions, Comput. Ind. 97 (2018) 34–46.
[31] J. Wan, B. Chen, M. Imran, F. Tao, D. Li, C. Liu, S. Ahmad, Toward Dynamic Resources
Management for IoT-Based Manufacturing, IEEE Commun. Mag. 56(2) (2018) 52-59.
[32] F. Tao, J. Cheng, Q. Qi, IIHub: An Industrial Internet-of-Things Hub Toward Smart Manufacturing
Based on Cyber-Physical System, IEEE Trans. Ind. Inform. 14(5) (2018) 2271-2280.
[33] F. Zezulka, P. Marcon, Z. Bradac, J. Arm, T. Benesl, I. Vesely, Communication Systems for
Industry 4.0 and the IIoT, IFAC-PapersOnLine, 51(6) (2018) 150-155.
[34] A.J.C. Trappey, C.V. Trappey, U.H. Govindarajan, A.C. Chuang, J.J. Sun, A review of essential
standards and patent landscapes for the Internet of Things: A key enabler for Industry 4.0, Adv.
Eng. Inform. 33 (2017) 208-229.
[35] H. Boyes, B. Hallaq, J. Cunningham, T. Watson, The industrial internet of things (IIoT): An analysis
framework, Comput. Ind. 101 (2018) 1-12.
[36] K. Alexopoulos, S. Koukas, N. Boli, D. Mourtzis, Architecture and development of an Industrial
Internet of Things framework for realizing services in Industrial Product Service Systems,
Procedia CIRP. 72 (2018) 880-885.
[37] D. Kiel, C. Arnold, K.-I. Voigt, The influence of the Industrial Internet of Things on business
models of established manufacturing companies – A business level perspective, Technovation,
68 (2017) 4-19.
[38] C. Kan, H. Yang, S. Kumara, Parallel computing and network analytics for fast Industrial Internet-
of-Things (IIoT) machine information processing and condition monitoring, J. Manuf. Syst. 46
(2018) 282-293.
[39] M.S. Hossain, G. Muhammad, Cloud-assisted Industrial Internet of Things (IIoT) – Enabled
framework for health monitoring, Comput. Netw. 101 (2016) 192-202.

[40] J. Cheng, W. Chen, F. Tao, C.-L. Lin, Industrial IoT in 5G environment towards smart
manufacturing, J. Ind. Inf. Integr. 10 (2018) 10-19.
[41] D.L. Nuñez, M. Borsato, An ontology-based model for prognostics and health management of
machines, J. Ind. Inf. Integr. 6 (2017) 33-46.
[42] L. Petnga, M. Austin, An ontological framework for knowledge modeling and decision support in
cyber-physical systems, Adv. Eng. Inform. 30(1) (2016) 77-94.
[43] Y. Lu, X. Xu, Resource virtualization: A core technology for developing cyber-physical production
systems, J. Manuf. Syst. 47 (2018) 128-140.
[44] Z. Song, Y. Sun, J. Wan, P. Liang, Data quality management for service-oriented manufacturing
cyber-physical systems, Comput. Electr. Eng. (2017) 34-44.
[45] J. Klöber-Koch, J. Pielmeier, S. Grimm, M. Miličić Brandt, M. Schneider, G. Reinhart, Knowledge-
Based Decision Making in a Cyber-Physical Production Scenario, Procedia Manuf. 9 (2017) 167-
174.
[46] S. Iarovyi, W.M. Mohammed, A. Lobov, B.R. Ferrer and J.L.M. Lastra, Cyber–Physical Systems for
Open-Knowledge-Driven Manufacturing Execution Systems, Proc. IEEE. 104(5) (2016) 1142-
1154.
[47] G. Engel, T. Greiner, S. Seifert, Ontology-Assisted Engineering of Cyber–Physical Production
Systems in the Field of Process Technology, IEEE Trans. Ind. Inform. 14(6) (2018) 2792-2802.
[48] M. Brandmeier, E. Bogner, M. Brossog, J. Franke, Product Design Improvement Through
Knowledge Feedback of Cyber-physical Systems, Procedia CIRP. 50, (2016), 186-191.
[49] VDMA Forum Industrie 4.0, Fraunhofer-Anwendungszentrum Industrial Automation (IOSB-INA),
Kommunikation mit OPC UA Leitfaden zur Einführung in den Mittelstand (Communication with
OPC UA - Guide for technology introduction to SMEs), VDMA Verlag, Frankfurt, 2017.
[50] A. Rahatulain, M. Onori, Viewpoints and views for the architecture description of cyber-physical
manufacturing systems, Procedia CIRP, 72 (2018) 450-455.
[51] J. Lee, B. Bagheri, H.-A. Kao, A Cyber-Physical Systems architecture for Industry 4.0-based
manufacturing systems, Manuf. Lett. 3 (2015) 18-23.
[52] A.J.C. Trappey, C.V. Trappey, U.H. Govindarajan, J.J. Sun, A.C. Chuang, A Review of Technology
Standards and Patent Portfolios for Enabling Cyber-Physical Systems in Advanced
Manufacturing, IEEE Access, 4 (2016) 7356-7382.
[53] Y. Zhang, C. Qian, J. Lv and Y. Liu, Agent and Cyber-Physical System Based Self-Organizing and
Self-Adaptive Intelligent Shopfloor, IEEE Trans. Ind. Inform. 13(2) (2017) 737-747.
[54] F. Tao, M. Zhang, Digital Twin Shop-Floor: A New Shop-Floor Paradigm Towards Smart
Manufacturing, IEEE Access, 5 (2017) 20418-20427.
[55] B.-C. Pirvu, C.-B. Zamfirescu, D. Gorecky, Engineering insights from an anthropocentric cyber-
physical system: A case study for an assembly station, Mechatron. 34 (2016) 147-159.
[56] M. Pinzone, F. Albè, D. Orlandelli, I. Barletta, C. Berlin, B. Johansson, M. Taisch, A framework for
operative and social sustainability functionalities in Human-Centric Cyber-Physical Production
Systems, Comput. Ind. Eng. In press,
[57] T. Bangemann, M. Riedl, M. Thron, C. Diedrich, Integration of Classical Components Into
Industrial Cyber–Physical Systems, Proc. IEEE. 104(5) (2016) 947-959.
[58] A. Bonci, M. Pirani, S. Longhi, A database-centric approach for the modeling, simulation and
control of cyber-physical systems in the factory of the future, IFAC-PapersOnLine. 49(12) (2016)
249-254.

[59] P. Peniak and M. Franekova, Open communication protocols for integration of embedded
systems within Industry 4, 2015 International Conference on Applied Electronics (AE). Pilsen,
Czech Republic, 8-10 Sep 2015, pp. 181-184.
[60] M. García-Valls, C. Calva-Urrego, J.A. de la Puente, A. Alonso, Adjusting middleware knobs to
assess scalability limits of distributed cyber-physical systems, Comput. Stand. Interfaces. 51
(2017) 95-103.
[61] P. Marcon, F. Zezulka, I. Vesely, Z. Szabo, Z. Roubal, O. Sajdl, E. Gescheidtova, P. Dohnal,
Communication technology for industry 4.0, 2017 Progress In Electromagnetics Research
Symposium - Spring (PIERS). St. Petersburg, 22-25 May 2017, pp. 1694-1697.
[62] L.I. Terlouw, A. Albani, An Enterprise Ontology-Based Approach to Service Specification, IEEE
Trans. Serv. Comput. 6(1) (2013) 89-101.
[63] H. Wang, Y. Zhang, J. Cao, V. Varadharajan, Achieving secure and flexible M-services through
tickets, IEEE Trans. Syst. Man, Cybern. - Part A. 33(6) (2003) 697-708.
[64] C.C. Albrecht, D.L. Dean, J.V. Hansen, An Ontological Approach to Evaluating Standards in E-
Commerce Platforms, IEEE Trans. Syst., Man, Cybern., Part C. 37(5) (2007) 846–859.
[65] Y. Yarimagan, A. Dogac, A Semantic-Based Solution for UBL Schema Interoperability, IEEE
Internet Comput. 13(3) (2009) 64-71.
[66] F. Lampathaki, S. Mouzakitis, G. Gionis, Y. Charalabidis, D. Askounis, Business to business
interoperability: A current review of XML data integration standards, Comput. Stand. Interfaces.
31(6) (2009) 1045-1055.
[67] B. Eierle, H. Ojala, E. Penttinen, XBRL to enhance external financial reporting: Should we
implement or not? Case Company X, J. Account. Educ. 32(2) (2014) 160-170.
[68] P. Seele, Digitally unified reporting: how XBRL-based real-time transparency helps in combining
integrated sustainability reporting and performance control, J. Clean. Prod. 136 (2016) 65-77.
[69] C.-M. Chituc, XML interoperability standards for seamless communication: An analysis of
industry-neutral and domain-specific initiatives, Comput. Ind. 92–93 (2017) 118-136.
[70] J.-M. Nurmilaakso, P. Kotinurmi, H. Laesvuori, XML-based e-business frameworks and
standardization, Comput. Stand. Interfaces. 28(5) (2006) 585-599.
[71] J.-M. Nurmilaakso, EDI, XML and e-business frameworks: A survey, Comput. Ind. 59(4) (2008)
370-379.
[72] D. Goerzig, T. Bauernhansl, Enterprise Architectures for the Digital Transformation in Small and
Medium-sized Enterprises, Procedia CIRP, 67 (2018) 540-545.
[73] F. Gampfer, A. Jürgens, M. Müller, R. Buchkremer, Past, current and future trends in enterprise
architecture—A view beyond the horizon, Comput. Ind. 100 (2018) 70-84.
[74] V.E. Tobón, S. Lamouri, R. Pellerin, P. Dubois, A. Moeuf, The integration of ERP and inter-intra
organizational information systems: A Literature Review, IFAC-PapersOnLine. 51(11) (2018)
1212-1217.
[75] J. Kaidalova, K. Sandkuhl, U. Seigerroth Ulf, Challenges in Integrating Product-IT into Enterprise
Architecture – a case study, Procedia Comput. Sci. 121 (2017) 525-533.
[76] W. Bauer, M. Hämmerle, S. Schlund, C. Vocke, Transforming to a Hyper-connected Society and
Economy – Towards an “Industry 4.0”, Procedia Manuf. 3 (2015) 417-424.
[77] A. Telukdarie, E. Buhulaiga, S. Bag, S. Gupta, Z. Luo, Industry 4.0 implementation for
multinationals, Process Saf. Environ. Prot. 118 (2018) 316–329.

[78] K. Suri, J. Cadavid, M. Alferez, S. Dhouib, S. Tucci-Piergiovanni, Modeling business motivation
and underlying processes for RAMI 4.0-aligned cyber-physical production systems, 22nd IEEE
International Conference on Emerging Technologies and Factory Automation (ETFA), Limassol,
Cyprus, 12-14 Sep 2017, 1-6.
[79] B.-H. Li, L. Zhang, S.L. Wang, F. Tao, J.W. Cao, X.D. Jiang, X. Song, X.D. Chai, Cloud manufacturing:
a new service-oriented networked manufacturing model, Comput. Integr. Manuf. Syst. 16 (2010)
1-7+16.
[80] Y. Liu, L. Wang, X.V. Wang, Cloud manufacturing: latest advancements and future trends,
Procedia Manuf. 25 (2018) 62-73.
[81] O. Fisher, N. Watson, L. Porcu, D. Bacon, M. Rigley, R.L. Gomes, Cloud manufacturing as a
sustainable process manufacturing route, J. Manuf. Syst. 47 (2018) 53-68.
[82] X.V. Wang, X.W. Xu, An interoperable solution for Cloud manufacturing, Robotics Comput.-
Integr. Manuf. 29(4) (2013) 232-247.
[83] G. Pedone, I. Mezgár, Model similarity evidence and interoperability affinity in cloud-ready
Industry 4.0 technologies, Comput. Ind. 100 (2018) 278-286.
[84] A. Caggiano, T. Segreto, R. Teti, Cloud Manufacturing On-demand Services for Holistic Quality
Assurance of Manufactured Components, Procedia CIRP. 67 (2018) 144-149.
[85] P. Helo, D. Phuong, Y. Hao, Cloud manufacturing – Scheduling as a service for sheet metal
manufacturing, Comp. Oper. Res. (In press)
[86] J. Chen, G.Q. Huang, J.-Q. Wang, C. Yang, A cooperative approach to service booking and
scheduling in cloud manufacturing, Eur. J. Oper. Res. (In press)
[87] K. Mubarok, X. Xu, X. Ye, R.Y. Zhong, Y. Lu, Manufacturing service reliability assessment in cloud
manufacturing, Procedia CIRP, 72 (2018) 940-946.
[88] E. Ostrosi, A.-J. Fougères, Intelligent virtual manufacturing cell formation in cloud-based design
and manufacturing, Eng. Appl. Artif. Intell. 76 (2018) 80-95.
[89] S. Răileanu, F. Anton, T. Borangiu, S. Anton, M. Nicolae, A cloud-based manufacturing control
system with data integration from multiple autonomous agents, Comput. Ind. 102 (2018) 50-61.
[90] Z. Li, A.V. Barenji, G.Q. Huang, Toward a blockchain cloud manufacturing system as a peer to
peer distributed network platform, Robotics Comput.-Integr. Manuf. 54 (2018) 133-144.
[91] S. Grüner, J. Pfrommer, F. Palm, RESTful Industrial Communication With OPC UA, IEEE Trans. Ind.
Inform. 12(5) (2016) 1832-1841.
[92] W. Kim, M. Sung, Standalone OPC UA Wrapper for Industrial Monitoring and Control Systems,
IEEE Access, 6 (2018) 36557-36570.
[93] A. Girbea, C. Suciu, S. Nechifor, F. Sisak (2014) Design and Implementation of a Service-Oriented
Architecture for the Optimization of Industrial Applications, IEEE Trans. Ind. Inform. 10(1) (2014)
185–196.
[94] O. Givehchi, K. Landsdorf, P. Simoens, A,W, Colombo, Interoperability for Industrial Cyber-
Physical Systems: An Approach for Legacy Systems, IEEE Trans. Ind. Inform. 13(6) (2017) 3370-
3378.
[95] S. Wang, J. Ouyang, D. Li, C. Liu, An Integrated Industrial Ethernet Solution for the
Implementation of Smart Factory, IEEE Access. 5 (2017) 25455-25462.
[96] P. Pop, M.L. Raagaard, M. Gutierrez, W. Steiner, Enabling Fog Computing for Industrial
Automation Through Time-Sensitive Networking (TSN), IEEE Commun. Stand. Mag. 2(2) (2018)
55-61.

[97] V. Jirkovský, M. Obitko, P. Kadera, V. Mařík, Toward Plug&Play Cyber-Physical System
Components, IEEE Trans. Ind. Inform. 14(6) (2018) 2803-2811.
[98] D. Lang, M. Friesen, M. Ehrlich, L. Wisniewski, J. Jasperneite, Pursuing the Vision of Industrie 4.0:
Secure Plug-and-Produce by Means of the Asset Administration Shell and Blockchain
Technology, IEEE 16th Int. Conf. Ind. Inform. Porto, Portugal, 18-20 Jul 2018, 1092-1097.
[99] M. Wenger. A. Zoitl, T. Müller, Connecting PLCs With Their Asset Administration Shell For
Automatic Device Configuration, IEEE 16th Int. Conf. Ind. Inform. Porto, Portugal, 18-20 Jul 2018,
74-79.
[100] C. Wagner, J, Grothoff, U. Epple, R. Drath, S. Malakuti, S. Grüner, M. Hoffmeister, P.
Zimermann (2017) The role of the Industry 4.0 asset administration shell and the digital twin
during the life cycle of a plant, 22nd IEEE International Conference on Emerging Technologies
and Factory Automation (ETFA), Limassol, Cyprus, 12-14 Sep 2017, 1-8.
[101] OPC Foundation: OPC Unified Architecture Specification, Part 3: Address Space Model,
Release 1.04, OPC Foundation, 2017.
[102] K. Collins, A.J. Palmer, K. Rathmill, The Development of a European Benchmark for the
Comparison of Assembly Robot Programming Systems, in: K. Rathmill, P. MacConaill, P. O'Leary,
J. Browne (Eds.), Robot Technology and Applications, Springer, Berlin, Heidelberg, 1985, pp. 187-
199.
[103] S.-W. Lin, M. Crawford, S. Mellor, The Industrial Internet of Things Volume G1:
Reference Architecture, Industrial Internet Consortium, 2017.