Task Force Platform Interoperability

TF 02: Platforms Interoperability

Ovidiu Vermesan, UNIFY-IoT, SINTEF, Norway

Steffen Lohmann, Be-IoT, Fraunhofer IAIS, GermanyIoT-EPI Common Workshop, 22-23 June, 2016

Valencia, Spain

TF02: Motivation

•IoT ecosystems require interoperability to create seamless integrations

•On different levels: technical, network, syntactic, semantic, enterprise

•IoT landscape is fragmented and lacks interoperability, in terms of:•Proliferation of solutions from different OEMs•Operating systems and programing languages •Versions or times of deployment •Types of connectors and connectivity frameworks •Communication protocol standards

Architectural View

Examples of Protocol Layer Stacks

Network/Transport Layer

Physical/Link Layer (MAC/PHY)

CoAPDDS

XTypes, SecurityAPI, QoS, RTPS

MQTTXMPP

IEEE

1888

REST/HTTPSSIP /

SIMPLE

IEC 61968 CIMANSI C12.19/C12.22

DLMS COSEM

IEC 6185

0

IEC 6087

0

MODBUS

DNP

IEEE P1901.2 PHY

IEEE P1901.2 MAC

IEEE 802.11Wi-Fi

IEEE 802.3

Ethernet

IEEE 802.16 WiMax

2G/3G/LTE Mobile

IEEE 802.15.4g (FSK, DSSS, OFDM)

IEEE 802.15.4 MAC (including FHSS)

802.15.4e MAC Enhancements

802.15.4e TSCH

Bluetooth Low

EnergyBACNET DECT NFC

6LoWPAN (RFC 6282) RFC 2464 RFC 5121 RFC 5072

802.1x / EAP-TLS based Access Control

IPv6 / IPv4

TCP / UDP

6Lo6top/6LoWPAN

Application Layer

VLC WPAN

IEEE802.15.7

VLC

Examples of Protocol Layer Stacks

Network/Transport Layer

Physical/Link Layer (MAC/PHY)

CoAP

DDSXTypes, Security

API, QoS, RTPS

MQTT

XMPP

IEEE

1888

HTTP/HTTPS

SIP / SIMPL

E

IEC 61968 CIMANSI C12.19/C12.22

DLMS COSEM

IEC 6185

0

IEC 6087

0

MODBUS

/TCP

DNP

IEEE P1901.2 PHY

IEEE P1901.2 MAC

IEEE 802.11Wi-Fi

IEEE 802.3

Ethernet

IEEE 802.16 WiMax

2G/3G/LTE Mobile

IEEE 802.15.4g (FSK, DSSS, OFDM)

IEEE 802.15.4 MAC (including FHSS)

802.15.4e MAC Enhancements

802.15.4e TSCH

Bluetooth Low

EnergyBACNET DECT NFC

6LoWPAN (RFC 6282) RFC 2464 RFC 5121 RFC 5072

802.1x / EAP-TLS based Access Control

IPv6 / IPv4

TCP / UDP

6Lo6top/6LoWPAN

Application Layer

VLC WPAN

IEEE802.15.7

VLC

Internet/Webcommunication

Pull/Push, P2P, Pub-Sub,

Persistence, …

Generic IoT payload

TaxonomiesOntologies

O-MI

O-M

I

O-DF

Schema.org, O-DEF, FOAF, UNSPSC, ISO 3166-1, hl7, …

Missing at least:• Websockets:• FTP• SMTP• …

Applications

TF02: Objectives•Presentation and discussion of interoperability issues

•Knowledge exchange on existing standards and technologies

•Analysis of the state-of-the art and identification of gaps

•Discussion of challenges (security, scalability, performance, etc.)

•Collaboration between the projects to increase interoperability

TF02: Objectives•An IoT Platform is an intelligent layer that connect the things to the network and abstract applications from the things in order to enable the development of services.

•To achieve at least three main objectives:

•Flexibility (being able to deploy things in different contexts),

•Usability (being able to make the user experience easy),

•Productivity (enabling service creation in order to improve efficiency, but also enabling new service development)

TF02: Retrospective (Meetings)

•April 20: Kick-off•May 4: Online

•Sebastian Kaebisch (BIG IoT): W3C Web of Things and BIG IoT

•Raúl García-Castro (VICINITY): IoT-related ontology standardization initiatives (W3C, ETSI, oneM2M)

•May 16: Online•Arkady Zaslavsky (bIoTope): IoT interoperability in NIST, ISO and IEEE SA developments

•Ovidiu Vermesan (UNIFY-IoT): Report on EU-NIST meeting and international cooperation

•June 15: Online•Kary Främing (bIoTope)

•June 23: F2F Meeting

TF02: Workshop AgendaThursday 23 June 2016

08:45-09:00 Welcome

09:00-10:30

Welcome and agenda Introduction of participants Presentation of TF objectives, activities, milestones, outcome Interoperability and IoT architectures (including SoA approaches) NIST IoT/CPS developments ISO, IIC and Web of Things feedback, Open Group White Paper SAREF ontology, W3C, ETSI ISO, ITU and IEEE AIOTI approach Project requirements and gap analysis

10:30-11:00 Coffee Break

11:00-12:30

