2018 IEEE 21st International Symposium on Real-Time Distributed Computing
IoT Integration for Adaptive Manufacturing
Christos Alexakos, Christos Anagnostopoulos, Apostolos Fournaris, Christos Koulamas, Athanasios Kalogeras
Industrial Systems Institution
ATHENA Research Center
Patras, Greece
{alexakos, anagnostopoulos, fournaris, koulamas, kalogeras}@isi.gr
Abstract— The Industrial Internet of Things (IIoT) has
emerged as a concept for the integration of the Internet of Things
(IoT) in the industrial domain, posing a variety of challenges and
emphasizing among others in interoperability and integration
aspects with Shop Floor and Plant layer systems. Present work
builds on top of previous work related to the integration of the
different systems in the manufacturing environment automation
pyramid. This classical hierarchy involves three layers: the
Enterprise Resource Planning (ERP), the Manufacturing
Execution System (MES) and the Shop Floor. A further issue is
relevant to the semantic integration of IoT sensors with
manufacturing systems. The present paper presents a complex
system architecture which allows both the aggregation of data
generated by IIoT devices, and the automated reaction of the
manufacturing environment to either detected and diagnosed, or
predicted events based on this data.
Keywords— IIoT; adaptive manufacturing;systems integration;
manufacturing automation
I. INTRODUCTION
The Internet of Things (IoT) [1] has revolutionized a wide
range of applications in different domains of human activity. It
is relevant to the networked interconnection of things, e.g.
smart everyday objects. Embedded systems enable the
integration of interconnected smart things, efficiently
communicating and interacting with other smart things and
humans.
A subset of the IoT, the Industrial Internet of Things (IIoT)
has emerged as a concept for the integration of IoT in the
industrial domain. IIoT faces additional challenges with
reference to its superset IoT, related to the need for appropriate
architectures and technologies for design and management of
Cyber-Physical Systems (CPS), and the unified approach
towards safety and security issues, to name a few [2].
There are two main platforms that deal with the wider
adoption of the IIoT. Industrie 4.0 [3] represents a high-tech
strategic initiative in Germany aiming at the penetration of
information and communication technologies (ICT) in the
manufacturing domain. Deployment of CPS in the
manufacturing environment makes possible monitoring and
synchronization between the factory floor and the cyber ICT
space. In this context, the manufacturing domain is transformed
into a more efficient, collaborative and resilient space [4],
making possible the production of high-quality, low-cost mass
specialized products. Wider adoption of CPS in the
manufacturing domain, actually leads to a fourth industrial
Work supported by projects VISETAK, PALMIS and I3T, co-financed
by Greece and the European Union – European Regional Development
Fund (NSRF/EPAnEK I3T-5002434).
2375-5261/18/$31.00 ©2018 IEEE
DOI 10.1109/ISORC.2018.00030
revolution and a new production paradigm, characterized by
higher flexibility, configurability, and agility. IIoT actually
represents a generalization of the Industrie 4.0 platform [2].
The Industrial Internet Consortium (IIC) [5] represents a
second platform with leadership in the field. IIoT vision has
such constituent elements as dynamic composition and
automated interoperability, intelligent and resilient control,
data management, data analytics and advanced data processing,
connectivity, integrability, interoperability and composability,
resilience, safety and security [6].
Both platforms propose reference architectures to facilitate
IIoT adoption. A document for the mapping and alignment of
the Reference Architecture Model for Industrie 4.0 (RAMI 4.0)
[7] and the Industrial Internet Reference Architecture (IIRA)
[8] has recently been made available by the two platforms [9].
Further to sensing technologies and their networking
protocols, fundamental technologies associated with the IIoT
are higher level protocols such as multicast DNS (mDNS)
[10] for resource and service discovery, or application
protocols like Constrained Application Protocol (CoAP) [11]
targeting constrained resource devices and their synchronous
research/response interaction, Message Queue Telemetry
Transport (MQTT) [12] being an asynchronous publish
subscribe protocol on top of Transmission Control Protocol
(TCP), and Advanced Message Queuing Protocol (AMQP)
[13] also employing asynchronous publish / subscribe over
TCP.
The IIoT is relevant to other domains further to the
manufacturing paradigm. Such domains comprise critical
infrastructures, e.g. energy grid, transportation, smart buildings
and smart cities. Industrial Control Systems (ICS) are widely
used in the above usecases that present similarities to
manufacturing systems. For instance, they involve similar
technologies like sensors, controllers, sensor networks, and
data acquisition systems. They also present similar
requirements such as continuous operation and need for
resilience.
The paper focuses on the integration of IIoT devices in
manufacturing processes. This integration has two aims: to
achieve a) faster and safer data exchange among manufacturing
systems and IIoT systems and b) information unification, in the
sense that data transmitted must be easily translated in order to
be computer-understandable by all involved systems.
The paper builds on top of previous work of the authors
related to the actual implementation of the Manufacturing
146
Execution System (MES) by a Multi Agent System (MAS) of
autonomous software agents with different roles. This allows in
fact to completely dissolve the MES introducing a flat
hierarchical scheme in the manufacturing environment that is
in line with the current state of the art as presented by IIoT
prevalent reference architectures. This work is extended with
reference to thing connectivity by enhancing intelligence to the
“edge” of the network which is also in line with the current
state of the art. The proposed architecture is in line with the
current state of the art and more specifically the architectural
axis of RAMI 4.0 and the functional viewpoint of the IIRA.
The paper is structured as follows. Section II presents prior
work, which the presented approach is based on. Section III
describes the proposed system architecture. Finally,
conclusions are presented in Section IV.
II. IIOT CHALLENGES IN MANUFACTURING
The integration of IIoT in manufacturing is driven by a
huge market potential of between 900 billion USD and 2.3
trillion USD on a yearly basis up to 2025. The main research
challenge is the combination of a number of enabling
technologies. Such technologies comprise IoT, Cyber Physical
Systems, Cloud and Cognitive Computing.
Traditionally, there is a split between Information
Technology (IT) and Operational Technology (OT) in the
industrial domain [2]. OT starts with physical assets and things,
and moves towards industrial control systems. IT starts with
data and their models and moves towards data driven
infrastructures. Their combination makes it possible to inject IT
ideas in OT resulting to advancements in the manufacturing
domain.
Asset management is critical in manufacturing, more and
more with reference to advanced production models, such as
mass customization. Information systems and their induced
seamless integration and interoperability of things can provide
improved capacity with reference to asset monitoring and
management. Self-configuration, self-optimization and self-
diagnosis can be some of the challenges introduced in this
sense.
Data use and analytics is quite important for a number of
services in the manufacturing domain. Big data generated by
physical things and their enterprise connectivity to the cloud
poses new challenges for data aggregation and analysis.
The need for advanced intelligence in the industrial
environment also moves intelligence down to the local network
level or directly into devices. Thus, fog or edge computing
emerge as additional challenges.
As more and more intelligent things participate in the
industrial domain and are networked with the cloud,
exchanging information, the level of overall exposal is
increased. Thus, risk of cyberattacks is enhanced significantly.
Cybersecurity poses a challenge with an eye also to the mission
critical character of industrial control systems.
Work in this paper deals with a number of the
aforementioned challenges. First of all, it addresses the issue of
interoperability and integration in the industrial domain with
147
reference to both manufacturing assets and IoT devices. Its
proposed flat hierarchical architecture serves this goal.
Furthermore, its proposed Multi Agent System with the
increased autonomy of software agents that it introduces
enhances the merging of IT and OT technologies contributing
to a greater degree of flexibility and agility. Edge intelligence
is introduced close to the IIoT devices enabling data storage
and manipulation. The overall architecture proposed can
support asset performance management services, as industrial
assets are handled by special agents, the Resource Agents that
can provide asset specific information to higher layer services.
Cybersecurity is out of the scope of the presented work.
III. PRIOR WORK
The PABADIS’PROMISE (P2) project [14], at a relatively
early date, extended the ideas of distributed control systems, in
order to overcome the limitations of classical manufacturing
systems. The project employed an innovative control and
networking architecture, incorporating both manufacturing
resources and products, and ranging across all three layers of
the traditional manufacturing environment automation
hierarchy: Enterprise Resource Planning (ERP), MES and Shop
Floor layer. MES is especially fully decentralized through the
application of software agent middleware. The resulting MAS
enables, through appropriate interfaces, direct access from the
ERP layer down to the Shop Floor layer. When it comes to
interoperability issues in the manufacturing environment,
P2Ontology [15] presents the necessary semantics enabling a
P2 MAS interoperable software agent paradigm.
According to the P2 architecture, product orders issued by a
customer trigger at the ERP module level the creation of a
number of Order Agents. Each of these software agents is
committed to a specific production task. Each production task
needs to enroll a number of resources in the manufacturing
environment, being sensing or control equipment. Each
resource is controlled by a Resource Agent, exposing to the
whole manufacturing environment the relevant resource
abilities. The Ability Broker serves the role of gathering the
different Resource Agents exposed abilities. A mapping
between the existing abilities and the requested capabilities for
an order to be fulfilled is necessary, leading to the Order
Agents to negotiate with Resource Agents their schedule and
allocate resources to their tasks.
The VISETAK system extended P2 work towards IoT
device integration [16]. It dealt both with semantic integration
of IoT devices and the extension of the P2 MAS, making
possible the adequate integration of IoT devices in the
manufacturing process workflow. Semantic integration of IoT
devices was achieved by adopting the Semantic Sensor
Network Ontology (SSN). Each IoT device is assigned a MAS
Sensor Agent, resulting from the enrichment of the P2 MAS
agent role model for IoT integration needs. The resulting
VISETAK MAS is depicted in Fig. 1.
IV. IIOT INTEGRATION IN THE MANUFACTURING ENVIRONMENT
The ǿǿȠȉ integration system architecture must provide three
basic functionalities. The first would be to enable a wide
network of IoT devices exchanging data according to
standardized application protocols. The second would be to
allow timely IoT device data acquisition for consumption at the
MAS-implemented MES layer, as well as by higher level
enterprise information systems. Finally, it should be supported
to “translate” device data information to MAS ontology terms,
allowing the MAS to appropriately detect and diagnose events
and accordingly respond to them.
Fig. 1. VISETAK MAS Architecture
Fig. 2 depicts the basic components of the system
architecture, as well as how it interoperates with the installed
enterprise and production systems.
Fig. 2. Overall IIoT – Manufacturing Systems Integration Architecture
The presented architecture builds on top of, and improves
the one proposed in [17] and depicted in Fig. 1. In this earlier
version http gateways are used, so as to integrate MAS with
IoT devices. This approach suffers certain drawbacks.
Overhead is induced, increasing transmission times of data
between gateways. Furthermore, Sensor Agent computational
time is increased, by the number of additional systems and
148
applications, that need the same IoT device data for further
analysis.
In this context, the presented architecture is improved, as
the collection of data and the configuration of IoT devices has
been undertaken by a lightweight software implementation that
is able to act as middleware without adding significant
overhead. The presented architecture actually moves
intelligence to the “edge” of the network, introducing some
middleware mediation, thus removing the need for heavy
protocol stacks on e.g. sensing equipment to allow their remote
interaction to the MQ (Message Queue) Server.
A. IoT Devices and Network Technology Choices
The parts of the novelty detection architecture that have
been assigned to execute in the edge of the system, close to the
monitored resources, were implemented using a range of
embedded devices. These devices are of different capabilities,
interconnected under a wireless sensor network of
heterogeneous IoT technologies. The chosen application level
integration technology is RESTful (Representational State
Transfer - REST) Web Services over Hypertext Transfer
Protocol (HTTP), using JavaScript Object Notation (JSON) as
content format. Resource constrained wireless sensor nodes are
coupled through embedded gateways translating HTTP/JSON
to the underlying CoAP/CBOR (Concise Binary Object
Representation) equivalents. However, all CoAP accessed
wireless nodes are also accessible from any CoAP-enabled
device directly through Internet Protocol version 6 (IPv6). This
multi-level access becomes seamlessly feasible by using URIs
(Uniform Resource Identifier) for sensor identification,
separating the access, node, sensor and information or
configuration resources in the URI path.
Thus, let sensor “s1”, attached to a node with an FQDN
(Fully Qualified Domain Name) of “n1.domX.com”,
containing a REST resource such as “/dtct/inf/bufSz”,
representing in this case a buffer size. Then, if it were accessed
directly from a CoAP capable controller, the leaf resource URI,
i.e. the URI of a CoAP Resource that does not contain other
resources, would be “coap://s1.n1.domX.com/dtct/inf/bufSz”.
On the other hand, if it is accessed through a generic HTTP to
CoAP gateway, it will be
“http://gw1.domY.com/s1.n1.domX.com//dtct/inf/bufSz”. Thus
the gateway will be able to directly DNS (Domain Name
Service) resolve the sensor node FQDN embedded to its URL,
and forward the request.
All sensor nodes execute the aforementioned sampling,
storage, feature extraction, classification and novelty detection
services. Their operation is externally controlled through a
well-structured set of resource URIs, accessed through HTTP
or CoAP GET/POST/PUT REST operations. The most
important information and configuration resources which
indirectly explain the internal operation of the signal
processing engines have as follows:
• /info: The set of implementation dependent not
configurable parameters, such as basic buffer size,
maximum number of buffers, the maximum number of
sliding windows for the acquired signal processing, the
 supported sampling rates and the maximum number of
