DELIVERABLE D3.5 Prototype of Platform Integration using ...api.ning.com/files/2lCHlA6Jtw4Kq20Lwk3UbPW23M3QRW1... · FI-WARE IoT Stack ... Introduction In recent years, various IoT

DELIVERABLE

This project has received financial support from the European Union Horizon 2020 Programme under grant agreement no. 688203.

D3.5 Prototype of Platform Integration using API

Mediators

Project Acronym: bIoTope

Project title: Building an IoT Open Innovation Ecosystem for Connected Smart Objects

Grant Agreement No. 688203

Website: www.bIoTope-project.org

Version: 1.0

Date: June 20, 2017

Responsible Partner: Aalto University

Contributing Partners: ControlThings, UL, ITMO

Dissemination Level: Public X

Confidential – only consortium members and European Commission Services

Ref. Ares(2017)3188034 - 26/06/2017

D3.5 Prototype of Platform Integration using API Mediators

© 688203 bIoTope Project Partners 2 June 20, 2017

Revision History

Revision Date Author Organization Description

0.1 10/05/2017 Asad Javed Aalto University Initial draft

0.2 17/05/2017 Asad Javed Aalto University Introduction written

0.3 21/05/2017 Asad Javed Aalto University Section 2.1 and 2.2 completed

0.4 23/05/2017 Asad Javed Aalto University Chapter 2 completed

0.5 29/05/2017 Kristian Bäckström ControlThings Section 3.1 written

0.6 30/05/2017 Asad Javed Aalto University Section 3.2 written

0.7 31/05/2017 Petr Fedchenkov ITMO University Chapter 4 completed

0.8 31/05/2017 Kristian Bäckström ControlThings Section 3.1 reviewed and updated

0.9 02/06/2017 Sylvain Kubler UL Section 3.4 written

0.10 02/06/2017 Asad Javed Aalto University Section 3.2 reviewed and updated

0.11 03/06/2017 Asad Javed Aalto University Section 3.3 written

0.12 04/06/2017 Asad Javed Aalto University Chapter 3 completed

0.13 05/06/2017 Asad Javed Aalto University Draft ready for review

0.14 13/06/2017 Tom Palmgren Ensto Enervent Draft comments

0.15 16/06/2017 Christian Mader Fraunhofer IAIS Draft comments

0.16 18/06/2017 Eva Coscia Holonix Draft comments

0.17 19/06/2017 Asad Javed Aalto University Including reviewers feedback

1.0 20/06/2017 Asad Javed Aalto University Final version

Every effort has been made to ensure that all statements and information contained herein are accurate, however the bIoTope Project Partners accept no liability for any error or omission in the same.



Table of Contents

Executive Summary ...................................................................................................................... 5

1. Introduction .......................................................................................................................... 6

1.1. Objectives of WP3 ..................................................................................................................... 6

1.2. Objectives in D3.5 ..................................................................................................................... 6

1.3. Structure of the document ........................................................................................................ 7

2. O-MI/O-DF Reference Implementation .................................................................................. 8

2.1. O-MI Node Server ..................................................................................................................... 8

2.2. Agent System Interface ........................................................................................................... 10

2.3. O-MI Node web client ............................................................................................................. 11

3. O-MI/O-DF Wrappers Integration ........................................................................................ 14

3.1. MIST to HTTP/Websocket wrapper .......................................................................................... 14

3.1.1. Mist wrapper to Websocket based O-MI/O-DF server ............................................................. 15

3.2. 1-wire wrapper ....................................................................................................................... 15

3.3. Warp10 wrapper ..................................................................................................................... 17

3.4. IoTBnB wrapper ...................................................................................................................... 19

3.5. OpenIoT Platform Integration .................................................................................................. 21

4. FI-WARE IoT Stack ............................................................................................................... 23

4.1. Device integration with FI-WARE ............................................................................................. 24

5. Conclusion .......................................................................................................................... 28

6. References .......................................................................................................................... 29



List of Tables

Table 1: Basic operations of messaging standard ............................................................................................... 9

Table 2: Minimal set of APIs to enable search & discovery of IoT data/services in the bIoTope ecosystem ... 19

List of Figures

Figure 1: Integration platforms active in the IoT (source: FirstMark) [4] ............................................................ 7

Figure 2: Reference implementation modules [8] .............................................................................................. 8

Figure 3: Architectural overview of the reference implementation ................................................................... 9

Figure 4: External agent architecture functionality ........................................................................................... 10

Figure 5: Detailed functionality of Internal agents ............................................................................................ 11

Figure 6: Starting page of O-MI reference implementation .............................................................................. 11

Figure 7: An example of O-MI web client interface showing five different panels ........................................... 13

Figure 8: The extended version of required and optional parameters ............................................................. 13

Figure 9: An example of the perspective a Mist to HTTP/WS wrapper can provide. The network contains a lot

more identities and systems, but the exposed information and control access corresponds to the

amount that has been shared with this particular Mist to HTTP/WS wrapper node. .............................. 14

Figure 10: The trust relations are formed between identities. If the vessel is hosting the Mist HTTP wrapper it

will only expose the lighthouse for other O-MI/O-DF HTTP nodes, since that’s the only identity relation

the vessel has. ........................................................................................................................................... 15

Figure 11: 1-wire sensor example with the home gateway .............................................................................. 16