IoT Platforms Interoperability approaches prepared by the EPI-projects(7 Presentations)

Synergies common approaches Panel discussion Identify the challenges and the elements

beyond SoA – IoT platforms that are communicable, operable, and programmable across devices, communication infrastructure, applications, etc. regardless of make, model, manufacturer, or industry.

Outcome and action plan

12:30-13:30 Lunch

IoT Platforms

•Connectivity / M2M platforms. These platforms focus mainly on the connectivity of connected IoT devices via telecommunication networks (e.g., SIM-cards) but rarely on the processing and enrichment of different sets of sensor data. (An example of a connectivity platform is Sierra Wireless’ AirVantage)•IaaS backends. Infrastructure-as-a-service backends provide hosting space and processing power for applications and services. These backends used to be optimized for desktop and mobile applications but IoT is now also in focus. (An example IBM Bluemix)•Hardware-specific software platforms. Some companies that sell connected devices have built their own proprietary software backend. They like to refer to the backend as an IoT Platform. Since the platform is not open to anyone else on the market it is debatable whether one should call it an IoT Platform. (An example is Google Nest)•Consumer/Enterprise software extensions. Existing enterprise software packages and operating systems are increasingly allowing the integration of IoT devices. Currently these extensions are often not advanced enough to classify as a full IoT Platform – but they may get there soon.

E2E IoT Platforms

https://iot-analytics.com/wp/wp-content/uploads/2016/01/iotplatformcomponents-v1-min.png

IoT Platforms

•Connectivity & normalization: brings different protocols and different data formats into one “software” interface ensuring accurate data streaming and interaction with all devices.•Device management: ensures the connected “things” are working properly, seamlessly running patches and updates for software and applications running on the device or edge gateways.•Database: scalable storage of device data brings the requirements for hybrid cloud-based databases to a new level in terms of data volume, variety, velocity and veracity.•Processing & action management: brings data to life with rule-based event-action-triggers enabling execution of “smart” actions based on specific sensor data.•Analytics: performs a range of complex analysis from basic data clustering and deep machine learning to predictive analytics extracting the most value out of the IoT data-stream.•Visualization: enables humans to see patterns and observe trends from visualization dashboards where data is vividly portrayed through line-, stacked-, or pie charts, 2D- or even 3D-models.•Additional tools: allow IoT developers prototype, test and market the IoT use case creating platform ecosystem apps for visualizing, managing and controlling connected devices.•External interfaces: integrate with 3rd-party systems and the rest of the wider IT-ecosystem via built-in application programming interfaces (API), software development kits (SDK), and gateways.

IoT Platforms

•Organic bottom-up approach: Starting with the connectivity part and building out platform features from the bottom-up (e.g., Ayla Networks)•Organic top-down approach: Starting with the analytics part and building out platform features from the top-down (e.g., IBM IoT Foundation)•Partnership approach: Striking alliances to offer the full package (e.g., GE Predix & PTC Thingworx)•M&A approach: Targeted acquisitions (e.g., Amazon – 2lemetry) or contenders performing strategic mergers (e.g., Nokia & Alcatel-Lucent)•Investment approach: Tactical investments throughout the IoT ecosystem (e.g., Cisco).

Open-source-IoT Platform ecosystem

(Source: www.eclipse.org/vorto/)

https://www.eclipse.org/vorto/

https://iot-analytics.com/wp/wp-content/uploads/2016/01/vorto-min.png

Platforms InteroperabilityKary Främling, bIoTope, Aalto University, Finland

IoT-EPI Common Workshop, 22-23 June, 2016Valencia, Spain

IoT today: usual view/implementation

16

MQTT/CoAP/…

REST API

Cloud

Machine/Device

Michael Porter, James Heppelmann. How Smart, Connected Products Are Transforming Companies. Harvard Business Review, November 2014.

REST API

M2M and machine-to-cloud standards

•Standards such as MQTT, CoAP, AMQP, …•Binary, using TCP/UDP as underlying protocols•Suitable for:

• Resource-constrained devices• Massive ”pushing” of data from

constrained devices to Cloud• Local M2M communication

•Challenges • Run on TCP/UDP only• Firewalls are challenging

(avoidable with e.g. WebSockets)• Payload tends to be in JSON/XML so

advantages of binary compactness tend to be lost

•Not intended nor suitable for Web-based information systems

•Many standards use Pub/Sub model (centralised) rather than Observer (peer-to-peer)

17

REST APIs

•REST is not a standard•Mainly used for publishing information on Web, i.e. using HTTP or HTTPS•”IoT REST APIs” are (all?) proprietary •”Low-level IoT”+”REST API” make IoT systems more complex than they should be

•Low-level IoT up to Gateway level + sensor/device to Cloud•REST APIs for web-based systems such as energy prices, weather forecasts, maintenance systems etc.

18

What this signifies in practice for IoT today

•Different interfaces for devices/machines and other information systems•Proprietary APIs and Payload semantics•Requires implementation and support of tens or hundreds of ”adapters”, ”plug-ins”, ”drivers” etc.

19

Example: Car arriving in town

IoT CRUDCreate

Read

Update

Delete

1. New ”system” appears

2. Read/subscribeto data,

information, events, …

3. Write data, information, events, …

