Date post: | 16-Feb-2017 |
Category: |
Technology |
Upload: | iot-epi |
View: | 256 times |
Download: | 7 times |
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
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/)
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
IoT-EPI Common Workshop, 22-23 June, 2016Valencia, Spain
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.
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
IoT-EPI Common Workshop, 22-23 June, 2016Valencia, Spain
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
Multiple core 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
Single core ontology
Mapping between platform-specific
ontologies
Pre-mapped best practice
ontologies
Multiple core ontologies
Core ontology with extension points
•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?
Single core ontology
Mapping between platform-specific
ontologies
Pre-mapped best practice
ontologies
Multiple core ontologies
Core ontology with extension points
•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
Single core ontology
Mapping between platform-specific
ontologies
Pre-mapped best practice
ontologies
Multiple core ontologies
Core ontology with extension points
•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
Single core ontology
Mapping between platform-specific
ontologies
Pre-mapped best practice
ontologies
Multiple core ontologies
Core ontology with extension points
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 |
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
Dr. Arne Bröring - Siemens AG
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
Dr. Arne Bröring - Siemens AG
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
Dr. Arne Bröring - Siemens AG
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
Dr. Arne Bröring - Siemens AG
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
Dr. Arne Bröring - Siemens AG
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
Dr. Arne Bröring - Siemens AG
•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
Dr. Arne Bröring - Siemens AG
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
Dr. Arne Bröring - Siemens AG
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
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
Dr. Arne Bröring - Siemens AG
Ecosystem: Roles
Dr. Arne Bröring - Siemens AG
Use of ontologies in the IoT-EPI projectsTF02 Platforms Interoperability
Raúl García-Castro, VICINITY, Universidad Politécnica de Madrid, Spain
IoT-EPI Common Workshop, 22-23 June, 2016Valencia, Spain
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
IoT-EPI Common Workshop, 22-23 June, 2016Valencia, Spain
•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 |
Presentation title | Presenter name104 |
Presentation title | Presenter name105 |
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 |
Presentation title | Presenter name
IoT RA System View
118 |
Presentation title | Presenter name
IoT RA Information View
119 |
Presentation title | Presenter name
IoT RA system integration types
120 |
Presentation title | Presenter name
Overall IoT Infrastructure
121 |
IEEE SA P2413
122 | http://grouper.ieee.org/groups/2413/