Konvergenz heterogener Sensorprotokolle mit embedded · PDF fileAlternative eJMS um IoT/IIoT...

V1.3 © Heuser Software AG 2016 1

März - 2016

Konvergenz heterogener Sensorprotokolle mit embedded Java und OSGi für das IoT/IIoT


•  IoT Fakten & Herausforderungen

•  Konvergenz •  Prinzipien •  Funktionalität •  Transaktionalität •  Komponenten

•  EM (Event Marking) •  AND (Automatic Node Discover) •  eJMS (embedded JMS)

•  Use Cases und F&A


IoT Fakten und Herausforderungen


2020*

8 Mrd. Menschen

Myriaden Sensoren/Aktoren

Zunehmender Sicherheitsbedarf

Weit mehr als 30 Mrd. Geräte

Zunehmende Abhängigkeit

von proprietären Marktführern

Mindestens 90 Mio. Menschen leben in

Smart Homes

BigData Explosion

(insbesondere mit IoT)

Zunehmende Verbindungs-komplexität

Fast 60% der Menschen benutzen

Smart Phones für alles ...

*Gartner Group

Vorschau 2020* - Warum werden intelligente Integrations-lösungen benötigt?

Geschäfts-felder

Szenarien

vorausschauend 2020

Führt zu unendlich vielen Anforderungen


IoT und seine Anforderungen & Notwendigkeiten

2020

8 Mrd. Menschen

Myriaden von Sensoren/Aktoren

Zunehmende Sicherheits-

anforderungen

Weit mehr als 30 Mrd. Geräte

Zunehmende Abhängigkeit

von proprietären Marktführern

mindestens 90 mio. Menschen leben in

Smart Homes

BigData Explosion (insbesondere mit IoT)

Zunehmende Vernetzungs-komplexität

Fast 60% benutzen

Smart Phones für so ziemlich

alles ...

strukturierbar

organisierbar

verknüpfbar

ANFORDERUNGEN

sichern

nach-verfolgbar skalierbar

kontrollierbar

.....

standardi- sierbar

vorhersehbar

folgt Mehrdimensionalität Aus Eindimensionalität

über die Zeit

bedingt

führt zu

Standards

NOTWENDIGKEITEN technische

Überlagerung PnP

offene Systeme

herstellerneutral Multiplexing

Daten-mediation

streambar Echtzeit

Erweiterbarkeit .....

Konvergent nutzbar

Einfache Inbetriebnahme

Techn.: Aus einer Anforderung entstehen n Notwendigkeiten und Abhängigkeiten


IoT und seine (aktuellen) Kritikpunkte

Viele gute Ideen, aber oft fehlender Business Case

Keine systemübergreifende Bedienkonzepte

Konzentration auf die vermeintlich stärksten Treiber

Häufig nur proprietär anwendbar

Entwickelt für Nischen Unvorhersehbares Wachstum durch Netzwerkeffekte getrieben

Häufig nur mittels Cloud betreibbar

Keine bis wenige durchsetzungsfähige

Standards

Häufig geringer Produktreifegrad

Auf der Suche nach der Killerapplikation

Konzentration auf technische Anbindungen, aber geringe bis

gar keine Konzentration auf generische Datenstrukturen

Fragliche Sicherungskonzepte


Konvergenzprinzipien


Konvergenz – Warum überhaupt?

Geschäfts-felder

Hohe Permutation

an Varianten

Riesige Permutation

an Varianten

2020 - .... Viele Hersteller = viele Lösungen & damit beliebige Anzahl an Varianten und Verknüpfungen

Permutation verläuft ins unendliche

Use Cases

Ver-knüpfungen V1

+ V2+

Vn+Vm...


Konvergenz – als notwendige Option Am Beispiel typischer Systemlandschaften

Her-steller

Zigbee Z-‐Wave EnOcean WirelessM-‐Bus

6LoWPAN WiFi BLE Dect BidCos

#1 x x x x x x

#2 x

#3 x x x x

#4 x x

#5 x x x

#6 x

#7 x

...

Horizontale Fragmen5erung

Ver5kale Fragmen5erung

Zigbee 868 MHz 915 MHz 2.4 GHz

