2015 18th International Conference on Intelligence in Next Generation Networks
Industrial application development exploiting IoT
Vision and Model Driven programming
Conzon D., Brizzi P.,
Pramudianto F.
Kasinathan P., Pastrone C.
Fraunhofer Institute for Applied
Pervasive Technology Area (PerT),
Information Technology FIT
Istituto Superiore Mario Boella (ISMB)
Schloss Birlinghoven,
Via P.C. Boggio 61, 10138 Torino, Italy
53754 St. Augustin, Germany
{brizzi, conzon, kasinathan, pastrone}
ferry.pramudianto@fit.fraunhofer.de
@ismb.it
AbstractIn recent years there has been a huge discussion about
the IoT (Internet of Things) concept, and even more about IoT within
industrial environment. The real IoT is a network of devices with
local intelligence (sensors, lights, gas pumps, HVAC systems), which
shares access & control mechanisms to push and pull status and
command information from the networked world. However, there are
still some issues, limiting the IoT diffusion: the devices involved are
heterogeneous, with proprietary system of chips, protocols and
interface; furthermore, there is a lack of development toolkits,
enabling developers to create and evaluate IoT prototypes in simple
and flexible manner. The ebbits [1] platform addressed those issues,
taking advantages from the IoT vision and providing a middleware
infrastructure for the integration of heterogeneous industrial devices
and sensors, transforming them into web services and thus enabling
their seamless integration into existing legacy systems. This paper
will introduce the platform and its software architecture, describing
features like semantic devices interoperability and entity
virtualization. Furthermore, the paper will describe an innovative,
IoT oriented, model driven development toolkit. This toolkit
leverages on the semantic discovery service, allowing to dynamically
selecting and locating available resources or devices, and provides a
flexible instrument, including a graphical interface, that enables
developers to compose mashup applications.
Keywords ebbits, Internet of Things People and Services,
Middleware, Model Driven Development.
I. INTRODUCTION
The IoT is the current vision for a future Internet
encompassing any IT artefact, information source, and
recently, even people and services. The IoT vision has found a
breeding ground also in the industrial ecosystem, where it is
used to talk about CPS, standing for Cyber-Physical System,
or CPSoS (CPS of Systems). However, CPS properly refers to
next generation embedded systems that are interconnected to
perform advanced and automated controls. CPSoSs, instead,
are complex architectures, able to manage multiple CPSs.
Bringing the IoT in the manufacturing environment, firstly
means to deal with crucial issues like privacy, safety, security,
usability and adaptability plus other physical requirements like
limited power consumption, small dimensions and higher
computing power, generally making devices "smarter,
endowed with monitoring, actuation and data gathering
This work is part of the Integrated European project ebbits, co-funded by
the European Commission within the 7th Framework Program, ICT-2009.1.3
Internet of Things and Enterprise environments, grant agreement No. 257852.
978-1-4799-1866-9/15/$31.00 2015 IEEE
Cultrona P.
Comau S.p.a.
Via Rivalta, 30
10095 Grugliasco, Italy
pietro.cultrona@comau.com
functions [1]. On the other hand, shifting to the IoT means to
add, to already existing CPSs or CPSoSs, those features
properly to the internet world; themes like naming &
addressing and search & discovery, which today are addressed
by almost all relevant IoT projects [3]. The ebbits project [1] -
Enabling business-based Internet of Things and Services - in
the scope of this paper, has been aimed to addressing all those
issues, specifically developing architecture, technologies and
processes, which allow to integrate the IoTPS (Internet of
Things People and Services) into mainstream enterprise
systems and support interoperable real-world, online end-to-
end business applications.
The ebbits platform features a SoA (Service-oriented
Architecture), based on open protocols and middleware, which
simplifies the development of applications for on-line
monitoring of the production processes and the products
themselves, throughout the entire product life cycle. Even if
the middleware introduction aims to simplify the development
of such IoT based application, there is another significant
requirement that comes from the users perspective: today the
developer finds relevant difficulties while dealing with the
actual deployment of IoT apps, especially in complex and
sensitive scenarios, such as the manufacturing industry.
Indeed, the developing process is a tedious task, requiring
expertise in disparate fields (various sensor components,
network protocols, data format, data management and so on).
Additionally, the design of the existing IoT development
platforms supports mainly vertical scenarios, like embedded
system management or enterprise applications. Consequently,
the creation of a simple IoT prototype requires merging
different heterogeneous tools and programming platforms,
thereby increasing time, effort and development costs.
This paper extends the work reported in [4], which
proposes the description of the ebbits platform. [4] focused on
new approaches to be used in factory automation and on
techniques used for energy consumption optimization and CO2
reduction on the top of the ebbits middleware, also proposing
prototypes (a single-stage energy and water usage monitor, a
welding robot remote control app and a WSN-based robot arm
acceleration monitor interface). In this paper, authors aim to
168
 2015 18th International Conference on Intelligence in Next Generation Networks