4. Remove ”system” or parts of it

with O-MI and O-DF1. ”Publish” with

O-MI write

2. O-MI read/subscription

3. Update with O-MI write

4. No O-MI delete yet

O-MI: Open Messaging InterfaceO-DF: Open Data FormatStandards published by The Open Group in 2014

Presentation Title or Event 22

Demonstration

Partner Name

Smart House

23

House owner, inhabitants

Power monitoring

Weather station

Integrated control, Internet gateway

Manufacturers, maintenance and service companies, electricity providers, ...

Smart Grid

Local power production

Ventilation, refrigerators, ...

Energy prices, forecasts, control commands etc.

Data acquisition, visualisation, analysis, control, etc. (server/cloud)

1. Asemo internals (seecc+webkeruudlogsender)

2. Temperature & humidity sensors

3. Enervent Pandion

Reference Implementation

•Published as Open Source•Plan: disseminate through iot.eclipse.org•Implements:

•URL-based discovery and read operations•Web GUI for more advanced operations

•Source Code in Github : https://github.com/AaltoAsia/O-MI•Implementations in several languages exist•Data publication and acquisition for instance with simple Unix Shell Script

Partner Name Presentation Title or Event 24

IoT stack

25

ApplicationDifferent ”platforms”

Taxonomies/OntologiesO-DEF / domain vocabularies /

proprietary vocabularies

Generic IoT Data DescriptionOpen Data Format (O-DF)

Generic IoT MessagingOpen Messaging Interface (O-MI)

Internet CommunicationHTTP/HTTPS/SMTP/TCP/XMPP/FTP…

Lower-level CommunicationISO-OSI model layers 1-6

Generic: OpenIoT, IBM Bluemix, …Domain/company-specific: Energy providers, Fleet management, …

Standards from ISO, SAE, IEEE, The Open Group (or proprietary)

Like HTML for Web

Support necessary IoT operations:subscription, persistence, piggy-backing, callback, …

O-MI can use any of these, and even non-internet communication such as USB sticks and possible future networks

MQTTUses TCP/IP

Some words about Security

•Reference implementation uses SSL with Client authentication•Same certificate in all ”my” (Kary’s) devices•Certificate management a challenge•Access control currently read/write for O-DF Objects/InfoItems

26

BO-MI node

AO-MI node

bIoTope Big Picture

27

P1

P2

P3

P4

P5

UC1 UC2UC3

DS

DE

Storage & Sensing & Actuation Layer

SR

O-MI/O-DF

Coordination layer/Ecosystem Coordinator

Platform/Tool O-MI/O-DF Compliant Wrapper

Smart Connectedobjects

Wrapper Generator

SR

SR

SR

IoT EPIecosystems

SR

Data ContextKnowledge

WSNWSN

OpenFlexibleVersatileHeterogeneous

bIoTope ecosystementry point

What can we do already?

•Publish IoT services/information•Discover IoT services/information •Exchange and subscribe to information•Unprotected or protected with standard Web security and access control (passwords, public/private keys etc.)•O-DF based access control•Semantic annotations by linking to existing standards (O-DF)

©bIoTope Consortium

What do we need to develop?•How do we find relevant O-MI nodes

•Locally?•On internet?

•More generic queries than those provided by O-DF only?•E.g. ”Find parking/charging place close to address X for charging my EV”•O-DF provides necessary information about my Electrical Vehicle•O-DF can describe all parking places/charging stations•Service query would be something like: ”findEVParking(myCar)”•Can be implemented by O-MI write, where ”findEVParking” is infoItem of parking/charging service, ”myCar” is O-DF structure for the query and the returned result is O-DF structure of reserved parking/charging place

•Ad hoc security mechanisms•Universal Identification•Trust-based security (remember for instance ”car arrives into town” example!)

•Necessary reasoning mechanisms that are not yet provided by existing platforms•Aalto has platforms using ”generic agents”•OpenIoT has ”reasoning mechanisms”•Partner platforms have their own mechanisms

©bIoTope Consortium

Thank You!

VICINITY Interoperability ApproachTF02 Platforms Interoperability

Viktor Oravec, bAvenir


What is the aim of VICINITY?

The VICINITY project will build and demonstrate a bottom-up ecosystem of decentralised

interoperability of IoT infrastructures called virtual neighbourhood, where users can share the access to

their smart objects without losing the control over them.

VICINITY Architecture approach

Isolated IoT infrastructures

Build your IoT social network through Open

VICINITY platform

Explore your neighbourhood and expand your social

network

Architecture approach in example

ABCas facility manager wish

• to extend measuring outdoor temperature and luminance for

improved HVAC management without investing in new IoT

infrastructure,• to monitor Reagon’s energy

consumption to improve Reagon’s energy plans

• accessing data by own IoT infrastructure

ACME Inc.is sharing building infrastructure for including indoor and outdoor temperature and luminance.

Reagonis sharing energy consumption measurements from the small IoT infrastructure.

https://portals.exosite.com/views/2982322286/1293028459

VICINITY interoperability approach

•Interoperability as a service for existing IoT platforms

•IoT platform level•Open VICINITY gateway API

•With sample adapters•Trust, security and privacy assuring mechanisms