Z-‐Wave 868 MHz 908 MHz 2.4 GHz

EnOcean 315 MHz 868 MHz

...

M-‐Bus 868 MHz 169 MHz

6LoWPAN 868 MHz 915 MHz 2.4 GHz

WiFi 2.4 GHz 5 GHz

BLE 2.4 GHz

Dect 1.800 MHz

BidCos 868 MHz

Und nach 2020?


Konvergenz – als notwendige Option Am Beispiel einer Studie über die 5 größten Hausautomationsmärkte

4.6

24.5

3.3 2.4 2.1 1.5 0.4 0.3 0.3 0.2

2020

2015

*Statista Digital Market Outlook (2015)

%

80%

15%

5%

Unentschlossene

Maker

Luxus für Anlagen > 5k€

Quintessenz: Nach wie vor existiert ein Akzeptanzproblem

Warum? Die häufigsten genannten Gründe:

-  technische Unreife (wenige Installateure) -  inkompatibles Durcheinander -  zu teuer -  Angst vor Hackern -  Angst vor dem Verlust der Privatsphäre


Funktionalitäten einer Konvergenz


Konvergenzobjekte

Vermengen

Verteilen

Sammeln

Filtern

Aggregieren

Anwenden

Mappen

....

Primitive Data

Streaming Data

Binary Data

Serialisierbare Daten

Nachrichten

Bulk Compound

Streaming Compound

Protokollmetadaten

Message Compound

...

Source Compounder Mediator

...

Compound Object

Compound

...

Welche Objekte werden einer Konvergenz zugeführt?

Konvergenzmuster (Pattern)

Resultierende (Compound)

Datenobjekte (Load)

Datenbank/ OLAP

IP-basiert

JMS-basiert

Über Adapter

Techn. Adapter

HTTP/S

REST

OLAP

SOAP

JDBC

...

Infrastruktur Adapter

Zigbee

Z-Wave

EnOcean

M-Bus

MQTT

...

Socket

BidCos


Konvergenz - Funktionsweise Am Beispiel eines Protokoll-Multiplexings

K1 K2

Sensor- protokoll A

Multiplexing

Sensor- Protokoll B

Multiplexer

H3 H2

H1

-  Über Koordinatoren werden unterschiedliche Herstellerkomponenten eingebunden

-  Multiplexing anwenden: -  Zusammenführen unterschiedlicher

Herstellerprodukte einer Infrastruktur und zudem -  unterschiedlicher Herstellerprodukte

unterschiedlicher Infrastrukturen

K1

Multiplexing

K2 Kn

Sensorprotokolle


Konvergenz - Herausforderung Das Ziel: hersteller- und protokollunabhängiger Sensorbetrieb

Zigbee – 868 MHz / 2.4 GHz

Env.-Sensor °C / lm

*Passive Infrared

Bedingung 1 Aktion 1 Horizontal = Funktions-orientiert

Vertikal = Medium- orientiert

Z-Wave – 868/908 MHz / 2.4 GHz

Env.-Sensor Sensor - °C Schaltsensor On/Off

Gassensor O3 / CO2 Multisensor PIR* / lm

Transak5on #1: wenn Bdg. 1 = True => Ak5on 1

Messung lm, CO2 °C > 30 und lm >= 1380

Bdg. 1 erreicht und °C > 31 Schalter

Aktion 2

Transak5on #2: wenn Transak5on 1 erfolgreich und Bdg. 2 erfolgreich => Ak5on 2

Bedingung 2

Me

diu

mo

rien

tiert

WiFi

Kamera On/Off

EnOcean – 868 MHz

Schaltsensor On/Off

Aktion 3

Transak5on #3: wenn Transak5on 2 erfolgreich => Ak5on 3

Funktionsorientiert


Koordinator

Start

XBee-Operation 0x08 (AT-Command)

Länge Frame Typ

Frame ID

AT- Befehl

Parameter (modul-/netzwerkspezifisch) CS

Konvergenz – Wirkung (horizontal vs. vertikal) Horizontal

Beispiel für systemische Interpretation Perspektive: Koordinator

ZBK R

S1 S2

S3

Sensor1

Start

XBee-Operation 0x10 (Transmit Request)