add details regarding the latest ebbits middleware progresses
and propose a model driven development toolkit that allows
inexperienced developers to discover and compose distributed
devices and services into mashups [5]. The modeling tool
proposed allows operators to model the integration of IoT
components visually and programmatically, transforming the
model into actual source code, executable as a standalone
application, with software interfaces selectable during
prototype modeling.
The organization of the rest of the paper is the following.
Section II summarizes the ebbits platform architecture,
particularly describing the middleware architecture, the PWAL
(Physical World Adaptation Layer) development and other
relevant components. Section III describes the application
scenario and Section IV introduces the model driven
development approach focusing on mashup development,
semantic discovery, the proposed model driven tool and a
usability evaluation of it. Finally, authors hand out of their
conclusion in the section V.
II. EBBITS PLATFORM
Ebbits provides semantic resolution to IoT and hence
presents a new bridge between backend enterprise
applications, people, services and the physical world, using
information generated by tags, sensors, and other devices and
performing actions on the real world. The platform is based on
a SoA, so virtualizing every device into a service. The SoA
approach will allow these services to semantically discover,
configure, and communicate with each other. Furthermore, the
ebbits platform aims at supporting interoperable applications
to process context-aware data, separated in time and space,
acquiring information and real-world events and to handle end-
to-end business workflows, including comprehensive
consumer demands. The ebbits platform enables these main
innovative features:
Physical world sensors and networks - supporting semantic
interoperability between heterogeneous physical world
technologies and the enterprise systems, also outlining
scalable network architectures and featuring opportunistic
communication paradigms.
Entity Virtualization - realized through an addressing layer
based on unique identifiers, it enables discovery features,
through semantic techniques and attribute-based services
descriptions.
Data and Event Management - providing a P2P (peer-to-
peer) Event Management Architecture, which leverages on
the publish & subscribe communication paradigm to
handle rule-based service orchestration.
Centralized and Distributed Intelligence - allowing the
definition of data fusion frameworks and adopting
ontology-based context models to promote self-awareness
mechanisms.
Semantic Knowledge Infrastructure - Connecting many
conventional data sources to semantic models, with support
of hybrid querying and real-time reasoning.
169
Frameworks for Business Process Life Cycle Management
- includes process taxonomy and optimization metrics.
The ebbits project advances the LinkSmart middleware, the
main result of an EU project called Hydra [6], described in
subsection B. It combines a service-oriented architecture, peer-
to-peer networking technologies and semantic Web Services,
addressing the interoperability issue. On the top of LinkSmart,
the ebbits platform builds its five main layers:
Physical World - Composed by the actual devices of the
physical world, including PLC, robot arms, wireless sensor
devices, etc.
Internet of Things - Enables the physical world devices by
exposing their functionalities in the platform and providing
metadata for physical world devices.
Internet of Services - Provides services for managing the
IoT devices at a higher level, for example handling events
and context data.
Business System Mediation - Provides higher-level
services, interacting with external services, like legacy
business systems or ERP.
Inter Business layer - provides inter connectivity for
different ebbits based systems.
Besides these main layers, there is an adaption layer
between Physical World and Internet of Things, described in
the next subsection.
A. Physical World Adaption Layer (PWAL)
The PWAL is the adaption layer between the Physical
World sensors and Internet of Things platform, used to provide
a common way to interconnect physical entities (including
sensors, devices, protocols and communication channels),
which are not part of LinkSmart or of other ebbits components.
An initial architecture of the PWAL has been already
introduced and published [4]. This work adds several
enhancements and describes in detail the final software
architecture. The main role of the PWAL is to abstract any
device connected to the platform, exposing its capabilities and
output data and hiding the specific implementation details
(hardware and software). Specifically, the capabilities exposed
are the events generated, the services offered and the direct
access to information stored into hardware resources. In this
way, the application that uses the device can interact with it,
without knowing details about its implementation. The
capabilities of the device are exposed through the PWAL
driver, which provides, on one side, an abstraction to the
device specific technologies and, on the other side, a uniform
interface for other ebbits components, ensuring that devices
can be integrated seamlessly with the other IoT components of
the platform. Figure 1 shows the PWAL architecture, which is
based on three separated Java components:
The PWAL framework - It is the core of the architecture,
the entry point by the applications using it. This component
provides the list of the drivers currently available and
allows to actually handling them.
 2015 18th International Conference on Intelligence in Next Generation Networks