•IoT device level•Discovery and dynamic configuration

•All levels•Standard communication and data exchange protocols•Shared ontology based on standards

Thank You!

Approaches to Semantic Interoperability

TF02 - Platforms InteroperabilityMichael Jacoby, symbIoTe, Fraunhofer IOSB, Germany


Presentation Outline

•Objectives w.r.t. Interoperability•Interoperability in symbIoTe•Possible Approaches to Semantic Interoperability•What we have done so far

Objectives w.r.t. Interoperability

•Enable platform federation for existing and future platforms•Every platform has its own information model•Problem:Find/Discover and access resources of different platforms

Common understanding sensors, actuators & services needed

symbIoTe Core Services

Resource Monitor

Authentication and Authorization

Resource Access andStatistics

Cross-Platform Applications

IoT Platform A

Interworking interface/API

IoT Platform B

Interworking interface/APIAuthentication

and Authorization

Manager

Bartering and Trading

Interoperability in symbIoTe

FederationManager

Authentication and

Authorization Manager

Bartering and Trading

FederationManager

RegistrationHandler

RegistrationHandler

Syntactical Interoperability

symbIoTe

Registry

symbIoTe Search Engine

Semantic Interoperability

Approaches to Semantic Interoperability

•Currently main focus on finding/discovering sensors, actuators & service across platforms•Assumption

•platforms describe available sensors, actuators & services using ontologies

Single core

ontology

Mapping between

platform-specific ontologies

Pre-mapped best

practice ontologies

Multiple core ontologies

Core ontology with extension

points

•Single core ontology is the only information model that can be used•Pro

•Clearly defined information model easy to use

•Contra•What’s not modelled in the core ontology cannot be expressed would exclude some platforms with needs for very specific

information models

Single core ontology

Mapping between platform-specific

ontologies

Pre-mapped best practice

ontologies


Core ontology with extension points

•Every platform provides their own information model/ontology•Mappings between ontologies must be defined•Pro

•All platforms/information models are supported

•Contra•Discovery only possible when a mapping exists (+ symbIoTe cannot understand any of the sensors, actuators & services the platforms are offering)•Problem: How to find ontologies to align to? possible solutions e.g. full text search



ontologies


ontologies



•A core ontology which is explicitly designed for extension•Somehow like an upper ontology for IoT or like SSNO for sensing

•Use mappings between different implementations of extensions•Pro

•Basic information understandable to all platforms (incl. symbIoTe)

•Contra•Introduce extension points at which level?



ontologies


ontologies



•Provide multiple core ontologies & mapping between them•Restrict platforms to only use one of these ontologies•Pro

•Broader support of platform than a single core ontology

•Contra•May still not be suitable for all platforms



ontologies


ontologies



•Similar to Multiple Core Ontologies except platforms are not restricted to use one of the core ontologies but can also use their own •Pro

•As open as Mapping between Ontologies but easier to use for platform providers not familiar with semantics•Better and broader interoperability due to already aligned best practice ontologies

•Contra•Same as Mapping between platform-specific ontologies



ontologies


ontologies



What we have done so far

•Analysis of•Existing ontologies•Mapping technologies

•Mapping languages•(Graphical) Editors•SPARQL query re-writing based on mapping definitions

•Supporting tools•Mapping JSON/XML/RDB to RDF

Thank You!

INTER-IoT: Interoperability Session

IoT-EPI Meeting - Valencia 22nd- 23rd June 2016

INTRODUCTION

•The overall goal of the INTER-IoT project is to provide an interoperable open IoT framework (with associated engineering tools and methodology) for seamless integration of heterogeneous IoT platforms functioning in the same or different application domains •The INTER-IoT approach is generic and may be applied to any application domain and across domains, in which there is a need to interconnect IoT platforms already deployed or add new ones.

INTRODUCTION

Architectural Components

•INTER-IoT will be based on three main building blocks:•INTER-LAYER: Methods and tools for providing interoperability among and across each layers of IoT platforms;•INTER-FW: Global framework for programming and managing interoperable IoT platforms, including an API;•Engineering Methodology based on CASE tool for IoT platforms integration/interconnection, in order to support the INTER-IoT methodology INTER-METH.

INTER-IoT Interoperabilty basics

•Make heterogeneous devices interoperate•to access them through a unifying interface•to integrate them into any IoT platform.

•New techniques for protocol adaptation and encapsulation to support communications among heterogeneous smart objects and mobility of smart objects between heterogeneous IoT platforms.•Discovery and management of heterogeneous smart objects and for heterogeneous middleware component integration

INTER-IoT Interoperabilty basics

•To develop composition methods for heterogeneous application services to provide a super-infrastructure for guaranteeing interoperability among services exported by IoT platforms. •To design procedures and methods to translate/match data and semantics to be reused on heterogeneous IoT systems.•To analyze and define solutions for basic non-functional requirements correlated to interoperability and will be addressed at every layer: (i) Reliability; (ii) Security; (iii) Privacy; (iv) Trust.

INTER-LAYER

•INTER-IoT considers a layered independent approach with five layers (top-down):

•Data and Semantics layer•Applications and Services layer•Middleware layer•Network layer•Device layer•Cross-layer: resilience, security, privacy and trust, QoS issues, …