Figure 12: O-MI/O-DF reference implementation sandbox which shows the 1-wire sensors information ..... 16

Figure 13: A script to create O-DF tree structure using named variables ......................................................... 17

Figure 14: Warp10 database is running separately and the wrapper connects this database to O-MI node

server ......................................................................................................................................................... 18

Figure 15: An example of O-MI write message that is converted into warp10 supported format and send to

the database for storage ........................................................................................................................... 18

Figure 16: An example of O-MI read message that request the data with WarpScript data manipulation

environment and receives a response message ....................................................................................... 18

Figure 17: Illustration of IoTBnB features (to securely publish and/or consume IoT data/services) and how

IoTBnB is going to be “wrapped” to expose the marketplace APIs based open IoT interfaces ................ 20

Figure 18: O-MI/O-DF request message when calling the “getAllServices” function ....................................... 20

Figure 19: O-MI/O-DF response message returned by the “getAllServices” function (assuming that only 2

services are included in the IoTBnB service catalog)................................................................................. 21

Figure 20: Architectural overview of the system illustrating platform integration .......................................... 22

Figure 21: System architecture in which there are two proposed components named mobile.core and

mobile.appl ................................................................................................................................................ 23

Figure 22: The mobile application interface and the result of bad air quality location after performing search

and query ................................................................................................................................................... 23

Figure 23: The possible components of FI-WARE IoT stack .............................................................................. 24

Figure 24: Device integration architecture ........................................................................................................ 26

Figure 25: Freeboard interface example ........................................................................................................... 27

Figure 26: Node-Red browser based editor for creating JavaScript functions ................................................. 28



Executive Summary

This deliverable is a part of WP3 which defines the overall bIoTope Systems of Systems (SoS) ecosystem architecture by providing state-of-the-art framework for information source publication and consumption developed around Open API standards including Open Messaging Interface (O-MI) and Open Data Format (O-DF) specifications. This SoS platform will enable users, developers, and resource providers to publish, consume, compose, and integrate services in order to explain the coordination of various platforms with the standardized APIs. For the platform to be successful, the APIs and platforms need to be robust and better managed, acting as technological foundation for an open Internet of Things (IoT) innovation ecosystem. The basic requirements and key mechanisms for IoT devices and IoT-related information systems for publishing their presence, and be discovered by, other IoT systems based on the standardized APIs have been set up in D3.2 titled Information source publication and consumption framework. The main objective of D3.2 is to extend the discovery functionality provided by O-MI and O-DF standard with geo-location and semantic web discovery methods. This deliverable provides an overview of the framework for data communication in the form of Open API standards that are implemented by Aalto University. The main objective is to demonstrate various platform integrations with those standards. The focus will be mainly towards providing a framework in which the prototype of computing platforms with O-MI/O-DF standards are supported as and when needed by the bIoTope project. The following deliverable will also interact in future with WP4 in which the “contexts” related to human beings or physical objects will be taken into consideration.



1. Introduction

In recent years, various IoT applications and initiatives are emerging across the modern world that leverages ubiquitous connectivity and analytics, and offers tremendous capabilities for enhanced computing, device monitoring, and data management across numerous IoT platforms (e.g., transportation, energy, manufacturing, healthcare, and city service providers). IoT is intended to provide a network where information flows could easily be set up between any kinds of products, devices, users, and information systems in general. This vision is getting closer to become real due to the continuous development of new information system concepts and technologies, which have made IoT an integral part of the scientific research in academia, industry, and even government organizations. In a broader sense, the key goal of IoT is to link objects of the real world with the virtual world, thus enabling connectivity anywhere, anytime, and with anything [1, 2]. The recent study has revealed that billions of devices interact with each other by connecting to the Internet and IoT specifically has a potential to connect 28 billion objects by 2020 [3]. As this trend continues to grow, it is introducing new types of interactions between various types of things to help enterprises to enable real-time monitoring, control, and maintenance. Nonetheless, as IoT is expanded around the globe, the focus is now shifted towards new platforms and technologies which provide different mechanisms to avoid the continual emergence of vertical silos. This requires heterogeneous, disruptive, and value-added services to be produced by researchers and developers in order to enable interoperation across multiple platforms. In that case, the data generated from the overall IoT ecosystem can be siloed or piled together in a large-scale computing system, cloud, or other similar domain. The core mission of the bIoTope project is to overcome these silos by developing an ecosystem of connected services and platforms. bIoTope capabilities lay the foundation for open innovation ecosystems where companies can innovate both by the creation of new software components for IoT ecosystems, as well as create new platforms for connected smart objects with minimal investment. Figure 1 illustrates some integration platforms that are active in the IoT domain [4].

1.1. Objectives of WP3

The main objectives of WP3 is to define the overall bIoTope ecosystem architecture by providing state-of-the-art framework for information source publication and consumption developed around Open API standards including Open Messaging Interface (O-MI) and Open Data Format (O-DF) specifications [6, 7]. In addition, the ecosystem is capable to specify, implement, and make universally available mechanisms for service and information source discovery in the IoT (i.e., IaaS). The other objectives include: context-sensitive security and privacy mechanisms that enable end-users to have full control over their data and privacy, P2P paradigms for identity-based authentication, and micro-transaction mechanisms for IoT billing services based on recent developments in Block Chain technologies and networks such as Bitcoin. The achievement of these objectives is very much related to WP4, which provides knowledge and context-aware service provisioning for IoT. This “context” is related to human beings or physical objects in terms of location, situation, level of trust of the surrounding objects, etc.