The PWAL API - It is the component that contains the
interfaces, which have to be used by the developers, in
order to develop new drivers. It contains the basic structure
for the drivers, which allows to simply exposing events
generated, services provided and data polling. This
component contains also all the models, basic structures of
generic drivers, to be used as reference developments and
then specialized by the developers. The version of the
PWAL described in this paper does not interact with the
ontology model of LinkSmart detailed in section IV.D. The
integration and harmonization of the two models is one of
the tasks already planned for the future developments of
the platform.
The PWAL drivers - Separated components, with a
common structure (interfaces defined in the API), which
control the physical resources. Every driver, when started,
registers itself on the PWAL framework, in order to
maintain the list of available drivers always updated. A
PWAL driver is a piece of software that communicates
with the physical device using device specific technology
and exposes standard interfaces for the ebbits platform.
One of the main features provided by a PWAL driver is to
offer a common interface for a group of similar devices: for
example, all temperature sensors can be modeled as a
device that exposes a getTemperature() service to retrieve
the measure (including any other additional services or
data). The example done for the temperature sensor is
extendible to any other device, for example, the driver
developed to control an RFID reader using the
EPCGlobals Low Level Reader Protocol (LLRP) can be
used to control every reader compliant with this protocol.
The PWAL is responsible to detect the presence of new
devices and services in the physical world. To fulfill this task,
it contains a set of Discovery Managers, one for each
technology (such as Bluetooth, 6LowPAN and so on), because
they work on low-level protocol and for this reason must be
very specific for each technology used.
Leveraging this model it is possible to simplify both the
integration of a new device in the platform, and its use. When
a new device, of a certain type, has to be integrated, the
developer does not need to write from scratch the driver, but
he can use the model already implemented for that type of
device, and only the low-level part of the driver, needed to
communicate with the specific device, has to be written. In the
same time, the PWAL allows simply using a new integrated
device; indeed, if an application was already using another
device of that type, it can use the new one with the same
interface, without the need to know anything about its
implementation.
The architecture is based on the OSGi (Open Service
Gateway initiative) framework, a Java environment used to
dynamically control the life cycle of different Java modules. In
this way, there is loose coupling among the different
components and it is possible to install, start, stop and remove
at runtime the drivers, without the need to stop and restart the
entire platform. The PWAL is not tightly coupled with the
platform using it. In this way, this component, integrated in the
170
Figure 1: PWAL architecture
ebbits platform, eventually can also be used with other
solutions, without doing major modifications. The interface
between the PWAL and the platform is the Internet of Things
layer of ebbits. This layer includes the DDM (Device
Discovery Manager) and the DP (Device Proxy). The DDM
uses the LinkSmart device ontology to instantiate proxies.
A proxy is a piece of software, which communicates with
the PWAL driver and exposes its features to other ebbits
components, leveraging the LinkSmart features. The proxy
represents the physical device as a virtual device. The DP
includes Context Manager, which stores all information that is
not included in the raw data of the device (info like
measurement unit, reading frequency, error state, etc.). The
Context Manager in the Proxy provides and uses information
provided by Context Managers of higher level. Section C
describes more deeply the Context Manager, together with the
features of the main components of the ebbits platform.
B. The LinkSmart Middleware
LinkSmart [14] is an OSGi-based middleware for the
networking of heterogeneous systems through loosely coupled
web services. Its communication was originally based on
SOAP web services, but the last versions introduce a new
tunnel service, which offers querying for services through
parameterized URLs, paving the way for innovative SOAP-
less application. LinkSmart is composed by a set of system
components (called managers), there are mandatory
components, such as the Network Manager, which provides
the networking features; and, optionally ones, like Context
Manager or the Device Discovery Manager, which discovers
the new devices integrated in the LinkSmart network.
LinkSmart includes a set of ontologies. Particularly, the
Device Ontology describes the device related information; it
contains information about device type, model and
manufacturer; furthermore, the services provided by the device
are modeled using operation names, inputs and outputs. Both
 2015 18th International Conference on Intelligence in Next Generation Networks