INTER-LAYER

INTER-LAYER: D2D

Virtual Plane

Physical Plane

IP

CoAP

WiFi

DDS

NFC BLE SigFox ZigBee 4G LoRa

MQTTXMPP AMQP

VIRTUAL GW PROXY CLIENT

BROKER

API

Object&

DeviceVirtualization

Semantics

Discovery

N2N Client

QoS Other (optional) services

VIRTUAL GW PROXY SERVER

Module runtime

INTER-LAYER: N2N

INTER-LAYER: MW2W

INTER-LAYER: AS2AS

INTER-LAYER: DS2DS

Use Cases

INTER-LogP Use case INTER-Health Use case

63

Context Provisioning Service for IoT Interoperability

Partner Name CSIRO

Arkady Zaslavsky, CSIRO, Australia

IoT EP

I, TF02, 23 June, 2016, Valencia

bIoTope Project Overview 64Partner Name: CSIRO

•Fundamental design principle: Utilise an “Everything-as-a-Service” (XaaS) paradigm to deliver essential capabilities for System-of-System (SoS) platforms involving connected smart objects

Partner Name

Easing IoT solutions development

Developing 6 standardised SoS platform services for streamlining creation of IoT based solutions Information-as-a-Service (InaaS) Billing-as-a-Service (BaaS) Knowledge-as-a-Service (KwaaS) Context-as-a-Service (CoaaS) Security-as-a-Service (SecaaS) User Interaction-as-a-Service (UIaaS)

Partner Name: CSIRO

What is IoT platform•An IoT platform is a software suite or a PaaS cloud offering that monitors, and may manage and control, various types of endpoints, often via applications, end users build on the platform. It facilitates operations involving IoT endpoints and integration with enterprise resources. Platforms should be capable of:

•Provisioning and management of devices and their application software•Data aggregation, integration, transformation, storage and management (often collectively referred to as "data digestion")

•Event processing: Rule engine/orchestration/BPM•Customizing and building applications (SDK, app server, IDE and others)•IoT data analysis and visualization•Cybersecurity•IoT device communications (network and/or Internet)•Adapter (API hub, gateway software but also to the application on endpoint)•User interfaces for both end users and developers

Gartner’s Market Guide for IoT Platforms, https://www.gartner.com/doc/3086918/market-guide-iot-platforms65 |

https://www.gartner.com/doc/3086918/market-guide-iot-platforms

bIoTope WP4, 8-9 June, 2016, Helsinki 66Partner Name: CSIRO

An IoT platform is a software suite or a PaaS cloud offering that monitors, and may manage and control, various types of endpoints, often via applications, end users build on the platform. It facilitates operations involving IoT endpoints and integration with enterprise resources.

Feature/Criterion FIWARE OpenIoT Dialog ThingWorx

BlueMix

Provisioning and management of devices and their application software

Yes

Data aggregation, integration, transformation, storage and management (often collectively referred to as "data digestion")

Yes, cloud

Event processing: Rule engine/orchestration/BPM

No

Customizing and building applications (SDK, app server, IDE and others)

Yes

IoT data analysis and visualization

Yes

Cybersecurity Partial IoT device communications (network and/or Internet)

Yes

Adapter (API hub, gateway software but also to the application on endpoint)

Yes

User interfaces for both end users and developers

Yes

bIoTope Project Overview 67Partner Name: CSIRO

•Situation- or context-aware systems create new opportunities for automating everyday tasks

•For example, context-aware mobile phones that know what to do with incoming calls, or context-aware parking areas that tell drivers where to park

•Substantial capabilities exist today, but some fundamental challenges and gaps still remain in two key areas:

•No theoretical framework that enables application-independent representation of context, reasoning about and validation of context

•Very little research has been done on context- and situation-prediction

•bIoTope will provide runtime support for advanced context-awareness through context prediction, proactive Act-Ahead adaptation, and user interaction awareness and personalisation

Partner Name

Context-as-a-Service

…Dom

ains

IoT

data

col

lect

ion

GSNCoAP,

Xively,…

DSE DS

E

Data StoreData

StoreData Store

Data StoreData

StoreContext Store

Raw

dataContext

Context Service• Discovery• Validation• Semantics• Utility• Delivery• Representation• Reasoning

CSDL – Service requests (context, knowledge)

Open API

Ont

olog

ies

IoT middleware, platformsdata stream engines (DSE)

OpenIoT, FIWARE, Dialog,…

Context-driven UI

Context-driven privacySecurity, trust

CSD

L-C

onte

xt S

ervi

ce

Des

crip

tion

Lang

uage

Con

text

Ser

vice

Plat

form

Standards

SSN

O

Pilots &use cases

Cloud

Data bases

Social web

Semantic w

eb

WSN

Context fusion and validation

Con

text

pro

visi

onin

g pl

atfo

rm

Service layer CoaaS SecaaS KwaaS UIaaS

Storage layer Warp10 Cassandra SL3 SL4

Physical/Sensing layer GSN DS3 DS4

IoT Platforms

OpenIoT

Pl3

Pl4

FIWA

RE

toreoreData Stor

e

reContext

store

XaaS

bIoTope WP4, 8-9 June, 2016, Helsinki 71

