IoT@Work Automation Middleware System Design and Architecture

S. Gusmeroli S. Piccione D. Rotondi

TXT e-solutions S.p.A. TXT e-solutions S.p.A. TXT e-solutions S.p.A.
Via Frigia, 27 c/o Tecnopolis N.O. c/o Tecnopolis N.O.
20126 Milan, IT Strada Prov. Casamassima Km 3 Strada Prov. Casamassima Km 3
sergio.gusmeroli@txtgroup.com 70010 Valenzano (BA), IT 70010 Valenzano (BA), IT
salvatore.piccione@network.txtgroup.com domenico.rotondi@txtgroup.com

Abstract driven processes for manufacturing applications have

The industrial sector is being impacted by the Internet
of Things due to the increasing availability of computing
and communication capabilities in a wide range of
devices and equipment deployed in the shop floor. This
requires substantial architectural and functional
improvements in order to actually manage and exploit
the potential of such smart components. The EU FP7
IoT@Work project aims at addressing the issues of
Plug&Work configuration and self-management features
in automation systems. This paper focuses on presenting
the architecture and the main features of the IoT@Work
Event Notification Service (ENS) middleware that is
used to support an event-driven communication
paradigm among devices and services, both inside and
outside the factory plant.
1. Introduction
Modern factory automation systems are becoming
complex distributed computing systems thank to the
increasingly wide availability of computing and communication
features in sensors, actuators and production devices. This is
recently promoting Internet-of-Things (IoT) concepts [1]
and technologies in factory automation to manage a n d
orchestrate this wide variety of smart devices.
Service Oriented Architecture (SOA) has been a
major step towards loosely coupled distributed
computing, opening new horizons in the interoperability
of systems, processes and services. Event-Driven
Architecture (EDA) [35] is the next evolutionary step to
advanced decoupling, enabling event based mediation
between systems that can be totally unaware of each
other and dynamically rearranged as needed [2]. EDA
enables composite applications to react to events and
improve system responsiveness and scalability. As a
result, EDA blended with SOA provides a versatile way
for implementing interoperability on a both synchronous
and asynchronous basis.
Manufacturing systems have early on embraced
event-driven techniques (see [3], [4]) as events are
integral elements of supervision and control software
used in production applications. Recent efforts on event-
strived to work out systems for holistic event-driven
manufacturing monitoring and control, which includes
work towards unified management of events across all
levels of the automation pyramid [5].
Event-driven architectures normally adopt a
publish/subscribe model that pushes events to interested
listeners as compared to the pull model of more
traditional SOA approaches, therefore providing more
scalability and flexibility. Push models have normally
unidirectional, asynchronous and fire-and-forget
communication patterns, promoting the use of highly
decoupled systems in which the only relevant issues are
related to well-defined message semantics [6].
The IoT@Work1 project (https://www.iot-at-
work.eu) is focusing on a holistic approach towards a
Plug&Play IoT solution for manufacturing through
the development of self-configuration mechanisms,
enabling what we call secure, Plug&Work IoT, whereby
devices are auto-configured and ready to cooperate with
each other as soon as they are plugged into the factory
network, self-adapting to changes in response to
demands, faults, etc..
The IoT@Work architecture, among other functional
components, envisages a specific middleware (the Event
Notification Service – ENS) devoted to collect, organise
and provide, in a controlled way, production data coming
from the shop floor.
In the following we present the IoT@Work ENS
middleware and its provided publish/subscribe event
based communication model to support both one-to-
many and many-to-many communication patterns, as
well as dynamic coupling of devices, processes and
services.
The paper is organised as follows:
 in Section 2 we provide a brief overview of the
State of the Art in the management of
manufacturing data flow;
 in Section 3 we shortly present the IoT@Work
project and the ENS structure and
functionalities describing, in order of reporting:
the IoT@Work Plug&Work concept, the
1 This work was financially partially supported by the European FP7
EU Project IoT@Work under grant number ICT-257367

978-1-4673-4737-2/12/$31.00 ©2012 IEEE

 motivation underlying the definition of the
ENS, its functionalities and architecture, the
structure of the ENS namespaces, the access
control mechanisms used to secure the ENS
and, finally, a summary of the used
technologies;
 in Section 4 we report the conclusions and the