Länge Frame Typ

Frame ID

Parameter (modul-/netzwerkspezifisch) CS 64-Bit

Zieladresse 16-Bit

Netzwerk- adresse

Broadcast Radius Optionen

Beispiel für herstellerübergreifende Interpretation Perspektive: Sensor

ZBK R

S1 S2

S3


Konvergenz – Wirkung (horizontal vs. vertikal) Vertikal

Sensor2

Start

XBee-Operation 0x10 (Transmit Request)

Länge Frame Typ

Frame ID

Parameter (herstellerspezifisch) CS 64-Bit

Zieladresse 16-Bit

Netzwerk- adresse

Broadcast Radius Optionen

Beispiel für hersteller- und infrastrukturübergreifende Interpretation Perspektive: Sensor

ZBK R

S1 S2

S3 Sensor6

32-Bit HomeID

Z-Wave Frame (Single Cast Request)

Source NodeID

Frame Header Länge Parameter

(herstellerspezifisch) CS Zieladresse

Command Class Command Command

Data 1 Command

Data 2 Command

Data n

Command Data 1

Command Data 2

Command Data n

ZWK R

S4 S5

S6

ZBK konvergiert

mit ZWK


Transaktionalität


Transaktionale Konvergenz Protokollmultiplexing

Rohdaten

Z-Wave Metadaten .... Herst.B Herst.C Schaltsensor Verbrauchsmessung Metadaten

Zigbee MD .... Rauchmelder2 .... HerstellerD Rauchmelder1 Gassensor Metadaten

Zigbee Metadaten Bewegungsmelder1 .... Metadaten HerstellerA CO2 Sensor

me

diu

m o

rien

tiert

e K

on

verg

en

z

funktional orientierte Konvergenz

Event MarkerST

Anwender

TA2

Rauchmelder1

Schaltsensor Verbrauchsmessung

Rauchmelder2 Gassensor

.... ET2

Event MarkerET

Start TA2

Ende TA2

Prinzipiell verhilft transaktionale Konvergenz zur -  Synchronisation von asynchron orientierten Daten -  Datensynchronisation über verschiedene Infrastruktur-Topologien beim -  Sammeln der Daten basierend auf ihren Business und Use Cases und nicht nur

basierend auf deren herstellerbedingten Möglichkeiten

Transaktionen können auf Basis von Daten, Objekten oder Ereignissen definiert

werden TA1 ET1 Bewegung + CO2 Indikation

Start TA1

Ende TA1

Szenarien


Mediator & Compounder Source

Multiplexer

Services Appli-

kations Bundles

Szenarien

Nachricht

Multiplexing unterschiedlichster, herstellerabhängiger Datenströme in einen einzigen herstellerunabhängigen Datenstrom

A1S1S2+P1, C1+P3, C2A3S3+P2, ...

Sammeln

Filtern

Konsolidieren

Aggregieren

Verteilen Routing

Kontrollieren Zusammen- führen

Sensoren

S1

S2

S3

..

Unterschiedliche Hersteller

Unterschiedliche Protokolle

Konvergenzziel

Aktoren

A1

A2

A3

..

Kameras

C1

C2

..

Protokoll & Benutzerdaten Aggregation

P1

P2

P3

..

Läuft auf einer beliebigen Hardware

Nutzung eines einzelnen

Datenstroms zum Endgerät


Konvergenz – subsummiert Sensorprotokolle vs. Daten

-  Protokolle werden als Streaming-Objekte angesehen, die in zwei Richtungen operieren

-  Für IoT/IIoT werden auch serielle/native Protokolle berücksichtigt (Bsp.: BLE)

-  Herstellerspezifische Protokolle können adaptiert und ihre Daten per IP weitergeleitet werden

-  Konvergenz wird auf Basis einer Proxy-Funktionalität bei vordefinierten Protokollen und darin befindlichen Daten angewandt

-  Daten werden strukturiert aufbereitet und in Streams bzw. ge-framten Paketen weitergeleitet – Konvergenz dient auch als Filter

-  Daten werden mittels Pattern vordefiniert und wiederum als Funktionen formuliert und übergeben

