This document contains information, which is proprietary to the OpenIoT Consortium. Neither this document nor the information contained herein shall be used, duplicated or communicated by any means to any
third party, in whole or in parts, except with prior written consent of the consortium
SEVENTH FRAMEWORK PROGRAMME Specific Targeted Research Project
TABLE OF CONTENTS DOCUMENT HISTORY .......................................................................................................................... 1
CHANGES & UPDATES FROM D3.3.1 ................................................................................................. 2
2 ADAPTATION OF EXISTING IOT PLATFORMS IN VITAL .......................................................... 102.1 Rationale .................................................................................................................................. 102.2 Mechanisms ............................................................................................................................. 102.3 Procedure ................................................................................................................................ 10
3 ADAPTATION OF M2M AND ONEM2M PLATFORMS ................................................................ 123.1 Overview of ETSI M2M and oneM2M ...................................................................................... 123.2 Mapping Guidelines ................................................................................................................. 15
4 ADAPTATION OF OGC PLATFORMS .......................................................................................... 164.1 Overview of OGC Standards ................................................................................................... 16
4.1.1 Sensor Model .................................................................................................................... 184.1.2 Observations & Measurements model .............................................................................. 184.1.3 SWE Service Model and sensors related service specifications ...................................... 19
FIGURE 11: HIGH LEVEL REPRESENTATION OF THE ICORE ARCHITECTURE. ................................................. 36
FIGURE 12: ICORE VIRTUAL OBJECT DATA MODEL .................................................................................... 37
FIGURE 13 – ARDUINO MEGA BOARD AND DHT11 SENSOR ........................................................................ 39
LIST OF TABLES TABLE 1: MAPPING BETWEEN ONEM2M AND VITAL ENTITIES. .................................................................... 15TABLE 2: MAPPING BETWEEN SOS OPERATIONS AND PPI PRIMITIVES. ........................................................ 23TABLE 3: MAPPING BETWEEN XIVELY AND VITAL ENTITIES. ....................................................................... 26TABLE 4: MAPPING BETWEEN CKAN AND VITAL ENTITIES. ........................................................................ 29TABLE 5: MAPPING BETWEEN CITYBIKES AND VITAL ENTITIES ................................................................... 30TABLE 6: MAPPING BETWEEN FIWARE AND VITAL ENTITIES. .................................................................... 34TABLE 7: MAPPING BETWEEN VITAL AND ICORE ENTITIES. ........................................................................ 38
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
The main objective of the VITAL project is to research the development and deployment of semantically interoperable IoT applications in smart cities, notably applications that combine data and services from multiple (legacy) IoT platforms and IoT systems, which are nowadays already deployed in modern smart cities. To this end, WP3 of the project has been already defining and implementing (a) an ontology (i.e. VITAL ontology), which serves as a common data model for the semantic unification and interoperability of diverse IoT services and data streams stemming from the various platforms and data sources, and (b) a set of virtualized (platform-agnostic) interfaces for accessing functionalities of the VITAL platform, including a set of PPIs (Platform Provider Interfaces) for accessing the capabilities of different IoT platforms in a unified platform-agnostic way. The validation of these developments has taken place on the basis of the adaptation of four diverse IoT platforms to the VITAL paradigm. These four platforms provide by no means an exhaustive coverage of the range of capabilities that are supported by the numerous IoT platforms that are nowadays available. Furthermore, the selected platforms do not support mainstream IoT standards (such as OGC and oneM2M). As a perquisite for the wider deployment and the sustainable use of the VITAL platform and paradigm, the above-listed components (i.e. PPI, VITAL ontology, and VITAL platform) should support integration with additional IoT architectures and platforms, including standards-based platforms, public IoT cloud platforms and more. The purpose of this deliverable is to illustrate a methodology for adapting and integrating IoT platforms to the VITAL semantically interoperability paradigm, notably platforms beyond the ones that have already been adapted to VITAL. The deliverable is the outcome of task T3.5 of the project work plan, which is devoted to research on how an IoT system built based on a legacy platform/architecture could be adapted to the VITAL approach. As part of this task, the project has produced a detailed list of steps, which are required for adapting and interconnecting legacy IoT platforms to VITAL. The deliverable includes a procedure for the migration and adaptation of legacy IoT systems and architectures to the VITAL virtualization paradigm. Prototype implementations of these mechanisms have been carried out for some platforms. Overall, the present deliverable represents a milestone associated with the expandability of the VITAL platform and paradigm, towards a broader range of legacy IoT platforms and architectures. D3.3.1 version of the deliverable has constituted its early release. In the current and final release (D3.3.2) the focus has been on providing 3 proof-of-concept implementations to better explain the adaptation and migration process.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
This deliverable is addressed to the following audiences: • IoT application developers and solution providers, notably (third-party)
developers and providers of smart city solutions that currently deploy/use legacy IoT platforms and who wish to exploit the VITAL semantic interoperability characteristics. Indeed, such developers and solution provides will be seeking ways of adapting their platforms and applications to the VITAL paradigm. The present deliverable provides a procedure and “cookbook” for such an adaptation.
• IoT researchers, notably researchers working on IoT platforms and standards. The present document could serve as a valuable guide for them to understand the structure of services, data streams, filters and other IoT resources in the scope of diverse architectures and platforms (including standards-based platforms, such as oneM2M). Specifically, by reading this document, IoT researchers will be able to understand differences in the practical implementations of different IoT platforms, which (in several cases) represent and support similar concepts in different ways.
• VITAL developers, notably individuals that will be engaging in the integration of legacy platforms or applications to the VITAL paradigm. VITAL developers may be undertaking such tasks as part of WP6 of the project, where applications for the Camden and Istanbul smart cities are implemented.
1.3 Summary
The deliverable starts with an overview of the main mechanisms for adapting and integrating a platform with the VITAL platform. These mechanisms are presented in the form of a four-step procedure, which includes design, mapping and implementation tasks. Accordingly, the deliverable presents the application of this process to the adaptation of a wide range of platforms, which can be grouped in four main categories, namely:
• standards-based platforms (such as oneM2M and OGC compliant platforms),
• public IoT cloud platform or services (such as Xively.com, CKAN),
• platforms that have been developed in the scope of EC funded projects (such as FP7 iCore and FP7 FIWARE),
• IoT devices
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
The deliverable is structured as follows: • Section 2, following this introductory section, illustrates the steps that are
required in order to adapt a given IoT platform to the PPI and VUAI mechanisms of the VITAL project.
• Section 3 maps the constructs and mechanisms of oneM2M standards-based platforms to the mechanisms and semantics of the VITAL platform, therefore illustrating how an oneM2M-compliant platform could be used in conjunction with VITAL.
• Section 4 is devoted to the presentation of the way an OGC-compliant platform could be used in conjunction with VITAL.
• Section 5 illustrates the adaptation and mapping of public IoT cloud platforms to the VITAL platform. Xively.com, CKAN, CityBikes are presented as concrete examples.
• Section 6 provides information on how IoT platforms produced in the scope of EC projects (including, for example, FIWARE) could be adapted and used in conjunction with VITAL.
• Section 7 explains how IoT devices can be adapted and used in conjunction with VITAL.
• Section 8 concludes the deliverable.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
The rationale behind adapting legacy IoT platforms in VITAL is manifold. In particular:
• It enables integration with and compatibility to legacy IoT platforms. Legacy IoT applications and platforms need concrete guidelines on how to integrate their functionalities with VITAL.
• It enables integration of many platforms along with their IoT services and data streams, thus giving rise to more and richer IoT applications.
• It facilitates the integration of standards-based systems, thus pinpointing VITAL’s compatibility and alignment to mainstream IoT standards.
2.2 Mechanisms
VITAL has published a set of specifications, under the name Platform Provider Interface (PPI), that define the interface between the VITAL platform and third-party IoT systems (i.e. IoT platforms and applications). An implementation of the PPI is all that is required by IoT platform and application providers that want to make their platforms and/or applications compliant with VITAL. In its current version, the PPI has been defined as a set of RESTful web services that are marked as either mandatory or optional. The use of popular web standards (e.g. REST, JSON-LD) will certainly facilitate the implementation of the interface, whereas the classification of the PPI services into optional and mandatory will minimize the effort required by IoT system providers in order to integrate their systems into VITAL.
2.3 Procedure
IoT system providers that want to connect their platforms into VITAL are expected to implement at least the subset of the PPI services that are marked as mandatory. This requirement does not merely involve the implementation and provision of a set of RESTful web services, but it also involves the task of transforming their data and metadata from the models that they currently use to the VITAL data models (and viceversa for e.g. configuration settings). The provision of an implementation of the Platform Provider Interface is essentially a process that can be summarized in the following steps.
Step 1: Describe the managed sensors The provider must first use the VITAL ontology to describe the sensors that the IoT system manages. Its type, the properties it observes, its accuracy, its reliability, or information about the quality of its network connection are only some parts of the information that can be provided for a sensor. In case of a mobile sensor, a movement pattern or a service that will allow VITAL to predict or learn, respectively, the current location of the sensor can also be described using the
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
VITAL ontology. It is important to note that during this process the provider might need to extend the VITAL ontology to accommodate, for example, sensor or property types that are not already part of the ontology. The final task for this step is to implement the RESTful web service (i.e. the PPI primitive) that will make all this information available to the VITAL platform.
Step 2: Describe observations As part of this step, the IoT system provider is expected to map the measurements made by the sensors to observations, as the latter are defined in the VITAL ontology. Note that, based on the SSN ontology that the VITAL ontology uses, an observation is a single value observed for a single property of a single feature of interest by a single sensor. This means that the need for observations of multiple features of interest or of multiple properties might require, for example, the definition of a new property or feature type. In order to complete this step, the IoT system provider must implement the RESTful web services that are required to support at least one of the two observation access mechanisms (push-based or pull-based).
Step 3: Describe the provided services If the provider offers one or more services that they want to make available through the VITAL platform, then they first need to use the VITAL ontology to describe them. The type of the service, as well as information of how to access it, or what its expected input and output are, are only some of the metadata that can be specified and exposed for the services that an IoT system provides. In order for VITAL to have access to the above information, the provider must implement the related PPI service.
Step 4: Describe the system The next step in the PPI implementation process is to implement the RESTful web service that will enable VITAL to have access to the metadata about the IoT system (e.g. about the person that is responsible to operate it).
Step 5: Enable the system in VITAL (register and secure the instance) The final step is to enable the system in VITAL by registering and securing the instance.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
One key notion in the Internet of Things (IoT) is the notion of Machine to Machine (M2M) Communications that is used to describe the communications between two or more entities without the need of any direct human intervention. In 2009, ETSI (European Telecommunications Standards Institute) formed a technical committee that was dedicated to the development of standards for M2M Communications. The first release of these M2M standards was published in February 2012 as a set of three publicly available specifications: requirements, functional architecture, and interface descriptions. Five months later, in July 2012, ETSI together with six other standards organizations from all over the world (ARIB and TTC from Japan, ATIS and TIA from U.S.A., TTA from Korea, and CCSA from China) established oneM2M, a global initiative for M2M standardization. The purpose and goal of oneM2M, as stated on its official web site, is “to develop technical specifications which address the need for a common M2M service layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M servers worldwide”. In a few words, what oneM2M intends is to provide specifications for a horizontal service layer that will enable services and applications across different industries to interwork. In February 2015, oneM2M issued its Release 1, a set of ten publicly available specifications: requirements, functional architecture, communication protocol specifications, security solutions, bindings for common protocols (such as CoAP, MQTT and HTTP), and re-use of existing device management technologies. Figure 1 gives an overview of the oneM2M functional architecture. Based on that, oneM2M identifies the following types of entities:
• Application Entity (AE): An AE is an entity in the application layer that implements a piece of M2M application logic (e.g. a powering metering application).
• Common Services Entity (CSE): A CSE is an entity that provides a set of service functions that are common in M2M environments (e.g. device management, data management and repository, subscription and notification services, location services, discovery services).
• Network Services Entity (NSE): An NSE is an entity that provides services from the underlying network to CSEs (e.g. device management, location services, device triggering).
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
Reference points allow M2M entities to communicate. An AE communicates with a CSE over the Mca reference point. Two CSEs communicate over the Mcc reference point. A CSE communicates with an NSE over the Mcn reference point. Finally, two CSEs that belong to different M2M Service Providers communicate over the Mcc’ reference point.
Figure 1: oneM2M functional architecture.
Figure 2 illustrates how the various oneM2M entities can be inter-connected. Nodes are logical entities that are uniquely identifiable. oneM2M supports the following node types:
• Application Dedicated Node (ADN): An ADN is a node that contains no CSEs and at least one AE. There may be zero or more ADNs in the Field Domain.
• Application Service Node (ASN): An ASN is a node that contains one CSE and at least one AE. There may be zero or more ASNs in the oneM2M system.
• Infrastructure Node (IN): An IN is a node that contains one CSE and zero or more AEs. There is exactly one IN in the Infrastructure domain per M2M Service Provider.
• Middle Node (MN): An MN is a node that contains one CSE and zero or more AEs. There may be zero or more MNs in the Field Domain.
• Non-oneM2M Node (NoDN): A NoDN is a node that contains no oneM2M entities.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
Figure 2: Configuration supported by the oneM2M architecture. In oneM2M, information is represented as resources. A resource is a uniquely identifiable (via a URI) entity that can be manipulated using CRUD operations, and that can contain child resources and attributes. In order to combine communications interoperability with data interoperability, oneM2M platform was decided to be semantically enhanced. In that direction, as part of Release 1, each resource can have a name (e.g. “Temperature sensor 123”), can be associated with zero or more labels (e.g. “temperature”), and can be linked to an ontology reference (e.g. “http://vital-iot.eu/ontology/ns/VitalSensor”). As a next step, in Release 2 (planned for delivery in autumn 2016), each resource will optionally have a complete semantic description. For that purpose, oneM2M base ontology is currently being developed. oneM2M base ontology is not specific to any vertical domain; instead it is expected to be integrated with the appropriate domain-specific ontologies, in order to serve the needs of a particular domain. In order to support this new semantic IoT model, oneM2M combines its existing resource repository with a triple store.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
In order to integrate an oneM2M compliant system into VITAL, we first need to map oneM2M resources to VITAL entities, which is a rather straightforward task because of the abstraction that oneM2M supports. Table 1 presents the results of this task.
Table 1: Mapping between oneM2M and VITAL entities. oneM2M VITAL AE Sensor
Container Property
ContentInstance Measurement
In oneM2M, Internet Connected Objects are represented as AEs. Those AEs can be mapped to sensors. Containers represent essentially data streams, i.e. sets of values that a particular sensor observes for a particular property. Based on that, containers can be mapped to observed properties. Content instances are in oneM2M what measurements are in VITAL; a value that a particular sensor observes for a particular property. oneM2M subscription and notification mechanism can facilitate the development of a push-based way to fetch into VITAL observations made by sensors. The management capabilities that oneM2M platform offers can support both the configuration and the management functionalities advertised by VITAL. Finally, in order to complete the picture, we need to add an extra ADN in any oneM2M system that we want to connect with VITAL; that ADN will have an AE that will implement all functionalities mandated by the PPI specification. The PPI-related AE will be responsible for accessing and manipulating all resources exposable to and/or configurable by VITAL.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
The Open Geospatial Consortium (OGC, formerly OpenGIS Consortium) is an international non-profit organization that works on the development of open and extensible standards for geographic data modelling and interchange. All of the OGC specifications are freely available on its official website. At the moment, the list comprises more than thirty standards covering every aspect of Geographic Information Systems (GIS) including standards related to web mapping services (WMS, WMTS, SLD), feature querying and presentation (WFS), semantic services (GSW, SSW, CSW, GeoSparql), sensor data modelling and acquisition (SWE and its descendants). The OGC's Sensor Web Enablement (SWE) standards can be particularly relevant for VITAL. The OGC SWE working group has specified a number of standards defining formats for sensor data and metadata, as well as service interfaces which enable the interoperable access to real and virtual sensor resources. The SWE 1.0 specifications, approved as standards between 2006 and 2007, offer the following functionalities:
• Description of sensor data to enable further processing
• Description of sensor metadata, including properties and behaviour of sensors, as well as correlating reliability and accuracy of collected measurements
• Access to observations and sensor metadata based on standardized data formats and appropriate querying and filtering mechanisms
• Tasking of sensors for the acquisition of measurement data Furthermore, the following functionalities are specified, but not yet approved as standards:
• Alerting based on sensor measurements and defined alert criteria
• Notification of end users in case of alerts or finished sensor tasks via, for example, SMS or e-mail
In the more recent SWE 2.0 framework, the main standards include:
• Observations & Measurements (O&M): Provides the general models and XML encodings for observations and measurements.
• Sensor Model Language (SensorML): Standard models and XML Schema for describing the processes within sensor and observation processing systems.
• SWE Common Data Model: Defines low-level data models for exchanging sensor related data between nodes of the OGC SWE framework. The main
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
objective is to achieve interoperability, first at the syntactic level, and then at the semantic level (by use of ontologies).
• Sensor Observation Service (SOS): An open interface for a web service to obtain observations, and sensor and platform descriptions from one or more sensors.
• Sensor Planning Service (SPS): An open interface for a web service by which a client can (a) determine the feasibility of collecting data from one or more sensors or models and (b) submit collection requests.
• SWE Service Model: Defines data types for common use across OGC SWE services. Five of these packages define operation request and response types.
Other SWE specifications that are under discussion or in various stages of development focus on aspects related to alerting, eventing, and discovery. As shown in Figure 3 below, in the evolution of SWE specifications from version 1.0 to version 2.0, O&M and SensorML standards have evolved from version 1.0 to version 2.0. Instead, the Transducer Markup Language (TML) Encoding Standard, an application and presentation layer communication protocol for exchanging live streaming or archived data to (i.e. control data) and/or sensor data from any sensor system, has been retired. Furthermore, the SWE Common Data Model, which defines data types shared by multiple SWE specifications, has been extracted from the SensorML standard, and is now provided as a standalone specification called SWE Common 2.0. A recent specification is the Event Pattern Markup Language (EML). It is used to define event patterns as processing rules for Complex Event Processing (CEP) and Event Stream Processing (ESP). These processing techniques can be implemented within services such as the Sensor Alert Service or the Sensor Event Service.
Figure 3: SWE information model (in green boxes, standards; in beige boxes,
not yet standards)1.
1 Figure from (Bröring, 2011).
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
SWE services use SensorML as a format for describing their associated sensors. The Sensor Model Language (SensorML) allows describing processes and processing components associated with the measurement of observations. This includes sensors and actuators, as well as related computational processes pre- and post-measurement. In SensorML a sensor is defined as a process which is capable of observing a phenomenon and returning an observed value. It allows a detailed description of a process including a listing of its inputs, outputs, parameters, and process methods. Further metadata of a process can be defined including its identification and classification, as well as characteristics, such as its temporal availability or its spatial description.
4.1.2 Observations & Measurements model
The Observations & Measurements (O&M) standard defines a domain independent, conceptual model for the representation of (spatiotemporal) measurement data. O&M is particularly used for the creation of response documents for the GetObservation operation of the SOS. However, O&M can also be used as a generic means to deal with measurements in a standardized way. The basic observation model as designed in O&M 2.0 is shown in Figure 4. An observation has a relationship to a procedure representing the process which has made the observation, e.g. a physical sensor or a simulation. The observed property points to a description of the property which is observed (e.g. air_ temperature or sea_water_salinity). The observation‘s result can be of any type, ranging from a single measurement to an n-dimensional coverage of values. The feature of interest, the computational representation of a real world feature, carries the property which is observed. The observation provides a value for this property at a certain time (the phenomenon time).
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
4.1.3 SWE Service Model and sensors related service specifications
The SWE Service Model (SWES)3 standard has been introduced to have a common definition of many aspects of SWE service specifications, including service operations and exceptions. SPS 2.0 and SOS 2.0 are based on this common SWE service model.
Figure 5: Main SWE services (in green boxes, standards; in beige boxes, not yet standards).4
2 Figure from (Bröring, 2011). 3 http://www.opengeospatial.org/standards/swes 4 Figure from (Bröring, 2011).
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
The following OGC service specifications are particularly related to the VITAL scope. Sensor Observation Service (SOS) The SOS standard defines services to query sensor data and metadata, encoded in SensorML, and the measured values, in the O&M format. Sensor Planning Service (SPS) The SPS standard defines interfaces for queries that provide information about the capabilities of a sensor and how to task the sensor. The standard is designed to support queries that have the following purposes: (a) to determine the feasibility of a sensor planning request; (b) to submit and reserve/commit such a request; (c) to inquire about the status of such a request; (d) to update or cancel such a request; and (e) to request information about other OGC web services that provide access to the data collected by the requested task. Using SPS, sensors can be reprogrammed or calibrated, sensor missions can be started or changed, and simulation models can be executed and controlled. The feasibility of a tasking request can be checked and alternatives may be provided. Sensor Event Service (SES) SES is an enhancement of the Sensor Alert Service (SAS). Both are used to provide a publish/subscribe based access to sensor data and measurements. They also provide optional methods to dynamically add new sensors and send notifications to the service. The SES specification is currently available as an OGC discussion paper. SES provides operations to register sensors at the service application and let clients subscribe for observations available at the service. The service performs filtering of sensor data (streams) based upon the filter criteria defined in these subscriptions. Filters can be applied on single observations, but also on observation streams, potentially aggregating observations into higher-level information (which itself can be regarded as observation data). Whenever matches are discovered, a notification is sent to the subscriber, using asynchronous, push-based communication mechanisms. OGC SensorThings API The OGC SensorThings API is currently a standard candidate proposed by the OGC Sensor Web for IoT Standards Working Group, with the aim of providing an open and unified framework to interconnect IoT devices, data, and applications in the Web of Things and Internet of Things. Although the OGC SensorThings leverages existing OGC SWE standards, its service interface is different from the other OGC web services, in that it is based on JSON encoding. The OGC SensorThings API is inspired by the OASIS Open Data Protocol (OData), which defines a general-purpose RESTful service interface, but it has been specifically designed for the IoT.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
In order to define an appropriate mapping between OGC standards entities and VITAL entities, the following definitions for the SOS and other OGC standards shall be considered:
• Feature of Interest (FOI): is the “geoobject” whose properties are under observation. The FOI is usually the means of locating (geocoding) the measuring points, i.e. the geoobject has coordinates (for example latitude, longitude and altitude).
• Observation: provides measurement (result) for the property (phenomenon) of an object under observation (Feature of Interest). An instance of an Observation is classified by its phenomenon time, feature of interest, observed property, and the procedure used. The result could have been generated at a time (resultTime) different from the phenomenonTime.
Other relevant concepts, involved in SensorThings as shown in Figure 6, are:
• Thing: is an object of the physical world (physical thing) or the information world (virtual thing) which is capable of being identified and integrated into communication networks.
• Location: is an absolute geographical position at a specific time point.
• Data Stream: groups a collection of observations that are related in some way.
• Sensor: is an instrument that can observe a property or phenomenon with the goal of producing an estimate of the value of the property.
• Observed Property: specifies the phenomenon of an observation.
• Actuator: is an instrument that can execute a task.
• Tasking Capability: serves as an executable function of a thing. A tasking capability could be enabled by an actuator.
• Task: is a user-submitted request for executing a tasking capability. A user can specify input values of a task based on the parameters description of a tasking capability. A user can also specify the time that he/she wants the task to be sent to the thing.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
In VITAL, a sensor is modelled by the VitalSensor class that extends the SSN Sensor class. In SSN, “a sensor can do (implements) sensing: that is, a sensor is any entity that can follow a sensing method and thus observe some Property of a FeatureOfInterest. Sensors may be physical devices, computational methods, a laboratory setup with a person following a method, or any other thing that can follow a Sensing Method to observe a Property”. The mapping with OGC sensor and FOI is therefore straightforward. In VITAL measurements, as specified in D3.1.2, are modelled as ssn:Observation. Similarly to the Observation entity in OGC data model, the observation contains a link to an observed property (using ssn:observationProperty) and specifies when the measurement was taken (ssn:observationResultTime), at which location (dul:hasLocation). The next step is to map SOS service operations to VITAL interfaces. VITAL services can use, through a proper PPI, the functionalities provided by the OGC services. The usage of the SOS (and other OGC standards) could be described from two user perspectives: the sensor data publisher perspective, and the data consumer perspective. We will focus here on the latter, since it is what is needed to integrate data and services from legacy OGC system into VITAL. SOS Operations The SOS has a so-called core profile, which defines three mandatory operations:
• GetCapabilities: returns an XML service description with information about the interface (offered operations and endpoints), as well as the available sensor data (such as the period for which sensor data is available, sensors that produce the measured values, or phenomena that are observed, for example air temperature).
• GetObservation: allows pull-based querying of observed values, including their metadata. The measured values and their metadata are returned in the O&M format.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
• DescribeSensor: provides sensor metadata in SensorML. The sensor description can contain information about the sensor in general, the identifier and classification, position and observed phenomena, but also details such as calibration data.
The optional transactional profile defines how new sensors can be registered on the service interface, and how measuring values can be inserted. The enhanced profile specifies extended operations including:
• GetFeatureOfInterest: returns the geoobject whose properties are monitored by sensors in Geography Markup Language (GML) encoding.
Mapping between SOS services and PPI services is shown:
Table 2: Mapping between SOS operations and PPI primitives.
SOS operation PPI Primitive GetCapabilities Get IoT service metadata
GetObservation Get observations (pull-based) (all observations made by a sensor or observations made by it in a specific time range)
DescribeSensor Get sensor metadata
GetFeatureOfInterest (not mandatory)
Get sensor metadata (not mandatory)
SPS operations SPS defines the following mandatory operations:
• GetCapabilities: returns a document with a detailed description of the service and the connected sensors
• DescribeTasking: with this operation, a client can obtain information about the parameterization of the sensor. This includes information about the permitted value ranges, the unit of measurement these values must be transmitted and whether the setting of a specific value is mandatory or optional.
• Submit: with this operation the (new) values are transmitted to the SPS.
• DescribeResultAccess: describes where the result of this process can be picked up from after processing. This can be a SOS or simply a link to a file.
In VITAL, a ConfigurationService can allow obtaining or setting configuration information about the IoT services through its GetConfiguration and Set Configuration operations.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
SES operations The default binding of SES is based upon SOAP and WS-Notification, but the specification allows the definition of other bindings, for instance an XMPP binding compatible to SAS. In the basic version SES acts as a notification producer. The notification producer interface provides methods to subscribe for notifications and retrieve the latest notification. The notifications received by the SES are posted to topics. These topics define logical groups of notifications. They are declared following the WS-Topics standard. A mandatory predefined topic is that of Measurement, used for O&M and SESEvent messages. Further topics can be added as needed. Sensor notifications are for instance posted to the measurements topic, notifications regarding the management of sensors are posted to the sensor management topic. When subscribing for notifications at the SES one can filter the notifications by topic. In addition to the topic-based filtering, one can define content-based filtering criteria to further restrict the notifications. SES can be exploited in order to implement push-based access to sensor data, which allows accessing a stream by subscribing to it (i.e. a specific sensor and property combination). To this, it is needed to implement an ObservationService having a SubscribeToObservationStream operation to create a subscription to a specific stream of observations and an UnsubscribeFromObservationStream operation to cancel the subscription with a specific ID. OGC SensorThings API The OGC SensorThings API consists of two major profiles:
• Sensing profile: is designed based on the OGC SOS specification. The SensorThings API adopts the efficient RESTful web service style and allows CREATE, READ, UPDATE, and DELETE (CRUD) actions to uniquely-identifiable resources in the service, entities of type Thing, Location, Datastream, Sensor, Observation, FeatureOfInterest, and ObservedProperty.
• Tasking profile: is based on the OGC SPS specification, which defines an interoperable way to submit tasks to control sensors and actuators. This profile is mainly for users to control actuators through a unified web service interface. There are two major parts in the TaskingCapability profile. The first part is to convey the acceptable parameters of an actuator and allow users to submit controlling tasks through a RESTful interface. The second part in the TaskingCapability profile is to allow SensorThings services to communicate with actuators that are attached to things.
For mapping of operations, follow the guidelines for SOS and SPS. Note that in the SensorThings API, each entity is encoded in JSON. For example, a Sensor has this JSON format:
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
OGC SensorThings API groups the same types of entities into collections. Each entity has a unique identifier and one or more properties. Also, in the case of an entity holding a relationship with entities in another collection, this entity has a navigation property (i.e. a link) linking to other entities. Each entity has:
• ID: the system-generated identifier of an entity. ID is unique among the entities of the same entity type.
• Self-Link: the absolute URL of an entity which is unique among all other entities.
Each entity can also have Association-Links, relative URLs showing the related entities in other entity types, and Navigation-Links, relative URLs that retrieve content of related entities. The sensing and tasking profiles can be used in Vital to access sensor data and metadata and management capabilities.
5 ADAPTATION OF PUBLIC IOT CLOUD PLATFORMS
5.1 Xively
5.1.1 Overview
Xively is an IoT Platform as a Service (PaaS) that enables its users to store their data, query them, and even receive notifications when certain conditions are met (e.g. when a new value has been added). In Xively, products are used to represent device types (e.g. Acme Smart Thermostats), and devices are merely individual instances of a product, each of which is uniquely identified by a serial number. Once a device is created, a feed is automatically created for it. Each device has exactly one feed, but can have one or more data streams (channels) associated with it. Each datastream represents a specific variable, whose values in time are represented as datapoints in that stream (i.e. timestamp-value pairs). So, feeds can
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
be viewed as collections of datastreams (defined for the corresponding device), whereas datastreams can be viewed as collections of datapoints. Xively provides also support for triggers (a.k.a. notifications): users can specify conditions on datastreams that, when met, result in HTTP POST requests made to a URL of the user’s choice. Xively identifies seven types of resources (feeds, datastreams, datapoints, keys, triggers, products, devices), and provides a set of pre-defined attributes for each one of them. These attributes act as metadata about the resources. Especially for feeds and datastreams, Xively supports the use of tags. Tags are keywords (e.g. Temperature) that can be assigned to feeds and datastreams mainly for identification, discovery and/or grouping purposes. A feed or a datastream can have zero or more tags associated with it. Xively exposes information about its resources through REST in XML, JSON or CSV format, and supports the following communication protocols:
• HTTP (discouraged)
• HTTPS
• WebSockets
• TCP Sockets
• MQTT In order to control the access to its resources, Xively makes use of API keys. Each API key contains a key, each key contains one or more permissions, each permission may optionally contain one or more resources. This scheme allows for fine-grained control on who, how, and when has access to a specific resource. Access control at the resource level is only supported for feeds and datastreams. Master keys can be used to grant access to all other types of resources. Keys can be included in a request either as part of the header or as part of its URL (discouraged). Xively supports OAuth.
5.1.2 Mapping Guidelines
First we need to find an appropriate mapping between Xively entities (e.g. devices, feeds, datastreams) and VITAL entities (e.g. sensors, services, measurements). Table 3 gives an overview of this mapping.
Table 3: Mapping between Xively and VITAL entities. Xively VITAL Product Sensor
Device Sensor
Feed Sensor
Datastream Property
Datapoint Measurement
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
Products, devices and feeds can be mapped to sensors. More specifically, we need to use:
• the feed title to determine the name of the sensor
• the product name, the product description and/or the feed tags to determine the type of the sensor (e.g. http://vital-iot.eu/ontology/ns/VitalSensor)
• the feed disposition to determine the movement pattern of the sensor (only fixed and mobile sensors can be supported)
• the feed waypoints to determine the current location of a mobile sensor The datastreams that are associated with a feed can be mapped to properties that the corresponding sensor observes.. More specifically, we can use:
• the datastream tags to determine the type of the observed property (e.g. http://lsm.deri.ie/OpenIoT/Temperature)
A Datapoint in a datastream can be mapped to a measurement that was collected by a specific sensor (namely the sensor that the corresponding feed has been mapped to) for a specific property (namely the property that the corresponding datastream has been mapped to). More specifically, we can use:
• the datapoint timestamp to determine the time of the observation
• the datapoint value to determine the observed value
• the datastream units, unit type and unit symbol to determine the unit of the observed value
VITAL services can be implemented using the functionalities provided by Xively. For example, a localization service can be implemented using waypoints. Triggers can be used to implement the push-based access to sensor data, as prescribed by VITAL. When a user wants to subscribe to a stream (i.e. a specific sensor and property combination) a trigger will be created and associated with the underlying datastream. When a user wants to unsubscribe from a stream, the corresponding trigger will just be deleted.
5.2 CKAN open data portal platform
5.2.1 Overview
CKAN is a data portal platform that enables its users to set up their own data portals. It is developed by Open Knowledge Foundation, a non-profit organisation dedicated to finding solutions to the technical and social problems of opening up knowledge and data. CKAN is licensed under the terms of the Afferno GNU GPL v3.0, and thus can be downloaded and used for free. CKAN allows its users, among others, to:
• Publish data
• Search data using keywords
• Filter data using tags
• View a complete change history of data
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
• Communicate and collaborate on data (e.g. add comments or discuss on Facebook)
All the above features are made available through both an intuitive web interface and a powerful RESTful JSON API. In CKAN, data is published in units called datasets. Each dataset is essentially a collection of data (e.g. temperature data for London, or traffic data for Istanbul), and has two things: (1) metadata that describes it, and (2) any number of resources that contain the data itself. A resource can be a CSV file, an Excel spreadsheet, an XML file or even a JPEG image. CKAN can either store resources internally, or just keep links to them in case they are hosted elsewhere. CKAN protects datastreams using a distributed authorization model that is based on organisations. Each organization has one or more users, each one with a different role that determines his permissions. Each dataset is owned by an organisation, and can be either public or private. Private datasets are visible only to the logged-in users of their organization. CKAN primarily aims at data publishers (e.g. companies or organizations) that want to make their data available, and allows them to set up their own data portal for that purpose. CKAN portals can be themed (using CSS), integrated with CMS’s (like Drupal or WordPress), and enhanced with any of the more than 150 CKAN extensions that exist. Examples of CKAN portals around the world include: (1) data.gov.uk, the official open data portal of the UK government, that is powered by CKAN and Drupal, (2) publicdata.eu, a research prototype of a pan-european data catalogue and federation mechanism developed as part of the FP7-funded LOD2 project, (3) the Helsinki Region Infoshare project that combines CKAN with WordPress, and (4) the International Aid Transparency Initiative (IATI) that uses CKAN to make aid spending information easier to access and understand. CKAN provides a harvesting mechanism that can be used to pull in information from several repository sources (e.g. geospatial CSW servers). It can even be used to pull data from other CKAN instances, thereby allowing the creation of federated networks of CKAN nodes that share data between each other. Finally, Datahub is a data management platform that is also developed by the Open Knowledge Foundation, is based on the CKAN data management system, and provides its users with free access to many of CKAN’s core features. The decision of whether someone should create an account on Datahub or set up his own data portal depends really on his needs; for example, if all he wants to do is publish a few datasets, then it will most probably not worth the effort of setting up, configuring and running his own data portal for that purpose.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
Table 4 depicts the mapping from CKAN entities (e.g. datasets and resources) to VITAL entities (e.g. sensors, measurements).
Table 4: Mapping between CKAN and VITAL entities. CKAN VITAL Organization System
Dataset Sensor
Dataset Property
Resource Measurement
As shown in the above table, organizations can be mapped to systems, and published datasets can be mapped to managed sensors. That way we manage to also preserve the ownership relation between the organizations and their datasets. Resources can be mapped to measurements or, in some cases, collection of measurements. In case a resource contains more than one measurements, then we might need to parse it first, in order to import the measurements one by one into VITAL. In case a resource is not stored internally to CKAN, but is rather hosted elsewhere, we need to follow the link that points to it, in order to pull the data it contains into VITAL. In any case, the only mechanism we can support in order to import data from CKAN into VITAL is the pull-based one. Finally, in order to support CKAN authorization system, we can map CKAN organizations to VITAL groups, CKAN users to VITAL users, and use the license of each dataset to (automatically) build the necessary policies to control its access. Developers can find in the “Vital-CKAN” project of VITAL source code repository the proof-of-concept implementation of the above-described guidelines.
5.3 CityBikes data service
While CKAN is a general purpose data portal platform, CityBikes is a service started in 2010 as a FOSS alternative endpoint to gather information for Barcelona’s Bicing bike sharing service and later on evolved to become an open API [9] providing bike sharing live data of many services worldwide. We use this as an example of connecting an existing data source to VITAL and constructing a PPI, while adding to the platform live open data for different cities. CityBikes is also a particular example which allows to show how VITAL can deal with hierarchies of IoT systems. In this case, the CityBikes service has been modelled as a VITAL system containing a number of sub-systems, each being a bike sharing network exposed by the API. The super-PPI is more like a container wrapping the networks under the CityBikes umbrella, while the sub-PPIs expose the “real” sensors, which provide live information about free bikes and empty slots of each network station.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
Developers can find in the “vital-ppi-citybikes” project of the VITAL source code release the implementation of this mapping.
The implementation is based on two main components: one calls the CityBikes API endpoints to obtain the networks list or the network specific data and metadata and converts the JSON responses to Java objects. The other one exposes the HTTP services required by the PPI specifications and, upon request, populates the objects to send as response with the data obtained from CityBikes and additional performance metrics of the system.
The PPI has no static knowledge of the networks, but dynamically exposes the data retrieved at runtime from CityBikes. This also means that when a new bike sharing service is added a new PPI is automatically exposed and added as a sub-system to the super-PPI.
Since CityBikes allows observing the live status of bike sharing stations, but nothing more, the PPI does not provide historical data (a database at the PPI level would need to be set up). The observation service is based on the pull-based mechanism and leaves to the VITAL platform instance to choose with what frequency it wants to retrieve the data.
6 ADAPTATION OF EU PLATFORMS
6.1 FIWARE Platform
6.1.1 Overview
The FIWARE platform [3] is a generic and extendible ICT platform for Future Internet services. FIWARE platform provides a set of APIs (Application Programming Interfaces) that aim to ease the development of smart applications in multiple sectors. These APIs along with their specifications are publically available for free. For the purpose of reference, an open source implementation of FIWARE modules is also made publically available. The FIWARE catalogue [4] contains a list of these modules, which are called generic enablers. In order to make the programming task easier, these enablers allow developers to put into effect functionalities for example connecting the Internet of Things.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
FIWARE - Generic Enablers along with open source reference implementation are made available hence providing a variety of general-purpose functions that can be used when developing smart applications. These functions are provided through well-defined APIs. The specifications of these APIs are public and royalty-free. For example, Data/Context Management API provides functionalities to support easy access, gathering, processing, publication, and analysis of context information at large scale. The Security API makes the delivery and usage of services trustworthy by meeting security and privacy requirements. The Internet of Things (IoT) Services Enablement (enabler) supports IoT functionalities to make “connected things” available, searchable, accessible, and usable by the application. A number of APIs/adapters for IoT enabler are available which include, protocol adaptor, backend device management, IoT discovery, configuration manager, etc. The integration of FIWARE platform into VITAL will be carried out through IoT Services Enablement module.
6.1.1.1 Architecture Overview
The core FIWARE platform is based on a number of chapters. These chapters comprise of various Generic Enablers (GEs) belonging to the same domain. Figure 7 depicts the architecture of FIWARE platform with all major chapters and GEs they contain. The IoT Service Enablement chapter GEs are spread in two domains: Gateway and Backend. IoT Gateway GEs provide inter-networking and protocol conversion methodologies between devices and the IoT Backend GEs; the IoT Backend GEs provide management functionalities for the devices and IoT domain-specific support for the applications. The GEs to be used from the IoT Service Enablement chapter depend on the IoT deployment scenarios. For example, if a simple integration of IoT devices into the Data chapter Context Broker is required (this will enable FIWARE App developers to interact with these IoT devices) then the mandatory GEs to be used are Backend Device Management GE and Data chapter ContextBroker GE. This scenario is depicted in Figure 8. Similarly, other use-case scenarios can require the utilization of GEs available in various FIWARE chapters.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
Figure 8: FIWARE IoT devices integration and management.
6.1.2 Mapping Guidelines
The integration of FIWARE platform into VITAL can be carried out through “IoT Services Enablement chapter”. In order to connect IoT devices or the Gateways to VITAL application using the FIWARE platform, Ultralight2.0 (UL2.0) – which is a simplified version of SensorML (SML) standard, can be used. The IoT devices then send their observations or measurements to the FIWARE Lab public ContextBroker. Once the readings from connected IoT devices reach the public ContextBroker, they can be accessed by the application.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
Orion Context Broker is an implementation of the Publish/Subscribe Context Broker GE, which provides NGSI9 and NGSI10 interfaces. Using these interfaces VITAL application will be able to carry out the following operations: Register context broker applications, update context information, receive notifications if there is a change in context information, and query the context information. These interfaces are RESTful interfaces and can easily be integrated into the VITAL (as the integration of VITAL modules is carried out through RESTful interfaces). NGSI RESTful interface is a standard interface, which allows handling any type of data. Figure 9 provides a list of REST operations that can be performed on the context information available in the public ContextBroker.
Figure 9: FIWARE schema of REST resources in NGSI-9/10.
The purpose of the RESTful API is to exchange information regarding the availability of context information. The three main questions VITAL’s PPI can ask are: discover hosts where context information is available, subscribe for context information updates, and registration of available context information. These three interactions along with other interfaces can be mapped to VITAL entities. Further information about this API is available at [5]. Table 3 provides an overview of this mapping.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
iCore is an Internet of Things platform whose main differentiator is cognition. This platform uses cognition in order to govern and dynamically find solutions for the usage of resources of the iCore system. An iCore system is able to extract knowledge from each situation, and learn the way to improve the support to applications. This comprises the capabilities to recognize patterns and to derive knowledge from them. Virtualization is another important feature of this platform. iCore has the capability of virtualize real world objects, and to represent them into a programmable framework. Virtualization can help to overcome the heterogeneity of many proprietary architectures and systems, enabling the possibility to run several proprietary IoT applications into a single platform. Virtualization enables the possibility of programming in relation to real world objects in the iCore platform, as well as of controlling, governing, or integrating the virtual instances in a programmable environment. Virtualization also allows deriving useful functions from many heterogeneous devices deployed in the real world. Composition and extraction of these features are supported by virtualization. The scope of iCore includes large scale systems. These systems are dealt with in a different way than small Internet of Things systems, because they comprise many objects that have a very unpredictable and dynamic behaviour. The objective of iCore is to put together virtualization and self-organization in order to create an intelligent environment of large size, capable of self-governing a great deal of issues.
6.2.1.1 High Level architecture
As it is said before, the target of the iCore architecture is to support virtualization and to enrich the IoT environment with cognitive capability. The main concepts are the following:
- Virtual Object (VO): A VO is the virtual representation of an ICT object that is associated with a non ICT object. It brings the ICT object in a specific real-world context, which is modelled as an association to one or more non-ICT objects. VO helps in accessing the real world objects and interfacing them to
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
the external world. VO can be seen as providing a very basic set of functionalities representing the actual functions of a Real World Object.
- Composite Virtual Object (CVO): It is a combination of VOs that can be functionally extended by introducing new functionalities and logic with respect to the applications and needs of the environment. It is a mash-up of VOs that renders services in accordance with user perspectives and application requirements. A CVO may have several VOs or only one if it has built some more cognitive functionalities which are not possible or available in the included VO.
- Servitization: It is a mean to create a continuum between a product and a set of remote functionalities that augment the capabilities and properties of the product and to relate it to other products and functions either in the physical or virtualized environments.
Figure 10 depicts the main iCore concepts.
Figure 10: iCore concepts.
The interaction with an iCore system is initiated through a Service Request generated for the purpose of activating a data streams from IoT objects and processing them to support and end-user or application with a set of processes to monitor a situation, and produce alerts when particular conditions are met. Such processes are orchestrated and bound to relevant VOs using iCore functionality. A Service Request can get a Service Execution Request, mapped via the Service Level functionality, which is then passed to the lower CVO/VO levels for the selection
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
and activation of appropriate objects needed for satisfying the request. iCore has a loose coupling between service requests and actual IoT objects or a combination of these which satisfies the request as well as the ability to select these dynamically, runtime and purposefully though the use of cognitive technologies. This is possible due to the ability of iCore system to learn and adapt to changing situations to satisfy requests.
Figure 11: High level Representation of the iCore Architecture.
To support all these functionalities and the decoupling between the user requests and the composition of processing nodes, iCore provides different Knowledge Models:
- Real World Knowledge Model: this model represents the interaction with users, their feedback as well as the accuracy of service behaviour.
- System Knowledge Model: this model holds on the current and past existence of CVOs, their behaviour and capabilities. It is fundamental for optimizing the iCore system operation.
Together with the knowledge models, iCore counts with three RDF repositories in order to store Meta Data of each element, and two registries that hold the reference and important data of each virtualization.
- Service Template Repository: It holds the metadata of each service. It is placed at Service level in order to look up for the appropriate service to fulfil a user request.
- CVO Template Repository: it contains a query-able collection of CVO templates. It is placed at CVO level and it is used by CVO Manager module in order to find the functionalities to attend the needs of services.
- VO Template Repository: it contains a query-able collection of VO templates. It is placed at VO level and it is used by VO Manager module in order to find the appropriate VOs that together with CVOs will fulfil a service request.
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
- CVO Registry: it contains metadata for each deployed CVO instance. It is placed at CVO level and is only used by CVO Manager.
- VO Registry: The VO Registry contains metadata for each installed VO, which is preserved for a specific time period. VO registries store the semantically enriched data that are used for the description of the VOs. It is placed at VO level and only accessed by VO Manager.
6.2.2 Mapping Guidelines
iCore was designed to fulfil user request by means of services, while isolating users from the internal processes of the platform. This idea implies that iCore does not offer an interface to interact with real objects, or even the Virtual Entities. Also, due to the high decoupling between layers of iCore (Service layer, CVO layer and VO layer) and the unavailability of accessing VOs entities directly, the task of integrating iCore into VITAL will be performed through a new iCore service. At the top level this new iCore service will implement al the primitives of the VITAL PPI, allowing a direct connection between both platforms. At the bottom level, this server will have to be able to work with the required CVOs that manage the VO instances, in order to, first fetch Metadata of each VO type, and then set the required configuration and secondly fetch the data of each Real World Object. In order to map VITAL entities with iCore data model we need to comment firstly the iCore VO data model:
Most IoT sensors and actuators are equipped with wired connection or with personal area level wireless radio interfaces (such as Zigbee, Bluetooth low energy, NFC, etc.) due to cost of radio modules, energy consumption, and subscription requirement of wireless cellular networks such as 3G, WiMAX and LTE. Wide area connectivity in order to collect data from such devices is typically provided by an IoT gateway node that can transfer the data to the server/cloud backend. REST APIs are commonly used IoT communication protocols, although also MQTT, AMQP, CoAP are often adopted. REST implementations are lightweight – HTTP clients and servers are now available even on the smallest, IP-enabled platforms and therefore a VITAL PPI can be
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
installed directly in IoT gateway based on Raspberry, Intel Edison or Arduino. If a VITAL specified REST APIs cannot be installed on the IoT device in the field (for instance because this is an off-the-shelf device not “open”), a VITAL compliant PPI can be deployed on the server and it shall deal with the device interface with its protocol while enabling VITAL functionalities. As an example of lightweight implementation for IoT devices, we describe in the following of this section the VITAL PPI developed for connecting an Arduino node, equipped with environmental sensors. The adaptation layer has been developed and tested on an Arduino Mega, a microcontroller board based on the ATmega2560. It has 54 digital input/output pins (of which 14 can be used as PWM outputs), 16 analog inputs, 4 UARTs (hardware serial ports), a 16 MHz crystal oscillator, a USB connection, a power jack, an ICSP header and a reset button. Arduino is a low-cost, open-source physical computing platform based on a simple I/O board; the Arduino development environment implements the Processing/Wiring language and provides an open-source IDE that can be downloaded and used for free. The sensor that has been used is the DHT115 digital temperature and humidity sensor. It is a basic, low-cost sensor using a capacitive humidity sensor and a thermistor to measure the surrounding air and spits out a digital signal on the data pin.
Figure 13 – Arduino Mega board and DHT11 sensor
We implemented a basic PPI, as explained in Section 3.4 of D3.2.3; this is what IoT providers wanting to connect a single sensor or few sensors shall do too. Concerning Steps 1 and 2 listed in the mapping procedure defined in Section Error! Reference source not found., the ontology did not require extensions, since the desired sensors types, observation types and methods were already described in VITAL ontology. The pull-based mechanism has been chosen for the PPI (the IoT adapter pulls data from it) and the service for providing observations has been implemented. Received requests are looped on and requested observations are dealt
5 DHT11 Description and datasheet: http://www.micropik.com/PDF/dht11.pdf
Deliverable 3.3.2: Adaptation and Migration Mechanisms V2
with through a getObservation function; this gets the time from an NTP server (needed for timestamp), retrieves the requested measure from the sensor, constructs the JSON response and sends it to the requester.
About the Step 3, to describe provided services, the mandatory Get sensor metadata PPI primitive which provides information about the sensors that we want to connect to the VITAL platform, has been implemented. The current status of the sensor is provided through the status property of the sensor. The current location of the sensor is provided through the hasLastKnownLocation property of the sensor. Finally, the observations made by the sensor are accessible using the hasObserver property of the sensor that is expected to point to a service of type ObservationService. About the Step 4, a service that enables VITAL to have access to the metadata about the IoT system (with information such as the system description, the owner, etc…) has been implemented. Once developed, the PPI for the IoT device has been registered (Step 5) using the IoT data adapter web interface, registering the unique URI for the device (which, in this case, represents the “system”) and the base URL, through which the PPI implementation is accessible. In order to have an IP reachable over the Internet, a free Dynamic DNS service has been used. The communication is over HTTP rather than HTTPS due to a hardware limit of the WiFi shield6, which does not support SSL; however, a newer Arduino WiFi Shield supporting SSL can now be found on the market. The Arduino “sketch”, i.e. program, can be found in the “vital-ppi-arduino-dev” project of VITAL source code release. Developers needing a PPI running on Arduino are recommended to see the template and instructions provided in D5.1.3 as part of the VITAL migration toolkit.
8 CONCLUSIONS
This deliverable describes the procedure or mechanism to integrate an IoT platform with Vital Platform. This mechanism, which comprises the tasks to design the platform interface, will ease the work of developers, solution providers and researchers whereas allow to leverage the capabilities of the platform to be integrated (devices, services, etc.). This mechanism is intended to offer a way to design the interface between VITAL platform and the provider platform by means of describing the metadata of the platform and devices it relies upon, observations and services, as well as implementation details of the interface. As examples of adaptation of a platform to VITAL, this deliverable describes the guide lines to adapt a platform compliant with M2M and OGC standards. These standards were selected as they are two of the most widely used in the design of IoT
platforms. It also tries to facilitate the task of designing the platform provider interface for the wider number of IoT platforms. In order to smooth the integration with other platforms and looking the collaboration with other researching projects, this document also describe how to adapt a public platform, Xively, and two other platforms that are the result of researching projects into the FP7 program. In addition to the afore-mentioned contents, already present in D3.3.1, this deliverable provides and describes VITAL enabling interfaces that have been implemented for the CKAN open data platform, a legacy data service (CityBikes) providing data from multiple cities, and an IoT resource-constrained device.
9 REFERENCES
[1] Bröring, E. J. (2011). New Generation Sensor Web Enablement. [2] OGC® Standards and Supporting Documents . (n.d.). Retrieved from http://www.opengeospatial.org/standards/ [3] The FIWARE platform. Retrieved from: https://www.fiware.org. [4] The FIWARE Catalogue. Retrieved from: http://catalogue.fiware.org [5] https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI-
10_Open_RESTful_API_Specification_(PRELIMINARY) [6] D2.3 iCore Architecture Reference Model [7] D5.3 Full specification of iCore Service Level cognitive management and control
mechanisms [8] VITAL- “D3.2.3 Specification and Implementation of Virtualized Unified Access
Interfaces V3”
[9] http://api.citybik.es/v2/CityBikes v2 API documentation page
