![2 C. E. Palau et al.
Abstract INTER-IoT presents a novel layer-oriented solution for interoperability,
to provide interoperability at any layer and across layers among different IoT systems
and platforms. Contrary to a more general global approach, the INTER-IoT layered
approach has a higher potential in order to provide interoperability. It facilitates a
tight bidirectional integration, higher performance, complete modularity, high adapt-
ability and flexibility, and presents increased reliability. This layer-oriented solution
is achieved through INTER-LAYER, several interoperability solutions dedicated to
specific layers. Each interoperability infrastructure layer has a strong coupling with
adjacent layers and provides an interface. Interfaces will be controlled by a meta-level
framework to provide global interoperability. Every interoperability mechanism can
be accessed through an API. The interoperability infrastructure layers can commu-
nicate and interoperate through the interfaces. This cross-layering allows to achieve
a deeper and more complete integration.
1 Introduction
The connection of intelligent devices, equipped with a growing number of electronic
sensors and/or actuators, via the Internet, is known as the Internet of Things (IoT).
With the IoT, every physical and virtual object can be connected to other objects and
to the Internet, creating a fabric of connectivity between things and between humans
and things [1, 2]. The IoT is now widely recognised as the next step of disruptive
digital innovation.
The International Communications Union (ITU) and the European Research Clus-
ter on the Internet of Things (IERC) provide the following definition: IoT is a dynamic
global network infrastructure, with self-configuring capabilities based on standard
and interoperable communication protocols, where physical and virtual things have
identities, physical attributes and virtual personalities and use intelligent interfaces.
All of them seamlessly integrated into the information network [3].
The design of the Internet and specifically the extension of the Internet to the IoT,
rely on the convergence of the infrastructure with software and services. A common
practice is required to think/design cross solutions between software and infrastruc-
ture in order to provide integrated solutions for some of the complex problems in
the current and future systems. In the IoT environment this convergence is evident,
and the continuous evolution generates more and more smart connected objects and
platforms that are embedded with sensors and their respective associated services,
in some cases considering virtualization.
IoT is the network or overlay associations between smart connected objects (phys-
ical and virtual), that are able to exchange information by using an agreed method
(including protocols) and a data schema. IoT deployments are increasing, the same
applies to standards, alliances and interest for homogenization. All of this is giving a
strong push to the IoT domain to be considered as one of the most promising emerg-
ing technologies. As an example, Gartner (one of the world’s leading information
technology research and advisory company) estimates the number of web-connected](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-17-320.jpg)
![Introduction to Interoperability for Heterogeneous IoT Platforms 3
devices will reach 25 billion by 2020. In other words, more devices, appliances, cars,
artefacts, and accessories will be connected and will communicate with each other,
and with other objects, thus bringing amplified connectivity and better supply chain
visibility. The applications of the IoT are numerous i.e. every object could be trans-
formed into a smart object that sends several valuable information to other devices.
As an example, in the port industry IoT could be applied to shipping containers, the
equipment that handles them, the trucks that carry them and, even, the ships that
move them around the globe [4].
According to the European Commission (EC) the IoT represents the next step
towards the digitisation of our society and economy, where objects and people are
interconnected through communication networks, and report about their status and/or
the surrounding environment. Furthermore, IoT can also benefit the European econ-
omy generating economic growth and employment; according to a recent European
Commission study revenues in the EU28 will increase from more than e307 billion
in 2013 to more than e1,181 billion in 2020 [3, 4].
IoT is an emerging area that not only requires development of infrastructure but
also deployment of new services capable of supporting multiple, scalable and inter-
operable applications. The focus is today associated with cloud deployments, virtu-
alizations and the elimination of silos avoiding the existence of application domain
specific developments, AIOTI and EC are pressing in this line. IoT has evolved from
sensor networks and wireless sensor networks to a most clear description and def-
inition referring to objects and the virtual representations of these objects on the
Internet and associated infrastructures. It defines how the physical things and virtual
objects will be connected through the Internet and their interaction, and how they
communicate with other systems and platforms, in order to expose their capabil-
ities and functionalities in terms of services and accessibility through open APIs
and frameworks. IoT is not only linking connected devices by the Internet; it is
also web-enabled data exchange in order to enable systems with more capacities to
become smart and accessible, creating webs of objects and allowing integration of
data, services and components [5].
There are several challenges associated with IoT and its evolution, but one major
issue is related with interoperability [6–8]. IoT is mainly supported by continu-
ous progress in wireless sensor and actuator networks and by manufacturing low
cost and energy efficient hardware for sensor and device communications. However,
heterogeneity of underlying devices and communication technologies and interoper-
ability in different layers, from communication and seamless integration of devices
to interoperability of data generated by the IoT resources, is a challenge for expand-
ing generic IoT solutions to a global scale, with the further aim of avoiding silos
and provide solutions that are application domain agnostic, like those proposed in
INTER-IoT and that will be reflected in the rest of the book [9].](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-18-320.jpg)
![4 C. E. Palau et al.
2 INTER-IoT at a Glance
Achieving interoperability is one of the main objectives of the IoT. It is all about con-
necting things and make them easily accessible just like the Internet today. Broadly
speaking, interoperability can be defined as a measure of the degree to which diverse
systems, organizations, and/or individuals are able to work together to achieve a
common goal” [6]. However, interoperability is a complex thing and there are many
aspects to it. In literature, there exists quite a lot of different classifications of these
aspects of interoperability, often also called levels of interoperability. One of the
most important classification of levels of interoperability for technical systems is
called Levels of Conceptual Interoperability Model (LCIM). It defines six levels
of interoperability: technical, syntactic, semantic, pragmatic, dynamic and concep-
tual interoperability. INTER-IoT follows a similar layered structure, however the
approach has been different in terms of identification of the layers.
INTER-IoT as a whole has been the result of a Research and Innovation Action
under H2020 EC Framework Programme. The project has designed, implemented
and experimented with an open cross-layer framework, an associated methodol-
ogy and tools to enable voluntary interoperability among heterogeneous Internet of
Things (IoT) platforms (all these components will be reflected in the next chap-
ters of this book) [10]. The proposal has allowed effective and efficient develop-
ment of adaptive, smart IoT applications and services, atop different heterogeneous
IoT platforms, spanning single and/or multiple application domains. The project
will be tested in two application domains: transport and logistics in a port environ-
ment and mobile health, additionally it will be validated in a cross-domain use case
supported by the integration in the project of twelve third parties. The INTER-IoT
approach is general-purpose and may be applied to any application domain and across
domains, in which there is a need to interconnect IoT systems already deployed or
add new ones. Additionally, INTER-IoT is one of the seven RIAs and two CSA
composing IoT-EPI, supporting the creation of a European common space for IoT
interoperability [11–13].
INTER-IoT is based on three main building blocks, with different subcomponents
that have been identified and classified in different exploitable products adequate to
the needs of the different stakeholders involved in the project and also addressing
the main needs of the potential customers of the entities participating in INTER-
IoT. This three main building blocks, that will be further explained in the following
chapters of the book are:
• INTER-LAYER: methods and tools for providing interoperability among and
across each layer (virtual gateways/devices, network, middleware, application
services, data and semantics) of IoT platforms. Specifically, we will explore
real/virtual gateways, for device-to-device communication, virtual switches based
on SDN for network-to-network interconnection, super middleware for
middleware-to-middleware integration, service broker for the orchestration of the
service layer and a semantics mediator for data and semantics interoperability [11].](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-19-320.jpg)
![Introduction to Interoperability for Heterogeneous IoT Platforms 5
• INTER-FW: a global framework (based on an interoperable meta-architecture and
meta-data model) for programming and managing interoperable IoT platforms,
including an API to access INTER-LAYER components and allow the creation
of an ecosystem of IoT applications and services. INTER-FW will provide man-
agement functions specifically devoted to the interconnection between layers. The
provided API includes security and privacy features and will support the creation
of a community of users and developers [14].
• INTER-METH: an engineering methodology based on CASE (Computer Aided
Software Engineering) tool for systematically driving the integration and inter-
connection of heterogeneous non-interoperable IoT platforms [15, 16].
INTER-IoT provides an interoperable mediation component (i.e. INTER-LAYER
to enable the discovery and sharing of connected devices across existing and future
IoT platforms for rapid development of cross-platform IoT applications. INTER-
IoT allows flexible and voluntary interoperability at different layers. This layered
approach can be achieved by introducing an incremental deployment of INTER-IoT
functionality across the platform’s space, which will in effect influence the level of
platform collaboration and cooperation with other platforms. INTER-IoT does not
pretend to create a new IoT platform but an interoperability structure to interconnect
different IoT platforms, devices, applications and other IoT artifacts [11, 17].
Syntactic and semantic interoperability represent the essential interoperability
mechanisms in the future INTER-IoT ecosystem, while organizational/enterprise
interoperability has different structures/layers to enable platform providers to choose
an adequate interoperability model for their business needs. It will be supported by
INTER-FW that may allow the development of new applications and services atop
INTER-LAYER and INTER-METH, to provide a methodology in order to coordinate
interoperability supported by the definition of different interoperability patterns and
a CASE tool [16] (Fig. 1).
INTER-LAYER, which will be addressed in detail in Chap.4, is composed by
five layers, supported by cross-layer components as needed for the interaction of the
different layers:
• Device layer (D2D): At the device level, D2D solution will allow the seamless
inclusion of novel IoT devices and their interoperation with already existing ones.
D2D solution is a modular gateway that supports a vast range of protocols as well
as raw forwarding. It is composed on a physical part that only handles network
access and communication protocols, and a virtual part that handles all other
gateway operations and services (gw virtualization). When connection is lost, the
virtual part remains functional and is capable to answer the API and Middleware
requests. The gateway follows a modular approach to allow the addition of optional
service blocks to adapt to the specific case, allowing a fast growth of smart objects
ecosystems [18, 19].
• Network layer (N2N): N2N solution enables seamless Network-to-Network inter-
operability, allowing transparent smart object mobility, and information routing
support. It will also allow offloading and roaming, what implies the interconnec-
tion of gateways and platforms through the network. Interoperability is achieved](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-20-320.jpg)
![6 C. E. Palau et al.
Fig. 1 INTER-IoT concept and vision
through the creation of a virtual network, using SDN and NFV paradigms, with
the support of the N2N API. The N2N solution will allow the design and imple-
mentation of fully interconnected ecosystems, and solve the smart object mobility
problem [20].
• Middleware layer (MW2MW): At the middleware level INTER-IoT solution will
enable seamless resource discovery and management system for the IoT devices in
heterogeneous IoT platforms. Interoperability at the middleware layer is achieved
through the establishment of an abstraction layer and the attachment of IoT plat-
forms to it. Different modules included at this level provide services to manage
the virtual representation of the objects, creating the abstraction layer to access
all their features and information. Those services are accessible through a general
API. Interoperability at this layer will allow a global exploitation of smart objects
in large scale multi-platform IoT systems [21].
• Application and Services layer (AS2AS): INTER-IoT will enable the use of het-
erogeneous services among different IoT platforms. Our approach will allow the
discovery, catalogue, use and even composition of services from different plat-
forms. AS2AS will also provide an API as an integration toolbox to facilitate
the development of new applications that integrate existing heterogeneous IoT
services [22].
• Data and Semantics level (DS2DS): INTER-IoT guarantees a common interpre-
tation of data and information among different IoT platforms and heterogeneous
data sources that typically employ different data formats and ontologies, and are
unable to directly share information among them. INTER-IoT DS2DS approach](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-21-320.jpg)
![Introduction to Interoperability for Heterogeneous IoT Platforms 7
is the first solution that provides universal semantic and syntactic interoperability
among heterogeneous IoT platforms. It is based on a novel approach, a seman-
tic translation of IoT platforms’ ontologies to/from a common Central Ontology
that INTER-IoT employs, instead of direct platform-to-platform translations. This
technique reduces dramatically the number of potential combinations of semantic
translations required for universal semantic interoperability. INTER-IoT seman-
tic interoperability tools work with any vocabulary, or ontology. INTER-IoT own
modular Central Ontology, called GOIoTP, for all IoT platforms, devices and ser-
vices, is available at http://docs.inter-iot.eu/ontology. Also, syntactic translators
allow interoperability between different data formats, such as JSON, XML, and
others. Although the pilot deployments of INTER-IoT realize the Core Informa-
tion Model with Extensions approach to semantic interoperability, INTER-IoT
supports any solutions between its pilot approach and Core Information Model
[23, 24].
• Cross-Layer: INTER-IoT also guarantees non-functional aspects that must be
present across all layers: trust, security, privacy, and quality of service (QoS). As
well, INTER-IoT provides a virtualized version of the solution for each layer, to
offer the possibility of a quick and easy deployment. Security is guaranteed inside
each individual layer, and the external API access is securitized through encrypted
communication, authentication and security tokens. INTER-IoT accomplishes the
new European Data Privacy Law, and in the specific case of e-Health, in which
information is highly sensitive, the Medical Device Regulation law [11, 25].
And INTER-FW which provides the wrapping environment for INTER-LAYER
component coordination and new services development using INTER-API. Open
interoperability delivers on the promise of enabling vendors and developers to inter-
act and interoperate, without interfering with anyone’s ability to compete by deliv-
ering a superior product and experience. In the absence of global IoT standards, the
INTER-IoT project will support and make it easy for any company to design IoT
devices, smart objects, or services and get them to market quickly, and create new
IoT interoperable ecosystems. INTER-IoT may provide a solution to any potential
interoperability problem within the IoT landscape [13] (Fig. 2).
3 INTER-IoT Use Case-Driven
TheINTER-IoTapproachisusecase-driven,implementedandtestedinthreerealistic
large-scale pilots: (i) Port of Valencia transportation and logistics involving hetero-
geneous platforms with 400 smart objects; (ii) an Italian National Health Center for
m-health involving 200 patients, equipped with body sensor networks with wear-
able sensors and mobile smart devices and (iii) a cross domain pilot involving IoT
platforms from different application domains and enlarged by the collaboration of
the solutions associated to the different layers and sublayers from the third parties
that have attended the open call. The use cases are:](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-22-320.jpg)
![8 C. E. Palau et al.
Fig. 2 INTER-IoT layered approach
• INTER-LogP: The use of IoT platforms in the ports of the future will enable locat-
ing, monitoring, and handling different transport and cargo equipment and stor-
age areas. This use case will address the need to seamlessly handle IoT platforms
interoperation within port premises: container terminal, transportation companies,
warehouses, road hauliers, port authorities, customs, and outside the port [26].
• INTER-Health: The Decentralized and Mobile Monitoring of Assisted Livings’
Lifestyle use case, aims to develop an integrated IoT system for monitoring
humans’ lifestyle in a decentralized mobile way to prevent chronic diseases.
The aforementioned monitoring process can be decentralized from the health-
care center to the monitored subjects’ homes, and supported in mobility by using
on-body physical activity monitors [27].
• INTER-DOMAIN, composed by IoT platforms from the two application domain
oriented pilots and the IoT platforms and the specific layer-oriented solutions from
different application domains selected in the open call. SENSINACT and OM2M
platforms with Smart Cities orientation have been selected, and contributions from
the different layers may complement INTER-IoT [28, 29].
The project has analyzed requirements provided by the stakeholders of the project
and usability of the provided solutions from the perspective of IoT platform creators,](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-23-320.jpg)
![Introduction to Interoperability for Heterogeneous IoT Platforms 11
internal communication network and connects (more than 400) operating companies
in the port.
NOATUM provides the SEAMS platform to be included in the INTER-LogP use
case. SEAMS is an outcome from the Sea Terminals action (Smart, Energy Efficient
and Adaptive Port Terminals) co-funded by the Trans-European Transport Network
(TEN-T). It is an operational tool based on the reception of real-time energy and
operative data coming from the whole machinery and vehicle fleets of NOATUM
Container Terminal Valencia (NCTV). SEAMS integrates the whole set of machines
(including Rubber Tyre Gantry cranes (RTG), Ship-To-Shore cranes (STS), Terminal
Tractors (TT), Reach Stackers (RS) and Empty Container Handlers (ECH)) and
vehicles deployed and available in the terminal premises.
INTER-IoT will help to expand the possibilities offered by not only SEAMS and
the sensors installed on its own container terminal vehicles and container handling
equipment units, but also sensors available on third party equipment (i.e., reefer
containers) and vehicles (i.e., external trucks picking up and delivering containers).
Finally, it will allow installation of sensors on legacy equipment that does not have
them available. Moreover, INTER-IoT will allow to seamlessly connecting the con-
tainer terminal IoT ecosystem with other ecosystems owned by other parties, e.g., the
port authority, road hauliers, the individual trucks, vehicles, containers and vessels
through intelligent objects offered by different vendors, some of them managed by
the PCS [30].
On the other hand, UPV provided I3WSN, semantic IoT methodology and plat-
form deployed in application domains like factories, automotive and defence. This
generic architecture was developed within a large Spanish National project FASyS
and has been extended to be used in different areas like port transportation and
m-health. The framework provides interoperability at different layers and includes
reliability, privacy and security by design. Additionally, devices from the partners
will be added to the trials and devices from the users (e.g., truck drivers or terminal
operators) like smart phones will be added to the system following BYOD (Bring
Your Own Device) philosophy, allowing the integration of COTS devices in the large
scale trials.
Although the different platforms that the transport and logistics use case integrates
(in particular, IoT-PCS from VPF, NOATUM TOS, I3WSN UPV and the IoT plat-
forms from other stakeholders) share some characteristics, they have different aims
(i.e., focused on the particular benefits of the administrator/operator and use differ-
ent technologies). All of them gather data, using different M2M and P2M protocols;
some of them are cloud-based and others will be, but the most important thing is
that they lack interoperability in terms of the five identified layers. There is a poten-
tial integration using one of the platforms (i.e., IoT-PCS) as a matrix architecture;
however interoperability and integration will not profit the power of the proposed
approach neither the capabilities of interoperable architectures rather than intercon-
nected architectures. The use case, mainly focused in the transportation of containers,
as it is the most sensorized in port transportation (especially reefer and International
Maritime Organization—IMO safe containers), may improve efficiency, security and
benefits to the whole transport chain. Additionally, INTER-IoT will provide the pos-](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-26-320.jpg)
![12 C. E. Palau et al.
Fig. 3 INTER-IoT interconnection for m-Health (INTER-Health)
sibility to interact with other IoT platforms available in the port surroundings like
Valencia City FIWARE infrastructure (i.e., VLCi) that is an open platform that will
provide contextual information for different services and interactions at data and
services layers [31–33] (Fig. 3).
3.2 INTER-Health: Interoperability for Mobile Health for
Chronic Patients
The Decentralized and Mobile Monitoring of Assisted Livings’ Lifestyle use case,
aims at developing an integrated IoT system for monitoring humans’ lifestyle in a
decentralized way and in mobility, to prevent health issues mainly resulting from
food and physical activity disorders. Users that attend nutritional out-patient care
centres are healthy subjects with different risk degrees (normal weight, overweight,
obese) that could develop chronic diseases. Only the obese (in case of second and
third level obesity) need, at times, hospital care and get into a clinical and therapeutic
route. The medical environment in which the pilot will be developed and deployed
is the Dept. of Prevention/Hygiene Nutrition Unit at ASLTO5.](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-27-320.jpg)
![Introduction to Interoperability for Heterogeneous IoT Platforms 13
The use case will focus in the fact that in main chronic diseases, such as car-
diovascular diseases, stroke, cancer, chronic respiratory diseases and diabetes, there
are common and modifiable risk factors that are the cause of the majority of deaths
(and of new diseases). Between the common and modifiable risk factors there are
wrong lifestyles such as improper and hyper caloric diet and, in particular, the lack
of physical activity. Every year in the world (World Health Organization and others,
2013): 2.8 million people die for obesity or overweight; 2.6 million people die for
high cholesterol levels; 7.5 million people die for hypertension; 3.2 million people
die for physical inactivity. These wrong lifestyles are expressed through the inter-
mediate risk factors of raised blood pressure, raised glucose levels, abnormal blood
lipids, particularly Low Density Lipoprotein (LDL cholesterol) and obesity (body
mass index superior to 30kg/m2).
According to the reference standard medical protocol for the global prevention
and management of obesity, written by the World Health Organization, in order
to assess the health status (underweight, normal weight, overweight, obesity) of
the subject (of a given age) during the visit at the healthcare center, objective and
subjective measurements should be collected (and/or computed) by a health-care
team (doctor, biologist nutritionist, dietician, etc.). The objective measurements are:
weight, height, body mass index (enabling diagnosis of overweight and obesity),
blood pressure or waist circumference. The subjective measurements reported by the
subject, are collected through computerized questionnaires, and concern the eating
habits: quality and quantity of food consumed daily and weekly, daily consumption
of main meals (breakfast, lunch, dinner and snacks) and the practice of physical
activity (quality and quantity of physical activity daily and weekly). The physical
activity degree is detected subjectively during the first visit and could be objectively
monitoredthroughwearablemonitoringdevices.Onthebasisofthesemeasurements,
the caloric needs are automatically calculated, and the diet of the subject is defined.
From this point forward, the subject must be monitored periodically (for example,
every three months) for a period of at least one year. Usually monitoring is carried
out at the health-care center, where the objective and subjective measurements are
cyclically repeated. Based on the results, and depending on the health status reached
by the subject (improved or worsened), the possibility of redefining his diet and his
physical activity is analyzed.
By exploiting an integrated IoT environment, the aforementioned monitoring pro-
cesscanbedecentralizedfromthehealthcarecentertothemonitoredsubjects’homes,
and supported in mobility by using on-body physical activity monitors. Specifically,
the system will be created by using a new IoT platform, named INTER-Health,
obtained by integrating two already-existing heterogeneous, non-interoperable IoT
platforms for e-Health according to the approach proposed in the INTER-IoT project,
based on the INTER-FW and its associated methodology INTER-METH: (i) Uni-
versAAL, developed by UPV, and (ii) BodyCloud [34], developed by UNICAL.](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-28-320.jpg)
![14 C. E. Palau et al.
3.2.1 INTER-IoT Approach to INTER-Health
There is a need of integrating different IoT platforms as proposed in the INTER-
Health use case. The effective and efficient integration of heterogeneous e-Health IoT
Platforms will provide an appropriate answer to the challenges described in INTER-
IoT proposal. The two platforms considered are UniversAAL and BodyCloud, and
the result of the integration will allow developing a novel IoT m-Health system for
Lifestyle Monitoring [27].
This flexibility allows deploying universAAL-based solutions in multiple config-
urations, such as local-only nodes, mobile nodes connected to server instances, or
non-universAAL nodes connecting to a multi-tenant server. Communication between
applications and/or sensors happens through three different buses. Messages and
members are always described semantically using the domain ontologies at hand: (i)
Context bus—An event-based bus for sharing contextual information from context
publishers to context subscribers; (ii) Service bus—A request-based bus for on-
demand execution and information retrieval from service callers to service providers
and (iii) User Interface bus—A centrally-managed bus that allows applications to
define abstract interfaces to be rendered by different User Interface (UI) modalities.
In each bus, semantic reasoning is used to match the transferred messages to the
appropriate destination. This way, applications and sensors only need to describe
what they provide and what they require from others. There is no need to specify
recipients, connections nor addresses explicitly [30].
BodyCloud is a SaaS architecture that supports the storage and management of
body sensor data streams and the processing (online and offline analysis) of the
stored data using software services hosted in the Cloud. In particular, BodyCloud
endeavours to support several cross-disciplinary applications and specialized pro-
cessing tasks. It enables large-scale data sharing and collaborations among users and
applications in the Cloud, and delivers Cloud services via sensor-rich mobile devices.
BodyCloud also offers decision support services to take further actions based on the
analyzed BSN data [34].
The BodyCloud approach is centered around four main decentralized components
(or sides), namely Body, Cloud, Viewer, Analyst: (i) Body-side is the component,
currently based on the SPINE Android, that monitors an assisted living through wear-
able sensors and stores the collected data in the Cloud by means of a mobile device;
(ii) Cloud-side is the component, based on SaaS paradigm, being the first general-
purpose software engineering approach for Cloud-assisted community BSNs; (iii)
Viewer-side is the Web browser-enabled component able to visualize data analysis
through advanced graphical reporting; and (iv) e Analyst-side is the component that
supports the development of BodyCloud applications.
The two platforms, UniversAAL and BodyCloud, share some high-level charac-
teristics while differ in objectives and technology. Specifically, they are both e-Health
platforms, based on Bluetooth technology to interact with measurement devices, and
based on Cloud infrastructures to enable data storing, off-line analysis, and data visu-
alization. However, they have different specific objectives and are not interoperable
from a technological point of view (at each layer and at the global level). Their spe-](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-29-320.jpg)
![Introduction to Interoperability for Heterogeneous IoT Platforms 15
Fig. 4 INTER-IoT interconnection for m-Health (INTER-Health)
cific objectives are complementary: UniversAAL is focused mainly on non-mobile
remote monitoring based on non-wearable measurement devices, whereas Body-
Cloud provides monitoring of mobile subjects through wearable devices organized
as body sensor networks. Thus, their integration will produce a full-fledged m-Health
integrated platform on top of which multitudes of m-Health services could be devel-
oped and furnished. The use case will be fully deployable atop the integration of
UniversAAL and BodyCloud: (i) the automated monitoring at the health-care center
and the decentralization of the monitoring at the patients’ homes will be supported
by UniversAAL remote services; (ii) the monitoring of mobile assisted livings would
be enabled by the BodyCloud mobile services; (iii) new cross-platform services will
be developed for enabling complete analysis of the measurement streams coming
from assisted livings [28, 35] (Fig. 4).
4 INTER-IoT Progress Beyond the State of Art
The overall concept of the INTER-IoT project targets a full-fledged robust approach
for seamless integration of different IoT platforms within and across different appli-](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-30-320.jpg)
![16 C. E. Palau et al.
cation domains. Interoperability will be achieved at different layers, depending on
the requirements of the specific scenario or the use case. The main outcomes of the
project will be infrastructures for layer-oriented interoperability and a reference inter-
operable meta-architecture; an interoperability framework and an API along with an
engineering methodology driven by a toolbox to be used by third parties to integrate
heterogeneous IoT platforms and thus implement interoperable IoT applications.
INTER-IoT will focus on two application domains (m-health and port transportation
and logistics) and on their integration. The project outcome will optimize different
operations in these two domains and in their integration. However, the INTER-IoT
approach will be easily reused in any application domain, in which there is a need
to interconnect already deployed (heterogeneous) IoT platforms. Or even in cross
application domains, where IoT platforms and smart objects from different applica-
tion domains will require co-operation or interoperability between them. Based on
these principles, INTER-IoT targets the following innovations [5, 6].
4.1 Global Platform Interoperability
Global interoperability of hardware/software infrastructures is usually based on stan-
dards. However, as IoT is an evolving technology without specific central technical
coordination and control, it is foreseen that many solutions and (pseudo) standards
will be developed and proposed in the coming years. This will lead to massive hetero-
geneity. Indeed, currently many different (quasi) standards do exist in the IoT arena
addressing: communications, hardware, software, and data. However, they mainly
refer to specific IoT objects (sensors, sensor networks, RFID, nanocomputers, etc.)
or contexts (smart grid, health-care, logistics, etc.). From the communications view-
point, standards protocols at different level (MAC, network, application) are avail-
able: IEEE 802.11—WiFi, IEEE 802.16—WiMax, IEEE 802.15.4—LR-WPAN,
2G/3G/4G—Mobile Communication, Zigbee, Bluetooth, ANT+, NFC, M2M com-
munications (M-Bus, WM-Bus, UWB, ModBus, Z-Wave), M2M ETSI, IPv4, IPv6,
6LowPAN, TCP, UDP, ISO/IEEE 11073 for medical devices, CoAP, HTTP, MQTT,
XMPP, DDS, AMQP, Websocket, etc. From the hardware perspective, the techno-
logical state of the art is also heterogeneous: Arduino, BeagleBoard, TelosB sen-
sor mote, RaspberryPI, pcDuino, Cubieboard, Libelium sensor/gateway, etc. The
software realm is even richer including many base software technology (TinyOS,
Contiki, FreeRTOS, eCos, Android, Ubuntu, Java, WebRTC, REST, WAMP, Django,
etc.) and middleware solutions (FedNet, Ubicomp, SmartProducts, ACOSO, SkyNet,
etc.), including cloud computing-based infrastructures (Amazon EC2, Google App
Engine, Xively, MS Windows Azure). Also the data (and semantics) level presents
high heterogeneity: XML (and XML-based like WSDL), JSON, UDCAP, uCode
Relational Model, RDF, OWL, W3C SSN (Semantic Sensor Network) [4, 11].
It is worth noting that, when we consider a complete IoT platform, the complex-
ity of technologies used to build up the platform further arises as each defined layer
(device, networking, middleware, application service, data and semantics) exploits](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-31-320.jpg)
![Introduction to Interoperability for Heterogeneous IoT Platforms 17
specific solutions that need to be holistically adapted to form the final platform.
For instance, several available platforms, each of which was designed and deployed
to fulfil quasi similar goals but exploiting heterogeneous IoT technological solu-
tions, or providing any (or even limited) interoperability [36]. Thus, it is critical to
provide bottom-up “voluntary” approaches able to integrate, interconnect, merge,
heterogeneous IoT platforms to build up extreme-scale interoperable ecosystems on
top of which large-scale applications can be designed, implemented, executed and
managed [37].
INTER-IoT will provide the first full-fledged methodological and technologi-
cal suite to completely address the fundamental issue of “voluntary interoperabil-
ity”. The suite will be composed of three main building blocks: (i) Layer-oriented
infrastructures to adapt heterogeneous peer layers (device-to-device, networking-
to-networking, middleware-to-middleware, application services-to-application ser-
vices, data-to-data, and semantics-to-semantics); (ii) Interoperable open framework
to program and manage integrated IoT platforms; (iii) Engineering methodology
and tools to drive the integration process of heterogeneous IoT platforms. By using
INTER-IoT, IoT heterogeneity will be turned from the most limiting factor for
IoT technology diffusion to its greatest advantage due to the exploitation of spe-
cific benefits and characteristics derived from multiple heterogeneous IoT platforms
[15, 38, 39].
4.2 Gateway and Device Interoperability
As sensors, actuators and smart devices become smaller, more versatile, lower cost
and more power efficient, they are being deployed in greater numbers, either as
special-purpose devices or embedded into other products. The unification and con-
vergence of the vast number of platforms already deployed, the accessibility (API
and interfaces) of the platform to app developers, requires interoperability. Smart-
phones are key components in Device-to-Device (D2D) communication and interop-
erability, however there are many other types of devices that are currently deployed,
both independently (e.g. smart watches and other wearables) and as part of other
devices and platforms (e.g. consumer electronics or Cyber-Physical Systems). Dif-
ferent communication protocols are used at device level. Here, Cellular and WiFi
that are ubiquitous; they are evolving to support higher bandwidths and lower cost.
Bluetooth is also becoming lower cost. New communication technologies like Blue-
toothlowenergy(BluetoothLE)andNFCareopeningnewpossibilitiesforIoT.How-
ever, also traditional communication protocols and mechanisms for sensors, actua-
tors and smart objects have to be considered (e.g. ZigBee, ISA100, WirelessHart),
in addition to other non-standard proprietary protocols developed by individual ven-
dors, or even to new emerging protocols, e.g. [40, 41]. Different classes of IoT objects
need different communication supports: e.g. ‘deterministic’ communication proto-
cols (MAC and Routing layers) are not possible using current Internet protocols, but
may be needed by some application. Standardization on these topics is just starting](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-32-320.jpg)
![18 C. E. Palau et al.
(e.g., detnet working group in IETF). Yet, deterministic communications will hardly
meet the interoperability requirements of all IoT objects. Typically device-level inter-
connection of IoT architectures has been performed using gateway-based solutions.
FP7 Butler project proposed a device-centric architecture where a SmartGateway
allows interconnection between smart objects (sensors, actuators, gateways) using
IPv6 as communication protocol. Different approaches have been developed to inte-
grate and interoperate devices in IoT architectures. Basic devices (e.g. sensors, tags,
actuators) are virtualized and can be composed in more complex smart systems. The
idea has been to create virtual objects, allowing object composition, considering a
virtual object as a counterpart of existing smart objects [19, 42, 43].
INTER-IoT will provide fundamental benefits and competitiveness improvements
in the way IoT devices will communicate with each other and will interface with
different IoT platforms and subsystems. One of the proposed progresses regarding
D2D interaction is to complement standardized communication protocols (which
are mostly deterministic and reactive) with an ability for objects to make sense of
their surroundings in order to understand how to best interplay with their neigh-
bours. This requires new ‘proactive’ and ‘predictive’ communications capabilities,
whereby a node can determine its communication requirements and those of its
neighbours well before communication is required. It has recently been proven that
machine learning capabilities can run even on small sensors (with as little as 20
KB of RAM). INTER-IoT will develop an interoperable communication layer, even
based on lightweight machine learning that also accommodate for opportunistic com-
munications among heterogeneous nodes/devices, based on prediction mechanisms
[21, 44].
4.3 Networking Mobility and Interoperability
IoT products will encompass different data communication scenarios. Some may
involve sensors that send small data packets infrequently and do not prioritize timely
delivery. Others may involve storage in order to sustain periods when the communi-
cation link is down (e.g. Delay Tolerant Networks). Others may need high bandwidth
but be able to accept high latency. And others may need high quality, high bandwidth,
and low latency. Large amounts of traffic with relatively short packet sizes will require
sophisticated traffic management. More efficient protocols can help reduce overhead
but may present challenges to system integrity, reliability and scalability. Interface
standardization is desirable so that IoT objects can communicate quickly and effi-
ciently, and allow mobility between interoperable IoT platforms. IoT objects will
need a way to quickly and easily discover each other and learn their neighbour’s
capabilities [28, 45].
At networking and communications layer different protocols can be used like
6LowPAN, TCP/HTTP, UDP/CoAP. Communication between real objects and the
gatewaycanbebasedonuniversalplugandplay(UPnP)orDLNA.Useofbusesbased
on MQTT protocol can also be used to implement asynchronous communications](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-33-320.jpg)
![Introduction to Interoperability for Heterogeneous IoT Platforms 19
between entities. The most promoted networking protocol in IoT environments is
IPv6 and its version for constrained devices 6LoWPAN, even though its adoption is
slow, and without global adoption it will be impossible for IoT to proliferate. IPv6
provides the following benefits to IoT configurations: (i) IPv6 auto-configuration; (ii)
Scalable address space (sufficiently large for the enormous numbers of IoT objects
envisioned); (iii) Redefined headers that enable header compression formats; (iv)
Easy control of the system of things: (v) Open/Standard communications; (vi) IPv6 to
IPv4 transition methods; (vii) IPv6 over constrained node networks (6LO, 6LoWPAN
[11, 46].
IoT platforms have usually mechanisms for integrating with external systems, but
they are all based on specific point to point connections, usually with legacy systems
in the area of interest of the IoT platform (city, neighbourhood, factory, hospital, port,
house, etc.). The integration between IoT platforms will allow tracking the behaviour
of these objects when they move outside the intrinsic area of interest and get into the
area of interest of another IoT platform. The pub/sub mechanism usually available in
the communication buses at the core of these IoT platforms and the possible object
context sharing allow a powerful and easy way to track the behaviour of these objects
among different IoTs scope areas.
INTER-IoT will provide support for as many networks as possible, including as
many networks as possible in the INTER-FW definition. Main contributions of the
project will be focused to multihoming capabilities among the different IoT objects
in order to provide network offloading connectivity and seamless mobility between
different IoT platforms of moving objects. INTER-IoT will use SDN components
to configure interconnection at network level and also will use ICN/CCN as support
for interoperability and roaming of smart objects between different platforms of the
same ecosystem while keeping secure connectivity and also guaranteed quality of
service. Resource management and scalability so as reliability, trust, privacy and
security will be non-functional requirements that will be addressed by the project to
provide optimal interoperability at network layer [6, 30, 47].
4.4 Middleware Platform Interoperability
Middleware, widely used in conventional distributed systems, is a fundamental tool
for the design and implementation of both IoT devices and IoT systems. They pro-
vide general and specific abstractions (e.g., object computation model, inter-object
communication, sensory/actuation interfaces, discovery service, knowledge manage-
ment), as well as development and deployment tools, through which IoT devices,
IoT systems and their related applications can be easily built up. Indeed, middle-
ware (i) enable connectivity for huge numbers of diverse components comprised at
Device Layer, (ii) realize their seamless interoperability at Networking Layer, and
(iii) ensure operational transparency at Application Service Layer. In such a way,
heterogeneous, often complex and already existing IoT devices and IoT systems,
belonging to different application domains and not originally designed to be con-](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-34-320.jpg)
![20 C. E. Palau et al.
nected, can be easily integrated, effectively managed and jointly exploited. It follows
that the role of middleware within the cyberphysical, heterogeneous, large scale and
interconnected IoT scenario is even more crucial than within conventional distributed
systems. Over the years, many IoT middleware have been proposed, so much so that
only in [11, 34] more than 70 contributions have been surveyed and compared. The
best way to analyse such plethora of middleware, regardless of the specific detail
or technology, is to build up comparison frameworks around well-defined criteria to
effectively highlight their salient differences and similarities.
In very few words, LinkSmart is service-based middleware for ambient intelli-
gence (AmI) systems, supporting devices communication, virtualization, dynamic
reconfiguration, self-configuration, energy optimization and security by means
of WebService-based mechanisms enriched by semantic resolution. UbiROAD is
semantic, context-aware, self-adaptive agent-based middleware for smart road envi-
ronments, aiming at collecting, analysing and mining real time data from in-car
and roadside heterogeneous devices. ACOSO is an agent-oriented middleware with
a related methodology fully supporting the development (from the modelling to
the implementation phase), management and deployment of smart objects and IoT
systems, as well as their integration with the Cloud. IMPReSS, finally, is a mid-
dleware conceived for the rapid development of context-aware, adaptive and real-
time monitoring applications to control and optimize energy usage in smart cities
[2, 39, 48, 49].
In particular, INTER-IoT will focus on defining component-based methods for
middleware interoperability/integration; in particular, we focus on discovery, man-
agement and high-level communication of IoT devices in heterogeneous IoT plat-
forms. We will define two main approaches: (i) definition of overlay middleware
components able to couple the middleware components of the heterogeneous IoT
platforms; (ii) virtualization of the heterogeneous middleware components. In the
first approach, we will design overlay middle components such as mediators and
brokers [6].
4.5 Semantic Interoperability
Semantic interoperability can be conceptualized as an approach to facilitate “com-
bining” multiple IoT platforms. The simplest case, of combining two IoT plat-
forms, could be addressed by developing a one-to-one translator (a “gateway”)
to allow“semantic understanding” between them. However, this approach does not
scale, as for every subsequent entity joining an assembly of N platforms. Thus, N
translators would have to be created. The two main approaches to avoid this problem,
and deal with semantic interoperability are: (i) common communication standards;
(ii) ontology and semantic data processing [50]. Developing a common communi-
cation standard, is tried in the travel domain with the OTA message specification a
standard consisting on a set of (XML-demarcated) messages; or in the healthcare
domain (and thus related to the INTER-Health use case) with OpenEHR, which is an](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-35-320.jpg)
![Introduction to Interoperability for Heterogeneous IoT Platforms 21
opendomain-drivenplatformfordevelopingflexiblee-healthsystems.Here,multiple
projects strive to establish interoperability between already known standards and the
OpenEHR, e.g. establishing semantic interoperability of the ISO EN 13606 and the
OpenEHRarchetypes.SimilarlytheThink!EHRPlatform(healthdataplatformbased
on vendor-neutral open data standards designed for real-time, transactional health
data storage, query, retrieve and exchange); aims at establishing interoperability of
the OpenEHR and the HL7 standard (a framework for the exchange, integration, shar-
ing, and retrieval of electronic health information). Interestingly, development of the
Think!EHR Platform had to deal with the data standards problem caused by existence
of HL7 RIMv3, ISO13606, and OpenEHR standards. While it is possible to envision
an approach similar to this, applied to individual domains, it is not likely to be easily
generalizable to support interactions between domains. Therefore, approaches based
on ontologies and semantic data processing will be used in the project [51, 52].
INTER-IoT approach will be based on development of a generic ontology of an IoT
Platform (GOIoTP). The GOIoTP will be used as the centerpiece for establishing
platform interoperability (allowing for, among others, data interoperability, message
translation, etc.). It should be stressed that, state-of-the-art ontologies of the IoT, will
constitute the starting point for construction of the GOIoTP, needed in our project.
The proposed approach will require, (i) ontology matching, (ii) merging, noting that
ontology merging is often reduced to ontology matching, as well as (iii) techniques
for establishing semantic distance (needed for ontology matching). Observing that
this approach allows “understanding” and adaptability (handled through ontology
adaptation) of heterogeneous data [39, 53, 54].
The creation of GOIoTP in INTER-IoT, combined with the state-of-the-art
approaches to ontology matching/merging will allow development of a comprehen-
sive support for facilitation of semantic interoperability between IoT platforms. The
resulting approach, based on conducted research, will consist both of the methods
and supporting tools and will include, among others, methods for:
• Combining two (or more) IoT platforms with explicitly defined ontologies. Here,
among others, the following issues will be researched: (i) bringing multiple ontolo-
gies to a common format / language (for example, transforming XML into RDF and
further transforming it into OWL-demarcated ontology using XLST), (ii) ontology
matching, to allow for (iii) ontology merging into the extended GOIoTP (as the
top-level ontology).
• Combining two (or more) IoT platforms with explicitly defined ontologies. Here,
among others, the following issues will be researched: (i) bringing multiple ontolo-
gies to a common format / language (for example, transforming XML into RDF and
further transforming it into OWL-demarcated ontology using XLST), (ii) ontology
matching, to allow for (iii) ontology merging into the extended GOIoTP (as the
top-level ontology) [55].
• Joining an “incoming” IoT platform (with an explicitly defined ontology) to an
existing federation of IoT platforms (with an already defined common ontology).
Here the process would be somewhat a simplified version of the previous method
as only two ontologies will be integrated.](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-36-320.jpg)
![22 C. E. Palau et al.
• Dealing with IoT platforms without an explicitly defined ontology / taxonomy /
etc. Here, appropriate set of tools will be adapted to help instantiate an ontology
for the multi-IoT-platform under construction. Specifically, the ontology will be
built on the basis of information contained in one, or more: (i) definition of used
data; (ii) structure of the database(s); (iii) queries issued on the database(s); and
(iv) exchanged messages [54].
4.6 Cross-Layer Approach for Interoperability
INTER-IoT specifically aims at creating cross-layer interoperability and integration
between heterogeneous IoT platforms. Cross-layer approaches are fundamental to
made interoperable/integrate the whole layer stack (device, networking, middleware,
application service, data and semantics) of IoT platforms. Cross layering will be
therefore based on the outcomes of the previous points.
Moreover, important requirements and features such as Quality of Service (QoS),
Quality of Experience (QoE), Security, Privacy, Trust and Reliability, require to be
addressed at each layer with different mechanisms. Such transversal approach allows
retaining the benefits of a layered architecture (e.g., modularity, interoperability,
etc.) but adding, at the same time, flexibility (e.g., optimization, tunable design,
etc.) to those components that require it. Considering the heterogeneity and spread
of IoT devices and IoT applications, it is straightforward that such design choice
is more than suitable to properly support (i) dynamic QoS and QoE (the former,
basically aiming at splitting traffic up into priority classes and trying to guarantee
a particular performance metric, the latter at combining more subjective aspects
related to user perception into evaluating a service); (ii) novel security and privacy
techniques (that consider the cyber-physical nature of IoT devices as well as of the
IoT application contexts); extended trust models (in which unconventional actors,
likesocial networks, playanimportant role) and(iv) enhancedreliabilitymechanisms
(to deal with failure of resource-limited IoT device, lack of coverage from access
networks in some region, rapid application context switches, etc.) [11, 56].
5 Conclusions
In this chapter we have presented the INTER-IoT systemic approach, which is being
created within the INTER-IoT project together with necessary software tools and
enduser applications. It will provide ways of overcoming interoperability prob-
lems between heterogeneous IoT systems across the communication/software stack,
including: devices, networks, middleware, application services, data/semantics.
Henceforth, reuse and integration of existing and future (even standard) IoT sys-
tems will be facilitated and made possible to obtain interoperable ecosystems of IoT
platforms.](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-37-320.jpg)
![INTER-IoT Requirements
Pablo Giménez, Miguel Llop, Regel Gonzalez-Usach, and Miguel A. Llorente
Abstract There are some significant tasks in the first stage of a project in order to
achieve success when taking out a new product, a service or release a software. It is
essential to know what is in the market and what the potential customers want. There-
fore, during the project, we performed a market analysis regarding all the products
related with IoT and we had interviews with all the involved actors in all the domains,
such as developers, integrators, operators, domain users, clients, etc. Furthermore,
from the previous information we define the requirements in order to determine how
the system should work and what it should do. This chapter presents the process
and the results of these three activities developed in the first stage of the INTER-
IoT project: market analysis, stakeholders analysis, and requirements analysis. This
task was done for the five different products defined in the project: INTER-LAYER,
INTER-FW, INTER-METH, INTER-LogP, and INTER-Health. These tasks have
been made using the VOLERE methodology, which is an excellent methodology to
extract conclusions and provide results following a systematic approach.
1 Introduction
Requirements are an essential part of any software project and it is critical to devote
enough time to identify all project requirements [1]. The gathering of and compiling
of requirements for a software project requires a very tight collaboration between the
clients, the developers and the software integrators. This is because the behaviour
attributes and properties of the future system rely dramatically on a correct identifi-
cation of requirements [2].
P. Giménez (B) · M. Llop
Fundación Valenciaport, Valencia, Spain
e-mail: pgimenez@fundacion.valenciaport.com
R. Gonzalez-Usach
Universitat Politècnica de València, Valencia, Spain
M. A. Llorente
Prodevelop, Valencia, Spain
© Springer Nature Switzerland AG 2021
C. E. Palau (eds.), Interoperability of Heterogeneous IoT Platforms, Internet of Things,
https://doi.org/10.1007/978-3-030-82446-4_2
27](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-42-320.jpg)
![28 P. Giménez et al.
There are two main reasons for specifying requirements. First, it guides design
and decision-making processes towards a correct solution [3]. In addition, it provides
a basis of testing the implemented solution is correct [1].
It must be noted that the creation of the INTER-IoT framework represents a vast
and very complex development task that encompasses all layers from IoT systems,
and novel aspects in IoT-related software [4].
Therefore, requirements on each level of the IoT stack [5] must be identified and
collected, including the platform layer [6], middleware [7], gateway or fog domain
[8], network [8], semantics [9, 10], service and application layer [11, 12], security
[13] and cross-layer elements [14] and other IoT-related aspects [5].
The first stage of the project was focused on the definition of all the elements
necessary for the development of the project. The objective of the initial phase was
to gather and define the set of technical requirements for the development of INTER-
IoT framework and for each of its core components. The work in this work package
was structured in five tasks:
• Identify and analyse stakeholders and products for both use cases addressed in the
project: smart port logistics and smart mobile m-health.
• Collect and analyse requirements from targeted stakeholders, and other involved
actors to develop the INTER-IoT products.
• Identify and design suitable business models for the INTER-IoT system.
• Define comprehensive suitable scenarios for the use cases and the targeted stake-
holders.
• Analyse legal and regulatory requirements that are relevant to INTER-IoT.
1.1 Methodology
The methodology selected as a reference for most of the above tasks is VOLERE1
[15] , as it represents a solid methodology widely used by thousands of organizations
around the world in order to define, discover, communicate and manage all the
necessary requirements for any type of system development (e.g. software, hardware,
commodities, services, organizational, etc.). The VOLERE methodology [3, 15] is
used in INTER-IoT mainly because it helps project partners to describe, formalize
and track the project market analysis, requirements, use cases and scenarios in an
explicit and unambiguous manner, and has widely proven to be effective and reliable
for this type of tasks. It is also quite clear and simple to apply.
VOLERE can be applied in almost all kinds of development environments, with
any other development methods or with most requirements tools and modelling tech-
niques. To produce accurate and unambiguous requirements, the VOLERE method-
ology uses techniques that are based on experience from worldwide business analysis
projects, and are continually improved [16].
1 http://www.volere.co.uk/.](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-43-320.jpg)
![INTER-IoT Requirements 29
The VOLERE methodology provides several templates to deal with the different
techniques and activities that it includes. In a quick view, the VOLERE Requirement
Process2
that this methodology suggests can be summarised as follows:
1. Define the Purpose of the Project
2. Stakeholders Identification and Analysis
3. Business Use Cases
4. Scenarios
5. Writing the Requirements (functional requirements and non-functional require-
ments)
6. Validation of requirements (completeness, relevance, testability, coherency, trace-
ability, and several other qualities before they allow it to be passed to the devel-
opers)
7. Communicating the Requirements
8. Requirements Completeness.
The consequent application of the VOLERE methodology is not only useful in
the initial phases of the project but it is also helpful in specifying a reference point
for the later stages. During the implementation and management, it can be used
to track and evaluate the progress of the individual work packages and the overall
project. Besides being efficient and easy to use, the VOLERE methodology provides
a mechanism for all partners to specify requirements, needs, use cases and scenarios
in a standard format. Thereby, specifying additional context of an element such as
the rationale and the acceptance criteria helps to build a common understanding of
the overall system [16]. Furthermore, defining priorities helps to clarify the focus of
the project [17].
1.2 Repository
The implementation of this methodology in the INTER-IoT project has been done
using a commercial software called Jira.3
Jira is an online tracking tool to manage
the whole project progress, where all the information compiled and produced is
accessible through to the different partners. Following the Volere recommendations,
all the requirements, scenarios, stakeholders, and products were registered.
This repository help to search, access, review, and register new elements (stake-
holders, requirements, etc.) identified after completion of the initial stage as the
project progresses.
2 Volere Getting Started http://www.volere.co.uk/pdf%20files/VolereGettingStarted.pdf.
3 https://es.atlassian.com/software/jira.](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-44-320.jpg)
![30 P. Giménez et al.
2 Stakeholders Analysis
2.1 Definition
Stakeholders’ analysis [18] was the first task in the project and it is part of a rigorous
and complete requirements specification [16]. It describes the process of targeting
the people who have an interest in the new products and results that are planned for
the project. The stakeholders’ group being involved in this task has also included
anyone who may have any influence on the project’s outcomes, may be affected
by the product or may have any knowledge needed to uncover the requirements
of these products. The identification and involvement of relevant stakeholders is
very important to be able to capture the requirements for the interoperability of
heterogeneous IoT platforms [19].
The stakeholders’ analysis was carried out through interviews with stakeholders,
following an INTER-IoT product oriented approach. With this analysis, we have
identified the initial needs for the five components of the project: INTER-LAYER,
INTER-FW, INTER-METH, INTER-LogP and INTER-Health. The identification
of stakeholders also helped us to start developing cooperation with them, to focus on
the requirements gathering process and, ultimately, to ensure a successful outcome
for the project. The analysis took into account both demand and supply points of
view and both qualitative and quantitative aspects [20].
Although there could be other kind of stakeholders, the following list of potential
classes of stakeholders was initially defined for the identification process carried out
by all the partners in the consortium:
1. Client/sponsor 10. Representatives of external associations
2. Customer 11. Business analysts
3. Subject-matter experts 12. Designers and developers
4. Members of the public 13. Testers
5. Users of the current system 14. Systems engineers
6. Marketing experts 15. Software engineers
7. Legal experts 16. Technology experts
8. Domain experts 17. System designers
9. Usability experts
As far as the European Commission (EC) is the sponsor of INTER-IoT, as it is the
funding entity of the project, it represents one of the most relevant stakeholders and
we established the optimal value for it. Although the EC influenced on the outcomes
of the project, it is not the customer of the project’s products and results.
To easily identify the stakeholders of each product, we have used a stakeholder’s
map as it has been described in the publication of “Mastering the Requirements Pro-
cess: Getting Requirements Right” used as a reference for the VOLERE methodol-
ogy. The stakeholder’s map shows the organizational rings surrounding the product
and the classes of stakeholders who inhabit on these rings. The stakeholder map](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-45-320.jpg)
![INTER-IoT Requirements 33
2.2 Analysis
The stakeholders’ analysis has been carried out through an INTER-IoT product-
oriented approach [18], as stakeholders have been identified separately with regard
to each product (INTER-LAYER, INTER-FW, INTER-METH, INTER-LogP and
INTER-Health). The addressed stakeholders are interested from one product to all.
From the data gathered in the stakeholder form, we carried out an analysis by product.
Therefore, for each of the five products we analysed the following topics:
• Stakeholders by company type (research institutions, public authorities, non-profit
organizations, private companies, etc.)
• Stakeholders by country
• Stakeholders map
• Stakeholders by class (client, system, engineers, software engineers, IoT operators,
etc.)
• Stakeholders by IoT Demand/Supply
• Stakeholders with interest in Open Call participation
• Products identified by Stakeholders
• Stakeholders needs.
During the first phase of the project, the partners identified and interviewed 93
stakeholders. For each of them one or more stakeholders forms depending on their
interest in the different INTER-IoT products.
One of the most interesting conclusions is the type of stakeholders with interest
in the project. In Fig.3 can be seen that a quarter of the stakeholders were potential
clientsorcustomersoftheINTER-IoTproducts.Afterthatarethetechnologyexperts,
sub-matter experts, system and software engineers which will use the INTER-IoT
products developing new features and updating the last versions.
For each product, we completed a stakeholder map, like the one in the Fig.4 for
INTER-LAYER. Stakeholders are classified by how involved they are in the design,
development and execution of the product. There are four main areas in this map,
corresponding to the degree of influence that each stakeholder could have:
• Analysis team: Is the core team in the design and development of INTER-LAYER.
It is comprised by all project partners that lead the project and are directly involved
with INTER-LAYER (e.g. UPVLC, PRO, XLAB, VPF, etc.).
• Operational work area: Every stakeholder that has direct a contact with INTER-
LAYER (e.g. SigFox, ValenciaPort PCS), has enough knowledge in the product
(e.g. AFT) or has a main role in the development and execution of INTER-LAYER
(e.g. NOATUM, ASL TO5) fall under this ring.
• Business area: Stakeholders that are affected in some way by INTER-LAYER
(but not enough to have a main role) are located in this ring. Some stakeholders
are interested in contributing to INTER-LAYER (e.g. Infoport, ETRA) or testing
and adopting INTER-LAYER (e.g. Valencia Port Authority). Their business mod-
els may influence the business models developed within INTER-IoT regarding
INTER-LAYER.](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-48-320.jpg)
![INTER-IoT Requirements 35
• Influence area: In the outer ring, stakeholders that have an influence or some
interest with INTER-LAYER are located. Other IoT related projects (e.g. BIG-
IoT, Vicinity), IoT alliances (e.g. AIOTI, AllSeen), I+D companies (e.g. ETRA
I+D), etc. Standardization organizations also play an important role in this ring,
as the developed INTER-LAYER product should follow or be in line with the
recommendations and working groups implied in these bodies [21].
The whole list of stakeholders and a complete analysis can be found in the INTER-
IoT deliverable D2.1 INTER-IoT Stakeholders and market analysis report [22].
3 Market Analysis
3.1 Definition
The aim of the market analysis [23] is to provide an insight of the current IoT market
landscape and the vision of different technologies supporting it [24]. The market
analysis process is a must to do task in order to identify products that are being
introduced or are already in the market which are related with the project in one of
the following ways [23]:
• as a component or module of the solution
• as a complementary product
• as a beneficiary, client or consumer of the solution
• as a concurrent product
The products identified during the stakeholders analysis need to be taken into
accounttoidentifycharacteristics,capabilities,objectivesandneedsoftheseproducts
under the point of view of interoperability of heterogeneous IoT platforms. The
market analysis has been done in combination with the stakeholders analysis, this
has allowed us to identify the readiness and willingness of different stakeholders to
participate in interoperable IoT scenarios, different systems and products that could
be involved and systems and products that would be required to participate in those
scenarios [23].
This process has been quite relevant, as we have identified that many existing
products are not yet ready to participate in an interoperable IoT environment and
they need to be transformed and complemented with other components like IoT
gateways and platforms to meet the interoperability requirements. This represents a
new market niche, as there do not exist yet a wide adoption of IoT aware solutions
and interoperable IoT products. The market analysis also helps to identify relevant
standards and protocols that products are supporting and that INTER-IoT products
would need to assess.
The Fig.5 shows the product’s template, which includes the name of the product;
the product class; the acquisition or licence options; references or web addresses
to access further information; a brief description and the services provided by the](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-50-320.jpg)
![38 P. Giménez et al.
Fig. 7 Products by access
policy
us to assume there is a high level of domain application specialization of the products
being identified.
Other conclusion extracted from the analysis is product access policy. It allows
to a certain degree to acquire a clearer idea of the economic and administrative
constraints to overcome in order to be able to use the products. The access mode also
provides a certain indication as to the structural interoperability the products bear.
Figure7 confirms the need for INTER-IoT solutions as over half of the identified
products are used in a closed environment mode, thus hindering the economic effi-
ciency and competitive advantages that could be gained by fostering interoperability.
Luckily, among those products that can theoretically be accessed more openly, few
require to overcome additional hurdles such as subscription or licensing.
The whole list of products and a complete analysis can be found in the INTER-IoT
deliverable D2.1 INTER-IoT Stakeholders and market analysis report [22].
4 Requirements Analysis
4.1 Definition
The set of requirements define how should work the different products from the
needs of end users, suppliers and developers. A rigorous assessment of requirements
before design allows a clear idea of what you want to implement and reduces delays
due to design flaws. It also allows estimating more accurately the costs and the
risks [3].](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-53-320.jpg)
![INTER-IoT Requirements 39
The requirements are the basis for the design stage, so a well-defined requirement
reduces the development effort [16]. During the specification of the requirements, we
should involve almost all the departments of the organization in order to define the
necessary requirements for a specific product or service [25]. A complete and correct
requirement process reduces the effort wasted on redesign, recoding and retesting. It
also provides an efficient mechanism for the product validation and verification [3].
The characteristics that the requirements should have following ISO 2011 are:
necessary,appropriate,unambiguous,complete,singular,feasible,verifiable,correct,
consistent and comprehensible. There are several requirements categorizations, but
the Volere methodology categorises requirements into three main groups4
:
• Functional requirements are the fundamental subject matter of the system and
are measured by concrete means like; data values, decision-making logic and
algorithms.
• Non-functional requirements are the behavioural properties that the specified func-
tions must have, such as performance, usability, etc. Non-functional requirements
can be assigned to a specific measurement. The methodology also includes a rich
catalogue of non-functional requirements to be taken into account, which will be
reviewed afterwards.
• Project constraints identify how the eventual product must fit into the world. For
example, the product might have to interface with or use some existing hardware,
software or business practice, or it might have to fit within a defined budget or be
ready by a defined date.
In the project, we followed 5-step iterative process for identifying, capturing,
defining, analysing, and reconciling requirements (see Fig.8). As it is an iterative
process, during the whole project the requirements were reviewed and redefined to
be more focused on the real development of the different components [26].
4.1.1 Identify Sources of Requirements
The partners identified the sources of information to collect requirements such as
previous research projects, partners’ knowledge, stakeholders, regulation, standards,
etc.
4.1.2 Requirement Capturing
This step generated an inventory of identified requirements by INTER-IoT product,
including requirement name and brief description.
4 Volere Requirements Specification Template https://www.st.cs.uni-saarland.de/edu/se/2009/
slides/volere_specification_template_v6.pdf.](https://image.slidesharecdn.com/18392177-250530022315-8c0257a3/85/Interoperability-Of-Heterogeneous-Iot-Platforms-A-Layered-Approach-1st-Edition-Carlos-E-Palau-54-320.jpg)
Interoperability Of Heterogeneous Iot Platforms A Layered Approach 1st Edition Carlos E Palau
- 1. Interoperability Of Heterogeneous Iot Platforms A Layered Approach 1st Edition Carlos E Palau download https://ebookbell.com/product/interoperability-of-heterogeneous- iot-platforms-a-layered-approach-1st-edition-carlos-e- palau-36784354 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Interoperability Of Enterprise Software And Applications 1st Edition Dimitri Konstantas https://ebookbell.com/product/interoperability-of-enterprise-software- and-applications-1st-edition-dimitri-konstantas-2139432 Interoperability Of Enterprise Software And Applications Workshops Of The Interopesa International Conference E12n Wsi Isidi And Iehena 2005 February 22nd 2005 Geneva Switzerland Herve Panetto https://ebookbell.com/product/interoperability-of-enterprise-software- and-applications-workshops-of-the-interopesa-international- conference-e12n-wsi-isidi-and-iehena-2005-february-22nd-2005-geneva- switzerland-herve-panetto-4103212 Integration Interconnection And Interoperability Of Iot Systems Fortino https://ebookbell.com/product/integration-interconnection-and- interoperability-of-iot-systems-fortino-6752704 Principles Of Health Interoperability Fhir Hl7 And Snomed Ct 4th Ed 2021 Tim Benson https://ebookbell.com/product/principles-of-health-interoperability- fhir-hl7-and-snomed-ct-4th-ed-2021-tim-benson-56920576
- 3. Principles Of Health Interoperability Hl7 And Snomed 2nd Edition Tim Benson Auth https://ebookbell.com/product/principles-of-health-interoperability- hl7-and-snomed-2nd-edition-tim-benson-auth-4392100 Principles Of Health Interoperability Hl7 And Snomed Xxiv Tim Benson Auth https://ebookbell.com/product/principles-of-health-interoperability- hl7-and-snomed-xxiv-tim-benson-auth-4396456 Principles Of Health Interoperability Snomed Ct Hl7 And Fhir 3rd Edition Tim Benson https://ebookbell.com/product/principles-of-health-interoperability- snomed-ct-hl7-and-fhir-3rd-edition-tim-benson-5483930 Enterprise Interoperability Smart Services And Business Impact Of Enterprise Interoperability 1st Edition Martin Zelm https://ebookbell.com/product/enterprise-interoperability-smart- services-and-business-impact-of-enterprise-interoperability-1st- edition-martin-zelm-7258826 Enterprise Interoperability Viii Smart Services And Business Impact Of Enterprise Interoperability 1st Ed Keith Popplewell https://ebookbell.com/product/enterprise-interoperability-viii-smart- services-and-business-impact-of-enterprise-interoperability-1st-ed- keith-popplewell-10486214
- 5. Internet ofThings CarlosE.Palau·GiancarloFortino· MiguelMontesinos·GeorgeExarchakos· PabloGiménez·GarikMarkarian·ValérieCastay · FlavioFuart·WiesławPawłowski·MarinaMortara· AlessandroBassi·FransGevers· GemaIbáñez-Sánchez·IgnacioHuet Editors Interoperability of Heterogeneous IoT Platforms A Layered Approach
- 6. Internet of Things Technology, Communications and Computing Series Editors Giancarlo Fortino, Rende (CS), Italy Antonio Liotta, Edinburgh Napier University, School of Computing, Edinburgh, UK
- 7. The series Internet of Things - Technologies, Communications and Computing publishes new developments and advances in the various areas of the different facets of the Internet of Things. The intent is to cover technology (smart devices, wireless sensors, systems), communications (networks and protocols) and computing (theory, middleware and applications) of the Internet of Things, as embedded in the fields of engineering, computer science, life sciences, as well as the methodologies behind them. The series contains monographs, lecture notes and edited volumes in the Internet of Things research and development area, spanning the areas of wireless sensor networks, autonomic networking, network protocol, agent-based computing, artificial intelligence, self organizing systems, multi-sensor data fusion, smart objects, and hybrid intelligent systems. ** Indexing: Internet of Things is covered by Scopus and Ei-Compendex ** More information about this series at https://link.springer.com/bookseries/11636
- 8. Carlos E. Palau · Giancarlo Fortino · Miguel Montesinos · George Exarchakos · Pablo Giménez · Garik Markarian · Valérie Castay · Flavio Fuart · Wiesław Pawłowski · Marina Mortara · Alessandro Bassi · Frans Gevers · Gema Ibáñez-Sánchez · Ignacio Huet Editors Interoperability of Heterogeneous IoT Platforms A Layered Approach
- 9. Editors Carlos E. Palau School of Telecommunications Engineering Universitat Politècnica de València Valencia, Spain Miguel Montesinos Prodevelop, S.L. Valencia, Spain Pablo Giménez Sede APV Valencia, Spain Valérie Castay AFT Paris, France Wiesław Pawłowski Faculty of Mathematics, Physics and Informatics University of Gdańsk Gdańsk, Poland Alessandro Bassi ABC Prague, Czech Republic Gema Ibáñez-Sánchez Instituto ITACA Universitat Politècnica de Valencia Valencia, Spain Giancarlo Fortino DIMES, University of Calabria Rende (CS), Italy George Exarchakos Department of Electrical Engineering Eindhoven University of Technology Eindhoven, The Netherlands Garik Markarian Riverway House Rinicom Ltd. Lancaster, UK Flavio Fuart XLAB doo Ljubljana, Slovenia Marina Mortara Dipartimento di Prevenzione, ASL TO5 Struttura Complessa Igiene degli Aliment Nichelino, Torino, Italy Frans Gevers Neways Technologies B.V. EP Son, The Netherlands Ignacio Huet CSP Spain Valencia, Spain ISSN 2199-1073 ISSN 2199-1081 (electronic) Internet of Things ISBN 978-3-030-82445-7 ISBN 978-3-030-82446-4 (eBook) https://doi.org/10.1007/978-3-030-82446-4 © Springer Nature Switzerland AG 2021 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer imprint is published by the registered company Springer Nature Switzerland AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
- 10. Preface In recent years, due to a great interest of both Industry and Academy in researching and developing IoT technology, many solutions at different levels (from the IoT device-level to full-fledged IoT platforms) have been implemented. However, there is no reference standard for IoT platform technology, and we do not foresee one in the near future. Hence, IoT scenarios will be characterized by a high degree of heterogeneity at all levels (device, networking, middleware, application service, data/semantics), preventing interoperability of IoT solutions. Although many research actions and projects have dealt and/or are dealing with developing IoT architectures in diversified application domains, not many of them have addressed interoperability/integration issues. Furthermore, no proposals (to date) have been put forward to deliver a general, application domain agnostic, fully reusable and systematic approach to solve multiple interoperability problems existing in the IoT platforms technology. Lack of interoperability causes major technological and business issues such as impossibility to plug non-interoperable IoT devices into heterogeneous IoT plat- forms, impossibility to develop IoT applications exploiting multiple platforms in homogeneous and/or cross domains, slowness of IoT technology introduction at a large-scale, discouragement in adopting IoT technology, increase of costs, scarce reusability of technical solutions, user dissatisfaction. In contrast, interoperability among platforms will provide numerous benefits such as new market opportuni- ties, the disappearance of vertical silos, and vertically oriented closed systems, architectures and application areas, to move towards open systems and platforms. Comprehensively addressing lack of interoperability in the IoT realm by proposing a full-fledged approach facilitating “voluntary interoperability” at any level of IoT platforms and across any IoT application domain, thus guaranteeing a seamless integration of heterogeneous IoT technology. Most current existing sensor networks and IoT device deployments work as inde- pendent entities of homogeneous elements that serve a specific purpose, and are isolated from “the rest of the world”. In a few cases where heterogeneous elements are integrated, this is done either at device or network level, and focused mostly on unidirectional gathering of information. A multi-layered approach to integrating v
- 11. vi Preface heterogeneous IoT devices, networks, platforms, services and applications will allow heterogeneous elements to cooperate seamlessly to share data, infrastructures and services as in a homogeneous scenario. INTER-IoT is a solution proposed to the above problem, and has aimed at the design, implementation and experimentation of an open cross-layer framework, an associated methodology and tools to enable voluntary interoperability among hetero- geneous Internet of Things (IoT) platforms. INTER-IoT is the supporting envi- ronment for this book. It has been conceived and created among other potential solutions in the framework of IoT-EPI (IoT European Platforms Initiative), and has allowed effective and efficient development of adaptive, smart IoT applications and services, atop different heterogeneous IoT platforms, spanning single and/or multiple application domains, creating also its own ecosystem. This book investigates on the multi-layered approach to achieve semantic inter- operability, presenting innovative solutions for the architecture and the individual layers so as management and the methodological approach. Readers are offered with new issues and challenges in a continuously moving environment like IoT platform interoperability. In particular, the book spans the following scenarios: (1) port trans- portation and logistics; (2) mobile healthcare and (3) different application domains related with the INTER-IoT ecosystem. All the areas covered by the interoperability solution and its application correspond to ten authored chapters briefly introduced below. Chapter “Introduction to Interoperability for Heterogeneous IoT Platforms” by Carlos E. Palau, et al., presents an overview of the needs, potential solutions and advances regarding IoT platforms interoperability. The chapter in particular starts reviewing the existing solutions and state of the art associated with platform inter- operability and discuses the benefits of a multi-layered approach solution analysing the layers selected for the INTER-IoT solution and the potential application to two selected use cases, identifying the uniqueness of the provided approach. Chapter “INTER-IoT Requirements” by Pablo Giménez, Miguel Llop, Regel Gonzalez-Usach, and Miguel A. Llorente proposes the main requirements and the process to gather them to achieve interoperability between IoT platforms. The chapter considers the Volere methodology as the mechanism to define, gather, select and prioritize the functional and non-functional requirements to develop an interoper- able solution. Requirements are analysed following different approaches and can be used as support for potential developers that may need to perform a similar analysis for the same or different application domains. Chapter “INTER-IoT Architecture for Platform Interoperability” by Alessandro Bassi, Miguel A. Llorente, Miguel Montesinos, and Raffaele Gravina analyses the need of a meta-architecture with a specific domain model to define the different building blocks for an interoperable solution. The chapter illustrates the contribution of INTER-IoT for the definition of a reference architecture, using IoT-A as a starting point and the link with further developments related with the IoT community. The chapter includes the software vision of the architecture and supports the multi-layered approach which is the current approach required from the market.
- 12. Preface vii Chapter “INTER-Layer: A Layered Approach for IoT Platform Interoperability” by Andreu Belsa et al., describes the different solutions for each of the layers that compose the architecture. The chapter starts with a detailed state-of-the-art analysis and describes the different technologies that can be used to provide interoperability at each layer of the architecture. The technical aspects of the developments and integra- tion are based on the requirements gathered and described in Chapter “INTER-IoT Requirements”. The cross-layer needs of the architecture are also analysed in the chapter with a specific focus on security, privacy, reliability and management. Chapter “Semantic Interoperability” by Maria Ganzha, et al., concerns modern trends in IoT semantic interoperability, in particular the different methods to be used, with a specific focus on semantic alignment. After an overview of current literature, the chapter defines the different semantic interoperability patterns, a global ontology (GOIoTP) for platform interoperability, that agnostically address any domain. The chapter describes a key component of the architecture as the IoT Platform Semantic Mediator (IPSM) that support semantic interoperability functions at any layer but mainly at middleware and application and service layers. Chapter “INTER-Framework: An Interoperability Framework to Support IoT Platform Interoperability” by Clara I. Valero et al., considers the different tools required to manage, secure and provide global access to the APIs of the architecture. After a brief discussion on related work the chapter describes INTER-API and the global API of the INTER-IoT architecture as a relevant contribution and innovation in the area of IoT interoperability; the management functions that allow fast config- uration of the interoperability parameters at any layer and the security measures in order to achieve and guarantee interoperability highlighting scalability, flexibility and sustainability. Chapter “INTER-Meth: A Methodological Approach for the Integration of Heterogeneous IoT Systems” by Giancarlo Fortino et al., provides support for the integration of heterogeneous IoT platforms from the analysis to the maintenance phase, something that is required due to the lack of proper interoperability standards. The chapter provides a description using software engineering of a methodolog- ical approach to achieve and manage interoperability among IoT platforms avoiding dependency on the application domain. The proposed methodology is supported by software tools that help the different actors, following their different profile in configuring every required enabler and component. Chapter “Interoperability Application in e-Health” by Gema Ibáñez-Sánchez, AlvaroFides-Valero,Jose-LuisBayo-Monton,MargheritaGulino,andPasqualePace is a chapter where the different proposals of the previous chapters, from requirements elicitation till interoperability achievement, are analysed and deployed in the appli- cation domain of mobile health. INTER-HEALTH provides a solution that allows health experts to prevent and reduce obesity, which is one of the main causes of chronic diseases. Through INTER-IoT, two different platforms (i.e. UniversAAL and BodyCloud) are able to interoperate to exchange information and so, to provide aggregated information to health experts. The results show a clear improvement in the health of the participants compared to those not using it.
- 13. viii Preface Chapter “INTER-LogP: INTER-IoT for Smart Port Transportation” by Pablo Giménez, Miguel Llop, Joan Meseguer, Fernando Martin, and Antonio Broseta explores the application of the methodology, including requirements gathering and implementation of the different components in a complex environment like a port. The chapter considers the interaction of several IoT platforms with the goal of sharing data and services, provided by the port authority of Valencia, the NOATUM container terminal and other IoT platforms provided by third parties. With the data provided, three different scenarios were defined, and showed the benefits of sharing data in the port and the logistic sector: access control and traffic, dynamic lighting and wind gusts detection. Chapter “IoT Ecosystem Building” by Regel Gonzalez-Usach, Carlos E. Palau, Miguel A. Llorente, Roel Vossen, Rafael Vaño, and Joao Pita analyses the mechanism to extend the developments of an IoT Open Source project. The chapter describes the methodology and new actors associated with the interoperability framework defined in the previous chapters. A detailed description of different projects is associated with INTER-IoT that validated different enablers, components and methods of the proposed interoperability approach with the aim of sustainability and extendibility. Our gratitude is for all chapter contributors, the reviewers, and for the Editorial Board from Springer for their support and work during the publication process. Valencia, Spain Rende (CS), Italy Valencia, Spain Eindhoven, The Netherlands Valencia, Spain Lancaster, UK Paris, France Ljubljana, Slovenia Gdańsk, Poland Nichelino, Italy Prague, Czech Republic EP Son, The Netherlands Valencia, Spain Valencia, Spain Carlos E. Palau Giancarlo Fortino Miguel Montesinos George Exarchakos Pablo Giménez Garik Markarian Valérie Castay Flavio Fuart Wiesław Pawłowski Marina Mortara Alessandro Bassi Frans Gevers Gema Ibáñez-Sánchez Ignacio Huet
- 14. Contents Introduction to Interoperability for Heterogeneous IoT Platforms . . . . . . 1 Carlos E. Palau, Giancarlo Fortino, Miguel Montesinos, Pablo Giménez, Garik Markarian, Valérie Castay, Flavio Fuart, Wiesław Pawłowski, Marina Mortara, Alessandro Bassi, Frans Gevers, Gema Ibáñez-Sánchez, Ignacio Huet, and George Exarchakos INTER-IoT Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Pablo Giménez, Miguel Llop, Regel Gonzalez-Usach, and Miguel A. Llorente INTER-IoT Architecture for Platform Interoperability . . . . . . . . . . . . . . . 49 Alessandro Bassi, Miguel A. Llorente, Miguel Montesinos, and Raffaele Gravina INTER-Layer: A Layered Approach for IoT Platform Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Andreu Belsa, Alejandro Fornes-Leal, Clara I. Valero, Eneko Olivares, Jara Suárez de Puga, Fernando Boronat, and Flavio Fuart Semantic Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Maria Ganzha, Marcin Paprzycki, Wiesław Pawłowski, Bartłomiej Solarz-Niesłuchowski, Paweł Szmeja, and Katarzyna Wasielewska INTER-Framework: An Interoperability Framework to Support IoT Platform Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Clara I. Valero, Andreu Belsa, Alejandro Fornes-Leal, Fernando Boronat, Miguel A. Llorente, and Miguel Montesinos INTER-Meth: A Methodological Approach for the Integration of Heterogeneous IoT Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Giancarlo Fortino, Raffaele Gravina, Wilma Russo, Claudio Savaglio, Katarzyna Wasielewska, Maria Ganzha, Marcin Paprzycki, Wiesław Pawłowski, Paweł Szmeja, and Rafał Tkaczyk ix
- 15. x Contents Interoperability Application in e-Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Gema Ibáñez-Sánchez, Alvaro Fides-Valero, Jose-Luis Bayo-Monton, Margherita Gulino, and Pasquale Pace INTER-LogP: INTER-IoT for Smart Port Transportation . . . . . . . . . . . . . 257 Pablo Giménez, Miguel Llop, Joan Meseguer, Fernando Martin, and Antonio Broseta IoT Ecosystem Building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Regel Gonzalez-Usach, Carlos E. Palau, Miguel A. Llorente, Roel Vossen, Rafael Vaño, and Joao Pita
- 16. Introduction to Interoperability for Heterogeneous IoT Platforms Carlos E. Palau, Giancarlo Fortino, Miguel Montesinos, Pablo Giménez, Garik Markarian, Valérie Castay, Flavio Fuart, Wiesław Pawłowski, Marina Mortara, Alessandro Bassi, Frans Gevers, Gema Ibáñez-Sánchez, Ignacio Huet, and George Exarchakos C. E. Palau (B) DCOM, Universitat Politècnica de València, Camino de Vera, 46022 Valencia, Spain e-mail: cpalau@dcom.upv.es G. Fortino DIMES, Universitá della Calabria, Via Pietro Bucci, 87036 Arcavacata, Rende CS, Italy M. Montesinos PRODEVELOP S.L., Carrer del Cronista Carreres, 13, Valencia, Spain P. Giménez Fundación Valenciaport, Avinguda Moll del Turia, s/n, 46024 Valencia, Spain G. Markarian RINICOM Ltd, Morecambe Road, Lancaster LA1 2RX, UK V. Castay Département des Etudes et Projets, AFT-DEV, 82 rue Cardinet, 75845 Paris, France F. Fuart XLAB doo, Pot za Brdom 100, SI-1000 Ljubljana, Slovenia W. Pawłowski Faculty of Mathematics, Physics and Informatics, University of Gdańsk, Gdańsk, Poland e-mail: wieslaw.pawlowski@ug.edu.pl M. Mortara Dipartimento di Prevenzione, ASL TO5, Via San Francesco d’Assisi, 35., 10042 Nichelino (TO), Italy A. Bassi ABC, Ruska 50, 101 00 Prague, Czech Republic F. Gevers Neways Technologies B.V., Science Park Eindhoven 5709, The Netherlands G. Ibáñez-Sánchez ITACA, Universitat Politècnica de València, Camino de Vera, 46022 Valencia, Spain I. Huet CSP Spain, C/ Menorca, 19 - Edificio Aqua, 46023 Valencia, Spain G. Exarchakos Department of Electrical Engineering, Eindhoven University of Technology, 5600 MB Eindhoven, The Netherlands © Springer Nature Switzerland AG 2021 C. E. Palau (eds.), Interoperability of Heterogeneous IoT Platforms, Internet of Things, https://doi.org/10.1007/978-3-030-82446-4_1 1
- 17. 2 C. E. Palau et al. Abstract INTER-IoT presents a novel layer-oriented solution for interoperability, to provide interoperability at any layer and across layers among different IoT systems and platforms. Contrary to a more general global approach, the INTER-IoT layered approach has a higher potential in order to provide interoperability. It facilitates a tight bidirectional integration, higher performance, complete modularity, high adapt- ability and flexibility, and presents increased reliability. This layer-oriented solution is achieved through INTER-LAYER, several interoperability solutions dedicated to specific layers. Each interoperability infrastructure layer has a strong coupling with adjacent layers and provides an interface. Interfaces will be controlled by a meta-level framework to provide global interoperability. Every interoperability mechanism can be accessed through an API. The interoperability infrastructure layers can commu- nicate and interoperate through the interfaces. This cross-layering allows to achieve a deeper and more complete integration. 1 Introduction The connection of intelligent devices, equipped with a growing number of electronic sensors and/or actuators, via the Internet, is known as the Internet of Things (IoT). With the IoT, every physical and virtual object can be connected to other objects and to the Internet, creating a fabric of connectivity between things and between humans and things [1, 2]. The IoT is now widely recognised as the next step of disruptive digital innovation. The International Communications Union (ITU) and the European Research Clus- ter on the Internet of Things (IERC) provide the following definition: IoT is a dynamic global network infrastructure, with self-configuring capabilities based on standard and interoperable communication protocols, where physical and virtual things have identities, physical attributes and virtual personalities and use intelligent interfaces. All of them seamlessly integrated into the information network [3]. The design of the Internet and specifically the extension of the Internet to the IoT, rely on the convergence of the infrastructure with software and services. A common practice is required to think/design cross solutions between software and infrastruc- ture in order to provide integrated solutions for some of the complex problems in the current and future systems. In the IoT environment this convergence is evident, and the continuous evolution generates more and more smart connected objects and platforms that are embedded with sensors and their respective associated services, in some cases considering virtualization. IoT is the network or overlay associations between smart connected objects (phys- ical and virtual), that are able to exchange information by using an agreed method (including protocols) and a data schema. IoT deployments are increasing, the same applies to standards, alliances and interest for homogenization. All of this is giving a strong push to the IoT domain to be considered as one of the most promising emerg- ing technologies. As an example, Gartner (one of the world’s leading information technology research and advisory company) estimates the number of web-connected
- 18. Introduction to Interoperability for Heterogeneous IoT Platforms 3 devices will reach 25 billion by 2020. In other words, more devices, appliances, cars, artefacts, and accessories will be connected and will communicate with each other, and with other objects, thus bringing amplified connectivity and better supply chain visibility. The applications of the IoT are numerous i.e. every object could be trans- formed into a smart object that sends several valuable information to other devices. As an example, in the port industry IoT could be applied to shipping containers, the equipment that handles them, the trucks that carry them and, even, the ships that move them around the globe [4]. According to the European Commission (EC) the IoT represents the next step towards the digitisation of our society and economy, where objects and people are interconnected through communication networks, and report about their status and/or the surrounding environment. Furthermore, IoT can also benefit the European econ- omy generating economic growth and employment; according to a recent European Commission study revenues in the EU28 will increase from more than e307 billion in 2013 to more than e1,181 billion in 2020 [3, 4]. IoT is an emerging area that not only requires development of infrastructure but also deployment of new services capable of supporting multiple, scalable and inter- operable applications. The focus is today associated with cloud deployments, virtu- alizations and the elimination of silos avoiding the existence of application domain specific developments, AIOTI and EC are pressing in this line. IoT has evolved from sensor networks and wireless sensor networks to a most clear description and def- inition referring to objects and the virtual representations of these objects on the Internet and associated infrastructures. It defines how the physical things and virtual objects will be connected through the Internet and their interaction, and how they communicate with other systems and platforms, in order to expose their capabil- ities and functionalities in terms of services and accessibility through open APIs and frameworks. IoT is not only linking connected devices by the Internet; it is also web-enabled data exchange in order to enable systems with more capacities to become smart and accessible, creating webs of objects and allowing integration of data, services and components [5]. There are several challenges associated with IoT and its evolution, but one major issue is related with interoperability [6–8]. IoT is mainly supported by continu- ous progress in wireless sensor and actuator networks and by manufacturing low cost and energy efficient hardware for sensor and device communications. However, heterogeneity of underlying devices and communication technologies and interoper- ability in different layers, from communication and seamless integration of devices to interoperability of data generated by the IoT resources, is a challenge for expand- ing generic IoT solutions to a global scale, with the further aim of avoiding silos and provide solutions that are application domain agnostic, like those proposed in INTER-IoT and that will be reflected in the rest of the book [9].
- 19. 4 C. E. Palau et al. 2 INTER-IoT at a Glance Achieving interoperability is one of the main objectives of the IoT. It is all about con- necting things and make them easily accessible just like the Internet today. Broadly speaking, interoperability can be defined as a measure of the degree to which diverse systems, organizations, and/or individuals are able to work together to achieve a common goal” [6]. However, interoperability is a complex thing and there are many aspects to it. In literature, there exists quite a lot of different classifications of these aspects of interoperability, often also called levels of interoperability. One of the most important classification of levels of interoperability for technical systems is called Levels of Conceptual Interoperability Model (LCIM). It defines six levels of interoperability: technical, syntactic, semantic, pragmatic, dynamic and concep- tual interoperability. INTER-IoT follows a similar layered structure, however the approach has been different in terms of identification of the layers. INTER-IoT as a whole has been the result of a Research and Innovation Action under H2020 EC Framework Programme. The project has designed, implemented and experimented with an open cross-layer framework, an associated methodol- ogy and tools to enable voluntary interoperability among heterogeneous Internet of Things (IoT) platforms (all these components will be reflected in the next chap- ters of this book) [10]. The proposal has allowed effective and efficient develop- ment of adaptive, smart IoT applications and services, atop different heterogeneous IoT platforms, spanning single and/or multiple application domains. The project will be tested in two application domains: transport and logistics in a port environ- ment and mobile health, additionally it will be validated in a cross-domain use case supported by the integration in the project of twelve third parties. The INTER-IoT approach is general-purpose and may be applied to any application domain and across domains, in which there is a need to interconnect IoT systems already deployed or add new ones. Additionally, INTER-IoT is one of the seven RIAs and two CSA composing IoT-EPI, supporting the creation of a European common space for IoT interoperability [11–13]. INTER-IoT is based on three main building blocks, with different subcomponents that have been identified and classified in different exploitable products adequate to the needs of the different stakeholders involved in the project and also addressing the main needs of the potential customers of the entities participating in INTER- IoT. This three main building blocks, that will be further explained in the following chapters of the book are: • INTER-LAYER: methods and tools for providing interoperability among and across each layer (virtual gateways/devices, network, middleware, application services, data and semantics) of IoT platforms. Specifically, we will explore real/virtual gateways, for device-to-device communication, virtual switches based on SDN for network-to-network interconnection, super middleware for middleware-to-middleware integration, service broker for the orchestration of the service layer and a semantics mediator for data and semantics interoperability [11].
- 20. Introduction to Interoperability for Heterogeneous IoT Platforms 5 • INTER-FW: a global framework (based on an interoperable meta-architecture and meta-data model) for programming and managing interoperable IoT platforms, including an API to access INTER-LAYER components and allow the creation of an ecosystem of IoT applications and services. INTER-FW will provide man- agement functions specifically devoted to the interconnection between layers. The provided API includes security and privacy features and will support the creation of a community of users and developers [14]. • INTER-METH: an engineering methodology based on CASE (Computer Aided Software Engineering) tool for systematically driving the integration and inter- connection of heterogeneous non-interoperable IoT platforms [15, 16]. INTER-IoT provides an interoperable mediation component (i.e. INTER-LAYER to enable the discovery and sharing of connected devices across existing and future IoT platforms for rapid development of cross-platform IoT applications. INTER- IoT allows flexible and voluntary interoperability at different layers. This layered approach can be achieved by introducing an incremental deployment of INTER-IoT functionality across the platform’s space, which will in effect influence the level of platform collaboration and cooperation with other platforms. INTER-IoT does not pretend to create a new IoT platform but an interoperability structure to interconnect different IoT platforms, devices, applications and other IoT artifacts [11, 17]. Syntactic and semantic interoperability represent the essential interoperability mechanisms in the future INTER-IoT ecosystem, while organizational/enterprise interoperability has different structures/layers to enable platform providers to choose an adequate interoperability model for their business needs. It will be supported by INTER-FW that may allow the development of new applications and services atop INTER-LAYER and INTER-METH, to provide a methodology in order to coordinate interoperability supported by the definition of different interoperability patterns and a CASE tool [16] (Fig. 1). INTER-LAYER, which will be addressed in detail in Chap.4, is composed by five layers, supported by cross-layer components as needed for the interaction of the different layers: • Device layer (D2D): At the device level, D2D solution will allow the seamless inclusion of novel IoT devices and their interoperation with already existing ones. D2D solution is a modular gateway that supports a vast range of protocols as well as raw forwarding. It is composed on a physical part that only handles network access and communication protocols, and a virtual part that handles all other gateway operations and services (gw virtualization). When connection is lost, the virtual part remains functional and is capable to answer the API and Middleware requests. The gateway follows a modular approach to allow the addition of optional service blocks to adapt to the specific case, allowing a fast growth of smart objects ecosystems [18, 19]. • Network layer (N2N): N2N solution enables seamless Network-to-Network inter- operability, allowing transparent smart object mobility, and information routing support. It will also allow offloading and roaming, what implies the interconnec- tion of gateways and platforms through the network. Interoperability is achieved
- 21. 6 C. E. Palau et al. Fig. 1 INTER-IoT concept and vision through the creation of a virtual network, using SDN and NFV paradigms, with the support of the N2N API. The N2N solution will allow the design and imple- mentation of fully interconnected ecosystems, and solve the smart object mobility problem [20]. • Middleware layer (MW2MW): At the middleware level INTER-IoT solution will enable seamless resource discovery and management system for the IoT devices in heterogeneous IoT platforms. Interoperability at the middleware layer is achieved through the establishment of an abstraction layer and the attachment of IoT plat- forms to it. Different modules included at this level provide services to manage the virtual representation of the objects, creating the abstraction layer to access all their features and information. Those services are accessible through a general API. Interoperability at this layer will allow a global exploitation of smart objects in large scale multi-platform IoT systems [21]. • Application and Services layer (AS2AS): INTER-IoT will enable the use of het- erogeneous services among different IoT platforms. Our approach will allow the discovery, catalogue, use and even composition of services from different plat- forms. AS2AS will also provide an API as an integration toolbox to facilitate the development of new applications that integrate existing heterogeneous IoT services [22]. • Data and Semantics level (DS2DS): INTER-IoT guarantees a common interpre- tation of data and information among different IoT platforms and heterogeneous data sources that typically employ different data formats and ontologies, and are unable to directly share information among them. INTER-IoT DS2DS approach
- 22. Introduction to Interoperability for Heterogeneous IoT Platforms 7 is the first solution that provides universal semantic and syntactic interoperability among heterogeneous IoT platforms. It is based on a novel approach, a seman- tic translation of IoT platforms’ ontologies to/from a common Central Ontology that INTER-IoT employs, instead of direct platform-to-platform translations. This technique reduces dramatically the number of potential combinations of semantic translations required for universal semantic interoperability. INTER-IoT seman- tic interoperability tools work with any vocabulary, or ontology. INTER-IoT own modular Central Ontology, called GOIoTP, for all IoT platforms, devices and ser- vices, is available at http://docs.inter-iot.eu/ontology. Also, syntactic translators allow interoperability between different data formats, such as JSON, XML, and others. Although the pilot deployments of INTER-IoT realize the Core Informa- tion Model with Extensions approach to semantic interoperability, INTER-IoT supports any solutions between its pilot approach and Core Information Model [23, 24]. • Cross-Layer: INTER-IoT also guarantees non-functional aspects that must be present across all layers: trust, security, privacy, and quality of service (QoS). As well, INTER-IoT provides a virtualized version of the solution for each layer, to offer the possibility of a quick and easy deployment. Security is guaranteed inside each individual layer, and the external API access is securitized through encrypted communication, authentication and security tokens. INTER-IoT accomplishes the new European Data Privacy Law, and in the specific case of e-Health, in which information is highly sensitive, the Medical Device Regulation law [11, 25]. And INTER-FW which provides the wrapping environment for INTER-LAYER component coordination and new services development using INTER-API. Open interoperability delivers on the promise of enabling vendors and developers to inter- act and interoperate, without interfering with anyone’s ability to compete by deliv- ering a superior product and experience. In the absence of global IoT standards, the INTER-IoT project will support and make it easy for any company to design IoT devices, smart objects, or services and get them to market quickly, and create new IoT interoperable ecosystems. INTER-IoT may provide a solution to any potential interoperability problem within the IoT landscape [13] (Fig. 2). 3 INTER-IoT Use Case-Driven TheINTER-IoTapproachisusecase-driven,implementedandtestedinthreerealistic large-scale pilots: (i) Port of Valencia transportation and logistics involving hetero- geneous platforms with 400 smart objects; (ii) an Italian National Health Center for m-health involving 200 patients, equipped with body sensor networks with wear- able sensors and mobile smart devices and (iii) a cross domain pilot involving IoT platforms from different application domains and enlarged by the collaboration of the solutions associated to the different layers and sublayers from the third parties that have attended the open call. The use cases are:
- 23. 8 C. E. Palau et al. Fig. 2 INTER-IoT layered approach • INTER-LogP: The use of IoT platforms in the ports of the future will enable locat- ing, monitoring, and handling different transport and cargo equipment and stor- age areas. This use case will address the need to seamlessly handle IoT platforms interoperation within port premises: container terminal, transportation companies, warehouses, road hauliers, port authorities, customs, and outside the port [26]. • INTER-Health: The Decentralized and Mobile Monitoring of Assisted Livings’ Lifestyle use case, aims to develop an integrated IoT system for monitoring humans’ lifestyle in a decentralized mobile way to prevent chronic diseases. The aforementioned monitoring process can be decentralized from the health- care center to the monitored subjects’ homes, and supported in mobility by using on-body physical activity monitors [27]. • INTER-DOMAIN, composed by IoT platforms from the two application domain oriented pilots and the IoT platforms and the specific layer-oriented solutions from different application domains selected in the open call. SENSINACT and OM2M platforms with Smart Cities orientation have been selected, and contributions from the different layers may complement INTER-IoT [28, 29]. The project has analyzed requirements provided by the stakeholders of the project and usability of the provided solutions from the perspective of IoT platform creators,
- 24. Introduction to Interoperability for Heterogeneous IoT Platforms 9 IoT platform owners, IoT application programmers and users investigating business perspectives and creating new business models. These results have allowed to start INTER-IoT ecosystem and new features and components: methodologies, tools, protocols and API. The variety and cross availability of the results could be used to build and integrate services and platforms at different layers according to the needs of the stakeholders and developers. The availability of more and new data will stimulate the creation of new opportunities and products. 3.1 INTER-LogP: Interoperability for Transport and Logistics in a Port Environment In the ports of the future, port users, equipment and infrastructures will achieve a zero distance interaction offering more sustainable transport solutions. The use of IoT platforms will enable locating, monitoring, and handling different transport and cargo equipment and storage areas. The requirements for a better management of equipment and resources and the huge complexity of interactions involving large quantity of simultaneous transport movements around big logistics nodes (e.g., con- tainer terminals, ports, warehouses and dry ports) originates the need to introduce IoT platforms with multiple sensors in all logistics elements to control and monitor the several operations like energy consumption, gas emissions, or machine status. With these platforms, logistics service providers will be able to monitor and control in real time all the operations and movements of freight, equipment, vehicles and drivers on logistics nodes. The Port of Valencia premises extend for several square kilometres. It is the largest Mediterranean port in terms of container handling. The port contains five container terminals (e.g., NOATUM and MSC), and several other facilities (e.g., train freight station, warehouses, and parking spaces). The port includes several kilometres of road within the premises. The Port Authority has several deployed IoT platforms connected to different HMI and SCADA with different goals (e.g., traffic management,security,safetyandenvironmentalprotection,orvesselsidentification). Some of these platforms provide selected data to the Port Community System (PCS) like tamper proof RFID tags and e-seals that are installed on trucks and semi-trailers. In particular, A Port Community System is an electronic platform that connects the multiple systems operated by a variety of organisations that make up a seaport, airport or inland port community. It is shared in the sense that it is set up, organised and used by firms in the same sector—in this case, a port community. There is an increasing need that trucks, vehicles and drivers seamlessly interoperate with the port infrastructures and vice versa. All deployed IoT platforms do not interoperate as they are based on different standards, and remain isolated with a clear lack of interoperability at all layers. NOATUM Container Terminal is one of the biggest container terminals in the Mediterranean located at the port of Valencia. It is the fifth largest European port in
- 25. 10 C. E. Palau et al. container handling, i.e. it deals with more than 50,000 movements per day, produced by more than 200 container handling units (e.g., cranes, forklifts, RTGs, internally owned tractors and trailers, etc.); more than 4,000 trucks and other vehicles visit terminal premises; with more than 10,000 containers involved in these movements. These values show the complexity of this environment and the opportunities that the information compiled by the sensors installed on the equipment, trucks and containers; and the IoT interconnected architectures can bring to the terminal (e.g., in terms of optimization in the operations, safety, security or cost and energy savings). Container terminals like the one managed by the NOATUM have a huge number of sensors, CPS (Cyber Physical Systems) and smart objects; fixed and mobile deployed and exchanging information within one or between several platforms deployed in their premises. The sensors from the internal equipment (i.e., container terminal IoT ecosystem), constitute 5% of total vehicles moving daily within terminal premises, and they generate more than 8,000 data units per second. The other 95% of the vehicles are external trucks and other vehicles, with sensors belonging to other IoT ecosystems, currently unable to interact with the terminal IoT solution. Additionally, containers (mainly used to transport controlled temperature cargoes) have their own IoT architecture, which cannot be accessed by the terminal, when the container is stored in the yard or moved across it. This lack of interoperability of outdoor ambulatory IoT things based on heterogeneous architectures represents a big barrier that INTER-IoT aims at removing. This use case illustrates the need to seamlessly IoT platforms interoperation within port premises, e.g., container terminal, transportation companies, warehouses, road hauliers, port authorities, customs, border protection agencies, and outside the port. Port IoT ecosystems use to be operated by a large number of stakeholders, and typically require high security and trust, due to mobility and seamless connectivity requirements, that currently are not available with the exception of proprietary and isolated solutions. Introduction of interoperability mechanisms and tools will there- fore bring about new solutions and services leading to developments of the ports of the future. 3.1.1 INTER-IoT Approach to INTER-LogP INTER-LogP will be an INTER-IoT outcome to facilitate interoperability of hetero- geneous Port Transport and Logistics-oriented IoT platforms already in place, i.e., VPF and NOATUM and other components that will be brought to the use case in order to achieve the INTER-IoT proposed goals, e.g., I3WSN from UPV and other IoT platforms from companies operating in the Port managed premises. The Port Authority of Valencia will provide its own IoT platform ecosystem to the project, including (i) the climate and weather forecast infrastructures, which monitor the environmental conditions in real-time and maintain historical data; (ii) beacon data acquisition system, which monitors and controls whenever necessary all the buoys distributed on the sea side; (iii) PCS-IoT platform, developed to cover different transportation and logistics components throughout the port premises, integrates an
- 26. Introduction to Interoperability for Heterogeneous IoT Platforms 11 internal communication network and connects (more than 400) operating companies in the port. NOATUM provides the SEAMS platform to be included in the INTER-LogP use case. SEAMS is an outcome from the Sea Terminals action (Smart, Energy Efficient and Adaptive Port Terminals) co-funded by the Trans-European Transport Network (TEN-T). It is an operational tool based on the reception of real-time energy and operative data coming from the whole machinery and vehicle fleets of NOATUM Container Terminal Valencia (NCTV). SEAMS integrates the whole set of machines (including Rubber Tyre Gantry cranes (RTG), Ship-To-Shore cranes (STS), Terminal Tractors (TT), Reach Stackers (RS) and Empty Container Handlers (ECH)) and vehicles deployed and available in the terminal premises. INTER-IoT will help to expand the possibilities offered by not only SEAMS and the sensors installed on its own container terminal vehicles and container handling equipment units, but also sensors available on third party equipment (i.e., reefer containers) and vehicles (i.e., external trucks picking up and delivering containers). Finally, it will allow installation of sensors on legacy equipment that does not have them available. Moreover, INTER-IoT will allow to seamlessly connecting the con- tainer terminal IoT ecosystem with other ecosystems owned by other parties, e.g., the port authority, road hauliers, the individual trucks, vehicles, containers and vessels through intelligent objects offered by different vendors, some of them managed by the PCS [30]. On the other hand, UPV provided I3WSN, semantic IoT methodology and plat- form deployed in application domains like factories, automotive and defence. This generic architecture was developed within a large Spanish National project FASyS and has been extended to be used in different areas like port transportation and m-health. The framework provides interoperability at different layers and includes reliability, privacy and security by design. Additionally, devices from the partners will be added to the trials and devices from the users (e.g., truck drivers or terminal operators) like smart phones will be added to the system following BYOD (Bring Your Own Device) philosophy, allowing the integration of COTS devices in the large scale trials. Although the different platforms that the transport and logistics use case integrates (in particular, IoT-PCS from VPF, NOATUM TOS, I3WSN UPV and the IoT plat- forms from other stakeholders) share some characteristics, they have different aims (i.e., focused on the particular benefits of the administrator/operator and use differ- ent technologies). All of them gather data, using different M2M and P2M protocols; some of them are cloud-based and others will be, but the most important thing is that they lack interoperability in terms of the five identified layers. There is a poten- tial integration using one of the platforms (i.e., IoT-PCS) as a matrix architecture; however interoperability and integration will not profit the power of the proposed approach neither the capabilities of interoperable architectures rather than intercon- nected architectures. The use case, mainly focused in the transportation of containers, as it is the most sensorized in port transportation (especially reefer and International Maritime Organization—IMO safe containers), may improve efficiency, security and benefits to the whole transport chain. Additionally, INTER-IoT will provide the pos-
- 27. 12 C. E. Palau et al. Fig. 3 INTER-IoT interconnection for m-Health (INTER-Health) sibility to interact with other IoT platforms available in the port surroundings like Valencia City FIWARE infrastructure (i.e., VLCi) that is an open platform that will provide contextual information for different services and interactions at data and services layers [31–33] (Fig. 3). 3.2 INTER-Health: Interoperability for Mobile Health for Chronic Patients The Decentralized and Mobile Monitoring of Assisted Livings’ Lifestyle use case, aims at developing an integrated IoT system for monitoring humans’ lifestyle in a decentralized way and in mobility, to prevent health issues mainly resulting from food and physical activity disorders. Users that attend nutritional out-patient care centres are healthy subjects with different risk degrees (normal weight, overweight, obese) that could develop chronic diseases. Only the obese (in case of second and third level obesity) need, at times, hospital care and get into a clinical and therapeutic route. The medical environment in which the pilot will be developed and deployed is the Dept. of Prevention/Hygiene Nutrition Unit at ASLTO5.
- 28. Introduction to Interoperability for Heterogeneous IoT Platforms 13 The use case will focus in the fact that in main chronic diseases, such as car- diovascular diseases, stroke, cancer, chronic respiratory diseases and diabetes, there are common and modifiable risk factors that are the cause of the majority of deaths (and of new diseases). Between the common and modifiable risk factors there are wrong lifestyles such as improper and hyper caloric diet and, in particular, the lack of physical activity. Every year in the world (World Health Organization and others, 2013): 2.8 million people die for obesity or overweight; 2.6 million people die for high cholesterol levels; 7.5 million people die for hypertension; 3.2 million people die for physical inactivity. These wrong lifestyles are expressed through the inter- mediate risk factors of raised blood pressure, raised glucose levels, abnormal blood lipids, particularly Low Density Lipoprotein (LDL cholesterol) and obesity (body mass index superior to 30kg/m2). According to the reference standard medical protocol for the global prevention and management of obesity, written by the World Health Organization, in order to assess the health status (underweight, normal weight, overweight, obesity) of the subject (of a given age) during the visit at the healthcare center, objective and subjective measurements should be collected (and/or computed) by a health-care team (doctor, biologist nutritionist, dietician, etc.). The objective measurements are: weight, height, body mass index (enabling diagnosis of overweight and obesity), blood pressure or waist circumference. The subjective measurements reported by the subject, are collected through computerized questionnaires, and concern the eating habits: quality and quantity of food consumed daily and weekly, daily consumption of main meals (breakfast, lunch, dinner and snacks) and the practice of physical activity (quality and quantity of physical activity daily and weekly). The physical activity degree is detected subjectively during the first visit and could be objectively monitoredthroughwearablemonitoringdevices.Onthebasisofthesemeasurements, the caloric needs are automatically calculated, and the diet of the subject is defined. From this point forward, the subject must be monitored periodically (for example, every three months) for a period of at least one year. Usually monitoring is carried out at the health-care center, where the objective and subjective measurements are cyclically repeated. Based on the results, and depending on the health status reached by the subject (improved or worsened), the possibility of redefining his diet and his physical activity is analyzed. By exploiting an integrated IoT environment, the aforementioned monitoring pro- cesscanbedecentralizedfromthehealthcarecentertothemonitoredsubjects’homes, and supported in mobility by using on-body physical activity monitors. Specifically, the system will be created by using a new IoT platform, named INTER-Health, obtained by integrating two already-existing heterogeneous, non-interoperable IoT platforms for e-Health according to the approach proposed in the INTER-IoT project, based on the INTER-FW and its associated methodology INTER-METH: (i) Uni- versAAL, developed by UPV, and (ii) BodyCloud [34], developed by UNICAL.
- 29. 14 C. E. Palau et al. 3.2.1 INTER-IoT Approach to INTER-Health There is a need of integrating different IoT platforms as proposed in the INTER- Health use case. The effective and efficient integration of heterogeneous e-Health IoT Platforms will provide an appropriate answer to the challenges described in INTER- IoT proposal. The two platforms considered are UniversAAL and BodyCloud, and the result of the integration will allow developing a novel IoT m-Health system for Lifestyle Monitoring [27]. This flexibility allows deploying universAAL-based solutions in multiple config- urations, such as local-only nodes, mobile nodes connected to server instances, or non-universAAL nodes connecting to a multi-tenant server. Communication between applications and/or sensors happens through three different buses. Messages and members are always described semantically using the domain ontologies at hand: (i) Context bus—An event-based bus for sharing contextual information from context publishers to context subscribers; (ii) Service bus—A request-based bus for on- demand execution and information retrieval from service callers to service providers and (iii) User Interface bus—A centrally-managed bus that allows applications to define abstract interfaces to be rendered by different User Interface (UI) modalities. In each bus, semantic reasoning is used to match the transferred messages to the appropriate destination. This way, applications and sensors only need to describe what they provide and what they require from others. There is no need to specify recipients, connections nor addresses explicitly [30]. BodyCloud is a SaaS architecture that supports the storage and management of body sensor data streams and the processing (online and offline analysis) of the stored data using software services hosted in the Cloud. In particular, BodyCloud endeavours to support several cross-disciplinary applications and specialized pro- cessing tasks. It enables large-scale data sharing and collaborations among users and applications in the Cloud, and delivers Cloud services via sensor-rich mobile devices. BodyCloud also offers decision support services to take further actions based on the analyzed BSN data [34]. The BodyCloud approach is centered around four main decentralized components (or sides), namely Body, Cloud, Viewer, Analyst: (i) Body-side is the component, currently based on the SPINE Android, that monitors an assisted living through wear- able sensors and stores the collected data in the Cloud by means of a mobile device; (ii) Cloud-side is the component, based on SaaS paradigm, being the first general- purpose software engineering approach for Cloud-assisted community BSNs; (iii) Viewer-side is the Web browser-enabled component able to visualize data analysis through advanced graphical reporting; and (iv) e Analyst-side is the component that supports the development of BodyCloud applications. The two platforms, UniversAAL and BodyCloud, share some high-level charac- teristics while differ in objectives and technology. Specifically, they are both e-Health platforms, based on Bluetooth technology to interact with measurement devices, and based on Cloud infrastructures to enable data storing, off-line analysis, and data visu- alization. However, they have different specific objectives and are not interoperable from a technological point of view (at each layer and at the global level). Their spe-
- 30. Introduction to Interoperability for Heterogeneous IoT Platforms 15 Fig. 4 INTER-IoT interconnection for m-Health (INTER-Health) cific objectives are complementary: UniversAAL is focused mainly on non-mobile remote monitoring based on non-wearable measurement devices, whereas Body- Cloud provides monitoring of mobile subjects through wearable devices organized as body sensor networks. Thus, their integration will produce a full-fledged m-Health integrated platform on top of which multitudes of m-Health services could be devel- oped and furnished. The use case will be fully deployable atop the integration of UniversAAL and BodyCloud: (i) the automated monitoring at the health-care center and the decentralization of the monitoring at the patients’ homes will be supported by UniversAAL remote services; (ii) the monitoring of mobile assisted livings would be enabled by the BodyCloud mobile services; (iii) new cross-platform services will be developed for enabling complete analysis of the measurement streams coming from assisted livings [28, 35] (Fig. 4). 4 INTER-IoT Progress Beyond the State of Art The overall concept of the INTER-IoT project targets a full-fledged robust approach for seamless integration of different IoT platforms within and across different appli-
- 31. 16 C. E. Palau et al. cation domains. Interoperability will be achieved at different layers, depending on the requirements of the specific scenario or the use case. The main outcomes of the project will be infrastructures for layer-oriented interoperability and a reference inter- operable meta-architecture; an interoperability framework and an API along with an engineering methodology driven by a toolbox to be used by third parties to integrate heterogeneous IoT platforms and thus implement interoperable IoT applications. INTER-IoT will focus on two application domains (m-health and port transportation and logistics) and on their integration. The project outcome will optimize different operations in these two domains and in their integration. However, the INTER-IoT approach will be easily reused in any application domain, in which there is a need to interconnect already deployed (heterogeneous) IoT platforms. Or even in cross application domains, where IoT platforms and smart objects from different applica- tion domains will require co-operation or interoperability between them. Based on these principles, INTER-IoT targets the following innovations [5, 6]. 4.1 Global Platform Interoperability Global interoperability of hardware/software infrastructures is usually based on stan- dards. However, as IoT is an evolving technology without specific central technical coordination and control, it is foreseen that many solutions and (pseudo) standards will be developed and proposed in the coming years. This will lead to massive hetero- geneity. Indeed, currently many different (quasi) standards do exist in the IoT arena addressing: communications, hardware, software, and data. However, they mainly refer to specific IoT objects (sensors, sensor networks, RFID, nanocomputers, etc.) or contexts (smart grid, health-care, logistics, etc.). From the communications view- point, standards protocols at different level (MAC, network, application) are avail- able: IEEE 802.11—WiFi, IEEE 802.16—WiMax, IEEE 802.15.4—LR-WPAN, 2G/3G/4G—Mobile Communication, Zigbee, Bluetooth, ANT+, NFC, M2M com- munications (M-Bus, WM-Bus, UWB, ModBus, Z-Wave), M2M ETSI, IPv4, IPv6, 6LowPAN, TCP, UDP, ISO/IEEE 11073 for medical devices, CoAP, HTTP, MQTT, XMPP, DDS, AMQP, Websocket, etc. From the hardware perspective, the techno- logical state of the art is also heterogeneous: Arduino, BeagleBoard, TelosB sen- sor mote, RaspberryPI, pcDuino, Cubieboard, Libelium sensor/gateway, etc. The software realm is even richer including many base software technology (TinyOS, Contiki, FreeRTOS, eCos, Android, Ubuntu, Java, WebRTC, REST, WAMP, Django, etc.) and middleware solutions (FedNet, Ubicomp, SmartProducts, ACOSO, SkyNet, etc.), including cloud computing-based infrastructures (Amazon EC2, Google App Engine, Xively, MS Windows Azure). Also the data (and semantics) level presents high heterogeneity: XML (and XML-based like WSDL), JSON, UDCAP, uCode Relational Model, RDF, OWL, W3C SSN (Semantic Sensor Network) [4, 11]. It is worth noting that, when we consider a complete IoT platform, the complex- ity of technologies used to build up the platform further arises as each defined layer (device, networking, middleware, application service, data and semantics) exploits
- 32. Introduction to Interoperability for Heterogeneous IoT Platforms 17 specific solutions that need to be holistically adapted to form the final platform. For instance, several available platforms, each of which was designed and deployed to fulfil quasi similar goals but exploiting heterogeneous IoT technological solu- tions, or providing any (or even limited) interoperability [36]. Thus, it is critical to provide bottom-up “voluntary” approaches able to integrate, interconnect, merge, heterogeneous IoT platforms to build up extreme-scale interoperable ecosystems on top of which large-scale applications can be designed, implemented, executed and managed [37]. INTER-IoT will provide the first full-fledged methodological and technologi- cal suite to completely address the fundamental issue of “voluntary interoperabil- ity”. The suite will be composed of three main building blocks: (i) Layer-oriented infrastructures to adapt heterogeneous peer layers (device-to-device, networking- to-networking, middleware-to-middleware, application services-to-application ser- vices, data-to-data, and semantics-to-semantics); (ii) Interoperable open framework to program and manage integrated IoT platforms; (iii) Engineering methodology and tools to drive the integration process of heterogeneous IoT platforms. By using INTER-IoT, IoT heterogeneity will be turned from the most limiting factor for IoT technology diffusion to its greatest advantage due to the exploitation of spe- cific benefits and characteristics derived from multiple heterogeneous IoT platforms [15, 38, 39]. 4.2 Gateway and Device Interoperability As sensors, actuators and smart devices become smaller, more versatile, lower cost and more power efficient, they are being deployed in greater numbers, either as special-purpose devices or embedded into other products. The unification and con- vergence of the vast number of platforms already deployed, the accessibility (API and interfaces) of the platform to app developers, requires interoperability. Smart- phones are key components in Device-to-Device (D2D) communication and interop- erability, however there are many other types of devices that are currently deployed, both independently (e.g. smart watches and other wearables) and as part of other devices and platforms (e.g. consumer electronics or Cyber-Physical Systems). Dif- ferent communication protocols are used at device level. Here, Cellular and WiFi that are ubiquitous; they are evolving to support higher bandwidths and lower cost. Bluetooth is also becoming lower cost. New communication technologies like Blue- toothlowenergy(BluetoothLE)andNFCareopeningnewpossibilitiesforIoT.How- ever, also traditional communication protocols and mechanisms for sensors, actua- tors and smart objects have to be considered (e.g. ZigBee, ISA100, WirelessHart), in addition to other non-standard proprietary protocols developed by individual ven- dors, or even to new emerging protocols, e.g. [40, 41]. Different classes of IoT objects need different communication supports: e.g. ‘deterministic’ communication proto- cols (MAC and Routing layers) are not possible using current Internet protocols, but may be needed by some application. Standardization on these topics is just starting
- 33. 18 C. E. Palau et al. (e.g., detnet working group in IETF). Yet, deterministic communications will hardly meet the interoperability requirements of all IoT objects. Typically device-level inter- connection of IoT architectures has been performed using gateway-based solutions. FP7 Butler project proposed a device-centric architecture where a SmartGateway allows interconnection between smart objects (sensors, actuators, gateways) using IPv6 as communication protocol. Different approaches have been developed to inte- grate and interoperate devices in IoT architectures. Basic devices (e.g. sensors, tags, actuators) are virtualized and can be composed in more complex smart systems. The idea has been to create virtual objects, allowing object composition, considering a virtual object as a counterpart of existing smart objects [19, 42, 43]. INTER-IoT will provide fundamental benefits and competitiveness improvements in the way IoT devices will communicate with each other and will interface with different IoT platforms and subsystems. One of the proposed progresses regarding D2D interaction is to complement standardized communication protocols (which are mostly deterministic and reactive) with an ability for objects to make sense of their surroundings in order to understand how to best interplay with their neigh- bours. This requires new ‘proactive’ and ‘predictive’ communications capabilities, whereby a node can determine its communication requirements and those of its neighbours well before communication is required. It has recently been proven that machine learning capabilities can run even on small sensors (with as little as 20 KB of RAM). INTER-IoT will develop an interoperable communication layer, even based on lightweight machine learning that also accommodate for opportunistic com- munications among heterogeneous nodes/devices, based on prediction mechanisms [21, 44]. 4.3 Networking Mobility and Interoperability IoT products will encompass different data communication scenarios. Some may involve sensors that send small data packets infrequently and do not prioritize timely delivery. Others may involve storage in order to sustain periods when the communi- cation link is down (e.g. Delay Tolerant Networks). Others may need high bandwidth but be able to accept high latency. And others may need high quality, high bandwidth, and low latency. Large amounts of traffic with relatively short packet sizes will require sophisticated traffic management. More efficient protocols can help reduce overhead but may present challenges to system integrity, reliability and scalability. Interface standardization is desirable so that IoT objects can communicate quickly and effi- ciently, and allow mobility between interoperable IoT platforms. IoT objects will need a way to quickly and easily discover each other and learn their neighbour’s capabilities [28, 45]. At networking and communications layer different protocols can be used like 6LowPAN, TCP/HTTP, UDP/CoAP. Communication between real objects and the gatewaycanbebasedonuniversalplugandplay(UPnP)orDLNA.Useofbusesbased on MQTT protocol can also be used to implement asynchronous communications
- 34. Introduction to Interoperability for Heterogeneous IoT Platforms 19 between entities. The most promoted networking protocol in IoT environments is IPv6 and its version for constrained devices 6LoWPAN, even though its adoption is slow, and without global adoption it will be impossible for IoT to proliferate. IPv6 provides the following benefits to IoT configurations: (i) IPv6 auto-configuration; (ii) Scalable address space (sufficiently large for the enormous numbers of IoT objects envisioned); (iii) Redefined headers that enable header compression formats; (iv) Easy control of the system of things: (v) Open/Standard communications; (vi) IPv6 to IPv4 transition methods; (vii) IPv6 over constrained node networks (6LO, 6LoWPAN [11, 46]. IoT platforms have usually mechanisms for integrating with external systems, but they are all based on specific point to point connections, usually with legacy systems in the area of interest of the IoT platform (city, neighbourhood, factory, hospital, port, house, etc.). The integration between IoT platforms will allow tracking the behaviour of these objects when they move outside the intrinsic area of interest and get into the area of interest of another IoT platform. The pub/sub mechanism usually available in the communication buses at the core of these IoT platforms and the possible object context sharing allow a powerful and easy way to track the behaviour of these objects among different IoTs scope areas. INTER-IoT will provide support for as many networks as possible, including as many networks as possible in the INTER-FW definition. Main contributions of the project will be focused to multihoming capabilities among the different IoT objects in order to provide network offloading connectivity and seamless mobility between different IoT platforms of moving objects. INTER-IoT will use SDN components to configure interconnection at network level and also will use ICN/CCN as support for interoperability and roaming of smart objects between different platforms of the same ecosystem while keeping secure connectivity and also guaranteed quality of service. Resource management and scalability so as reliability, trust, privacy and security will be non-functional requirements that will be addressed by the project to provide optimal interoperability at network layer [6, 30, 47]. 4.4 Middleware Platform Interoperability Middleware, widely used in conventional distributed systems, is a fundamental tool for the design and implementation of both IoT devices and IoT systems. They pro- vide general and specific abstractions (e.g., object computation model, inter-object communication, sensory/actuation interfaces, discovery service, knowledge manage- ment), as well as development and deployment tools, through which IoT devices, IoT systems and their related applications can be easily built up. Indeed, middle- ware (i) enable connectivity for huge numbers of diverse components comprised at Device Layer, (ii) realize their seamless interoperability at Networking Layer, and (iii) ensure operational transparency at Application Service Layer. In such a way, heterogeneous, often complex and already existing IoT devices and IoT systems, belonging to different application domains and not originally designed to be con-
- 35. 20 C. E. Palau et al. nected, can be easily integrated, effectively managed and jointly exploited. It follows that the role of middleware within the cyberphysical, heterogeneous, large scale and interconnected IoT scenario is even more crucial than within conventional distributed systems. Over the years, many IoT middleware have been proposed, so much so that only in [11, 34] more than 70 contributions have been surveyed and compared. The best way to analyse such plethora of middleware, regardless of the specific detail or technology, is to build up comparison frameworks around well-defined criteria to effectively highlight their salient differences and similarities. In very few words, LinkSmart is service-based middleware for ambient intelli- gence (AmI) systems, supporting devices communication, virtualization, dynamic reconfiguration, self-configuration, energy optimization and security by means of WebService-based mechanisms enriched by semantic resolution. UbiROAD is semantic, context-aware, self-adaptive agent-based middleware for smart road envi- ronments, aiming at collecting, analysing and mining real time data from in-car and roadside heterogeneous devices. ACOSO is an agent-oriented middleware with a related methodology fully supporting the development (from the modelling to the implementation phase), management and deployment of smart objects and IoT systems, as well as their integration with the Cloud. IMPReSS, finally, is a mid- dleware conceived for the rapid development of context-aware, adaptive and real- time monitoring applications to control and optimize energy usage in smart cities [2, 39, 48, 49]. In particular, INTER-IoT will focus on defining component-based methods for middleware interoperability/integration; in particular, we focus on discovery, man- agement and high-level communication of IoT devices in heterogeneous IoT plat- forms. We will define two main approaches: (i) definition of overlay middleware components able to couple the middleware components of the heterogeneous IoT platforms; (ii) virtualization of the heterogeneous middleware components. In the first approach, we will design overlay middle components such as mediators and brokers [6]. 4.5 Semantic Interoperability Semantic interoperability can be conceptualized as an approach to facilitate “com- bining” multiple IoT platforms. The simplest case, of combining two IoT plat- forms, could be addressed by developing a one-to-one translator (a “gateway”) to allow“semantic understanding” between them. However, this approach does not scale, as for every subsequent entity joining an assembly of N platforms. Thus, N translators would have to be created. The two main approaches to avoid this problem, and deal with semantic interoperability are: (i) common communication standards; (ii) ontology and semantic data processing [50]. Developing a common communi- cation standard, is tried in the travel domain with the OTA message specification a standard consisting on a set of (XML-demarcated) messages; or in the healthcare domain (and thus related to the INTER-Health use case) with OpenEHR, which is an
- 36. Introduction to Interoperability for Heterogeneous IoT Platforms 21 opendomain-drivenplatformfordevelopingflexiblee-healthsystems.Here,multiple projects strive to establish interoperability between already known standards and the OpenEHR, e.g. establishing semantic interoperability of the ISO EN 13606 and the OpenEHRarchetypes.SimilarlytheThink!EHRPlatform(healthdataplatformbased on vendor-neutral open data standards designed for real-time, transactional health data storage, query, retrieve and exchange); aims at establishing interoperability of the OpenEHR and the HL7 standard (a framework for the exchange, integration, shar- ing, and retrieval of electronic health information). Interestingly, development of the Think!EHR Platform had to deal with the data standards problem caused by existence of HL7 RIMv3, ISO13606, and OpenEHR standards. While it is possible to envision an approach similar to this, applied to individual domains, it is not likely to be easily generalizable to support interactions between domains. Therefore, approaches based on ontologies and semantic data processing will be used in the project [51, 52]. INTER-IoT approach will be based on development of a generic ontology of an IoT Platform (GOIoTP). The GOIoTP will be used as the centerpiece for establishing platform interoperability (allowing for, among others, data interoperability, message translation, etc.). It should be stressed that, state-of-the-art ontologies of the IoT, will constitute the starting point for construction of the GOIoTP, needed in our project. The proposed approach will require, (i) ontology matching, (ii) merging, noting that ontology merging is often reduced to ontology matching, as well as (iii) techniques for establishing semantic distance (needed for ontology matching). Observing that this approach allows “understanding” and adaptability (handled through ontology adaptation) of heterogeneous data [39, 53, 54]. The creation of GOIoTP in INTER-IoT, combined with the state-of-the-art approaches to ontology matching/merging will allow development of a comprehen- sive support for facilitation of semantic interoperability between IoT platforms. The resulting approach, based on conducted research, will consist both of the methods and supporting tools and will include, among others, methods for: • Combining two (or more) IoT platforms with explicitly defined ontologies. Here, among others, the following issues will be researched: (i) bringing multiple ontolo- gies to a common format / language (for example, transforming XML into RDF and further transforming it into OWL-demarcated ontology using XLST), (ii) ontology matching, to allow for (iii) ontology merging into the extended GOIoTP (as the top-level ontology). • Combining two (or more) IoT platforms with explicitly defined ontologies. Here, among others, the following issues will be researched: (i) bringing multiple ontolo- gies to a common format / language (for example, transforming XML into RDF and further transforming it into OWL-demarcated ontology using XLST), (ii) ontology matching, to allow for (iii) ontology merging into the extended GOIoTP (as the top-level ontology) [55]. • Joining an “incoming” IoT platform (with an explicitly defined ontology) to an existing federation of IoT platforms (with an already defined common ontology). Here the process would be somewhat a simplified version of the previous method as only two ontologies will be integrated.
- 37. 22 C. E. Palau et al. • Dealing with IoT platforms without an explicitly defined ontology / taxonomy / etc. Here, appropriate set of tools will be adapted to help instantiate an ontology for the multi-IoT-platform under construction. Specifically, the ontology will be built on the basis of information contained in one, or more: (i) definition of used data; (ii) structure of the database(s); (iii) queries issued on the database(s); and (iv) exchanged messages [54]. 4.6 Cross-Layer Approach for Interoperability INTER-IoT specifically aims at creating cross-layer interoperability and integration between heterogeneous IoT platforms. Cross-layer approaches are fundamental to made interoperable/integrate the whole layer stack (device, networking, middleware, application service, data and semantics) of IoT platforms. Cross layering will be therefore based on the outcomes of the previous points. Moreover, important requirements and features such as Quality of Service (QoS), Quality of Experience (QoE), Security, Privacy, Trust and Reliability, require to be addressed at each layer with different mechanisms. Such transversal approach allows retaining the benefits of a layered architecture (e.g., modularity, interoperability, etc.) but adding, at the same time, flexibility (e.g., optimization, tunable design, etc.) to those components that require it. Considering the heterogeneity and spread of IoT devices and IoT applications, it is straightforward that such design choice is more than suitable to properly support (i) dynamic QoS and QoE (the former, basically aiming at splitting traffic up into priority classes and trying to guarantee a particular performance metric, the latter at combining more subjective aspects related to user perception into evaluating a service); (ii) novel security and privacy techniques (that consider the cyber-physical nature of IoT devices as well as of the IoT application contexts); extended trust models (in which unconventional actors, likesocial networks, playanimportant role) and(iv) enhancedreliabilitymechanisms (to deal with failure of resource-limited IoT device, lack of coverage from access networks in some region, rapid application context switches, etc.) [11, 56]. 5 Conclusions In this chapter we have presented the INTER-IoT systemic approach, which is being created within the INTER-IoT project together with necessary software tools and enduser applications. It will provide ways of overcoming interoperability prob- lems between heterogeneous IoT systems across the communication/software stack, including: devices, networks, middleware, application services, data/semantics. Henceforth, reuse and integration of existing and future (even standard) IoT sys- tems will be facilitated and made possible to obtain interoperable ecosystems of IoT platforms.
- 38. Introduction to Interoperability for Heterogeneous IoT Platforms 23 As the ecosystem of interoperable devices and services expands, so will increase the value of building new devices for and applications working within this ecosystem. This emerging ecosystem is not owned by any business or entity, but rather it exists to enable many entities to pool their resources together to create larger opportunities for all. Open interoperability delivers on the promise of open source software, enabling vendors and developers to interact and interoperate, without interfering with anyone’s ability to compete by delivering a superior product and experience. In the absence of global IoT standards, the INTER-IoT project and results will support and make it easy for any company to design IoT devices, smart object, or services and get them to market quickly, to a wider client-base, and to create new IoT interoperable ecosystems. In the long term, ability for multiple applications to connect to and interact with heterogeneous sensors, actuators, and controllers, thus making them interoperable, will become a huge enabler for new products and services. References 1. Fortino, G., Savaglio, C., Spezzano, G., Zhou, M.C.: Internet of things as system of systems: a review of methodologies, frameworks, platforms, and tools. IEEE Trans. Syst. Man Cybern. Syst. 51(1), 223–236 (2021) 2. Savaglio, C., Ganzha, M., Paprzycki, M., Badica, C., Ivanovic, M., Fortino, G.: Agent-based Internet of Things: state-of-the-art and research challenges. Future Gener. Comput. Syst. 102, 1038–1053 (2020) 3. Vermesan, O., Friess, P. (eds.): Digitising the Industry Internet of Things Connecting the Phys- ical, Digital and Virtual Worlds. Riverpublishers (2016) 4. Vermesan, O., Friess, P. (eds.): D3.2. Methods for Interoperability and Integration, vol. 2. INTER-IoT H2020 project, October 2017. https://inter-iot.eu/deliverables 5. Broring, A., Zappa, A., Vermesan, O., Främling, K., Zaslavsky, A., Gonzalez-Usach, R., Szmeja, P., Palau, C., Jacoby, M., Zarko, I.P., Sour-sos, S., Schmitt, C., Plociennik, M., Krco, S., Georgoulas, S., Larizgoitia, I., Gligoric, N., García-Castro, R., Serena, F., Orav, V.: Advancing IoT Platform Interoperability. River Publishers, The Nederlands (2018) 6. Gravina, R., Palau, C.E., Manso, M., Liotta, A., Fortino, G. (eds.): Integration, Interconnection, and Interoperability of IoT Systems. Internet of Things. Springer International Publishing (2018) 7. Fortino, G., Palau, C.E., Guerrieri, A., Cuppens, N., Cuppens, F., Chaouchi, H., Gabillon, A. (eds.): Interoperability, Safety and Security in IoT—Third International Conference, InterIoT 2017, and Fourth International Conference, SaSeIot 2017, Valencia, Spain, November 6–7, 2017, Proceedings. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol. 242. Springer (2018) 8. Fortino, G., Garro, A., Russo, W.: Achieving mobile agent systems interoperability through software layering. Inf. Softw. Technol. 50(4), 322–341 (2008) 9. Fortino, G., Garro, A., Russo, W.: D4.5. Interoperable IoT Framework API and tools v1. INTER-IoT H2020 project, October 2017. https://inter-iot.eu/deliverables 10. Fortino, G., Savaglio, C., Palau, C.E., de Puga, J.S., Ghanza, M., Paprzycki, M., Montesinos, M., Liotta, A., Llop, M.: Towards multi-layer interoperability of heterogeneous IoT platforms: the inter-IoT approach. Internet of Things 199–232 (2018) 11. Fortino, G., Savaglio, C., Palau, C.E., de Puga, J.S., Ghanza, M., Paprzycki, M., Montesinos, M., Liotta, A., Llop, M.: D3.3. Methods for Interoperability and Integration Final. INTER-IoT H2020 project, June 2018. https://inter-iot.eu/deliverables
- 39. 24 C. E. Palau et al. 12. Fortino, G., Savaglio, C., Palau, C.E., de Puga, J.S., Ghanza, M., Paprzycki, M., Montesinos, M., Liotta, A., Llop, M.: D4.2. Final Reference IoT Platform Meta-architecture and Meta-data Model. INTER-IoT H2020 project, January 2018. https://inter-iot.eu/deliverables 13. Fortino, G., Savaglio, C., Palau, C.E., de Puga, J.S., Ghanza, M., Paprzycki, M., Montesinos, M., Liotta, A., Llop, M.: D4.6. Interoperable IoT Framework API and Tools, Model and Engine v2. INTER-IoT H2020 project, June 2018. https://inter-iot.eu/deliverables 14. Fortino, G., Savaglio, C., Palau, C.E., de Puga, J.S., Ghanza, M., Paprzycki, M., Montesinos, M., Liotta, A., Llop, M.: D4.3. Initial Reference IoT Platform Meta-Architecture and Meta Data Model Interoperable IoT framework Model and Engine v1. INTER-IoT H2020 project, October 2017. https://inter-iot.eu/deliverables 15. Fortino, G., Savaglio, C., Palau, C.E., de Puga, J.S., Ghanza, M., Paprzycki, M., Montesinos, M., Liotta, A., Llop, M.: D5.1. Design Patterns for Interoperable IoT Systems. INTER-IoT H2020 project, December 2017. https://inter-iot.eu/deliverables 16. Fortino, G., Savaglio, C., Palau, C.E., de Puga, J.S., Ghanza, M., Paprzycki, M., Montesinos, M., Liotta, A., Llop, M.: D5.2. INTER-Meth: Full-fledged Methodology for IoT Platforms Integration. INTER-IoT H2020 project, December 2017. https://inter-iot.eu/deliverables 17. Fortino, G., Savaglio, C., Palau, C.E., de Puga, J.S., Ghanza, M., Paprzycki, M., Montesinos, M., Liotta, A., Llop, M.: D6.1. System Integration Plan. INTER-IoT H2020 project, August 2017. https://inter-iot.eu/deliverables 18. Yacchirema, D.C., Esteve, M., Palau, C.E.: Design and implementation of a gateway for per- vasive smart environments. In: 2016 IEEE International Conference on Systems, Man, and Cybernetics (SMC), pp. 004454–004459, October 2016 19. Aloi, G., Fortino, G., Gravina, R., Pace, P., Caliciuri, G.: Edge computing-enabled body area networks. In: 2018 32nd International Conference on Advanced Information Networking and Applications Workshops (WAINA), pp. 349–353, Krakow, May 2018. IEEE 20. Mocanu, D.C.: On the synergy of network science and artificial intelligence. In: Proceedings of the Twenty-Fifth International Joint Conference on Artificial Intelligence, IJCAI’16, pp. 4020–4021, New York, New York, USA, July 2016. AAAI Press 21. Cankar, M., Gorriti, E.O., Markovič, M., Fuart, F.: Fog and cloud in the transportation, marine and eHealth domains. In: Heras, D.B., Bougé, L., Mencagli, G., Jeannot, E., Sakellariou, R., Badia, R.M., Barbosa, J.G., Ricci, L., Scott, S.L., Lankes, S., Weidendorfer, J. (eds.) Euro-Par 2017: Parallel Processing Workshops. Lecture Notes in Computer Science, vol. 10659, pp. 292–303. Springer International Publishing, Cham (2018) 22. Belsa, A., Sarabia-Jacome, D., Palau, C.E., Esteve, M.: Flow-based programming interoper- ability solution for IoT platform applications. In: 2018 IEEE International Conference on Cloud Engineering (IC2E), pp. 304–309, Orlando, FL, April 2018. IEEE 23. Ganzha, M., Paprzycki, M., Pawłowski, W., Szmeja, P., Wasielewska, K.: Semantic technolo- gies for the IoT: an inter-IoT perspective. In: 2016 IEEE First International Conference on Internet-of-Things Design and Implementation (IoTDI), pp. 271–276, April 2016 24. Ganzha, M., Paprzycki, M., Pawłowski, W., Szmeja, P., Wasielewska, K.: Semantic interop- erability in the Internet of Things: an overview from the INTER-IoT perspective. J. Netw. Comput. Appl. 81, 111–124 (2017) 25. Fortino, G., Savaglio, C., Palau, C.E., de Puga, J.S., Ghanza, M., Paprzycki, M., Montesinos, M., Liotta, A., Llop, M.: D7.3. Final Evaluation Report. INTER-IoT H2020 project, December 2018. https://inter-iot.eu/deliverables 26. Yacchirema, D., Gonzalez-Usach, R., Esteve, M., Palau, C.E.: Interoperability of IoT platforms applied to the transport and logistics domain. In: Transport Arena Research Conference 2018, Austria. TRA (2018) 27. Margherita, G., Claudio, M., Anna, C., Marina, M., Ilaria, D.L., Monica, M., Massimo, U., Luciano, B., Massimo, C., Angelina, D.T., Bartolomeo, A., Anna, A., Domenica, P., Lucia, A. Fortunata, M., Rina: Telemedicine and prevention: electromedical devices experimentation in the nutritional counseling. Mattioli 1885 SpA Italy (2017) 28. Margherita, G., Claudio, M., Anna, C., Marina, M., Ilaria, D.L., Monica, M., Massimo, U., Luciano, B., Massimo, C., Angelina, D.T., Bartolomeo, A., Anna, A., Domenica, P., Lucia, A.
- 40. Introduction to Interoperability for Heterogeneous IoT Platforms 25 Fortunata, M., Rina: D6.3. Site Acceptance Test Plan. INTER-IoT H2020 project, September 2018. https://inter-iot.eu/deliverables 29. Margherita, G., Claudio, M., Anna, C., Marina, M., Ilaria, D.L., Monica, M., Massimo, U., Luciano, B., Massimo, C., Angelina, D.T., Bartolomeo, A., Anna, A., Domenica, P., Lucia, A. Fortunata, M., Rina: D7.2. Technical Evaluation and Assessment Report. INTER-IoT H2020 project, September 2018. https://inter-iot.eu/deliverables 30. Yacchirema, D., Sarabia-Jácome, D., Palau, C.E., Esteve, M.: System for monitoring and sup- porting the treatment of sleep apnea using IoT and big data. Pervasive Mobile Comput. 50, 25–40 (2018) 31. Drozdowicz, M., Alwazir, M., Ganzha, M., Paprzycki, M.: Graphical interface for ontol- ogy mapping with application to access control. In: Nguyen, N.T., Tojo, S., Nguyen, L.M., Trawiński, B. (eds.) Intelligent Information and Database Systems. Lecture Notes in Computer Science, vol. 10191, pp. 46–55. Springer International Publishing, Cham (2017) 32. Drozdowicz, M., Alwazir, M., Ganzha, M., Paprzycki, M.: D6.2. Factory Acceptance Test Plan. INTER-IoT H2020 project, Febuary 2018. https://inter-iot.eu/deliverables 33. Drozdowicz, M., Alwazir, M., Ganzha, M., Paprzycki, M.: D8.6. Report on Impact Creation at M36. INTER-IoT H2020 project, December 2018. https://inter-iot.eu/deliverables 34. Fortino, G., Parisi, D., Pirrone, V., Di Fatta, G.: Bodycloud: a SaaS approach for community body sensor networks. Future Gener. Comput. Syst. 35, 62–79 (2014) 35. Drozdowicz, M., Ganzha, M., Paprzycki, M.: Semantically enriched data access policies in eHealth. J. Med. Syst. 40(11), 238 (2016) 36. Fortino, G., Savaglio, C., Zhou, M.: Toward opportunistic services for the industrial Internet of Things. In: 2017 13th IEEE Conference on Automation Science and Engineering (CASE), pp. 825–830, Xi’an, August 2017. IEEE 37. Vargas, D.C.Y., Salvador, C.E.P.: Smart IoT gateway for heterogeneous devices interoperability. IEEE Lat. Am. Trans. 14(8), 3900–3906 (2016) 38. Fortino, G., Gravina, R., Russo, W., Savaglio, C.: Modeling and simulating Internet of Things systems: a hybrid agent-oriented approach. Comput. Sci. Eng. 19(5), 68–76 (2017) 39. Ganzha, M., Paprzycki, M., Pawłowski, W., Szmeja, P., Wasielewska, K.: Alignment-based semantic translation of geospatial data. In: 2017 3rd International Conference on Advances in Computing, Communication and Automation (ICACCA) (Fall), pp. 1–8, Dehradun, India, September 2017. IEEE 40. Smart, G., Deligiannis, N., Surace, R., Loscrì, V., Fortino, G., Andreopoulos, Y.: Decentralized time-synchronized channel swapping for ad hoc wireless networks. IEEE Trans. Veh. Technol. 65(10), 8538–8553 (2016) 41. Pace, P., Fortino, G., Zhang, Y., Liotta, A.: Intelligence at the edge of complex networks: the case of cognitive transmission power control. IEEE Wirel. Commun. 26(3), 97–103 (2019) 42. Gonzalez-Usach, R., Collado, V., Esteve, M., Palau, C.E.: AAL open source system for the monitoring and intelligent control of nursing homes. In: 2017 IEEE 14th International Confer- ence on Networking, Sensing and Control (ICNSC), pp. 84–89, May 2017 43. Pace, P., Aloi, G., Gravina, R., Fortino, G., Larini, G., Gulino, M.: Towards interoperability of IoT-based health care platforms: the inter-health use case. In: Proceedings of the 11th EAI International Conference on Body Area Networks, BodyNets’16, pp. 12–18, Brussels, BEL, December 2016. ICST (Institute for Computer Sciences, Social-Informatics and Telecommu- nications Engineering) 44. Exarchakos, G., Oztelcan, I., Sarakiotis, D., Liotta, A.: plexi: adaptive re-scheduling web- service of time synchronized low-power wireless networks. J. Netw. Comput. Appl. 81, 62–73 (2017) 45. Pradilla, J., González, R., Esteve, M., Palau, C.: Sensor observation service (SOS)/constrained application protocol (COAP) proxy design. In: 2016 18th Mediterranean Electrotechnical Con- ference (MELECON), pp. 1–5, April 2016. ISSN: 2158-8481 46. Kotian, R., Exarchakos, G., Stavros, S., Liotta, A.: Impact of transmission power control in multi-hop networks. Future Gener. Comput. Syst. 75, 94–107 (2017)
- 41. 26 C. E. Palau et al. 47. Kotian, R., Exarchakos, G., Stavros, S., Liotta, A.: D7.1. Evaluation Plan. INTER-IoT H2020 project, March 2018. https://inter-iot.eu/deliverables 48. Savaglio, C., Fortino, G., Zhou, M.: Towards interoperable, cognitive and autonomic IoT sys- tems: an agent-based approach. In: 2016 IEEE 3rd World Forum on Internet of Things (WF- IoT), pp. 58–63, December 2016 49. Savaglio, C., Fortino, G., Gravina, R., Russo, W.: A methodology for integrating Internet of Things platforms. In: 2018 IEEE International Conference on Cloud Engineering (IC2E), pp. 317–322, Orlando, FL, April 2018. IEEE 50. Ganzha, M., Paprzycki, M., Pawłowski, W., Szmeja, P., Wasielewska, K., Palau, C.E.: From implicit semantics towards ontologies—practical considerations from the INTER-IoT perspec- tive. In: 2017 14th IEEE Annual Consumer Communications Networking Conference (CCNC), pp. 59–64, January 2017. ISSN: 2331-9860 51. Ganzha, M., Paprzycki, M., Pawłowski, W., Szmeja, P., Wasielewska, K.: Streaming semantic translations. In: 2017 21st International Conference on System Theory, Control and Computing (ICSTCC), pp. 1–8, Sinaia, October 2017. IEEE 52. Pileggi, S.F., Palau, C.E., Esteve, M.: Building semantic sensor web: knowledge and interoper- ability. In: Proceedings of the International Workshop on Semantic Sensor Web (SSW), (IC3K 2010), vol. 1, pp. 15–22. INSTICC, SciTePress (2010) 53. Tkaczyk, R., Szmeja, P., Ganzha, M., Paprzycki, M., Solarz-Niesluchowski, B.: From relational databases to an ontology—practical considerations. In: 2017 21st International Conference on System Theory, Control and Computing (ICSTCC), pp. 254–261, Sinaia, October 2017. IEEE 54. Ganzha, M., Paprzycki, M., Pawłowski, W., Szmeja, P., Wasielewska, K.: Identifier manage- ment in semantic interoperability solutions for IoT. In: 2018 IEEE International Conference on Communications Workshops (ICC Workshops), pp. 1–6, Kansas City, MO, May 2018. IEEE 55. Moreira, J.L., Daniele, L.M., Pires, L.F., van Sinderen, M.J., Wasielewska, K., Szmeja, P., Pawłowski, W., Ganzha, M., Paprzycki, M.: Towards IoT platforms integration: semantic trans- lations between W3C SSN AND ETSI SAREF. In: Semantics. Workshop Semantic Interoper- ability and Standardization in the IoT (SIS-IoT), November 2017 56. Frustaci, M., Pace, P., Aloi, G.: Securing the IoT world: issues and perspectives. In 2017 IEEE Conference on Standards for Communications and Networking (CSCN), pp. 246–251, Helsinki, Finland, September 2017. IEEE
- 42. INTER-IoT Requirements Pablo Giménez, Miguel Llop, Regel Gonzalez-Usach, and Miguel A. Llorente Abstract There are some significant tasks in the first stage of a project in order to achieve success when taking out a new product, a service or release a software. It is essential to know what is in the market and what the potential customers want. There- fore, during the project, we performed a market analysis regarding all the products related with IoT and we had interviews with all the involved actors in all the domains, such as developers, integrators, operators, domain users, clients, etc. Furthermore, from the previous information we define the requirements in order to determine how the system should work and what it should do. This chapter presents the process and the results of these three activities developed in the first stage of the INTER- IoT project: market analysis, stakeholders analysis, and requirements analysis. This task was done for the five different products defined in the project: INTER-LAYER, INTER-FW, INTER-METH, INTER-LogP, and INTER-Health. These tasks have been made using the VOLERE methodology, which is an excellent methodology to extract conclusions and provide results following a systematic approach. 1 Introduction Requirements are an essential part of any software project and it is critical to devote enough time to identify all project requirements [1]. The gathering of and compiling of requirements for a software project requires a very tight collaboration between the clients, the developers and the software integrators. This is because the behaviour attributes and properties of the future system rely dramatically on a correct identifi- cation of requirements [2]. P. Giménez (B) · M. Llop Fundación Valenciaport, Valencia, Spain e-mail: pgimenez@fundacion.valenciaport.com R. Gonzalez-Usach Universitat Politècnica de València, Valencia, Spain M. A. Llorente Prodevelop, Valencia, Spain © Springer Nature Switzerland AG 2021 C. E. Palau (eds.), Interoperability of Heterogeneous IoT Platforms, Internet of Things, https://doi.org/10.1007/978-3-030-82446-4_2 27
- 43. 28 P. Giménez et al. There are two main reasons for specifying requirements. First, it guides design and decision-making processes towards a correct solution [3]. In addition, it provides a basis of testing the implemented solution is correct [1]. It must be noted that the creation of the INTER-IoT framework represents a vast and very complex development task that encompasses all layers from IoT systems, and novel aspects in IoT-related software [4]. Therefore, requirements on each level of the IoT stack [5] must be identified and collected, including the platform layer [6], middleware [7], gateway or fog domain [8], network [8], semantics [9, 10], service and application layer [11, 12], security [13] and cross-layer elements [14] and other IoT-related aspects [5]. The first stage of the project was focused on the definition of all the elements necessary for the development of the project. The objective of the initial phase was to gather and define the set of technical requirements for the development of INTER- IoT framework and for each of its core components. The work in this work package was structured in five tasks: • Identify and analyse stakeholders and products for both use cases addressed in the project: smart port logistics and smart mobile m-health. • Collect and analyse requirements from targeted stakeholders, and other involved actors to develop the INTER-IoT products. • Identify and design suitable business models for the INTER-IoT system. • Define comprehensive suitable scenarios for the use cases and the targeted stake- holders. • Analyse legal and regulatory requirements that are relevant to INTER-IoT. 1.1 Methodology The methodology selected as a reference for most of the above tasks is VOLERE1 [15] , as it represents a solid methodology widely used by thousands of organizations around the world in order to define, discover, communicate and manage all the necessary requirements for any type of system development (e.g. software, hardware, commodities, services, organizational, etc.). The VOLERE methodology [3, 15] is used in INTER-IoT mainly because it helps project partners to describe, formalize and track the project market analysis, requirements, use cases and scenarios in an explicit and unambiguous manner, and has widely proven to be effective and reliable for this type of tasks. It is also quite clear and simple to apply. VOLERE can be applied in almost all kinds of development environments, with any other development methods or with most requirements tools and modelling tech- niques. To produce accurate and unambiguous requirements, the VOLERE method- ology uses techniques that are based on experience from worldwide business analysis projects, and are continually improved [16]. 1 http://www.volere.co.uk/.
- 44. INTER-IoT Requirements 29 The VOLERE methodology provides several templates to deal with the different techniques and activities that it includes. In a quick view, the VOLERE Requirement Process2 that this methodology suggests can be summarised as follows: 1. Define the Purpose of the Project 2. Stakeholders Identification and Analysis 3. Business Use Cases 4. Scenarios 5. Writing the Requirements (functional requirements and non-functional require- ments) 6. Validation of requirements (completeness, relevance, testability, coherency, trace- ability, and several other qualities before they allow it to be passed to the devel- opers) 7. Communicating the Requirements 8. Requirements Completeness. The consequent application of the VOLERE methodology is not only useful in the initial phases of the project but it is also helpful in specifying a reference point for the later stages. During the implementation and management, it can be used to track and evaluate the progress of the individual work packages and the overall project. Besides being efficient and easy to use, the VOLERE methodology provides a mechanism for all partners to specify requirements, needs, use cases and scenarios in a standard format. Thereby, specifying additional context of an element such as the rationale and the acceptance criteria helps to build a common understanding of the overall system [16]. Furthermore, defining priorities helps to clarify the focus of the project [17]. 1.2 Repository The implementation of this methodology in the INTER-IoT project has been done using a commercial software called Jira.3 Jira is an online tracking tool to manage the whole project progress, where all the information compiled and produced is accessible through to the different partners. Following the Volere recommendations, all the requirements, scenarios, stakeholders, and products were registered. This repository help to search, access, review, and register new elements (stake- holders, requirements, etc.) identified after completion of the initial stage as the project progresses. 2 Volere Getting Started http://www.volere.co.uk/pdf%20files/VolereGettingStarted.pdf. 3 https://es.atlassian.com/software/jira.
- 45. 30 P. Giménez et al. 2 Stakeholders Analysis 2.1 Definition Stakeholders’ analysis [18] was the first task in the project and it is part of a rigorous and complete requirements specification [16]. It describes the process of targeting the people who have an interest in the new products and results that are planned for the project. The stakeholders’ group being involved in this task has also included anyone who may have any influence on the project’s outcomes, may be affected by the product or may have any knowledge needed to uncover the requirements of these products. The identification and involvement of relevant stakeholders is very important to be able to capture the requirements for the interoperability of heterogeneous IoT platforms [19]. The stakeholders’ analysis was carried out through interviews with stakeholders, following an INTER-IoT product oriented approach. With this analysis, we have identified the initial needs for the five components of the project: INTER-LAYER, INTER-FW, INTER-METH, INTER-LogP and INTER-Health. The identification of stakeholders also helped us to start developing cooperation with them, to focus on the requirements gathering process and, ultimately, to ensure a successful outcome for the project. The analysis took into account both demand and supply points of view and both qualitative and quantitative aspects [20]. Although there could be other kind of stakeholders, the following list of potential classes of stakeholders was initially defined for the identification process carried out by all the partners in the consortium: 1. Client/sponsor 10. Representatives of external associations 2. Customer 11. Business analysts 3. Subject-matter experts 12. Designers and developers 4. Members of the public 13. Testers 5. Users of the current system 14. Systems engineers 6. Marketing experts 15. Software engineers 7. Legal experts 16. Technology experts 8. Domain experts 17. System designers 9. Usability experts As far as the European Commission (EC) is the sponsor of INTER-IoT, as it is the funding entity of the project, it represents one of the most relevant stakeholders and we established the optimal value for it. Although the EC influenced on the outcomes of the project, it is not the customer of the project’s products and results. To easily identify the stakeholders of each product, we have used a stakeholder’s map as it has been described in the publication of “Mastering the Requirements Pro- cess: Getting Requirements Right” used as a reference for the VOLERE methodol- ogy. The stakeholder’s map shows the organizational rings surrounding the product and the classes of stakeholders who inhabit on these rings. The stakeholder map
- 46. INTER-IoT Requirements 31 Fig. 1 Stakeholders’ map template determines which classes of stakeholders are relevant to the project and which roles are needed to represent them. Each product being considered in INTER-IoT has a stakeholders’ map represen- tation in this document. The picture below shows the stakeholders map template. At the centre of the stakeholder map is the intended product (i.e. INTER- LAYER, INTER-FW, INTER-METH, INTER-LogP, INTER-Health). Surrounding the intended product is a ring representing the operational work area—stakeholders who have some direct contact with the product. In the next ring, the containing business include the stakeholders who benefit from the product in some way, even though they are not in the operational area. Finally, the outer ring, the wider envi- ronment, contains other stakeholders who have an influence on or an interest in the product. Note also the detailed and multiple involvement of the core team members is emphasized by the fact they span all the rings (Fig.1). Each stakeholder identified for each product has been characterised through the template (shown in Fig. 2) designed for the project. This template has helped to easily identify,classifyandmanagepotentialstakeholders.Theprocessofcharacterisingthe stakeholders has helped to start developing cooperation between these stakeholders and the project team. The stakeholder’s template has also helped to identify other stakeholders who may also be involved in the product design and implementation. The file has also helped to identify existing products and systems being used, produced or provided by the stakeholders related with the INTER-IoT products as well as new products
- 47. 32 P. Giménez et al. Fig. 2 Stakeholder template or systems which might be required before or during the adoption of INTER-IoT solutions. Many of the products identified during the stakeholder analysis have been considered in the market analysis.
- 48. INTER-IoT Requirements 33 2.2 Analysis The stakeholders’ analysis has been carried out through an INTER-IoT product- oriented approach [18], as stakeholders have been identified separately with regard to each product (INTER-LAYER, INTER-FW, INTER-METH, INTER-LogP and INTER-Health). The addressed stakeholders are interested from one product to all. From the data gathered in the stakeholder form, we carried out an analysis by product. Therefore, for each of the five products we analysed the following topics: • Stakeholders by company type (research institutions, public authorities, non-profit organizations, private companies, etc.) • Stakeholders by country • Stakeholders map • Stakeholders by class (client, system, engineers, software engineers, IoT operators, etc.) • Stakeholders by IoT Demand/Supply • Stakeholders with interest in Open Call participation • Products identified by Stakeholders • Stakeholders needs. During the first phase of the project, the partners identified and interviewed 93 stakeholders. For each of them one or more stakeholders forms depending on their interest in the different INTER-IoT products. One of the most interesting conclusions is the type of stakeholders with interest in the project. In Fig.3 can be seen that a quarter of the stakeholders were potential clientsorcustomersoftheINTER-IoTproducts.Afterthatarethetechnologyexperts, sub-matter experts, system and software engineers which will use the INTER-IoT products developing new features and updating the last versions. For each product, we completed a stakeholder map, like the one in the Fig.4 for INTER-LAYER. Stakeholders are classified by how involved they are in the design, development and execution of the product. There are four main areas in this map, corresponding to the degree of influence that each stakeholder could have: • Analysis team: Is the core team in the design and development of INTER-LAYER. It is comprised by all project partners that lead the project and are directly involved with INTER-LAYER (e.g. UPVLC, PRO, XLAB, VPF, etc.). • Operational work area: Every stakeholder that has direct a contact with INTER- LAYER (e.g. SigFox, ValenciaPort PCS), has enough knowledge in the product (e.g. AFT) or has a main role in the development and execution of INTER-LAYER (e.g. NOATUM, ASL TO5) fall under this ring. • Business area: Stakeholders that are affected in some way by INTER-LAYER (but not enough to have a main role) are located in this ring. Some stakeholders are interested in contributing to INTER-LAYER (e.g. Infoport, ETRA) or testing and adopting INTER-LAYER (e.g. Valencia Port Authority). Their business mod- els may influence the business models developed within INTER-IoT regarding INTER-LAYER.
- 49. 34 P. Giménez et al. Fig. 3 Total stakeholders by class Fig. 4 INTER-LAYER stakeholder’s map
- 50. INTER-IoT Requirements 35 • Influence area: In the outer ring, stakeholders that have an influence or some interest with INTER-LAYER are located. Other IoT related projects (e.g. BIG- IoT, Vicinity), IoT alliances (e.g. AIOTI, AllSeen), I+D companies (e.g. ETRA I+D), etc. Standardization organizations also play an important role in this ring, as the developed INTER-LAYER product should follow or be in line with the recommendations and working groups implied in these bodies [21]. The whole list of stakeholders and a complete analysis can be found in the INTER- IoT deliverable D2.1 INTER-IoT Stakeholders and market analysis report [22]. 3 Market Analysis 3.1 Definition The aim of the market analysis [23] is to provide an insight of the current IoT market landscape and the vision of different technologies supporting it [24]. The market analysis process is a must to do task in order to identify products that are being introduced or are already in the market which are related with the project in one of the following ways [23]: • as a component or module of the solution • as a complementary product • as a beneficiary, client or consumer of the solution • as a concurrent product The products identified during the stakeholders analysis need to be taken into accounttoidentifycharacteristics,capabilities,objectivesandneedsoftheseproducts under the point of view of interoperability of heterogeneous IoT platforms. The market analysis has been done in combination with the stakeholders analysis, this has allowed us to identify the readiness and willingness of different stakeholders to participate in interoperable IoT scenarios, different systems and products that could be involved and systems and products that would be required to participate in those scenarios [23]. This process has been quite relevant, as we have identified that many existing products are not yet ready to participate in an interoperable IoT environment and they need to be transformed and complemented with other components like IoT gateways and platforms to meet the interoperability requirements. This represents a new market niche, as there do not exist yet a wide adoption of IoT aware solutions and interoperable IoT products. The market analysis also helps to identify relevant standards and protocols that products are supporting and that INTER-IoT products would need to assess. The Fig.5 shows the product’s template, which includes the name of the product; the product class; the acquisition or licence options; references or web addresses to access further information; a brief description and the services provided by the
- 51. 36 P. Giménez et al. Fig. 5 Product template product. The file also records the partner who has identified the product and the reason why it is registered, including its relation with any of the INTER-IoT products.
- 52. INTER-IoT Requirements 37 Fig. 6 Products by class 3.2 Analysis The market analysis was performed mainly through desk research, workshops, mar- ket studies, report analysis and consultation with IoT market experts, including our participation in IoT-EPI and AIOTI forums. The market analysis comprised exist- ing solutions and trends, including vendor specific solutions, research projects and existing and proposed standards. We analysed more than 110 representative prod- ucts, although we were aware than a high spread of products exist. We classified the products in 16 different domains, which can be seen in Fig.6. ThemostprominenteffectofFig.6isthefactitshowsahighlevelofheterogeneity, with many product classes accounting for very low portions of the overall product class spread (e.g. hardware, standards, simulators, IoT platforms etc.). There is no general rule that can emerge from this view though other than the fact that IoT educated stakeholders’ awareness of existing products is quite scattered. However, another interesting fact emerges, showing that the quantity of known products can be closely tied to domain specific classes. The figure above indeed shows that 20% of products identified are linked to either the medical sector (15% to eHealth, 5% to medical devices) or to port systems (10%). This observation enables
- 53. 38 P. Giménez et al. Fig. 7 Products by access policy us to assume there is a high level of domain application specialization of the products being identified. Other conclusion extracted from the analysis is product access policy. It allows to a certain degree to acquire a clearer idea of the economic and administrative constraints to overcome in order to be able to use the products. The access mode also provides a certain indication as to the structural interoperability the products bear. Figure7 confirms the need for INTER-IoT solutions as over half of the identified products are used in a closed environment mode, thus hindering the economic effi- ciency and competitive advantages that could be gained by fostering interoperability. Luckily, among those products that can theoretically be accessed more openly, few require to overcome additional hurdles such as subscription or licensing. The whole list of products and a complete analysis can be found in the INTER-IoT deliverable D2.1 INTER-IoT Stakeholders and market analysis report [22]. 4 Requirements Analysis 4.1 Definition The set of requirements define how should work the different products from the needs of end users, suppliers and developers. A rigorous assessment of requirements before design allows a clear idea of what you want to implement and reduces delays due to design flaws. It also allows estimating more accurately the costs and the risks [3].
- 54. INTER-IoT Requirements 39 The requirements are the basis for the design stage, so a well-defined requirement reduces the development effort [16]. During the specification of the requirements, we should involve almost all the departments of the organization in order to define the necessary requirements for a specific product or service [25]. A complete and correct requirement process reduces the effort wasted on redesign, recoding and retesting. It also provides an efficient mechanism for the product validation and verification [3]. The characteristics that the requirements should have following ISO 2011 are: necessary,appropriate,unambiguous,complete,singular,feasible,verifiable,correct, consistent and comprehensible. There are several requirements categorizations, but the Volere methodology categorises requirements into three main groups4 : • Functional requirements are the fundamental subject matter of the system and are measured by concrete means like; data values, decision-making logic and algorithms. • Non-functional requirements are the behavioural properties that the specified func- tions must have, such as performance, usability, etc. Non-functional requirements can be assigned to a specific measurement. The methodology also includes a rich catalogue of non-functional requirements to be taken into account, which will be reviewed afterwards. • Project constraints identify how the eventual product must fit into the world. For example, the product might have to interface with or use some existing hardware, software or business practice, or it might have to fit within a defined budget or be ready by a defined date. In the project, we followed 5-step iterative process for identifying, capturing, defining, analysing, and reconciling requirements (see Fig.8). As it is an iterative process, during the whole project the requirements were reviewed and redefined to be more focused on the real development of the different components [26]. 4.1.1 Identify Sources of Requirements The partners identified the sources of information to collect requirements such as previous research projects, partners’ knowledge, stakeholders, regulation, standards, etc. 4.1.2 Requirement Capturing This step generated an inventory of identified requirements by INTER-IoT product, including requirement name and brief description. 4 Volere Requirements Specification Template https://www.st.cs.uni-saarland.de/edu/se/2009/ slides/volere_specification_template_v6.pdf.
- 55. Another Random Scribd Document with Unrelated Content
- 56. Causation. Hæmorrhage is apt to be not only more free, but also more serious, in young children and in patients over 60. The tendency is increased with menstruation or pregnancy, and hæmophilia is to be particularly looked for. In the nose the vascular turbinals bleed freely; a small varicose vessel on the septum is the commonest source of epistaxis, —often very copious. Many vascular growths are met with, and malignant ones are apt to bleed profusely. Secondary hæmorrhage may occur between the third and eighth day, when clots or crusts become detached. The prevention of local hæmorrhage. The patient should be prepared more carefully than usual for an operation. Hæmophilia should be inquired after, and if there is any suspicion of it lactate of calcium is administered for three days beforehand, in doses of 15 to 30 grains twice a day. If the patient be an undoubted hæmophilic, an operation should be avoided if possible. It is well to suspend the use of alcohol and tobacco for at least three days beforehand. Many risks are avoided if the operation can be carried out in the home or hospital where the patient has slept, and if he can remain there afterwards. The arrest of local hæmorrhage. The preliminary use of adrenalin will diminish bleeding in many cases (see p. 573). When it does occur, unless the hæmorrhage is serious, it is well not to be too precipitate in efforts to arrest it. Such attempts, by stimulating the patient, detaching blood-clots, or exciting reflexes, may even maintain it. The clothing should be loose, the operating-room should be well aired and cool, and iced water should always be at hand. If freely sluiced over the face, behind the ears, and round the neck, cold water has such a remarkable reflex vaso-constrictor action that it alone is sufficient to arrest hæmorrhage in the majority of operations on the nose and throat. Its stimulating effect on the respiration and circulation is always agreeable to the patient, and may be very valuable when he is under a general anæsthetic. If operated upon under a local anæsthetic, the patient’s head should be inclined forwards, so that the blood can drip from the nose. The first formed clots may be expelled, but then he should avoid sniffing, sneezing, or coughing, and sit with the head forward and the nostrils completely closed with his thumb and forefinger. Five to ten minutes in this position will arrest the bleeding in most cases of epistaxis. A slight
- 57. oozing of blood may be allowed to go on for a few hours in certain cases. If the bleeding persists, ice should be applied externally and held in the mouth, the nose may be syringed with very cold or with very warm salt and water (ʒi to the pint), and the horizontal position assumed. If this fails, a pledget of cotton-wool is dipped in peroxide of hydrogen solution (10 vols. %) and introduced into the bleeding nostril, the orifice of which is then closed by the surgeon’s thumb. This may be repeated more than once, the patient lying on his side, face downwards, and pinching both nostrils. If a galvano-cautery be available, and the bleeding comes from a limited and visible point, it can be sealed with a touch of the cautery point. If these methods fail, plugging must be resorted to. With the nasal speculum and good illumination, the bleeding area is cleansed with cocaine and adrenalin and a strip of 1-inch ribbon gauze is carefully packed on to the spot, the end being left just within the vestibule, so that the patient can remove it for himself at the end of 12 or 24 hours. It is better to use a single strip of gauze, instead of cotton-wool, as portions of the latter might be detached and left behind. If there be fear of the gauze strip becoming adherent, it can be well smeared with plain sterilized vaseline. If the bleeding comes from far back in the nose, or from the post-nasal space, it may become necessary to plug the latter cavity. A sterilized sponge, about the size of a Tangerine orange, is squeezed very dry and tied round its centre with a piece of tape or a stout silk ligature, leaving two free ends of about 12 inches in length. A soft rubber catheter is passed along the floor of the nose till it appears below the soft palate, when the end is seized with forceps and drawn through the mouth. To this end one of the tapes is made fast, so that when the catheter is withdrawn from the nose, the sponge is pulled up into the post-nasal space; the other end hangs out of the mouth. The two tapes are tied together over the upper lip. The anterior part of the nostril can then be packed with gauze, if necessary. If the patient be under chloroform, one tape can be dispensed with; the soft palate is simply held forward with the forefinger of one hand, while the other passes the compressed sponge up into the naso-pharyngeal space.
- 58. Plugs in the nose should be avoided. They are painful, interfere with repair, prevent drainage, and may be followed by septic troubles in the nose, accessory sinuses, middle ear, or cranial cavity. Bleeding often recurs on their removal. In any case they should not be left unchanged for more than 24 or, at the most, 48 hours. Removal is facilitated by soaking them well with peroxide of hydrogen, and detaching them slowly and gently. Ligature of the external carotid (see Vol. I, p. 384) may be necessary in extreme cases.48 THE PROTECTION OF THE LOWER AIR-PASSAGES FROM THE DESCENT OF BLOOD When operated upon under local anæsthesia the patient is able to prevent blood descending from the nose or throat into the larynx or trachea. In this he is assisted by throwing the head forwards. When the patient is under a general anæsthetic other measures must be taken to guard against the descent of blood into the windpipe and lungs. The most important is to see that the anæsthesia is never so deep as to abolish the swallowing or coughing reflexes. Fortunately these are amongst the last to go, yet in many cases it is well to let the patient come partly round, so as to expel blood and mucus by coughing. If the frontal sinus is being operated upon, the nose is carefully packed beforehand. When the ethmoidal labyrinth is being cleared, or the sphenoidal sinus opened, a sponge may be placed in the post-nasal space as described above until the operation is completed. During the operation upon the maxillary sinus through the canine fossa, a sponge placed between the last molar teeth and the cheek on the same side, and frequently renewed, will keep any blood from entering the pharynx. In operations upon the naso-pharynx, it is a wise precaution, when much bleeding is anticipated, to perform a preliminary temporary laryngotomy and plug the pharynx with a sponge (see p. 510). In many proceedings security is attained by rolling the patient well over to one side, so that the blood runs out of the corner of the mouth, of blood is also swallowed. This may be vomited as consciousness returns; if not, an aperient should be given within 24 hours to prevent gastro- intestinal sepsis. The descent of blood into the trachea and lungs, if sudden and copious, may cause immediate asphyxia; or, if less abundant, it may cause septic
- 59. pneumonia. When it occurs, the anæsthesia should be stopped, and the patient rolled well over on to his face or inverted, until the breathing is quite unobstructed. After all nose and throat operations it is a wise precaution for the patient to be kept on his side, the head on a low pillow, and face downwards, while the body is arranged in the gynæcological position. SHOCK Shock, particularly in operations on the nose, is apt to be marked in young children and in elderly persons. It is for this reason that we try to avoid the removal of adenoids in patients under 3 years of age, or of polypi in those over 60; and that in all cases we endeavour to operate as rapidly as possible. This possibility of shock is guarded against and treated in the usual way. The use of cocaine and adrenalin—even in patients under a general anæsthetic—helps to avoid it,49 and anæsthesia should never be too deep or prolonged. When operating under local anæsthesia it is sometimes wiser not to attempt too much at one sitting, e.g. to treat only one side of the nose at a time. In certain conditions, and when a general anæsthetic is employed, it may be safer to try and complete treatment at one operation. SEPSIS AND OTHER COMPLICATIONS Deaths have been recorded after the simple use of the galvano-cautery, or the removal of nasal polypi, and of course are more to be feared after major operations, such as the radical cure of sinus suppurations. Septic infection from nasal operations may spread to the accessory sinuses, meninges, ear, eye, tonsils, glands, gastro-intestinal tract, bronchi, and lungs. From the naso-pharynx, the ears and the lower food and air tracts are chiefly threatened. The orbit may be invaded in operations on the ethmoid; the external muscles of the eye may be injured in the frontal sinus operation; and optic atrophy may be due to plugging of the ophthalmic vein. While these accidents may sometimes be directly due to operation, it is well to remember that in treating such septic conditions as are entailed by nasal suppuration, the complications may only be precipitated by
- 60. traumatism and may also be purely coincident. It is not to be forgotten that latent infection—of influenza, erysipelas, measles, scarlatina, diphtheria, or other disease—may develop immediately after an operation upon the nose or throat, and until its true character is recognized the operation is often unjustly blamed. Septic infection, in these necessarily exposed wounds of the air-passages, may be traced to insanitary surroundings. ASEPSIS The field of operation in rhinology can never be rendered completely sterile, and in many cases is particularly septic. Wounds through the mucous membrane cannot be protected with dressings in the usual way; so that the local methods of repair require particular study. In the nose, when there is no suppuration, it is safer to make no attempt to purify the cavity, beyond cleansing the vibrissæ and vestibules. The Schneiderian membrane will not tolerate any antiseptic lotion of such a strength as to be effective, and weaker solutions only interfere with the action of the cilia, the protective power of the mucus, and other defensive arrangements of the nose. If pus, scabs, or foreign bodies exist in the nose, it should be well washed with a simple tepid alkaline solution. But every care should be taken to purify the surgeon’s hands, sterilize all instruments, and see that no contamination takes place during the operation. This is assisted by having the patient’s head surrounded by a carbolized towel, and his face, moustache, and beard well washed, for the surgeon’s hands and instruments come in frequent contact with these parts. AFTER-TREATMENT After all intranasal operations everything should be avoided which interferes with the drainage, ventilation, and natural repair of the region. Protective dressings cannot be employed, and we have in most cases to aim at healing under a blood-clot. Tags of semi-detached tissue and loose clots of blood are removed, but otherwise the parts are disturbed as little as possible. For the first two or three days the nose may be left alone, and if there be no bleeding the patient is encouraged to breathe through it. When there is much formation of thick mucus, or blood-clots or
- 61. sloughs are loosening, a tepid alkaline lotion can be used. The pain of stiffness or dryness in the nose is relieved by an ointment or an oily spray. Adhesions are apt to form between the septum and the outer wall when opposing surfaces are injured by the galvano-cautery. They may occur in narrow cavities after cutting operations. If an adhesion be seen to be threatening in the first few days, it should be broken down with a probe, and strips of gauze or plates of white celluloid introduced daily until healing takes place. If it forms later, it is wiser to wait until the fleshy bridge becomes less vascular and contracts, when it may be divided with a knife or the galvano-cautery at a white heat, and the opposing surfaces are then kept apart as described. All post-operative conditions in the nose and throat will heal more rapidly and pleasantly if the patient be freely exposed, day and night, to abundance of fresh air; and while fatigue is generally to be avoided, the sooner the patient is out of bed and in the fresh air, the better for him. Our inability to operate under aseptic conditions should make us more careful to raise the resistance of the individual by general care, and to protect him from external dangers. CLEANSING THE NOSE The simplest and safest method of cleansing the nose is by blowing it,— one nostril at a time. Sometimes it is required to hawk any discharge backwards and expel it through the mouth. Watery lotions are frequently required to assist in cleansing the nose. Strong antiseptics and astringents must be avoided. All nose lotions should be alkaline, and isotonic with the blood plasma. These requirements are met by prescribing one or more alkalis (bicarbonate of soda, borax, salt, &c.), in the strength of about 5 grains to the ounce. They may be rendered more pleasant by the addition of white sugar or glycerine. The addition of a small amount of some mild antiseptic— menthol, thymol, oil of eucalyptus, carbolic, sanitas, listerine, &c.—may give a pleasant flavour. But all antiseptics have a slight irritant action which is disagreeable if there be an intact mucosa, although they may be more helpful in certain cases of ulceration or intranasal sepsis. When the Schneiderian membrane is more or less damaged, when there are foreign
- 62. bodies, sloughs, necrosis, &c., in the nasal chambers, these or similar antiseptics can be employed, though always with an alkaline basis. All nose lotions should be employed tepid. They may be sniffed, irrigated, sprayed, or syringed into the nostrils. Crusts, scabs, and sloughs may have to be removed from the nose with forceps, after its sensitiveness has been deadened with cocaine; peroxide of hydrogen will help to detach them. AFTER-RESULTS Incomplete operation may be unsatisfactory in many ways. Thus, nasal obstruction may be unrelieved: foci of suppuration may be left in the accessory sinuses: portions of adenoid growth or tonsils left behind may continue to give trouble: malignant growths may not be extirpated freely enough. On the other hand, operations may fail to relieve, or even produce a worse state of affairs, if too much tissue be sacrificed. This is important as regards the nose, owing to the important respiratory and defensive function of its mucous membrane. It is a good rule to injure the inferior turbinal as little as possible, otherwise a condition of crusting rhinitis may be set up, with secondary atrophy in the pharynx and larynx.50 Much judgment is required in adapting the suitable operation to each case. While in some instances one or more small interventions are all that is required, in another a well-planned and more extensive operation may be indicated. In any case, the advice of Semon should be kept in mind, viz. that the magnitude of an operation should not exceed the gravity of the symptoms calling for relief. CHAPTER II OPERATIONS FOR INJURIES, DEFORMITIES, FOREIGN BODIES, AND RHINOLITHS: OPERATIONS UPON THE
- 63. Fig. 284. Meyer’s hollow Vulcanite Nasal Splint. TURBINALS: OPERATIONS IN SYPHILIS AND LUPUS OPERATIONS FOR INJURIES TO THE NOSE The external injuries of the nose belong to general surgery. It might be well to recollect that the fleshy end of the nose may be completely detached, and yet, if carefully and promptly replaced, perfect union will occur.51 FRACTURES OF THE NASAL BONES AND SEPTUM Setting a recent fracture. One or both nasal bones may be displaced, causing a flat bridge with a sharp ridge on either side. In the septum fracture generally takes place in the quadrilateral cartilage, or displacement occurs at its junction with the vomer or superior maxilla. It may be accompanied by a hæmatoma (see p. 612), and the occurrence of epistaxis shows that it is really a compound fracture. Care should therefore be taken not to infect the wound in the nose, and the patient should be warned on the subject. The application of cocaine and adrenalin may allow of careful inspection of the septum. But, as the exact condition of things is marked by swelling, it is nearly always advisable to administer a general anæsthetic. Crepitus can rarely be made out. A hæmatoma is dealt with as directed (see p. 612). If there be any displacement of the septum— and it generally takes place towards the side on which there is already some convexity or depression of the nasal bones—the parts should be raised into place by manipulation with the little finger in the nostril. A flat- bladed forceps, like those of Adams, may be used. One blade in each nostril will straighten the septum and, at the same time, raise the whole nose into place. Small pencils of sterilized cotton-wool, smeared with vaseline (see p. 608), are then carefully packed up into the roof of the nose and kept there by Meyer’s vulcanite tube (Fig. 284). They are changed every 24 or 48 hours, for a week or so. The vomer is rarely
- 64. fractured, although much callus is often thrown out in the displacements which occur between it and the cartilage. Recent cases require no splints. In fact, if the displacement be promptly reduced—under general anæsthesia—the restored parts will generally maintain their position. Elevating an old fracture. In neglected cases it may be necessary to re-fracture the nasal bones, and when these are replaced an external splint may be necessary. This can be made of plaster of Paris; or the outside of the nose may be covered with a piece of heavy adhesive plaster, and outside that a shield of tin, copper, or, preferably, aluminium.52 Fracture of the ethmoid is, fortunately, rare. When it occurs it is apt to run into the cribriform plate, and be associated with the escape of cerebro-spinal fluid and other indications of fracture of the anterior fossa of the skull. OPERATIONS FOR CONGENITAL OCCLUSION OF THE NOSTRILS Operation for congenital occlusion of the anterior nares. If the web obstructing the nostril be thin and membranous, and of low vitality, a simple and effective method is to destroy it with the galvano-cautery. It is best to spread the treatment over several sittings, so as to diminish the local reaction. The application of cocaine may not be sufficient to numb the pain, as the tissue of the obstructing web is more allied to skin than to mucous membrane. It should therefore be punctured quickly in two or three places, with a sharp cautery point raised nearly to a white heat. If the patient be nervous it may be well to administer nitrous oxide gas. After the operation the nasal orifice is kept distended until healing has taken place by wearing Meyer’s vulcanite tube in it or short lengths of full- sized rubber drainage tube, well smeared with boric, aristol, zinc, or similar ointment. These simple nasal dilators are changed once or twice daily, and the nostril is well cleansed on each occasion. If the web obstructing the anterior naris be more fleshy in character (and it is more apt to be of this nature when it is incomplete), it may be necessary to remove it with a knife. So as to leave as much epithelial
- 65. tissue as possible, and avoid retraction, the operation is done as follows, under local or general anæsthesia: A narrow, sharp-pointed instrument, such as a Graefe’s or other ophthalmic knife, is used to puncture the web from before backwards, and it is then made to sweep round the obstructing diaphragm, while gradually cutting its way towards the central lumen. The tongue of skin thus formed can be used as a graft to cover most of the raw surface. The restored anterior naris is kept patent, as already described, till healing takes place. In some cases the following operation has been shown to be easy and effective: An incision is made at the junction of the web with the septum, keeping close to the latter and passing straight down to the floor of the nose. On the outer side a similar incision is made, but sloping somewhat outwards. The flap formed between these two incisions is not cut off, but is bent backwards and fastened to the floor of the nose by a single horsehair stitch.53 Fig. 285. Krause’s Trochar and Canula. For puncturing the maxillary antrum from the nose. Fig. 286. Nasal Punch-forceps.
- 66. Operation for congenital occlusion of the posterior choanæ. If the obstruction be not freely and completely removed it tends to re-form. A general anæsthetic is required. Unless the operator is ambidextrous he will find it most convenient to stand on the patient’s left hand, and to introduce his own left forefinger into the post-nasal space. This enables him to guide any straight, sharp instrument, such as an antrum drill (Fig. 323), Krause’s trochar (Fig. 285), or a surgical bradawl, from the front of the nose until it presses against and breaks through the obstructing diaphragm in two or more points. If preferred, an electric trephine can be used, and often pressure with the tip of a pair of nasal punch-forceps will be sufficient. The latter, either straight or tip-tilted (Fig. 286), are then inserted through the nostril, and, still guided by the left forefinger in the post-nasal space, are employed to clip away all the obstruction. To prevent any possibility of this reforming it is recommended by some surgeons that a small piece should be nipped out of the posterior margin of the bony septum. This can be done with the beaked punch-forceps of Grünwald (Fig. 286), passed through the nose, or with a pair of Loewenberg’s post-nasal forceps (Fig. 287) introduced through the mouth. In either case their action is controlled and directed by the operator’s left forefinger in the post-nasal space. Fig. 287. Post-nasal Forceps. No special after-treatment is required. The patient should be ordered a tepid alkaline nose lotion, and should be encouraged to make use of the nasal air-way and acquire the habit of blowing the nose. REMOVAL OF FOREIGN BODIES FROM THE NOSE It might be helpful to remember that foreign bodies not only enter the nasal cavities (1) through the anterior nares, but also (2) through the posterior choanæ, or (3) by penetration through the walls. They may also arise (4) in situ, as in the case of sequestra and rhinoliths. The last group will be considered separately.
- 67. A foreign body, if small, may form the centre of a rhinolith. Operation. Great care and gentleness are required in the removal of foreign bodies from the nose. The extraction should never be attempted blindly, or forcibly, or hurriedly. A little delay to make necessary arrangements does no harm. If a child will not submit to examination it is much better to employ a general anæsthetic so as to complete examination and, if found necessary, extraction at the one sitting. If the nose be not well illuminated and opened with a nasal speculum, groping about in the dark will only do further damage and result in disappointment. Fig. 288. Nasal Dressing Forceps. In adults removal can generally be carried on under cocaine. The nostril is cleaned with cotton-wool, and if the extremity of the probe used for detecting the presence of a foreign body be curved to a right angle, it will also serve for gently levering or displacing it forwards. With a small pair of nasal dressing forceps (Fig. 288) it can generally be firmly seized and gently extracted, care being taken not to include any of the mucosa nor to drag the foreign body out regardless of the sinuosities of the cavity. Lister’s ear hook is a most useful instrument. Sometimes a nasal snare will help to extract the substance or to tilt or drag it into a better position. Unless coated with solid accretions there is never any need to break up a foreign body; anything small enough to slip into the nose is small enough to be extracted entire. If it should be found impossible to remove the body through the anterior nares, it may be pushed backwards into the post-nasal space, where the forefinger of the left hand is in readiness to prevent its falling into the gullet or larynx.
- 68. The usual warm alkaline lotion may be used to clear the nose, but liquid should never be forcibly injected into the nostril with the idea of thus expelling the foreign body. If the lotion be sent up the nasal chamber on the same side it will only drive the intruding substance further in; if injected on the opposite side there is risk of otitis media. In the case of small children it is sometimes recommended that a piece of muslin should be placed over the mouth, and that the practitioner should then apply his lips to those of the patient and by blowing forcibly through the mouth drive out the foreign body by the blast of air from the post- nasal space. Or the same principle may be applied by insufflating the air from a Politzer’s bag through the opposite nostril. Both plans are alarming and seldom effective. The after-treatment consists of some simple cleansing lotion and soothing ointment. REMOVAL OF RHINOLITHS (NASAL CALCULI, OR CONCRETIONS IN THE NOSE) These concretions are almost unknown in children, in whom foreign bodies are met with most frequently. A general anæsthetic is, therefore, not so often required, otherwise the remarks on the removal of foreign bodies will be found to apply to the extraction of calculi. With the help of cocaine and good illumination they can easily be removed with a strabismus hook, Lister’s ear hook, or a pair of fine probe-pointed nasal forceps with serrated extremities. In some cases where the calculus has sent prolongations into the recesses of the meatus, it might first be necessary to crush it. In that event a general anæsthetic may be required. The after-treatment consists in simple cleansing measures. Subsequent syringing of the nose should be done from the opposite side. OPERATIONS UPON THE TURBINALS Indications. In many cases of hypertrophic rhinitis it is necessary to remove portions of redundant turbinal tissue. It is never desirable—and it can only rarely be necessary—to remove the whole of the inferior turbinal. ‘Turbinotomy,’ or amputation of the whole inferior turbinal, was
- 69. recognized as an operation some years ago. But it was never generally accepted, as it was always realized that the highly important physiological functions of the lower spongy bone could not be spared. Improved technique, particularly in being able to correct deformities of the septum without the sacrifice of any mucous membrane (see p. 603), now enables us to rectify nasal stenosis with the sacrifice of much less turbinal tissue. The middle turbinal is not of so much importance in the physiology of the nose, and the whole of this body is not infrequently removed. This may be done not only because it is diseased, but even a healthy middle turbinal may require amputation in order to approach the accessory sinuses or diseases in the deeper regions of the nose. Part of the healthy inferior turbinal may also require removal—as in the radical operation on the maxillary sinus. As these operations will be referred to frequently later on, and as their performance enters into different groups of operation, they will be described first. OPERATIONS UPON THE INFERIOR TURBINAL Amputation of the anterior end. Indications. The amputation may be required: (i) On account of polypoid degeneration of the anterior extremity of the turbinal. (ii) To allow of access to the antro-nasal wall (see p. 633). (iii) To avoid operation on the septum by relieving nasal stenosis.
- 70. Fig. 289. First Step in removing the Anterior End of the Inferior Turbinal, which is seen to have undergone Polypoid Degeneration. Operation. The local application of cocaine and adrenalin (see p. 573) is sufficient. Anæsthesia. With the patient sitting upright in a chair, and the nostril well illuminated, a pair of nasal scissors (such as Heymann’s, Walsham’s, or Beckmann’s) are made to grasp as much of the anterior extremity as it is desired to remove, generally the anterior third (Fig. 289). The scissors are pressed very firmly against the outer nasal wall, so as to divide the base of the turbinal as close as possible to its attachment. If the scissors slip off the bone it should be divided with Grünwald’s punch-forceps. The semi-detached extremity is then surrounded with a nasal snare, carrying a No. 5 piano wire, and cut through (Fig. 291). It is well not to seize and twist off the anterior extremity, as this might lead to the ripping out of a larger portion than was intended. Besides, it might cause fracture of the base of the remaining piece of the inferior turbinal bone and this might become displaced inwards so as to block the air-way more than ever. After-treatment. It is well to check the hæmorrhage without the use of plugging. Some antiseptic powder—europhen, xeroform, formidine, aristol, &c.—if lightly insufflated over the wounded area, will assist in the formation of a protective scab. This should not be disturbed for some days, during which the nose is made comfortable by some menthol and boric ointment, or a paroleine spray. When the scab begins to break down
- 71. its removal is assisted by warm alkaline lotions (see p. 579). The stump may require a few applications of nitrate of silver or other silver salt. There is no danger in this operation. Healing, as in other intranasal operations, takes from three to six weeks. Amputation of the lower margin. Indications. This is not infrequently necessary when there is a general hypertrophy—as in the compensatory hypertrophy of septal scoliosis (Fig. 310)—or when the whole lower and outer margin is occupied by papillary hypertrophies (Fig. 289). Operation. The operation can be carried out under the local application of cocaine and adrenalin, but is frequently performed as part of some other operation under a general anæsthesia. Fig. 290. Nasal Scissors. The steps have to be varied according to the degree and extent of the hypertrophic tissue requiring removal. When this is principally along the lower border of the turbinal it can be removed with one cut of a stout pair of nasal scissors (Fig. 290). Under good illumination a blade is insinuated along the concavity, while the other passes between the convexity and the septum. Care should be taken that the direction of the scissors is parallel to the axis of the turbinal body, and that the cut embraces only that portion of the lower area to be removed. The severed portion should be quickly seized with a pair of punch-forceps and lifted out, or the patient, if only under local anæsthesia, may be requested to blow it forward into a tray. Otherwise it is apt to become obscured in the outpouring of blood, and, if the patient is unconscious, to be sucked backwards out of sight. If, as not infrequently happens, the lower margin remains attached at its posterior extremity, a wire snare is threaded along over it so as to cut this through. When the papillary hypertrophy is more diffuse it is apt to be concealed in the concavity of the turbinal. From this
- 72. hiding-place it can be partially dislodged with a probe and then cut off with a snare. The after-treatment is similar to that for removal of the anterior end. Removal of the posterior end. Indications. The posterior extremity of the inferior turbinal is very subject to a moriform hypertrophy, and some delicacy and skill are required in removing it. Operation. The interior of the nose on the affected side should be treated with a weak solution of cocaine and adrenalin. The most disagreeable part of the operation is the introduction of the operator’s finger into the post-nasal space. Hence the fauces should be freely sprayed with a 5% solution of cocaine. This will deaden painful sensation, but it will not prevent the discomfort nor the nausea often induced. It is well to avoid as much as possible the direct application of cocaine or adrenalin to the moriform hypertrophy itself, for it is an extremely vascular growth, and if much contracted it is more difficult to ensnare. The operation may also be carried out under a general anæsthetic, when one is given for other surgical measures in the nose. In that case it is best to defer the removal of the moriform hypertrophy until the end— practically until the patient is commencing to recover consciousness—on account of the sharp hæmorrhage which is apt to accompany it. The chief difficulty of the operation lies in the fact that the part to be operated on cannot be kept in view, either directly or indirectly, and that therefore success depends a good deal on delicacy of touch. A nasal snare—such as that of Blake, Krause, or Badgerow—is threaded with No. 5 piano wire, and a loop left out a little larger than sufficient to grasp the growth. This loop is then bent over smartly towards the side to be operated on, and a slight kink is given to it. The loop is then slightly withdrawn within the barrel, and this again brings it into a straight line. If now the snare be passed along the floor of the nose until the end of it is opposite the posterior extremity of the turbinal, and if the looped wire be slightly projected from the barrel, the loop will tend to curve outwards to the side on which it was kinked. In this way it will be felt to surround the moriform growth, which can then be cut off.
- 73. Fig. 291. Amputation of the Posterior End of the Inferior Turbinal. It must be confessed that this is not always successful, that there is no means of making sure that the snare is applied to the root of the growth, and that once the bleeding is started posterior rhinoscopy fails to reveal if any of it still remains. It is better therefore to introduce the purified forefinger of the left hand into the post-nasal space, so as to define the growth and guide the loop of the snare over it. The nail of the same finger then keeps the wire close to the base of the hypertrophy, while the loop is drawn home (Fig. 291). The patient may then be relieved of the discomfort of the operator’s finger in his throat, and may be given time to clear away the collected mucus. A little delay is advantageous, as it allows coagulation to take place in the large veins of the moriform growth. Some surgeons recommend that once the growth is strangled the snare should be left in situ for 10 or more minutes. This is irksome and unnecessary, and bleeding is seldom excessive if the snare be not employed for cutting off the hypertrophy, but is used as follows: Once the loop is drawn firmly home so as to embrace the growth tightly, a few minutes’ rest is given. Then, steadying the patient’s head with the now disengaged left hand, the snare is plucked from the nose with a quick movement. This brings away the mulberry hypertrophy in its grasp, and frequently a strip of mucosa from the lower margin of the turbinal. No bone is removed in this operation. The bleeding may be very sharp at first, but generally ceases under the usual measures (see p. 574). Occasionally it is extremely
- 74. Fig. 292. Nasal Spokeshave. troublesome, and as the bleeding surface overhangs the post-nasal space the only local pressure which is available is that of a post-nasal plug. After-treatment. As secondary hæmorrhage is apt to be met with the patient should be advised to leave his nose alone, neither blowing nor clearing it, nor using any cleansing measures for 48 hours. After that time he can employ the usual warm alkaline nose lotion. He should be warned against the habit of hawking backwards, as this would tend to a recurrence of the hypertrophy. Prognosis. Great relief can generally be promised within a few days. There is no danger in the operation. The hæmorrhage may be troublesome, especially in men. The precautions described in the previous chapter are well worth observing (see p. 574). Complete turbinotomy. Indications. As already remarked it must be extremely rare for this operation to be required. Papillary hypertrophy chiefly attacks the lower and posterior parts of the turbinal, and these can be removed as described above, so that if the entrance of the nostril is made free by anterior turbinectomy, there will still be left a sufficient area of functionally active mucosa. If, however, almost the entire inferior turbinal be degenerated, or if it be replaced by malignant growth, it can be removed in the following way. Operation. Anæsthesia may be local or general. If no other operative procedure be required at the same time, the anæsthesia of nitrous oxide gas or chloride of ethyl will be long enough. Owing to the vascularity of the part adrenalin should be applied for at least 30 minutes beforehand. Removal of the turbinal is easily and quickly carried out with Carmalt Jones’s or Moure’s spokeshave (Fig. 292). This is introduced, passed as far as the posterior extremity of the turbinal, and the edge is guided in place with the operator’s left forefinger in the post-nasal space. With a sharp pull the spokeshave is then drawn forwards and the detached body can be lifted out with a pair of punch-forceps. Owing to the slope of the attached border it is seldom that the whole of the turbinal is removed. Those who are skilled in the
- 75. use of this instrument can manipulate it so as to leave a good part of the attached margin of the turbinal, and the spokeshave can be used instead of the scissors for removal of the inferior margin. But its action is apt to be uncertain, and as it may unexpectedly rip out more than was intended, it is seldom employed nowadays. After-treatment. After the removal of such a large portion of secreting surface the nasal secretion may dry into adhering crusts and scabs for some weeks—possibly for six or even eight. The scabs should be softened by the use of ointment or oily sprays, and removed by the fere use of warm alkaline lotions. The even healing of the granulating surface requires watching; its progress should be inspected from time to time, as the surface may require touching with a weak nitrate of silver solution. OPERATIONS UPON THE MIDDLE TURBINAL Indications. Amputation of the anterior end may be required for (1) simple hypertrophy, (2) cyst or empyema in the anterior extremity, (3) to gain access to the ostia of the various accessory sinuses, (4) as a first step to uncover the ethmoidal cells, and (5) as a first step in removal of ethmoidal polypi. Operation. Local anæsthesia with cocaine and adrenalin is sufficient, and the operation can be carried out with the patient sitting in the examination chair. It frequently forms part of some other intranasal operation which is performed under a general anæsthetic, but the preliminary application of cocaine and adrenalin should still be carried out (see p. 572). If the pieces of gauze soaked in the cocaine-adrenalin mixture be carefully tucked up on each side of the head of the turbinal, the part to be removed is generally well exposed. With a pair of Grünwald’s punch-forceps (Fig. 286) or Panzer’s scissors (Fig. 290), the anterior attachment to the outer wall is cut through (Fig. 293) so as to free the end, around which a cold wire snare can be passed and the extremity removed (Fig. 294.) In cases where it is difficult to introduce the punch-forceps under the attachment of the middle turbinal the blades may be applied to the lower margin, about half an inch from the anterior extremity so as to bite out a wedge. Into this the loop of the wire snare is inserted and the head of the turbinal can easily be snared off.
- 76. Fig. 293. First Step in the Removal of the Anterior End of the Middle Turbinal. Fig. 294. Second Step in the Removal of the Anterior End of the Middle Turbinal. The snare is generally recommended as being safer than the punch- forceps. There is certainly a risk attending any slip in manipulating the latter in this region, more so, indeed, than in the deeper ethmoidal regions, for in the anterior part of the nasal roof the cerebral floor dips down lower than it does posteriorly, and the nasal fossa in the anterior part of the middle meatus is very narrow, so that if the forceps slipped they might impinge on the cribriform plate. But when the middle turbinal is softened and broken down by disease it is as safe, and it is certainly more convenient, to take out a wedge from its centre, as directed above, and then with a pair of Grünwald’s or Luc’s forceps to twist out not only the anterior extremity, but also the posterior half. The latter part can also be removed with a spokeshave, as directed for the inferior turbinal (see p. 591). After-treatment. There is not the same tendency to crusting as occurs after operation on the inferior turbinal. Hæmorrhage is also less troublesome. Plugging is therefore the less likely to be required, and should always be avoided if possible, since it would interfere with drainage from the various accessory sinuses, and this operation is frequently required when their contents are particularly septic. The best plan is to leave the nose severely alone for 48 hours, and then to clear it gradually with the help of warm alkaline lotions.
- 77. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com