-  Daten können mittels Event Marker vorbestimmt werden um Transaktionen, Daten, Objekte und Metadaten zu triggern

-  Daten in verschiedenen Streams können transaktionale Beziehungen zueinander besitzen

Sensorprotokolle

Daten


Konvergenz anwenden Komponente: Event Marking (EM)


Transaktionale Konvergenz Event Marking

Rohdaten

Z-Wave Metadaten .... Herst.B Herst.C Schaltsensor Verbrauchsmessung Metadaten

Zigbee MD .... Rauchmelder2 .... HerstellerD Rauchmelder1 Gassensor Metadaten

Zigbee Metadaten Bewegungsmelder1 .... Metadaten HerstellerA CO2 Sensor

Prinzipiell verhilft Event Marking -  um nur die Daten zu erhalten die gewünscht werden -  zu geringeren Latenzen und zu höherer Geschwindigkeit -  Zusammenfassen von Event Markern ermöglicht präzisen Informationsaustausch

unabhängig von Herstellereigenschaften und Infrastruktur-Topologien

Kamera2 IP .... .... Hersteller4 Kamera3 Kamera1 MD Metadaten

Nutzbar über API

EM1

EM2

EM3 EM5

EM4 EM6

EM8

EM9


Konvergenz anwenden Komponente: Automatic Node Discover (AND)


AND – Automatic Node Discover Wie werden neue Geräte erkannt?

AND Device-DB

AND Identifikation

1/3

AND Identifikation

2/3

AND Identifikation

3/3

senden eines topologie-

spezifischen DC-requests

extrahieren herstellerspezifischer

Daten (SN etc.)

matched Hersteller

(Active) senden

eines hersteller-spezifischen

Sensor-Requests

erstellt generisches Device-Objekt

kategoriebezogen

Unterscheiden zwischen Active- & Passive-Sensoren

(Passive) warten auf hersteller-spezifische

Sensor-Response

extrahiert sensorspezifische

Daten (über Pattern)

Senden von Testfragmenten

Identifikation abgeschlossen

matched Sensoriken


Konvergenz anwenden Komponente: embedded JMS (eJMS)


Typische IoT/IIoT Protokolle

AMQP DDS MQTT CoAP XMPP REST/HTTP eJMS

Advanced Message Queing

Protocol

Data Distribution Service for Real-

Time Systems

MQ Telemetry Transport

Constrained Application

Protocol

eXtensible Messaging and

Presence Protocol

Representational State Transfer

embedded Java Messaging

Service

Transport TCP/IP UDP/IP (uni-/multicast)

TCP/IP

TCP/IP

UDP/IP

TCP/IP

TCP/IP

UDP/IP (uni-/multicast)

TCP/IP

Interaktion P-t-P – Message Exchange

P-S and R-R P-S R-R (REST) P-t-P – Message Exchange

R-R P-t-P / P-S / R-R / Adapter-basierend

Abbildung Dev–to-Dev Cloud-to-Cloud Dev-to-Cloud

Dev–to-Dev Cloud-to-Cloud Dev-to-Cloud

Cloud-to-Cloud

Dev-to-Cloud

Dev–to-Dev

Cloud-to-Cloud

Dev-to-Cloud

Cloud-to-Cloud Dev-to-Cloud

Dev–to-Dev Cloud-to-Cloud Dev-to-Cloud

Automatic Discovery - X - X - -

Limitiert auf Basis der betriebenen Sensorptokollen

QoS Limitiert (implementierungs-

abhängig)

Extensive (≈20) Limitiert Limitiert - -

Limitiert (Toolbasiert)

Security TLS + SASL TLS + DTLS* DDS*

TLS DTLS* TLS + SASL*

HTTPS TLS + SASL + HTTPS

Fehler-toleranz

Implementie-rungabhängig

Dezentralisiert

Broker ist SPoF Dezentralisiert

Broker ist SPoF

Broker ist SPoF

Dezentralisiert/ Cluster

DDS* Data-Distribution Service DTLS* Datagram Transport Security Layer SASL* Simple Authentication and Security Layer


Map

Die bekannte Funktionalität von JMS

JMS – Java Message Service

Producer#1

Producer#2

Producer#3

Message

Bytes

Text