the device types and the device services are organized into
taxonomy. The LinkSmart communication network was
originally based on the protocol JXTA (Juxtapose), which
creates an overlay virtual P2P network and allows different
peers to interconnect with each other, also if they are behind
firewalls and NATs, giving more interoperability. LinkSmart
supports two different communication paradigms, traditional
web services or publish-subscribe event management through
SOAP web services, as described in the section C - Event
Manager, together with a brief description of the main
platform components.
C. Platform components
The ebbits platform architecture (based on the LinkSmart
middleware) is composed by several system modules, each one
with specific functionalities. The main components are:
Network Manager: this component is the entry and exit
point of the LinkSmart middleware. There must be only
one instance of it, in every device, where the middleware is
running. This component provides the entry point of the
middleware as a Web Service interface. Furthermore, it
creates the overlay P2P network needed to interconnect the
components of the middleware. It provides the architecture
needed to address LinkSmart Web Services using unique
IDs and it provides the transport mechanism over the P2P
network, needed to invoke the LinkSmart Web Services
(SOAP Tunneling) using their IDs.
Ontology Manager: the purpose of this component is to
provide a unified interface for using the LinkSmart Device
Ontology and all related modules, within the LinkSmart
middleware. The manager maintains run-time instances of
the LinkSmart devices.
Context Manager: a unified interface to access the context
of entities in the environment, it decouples the application
from the context providers (sensors), which consequently
eases the application developer tasks. The context
management consists of an Entity Manager and Rule
Manager, both depending on the Event Manager to retrieve
sensor data from the proxies.
Entity Manager: exploits the Ontology Manager to retrieve
the metadata of the sensor readings, such as location,
measurement unit, reading interval, and other attributes.
This manager is responsible to store the current context
attributes of the entities. For this purpose, the developers
must define which entities and context attributes are to be
monitored by the Context Manager. The application
developers can define this in the header of the rules, which
then are passed to the rule engine. In this way, the Entity
Manager can monitor only the state of the system that is
needed, optimizing the performance of the Context
Manager.
Rule Manager: The Context Manager recognizes
situational context based on rules defined by the
developers and stored by the Rule Manager component.
The rules may also define a higher level of context
information, which must be inferred based on several
171
sensor information, and their semantics defined by the
ontology. In the rules, there is also the definition of action
that should be performed when certain context is
recognized.
Device Discovery Manager: it is the component in charge
to detect when new features of a device are exposed
(events generated, services offered, properties hosted) by
the PWAL. The DDM is in charge to group these feature in
a virtual device (the Device Proxy) that will be the
interface between the PWAL device driver and the other
platforms components.
Event Manager: it is the component used to implement the
publish-subscribe paradigm on the top of the functionalities
provided by the LinkSmart middleware. It provides an
application-level selected multicast that decouples senders
and receivers in time, space, and data (i.e., sender and
receivers do not need to up at the same time, do not need to
know each others network addresses and do not need to
use the same data schema for events they send). It leverage
on the JXTA Pipe Abstraction, which provide a virtual
connection between two pipes endpoints: the input pipe
and output one. Pipe connections are independent from
pipe location and connectivity, thus enabling to bypass
network issues like firewall or NAT. Publish-subscribe
mechanism is implemented through JXTA since a pipe
endpoint can subscribe to messages sent from a publisher
endpoint. Using this manager, the developers can create
applications based on asynchronous events; the Event
Manager can be used both to send events and to subscribe
itself to the topic of interest.
The information propagated through events, after being
acquired by the PWAL, create the basis for the decision-
making processes, which includes data fusion, situation
patterns recognition, complex event processing, analysis of
historical acquired data, etc. All these requirements need to
manage a large amount of information related to the devices
generating events or providing services for further processing
by event/service orchestration, decision algorithms or business
logics, which can require analysing historical data generated
by particular events. All parts of decision making process are
be supported by enriched semantic model listed before, that
enable a flexible knowledge representation of all included
events, roles, services and processes. After the description of
the platform, the next section explains the manufacturing
application scenario of ebbits.
III. APPLICATION SCENARIO
Current manufacturing management approach limitations
are resulting from the fact that automated productions are
divided into separated areas, dedicated to specific activities.
The only way to manage this separation, reflected by the actual
solutions in industrial automation is to have centralized
controls architectures, through a unique legacy management
system. In the car-manufacturing scenario [4], PWT (power
train machining and assembly) machines and systems are
specialized equipment for the production of cylinder heads,
 2015 18th International Conference on Intelligence in Next Generation Networks