1.2. Objectives in D3.5

The main objective of D3.5 is to demonstrate various platform integrations with Open API standards. The focus will be mainly towards providing a framework in which the prototype of computing platforms with O-MI/O-DF standards are supported as and when needed by bIoTope project.



1.3. Structure of the document

The rest of the document is organized as follows. Chapter 2 describes the detailed overview of reference implementation in terms of two main modules called API endpoint (O-MI node server) and user interface along with the agent based system used in the O-MI implementation. Chapter 3 demonstrates the integration of O-MI/O-DF implementation with various platforms in the form of wrappers. Chapter 4 explains FI-WARE IoT stack along with its integration with O-MI/O-DF. Finally, Chapter 5 concludes this deliverable.

Figure 1: Integration platforms active in the IoT (source: FirstMark) [4]



2. O-MI/O-DF Reference Implementation

As the standards and technology frameworks continue to grow, the focus is shifted towards a communication abstraction model that has been motivated by available resources, both in terms of documentation and reference implementation. It is imperative to have an implementation and a sandbox environment where developers, researchers, and experts perform multiple operations related to IoT devices and enables them to fully understand the standards specifications. The Open Group consortium has defined universal messaging standards named Open Messaging Interface (O-MI) and Open Data Format (O-DF) to provide peer-to-peer communication between various devices [5]. O-MI provides a way for communicating various objects with distributed information systems that consume and publish information on a real-time basis [6], whereas, O-DF is defined as a standard for representing the payload in IoT application [7]. The open reference implementation for these standards is developed at Aalto University, School of Science, Department of Computer Science and is available online at https://github.com/AaltoAsia/O-MI. This implementation allows users to create their own O-MI node and perform request/response operations to better understand the standards specifications. Currently, it has two main modules: O-MI node server (API endpoint) and web-client (user interface) as shown in Figure 2.

Figure 2: Reference implementation modules [8]

2.1. O-MI Node Server

The O-MI server is the main building block of this reference implementation, which provides all basic operations as listed in Table 1 (for more details, see [9]). It maintains a database where the information about O-DF data model, consisting of Objects and InfoItems, is stored. “Object” elements can have any number of properties, referred to as InfoItems, as well as “Object” sub-elements. The hierarchy consists of “Objects” as the top element in which other sub-elements are present. Inside each “Object” sub-element, there are further sub-objects and InfoItems as the more detailed structure in the hierarchy. A user can interact with the O-DF data structure by sending a request to the node server through HTTP POST. Currently, the server uses HTTP and web sockets as the underlying transport protocols for carrying out different operations. In many cases, the reference implementation behaves like a normal REST endpoint, except for the subscription mechanism that allows interval or event based responses to a list of subscribers. Moreover, subscribers can specify a callback address (basically a URL different from the original URL which sent the request) that will receive the messages during an active subscription session. Without the callback URL, the data can be polled using read request with the subscription ID.

https://github.com/AaltoAsia/O-MI



Table 1: Basic operations of messaging standard

Figure 3 shows the high-level architecture in which the front end contains web client through which the requests can be made. Then, there is an O-MI service which handles the database (DB) and the agents. On the backend, the agent system is integrated with the O-MI service to pull/push sensor data. The basic idea is that the server stores information (e.g. sensor data) that it serves to the clients. In our implementation, data server component together with HTTP library called Spray uses Akka Actors1 and Scala’s Futures2 for threading. The data is stored in H2 database3 (Java SQL database) tables and accessed with Slick library. Data has hierarchy information, Objects defining the “directories” and the InfoItems of an Object containing the actual data values. Hierarchy information is stored in its own table in database and sensor values are stored in another table. Moreover, there is a possibility to add agents for getting and translating the incoming sensor data into the format that is used in the data server. New Agents can be implemented in two different ways as a JVM compatible class or with any programming language using a socket interface. The agents are described in more details in Section 2.2.

Figure 3: Architectural overview of the reference implementation

1 http://doc.akka.io/docs/akka/current/scala/actors.html 2 http://docs.scala-lang.org/overviews/core/futures.html 3 http://www.h2database.com/html/main.html

Function Description

Read Read requests are used to request data or to set up subscription from O-MI node.

• One-Time Read: O-MI node will answer the request only once and immediately send

the response.

• Subscription Request: The read requests are handled at regular intervals or on event

basis in case the value or status changes for the resource subscribed to.

• Subscription with callback address: The requested data is sent to the callback address

(different from the original URL) with a specified interval.

• Subscription without callback: The data is stored on the subscribed node until the

subscription is valid. The data can then be retrieved (polled) by issuing a new read

request.

Write This request is used to send or write data to different systems including sensors and O-MI

node.

Cancel This is used to cancel a single request or a subscription

http://doc.akka.io/docs/akka/current/scala/actors.html

http://docs.scala-lang.org/overviews/core/futures.html

http://www.h2database.com/html/main.html



2.2. Agent System Interface

The agent subsystem provides a mechanism to interact programmatically with the core of an O-MI node server. In general, an agent is a separate worker thread that fetches data from specific data sources using specific protocols and transform them into objects that are understandable by the core. In other words, it can be said that the agents act as an intermediary entry between the lower layer hardware and the O-MI node. Moreover, agents act as converters to O-DF data and push-model. The current reference implementation defines two kinds of agents, external and internal, that are described in what follows.