Q Q

T T

Consumer#1

Consumer#2

-  Findet hauptsächlich Verwendung innerhalb eines J2EE – Containers und auch für den Enterprise-Bereich konzipiert

-  Gemacht für lose Kopplung und um Nachrichten hochperformant zu versenden (implementierungsabhängig)

-  Verwendet Publish/Subscribe, Point-to-Point und unterstützt Standard-Persistenzstrategien des Containers

Active-MQ

Wepshere

Tibco - BW

Rabbit-MQ ....

-  Eingebaute Transport-Security

-  Benötigt mehr Aufwand in der Verwaltung und Administration


Embedded System#1

eJMS registriert non-default Nachrichten

Medium Defined Message

Vendor Defined Message

ZWaveCommand Message

Embedded System#2

Embedded System#1

Alternative eJMS um IoT/IIoT zu adressieren

Der embedded Weg JMS unter OSGi zu nutzen

Producer#1

Producer#2

eJMS Funktionalität wird injiziert durch DS

Map

Message

Bytes

LQ

Text

RQ Q

LT RT T

eJMS ermöglicht dynamische

‚on – demand‘ Queues

Local Consumer#1

Remote Consumer#2

eJMS nutzt Bundles als Producer eJMS ermöglicht

Nachrichten-Routing

XBeeOperation Message

User Defined Message

Registry

....

MsgDB QDB

eJMS unterstützt eigene

Persistenzstrategien

eJMS ist transaktional

orientiert

EnOceanPulse Message

eJMS erlaubt zwischen locale/remote

Übertragungen zu unterscheiden


eJMS V 1.0 – subsummiert Funktionalität und Diversifikation

-  Läuft prinzipiell als ein OSGi – Bundle

-  Beinhaltet ein leichtgewichtiges API (ca. 850 Kb jar)

-  Nutzt injection pattern – OSGi DS

-  Ist auf IoT/IIoT optimiert durch die vordefinierten Protokollnachrichten

-  Ein einzelnes eJMS kann als Hub für Nachrichten Clustering zu verschiedenen anderen embedded Systemen dienen

-  Basiert auf den gleichen Funktionsaufrufen wie unter JMS 2.0 – beinhaltet zudem zahlreiche Erweiterungen

-  MsgDB und QDB können über verschiedene embedded Systeme verteilt werden um somit mögliches failover handling unterstützen (Kompromisse in puncto Geschwindigkeit und Latenz)

-  Unterschiedliche eJMS können unterschiedliche Business/Use Case Anforderungen übernehmen und somit fachlich separiert werden

-  eJMS wurde als Enabler konzipiert


Kurze Vorstellung


1990: Gegründet für das Business in Software Design,

Entwicklung, Architektur und Systemintegration Geschäftsfelder: Corporate Services im Bereich IT, Automation, Telematics,

Lösungen im Bereich M2M und IoT/IIoT seit 2003 Branchen: Telekommunikation, Automotive und Finanzsektor Basis: Düsseldorf / Germany


Executive Summary Timeline

2003

Erstes Integrationssystem zur Steuerung von Inhouse-Komponenten über SMS.

Komponenten: GE und Conrad Funksteckdosen

2012 (in Kooperation zum Fraunhofer IMS)

Proof of Concept: Integrationssystem zur Kontrolle von vier Netzwerk-Topologien (Zigbee, BidCos, WiFi und GSM)

Komponenten: Libelium, Pikkerton und HomeMatic

2014 (Innovationsförderung durch BMWi mit Fraunhofer gemeinsam)

Plattformentwicklung zur Kontrolle von sechs drahtlos Netzwerk-Topologien (Zigbee, Z-Wave, EnOcean, M-Bus, BLE und GSM) inkl. drahtlos Energieübertragung für Komponenten

Komponenten: RPi, BBB, CubieTruck


Executive Summary Einige Kunden und Partner


Vielen Dank eM: [email protected]

Konvergenz heterogener Sensorprotokolle mit embedded · PDF fileAlternative eJMS um IoT/IIoT...

Documents

Transcript of Konvergenz heterogener Sensorprotokolle mit embedded · PDF fileAlternative eJMS um IoT/IIoT...