engine blocks and transmissions, in metal cutting and assembly
processes, involving CNC (Computer Numerical Control)
machining and dedicated assembly solutions for engine and
transmission components, etc. Besides, a typical BWA (Body
Welding and Assembly) line consists of an intricate collection
of loaders, rollers, framers, elevators, conveyors and clamping
fixtures. This leads to the widespread use of robots for picking,
loading and welding, also requiring the involvement of human
operators, who typically provide the proper fit for most of the
bolt-on functional parts of the vehicle, with pneumatically
assisted tools. Consequently, the main weaknesses of present
manufacturing systems, which highly affect overall efficiency
and reduce competitiveness, are referred to the following
aspects:
Process integration: limited integration among the
processes involved in the engineering and management of
the plants.
Flexibility: inadequate flexibility of the production plant,
with limited capability for handling variations in product
mix and volumes.
Scalability and re-configurability: production systems are
not designed to be easily reconfigurable.
Manufacturing efficiency: the monitoring of productivity is
affected by low diagnostics capacity; there are usually no
efficient instruments to detect engineering errors and to
prevent installation problems, as well as efficient data
logging to enable predictive maintenance.
Ramp-up time: the time to reach full production capacity is
often too long and therefore too costly.
Furthermore, the actual connection between the various
production chain rings is based on obsolete bus-to-bus
communication, like through traditional RS-232/422/485 serial
communication channels or through bus converters. The
overall result is a limitation of reliability and configurability as
hundreds of conductors are required to route signals to the
central control chassis. Overall, this traditional approach is
cumbersome, relatively large and more expensive. Another big
problem is related to the software used for controllers. Due to
the lack of standard interfaces, different vendors have different
approaches for the development of various subsystems, and
integrating them has proven to be expensive and time-
consuming. To avoid the use of a centralized backplane based
system, it is important to localize control of devices
performing similar functions.
This DCS (Distributed Control System) architecture uses a
serial or parallel cable to link already digitized information,
from the point of use. With the enhanced possibilities provided
by the innovative and pervasive monitoring systems, the whole
plant will become a living organism, able to configure itself in
response to the internal and external environment and the
physical condition of the manufacturing equipment. All the
devices (such as robots, tools, handling systems, welding
guns), used in the plant, are able to collect energy consumption
data, and the operator does not have to retrieve information
manually, the processes have been simplified and the
172
probability of errors reduced. The devices connect to the plant
network and can be easily substituted during maintenance, if
necessary. The plant informatics infrastructure is able to
collect from the devices all data related to process activities,
energy consumption and quality indicators. Complex services,
distributed on the computer network, analyze and correlate the
data retrieved. In this way, it is extremely simple for the
operator to monitor the energy efficiency of each device,
correlating indicators, such as the production quantities, and
ultimately publish these data in the company's sustainability
reports. In DCS, analogue signals are quickly digitized and
functions that do not need to be centrally supervised are
localized. One of the main advantages of the usage of an IoT
platform like ebbits - in the manufacturing context is cabling
simplification: indeed cabling can be streamlined and
functional sub-systems can be modularized. These sub-systems
can be then plugged into bigger and more complex networks
hence simplifying system configuration. Furthermore, an
innovative management approach is enabled, thanks to the
inherently packet driven simplification obtained by the remote
monitoring of signals or control functions over a local area or
public network through the DCS architecture.
The software components previously described and the
depicted scenario are aligned with the ebbits project vision,
which foresees accordingly with the IoTPS paradigm - the
mutual integration of physical devices, system and components
with workflows, people, assets, data, information and
knowledge. This imply the directing feeding of legacy systems,
turning natively unrelated information into useful and value-
added business services. Usually, this integration requires the
development of use-cases-specific applications. This attitude,
driven by development simplification needs, is slowing down
the introduction of the IoTPS in the business ecosystem.
Finding a workaround of this constrains is challenging, while
developing IoTPS applications and platforms. In the next
section the authors provided their approach to this issue,
describing the model driven tool used to simplify the
deployment of the applications based on the ebbits platform
and also detailing the approach chosen to design this tool.
IV. MODEL DRIVEN APPROACH
To summarize, the ebbits platform provides features of
seamless integration of heterogeneous physical world devices,
exposing them as internet web services. However, in-depth
knowledge of wide range of technologies is required for the
application developers to use them appropriately, and a lack of
development toolkits enabling rapid prototypes creation has
been registered. More often, business scenario requires novice
developers to create prototypes within a short period. Usually,
these developers have very less domain knowledge; hence, it is
important to provide necessary toolkits for inexperienced
developers, to create good quality products within a short span
of time. To shorten the time taken for developing IoT
applications, ebbits has created a development toolkit based on
a model driven approach that allows novice developers to
create IoT applications and could provide information of the
physical world devices (such as location, shared resources,
 2015 18th International Conference on Intelligence in Next Generation Networks
Figure 2: Architecture of the IoTPS development toolkit
etc.). More specifically, the toolkit produces blocks of code
based on the input specifications provided to it.
The following subsection describes an introduction of the
advanced methodologies adopted to build this toolkit,
consisting of mashup development and semantic discovery
approaches followed by the architecture of the development
toolkit. Finally, the outcomes of the experiments conducted
with a range of application developers and their evaluation
results are described.
A. Mashup development and Rapid prototyping
Mashup development is a way of building web applications
rapidly by aggregating different data sources on the web, using
a graphical development interface. Mashup development is
less flexible than conventional programming language, since
the abstraction level of the components are quite high and
reveals less technical details, to ensure the simplicity of the
development. A MDD (Model Driven Development) toolkit
allows inexperienced developers to discover and compose
distributed devices and services into mashups. The modeling
tool allows developers to model the integration of IoT
components visually, using a graphical interface, and
transforms that model into a piece of java code, which can in
turn be extended by more experienced developers in the
further phase of the development. The generated source code
may also be executed as a standalone application, with
software interfaces that can be chosen during modeling the
prototype. A basic rapid prototyping tool architecture for IoT
had been proposed considering the unique perspective of
positions domain modeling and object virtualization in the
work [7]. In the next subsection, the description of the
approach chosen to achieve the semantic discovery is
provided.
B. Semantic Discovery
In [15] many different ontological approaches applied to
the IoT are presented, this section introduces the approach
adopted in the ebbits platform. Semantic devices are a logical
173
representation of devices from an applications point of view.
There is an ontology that represents the semantic devices, and
which can be queried by the applications. For example, tourists
visiting a harbor may request information about it, once they
are connected to the public network. LinkSmart [8] uses a
model-driven architecture to map descriptions of physical
devices to what they dubbed as semantic devices. The existing
semantic discovery approaches [9] assume that the
terminology used to describe devices is always consistent.
Even though, it is difficult to achieve in an Internet of Things
context, an approach for dealing with a situation where
different preferred terms are used for describing semantic
properties of the devices is adopted. This goes beyond the
state-of-the art of the current semantic discovery in the scope
of Internet of Things. After the introduction of the basic
concepts used to design the toolkit, the next subsection details
its architecture.
C. Architecture of MDD toolkit for IoT
Figure 2 illustrates an IoT ecosystem, in which several
applications can share applicable devices. Several service
providers may run their business by providing new services,
enabled by IoT such as providing real time air quality data,
traffic reports, tracking goods or products, and monitoring
public transportation. Application developers could subscribe
to the appropriate services and import them to acquire
contextual information for their systems.
In the ebbits scenario, the PWAL provides the software
components to interact with the sensors and actuators
(represented in the Figure 2 as PWAL proxies). The proxy
should offer the intended services that can be accessed
uniformly, without requiring the application developers to
have extensive knowledge about the devices communication
technology. Proxies must be annotated with semantic
information, such as the capabilities of the sensors, actuators,
and quality parameters that might be an interest of the
applications, such as the accuracy, precision, range, unit of
measurements, and offset. The higher-level component, the
 2015 18th International Conference on Intelligence in Next Generation Networks