bIoTope Big Picture

P1

P2

P3

P4

P5

UC1 UC2UC3

DS

DE

Storage & Sensing & Actuation Layer

SR

O-MI/O-DF

Coordination layer/Ecosystem Coordinator

Platform/Tool O-MI/O-DF Compliant Wrapper

Smart Connectedobjects

Wrapper Generator

SR

SR

SR

IoT EPIecosystems S

R

Data ContextKnowledge

WSNWSN

OpenFlexibleVersatileHeterogeneous

bIoTope ecosystementry point

SR

bIoTope Directory Service

bIoTope Discovery Engine

BIG IoT Interoperability Approach

Dr. Arne Bröring, Siemens AGTechnical Manager BIG IoT

IoT-EPI MeetingValencia 23.06.2016

Approach

Dr. Arne Bröring, Siemens AG

Provider Platform

BOSCH SI ConnectedCity Platform

BOSCH CR Distributed Smart Object Platform

CSI Smart Data Platform

ECONAIS Wubby Platform

NUIG OpenIoT Platform

VODAFONE Mobile Analytics Platform

VMZ TIC Platform

WorldSensing Smart Traffic Platform

BIG IoT Marketplace

Aim: Ignite an Ecosystem with BIG IoT Platforms

Application

Application

…

Service

Service

…

Dr. Arne Bröring - Siemens AG

5 Patterns of Interoperability

•Source:

Broering et al. (2016, under review) - Enabling IoT Ecosystems through Platform Interoperability, IEEE Software

1.) “Cross Platform Access” pattern•Fundamental characteristic of an interoperable IoT ecosystem•Application or service accesses offerings from multiple platforms through the same interface•E.g., “air quality monitoring” application gathers NO2, CO, and O3 from different platforms


2.) “Cross Application Domain Access” pattern•Extends the “Cross Platform Access” pattern•Application / service accesses offerings not only from multiple platforms, but also from platforms from different application domains.•Semantic descriptions of the information sources become more important


3.) “Platform Independence” pattern

•Same application / service can be used on top of different platforms (e.g. in different regions)•E.g., 2 deployments of a “smart parking” service in 2 regions, which have their own platforms with information about parking spots


4.) “Platform-Scale Independence” pattern•Platform hides its scale towards services / applications; scales:

•Server-level (e.g., a cloud platform) -> vast amount of data•Fog-level (e.g., a gateway) -> limited spatio-temporal scope•Device-level (e.g., a sensor device) -> direct access to thing


5.) “Higher-level Service Facades” pattern•Not only platforms but also services offer information and functions via a common API•Service acts as a façade towards an IoT platform and accesses offered information or functions to provide value-added functionalities•E.g., application gets aggregated air quality data through a service


Standardisation

•Focus on:

•W3C Web of Things Interest Group •moderated by Siemens•planned contributions, e.g., BIG IoT API•Contributors welcome!

•W3C Spatial Data on the Web Work Group •NUI Galway contributes to SSN ontology


•Launched Spring 2015

•160 Members

• Collaborations with:

IETF/IRTF, oneM2M,

OCF, IIC, AIOTI, OPC Foundation, Industrie 4.0

•Working on use cases, requirements, and technology elements

•W3C WoT Webpage: https://www.w3.org/WoT/

Web of Things IG


https://www.w3.org/WoT/

Discovery Security

Thing Description

W3C WoT aims

at:

Standardizing

building blocks for

an open

application layer

to

enable cross

domain IoT

applications.

CoAP

IPv6 / 6LoWPAN

DTLS

Core Link

IoT Building Blocks,

e.g. from IETF

UDP

W3C WoT Building Blocks

TCP

APIs

Web of Things IG


W3C WoT in BIG IoT

Jelena Mitic, Dr. Arne Bröring - Siemens AG

Service / Application

Platform / Service

BIG IoT Marketplace

BIG IoT Provider Lib

BIG IoT Consumer Lib

Authen

ticati

on

Discov

ery

Accou

nting

Accou

nting

Regist

ration

Authen

ticati

on

Acces

s

TD used as payload.

TD used for searching.

TD describes interface.