External Agents

External agents run as independent processes and can be located either on the same JVM or different machine. The interaction between external agents and the O-MI node use a plain TCP socket for the communication. One advantage of using external agents is that they can be implemented in any language that supports a TCP/IP library. It works by creating O-DF formatted xml data gathered from sensors and sending it to the configured port via a keepalive TCP connection. The core functionality of external agents is demonstrated in Figure 4. As can be seen, an agent should open a TCP connection to the port configured in the O-MI node server. Then it can send O-DF formatted xml data through the open connection as raw UTF-8 string. Once the data is available in raw format, the agent should send new data to the server so that it follows the push-model. Connection should be kept open if the agent is running and O-MI server never sends responses that are not related to TCP. The content of O-DF data is described below:

• It can contain timestamps. If there are no timestamps the server adds them.

• It can contain many sensors.

• It should contain only one value per sensor. If sensors path doesn’t exist in the database of the server, it is created automatically.

• The data is UTF-8 encoded, otherwise according to the O-DF standard.

Figure 4: External agent architecture functionality

Internal Agents

Internal agents are actors that are instantiated by a Bootable class and are implemented using Scala actors4. It runs in the same JVM with the core server. Internal agents are extended threads that are instantiated by InternalAgentLoader (as shown in Figure 5). They are compiled to a jar file, where they can be loaded by the InternalAgentLoader. The InternalAgentLoader is an actor that loads jars from deploy directory and instantiates all of the agents listed in the application.conf file. After creating an InternalAgent, its init method is called with config string and then Thread’s start method is called that causes the process to run its method in different thread. Interrupt is used to terminate agent so it need to be handled accordingly by the agent. Any exception thrown during init or run will be reported to the InternalAgentLoader if unhandled. InternalAgentLoader will try to restart InternalAgent if the exception report was not received during init or

4 http://docs.scala-lang.org/overviews/core/actors.html

http://docs.scala-lang.org/overviews/core/actors.html



was not considered as unrecoverable or was not received too fast after the previous exception. To push some received data to the database an internal agent should call one of the static methods of the InputPusher.

Figure 5: Detailed functionality of Internal agents

2.3. O-MI Node web client

This module provides a graphical user interface for the end-users and developers in order to demonstrate the automatic creation of O-MI/O-DF messages instead of manually writing XML and HTTP queries. The web client can be accessed at https://otaniemi3d.cs.hut.fi/omi/node/. Figure 6 shows the starting page when the link is opened.

Figure 6: Starting page of O-MI reference implementation

On the starting page, the user will find three different links related to the O-MI node service:

1. The first link shows the data discovery in terms of the root of the hierarchy in which you can request

Objects, InfoItems and their values through HTTP GET request. The request can be made by using

existing path of the O-DF xml.

2. The second link provides the real User Interface (UI) in which the user can send O-MI requests and

check responses.

3. The third link contains the example implementation details of all the requests with their possible

responses.

https://otaniemi3d.cs.hut.fi/omi/node/



This section is more focused on the second link that has a UI for users and developers. As can be seen in

Figure 7, there are five panels in the UI as described in what follows.

1. O-DF structure: This panel contains the object hierarchy. Through this panel, the users can choose

different item(s) they are interested in by just clicking on them. Initially, the main interaction

happens by clicking on the Read All button which causes the web client to forward a request to the

server for retrieving all objects. As an example, it can be seen in Figure 7 that there is a top element

called “Objects”, which can have an arbitrary number of sub-objects and InfoItems. Inside this

parent object, the sub-object called “SmartHouse” is selected along with an InfoItem “FrontDoor”.

Once, the interested items have been selected, the web client then translates it into the

corresponding XML request along with all necessary parameters and the selected type of query. This

query is chosen from the next panel.

2. O-MI Request: This panel contains O-MI request types. For making a query regarding the specific O-

DF structure, it provides read, write, and cancel requests. In our example scenario (see Figure 7), it is

a one-time read request.

3. Required Parameters: This panel gives additional functionality of selecting other parameters along

with some optional values. This panel is expanded in Figure 8. The TTL parameter specified the time

for which a request remains valid (time for processing and reply). The Interval, requestID, and

callback URL parameters are used only for subscription. In addition, it is also possible to specify the

newest or oldest values or specify particular timeframe from begin to end in order to do specific

queries.

4. Sending Request: This panel shows the XML formatted O-DF structure of the Objects and InfoItems,

which the users are interested to query. As can be seen in figure, the structure has the selected

objects with the required parameters. It can then be queried by pressing the send button.

5. Response: Once the request has been sent, the user can see the response in another O-DF

formatted structure in this panel. For our example, it is desired to check the FrontDoor value of the

SmartHouse object. This value is returned with proper format in this panel.



Figure 7: An example of O-MI web client interface showing five different panels

Figure 8: The extended version of required and optional parameters



3. O-MI/O-DF Wrappers Integration

3.1. MIST to HTTP/Websocket wrapper

