deliverable 2.1: analysis of technology readiness - big...

SUMMARY OF THE ANALYSIS OF TECHNOLOGY READINESS OF TECHNOLOGIES AND

PLATFORMS FOR THE INTERNET OF THINGS D2.1

© 2016 1

Deliverable 2.1:

Analysis of Technology Readiness

This project has received funding from the European Union’s Horizon 2020 research

and innovation programme under grant agreement No 688038.



© 2016 2

DOCUMENT HISTORY

Responsible Person and Affiliation Yong Wang (TU Clausthal)

Contributor (s): Abdelmajid Khelil (Bosch SI), Arne Broe-

ring (Siemens), Darko Anicic (Sie-

mens), Dirk Herrling (TU Clausthal), Jan

Zibuschka (Bosch CR), Jansen Lim (Bosch

SI), Karina Rehfeldt (TU Clausthal), Stefan

Schmid (Bosch CR), Sebastian Kaebisch

(Siemens), Thomas Schöftner

(Atos), Victor Charpenay (Siemens), Yong

Wang (TU Clausthal).

Reviewer(s): Arne Broering (Siemens)

Hans-Peter Schwefel (AAU)

Lars Mikkelsen (AAU)

Martin Serrano (NUIG)

Stefan Schmid (Bosch CR)

Due Date / Delivery Date 31.05.2016

State Final

Version 1.0

Confidentiality Public



© 2016 3

VERSION CONTROL

Version Description of Changes Date of Resolution

0.1 Initial Version 02.05.2016

0.11 Partners Contributions 20.05.2016

0.2 Preview Version 24.05.2016

0.21 Technical & Quality 29.05.2016

0.3 Final Draft 30.05.2016

1.0 Final 31.05.2016



© 2016 4

Executive Summary

This document analyses relevant State-of-the-Art IoT platforms and technolo-

gies for the BIG IoT project, focusing particularly on the Technology Readiness Level

(TRL) of the evaluated platforms, frameworks, systems, and technologies and their

suitability in the context of the BIG IoT project. The document provides the results of

an analysis and comparison of the interoperability capabilities of existing IoT Plat-

forms, and evaluates a broad set of potentially relevant technologies, frameworks

and solutions with respect to their readiness for building the envisioned BIG IoT Eco-

system. The document can be used as the baseline for the technical work in future

tasks of the project.



© 2016 5

TABLE OF CONTENTS

Executive Summary _____________________________________________________ 4

1. Introduction _______________________________________________________ 7

2. Methodology ______________________________________________________ 9

2.1. Process of Analysis ___________________________________________________ 9

2.2. Questionnaire Design ________________________________________________ 10

2.3. Structure of this Deliverable __________________________________________ 11

3. Concepts Relevant for IoT Platforms __________________________________ 13

3.1. Communication_____________________________________________________ 13

3.2. Semantic Descriptions _______________________________________________ 19

3.3. Service Discovery ___________________________________________________ 21

3.4. Service Orchestration ________________________________________________ 22

3.5. Interoperability _____________________________________________________ 23

3.6. Deployment _______________________________________________________ 24

3.7. Persistency ________________________________________________________ 25

3.8. Security ___________________________________________________________ 27

3.9. Marketplace _______________________________________________________ 28

4. IoT Platforms _____________________________________________________ 30

4.1. IoT Standard Frameworks ____________________________________________ 31

4.2. BEZIRK ____________________________________________________________ 35

4.3. Bosch Smart City Platform (SCP) _______________________________________ 36

4.4. CSI Piemonte Smartdata Platform ______________________________________ 37

4.5. FIWARE ___________________________________________________________ 38

4.6. OpenIoT ___________________________________________________________ 39

4.7. Vodafone IoT Platform _______________________________________________ 40

4.8. WorldSensing ______________________________________________________ 41

4.9. TIC Platform _______________________________________________________ 42

4.10. IFTTT ___________________________________________________________ 43

4.11. Wubby__________________________________________________________ 44

4.12. Xively___________________________________________________________ 45

4.13. Comparison of IoT Platforms ____________________________________ 46

5. Results and Evaluation______________________________________________ 49

6. Acknowledgements ________________________________________________ 53

7. References _______________________________________________________ 54

8. Annex ___________________________________________________________ 56



© 2016 6

LIST OF FIGURES

FIGURE 1: OVERVIEW OF BIG IOT APPROACH. ............................................................................................ 7

LIST OF TABLES

TABLE 1 : COMPARISON OF IOT STANDARD FRAMEWORKS ......................................................................... 33 TABLE 2 : COMPARISON OF GENERIC INFORMATION ................................................................................... 46 TABLE 3 : COMPARISON OF INTEROPERABILITY OF IOT PLATFORMS ............................................................ 47 TABLE 4 : SOLUTION/TECHNOLOGIES OF IOT PLATFORMS ........................................................................... 51



© 2016 7

1. Introduction

The BIG IoT (“Bridging the Interoperability Gap of the Internet of Things”) is a collab-

orative European H2020 funded project that aims at enabling the emergence of

cross-standard, cross-platform, and cross-domain IoT services and applications to-

wards enabling an IoT ecosystem. BIG-IoT is part of the work programme ICT-30-

2015 ‘Internet of Things and Platforms for Connected Smart Objects’. The main goal

of the BIG IoT project is to introduce syntactic and semantic interoperability among

vertically integrated IoT platforms and to create open marketplaces for IoT services

and applications. To achieve this goal, BIG IoT consortium will define a generic API

(Application Programming Interface), which will offer a functionally rich but at the

same time easy way to discover, access, control, manage, and secure smart objects

data and functions, as well as services. The BIG IoT API will firstly be implemented

by the eight smart object platforms that are represented in this project, each one by

the corresponding project partners in the consortium that will start the BIG-IoT eco-

system. Once the ecosystem is established, other platforms are expected to imple-

ment the API as well. This overall approach is indicated in the Figure 1 below.

Figure 1: Overview of BIG IoT approach.

(Icons made by Freepik from www.flaticon.com.)

http://www.flaticon.com/



© 2016 8

The BIG IoT consortium joins large companies (ATOS, BOSCH, SEAT, SIE-

MENS, VODAFONE) with experts from SMEs, research institutes and recognized

universities (AAU, ECONAIS, NUIG, TUC, UPC) which will implement the BIG IoT

API and include stakeholders from public bodies (CSI, VMZ, WAG) that will drive the

efforts of defining it in a community process, contributing it to standardization activi-

ties, and promoting its usage among the partners and create the BIG-IoT ecosystem.

In order to be able to implement this approach, it is important to study and eval-

uate current IoT platforms, especially those technologies required to realize the de-

sired functionalities of the BIG IoT API and the marketplace. This deliverable pre-

sents a condensed overview and makes a comprehensive technology study. It fo-

cuses on the topics: persistency, communication, interoperability, identity manage-

ment, marketplace, semantic descriptions, service discovery and orchestration, de-

ployment, and data streaming and processing. Additionally this deliverable present

the results of a comprehensive study about relevant IoT platforms with regard to their

licensing model, common domain, and interoperability measures. The Technology

Readiness Levels (TRL) as defined by the EC [1] is used to enable comparison of the

maturity of the analysed technologies in this document.

In this document we focus on dedicated IoT platforms, which are consider es-

pecially relevant for the realization of the BIG IoT project, and due to the fast evolu-

tion of the IoT area and the specified time and resources to perform the analysis pre-

sented in this document, we are aware that new IoT technologies are emerging and

not all of them that are potentially usable within the project could be included. How-

ever the included ones are a good representation of the current IoT technology mar-

ket.



© 2016 9

2. Methodology

This section introduces the methodology that was used to create this document.

It presents and explains the processes used to identify topics and aggregate infor-

mation about them, the collaboration platform used to collect this information and the

relationship between this platform and the deliverable at hand.

2.1. Process of Analysis

The analysis of the selected IoT technologies was carried out in four steps.

First step, due to the high number of available IoT platforms and technologies of

interest it was decided to involve and interview specialists from the various partners

of the BIG IoT consortium and capture the most relevant ones. To achieve compara-

ble results and common types of meta information (e.g., licensing model or installa-

tion base), it was decided to design two questionnaires: One for IoT platforms and a

second one for technologies and solutions for concepts (e.g., persistency or commu-

nication) usually present in IoT platforms.

In the second step, a comprehensive list of IoT platforms and concepts relevant

for IoT platforms was collected. Its basis was formed by those mentioned in the origi-

nal BIG IoT project proposal. The list was extended by further platforms and technol-

ogies in three consecutive brainstorming and consolidation rounds that were carried

out by the task contributors of Task 2.1.

In the third step, specialists for the identified topics within the BIG IoT consorti-

um were identified and asked to contribute. After they agreed to support the task,

they were presented the questionnaire. The questionnaires were answered by them

directly in a Wiki as collaboration tool. The structure of the Wiki and its relation to this

deliverable will be described later in this document.

The fourth, last step, the questionnaires and derived results on a more abstract

level were examined. To clarify further details, the consortium members dedicated to

this activity had personal discussions with the specialists that answered the ques-

tionnaires. The findings and gathered information (over 400 pages, see Annex of this

document) were then generalized and abstracted in the aim to condense the material

into a compact and comprehensible report, which this document aims to be.



© 2016 10

2.2. Questionnaire Design

Two tabular questionnaires were created, one for concepts, commonly found in

IoT platforms (which summarize standards, technical solutions and readily available

building blocks), and a second one for existing IoT platforms. Though tailored to the

specific needs of these two fields, the structure of the questionnaires is comparable:

They both share the sections about metadata (such as: name, main contributor or

sponsor, or URL), general information (e.g., Technology Readiness Level, licensing

model, or installation base), and supported functionalities. The latter one differs

strongly for IoT platforms and concepts, as IoT platforms usually support a multitude

of concepts and, as such, the level of detail of the questions in this section is quite

different. The functionalities asked for have been previously identified during the BIG

IoT proposal phase as highly relevant for IoT platforms. Those key IoT functionalities

are (see also Figure 1):

Identity & Lifecycle management – indicates whether registration, deregistra-

tion, and update of smart objects as well as the provisioning of identifiers for new

smart objects is supported.

Discovery – indicates if search and finding of smart objects according to user

defined search criteria, such as device type, communication protocol, or security pro-

tocols is enabled.

Access (pull) of measured data – the retrieval of (measured) data according

to the “pull” communication paradigm is enabled.

Access (pull) of object metadata – the retrieval of metadata according to the

“pull” communication paradigm is enabled.

Tasking – client is enabled to forward a task definition (or control command) to

smart objects. E.g., a task can change a sampling rate of a sensor, open/close a

valve, or lift a robot arm.

Messaging (Pub/Sub) Services – a client can subscribe for data streams from

smart objects.

Event/data processing – the processing of data streams from smart objects is

supported. It enables a client to receive processed data and/or events created by

smart objects.



© 2016 11

Vocabulary management / Semantic concepts – the management of seman-

tic descriptions of concepts such as smart object properties and/or values for such

properties is enabled. E.g., this could be a management of a set of tags, a controlled

vocabulary, or ontologies.

Security management – the secure access and usage of smart objects and

their data is supported.

Privacy management – the transparency and anonymization functions to pro-

tect privacy of the users are considered.

Charging and Billing – the billing for offered functionalities (e.g., for creating a

user profile or for accessing data streams) is enabled.

Reputation Management – a mechanism to assess reputation of users, smart

object, or data streams is supported. E.g., reputation could be determined through a

review process performed by users.

SLA / QoS Management – service level agreements (SLA) and/or quality of

service (QoS) parameters are defined.

The questionnaire for IoT platforms contains a fourth section, which asks specif-

ic questions about the measures taken to achieve interoperability with other IoT plat-

forms.

2.3. Structure of this Deliverable

To enable concurrent work of the numerous contributors and specialists that

worked on this deliverable a Wiki space to facilitate the collection of information was

used. A central, portal-like page was created. On this central page the questionnaires

were designed and improved and then the topic collection created. The Wiki is con-

sidered as a “living document” for the rest of the project duration with this deliverable

as a snapshot of the current state of our knowledge. As the project progresses the

pages will be updated and add further technologies. The current state of this large

number of analysed technologies and the resulting questionnaires can be sound in

the Annex of this document.

The rest of this document is structured as follows:

Section 3 presents and discusses the findings and analysis for the different concepts

relevant for IoT platforms. In Section 4, IoT platforms are analysed and the results of



© 2016 12

the questionnaires regarding IoT platforms, together with the analysis of the Task 2.1

contributor team can be found. The section is concluded by two tables, offering an

overview of IoT platforms, simplified to the bare minimum. Section 5 concludes this

deliverable by putting the concepts and IoT platforms into relation: Which IoT plat-

forms realize which concepts, and (if known), which particular solutions are used?

The deliverable contains a section for most relevant references and contains an An-

nex as separate document that complement this document.



© 2016 13

3. Concepts Relevant for IoT Platforms

In this section, the concepts and the corresponding technologies / solutions,

relevant for BIG IoT are introduced and discussed. Those concepts cover most areas

of the functionalities envisioned for BIG IoT, including communication, semantic de-

scription, service discovery, service orchestration, interoperability, deployment, per-

sistency, security, identity management, as well as marketplace features such as

billing. The results, presented in this chapter can be used to identify possible tech-

nologies for the use in BIG IoT. To help assessing suitable technologies, relevant

information, such as Technology Readiness Levels or licensing models are given.

In the following, each concept in a separate subsection is presented. Each sub-

section follows the same structure: First, a general overview of the concept is given.

This is followed by a listing and short discussion of existing approaches and solutions

that presents the most important commonalities and differences, as well as the pos-

sible applications in BIG IoT.

3.1. Communication

3.1.1. Concept Overview

Communication can be defined as the act of transferring information from one

entity to another by complying with mutually understood rules. The sender encodes

information being conveyed and the receiver decodes the message to understand its

meaning. The form of the encoded information is typically referred to as the data for-

mat. The data format also covers the rules for the data encoding and decoding, and

their unambiguity prevent misinterpretation of data (misunderstandings).

In contrast to the data formats explained in the previous paragraph, communi-

cation paradigms define in which way sender and receiver(s) exchange information.

Examples range from request/response message exchange (an entity sends a re-

quest messages and receives the response) to publish-subscribe mechanisms (an

entity subscribes to types of data, a sender produces, and receives them whenever

new ones are available).

3.1.2. Approaches and Solutions

The interface model and interaction model of BIG IoT should be mainly based

on established standard technologies (e.g., from W3C and IETF), so that they enable



© 2016 14

to achieve a high degree of acceptance. In this subsection we will give an overview

of those technologies. Firstly, we introduce two common data formats. We begin with

generic technologies to serialize arbitrary data and proceed to approaches that are

mainly used to serialize semantic data based on the Resource Description Frame-

work (RDF) [16][17] model. After that we show several communication paradigms of

communication.

Data Formats

Extensible Markup Language (XML) [9] is a very prominent data format that is

applied in many domains, such as different kinds of communication protocols, User

interface definitions or graphics. One of the strengths of XML is the XML schema

language that allows the definition of a meta-model for the stored data. This enables

to model data structures in a very precise manner and enables the validation of XML

instances with regard to their respective schema. This is the major reason why XML

is so successful in many industry environments.

JavaScript Object Notation (JSON) [10] is a simple data format that can be

automatically derived from the code (e.g. JavaScript objects). JSON can especially

be used to exchange data between different kinds of parties (e.g., client and servers).

Traditional data exchange formats such as JSON and XML are based on a plain-text,

human readable representation. They are widely used for exchanging information

and have a TRL of 9.

The Efficient XML Interchange (EXI) [11] format is an efficient data exchange

format based on XML data model. EXI is compressed representation format (binary

XML) for optimizing the utilization efficiency of computing resources and the ex-

change of XML. EXI is also quite common for resource constrained smart objects

due to the very low memory, computation, and bandwidth usage. EXI is established

in many smart object-based industry standards such as ISO/IEC 15118 and ONVIF

Media Service Specification. IoT devices that can be resource constrained in terms of

memory, processing capabilities and bandwidth require a high efficient data ex-

change format. EXI is a W3C standard recommendation (since 2011) with existing

many libraries and tools. EXI has a TRL of 9.

EXI4JSON format [12] has been released in 2016 to be a standard by W3C.

JSON is a quite popular due to Java and JavaScript usage, however, it is not well

suited for the use in resource constrained devices, like smart objects. EXI4JSON is



© 2016 15

developed to bring JSON-based data into a binary representation and make it usable

for resource constrained smart objects. EXI4JSON has a TRL of 6-7.

RDF/XML (Resource Description Framework) [13] is one of the popular seri-

alization formats for RDF based data. Especial to express RDF-based data, several

semantic serialization data formats have been developed. The RDF/XML standard

recommendation defines XML syntax for RDF. RDF/XML is a W3C recommendation

standard that comes with a broad library support and is used in many semantic–

based projects. The TRL of RDF/XML is 9.

JSON-LD (linking data) [14] is a relatively new RDF serialization format for

linking data and a promising one since it relies on the widely used JSON data format.

JSON-LD is a W3C recommendation standard and has a TRL of 9.

Triple-based representation (Turtle) [18] is a textual representation of an RDF

graph that does not follow a tree-like-structure (such as XML and JSON do). It is one

of the commonly used RDF serialization variants. Turtle is a W3C recommendation

standard and supported in many semantic web based tools (e.g., Protégé, and

Apache Jena). Turtle has a TRL of 9.

RDF/EXI relies on the EXI data format. Traditional RDF serialization formats,

such as RDF/XML, Turtle, and JSON-LD are based on plain-text representation. That

is not feasible in an IoT environment that consists of resource constrained devices

such as microcontrollers with limited memory, processing capabilities, and band-

width. RDF-EXI strength is the reduction of string-based content as well redundancy

that is heavily used in RDF based data (especially URIs). DF/EXI has a TRL of 9.

Communication Paradigms

Many communication paradigms have been analysed, namely, Web based pro-

tocols, remote procedure calls, message-oriented communication, stream-oriented

communication, etc.

Web based protocols describe rules, mostly between clients and Web servers

to enable data exchange and are mainly defined in established standards or set of

conventions.

Hypertext Transfer Protocol (HTTP) is one of widely used Web Protocol.

HTTP 1.0 was designed as a stateless (hence connection-less) protocol, which con-

tinuously creates new server connections for each request/response. In order to im-

proving the connectivity performance, HTTP/1.1 was released which introduced con-



© 2016 16

nection re-use. Basically, connections are not discarded after successful re-

quest/response, but kept open for a short time in order to be re-used in subsequent

requests, alleviating these requests from establishing their connections from scratch

again. HTTP/2 [20] is W3C's most recent version of HTTP (released summer 2015)

to improve the performance of the web even further and also to support bi-directional

communication. HTTP/2 has a TRL of 8.

WebSockets [19] is a protocol providing full-duplex communication channels

over a single TCP/IP connection. WebSockets use HTTP for connection establish-

ment that implicates compatibility with most corporate firewalls and security guide-

lines. Instead of breaking the connection after receiving a server response, HTTP

connections are promoted to WebSockets connections that remain opened - just like

standard TCP connections. WebSockets are a well-established and proven W3C

standard with wide adoption across various domains – predominantly highly-

interactive web-applications. There are two kinds of Solutions for Web services,

REST based and SOAP based [8]. WebSockets has a TRL of 9.

At the beginning of the Web 2.0 era, interacting with Web Services was mainly

based on SOAP-based protocols. Still Simple Object Access Protocol (SOAP) can be

found in many Web Service realizations (e.g., used by Amazon Web Services and

Google AdWords). SOAP based protocols have a TRL of 9.

Representational State Transfer (REST) is an architecture style for designing

networked applications that is mainly based on the principal of the well-known HTTP.

A REST Server provides access to resources and a REST client accesses and pre-

sents the resources. Each resource is identified by Uniform Resource Identifiers

(URI). Following, well known HTTP methods are commonly used in REST based ar-

chitectures; GET, PUT, POST, and DELETE. Web services following the REST ar-

chitecture are known as RESTful web services. REST has a TRL of 9.

Remote procedure call (RPC) is an inter-computer communications paradigm.

This paradigm allows a computer program to execute a subroutine at a remote. RPC

can be realized in two manners: object-based such as Common Object Request Bro-

ker Architecture (CORBA), Java RMI, Distributed Component Object Model (DCOM)

and on the other hand data-based, such as Dynamic Content Elements (DCE) or Sun

RPC. Those technologies are mature and have a highest TRL, as they have been

used in quite a number of commercial applications for a long time.



© 2016 17

Message-Oriented Middleware (MoM) is a paradigm of message-oriented

communication. MoM can be used to implement a high-level concept of service ori-

ented architecture like SOAP/REST, an event driven architecture or other architec-

tures. The important properties of MOM are synchronicity, persistence and publish-

subscribe. Many IoT protocols are developed as open standard application layer pro-

tocol for Message-Oriented Middlewares.

Advanced Message Queuing Protocol (AMQP) [24] has been designed to ef-

ficiently support a wide variety of messaging applications and communication pat-

terns. Specifically, AMQP supports flow controlled, message-oriented communication

(queuing and routing) with message-delivery guarantees such as at-most-once, at-

least-once and exactly-once, as well as support for publish-and-subscribe communi-

cation paradigms. AMQP assumes a reliable underlying transport layer protocol and

thus is built on top of TCP/IP. Authentication and/or encryption are also based on

standard solutions, such as Simple Authentication and Security Layer (SASL) and/or

Transport Layer Security (TLS). AMQP standardizes the wire formats for all types of

Message-oriented-Middleware (MoM). AMQP has been so influential that most major

Java Message Service (JMS) brokers are adopting AMQP as an alternative format to

exchange messages. AMQP is more than just a messaging protocol in that it “com-

prises an efficient [binary] wire protocol that separates the network transport from

broker architecture and management”. As such, it can be thought of as an architec-

ture recommendation as well as a protocol specification. AMQP is heavily used by

many commercial applications and has a TRL of 9.

Extensible Messaging and Presence Protocol (XMPP) [22] has his origins in

instant messaging, it has developed into a general purpose messaging platform used

in a broad range of application domains including the IoT. It is characterized by a de-

centralized highly scalable and modular architecture. Mature implementations are

available for a broad range of languages and runtime environments including some

that are backed by companies. In particular the standardization process based on

comparatively small and focused extensions to the core specification has led to nu-

merous adaptations and broad adoption. XMPP has very large commercial deploy-

ments. XMPP has therefore a TRL of 9.

Constrained Application Protocol (CoAP) [21] is a quite new application layer

protocol and is already quite established in IoT environments since it is based on the

concept of HTTP. It enables seamless REST-based Web services for resource con-

strained (IoT) devices in terms of memory, processing, and bandwidth usage. How-



© 2016 18

ever, it is feasible for a resource constrained environment because its binary header

format. CoAP is standardized as RFC 7252 and comes with many implementations.

CoAP has a TRL of 9.

Message Queuing Telemetry Transport (MQTT) [23] is a broker-based Mes-

sage-oriented-Middleware (MoM) that focuses on the publish/subscribe pattern (see

Annex). The broker is responsible for distributing messages to interested clients

based on the topic of a message. Due to its small code footprint it is suitable for con-

strained client devices (e.g., sensors) with limited processing and storage capabili-

ties. Furthermore, MQTT is a “lightweight” messaging protocol on top of TCP/IP for

bandwidth limited networks (e.g., wireless). MQTT is heavily used by many commer-

cial applications. MQTT has a TRL of 9.

RabbitMQ [35] is an open source message broker. RabbitMQ provides a ready-

to-use technology for providing messaging services for IoT systems. It is a widely

adopted implementation of the AMQP (Advanced Message Queuing Protocol), which

supports scalability and maintainability by decoupling, using the messaging pattern.

Services and their components can be dynamically, redundantly and robustly distrib-

uted across an arbitrary number of physical servers. Lightweight clients are support-

ed via an MQTT adapter. The product is mature, well documented, widely supported

and widely used. RabbitMQ has a TRL of 9.

Apache Kafka was initially developed by LinkedIn to handle all internal com-

munications of their entire social network platform. Kafka is a message-oriented-

middleware which was built for distribution and scale-out by design. After being open-

sourced, Kafka has proven to scale linearly and provide high robustness in messag-

ing. It is worth to note, that Kafka scales linearly with the underlying disk drives – un-

like common MoM solutions – and introduces minimum latency which makes it a per-

fect fit for real-time and high-performance communication scenarios. Kafka is already

widely adopted across industries. Kafka has a TRL of 8.

In contrast of MoM based protocols, protocols that are based on stream-

oriented communication send a continuous flow of data. There are many systems

based on stream–oriented communication, such as Apache Spark and Reactive

Streams.

Apache Spark [30] is a streaming and stream analytic engine built on top of

Akka [32] (Akka is an actor library. Actors are a long-known concept (since the 70s)

which provides an asynchronous & reactive way of processing data). It is provided



© 2016 19

as-a-service by many popular cloud vendors today for accessing big data lakes and

storage infrastructure and processing the contained data at fast speed. Due the un-

derlying actor model, Spark is inherently distributable and scalable. Spark is also part

of PTC's IoT offering Thingworx which is among the most well-known and adopted

IoT stacks today. Apache Spark is heavily used in popular cloud platforms. It has a

TRL of 9.

Reactive Streams (RS) [31] is an enhancement to usual communication proto-

cols for supporting overload protection and flow control. Since IoT scenarios are

known to potentially produce large quantities of communication messages at high

rates, RS is a convenient and industrial means of controlling this communication

sprawl and thus increases client and server robustness. Reactive Streams is an initi-

ative to provide a standard for asynchronous stream processing with non-blocking

back pressure. Reactive Streams is a mechanism to enable stream processing (e.g.,

of IoT device data) with built-in flow-control and overload protection. ATOS has al-

ready built a number of production platforms as well as prototypes, which rely exclu-

sively on Reactive Streams on top of streaming protocols. RS has a TRL of 8.

3.2. Semantic Descriptions


Semantic Description of an artefact (e.g., smart object, data, physical object

etc.) provides the meta-data about it with the goal of giving the structural or descrip-

tive information about the artefact. One of the goals of using semantic description for

data or functions of smart objects is to enable to communicate with each other. To

achieve this goal, the described objects need to use a common semantic model.

Semantic model can be expressed with the help of knowledge representation lan-

guages (ontology languages). One of the important goals of BIG IoT is the semantic

description of smart object data and functions, and services.


Knowledge representation languages are based mostly on first-order predicates

and can follow different language paradigms. A collection of Semantic Web Technol-

ogies that contain the widely used ontology languages such as RDF, RDFS [25] and

OWL [26] can be used to build semantic web application. Those W3C’s Semantic

Web technologies are used in many semantic based projects, e.g., schema.org [28],



© 2016 20

Semantic Sensor Network (SSN) Ontology [29], etc. (more information about existing

ontologies and the supported editing tools can be found in Annex).

Resource Description Framework (RDF) is a general framework to describe

any Web resource. The RDF data model is based on triples, each consisting of a

subject, a predicate and an object. The several common serialization formats in use,

include RDF/XML, JSON-LD, JSON-LD/EXI, and RDF/EXI. RDF is widely used in

various vertical domains. Recently RDF has been used in different IoT projects such

as OpenIoT, and is considered as the data model in an upcoming W3C standard re-

lated to Web of Things. RDF has a TRL of 9.

RDF Schema (RDFS) is a semantic extension of RDF. RDFS can be used to

build a data-modeling vocabulary for RDF data. It uses the classes and types of rela-

tionship for describing groups of related resources and the relationships between

these resources. Like RDF, RDFS can be serialized in different formats, see Section

3.1 “Communication”. It can be saved in triple stores, see the Section 3.7 about Per-

sistency.

Web Ontology Language (OWL) builds upon the RDF and RDFS. OWL adds

a more expressive semantics to RDFS. It provides more expressive constructs to

specify classes and properties. Further on, OWL can also express more constraints

on the semantic models, which enable more expressive and efficient search queries.

A wide range of reasoners exist to do reasoning over OWL semantic ontologies for

OWL ontology developers [39]. OWL is used in commercial and government projects

and has a TRL of 9.

SPARQL (SPARQL Protocol and RDF Query Language) [27] is a set of spec-

ifications that define a query language for RDF data, along with protocols for query-

ing and result set serialization formats (XML, JSON). The SPARQL query language

was designed to look similar to SQL. It reuses part of its syntax but also introduces a

way to express complex graph patterns, since RDF data can be represented as a

graph. SPARQL is often used in conjunction with reasoners to dynamically infer

knowledge, at query time, according to given semantics. SPARQL can be used in the

task of the discovery of a service by querying semantic descriptions of services.

However it is also used as a general query language for querying RDF data.

SPARQL is widely used in applications from different domains. It has TRL 9.



© 2016 21

3.3. Service Discovery


Service discovery is the process of searching one or more provided services

that are required by other services or applications. To perform a service discovery

process, there are two different concepts: syntactic based discovery and semantic

based discovery. For syntactic based discovery, the required service and the provid-

ed service must have the same syntactic description, such as a common protocol,

programming interface, etc. The entity requiring a service can search provided ser-

vices with exact information, such as an ID or a name, etc. The discovery process of

the semantic based method is supported by the semantic description of a service.

With the semantic description it is possible to discover a service whose description

semantically satisfies the search criteria, also when it syntactically does not match.


One of the fundamental communication technologies in the Internet are Web

Services that serve different kind of services. In this section, we introduce syntactic

based and semantic description based Web Service discovery mechanisms.

Universal Description, Discovery and Integration (UDDI), based on SOAP-

based Web Services, refer to a standardized directory service. UDDI defines a way

to publish and discover Web Services based on protocols. A typical search process

of UDDI is as follows: The service provider (Web Service) sends a Web Services De-

scription Language (WSDL) file to UDDI (WSDL is XML based interface definition

language). The service requester (client) requests UDDI to find some particular kind

of data it needs and then contacts the Web Service directly, using the SOAP proto-

col. Simple Object Access Protocol (SOAP) is a message exchange protocol to

transport the data between server and client. The service provider validates the ser-

vice request and sends structured data back in a XML file, using the SOAP protocol

that is transported over HTTP. This XML file is validated by the service requester us-

ing an XSD file. The UDDI protocol has TRL 9.

Web Ontology Language for Services (OWL-S) is one ontology for describing

Web services. The essence of semantic Web Service description is to realize auto-

matic Web Service discovery. OWL-S is an explicit, semantically unambiguous, ma-

chine readable markup language. A service in OWL-S consists of three elements:



© 2016 22

ServiceProfile, ServiceModel, and ServiceGrounding. ServiceProfile describes the

capabilities of a service, ServiceModel refers to the structure of a service, and Ser-

viceGrounding describes the access to the service. It is used widely in academic re-

search and has a TRL of 6/7.

Web Service Modeling Ontology (WSMO) is another well-known ontology that

can be used to describe various aspects related to semantic Web Services. WSMO

consists of four main concepts to describe semantic Web services: Web services,

Goals, Ontologies and Mediators. Web service descriptions define various aspects of

a Web Service such as the capabilities, interfaces and internal working of the Web

service. Goals state the intentions that should be solved by Web Services. Ontolo-

gies provide the terminology used by other elements. Mediators resolve interoperabil-

ity problems between different WSMO elements. Mediators are core concepts for

incompatibilities on the data level (terminologies), process level (combining Web ser-

vices) and protocol level (communicate between Web services). In contrast to OWL-

S, WSMO can describe non-functional properties, and enable to use mediators that

can be used as brokers to connect provided and required services. It is used widely

in academic research, and has a TRL of 6/7.

3.4. Service Orchestration


Service orchestration is the automated arrangement, coordination and man-

agement of services. Service composition, which is closely related to Service Or-

chestration deals with the orchestration of a number of services and exposing them

as a single new service.


Web Service-Business Process Execution Language (BPEL) is an XML

based specification language used to automate business processes. Those process-

es can be executed on any platform or product that complies with the BPEL specifi-

cation. BPEL extends WSDL interfaces, and also belongs to the SOA based solu-

tions. BPEL defines how to implement interfaces with an own interface definition lan-

guage, including the input parameters, operation names, and return parameters.

BPEL defines how to invoke methods from other services to realize its own services.

BPEL provides a standard that allows the description of dependencies between ser-



© 2016 23

vices. It does not specify how to automatically resolve these dependencies. BPEL is

supported by IBM and SAP and has a TRL of 9.

WSMO mediators, The concept of mediators that has been introduced in Sec-

tion 3.3 “service discovery” provides a general mechanism to mitigate the unavoida-

ble issues when Web Services require each other. It addresses the handling of het-

erogeneities that arise in open environments. Heterogeneity can occur in terms of

data, underlying ontology, protocols or processes. However, WSMO has no clear

specification of the solutions for composition an invocation of Web Services. It is

used widely in academics research. It has a TRL of 6/7

3.5. Interoperability


Interoperability can be defined as the ability of two or more systems to collabo-

rate. Those systems could be similar systems from different vendors, past and future

revisions of the same system, or entirely different types of systems (e.g., an IoT plat-

form and an industrial control system). To be able to exchange information between

those systems in a meaningful way, the systems need to share a common way to

communicate and a mutual understanding of the interchanged information. A com-

mon understanding can, for example, be achieved by using common standards, an

accessible and documented API, and/or semantic descriptions based on identical

models.


The use of common protocols, common data formats, common standards or

common APIs is a common solution for improving interoperability of systems. This

ensures a common understanding across the systems with regards to the exchange

of information among the participating entities. However, systems developed in dif-

ferent domain typically use different data formats and standards that are tailored to

the domain at hand. Therefore, it is generally difficult to exchange information among

systems designed for and deployed within heterogeneous domains. Without the use

of adapter the exchange of data between systems that use different data formats or

protocols is impossible.

To improve the interoperability, one solution is to endorse a publicly available,

well documented application programming interface (API), a so call open API, that

provides developers with programmatic access to resources and services. Systems



© 2016 24

typically adopt such open APIs of a successful or dominate system. The open APIs is

usually defined by that organization. Many of today’s successful Web services enable

access to their services via an open API like, Google Maps, Yahoo! Developer Net-

work, Facebook, IoT platforms, etc.

A further approach to enable interoperability across heterogeneous systems is

through open source. This means a system offers access to its source code, so that

the peer systems can adapt their interfaces accordingly, or extend the functionality of

the target system.

3.6. Deployment


Software and system deployment is an important part of the product develop-

ment process. Deployment comprises a number of process steps, like, release, in-

stall and activate, update, version tracking, deactivate uninstall and retire. The big

challenges of software system development processes are the differences between

development and production environment, as well as the management of software

updates on devices/systems already deployed in the field.


Vagrant is one of the solutions for synchronization between develop and pro-

duction environment. Vagrant can provide a configurable, renewable, portable work-

ing environment by creating development environments on a virtual machine. Those

environments can be configured entirely independently from the host machine and

can be shared among a team. It ensures that all codes developed components from

different developers in a team are running in the same environment, which over-

comes the problem of “it is no problem on my machine”. Vagrant has a TRL of 9.

Docker [33] is another candidate addressing the same issue. Docker also runs

on a virtual machine, but it works in a fundamentally different way. Docker is a flavour

of the Linux kernel containers (and their tool-chain), which allows packaging applica-

tions in a generic container format. These deployment packages can then be run on

any Linux-host featuring the Docker daemon as a run-time environment. It therefore

allows packaging, delivery and running of an application anywhere. One of the major

benefits of Docker is that it allows to completely avoid a thick virtualization as for ex-

ample VMWare, Xen, or other hypervisor technologies. This decreases the runtime

overhead and improves performance, with regard to CPU load and memory con-



© 2016 25

sumption. Many tools are developed to be used with the Docker Containers, such as

the Docker Registry, Kubernetes, etc. With the supports of those tools applications

can easily be deployed on cloud systems, such as Amazon (ECS - Elastic Container

Services), Microsoft Azure, IBM, etc. Docker has a TRL of 9.

Eclipse hawkBit [34] is another solution to enable automatic software updates

through managed software provisioning. It enable smart object and smart objects

platform providers to manage software updates on devices and systems, already de-

ployed in the field. It reduces adequate management capabilities for coordinating the

software updates as well as rolling them out to large numbers of devices. Eclipse

hawkBit is a mature (TRL 8-9) open resource project for in-field software provision-

ing.

3.7. Persistency


Persistency means storing of data (e.g. semantic descriptions of smart object

data) in permanent storage. It is important for BIG IoT to find storage solutions to

save data or information, semantic descriptions, charging data, etc. One of the ma-

ture solutions for permanent storage is databases. Databases haven been developed

based on different concepts, namely relational databases and non-relational data-

bases, such as key-value stores, document stores or graph-based databases.


Relational databases are databases that utilize a relational model. They present

a variety of entities in the real world and the relationships among them. The various

software systems used to maintain relational databases are called relational data-

base management systems (RDBMS).

Relational database management systems (RDBMS), prominent products in-

clude MySQL, Microsoft SQL, Oracle Database, etc. Structured Query Language

(SQL) is used to manage data held in RDBMS. MySQL, Microsoft SQL and Oracle

Database are very widely used. They have a TRL of 9.

Non-relational Databases are a general name of databases that provide a

mechanism for storage and retrieval of data, which do not use the tabular relations

known from relational databases. They usually renounce SQL to manage their data.

According to the data model, non-relational databases can be classified into non-

https://en.wikipedia.org/wiki/Computer_data_storage

https://en.wikipedia.org/wiki/Data_retrieval

https://en.wikipedia.org/wiki/Relational_database



© 2016 26

relational database models, including key-value stores, document stores, and graph

databases.

As the name suggests key-value stores such as BerkeleyDB, DynamoDB, Kyo-

to Cabinet, etc. store data in form of key-value pairs. The most important features are

fast querying, storage of large volumes of data, high-concurrency and the high suita-

bility for queries by primary keys.

Document stores databases, such as MongoDB, are a subclass of key-value

stores. They are generally used to store data in JSON format, whereby the stored

content is a document type. This also opens the opportunity to index some fields, to

be able to use some of the features of a relational database.

Graph-based databases such as Stardog, GraphDB, etc. are preferred for

storage data that has a graph-like structure. They are very suitable to store semanti-

cally enriched heterogeneous data like RDF. Querying of that semantic information in

these databases is partly supported by the RDF query language SPARQL. SPARQL

is a set of specifications that define a query language for RDF data, along with proto-

cols for querying, and serialization formats (XML, JSON) for the results.

Although NoSQL databases have been extensively used in operational envi-

ronments for a few years. The benefit of NoSQL over SQL has been made clear in

the case of data-intensive applications and database management system. Many

Vendors already advocate NoSQL for IoT platforms. However, evaluations tend to

show that NoSQL will not fully replace traditional database management systems,

particularly due to its limited query support, even in the case of document-oriented

storage [7]. Therefore it is not certain if this technology will succeed without further

research. NoSQL databases for the IoT have a TRL of 7.

In general, relational databases have a highly organized structure of data that

delimited data into the small logical tables (relational tables) to avoid duplication and

get the most effective way to use the storage. Most relational databases support AC-

ID properties (Atomicity, Consistency, Isolation, Durability). In contrast to relational

database, no-relation database offer high performance, high availability and scalabil-

ity. They are a perfect fit to store for big data. They ensure eventual BASE (basic

availability, Soft state, Eventual consistency), rather than ACID properties.

https://en.wikipedia.org/wiki/Key-value_database

https://en.wikipedia.org/wiki/Key-value_database

https://en.wikipedia.org/wiki/Atomicity_(database_systems)

https://en.wikipedia.org/wiki/Consistency_(database_systems)

https://en.wikipedia.org/wiki/Isolation_(database_systems)

https://en.wikipedia.org/wiki/Durability_(database_systems)



© 2016 27

3.8. Security


Information security must protect information from unauthorized access, mis-

use, disclosure, modification, inspection, recording or destruction. Information securi-

ty is concerned with three main aspects: Confidentiality, Integrity, and Availability

(CIA). There are many countermeasures for security threats, such as access control,

encryption, authentication and authorization, firewalling, etc. Authentication, Authori-

zation and Accounting (AAA) is a core concept and cornerstone for information secu-

rity. It provides the basis to tackle the security and privacy challenges of BIG IoT.


There are many different solutions for the AAA concept. They are suitable for

different application environment. Which solution to choose is depending on the spe-

cific requirements.

HTTP basic authentication is a simple authentication mechanism. When a cli-

ent requests a page that requires authentication and the client does not provide a

user name and password, the server will send a 401 status code (not authorized). In

turn, the browser will pop up a login dialog box for the user to fill in the username and

password. After the user enters his/her username and password, the client software

will add the authentication header in the original request. If the server accepts the

authentication, it will provide the data, the client requested. HTTP basic authentica-

tion is widely used and has a TRL of 9.

OpenID is a user-centric digital identity framework. OpenID supports user au-

thentication based on a unique URI (also known as URL). The first part of the

OpenID system is authentication, namely, users are authenticated based on the

unique URI. Most Web sites rely on basic authentication for the user login, which

means that users need to register with their username and password for each site,

even if you use the same password. OpenID system provides a mechanism that your

website address (URI) is your user name and your password is stored on a secure

OpenID service website. OpenID has a TRL of 9.

OAuth [37] is related to OpenID, as it was originally developed as part of Twit-

ter's OpenID implementation. OAuth is complementary to OpenID and supports dif-

ferent functionalities. OAuth allows users to provide a token instead of a user name

and password combination to access data that are provided in a particular service.

https://en.wikipedia.org/wiki/Information

https://en.wikipedia.org/wiki/Authorization




© 2016 28

Every token is authorized for a particular site, a specific time, and a particular re-

source. Thus, OAuth allows users to authorize third-party site access to certain in-

formation that is stored in another place. Above that, OAuth allows to specify different

kinds of access, enabling to limit the granted access. OAuth was developed for Twit-

ters identity management and has since been used in many commercial settings,

including Web and mobile applications and by network providers. It has a TRL of 9.

RADIUS protocol is a server-client architecture based protocol. A RADIUS pro-

tocol clients are users (human or computer) that require network connectivity ser-

vices. The network provider requires the verification services (and maybe billing).

The server can only request client responses for verification and billing, but cannot

deny access to service or redirect to other requests. RADIUS was developed earlier

than AAA. Because of that, RADIUS does not separate authentication and authoriza-

tion. RADIUS is already in production state for many years and used in various infra-

structures and has a TRL of 9.

Diameter [36] is an open protocol that was derived from the RADIUS protocol.

A Diameter protocol based network is an overlay network that allows for efficient

transport of AAA messages between nodes of a telecommunication infrastructure.

Furthermore, Diameter also allows the definition of AAA applications between nodes

of the Diameter network. In Diameter each component of the protocol is extensible:

One can define new applications, i.e. a set of commands and each command can

carry several AVPs (Attribute Value Pairs). Diameter also provides a mechanism by

which nodes can negotiate their capabilities; in other words, the Diameter applica-

tions that they support. Diameter is in production state in many infrastructures and

has a TRL of 9.

3.9. Marketplace


A marketplace provides a space for exchanging a commodity. In an e-

marketplace, the commodity can be real goods or virtual goods. The information of

the goods is provided by the providers of the goods. A consumer accesses the mar-

ketplace to discover, evaluate and potentially to purchase goods. Transactions be-

tween consumers and providers are processed by the marketplace. An App store is a

typical e-marketplace for virtual goods. In an App store, the virtual goods that are

traded are software artifacts. App stores provides similar functionality to the planned



https://en.wikipedia.org/wiki/RADIUS



© 2016 29

BIG IoT marketplace. A study of App stores will help to identify the requirements of

the BIG IoT marketplace.


An App Store is a web-based software platform for the transaction. Platform

providers, such as Apple or Google Play provide usually only a part of the software

that is traded on their App Store. Typically, most of the software is provided by third

parties, such as software companies. Users can search for application or select them

from them the application catalog, App stores also handle the provision of download

links to the software.

As such, App Stores connect software providers (software companies) and

consumers (end users). On the one hand, App Stores provides a software platform

for the sale of software artifacts. On the other hand, they provide users with continu-

ous Internet content or application services. Platform providers like Apple and Google

keep a handling fee of 30% of all processed payments; the software providers obtain

the remaining 70%. The app stores for mobile devises are run as a service by their

respective providers, not available for third parties to operate, and have a TRL of 9.

https://zh.wikipedia.org/zh/Google_Play



© 2016 30

4. IoT Platforms

The aim of the BIG IoT project is to close the interoperability gap of the IoT plat-

forms. To achieve this aim, it is therefore important to survey current IoT platforms

and give an overview of the current IoT platforms with regard to their technological

readiness levels and the measures they took towards interoperability.

In Section 4.1, the standard reference frameworks for the IoT are introduced.

An overview of the functionalities and interoperability of those IoT standards frame-

works is provided, this section concludes with a comparison of those frameworks.

Following the Section 4.1, a representative range of relevant implemented IoT plat-

forms with relevance for BIG IoT are presented as subsections. The IoT platforms

included are those that project partners will use and extend as part of the BIG IoT

project, namely: BEZIRK, Bosch Smart City Platform, CSI Piemonte Smartdata Plat-

form, OpenIoT, Vodafone IoT Platform, TIC Platform, WorldSensing and Wubby. Ad-

ditionally further external IoT platform that have already established a representative

user base and target a similar goal than project, namely FIWARE, IFTTT and Xively

are presented. In particular, we highlight the licensing models, and common domain

and technical readiness level of these IoT platforms. Furthermore, we point to exist-

ing barriers and gaps for interoperability. Finally in Section 4.13, the chapter con-

cludes with a short, summarizing table that presents the most important facts of the

surveyed IoT platforms and provides a quick overview as well as their interoperability

measures. The technical details of analysed standards frameworks and IoT platforms

can be found in the Annex for this document.



© 2016 31

4.1. IoT Standard Frameworks

4.1.1. Overview and Introduction

This section analyses IoT Standard Frameworks relevant for BIG IoT. The se-

lected IoT standard frameworks for this analysis include definitions of APIs with parts

of the required functionalities (e.g., discovery, access, tasking, or event processing).

The capabilities of those standard frameworks in the template used throughout this

deliverable in order to reach wide comparability are analysed. The technology readi-

ness levels of the standards were assessed by estimating this factor of known im-

plementations of those standards. In the remainder of this section, the following IoT

standard frameworks, OGC SWE, HyperCat, OneM2M, FI-WARE NGSI 9/10 are

compared.

4.1.2. OGC SWE

The Open Geospatial Consortium (OGC) started the Sensor Web Enable-

ment (SWE) initiative back in 2003. Within the SWE working group a suite of stand-

ards has been developed which can be used as building blocks for a "Sensor Web"

[2]. SWE defines the term Sensor Web as “Web accessible sensor networks and ar-

chived sensor data that can be discovered and accessed using standard protocols

and application programming interfaces” [3].

SWE comprises the following services: A Sensor Observation Service (SOS) [4]

enables querying as well as inserting measured sensor data and metadata. While the

SOS follows a pull-based communication paradigm to access sensor data, the Sen-

sor Alert Service (SAS) and its successor the Sensor Event Service (SES) push sen-

sor data to subscribed clients in case of user defined filter criteria. The Sensor Plan-

ning Service (SPS) enables tasking of sensors (e.g., setting the sampling rate of a

sensor). Discovery [4] of sensors is supported by implementations of Sensor In-

stance Registry (SIR) and Sensor Observable Registry (SOR) [6][7]. SWE further

comprises data encodings: SensorML, an XML schema, is used to encode sensor

metadata. Observations & Measurements (O&M) is used to encode measured sen-

sor data. O&M also defines an XML schema. Different companies implemented the

SWE standards and deployed productive systems for some of them. The TRL of

OGC SWE lays between 3 and 9 - depending on the specific standard of the family.

4.1.3. HyperCat

HyperCat is an open, lightweight JSON-based hypermedia catalogue format for

exposing collections of URIs. HyperCat catalogue may expose any number of URIs,

https://www.ctwiki.siemens.com/display/BIGIoT/D2.1+-+IoT+Standard+Frameworks



© 2016 32

each with any number of resource description framework-like (RDF-like) triple state-

ments about it. It can be used in domain like Smart Cities, Smart Mobility, Smart En-

vironment / water, Smart Farming and food security.

HyperCat supports only the functionalities ID & Lifecycle Management and Dis-

covery of IoT assets. It therefore offers create/read/search functionality for catalogue

servers. Multiple organizations have used the standard and tested it. However, it is

quite new and still maturing with a TRL of 8.

4.1.4. OneM2M

oneM2M, purpose and goal is to develop technical specifications that address

the need for a common M2M Service Layer, which can be readily embedded within

various hardware and software, and relied upon to connect the myriad of devices in

the field with M2M application servers worldwide. The objective "any app, any device,

any network" is achieved by abstracting devices and applications from underlying

access networks and technologies.

Release 1 has been released in January 2015. It includes interworking commu-

nication support, but limited semantic support. Release 2 is planned for May-July

2016 and is focused on Semantic Interoperability, and the inclusion of testing specifi-

cations. OneM2M has a TRL of 7.

4.1.5. FI-WARE NGSI 9/10

FI-WARE (see also Section 4.5 for the description of the platform) utilizes the

standard “Next Generation Service Interface (NGSI) 9/10”, which is based on the

Open Mobile Alliance (OMA) NGSI Context Management. NGSI-9 and NGSI-10 are

the two interfaces that specify the Context Management functions of the NGSI ena-

bler. The FI-WARE versions of the OMA NGSI-9/10 interfaces are a RESTful API via

HTTP with a few extensions. NGSI-9 interface is used to exchange information about

availability of context information (registration of context information, subscription for

context availability information updates and one-time queries for discovering agents

where certain context information is available). NGSI-10 is used to exchange context

information (one-time queries for context information, subscriptions for context infor-

mation updates (and the corresponding notifications), unsolicited updates (invoked

by context providers)).

The IoT Architecture differentiates between the IoT Edge with a connection to

the devices and the IoT Backend, which may typically run on a server/in the cloud.

Through NGSI, information from devices is provided on a higher abstraction level,



© 2016 33

using an entity-attribute model, e.g. devices, but also rooms, cars etc. are modelled

as entities, which may have attributes like temperature, speed, occupation etc. The

NGSI interface allows query and subscription operations triggered by information

consumers, as well as update operations by information providers. NGSI queries and

subscriptions allow the definition of restrictions (e.g. for filtering according to values),

as well as scopes, defining where to look for information, e.g. within geographic

scopes defined using coordinates (example: give me all current outdoor temperature

values within specified geographic area). NGSI data sources, e.g. on IoT NGSI

Gateways, register the information they can provide with the IoT Discovery GE using

the NGSI-9 interface. The IoT Broker GE finds suitable NGSI data sources using the

IoT Discovery GE and accesses and integrates information from the different NGSI

data sources, possibly providing them to the Data Context Broker. FI-WARE NGSI

9/10 has a TRL of 5-9, it depending on the particular functionality.

4.1.6. Comparison of IoT Standard Frameworks

To aid the reader in focusing on the features that are crucial, a comparison ta-ble of the IoT standard frameworks introduced above is presented below

Table 1 : Comparison of IoT Standard Frameworks

IoT Standard Frameworks

OGC SWE Hypercat OneM2M FIWARE NGSI 9/10

TRL TRL 3-9 TRL 8 TRL 7 TRL 5-9 (depending on functionality)

Interoperability Open Standards Open Standards Open standard, open

API

Open standard, based

on OMA NGSI-9/10

Context Interfaces

Layer of

interoperability

Service-level &

data-level

Service-level network-level, data-

level, service-level

API-level

Service Discovery ID-based, free

text, spatial, tem-

poral

ID-based, key-

word-based,

spatial

ID-based, keyword-

based, spatial, value

comparison, tem-

plate, complex filter

Queries and subscrip-

tions

Requests for entities

(based on ID or entity

type)

Scopes, e.g. geo-

graphic scopes (within

geographic area)

Access (pull) of measured data Yes No Yes Yes

Access (pull) of object metadata Yes Yes Yes, in Release 2. Yes

Tasking Yes No No Yes



© 2016 34

Messaging (Pub/Sub) Services Yes No Yes Yes, subscript to data

Event/data processing Yes No No Yes. Update infor-

mation (events) to IoT

Broker/Context Broker

and the update opera-

tion is via HTTP.

Vocabulary management /

Semantic concepts

Yes No Release 1: No

Release 2: Yes -

Semantic Interoper-

ability as new speci-

fication.

Yes. NGSI allows

specification of entity

types, supported

attributes, and based

on ontologies.

Security management No No Yes Yes

Privacy management No No Yes, in Release 2 No

Charging and Billing No No Yes No

4.1.7. Conclusions of IoT Standard Frameworks Analysis

There are various IoT standard frameworks already out there, of which we have

analysed here OGC SWE, HyperCat, OneM2M, and the FiWare extension of OMA

NGSI 9/10. Except for HyperCat (which concentrates on the 'discovery' functionality)

all frameworks comprise a wide spectrum of IoT platform functionalities, as identified

in Section 2.2. All three standard frameworks (except HyperCat) support discovery,

access (pull) to measured data, access (pull) to metadata, messaging (pub/sub) ser-

vices, and vocabulary management. For OneM2M, however, many of those features

will be only supported in the planned second release. Tasking functionality is only

supported by OGC SWE and FiWare's NGSI. Security mechanisms are supported by

OneM2M and FiWare NGSI. Further functionalities, privacy management, charging

and billing, and SLA/QoS management are only supported by OneM2M. Reputation

management is not supported by any standard framework.

OGC SWE is a comprehensive framework with many elaborated functionalities.

It particularly shows strength in querying data with rich filtering options (spatiotem-

poral).Also, with the SPS, it has an elaborated standard on tasking. A downside of

this framework however is that the encodings and bindings are based on XML/SOAP

message exchange which is not state of the art for today's Web API designs.

HyperCat is an outlier among the analysed framework as it only focuses on dis-

covery. This functionality, however, is solved in a very lean and lightweight manner.



© 2016 35

OneM2M is a very comprehensive framework. In particular, the upcoming sec-

ond release will complete a rich functionality set.

FiWare's NGSI extension is also very elaborate. However, a downside is that it

seems very complex and hence has not yet been picked up significantly by a user

base.

In summary, we can say that there is not the one standard framework that ad-

dresses all requirements. In consequence, for the design of the BIG IoT API that

could mean that we have to reuse different standards and build a coherent solution

out of those.

4.2. BEZIRK

4.2.1. Overview of the Platform

BEZIRK [www.bezirk.com] is a peer-to-peer IoT middleware for both communi-

cation and service execution on local devices following a service-oriented paradigm.

BEZIRK is developed with a view to facilitate asynchronous interactions among vari-

ous components or services of an application with respect to distribution across dif-

ferent devices in a network. To achieve this, BEZIRK is implemented on top of such

as UDP over Wi-Fi within local networks, and TCP sockets for internet communica-

tions.

The main features of BEZIRK are: i) handling reliable delivery of messages

among devices or services, ii) hiding service distribution, iii) enforcing security and

privacy policies of the user, and iv) facilitating dynamic service discovery and seman-

tic addressing.

BEZIRK allows end users to personalize their security and privacy settings

based on an easy-to-use user interface. All communications over BEZIRK is encrypt-

ed.

4.2.2. Technology Readiness

BEZIRK was initiated by Bosch Corporate Research and is now released as an

open platform by the Robert Bosch Start-up GmbH. BEZIRK has been developed

primarily for consumer IoT domains (e.g. smart home) but can also be adopted in

other domains where IoT devices communicate and collaborate in a local environ-

ment, or where users desire to manage and control their privacy. BEZIRK has been

validated and demonstrated in relevant environments and currently has a TRL of 5-6.



© 2016 36

4.2.3. Interoperability Measures

BEZIRK follows an Open API, Open Protocol and Open Source approach to fa-

cilitate interoperability. The decentralized design requires no infrastructure that facili-

tates local integration without any dependencies on backend infrastructure or provid-

ers. Another key design consideration of BEZIRK is to enable easy middleware inte-

gration on new IoT platforms. This is achieved through the usage of standard com-

munication protocols (e.g. TCP/IP for data transport, JSON for data encoding) and

available Java implementations for Linux/MacOS/Windows/Android.

4.3. Bosch Smart City Platform (SCP)


Smart City IT solutions generally have different requirements to those known for

classical enterprise applications. Therefore, Smart City installations are typically

composed of heterogeneous solutions individually customized for a City, but with a

common need with respect to operation, data-sharing and security. Bosch’s Smart

City platform (SCP) targets to connect the silos in the Smart City, i.e., governance,

mobility, energy, environment, industry life, tourism, etc. It offers tools and methods

to develop, operate and maintain such systems without sacrificing data security and

privacy. The key aspects of the Bosch SCP platform are: secure data routing / fan-

out, third party and developer tooling, data as a Service / data tooling integration,

operational support.


The business model is inspired by the SaaS business model. The platform pro-

vides City stakeholders the means to easily plugin diverse sensors and devices, and

to provide citizens access to services and data collected by the devices. The platform

has been developed with a main focus on addressing the Smart City domain, includ-

ing Smart Mobility and environment domains. Smart Home and Smart Factory are

currently not addressed but may be required for an IoT platform. Bosch’s SCP is op-

erational in various Smart City demonstrators. The platform is currently used for cus-

tomers to build solutions. First solutions to Smart City customers are operational. It

currently has a TRL of 7.


Within Smart City projects it is very unlikely that a single provider will provide all

the solutions. Accordingly, Bosch’s SCP platform has been designed to interoperate



© 2016 37

with other solution providers and to contribute and rollout artifacts in a quality con-

trolled multi-staged software provisioning concept. Because of the yet very unclear

concrete requirements of solutions for cities in the future, the platform is designed to

be flexible enough to support a wide span of technologies and/or programming lan-

guages. This makes it possible for the platform to evolve in the required direction(s)

without disrupting installations and rebuilding them from scratch. In particular, the

following measures for interoperability have been stressed in the design: the platform

is easy to deploy on premise (e.g. notebook) or on varied cloud providers; the plat-

form allows flexible integration of diverse sensors and devices (with different proto-

cols/APIs/standards); and the platform is able to provide Data-as-a-Service.

4.4. CSI Piemonte Smartdata Platform


The business model of a government agency is to facilitate value creation in so-

ciety. In this sense, the Piedmont region has developed the Smart Data Platform

(SDP) and included it in a context which has edited and organized the Smart Data

Net [http://www.smartdatanet.it]. This service is made available to public and private

entities of Piedmont. SDP is based on project Yucca, a cloud self-service platform

enabling to develop applications based on IoT and Big Data. SDP works as a Plat-

form-as-a-Service as an IoT cloud-based platform and supports features such as

multi-tenancy. It receives events from "things", "people" (twitter) and "applications",

exposes APIs that realize a Publish-Subscribe paradigm in near real-time and APIs

with Request-Response paradigm to read historical data. It uses the ODATA proto-

col, different types of visibility (opendata, public, private and shared APIs), and

makes use of OAUTH2 security to access non-public APIs. Beyond that it enables

complex event processing in near real-time to enrich or filter events.


SDP is built using different Open Source projects, middlewares and frame-

works: Yucca Userportal, Yucca Storage, Yucca Realtime, Yucca Fabriccontroller,

ActiveMQ WSO2 CEP, WSO2 API Manager, and WSO2 Identity Server. The usage

of SDP is free for Piedmont residents and the region is in charge of the maintenance,

infrastructure and ecosystem evolution. SDP can serve different domains, but is

mainly oriented to data for the Piedmont region in Italy. SDP has proven itself in op-



© 2016 38

erational environment. It has been used in production environment by more than 20

projects. It has a TRL of 9.


The interoperability approach is to define Open APIs and send events to the

platform for the data, information and service levels. It uses HTTP(s)/MQTT(s) for

data transport, JSON/ODATA for data encoding, and OAuth2 for authorization. SDP

can interact with other platforms through sending events over MQTT in JSON format,

reading historical events through an ODATA REST API, or subscribe to events

through MQTTs or Web sockets.

4.5. FIWARE


FIWARE [https://www.fiware.org] is a middleware platform and has been devel-

oped for the future internet, driven by the EU commission. The FIWARE platform

consists of a number of General Enablers (GEs) that are/have been developed by

different chapters within the FIWARE and FI-CORE projects. The FIWARE Internet of

Things Generic Enablers allows “Things” to become available, searchable, accessi-

ble, and usable resources fostering FIWARE-based Apps interaction with real-life

objects. The success behind FIWARE IoT is that all Things or IoT resources are ex-

posed to FIWARE App developers just as other Next Generation Service Interface

(NGSI) Context Entities. Therefore, developers do not have to deal at all with today's

complexity and high fragmentation of IoT technologies and deployment scenarios.

On the contrary, app developers just need to learn and use the same NGSI Context-

Broker API, used in FIWARE to represent all context information.

There are more than 800 organizations using FIWARE, including IoT GEs and

complete FIWARE instances. Around 350 startups joined a program to get trained on

FIWARE for their future digital market asset creation. There are also openly accessi-

ble FIWARE platform instances hosted by multiple nodes inside and outside Europe,

providing a lab environment for testing and learning.


FIWARE has been defined as a Future Internet core platform. It has been used

in a variety of domains such as Smart Cities, agriculture and food safety,

eHealth/AAL etc. Each GE has his own the licensing model; to give some examples

NEC IoT Broker has a 4-clause BSD license, Surrey IoT Discovery is licensed under

https://en.wikipedia.org/wiki/Middleware



© 2016 39

AGPLv3, Orange IoT Data Edge Consolidation GE is available under Cepheus

GPLv2, and the Telefonica Backend Device Management is also licensed under the

AGPLv3. With the upcoming FIWARE Open Source Community, a partly harmoniza-

tion of license terms is planned. Each GE has a different TRL and the TRLs range

between 5-9, depending on the functionality.


The interoperability of FIWARE is achieved through a standard interface, name-

ly NGSI-10 based sources. Core interfaces for the IoT and Context GEs are the

NGSI-9/10 Context Interfaces that were originally developed by OMA and for which

FIWARE defined a REST-like interface with a few extensions. In addition, the

IDAS/IoT Data Edge provides interoperability with a number of existing technologies,

e.g., UL2.0/HTTP, MQTT, OMA LWM2M/CoAP, ThinkingThings Protocol and SIG-

FOX protocol. Interoperability takes place at the interface level like it is envisioned in

BIG IoT.

4.6. OpenIoT


OpenIoT [http://www.openiot.eu] is a middleware infrastructure for implement-

ing/integrating Internet-of-Things solutions. The OpenIoT infrastructure provides the

means for the following: Collecting and processing data from virtually any sensor in

the world, including physical devices, sensor processing algorithms, social media

processing algorithms and more. Note that in OpenIoT the term sensor refers to any

components that can provide observations. OpenIoT facilitates the integration of the

above sensors with only minimal effort (i.e. few man days effort) for implementing an

appropriate access driver; semantically annotating sensor data, according to the

W3C Semantic Sensor Networks (SSN) specifications; streaming the data of the var-

ious sensors to a cloud computing infrastructure; dynamically discovering/querying

sensors and their data; composing and delivering IoT services that comprise data

from multiple sensors; visualizing IoT data based on appropriate mashups (charts,

graphs, maps etc.); optimizing resources within the OpenIoT middleware and cloud

computing infrastructure. OpenIoT combines and enhances results from leading

edge middleware projects, such as the Global Sensor Networks (GSN) and the

Linked Sensor Middleware (LSM) projects.



© 2016 40


OpenIoT is designed to satisfy different domains, in particular focusing on

providing efficient ways to use and manage cloud environments for IoT entities and

resources such as sensors, actuators and smart devices. OpenIoT is released as

Open Source under the LGPLv3 license. The OpenIoT platform has been validated

and demonstrated in relevant environments (CSIRO, Fraunhofer IOSB) and has

TRLs of 5-6.


OpenIoT transports data through using data XM and RDF with standard proto-

col HTTP. Interoperability on the platform level is enabled through the public and well

documented APIs.

4.7. Vodafone IoT Platform


The Vodafone IoT platform [38] is offered as a service. The Vodafone IoT plat-

form is access level comprising cellular network, fixed network, local/private networks

(RF, Wi-Fi, etc.). The Vodafone IoT platform is a central Acquisition System for IoT

including data collection, device management and network management and pro-

vides mobile analytics for mobility/vehicles metrics. The platform is installed in a fault

tolerant and load balanced configuration. The RF transmission and signal strength is

constantly monitored.


The domains in focus are Smart Metering, Smart Home, Smart Energy, Smart

Lighting, Smart City and Smart Mobility. The platform is not licensed. Vodafone offer

it as a service with a commercial license. The technology has shown acceptable per-

formance and reliability over a period of time. The platform has a TRL of 6-7.


The solution of Vodafone IoT Platform is based on open standards in the meter-

ing, Device Language Message Specification (DLMS) and M-Bus (Meter-Bus). Cur-

rently the platform is not interoperable with other platforms. However, the Interaction

with other platforms could be achieved through the web portal and adoption of the

offered APIs at the service-level.



© 2016 41

4.8. WorldSensing


Worldsensing [http://www.worldsensing.com] provides a unique traffic man-

agement portfolio for Smart Cities that includes Bitcarrier, a real-time intelligent traffic

management and information solution designed for both road and urban environ-

ments. Fastprk provides an intelligent parking system and Sensefields provides an

innovative system for detecting and monitoring vehicles and traffic flow.

Fastprk, a Worldsensing’s intelligent parking solution has been commercially

operational since November 2012. This pioneering technology has allowed

Worldsensing to become one of the foremost technological companies since it has

deployed the largest smart parking project with over 12,000 sensors installed in Mos-

cow. Fastprk also contributed towards Worldsensing being labelled by prestigious

“Pike Research” as one of the 17 companies actively shaping the Smart City ecosys-

tem. Coinciding with the first stage of Fastprk deployment in Moscow, Worldsensing

received its first significant Series-A investment (early 2013). Since then, Worldsens-

ing has held a strong executive and advisory team, and has also counted on the stra-

tegic investor JFME, which has direct access to the construction giant Acciona. This

has allowed the company to grow and acquire Bitcarrier (early 2014), a world-leader

in traffic flux and journey time monitoring.

Fastprk has won two major awards. The Stockholm Smart City Living Labs

Global Award 2011 and the IBM Smart Camp 2010 London Award.

Bitcarrier was also IBM Smart Camp Winner 2011 and it has been recognized

by analyst firm Gartner as “Cool Vendor 2013” of Smart City Applications.


Worldsensing business relies on providing useful data analysis of their own in-

formation sources. Worldsensing platform is proprietary code and is not released.

Worldsensing's platform access will be only provided for the deployment of the Bar-

celona use case. The platform is fully operational and already in use in the Barcelona

region. It has a TRL of 8.


Worldsensing transfer data through HTTP(s) in the JSON data format and

through a REST API. Interoperability to other platforms/solutions can be achieved by

adopting the RESTful APIs and an already integrated pull service. No raw access to



© 2016 42

the "actual" things/sensors but a bunch of functions/functionalities is provided, based

on the collected data. Access to the platform will be limited to the Barcelona pilot, for

specific clients just during the project. Subscription/PUSH service will be implement-

ed.

4.9. TIC Platform


The TIC mobility platform [http://viz-info.de] provided by VMZ is a data and ser-

vice platform that has been developed to provide comprehensive information on all

mobility options available in Berlin. It is based on the platform of the Traffic Infor-

mation Center (TIC) of the City of Berlin. Since new mobility providers recently en-

tered the Berlin Mobility Market the TIC mobility platform was extended by VMZ to a

multimodal mobility platform. The platform includes real-time data from the traffic in-

formation center, mobility operators and infrastructure providers and provides a mul-

timodal routing platform using the modal router offered by third parties.

Based on the TIC mobility platform various services and applications are offered

to the public sector/administration, business clients and end users. Some examples

are the www.viz-info.de, location-based multimodal mobility displays and mobility

apps. The TIC mobility platform of VMZ has been developed in cooperation with the

City of Berlin. Usage of data provided by mobility operators is stipulated in individual

data provision contracts.

The TIC mobility platform is a decentralized system with integrated data from

more than 20 external service providers. The system comprises of three compo-

nents; a data platform integrating real time data from mobility providers, a routing

platform, and an online monitoring system for air pollution and noise in the arterial

street network of Berlin.


The TIC platform is primarily designed for the domain of Smart Mobility. Smart

Environment is also considered as the traffic detectors data are used to monitor air

pollution and noise. The TIC mobility platform is used to provide mobility information

services and applications for the city administration, mobility providers and other

business clients (e.g. stations, airports).



© 2016 43

The scalability depends on the mobility data that are provided. If it is provided,

the solution is transferable to all European metropolitan regions. The limiting factor

for the platform is the provision of data from mobility providers and low standardiza-

tion of interfaces.

Applications based on platform such as mobility websites and mobility displays

are implemented and running in various applications, end user apps based on the

mobility platform are qualified and are ready to be launched. It has a TRL of 9.


Interoperability on the platform level is enabled via Open API (charging sta-

tions), data level (detector data), service level (modal routers). The TIC Platform has

been connected with the VBB platform (Public transportation data and routing ser-

vices in the region Berlin/Brandenburg).

4.10. IFTTT


IFTTT (If This Then That) [https://ifttt.com] is a service platform where users may

create new services or use existing ones. Services are actually provided by other

service provider, e.g., Instagram, Dropbox, Google, Facebook etc. Similarly in BIG

IoT users will be able to create or use services that are provided by other platforms. It

enables users to create chains of simple conditional statements, called "recipes",

which are exposed as web services. They are triggered based on changes to other

web services such as Gmail, Facebook, Instagram, and Dropbox and so on. IFTTT is

a commercial service platform. It is based on its own constructs (channels), which

enable definition of triggers and actions IFTTT is an example of a service platform,

which is relevant when surveying the technology readiness of available IoT Plat-

forms. This is especially important when the interoperability at the platform level is

concerned, as IFTTT enables interoperability between various platforms.


Currently 287 service providers from different domains are available via IFTTT,

including: business, commerce, connected car, connected home, fitness and weara-

bles, mobile, Web etc. IFTTT offers the Maker Channel, which enables users to con-

nect IFTTT to a customer project. IFTTT is a commercial platform. It has a TRL of 9.



© 2016 44


In order to monitor the behaviour of the hundreds of APIs that IFTTT connects

from other service providers (e.g., information about the API requests, metrics such

as response time and HTTP status codes etc.), IFTTT uses elasticsearch and its

components "Internal Monitoring & Alerting" and "Developer Dashboard". Manual

integration with the hundreds of APIs is supported by IFTTT.

4.11. Wubby


Wubby [http://wubby.io] was created in 2015 as a spin-off of Econais. Econais

has been in the IoT market since 2010 and has developed a number of Wi-Fi mod-

ules with very unique characteristics (smallest size, lowest power consumption, com-

plete software, etc.) compared to any other competitive solutions in the market.

Wubby is an ecosystem of software components and services for rapid devel-

opment of everyday objects. Everyday objects are physical objects embedded with

electronics, software, sensors and network connectivity to collect and exchange data.

At the core of this ecosystem is Wubby VM that runs in the heart of an everyday ob-

ject, the microcontroller. Its main duty is providing a hardware agnostic environment

for the creation of interoperable applications inside each everyday object. Wubby VM

has built-in Python support, so programming an everyday object becomes as simple

as writing a Python script.

Wubby IDE is a platform independent development environment for configura-

tion, debugging and simulation of everyday objects, Wubby Cloud is a bunch of pro-

tocols and web services for application deployment and backend device manage-

ment, Wubby Client is the main tool for user interaction with everyday objects includ-

ing managing them and installing/updating new apps.


Wubby can serve any domain that focus on low power 32bit devices. Wubby is

a solution to fuel fast development of low cost, low complexity, low power and high

volume IoT products made on Embedded Microcontroller Unit (MCU) regardless of

the domain for which they will be used.

The business model for the various components is different. Development Envi-

ronment: License per seat, special App Libraries: License + Runtime, runtime Envi-



© 2016 45

ronment: Base price + Lib Runtime, License to use and distribute backend Wubby:

Per number and devices supported.

Wubby has been demonstrated in a number of different environments and

commercially available hardware platforms from chip and module vendors. Wubby

has TRL5-6.


Wubby provides interoperability at the device level (device-service discovery, in-

itial setup) and new protocols could be added by installing new python librar-

ies/modules in the device. Wubby allows new platforms to be integrated by allowing

layer 2 interoperability whenever possible (e.g. Wi-Fi Direct service discovery) and

enables integration of new protocols by adding new applications in the Wubby VM.

Wubby encourages interoperability on different levels: it is protocol agnostic (where

users can add support for their own protocols), it supports standard wireless technol-

ogies, e.g. Wi-Fi, BLE, etc., multiple security schemes can be integrated, and it sup-

ports device & service discovery using MQTT and layer2 frames according to individ-

ual wireless standard.

4.12. Xively


The platform started under the name Pachube. After its acquisition by LogMeln,

it was renamed to COSM, and has later been rebranded as Xively [http://xively.com].

Xively works as a PaaS which makes it an IoT cloud-based platform. Xively is an en-

terprise grade IoT software platform and easy-to-use APIs are at the heart of what

they offer. The central goal of Xively is to enable building of a "Connected Product"

and a customer shall be enabled to realize a "Connected Business". The API is com-

posed of "microservices". Xively is designed to be a centralized PaaS. Thus, its

scalability is global. Xively generates revenue from Professional Services (e.g. build-

ing customer projects on their platform)


Xively is generally designed for whichever domains where Smart Products play

a role. However, to be specific, it has mainly been applied in domains such as Smart

Home and Smart Lab. Since Xively is closed source, the internal implementation de-



© 2016 46

tails are not disclosed. Xively has proven itself in operational environment. Xively has

TRL9.


Xively uses Open APIs to promote interoperability. The Open API is defined for

the data, information and service levels. It provides 4 key functionalities: blueprint

service: Allows to describe the metadata and relations between device, user and or-

ganization, messaging service: Via MQTT protocol, data messaging streams from

devices to services can be set up, time series service: Via HTTP GET request, histor-

ical data measured by connected devices can be queried, Identity management: Us-

er accounts need to be created to use the API. Roles can be assigned to users. In-

teroperability on the platform level (as well as its offered services) is enabled through

the public and well documented API.

4.13. Comparison of IoT Platforms

4.13.1. Comparison of Generic Information

To provide a briefly overview of the analysed IoT platforms, we summarize the

key information in the following Table 2.

Table 2 : Comparison of Generic Information

Common Domain Licensing Model TRL Main drivers

BEZIRK IoT domains, e.g., smart home

Not fixed TRL 5-6 • Bosch CR

• Targeted at Open Source

Bosch SCP Smart City SaaS – commercially TRL 7 Bosch

CSI Piemonte Smart data Commons licenses CC0 or CC BY

TRL 9 CSI Piemonte

FIWARE Smart Cities, agriculture and food safety, ehealth/AAL etc.

Difference depending on functionality.

TRL 5-9

(depending on functionality)

FIWARE and FICORE projects

Coordinator: Telefonica

OpenIoT IoT entities and resources

such as sensors, actua-

tors and smart devices.

Open source: LGPLv3

license

TRL 5-6 EU Project

Vodafone IoT

platform

Smart Metering, Smart

Home, Smart Energy,

Smart Lighting, Smart

City and Smart Mobility.

The platform is not li-

censed. Vodafone offer it

as a service with a com-

mercial license

TRL 6-7 Vodafone



© 2016 47

WorldSensing Smart City, Smart mobili-ty

Not applicable, not for

public

TRL 8 WorldSensing

TIC Platform Smart Mobility SaaS (commercially

available)

TRL 9 VMZ Berlin

IFTTT Business, commerce,

connected car, connected

home, fitness and weara-

bles, mobile, Web etc.

The platform is not open

source. It provides a

service free of charge.

TRL 9 IFTTT Inc.

Wubby low power 32bit devices Depending on compo-

nents

TRL5-6 Econais

Xively Smart Home and Smart

Lab

Commercial access

through PaaS.

TRL 9 LogMeIn

4.13.2. Comparison of Interoperability of IoT Platforms

To improve interoperability across current IoT platforms is one of important tasks

of BIG IoT. The following table [Table 3] shows the four fields about the interoperabil-

ity of our analysed IoT platforms. The information in the column “solutions for In-

teroperability” show what approach/solution is used for interoperability (e.g. Open

API, Open Source, etc.). The column “the layer of interoperability” shows at which

level interoperability is enabled, e.g. at data-level, device-level, interface-level, proto-

col-level, service-level. In column “supported platforms”, we show the application ar-

eas of IoT platforms. The last column shows the barriers of interoperability of current

IoT platforms.

Table 3 : Comparison of Interoperability of IoT Platforms

Solutions for

Interoperability

Layer of

interoperability

Supported platforms Barriers for

interoperability

BEZIRK Open API

Open Protocol

Open Source

Protocol-level

Interface-level

Device-level

Several smart home

systems, e.g. Philips

Hue

Interoperability only with sys-

tems in the local network

Bosch SCP Data-as-a-

Service

Data-level FlyBits platform Integration of varied identity

managements.

CSI Piemonte Open API Data-level

Interface-level

Service-level

Not known The impossibility of manage

lifecycle of smart objects repre-

sents a barrier to a complete

integration with other platforms.



© 2016 48

FIWARE OMA NGSI-9/10

IDAS/IoT Data

Edge

Interface-level Not known Lack of easy-to-use SDKs for

IoT Platform and service devel-

opers

Lack of semantic expressive-

ness (to describe/discover data

and functions)

Lack of maturity (TRL of IoT

Discovery around 5)

OpenIoT HTTP Data level None Not known

Vodafone

IoT platform

Web portal

APIs

Service level not interoperable with

other platforms

The lack of commonly used

standards for device manufac-

turers especially in non-

regulated markets and conse-

quently the difficulties to reach

the economies of scale with

highly optimized hardware.

WorldSensing HTTP(s) (data

transport)

REST API

Interface-level Barcelona Sentilo. No raw access to the "actual"

things/sensors. Access to the

platform will be limited to the

Barcelona pilot, for specific

clients just during the project.

TIC Platform Open API Data-level

Service-level

VBB platform (Public

transportation data

and routing services

in the region Ber-

lin/Brandenburg).

The platform integrates data

via open API, but also to a great

part data provided by 3rd par-

ties. For these data we have

no consent to use

the data within interoperable

solutions.

IFTTT Open API Data-level Not known For creating IFTTT rules, a de-

veloper needs to know a ser-

vice/platform that is connected

to IFTTT and IFTTT itself.

Wubby Adding new

applications in

Wubby VM

Device-level Not Known The availability of resources on

the device.

Xively Open APIs Device-level Salesforce CRM

system

Texas Instruments

device-level platform

Not known



© 2016 49

5. Results and Evaluation

This deliverable presents the results of about the initial analysis of BIG IoT rele-

vant IoT platforms and technologies. In particular, the analysis was focused on tech-

nology readiness levels and interoperability measures of the IoT platforms and tech-

nologies included in this report.

In summarize, a comprehensive overview of the analyses performed for the vari-

ous technologies as well as the IoT platforms was provided. The analyses of tech-

nologies and concepts were carried out from the results of generated questionnaires

and the information collected from experts in the areas and technologies. Naturally, it

has not been possible that our analysis covers all IoT concepts and platforms. Never-

theless, the results are valuable and will be helpful for BIG IoT’s future work.

According to the presented analysis, eight of the IoT platforms provide infor-

mation communication by XML and/or JSON data model, two IoT platforms support

special purpose JSON data format, BEZIRK supports JSON-LD and CSI Piemonte

supports JSON/ODATA. IoT platforms support their functionalities mostly by using

HTTP protocol. IoT platforms, which offer message-oriented communication such as

Bosch’s SCP, CSI Piemonte, and Wubby use mostly MQTT for communication..

To improve interoperability, the IoT platforms provide programming interfaces,

such as BEZIRK, CSI Piemonte, OpenIoT, TIC Platform, and IFTTT. Other IoT plat-

forms try to achieve interoperability through an open source approach, such as BE-

ZIRK and OpenIoT. Instead of Opening their functionality, Bosch SCP exchanges

their information with other systems through a data as service approach and Xively

allows only the delivery of data over their platform as a platform as a service ap-

proach. WorldSensing is currently a closed system and does not offer specific in-

teroperability measures.

The IoT platforms BEZIRK, Vodafone IoT platform, and WorldSensing improve

system security by Encryption. WorldSensing uses JSON Web Token (JWT) while

BEZIRK uses its sphere-based model, utilizing standard encryption technologies.

Moreover, CSI Piemonte, FIWARE, and OpenIoT provide the AAA concept by using

OAuth2 protocol. Bosch SCP supports their security by using the framework Spring

XD security.

To store data, Bosch SCP provides MySQL, MongoDB and DynamoDB. Wubby

uses MySQL. CSI Piemonte uses the Yucca Storage to save their data. Amazon



© 2016 50

Simple Storage Service (AWS S3) provides the IFTTT service platform with a cloud

storage. WorldSensing manages the real-time traffic information and supports no

storage. In contrast, OpenIoT uses an RDF store to persist information according to

the used semantic models.

Support for semantic descriptions is not wide. Three of the eleven surveyed IoT

platforms, supports semantic descriptions of their data or services. OpenIoT and FI-

WARE both support the semantic description of their data by using RDF/OWL.

Thereby, OpenIoT uses the SSN Ontology and OpenIoT Ontology. BEZIRK also us-

es semantic descriptions of the information, assuming the use of application or do-

main specific ontologies. Bosch SCP uses semantics for service discovery, but it

doesn’t support semantic description of smart objects.

Regarding Service Discovery, Ten IoT platforms support service discovery.

Three IoT platforms discovery its services based on semantic description. Seven IoT

platforms support service discovery through syntactic description of services. Two

IoT platforms have no discovery functionality. None of the analysed IoT platforms

support service orchestration.

Cloud based IoT platforms, Bosch SCP, FIWARE, and the TIC Platform use the

Docker Container. One benefit of using Docker is to allow for automatic synchroniza-

tion of the development environment and runtime environment.

Two IoT of the eleven IoT platforms have provided a marketplace. However, the

FIWARE marketplace is platform dependent. It allows transactions of the da-

ta/services that are developed within FIWARE. IFTTT also supports a marketplace,

but the details are unknown.

Acting as general conclusion, the overview table [Table 4Fehler! Verweisquelle

konnte nicht gefunden werden.] that shows the concepts as columns and the plat-

forms as rows has been created and provided as comprehensive summary. At the

table a cross or, if known, a concrete technology/solution states how the particular

IoT platform realizes the concept, i.e. based on which measures or technologies

(where applicable).



© 2016 51

Table 4 : Solution/technologies of IoT platforms

Communication Openness Security Persistency Semantic

Concept

Service

discovery and Orchestration

Deployment Marketplace

BEZIRK JSON and JSON-LD,

TCP/IP (ZeroMQ)

Open API, Open

Protocols and

Open Source

Encryption On device storage Yes, based on

domain-specific

semantic protocols

and ontologies

Semantic based Not supported Not supported

Bosch SCP XML, JSON,

HTTP REST, MQTT.

Data as service Spring XD security MySQL, MongoDB

and DynamoDB

Semantic is sup-

ported

No ontologies

Syntactic level Docker,

Provisioner

Not supported

CSI Piemonte JSON/ODATA,

HTTP(s)/MQTT(s)

Open API OAuth2 Yucca Storage Not supported only through user

interaction

Not known Using for free

FIWARE JSON/HTTP OMA NGSI-9/10

IDAS/IoT Data

Edge

OAuth 2.0 Different depending

on GEs.

RDF/OWL Trough different

GEs: Syntax based:

NGSI-9 Server

Semantic based:

Sense2Web

Docker

GE in FiWare:

Sagitta

GE in FiWare:

Repository RI

Different GEs:

WMarket and

WStore

OpenIoT XML, JSON, RDF HTTP Oauth2 OpenIoT RDF store

(LSM light)

SSN ontology,

OpenIoT ontology.

Semantic based:

depend on Ontolo-

gy.

Not known Not supported

Vodafone

IoT platform

XML Web portal

APIs

encryption Not known Not supported Syntax based: ID-

based, keyword-

based.

Not known Not supported



© 2016 52

WorldSensing JSON Not known JWT Not supported Not supported Not supported Not supported Not supported

TIC Platform JSON Open API Apikey nosql (only internal

use)

Not known No Exist Docker No Exist

IFTTT Not known,

depending on

supported services

Open API Two-step verifica-

tion using user

password and

phone

Amazon Simple

Storage Service (a

cloud storage)

Syntax based:

Keyword-based

Not known. Not supported Yes,

details not

known

Wubby Anything Protocol agnostic

MQTT

Not known MySQL Syntax based: ID-

based, service

based, product

based

Not supported A custom buildbot

approach together

with some logic in

the IoT devices for

automatic updates

No Exist

Xively JSON+SenML

XML+SenML

CSV (proprietary)

HTTP REST (GET) Not known Not known Not known Syntax based: very

limited search

criteria

Not known Not known



© 2016 53

6. Acknowledgements

We are grateful for contributions in form of technology descriptions and evalua-

tions by the following people: Martin Bauer (NEC), Christian Beckel (Bosch), Sven

Trieflinger (Bosch), Mark Andrew (Bosch), Alexandros Patelis (Bosch), Benjamin

Herd (Bosch), Felix Lösch (Bosch), Aparna Saisree Thuluva (Siemens), Danh Le

Phuoc (NUIG), Costas Pipilas (Econais), Juan Hernandez Serrano (UPC), Stefano

Marzorati (Vodafone), Claudia Baumgartner(VMZ), Claudio Parodi (CSI Piemonte).



© 2016 54

7. References

[1] Technology readiness levels (TRL),

http://ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020-wp1415-

annex-g-trl_en.pdf

[2] Bröring, A., J. Echterhoff, S. Jirka, I. Simonis, T. Everding, C. Stasch, S. Liang, & R. Lemmens

(2011): New Generation Sensor Web Enablement. Sensors, 11(3), pp. 2652-2699.

[3] Botts, M; Percivall, G; Reed, C; Davidson, J. OGC Sensor Web Enablement: Overview and High

Level Architecture. Proceedings of GeoSensor Networks, 2nd International Conference, GSN

2006, Boston, MA, USA, October 2006; Nittel, S, Labrinidis, A, Stefanidis, A, Eds.; Lecture Notes

In Computer Science;. Springer: Berlin, Germany, 2008; 4540, pp. 175–190.

[4] Open Geospatial Consortium. Approved Implementation Standard. Sensor Observation Service

Interface Standard, Version 2.0. OGC 12-006. (2012). Editors: Bröring, A., C. Stasch & J.

Echterhoff. Authors: Bröring, A., C. Stasch, J. Echterhoff, P. Taylor, L. Bermudez, A. Robin, J. de

La Beaujardiere, T. Ingold, C. Hollmann & S. Cox.

[5] Jirka, S., A. Bröring & C. Stasch (2009): Discovery Mechanisms for the Sensor Web. Sensors,

9(4), pp. 2661-2681.

[6] Open Geospatial Consortium. Discussion Paper. Sensor Observable Registry. OGC 09-112.

(2009). Editors: Jirka, S. & A. Bröring.

[7] T. A. M. Phan, J. K. Nurminen, and M. Di Francesco, “Cloud Databases for Internet-of-Things

Data,” 2014, pp. 117–124.

[8] SOAP-based Web Services, https://www.w3.org/TR/soap/

[9] Extensible Markup Language (XML), https://www.w3.org/TR/xml/

[10] JavaScript Object Notation, JSON, https://tools.ietf.org/html/rfc7159

[11] W3C Efficient XML Interchange (EXI), https://www.w3.org/TR/exi/

[12] EXI for JSON (EXI4JSON), https://www.w3.org/TR/exi-for-json/

[13] RDF/XML, https://www.w3.org/TR/rdf-syntax-grammar/

[14] JSON-LD, https://www.w3.org/TR/json-ld/

[15] EXI, https://www.w3.org/XML/EXI/

[16] The Resource Description Framework (RDF),, https://www.w3.org/RDF/

[17] The Resource Description Framework (RDF), https://www.w3.org/standards/techs/rdf#w3c_all

[18] Triple-based representation (Turtle), https://www.w3.org/TR/turtle/

[19] WebSockets, https://tools.ietf.org/html/rfc6455

http://ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020-wp1415-annex-g-trl_en.pdf


http://www.opengeospatial.org/standards/sos

https://portal.opengeospatial.org/files/?artifact_id=47599


http://portal.opengeospatial.org/files/?artifact_id=40571

https://www.w3.org/TR/soap/

https://www.w3.org/TR/xml/

https://tools.ietf.org/html/rfc7159

https://www.w3.org/TR/exi/

https://www.w3.org/TR/exi-for-json/

https://www.w3.org/TR/rdf-syntax-grammar/

https://www.w3.org/TR/json-ld/

https://www.w3.org/XML/EXI/

https://www.w3.org/RDF/

https://www.w3.org/standards/techs/rdf#w3c_all

https://www.w3.org/TR/turtle/




© 2016 55

[20] HTTP/2.0, https://tools.ietf.org/html/rfc7540

[21] Constrained Application Protocol (CoAP), https://tools.ietf.org/html/rfc7252

[22] XMPP, https://www.xmpp.org.

[23] MQTT (Message Queue Telemetry Transport), http://mqtt.org/

[24] AMQP (Advanced Message Queuing Protocol), http://www.amqp.org

[25] RDFS, https://www.w3.org/TR/2014/REC-rdf-schema-20140225/

[26] Web Ontology Language (OWL), https://www.w3.org/standards/techs/owl#w3c_all

[27] SPARQL Protocol and RDF Query Language (SPARQL),

https://www.w3.org/standards/techs/sparql#w3c_all

[28] Schema.org, http://schema.org

[29] Semantic Sensor Netywork (SSN), https://www.w3.org/2005/Incubator/ssn/ssnx/ssn

[30] Apache Spark, http://spark.apache.org/

[31] Reactive Streams, http://www.reactive-streams.org/

[32] Akka, http://akka.io/

[33] Docker Engine, https://docs.docker.com/engine/

[34] Eclipse hawkBit, https://projects.eclipse.org/projects/iot.hawkbit

[35] RabbitMQ, https://www.rabbitmq.com/

[36] Diameter, https://tools.ietf.org/html/rfc6733

[37] OAuth, https://tools.ietf.org/html/rfc6749

[38] Vodafone IoT platform, http://www8.hp.com/h20195/V2/getpdf.aspx/4AA4-6123ENW.pdf?ver=1.0

[39] OWL Implementations, https://www.w3.org/2001/sw/wiki/OWL/Implementations



https://www.xmpp.org./

http://mqtt.org/

http://www.amqp.org/

https://www.w3.org/TR/2014/REC-rdf-schema-20140225/

https://www.w3.org/standards/techs/owl#w3c_all


http://schema.org/

https://www.w3.org/2005/Incubator/ssn/ssnx/ssn

http://spark.apache.org/

http://www.reactive-streams.org/

http://akka.io/

https://docs.docker.com/engine/

https://projects.eclipse.org/projects/iot.hawkbit

https://www.rabbitmq.com/



http://www8.hp.com/h20195/V2/getpdf.aspx/4AA4-6123ENW.pdf?ver=1.0



© 2016 56

8. Annex

Contents of this Annex are in a separate file

“Annex D2.1: Summary of the Analysis of Technology Readiness of Technolo-

gies and Platforms for the Internet of Things".

ANNEX D2.1: SUMMARY OF THE ANALYSIS FOR TECHNOLOGY READINESS LEVEL OF

TECHNOLOGIES AND PLATFORMS FOR THE INTERNET OF THINGS

D2.1

ANNEX

© 2016 1

Annex D2.1:

Summary of the Analysis for

Technology Readiness Level of

Technologies and Platforms for the

Internet of Things

Note: This Annex complements the Deliverable

D2.1 Analysis of Technology Readiness

This project has received funding from the European Union’s Horizon 2020 research and in-

novation programme under grant agreement No 688038.



D2.1

ANNEX

© 2016 2

DOCUMENT HISTORY

Responsible Person and Affiliation Yong Wang (TU Clausthal)

Contributor (s): Abdelmajid Khelil (Bosch SI), Arne Broe-

ring (Siemens), Darko Anicic (Sie-

mens), Dirk Herrling (TU Clausthal), Jan

Zibuschka (Bosch CR), Jansen Lim (Bosch

SI), Stefan Schmid (Bosch CR), Sebastian

Kaebisch (Siemens), Thomas Schöftner

(Atos), Victor Charpenay (Siemens), Yong

Wang (TU Clausthal), Martin Bauer (NEC),

Christian Beckel (Bosch), Sven Trieflinger

(Bosch), Mark Andrew (Bosch), Alexandros

Patelis (Bosch), Benjamin Herd (Bosch),

Felix Lösch (Bosch), Aparna Saisree Thu-

luva (Siemens), Danh Le Phuoc

(NUIG), Costas Pipilas (Econais), Juan

Hernandez Serrano (UPC), Stefano Mar-

zorati (Vodafone), Claudia Baumgart-

ner(VMZ), Claudio Parodi (CSI Piemonte).

Reviewer(s): Arne Broering (Siemens)

Hans-Peter Schwefel (AAU)

Lars Mikkelsen (AAU)

Martin Serrano (NUIG)

Stefan Schmid (Bosch CR)

Due Date / Delivery Date 31.05.2016

State Final

Version 1.0

Confidentiality Public



D2.1

ANNEX

© 2016 3

VERSION CONTROL

Version Description of Changes Date of Resolution

0.1 Initial Version 15.05.2016

0.11 Partners Contributions 20.05.2016

0.2 Technical & Quality 29.05.2016

0.3 Final Draft 30.05.2016

1.0 Final 31.05.2016



D2.1

ANNEX

© 2016 4

TABLE OF CONTENTS

1. Concepts Relevant for IoT Platforms __________________________________ 7

1.1. Communication______________________________________________________ 7

1.1.1. Generic Serialization Formats _______________________________________ 7

1.1.2. Semantic/RDF-based Serialization Formats ___________________________ 32

1.1.3. Web based Technologies _________________________________________ 47

1.1.4. Messaging Frameworks/Services ___________________________________ 74

1.1.5. Event and Stream Processing Frameworks __________________________ 122

1.1.6. Literature ____________________________________________________ 145

1.2. Semantic Descriptions ______________________________________________ 146

1.2.1. Conceptual schema (Semantic models) _____________________________ 175

1.2.2. Existing Base Tools _____________________________________________ 197

1.3. Deployment ______________________________________________________ 209

1.3.1. Docker Engine _________________________________________________ 209

1.3.2. Docker Registry ________________________________________________ 211

1.3.3. Kubernetes ___________________________________________________ 214

1.4. Persistency _______________________________________________________ 217

1.4.1. NoSQL _______________________________________________________ 217

1.4.2. RDF stores ____________________________________________________ 226

1.4.3. Literature ____________________________________________________ 236

1.5. Security __________________________________________________________ 237

1.5.1. Diameter _____________________________________________________ 237

1.5.2. Google “my Account” ___________________________________________ 242

1.5.3. OAuth _______________________________________________________ 246

1.5.4. XACML_______________________________________________________ 251

2. IoT Platforms ___________________________________________________ 256

2.1. IoT Standard Frameworks ________________________________________ 256

2.1.1. OGC SWE _____________________________________________________ 256

2.1.2. HyperCat _____________________________________________________ 265

2.1.3. OneM2M_____________________________________________________ 271

2.1.4. FI-WARE NGSI 9/10 _____________________________________________ 279

2.1.5. Literature ____________________________________________________ 285

2.2. BEZIRK ___________________________________________________________ 286

2.3. Bosch Smart City Platform (SCP) ______________________________________ 296

2.4. CSI Piemonte Smartdata Platform _____________________________________ 307

2.5. FIWARE __________________________________________________________ 318



D2.1

ANNEX

© 2016 5

2.6. OpenIoT __________________________________________________________ 329

2.7. Vodafone IoT Platform ______________________________________________ 339

2.8. WorldSensing _____________________________________________________ 348

2.9. TIC Platform ______________________________________________________ 358

2.10. IFTTT __________________________________________________________ 362

2.11. Wubby_________________________________________________________ 371

2.12. Xively__________________________________________________________ 382

2.13. Eclipse Vorto ____________________________________________________ 393

LIST OF FIGURES

FIGURE 1, THE CONCEPTUAL USAGE OF EXI IN DIFFERENT APPLICATION DOMAINS. ...................................... 20 FIGURE 2, EXI COMPACTNESS COMPARED TO GZIPPED XML. .................................................................... 21 FIGURE 3, THE BASIC ARCHITECTURE OF SOAP-BASED WEB SERVICES. .................................................... 48 FIGURE 4. XMPP PROTOCOL REPRESENTATION ........................................................................................ 81 FIGURE 5. MQTT CLIENTS B AND C SUBSCRIBING TO TOPIC "TEMPERATURE." TWO CASES ......................... 89 FIGURE 6. AMQP IS AN OPEN WIRE PROTOCOL STANDARD FOR MESSAGE-QUEUING ................................... 95 FIGURE 7 CONCEPT OF RABBITMQ ......................................................................................................... 103 FIGURE 8, SELECTED USERS OF RABBITMQ ............................................................................................ 105 FIGURE 9: THE SSN-XG SOURCE .......................................................................................................... 182 FIGURE 10: THE CONCEPTS OF THE ONTOLOGY. ...................................................................................... 184 FIGURE 11 DIAMETER PROTOCOL........................................................................................................ 238 FIGURE 12. COMPARISON OF OPENID AND OAUTH, WIKIMEDIA COMMONS ............................................... 248 FIGURE 13 XACML PROTOCOL REPRESENTATION ................................................................................... 252 FIGURE 14: DEPLOYMENT SCENARIO OF THE SWE SERVICES ................................................................. 257 FIGURE 15: ONEM2M SIMPLIFIED ARCHITECTURE .................................................................................... 273 FIGURE 16: BEZIRK SOFTWARE ARCHITECTURE OVERVIEW ................................................................... 287 FIGURE 17: ILLUSTRATION OF DEPLOYMENT ............................................................................................ 288 FIGURE 18: SCP HIGH LEVEL COMPONENTS (VIGIER, 2014) ................................................................... 298 FIGURE 19: ILLUSTRATION OF SOFTWARE PROVISIONING WORKFLOW FOR BOSCH SCP ........................... 298 FIGURE 20: USED TECHNOLOGIES IN BOSCH SCP .................................................................................. 299 FIGURE 21: HIGH-LEVEL ARCHITECTURE OF SDP .................................................................................... 309 FIGURE 22: SDP SUPPORTED PROTOCOLS.............................................................................................. 312 FIGURE 23: FIWARE PLATFORM ARCHITECTURE OVERVIEW ................................................................... 320 FIGURE 24: FIWARE IOT SERVICES ENABLEMENT ARCHITECTURE OVERVIEW ......................................... 321 FIGURE 25: OPENIOT ARCHITECTURE ..................................................................................................... 330 FIGURE 26: PUB/SUB METHOD AT OPENIOT ............................................................................................ 331 FIGURE 27: OPENIOT IDE (INTEGRATED DEVELOPMENT ENVIRONMENT) .................................................. 331 FIGURE 28: VODAFONE IOT PLATFORM ARCHITECTURE OVERVIEW .......................................................... 340 FIGURE 29: CAS BLOCK OVERVIEW ....................................................................................................... 341 FIGURE 30: FASTPRK ARCHITECTURE OVERVIEW .................................................................................... 350 FIGURE 31: SENSEFIELDS ARCHITECTURE OVERVIEW ............................................................................. 350 FIGURE 32: BITCARRIER ARCHITECTURE OVERVIEW ................................................................................ 351 FIGURE 33: CLIENT-SERVER REPRESENTATION ...................................................................................... 351 FIGURE 34: TIC MOBILITY PLATFORM - DATA CONTENT ........................................................................... 359 FIGURE 35: TIC MOBILITY PLATFORM COMPONENTS ............................................................................... 360 FIGURE 36: AMAZON RELATIONAL DATABASE SERVICE REPRESENTATION ................................................ 364 FIGURE 37: WUBBY ECOSYSTEM ............................................................................................................ 372 FIGURE 38: WUBBY FRIENDS.................................................................................................................. 373



D2.1

ANNEX

© 2016 6

FIGURE 39: WUBBY FRIENDS.................................................................................................................. 374 FIGURE 40: XIVELY ARCHITECTURE OVERVIEW ....................................................................................... 384 FIGURE 41: XIVELY ARCHITECTURE OVERVIEW 2 .................................................................................... 384 FIGURE 43: ECLIPSE VORTO COMPONENTS ............................................................................................ 394 FIGURE 44: VORTO ARCHITECTURE ........................................................................................................ 394 FIGURE 45: VORTO'S IDEA FOR INTEROPERABILITY .................................................................................. 397

LIST OF TABLES

TABLE 1 GENERAL DESCRIPTION OF TOOLS ............................................................................................ 204 TABLE 2 SOFTWARE ARCHITECTURE AND TOOL EVOLUTION .................................................................... 204 TABLE 3 INTEROPERABILITY .................................................................................................................... 205 TABLE 4 KNOWLEDGE REPRESENTATION ................................................................................................ 206 TABLE 5 INFERENCE SERVICES ............................................................................................................... 207 TABLE 6 USABILITY ................................................................................................................................ 208



D2.1

ANNEX

© 2016 7

1. Concepts Relevant for IoT Platforms

1.1. Communication

1.1.1. Generic Serialization Formats

Extensible Markup Language (XML)

Metadata

Name of the Standard / Technology / Building Block

Extensible Markup Language (XML)

Part of (project, standardization institution, but also: company, etc.?

W3C

URL / bibliography entry / source


General Information

Why is this building block part of BIG-IoT’s SotA?

XML is a very prominent format that is applied in many application domains such as in different kind of

communication protocols (e.g., XMPP, DPWS, OPC UA), UI/graphics (e.g., SVG, Android XML), and

office content (e.g., Office Open XML, OpenDocument).

One of the XML strengths is that the data can be modelled based on the XML Schema language. This

enables to model data and define data structures in a very flexible and at the same time precise man-

ner, this same modeling feature enables a validation of XML instances by comparing models. This is

one of the major reasons why XML is quite established/been adopted in many industry environments.

Provide a short summarizing text about the platform / solution [10-20 lines]

An Architecture/solution figure (optional)




D2.1

ANNEX

© 2016 8

General Information

The structure of (plain-text) XML relies on the XML Info set that derives following main rules:

element is structured by a start tag (<elementName>) and an end tag (</elementName>)

each XML documents/message has only one root element

elements can nest another (child) elements

elements can carry attributes as name/value pair

For each data value a data type can be assigned coming from the XML Schema data type definition

set. This includes types that are well known from programming languages (e.g., boolean, byte,

unsgnedShort, list, etc.). In addition, XML Schema allows defining data types in a very precise manner

such as data ranges and enumerations that can be applied to XML data.

The root element projects contain nested child project elements. Each project element has one attrib-

ute name and a nested element year.

State overview of implementation (e.g., which programming language)

XML has already a rich set of well know tools (e.g., XML validation tools) and library support (e.g., from

Apache).

For which domain was the building block / technology designed and for which is it primarily used? [1-5

lines]

Any

What is the estimated Technology Readiness Level? With Explanation ... [1-5 lines]

Technology Readiness: Technology readiness is usually noted in TRLs (Technology Readiness Lev-

els).

In this deliverable, we will use the TRLs as defined by the European Commission:


annex-g-trl_en.pdf

TRL 9

Which license terms do apply? [1-5 lines]

a) Is the platform open source, and if: which license does apply?





D2.1

ANNEX

© 2016 9

General Information

Yes, is an open W3C standard / recommendation

What is known about the installation base/usage of the Building Block / Technology / Standard? [1-5

lines]

How many networks/devices/ecosystems use this standard? How big are those? Are they interesting in

the IoT, smart city, etc., domain?

Many industry standard uses XML-based messaging (e.g., ISO/IEC 15118 [2], OPC UA [10],...) or IoT

platforms (e.g., OpenIoT, [7]...)

Which tools for developers are provided? [3-10 lines]

There is a rich set of development tools for setting up XML documents (e.g., editors), libraries (e.g.,

XML at Apache), and validation tools.

Supported functionalities

(Provide enough information about how to find them/where they are located. [5-10 lines each])

Identity & Lifecycle management

Platform allows registration / deregistration / update of smart objects as well as the provisioning of iden-

tifiers for new smart objects.

XML is a generic technology that can be involved/used in that functionality.

Discovery

Platform enables the search and finding of smart objects according to user defined search criteria, such

as device type, communication protocol, or security protocols.


If this is supported, please specify additionally:

Supported search types (e.g., ID-based, keyword-based, value comparison, spatial, temporal, complex



D2.1

ANNEX

© 2016 10

General Information

queries)

XML is a generic technology that can be involved/used in that functionality (e.g., XPath [13]).

Access (pull) of measured data

Platform enables the retrieval of (measured) data according to the “pull” communication paradigm.

XML is a generic technology that can be involved/used in that functionality (e.g. in Web Services)..


Supported filter types to query data (e.g., keyword filter, value comparison, spatial, temporal, complex

filter)


Supported data formats (e.g., XML or JSON, or specific schemas such as SenML)

N/A.

Supported access type (e.g., HTTP REST, RPC-style, SOAP, CoAP, SPARQL)


Access (pull) of object metadata

Platform enables the retrieval of metadata according to the “pull” communication paradigm.

XML is a generic technology that can be involved/used in that functionality (e.g. in XMPP).


Supported filter types to query metadata (e.g., keyword filter, value comparison, spatial, temporal,

complex filter)



D2.1

ANNEX

© 2016 11

General Information


Supported metadata formats (e.g., XML or JSON, RDF, or specific schemas such as, SensorML or

SSN)

N/A.



Tasking

Platform enables a client to forward a task definition (= control command) to smart objects. E.g., a task

can change a sampling rate of a sensor, open/close a valve, or lift a robot arm.

N/A

Messaging (Pub/Sub) Services

Platform enables a client to subscribe for data streams from smart objects.

XML is a generic technology that can be involved/used in that functionality


Supported messaging technology (e.g., MQTT, XMPP)

XMPP

Supported data formats.

XML

Event/data processing



D2.1

ANNEX

© 2016 12

General Information

Platform enables processing of data streams from smart objects. It enables a client to receive pro-

cessed data and/or events created by smart objects.




XML

Vocabulary management / Semantic concepts

Platform enables the management of semantic descriptions of concepts such as smart object proper-

ties and/or values for such properties. This could be e.g. a management of a set of tags, a controlled


XML is a generic technology that can be involved/used in that functionality (e.g. RDF/XML).


Security management

Platform enables secure access and usage of smart objects and their data.



Mechanism of authentication and authorization


Mechanism of key management

N/A.



D2.1

ANNEX

© 2016 13

General Information

Charging and Billing

Platform enables billing for offered functionalities (e.g., for creating a user profile or for accessing data

streams).


Reputation Management

Platform supports a mechanism to assess reputation of users, smart object, or data streams. E.g., rep-

utation could be determined through a review process performed by users.


SLA / QoS Management

Platform defines service level agreements (SLA) and/or quality of service (QoS) parameters.

N/A.

JavaScript Object Notation (JSON)

Metadata


JavaScript Object Notation

Part of (project, standardization institution, but also: company, etc?

IETF






D2.1

ANNEX

© 2016 14

General Information


JSON is currently a quite popular data format, especially to exchange data between different kind of

parties (e.g., client and servers).


An Architecture/solution figure ( optional)

JSON is a simple data format that is identical to the code for creating JavaScript objects.

Thus, the JSON syntax has following structure:

Data is in name/value pairs

Data is separated by commas

Curly braces hold objects

Square brackets hold arrays

JSON supports different kind of data types:

number

string

boolean

array

object

null


For almost each programming languages exists tools and libraries to process JSON data.


lines]

JSON is a domain independent data exchange format.

Which business model is followed? [1-5 lines]



D2.1

ANNEX

© 2016 15

General Information

Not relevant here.



els).



annex-g-trl_en.pdf

TRL 9



Is an open standard without any license restrictions?

b) Is the platform commercially available?

No

c) Other relevant license details

No


lines]



Since this is a well-known data format many platforms support JSON to exchange data, e.g., between

client and services.






D2.1

ANNEX

© 2016 16

General Information

For almost each programming languages exists tools and libraries to process JSON data.






JSON is a generic technology that can be involved/used in that functionality.



JSON is a generic technology that can be involved/used in that functionality (e.g. in Web Services).


HTTP REST





SSN)

JSON


HTTP REST



D2.1

ANNEX

© 2016 17

General Information

Tasking






JSON is a generic technology that can be involved/used in that functionality (e.g. CoAP Observe).



Via CoAP Observe


JSON




JSON is a generic technology that can be involved/used in that functionality (e.g. CoAP Observe).



JSON



D2.1

ANNEX

© 2016 18

General Information







Supported data formats for retrieving descriptions of semantic concepts (e.g., RDF, JSON-LD, plain

text)

JSON-LD

Security management





e.g., XML-Security




streams).




D2.1

ANNEX

© 2016 19

W3C Efficient XML Interchange (EXI)

Metadata


W3C Efficient XML Interchange (EXI)


W3C



General Information


IoT platforms that use resource constrained Things in terms of memory, processing capability, and

bandwidth usage needs an efficient data exchange format that is also feasible for such constrained

Things. Traditional data exchange formats known from the Web such as JSON and XML are based on

a plain-text representation that, however, would overwhelm resource constrained Things due to parsing

overhead, memory and network traffic usage.

EXI is one of the well-known approaches to overcome this issues and make the well-known data for-

mats such as XML and JSON (see next Section EXI4JSON) feasible for resource constrained Things.

EXI is established in many Thing-based industry standards such as

ISO/IEC 15118 [2] or SmartGrid Profile 2.0 [5], in IoT consumer products (e.g., Lemonbeat [19]), in IoT

platforms (e.g., OpenIoT [7]), or in general communication protocols (e.g., XMPP).



Similar to plain-text XML, EXI relies on the definition of XML info set. Thus, it contains the equivalent

structure and rules as known from XML, however, compress this in a binary representation (binary

XML). One of the big advantages of EXI is the operation on the binary level. More precisely, the data

can be directly retrieved from the binary representation without the need to transform it back to plain-




D2.1

ANNEX

© 2016 20

General Information

text XML. This feature make it very interesting for the IoT domain that is based on resource constrained

embedded devices. In general, EXI was designed that it simultaneously improves performance and

significantly reduces bandwidth requirements without compromising efficient use of other resources

such as battery life, code size, processing power, and memory.

The following Figure 1shows the conceptual usage of EXI in different application domains (from [3]):

Figure 1: the conceptual usage of EXI in different application domains.

The following Figure 2 shows some numbers, how efficient EXI can be in terms of compression (from

https://www.w3.org/TR/exi-evaluation/):

https://www.w3.org/TR/exi-evaluation/



D2.1

ANNEX

© 2016 21

General Information

Figure 2: EXI compactness compared to Gzipped XML.

The figure compares EXI to Gzipped XML. EXI is consistently smaller than gzipped XML regardless of

document size, document structure or the availability of schema information. In some cases, EXI is

over 10 times smaller than gzip. In addition, EXI works well in cases where gzip has little effect or even

makes documents bigger, such as high volume streams of small messages typical of geolocation, fi-

nancial exchange and sensor applications.


There are many implementations for different kind of programming languages. E.g., Java (e.g., EXIfi-

cient [3], OpenEXI [20]) C/C++ (e.g., EXIP [21]) (e.g., EXIP and EXIdizer (for resource constrained

Things)), C# (e.g., Nagasena [20]), scripting languages (e.g., JavaScript (e.g. exificient.js) and Lua)

[3].


lines]

For resource constrained devices / Things that have a limited memory, processing capability, and

bandwidth. Based on EXI you can rely on XML-based data and exchange this kind of data also in a

IoT-based environment seamlessly.


Make standardized data format feasible also to resource constrained IoT environment.



els).



annex-g-trl_en.pdf

TRL 9

EXI is a W3C standard recommendation (since 2011) with existing many libraries and tools (e.g., EXIfi-

cient [3], OpenEXI [20]).





D2.1

ANNEX

© 2016 22

General Information



EXI is an open source standard with many open source implementations (e.g., EXIficient [3], Open-

EXI).


There exists commercial EXI implementations (e.g., Efficient XML from AgileDelta [22])


lines]



EXI is established in many Thing-based industry standards such as ISO/IEC 15118 [2] or SmartGrid

Profile 2.0 [5], in IoT consumer products (e.g., Lemonbeat [19]), in IoT platforms (e.g., OpenIoT [7]), or

In general communication protocols (e.g., XMPP [6]).


Developer can use the tools that are also provided for XML (e.g., XML Editors, XML Schema valida-

tors, etc.). This is based on the fact, EXI relies on XML-based data structure and can be transformed

easily to a plaint-text representation and vice versa (binary XML)






EXI is a generic technology that can be involved/used in that functionality (similar to XML and JSON).



D2.1

ANNEX

© 2016 23

General Information

Discovery






queries)

E.g., based on XPath [13]






filter)

Using XPath [13]


Binary XML


Almost all access variants can be applied such as HTTP, CoAP, SOAP, RPC-style, SPARQL




D2.1

ANNEX

© 2016 24

General Information





complex filter)

XPath [13]


SSN)

Binary XML



Tasking





Supported tasking approach (e.g., task definitions can be sent as XML via HTTP REST, or specific API

encapsulates device calls)

Independent, e.g., task definitions can be sent as Binary XML via HTTP REST




D2.1

ANNEX

© 2016 25

General Information





That are XML-based e.g., XMPP


XML-based







XML-based





EXI is a generic technology that can be involved/used in that functionality (e.g., RDF/EXI).




D2.1

ANNEX

© 2016 26

General Information


text)

RDF (RDF/EXI)

Security management





e.g., XML-Security can be applied with EXI

Privacy management

Platform provides the foundation for transparency and anonymization functions to protect privacy of the

users.


Please specify how privacy is further protected.

e.g., XML-Security can be applied with EXI



streams).




D2.1

ANNEX

© 2016 27

EXI for JSON (EXI4JSON)

Metadata


EXI for JSON (EXI4JSON)


W3C



General Information


Similar to the motivation of EXI (see previous section) interaction with IoT devices that are resource

constrained in terms of memory, processing capability and bandwidth requires a high efficient data

exchange format. JSON is a quite popular due to JavaScript usage in the web, however, it is not feasi-

ble for such kind of Thing instances to interact with.

EXI4JSON is developed to bring JSON-based data into a binary representation and to make it feasible

to resource constrained Things.



EXI4JSON relies on the concept of the generic EXI approach (see previous section). With a relatively

small set of transformations it may also be used for JSON, a popular format for exchange of structured

data on the Web. Based on this it can be taken the strength of both worlds: the well-established JSON

data exchanged format and high efficient compression format of EXI. Especially, EXI is quite strong to

be efficient in string based encoding and removing redundancy in the data.





D2.1

ANNEX

© 2016 28

General Information

There exists implementation for Java, C, JavaScript and Lua (see webpage [3]).


lines]

For resource constrained devices / Things that have a limited memory, processing capability, and

bandwidth. Based on EXI you can rely on JSON-based data and exchange this kind of data also in a

IoT-based environment seamlessly.


Make standardized data format feasible also to resource constrained IoT environment.



els).



annex-g-trl_en.pdf

TRL 6/7

EXI4JSON started last year to be a standard and will be a recommendation end of this year(! have to

be checked!). Based on the first implementations of EXI4JSON there exists fist prototypes (see [3]).


lines]



Since JSON is a well-known data format many platforms support JSON to exchange data, e.g., be-

tween client and services. EXI can be simple applied to existing JSON implementation.


Same tools can be used as for JSON and for EXI (e.g., EXIficient, JavaScript for JSON parsing, etc).





D2.1

ANNEX

© 2016 29







Discovery








Binary JSON








D2.1

ANNEX

© 2016 30




SSN)

Binary JSON



Tasking







Independent, e.g., task definitions can be sent as Binary XML via HTTP REST






That are JSON-based



D2.1

ANNEX

© 2016 31




JSON-based







JSON-based





EXI is a generic technology that can be involved/used in that functionality (e.g., JSON-LD/EXI).



text)

JSON-LD/EXI, (also see RDF/EXI)

Security management




D2.1

ANNEX

© 2016 32





Privacy management


users.




streams).


1.1.2. Semantic/RDF-based Serialization Formats

RDF/XML

Metadata


RDF/XML


W3C




D2.1

ANNEX

© 2016 33

Metadata


General Information


RDF/XML is one of the popular serialization format for RDF based data.



The W3C RDF/XML standard recommendation defines an XML syntax for RDF. The setup a RDF

statement with RDF/XML the following basic structure is used as example:

The statement is "The usedIoTplatform in http://big-iot.eu/ is OpenIoT. Thus,

The subject of the statement above is: http://big-iot.eu/

The predicate is: usedIoTplatform

The object is: OpenIoT


Almost all RDF-based tools support RDF/XML as serialization formats (e.g., Apache Jena).


lines]

This technology is used in a technology environment where semantic web approaches is used based

on RDF.



els).







D2.1

ANNEX

© 2016 34

General Information

annex-g-trl_en.pdf

TRL9

RDF/XML is a W3C recommendation standard that comes with a broad library support and is used in

many semantic based projects (e.g., OpenIoT [7]).



RDF/XML is an open source W3C standard.


No


No


lines]



Used in many semantic-based applications and platforms (e.g., OpenIoT [7], RES-COM, etc.)


Since RDF/XML relies on XML, XML-based tools can be used. However, there are many RDF tools out

there that supports RDF/XML serializations (e.g., Apache Jena)






D2.1

ANNEX

© 2016 35

General Information

Discovery



RDF/XML is a generic technology that can be involved/used in that functionality, e.g., by using

SPARQL endpoints



queries)

Based on triple search and/or SPARQL





RDF/XML is a generic technology that can be involved/used in that functionality, e.g, by using RDF

triple stores and SPARQL endpoints



text)

All kind of RDF serialization formats.

If ontologies are used, please specify which ones

RDF is the basis technology to define ontologies.

Mechanism to store semantic concepts (e.g., triplestore)



D2.1

ANNEX

© 2016 36

General Information

RDF is typically managed by a triple tore.

Are semantic concepts queryable (e.g., using SPARQL endpoint)

Triple search and SPARQL querying.

JSON-LD

green area

Metadata


JSON-LD


W3C



General Information


JSON-LD is a relative new RDF serialization format and a promising one since it relies on the widely

used JSON data format.






D2.1

ANNEX

© 2016 37

General Information

The W3C JSON-LD standard recommendation defines JSON syntax for RDF. In the following a sample

is shown (also compare with XML/RDF) to setup a RDF statement:

The statement is "The usedIoTplatform in http://big-iot.eu/ is OpenIoT. Thus,

The subject of the statement above is: http://big-iot.eu/

The predicate is: usedIoTplatform

The object is: OpenIoT

In general, JSON-LD provides a pre-defined set of keywords. The most important ones are @context,

@id, and @type:

@context: provides the mapping from JSON to an RDF model

@id: Used to uniquely identify things/subjects

@type: used to set the data type such as a class


Almost all RDF-based tools support also JSON-LD as serialization formats (e.g., Apache Jena).


lines]


on RDF.


Get semantic established where mainly JSON data model is used.



els).



annex-g-trl_en.pdf

TRL9

https://www.ctwiki.siemens.com/pages/viewpage.action?pageId=57409739





D2.1

ANNEX

© 2016 38

General Information

JSON-LD is a W3C recommendation standard.



JSON-LD is an open source W3C standard.


No


No


lines]



There is a huge list of companies/projects that uses JSON-LD: https://github.com/json-ld/json-

ld.org/wiki/Users-of-JSON-LD . JSON-LD is also involved in the current working assumption for the

Thing Description in

the W3C Web of Thing (WoT) group.


Since JSON-LD relies on JSON, JSON-based tools can be used. However, there are JSON-LD tools

out there that supports JSON-LD serializations (e.g., Apache Jena)



Discovery

https://github.com/json-ld/json-ld.org/wiki/Users-of-JSON-LD

https://github.com/json-ld/json-ld.org/wiki/Users-of-JSON-LD



D2.1

ANNEX

© 2016 39

General Information




SPARQL endpoints



queries)






JSON-LD is a generic technology that can be involved/used in that functionality, e.g., by using RDF




text)








D2.1

ANNEX

© 2016 40

General Information



RDF/EXI

Metadata


RDF/EXI


W3C


https://www.w3.org/RDF/ and https://www.w3.org/XML/EXI/

General Information


Traditional RDF serialization formats such as RDF/XML, Turtle, and JSON-LD are based on plain-text

representation. That is not feasible in IoT environments that consist of resource-constrained devices

such as microcontrollers with limited memory, processing capabilities, and bandwidth.



The conceptual idea of this serialization variant is based on the existing (traditional) RDF serializations

https://www.w3.org/RDF/

https://www.w3.org/XML/EXI/



D2.1

ANNEX

© 2016 41

General Information

variants such as RDF/XML and JSON-LD and simple apply them with the coding mechanism of EXI or

EXI4JSON respectively.

EXI strength is the reduction of string-based content as well redundancy. Semantic based data are

dominated by string-based contents (especially URIs).To make semantics also efficient applicable to

resource constrained devices EXI can be applied.


Almost all RDF, XML, JSON, and EXI-based tools can be used to apply this approach.


lines]

This technology is used in a resource-constrained environment such as IoT.


To make semantics efficient available to resource constrained IoT environment (e.g., small microcon-

troller).



els).



annex-g-trl_en.pdf

TRL9

Approach relies on existing and finished standards (from W3C)



RDF, JSON-LD, XML, and EXI are open source W3C standard.


https://www.ctwiki.siemens.com/display/BIGIoT/JSON-LD

https://www.ctwiki.siemens.com/display/BIGIoT/EXI

https://www.ctwiki.siemens.com/display/BIGIoT/EXI4JSON





D2.1

ANNEX

© 2016 42

General Information


No


No


lines]



EXI is established in many Thing-based industry standards such as ISO/IEC 15118 [2] or SmartGrid

Profile 2.0 [5], in IoT consumer products (e.g., Lemonbeat [19]), in IoT platforms (e.g., OpenIoT [7]), or

in general communication protocols (e.g., XMPP [6]).


Similar to JSON-LD, XML, RDF, and EXI (see above).



Discovery




SPARQL endpoints




D2.1

ANNEX

© 2016 43




queries)










text)










D2.1

ANNEX

© 2016 44

Triple-based representation (Turtle)

Metadata


Triple-based representation (Turtle)


W3C



General Information


One of the common used RDF serialization variants.



A Turtle document is a textual representations of an RDF graph that not follows basic data model struc-

ture such as from XML and JSON. E.g., to represent the statement "The usedIoTplatformin http://big-

iot.eu/ is OpenIoT (see example above) the


Almost all RDF-based tools support Turtle as serialization formats (e.g., Apache Jena).


lines]





D2.1

ANNEX

© 2016 45

General Information

on RDF.



els).



annex-g-trl_en.pdf

TRL9

Turtle is a W3C recommendation standard and supported in many semantic web based tools (e.g.,

Protégé, and Apache Jena).



Turtle is an open source W3C standard.


No


No


lines]



Almost everywhere where semantic web approaches is used. Typically, Turtle is always supported as a

serialization variant.





D2.1

ANNEX

© 2016 46

General Information


Simple editor tools can be used to setup/read Turtle triples as well as to process some with established

Web Semantic tools (e.g., Apache Jena)



Discovery




SPARQL endpoints



queries)










text)



D2.1

ANNEX

© 2016 47

General Information








1.1.3. Web based Technologies

SOAP-based Web Services

Metadata


SOAP-based Web Services


W3C



General Information





D2.1

ANNEX

© 2016 48

Metadata

At the beginning of the Web 2.0 era interacting with Web Services were mainly based on SOAP-based

protocols. Still SOAP is one of the prominent approaches to realize Web Services (e.g., used by Ama-

zon Web Services [9], Google AdWords [11], OPC UA [10]).



The basic technologies of SOAP-based Web Services (WS) are:

XML: description format of the exchanged data (SOAP) and service metadata (XSD, WSDL)

XML Schema: Defines data type of the exchanged data between client and services (used in the

WSDL)

WSDL: Web service description language that describes what kind of services are served and what

kind of data is consumed and/or produced

SOAP: Message exchange protocol to transport the data between server and client

UDDI: lists what for services are available (in practices, not that used)

The basic architecture of this approach can be seen in the following Figure 3:

Figure 3: the basic architecture of SOAP-based Web Services.

The service provider (Web Service) sends a WSDL file to UDDI. The service requester (client) requests

UDDI to find for some particular kind of data it needs, and then it contacts the Web service using the

SOAP protocol. The service provider validates the service request and sends structured data back in

an XML file, using the SOAP protocol that is transported via HTTP. This XML file would be validated

again by the service requester using an XSD file.

The interesting part is that SOAP-based Web Services comes with many additional standards to inte-



D2.1

ANNEX

© 2016 49

Metadata

grate protocols for particular kind of use cases such as Security, Discovery, and Addressing (also see

WS-* [8]).


For almost each programming languages exists Web Service tools and libraries (e.g., Apache Axis,

gSOAP)


lines]

Interaction between client and services.


It is based on open source technologies provided by the W3C to reach a high acceptance and interop-

erability in the web.



els).



annex-g-trl_en.pdf

TRL9

SOAP-based Web services are based on standard recommendations of W3C and used in many appli-

cations.



Yes, open standard (W3C)






D2.1

ANNEX

© 2016 50

Metadata

lines]



Small selection is: Amazon Web Services [9], Google AdWords [11], OPC UA [10], DPWS [12]


There exists many tools for developers:

Apache Axis

gSOAP

Java Web Service






For this propose the concept of UDDI is used.

Discovery



WS-* provides functionality for discovery, such as WS-Discovery [14]



queries)



D2.1

ANNEX

© 2016 51



Different search mechanism can be realized via SOAP-based Web services such as SQL- and/or

SPARQL-based search mechanism (e.g., SPARQL Protocol for RDF).



Yes, SOAP-based WS are mainly based on request/response message pattern.



filter)

Supports the embedding of XPath mechanism [13].


Mainly based on XML-based messaging and/or binary XML with EXI cab is applied.


HTTP+SOAP, CoAP+SOAP are also possible. SPARQL can be also embedded in the message pat-

tern.



Yes, SOAP-based WS are mainly based on request/response message pattern.



complex filter)

https://www.ctwiki.siemens.com/pages/createpage.action?spaceKey=BIGIoT&title=x&linkCreation=true&fromPageId=57901217



D2.1

ANNEX

© 2016 52



Supports the embedding of XPath mechanism [13].


SSN)

Mainly based on XML-based messaging and/or binary XML with EXI cab be applied.


HTTP+SOAP, CoAP+SOAP is also possible. SPARQL can be also embedded in the message pattern.

Tasking



This is possible by defining well-defined function on the WS.




Tasks can be sending via SOAP/XML and or a script can be send as a value within the SOAP/XML

document.



Using WS-Brokered Notification [15] allows enables this kind of pub/sub mechanism





D2.1

ANNEX

© 2016 53



Based on SOAP/XML


XML




Using WS-Notification [15] allows pub/sub.



Based on SOAP/XML

Is a client-side processing configuration supported? (e.g., through definition of events)

XML



text)

RDF/XML

Security management


WS-Security [16] framework provides security tools to SOAP-based Web Services.



D2.1

ANNEX

© 2016 54





It can be used XML-Signature [17] and XML-Encryption [18].

Privacy management


users.

XML-Encryption [18] can be applied.

REST-based Web Services

Metadata


Representational state transfer (REST)



General Information




D2.1

ANNEX

© 2016 55

General Information

REST is an architecture style for designing networked applications that is mainly based on the principal

of the well-known HTTP.



A REST Server provides access to resources and REST client accesses and presents the resources.

Each resource is identified by URIs. Following well known HTTP methods are commonly used in REST

based architecture:

GET: reads a resource

PUT: create a new resource

POST: update or creates a new resource

DELETE: remove a resource

Web services following REST architecture are known as RESTful web services.

CoAP is an alternative to HTTP and more used in resource constrained IoT environment. CoAP relies

on the same basic method as HTTP. More details about CoAP can be found in Section XX (CoAP).


REST is typically realized is RESTful-based Web Services based on standard HTTP methods.


lines]

Interaction between server and clients that can you find almost all application domains (home/building

automation, industry, etc.)


Open Source, get wide acceptance in the Web to reach interoperability.



els).

https://www.ctwiki.siemens.com/display/BIGIoT/CoAP



D2.1

ANNEX

© 2016 56

General Information



annex-g-trl_en.pdf

TRL9. The Web mainly is based on the REST-approach using HTTP.



Yes


lines]



Each Web page in the web is based on the REST-Web service approach.


There exist well-adopted specification frameworks to allow code generation, automatic validation and

various deployment features of RESTful Web services. Among others:

Open API Initiative (OAI), formerly known as Swagger, see http://openapis.org/

RESTful API Modeling Language (RAML), see http://raml.org/

Hydra W3C Community Group, see http://hydra-cg.com/








http://openapis.org/

http://raml.org/

http://hydra-cg.com/



D2.1

ANNEX

© 2016 57

General Information

For REST-based approaches exist many frameworks to manage this. E.g., for CoRE Resource Directo-

ry [1]

Discovery



A simple discovery functionality (based on the resources of a REST-Web services) can be done by

CoRE Resource Directory [1]



queries)

Simple resource search possible within a CoRE Resource Directory [1]



Yes, REST is mainly based on request/response message pattern.


Data format independent. All data format can be transmitted.



Yes, REST is mainly based on request/response message pattern.




D2.1

ANNEX

© 2016 58

General Information


SSN)

Data format independent. All data format can be transmitted.



HTTP itself do not support pub/sub, however, CoAP comes with a pub/sub mechanism called Observe

[ x ]


Format independent. All data format can be transmitted.

Security management


HTTPS and DTL can be used to enable secure communication.

WebSockets

Metadata


WebSockets


W3C standardization




D2.1

ANNEX

© 2016 59

Metadata

RFC6455

https://en.wikipedia.org/wiki/WebSocket

General Information


WebSockets is a full-duplex, frame-based communication vehicle for efficient transmission of data and

always-online scenarios.



WebSockets use HTTP for connection establishment that implicates compatibility with most corporate

firewalls and security guidelines. Instead of breaking down the connection after receiving a server re-

sponse, HTTP connections are promoted to WebSocket connections that remain open - just like stand-

ard socket connections.

Similar to HTTP a secure flavour of WebSockets (WS) based on TLS/SSL is available - Secure Web-

Sockets (WSS).

The WebSocket protocol provides a frame-/message-based abstraction to communication, i.e. users

don't need to define basic transmission protocols as with plain socket connections where termination

flags or length fields need to be transmitted in order to allow detection of the end of a message.


WebSocket is a released W3C standard with support in all-major programming environments (JVM,

.NET, native, Ruby, Python, etc.)


lines]

WebSockets were designed for HTTP-based connectivity involving either

transmission of large data quantities,

bi-directional communication (active push from server -> client), or


https://en.wikipedia.org/wiki/WebSocket



D2.1

ANNEX

© 2016 60

General Information

always-on scenarios


N/A



els).



annex-g-trl_en.pdf

TRL-9

WebSockets are a well-established and proven W3C standard with wide adoption across various do-

mains - predominantly highly interactive web-applications.



Simplified BSD


There are commercial offerings including WebSocket connectivity, but due to the vast availability of

open-source alternatives it is optional to resort to commercial offerings.


N/A


lines]






D2.1

ANNEX

© 2016 61

General Information


Vast distribution among modern web-application.

Several IoT solutions feature WebSocket-based connectivity among other connectivity options (e.g.

PTC Thingworx).


none required






N/A

Discovery



N/A



WebSockets are bi-directional - once the connection is established, bother client and server can push

and pull data.




D2.1

ANNEX

© 2016 62

General Information


filter)

N/A


WebSockets are agnostic of the underlying data format. - There are no specific limitations in message

size and type.


WebSockets is a dedicated protocol (comparable to REST or CoAP) Connection establishment via

HTTP, after that message-based communication via stream is supported.



WebSockets are bi-directional - once the connection is established, bother client and server can push

and pull data.



complex filter)

N/A


SSN)

N/A




D2.1

ANNEX

© 2016 63

General Information

N/A

Tasking



WebSockets are bi-directional - perfect infrastructure to issue server-sent commands to clients.




WebSockets are data format independent and can exchange any messages. - Commands are simply

messages which can be defined freely in context of a solution, such as BigIoT



Since WebSockets are a connection-based protocol, established connections remain open until closed.

This effectively allows pub/sub scenarios where data is continuously sent (published) over an opened

connection.



WebSockets is the messaging technology


any




D2.1

ANNEX

© 2016 64

General Information



Yes, WebSockets are perfectly appropriate for stream processing due to their stateful and connection-

based nature.



Any


WebSockets are agnostic of server- and client-side semantics - they are a pure means of stream-

based and bi-directional connectivity.





N/A



text)

Any


Any



D2.1

ANNEX

© 2016 65

General Information


N/A


N/A

Security management


Security available through Secure WebSockets (WSS) that use TLS/SSL under the hood - similar to

HTTPS.



same as with HTTPS


same as with HTTPS

Privacy management


users.

N/A


N/A



D2.1

ANNEX

© 2016 66

General Information



streams).

N/A




N/A



N/A

HTTP/2.0

Metadata


HTTP/2.0


W3C




D2.1

ANNEX

© 2016 67

Metadata


https://en.wikipedia.org/wiki/HTTP/2

General Information


HTTP/2 is a full-duplex, frame-based communication vehicle for efficient transmission of data and al-

ways-online scenarios.



Historically HTTP was designed as a stateless (hence connection-less) protocol, which continuously

creates new server connections for each request/response. This has proven utmost inefficient. In order

to improve the connectivity performance, HTTP/1.1. was released which introduced connection re-use.

Basically, connections are not discarded after successful request/response, but kept open for a short

time in order to be re-used in subsequent requests, alleviating these requests from establishing their

connections from scratch again.

HTTP/2 is W3C's most recent version of HTTP (released summer 2015) to improve the performance of

the web even further and also to support bi-directional communication. Prior to HTTP/2 this was only

possible via WebSockets and HTTP-based solutions that often rely on message chunking and partial

responses (e.g. SSE - Server Sent Events, Long-Time Polling, etc.). None of these approaches, how-

ever, have proven simple to implement, manage, and secure.

HTTP/2, on the contrary, is based on Google's very own SPDY protocol that is basically a streaming

protocol very similar to WebSockets. Unlike WebSockets, SPDY retained the basic capabilities of

HTTP messages (headers, body, etc.) but introduced more efficient means of transmitting these mes-

sages. Due to its stateful and connection-based principle, SPDY was highly efficient compared to

HTTP/1 and HTTP/1.1. Instead of creating multiple server connections, clients created only a single

SPDY connection that was kept open and used for multiple requests & responses concurrently.

HTTP/2 is largely based on the same principles of SPDY that specific changes introduced by the W3C.

The main benefits over previous version of HTTP are:

improved performance

built-in support for bi-directional communication as 1st-class citizen (e.g. push events from servers to


https://en.wikipedia.org/wiki/HTTP/2

https://www.ctwiki.siemens.com/display/BIGIoT/WebSockets

https://en.wikipedia.org/wiki/SPDY



D2.1

ANNEX

© 2016 68

General Information

clients)

possibility for highly interactive use-cases

retain the concepts of HTTP (headers, body, request/response, etc.) on top of a true streaming protocol


standard released in May 2015


lines]

high-performance eb


N/A



els).



annex-g-trl_en.pdf

TRL-8

W3C standard is out - currently support for HTTP/2 in technologies and frameworks is being built up.

The majority of web-browsers already support HTTP/2.



Simplified BSD






D2.1

ANNEX

© 2016 69

General Information

N/A


N/A


lines]



As of Feb 2016, ~7% of the world's top 10M websites are already based on HTTP/2. Since the stand-

ard was only released in 2015, expectations are that HTTP/2 will spread rapidly.


N/A - basic REST tooling remains compatible






N/A

Discovery



N/A



D2.1

ANNEX

© 2016 70

General Information



queries)

N/A



HTTP/2 is bi-directional - once the connection is established, bother client and server can push and pull

data.



filter)

N/A


Any


HTTP/REST



HTTP/2 is bi-directional - once the connection is established, bother client and server can push and pull

data.



D2.1

ANNEX

© 2016 71

General Information



complex filter)

N/A


SSN)

Any + HTTP headers


HTTP/REST

Tasking



HTTP/2 is bi-directional - perfect infrastructure to issue server-sent commands to clients.




REST



HTTP is connection-based (connection remains open) -> publish/subscribe scenarios are supported



D2.1

ANNEX

© 2016 72

General Information



HTTP/2 messages


Any




Yes, HTTP/2 is perfectly appropriate for stream processing due to their stateful and connection-based

nature.



Any


HTTP/2 compliant client- & server-libraries are required. - Since only HTTP frames are transmitted, the

interpretation as commands/events/anything else is supported implicitly.





N/A



D2.1

ANNEX

© 2016 73

General Information



text)

Any


Any


N/A


N/A

Security management


HTTPS is still applicable to HTTP/2 - basically TLS/SSL is used under the hood for establishing a se-

cure socket connection.



Same as HTTP/1.1


Same as HTTP/1.1



D2.1

ANNEX

© 2016 74

General Information

Privacy management


users.

N/A


Secure connections via HTTPS



streams).

N/A




N/A

1.1.4. Messaging Frameworks/Services

CoAP

Metadata


Constrained Application Protocol (CoAP)



D2.1

ANNEX

© 2016 75

Metadata


IETF



General Information


CoAP is a quite new application layer protocol and it is already quite established in IoT environments

since it is based on the concept of HTTP, however, it is feasible for a resource constrained environ-

ment because

Its binary header format.



CoAP provides a request/response interaction model between application endpoints, supports built-in

discovery of services and resources, and includes key concepts of the Web such as URIs and Internet

media types. The base header has a size of 9 bytes and can be seen in the following Figure in the first

row. It consist of a version number (ver), type (t) such as Confirmable and Acknowledgement, token

length (tkl) that indicates the length of the variable-length Token field, code (e.g., for a response code),

and a message id.




D2.1

ANNEX

© 2016 76

General Information

After the base header, an optional token can be used to correlate requests and responses, and option-

al options in an optimized Type-Length-Value format (e.g., to define the content-type of the payload).

The actual payload of the message can be found after the one-byte Payload Marker (0xFF).

In addition, there exists an extension of the


There exists many implementations for different kind of programming languages, even for resource

constrained Things. Californium (Cf) is one of the well known reference implementation of CoAP in

Java.


lines]

CoAP is manly used in resource constrained environment such as in IoT where memory, processing

capability, and bandwidth is an issue.


Make seamless REST-based Web services possible for resource constrained (IoT) devices in terms of

memory, processing, and bandwidth usage.



els).



D2.1

ANNEX

© 2016 77

General Information



annex-g-trl_en.pdf

TRL9

CoAP is a finished RFC standard that comes with many implementations and is used in many stand-

ards.



CoAP is an open standard. No license is necessary.


No


No


lines]


Similar to http, for CoAP exists many libraries (e.g. Californium) and modules to setup a CoAP-based

communication.









D2.1

ANNEX

© 2016 78

General Information


CoRE Resource Directory [x ] enables to register and mange resources/Things from CoAP.

Discovery



CoRE Resource Directory [x ] can be used for discovery.



queries)

Uses keyword-based search.



CoAP can be used for request/response mechanism.


Can transport any data formats.


REST-based







D2.1

ANNEX

© 2016 79

General Information

CoAP can be also used only for pull mechanism (one-way message transport).



SSN)



REST-based



Yes, CoAP can be used with the Observe [x] mechanism.







Yes, CoAP can be used with the Observe [x] mechanism.





D2.1

ANNEX

© 2016 80

General Information


XMPP


extensible Messaging and Presence Protocol (XMPP)


The XSF homepage is available at https://www.xmpp.org. The most up-to-date XMPP core specifica-

tions are available as IETF maintained RFCs, namely RFC 6120, RFC 6121, and RFC 6122. An

overview of all XEPs is available at http://xmpp.org/extensions/index.html.


The XSF homepage is available at https://www.xmpp.org. The most up-to-date XMPP core specifica-

tions are available as IETF maintained RFCs, namely RFC 6120, RFC 6121, and RFC 6122. An

overview of all XEPs is available at http://xmpp.org/extensions/index.html.

Why is this building block part of BIG-IoT’s SotA? How can it be used in BIG IoT?

While XMPP has his origins in instant messaging, it has developed into a general purpose messag-

ing platform used in a broad range of application domains including the IoT. It is characterized by a

decentralized highly scalable and modular architecture. Mature implementations are available for a

broad range of languages and runtime environments including some that are backed by companies.

In particular the standardization process based on comparatively small and focused extensions to

the core specification has led to numerous adaptations and broad adoption.




http://xmpp.org/rfcs/rfc6120.html



http://xmpp.org/extensions/index.html





http://xmpp.org/extensions/index.html



D2.1

ANNEX

© 2016 81

Figure 4: XMPP protocol representation


Client libraries (70+) and server Implementations (25+) are available in a plethora of languages. An

overview is available at http://xmpp.org/software. There are carrier-grade commercial server imple-

mentations available with clustering and high availability support, e.g. ejabberd from process one

(see https://www.process-one.net/en/). There are deployments of XMPP-based infrastructures with

billions of users (see http://xmpp.org/software/projects.html).

For which domain was the building block / technology designed and for which is it primarily used? [1-

5 lines]

XMPP has its origin in instant messaging. Today it is used for all kinds of applications including e.g.

IoT (see http://www.xmpp-iot.org/) and SIP/WebRTC-based Conferencing

(seehttp://sylkserver.com/).


The XSF is a non-profit standards development organization funded by a number of sponsors (see

http://xmpp.org/community/sponsors.html).


XMPP is by all means on TRL 9 (very large commercial deployments).


http://xmpp.org/software

https://www.process-one.net/en/


http://xmpp.org/software/projects.html

http://www.xmpp-iot.org/

http://sylkserver.com/

http://xmpp.org/community/sponsors.html



D2.1

ANNEX

© 2016 82


The core specifications are as IETF standards open standards. The extension protocols (XEPs) are

published under a permissive license called the Intellectual Property RIghts (IPR) policy

(seehttp://xmpp.org/about/xsf/ipr-policy). Implementations are available under various licenses

(Commercial, AL, GPL, AGPL, MIT, etc.)


Commercial implementations are available most notably ejabberd from process one (see

https://www.process-one.net/en/)


lines]

How many networks/devices/ecosystems use this standard? How big are those? Are they interesting

in the IoT, smart city, etc., domain?

There are deployments of XMPP-based infrastructures with billions of users (see

http://xmpp.org/software/projects.html). These are mainly focused on instant messaging. In addition

several XMPP-based IoT platforms are available (see http://www.xmpp-iot.org/backers/).


Clients’ libraries (70+) and server Implementations are (25+) available in a plethora of languages. An

overview is available at http://xmpp.org/software. Servers often come with a management console

that can be used for monitoring and basic debugging. For network-level debugging a Wireshark pro-

tocol dissector is available (see https://www.wireshark.org/docs/dfref/x/xmpp.html).


Platform allows registration / deregistration / update of smart objects as well as the provisioning of

identifiers for new smart objects.

XMPP servers provide means for registering/unregistering users. Relationships among users can be

expressed using rosters (friends). Things in XMPP IoT are modelled as users and can have an arbi-

trary number of attributes. Identifiers for users are in the form of email addresses, i.e. <us-

er/thing>@somexmppserver-domain. If no user id is provided during registration a username is gen-

erated automatically.

http://xmpp.org/about/xsf/ipr-policy



http://xmpp.org/software/projects.html

http://www.xmpp-iot.org/backers/

http://xmpp.org/software

https://www.wireshark.org/docs/dfref/x/xmpp.html



D2.1

ANNEX

© 2016 83

Discovery

Platform enables the search and finding of smart objects according to user defined search criteria,

such as device type, communication protocol, or security protocols.

XEP-0030 defines a generic discovery mechanism to retrieve information about XMPP entities in-

cluding users/things.


Supported search types (e.g., ID-based, keyword-based, value comparison, spatial, temporal, com-

plex queries)

The main search type is by namespace.



XMPP includes a generic request/response mechanism. This mechanism can be used to perform

queries. The details for the IoT domain are defined in XEP-0323 (seehttp://xmpp.org/extensions/xep-

0323.htm).


Supported filter types to query data (e.g., keyword filter, value comparison, spatial, temporal, com-

plex filter)

The data is fetched using a namespace describing the information type of interest. Example:

<iq type='get'

from='[email protected]/amr'

to='[email protected]'

id='S0001'>

<req xmlns='urn:xmpp:iot:sensordata' seqnr='1' momentary='true'/>

</iq>

Triggers the response from the target entity

http://xmpp.org/extensions/xep-0323.htm

http://xmpp.org/extensions/xep-0323.htm



D2.1

ANNEX

© 2016 84

<message from='[email protected]'

to='[email protected]/amr'>

<fields xmlns='urn:xmpp:iot:sensordata' seqnr='1' done='true'>

<node nodeId='Device01'>

<timestamp value='2013-03-07T16:24:30'>

<numeric name='Temperature' momentary='true' automaticReadout='true' value='23.4' unit='°C'/>

</timestamp>

</node>

</fields>

</message>


XML


XMPP IQ Protocol



See Discovery.



complex filter)

See Discovery.


SSN)

XML



D2.1

ANNEX

© 2016 85

Tasking

Platform enables a client to forward a task definition (= control command) to smart objects. E.g., a

task can change a sampling rate of a sensor, open/close a valve, or lift a robot arm.

This can be done using the same mechanism as for pulling measured data (see XEP-0325,

http://xmpp.org/extensions/xep-0325.html). In this case, however, a set IQ stanza is sent to the tar-

get entity. Example

<iq type='set'

from='[email protected]/amr'

to='[email protected]'

id='1'>

<set xmlns='urn:xmpp:iot:control' xml:lang='en'>

<boolean name='Output' value='true'/>

</set>

</iq>

In this example the value "true" is written to the "Output" field of the target entity.


Supported tasking approach (e.g., task definitions can be sent as XML via HTTP REST, or specific

API encapsulates device calls)

Writes to a field of the target entity. The value is specified using XML.



XEP-0060 specifies a publish/subscribe extension (see http://www.xmpp.org/extensions/xep-

0060.html).



http://xmpp.org/extensions/xep-0325.html

http://xmpp.org/extensions/xep-0325.html

http://www.xmpp.org/extensions/xep-0060.html

http://www.xmpp.org/extensions/xep-0060.html



D2.1

ANNEX

© 2016 86

XMPP, obviously.


XML




Not directly. However, using Pub/Sub raw data can be received on one topic by a processor that

processes the raw data and then publishes the result on another topic.



XML


No


Platform enables the management of semantic descriptions of concepts such as smart object prop-

erties and/or values for such properties. This could be e.g. a management of a set of tags, a con-

trolled vocabulary, or ontologies.

No

Security management


Pub/Sub allows for fine-grained per topic control over access rights using a concept called affilia-

tions.



D2.1

ANNEX

© 2016 87



Authentication is done by the server using a Password-based login step. Authorization is based on

per topic affiliation lists.


User/password database on server.

Privacy management

Platform provides the foundation for transparency and anonymization functions to protect privacy of

the users.

No


Platform enables billing for offered functionalities (e.g., for creating a user profile or for accessing

data streams).

No (except the specification of "payment required" error conditions in e.g. the Pub/Sub protocol).


Platform supports a mechanism to assess reputation of users, smart object, or data streams. E.g.,

reputation could be determined through a review process performed by users.

No



QoS is not built into the core protocol specification. However, there are two draft/experimental XEPs

(XEP-0184, XEP-0333) that provide extensions for QoS wrt. message delivery guarantees. SLAs



D2.1

ANNEX

© 2016 88

(e.g. wrt. availability) are offered by SaaS offerings from commercial XMPP providers like process

one (see https://www.process-one.net/en/).

MQTT

Metadata


MQTT (Message Queue Telemetry Transport)


MQTT v3.1.1 is an OASIS Standard


http://mqtt.org/

General Information


The MQTT protocol is a candidate for publish/subscribe based communication among BIG IoT entities.



MQTT is a broker-based Message-oriented-Middleware (MoM) that focuses on the publish-subscribe

pattern (see Figure 5). The broker is responsible for distributing messages to interested clients based

on the topic of a message. Due to its small code footprint it is designed for constrained client devices

(e.g. sensors) with limited processing and storage capabilities. Furthermore, MQTT is a “lightweight”

messaging protocol on top of TCP/IP for bandwidth limited networks (e.g. wireless).


http://mqtt.org/



D2.1

ANNEX

© 2016 89

General Information

Figure 5: MQTT Clients B and C subscribing to Topic "temperature." two cases

Figure 5a“MQTT Clients B and C subscribe to Topic "temperature." Figure 5b: MQTT Client A publish-

es a message with the Topic "temperature"; the MQTT Broker will distribute this Clients B and C.

[Source of figures: https://eclipse.org/community/eclipse_newsletter/2014/february/article2.php]

The MQTT protocol and the predominant broker, Mosquitto, were originally developed by IBM and as

of November, 2014, MQTT v3.1 is an OASIS standard. Mosquitto has been released as open source

and the development and support of Mosquitto are now under the Eclipse Foundation. Since the history

of the MQTT Protocol and Mosquitto broker are interlinked, sometimes the two can get confused in

technical documentation, but there are multiple independently developed broker and client implementa-

tions for various languages.

As a protocol, MQTT is “designed to minimize network bandwidth and device resource requirements

whilst also attempting to ensure reliability and assurance of delivery”. MQTT support multiple levels of

message delivery guarantee, called “QoS levels.” The following three QoS levels are supported: 0 (at

least once), 1 (at most once), and 2 (exactly once). Subscribers can specify the lowest QoS they are

willing to expect and senders set a QoS level on a per message basis.

The most prominent feature of MQTT is its support for communication environments where loss of

connectivity is common (e.g. in mobile applications). MQTT support loss of connectivity scenarios by:

Persisting messages on the client side once a client has been disconnected and then transparently

sending them once the connection has been re-established.

https://eclipse.org/community/eclipse_newsletter/2014/february/article2.php



D2.1

ANNEX

© 2016 90

General Information

Persisting messages and holding them on the server side once a client has been disconnected and

then delivering them once the client re-connects.

A “Last Will and Testament” feature in which a pre-registered message can be sent to a particular topic

once a client disconnects. This effectively allows clients to notify other clients that they have become

disconnected, thus allowing the overall application to adjust behaviour.

Even though it is designed for constrained environments, MQTT also supports large message sizes

(e.g. 256 MB in the case of Mosquitto), allowing large data files to be relayed from remote nodes. The

MQTT protocol has growing support with connector implementations for a number of established mes-

sage brokers such as ActiveMQ, RabbitMQ, etc. However, MQTT lacks many of the “enterprise” mes-

saging features that many developers and architects may be familiar with in some of the more estab-

lished brokers. These features include message persistence, transactions, and message queues.

However, it is the lack of these features that allows MQTT to have lean implementations and its QoS

and loss-of-connectivity features help to solve similar issues, especially for IoT applications.


MQTT Client libraries are available for in most platforms and many programming languages, Java,

JavaScript, Node.js, C/C++, Erlang, Ruby, and Swift.


lines]

For now specific domain, but the protocol was optimized for constrained devices (bandwidth and power

constrained) and low-bandwidth, high-latency or unreliable networks.


MQTT is open source. Companies who develops commercial MQTT brokers make revenues through

licensing of their products. Companies with open source MQTT broker implementation target consul-

tancy business.



els).






D2.1

ANNEX

© 2016 91

General Information

annex-g-trl_en.pdf

TRL 9, as MQTT is heavily used by many commercial applications.



The protocol is open. Open source implementations for both MQTT clients and brokers are available.


Yes, companies like IBM, Pivotal, etc. offer also commercial solutions.


N/A


lines]



MQTT is heavily used in many IoT products and solutions.


Open source clients, brokers, libraries, SDKs and documentation (see:

https://github.com/mqtt/mqtt.github.io/wiki/software?id=software)





https://github.com/mqtt/mqtt.github.io/wiki/software?id=software



D2.1

ANNEX

© 2016 92

General Information



MQTT Brokers provides the means for Clients (e.g. devices) to register / deregister themselves. The

standard also supports device authentication using a cryptographically bound identifier.

Discovery



N/A



Yes. MQTT Clients can subscribe to relevant measured data. The MQTT Broker will distribute them as

soon they are published by any client.



MQTT, obviously


MQTT message payloads supports arbitrary data formats.




N/A



D2.1

ANNEX

© 2016 93

General Information





N/A

Security management


TLS and SSL based encryption is used.



The standard also supports device authentication using a cryptographically bound identifier.


N/A

Privacy management


users.

N/A



streams).



D2.1

ANNEX

© 2016 94

General Information

N/A




N/A



MQTT support multiple levels of message delivery guarantee, called “QoS levels.” The following three

QoS levels are supported: 0 (at least once), 1 (at most once), and 2 (exactly once). Subscribers can

specify the lowest QoS they are willing to expect and senders set a QoS level on a per message basis.

AMQP

Metadata


AMQP (Advanced Message Queuing Protocol)


AMAP v1.0 is an ISO/IEC International Standard (ISO/IEC 19464) and OASIS Standard


http://www.amqp.org

General Information

http://www.amqp.org/



D2.1

ANNEX

© 2016 95

General Information


The AMQP protocol is a candidate for publish/subscribe based communication among BIG IoT entities.



AMQP has been designed to efficiently support a wide variety of messaging applications and commu-

nication patterns. Specifically, AMQP supports flow controlled, message-oriented communication

(queuing and routing) with message-delivery guarantees such as at-most-once, at-least-once and ex-

actly-once, as well as support for publish-and-subscribe communication paradigms. AMQP assumes a

reliable underlying transport layer protocol and thus is built on TCP/IP. Authentication and/or encryption

are also based on standard solutions, such as SASL and/or TLS.

AMQP standardizes the wire formats for all types of Message-oriented-Middleware (MoM). AMQP has

been so influential that most major JMS brokers are adopting AMQP as an alternative format to ex-

change messages. AMQP is more than just a messaging protocol in that it “comprises an efficient [b i-

nary] wire protocol that separates the network transport from broker architecture and management”. As

such, it can be thought of as an architecture recommendation as well as a protocol specification.

Figure 6: AMQP is an open Wire Protocol standard for message-queuing

communications for the Internet.



D2.1

ANNEX

© 2016 96

General Information

[Source: https://www.amqp.org/product/overview]

AMQP 1.0 supports both broker-based communication styles with topics and queues as well as peer-

to-peer communication styles. Additionally, it has features that allow for the creation of complex net-

work topologies where local peer nodes can act as routers to other networks. Note that versions of

AMQP prior to 1.0 are broker-only and 1.0 is thought of as a much different protocol than prior ver-

sions. In fact, protocol support for AMQP 1.0 is much lower among the major message brokers, most

notably RabbitMQ, which may never support AMQP 1.0 beyond an experimental plug-in. Likewise,

most AMQP frameworks vary in the protocol version that is supported and as a result, most offer some

kind of protocol negotiation in which frameworks from different vendors can dynamically agree between

each other as to what protocol messages they will exchange.


AMPQ Client libraries are available for in many programming languages, Java, C, Python, Perl, Erlang,

and Ruby.


lines]

For now specific domain, but the protocol was optimized for constrained devices (bandwidth and power

constrained) and low-bandwidth, high-latency or unreliable networks.


AMQP is open source. Companies who develop commercial AMQP brokers make revenues through

licensing of their products. Companies with open source AMQP broker implementation target consul-

tancy business.

What is the estimated Technology Readiness Level? With Explanation ...[1-5 lines]


els).



annex-g-trl_en.pdf

TRL 9, as AMQP is heavily used by many commercial applications.

https://www.amqp.org/product/overview





D2.1

ANNEX

© 2016 97

General Information



The protocol is open. Open source implementations for both MQTT clients and brokers are available.

RabbitMQ is the most known open source broker implementation.


Yes, companies like IBM, Pivotal, etc. offer also commercial solutions. Microsoft uses AMQP for their

Azure Service Bus.


N/A


lines]



AMQP is heavily used in many commercial products and solutions.


Open source clients, brokers, libraries, SDKs and documentation (see:

http://www.rabbitmq.com/devtools.html)






http://www.rabbitmq.com/devtools.html



D2.1

ANNEX

© 2016 98

General Information

AMQP Brokers provides the means for Clients (e.g. devices) to register / deregister themselves.

Discovery



N/A



AMQP can be used to implement a request/response message protocol.



filter)

N/A


AMQP message payloads supports arbitrary data formats.


AMQP



AMQP can be used to implement a request/response message protocol.



D2.1

ANNEX

© 2016 99

General Information



complex filter)

N/A


SSN)



AMQP

Tasking



N/A



Yes. AMQP Clients can subscribe to relevant measured data. The AMQP Broker will distribute them as

soon they are published by any client.



AMQP, obviously



D2.1

ANNEX

© 2016 100

General Information






N/A





N/A

Security management


Encryption is based on standard solutions, such as SSL and/or TLS.



Authentication is based on standard solutions, such as SASL


N/A

Privacy management



D2.1

ANNEX

© 2016 101

General Information


users.

N/A



streams).

N/A




N/A



AMPQ support message-delivery guarantees such as at-most-once (where each message is delivered

once or never), at-least-once (where each message is certain to be delivered, but may do so multiple

times) and exactly-once (where the message will always certainly arrive and do so only once).

RabbitMQ

Meta Data


RabbitMQ



D2.1

ANNEX

© 2016 102


Rabbit Technologies Ltd



General Information


RabbitMQ is a ready-to-use technology for providing messaging services for IoT systems. It is a widely

adopted implementation of the AMQP (Advanced Message Queuing Protocol), which supports scala-

bility and maintainability by decoupling using the messaging pattern. Services and their components

can be dynamically, redundantly and robustly distributed across an arbitrary number of physical serv-

ers. Lightweight clients are supported via an MQTT adapter.






D2.1

ANNEX

© 2016 103

Figure 7: concept of RabbitMQ

.

Refer to https://www.rabbitmq.com/tutorials/amqp-concepts.html for details on the Exchange, Binding

and Queue concepts.


RabbitMQ is written in Erlang using the OTP (Open Telecom Platform), a runtime environment that

supports highly parallel processing without the overhead of processes or threads. Ports are available

for all major platforms.

Clients are available for all major programming languages.


lines]

https://www.rabbitmq.com/tutorials/amqp-concepts.html



D2.1

ANNEX

© 2016 104

High throughput web scale applications.


Open source with support provided by a company which employs the core developers



els).



annex-g-trl_en.pdf

TRL 9. The product is mature, well documented, widely supported and widely used.



Yes, Mozilla Public License


Support provided by Rabbit Technologies Ltd


lines]

How many networks/devices/ecosystems use this standard? How big are those? Are they interesting

in the IoT, smart city, etc., domain?

See the following Figure 10 for a selection of RabbitMQ users.





D2.1

ANNEX

© 2016 105

Figure 8: Selected users of RabbitMQ


Server, server management tools, client libraries for major languages.






This is an enabling technology, not a platform, but is well suited to implement this functionality

Discovery






D2.1

ANNEX

© 2016 106



This is an enabling technology, not a platform, with a primary "push" paradigm, but can nonetheless

be useful for implementing this functionality at scale.



This is an enabling technology, not a platform, with a primary "push" paradigm, but can nonetheless

be useful for implementing this functionality at scale.

Tasking






This is an enabling technology, not a platform, but is primarily designed to help users implement this

functionality



AMQP (native), MQTT (plugin adapter)


Interpretation of payload is user-defined



D2.1

ANNEX

© 2016 107




Yes



Interpretation of payload is user-defined


Clients define topics and filters at run time.





RabbitMQ provides only a messaging solution. Any semantic framework can be used in the payload.

Security management


Pluggable authentication backend include LDAP and http



Varies according to plugin

Privacy management



D2.1

ANNEX

© 2016 108


the users.

Not in scope of RabbitMQ



streams).

Can be implemented using RabbitMQ




Can be implemented using RabbitMQ



Not in scope of RabbitMQ

Apache Kafka

Metadata


Apache Kafka


Apache Foundation



D2.1

ANNEX

© 2016 109

Metadata


http://kafka.apache.org/

General Information


Apache is among the most scalable and reliable middleware in existence today.



Kafka was initially developed by LinkedIn to handle all internal communications of their entire social

network platform. Kafka is a message-oriented-middleware that was built for distribution and scale-out

by design. After being open-sourced, Kafka has proven to scale linearly and provide high robustness in

messaging.

Under the hood Kafka uses Apache Zookeeper for distributed storage of cluster meta-information. Alt-

hough Zookeeper can be painful to manage, it is a solid foundation for operating distributed applica-

tions which require de-central storage of meta-information, such as Kafka.

It's worth to note, that Kafka scales linearly with the underlying disk drives - unlike common MoM solu-

tions - and introduces minimum latency that makes it a perfect fit for real-time and high-performance

communication scenarios.


Kafka has been built in Scala and runs on the JVM. The low-level API is binary, so that libraries for all

major programming platforms exist. Naturally, there are also native Java client libraries.


lines]

Initially Kafka was designed to handle all internal communication at LinkedIn's social network.

Kafka, however, is being used today across industries as a reliable and high-performance communica-

tion backend.




D2.1

ANNEX

© 2016 110

Metadata


N/A



els).



annex-g-trl_en.pdf

TRL-8 - widely adopted across industries.

Despite version number <1.0, Kafka has been heavily used and battle-proven in many domains for

years.



Apache License


Commercial support by Confluent.io and various companies behind the Apache foundation.


lines]



LinkedIn is the inventor of Kafka and heavily relies on it with its internal infrastructure.

Kafka has also been introduced in various production scenarios in the areas of banking and IoT.

Amazon Web Services features Kinesis - a middleware solution with utmost scalability - that is proprie-

tary but built on the very same principles as Kafka.



http://www.confluent.io/



D2.1

ANNEX

© 2016 111

Metadata


SDKs and client libraries






Kafka is communication middleware - these use cases are supported on a generic basis.

Discovery



N/A



queries)

Query and look-ups on streams (topics) are possible



Kafka is bi-directional middleware, so push and pull are possible.




D2.1

ANNEX

© 2016 112




filter)

Filtering and querying on streams and shards is possible


Any


Native API (binary) and client libraries for all major platforms are available.

Confluent also offers a REST front-end for Kafka producers and consumers.



Kafka is bi-directional middleware, so push and pull are possible.



complex filter)

Filtering and querying on streams and shards is possible


SSN)

Any


Native API (binary) and client libraries for all major platforms are available.



D2.1

ANNEX

© 2016 113



Confluent also offers a REST front-end for Kafka producers and consumers.

Tasking



Kafka offers bi-directional connectivity - server-sent commands are supported implicitly.




Kafka is independent of data format.



Supported out-of-the-box



Kafka native format


Any





D2.1

ANNEX

© 2016 114




Stream processing with minimum latency and high load is what Kafka is designed for.

Benchmarks and further tooling around Kafka is available at confluent.io.



Any


Possible, but not necessary





Kafka is agnostic of data modelling.



text)

Any


Any


http://www.confluent.io/



D2.1

ANNEX

© 2016 115



N/A


N/A

Security management


Security is supported through built-in means of authorization and authentication.

However, Kafka is best used internally - inside back-ends - to enable fast, reliable, and high-volume

communication at minimum latency.



Built-in mechanism is proprietary.

If REST-Facade for Kafka is used, standard HTTP/REST means of authentication & authorization are

supported.


N/A

Privacy management


users.

N/A




D2.1

ANNEX

© 2016 116



N/A



streams).

N/A




N/A



N/A

PubNub

Metadata


PubNub


PubNub Inc.



D2.1

ANNEX

© 2016 117

Metadata


www.pubnub.com

General Information


PubNub offers a public publish/subscribe service with the goal to integrate/support many different IoT

platforms/protocols. Publish/subscribe is also an important functionality that is needed in BIG IoT.



PubNub offers a public publish/subscribe service that can be accessed over the Internet. Users of the

service are required to pay a fee based on the number of messages transmitted over the service.


PubNub is a commercial service. The implementation details are not made public.


lines]

Cross-Platform Messaging in transportation, manufacturing, e-commerce, traffic, energy, etc.


PubNub offers a commercial Internet service for public/subscribe.



els).



http://www.pubnub.com/




D2.1

ANNEX

© 2016 118

Metadata

annex-g-trl_en.pdf

TRL8-9: Service is ready and sold to customers over the internet: 1.8 Trillion Messages are transferred

per Month



No


PubNub is offered as a commercial service on the Internet.


lines]



1.8 Trillion Messages per Month

330 Million Unique Devices

15 Global Points of Presence

Used extensively throughout different industries: Adobe, Coca Cola, Insteon, Vimeo, ...

How big are those?

From small to very large (e.g. Coca Cola)

Are they interesting in the IoT/smart city/... domain?

Yes. Some of them.


Development frameworks: 70+ SDKs

Programming languages




D2.1

ANNEX

© 2016 119

Metadata

Microservice Building Blocks






PubNub supports IdM for access control of its publish/subscribe channels. It is a closed system though.

Discovery



N/A



Yes, based on subscriptions to relevant topics/data



filter)

Basic filtering is supported


Adapter for many formats / interfaces exist



D2.1

ANNEX

© 2016 120







N/A

Tasking



N/A



Yes - this is the main service.



Different protocols are supported, e.g. WebSockets, Socket.IO, SignalR, WebRTC Data Channel and

other streaming protocols






D2.1

ANNEX

© 2016 121





N/A





PubNub only defines the basic concepts for publish/subscribe. The payload of the messages is agnos-

tic to specific semantic concepts

Security management


Access control mechanisms as well as secure communication is provided



Encryption:

built-in AES encryption for all major PubNub APIs and optional TLS/SSL encryption

Authorization:

Works with Auth tokens from any existing authentication system: Facebook Connect, Twitter, Google,

LDAP, or homegrown solutions

Grant/revoke permissions for your real time streams at the user/device, channel or key level

Privacy management




D2.1

ANNEX

© 2016 122



users.

N/A


N/A



streams).

Yes, this is the basis for billing the customers of the PubNub service.




N/A



N/A

1.1.5. Event and Stream Processing Frameworks

Apache Spark

Metadata




D2.1

ANNEX

© 2016 123

Metadata

Apache Spark


Apache



General Information


IoT implicates stream processing and Spark is today's most widely used stream processing tool.



Spark is a streaming and stream analytic engine built on top of Akka. It is provided as-a-service by

many popular cloud vendors today for accessing big data lakes and storage infrastructure and pro-

cessing the contained data at fast speed. Due the underlying actor model, Spark is inherently distribut-

able and scalable. Typical benchmarks indicate performance improvements of factors 50-100 faster as

typical Hadoop Map/Reduce processes.

When not connected to data storage, Spark is often used to handle data ingestion in IoT platforms.

Spark is also part of PTC's IoT offering Thingworx which is among the most well-known and adopted

IoT stacks today.


Spark runs on the JVM (Scala + Java code)


lines]





D2.1

ANNEX

© 2016 124

Metadata

Stream processing and data analytics across domains.


N/A



els).



annex-g-trl_en.pdf

TRL-9 - heavily used in popular cloud platforms (Cloudera, Oracle, etc.)



Yes - Apache V2


Via as-a-service cloud offerings, and through Databricks


N/A


lines]



Spark is considered base infrastructure in many cloud environments (e.g. Cloudera).





D2.1

ANNEX

© 2016 125

Metadata

Spark is also part of PTC's IoT offering Thingworx which is among the most well-known and adopted

IoT stacks today.


N/A






N/A

Discovery



N/A



queries)

N/A



Yes



D2.1

ANNEX

© 2016 126





filter)

N/A


Any


SPARQL, R, Java, Scala, Python, HTTP, etc.



Yes



complex filter)

N/A


SSN)

Any




D2.1

ANNEX

© 2016 127



SPARQL, R, Java, Scala, Python, HTTP, etc.

Tasking



N/A




N/A



N/A



N/A


Any





D2.1

ANNEX

© 2016 128




Yes - this is what Spark is designed for



Any


N/A





N/A



text)

Any


Ontologies can be used optionally (Spark does not care about data model).




D2.1

ANNEX

© 2016 129



Any storage tool connected to Spark.

Reactive Streams

Metadata


Reactive Streams


Reactive Manifesto - http://www.reactivemanifesto.org/



General Information


Reactive Streams (RS) is an enhancement to usual communication protocols for supporting overload

protection and flow control.

Since IoT scenarios are known to potentially produce large quantities of communication messages at

high rates, RS is a convenient and industrial means of controlling this communication sprawl and in-

crease client & server robustness.



Reactive Streams is a mechanism to enable stream processing (e.g. of IoT device data) with built-in

flow-control and overload protection.

http://www.reactivemanifesto.org/




D2.1

ANNEX

© 2016 130

Metadata

Reactive Streams is a platform-independent protocol which is already implemented on various plat-

forms (Java. Scala, JavaScript, etc.) and supports polyglot architectures across programming lan-

guages.

The beauty of Reactive Streams is that it prevents applications from breaking down and crashing due

to overload scenarios by introducing throttling mechanisms (e.g. Backpressure) as first class citizens.

Reactive Streams work on a variety of communication protocols, such as REST/HTTP, all kinds of

streams (HTTP/2, SPDY, WebSockets, plain TCP), UDP, and also in combination with message-

oriented middleware (MoM).


The Reactive Streams API has already been implemented for various languages (Java, JavaScript,

Scala, .NET, etc.)


lines]

Cross-domain, for any application involving large numbers of connections and/or continuous data flows

- both applies to IoT.


N/A



els).



annex-g-trl_en.pdf

TRL-8

Atos has built a number of production platforms as well as prototypes which rely exclusively on Reac-

tiveStreams on top of streaming protocols.






D2.1

ANNEX

© 2016 131

Metadata


Depends on implementation - generally the vast majority of implementations are open-source.


Through Typesafe / Lightbend


N/A


lines]



Used mainly in cutting-edge solutions and recent open-source technologies

.NET reactive is a strong driver of the Reactive Manifesto.

Atos has built solutions for customers in various industries (precision agriculture, infrastructure & cities,

automotive) which rely on ReactiveStreams.


N/A






http://www.lightbend.com/



D2.1

ANNEX

© 2016 132



N/A

Discovery



N/A



queries)

N/A



In short: push and pull are supported out of the box.

Under-the-hood, Reactive Streams follows a pull model which is used to implement flow-control.

However, the same applies to other communication technologies (such as message-oriented middle-

ware) which are being considered a push-model while being implemented as a pull-model under the

hood.



filter)

Any




D2.1

ANNEX

© 2016 133



Any


HTTP / REST, any kinds of streams, also works with connection-less protocols, such as UDP or CoAP.



In short: push and pull are supported out of the box.

Under-the-hood, Reactive Streams follows a pull model which is used to implement flow-control.

However, the same applies to other communication technologies (such as message-oriented middle-

ware) which are being considered a push-model while being implemented as a pull-model under the

hood.



complex filter)

Any


SSN)

Any


HTTP / REST, any kinds of streams, also works with connection-less protocols, such as UDP or CoAP.

Tasking




D2.1

ANNEX

© 2016 134




Yes, supported implicitly - no explicit support for commands or tasks required. RS is more generic than

this abstraction.




Any format is possible, RS is agnostic of data format



Yes, supported implicitly - no explicit support for pub/sub required. RS is more generic than this ab-

straction.



MQTT, XMPP, REST, UDP, TCP, etc. are possible options


Any




ReactiveSteams is designed for stream processing (as the name suggests)



D2.1

ANNEX

© 2016 135





Any


N/A





N/A



text)

Any


Any


N/A




D2.1

ANNEX

© 2016 136



N/A

Security management


N/A - security is covered by communication protocol and domain implementation



N/A


N/A

Privacy management


users.

N/A


N/A



streams).

for example, RS can be used to explicitly limit throughput in correlation with pricing (i.e. higher through-



D2.1

ANNEX

© 2016 137



put and shorter latency at higher price)




N/A



N/A

Akka

Metadata


Akka


Lightbend (formerly Typesafe)


http://akka.io/

http://doc.akka.io/docs/akka/2.4.2/scala/stream/index.html

General Information

http://www.typesafe.com/

http://akka.io/

http://doc.akka.io/docs/akka/2.4.2/scala/stream/index.html



D2.1

ANNEX

© 2016 138

Metadata


Actor frameworks, such as Akka, are excellent vehicles to implement server-side IoT functionality due

to their unblocking and concurrent nature.

Akka-Streams is a full-blown implementation of Reactive Streams.



Akka is an actor library. Actors are a long-known concept (since the 70s) which provides an asynchro-

nous & reactive way of processing data. Under the hood, Microsofts IoT stack as well as many other

IoT solutions (e.g. RelayR) is based on actors or concretely Akka.

The purpose of actors is to increase performance by introducing a non-blocking way of processing

ephemeral data chunks (immutable messages). By default this approach is scalable, because Akka

actors are location-transparent and can be scattered/distributed across processing nodes.

Akka-Streams is a built-in vehicle for reactive stream processing based on Akka's actor model.

Akka is also the foundation of Spark - one of the most popular and promising data and stream analytics

platforms today.


Akka has been used in production scenarios since several years across domains (retail, banking, in-

dustry, IoT, analytics).


lines]

Across domains - Akka and Akka-Streams are generic building blocks


Open source but commercial consulting available.

Atos is a long-experienced veteran regarding Akka and Akka-Streams technology.


https://www.ctwiki.siemens.com/display/BIGIoT/Reactive+Streams



D2.1

ANNEX

© 2016 139

Metadata


els).



annex-g-trl_en.pdf

TRL-9 - used for various IoT products (e.g. RelayR) and also mission-critical applications in other do-

mains.



Open source - Apache License


Yes - commercial support through Lightbend


N/A


lines]



Akka is used by Atos for various domains and industrial IoT scenarios (precision agriculture, automo-

tive)


Lightbend Activator (getting started toolkit, samples, etc.)

Simple Build Tool (next generation build tool as an alternative to standard tooling, such as Gradle)



http://www.typesafe.com/



D2.1

ANNEX

© 2016 140






N/A

Discovery



Akka is generic, but typically IoT devices can be modelled as Actors which provides a cheap and yet

powerful server-side representation of things.

Actors are structured in trees (parent-children), can be queried, and distributed across computation

nodes (scale-out).



queries)

Actor & device names

Hierarchical clustering of actors.



Both push and pull are supported.



filter)



D2.1

ANNEX

© 2016 141



N/A


Any - Akka is agnostic of data formats


Various Akka-plugins are available (HTTP(S), Kafka, TCP, UDP, JMS, AMQP, etc.)



Both push and pull are supported.



complex filter)



SSN)




Tasking




D2.1

ANNEX

© 2016 142




Yes - Akka is agnostic of use case (a core technology)




Any



Yes - Actors can communicate with each other. Communication implies subscribing, so that an arbi-

trary actor keeps sending data to the subscribed actor (or other application)









Yes - Spark, one of today's leading stream analytics platforms is built on Akka.

Akka is made for processing vast data quantities at high speed with minimum resource overhead.



D2.1

ANNEX

© 2016 143







N/A





N/A



text)

N/A


N/A


N/A




D2.1

ANNEX

© 2016 144



N/A

Security management


Security through means of protocol security (e.g. HTTPS)



Depending on used communication protocols


Depending on used communication protocols

Privacy management


users.

N/A


N/A



streams).

N/A



D2.1

ANNEX

© 2016 145






N/A



N/A

1.1.6. Literature

[1] CoRE Resource Directory, https://tools.ietf.org/html/draft-shelby-core-resource-directory-05

[2] ISO 15118-2:2014,

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=55366

[3] EXIficient, http://exificient.github.io/

[4] Apache Jena, https://jena.apache.org/

[5] SmartGrid Profile 2.0, http://www.zigbee.org/zigbee-for-

developers/applicationstandards/zigbeesmartenergy/

[6] XMPP, https://tools.ietf.org/html/rfc6120

[7] OpenIoT, http://www.openiot.eu/

[8] WS-*, https://en.wikipedia.org/wiki/List_of_web_service_specifications

[9] Amazon WS, https://aws.amazon.com/de/

[10] OPC UA Foundation, https://opcfoundation.org/

https://tools.ietf.org/html/draft-shelby-core-resource-directory-05

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=55366

http://exificient.github.io/

https://jena.apache.org/

http://www.zigbee.org/zigbee-for-developers/applicationstandards/zigbeesmartenergy/

http://www.zigbee.org/zigbee-for-developers/applicationstandards/zigbeesmartenergy/


http://www.openiot.eu/

https://en.wikipedia.org/wiki/List_of_web_service_specifications

https://aws.amazon.com/de/

https://opcfoundation.org/



D2.1

ANNEX

© 2016 146

[11] google Adwords, www.google.de/AdWords

[12] DPWS, http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01

[13] XPath, https://www.w3.org/TR/xpath/

[14] WS-Discovery, http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-spec.html

[15] WS-Notification, https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn

[16] WS-Security, https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

[17] WS-Signature, https://www.w3.org/TR/xmldsig-core/

[18] WS-Encryption, https://www.w3.org/TR/xmlenc-core/

[19] Lemonbeat, http://www.lemonbeat.net/

[20] OpenEXI, http://openexi.sourceforge.net/

[21] EXIP, http://exip.sourceforge.net/

[22] AgileDelta, http://www.agiledelta.com/product_efx.html

[23] W3C WoT, https://www.w3.org/WoT/

1.2. Semantic Descriptions

The Resource Description Framework (RDF)

Metadata


The Resource Description Framework (RDF)


RDF is a published W3C Recommendation (standard)

http://www.google.de/AdWords

http://www.google.de/AdWords

http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01

https://www.w3.org/TR/xpath/

http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-spec.html

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

https://www.w3.org/TR/xmldsig-core/

https://www.w3.org/TR/xmlenc-core/

http://www.lemonbeat.net/

http://openexi.sourceforge.net/

http://exip.sourceforge.net/

http://www.agiledelta.com/product_efx.html

https://www.w3.org/WoT/



D2.1

ANNEX

© 2016 147

Metadata



General Information


RDF provides a data model for modeling of information that is implemented in Web resources. Togeth-

er with Linked Data principles, RDF provides a method for semantic interlinking and is also a basic

block that underlines all other Semantic Web technologies.

RDF is relevant for BIG IoT project as semantic modeling can be effectively realized in RDF. Semantic

descriptions of BIG IoT Things, services and applications may be expressed in RDF. Furthermore RDF

can be used for modeling information about the BIG IoT domain model, as well as for the mapping

between domain models of other platforms and the BIG IoT domain model.



The Resource Description Framework (RDF) is the core framework. It is a data model that underlines

all other Semantic Web technologies above (see Figure: The Semantic Web Stack). The data model

defines the atomic component which is a triple. A triple consists of subject, predicate and object. The

basic intuition behind a triple is to form a statement where subject and object are connected over a

predicate, thereby providing a basic sentence. Subject and object are hence a pair of resources that

can be considered nodes of a graph connected by an edge that is the predicate. The basic graph can

be further connected with other nodes (subjects and objects) thereby creating a larger RDF graph. RDF

statements can be serialized in different formats such as: XML , Notation 3, N-Triples, Turtle, JSON-LD

etc.


There exist a lot of tools that generate or process RDF data. Tools are provided in many different lan-

guages (e.g., Java, C, PHP, Ruby etc.)


lines]


http://www.w3.org/TR/rdf-syntax-grammar/

http://www.w3.org/TeamSubmission/n3/

http://www.w3.org/TR/rdf-testcases/#ntriples

http://www.w3.org/TeamSubmission/turtle/




D2.1

ANNEX

© 2016 148

Metadata

RDF is domain agnostic, and is a corner stone standard for the building blocks: Semantic Concepts

and Frameworks.


N/A



els).



annex-g-trl_en.pdf

RDF is used in commercial and government projects. Hence its TRL is high - we believe TRL 9.



RDF is a W3C standard and is freely available, also for a commercial use.


lines]



RDF is widely used in various vertical domains. Recently RDF has been used in different IoT projects,

and has been considered as the data model in an upcoming W3C standard related to Web of Things.


A wide range of RDF tools exist. They can be categorized as follows: tools [2]

Parsers and serializes: parse RDF data and can serialize data in different RDF syntaxes;



http://semanticweb.org/wiki/Tools



D2.1

ANNEX

© 2016 149

Metadata

Validators: validate various RDF syntaxes (for testing and debugging purposes);

Query libraries: provide support for executing RDF queries;

Reasoners: provide reasoning over RDF data (adhering to certain semantics, e.g., RDFS or OWL);

RDF triple stores: provide storage facilities for RDF data;

Other: provide different functionalists, e.g., language bindings in Perl, PHP, Python and Ruby.






N/A

Discovery



RDF data or metadata may serve as a basis for a semantic-based discovery. That is, BIG IoT re-

sources can be described with RDF metadata that is defined in an ontology (RDFS or OWL). Such BIG

IoT resources can then be found through semantic queries (e.g., SPARQL queries).



queries)

Complex queries can be supported.



https://www.w3.org/TR/rdf-sparql-query/



D2.1

ANNEX

© 2016 150

Metadata

When stored in an RDF triple store, RDF data can be pulled from the store.



filter)

Complex filters can be supported for queried data.


RDF statements can be serialized in different formats such as: XML , Notation 3, N-Triples, Turtle,

JSON-LD etc.

Supported access type (e.g., HTTP REST, RPC-style, SOAP, CoAP, SPARQ)

Various access types are supported (e.g., HTTP REST, RPC-style, SOAP, CoAP, SPARQL).



RDF enables realization of metadata that can be pulled from a triple store.



complex filter)

Complex filters can be supported when RDF metadata is queried (e.g., via SPARQL).


SSN)

See supported RDF serialization formats above.










D2.1

ANNEX

© 2016 151

Metadata


See supported access types related to RDF above.

Tasking



N/A.



N/A.



N/A.




N/A.


N/A.





D2.1

ANNEX

© 2016 152

Metadata




RDF is not a platform, but it provides a data model based on which IoT platforms may build semantic

vocabularies and ontologies e.g., for describing smart object properties.



text)



See subsections related to concrete ontologies below (e.g., SSN, oneM2M, SAREF etc.).


Up today there exist many different triplestores, based on SQL, NoSQL, native RDF triplestores etc.

An exhaustive list of triplestores can be found here.


Semantic concepts realized in RDF are queryable using SPARQL.

Security management


N/A.






D2.1

ANNEX

© 2016 153

Metadata

N/A.


N/A.

Privacy management


users.

N/A.


N/A.



streams).

N/A.




N/A.



N/A.



D2.1

ANNEX

© 2016 154

RDF Schema (RDFS)

Metadata


RDF Schema (RDFS)


RDFS is a part of the W3C Recommendation of RDF


RDFS

General Information


RDF Schema provides a data-modeling vocabulary for RDF data. RDF Schema is a semantic exten-

sion of RDF. It allows to specify schematic (or terminological) knowledge, i.e., it provides mechanisms

for describing groups of related resources and the relationships between these resources.

RDFS is relevant for BIG-IoT project as it provides the mechanism to model the terminological

knowledge of the BIG IoT domain model, Things, services and applications semantically and to de-

scribe the relationships between them.



RDFS is an ontology language for lightweight ontologies. RDFS provides the syntax and semantics to

define the class hierarchies (subclassOf), properties between the classes, property restrictions such as

defining the domain and range of a property, to work with Open Lists. RDFS provides the basic vo-

cabulary to create lightweight ontologies; the expressivity can be further extended by using OWL (Web

Ontology Language).

https://www.w3.org/TR/2014/REC-rdf-schema-20140225/

http://www.w3.org/TR/rdf11-mt/#semantic-extensions-and-entailment-regimes

http://www.w3.org/TR/rdf11-mt/#semantic-extensions-and-entailment-regimes



D2.1

ANNEX

© 2016 155

Metadata


There are a lot of tools that generate or process RDFS data. Tools are provided in many different lan-

guages (e.g., Java, C, PHP, Ruby etc.)


lines]

RDFS is the building block for Semantic Concepts and Frameworks. RDFS is domain independent.


N/A.



els).



annex-g-trl_en.pdf

RDFS is used in commercial and government projects. Hence its TRL is high - we believe TRL 9.



RDFS is a W3C standard and is freely available, also for a commercial use


lines]



RDFS is widely used to model RDF data in various vertical domains. Recently RDF has been used in





D2.1

ANNEX

© 2016 156

Metadata

different IoT projects, and has been considered as the data model in an upcoming W3C standard relat-

ed to Web of Things.


A wide range of reasoners exist to do reasoning over the RDF data adhering to RDFS semantics. The

reasoners are listed here: RDFS_Reasoners



Discovery



RDF data or metadata defined in an (RDFS or OWL) ontology, may serve as a basis for a semantic-

based discovery. That is, BIG IoT resources can be described with RDF data or metadata can then be

found through semantic queries (e.g., SPARQL queries).



queries)




When the data created using RDFS semantics is stored in an RDF triple store, then such RDF data can

be pulled from the store.


https://www.w3.org/2001/sw/wiki/Category:RDFS_Reasoner




D2.1

ANNEX

© 2016 157




filter)



RDF statements modelled using RDFS or OWL semantics can be serialized in different formats such

as: XML , Notation 3, N-Triples, Turtle, JSON-LD etc.


See RDF access types



RDF enables realization of metadata that can be pulled from a triple store.



complex filter)

Complex filters with RDFS prefix can be supported when RDF metadata expressed using RDFS se-

mantics is queried (e.g., via SPARQL).


SSN)

See RDF serialization formats.










D2.1

ANNEX

© 2016 158



See RDF access types.

Tasking



N/A.



N/A.




N/A.






RDFS syntax and semantics can be used to model and manage the semantic descriptions of smart

objects, their properties and/or values for such properties.




D2.1

ANNEX

© 2016 159




text)



See Section Semantic Models section.


See RDF triplestores.


Semantic concepts realized with RDFS semantics are queryable using SPARQL.

Security management


N/A.


Privacy management


users.

N/A.






D2.1

ANNEX

© 2016 160



streams).

N/A.




N/A.



N/A.

Web Ontology Language (OWL)

Metadata


Web Ontology Language (OWL)


World Wide Web Consortium (W3C)



https://www.w3.org/




D2.1

ANNEX

© 2016 161

General Information


OWL is a family of knowledge representation languages for creating ontologies. Since ontologies pro-

vide a means to enable semantic interoperability, in this section we review OWL.



The Web Ontology Language (OWL) is a family of knowledge representation languages for creating

ontologies. The languages are characterized by formal semantics and RDF-based serializations for the

Semantic Web. OWL extends RDFS with additional constructs and is syntactically embedded into RDF

(see The Semantic Web Stack). The OWL family can be distinguished between OWL and OWL 2.

OWL and OWL2 are used to refer to the 2004 and 2009 specifications, respectively. The OWL specifi-

cation includes the definition of three variants:OWL Lite: taxonomies and simple constraints; 2. OWL

DL: full description logic support; 3. OWL Full: maximum expressiveness and syntactic freedom of

RDF. In OWL 2, there are three sublanguages of the language: OWL 2 EL, OWL 2 QL, OWL 2 RL.

OWL 2 EL is a fragment that has polynomial time reasoning complexity for all the standard reasoning

tasks; it is particularly suitable for applications where very large ontologies are needed. The EL acro-

nym reflects the profile's basis in the EL family of description logics (logics that provide only existential

quantification). OWL 2 QL is particularly suitable for applications where relatively lightweight ontologies

are used to organize large numbers of individuals and where it is useful or necessary to access the

data directly via relational queries (e.g., SQL); OWL 2 RL is particularly suitable for applications where

relatively lightweight ontologies are used to organize large numbers of individuals and where it is useful

or necessary to operate directly on data in the form of RDF triples. OWL 2 RL enables the implementa-

tion of polynomial time reasoning algorithms using rule-extended database technologies.


Web Ontology Language (OWL) is a W3C standard.


lines]

OWL is a building block for Semantic Concepts and Frameworks domain.


http://www.w3.org/TR/owl-ref/

http://www.w3.org/TR/owl2-overview/

http://www.w3.org/TR/2004/REC-owl-features-20040210/#s2.1

http://www.w3.org/TR/2004/REC-owl-features-20040210/#s4

http://www.w3.org/TR/2004/REC-owl-features-20040210/#s4

https://www.w3.org/TR/owl-ref/#Sublanguages

http://www.w3.org/TR/owl2-profiles/#OWL_2_EL

http://www.w3.org/TR/owl2-profiles/#OWL_2_QL

http://www.w3.org/TR/owl2-profiles/#OWL_2_RL

http://www.w3.org/TR/2012/REC-owl2-profiles-20121211/#ref-ELpp



D2.1

ANNEX

© 2016 162

Metadata

N/A.



els).



annex-g-trl_en.pdf

OWL is used in commercial and government projects. Hence its TRL is high - we believe TRL 9.



OWL is a W3C standard and is freely available, also for a commercial use.


OWL is not a platform.


N/A.


lines]



OWL is widely used in various vertical domains. Recently OWL has been also used in different IoT

projects.






D2.1

ANNEX

© 2016 163

Metadata

A wide range of RDF tools exist. They can be categorized as follows: tools

Parsers and serializers: parse models written in OWL and can serialize data in different RDF syntaxes;

Validators: validate OWL syntax (for testing and debugging purposes);

Query libraries: provide support for executing SPARQL queries over OWL semantic models;

Reasoners: provide reasoning over OWL semantic ontologies;

RDF triple stores: provide storage facilities for RDF data (with OWL semantics);

Other: provide different functionalists, e.g., language bindings in Perl, PHP, Python, Java, Ruby etc.






N/A

Discovery



Metadata realized with OWL semantics may serve as a basis for a semantic-based discovery. That is,

BIG IoT resources can be described with such a metadata and can than be found through semantic

queries (e.g., SPARQL queries).



queries)

Complex queries (e.g., with SPARQL or OWL DL queries) can be supported.

http://semanticweb.org/wiki/Tools




D2.1

ANNEX

© 2016 164





When stored in an RDF triple store, RDF data with OWL semantics can be pulled from the store.



filter)



OWL statements can be serialized in different RDF-based formats such as: XML , Notation 3, N-

Triples, Turtle, JSON-LD etc.


Various access types can be supported in tools processing OWL (e.g., HTTP REST, RPC-style, SOAP,

CoAP, SPARQL).



OWL enables realization of metadata that can be pulled from a triple store.



complex filter)

Complex filters can be supported when RDF metadata is queried (e.g., via SPARQL or OWL-DL que-











D2.1

ANNEX

© 2016 165



ries).


SSN)

See supported RDF-based serialization formats above.


See supported access types related to RDF above.

Tasking



N/A.




N/A.



N/A.





D2.1

ANNEX

© 2016 166



N/A.


N/A.




N/A.



N/A.


N/A.





OWL is not a platform, but it is a family of languages based on which IoT platforms may build semantic

vocabularies and ontologies e.g., for describing smart object properties.





D2.1

ANNEX

© 2016 167



text)



See subsections related to concrete ontologies below (e.g., SSN, oneM2M, SAREF etc.).


Up today there exist many different triplestores, based on SQL, NoSQL, native RDF triplestores etc. An

exhaustive list of triplestores can be found here.

Are semantic concepts query-able (e.g., using SPARQL endpoint)

Semantic concepts realized in RDF are queryable, e.g., using SPARQL or OWL-DL.

Security management


N/A.



N/A.


N/A.

Privacy management

https://en.wikipedia.org/wiki/List_of_subject-predicate-object_databases




D2.1

ANNEX

© 2016 168




users.

N/A.


N/A.



streams).

N/A.




N/A.



N/A.

SPARQL Protocol and RDF Query Language (SPARQL)

Metadata



D2.1

ANNEX

© 2016 169

Metadata


SPARQL Protocol and RDF Query Language (SPARQL)


SPARQL is a published W3C Recommendation



https://www.w3.org/TR/sparql11-query/

General Information


SPARQL can be used to express queries across diverse data sources, whether the data is stored na-

tively as RDF or viewed as RDF via middleware. A typical SPARQL query is a text message that re-

trieves an XML document or an RDF graph. By default, a standard SPARQL query only analyses the

structure of the RDF graph and thus retrieves explicitly written data. In addition to that, a SPARQL pro-

cessor may be equipped with a reasoning service that enables retrieving data also about the virtual

statements, i.e. statements that can be logically deduced from the RDF graph(s).

SPARQL is relevant for BIG-IoT project as RDF can be used for semantic modeling of the BIG-IoT

Things, services, and applications and for modeling the information of the BIG-IoT domain model.

Thus, SPARQL can be used to query over the data represented in RDF to extract the information from

RDF graphs and to perform complex joins of disparate databases in a single, simple query. SPARQL

also contains capabilities for querying required and optional graph patterns along with their conjunc-

tions and disjunctions.



SPARQL queries are executed against RDF datasets, containing of RDF graphs (see The Semantic

Web Stack). SPARQL defines a SQL like query language for making queries for RDF. A SPARQL que-


https://www.w3.org/TR/sparql11-query/



D2.1

ANNEX

© 2016 170

Metadata

ry comprises of: Prefix declarations, for abbreviating URIs. Dataset definition, stating what RDF

graph(s) is being queried. A result clause, for identifying what information to return from the query. The

query pattern, specifying what to query for, in the underlying dataset. Query modifiers for filtering, or-

dering and rearranging query results.

A SPARQL endpoint accepts queries and returns results via HTTP. There are two types of SPARQL

endpoints namely, Generic endpoints that will query any Web-accessible RDF data. Specific endpoints

are hardwired to query against particular datasets. The results of SPARQL queries can be returned

and/or rendered in a variety of formats: XML, JSON, RDF and HTML.


There exists several tools to create and process SPARQL queries. Tools for creating SPARQL queries

and Query Engines for processing the SPARQL queries are provided in many languages (e.g., Java,

python, C, PHP e.t.c)


lines]

SPARQL is the standard for the building block: Semantic Concepts and Frameworks.



els).



annex-g-trl_en.pdf

SPARQL is used in commercial and government projects (e.g., BBC). Hence its TRL is high - we be-

lieve TRL 9.



SPARQL is a W3C standard and is freely available, also for a commercial use.




http://www.bbc.co.uk/blogs/bbcbackstage/2009/06/bbc-backstage-sparql-endpoint.shtml



D2.1

ANNEX

© 2016 171

Metadata

lines]



As RDF is widely used in various domains, SPARQL is used for discovery and integration of the RDF

data. Recently, SPARQL language is being used in various IoT projects to discover IoT resources in

the linked data. Several tools are developed extending the standard functionalities of SPARQL to ad-

dress the specific requirements of IoT data such as: The stSPARQL and stRDF extend the SPARQL

query language and RDF representations with spatial and temporal dimensions to facilitate query on

sensor data which is mostly time and location dependent. EP-SPARQL (Event Processing SPARQL) is

an extension to SPARQL that enables processing complex events and stream reasoning.


There exists wide range of SPARQL tools. They can be categorized as follows:SPARQL_Tools

SPARQL client: provides an interface to create and parse SPARQL queries.

Query Engine: used to process SPARQL queries.

Parsers: Parses the SPARQL queries.

SPARQL Endpoint: offer a URI with a SPARQL service that can be accessed using the SPARQL Pro-

tocol spec, and return XML and/or JSON.






N/A.

Discovery

https://www.w3.org/wiki/SparqlImplementations

http://www.w3.org/TR/rdf-sparql-protocol/

http://www.w3.org/TR/rdf-sparql-protocol/



D2.1

ANNEX

© 2016 172





SPARQL enables the discovery of the BIG-IoT resources, if the resources are described semantically

using RDF data model, as RDF data or metadata may serve as a basis for a semantic-based discov-

ery.



queries)




Data can be retrieved from triple stores using SPARQL queries.



filter)

SPARQL supports complex filters.


SPARQL is used to query data represented in RDF format.


SPARQL supports HTTP and SOAP access types.



D2.1

ANNEX

© 2016 173





Metadata can be retrieved from triple stores using SPARQL queries



complex filter)

SPARQL supports complex filters.


SSN)

SPARQL is used to query metadata represented in RDF format.


SPARQL supports HTTP and SOAP access types.

Tasking



N/A




When the data or events created by smart objects is represented semantically, then SPARQL query



D2.1

ANNEX

© 2016 174



language can be used to receive the processed data and events created by smart objects.



SPARQL supports XML, JSON, RDF, CSV and TSV as output data formats.





SPARQL supports UPDATE, INSERT and DELETE operations which can be used for the management

of the semantic descriptions of the smart objects.



text)

SPARQL supports XML, JSON, and RDF as output data formats.


Yes, the semantic concepts are queryable using SPARQL endpoint.

Security management


N/A




D2.1

ANNEX

© 2016 175



Privacy management


users.

N/A.



streams).

N/A.




N/A.



N/A.

1.2.1. Conceptual schema (Semantic models)

Schema.org




D2.1

ANNEX

© 2016 176

Schema.org



Schema.org

Schema.org is a joint initiative by Google, Bing, Yandex and Yahoo!.

http://schema.org


Schema.org was developed to markup Web pages. It provides a common vocabulary that Web devel-

opers can use to structure the information provided on their Website in order to improve search results.

Beyond optimizing search results, BIG IoT could utilize Schema.org to increase interoperability be-

tween platforms, for instance by describing the data provided by a platform with the vocabulary defined

by Schema.org.


an Architecture/solution figure (optimal)

Schema.org provides a vocabulary that can be used with the Microdata, RDFa, or JSON-LD formats to

add semantic information to Web content.

The listing below shows how Schema.org can be used to describe a movie (and its director) encoded in

Microdata. The listing shows an item (i.e., the movie avatar), which has a type (identified by the URL

http://schema.org/Movie). Each item can have multiple properties expressed as property value pairs

(e.g., property "director", which is a "person" that is named "James Cameron").

<div itemscope itemtype ="http://schema.org/Movie">

<h1 itemprop="name">Avatar</h1>

<div itemprop="director"itemscope itemtype="http://schema.org/Person">

Director: <span itemprop="name">James Cameron</span> (born <span

itemprop="birthDate">August 16, 1954</span>)

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/

http://en.wikipedia.org/wiki/Microdata_%28HTML%29

http://en.wikipedia.org/wiki/RDFa

http://en.wikipedia.org/wiki/JSON-LD

http://schema.org/

http://schema.org/Movie%29.

http://schema.org/Movie

http://schema.org/Person



D2.1

ANNEX

© 2016 177

</div>

<span itemprop="genre">

Science fiction

</span>

<a href="../movies/avatar-theatrical-

trailer.html"itemprop="trailer">Trailer</a>

</div>

Schema.org's data model is derived from RDF Schema. It contains types and properties. The schema

is represented in RDFa, and there is also an OWL version available. However, as Patel Schneider

points out in [1], the RDF mapping uses non-RDFS properties (e.g.,

http://schema.org/domainIncludes), and the OWL mapping (albeit adhering to the standard) is only a

translation of part of what defines schema.org.

Schema.org provides an extension mechanism to define more specialized and/or deeper vocabularies

that build upon the core Schema.org.

[1] Patel-Schneider, Peter. Analyzing Schema.org. 13th International Semantic Web Conference

(ISWC). Springer International Publishing, 261-276, 2014.


The vocabulary provided by Schema.org is defined on the Website and can be downloaded as RDFa

file (http://schema.org/docs/schema_org_rdfa.html). Snapshots in Microdata and OWL are provided but

marked obsolete. There is also a community site (http://schema.RDFS.org) to support Schema.org

deployment. The community site provides examples, maintains mappings from other vocabularies

toSchema.org, and lists tools and libraries that are able to consume or produce Schema.org-based

data. These tools are provided in many different languages (e.g., Java, C, PHP, Ruby)


lines]

Schema.org was mainly designed (and is still primarily used) to annotate Web pages in order to im-

prove search results.


http://schema.org/

http://schema.org/domainIncludes

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/docs/schema_org_rdfa.html

http://schema.rdfs.org/

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/



D2.1

ANNEX

© 2016 178

Schema.org was initiated by four major search engine operators (i.e., Google, Microsoft, Yandex, and

Yahoo!). Their purpose is to improve their core product by providing means to Web developers to ex-

pose the structure of Web pages.



els).



annex-g-trl_en.pdf

Most likely TRL9, because it is used by SEOs (search engine optimizers). However, we do not know to

what extend Schema.org actually found its way into the search engines.



It is open source (https://github.com/schemaorg/schemaorg) and falls under the Apache License.


No (see above)


The main vocabulary defined by Schema.org is available under the Apache License. This might not

apply for the tools available in the ecosystem (e.g. to validate if Web pages use Schema.org correctly).


lines]



Most likely the biggest search engine operators include Schema.org in their core product. However, the

number of Websites that are annotated using theSchema.org vocabulary is not known.

http://schema.org/



http://schema.org/

https://github.com/schemaorg/schemaorg

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/



D2.1

ANNEX

© 2016 179


Schema.RDFS.org provides links to different tools and libraries that are able to consume or produce

Schema.org-based data. These tools are provided in many different languages (e.g., Java, C, PHP,

Ruby). There are also mappings available to map to Schema.org from other vocabularies.

Existing tools are

Parsers: Parsers parse HTML sites and extract Schema.org information

Generators: Generators support the publishing process as they help to annotate Web sites

Validators (for testing and debugging), and

Other tools (e.g., a tool that enables microdata and RDF to co-exist, or an easy-to-use form to embed

Schema.org Microdata into WordPress.

These are community projects, which implies that they may be unstable.

Discovery



Schema.org enables Web sites to be discovered by search engine. Hence, it might be used to discover

services offered by a platform. However, this use case was not in the mind of the inventors and thus

there is no tool support for it (yet).





Schema.org defines a vocabulary that can be used to semantically describe concepts such as smart

object properties.



text)

Microdata, RDFa (Resource Description Framework in Attributes), JSON-LD

http://schema.rdfs.org/

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/

http://schema.org/

https://en.wikipedia.org/wiki/Resource_Description_Framework

https://en.wikipedia.org/wiki/RDFa#cite_note-n-1



D2.1

ANNEX

© 2016 180


RFD Schema, OWL


It defines semantic concepts and stores those in a file. There is no mechanism to store data in Sche-

ma.org


No

Semantic Sensor Netywork (SSN)

Metadata


Semantic Sensor Netywork (SSN)


W3C Semantic Sensor Network Incubator Group



General Information


The W3C Semantic Sensor Network Incubator group (the SSN-XG) has defined the SSN ontology with

the goal of applying Semantic Web technologies in order to enable interoperability for sensors and

sensing systems, and to enable high level advanced services over sensor data (e.g., semantic descrip-

tions of different abstraction layers in sensor-based systems, management, integration, interpretation

http://schema.org/

http://schema.org/


http://www.w3.org/2005/Incubator/ssn/wiki/Main_Page



D2.1

ANNEX

© 2016 181

Metadata

and querying of sensor data in these systems, computer reasoning etc.).

SSN is widely used and could be used in BIGIoT for the purpose mentioned here.



SSN is an OWL 2 ontology which describes sensors in terms of capabilities, measurement processes,

as well as observations and deployments. It provides a domain-independent semantic model for sens-

ing applications, thereby distinguishing following different perspectives:

A sensor perspective, with a focus on what can sense, how it senses, and what is sensed;

An observation perspective, with a focus on observation data and related metadata;

A system perspective, with a focus on systems of sensors and deployments;

A feature and property perspective, focusing on what senses a particular property or what observations

have been made about a property.

The following Figure 9 shows an overview of the SSN ontology and highlights important part of it such

as sensors, the accuracy and capabilities of such sensors, observations and methods used for sensing

etc.



D2.1

ANNEX

© 2016 182

Metadata

Figure 9: The SSN-XG Source

Overview of the Semantic Sensor Network ontology classes and properties

According to the ontology, a sensor is anything that observes. Sensors can be described at any level of

detail including descriptions of sensors in terms of their components and methods of operations. This

design decision of the group is important as it enables even more complex devices to be described as

sensors, sensing systems, virtual sensors and so forth. For example, a microcontroller connected with

few sensors can be described as a sensing system with its sensing devices. In general, a system has

components (defined by ssn:hasSubSystem) which are systems themselves. These systems further

can be devices, sensing devices or (complex) systems (defined by ssn:Device, ssn:SensingDevice and

ssn:System respectively). There exist many different sensing devices and systems with varying capa-

bilities and complexities, and used in many different use cases and application domains. Therefore this

approach of the SSN ontology is important since it leaves the flexibility when describing and imple-

menting a particular domain of discourse.


The first version of SSN has been released. It is implemented in OWL. The Spatial Data on the Web

Working Group (SDWWG) works on a new version of the SSN ontology, which will be the standard.


lines]

The SSN ontology is a building block for Semantic Concepts and Frameworks domain. It is a domain

independent ontology that describes sensors, observations, and related concepts. Other aspects such

as domain concepts, time, locations, etc. need to be described with other ontologies.



els).



annex-g-trl_en.pdf

SSN is used in several IoT Projects like OpenIoT. We believe, SSN have a high TRL 9.






D2.1

ANNEX

© 2016 183

Metadata


SSN is freely available, also for a commercial use.


lines]



It is currently being used by various organizations, from academia, government, and industry. see cur-

rent list of the applications.


OWL editor or API.

IoT-Lite ontology

Metadata


IoT-Lite ontology


W3C member submission 26 November 2015


IoT-Lite ontology

https://www.w3.org/community/ssn-cg/wiki/SSN_Applications

https://www.w3.org/community/ssn-cg/wiki/SSN_Applications

https://www.w3.org/Submission/2015/SUBM-iot-lite-20151126/



D2.1

ANNEX

© 2016 184

General Information



IoT-Lite is a lightweight instantiation of the semantic sensor network (SSN) ontology to describe the

key IoT concepts that allows interoperability and discovery of sensory data in heterogeneous IoT plat-

forms. IoT-Lite reduces the complexity of other IoT models describing only the main concepts of the IoT

domain. IoT-Lite can be extended by different models to increment it expressiveness.

IoT-Lite ontology is relevant for BIG-IoT project as it is a lightweight ontology, it can be used to repre-

sent BIG-IoT resources, services and applications. It can also be used to model the BIG-IoT domain

model and thus to enable interoperability and discovery of data among BIG-IoT resources, services

and applications.


IoT-Lite describes IoT concepts in three classes. Objects, system or resources and services.

IoT devices are classified into, although not restricted to, three classes: sensing devices, actuating

devices and tag devices. IoT-Lite is focused on sensing, although it has a high level concept on

actuation that allows any future extension on this area. Services are described with a coverage. This

coverage represents the 2D-spatial covered by the IoT device. The Figure 10 below depicts the con-

cepts of the ontology and the main relationships between them.

Figure 10: The concepts of the ontology.

http://www.w3.org/2005/Incubator/ssn/ssnx/ssn

http://www.w3.org/2005/Incubator/ssn/ssnx/ssn

https://www.w3.org/Submission/2015/SUBM-iot-lite-20151126/#term_Object

http://purl.oclc.org/NET/ssnx/ssn#System

https://www.w3.org/Submission/2015/SUBM-iot-lite-20151126/#term_Service

http://purl.oclc.org/NET/ssnx/ssn#SensingDevice

https://www.w3.org/Submission/2015/SUBM-iot-lite-20151126/#term_ActuatingDevice

https://www.w3.org/Submission/2015/SUBM-iot-lite-20151126/#term_ActuatingDevice

https://www.w3.org/Submission/2015/SUBM-iot-lite-20151126/#term_TagDevice

https://www.w3.org/Submission/2015/SUBM-iot-lite-20151126/#term_Coverage



D2.1

ANNEX

© 2016 185

Metadata

IoT-Lite Ontology is created to be used with common quantity taxonomy, qu-taxo, to describe the Units

and QuantityKind that IoT devices can measure. This taxonomy is represented by individuals in the

ontology and is based on well-known taxonomies such as: qu and qudt. Similarly, some other classes,

such as Object, Service or Attribute, can be linked to a vocabulary to choose the terms from a set of

individual and existing concepts.


N/A.


lines]

IoT-Lite ontology is a building block for Semantic Concepts and Frameworks domain. It can be used for

semantic modeling of the BIG-IoT domain models, services, applications and resources.


N/A.



els).



annex-g-trl_en.pdf

TRL 2



IoT-Lite ontology is a W3C member submission and is freely available, also for a commercial use.


http://purl.oclc.org/NET/UNIS/fiware/iot-lite/qu-taxo

http://purl.oclc.org/NET/ssnx/qu/qu#Unit

http://purl.oclc.org/NET/ssnx/qu/qu#Unit

http://purl.oclc.org/NET/ssnx/qu/qu#QuantityKind

http://www.w3.org/2005/Incubator/ssn/wiki/QU_Ontology

http://www.qudt.org/





D2.1

ANNEX

© 2016 186

Metadata

lines]



IoT-Lite is new W3C member submission.


N/A.






N/A.

Discovery



As IoT-Lite ontology is a semantic model, it enables semantic-based discovery. That is, BIG IoT re-

sources can be described with IoT-Lite ontology. Such BIG IoT resources can then be found through

semantic queries (e.g., SPARQL queries) or by using Semantic reasoning techniques.


queries)






D2.1

ANNEX

© 2016 187




If the data represented using IoT-Lite ontology is stored in a RDF triple store, then, this data can be

pulled from the store.



filter)



Data represented using IoT-Lite ontology is a set of RDF statements, which can be serialized in differ-

ent formats such as: XML , Notation 3, N-Triples, Turtle, JSON-LD etc.





Metadata of the IoT-Lite ontology can be pulled from a triple store.



complex filter)

Complex filters can be supported when RDF metadata is queried.










D2.1

ANNEX

© 2016 188



SSN)

See supported RDF serialization formats.


See supported RDF access types.

Tasking



N/A.



N/A.




N/A.





IoT-Lite is not a platform, but it is a data model which can be used to model the smart object properties



D2.1

ANNEX

© 2016 189



in IoT platform.



text)



N/A.





Semantic concepts realized in RDF are queryable using SPARQL.

Security management


N/A.

Privacy management


users.

N/A.




D2.1

ANNEX

© 2016 190






streams).

N/A.




N/A.



N/A.

SAREF: the Smart Appliances REFerence ontology

Metadata


SAREF: the Smart Appliances REFerence ontology


Samenvatting Smart Appliances Project, TNO. (SMART 2013/0077)



D2.1

ANNEX

© 2016 191

Metadata


https://sites.google.com/site/smartappliancesproject/ontologies/reference-ontology

General Information


The Smart Appliances REFerence (SAREF) ontology is a shared model of consensus that facilitates

the matching of existing assets (standards/protocols/datamodels/etc.) in the smart appliances domain.

The SAREF ontology provides building blocks that allow separation and recombination of different

parts of the ontology depending on specific needs.

SAREF ontology is relevant for BIG-IoT project as, it can be used to efficiently model the smart objects

or devices in the BIG-IoT domain semantically. SAREF ontology can be used to create complex func-

tions by combining a list of basic functions in a single device (or object), thus it can be used to create

BIG-IoT services.



The starting point of SAREF is the concept of Device (e.g., a switch). Devices are tangible objects de-

signed to accomplish one or more functions in households, common public buildings or offices. The

SAREF ontology offers a list of basic functions that can be eventually combined in order to have more

complex functions in a single device. For example, a switch offers an actuating function of type “switch-

ing on/off”. Each function has some associated commands, which can also be picked up as building

blocks from a list. For example, the “switching on/off” is associated with the commands “switch on”,

“switch off” and “toggle”. Depending on the function(s) it accomplishes, a device can be found in some

corresponding states that are also listed as building blocks.

A Device offers a Service, which is a representation of a Function to a network that makes the function

discoverable, registerable and remotely controllable by other devices in the network. A Service can

represent one or more functions. A Service is offered by a device that wants (a certain set of) its func-

tion(s) to be discoverable, registerable, remotely controllable by other devices in the network. A Service

must specify the device that is offering the service, the function(s) to be represented, and the (input and

output) parameters necessary to operate the service.


https://sites.google.com/site/smartappliancesproject/ontologies/reference-ontology



D2.1

ANNEX

© 2016 192

Metadata

N/A.


lines]

SAREF ontology is a building block for Semantic Concepts and Frameworks domain. It can be used for

semantic modeling of the BIG-IoT devices (or objects) and services.


N/A.



els).



annex-g-trl_en.pdf

TRL 2



SAREF ontology is developed by TNO-Innovation for life company. As part of Samenvatting Smart

Appliances Project (SMART 2013/0077). It is freely available.










D2.1

ANNEX

© 2016 193



N/A.

Discovery



As SAREF ontology is a semantic model, it enables semantic-based discovery. That is, BIG IoT re-

sources can be described with SAREF ontology. Such BIG IoT resources can then be found through

semantic queries (e.g., SPARQL queries) or by using Semantic reasoning techniques.


queries)




If the data represented using SAREF ontology is stored in a RDF triple store, then, this data can be

pulled from the store.



filter)



Data represented using SAREF ontology is a set of triples (Turtle format), which can be serialized in

different formats such as: XML , Notation 3, N-Triples, RDF, JSON-LD etc.










D2.1

ANNEX

© 2016 194







Metadata of the SAREF ontology can be pulled from a triple store.



complex filter)

Complex filters can be supported when RDF metadata is queried.


SSN)



See supported RDF access types.

Tasking



N/A.





D2.1

ANNEX

© 2016 195




N/A.




N/A.







SAREF ontology enables the management of semantic descriptions of the smart object (or device)

properties and their values in the IoT domain. But, it is a data model, not a platform.



text)



N/A.



D2.1

ANNEX

© 2016 196







Semantic concepts realized using SAREF ontology are queryable using SPARQL.

Security management


N/A.



Privacy management


users.

N/A.




streams).

N/A.




D2.1

ANNEX

© 2016 197






N/A.



N/A.

OneM2M Base Ontology

1.2.2. Existing Base Tools

There are a lot of software tools related to Semantic web. Special significant have Semantic web edi-

tors – software for the creation and manipulation of ontologies.

Example tools are:

Apollo,

OntoStudio,

Protégé,

Virtuoso,

Swoop and

TopBraid Composer.

All of the above are used from huge number of people.

Some other ontology tools are:

NeOn Toolkit is another ontology editor with many pluggins available. It is especially suited for heavy-

weight projects (e.g., multi-modular ontologies, multi-lingual, ontology integration, etc);

Neologism is an online vocabulary editor and publishing platform;

Vitro is an Integrated Ontology Editor and Semantic Web Application;

http://neon-toolkit.org/

http://neologism.deri.ie/

http://vitro.mannlib.cornell.edu/



D2.1

ANNEX

© 2016 198

Knoodl is a community-oriented ontology and knowledge base editor.

Ontofly is a web-based ontology editor.

Altova OWL editor is another ontology editor.

PoolParty is a thesaurus management system and a SKOS editor.

IBM Integrated Ontology Development Toolkit An ontology toolkit for storage, manipulation, query, and

inference of ontologies and corresponding instances, based on Eclipse.

Anzo for Excel will generate an initial ontology based on spreadsheet data and structure.

Main Characteristics of Ontology Tools

1. General description of the tools includes information about developers and availability.

2. Software architecture and tool evolution includes information about the tool architecture

(standalone, client/server, n-tier application). It also explains how the tool can be extended with other

functionalities/modules; furthermore, it describes how ontologies are stored (databases, text files, etc.)

and if there any backup management system.

3. Interoperability with other ontology development tools and languages includes information about

the interoperability of the tool. Tool‟s interoperability with other ontology tools can be recognized by

functionalities like (merging, annotation, storage, inference, etc.), in addition to translations to and from

ontology languages.

4. Knowledge representation is related to presenting of knowledge model of the tool. It also includes

the possibility of providing any language for building axioms and whether tool gives support to meth-

odology.

5. Inference services attached to the tool tells if the tool has a built-in inference engine or it can use

other attached inference engine. It also shows if the tool performs constraint/consistency checking. It

also provides the possibility of classifying concepts automatically in concept taxonomy and capabilities

to manage the exceptions in taxonomies.

6. Usability shows the existence of the graphical editors for the creation of concept taxonomies and

relations, the ability to prune these graphs and the possibility to perform zooms of parts of it. It also

says if the tool allows some kind of collaborative working and whether it provides libraries of ontolo-

gies.

Ontology Editors

Apollo

Apollo is a user-friendly knowledge modeling application. Apollo allows a user to model ontology with

basic primitives, such as classes, instances, functions, relations and so on.

The internal model is a frame system based on the OKBC protocol. The knowledge base of Apollo

consists of a hierarchical organization of ontologies. Ontologies can be inherited from other ontologies

and can be used as if they were their own ontologies.

Each ontology is the default ontology, which includes all primitive classes.

Each class can create a number of instances, and an instance inherits all slots of the class.

Each slot consists of a set of facets.

http://www.knoodl.com/

http://141.76.40.81:8080/Ontofly/

http://www.altova.com/semanticworks/owl-editor.html

http://poolparty.punkt.at/

http://www.alphaworks.ibm.com/tech/semanticstk

http://www.cambridgesemantics.com/products/anzo_for_excel



D2.1

ANNEX

© 2016 199

Apollo does not support graph view, web, information extraction and multi-user capabilities or collabo-

rative processing but it features strong type consistency checking, storing the ontologies (files only)

and import/export format (I/O plug-in architecture - export plug-ins to CLOS and OCML).

Apollo is implemented in Java and it is available for a download from

http://apollo.opeN/Ac.uk/index.html.

OntoStudio

OntoStudio is a widespread commercial modeling work bench environment for creating and maintain-

ing ontologies. It stands out due to its comprehensive functions in intuitive ontology modeling. Is the

professional developing environment for ontology-based solutions. It combines modeling tools for on-

tologies and rules with components for the integration of heterogeneous data sources. Through its

modular design, OntoStudio can be enriched with self-developed modules and be customized to meet

personal needs.

OntoStudio is also able to import many structures, schemas and models. Some of OntoStudio most

important functions are:

Schema modeling of ontologies including classes, properties, instances, synonyms and queries.

Rule modeling, debugging, explaining and optimizing capabilities.

The graphical rule editor, which can be used to model complex correlations

the integrated test environment that assures the quality of the modelling at all times.

Integration features provided by various imports and exports

easy connection of databases and knowledge bases using a graphical mapping tool

export of self-provided queries to the ontology as a Web service

The mapping tool, which can be used to match heterogeneous structures quickly and intuitively.

The editing of OWL, RDF(s), RIF, SPARQL and Objectlogic ontologies.

Visualization, navigation and printing of ontologies.

Reporting based upon ontology models.

Textual editing capabilities.

OntoStudio supports the collaborative development of ontologies using the OntoBroker Enhancement

Collaboration Server.

OntoStudio support a very user-friendly GUI for creating and maintaining Ontologies. A first step is to

create a project for ontology development. It supports three different types of storage:

A file based, where the ontologies are held in the main memory and saved in a file. This is non-

persistent storage.

An internal repository, automatically saving all changes and therefore persistent.

Together with the Collaboration Server that allows collaborative ontology development. All ontologies

are stored in the remote server.

The next step is to create a new ontology for the project. Each ontology has an URI (Unique Resource

Identifier) that needs to be specified. Also, each ontology has a default namespace that is used for all

the defined elements unless stated otherwise. By creating a new ontology, a new entity properties

http://apollo.open.ac.uk/index.html



D2.1

ANNEX

© 2016 200

window is available. This window displays the ontology details, the namespaces tab, the ontology

imports tab and the ontology imports graph.

The ontology details shows the choosen name of the ontology as well as the name of the file the

ontology is saved to.

The namespaces tab lists all of the namespaces used in the ontology so far, together with their

aliases. These information can be edited and updated.

The ontology imports tab, supports the import of other ontologies in order to be reused.

The ontology imports graph shows a graph-based visualization of the import structure of the ontology.

Protégé

Protégé is a free, open-source platform that provides a growing user community with a suite of tools to

construct domain models and knowledge base applications with ontologies.

Protégé is run on a variety of platforms like Windows (32 and 64 bit), Linux (32 and 64 bit), MacOSX,

Sun, Solaris , HPUX, IBM. It allows the users to customize interface extensions, incorporates the

Open Knowledge-Base Connectivity knowledge model there by interacts with the standard storage

formats for example like relational databases, XML and RDF. OWL extends RDFS to allow for the

expression of complex relationships between different RDFS classes and of more precise constraints

on specific classes and properties (for example, cardinality relations, equality, enumerated classes,

characteristics of properties etc).

It implements a rich set of knowledge modeling structures and action that support the creation, visuali-

zation and manipulation of ontologies in various representation formats. It can be customized to pro-

vide domain-friendly support for creating knowledge models and entering data. Also, it can be extend-

ed by a plug-in architecture and Java-based application programming interface (API) for building

knowledge-based tools and applications. Protégé allows the definition of classes, class hierarchy’s

variables, variable-value restrictions, and the relationships between classes and the properties of

these relationships.

This tool allows formats like RDF/XML, OWL/XML, OWL Functional syntax, Manchester OWL syntax,

OBO 1.2 flat file, KRSS2 syntax, Latex and Turtle (Terse RDF Triple Language). Protégé uses the

reasoners like FACT++, Hermit and RACER to fix the inconsistency. The main services offered by

reasoner are to test whether or not one class is a subclass of another class. By performing such tests

on all classes, it is possible for a reasoner to compute the inferred ontology class hierarchy. Another

reasoning service is “consistency checking” which is to check whether it is possible or not for the class

to have any instances. The ontology can be sent to the reasoner automatically to compute the classifi-

cation hierarchy, and also for checking the logical consistency of the ontology. In Protégé, the manual-

ly constructed class hierarchy is called the asserted hierarchy, whereas automatically computed by the

reasoner is called the inferred hierarchy. While asserted knowledge inference is derived from original

data base, that of inferred knowledge, is through additional data that a reasoner (e.g. a reasoner that

is plugged-in Protégé) will provide from the original data. By maintaining relational database at the

backend, enables Protégé to process ontologies which are too large to reside in the memory. Finally,

through Protégé’s plug-in mechanism, user can generate their own custom import or export plug-ins to

work with custom or specialized formats. OWLGrEd is a unified modeling language style graphical



D2.1

ANNEX

© 2016 201

ontology editor for OWL and allow graphical ontology exploration and development including interop-

erability with Protégé.

Protégé is freely available for download. Stanford has a tutorial that covers the basics of using Protégé

with the OWL plug-in. Protégé-OWL provides a reasoning API that can access an external DIG-

compliant reasoner, enabling the inferences about classes and individuals in an ontology. It includes

an interface for SWRL (Semantic Web Rule Language), which sits on top of OWL to do maths, tem-

poral reasoning, and adds Prolog-type reasoning rules. The significant advantage of Protégé is its

scalability and extensibility. Protégé allows to build and to process large ontologies in an efficient

manner. Through its extensibility Protégé might be adopted and customized to suit users‟ require-

ments and needs. The most popular type of plug-ins is tab plug-ins; currently available tabs provide

capabilities for advanced visualization, ontology merging, version management, inference, and so on.

Protégé supports collaborative ontology editing as well as annotation of both ontology components

and ontology changes.

Virtuoso

Virtuoso is an innovative enterprise grade multi-model data server for agile enterprises & individuals. It

delivers a platform agnostic solution for data management, access and integration. It uses anobject-

relational SQL database (ORDBMS) and thus provides transactions, an SQL compiler, stored-

procedure language with Java and .Net server side hosting.

Main characteristics:

Smart Data Visualization & Integration

Scalable & High-Performance Data Management

Web-Scale Identity & Security

Standards Compliance

Supports many data-access interfaces, such as ODBC, ADO.net and OLE/DB.

Supports SPARQL embedded into SQL for querying RDF data stored in Virtuoso's database.

The hybrid server architecture enables it to offer traditionally distinct server functionality within a single

product offering that covers the following areas:

Relational Data Management

RDF Data Management

XML Data Management

Free Text Content Management & Full Text Indexing

Document Web Server

Linked Data Server

Web Application Server

Web Services Deployment (SOAP or REST)

Virtuoso currently supports Windows (XP, 200x, Vista, 7,8, x86_64 (64-bit)), Linux (Redhat, Suse)

Mac OS X, FreeBSD, Solaris, and other UNIX (32- & 64-bit platforms).

http://ado.net/



D2.1

ANNEX

© 2016 202

Virtuoso supports a virtual database. In the simplest form provides the ability to search across several

databases with a single query. Virtuoso extends this query functionality and data transformation

through hosted logic, SQL, SQL stored procedures and XML and the Virtuoso PL. It supports a num-

ber of database platforms and can simultaneously connect to ODBC, JDBC, UDBC, OLE-DB client

applications and services to data. These databases include Oracle, Microsoft SQL Server, DB/2, In-

formix, Progress, Ingress and other ODBC compliant database engines. It also supports loading RDF

data into the Virtuoso RDF Triple-Store.

Files such as N3, Turtle and RDF / XML can be loaded into a Virtuoso-hosted "named graph" using

Virtuoso SQL functions. The same functionality is also available to single triple statements. It has the

ability to automatically extract metadata from DAV resources via metadata extractors. It includes a

number of metadata extractors for a range of known data formats. These extractors enable automatic

triple-generation, graph association, and storage in Virtuoso RDF Triple Store.

SPARQL statements can be written inside SQL statements or presented as top-level SQL queries.

This means that ODBC, JDBC, .NET or OLE/DB applications can simply make SPARQL queries just

as if they were SQL queries.

Swoop

Swoop is an open-source, Web-based OWL ontology editor and browser. Swoop contains OWL vali-

dation and offers various OWL presentation syntax views (Abstract Syntax, N3 etc). It has reasoning

(RDFS-like and Pallet) support (OWL Inference Engine), and provides a Multiple Ontology environ-

ment, by which entities and relationships across various ontologies can be compared, edited and

merged seamlessly. Different ontologies can be compared against their Description Logic-based defi-

nitions, associated properties and instances. Navigation could be simple and easy due to the hyper-

linked capabilities in the interface of Swoop.

Swoop does not follow a methodology for ontology construction. The users can reuse external onto-

logical data either by simply linking to the external entity, or by importing the entire external ontology. It

is not possible to do partial imports of OWL, but it is possible to search concepts across multiple on-

tologies.

Swoop uses ontology search algorithms that combine keywords with DLbased constructs to find relat-

ed concepts in existing ontologies. This search is made along all the ontologies stored in the Swoop

knowledge base.

Swoop has collaborative annotation with the Annotate plug-in.

TopBraid Composer

TopBraid Composer comes in three editions:

Free Edition (FE) is an introductory version with only a core set of features.

Standard Edition (SE) includes all features of FE plus graphical viewers, import facilities, advanced

refactoring support and much more.

Maestro Edition (ME) includes all features of SE plus support for TopBraid Live, EVN and Ensemble

as well as SPARQLMotion and many other power user features.



D2.1

ANNEX

© 2016 203

TopBraid Composer a component of TopBraid Suite is a professional development tool for semantic

models (ontologies). It is based on the Eclipse platform and the Jena API. It is a complete editor for

RDF(S) and OWL models, as well as a platform for other RDF-based components and services.

TopBraid Composer can loads and save any OWL2 file in formats such as RDF/XML or Turtle.

TopBraid Composer supports various reasoning and consistency checking mechanisms. Consistency

checking and debugging is supported by built-in OWL inference engine, SPARQL query engine and

Rules engine. OWL description logic is supported via a range of built-in OWL DL engines

such as OWLIM, Jena and Pellet. TopBraid composer also supports the SPARQL inference Notation

(SPIN).SPIN can also be used to define integrity constraints that can be used to highlight invalid data

at edit time.

TopBraid Composer also provides inference explanation facilities for Pellet and SPIN. It can be used

to connect RDF resources or ontologies with geospatial ontologies. It can be used to query for re-

sources within a specific region. It can parse such documents to extract RDFa metadata from HTML

pages; the metadata can then be treated like any other RDF source, and users can perform DL rea-

soning or SPARQL queries on it. TopBraid Composer may use in a single user mode working with

ontologies stored as files or in a database. TopBraid Composer is a modeling tool for the creation and

maintenance of ontologies. It provides: standard-based, syntax directed development of RDF(S) and

OWL ontologies, SPARQL queries and Semantic Web rules import/export from a variety of data for-

mats including RDF(S), XML, Excel, etc. Usability, extensibility and robustness are provided by under-

lying technologies – Eclipse and Jena.

TopBraid Suite is a collection of integrated semantic solution products. All the components of the

TopBraid suite, work within an evolving open architecture platform and implemented adhering to W3C

semantic web standards. This software was released in 2011 and is available in three forms like free,

standard and maestro. It is found that free version has several limitations. Maestro version has many

advanced features like its own internal web server for testing application development. It has a flexible

and extensible framework with an application program interface for developing semantic client/server

or browser-based applications. Some of the concepts are similar to Protégé, like generation of schema

based forms for data acquisition. Many features are available like graphical editor which can be used

for designing the ontology easily. Moreover cloning of classes and subclasses is also supported.

Regarding Reasoning, TopBraid features a configurable Reasoning / Inference pipeline that includes

the Apache Jena reasoner (allowing us to reproduce the behaviour and any Jena/Fuseki-based

SPARQL end-point).

Regarding Editing Assistance, TopBraid offers better SPARQL functionality, but is still nowhere near a

sophisticated query environment. As far as editing goes, TopBraid seems to be a bit more comfortable

than OntoStudio. For instance, it makes suggestions for available (through inference) properties for

objects and offers a full text search to quickly navigate in the Ontology tree. Also, TopBraid displays

(similar to the usage view in Protégé) the usage of a Concept and also inferred properties. OntoStudio

does none of that.

TopBraid Composer (FE) is free for downloading. The other versions can be downloaded and evaluat-

ed for a 30 days evaluation period.



D2.1

ANNEX

© 2016 204

Evaluation

All of the above mentioned tools have the ability to build a new ontology either from scratch or by reus-

ing existing ontologies, which usually supports editing browsing, documentation, export and import

from different formats, views and libraries.

Table 1 General Description of Tools

Information about developers and availability

Feature OntoStudio Protégé Swoop TopBraid Composer

Developers Ontoprise SMI

Stanford Univer-

sity

MND

University of

Maryland

Top Quadrant

Implemented

using

Eclipse IDE Java Java Eclipse IDE, Jena,

Apache

Availability Licensed version, li-

cense for three months

trail is available

Freeware (Open

source)

Freeware

(Open source)

Free, standard, Maestro

versions are available

Multi user

support

Not Supported Supported Not Sup-

ported

Supported

Supporting

Platform

Windows XP, Vista,

Windows 7,

WindowsServer2003,

SUSE Linux 10.x

Windows(32 and

64 bit), Linux (32

and 64bit),

MacOSX, Sun,

Solaris, HPUX,

IBM

Windows,

Linux

Windows, Linux Mac-

intosh (32 and 64 bit)

Programming

languages

interface

Interface with .net,

Java program

PROTÉGÉ API,

Protégé Script

Tab

Interface

with Java

program

Adobe Flex, HTML and

JavaScript: used with

SPARQL Web Pages

(SWP),

Java Web service API is

implemented using

SPARQLMotion

Table 2 Software Architecture and Tool Evolution

Information about the tool architecture (extensibility, storage, backup)



D2.1

ANNEX

© 2016 205

Feature OntoStudio Protégé Swoop TopBraid Composer

Semantic web

architecture

Eclipse cli-

ent/server

Standalone &

client/server

Web based &

client/server

Standalone Eclipse plug-in

Extensibility Plug-ins Plug-ins Yes Via plug-

ins Plug-ins

Backup manage-

ment No No No No

Ontology storage File & Microsoft

SQLServer 2005

and 2008;

Oracle 10g and

11g; DB2 8.1.2,

8.2,9.0 and 9.5;

JDBC

File and

DBMS

(JDBC)

As HTML

Models

Oracle data base

(out of the box);

MySQL, SQL

Server, and other drivers

need to be installed by

user (link)

Consistency

check

Supported Supported Supported Supported

Language sup-

ported to define

synonyms

English, French

and German

English English English

Table 3 Interoperability

Information about the interoperability of a tool, i.e. the interoperability with other ontology tools can be

recognized by functionalities like merging, annotation, storage and inference.

Feature OntoStudio Protégé Swoop TopBraid Com-

poser

With other

ontology

tools

OntoAnnotate,

OntoBroker, OntoMat

Semantic & Miner

PROMPT, OKBC,

JESS, FaCT & Jena

No Sesame, Jena & Al-

legro Graph

Supporting OWL, RDF, F-

RDF/XML, OWL, RDF, OWL, RDF, turtle,

http://www.topquadrant.com/knowledge-assets/faq/tbc/



D2.1

ANNEX

© 2016 206


poser

File

Formats

logic ObjectLogic OWL/XML, OWL

Functional syntax,

Manchester OWL

syntax, OBO 1.2 flat

file,

KRSS2 syntax, Latex

and Turtle (Terse

RDF Triple Lan-

guage)

XML,text,

SWOOP on-

tology object

files

n-triple, xml

Imports

from

languages

XML(S), OWL, RDF(S),

UML Diagram, database

schemas

(Oracle, MSSQL,

DB2,MySQL), Outlook,

file system Metadata and

Remote OntoBroker.

XML(S), RDF(S),

OWL, (RDF,UML,

XML) backend, Ex-

cel, BioPortal

and DataMaster.

OWL, XML,

RDF and

text formats

RDFa, WOL,RDF(s),

XHTML, Microdata

and RDFa Data

sources,

SPIN, News Feed,

RDF Files into a new

TDB,

Email and Excel

Exports to

languages

XML(S), OWL, RDF(S),

UML and OXML

XML(S), RDF(S),

OWL, Clips, SWRL-

IQ,

Instance Selection,

MetaAnalysis,

OWLDoc,

Queries and (RDF,

UML, XML)

backend.

RDF (S), OIL

and DAML

Merge / Convert

RDF Graphs,

RDF(S), WOL

In contrast to Protégé, both OntoStudio and TopBraid seem to handle OWL2 well. As far as import

and export capabilities go, both seem to handle a variety of formats. OntoStudio lets you create map-

pings between different data sources and concepts / properties, while TopBraid only lets you perform

one time import/export operations for a few data sources such as Oracle databases, Jena TDB (which

happens to be ICA embedded TS), Jena SDB (i.e. DB2).

Table 4 Knowledge Representation

Information about how tools are presenting the knowledge model



D2.1

ANNEX

© 2016 207


poser

KR paradigm of

knowledge model

Frames and First

Order logic

Frames, First Order

logic,

SWRL and Meta-

classes

OWL RDF, OWL and

SWRL

Axiom language Yes (F-Logic) Yes (PAL) OWL-

DL

OWL-DL

Methodological support Yes Onto-Knowledge No No No

Table 5 Inference Services

Inference services attached to the tool.


poser


poser

Built-in inference engine Yes, ontobroker Yes (PAL) No

WOL, SPARQL

and Rule

Query Supports SPARQL, Object-

Logic query,

Query Builder

DL query Pellet Query SPARQL,

SPIN are supported

Other attached inference

engine Pellet

RACER,

FACT,

FACT++,

F-logic and

Pellet

Pellet and

RDFlike

OWLIM, Pellet and

SPARQL Rules

Constraint/Consistency

checking Yes Yes

Only with rea-

soner plug-in Yes

Automatic classifications No No No No

Exception Handling No No No Yes



D2.1

ANNEX

© 2016 208


poser


poser

RIF (Rule Interchange

Format)

Supported Not Support-

ed

Not Support-

ed

Supported Jena

rule engine

Table 6 Usability

Information about the existence of the graphical editors for the creation of concept taxonomies and

relations, the ability to prune these graphs and the possibility to perform zooms of parts of it.

Feature OntoStudio Protégé Swoop TopBraid

Composer

Graphical repre-

sentation

Supported OntoGraf,

OwlViz,

OWLGrEd for

UML

Not avail-

able

Supported

Graphical taxonomy Yes Yes Yes Yes

Graphical prunes

(views) Yes Yes No No

Chart Generation

support

Available Not Available Not Avail-

able

Available

Graphical editor

support

Available Not Available Not Avail-

able

Available

Zooms Yes Yes No No

Collaborative work-

ing Yes Yes Yes Yes

Ontology libraries Yes Yes No Yes

Report generation

support

Available. Using Business

Intelligent Reporting Tool Not Available Not Avail-

able

Available



D2.1

ANNEX

© 2016 209

1.3. Deployment

1.3.1. Docker Engine

Metadata


Docker Engine


Docker Inc.



General Information


Format for application packaging to harmonize deployment formats across BigIoT



Docker is a flavour of Linux kernel containers (plus tool-chain) which allows packaging applications in a

generic container format. These deployment packages can then be run on any Linux-host featuring the

Docker daemon as a run-time environment. In this approach, all application-specific packages, de-

pendencies, config files, etc. are packaged inside the container, so that the Linux host does not require

any insights into the application. In fact, running a web-server via Docker is no different than running

any arbitrary console application (e.g. ls) with Docker.

Docker containers also feature network virtualization (i.e. virtual network cards) so that each application

in a separate container can use port 80 (for example) without producing port conflicts on that host. If a

number of apps are using the same port on their virtual network card, Docker is mapping the internal

port (80) to another arbitrary/manually-defined port on the Linux host to avoid port conflicts.




D2.1

ANNEX

© 2016 210

Metadata

Docker containers also feature internal file systems which can be used by any application to store files.

These file systems are encapsulated inside docker containers, but can be viewed from external and

also exported on demand.

A number of dockerized applications is available out of the box through Docker-Hub - a public reposito-

ry of docker containers each holding a specific application. Docker containers are easy to configure,

extend, and upload to Docker-Hub.

One of the major benefits of Docker is that it allows to completely avoid thick virtualization as with

VMWare, Xen, or other hypervisor technologies. With Docker, no guest operating systems are being

run on top of the host OS. Instead, the Linux-based host-OS already supports means for container

isolation and, therefore, allows complete separation-of-concerns between containers without explicit

virtualization or even an entire guest OS.


production-ready - docker is written in GO and native code


lines]

cloud deployment without virtualization


Consulting is provided as-a-service.

Docker-Cloud services are also available.



els).



annex-g-trl_en.pdf

TRL-9 - battle-proven in many commercial setups.

Docker is supported in many clouds, such as Amazon (ECS - Elastic Container Services), Microsoft

Azure, IBM, etc.





D2.1

ANNEX

© 2016 211

Metadata



Apache V2


Yes, commercial support through Docker Inc. and many cloud vendors (AWS, Amazon, IBM, Rack-

space, Redhat, etc.)


N/A


lines]



Massive distribution - Docker has become the de-facto standard for application packaging in the cloud

lately


Docker Engine, Docker Hub, Docker Swarm, Docker Machine, Docker Registry, and many more

1.3.2. Docker Registry

Metadata




D2.1

ANNEX

© 2016 212

Metadata

Docker Registry


Docker Inc.


https://docs.docker.com/registry/

General Information


The Docker Registry may serve as a deployment repository for BigIoT applications, services, and core

components.



Docker Registry is a repository for management of Docker containers. Since containers are pre-

packaged applications with a very well-defined and clear structured interface for management (start,

stop, etc.), Docker-Registry instances are mainly used as repositories for ready-to-run (deployable)

applications and services. As other repositories, DR supports versioning of artifacts and relies on

Docker's built-in mechanism for container configuration via configuration files. In fact, Docker images -

the blueprints for containers - are often derived from more basic/generic containers by setting up on

these basic containers and enriching them with additional features. - This enrichment process is con-

figurable via the Docker File (a container configuration).

Effectively Docker-Registry manages basic containers and their descendants by storing deltas between

container configuration files. In that sense, Docker Registry is very resource-effective, but it also re-

quires additional resource repositories (such as Nexus) for downloading the application artifacts which

are needed for a concrete Docker container according to its Docker File.


Docker Registry is written in GO - just like the majority of other Docker tools.

https://docs.docker.com/registry/



D2.1

ANNEX

© 2016 213

Metadata


lines]

Modern cloud application deployment


N/A



els).



annex-g-trl_en.pdf

TLR-9 - already used in heavy load production scenarios



open-source Apache License


A commercial offering is available under the name Docker Trusted Registry


N/A


lines]




https://docs.docker.com/docker-trusted-registry/



D2.1

ANNEX

© 2016 214

Metadata


Docker tooling is supported in commercial cloud offerings from Google, Rackspace, Amazon, Mi-

crosoft, IBM, etc.


Complete Docker toolset (Docker Engine, Docker Swarm, Docker Repository, Docker Hub, etc.).

1.3.3. Kubernetes

Metadata


Kubernetes


Google, OpenShift


http://kubernetes.io/

General Information


Kubernetes enables automation and application management in cloud environments.






D2.1

ANNEX

© 2016 215

Metadata

Kubernetes is a state-of-the-art and open-source deployment tool for rolling-out and maintaining appli-

cations in cloud environments. Kubernetes is largely based on Docker containers and bundles co-

dependent applications and micro-services to pods - small clusters of applications which are supposed

to be deployed together in physical proximity.

Out-of-the-box support for dynamic scaling (i.e. increasing/decreasing number of application instances)

and separation-of-concerns through built-in network virtualization is also supported. Kubernetes takes

care that related application instances can communicate via networking, while isolated applications

have no means of connecting to each other on the network.

Kubernetes is being developed and pushed by Google as an open-source alternative to application

management. It has also been adopted by RedHat and other companies as the chosen technology for

application management in OpenShift - an open-source PaaS cloud framework.




lines]

Application deployment & management in the cloud


N/A



els).



annex-g-trl_en.pdf

TRL-9 - battle-proven in various environments through OpenShift (which comes with Kubernetes out-

of-the-box)


https://www.ctwiki.siemens.com/display/BIGIoT/Docker






D2.1

ANNEX

© 2016 216

Metadata


Apache 2.0 License


open-source + commercial offers (support, subscriptions, etc.) through OpenShift vendors (e.g.

RedHat)


N/A


lines]



Kubernetes is deployed in many cloud eco-systems across domains. Large users and contributors are:

Atos, Accenture, Cisco, etc.


N/A - Kubernetes IS a tool for developers, devops, and operators






Kubernetes is able to deploy any docker-ized application. Hadoop, Spark, and other stream-processing

infrastructure is available as Docker containers today.



D2.1

ANNEX

© 2016 217



The complexity of docker-izing other Linux-compatible applications is very low.

1.4. Persistency

1.4.1. NoSQL

Metadata


NoSQL (key-value pair databases, document-oriented databases)


GAFA


C. Strauch, “NoSQL Databases,” Hochschule der Medien Stuttgart, 2010.

General Information


As stated in previous section (see RDF Stores), relational databases do not fully address challenges

related to the IoT, namely the production of heterogeneous data at a high rate. While RDF stores are

appropriate to handle heterogeneous data, they also suffer from expensive data updates and they are

not the best candidates to store streamed data. Big IT companies (GAFA, among others), which have a

large amount of users using their services simultaneously, have recently adopted new NoSQL ap-

proaches to handle the data their platforms generate, tailored for high read/write rates. Such approach-

es solve issues like low availability, high error rates or low throughput (overall decreasing the quality of

service).

Although there are several kinds of NoSQL databases, we will focus in the following on key-value pair

databases and to some extent, document-oriented databases, since they solve best the issues we

https://www.ctwiki.siemens.com/display/BIGIoT/D2.1+-+Non-relational+Databases#D2.1-Non-relationalDatabases-rdf-stores



D2.1

ANNEX

© 2016 218

Metadata

have just mentioned.



NoSQL does not refer per se to one kind of database. Rather, it includes all persistence models that

are not (or more precisely not only) SQL. One such model, key-value pair databases was specifically

designed to support high write rate and random read of data. In theory, this model simply assumes one

thing: pieces of data are indexed by unique keys and may only be retrieved using these keys. Underly-

ing data structures could be hash tables or arrays. However, most implementations of key-value pair

databases share other characteristics that have become de facto standard [17]:

most implementations are "in-memory" first (meaning that data is located in the RAM);

data is then periodically persisted in the ROM and indexed using LSM-trees (instead of classical B-

trees used for relational databases) [14];

implementations are oriented towards massive parallelization, following the principle of "shared nothing

architecture";

Consistency is often traded off for availability, transactions are often referred to as BASE (Basically

Available, Soft state, Eventual consistency) rather than ACID.

As previously mentioned, key-value pair databases only manage keys and do not provide query

mechanisms. In contrast, document-oriented databases, while still relying on a key-value indexing

model, focus on providing efficient query processing by allowing values to be semi-structured. Having

semi-structured documents instead of raw values makes it possible to build secondary indexes on data

within a document. However, no standard query language for such documents has emerged yet. Mon-

goDB, the most successful NoSQL database, uses a syntax close to JSON to formulate queries.


See Implementations


lines]

NoSQL is a generic term to denote a cross-domain technology. It was first intended for Cloud platforms

(Amazon Web Services in the first place) having to meet a high quality of service (DynamoDB is the

first implementation of such database). Since most IT systems nowadays are Cloud-centric, NoSQL

https://www.ctwiki.siemens.com/display/BIGIoT/D2.1+-+Non-relational+Databases#D2.1-Non-relationalDatabases-impl



D2.1

ANNEX

© 2016 219

Metadata

databases potentially apply to any business domain. Examples of usage of BerkeleyDB (an Oracle

product) include, but are not limited to, telecom operators (Docomo), banking (Payback) or manufactur-

ing [15].


See Implementations



els).



annex-g-trl_en.pdf

NoSQL for the IoT: TRL 7

Although NoSQL databases have been extensively used in operational environment for a few years, it

is not clear, whether there exist long-term deployments of IoT systems explicitly using them. In any

case, the benefit of NoSQL over SQL has been made clear in the case of data-intensive applications

and database management system vendors already advocate NoSQL for IoT platforms. However,

evaluations tend to show that NoSQL won't fully replace traditional database management systems,

particularly due to its limited query support, even in the case of document-oriented storage [16]. There-

fore it is not certain that this technology will be deployed as is, in the future, without further research.



See Implementations


See Implementations






D2.1

ANNEX

© 2016 220

Metadata

See Implementations


lines]



MongoDB advertises the company has hundreds of clients globally and is identified as a major player

by Gartner with regards to operational database [18], competing with Oracle and Amazon. Redis is also

a major player in the field. Although we lack information about the architecture of proprietary IoT plat-

forms, it is reasonable to think that most of them include a NoSQL module. AWS IoT has a binding to

MongoDB (inherited from other AWS products) and Microsoft Azure IoT has bindings to MongoDB and

Redis. EVRYTHNG, a dedicated IoT platform also uses NoSQL (we lack details about the concrete

platform they use, though). Among the open-source platforms used in the BIG-IoT project, Yucca (or

CSI Piemonte Smartdata) uses MongoDB as a persistence layer.

NoSQL, especially key-value pair databases, are not simply meant to replace SQL. They are often

used as cache databases before warehousing or storage in a database cluster. Certain uses specific to

the IoT have emerged. For instance, BerkeleyDB is used on field devices or on gateways as a cache

before data is being sent to the Cloud [15]. It is of importance e.g. in case devices have intermittent

connectivity.


See Implementations

Implementations [17]

Implementa-

tion

Type Main-

tainer

License Commer-

cial Sup-

port

Interfac-

ing Lan-

guage(s)

Comments

BerkeleyDB Key-

value

pair

Oracle Proprie-

tary

Yes C++, Perl,

Tcl, Java

Early implementa-

tion of this kind

(1994)

DynamoDB Key- Amazon Proprie- Yes Java, JS, Influenced most



D2.1

ANNEX

© 2016 221


value

pair

tary C#, Py-

thon, Ruby

of the other im-

plementations [4]

Available only in

AWS Cloud

Kyoto Cabi-

net

Key-

value

pair

FAB

Labs

GPL/LG

PL

No (not

main-

tained

anymore)

Redis Key-

value

pair

(typed

values)

Redis

Labs

BSD Yes Lua (and

50+ oth-

ers)

Most widely used

key-value pair

database

LevelDB Key-

value

pair

Google MIT No C++, JS LevelDB is an

append-only log

buffer without any

higher-level data-

base services or

means for distri-

bution/clustering.

RocksDB Key-

value

pair

Face-

book

BSD No C++ Fork of LevelDB

Founda-

tionDB

Key-

value

pair

Apple Proprie-

tary

No (not

public

anymore)

Project

Voldemort

Key-

value

pair

LinkedIn Apache No Java

MongoDB Docu-

ment-

Mon-

goDB

AGPL Yes Java, Sca-

la, GO,

Most widely used

NoSQL database



D2.1

ANNEX

© 2016 222


oriented Inc. .NET, C,

JavaScript,

HTTP, Perl

Cassandra Key-

value

Apache Apache

2

DataStax C++, Java.

.NET,

JavaScript,

Python,

Ruby, GO,

PHP, etc.

Widely used for

large data quanti-

ties and massive

read/write per-

formance (when

linear scalability is

required, which

cannot be provid-

ed by Mongo).

Open-Source

alternative to

AWS' Dyna-

moDB. Good

integration with

Apache Spark.

Riak Key-

value

Basho Apache

2

Basho C++, Java.

.NET,

JavaScript,

Python,

Ruby, GO,

PHP, etc.

Among most in-

novative competi-

tors for Cassan-

dra and Dyna-

moDB. Good

integration with

Apache Spark.

InfluxDB Time-

series

data

InfluxDa-

ta

MIT InfluxData HTTP,

Java,

PHP, GO

Perfect fit for

many IoT chal-

lenges - especial-

ly when storing &

accessing mes-

sages from/to

things in a time-

based context.

Influx has gained

a reputation as a

cutting-edge solu-



D2.1

ANNEX

© 2016 223


tion for storage of

time-series data

dropping in at

rapid rates. It is

also applicable to

the concept of

EventSourcing.






Not supported

Discovery



Not supported



filter)

Key-value pair databases only support retrieval using keys. However, depending on the value type,

they may also offer utility functions for more complex queries. For instance, Redis supports range

queries over sorted sets and bitmap or geospatial indexing.

Document-oriented databases like MongoDB usually define their own SQL-like query language, with

comparable expressiveness.




D2.1

ANNEX

© 2016 224


System-specific


System-specific



Not supported

Tasking



Not supported



Not supported




In general, stream or processing is an application where relational databases do not yield best results

(similarly to data warehouse, text processing and scientific data [17]). However, despite that the term

NoSQL could be used to describe systems that address that specific issue (e.g. StreamBase), it is out

of our current scope. Indeed, stream processing requires efficient querying, which key-value pair da-

tabases (our focus) do not fully address it.



D2.1

ANNEX

© 2016 225






Not supported

Security management


Not supported

Privacy management


the users.

Not supported



streams).

Not supported




Not supported




D2.1

ANNEX

© 2016 226



Since key-value pair databases emerged in the context of Cloud computing, they are closely related to

the notions of quality of service (QoS) and service level agreement (SLA). DynamoDB was designed

with the objective that strict SLAs "have to be met in the 99.9th percentile of the distribution" [17]. As a

consequence, the platform requires high elasticity, which is being addressed by parallelization and

BASE transactions, common features of most key-value pair databases.

This requirements from Cloud computing extend to IoT platforms. EVRYTHNG, for instance, considers

SLA as a selling point, as shown by their white paper dealing with scalability [19].

1.4.2. RDF stores

Metadata


RDF stores


W3C (RDF)


https://www.w3.org/TR/2013/REC-sparql11-overview-20130321/ (SPARQL 1.1 Overview)

General Information


Sensors, connected devices or any IoT system will likely generate (1) a massive amount of heteroge-

neous data, (2) at a high rate. While relational databases have been the dominant model to store data

in the past, they do not fully address these two challenges. Database schemas lack flexibility and main-

taining their consistency (generally through transactions) turned out to be expensive for highly dynamic

systems.

https://www.w3.org/TR/2013/REC-sparql11-overview-20130321/



D2.1

ANNEX

© 2016 227

Metadata

Semantic technologies, RDF in the first place, have been identified as a powerful device to address

data heterogeneity in the IoT [1,2,3]. Semantic modeling tools and exchange formats are surveyed in

an other section of the present report. This section focuses on the state-of-the-art in storing semantical-

ly annotated data. It also tries to evaluate the effectiveness of existing solutions against the second

challenge cited above.

As RDF is a standardized, mature set of technologies for semantic annotation, we focus here on non-

relational databases that support SPARQL, the RDF query language, as specified by the W3C [4]. In

the following, we will simply denote them as RDF stores.



SPARQL (SPARQL Protocol and RDF Query Language) is a set of specifications that define a query

language for RDF data, along with protocols for querying and result set serialization formats (XML,

JSON). The SPARQL query language was meant to look familiar to SQL users, It reuses part of its

syntax but also introduces a way to express complex graph patterns, since RDF data can be interpret-

ed as a graph. SPARQL is often used in conjunction with reasoners to dynamically infer knowledge, at

query time, according to given semantics.

SPARQL makes no assumption about underlying data structures. As a consequence, there are several

ways to implement RDF stores, designed to meet distinct requirements. The oldest family of RDF

stores includes wrappers around conventional DBMS that map SPARQL queries to SQL. There are

then to be seen as database extensions, which is the case in Oracle or IBM DB2. More recent storage

systems still partly rely on relational schemas but they also add dedicated indexes and/or re-order ta-

bles to accelerate retrieval (e.g. vertical partitioning). Finally, on can cite a last family of RDF stores that

define their own data structures, usually focusing on query processing speed or reasoning. RDF stores

can also be distributed and rely on third-party frameworks, such as Hadoop.


See Adoption of the standard


lines]

RDF and SPARQL were first designed as the basis for the Semantic Web [5] and later for supporting

the idea of Linked Data, as illustrated by the Linked Open Data (LOD) cloud [6]. The LOD cloud is a

https://www.ctwiki.siemens.com/display/BIGIoT/D2.1+-+Non-relational+Databases#D2.1-Non-relationalDatabases-adoption



D2.1

ANNEX

© 2016 228

Metadata

graph of interlinked RDF datasets, publicly available on the Web. These datasets can be browsed,

among others, using one of the SPARQL protocols (either HTTP or Graph Protocol). They span many

application domains. e.g.:

Geographical and meteorological Information (GeoNames, AEMET...)

Healthcare & Medicine (Uniprot, KUPKB...)

Digital Asset Management (O'Reily, BNF, BBC Music...)

Statistics (see public data from the EU or UK)

Moreover, RDF stores are used in many industrial applications, outside the LOD cloud. Such specific

applications include:

Product lifecycle management (see for instance the porting to RDF of the standard IEC 61360

(eCl@ass) [7])

Building diagnostics (see IBM's project based on the Semantic Sensor Network ontology [8])

Business Analytics (see "NoETL" approach from UltraWrap)





els).



annex-g-trl_en.pdf

Storage/querying: TRL 9

In 2014, there were 175 datasets that had a SPARQL interface [9]. Some of them contain billions of

statements and RDF store implementations have proven their scalability over such datasets. The Bil-

lion Triple Challenge, the Berlin SPARQL Benchmark (BSBM) or the Lehigh University Benchmark

(LUBM) are well-established comparison frameworks that were designed to assess it. After one decade

of active academic research about large-scale RDF storage, the industry has found various applica-

tions for it, as mentioned previously (eCl@ass, IBM building diagnostics system or UltraWrap's NoETL

approach), and commercial products exist (Stardog, GraphDB...).

Reasoning/Update: TRL 5

https://www.ctwiki.siemens.com/display/BIGIoT/D2.1+-+Non-relational+Databases#D2.1-Non-relationalDatabases-adoption





D2.1

ANNEX

© 2016 229

Metadata

Although SPARQL was first specified about ten years ago, it had not supported update until 2013 and

SPARQL 1.1. Stream processing of RDF data is still a research field [10], which has not yet found its

way to industrial systems. Moreover, despite that reasoning is usually included in RDF stores, this fea-

ture suffers from a lack of scalability. GraphDB is the only commercial product that advertise reasoning

capability over more than one billion triples.









lines]



Some of the datasets or projects mentioned above are already in the context of the IoT. For instance,

the AEMET meteorological dataset or the building diagnostics system from IBM both rely on the Se-

mantic Sensor Network ontology, that is currently being standardized by the W3C. One should also

mention research projects like SPITFIRE, OpenIoT or IoT@Work, that make use of RDF stores to se-

mantically enrich sensor data or to annotate connected devices.


All RDF store implementations provide an API to one or more programming languages. See the Se-

mantic Descriptions section for a list of existing tools to process RDF data.



D2.1

ANNEX

© 2016 230

Adoption of the standard [11,12]

Implementa-

tion*

License Commer-

cial Sup-

port

Interfacing

Lan-

guage(s)

SPARQL

Exten-

sions

Reason-

ing Capa-

bilities

Comments

Jena Fuseki Apache

License

No Java Full-text

search

RDFS,

Rule-

based

Virtuoso GPLv2 or

Proprie-

tary

Yes C++ (,

Java...)

RDF to

relational

integration,

incremen-

tal insert

(using

WebDAV)

Used by

the biggest

publicly

available

dataset

(DBpedia)

Stardog Proprie-

tary

Yes Java Full-text

search,

geo-spatial

queries,

relational

to RDF

integration,

graph tra-

versal

OWL 2

AllegroGraph Proprie-

tary

Yes Lisp(, Java,

Python)

Full-text

search,

geo-spatial

queries,

extended

query pro-

tocol

RDFS,

Rule-

based

GraphDB Proprie-

tary

Yes Java Full-text

search,

data prov-

enance

Claims best

reasoning

perfor-

mances



D2.1

ANNEX

© 2016 231


framework over billions

of triples

Oracle Spatial

& Graph

Proprie-

tary

Yes Java Compli-

ance with

geo-

SPARQL

Oriented

towards

storage of

trillions of

triples and

geograph-

ical data

Profium Sense Proprie-

tary

Yes Full-text

search,

geo-spatial

queries

Claims

advance

support for

digital asset

manage-

ment (im-

ages, vide-

os, textual

resources)

Dydra Proprie-

tary

Yes Ruby(,

Java, JS,

...)

Extended

query pro-

tocol

Cloud-

centric

Blazegraph GPLv2 Yes Java Graph

traversal

More gen-

erally, is a

graph da-

tabase

supporting

SPARQL

MarkLogic Proprie-

tary

Yes Multi-modal

NoSQL

database

supporting

SPARQL

IBM DB2 Proprie- Yes Java Supports



D2.1

ANNEX

© 2016 232


tary relational

as well as

non-

relational

models

(*major implementations in bold)






RDF advocates URI-based identification (more precisely, IRI-based, allowing any non-Latin character

in a resource identifier). A Thing (or smart object) could be identified e.g. by the entry point of its Web

interface. SPARQL 1.1 includes specifications to update and delete RDF data, often referred to as

SPARQL Update of SPARUL.

Discovery



SPARQL provides an extensive graph pattern algebra to formulate queries. As an example, SPITFIRE

uses a crawler to extract sensor metadata in a sensor network and add them to a central RDF store.

The crawler also retrieves relevant RDF data from other sources (in the LOD cloud, for instance). A

browser can then submit SPARQL queries to the store to search for sensors. A deployment of SPIT-

FIRE in a parking lot in Berlin implemented search against sensor type, measurement and location.



queries)

SPARQL could theoretically support any search, as long as the search criteria are captured in RDF.



D2.1

ANNEX

© 2016 233



There exists RDF vocabularies for (non-exhaustive list):

geographic information (WGS84, GeoNames)

time constraints (OWL-Time)

sensor measurements (QUDT, SWEET)

but one could also use cross-domain ontologies for the IoT (SAREF, IoT-Lite, DogOnt).

Some RDF stores provide extensions to SPARQL, among others:

free text search (Apache Jena using Lucene)

implementation of geoSPARQL, an OGC standard [13] (Oracle Spatial & Graph)

other geo-spatial queries (Profium Sense, Stardog)

graph traversal and matching algorithms (Stardog, BlazeGraph using Gremlin)



RDF and SPARQL support literals and raw data. It is however not optimized for such usage.



By design, RDF and SPARQL support querying of metadata. However, in most existing systems,

metadata are stored in central repositories rather than at the device level.



complex filter)

See Discovery


SSN)



D2.1

ANNEX

© 2016 234



RDF


SPARQL 1.1 defines two protocols:

SPARQL HTTP Protocol

Graph Protocol (REST protocol, relying on HTTP but applicable to other protocols, such as CoAP)

Tasking



Not supported by the standard.







Event processing is not supported by the SPARQL standard. However, there are several research con-

tributions to run SPARQL queries over streamed data. See for instance C-SPARQL or EP-SPARQL

[10].





D2.1

ANNEX

© 2016 235






Some RDF stores natively support reasoning modules (such as Jena or Stardog). However, since rea-

soning is resource-demanding, a preferred approach is to separate reasoning from storage and facili-

tate integration through an API (as in Virtuoso). There exist several out-of-the-box reasoners that could

be integrated to RDF stores, such as Pellet, FaCT++ or HermiT (for OWL 2) or, to a certain extent,

RDFox (for rule reasoning).

Security management



Privacy management


users.




streams).







D2.1

ANNEX

© 2016 236







1.4.3. Literature

[1] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A survey,” Computer Networks, vol. 54,

no. 15, pp. 2787–2805, October 2010.

[2] A. Katasonov, O. Kaykova, O. Khriyenko, S. Nikitin, and V. Y. Terziyan, “Smart Semantic Middle-

ware for the Internet of Things,” ICINCO-ICSO, vol. 8, pp. 169–178, 2008.

[3] I. Toma, E. Simperl, and G. Hench, “A joint roadmap for Semantic technologies and the Internet of

Things,” 2009.

[4] The W3C SPARQL Working Group, “SPARQL 1.1 Overview.” W3C, 21 March 2013. Available:

https://www.w3.org/TR/2013/REC-sparql11-overview-20130321/.

[5] T. Berners-Lee, “Semantic Web Road map.” W3C, 1998. Available:

https://www.w3.org/DesignIssues/Semantic.html.

[6] M. Schmachtenberg, C. Bizer, A. Jentzsch, and R. Cyganiak, “The Linking Open Data cloud dia-

gram.” 2014. Available: http://lod-cloud.net/.

[7] M. Hepp and A. Radinger, “eClassOWL - The Web Ontology for Products and Services.” 2010.

Available: http://www.heppnetz.de/projects/eclassowl/.

[8] J. Ploennigs, A. Schumann, and F. Lécué, “Adapting Semantic Sensor Networks for Smart Building

Diagnosis,” in The Semantic Web – ISWC 2014, 2014, pp. 308–323.

[9] S. Auer, I. Ermilov, J. Lehmann, and M. Martin, “LODStats,” 2012. Available: http://stats.lod2.eu/.

[10] D. Anicic, P. Fodor, S. Rudolph, and N. Stojanovic, “EP-SPARQL: a unified language for event

processing and stream reasoning,” 2011, p. 635.



https://www.w3.org/DesignIssues/Semantic.html

http://lod-cloud.net/

http://www.heppnetz.de/projects/eclassowl/

http://stats.lod2.eu/



D2.1

ANNEX

© 2016 237

[11] “RDF Store Benchmarking.” Available: https://www.w3.org/wiki/RdfStoreBenchmarking.

[12] “Graph and RDF databases 2015,” Bloor Research, Novemver 2015.

[13] M. Perry and J. Herring, “GeoSPARQL - A Geographic Query Language for RDF Data.” OGC,

September 2012. Available: http://www.opengis.net/doc/IS/geosparql/1.0.

[14] I. Grigorik, “SSTable and Log Structured Storage: LevelDB,” igvita.com, 06-Feb-2012. Available:

https://www.igvita.com/2012/02/06/sstable-and-log-structured-storage-leveldb/

[15] M. Brey, “Solving the Internet of Things Scalability Challenge with Oracle Data Management Solu-

tions,” 2015.

[16] T. A. M. Phan, J. K. Nurminen, and M. Di Francesco, “Cloud Databases for Internet-of-Things

Data,” 2014, pp. 117–124.

[17] C. Strauch, “NoSQL Databases,” Hochschule der Medien Stuttgart, 2010.

[18] D. Feinberg, M. Adrian, N. Heudecker, A. M. Ronthal, and T. Palanca, “Magic Quadrant for Ope-

rational Database Management Systems,” Gartner Inc., Oct. 2015.

[19] “How to deliver Enterprise scale for the IoT,” EVRYTHNG.

1.5. Security

1.5.1. Diameter

Metadata


Diameter


Internet Engineering Task Force (IETF)



General Information

https://www.w3.org/wiki/RdfStoreBenchmarking

http://www.opengis.net/doc/IS/geosparql/1.0

https://www.igvita.com/2012/02/06/sstable-and-log-structured-storage-leveldb/




D2.1

ANNEX

© 2016 238

Metadata


Diameter is presented as a suitable protocol for allowing authentication, authorization and accounting

(AAA) between the different internal entities/platforms of the BIG IoT environment. AAA can be the

basis for developing appropriate billing systems thus allowing business opportunities to be deployed.



Figure 11: DIAMETER Protocol

A Diameter network is an overlay network that allows for efficient transport of AAA messages between

nodes of a telecommunication infrastructure. Furthermore, Diameter also allows the definition of AAA

applications between nodes of the Diameter network. Applications in Diameter define a set of com-

mands and each command can carry several AVPs (Attribute Value Pairs). In Diameter each compo-

nent of the protocol is extensible: you can define new applications, new commands or new AVPs. Di-

ameter also provides a mechanism by which nodes can negotiate their capabilities; in other words, the

Diameter applications that they support.

Diameter can be implemented over reliable and secure transport protocols (TLS or DTLS over SCTP),

it defines error reporting and it also defines an application ACK to provide reliability at the application

level. It is remarkable the fact that Diameter is not based on the classic client/server architecture but it

defines an overlay network by supporting agents (intermediate nodes). Diameter explicitly defines the

possible agents and their functionality. Moreover, Diameter allows agent auditability; that is to say, the

availability to detect if unreliable agents manipulate any message (attributes or headers).

Diameter also allows dynamic discovery and configuration of peers. In client/server applications the



D2.1

ANNEX

© 2016 239

Metadata

name or address of the server has to be previously known by the clients or configured manually to-

gether with the corresponding cryptographic material (like shared secrets or security tokens). This re-

sults in a considerable administrative burden and creates the temptation to reuse the cryptographic

material. In Diameter, dynamic discovery of peers through DNS and certification allow the simplification

of these tasks. Dynamic discovery and the possibility of chaining proxies are what allow the support for

secure and scalable roaming, in which a node can run AAA applications being outside its home do-

main.


Diameter is an open protocol that can be implemented with any programming language.


lines]

Diameter was designed for providing AAA in the networks of telecommunication operators.

In particular, it is being intensively used in many of the interfaces of the LTE network.


Diameter is an open standard developed by the IETF, and there some open source implementations

like freediameter.

AAA can be the basis for developing appropriate billing systems thus allowing business opportunities to

be deployed.



els).



annex-g-trl_en.pdf

TRL9. Already in production state in many infrastructures (e.g. 3GPP networks).






D2.1

ANNEX

© 2016 240

Metadata


The protocol is open. There are both proprietary and open-source implementations.


Yes, although the open-source implementations can probably suit BIG IoT needs.


Not applicable






Not applicable

Discovery



Diameter has a peer discovery capability. Besides manual configuration, which must be supported by

all Diameter nodes, two options -- SRVLOC and DNS -- may be supported for dynamic peer discovery.

The concept here is that it is required for Diameter server, or Diameter agent, to broadcast which appli-

cations they support, along with the provided security level.

Diameter clients can then depend on the desired Diameter application, security level, and realm info to

look up suitable first-hop Diameter nodes to which they can forward Diameter messages.




D2.1

ANNEX

© 2016 241




queries)

In Diameter peer discovery is done by any of the two following methods:

Service Location Protocol (SLP, SRVLOC). It is a service discovery protocol that provides a flexible

and scalable way to the computers and other devices to find the information about existence, location

and configuration of services in a network dynamically, without prior configuration.

Domain Name Service (DNS). It is the way of finding the services on the network by using standard

DNS programming interface. DNS provides with various API's for the purpose of service discovery.The

DNS Service Discovery API helps us to perform three main tasks: Registering a service (DNSService-

Register), Browsing for services (DNSServiceBrowse), Resolving service names to host names

(DNSServiceResolve).



The peer discovery protocol in Diameter allows for discovering and subscribing to services



Diameter


You can define any application/data format on top of Diameter.

Security management


Diameter security relies on the use of IPSec, TLS or DTLS. The Diameter provides with AAA security

services to any Diameter-defined application.



D2.1

ANNEX

© 2016 242





Authentication and authorization mechanisms can be Diameter applications. In this sense, most of

current standards are supported. The Diameter protocol isn't bound to a specific application running on

top of it. It focuses on general message exchanging features. Because authentication and authorization

mechanisms vary among applications, the Diameter base protocol doesn't define command codes or

AVPs specific to authentication and authorization. It is the responsibility of Diameter applications to

define their own messages and corresponding attributes based on the application's characteristics.


Once again key management mechanisms can be defined as Diameter applications. Anything is sup-

ported.



streams).

The Diameter base protocol (RFC 6733) provides an Accounting mechanism that can be used for de-

veloping the billing and charging systems of the Big IoT platform.



Diameter deploys high availability mechanisms. This mechanisms make the diameter overlay almost

always available for its applications.

1.5.2. Google “my Account”



D2.1

ANNEX

© 2016 243

Metadata


Google “my Account”


Google’s one stop self-service privacy management solution.


Ortlieb, M. (2014). The Anthropologist's View on Privacy. Security & Privacy, IEEE, 12(3), 85-87.

Google my Account Sign In - https://myaccount.google.com/ (retr. 2016-02-24)

General Information


covers essential privacy requirements, especially transparency and control



Google my Account allows users to review their data and information about Google product Usage.

This can be used for privacy management (accessing, correcting, and deleting personal information)

and to investigate account activity [1]. The Google my Account function is one of the most prominent

commercial implementations of the privacy dashboard, a privacy building block enabling transparency

of processed personal information for users[2]. It can be accessed directly or from any Google service

while logged into a Google account.


Closed source, proprietary


lines]

https://myaccount.google.com/

https://www.ctwiki.siemens.com/#_ftn1




D2.1

ANNEX

© 2016 244

Metadata

The Google my Account dashboard was designed for use with Google services, originally search and

web history. It has since expanded and covers IoT-relevant scenarios such as location tracking.


The Google "my Account" Privacy Dashboard is provided as an integral component of Google's ser-

vices.



els).



annex-g-trl_en.pdf

TRL 9, the system is in productive use by Google, and accessible to all Google account holders.



The Google my Account feature is proprietary and closed.


The Google my Account feature is not commercially available for deployment to third parties, and can

only be used with Google services.


The component cannot be used as an actual building block in Big IoT, but can serve as a base line

illustrating what level of privacy, especially wrt. Transparency, commercial players can realize in their

systems.


lines]





D2.1

ANNEX

© 2016 245

Metadata



The Google my Account privacy dashboard is used by all Google accounts. Online estimates of the

number of accounts range from 200 million to 2.2 billion[3]. It is also used by Google devices including

devices highly relevant in IoT scenarios, most prominently Google smart phones, around 1.4 billion

devices [4] (most of which are interated with a Google account).


There are not tools for developers to integrate or use the Google my Account feature independently,

however, several services with impact on the “my Account” privacy dashboard (navigation…) are avail-

able as open Web APIs with documentation from Google.






allows registration / deregistration / update of smart objects as well as the provisioning of identifiers for

new smart objects.

Security management


Allows to trace Google account activity on various devices.



Google account single sign on





D2.1

ANNEX

© 2016 246



Grant or revoke access to personal information

Privacy management


users.

Google "my Account" provides access to and download of personal information.


Control of information flow and deletion of personal information

1.5.3. OAuth

Metadata


OAuth


IETF



General Information


OAuth is presented as an example of protocols allowing for delegation of authorization to access a




D2.1

ANNEX

© 2016 247

Metadata

service or specific data from a service (or smart device in the context of BIG IoT) in distributed envi-

ronments.



OAuth allows for delegation of access rights to a protected resource (e.g. specific functions or infor-

mation from a service protected by password authentication) to a consumer application or service with-

out disclosing the authentication information a user would normally use to authenticate to the resource

(e.g. the user's password). This can be triggered either by the user as an interaction with the resource,

or by the consumer service, either by involving the user or independently. While OAuth 1.0 contained a

specific protocol (or set of protocols), OAuth 2.0 describes a more open authentication framework,

meaning it is not backward compatible with OAuth 1.0 nor are OAuth 2.0 implementations naturally

interoperable without adjustments. OAuth 2.0 is developed by the IETF OAuth WG.The functionality is

implemented through a valet (authorization) key issued by the protected resource that may have a lim-

ited scope wrt. the functionality it exposes. The key is provided to the consumer service (typically via

the user as described above). The consumer may then use the provided valet key to prove it is author-

ized to access certain functions.



D2.1

ANNEX

© 2016 248

Metadata

Figure 12: Comparison of OpenID and OAuth, Wikimedia Commons

https://commons.wikimedia.org/wiki/File:OpenIDvs.Pseudo-AuthenticationusingOAuth.svg

OAuth is related to OpenID, as it was originally developed as part of Twitter's OpenID implementation.

OpenID is however different in function in that it enables implementation of an identity provider, provid-

ing user identity attributes to a relying party (see Figure 12). In the context of this state of the art docu-

ment, we provide a more comprehensive discussion of Diameter as another example of identity man-

agement supporting a broader set of use cases with less overlap with OAuth compared to OpenID.


OAuth implementations are available for a broad range of programming languages, including C, .NET

languages like C# and VB, PHP, Python, ObjectiveC, Ruby, Perl, Lisp, Scala and others. A list of im-

plementations is available at http://oauth.net/code/.

https://commons.wikimedia.org/wiki/File:OpenIDvs.Pseudo-AuthenticationusingOAuth.svg

http://oauth.net/code/



D2.1

ANNEX

© 2016 249

Metadata


lines]

OAuth was developed for and is primarily used in the Web domain. However, there is also significant

usage in mobile apps.


OAuth is an open standard developed by the IETF, and there are many open source implementations.



els).



annex-g-trl_en.pdf

TRL 9, OAuth was developed for Twitters identity management and has since been used in many

commercial settings, including Web and mobile application and network providers.



Various, see above


Various, see above


Various, see above


lines]





D2.1

ANNEX

© 2016 250

Metadata



Facebook is broadly used by commercial players including Google, Facebook, Twitter, Amazon, Mi-

crosoft, and others (https://en.wikipedia.org/wiki/List_of_OAuth_providers). Concrete usage numbers

are not available.


Server, client, and proxy libraries exist (http://oauth.net/2/). In addition, there are providers offering

OAuth as a service. Libraries are available for a number of programming languages (see above).






OAuth supports the provisioning of valet keys to consumers, both services and mobile applications.

Security management


The valet key can be used to consume services, including on smart devices.



OAuth is such a mechanism.


https://en.wikipedia.org/wiki/List_of_OAuth_providers

http://oauth.net/2/



D2.1

ANNEX

© 2016 251



OAuth valet keys are typically generated randomly.

Privacy management


OAuth allows for selective access to resources (user control).

1.5.4. XACML

Metadata


XACML


OASIS standard


https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

https://www.researchgate.net/publication/228762031_OASIS_eXtensible_access_control_markup_lang

uage_XACML_TC

https://www.oasis-open.org/committees/download.php/3661/draft-xacml-wspl-04.pdf

General Information


XACML and related access control mechanisms are a cornerstone of both security manage-

ment/authorization and privacy management/information flow control. XACML is especially suitable for

distributed systems as the various roles and functions in access control workflows are clearly seperat-

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

https://www.researchgate.net/publication/228762031_OASIS_eXtensible_access_control_markup_language_XACML_TC

https://www.researchgate.net/publication/228762031_OASIS_eXtensible_access_control_markup_language_XACML_TC

https://www.oasis-open.org/committees/download.php/3661/draft-xacml-wspl-04.pdf



D2.1

ANNEX

© 2016 252

Metadata

ed into individual components that can be distributed across the various nodes of the system.



Figure 13: XACML protocol representation

The XACML (eXtensible Access Control Markup Language) standard allows a declarative specification

of XML access control policies for attribute-based access control (ABAC). XACML specifies an XML

schema for expressing policies, policy sets, and rules. It also offers a terminology for talking about

components of an access control system: the PEP (policy enforcement point) controls access to a re-

source and receives requests. The PDP (policy decision point) is the place where the actual decision

about the request will take place, based on a policy provided by a PRP/PAP (policy retriev-

al/administration point), using information from a PIP (policy information point) to base the decision on.

XACML can also specify obligations that have to be executed before or after an access based on a

request.


There are several available implementations of XACML, both Open Source and commercial. Most of

the implementations are in Java, however, other language bindings exist.



D2.1

ANNEX

© 2016 253

Metadata

Name Technology License

Axiomatics Policy Server Java, .NET Commercial

ndg-xacml Python Open Source (custom AT&T)

SunXACML Java Open Source (custom Sun)

Balana Java Open Source (Apache)

AT&T XACML Java Open Source (custom AT&T)

Technology readiness level

TRL 9 - XACML is in use in commercial products, e.g. the WSO2 identity server

(http://wso2.com/products/identity-server/).



various, see above


various, see above


various, see above


lines]


http://wso2.com/products/identity-server/



D2.1

ANNEX

© 2016 254

Metadata


XACML is used in various commercial solutions, e.g. by Oracle and IBM, and many Open Source im-

plementations are available (http://stackoverflow.com/questions/2893247/who-uses-xacml).


In addition to the PxP implementations, there are also policy editors for XACML policies

(http://xacmlinfo.org/category/xacml-editor/), e.g. in the WSO2 server.



Security management


Controls access to smart objects and services.



Authorization of accesses to resources based on standard, declarative policy language. Actual access

control decision implemented in PDP/PEP.


Privacy management


users.

XACML has been used to express anonymization requirements, and can express anonymization re-

http://stackoverflow.com/questions/2893247/who-uses-xacml

http://xacmlinfo.org/category/xacml-editor/



D2.1

ANNEX

© 2016 255



quirements as an obligation.


Attribute-based access control is typically used as a basis for information flow control in privacy man-

agement.



WSPL subset of XACML standard for expressing QoS aspects, such as required encryption.



D2.1

ANNEX

© 2016 256

2. IoT Platforms

2.1. IoT Standard Frameworks

2.1.1. OGC SWE

Metadata

Name of the interoperability solution

Sensor Web Enablement (SWE)

Main drivers (e.g. EU project, company, initiative, ...)

The SWE standard family is developed at: Open Geospatial Consortium (OGC)

URL and/or bibliography entry

[1]

http://www.opengeospatial.org/ogc/markets-technologies/swe

http://www.ogcnetwork.net/swe

General Information


Contents may include history, special features, and everything else that is of interest

The Open Geospatial Consortium (OGC) started the Sensor Web Enablement (SWE) initiative back in

2003. Within the SWE working group a suite of standards has been developed which can be used as

building blocks for a "Sensor Web" [1]. SWE defines the term Sensor Web as “Web accessible sensor

networks and archived sensor data that can be discovered and accessed using standard protocols and

application programming interfaces” [2].

SWE comprises the following services: A Sensor Observation Service (SOS) [3] enables querying as

well as inserting measured sensor data and metadata. While the SOS follows a pull-based communica-

tion paradigm to access sensor data, the Sensor Alert Service (SAS) and its successor the Sensor

Event Service (SES) push sensor data to subscribed clients in case of user defined filter criteria. The

Sensor Planning Service (SPS) enables tasking of sensors (e.g., setting the sampling rate of a sen-

http://www.opengeospatial.org/ogc/markets-technologies/swe

http://www.ogcnetwork.net/swe



D2.1

ANNEX

© 2016 257

Metadata

sor). Discovery [4] of sensors is supported by implementations of Sensor Instance Registry (SIR) and

Sensor Observable Registry (SOR) [5, 6].

SWE further comprises data encodings: SensorML, an XML schema, is used to encode sensor

metadata. Observations & Measurements (O&M) is used to encode measured sensor data. O&M also

defines an XML schema.

High-level architecture (you may include a figure).

Figure 14 below shows as an overview of an example deployment scenario of the SWE services (ex-

cept SIR and SOR for discovery).

Figure 14: Deployment Scenario of the SWE Services

Implementation overview

The most prominent implementation of the SWE standards family is developed by 52°North (link:

http://52north.org/communities/sensorweb/). All OGC SWE services are implemented and made

avaliable as open source. Also, client frameworks & applications for those services are provided.

http://52north.org/communities/sensorweb/



D2.1

ANNEX

© 2016 258

Metadata

For which domain was the platform / interoperability solution designed and for which is primarily used?

[1-5 lines]

Which domains are in focus? Is it designed for cross-domain?

(Domain examples are: Smart living environment / home, Smart farming and food security, Wearables,

Smart cities, Smart mobility, Smart environment / water management, Smart manufacturing)

Focus are use cases where the (geographic) space & time play a significant role. Hence, SWE stand-

ards are particularly applicable in: Smart Farming, Smart Cities, Smart Environment / water manage-

ment

What are limits, what (or which domains) are out-of-scope for the platform?

No area is specifically declared as out-of-scope.

What is the scalability (e.g., device-level/local, global, within a city or region)

SWE services can be deployed and configured for any scale.


The SWE standards are open, international standards and independent of a business model.


TRL 3-9, depending on particular standard of the family.

SOS: 9

SPS: 7

WNS: 6

SES: 3

SIR+SOR: 3

Different companies implemented the SWE standards and deployed productive systems for some of

them.

https://ec.europa.eu/digital-agenda/en/aioti-structure



D2.1

ANNEX

© 2016 259

Metadata


Open standards.

Interoperability Measures

What measures have been taken to achieve interoperability? [10-15 lines]

Which interoperability approach is followed: e.g., open standards (which standards), open source, set-

ting a de-facto standard, eco-system (incentives), open data, open API

Open standard.

At which layer does interoperability take place: e.g., data-level, information-level, service-level

Service-level & data-level

How is interoperability to other platforms / solutions achieved? [10-15 lines]

Consider the platform / solution level (how to interact with the platform / solution) as well as its business

data/services

Open standard.

With which other standards is interoperability supported [1-5 lines]

N/A








D2.1

ANNEX

© 2016 260


Yes, at the SOS, SPS, and SIR services, sensors can be registered, deregistered, and updated.

Discovery



Yes, device/sensor discovery is supported by SIR service.



queries)

ID-based

Free text

Spatial

Temporal



Yes, via SOS service.



filter)

All:

keyword filter

value comparison

spatial



D2.1

ANNEX

© 2016 261


Temporal

Complex filter


XML + specific XML schema (O&M)


HTTP + SOAP



Yes, at the SOS, SPS, and SIR services, metadata can be queried for all registered devices / sensors.



complex filter)

ID-based

Temporal


SSN)

XML + specific XML schema (SensorML)


HTTP + SOAP

Tasking



D2.1

ANNEX

© 2016 262




Yes, the SPS service is dedicated for this.




Task definitions are sent as XML.



Yes, the SAS is dedicated for this functionality.



XMPP


XML




Yes, the SES is dedicated for this functionality.




D2.1

ANNEX

© 2016 263



XML + specific XML schema (O&M)


Yes.





Yes, the SOR service is dedicated for this functionality.



text)

XML


No


Database


No

Security management



D2.1

ANNEX

© 2016 265


No



No

2.1.2. HyperCat

Metadata

Name of the platform / interoperability solution

Hypercat


Hypercat Consortium

Funded by InnovateUK


http://www.hypercat.io/consortium.html

General Information



HyperCat is an open, lightweight JSON-based hypermedia catalogue format for exposing collections of





D2.1

ANNEX

© 2016 266

General Information

URIs. HyperCat catalogue may expose any number of URIs, each with any number of resource de-

scription framework-like (RDF-like) triple statements about it.

HyperCat supports only the functionalities ID&Lifecycle Management and Discovery of IoT assets. It

therefore offers create/read/search functionality for catalogue servers.

Implementation overview (e.g., used technological building blocks)

Key implementor of the standard is the company 1248.


[1-5 lines]




Smart Cities, Smart Mobility, Smart Environment / water, Smart Farming and food security


Hypercat enabled services can be deployed and configured for any scale.


standard


TRL 8

Multiple organizations have used the standard and tested it. However, it is quite new and still maturing.


Open standard.

http://1248.io/




D2.1

ANNEX

© 2016 268



ID-based

keyword-based

spatial



No.



Yes, through the Catalogue.



complex filter)

ID-based

keyword-based

spatial


SSN)

JSON


HTTP REST



D2.1

ANNEX

© 2016 271




No.

2.1.3. OneM2M

Metadata


OneM2M


8 ICT Standards Development Organizations: ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC


http://www.oneM2M.org

http://www.onem2m.org/images/files/oneM2M-whitepaper-January-2015.pdf

http://www.onem2m.org/component/rsfiles/download-file/files?path=Release_2_Draft_TS%255CTS-

0001_Functional_Architecture-V2_6_0.doc&Itemid=238

http://onem2m.org/images/files/deliverables/TS-0003-Security_Solutions-V-2014-08.pdf

General Information



The purpose and goal of oneM2M 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 application servers worldwide. The

http://www.onem2m.org/


http://www.onem2m.org/component/rsfiles/download-file/files?path=Release_2_Draft_TS%255CTS-0001_Functional_Architecture-V2_6_0.doc&Itemid=238





D2.1

ANNEX

© 2016 272

Metadata

objective "any app, any device, any network" is achieved by abstracting devices and applications from

underlying access networks and technologies.

Release 1 has been released in January 2015. It includes interworking communication support, but

limited semantic support. Release 2 is planned for May-July 2016 and is focused on Semantic Interop-

erability, and the inclusion of testing specifications.

High-level architecture (you may include a figure).

oneM2M has layered model for supporting end-to-end M2M services. This layered model comprises

three layers: Application Layer, Common Service Layer and the underlying Network Service Layer. The

oneM2M architecture entities are

AE - Application Entity, containing the application logic of the M2M solution

CSE - Common Service Entity containing a set of common service functions (CFE) that are common to

a board range of M2M environment. This is the main part of the oneM2M specification.

CFS - Common Service Functions included in a CSE, CSFs can be mandatory or optional, CSF can

contain sub-functions (mandatory or optional)

NSE - Network Service Entity, provides network services to the CSE, like device triggering, device

management support, location services.



D2.1

ANNEX

© 2016 273

Metadata

Figure 15: oneM2M simplified architecture


There are multiple oneM2M based implementations, like OCEAN, OM2M, IoTDM, openMTC, oneM-

POWER.


[1-5 lines]




It is designed for cross-domain. The Use Cases have been collected from domain of Energy,

Healthcare, Enterprise, Public Services, Residential, Retail, Transportation.


"It is not oneM2M's objective to standardize the whole environment across networks, applications and

devices. The objective is to standardize interfaces so they are applicable to the entire ecosystem. The

intent is not to limit or excessively specify the activities of individual industries or businesses, but rather

to provide a means for them to interoperate openly, but securely, with one another."

(http://www.onem2m.org/images/files/oneM2M-whitepaper-January-2015.pdf)





D2.1

ANNEX

© 2016 274

Metadata


Global


Standard


TRL7


Open standard





Open standard, open API


network-level, data-level, service-level



data/services

Open standard



D2.1

ANNEX

© 2016 275


With which other standards is interoperability supported [1-5 lines]






Yes

Discovery



Yes



queries)

ID-based, keyword-based, spatial, value comparison, template, complex filter



Yes




D2.1

ANNEX

© 2016 276



filter)

ID-based, keyword-based, spatial, value comparison, template, complex filter


XML, JSON


CoAP



Planed for Release 2.

Tasking



Not aware of such mechanisms.



Yes





D2.1

ANNEX

© 2016 277


MQTT


XML, JSON




No





Release 1: no.

Release 2: will add Semantic Interoperability as new specification.



text)

RDF (Release 2)


oneM2M Base Ontology (Release 2)


triplestore (Release 2)



D2.1

ANNEX

© 2016 278



Yes (Release 2)

Security management


Yes



Mutual authentication of entities.

The Authorization function is responsible for authorizing services and data access to authenticated

entities according to provisioned access control policies and assigned roles.

Access control policy is defined as sets of conditions that define whether entities should be permitted

access to a protected resource.

The authorization function may support different authorization mechanisms, such as Access Control

List (ACL), Role Based Access Control (RBAC), etc.

The Authorization function may need to evaluate multiple access control policies in an authorization

process in order to get a finial access control decision.

(http://onem2m.org/images/files/deliverables/TS-0003-Security_Solutions-V-2014-08.pdf)

Privacy management


users.

Planned for Release 2.






D2.1

ANNEX

© 2016 279


streams).

Yes. The Service Charging and Accounting (SCA) CSF provides charging functions for the Service

Layer. It supports different charging models which also include online real time credit control. The SCA

CSF manages service layer charging policies and configuration capturing service layer chargeable

events, generating charging records and charging information. The SCA CSF can interact with the

charging System in the Underlying Network also. The SCA CSF in the IN-CSE handles the charging

information. (http://www.onem2m.org/component/rsfiles/download-

file/files?path=Release_2_Draft_TS%255CTS-0001_Functional_Architecture-V2_6_0.doc&Itemid=238)







Yes

2.1.4. FI-WARE NGSI 9/10

Metadata


FI-WARE NGSI 9/10


FI-WARE and FI-CORE projects within FI-PPP (FP7)





D2.1

ANNEX

© 2016 280

Metadata


Key IoT Players: Telefonica, NEC, Orange, University of Surrey


http://technical.openmobilealliance.org/Technical/release_program/docs/NGSI/V1_0-20120529-

A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI-

9_Open_RESTful_API_Specification_%28PRELIMINARY%29

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI-

10_Open_RESTful_API_Specification_%28PRELIMINARY%29





The usage of standards such as OMA NGSI-9/10 Context Interfaces and all specifications of FIWARE

GE APIs that are public and royalty free.


Interoperability takes place at the interface level such as the BIG IoT.



data/services

The interoperability is achieved through a standard interface, namely NGSI-10 based sources.



http://technical.openmobilealliance.org/Technical/release_program/docs/NGSI/V1_0-20120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf

http://technical.openmobilealliance.org/Technical/release_program/docs/NGSI/V1_0-20120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI-9_Open_RESTful_API_Specification_%28PRELIMINARY%29






D2.1

ANNEX

© 2016 281






Discovery



Yes, it enables through the following:

IoT Discovery GE (for meta information (who can provide what kind of information) - NSGI-9)

IoT Broker GE (for information itself - NSGI-10))



queries)

queries and subscriptions, requests for entities based on ID or entity type, and scopes (e.g. geographic

scopes within geographic area)



NGSI-10 supports queries and subscriptions for data



filter)

NGSI-10 supports restrictions, filtering based on entity attribute values and scopes (e.g. geographic



D2.1

ANNEX

© 2016 282


scopes)


JSON / XML (going to be deprecated).


HTTP REST



NGSI-9 supports queries and subscriptions for meta information about services providing information

via NGSI-10



complex filter)


scopes).


SSN)

JSON / XML (going to be deprecated)


HTTP REST

Tasking




D2.1

ANNEX

© 2016 283



Actuation command sending via FIWARE NGSI protocol (JSON via HTTP) is supported. Commands

can be translated into other protocols.




Commands can be sent in JSON via HTTP (according to FIWARE NGSI).



NGSI-10 enables subscriptions to data.


HTTP notifications. However, unclear on how data can be published.


This is service specific.




NGSI-10 services can update information (events) to IoT Broker/Context Broker and the update opera-

tion is via HTTP





D2.1

ANNEX

© 2016 284




NGSI allows the specification of entity types, supported attributes for example and based on ontolo-

gies.



text)

RDF


IoT-A ontology models


Tripelstore


yes

Security management


FIWARE Security Chapter provides authenticatioN/Authorization layer for access control to services.

Privacy management


users.




D2.1

ANNEX

© 2016 285




streams).





Not aware of such mechanisms




2.1.5. Literature

[1] Bröring, A., J. Echterhoff, S. Jirka, I. Simonis, T. Everding, C. Stasch, S. Liang, & R. Lemmens

(2011): New Generation Sensor Web Enablement. Sensors, 11(3), pp. 2652-2699 [publisher link]

[2] Botts, M; Percivall, G; Reed, C; Davidson, J. OGC Sensor Web Enablement: Overview and High

Level Architecture. Proceedings of GeoSensor Networks, 2nd International Conference, GSN 2006,

Boston, MA, USA, October 2006; Nittel, S, Labrinidis, A, Stefanidis, A, Eds.; Lecture Notes In Com-

puter Science;. Springer: Berlin, Germany, 2008; 4540, pp. 175–190.

[3] Open Geospatial Consortium. Approved Implementation Standard. Sensor Observation Service

Interface Standard, Version 2.0. OGC 12-006. (2012). Editors: Bröring, A., C. Stasch & J. Echterhoff.

Authors: Bröring, A., C. Stasch, J. Echterhoff, P. Taylor, L. Bermudez, A. Robin, J. de La Beaujardiere,

T. Ingold, C. Hollmann & S. Cox.

[4] Jirka, S., A. Bröring & C. Stasch (2009): Discovery Mechanisms for the Sensor Web. Sensors, 9(4),

pp. 2661-2681. [publisher link]

http://www.mdpi.com/1424-8220/11/3/2652/

http://www.opengeospatial.org/standards/sos



http://www.mdpi.com/1424-8220/9/4/2661



D2.1

ANNEX

© 2016 286

[5] Open Geospatial Consortium. Discussion Paper. Sensor Observable Registry. OGC 09-112.


[6] Open Geospatial Consortium. Discussion Paper. SensorML Profile for Discovery. OGC 09-033.


2.2. BEZIRK

Metadata


BEZIRK


Initiated by Bosch Corporate Research

Targeted at Open Source Community


www.bezirk.com

General Information



BEZIRK is a peer-to-peer IoT middleware for both communication and service execution on local de-

vices following the service-oriented paradigm. BEZIRK is developed with a view to facilitate asynchro-

nous interactions between the different components of an application with respect to distribution across

different devices in a network. To achieve this, BEZIRK is implemented on top-of-standard internet

protocols such as UDP over WiFi within local networks, and TCP sockets for internet communications.

BEZIRK allows end users to personalize security and privacy based on default policies and an easy-to-

use user interface. All the communication over BEZIRK is also encrypted.

The main features of BEZIRK are i) handling reliable delivery of messages among devices or services,



http://www.bezirk.com/



D2.1

ANNEX

© 2016 287

Metadata

ii) hiding service distribution, iii) enforcing security and privacy policies of the user, and iv) facilitating

dynamic service discovery and semantic addressing.

BEZIRK enables the following core features:

Interoperability: Allows direct, peer-to-peer interactions among devices from different vendors or plat-

forms in the local network without any infrastructure support.

Security and Privacy: Creation of user-defined spheres of trust for both communication and service

execution on the local devices.

Free and Easy of Use: Open Source and careful API design which allows the developer community to

swiftly utilize the middleware and develop new services. In this aspect, Bosch is driving the BEZIRK

platform to be an Open Source project in order to expand the developer community and BEZIRK's eco-

system.

High-level architecture (you may include a figure)

BEZIRK architecture is designed to be decentralized, in other words peer-to-peer. Figure 16 shows the

software architecture overview and Figure 17 illustrates a deployment example.

Figure 16: BEZIRK Software Architecture Overview



D2.1

ANNEX

© 2016 288

Metadata

Figure 17: Illustration of deployment


[1-5 lines]




BEZIRK has been developed primarily for consumer IoT domains (e.g. smart home) but can also be

implemented in multiple domains where IoT devices communicate and collaborate in a local environ-

ment, and also where users who desire privacy in their interaction with smart systems.


The BEZIRK middleware has been primarily developed for consumer IoT domains where collaboration

among devices/services takes place at the edge (e.g. within the local network). Thus, high reliability

and fault tolerance are not focused in the current implementation. Nevertheless, the core BEZIRK par-

adigms and features are generally applicable to other domains and could be adopted in industrial grade

implementations.


BEZIRK is a peer-to-peer platform without the need for centralized infrastructure, therefore it is highly




D2.1

ANNEX

© 2016 289

Metadata

scalable.


BEZIRK adopts the approach of Open Source. Its revenue by the developer community is expected

from Professional Services where customer projects are built on this platform.


TRL 5-6: BEZIRK has been validated and demonstrated in relevant environments.


BEZIRK will be released as Open Source with the exact licensing model to be confirmed later.

What do you know about the installation base of the platform / interoperability solution? [1-5 lines]

Number of sites/networks (if applicable)

Around 10-20 early adopter communities





BEZIRK follows an Open Source and Open API approach to facilitate interoperability. The decentral-

ized design requires no infrastructure which facilitates local integration without any dependencies on

backend infrastructure or providers. Another key design considerations in BEZIRK is to enable easy

middleware integration on new IoT platforms. This is achieved through the usage of standard commu-

nication protocols (e.g. IP/TCP+UDP for data transport, JSON for data encoding) and available Java

implementations for Linux/MacOS/Windows/Android and simple APIs to ensure a fast learning curve.




D2.1

ANNEX

© 2016 290


Interoperability takes place at three areas:

Communication at the semantic protocol level: Semantic protocols can be defined by service develop-

ers using JSON.

Service Execution on the device level: The Open API allows services to be executed on any BEZIRK

middleware instances.

The API provides 4 key functionalities: Messaging, Streaming, Publish/Subscribe, Semantic Address-

ing, and Privacy Management.



data/services

Interoperability is achieved on the platform level by enabling its platform including offered services

through the open API. Interoperability on the device/system level is enabled through a well-defined

communication stack (e.g. ZeroMQ) and service specific semantic protocols based on JSON.

With which other platforms is interoperability supported [1-5 lines]

Interoperability is supported through adapters. For some well-known IoT devices/systems, for example,

Philips Hue, adapters are already available.

What were the barriers for interoperability? [1-5 lines]

BEZIRK promotes interoperability only with systems in the local network





tifiers for new smart objects

This is not required as BEZIRK is fully decentralized and exploits the semantic addressing paradigm.



D2.1

ANNEX

© 2016 291


Discovery


as device type, communication protocol, or security protocols

BEZIRK uses semantic addressing to address or discover devices.



queries)

It depends on the semantic protocols. BEZIRK supports ID-based, keyword-based, spatial, temporal

and value-based discovery.


Platform enables the retrieval of (measured) data according to the “pull” communication paradigm

Yes.



filter)

Any filter types would be possible because it ultimately depends on the semantic protocol defined by

the service developer.


JSON.


Access is managed by the middleware. The low-level protocol is implemented based on ZeroMQ.



D2.1

ANNEX

© 2016 292



Platform enables the retrieval of metadata according to the “pull” communication paradigm

Yes.



complex filter)

Any filter types would be possible because it ultimately depends on the protocol defined by the service

developer.


SSN)

JSON.


Access is managed by the middleware. The low-level protocol is implemented based on ZeroMQ.

Tasking


can change a sampling rate of a sensor, open/close a valve, or lift a robot arm

Tasking can be implemented by a BEZIRK service logic, but is not a base functionality of the middle-

ware yet.






D2.1

ANNEX

© 2016 293


Tasking is supported via application defined payload.


Platform enables a client to subscribe for data streams from smart objects

Yes. Pub/Sub is the main messaging paradigm provided by the BEZIRK middleware. Services sub-

scribe to topics and the middleware delivers all relevant messages/events on those topics.



ZeroMQ is used as underling messaging protocol.

Supported data formats

JSON



cessed data and/or events created by smart objects

The BEZIRK middleware delivers events/data to services that have subscribed to the respective topics.

The actual processing of the stream data is handled by the services directly.



JSON


Yes



D2.1

ANNEX

© 2016 294





vocabulary, or ontologies

BEZIRK defines the basic semantic concepts topics, like topics and location in order to enable Pub/Sub

based communication and semantic addressing based on topics and location. The use of semantic

frameworks and ontologies for the communication at the semantic protocol level is supported, but must

be implemented by the participating services.



text)

JSON, JSON-LD




This is service specific and must be implemented by the services.



Security management

Platform enables secure access and usage of smart objects and their data

Yes, all communication among BEZIRK entities is encrypted. Only devices in a single Sphere will know

the symmetric encryption key used. BEZIRK offers convenient operations to join a device into a

Sphere.



D2.1

ANNEX

© 2016 295




N/A


Sphere keys are securely exchanged when a devices is joined into a BEZIRK Sphere.

Privacy management


users

In general, BEZIRK is a middleware for local IoT services (e.g. within a Smart Home, a Smart Car),

which empowers the user fully control where data flow. As a consequence, data anonymization is not

required. Transparency, i.e. a means to visualize to users what data are stored on a BEZIRK device or

Sphere, is still under development.

Please specify how privacy is further protected

The user who creates a Sphere is under full control who receives the data by joining only trusted de-

vices/services into a Sphere. Policies can be defined to control which data (based on topics) can leave

a Sphere, e.g. via a Pipe to Backend Service or another Sphere.



streams)

N/A





D2.1

ANNEX

© 2016 296


utation could be determined through a review process performed by users

N/A


Platform defines service level agreements (SLA) and/or quality of service (QoS) parameters

N/A

2.3. Bosch Smart City Platform (SCP)

Metadata


Bosch Smart City Platform (SCP)


Integrate heterogeneous hardware and software components into secure and flexible platform for

Smart City providers.


Peter Vigier “ The Smart City Platform - A reliable multi-tenant/multi-solution platform”

Bosch White Paper, Oct. 2014.

General Information





D2.1

ANNEX

© 2016 297

Metadata

Considering solutions for Smart Cities, the requirements differ from those known for classical enterprise

applications. In fact, Smart City installations are composed of many different solutions individually cus-

tomized for the city, but with a common need w.r.t. operation, data-sharing and security. The Smart

City platform (SCP) targets to connect the silos in the Smart City, i.e., governance, mobility, energy,

environment, industry life, tourism, etc. Bosch SCP offers tools and methods to develop, operate and

maintain such systems without sacrificing data security and privacy. The key aspects of the SCP plat-

form are:

Secure data routing / fanout

Third party and developer tooling

Data as a Service / Data tooling integration

Operational support


Figure 18 shows the two different main aspects of the Smart City platform:

1. The routing of the data-streams to the consumers, turning them into “information” and finally result-

ing into "knowledge" for people. Knowledge means that only little parts of the data or only aggregated

information are really interesting for people (UI).

2. The management and administrative components needed to successfully develop and operate

smart-city solutions and system-installations.



D2.1

ANNEX

© 2016 298

Metadata

Figure 18: SCP High Level Components (Vigier, 2014)

The platform supports a rollout and update process for all components running on top of it. This update

process includes an audit trail and rollback ability so that it is always possible to trace back from data

processed in the past back to the artefact versions used to process the data (Figure 19).

The process is widely automated but for pulling changes into a concrete city installation a manual ap-

proval step is needed (pull-request).

If a component packing step for docker images will be required, it is subject to evaluation.

Figure 19: Illustration of Software Provisioning Workflow for Bosch SCP

(Retrieved from: Bosch ConnectedCity Platform presentation by Peter Vigier, Bernd Vogt, Abdelmajid

Khelil)


Figure 20 illustrates the building blocks of the Bosch SCP along with key technologies that are used for

realizing these blocks.



D2.1

ANNEX

© 2016 299

Metadata

Figure 20: Used Technologies in Bosch SCP

(Retrieved from: Bosch ConnectedCity Platform presentation by Peter Vigier, Bernd Vogt, Abdelmajid

Khelil)


[1-5 lines]




The platform has been developed with the main focus of addressing the Smart City domain including

the smart mobility and environment domains.





D2.1

ANNEX

© 2016 300

Metadata

Smart Home and Smart Factory are currently not addressed and may be required.


The scalability on city and regional level with thousands of devices and hundreds of thousands of users

should be easy to support.


The business model is inspired by the SaaS business model. The platform provides city key stakehold-

ers to plugin varied sensors and devices and provide users access to services and data collected by

their own devices. In addition, we provide consultancies to support the stakeholders for selecting and

integrating devices.


TRL 7: System prototype demonstration in an operational environment.

The platform is currently used for customers to build solutions. First deliverables to customers are op-

erational.


SaaS - commercially available



The platform is currently deployed for 3 cities in Germany, USA, and UK.

Number of nodes connected (maybe per site; just provide an estimate that gives an idea if we are talk-

ing about five traffic lights or five thousand parking sensors)

The platform is currently connected to several smart surveillance cameras installed at customers and in

labs. It implements also the backend for varied apps for smart communities in varied cities.



D2.1

ANNEX

© 2016 301

Metadata

Number of users/customers using the interoperability solution (if applicable)

A few hundred of users are using the platform. We expect a few million users in 2-3 years.





Within Smart City projects it is very unlikely that one provider will be the only solution provider. Accord-

ingly, the platform is designed to support other solution providers to contribute and roll-out artifacts in a

quality controlled multi-staged software provisioning concept. Because of the yet very unclear concrete

requirements of solutions for cities of the future, the platform is designed to be flexible enough to sup-

port a wide span of technologies and/or programming languages. This makes it possible for the plat-

form to evolve in the required direction(s) without disrupting installations and rebuilding them from

scratch. In particular, the following measures for interoperability are stressed in the design:

The platform is easy to deploy on premise (e.g. notebook) or on varied cloud providers.

On device/sensor level: The platform is flexible integrating varied sensors and devices with varied pro-

tocols/APIs/standards.

Data-as-a-Service: The platform is able to provide Data-as-a-Service.


Data-level



data/services

Data-as-a-Service




D2.1

ANNEX

© 2016 302


FlyBits platform to provide Context-as-a-Service.


Integration of varied identity management systems






Yes.

Discovery



Yes (partially and restricted).



queries)

Flexible queries/discovery on Information Model level.



Yes.



D2.1

ANNEX

© 2016 303




filter)

Complex filters are possible.


XML and JSON.


HTTP REST, MQTT.



Yes.



complex filter)

Yes.


SSN)

XML and JSON.


HTTP REST, MQTT.



D2.1

ANNEX

© 2016 305




XML, MQTT.


Yes.





Partial support: Information-model level semantic is supported. No ontologies are used.



text)

N/A


N/A


N/A


N/A



D2.1

ANNEX

© 2016 306


Security management


Yes.



IM, Multi-tenancy.


Spring XD security.

Privacy management


users

Role based access with privacy preservation.


N/A



streams)

Partially.




D2.1

ANNEX

© 2016 307




N/A



Yes (e.g. varied resolution for video streams)

2.4. CSI Piemonte Smartdata Platform

Metadata


Smartdata Platform


CSI Piemonte


http://www.smartdatanet.it

General Information



Smartdata Platform (SDP) is based on project Yucca released in Open Source on Github:

http://www.smartdatanet.it/



D2.1

ANNEX

© 2016 308

Metadata

https://github.com/csipiemonte/yucca-userportal

https://github.com/csipiemonte/yucca-storage

https://github.com/csipiemonte/yucca-realtime

https://github.com/csipiemonte/yucca-fabriccontroller

SDP works as a Platform-as-a-Service as an IoT cloud-based platform and supports these features:

Multi-tenancy

Receives events from "things", "people" (twitter) and "application"

Expose APIs with Publish-Subscribe paradigm in near real-time

Expose APIs with Request-Response paradigm to read historical data with ODATA protocol

Different types of visibility (opendata, public, private and shared APIs)

OAUTH2 security to access non-public APIs

Complex event processing in near real-time to enrich/filter events


SDP adopts a centralized architecture type. Its main components are:

User Portal: WEB User Interface where users can define Smart Objects, streams and look for APIs to

use.

Events HUB: Broker that receives events from Smart Objects, publishes events to subscribers and

executes business logic coded by users.

Data HUB: Persistence component that stores and exposes via APIs ODATA historical data


https://github.com/csipiemonte/yucca-storage





D2.1

ANNEX

© 2016 309

Metadata

Figure 21: High-level architecture of SDP

(Retrieved from: http://developer.smartdatanet.it/wp-content/uploads/2014/09/yucca_arch.png)


SDP is built using different Open Source projects/middlewares/frameworks:

Yucca Userportal: web interface for SDP based on angularJS and Java

(https://github.com/csipiemonte/yucca-userportal)

Yucca Storage: services layer to access speed layer for SDP in Java

(https://github.com/csipiemonte/yucca-storage)

Yucca Real-time: streaming layer for SDP in Java (https://github.com/csipiemonte/yucca-realtime)

Yucca Fabriccontroller: deployed layer for SDP in Java (https://github.com/csipiemonte/yucca-

fabriccontroller)

ActiveMQ : open source messaging and Integration Patterns server (http://activemq.apache.org/)

WSO2 CEP: complex event processor middleware (http://wso2.com/products/complex-event-

http://developer.smartdatanet.it/wp-content/uploads/2014/09/yucca_arch.png






http://activemq.apache.org/enterprise-integration-patterns.html

http://activemq.apache.org/

http://wso2.com/products/complex-event-processor/

https://www.ctwiki.siemens.com/download/attachments/56066077/image2016-2-15 16:45:0.png?version=1&modificationDate=1455551101280&api=v2



D2.1

ANNEX

© 2016 310

Metadata

processor/)

WSO2 API Manager: solution for designing and publishing APIs and for scalable routing API traffic

(http://wso2.com/api-management/)

WSO2 Identity Server: Enterprise identity bus (http://wso2.com/products/identity-server/)


[1-5 lines]




SDP can serve different domains, but is mainly oriented to data for the Piedmont region in Italy.


SDP is built around a centralized PaaS approach; therefore its scalability is global.


The business model of a government agency is to facilitate value creation in society. In this sense, the

Piedmont region has developed the Smart Data Platform and included it in a context which has edited

and organized the Smart Data Net. This service is made available to public and private entities of

Piedmont. The usage is free for Piedmont residents and the region is in charge of the maintenance,

infrastructure and ecosystem evolution. In this regard, the region Piedmont has obtained a competitive

advantage on the topic of Open and Big Data, transmitting it to the economic and social system of

Piedmont.


TRL9 – SDP has proven itself in operational environment. It has been used in production environment

by more than 20 projects. Further information could be retrieved at

http://www.smartdatanet.it/progetti/ambiente.html.


http://wso2.com/products/complex-event-processor/

http://wso2.com/api-management/

http://wso2.com/products/identity-server/


http://www.smartdatanet.it/progetti/ambiente.html



D2.1

ANNEX

© 2016 311

Metadata

The Piedmont region has for years shown its interest with regional decrees on the reuse of public data

and finally issued a resolution on the subject of Open Data, the DGR October 8, 2012 n. 224,687; In

this standard, the user using the SDP find directions and rules to locate the license that suits his needs

through the use of Creative Commons licenses CC0 or CC BY. However, with respect to use the con-

tent of the SDP by the region, the reference is to the terms of use posted on smartdatanet.it portal in

which also protected the rights of those who indicates that the data are private.



One central cloud platform.



SDP has 1,400 streams defined (derived from 323 Smart Objects) at 15 Feb 2016.


SDP has 41 tenants with typically 2-3 users each.





The interoperability approach is to define the Open APIs and send events to the platform. It uses

HTTP(s)/MQTT(s) for data transport, JSON/ODATA for data encoding, and OAuth2 for authorization.


Interoperability is defined through the Open APIs for the data, information and service levels. Figure 22

shows the supported protocols

http://smartdatanet.it/



D2.1

ANNEX

© 2016 312


.

Figure 22: SDP supported protocols

(Retrieved from: http://developer.smartdatanet.it/wp-content/uploads/2015/02/prot.png)



data/services

Other platforms can interact with CSI Smartdata Platform in these ways:

sending events in a custom but well documented format (JSON over HTTPs or MQTTs)

reading historical events through ODATA API rest

subscribing to receive events in MQTTs or web socket

Actually it is not possible to manage lifecycle of smartobjects through APIs (only through web interface)

http://developer.smartdatanet.it/wp-content/uploads/2015/02/prot.png



D2.1

ANNEX

© 2016 313



Actually none.


The impossibility of manage lifecycle of smartobjects represents a barrier to a complete integration with

other platforms.






Yes, but only through user interaction with user portal. At this moment there is no APIs to manage

lifecycle of Smart Objects.

Discovery



Yes, but only through user interactions with the user portal. At this moment there is no APIs to search

Smart Objects.



queries)

Full text search on every metadata is defined.




D2.1

ANNEX

© 2016 314



Yes. Further information could be retrieved at http://developer.smartdatanet.it/docs/specifiche-per-

laccesso-ai-servizi-di-esposizione-dei-dati/



filter)

Filtering on every field defined for the event (see http://odata.org).


ODATA with output in JSON or XML formats.


HTTP REST (GET), ODATA.



Yes, but only through user interaction with user portal. At the moment there is no APIs to pull metadata.



complex filter)

Full text search on every metadata defined.


SSN)

http://developer.smartdatanet.it/docs/specifiche-per-laccesso-ai-servizi-di-esposizione-dei-dati/

http://developer.smartdatanet.it/docs/specifiche-per-laccesso-ai-servizi-di-esposizione-dei-dati/

http://odata.org/



D2.1

ANNEX

© 2016 315


HTML.


HTTP (GET).

Tasking



No.



Yes, it enables through the messaging service that offers an MQTT and Stomp over Websocket mes-

sage broker.



MQTT, Stomp over WEBSocket.


JSON.




Yes, through the siddhiQL engine. Further information could be retrieved at



D2.1

ANNEX

© 2016 316


https://docs.wso2.com/display/CEP310/Siddhi+Language+Specification.



JSON.


No, user can define event processing using siddhiQL server side. All events are processed for all con-

sumers.





Not supported by the platform.



text)

N/A

22. If ontologies are used, please specify which ones

N/A

23. Mechanism to store semantic concepts (e.g., triplestore)

N/A


https://docs.wso2.com/display/CEP310/Siddhi+Language+Specification



D2.1

ANNEX

© 2016 317


N/A

Security management


Yes, it is enabled through OAuth2.



OAuth2.


Keys are available on user portal for authenticated users.

Privacy management


users

Refer to security management.





streams)




D2.1

ANNEX

© 2016 318









2.5. FIWARE

Metadata


FIWARE


FI-WARE and FI-CORE projects within FI-PPP (FP7)


Key IoT Players: Telefonica, NEC, Orange, University of Surrey


https://www.fiware.org/

http://catalogue.fiware.org/

General Information

https://www.fiware.org/

http://catalogue.fiware.org/



D2.1

ANNEX

© 2016 319

Metadata



The FIWARE platform consists of a number of General Enablers (GEs) that are/have been developed

by different chapters within the FI-WARE and FI-CORE projects. For IoT, the IoT chapter is the most

relevant, but "Context and Data Management" chapter should also be considered. Core interfaces for

the IoT and Context GEs are the NGSI-9/10 Context Interfaces that were originally developed by OMA

and for which FIWARE defined a REST-ish interface with a few extensions.

The IoT Architecture differentiates between the IoT Edge with a connection to the devices and the IoT

Backend, which may typically run on a server/in the cloud. Through NGSI, information from devices is

provided on a higher abstraction level, using an entity-attribute model, e.g. devices, but also rooms,

cars etc. are modelled as entities which may have attributes like temperature, speed, occupation etc.

The NGSI interface allows query and subscription operations triggered by information consumers, as

well as update operations by information providers. NGSI queries and subscriptions allow the definition

of restrictions (e.g. for filtering according to values), as well as scopes, defining where to look for infor-

mation, e.g. within geographic scopes defined using coordinates (example: give me all current outdoor

temperature values within specified geographic area). NGSI data sources, e.g. on IoT NGSI Gateways,

register the information they can provide with the IoT Discovery GE using the NGSI-9 interface. The

IoT Broker GE finds suitable NGSI data sources using the IoT Discovery GE and accesses and inte-

grates information from the different NGSI data sources, possibly providing them to the Data Context-

Broker from the Data and Context Management Chapter.

The European commission has heavily invested into FIWARE; including not only the projects for build-

ing and maintaining the platform, but also e.g. invests 80M EUR into an innovation programme where

SMEs can get funding for projects using FIWARE.


Figure 23 depicts the schema behind the FIWARE platform on the major components (e.g. Generic

Enablers, or GEs) and the roles interacting with the system.



D2.1

ANNEX

© 2016 320

Metadata

Figure 23: FIWARE Platform Architecture Overview

(Retrieved from: https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE_Architecture)


The FIWARE Internet of Things Generic Enablers allow the Things to become available, searchable,

accessible, and usable resources fostering FIWARE-based Apps interaction with real-life objects. The

success behind FIWARE IoT is that all Things or IoT resources are exposed to FIWARE App develop-

ers just as other NGSI Context Entities. Therefore developers will not have to deal at all with today's

complexity and high fragmentation of IoT technologies and deployment scenarios. On the contrary, app

developers will just need to learn and use the same NGSI ContextBroker API used in FIWARE to rep-

resent all context information.

Figure 24 depicts the complete FIWARE IoT Services Enablement Architecture, including all the GEs

(Backend and IoT Edge) and their relationship in terms of APIs and communication protocols.

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE_Architecture



D2.1

ANNEX

© 2016 321

Metadata

Figure 24: FIWARE IoT Services Enablement Architecture Overview

(Retrieved

from:https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services

_Enablement_Architecture)


[1-5 lines]




FIWARE has been defined as the cross-domain Future Internet core platform. It has been used in a

variety of domains such as Smart Cities, agriculture and food safety, ehealth/AAL etc.

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture




D2.1

ANNEX

© 2016 322

Metadata


FIWARE is back-end / cloud centric platform and relies on connectivity.


FIWARE is intended to be able to serve as a large scale platform. The actual scalability may depend on

how it is deployed, e.g. you could also use hierarchies of IoT Broker/IoTDiscovery. IoT Brokers can

easily be replicated, as long as follow-up requests of one request are handled by the same servers. IoT

Discovery contains meta information (e.g. who can provide what information) that changes less fre-

quently than the actual information (measured value) which could be more easily replicated, synchro-

nizing its meta information.


FIWARE GEs are available as Open Source. An Open Source community is being established that is

to take over the further development after the end of the FI-Core project.


TRL 5: Surrey IoT Discovery; Orange IoT Data Edge Consolidation GE - Cepheus; SAP, Protocol

Adapter - MR CoAP;

TRL 9: NEC IoT Broker; Telefonica, Backend Device Management - IDAS; Telefonica, Pub-

lish/Subscribe Context Broker - Orion Context Broker;


• NEC IoT Broker: 4-clause BSD Licence

• Surrey IoT Discovery: AGPLv3

• Orange IoT Data Edge Consolidation GE – Cepheus GPLv2

• Telefonica, Backend Device Management – IDAS: AGPLv3

• SAP, Protocol Adapter - MR CoAP: 3-clause BSD License

• Telefonica, Publish/Subscribe Context Broker - Orion Context Broker: AGPLv3

With the upcoming FIWARE Open Source Community, a partly harmonization of license terms is

planned.




D2.1

ANNEX

© 2016 323

Metadata


Non-commercial FIWARE Lab instances are deployed across Europe and beyond. Further information

could be retrieved at http://infographic.lab.fiware.org/.



Some instances have thousands of sensors connected (e.g. Smart Santander).


There are more than 800 organisations using FIWARE including IoT GEs and complete FIWARE.

Around 350 startups are in a program to get trained on FIWARE for their future digital market asset

creation. There are also openly accessible FIWARE platform instances hosted by multiple nodes inside

and outside Europe providing a lab environment for testing and learning.





The usage of standards such as OMA NGSI-9/10 Context Interfaces and all specifications of FIWARE

GE APIs that are public and royalty free.


Interoperability takes place at the interface level such as the BIG IoT.



data/services

http://infographic.lab.fiware.org/



D2.1

ANNEX

© 2016 324


The interoperability is achieved through a standard interface, namely NGSI-10 based sources. In addi-

tion, the IDAS/IoT Data Edge provides interoperability with a number of existing technologies.


IDAS/IoT Data Edge provides interoperability with a number of existing technologies, e.g. UL2.0/HTTP,

MQTT, OMA LWM2M/CoAP, ThinkingThings Protocol and SIGFOX protocol.


The barriers for interoperability are:

Overall system complexity and learning curve

Lack of easy-to-use SDKs for IoT Platform and service developers

Lack of semantic expressiveness (to describe/discover data and functions)

Lack of maturity (TRL of IoT Discovery around 5)

Lack of Identity Management






Not aware of such mechanisms in FIWARE, at least not in the context of IoT

Discovery



Yes, it enables through the following:

IoT Discovery GE (for meta information (who can provide what kind of information)



D2.1

ANNEX

© 2016 325


IoT Broker GE (for information itself)



queries)

NGSI supports queries and subscriptions, requests for entities based on ID or entity type, and scopes

(e.g. geographic scopes within geographic area).



NGSI-10 supports queries and subscriptions for data.



filter)

NGSI-10 supports restrictions (e.g. filtering based on entity attribute values) and scopes (e.g. geo-

graphic).


NGSI has binding for JSON / XML (going to be deprecated).


HTTP REST





D2.1

ANNEX

© 2016 326


NGSI-9 supports queries and subscriptions for meta information about services providing information

via NGSI-10



complex filter)


scopes).


SSN)

NGSI has bindings for JSON / XML (going to be deprecated).


HTTP REST

Tasking



Actuation command sending via FIWARE NGSI protocol (JSON via HTTP) is supported. Commands

can be translated into other protocols.




Commands can be sent in JSON via HTTP (according to FIWARE NGSI).




D2.1

ANNEX

© 2016 327



NGSI-10 enables subscriptions to data.



HTTP notifications. However, unclear on how data can be published.






NGSI-10 services can update information (events) to IoT Broker/Context Broker and the update opera-

tion is via HTTP.





NGSI allows the specification of entity types, supported attributes for example and based on ontolo-

gies. No particular functionality in IoT Broker or Context Broker.

Security management


FIWARE Security Chapter provides authenticatioN/Authorization layer for access control to services.



D2.1

ANNEX

© 2016 328




The mechanism is based on OAuth 2.0.

Privacy management


users

Not aware of such mechanisms in FIWARE.



streams)

Not aware of such mechanisms in FIWARE, at least not specifically applied to IoT GEs.




Not aware of such mechanisms in FIWARE.



Not aware of such mechanisms in FIWARE



D2.1

ANNEX

© 2016 329

2.6. OpenIoT

Metadata


OpenIoT


EU project



https://github.com/OpenIotOrg/openiot/wiki

General Information



OpenIoT is developing a blueprint middleware infrastructure for implementing/integrating Internet-of-

Things solutions. The OpenIoT infrastructure will provide the means for the following:

Collecting and processing data from virtually any sensor in the world, including physical devices, sen-

sor processing algorithms, social media processing algorithms and more. Note that in OpenIoT the

term sensor refers to any components that can provide observations. OpenIoT will facilitate the integra-

tion of the above sensors with only minimal effort (i.e. few man days effort) for implementing an appro-

priate access driver.

Semantically annotating sensor data, according to the W3C Semantic Sensor Networks (SSN) specifi-

cations.

Streaming the data of the various sensors to a cloud computing infrastructure.

Dynamically discovering/querying sensors and their data.

Composing and delivering IoT services that comprise data from multiple sensors.

Visualizing IoT data based on appropriate mashups (charts, graphs, maps etc.)


https://github.com/OpenIotOrg/openiot/wiki



D2.1

ANNEX

© 2016 330

Metadata

Optimizing resources within the OpenIoT middleware and cloud computing infrastructure.

OpenIoT combines and enhances results from leading edge middleware projects, such as the Global

and the Linked Sensor Middleware (LSM) projects.


In Figure 25, it illustrates the OpenIoT architecture which comprises seven main elements that belong

to three different logical planes. These planes are the Utility/Application Plane, the Virtualized Plane

and the Physical Plane which include the following modules:

Figure 25: OpenIoT Architecture

http://code.google.com/p/deri-lsm/



D2.1

ANNEX

© 2016 331

Metadata

Figure 26: Pub/Sub method at OpenIoT

Figure 27: OpenIoT IDE (Integrated Development Environment)



D2.1

ANNEX

© 2016 332

Metadata

Utility/Application Plane

The Request Definition component enables on-the-fly specification of service requests to the OpenIoT

platform by providing a Web 2.0 interface. It comprises a set of services for specifying and formulating

such requests, while also submitting them to the Global Scheduler.

The Request Presentation component selects mashups from an appropriate library in order to facili-

tate a service presentation in a Web 2.0 interface. In order to visualize these services it communicates

directly with the Service Delivery & Utility Manager so as to retrieve the relevant data.

The Configuration and Monitoring component enables the management and configuration of func-

tionalities over the sensors and the OpenIoT services that are deployed within the OpenIoT platform.

Moreover, it enables the user to monitor the health of the different deployed modules.

Virtualized Plane

The Scheduler processes all the requests for services from the Request Definition and ensures their

proper access to the resources (e.g. data streams) that they require. This component undertakes the

following tasks: it discovers the sensors and the associated data streams that can contribute to service

setup; it manages a service and selects/enables the resources involved in service provision.

The Cloud Data Storage (Linked Stream Middleware Light: LSM-Light) enables the storage of data

streams stemming from the sensor middleware thereby acting as a cloud database. The cloud infra-

structure stores also the metadata required for the operation of the OpenIoT platform (functional data).

The prototype implementation of the OpenIoT platform uses the LSM Middleware, which has been re-

designed with push-pull data functionalities and cloud interfaces for enabling additional cloud-based

streaming processing.

The Service Delivery & Utility Manager performs a dual role. On the one hand, it combines the data

streams as indicated by service workflows within the OpenIoT system in order to deliver the requested

service (with the help of the SPARQL query provided by the Scheduler) either to the Request Presenta-

tion or a third-party application. To this end, this component makes use of the service description and

resources identified and reserved by the Scheduler component. On the other hand, this component

acts as a service metering facility, which keeps track of utility metrics for each individual service. This

metering functionality will be accordingly used to drive functionalities such as accounting, billing, and

utility-driven resource optimization. Such functionalities are essential in the scope of a utility (pay-as-

you-go) computing paradigm, such as the one promoted by OpenIoT.

Physical Plane

The Sensor Middleware (Extended Global Sensor Network: X-GSN) collects, filters, combines, and

semantically annotates data streams from virtual sensors or physical devices. It acts as a hub between

the OpenIoT platform and the physical world. The Sensor Middleware is deployed on the basis of one

or more distributed instances (nodes), which may belong to different administrative entities. The proto-

type implementation of the OpenIoT platform uses the GSN sensor middleware that has been extended



D2.1

ANNEX

© 2016 333

Metadata

and called X-GSN (Extended GSN).


Refer to the above.


[1-5 lines]




OpenIoT is designed to satisfy different domains, in particular focusing on providing efficient ways to

use and manage cloud environments for IoT entities and resources such as sensors, actuators and

smart devices.


None.


OpenIoT is an Open Source cloud solution for IoT, therefore it has a global scalability.


N/A (in the process of forming OpenIoT Foundation)


TRL 5-6: The OpenIoT platform has been validated and demonstrated in relevant environments

(CSIRO, Fraunhofer IOSB).





D2.1

ANNEX

© 2016 334

Metadata

OpenIoT is released as Open Source with LGPLv3 license.



One centralized cloud platform.



N/A





Interoperability through the used standards:

Data transport: HTTP

Data encoding: XML + RDF

Authorization: Oauth2

Further information regarding the data communication could be retrieved at

https://github.com/OpenIotOrg/openiot/wiki/X-GSN-Use.


The Sensor Middleware layer (data-level).



data/services

https://github.com/OpenIotOrg/openiot/wiki/X-GSN-Use



D2.1

ANNEX

© 2016 335


Interoperability on the platform level is enabled through the public and well documented APIs at

https://github.com/OpenIotOrg/openiot.


None.






Yes, this is enabled through the X-GSN module.

Discovery



Yes, it enables but the search criteria is defined by the data schema (ontology).



queries)

The supported search types are spatial search, value comparison, temporal and complex queries

(SPARQL query).



https://github.com/OpenIotOrg/openiot



D2.1

ANNEX

© 2016 336


Yes, it enables through the use of SPARQL endpoint.



filter)

The supported filter types are complex filter, spatial and temporal filter.


XML, JSON, RDF


SPARQL



Yes, the platform enables the retrieval of metadata through SPARQL endpoint.



complex filter)

Complex filter. The filter criteria is defined in SPARQL query,


SSN)

XML, JSON, RDF.




D2.1

ANNEX

© 2016 337


SPARQL.

Tasking



N/A.



To be implemented.




To be implemented.





Yes, OpenIoT platform is based on Semantic technologies.



text)

RDF, plain text, XML.



D2.1

ANNEX

© 2016 338



SSN ontology, OpenIoT ontology.


Triple store.


SPARQL endpoint.

Security management


User management, authentication, and authorization in OpenIoT are performed by the Privacy & Secu-

rity module and its Central Authentication Service (CAS) service.



Mechanism of using login and password.

Privacy management


users

None



streams)



D2.1

ANNEX

© 2016 339


None




None



None

2.7. Vodafone IoT Platform

Metadata


Vodafone IoT platform


Company



General Information





D2.1

ANNEX

© 2016 340

Metadata


The Vodafone IoT platform is based on the following main pillars:

Access level comprising cellular network, fixed network, local/private networks (RF, WiFi, etc)

Central Acquisition System for IoT including data collection, device management and network man-

agement

Mobile analytics for mobility/vehicles metrics


Figure 28 depicts the architecture overview for the Vodafone IoT platform.

Figure 28: Vodafone IoT Platform Architecture Overview


Figure 29 depicts the overview about the CAS block.



D2.1

ANNEX

© 2016 341

Metadata

Figure 29: CAS Block Overview


[1-5 lines]




The domains in focus are Smart Metering, Smart Home, Smart Energy, Smart Lighting, Smart City and

Smart Mobility.


Not defined.




D2.1

ANNEX

© 2016 342

Metadata


The system scalability could cover an entire country. For example the whole of Italy.


The platform is offered as a service.


TRL 6/7 - Technology installed Full-scale prototype built and integrated into intended operating system

with full interface and functionality test program in intended environment. The technology has shown

acceptable performance and reliability over a period of time


The platform is not licensed. Vodafone offer it as a service with a commercial license



2.

11. Number of nodes connected (maybe per site; just provide an estimate that gives an idea if we are

talking about five traffic lights or five thousand parking sensors)

Around 10,000 per site.







D2.1

ANNEX

© 2016 343


The solution is based on Open Standards in the metering (DLMS and WMBUS).


Interoperability takes place at the service-level for metering.



data/services

Interoperability to other platforms is achieved through the web portal and APIs.


N/A.


N/A.






Registration/deregistration is provided through provision of identifier for smart object done by the de-

vice manufacturer.

Discovery





D2.1

ANNEX

© 2016 344


Yes.



queries)

ID-based, keyword-based.



Yes.



filter)

The supported filter type is keyword filter.


XML.


SOAP.



Yes.



D2.1

ANNEX

© 2016 345




complex filter)

The supported filter type is the tree structure from the web portal.


SSN)

XML.


SOAP.

Tasking



Yes.




APIs.


14. Platform enables a client to subscribe for data streams from smart objects

No.



D2.1

ANNEX

© 2016 346





It does not enable but it is possible to develop through the workflow manager designer.


No.





N/A.

Security management


The platform various security measures including channel encryption, authentication, restricted access

based on VPN/restricted IP access.

The OTA frames use the DLMS/COSEM protocol which brings enhanced security features by providing

a controlled access to the data stored in the meter using different levels of authentication and authori-

zation using the association object. In addition, encryption can be used with various options for the

algorithms.



The platform uses HTTPS authentication (the channel access is restricted based on VPN/restricted IP

access).



D2.1

ANNEX

© 2016 347


There are 5 different system to access the meter: Installer, Maintainer, CAS, Regulation Authority, Dis-

tribution Utility. Each Object in the meter has his access rules.

The connection (in DLMS called association) with the meter may be established with lowest level secu-

rity, low level security or high level security. Lowest level security is mainly used to support the retrieval

of the structure of a meter unknown for the data collection system. Low level security (LLS) provide a

password based authentication of the client. It is typically used when the communication channel offers

adequate security to avoid eavesdropping and message (password) replay.

High level security (HLS) is a four-pass authentication, using cryptographic algorithm and secret cryp-

tographic keys. With HLS, both the Meter and the IoT platform authenticates itself. This authentication

mechanism is used in the case when the communication channel does not offer adequate security to

avoid eavesdropping and message (password) replay.


The communication between the metre and the CAS uses symmetric AES Keys (256 bit). The ex-

change of the keys is made using RSA asymmetric keys of at least 2048 bits. The system is able to

change the keys in the meters/end nodes using the DLMS protocol.

Privacy management


users

The platform provides data anonymization when they are transferred to the analytics platform.


Privacy is protected by encrypting the transmitted data.



streams)

Platforms offers the acquisition of the metering data used for billing purposes. The offered functionali-

ties are billed based on the number of the meters.



D2.1

ANNEX

© 2016 348





No.



The platform is installed in a fault tolerant and load balanced configuration. The RF transmission is

constantly monitored by monitoring the transmission of the meters and the signal strength of the signal.

2.8. WorldSensing

Metadata


Worldsensing


Worldsensing.


http://www.worldsensing.com/

http://www.bitcarrier.com/

http://www.fastprk.com/

http://www.sensefields.com/

http://www.worldsensing.com/

http://www.bitcarrier.com/

http://www.fastprk.com/

http://www.sensefields.com/



D2.1

ANNEX

© 2016 349

General Information



Worldsensing provides a unique traffic management portfolio for Smart Cities that includes Bitcarrier, a

real-time intelligent traffic management and information solution designed for both road and urban envi-

ronments. Fastprk provides an intelligent parking system and Sensefields provides an innovative sys-

tem for detecting and monitoring vehicles and traffic flow.

Fastprk, a Worldsensing’s intelligent parking solution has been commercially operational since Novem-

ber 2012. This pioneering technology has allowed Worldsensing to become one of the foremost tech-

nological companies since it has deployed the largest smart parking project with over 12,000 sensors

installed in Moscow. Fastprk also contributed towards Worldsensing being labelled by prestigious “Pike

Research” as one of the 17 companies actively shaping the Smart City ecosystem. Coinciding with the

first stage of Fastprk deployment in Moscow, Worldsensing received its first significant Series-A in-

vestment (early 2013). Since then, Worldsensing has held a strong executive and advisory team, and

has also counted on the strategic investor JFME, which has direct access to the construction giant

Acciona. This has allowed the company to grow and acquire Bitcarrier (early 2014), a world-leader in

traffic flux and journey time monitoring.

Fastprk has won two major awards. The Stockholm Smart City Living Labs Global Award 2011 and the

IBM Smart Camp 2010 London Award.

Bitcarrier was also IBM Smart Camp Winner 2011 and it has been recognized by analyst firm Gartner

as “Cool Vendor 2013” of Smart City Applications.




D2.1

ANNEX

© 2016 350

Metadata

Figure 30: Fastprk Architecture Overview

Figure 31: Sensefields Architecture Overview



D2.1

ANNEX

© 2016 351

Metadata

Figure 32: Bitcarrier Architecture Overview

Data sources:

600 street parking sensors (fastprk): submit spot status changes (free/occupied)

90 Bluetooth/WiFi antenna (bitcarrier)

3 road-side magnetometers control-stations (sensefield)

Figure 33: Client-Server Representation

Server/Cloud:



D2.1

ANNEX

© 2016 352

Metadata

Node.js + express + JWT auth

Restful API:

Bitcarrier.

Real-time traffic maps of cities

Analytics platform for operators

Travel times for short and long distances

Key traffic parameters such as hours of congestions, time spent, etc.

Origin and destination matrices: profiling of mobility

Key real-time and historic statistics

Third party data input for apis

B2C applications with real-time data

Sensefield:

Car counting

Classification of vehicles

Fastprk:

Real-time parking spot status map

Status of parking spots: free/occupied

Data latency: 10-15 s

Data storage:

1 month detailed status

Older data is aggregated (median, average, std, confidence interval…)

Client (providing customer user-friendly access to data and data analysis):

authenticated angular js app connecting to the server API.


In all three platforms, sensors push data to a server which provides some intelligence and implements

a restful API that allows retrieval of data. The server uses node.js, express, jwt and estimated data

latency is around 10-15 seconds.



D2.1

ANNEX

© 2016 353

Metadata


[1-5 lines]




WG8. Smart cities, WG9. Smart mobility


The scalability depends on the number of deployed sensors. For example, if sensors are deployed in a

city like Barcelona, the platform can monitor specific regions/quarters in Barcelona through these sen-

sors.


Worldsensing platform is proprietary code. Worldsensing business relies on providing useful data anal-

ysis of their own information sources


TRL 8: The platform is fully operational and already in use in the Barcelona region.


Not applicable, since the platform code is not released. Worldsensing's platform access will be only

provided for the deployment of the Barcelona use case.



N/A.





D2.1

ANNEX

© 2016 354

Metadata


Bitcarrier: 90 Bluetooth/Wi-Fi antennas

Fastprk: 600 street parking sensors

Sensefields: 3 road-side magnetometers control-stations

12. Number of users/customers using the interoperability solution (if applicable)

N/A.





Restful JSON API


Interoperability takes place at the information-level.



data/services

Interoperability to other platforms/solutions could be done via the RESTful APIs and already integrated

pull service.


Barcelona Sentilo.




D2.1

ANNEX

© 2016 355


Subscription/PUSH service still to be implemented. No raw access to the "actual" things/sensors.






Platform allows registration/deregistration of data consumers.

Discovery



N/A.



queries)

N/A.



Yes.





D2.1

ANNEX

© 2016 357




To be decided.


To be decided but probably JSON.




Yes.



JSON.

Security management


Yes.



Mechanism of login/password.




D2.1

ANNEX

© 2016 358


Transport Layer Security (TLS).

Privacy management


Unique identifiers are obfuscated and not correlated with external sources



streams)

Yes.


2.9. TIC Platform

Metadata


TIC Mobility platform at Berlin


VMZ Berlin – operator of the traffic information center at Berlin


http://viz-info.de

General Information

http://viz-info.de/



D2.1

ANNEX

© 2016 359

Metadata



The TIC mobility platform provided by VMZ is a data and service platform that has been developed to

provide comprehensive information on all mobility options available in Berlin. It is based on the platform

of the Traffic Information Center (TIC) of the City of Berlin. Since new mobility providers entered the

Berlin Mobility Market recently the TIC mobility platform was extended by VMZ to a multimodal mobility

platform. The platform includes real-time data from the traffic information center, mobility operators and

infrastructure providers and provides a multimodal routing platform using the modal router offered by

third parties.


Based on the TIC mobility platform various services and applications are offered to the public sec-

tor/administration, business clients and end users. Some examples are the www.viz-info.de, location-

based multimodal mobility displays and mobility apps. The TIC mobility platform of VMZ has been de-

veloped in cooperation with the City of Berlin. Usage of data provided by mobility operators is stipulated

in individual data provision contracts.

The TIC mobility platform is a decentralized system with integrated data from more than 20 external

service providers.

Figure 34: TIC Mobility Platform - Data Content

http://www.viz-info.de/



D2.1

ANNEX

© 2016 360

Metadata


The platform is also connected to an online monitoring system for air pollution and noise in the arterial

street network of Berlin.

The system comprises of three components (Figure 35).

Data platform integrating real time data from mobility providers

Routing platform

Interface to an urban environment monitoring system.

Figure 35: TIC Mobility Platform Components


[1-5 lines]




The TIC platform is primarily designed for the domain of Smart Mobility. Smart Environment is also

considered as the traffic detectors data are used to monitor air pollution and noise.


The limiting factor for the platform is the provision of data from mobility providers and low standardiza-

tion of interfaces.





D2.1

ANNEX

© 2016 361

Metadata

The scalability depends on the mobility data that are provided. If it is provided, the solution is transfera-

ble to all European metropolitan regions.


The TIC mobility platform is used to provide mobility information services and applications for the city

administration, mobility providers and other business clients (e.g. stations, airports).


TRL 9 – Actual system proven in operational environment.

Applications based on platform such as mobility websites and mobility displays are implemented and

running in various applications (www.viz-info.de, mobility displays at stations and airports), End user

apps based on the mobility platform are qualified and are ready to be launched.


SaaS (commercially available).




TIC Mobility Platform integrates the following:

Real-time data of 20 mobility Services Provider

Data from more than 350 traffic detectors

400 charging stations for electric cars

2500 free floating car sharing vehicles

Bike sharing bike

Level of Services data (congestion, dense traffic, free-flowing traffic) for a street network of 1200 km.


http://www.viz-info.de/



D2.1

ANNEX

© 2016 362





Open API (charging stations), data level (detector data), service level (modal routers).


Open API (charging stations), data level (detector data), service level (modal routers).



data/services

Interoperability on the platform level is enabled via open API.


VBB platform (Public transportation data and routing services in the region Berlin/Brandenburg).

2.10. IFTTT

Metadata


IFTTT (If This Then That)


IFTTT Inc.



D2.1

ANNEX

© 2016 363

Metadata


https://ifttt.com/

General Information


IFTTT is a service platform where users may create new services or use existing ones. Services are

actually provided by other service provider, e.g., Instagram, Dropbox, Google, Facebook etc. Similarly

in BIG IoT users will be able to create or use services that are provided by other platforms.



IFTTT is a web service platform. It enables users to create chains of simple conditional statements,

called "recipes", which are exposed as web services. They are triggered based on changes to other

web services such as Gmail, Facebook, Instagram, and Dropbox and so on. Currently 287 service pro-

viders from different domains are available via IFTTT, including: business, commerce, connected car,

connected home, fitness and wearables, mobile, Web etc.

The following Figure 36 represents a high level data infrastructure and architecture of IFTTT.

AWS RDS (Amazon Relational Database Service) maintains the current state of IFTTT's primary appli-

cation entities like users and recipes, along with their relations.The data from AWS RDS is moved be-

tween different compute and storage services. This is done by AWS Data Pipeline. Computation itself

is done in Amazon Redshift, which is a fast and large data warehouse. Redshift analyzes data using a

custom set of business intelligence tools. Amazon Simple Storage Service (AWS S3) provides the

IFTTT service platform with a cloud storage. As users interact with IFTTT platform, event data is fed

into Kafka cluster (a publish-subscribe messaging system). Finally, in order to monitor the behaviour of

the hundreds of APIs that IFTTT connects from other service providers (e.g., information about the API

requests, metrics such as response time and HTTP status codes etc.), IFTTT uses elasticsearch and

its components "Internal Monitoring & Alerting" and "Developer Dashboard". Cranium is an IFTTT plat-

form for writing ETL (extract, transform, load) jobs using SQL and Ruby, as well as for defining de-

pendencies between these jobs, and schedule their execution. Finally, IFTTT employs machine learn-

ing techniques to ensure that its users get relevant recipe recommendations and to avoid abuse. For

this purpose Apache Spark running on EC2 and S3 is deployed.

https://ifttt.com/

https://aws.amazon.com/rds/

https://aws.amazon.com/datapipeline/

https://aws.amazon.com/redshift/

https://aws.amazon.com/s3/


https://www.elastic.co/products/elasticsearch




D2.1

ANNEX

© 2016 364

Metadata

Figure 36: Amazon Relational Database Service representation


IFTTT is a commercial service platform. It is based on its own constructs (channels), which enable

definition of triggers and actions.


lines]

IFTTT is an example of a service platform, which is relevant when surveying the technology reediness

of available IoT Platforms. This is especially important when the interoperability at the platform level is

concerned, as IFTTT enables interoperability between its platform and many other platforms it con-

nects to.


There is no a clear business model in place yet. Currently IFTTT has been financed by investors. In

later stages, IFTTT may start a premium option or charge its analytic services. Its strategy may be to



D2.1

ANNEX

© 2016 365

Metadata

position itself as the backbone infrastructure for certain Internet of Things services.



els).



annex-g-trl_en.pdf

IFTTT is a commercial platform. We believe it has TRL 9.



The platform is not open source. It provides a service free of charge.


Yes.


-


lines]



Currently 287 service providers from different IoT domains are available via IFTTT, including: business,

commerce, connected car, connected home, fitness and wearables, mobile, Web etc. IFTTT gets every

day millions of recipes created by its users.






D2.1

ANNEX

© 2016 366

Metadata

No special tools are available. IFTTT offers the Maker Channel, which enables users to connect IFTTT

to a customer project.






No smart object exists in IFTTT. The platform allows registration of, so called, IFTTT recipes that ac-

complish different user's tasks.

Discovery



The platform the search and finding of IFTTT recipes.



queries)

Keyword-based is supported. Also search of IFTTT recipes via categories or domains is available.



The platform supports both "pull" and "push" communication paradigms, although the push pattern may

be more used.




D2.1

ANNEX

© 2016 367




filter)

N/A


Text is the most used data format, although the platform supports other formats too (e.g., for tasks

related to files, images etc.).


Not known.



The platform may have metadata but it is used internally.



complex filter)

N/A


SSN)

N/A


N/A



D2.1

ANNEX

© 2016 368



Tasking



IFTTT connects to other services. If a service allows control of a smart object over an API, then this

would be possible.




N/A



The platform enables a user to subscribe for data streams by writing IFTTT recipes.



IFTTT uses a messaging technology. However it is not known which technology is used. IFTTT may

relay on Apache Kafka for message exchange.


Not known.





D2.1

ANNEX

© 2016 369




The platform supports data stream processing. Apache Kafka is a part of the IFTTT architecture, but all

details are not known.



Not known.


A client-side processing is supported via Android or iOS apps.





Not known.

Security management


IFTTT uses Secure Socket Layer (SSL) software to protect the security of users personal information

during transmission.



IFTTT provides a two-step verification that protects a user's IFTTT account and mobile apps with both



D2.1

ANNEX

© 2016 370



user's password and user's phone.


N/A

Privacy management


users.

The platform provides the foundation for transparency and anonymization functions to protect privacy

of the users.


IFTTT does not sell or rent user's personal information to third parties without user's explicit consent.

They collect personal information for the personal use only.



streams).

The platform does not provide billing.




IFTTT recipes can be rated and users may express their opinion in case they like a recipe.




D2.1

ANNEX

© 2016 371




Not known.

2.11. Wubby

Metadata


Wubby


Econais


http://wubby.io

General Information



Wubby was created in 2015 as a spin-off of Econais. Econais has been in the IoT market since 2010

and has developed a number of Wi-Fi modules with very unique characteristics (smallest size, lowest

power consumption, complete software, etc) compared to any other competitive solutions in the mar-

ket.

Wubby as shown in Figure 37 is an ecosystem of software components and services for rapid devel-

opment of everyday objects. Everyday objects are physical objects embedded with electronics, soft-

ware, sensors and network connectivity to collect and exchange data. At the core of this ecosystem is

http://wubby.io/



D2.1

ANNEX

© 2016 372

Metadata

Wubby VM, that runs in the heart of an everyday object, the microcontroller. Its main duty is simple, to

provide a hardware agnostic environment for the creation of interoperable applications inside each

everyday object. And to make things even better, Wubby VM has built-in Python support, so program-

ming an everyday object becomes as simple as writing a Python script.

Figure 37: Wubby Ecosystem

(Retrieved from: http://www.wubby.io/)

But how one can develop and install an application for an everyday object? And how these everyday

objects can be managed? All these could be achieved by Wubby VM friends:

Wubby IDE is a platform independent development environment for configuration, debugging and sim-

ulation of everyday objects.

Wubby Cloud is a bunch of protocols and web services for application deployment and backend de-

vice management.

Wubby Client is the main tool for user interaction with everyday objects including managing them and

installing/updating new apps.

http://www.wubby.io/



D2.1

ANNEX

© 2016 375

Metadata

Refer to description above.


[1-5 lines]




Wubby can serve any domain that focus on low power 32bit devices.


Wubby is a solution to fuel fast development of low cost, low complexity, low power and high volume

IoT products made on Embedded Microcontroller Unit (MCU) regardless the domain that they will be

used.


The scalability is extremely high since it is a device-level platform.


The business model for the various components are as follows:

Development Environment: License per seat

Special App Libraries: License + Runtime

Runtime Environment: Base price + Lib Runtime

License to use and distribute backend Wubby: Per number and devices supported


TRL5-6: Wubby has been demonstrated in a number of different environments and commercially avail-

able hardware platforms from chip and module vendors.





D2.1

ANNEX

© 2016 376

Metadata

The business model for the various components are as follows:

Development Environment: License per seat

Special App Libraries: License + Runtime

Runtime Environment: Base price + Lib Runtime

License to use and distribute backend Wubby: Per number and devices supported



N/A.



N/A.


N/A.





The interoperability approach for Wubby is as follows:

Wubby is protocol agnostic where users can add support for their own products.

Wubby supports multiple wireless links, e.g. WiFi, BLE, etc.

Multiple security schemes can be integrated.

Device & service discovery using MQTT and layer2 frames according to individual wireless standard.



D2.1

ANNEX

© 2016 377



Wubby provides interoperability from the device level (device-service discovery, initial setup) and new

protocols could be added by installing new python libraries/modules in the device.



data/services

Wubby allows new platforms to be integrated by allowing layer 2 interoperability whenever possible

(e.g. WiFi Direct service discovery) and enables integration of new protocols by adding new applica-

tions in the Wubby VM.


N/A.


The availability of resources on the device.






Yes.

Discovery





D2.1

ANNEX

© 2016 378


Yes and devices could also do that.



queries)

ID-based, service based, product based.



Yes.



filter)

Anything.


User dependent.


User dependent.



Yes.



D2.1

ANNEX

© 2016 379




complex filter)

Anything.


SSN)

User dependent.


User dependent.

Tasking



Yes.




This is supported via application defined payload of MQTT messages.



Yes, through the messaging service that offers an MQTT message broker.



D2.1

ANNEX

© 2016 380




MQTT.


Data messaging formats such as SenML+XML, SenML+JSON, CSV.




Yes.



User defined.


User defined.









D2.1

ANNEX

© 2016 381



text)

N/A.


N/A.


N/A.


N/A.

Security management


Yes, both on device level and exchange level.



Proprietary protocol using auth tokens and a secure file system.


Through user/device/app credential management.

Privacy management




D2.1

ANNEX

© 2016 383

Metadata

Xively


LogMeIn


http://xively.com

General Information



The platform started under the name Pachube. After its acquisition by LogMeln, it was renamed to

COSM, and has later been rebranded as Xively. Xively works as a PaaS which makes it an IoT cloud-

based platform. Xively is an enterprise grade IoT software platform and easy-to-use APIs are at the

heart of what they offer. The central goal of Xively is to enable building of a "Connected Product" and a

customer shall be enabled to realize a "Connected Business". The API is composed of "microservices".


The architecture type is centralized. Figure 40 and Figure 41 depicts the architecture overviews.

http://xively.com/



D2.1

ANNEX

© 2016 384

Metadata

Figure 40: Xively Architecture Overview

(Retrieved from: http://xively.com/whats_xively/)

Figure 41: Xively Architecture Overview 2

(http://developer.xively.com/api/)

http://xively.com/whats_xively/)

http://developer.xively.com/api/



D2.1

ANNEX

© 2016 385

Metadata


Since Xively is closed source, the internal implementation details are not disclosed.


[1-5 lines]




Xively is generally designed for whichever domains where Smart Products play a role. However, to be

specific, it has mainly been applied in domains such as Smart Home and Smart Lab.


There are no limits or out-of-scope domains documented.


Xively designed to be a centralized PaaS. Thus, its scalability is global.


Xively generates revenue from Professional Services (e.g. building customer projects on their plat-

form). Further information could be retrieved at http://xively.com/solution/business_services/.


TRL9 – Xively has proven itself in operational environment.


Commercial access through PaaS.



http://xively.com/solution/business_services/



D2.1

ANNEX

© 2016 386

Metadata


One Central Cloud platform.



Website does not state any numbers of connected devices. However, due to the fact that it is a com-

mercial solution that grew over years, a very large number of connected devices can be assumed.


-





The interoperability approach is to use Open APIs. The used standards are the following:

Data transport: HTTP/MQTT

Data encoding: XML/JSON + SenML (http://tools.ietf.org/html/draft-jennings-senml-10)

Authorization: JSON Web Token (https://tools.ietf.org/html/rfc7519)


The Open API is defined for the data, information and service levels. It provides 4 key functionalities:

Blueprint service: Allows to describe the metadata and relations between device, user and organiza-

tion.

Messaging service: Via MQTT protocol, data messaging streams from devices to services can be set

up.

Time series service: Via HTTP GET request, historical data measured by connected devices can be

http://tools.ietf.org/html/draft-jennings-senml-10




D2.1

ANNEX

© 2016 387


queried.

Identity management: User accounts need to be created to use the API. Roles can be assigned to us-

ers.



data/services

Interoperability on the platform level (as well as its offered services) is enabled through the public and

well documented API.


A partner network has been established. These partner companies offer other kind of platforms (e.g.

CRM system from Salesforce, or a device-level platform from TexasInstruments) that have been inte-

grated with the Xively platform.


N/A.






Yes. Further information could be retrieved at http://developer.xively.com/api/blueprint/devices/.

Discovery


http://developer.xively.com/api/blueprint/devices/



D2.1

ANNEX

© 2016 388



Yes however very limited search criteria. Further information could be retrieved at

http://developer.xively.com/api/blueprint/devices/.



queries)

ID-based. Supported IDs are accountID, deviceTemplateID, organizationID, serialNumber.



Yes. Further information could be retrieved at http://developer.xively.com/api/timeseries/timeseries-

retrieve/.



filter)

Filtering only via time series topic and start/end time. Further information could be retrieved at

http://developer.xively.com/api/timeseries/timeseries-retrieve/.


JSON+SenML, XML+SenML, CSV (proprietary).


HTTP REST (GET).



http://developer.xively.com/api/timeseries/timeseries-retrieve/





D2.1

ANNEX

© 2016 389



Yes, the metadata about devices can be uploaded and downloaded (pull) as so-called blueprints. Fur-

ther information could be retrieved at http://developer.xively.com/tutorials/blueprint-and-messaging/.

However, only very limited metadata (e.g. accountId, serialNumber, organizationId) about a device is

specified.



complex filter)

ID filter (only: accountID, deviceTemplateID, organizationID, serialNumber). Further information could

be retrieved at http://developer.xively.com/api/blueprint/devices/.


SSN)

JSON.


HTTP REST (GET).

Tasking



This is not enabled directly as a service. However, the messaging service could be used to send com-

mands to a device. Further information could be retrieved

athttp://developer.xively.com/api/messaging/messaging-sendreceive/.




http://developer.xively.com/tutorials/blueprint-and-messaging/


http://developer.xively.com/api/messaging/messaging-sendreceive/



D2.1

ANNEX

© 2016 390


Supported tasking approach via application defined payload of MQTT messages.



Yes, this is enabled through the messaging service that offers a MQTT message broker.



MQTT.


Data messaging formats such as SenML+XML, SenML+JSON, CSV.







N/A.


N/A.




D2.1

ANNEX

© 2016 391








text)

N/A.


N/A.


N/A.


N/A.

Security management


Yes, through the Identity Management service. See:http://developer.xively.com/api/idm/.



“Access Tokens” are the authorization mechanism that all of Xively’s HTTP APIs are required to au-

http://developer.xively.com/api/idm/



D2.1

ANNEX

© 2016 392


thenticate and authorize any API call. Further information could be retrieved

athttp://developer.xively.com/api/idm/.


Through user/device/app credential management and access tokens (JSON web tokens, JWT). Further

information could be retrieved at http://developer.xively.com/api/credentials/users/.

Privacy management


users






streams)

Through customer specific business services. Further information could be retrieved at

http://xively.com/get_started/business_inquiries/.




No.



http://developer.xively.com/api/idm/

http://developer.xively.com/api/credentials/users/

http://xively.com/get_started/business_inquiries/



D2.1

ANNEX

© 2016 393


No.

2.13. Eclipse Vorto

Metadata


Eclipse Vorto


Eclipse IoT Project

Active member companies: Bosch


https://projects.eclipse.org/projects/iot.vorto

General Information



Vorto is an open source tool that allows creating and managing technology agnostic, abstract device

descriptions which are also known as information models. Information models describe the attributes

and the capabilities of real world devices. These information models upon defined could be managed

and shared within the Vorto Information Model Repository. Code Generators for these information

models ease device integration into different platforms.

Features at a glance:

IoT Tool Set

Information Model Repository

https://projects.eclipse.org/projects/iot.vorto



D2.1

ANNEX

© 2016 394

Metadata

Meta Information Model

Code Generators

Figure 42: Eclipse Vorto Components

(Retrieved from: Eclipse Vorto, Advanced Device Integration Presentation by Dr Olaf Weinmann)


Figure 43: Vorto Architecture

(Retrieved from: http://www.eclipse.org/vorto/overview/vorto_overview.html)

http://www.eclipse.org/vorto/overview/vorto_overview.html





D2.1

ANNEX

© 2016 395

Metadata


[1-5 lines]




Toolset for IoT Devices and Platforms across all domains.


Vorto has been designed to resolve the challenges of the various stakeholders in the IoT ecosystem:

Device manufacturers: to increase the number of ecosystems where their devices can be integrated.

Platform vendors: to integrate as much devices as possible into their ecosystem without major efforts.

Solution developers: to support a broad range of devices without a need to develop vendor specific

code.


Eclipse Vorto is an open source project.


TRL 6 – technology demonstrated in relevant environment (industrially relevant environment in the

case of key enabling technologies). Vorto has been tested in various demonstrations such as the PTC

LiveWorx Europe 2015 in the Track & Trace Testbed and Bosch Corporate Research Division in creat-

ing a Vorto representation of a sample vehicle-to-cloud interface.


Eclipse Public License 1.0

Eclipse Distribution License 1.0 (BSD)



https://projects.eclipse.org/content/eclipse-public-license-1.0

https://projects.eclipse.org/content/eclipse-distribution-license-1.0-bsd



D2.1

ANNEX

© 2016 396

Metadata


See "How is Eclipse Vorto used in practice?" - http://blog.bosch-

si.com/categories/technology/2015/12/eclipse-vorto-smart-approach-high-impact-getting-products-

connected/



Wide-spread adoption of Vorto is anticipated as a result of the Eclipse Open Source IoT Framework





Open source.


Interface layer.



data/services

The objective of the IoT tool set is to allow device manufacturers to describe the devices using Infor-

mation Models in a textual DSL editor. With the Information Model Repository, platform vendors would

be able to manage, share and reuse existing Information Models directly from the tool set or via the

web. Code generators allow solution developers to create information model based code artifacts that

can be employed in specific solutions.

http://blog.bosch-si.com/categories/technology/2015/12/eclipse-vorto-smart-approach-high-impact-getting-products-connected/





D2.1

ANNEX

© 2016 397


Figure 44: Vorto's Idea for Interoperability

(Retrieved from: Eclipse Vorto, Advanced Device Integration Presentation by Dr Olaf Weinmann)


ThinkWorx platform, Bosch IoT Suite


The willingness of device manufacturers to use the solution.

deliverable 2.1: analysis of technology readiness - big...

Documents