Discovery Manager is utilized to discover these proxies using
the WS-Discovery protocol. Once it discovers the proxies, the
semantic information is extracted and used by the Discovery
Manager to update its knowledge base, which maintains the
global knowledge about devices in the network. An
administrator is in charge of validating the knowledge related
to connected devices and verifying whether they have been
correctly classified according to their device types and
attributes. Once the Device Discovery Manager learns about
the new connected devices, it, dynamically, obtains their
service URLs, later. These URLs are used to invoke their web
services for retrieving the metadata. The Discovery Manager,
then, extracts the device properties in a universal predefined
JSON formatted metadata and stores them in a local RDF
(Resource Description Framework) ontology, described in the
next subsection.
D. Ontology Design
The design of the base ontology should be both simple to
understand as well as generic enough to describe very distinct
devices, with an arbitrary number of classifications. To build
the base ontology, the elements in the universe of discourse
must be defined. The domain of interest includes devices that
can be described with certain metadata in the context of the
Internet of Things and an example adopted in this work is
depicted in Figure 3.Given that in the IoT context, different
device developers may use different terminologies to describe
equivalent device features, the metadata should be pre-
processed, before adding it to the ontology, so that the
terminologies can be homogenized first. This homogenization
is a best effort solution to associate together terms that have
equivalent meanings.
E. Model Driven Development for IoT
The model driven tool's goal is to map sensors and
actuators into domain objects based on the IoT Meta model as
defined in the IoT ARM (Architecture Reference Model) [10].
For example, the physical objects have physical qualities (e.g.
temperature) that can be measured by a sensor (e.g.
thermometer). A physical object could also offer services, such
as delivering information about itself or could perform actions
that influence the environment including its own physical
qualities. To perform an action, services must use actuators.
Based on this conception, the model driven tool allows
developers to model the mapping between data sources such as
physical sensors, web services, to a physical quality of an
object. Based on this mapping, the tool will automatically
generate a java application that consists of java objects
representing the physical objects, the connection to the data
sources and their mapping with the properties of the objects.
The output components define how the virtual objects should
be exposed to the external applications. At the moment,
several implementations including relational database entries,
SOAP, and REST based web services are supported. For
instance, the SOAP based Web service provides a method to
get different objects based on their classes. Similarly, to
SOAP, the REST component represents the virtual objects as
web resources that can be retrieved as an XML or the more
174
Figure 3: The ontology used for maintaining the knowledge of the
available devices
popular JSON data format. It generates specific URLs for each
class of objects. When developers generate the java code, the
tool generates a controller class named MainApp. It initializes
various objects of predefined classes such as Connections,
Sensors, SensorFusion, VirtualObject, VirtualObjectFactory,
and Outputs. The connection objects are responsible for
building connection to the physical devices or data sources
such as web services. The connection classes are implemented
specifically for each data source. The incoming data is then
passed to sensor fusion modules to be processed before it is
next assigned to a property of a Virtual Object. The next
subsection contains an evaluation of the tool done by a group
of developers, to test its usability.
F. Evaluation and Impacts
To perform a usability evaluation of the proposed system, a
human-in-the-loop approach [16] has been implemented to test
the model driven tool and the semantic discovery method. The
first study was conducted at the end of the first iteration of the
model driven development, which results has been published
in [7]. Further improvements were performed after
incorporating some of users suggestions obtained in the first
study and than evaluated again by a group of computer science
students, with valuable expertise of java developments. They
received a development task related with the monitoring of
environmental conditions, such as temperature, humidity, and
occupancy in an office, using a mobile application for IoT. For
the intended tasks, the achieved results have shown that is
possible, on average, to reduce 44% of the development time
and 48% of mistakes, comparing developments provided by
user which used the traditional programming and ones which
used the approach here proposed. This shows that model
driven approach is faster and less error prone than writing a
java code for linking components with a high level of
abstraction. Later, they were given a questionnaire with
questions extracted from IBMs PSSUQ (Post-Study System
Usability Questionnaire) [11] to evaluate the model based on
several criteria such supporting documents provided, ease of
learn and use, efficient task completion and expectation vs
satisfaction. These participants were exposed to most of the
 2015 18th International Conference on Intelligence in Next Generation Networks