supported state descriptions, etc.
• /config: The set of configurable parameters of the
embedded detection engine, such as the chosen
sampling rate, the sliding windows size and step, the
sample scaling factor the monitoring period, etc.
• /stateset: The set of configurable state descriptions and
thresholds over which the distances of the calculated
feature matrices are compared, in order to generate a
novelty event
• /event: The (observable) resource of the last event
triggered by the node. This is the structure that is sent to
the upper software layers, periodically, on-demand or
on a novelty detection basis, encapsulating the whole
information of the feature-extraction, classification and
novelty detection chain. Its Java POJO equivalent is
depicted in Fig. 3
Fig. 3. Main embedded event information structure
A classification of measurement classes in terms of sensing
elements and relevant qualities is possible.
• At the lower end, there are simple scalar sensors,
such as temperature sensors. This class does not
impose high sampling bandwidth and processing
requirements, and thus can be supported by
resource constraint embedded devices and low
bandwidth IoT networking technologies.
• At the other extreme, there are high quality,
multiple axis vibration monitoring requirements.
For this class higher power and processing
resources may be needed, in order to handle more
complex data streams and interfaces to industrial
grade IEPE (Integrated Electronics Piezo Electric)
vibration sensors.
• In between, there are nodes that can still provide
for series and vector measurements, further to
simple scalar sensors, but with lower sampling
rates, and accuracy needs. Such nodes can be
supported by hardware with mid-processing
power, adequate flash and Random-Access
Memory (RAM) space for signal acquisition,
149
storage, processing and network transfer, radio
communication capabilities and mid-quality
analog to digital converters.
An instance of this latter class of nodes has been
implemented using off-the-self hardware components and
widely used IoT operating systems. The hardware is based on a
two processor board system structure, separating the
application from the communication processor, coupled with a
number of exchangeable sensor interface boards.
The sampling, signal processing, and detection components
execute in a Freescale FRDMK64F embedded board, while the
IoT networking stack, namely the IEEE-802.15.4 wireless
interface and the IPv6, RPL and CoAP components, are
implemented over the CC2538 base Openmote board. The two
parts are connected through an Xbee compatible shield and
communicate over a serial line protocol. The Openmote board
implements the networking protocols and wireless interface,
based on the CC2538 SoC (System on Chip), and
communicates with the Freescale board through a serial
connection. The system and its structure are presented in Fig. 4.
Fig. 4. Low-end vibration monitoring embedded node with event detection
capabilities
Still, high quality vector sampling requirements are always
present and these can be satisfied by larger and power intensive
embedded devices capable to support and power industrial
grade IEPE vibration sensors. This case has been covered by a
sensor node based on the DT9837B USB (Universal Serial
Bus) acquisition system from Data Translation, controlled by
an embedded PC (Personal Computer) or tablet device which
provides the developed interfaces to the IIoT infrastructure,
based on HTTP/JSON Web-Services, as presented in Fig. 5.
Fig. 5. High-end vibration monitoring embedded device with UI and event
detection capabilities
B. IoT sensors Data Aggregation
The IoT devices, although installed inside the
manufacturing environment, operate independently having
their own network infrastructure for data exchange. The
challenge here lies on how to timely transmit generated events
to the integrated manufacturing systems allowing the latter to
respond accordingly. IoT device data aggregation bears two
steps. The first is relevant to the periodic invocation of web
services via CoAP or HTTP protocols in order to receive
collected data and events. The second is to forward data
received through these service invocations to the appropriate
systems in the enterprise environment.
The first step is carried out by iIoT-Collect, a software
middleware application. For the implementation of the second
step a Message Queue (MQ) Server is used, which acts as a
mediator for the other enterprise and manufacturing systems
ensuring proper data transmission to them.
iIoT-Collect is an implemented lightweight IoT platform,
standing up to the specific needs of the presented architecture.
This platform is composed of three main modules: a) the
scheduler, b) the invoker, and c) a GUI (Graphical User
Interface). The scheduler constantly checks the platform
internal database for devices, which retrieval action is included
in the next time frame (usually 1 sec). The devices found are
submitted to the invoker, which is responsible to invoke their
services and forward the response to the MQ Server. The GUI
provides administration services to users such as registration
and configuration of a new device and monitoring of the
existing ones. iIoT-Collect is implemented with python and
MySQL, and supports both HTTP and CoAP, while MQTT
protocol integration is under development as well. Independent
of the application protocol used, final data is published in the
MQ Server abiding to the initial JSON data structure.
After data is retrieved from a sensor, it is essential to be
accessed from the other systems in the enterprise or
manufacturing environment. In our presented case, it is of
upmost important that the MAS is informed of an event
generated by an IoT device. Furthermore, collected data is
quite useful to be stored in a NoSQL database for further
analysis, e.g. advanced predictive analytics. The MQ Server
provides the appropriate functionalities to meet the
aforementioned requirements quickly and safely. The MQ
Server is able to maintain a large number of queues of
messages, which subscribed consumers can read. For each
device, a queue is configured with reference to the MAS and
one additional queue for any other third system. In the
previously presented example of the s1 sensor, and assuming
that a NoSQL database is used for storing all collected data, the
MQServer needs to have two queues: a) the
mas_s1_n1_domX_com_queue, which is consumed by the
MAS Sensor Agent, and b) the nosql_
s1_n1_domX_com_queue, which is consumed by the mediator
script that saves the data to the NoSQL database. By
maintaining these two queues, both systems may retrieve the
necessary data without delays. For the MQ Server
implementation the Rabbit MQ is used, an open source
message queue server able to serve up to 60.000 messages per
second.
150
The main reason for using this two-step approach in the
presented architecture, instead of directly integrating the IoT
sensors to the MAS, is in order to minimize the needed
computational effort on the part of MAS. This approach
achieves an abstraction of the protocols, the networks and the
functionalities of the devices, with reference to the MAS.
Finally, the MAS only receives data, without any need for
additional tools for setup or configuration. On the other hand,
this approach enables the collection of recorded data from other
systems used in the enterprise without interfering with the
manufacturing process.
C. Utilising the IoT Data from the MAS
At the MAS, each Sensor Agent is subscribed to the
associated queue of the MQ Server and waits for messages
from the respective IoT device. When a new message arrives,
its content, depicted in JSON format, is converted into JAVA
classes and is then parsed according to the ‘translation’ rules
described in [15] to P2 Ontology and SSN Ontology terms. The
translated information is thus ‘understandable’ by the agents in
the MAS system.
After the Sensor Agent interprets the information sent by
the device, it processes it. In the case of an event, the agent
initiates the associated protocols for the response actions that
must be taken in the manufacturing environment. In most of
the cases, where the IoT devices monitor a feature related to a
machine, an event is forwarded related to the absence of a
machine ability at the shop floor layer. The Sensor Agent
notifies the Resource Agent Supervisor about the forthcoming
absence of the particular ability and the latter forwards the even
to the associated Resource Agent. The Resource Agent, checks
the ERP placed orders, that it is responsible to carry out, and
informs the appropriate Order Agents for the lack of the ability.
The Order Agents then re-initiate the negotiation protocol in
order to locate an alternative resource that provides the specific
ability. In this context, rescheduling of the production is
achieved.
V. CONCLUSIONS
This paper presents a novel approach for integrating IoT
devices in the manufacturing process. More specifically, the
proposed complex system is able to efficiently gather
information from IoT devices. Furthermore, when an event is
detected it can automatically respond to it, utilizing a
manufacturing automation multi-agent system that orchestrates
and monitors the production process and has direct access to
the control devices of assets at the Shop Floor. The presented
architecture enhances previous work that it is based on by
moving intelligence to the edge of the network. Middleware is
used in order to provide mediation services to sensing
equipment.
When compared to existing IIoT Reference Architectures,
our proposed architecture is well mapped to RAMI 4.0 with
reference to its proposed flat hierarchy introduced via
VISETAK-MAS. Furthermore, work presented deals with the
Asset, Integration, Communication and Information layers of
the RAMI 4.0 architecture axis, while providing interfaces to
the upper layers. With reference to IIRA Functional Viewpoint,
the presented architecture is mapped to the control, information
and application domains. With reference to the IIRA
implementation viewpoint the presented architecture maps well
to the IIRA edge connectivity architecture through both its
OPC-UA service interface to the Shop Floor and iIoT collector
middleware. Furthermore with reference to communication
mapping our approach utilizes OPC-UA (present both in
RAMI 4.0 and IIRA) as well as IIoT mainstream protocols
such as CoAP and MQTT (present in IIRA).
Future work includes the extension of the iIoT-Collect
middleware towards integrating the MQTT application
protocol. Testing and validation of the presented architecture is
underway in a manufacturing industrial environment simulator.
REFERENCES
[1] Xia, F., Yang, L. T., Wang, L., & Vinel, A. (2012). Internet of things.
International Journal of Communication Systems, 25(9), 1101.
[2] Serpanos, D., & Wolf, M. (2017). Internet-of-things (iot) Systems:
Architectures, Algorithms, Methodologies. Springer.
[3] Lasi, H., Fettke, P., Kemper, H. G., Feld, T., & Hoffmann, M. (2014).
Industry 4.0. Business & Information Systems Engineering, 6(4), 239-
242.
[4] Lee, J., Bagheri, B., & Kao, H. A. (2015). A cyber-physical systems
architecture for industry 4.0-based manufacturing systems.
Manufacturing Letters, 3, 18-23.
[5] Industrial Internet Consortium, http://www.iiconsortium.org
[6] Mark Crawford, “Industrial Internet of Things: Understanding and Using
the Industrial Internet Consortium’s Reference Architecture”, June 2016,
https://www.iiconsortium.org/japan-forum/SAP-June-3-presentation.pdf
[7] Hankel, M., & Rexroth, B. (2015). The reference architectural model
industrie 4.0 (rami 4.0). ZVEI, April.
151
[8] Lin, S. W., Miller, B., Durand, J., Joshi, R., Didier, P., Chigani, A., ... &
King, A. (2015). Industrial internet reference architecture. Industrial
Internet Consortium (IIC), Tech. Rep.
[9] Shi-Wan Lin, Brett Murphy, Erich Clauer, Ulrich Loewen, Ralf Neubert,
Gerd Bachmann, Madhusudan Pai, Martin Hankel, “Architecture
Alignment and Interoperability”, Industrial Internet Consortium and
Plattform Industrie 4.0 Joint Whitepaper, 2018,
http://www.iiconsortium.org/pdf/JTG2_Whitepaper_final_20171205.pdf
[10] Cheshire, S., & Krochmal, M. (2013). Multicast dns (No. RFC 6762).
[11] Shelby, Z., Hartke, K., & Bormann, C. (2014). The constrained
application protocol (CoAP).
[12] Hunkeler, U., Truong, H. L., & Stanford-Clark, A. (2008, January).
MQTT-S—A publish/subscribe protocol for Wireless Sensor Networks.
In Communication systems software and middleware and workshops,
2008. comsware 2008. 3rd international conference on (pp. 791-798).
IEEE.
[13] Vinoski, S. (2006). Advanced message queuing protocol. IEEE Internet
Computing, 10(6).
[14] A.P. Kalogeras, L. Ferrarini, A. Lueder, J. Gialelis, C. Alexakos, J.
Peschke, C. Veber, “Ontology-driven Control Application Design
Methodology”, in the 12th IEEE Conference on Emerging Technologies
and Factory Automation – ETFA’2007, pp.1425-1428, September 25-
28, 2007, Patras, Greece
[15] D. Diep, C. Alexakos, T. Wagner, "An Ontology-based Interoperability
Framework for Distributed Manufacturing Control", In 12th IEEE
Conference on Emerging Technologies and Factory Automation (ETFA
2007), pp. 855-862, September 2007
[16] Alexakos, Christos, Christos Anagnostopoulos, and Athanasios P.
Kalogeras. "Integrating IoT to manufacturing processes utilizing
semantics." Industrial Informatics (INDIN), 2016 IEEE 14th
International Conference on. IEEE, 2016.
[17] Christos Alexakos, Christos Anagnostopoulos, Apostolos P. Fournaris,
Athanasios Kalogeras and Christos Koulamas, Production Process
Adaptation to IoT Triggered Manufacturing Resource Failure Events,
22nd IEEE International Conference on Emerging Technologies And
Factory Automation - ETFA 2017, September 12-15, 2017, Limassol,
Cyprus