Registration Description based on TD{ "@context": [ "http://w3c.github.io/wot/w3c-wot-td-context.jsonld", { "km4c": "http://www.disit.org/km4city/schema#", "qu": "http://purl.oclc.org/NET/ssnx/qu/qu#", "unit": "http://purl.oclc.org/NET/ssnx/qu/unit#", "ssn": "http://purl.oclc.org/NET/ssnx/ssn#", } ], "name": "Smart Data Platform (CSI Piedmont)", "uris": [ "http://api.smartdatanet.it/api/", "ws://stream.smartdatanet.it/ws/", ], "encodings": ["JSON", "XML"], "properties": [ { "@type": "qu:Frequency", "name": "Traffic counter Montalto Dora", "qu:unitKind": "unit:hertz", "hrefs": [ "ds_Trfl_375/Measures", "topic/output.quadrante.2d5dbb35" ], "@reverse": { "ssn:observes": { "@id": "2d5dbb35", "@type": "km4c:TrafficSensor" } } }...

Based on

Web of Things‘Thing Description

Import of additionalVocabularies.

Setting the base URIsof the platform.

Description of the “Offering”.

Integration of concepts fromW3C SSN Ontology

Thank you for your attention!Questions?

On the Web: http://big-iot.euOn Twitter: @BIG_IoT

Dr. Arne BröringSiemens AG

[email protected]

Layering of Semantic Models

e.g., SSN, IoT Light, GeoLocation, ...

e.g., Building, Smart City, eCl@ss, schema.org, …

Registration Description based on TD{ "@context": [ "http://w3c.github.io/wot/w3c-wot-td-context.jsonld", { "qu": "http://purl.oclc.org/NET/ssnx/qu/qu#", "unit": "http://purl.oclc.org/NET/ssnx/qu/unit#", } ], "name": "Smart Data Platform (CSI Piedmont)", "uris": [ "http://api.smartdatanet.it/api/", "ws://stream.smartdatanet.it/ws/", ], "encodings": ["JSON", "XML"], "properties": [ { "@type": "qu:Frequency", "name": "Traffic counter Montalto Dora", "qu:unitKind": "unit:hertz", "hrefs": [ "ds_Trfl_375/Measures", "topic/output.quadrante.2d5dbb35" ],...

Based on

Web of Things‘Thing Description

Import of additionalVocabularies.

Setting the base URIsof the platform.

Description of the “Offering”.

Your Service / Application

YourService / Platform

Collaboration with BIG IoT

Cloud-based Agent

GatewayGateway Level

Cloud Level

Device Level

IoT Platform

Gateway-based Agent

ApplicationsApplication Level

BIG IoT Marketplace

BIG IoT Provider Lib

BIG IoT Consumer Lib

Aut

hent

icat

ion

Dis

cove

ry

Acc

ount

ing

Acc

ount

ing

Reg

istra

tion

Aut

hent

icat

ion

Acc

ess

so far …

BIG IoT API

Example: Platform Interoperability

P1OpenIoTPlatform

Barcelona Piedmont

P2CSI Smart Data

Platform

BarcelonaParking Service

Barcelona Parking Application

PiedmontParking

Application

PiedmontParking Service

Parking Service

… with BIG IoTFind Free Parking

Application


Ecosystem: Roles


Use of ontologies in the IoT-EPI projectsTF02 Platforms Interoperability

Raúl García-Castro, VICINITY, Universidad Politécnica de Madrid, Spain

[email protected]


Some IoT-related ontology standards

• Semantic Sensor Network (SSN) ontology

•First version from the Semantic Sensor Networks XG (2011)•Being updated in the Spatial Data Web WG

• Smart Appliances Reference (SAREF) ontology

•Standardised by ETSI in Nov. 2015•Being extended in Specialist Task Force 513

• oneM2M ontology

•To appear in oneM2M release 2

Partner Name: CSIRO

Ontology features

Domain W3C SSN ETSI SAREF oneM2MThing X X XObservation X X XDevice X X XDevice Deployment

X X X

Device properties XDevice energy XService/Function X XSensor XSensor properties

X

Condition X

Call for use cases and requirements•ETSI has started the work on maintaining SAREF and defining extensions•This work is performed by STF 513 (with experts from TNO, UPM and Sensinov)•We are currently gathering use cases and requirements•Actively seeking for additional requirements from all domains

Transport

Industrial

Heal

thca

re

SAREF

Consumer & Home

Use of ontologies in projectsProject Use cases/

domainsW3C SSN ETSI SAREF oneM2M Other

AGILE

Be-IoT

BIG-IoT

bIoTope

INTER-IoT eHealth, transport X ? Transport, logistics, ehealth

simbIoTe

TagItSmart

Unify-IoT

VICINITY Energy, buildings, transport, assisted

living, eHealth

X X ?

Thank You!

IoT interoperability in NIST, ISO and IEEE SA developments

Arkady Zaslavsky, CSIRO, bIoTope


•NIST IoT-enabled Smart City Framework•ISO JTC1 WG10 IoT Reference Architecture•IEEE SA IoT Reference Architecture

Outline

NIST GCTC and IES-City w/s, 22-25 March, 2016

http://www.nist.gov/cps/gctc-tech-jam-and-iot-enabled-smart-city-framework-workshop.cfm

Smart City Framework

Presentation title | Presenter name | Page 101

Public Working GroupsTechnical Architectu

res

Workshops and

Analysis

Deployments

Convergence

Action Cluster

Workshops and

Analysis

Learning by Doing

• Review exemplar smart-city applications

• Summarize scope• Develop structure

of sub-domains• Identify Metrics for

evaluation

Application Framework

•Discover PPIs from existing Deployments

•Super Action Clusters e.g. GCTC

• Identify opportunities to develop more PPIs

Consensus Deployed PPI

IoT-Enabled Smart

City Framework

Model Specifications

Analysis from Deployment

Simplified Framework

Review Specifications

Participants: City CTOs, Experts, Companies, Technical Stakeholders, …

•Device specifications•Document overlaps and gaps•Identify PPIs•Find consensus standardized interfaces

Consensus PPIs

Presentation title | Presenter name103 |



International Technical Working Group on

IES-City Framework: Consensus PPI

April 15, 2016

Dr. Martin Burns

Electronic Engineer

Smart Grid and Cyber Physical Systems Program

Engineering Laboratory

National Institute of Standards and Technology

106

Pivotal Points of Interoperability - PPI

107

If you standardize everything, you freeze out innovation. If you standardize nothing, you get non-interoperable clusters that can’t be easily integrated. The principle of Pivotal Points of Interoperability is to find consensus standardized interfaces that deal with composition of CPS without constraining innovation.

Pivotal Points of Interoperability (PPI)

108

Independent technology deployments

With Pivotal Points of Interoperability

Potentially large distance to interoperability

Minimize distance to interoperability

PPI App

Diversity

PPI

PPI

Partner Name: CSIRO

Some potential PPIs•Domain-specific Data/Semantic/Information Models•Separate PII from Data•Standard metadata about objects, measurements, time, cost•REST APIs•IP Networking•Transport Layer Security (TLS)•Certificate Authentication•Role Based Access Control•OAuth 2.0 to establish third party access and regulate roles

109

How to Discover Consensus

110

Union of Application

s

Architecture/

Framework B

Architecture/

Framework A

Architecture/

Framework C

Common Pivotal Points of

Interoperability

Possible Extension

Points

Process:1) Transform architectures

to CPS Framework normal form

2) Transform deployments to CPS Framework normal form

3) Compare results of 1) and 2)