system functionalities and they had the chance of taking the
roles of device developers, administrators and application
developers to see how the flow of information affects each of
them, from the different interfaces to the system. A
questionnaire was given to them in order to find out their
impressions about the complete system. The extract of the
IBM's PSSUQ used in this evaluation consisted of 14
questions. These 14 questions were classified in 4 groups:
"Ease of use", "Efficient task completion", "Information
provided" and "Expectation vs. Satisfaction". Within each
group, the ratings of the different questions were averaged.
The least number represents the best achievement of the
proposed toolkit for IoT. Several similar studies were done to
achieve the overall system evaluation and all of the results
show medians between 2.3 and 2.6 out of 7 as shown in Figure
4, achieving good acceptance for the overall system prototype.
Figure 4: Acceptance of the overall system prototype
V. CONCLUSION
The enormous expertise and efforts required for deploying
innovation, like the here presented IoT platform, creates a
significant barrier for the evolution of todays factory to the so
coveted Factory of the Future. This paper has pointed out the
characteristics of the overall ebbits platform, mainly
describing how the middleware approach should simplify the
exploitation of an IoT-driven innovation into a real
manufacturing environment. The development toolkit
proposed aims at supporting inexperience developers in
rapidly building IoT prototypes, using a model driven
development approach, which has been evaluated involving
real developer and experts. The assessment of the method has
been achieved in separate iterations, through a human centered
design approach, which has been resulted into a promising
high acceptance by the end-users. A valuable qualitative
feedback from the participants has been obtained, such as a
high usability and a negative feeling of wasting time while
organizing the graphical elements. High experienced
developers have raised another interesting feedback since there
are users that still prefer the traditional direct coding approach.
The ebbits project has today addressed another valuable
use case regarding food traceability, published in [12]. The so [14]
positive results achieved in both the manufacturing and food [15]
scenario have been the reason why the project is going to be
[16]
extended, with the objective to enrich and optimize, as well as
further deploy and test, the ebbits platform and related tools.
175
ACKNOWLEDGMENTS
The authors want to thanks the large number of public
researches and all the open source developments, which
facilitated this work. A special thanks to the entire ebbits
consortium, for such productive and effective collaboration.
REFERENCES
[1] ebbits [Online]. Available: http://www.ebbits-project.eu/news.php.
[2] Various authors, CPS Methods and Techniques, Cyber-Physical
European Roadmap & Strategy, 2014. [Online]. Available:
http://www.cyphers.eu/sites/default/files/D4.1.pdf. [Accessed: 29-Mar-
2014].
[3] J. Soldatos and Antonio Skarmeta and c.pastrone and et.al, Catalogue
of IoT Naming , Addressing and Discovery Schemes in IERC Projects,
IERC. [Online]. Available:
http://www.theinternetofthings.eu/sites/default/files/%5Busername%5D/
IERC-AC2-D1-v1.7.pdf. [Accessed: 29-Mar-2014].
[4] P. Brizzi, D. Conzon, H. Khaleel, R. Tomasi, C. Pastrone, A. M. Spirito,
M. Knechtel, F. Pramudianto, and P. Cultrona, Bringing the Internet of
Things along the manufacturing line: A case study in controlling
industrial robot and monitoring energy consumption remotely, in 2013
IEEE 18th Conference on Emerging Technologies & Factory
Automation (ETFA), 2013, pp. 18.
[5] D. Benslimane, S. Dustdar, and A. Sheth, Services Mashups: The New
Generation of Web Applications, IEEE Internet Comput., vol. 12, no.
5, pp. 1315, Sep. 2008.
[6] A. Badii, M. Crouch, and C. Lallah, A Context-Awareness Framework
for Intelligent Networked Embedded Systems, in 2010 Third
International Conference on Advances in Human-Oriented and
Personalized Mechanisms, Technologies and Services, 2010, pp. 105
110.
[7] F. Pramudianto, R. I. Indra, and J. Mathias, Model Driven
Development for Internet of Things Application Prototyping, in The
25th International Conference on Software Engineering and Knowledge
Engineering. 2013. Hyatt Harborside at Logan Intl Airport, Boston,
USA: Knowledge Systems Institute Graduate School., 2013.
[8] S. Ben Mokhtar, P.-G. Raverdy, A. Urbieta, and R. S. Cardoso,
Interoperable Semantic and Syntactic Service Discovery for Ambient
Computing Environments, Int. J. Ambient Comput. Intell., vol. 2, no.
4, pp. 1332, 2010.
[9] A. Herzog, D. Jacobi, and A. Buchmann, A3ME - An Agent-Based
Middleware Approach for Mixed Mode Environments, in 2008 The
Second International Conference on Mobile Ubiquitous Computing,
Systems, Services and Technologies, 2008, pp. 191196.
[10] S. Bassi, A., Bauer, M., Fiedler, M., Kramp, T., Kranenburg, R., Lange,
S., Meissner, Enabling Things to Talk, in Springer Berlin Heidelberg,
2013.
[11] J. R. Lewis, IBM computer usability satisfaction questionnaires:
Psychometric evaluation and instructions for use, Int. J. Hum. Comput.
Interact., vol. 7, no. 1, pp. 5778, Jan. 1995.
[12] Brizzi, P., D. Conzon, F. Pramudianto, M. Paralic, M. Jacobsen, C.
Pastrone, R. Tomasi, and M. A. Spirito, "The ebbits platform:
leveraging on the Internet of Things to support meat traceability",
EFITA 2013, Torino, Italy, 06/2013.
[13] llrp standard [Online]. Available:
http://www.gs1.org/gsmp/kc/epcglobal/llrp.
LinkSmart [Online]. Available: https://linksmart.eu/redmine.
S. Gaglio, G. Lo Re, Advances onto the Internet of Things, in
Springer 2014
Christoph Evers, Romy Kniewel, Kurt Geihs, and Ludger Schmidt.
2014. The user in the loop: Enabling user participation for self-adaptive
applications. Future Gener. Comput. Syst. 34 (May 2014), 110-123.
DOI=10.1016/j.future.2013.12.010
http://dx.doi.org/10.1016/j.future.2013.12.010