konvergenz heterogener sensorprotokolle mit embedded · pdf filealternative ejms um iot/iiot...
Post on 06-Feb-2018
216 Views
Preview:
TRANSCRIPT
V1.3 © Heuser Software AG 2016 1
März - 2016
Konvergenz heterogener Sensorprotokolle mit embedded Java und OSGi für das IoT/IIoT
V1.3 © Heuser Software AG 2016 2
• 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
V1.3 © Heuser Software AG 2016 3
IoT Fakten und Herausforderungen
V1.3 © Heuser Software AG 2016 4
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
V1.3 © Heuser Software AG 2016 5
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
V1.3 © Heuser Software AG 2016 6
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
V1.3 © Heuser Software AG 2016 7
Konvergenzprinzipien
V1.3 © Heuser Software AG 2016 8
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...
V1.3 © Heuser Software AG 2016 9
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?
V1.3 © Heuser Software AG 2016 10
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
V1.3 © Heuser Software AG 2016 11
Funktionalitäten einer Konvergenz
V1.3 © Heuser Software AG 2016 12
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
V1.3 © Heuser Software AG 2016 13
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
V1.3 © Heuser Software AG 2016 14
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
V1.3 © Heuser Software AG 2016 15
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
V1.3 © Heuser Software AG 2016 16
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
V1.3 © Heuser Software AG 2016 17
Transaktionalität
V1.3 © Heuser Software AG 2016 18
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
V1.3 © Heuser Software AG 2016 19
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
V1.3 © Heuser Software AG 2016 20
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
V1.3 © Heuser Software AG 2016 21
Konvergenz anwenden Komponente: Event Marking (EM)
V1.3 © Heuser Software AG 2016 22
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
V1.3 © Heuser Software AG 2016 23
Konvergenz anwenden Komponente: Automatic Node Discover (AND)
V1.3 © Heuser Software AG 2016 24
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
V1.3 © Heuser Software AG 2016 25
Konvergenz anwenden Komponente: embedded JMS (eJMS)
V1.3 © Heuser Software AG 2016 26
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
V1.3 © Heuser Software AG 2016 27
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
V1.3 © Heuser Software AG 2016 28
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
V1.3 © Heuser Software AG 2016 29
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
V1.3 © Heuser Software AG 2016 30
Kurze Vorstellung
V1.3 © Heuser Software AG 2016 31
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
V1.3 © Heuser Software AG 2016 32
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
V1.3 © Heuser Software AG 2016 33
Executive Summary Einige Kunden und Partner
V1.3 © Heuser Software AG 2016 34
Vielen Dank eM: oliver.heuser@heuser-ag.de
top related