IoT requires a trusted identity service provider for “Things”. New requirements must be posted towards classic Identity Management (IdM) extending the authentication methods, allowing identity imprinting, trust negotiation, and trust revocation. For satisfying these requirements, ControlThings proposes a generic purpose communication stack as a trust-based network solution called Mist. Mist targets system developers and device manufacturers by providing an effortless way to incorporate a sophisticated IoT communication into their products and solutions.

The wrapper between Mist and other O-MI/O-DF nodes which are communicating with HTTP or Websocket is required due to the identity based communication layer. The O-MI/O-DF level of the communication is in practice completely aligned with the Mist native communication, and it could easily be serialized natively with 100% compatibility. However, interoperability also requires mutual supported transport protocols, and HTTP and Websocket are not closely related to the identity-based communication provided by Mist.

The Mist to HTTP/WS wrapper is a Mist node which is capable of describing the own perspective of the identity based network to other O-MI nodes which are not capable of identity based communication themselves.

The identity based network is decentralised, and thereby no single node is capable of describing the whole network of nodes. The Mist to HTTP/WS wrapper can be seen as a two-way gateway for the identity based trust network, for one single perspective of the network: the perspective of the wrappers own identity.

Within the identity based network, information can be exposed and access control can be provided for HTTP/WS based O-MI / O-DF communication by sharing access to the identity of the wrapper node, as described in Figure 10.

Figure 9: An example of the perspective a Mist to HTTP/WS wrapper can provide. The network contains a lot more identities and

systems, but the exposed information and control access corresponds to the amount that has been shared with this particular

Mist to HTTP/WS wrapper node.



3.1.1. Mist wrapper to Websocket based O-MI/O-DF server

ControlThings has implemented a wrapper for accessing the Mist network using Websocket based O-MI nodes. The Websocket technology is client / server based, while Mist is purely peer-to-peer. This wrapper is a Websocket client, which is capable of connecting to an instance of the Aalto reference implementation of the O-MI/O-DF Websocket based server. The client provides two-way event based communication, but the connection needs to be established in the direction from the client (wrapper) towards the O-MI Websocket server (Aalto reference implementation).

The Mist-wrapper is built upon a sub-wrapper which converts O-MI/O-DF to Json. ControlThings has published this sub-wrapper as open source, and it can be downloaded, installed and launched with a few simple steps, by following the instructions and download links found at https://github.com/ControlThings/omi-odf-nodejs.

Figure 10: The trust relations are formed between identities. If the vessel is hosting the Mist HTTP wrapper it will only expose the

lighthouse for other O-MI/O-DF HTTP nodes, since that’s the only identity relation the vessel has.

3.2. 1-wire wrapper

Aalto University has implemented a 1-wire wrapper demonstrator which involves the integration of multiple 1-wire sensors with the O-MI/O-DF reference implementation. Figure 11 demonstrates the configuration in which the Linux gateway (Linux OpenWRT5) is equipped with O-MI wrapper. The instructions for configuring node server is listed at https://github.com/AaltoAsia/O-MI. As can be seen, there are four 1-wire6 sensors connected to the USB converter that is further attached to the gateway containing O-MI/O-DF wrapper. This 1-wire sensor is basically used to measure temperature using a DS-2438Z with an operating range of -40°C to +85°C. It also measures relative humidity using a Honeywell part, HIH-4000.

5 https://openwrt.org/ 6 https://www.ibuttonlink.com/products/ms-th

https://github.com/ControlThings/omi-odf-nodejs

https://github.com/AaltoAsia/O-MI

https://openwrt.org/

https://www.ibuttonlink.com/products/ms-th



Figure 11: 1-wire sensor example with the home gateway

Once the environment has been setup, the sensor values are sent to the sandbox by creating O-MI write request. The object hierarchy structure is demonstrated in Figure 12 in which “KarysHouse” is the top object. All four sensors are listed inside the sub-object “BasementRoom1” of the parent object. This object structure should be defined previously by running a script that creates O-DF tree (as shown in Figure 13). Another script has been used to first create the hierarchy with the given variables (mentioned in Figure 13) and then create an O-MI write message. Moreover, certificates are also used at the gateway level to identify and authenticate the user so that no other anonymous user can send write request. Write access has been granted only to the intended user who has a certificate, however, read request can be done by anyone.

Figure 12: O-MI/O-DF reference implementation sandbox which shows the 1-wire sensors information



Figure 13: A script to create O-DF tree structure using named variables

3.3. Warp10 wrapper

The Warp 107 platform is developed by CityzenData to collect, store, and manipulate sensor data. Sensor data is ingested as sequences of measurements (also called time series). In Warp 10 the data points are stored in a time series with possibility to augment the data with spatial metadata. In the Warp 10 wrapper, we use this platform as a database for the reference implementation. By default, the O-MI/O-DF reference implementation uses H2 database8 and the communication with this database is done with Slick query and access library. Moreover, it is possible to change the database driver and use another relational database by changing the database driver from the config file. It is also possible to override the entire Database implementation as is done in Warp10-version of the reference implementation.

Furthermore, there are two different implementations for database interface: the default Slick database and Warp10 database implementation. In the custom database implementation, an interface needs to be implemented either in Java or Scala. This interface has three methods: (i) getNBetween for read messages, (ii) writeMany for write messages, and (iii) remove for removing data from the database.