4) Broaden consensus of intersections

5) Document Smart Cities Framework

CPS Framework – What is CPS

111

Key Goals of the Framework

112

Facets

Asp

ects

Conceptualization Realization Assurance

Functional

Business

HumanTrustworthin

essTiming

Data

BoundariesCompositio

nLifecycle

Activities

Artifacts (properti

es)

Use Case, Requirements, …

Model of a CPS

Design / Produce / Test / Operate

CPS

Argumentation, Claims, Evidence

CPS Assurance

Manufacturing

Transportation

Energy

Healthcare

. . . Domain

Domains

Establish a common nomenclature and structure for understanding and developing CPS and CPS architectures similar to the role that the ISO 7 Layer Model has provided for communications CPS Framework

Aspects – Groupings of ConcernsAspects are high-level groupings or categories of concerns. Concerns represent interests in a system and may be viewed as relevant by one or more stakeholders

Functional Concerns about function including sensing, actuation, control, communications, physicality, etc.

Business Concerns about enterprise, time to market, environment, regulation, cost, etc.

Human Concerns about human interaction with and as part of a CPS. Trustworthiness Concerns about trustworthiness of CPS including cybersecurity,

privacy, safety, reliability, and resilience.

TimingConcerns about time and frequency in CPS, including the generation and transport of time and frequency signals, timestamping, managing latency, timing composability, etc.

Data Concerns about data interoperability including fusion, metadata, type, identity, etc.

Boundaries Concerns related to demarcations of topological, functional, organizational, or other forms of interactions.

Composition

Concerns related to the ability to compute selected properties of a component assembly from the properties of its components. Compositionality requires components that are composable: they do not change their properties in an assembly. Timing composability is particularly difficult.

Lifecycle Concerns about the lifecycle of CPS including its components.

113

Partner Name: CSIRO

Analysis Worksheet

Aspect Concern DescriptionIIRA detailed mapping

IOTA detailed mapping PPI

Functional This row marks the beginning of the functional aspect section and represents all concerns of the aspect 6 D1.5-3.5, D1.5-4.2.2

Functional actuation Concerns related to the ability of the CPS to effect change in the physical world. 6.2:590, 6.2:610

D1.5-3.3.2, D1.5-3.3.3

Functional communication Concerns related to the exchange of information between the CPS and other entities.

6.2:595, 6.3:670, 6.5:750, 9.2:375, 12.0:825, 12.1:830, 12.2:860, 12.3:910, 12.5:1045

D1.5-3.3.2, D1.5-3.3.3, D1.5-3.5.2.4, D1.5-3.6, D1.5-4.2.2.6, D1.5-4.2.3 IPV6 for all node end points

Functional controllability

Ability of a CPS to control a property of a physical thing. There are many challenges to implementing control systems with CPS including the non-determinism of cyber systems, the uncertainty of location, time and observations or actions, their reliability and security, and complexity. Concerns related to the ability to monitor and, if necessary, modify a CPS or its function.

6.1:530, 6.2:575, 6.2:615, 6.2:590, 6.2:640, 6.3:670, 6.3:685, 6.2:610, 8.0:100, 9.3:445, 15.0:1355, 15.1:1355, 15.2:1380, 15.3:1455

D1.5-3.5.2.5, D1.5-4.2.2.8

Functional functionality Concerns related to the function that a CPS provides. 6.5:750, 6.6:765

Functional measurability Concerns related to the ability to measure the characteristics of the CPS.

6.3:670, 6.3:675, 6.3:680, 6.3:685

D1.5-3.5.2.5, D1.5-4.2.2.8

… … …… …

114

Partner Name: CSIRO115

ISO/IEC/ITU

116 |

Presentation title | Presenter name

IoT RA big picture

117 |


IoT RA System View

118 |


IoT RA Information View

119 |


IoT RA system integration types

120 |


Overall IoT Infrastructure

121 |

IEEE SA P2413

122 | http://grouper.ieee.org/groups/2413/