future work.
2. Related work
Plant data collection and acquisition is an integral
component of Manufacturing Execution Systems (MES), as is
also reflected within the ISA S95 standards. In general, plant
data collection refers to monitoring, gathering and organizing
data and information concerning processes, materials and
production operations that are associated with people,
machine and controls. Figure 1 depicts the usual data
flow in manufacturing.
Figure 1. Manufacturing traditional data flow
The importance of collecting data from production
systems has risen the deployment of technologies for
automated data acquisition and processing, including bar-
code and RFID. The benefits of RFID technology for
manufacturing have been acknowledged since over a decade
(see [7]) for reducing labour and inventory costs, as well as
providing other techno-economic benefits (see [8], [9]). This
has further increased the relevance and the deployment
of event-driven techniques in manufacturing, which have
also produced results associated with the specification of
manufacturing/control events, including complex events that
are based on logical or temporal combinations of primitive
events (see [5], [10]). In these and other works, EDA is
used as a vehicle for the application of complex event
processing, as a means to derive complex/composite
events [11].
All these innovations are fostering, on the one hand,
the design and development of more flexible middleware
in the shop floor able to provide events to an, even
dynamically, evolving set of monitoring and control
applications and, on the other hand, the need to deploy
Knowledge-Management t e c h n o l o g i e s applied to
automation and control systems. This is additionally
increasing the need to develop and more extensively use
ontologies to semantically represent manufacturing
processes’ information in order to support enhanced
communication among intelligent components of control
systems, to add flexibility and to facilitate automatic
reconfiguration of manufacturing systems [12].
The application of EDA-based solutions in industry,
although not consolidated and systematic, has gained a
considerable attraction, motivated by technological and
research achievements in recent years. In [13] a thorough
revision of the concept, use, design and application of
agents in manufacturing is held while in [14] and [15]
some successful research and application cases are
reported.
On the middleware side, attempts to specify, develop and
implement a SOA-based distributed embedded control and
automation systems were performed in the past years for
example by the CAMX framework [36], or by the EU FP6
SOCRADES project (http://www.socrades.eu) that designed
a cross-layer SOA-Infrastructure, covering the major levels
of the ISA´95 Enterprise Architecture. The results of those
projects were backed up by major European Automation
technology providers, which showed the importance of the
application of the SOA-paradigm in their core business (see
[16], [17]).
A similar approach is being pursued by the EU FP7
IMCAESOP project (http://www.imc-aesop.eu), which is
developing a new generation of SCADA systems based on a
set of SOA-based SCADA functionalities exposed and used
in a distributed IT Infrastructure along the Enterprise
Architecture, as well as by the EU FP7 FoFdation project
(http://www.fofdation-project.eu) which is designing a data
integration standard that allows individual entities and their
associated devices to share data in a common format.
Additional research approaches and activities are
described in [18], [19] and [20].
3. IoT@Work ENS
3.1. IoT@Work Plug&Work
Plug&Work, at the core of the IoT@Work design and
specification, is the ability of devices and network
components to auto-configure themselves according to
the needs of the automation applications. Plug&Work,
therefore, aims at heavily reducing the required manual
activities, the overall system downtime, and the
configuration errors.
Plug&Work requires not only self-configuration
features in production and network devices, but also a
consistent, semantically enriched naming and addressing
scheme, as well as specific middleware services and
components. Further information and details are reported
in [21], [22], and [23].
In the following we focus on the IoT@Work ENS
middleware components.
3.2. ENS Motivation
The IoT scenario presents the following substantial
differences as compared to previous scenarios:
 objects (sensors, PLCs, etc.) have more
computing and communication capabilities;
 objects have a more central role and are more
autonomous;
 communication patterns are more dynamic and
less statically defined.
In addition, the manufacturing environments are:
 becoming richer of intelligent devices and more
dependent on automation;
 becoming, from an ICT point of view, complex
distributed applications [24];
 moving toward an event-driven architecture in
which “… information can be propagated in
near-real-time throughout a highly distributed
environment, and enable the organization to
proactively respond to business activities”2 [6];
 subject not only to a substantial increase of the
number and nature of systems (e.g. monitoring
applications) interested to object's events, but
also to their dynamic changes for example to
support agile manufacturing;
 revising the management of data knowledge
(data meta-information) moving from a scenario
in which this knowledge is embedded in the
automation applications to a scenario in which
it is formalised and made available on request to
applications and services.
The above differences imply that the traditional
Automation Pyramid, in which there is a strict and static
2 Near-real-time here means that there are no significant delays
between the occurrence of an event and the availability of the
event related data for processing purposes. The delays, anyway,
have no predefined and fixed constraints
hierarchy that governs the data and control flows, has to
be revised giving more relevance to the events, to their
enrichment with meta-information and to more dynamic
and horizontal communication patterns (therefore more
in line with the Data Pyramid, as is usual for sensor
networks [25]).
The Data Pyramid [26] represents the process of
adding meta-information (context information) to move
from raw data to wisdom, adding first ontology
metadata, and then insights (i.e. reasoning capabilities).
As compared to current automation environment,
therefore, the meta-information, currently embedded
within each applications and communication patterns,
has to be factored out, formalised and provided in
addition to the data, so that each application can have
full opportunity to acquire and meaningfully process
data.
The responsibility to manage and provide both the
basic data (events in our environment) and the required
meta-information has to be awarded to a specific
middleware: this is exactly the role and objective of the
IoT@Work ENS middleware. Indeed, it addresses the
following IoT@Work specific requirements: smooth
scaling out; auditability and accountability;
interoperability; explicit representation of system set-up;
process-data provision/dissemination; event processing;
provision of semantically enriched events’ information;
run-time verification of system state.
3.3. ENS functionalities
The ENS is the IoT@Work middleware component
that acts as a common collector of events acquired from
disparate sources (called Event Publishers or simply
Publishers) and dispatched, in a controlled way, to a set
of listeners (called Event Subscribers/Consumers or
simply Subscribers/Consumers) as depicted in Figure 2.
The ENS functionalities can be summarised as
follows:
 asynchronous, fire-and-forget communication
patterns (publish/subscribe model);
 for manageability reasons, events are arranged
in distinct namespaces;
 event filtering capabilities;
 horizontal scalability and reconfiguration
flexibility;
 advanced namespaces access control features;
 events semantic;
 complete decoupling of publishers and
subscribers.
The ENS provides near-real-time3, one-to-many or
many-to-many communication facilities among
3 Real-time communication is normally used at production cells’
level (e.g. among PLCs and sensors/actuators) only. A full real-
time service providing the ENS features would put too many
constraints at network and system levels. PLCs, or equivalent
devices, can act as proxy systems between the real-time islands and
the other production systems and networks (as they currently do)
publishers and subscribers independently from their with no need to define ad-hoc extensions as it provides
location: the ENS middleware has to be normally an out-of-the-box flexibility.
deployed within a production plant and acts as a kind of AMQP provides more features (e.g.: interoperability
software bus connecting devices within the production of AMQP-based products, scalability) and functionalities
plant and both internal and external applications. Indeed, (e.g. event filtering capability) as compared to a JMS-
as depicted in Figure 2, even external applications, like based4 architecture solutions (e.g. ActiveMQ5). The
maintainers monitoring and supervising services, can AMQP envisages the concept of virtual host that is a
have controlled access to events’ subsets. fully functional AMQP broker hosted on a physical
AMQP server, which can host many distinct,
independent virtual hosts.
The ENS architecture, depicted in Figure 3, exploits
Maintainer Remote the AMQP features to provide scalability, asynchronous
Monitoring Service publish/subscribe communication, and clients
MES
Suppliers
partitioning.
Maintainer
SCADA
Adminitrative Domain Border

ENS

Events Str

Even

Eve
ts

n
n
ts

ts Str
Eve

ts S
en

s
Ev

t re
en

ea

eam
Ev

am
m
Network
Devices Energy Meters
PLCs CEP Engines
Energy Units
Production Devices
Reasoners

Figure 2. ENS middleware

The ENS, therefore, brings the data to the interested
parties, instead of bringing the parties to the data. This
reversed approach in data provision has significant
impacts both on the system’s security and on actually
controlling what data are provided to whom. Indeed,
applications and services (internal or external) have well
defined and controllable endpoints through which data
are provided; at the same time the data owner, as
reported in the following, can customize both the kinds
and the granularity of the data provided to each
applications and services.
3.4. ENS architecture
The ENS uses the AMQP (Advanced Message
Queuing Protocol) protocol and architecture [27], which
recently has been taken in charge by the OASIS
standardization organization (http://www.oasis-
open.org/committees/amqp), to provide some of its
features. AMQP is an open standard application layer
protocol for message-oriented middleware that defines
both:
 a model that introduces a general-purpose
modular framework that consists of components
that route and store messages and a set of rules
for connecting these components together;
 a network wire-level protocol that allows clients
to connect to servers to exchange messages.
By defining a model and a network-level protocol,
AMQP enables full functional interoperability between
complaint clients and messaging middleware servers.
Furthermore, AMQP general-purpose model and
protocol enables its usage in a large variety of scenarios
Figure 3. ENS Architecture
To improve access control without affecting ENS
operability, the ENS authentication and access control
checks are managed via a specific virtual host (Access
Request Broker Service in Figure 3), while actual events
processing and dispatching are managed by one or more
additional virtual hosts (ENS Broker Service in Figure
3). In this way the authentication and access control
overhead does not affect the events handling and ENS
can benefit of the AMQP scalability features for all its
functional elements.
All ENS clients (i.e. publishers or subscribers)
initially must submit their ENS access request via the
Access Request Broker Service to the ENS Authorization
Service that checks if the access request can be granted
and, in case, sets up the proper temporary configuration
(e.g. client’s specific AMQP Message Queue and
Binding for a subscriber client) on the appropriate virtual
4
JMS (Java Message Service) is described by the JSR914
specification and defines an API for Java Message Oriented
Middleware
5 See https://activemq.apache.org/
host and then returns to the client the information on the
operative virtual host to which to connect for publishing
or receiving events. Afterwards, the ENS client
communicates only with the indicated virtual host.
When the ENS client closes, regularly or irregularly,
its connection to the indicated virtual host, the temporary
configuration set up by the ENS Authorization Service is
automatically removed, therefore an ENS Client has to
redo its authorization process to connect again to the
ENS, therefore avoiding unauthorised access to the
production events.
The ENS Authorization Service checks the validity of
the submitted access request consulting the Policy
Decision Point which, on its turn, checks not only the
validity of the presented capability – the authorization
token specified in the presented access request and
described in Section 3.6 ENS access control – but also
that it has not been revoked querying the Capability
Revocation Service (for further details see Section 3.6
ENS access control below).
As already indicated, all published events are
3.5. ENS namespaces
As stated above, events are arranged in specific,
disjoint, hierarchical namespaces. The structure of each
namespace is independent from other namespaces and its
objective is to organize related events according to
production needs (for example creating a namespace
devoted to collect and manage all energy consumption
measures in a way that is functional to the energy
monitoring applications).
Each hierarchical namespace has a tree structure with
a Root Node, a set of Intermediate Nodes and Leaf
Nodes. Events are published under specific leaf nodes
that normally would a one-to-one relationship with a
publishing entity (e.g. energy monitored device), while
intermediate nodes can represent meaningful, from a
production point of view, collection of leaf nodes (e.g. a
production cell, a production line). Figure 4 provides an
example of a possible arrangement of an ENS
namespace devoted to the energy monitoring of a
production plant.
EnMonRoot

arranged in specific and distinct namespaces (see

Section 3.5 ENS namespaces below) in order to keep Production Line P1 ... Production Line Pn

together related events, simplify the authorization

mechanism (see Section 3.6 ENS access control below), Cell P1C1 ... Cell P1Cm ... ... ... Cell PnC1 ... Cell PnCs

and maximize the scalability and management of the Robots ... Conveyors ... ... ... ... ... ... Robots ... Conveyors

system (thanks to the possibility to assign/reassign

namespaces to different virtual hosts). Model NG-X1 ... Model NG-Xp ... ... ... Model NG-X1 ... Model NG-Xp ... ... ...

Therefore a virtual host can manage one or more P1C1Rob1 P1C1Rob2 P1C1Rob3 PnCsRob1 PnCsRob2 PnCsRob3

namespaces, while a namespace can be reassigned to a

different virtual host to balance the load on a virtual host
or physical server.
Each event managed by the ENS has a set of
attributes:
 Event Source ID: this attribute identifies the
publisher that has submitted the event to the
ENS;
 Event Timestamp: it reports when the event has
occurred (which can, in general, be different
from the publishing time);
 Event Semantic: this is an URI that points to the
meta-information (i.e. ontology) regarding that
kind of events;
 Event Data: this attribute carries the specific
value(s) of the event;
 Additional Event Specific Attributes: these are
attributes a publisher can add (for example an
energy meter, acting as publisher of energy
consumptions related events, can specify the ID
of the device to which the energy measures
refer).
Apart from the first three attributes, which are of
predefined types, the other elements can be of any type.
All elements anyway are completely transparent to the
ENS, therefore assuring that any kind of data can be
transferred.
Figure 4. Energy Monitoring Namespace
Each node in an ENS namespace has a set of
attributes like:
 Node Name: the identifier of the node;
 Node Description: a free-text describing the
entity represented by the node;
 EntityURI: a URI that points to a semantically
enriched description of the entity represented by
the node (for example for a Leaf Node
representing a sensor this URI can point to a
semantically enriched information regarding the
sensor);
 a URI that points to meta-data useful for
subscribing applications to properly manage
and process the published events (for example
for an energy monitoring namespace these
meta-information can detail the unit of measure,
accuracy, etc. of the published measured data).
Each source publishes its events under a specific leaf
of the hierarchical namespace. For example, with
reference to Figure 4, a SENTRON PAC3100 power
monitoring device that measures the energy
consumptions of robot P1C1Rob1 will publish its
measures under the “EnMonRoot.Production Line P1.
Cell P1C1.Robots.Model NG-X1.P1C1Rob1” leaf node.
 A subscriber application during the authentication
phase to the ENS must specify the namespace it wants to
connect to, as well as a node or a filter to identify a
subset of events it is interested to in that namespace. The
ENS will provide to the subscriber all events that belong
to the sub-tree identified by the specified node or
matching the provided filter.
A subscriber, therefore, can subscribe to a specific
node (e.g.: the Root Node, receiving all events in the
identified namespace, an Intermediate Node, receiving
all events published under the leaf nodes of that
intermediate node, or a Leaf Node), but also to filtered
subsets of the collected events.
For example, suppose an external supplier is
interested, and authorized, to monitor all energy related
events of all Model NG-X1 robots. In this case the
external supplier can be authorized to subscribe to the
energy monitoring namespace using the filtering
specification (see Figure 4):
EnMonRoot.*.Model NG-X1.*
A different subscriber interested in monitoring the
energy measures of all robots in “Production Line P1”
can subscribe to the energy monitoring namespace
specifying:
EnMonRoot.Production Line P1.*.Robots.*
The namespace concept and its subscription features
provide high flexibility and dynamicity to the ENS,
marking a big difference on other solutions for example
based on the JMS standard (e.g. solutions using
ActiveMQ).
Adding a new device to a manufacturing plant does
not impact the ENS or monitoring applications: it is
sufficient to provide, on the new added device side, the
information related to the topic under which it has to
publish the events and how to connect to the ENS, while,
on the monitoring applications side, the changes could
even not be required at all if the subscribing
applications/services have performed a namespace
subscription that already embraces the new device.
3.6. ENS access control mechanisms
The ENS access control is based on a Capability
Based Access Control mechanism (see [28], [29]) that is
being specifically developed in the IoT@Work project.
Capability Access Control, sometimes referred to as
capability based security, [30] “is […] one of the existing
security models. A capability (known in some systems as
a key) is a communicable, unforgeable token of
authority. It refers to a value that references an object
along with an associated set of access rights. […] A
capability is defined to be a protected object […] which,
by virtue of its possession by a user process, grants that
process the capability (hence the name) to interact with
an object in certain ways. Those ways might include
reading data associated with an object, modifying the
object, executing the data in the object as a process, and
other conceivable access rights. The capability logically
consists of a reference that uniquely identifies a
particular object and a set of one or more […] rights”.
Capability based security is not a new concept and
has been used in many contexts ([31], [32], [33]). In
traditional access control systems, like ACL (Access
Control List) based ones (RBAC/ABAC6), the
requesting subject has to assert his/her identity and
specify what he/she wants to do on what resource, while
the service provider has to check the ACLs to ascertain if
the subject has the right to perform the requested
operation on the specified resource. Figure 5 shortly
depicts the main differences between ACL- and
capability-based authorization systems.
R
R
Alice R /etc/passwd Alice /etc/passwd
W
R
Bob
W
/u/markm/foo Bob
R
/u/markm/foo
W R
Carol
R
/etc/motd Carol
R
W /etc/motd
R
R
Access Control List Capability List
Figure 5. Capability vs ACL access control
In capability based access control, therefore, the
subject has to include in his/her service request the
capability that asserts his/her rights on the resource and
demonstrate he/she is the owner of the presented
capability. The service provider has only to check that
the presented capability is valid and compatible with the
request, and that the granted subject, as stated in the
presented capability, is the subject that has submitted the
request. This solution is therefore more scalable, secure
and flexible and does not require complex federated
identity and access management systems.
The ENS capability based authorization approach is
based on ideas and approaches in the mentioned papers,
as well as in the “SPKI Certificate Theory” [34], with
extensions and adjustments to adapt the approach to the
IoT context and specifically to the IoT@Work ones.
As compared to the previous approaches, the
capability based authorization used in IoT@Work
provides the following additional features:
 delegation support: a subject can grant access
rights to another subject, as well as grant the
right to further delegate all or part of the
granted rights to a third subject;
 capability revocation: capabilities can be
revoked by properly authorized subjects,
therefore solving one of the issues of capability
based approaches in distributed environments;
and is able to meet the following requirements:
6 RBAC (Role-Based Access Control) and ABAC (Attribute-Based
Access Control) are widely used access control approaches
  easy support of the authorization needs of many
subjects (manufacturers, maintainers, etc.);
 easy control of the nature and characteristics of
the information made available through the
ENS;
 assurance that all subjects access ENS data with
the least privileges;
 high security and full auditability of resource
access even when rights have been delegated;
 offloading of access control management to
face external subjects dynamics.
3.7. Technologies and additional features
The ENS architecture eases the deployment of new
services and features simply connecting new applications
to it and instructing the ENS to provide only the
requested set of events.
A relevant example is predictive maintenance that can
be achieved connecting CEP (Complex Event
Processing) or semantic engines to the ENS middleware
and deploying specific programs (e.g. pattern-search
specifications on CEP engines) on these engines.
On the technological side, the IoT@Work ENS is
based on the RabbitMQ broker
(http://www.rabbitmq.com), which is one the most
accredited AMQP implementation and is being used, for
example, in cloud solutions like: OpenStack
(http://openstack.org), Heroku cloud application
platform (http://www.heroku.com), NASA Nebula
Cloud Computing Platform (http://nebula.nasa.gov).
RabbitMQ is written in the Erlang
(http://www.erlang.org) programming language which
has built-in support for concurrency, distribution and
fault tolerance.
The ENS authorization service is being developed as
an OSGi7 application, while the ENS client library is
being developed both as a traditional Java and OSGi
libraries.
4. Conclusions and future work
The previous sections have described the
functionalities and architecture of the IoT@Work ENS
middleware that act as a flexible and scalable connector
among events’ sources and events’ consumers. The ENS
is not only an asynchronous message-oriented server but
can be considered an active component of an Event-
Driven Architecture as it fully supports the key features
of that paradigm (e.g.: Broadcast communication,
Timeliness, Asynchrony, etc.).
7 The OSGi (Open Services Gateway initiative) framework provides
functionalities to create Java applications from small, reusable and
collaborative components, as well as to dynamically deploy and
manage, even remotely, them. The OSGi (http://www.osgi.org)
specifications are so widely applicable because the platform allows
multiple Java components to efficiently execute in a single Java
Virtual Machine
The ENS is pursuing the last research trends in
solutions for data collection in production systems (see
Section 2 Related work) proposing a solution able to
provide the following benefits:
 decoupling event collection and dispatching
from business-logic;
 improved security and data access control – as
stated, the IoT@Work approach brings the data
to the interested parties, instead of bringing the
parties to the data. This reversed approach
together with the capability based access
control mechanism, has significant impacts both
on the system’s security and on controlling
what data are provided to whom;
 scalability: the ENS, thanks to the use of
AMQP solutions, can be tuned in order to
efficiently support the increase of the event
producers (i.e. devices in the factory) and
consumers (i.e. monitoring applications);
 complex event processing and reasoning: the
events can be used to feed a Complex Event
Processing (CEP) engine which can be
programmed in order to support predictive
maintenance or other monitoring services.
The ENS is currently under development and will
soon be tested within specific validation scenarios the
IoT@Work consortium is setting up.
After completing the ENS development, it will be
extended via the integration of specific CEP engines for
implementing specific monitoring applications (for
example, energy consumption monitoring).
References
[1] H. Sundmaeker, P. Guillemin, P. Friess, S. Woelfflé
(editors), Vision and Challenges for Realising the
Internet of Things, ISBN 978-92-79-15088-3,
doi:10.2759/26127, March 2010.
[2] B. Kowalewski, M. Bubak, B. Balis, “An Event-Based
Approach to Reducing Coupling in Large- Scale
Applications”, Lecture Notes in Computer Science,
Springer, vol. 5103, pp. 358-367, June 2008.
[3] Z. A. Banaszak, B. H. Krogh, “Deadlock avoidance in
flexible manufacturing systems with concurrently
competing process flows”, IEEE Trans. on Robotics and
Automation, vol. 6, no. 6, pp. 724-734, December 1990.
[4] J. Park, S. A. Reveliotis, D. A. Bodner, L. F. Mcginnis,
“A distributed, event- driven control architecture for
flexibly automated manufacturing systems”,
International Journal of Computer Integrated
Manufacturing, vol. 15, no. 2, 2002.
[5] K. Walzer, J. Rode, D. Wunsch, M. Groch, “Event-
driven manufacturing: Unified management of primitive
and complex events for manufacturing monitoring and
control”, IEEE International Workshop on Factory
Communication Systems, WFCS 2008, May 2008, pp.
383-391.
[6] D. Chou, “Using Events in Highly Distributed
Architectures”, The Architecture Journal, Microsoft
Corporation, no. 17, October 2008.
[7] Rockwell Automation - Global Manufacturing Solutions,
“RFID in Manufacturing: A practical guide on extracting
measurable value from RFID implementations in plant
and warehousing operations”, October 2004.
[8] Y. M. Lee, F. Cheng, Y. T. Leung, “Exploring the
Impact of RFID Supply Chain Dynamics”, in Proc. 2004
Simulation Conference, vol. 2, pp.1145-1152, Dec. 2004.
[9] S. Toffaletti, J. Soldatos, “RFID-ROI-SME Project
Promises Big Help for Small Business”, RFID Journal,
June 14th, 2010.
[10] S. Karadgi, D. Metz, M. Grauer, W. Schäfer, “An Event
Driven Software Framework for Enabling Enterprise
integration and Control of Enterprise Processes”, in
Proc. 10th International IEEE Conference on Intelligent
System Design and Applications, Nov.-Dec. 2010, pp.
24-30.
[11] Y.H. Zhang, Q.Y. Dai, R.Y. Zhong, “An Extensible
Event-Driven Manufacturing Management with
Complex Event Processing Approach”, International
Journal of Control and Automation, vol. 2, no. 4, pp. 13-
24, Dec. 2009.
[12] J. L. Martinez Lastra, I. M. Delamer, “Semantic Web
Services in Factory Automation: Fundamental Insights
and Research Roadmap”, IEEE Transactions on
Industrial Informatics, vol. 2, no.1., pp. 1-11, Feb. 2006.
[13] L. Monostori, J. Váncza, S. R. T. Kumara, “Agent-Based
Systems for Manufacturing”, CIRP Annals –
Manufacturing Technology, vol. 55, pp. 697-720, 2006.
[14] V. Marik, J. Lazansky, “Industrial applications of agent
technologies”, Control Engineering Practice, Special
Issue on Manufacturing Plant Control: Challenges and
Issues, vol. 15, pp. 1364-1380, 2007.
[15] V. Marik, P. Vrba, K. H. Hall, F. P. Maturana,
“Rockwell automation agents for manufacturing”, in
Proc. 4th International Joint Conference on Autonomous
Agents and Multiagent Systems, pp. 107-113, July 2005.
[16] C. Popescu, “Approach to Incremental Modelling of
Web Services Orchestration - An Application to
Deadlock-free Scheduling in Automated Systems”,
Tampere University of Technology, Publication 832,
2009.
[17] A. W. Colombo, “SOCRADES: Steps Towards the
Factory of the Future”, Projects Magazine EU, edition
12, pp. 20-23. British Publishers Inc. 2009.
[18] J. Kaiser, C. Mitidieri, C. Brudna, C. E. Pereira,
“COSMIC: A middleware for event-based interaction”,
in Proc. 9th IEEE International Conference on Emerging
Technologies and Factory Automation (ETFA 2003),
vol. 2, pp. 669-676, Sept. 2003.
[19] T. Kirkham, D. Savio, H. Smit, R. Harrison, R. P.
Monfared, P. Phaithoonbuathong, "SOA middleware and
automation: Services, applications and architectures", in
Proc. 6th IEEE International Conference on Industrial
Informatics (INDIN 2008), pp. 1419-1424, July 2008.
[20] M. Marinov, N. Magaletti, T. Pavlov, F. Gaus, D.
Rotondi, P. Vitliemov, S. Ivanova, “An Approach to
Designing Distributed Knowledge-based Software
Platform for Injection Mould Industry”, WSEAS
TRANSACTIONS on INFORMATION SCIENCE and
APPLICATIONS, issue 11, vol. 7, Nov. 2010.
[21] D. Rotondi et al., “Project Deliverable D1.1 – State of
the art and functional requirements in manufacturing and
automation”, EU FP7 IoT@Work, public project
deliverable, Dec. 2011 (revised).
[22] A. M. Houyou et al., “Project Deliverable D2.1 – IoT
addressing schemes applied to manufacturing”, EU FP7
IoT@Work, public project deliverable, Dec. 2011
(revised).
[23] A. M. Houyou et al., “Project Deliverable D2.2 –
General bootstrapping architecture”, EU FP7
IoT@Work, public project deliverable, May 2011.
[24] P. Koen, C. Strömsdörfer, “Distributed Applications in
Manufacturing Environments”, The Architecture
Journal, Microsoft Corporation, no. 17, October 2008.
[25] A. Sheth, C. Henson, S. Sahoo, “Semantic Sensor Web”,
IEEE Internet Computing, pp. 78-83, July/August 2008.
[26] R. Akerkar, P. Sajja, Knowledge-Based Systems, Jones &
Bartlett Learning, ISBN 978-0-7637-7647-3, August
2009.
[27] AMQP Working Group, “Advanced Message Queuing
Protocol – Protocol Specification”. Available:
http://www.amqp.org/confluence/download/attachments/
720900/amqp.pdf?version=1&modificationDate=131801
1006000
[28] S. Gusmeroli, S. Piccione, D. Rotondi, “IoT Access
Control Issues: a Capability Based Approach”, to be
published in Proc. 6th International Conference on
Innovative Mobile and Internet Services in Ubiquitous
Computing (IMIS 2012), International Workshop on
Extending Seamlessly to the Internet of Things
(esIoT2012)
[29] D. Rotondi, C. Seccia, S. Piccione, “Access Control &
IoT: Capability Based Authorization Access Control
System” 1st IoT International Forum, position paper,
Nov. 2011.
[30] Wikipedia contributors, “Capability-based security”,
Wikipedia, The Free Encyclopedia.
[31] A. Lackorzynski, A. Warg, “Taming subsystems:
capabilities as universal resource access control in L4”,
in Proc. 2nd Workshop on Isolation and Integration in
Embedded Systems (IIES 2009), pp. 25-30, April 2009.
[32] G. D. Skinner, “Cyber Security Management of Access
Controls in Digital Ecosystems and Distributed
Environments”, in Proc. 6th International Conference on
Information Technology and Applications (ICITA 2009),
pp. 77-82, Nov. 2009.
[33] L. Fang, D. Gannon, F. Siebenlist, “XPOLA – An
Extensible Capability-based Authorization Infrastructure
for Grids”, 4th Annual PKI R&D Workshop, April 2005.
[34] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas,
T. Ylonen, “IETF RFC 2693 - SPKI Certificate Theory”,
Sept. 1999.
[35] G. Hohpe, “Programming Without a Call Stack – Event-
driven Architectures”, 2006.
[36] I. M. Delamer, J. L. M. Lastra, “Service-Oriented
Architecture for Distributed Publish/Subscribe
Middleware in Electronics Production”, IEEE
Transactions on Industrial Informatics, vol.2, no.4,
pp.281-294, Nov. 2006