The Warp10 wrapper is responsible for converting parsed O-MI/O-DF data to format suitable with the Warp 10 Platform. Detailed information about differences with the standard version of reference implementation can be found in the documentation file at https://github.com/AaltoAsia/O-MI/blob/warp10integration/warp10-documentation.md. Figure 14 demonstrates the functionality of this wrapper which acts as a middle layer between O-MI node server and the separate database and provide communication between them.

7 http://www.warp10.io/ 8 http://www.h2database.com/html/main.html

https://github.com/AaltoAsia/O-MI/blob/warp10integration/warp10-documentation.md

https://github.com/AaltoAsia/O-MI/blob/warp10integration/warp10-documentation.md

http://www.warp10.io/

http://www.h2database.com/html/main.html



Figure 14: Warp10 database is running separately and the wrapper connects this database to O-MI node server

Figure 15 and Figure 16 show the O-MI write and read messages that is done through the wrapper. The write message is converted into the specific format and then stored in a database. In case of a read, WarpScript data manipulation environment is used which allows the retrieval and analysis of data stored in the Warp 10 storage platform.

Figure 15: An example of O-MI write message that is converted into warp10 supported format and send to the database for

storage

Figure 16: An example of O-MI read message that request the data with WarpScript data manipulation environment and receives

a response message



3.4. IoTBnB wrapper

bIoTope is intended to make a wide range of IoT services talk to and understand each other, across multiple platforms and domains. This implies to have a universal way to both:

• describe and share/publish IoT data and/or service9,

• discover relevant data and/or service sources depending on the stakeholder’s needs, context, role, location, activity, or situation.

To achieve the above features, an IoT service marketplace (i.e., acting as the service registry/repository) is currently being developed in bIoTope. This marketplace, referred to as IoTBnB (standing for “IoT service puBlication aNd Billing”), aims to allow IoT stakeholders (e.g., companies, institutions, governments and citizens) to easily and securely publish and/or consume IoT data and services, while having the necessary functionalities to manage (i) multimodal search and discovery of these data/services; (ii) service quality/reputation assessment; and (iii) the payment of one or more IoT data/services. Such functionalities are illustrated through Figure 17 in a visual and human readable manner. Let us note that the storage and indexing of IoT data/service descriptions – collected from different O-MI gateways – is handled using the OpenDataSoft SaaS platform. The objective of the IoTBnB wrapper is to fulfill the above-mentioned functionalities in a machine-understandable manner, which implies to design and develop the necessary APIs. The minimal set of APIs are summarized and detailed in the following table.

Table 2: Minimal set of APIs to enable search & discovery of IoT data/services in the bIoTope ecosystem

API Input Output Description

getAllServices()

- List of Service(s)

Enable marketplace stakeholders to access the whole set of services available in the service registry/repository.

searchServices(“see

inputs”)

Location, Price, Reputation, Type

List of Service(s) including complementary information

Enable marketplace stakeholders to search for existing IoT data/services depending on their needs (e.g., location-based, price-based…).

addServicesToCart(“see

inputs”) Services Acknowledgment

Enable marketplace stakeholders to add one or more services to their carts (before proceeding to the final payment, if payment is required).

getServiceTokens(“see

inputs”) - List of Tokens

Enable marketplace stakeholders to retrieve access information (via a token) to access data/services purchased beforehand.

buyServices(“see

inputs”) OMI_Service_Requests

Enable marketplace stakeholders to buy the selected services (along with the specification of the expected O-MI request10).

9 A distinction can be made between IoT data and IoT services: “IoT data” refers to IoT data streams coming from sensors or other

systems generating or holding data (databases, files), while “IoT services” refers to the call of a web service that takes, as inputs, one or more parameters and may imply a processing stage to return the expected result. 10 Various kind of requests can be made such as Read (including subscription mechanisms), Write, Cancel, etc.



Figure 17: Illustration of IoTBnB features (to securely publish and/or consume IoT data/services) and how IoTBnB is going to be

“wrapped” to expose the marketplace APIs based open IoT interfaces

Since a core requirement of the bIoTope ecosystem is to make all APIs compliant with the O-MI/O-DF standards, the set of APIs listed in Table 2 is going to be specified and implemented in IoTBnB based on those standards. To do so, we rely on the “call” method that is intended to be supported in the next release of the O-MI/O-DF standards. Figure 18 and Figure 19 provide an example of request/response messages when calling one of the marketplace APIs, namely getAllServices(). Figure 18 highlights that the function is called without passing any input parameter. Figure 19 shows that two IoT data/services are currently available in the whole data catalog of IoTBnB, while providing some information about the corresponding price, reputation, type, etc. The remaining APIs will be developed in a similar manner.

Figure 18: O-MI/O-DF request message when calling the “getAllServices” function



Figure 19: O-MI/O-DF response message returned by the “getAllServices” function (assuming that only 2 services are included in

the IoTBnB service catalog)

3.5. OpenIoT Platform Integration

OpenIoT11 is a part of the bIoTope Project. It is an open source middleware for getting information from sensor clouds, without having to worry about what exact sensors are used. It provides support of cloud-based and utility-based sensing services enabling the concept of “Sensing-as-a-Service (SaaS)”, via an adaptive middleware framework for deploying and providing services in the cloud environments. Research into providing open standards for SaaS will be vital in stimulating economic growth in sectors such as public health, scientific research, information technology, etc. The OpenIoT platform integration with O-MI/O-DF standards is demonstrated by conceiving the following use case:

A user wants to be notified of their exposure to airborne allergens in their vicinity so they can plan to minimise their exposure. They log into OpenIoT and select a predefined application that renders a ‘point map’ based on available air-quality sensor information in the cloud. Combining their GPS coordinates, specific air contaminant, and a selectable radius they request a map with minimal and acceptable risk of exposure. Each subsequent refresh of the map based on their travels repositions the search area and updates the map of readings with real-time air quality data. Push notifications could warn the user that levels have exceed a threshold in their searched areas.

The main objective of explaining this system is to investigate the synergistic opportunities provided by implementing O-MI/O-DF standards and their interoperation with other IoT systems. This use case is chosen due to the recent media coverage of deaths resulting from “Asthma Storms” that illustrate the lifesaving potential of shared air quality information and user friendly decision-making systems. The proposed architecture for the platform integration is shown in Figure 20. The goals of this system are:

• Provide a mobile application to allow users to connect to OpenIoT and execute a dynamic selection of existing SPARQL queries by customizing a set of parameters.

• Validate and display the generated SPARQL query.

• Display the results of those queries.

11 http://www.openiot.eu/

http://www.openiot.eu/



Figure 20: Architectural overview of the system illustrating platform integration

Figure 21 shows the system architecture in which two additional modules are implemented: mobile.appl (mobile application) and mobile.core (core server). As can be seen, the step-by-step procedure is also illustrated with numbers from 1 to 6. At first, the mobile application searches the specific location. Then, it sends the O-MI get request including search query string to the server. The server converts the request to SPARQL query with RDF4J format and forwards it to the OpenIoT platform. This platform returns RDF data which then sends to the mobile application as O-MI/O-DF payload. At the end, the application displays the result markers of air quality information with the help of Google Maps. Figure 22 demonstrates this system in which the user has an application called mIOTIDE to display the location of different allergies information. Through this interface, location-based cloud service polling can be done and the results are returned after each refresh interval. In the right-side picture, selectable allergens are displayed and roaming queries track your location and refresh the query parameters keeping up with changes to context.



Figure 21: System architecture in which there are two proposed components named mobile.core and mobile.appl

Figure 22: The mobile application interface and the result of bad air quality location after performing search and query

4. FI-WARE IoT Stack

FIWARE IoT Stack [10] allows to connect devices and receive data, integrating all device protocols and connectivity methods, understanding and interpreting relevant information. It isolates data processing and application service layers from the device and network complexity, in terms of access, security, and network protocols.

These are the main benefits of solutions powered by the FIWARE IoT Stack:

• Simple sensor data integration

• Device-independent APIs for quick app development & lock-in prevention

• Modular

• Scalable. High available

• Open & standards based. FIWARE compliant



FI-WARE Components

FIWARE IoT Stack is based on the following FIWARE components in order to provide its functionality:

• IoTAgents (IoTA)

• Context Broker (Orion)

• Short Term Historic (STH)

• Connector Framework (Cygnus)

• Security Components: Identity Management (IDM), Policy Enforcement Point (PEP) and Access Control (AC). The platform does not use the FIWARE GEri for these components, but alternative GEi conforming with the same GE specifications.

In addition, the platform includes the following additional components, which are not part of FIWARE (but still open source): (i) Complex Event Processing (Perseo) component that integrates with the platform using FIWARE-based APIs (in particular, using NGSI), (ii) IoT Orchestrator.

Figure 23: The possible components of FI-WARE IoT stack

4.1. Device integration with FI-WARE

To integrate devices into FIWARE ecosystem, we choose several components of FIWARE IoT Stack:

• Orion Context Broker

• IoTAgent-UL

• Cygnus with MongoSINK

The architecture for the device integration is shown in Figure 24. For sending data into IoTAgent we use device backend written in Python via Ultralight 2.0 protocol. For data representation, we use Freeboard dashboard with Orion DataSource plugin. It allows pulling information from Orion Context Broker and showing it on gauge or chart. ThingProxy is used for cross-origin queries, as Orion disallow this one. For data flows orchestration, we use Node-Red platform with MongoDB plugin. For quick deployment, every component is packed into Docker-containers.

Orion Context Broker

We use official Docker image of FIWARE Orion Context Broker. It uses MongoDB storage, which also loaded from official Docker repository. For data persistence, we use Docker Volumes. After a few seconds, we should have your Context Broker running and listening on port 1026.



mongodb:

image: 'mongo:2.6'

restart: always

volumes:

- "./db/mongo/:/data/db"

orion:

image: fiware/orion

restart: always

links:

- mongodb

ports:

- "1026:1026"

command: -dbhost mongodb

For the device library, FIGWAY is used as it is an open source tool to work with FIWARE Orion ContextBroker and/or FIWARE IDAS.4.x.

IoTAgent-UL

This Internet of Things Agent is a bridge that can be used to communicate devices using the Ultralight 2.0 protocol and NGSI Context Brokers. Ultralight 2.0 is a lightweight text based protocol aimed to constrained devices and communications where the bandwidth and device memory may be limited resources.



Device(https://github.com/itmo-

swm/fiware-python-client)

IoTAgent-UL(https://github.com/itmo-

swm/fiware-iotagent-ul)

Orion

Context-Broker(https://github.com/itmo-

swm/fiware-orion)

Cygnus

MongoSINK(https://github.com/itmo-

swm/fiware-cygnus)

MongoDB

Ultralight 2.0

NGSI

NGSI

Node-RED(https://github.com/itmo-

swm/node-red)

IoTAgent-OMI

NGSI

Device

OMI/ODF

ThingProxy(https://github.com/itmo-

swm/thingproxy)

FreeBoard(https://github.com/itmo-

swm/freeboard)

NGSI

Figure 24: Device integration architecture

Cygnus MongoSINK

Cygnus is a connector in charge of persisting certain sources of data in certain configured third-party storages, creating a historical view of such data. We use MongoDB storage for persistence and integration with Node-Red. For sending information from Orion Context Broker we use subscription via subscribeContext request. For example, for Entity with id “TempTest1”, type “thing” and attribute “temperature” we can use this query.



(curl localhost:1026/v1/subscribeContext -s -S --header 'Content-Type: application/json' -

-header 'Accept: application/json' --header 'Fiware-Service: my_test' --header 'Fiware-

ServicePath: /' -d @- | python -mjson.tool) <<EOF

{

"entities": [

{

"type": "thing",

"isPattern": "false",

"id": "TempTest1"

}

],

"attributes": [

"temperature"

],

"reference": "http://localhost:5050/notify",

"duration": "P1M",

"notifyConditions": [

{

"type": "ONCHANGE",

"condValues": [

"temperature"

]

}

],

"throttling": "PT1S"

}

EOF

When temperature is changing, Orion send notification to http://localhost:5050/notify address, where Cygnus is waiting for connections. More information can be found at https://github.com/itmo-swm

Figure 25: Freeboard interface example

Node-Red

Node-RED provides a browser-based flow editor, which can be used to create JavaScript functions. Elements of applications can be saved or shared for re-use. The runtime is built on Node.js. The flows created in Node-RED are stored using JSON. We get information from Cygnus MongoDB and can integrate it with other services.

https://github.com/itmo-swm



Figure 26: Node-Red browser based editor for creating JavaScript functions

5. Conclusion

As IoT applications and initiatives are emerging across the modern world, the focus is now shifted towards new platforms and technologies which provide different mechanisms to avoid the continual emergence of vertical silos. The core mission of the bIoTope project is to overcome these silos by developing an ecosystem of connected services and platforms. This requires open messaging standards like O-MI/O-DF to perform information source publication and consumption between IoT devices in the bIoTope ecosystem. This deliverable has been focused on describing the standardised APIs along with the agent system interface and the user interface in order to do real-time interaction with various devices and platforms. The document also demonstrated the integration of O-MI/O-DF standards with numerous services and platforms including MIST, Warp10, IoTBnB, OpenIoT, and FI-WARE.



6. References

[1] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A survey,” Computer Networks, vol. 54, no. 15, pp. 2787–2805, 2010. [Online]. Available: http://dx.doi.org/10.1016/j.comnet.2010.05.010

[2] S. Kubler, K. Främling, and A. Buda, “A standardized approach to deal with firewall and mobility policies in the IoT,” Pervasive and Mobile Computing, vol. 20, pp. 100–114, 2015. Available: http://dx.doi.org/10.1016/j.pmcj.2014.09.005

[3] S. Jankowski, J. Covello, H. Bellini, J. Ritchie, and D. Costa, “The Internet of Things: Making sense of the next mega-trend,” Goldman Sachs Global Investment Research. http://www.goldmansachs.com/ourthinking/ outlook/internet-of-things/iot-report.pdf, 2014, [Online; accessed 17-May-2017].

[4] James Senior, “Choosing an IoT Platform Provider,” 2015. http://www.jamessenior.com/2015/05/21/choosing-an-iot-platform-provider/

[5] The Open Group, “An introduction to IoT and lifecycle management,” White paper of The Open Group IoT Work Group, 2016.

[6] “Open Messaging Interface (O-MI),” an open group IoT standard. http://www.opengroup.org/iot/omi/index.htm, 2014, [Online; accessed 17-May-2017].

[7] “Open Data Format (O-DF),” an open group IoT standard. http://www.opengroup.org/iot/odf/index.htm, 2014, [Online; accessed 17-May-2017].

[8] D3.3 Context-Sensitive Security, Privacy Management, and Adaptation Framework, bIoTope deliverable, 2017

[9] The Open Group, Messaging Objects, http://www.opengroup.org/iot/omi/p3.htm#X_Messaging_Objects

[10] FI-WARE IoT Stack, https://fiware-iot-stack.readthedocs.io/en/latest/, 2017

http://dx.doi.org/10.1016/j.comnet.2010.05.010

http://dx.doi.org/10.1016/j.pmcj.2014.09.005

http://www.goldmansachs.com/ourthinking/

http://www.jamessenior.com/2015/05/21/choosing-an-iot-platform-provider/

http://www.jamessenior.com/2015/05/21/choosing-an-iot-platform-provider/

http://www.opengroup.org/iot/omi/index.htm

http://www.opengroup.org/iot/odf/index.htm

http://www.opengroup.org/iot/omi/p3.htm#X_Messaging_Objects

https://fiware-iot-stack.readthedocs.io/en/latest/

Documents

DELIVERABLE D3.5 Prototype of Platform Integration using ...api.ning.com/files/2lCHlA6Jtw4Kq20Lwk3UbPW23M3QRW1... · FI-WARE IoT Stack ... Introduction In recent years, various IoT