• Entwicklung
  • Methoden
  • Programmiersprachen
• Betrieb
  • Datenbanken
  • Server
  • Sicherheit
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
  • Künstliche Intelligenz
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• News
• Termine
• IT-Jobs
• IT-Bücher

• Entwicklung
• Betrieb
• Management und Recht
• News
• IT-Jobs
• IT-Bücher
• Newsletter

Unter IoT- und mittlerweile auch IIoT-(Industrial Internet of Things)-Paradigmen versteht man die Möglichkeit, Geräte und Systeme auf einfachste Art und Weise miteinander kommunizieren zu lassen und dies unabhängig von Art, Ort und Zeit. Dieser legitime Anspruch ist allerdings nicht alleine auf die Erfindung der vorgenannten Paradigmen zurückzuführen, sondern rückte im Zuge des Voranschreitens der Leistungsfähigkeit mobiler Endgeräte und des "always on"-Gedanken mehr und mehr in den Vordergrund.

Begreift man das herkömmliche Web als Fundus für Recherche, Informationen abzurufen und Konversation zu betreiben (Social Media), werden mit dem IoT die bestehenden Möglichkeiten um die Interaktion mit Sensoren, Aktoren, Geräten und Produkten erweitert. Mit dem Aufkommen des IoT-Gedankens wurde dieser vielerorts prägnant und einleuchtend mit dem Bereich der Hausautomatisierung gekoppelt. Hier erschien die schiere Menge an Vernetzungsmöglichkeiten unterschiedlichster Produkte und der dazu notwendigen UseCases als gewinnbringendste Verlockung, dem größten Marktpotenzial und Nutzen zu bieten.

Aber nicht nur das. Mit der Leistungsfähigkeit der heutigen Endgeräte, mit dem Aufkommen erster Apps und der damit verbundenen Möglichkeit, überall Informationen abzurufen oder proaktiv zu erhalten, wurde dieses Potenzial ausgeweitet, so dass die Möglichkeiten heute schier unbegrenzt erscheinen. Schaut man sich den zuvor erwähnten heutigen Hausautomationsmarkt an, erlebt dieser förmlich eine zweite Renaissance. Hätte man in den späten Neunziger- oder frühen Nullerjahren versucht, als Kunde ähnliche Produkt- und Verschaltungsvielfalt zu erhalten, hätte man entweder zum waschechten Bastler avancieren oder auf teure Markenprodukte zurückgreifen müssen. Auf Letztere war man dann aber auch erst einmal festgelegt.

Der Wunsch zum Steuern, Messen und Kontrollieren scheint grenzenlos.

Für einen Endanwender, der seinerzeit auf derartige Monolithen zurückgriff, waren die Beweggründe zur Entscheidung durchaus legitim und vor allem funktional entscheidend, z. B. davon ausgehen zu können, dass eine Alarmanlage auch wirklich einen Alarm auslöste, wenn dies erforderlich wurde. Mit dem Aufkommen von Arduino, Raspberry Pi und Co. und den darauf basierenden Produkten sind die Beweggründe durchaus die gleichen, aber bezüglich ihrer Einsatzmöglichkeiten im Verhältnis zu den Platzhirschen des Marktes – sagen wir mal – zumindest offener.

Fairerweise muss man erwähnen, dass der nicht technisch-orientierte Endanwender, der sich den Bereich der Hausautomation erschließen möchte, immer noch viel Geduld mitbringen und "Mut zur Lücke" bei der Integration von Komponenten beweisen muss, um das angepeilte Ziel zu erreichen. Zu komplex, zu heterogen und zu wenig standardisiert werden heutige Produkte angeboten, als dass – ohne eine gewisse Bastleraffinität mitzubringen – der sofortige Produkteinsatz möglich ist.

Aber auch ohne die klassische Hausautomation scheint der Wunsch zum Steuern, Messen und Kontrollieren grenzenlos. Sicherlich kann man trefflich darüber streiten, ob der internetgesteuerte Toaster oder die Kaffeemaschine einen echten Use oder sogar Business Case darstellen. Aber wie so oft entsteht Schönheit und Geschmack im Auge des Betrachters und zumindest für Raspberry Pi & Co gilt, dass diese Systeme alleine schon auf Basis des Preises, der Verfügbarkeit und Möglichkeiten, Ideen und Konzepte dazu einladen, einfach mal auszuprobieren.

IoT ist sicherlich ein in erster Linie gehypter Begriff, der sich durch technologische Evolution und logische Schlussfolgerung entwickelt hat. Maßgeblich CISCO und IBM trugen zur Verbreitung des Namens bei und dies in vielschichtigen Varianten. Daher wird er auch häufig in Kombination zum physikalischen Web benutzt. Physikalisch, weil signal-/ereigniserzeugende Sensoren und Geräte in die bestehenden Rechnernetzwerke und auch über das Web integriert werden und somit interagieren können. Ob dabei der jeweilige Sensor oder das Gerät nur Ereignisse sendet, empfängt oder auch mit einer eigenen Businesslogik versehen und somit in der Lage ist, eigenständig Prozesse abzubilden, erscheint aktuell unerheblich. Auch der Gerätetyp spielt keine wirklich wichtige Rolle mehr. Der IoT-Gedanke unterscheidet nicht, ob es sich bei den zu verbindenden Geräten um Sensoren, Aktoren oder eigenständige Produkte oder Systeme handelt. Intention ist lediglich, möglichst transparent Geräte in Rechnernetzwerken und über das Web zu integrieren und die erzeugten/ abgegriffenen Informationen weiteren Systemen zur Verfügung zu stellen. Hierbei bestimmt in der Regel der Use Case die Komplexität der Umsetzung und Integration.

Über den IoT-Slogan werden mittlerweile unzählig viele eigenständige Produkte sowie Sensor- und Aktorenvarianten angeboten, die in allen Lebensbereichen Einzug halten. Sprach man bis vor wenigen Jahren in der Hauptsache von Hausautomatisierung (nicht zuletzt auch, weil man sich unter diesem Begriff eine Anwendung vorstellen konnte), treten jetzt Buzz-Wörter wie eHealth, Wearables und Smart City/ Environment vermehrt in den Vordergrund, ohne einen klar umrissenen Interaktionsfokus für eine konkrete Anwendung zu haben. Aber das Ende der Fahnenstange ist längst nicht erreicht. Das Diversifizierungspotenzial der Use Cases und Lösungsmöglichkeiten wird zunehmen und der Ruf nach Standardisierung bzw. nach Lösungen die ausgleichend über alle Geräte wirken, wird größer.

Folgt man einer vielzitierten Gartner-Studie [1], werden im Jahr 2020 mehr als 26 Milliarden Endgeräte, Sensoren und Systeme miteinander vernetzt sein oder vernetzt sein müssen. Die damit einhergehende Heterogenität der spezifischen Gerätevernetzung, deren Betrieb und mögliche Anwendungsfälle werden als Chance für die unterschiedlichsten Marktstrategien und als riesiges Potenzial verstanden.

Das Marktpotenzial erscheint durchaus logisch vorstellbar, die Vorteile dieser neuen Welt können jedoch nicht darüber hinwegtäuschen, dass im gleichen Verhältnis Strategien benötigt werden, Herr der Masse an Geräten zu werden. Nicht zuletzt auch, weil mit Sicherheit davon auszugehen ist, dass es nicht bei der prognostizierten Anzahl bleiben wird. Mal ganz abgesehen davon, dass in Zeiten von NSA und Co., die mit zunehmender Komplexität ausgestatteten Systeme und deren schiere Anzahl mehr sicherheitsrelevante Fragen aufwerfen als Lösungen erkennbar sind und bis dato eher unbeantwortet bleiben. Fairerweise muss man allerdings konstatieren, dass sich das IoT zum aktuellen Zeitpunkt eher in der IT-technischen Steinzeit befindet und somit die Chance bekommen sollte, weiter reifen zu dürfen.

Leider konkurrieren heutige Standards viel zu oft, als dass sie der gemeinsamen Sache dienen.

Betrachtet man die aktuellen Marketingstrategien, könnte man den Eindruck bekommen, dass IoT sei bereits auf etablierten Technologien realisiert, standardisiert und vor allem klar strukturiert. Das Gegenteil ist aktuell der Fall. Standardisierungen sind richtig, werfen aber im Kontext von IoT Fragen auf. Beim aktuellen Stand des Internet der Dinge handelt es sich weder um eine spezifische Technologie, Hardware oder ein spezifisches Kommunikationsprotokoll. Entsprechend schwierig gestaltet es sich, eine übergreifende Standardisierung zu etablieren. Noch prägnanter wird es, wenn Präferenzsichten der Hersteller dazu führen, bestimmte Technologien und Verfahren als die Richtigen zu propagieren, entwickelte Produkte oder APIs als IoT-Ready anzubieten, um damit die berühmten Testballons starten zu lassen, um festzustellen, ob und in welche Richtung der Markt wohl darauf anspringen wird.

Natürlich setzt Standardisierung ein gewisses Maß an Struktur voraus, insofern bedingt das eine auch das andere. Am Beispiel IoT aber – welches sich aktuell eher als ungerichtet, unstrukturiert und gewissermaßen chaotisch darstellt – sollte es einleuchtend sein, erst eine Struktur zu schaffen und dann Standards einzuführen. Bereits jetzt ist ersichtlich, dass es mit einem Standard nicht getan sein wird, um den exorbitant wachsenden Geräte- und Funktionsumfang zielgerichtet und einheitlich nutzen zu können. Leider konkurrieren heutige Standards untereinander viel zu oft, als dass sie der gemeinsamen Sache dienen. Interessantes Beispiel stellen die beiden Varianten MTConnect [2] und OPC UA [3] dar, die auf gänzlich unterschiedlichen Konzepten und Technologien beruhen und unterschiedliche Schwerpunkte setzen. Leider ist wiederum die Latenz der Entwicklung diverser Standards typischerweise so groß, dass man nicht davon ausgehen sollte, in den nächsten Jahren den großen Durchbruch in der Etablierung erwarten zu dürfen. Das gilt auch für die beiden letztgenannten.

Für das IoT ist es also wichtig, Strukturen zu entwickeln und Standardisierungen voranzutreiben, möglichst ohne Konkurrenzmodelle, Präferenzsichten oder den Willen, den ganz großen Wurf eigenständig zu platzieren.

Bezogen auf die im vorherigen Abschnitt erwähnte Gartner-Vision muss man sich fragen, was ein Zuwachs dieser Größenordnung von Sensoren und Geräten für die technischen Anforderungen und Notwendigkeiten bedeutet? Abb.1 symbolisiert noch einmal diesen Sachverhalt.

Ein- und mehrdimensionale Anforderungen

Es stellt sich als logische Schlussfolgerung dar, dass sich Notwendigkeiten durch die Zunahme der unterschiedlichen Geräte, Anbindungen und Abhängigkeiten verändern werden. Von den heute verfügbaren Produkten, die in der Regel eindimensionalen Anforderungen (eine Anforderung bedient einen Use Case) genügen, wird man in Zukunft auf mehrdimensional orientierte Anforderungen zurückgreifen müssen. Im Detail bedeutet das schlicht, dass dann entsprechende Geräte und Produkte nicht nur auf einzelne Funktionen und Attribute beschränkt sind, sondern gruppierte Funktionsweisen über Herstellergrenzen hinweg unterstützen müssen und somit dazu beitragen, sich in mehrfach unterschiedlichen Kontexten zu bewähren und zwar ohne das große Integrationsleistungen für Hersteller wie auch Käufer notwendig werden.

Bezogen auf das IoT stellt dies jedoch ein Problem dar, da die Anzahl der Möglichkeiten derart variiert, dass sie ins Unendliche konvergieren und selbst im optimistischen Fall – bei konsequentem Einsatz von Standards – eher dazu tendieren, unbeherrschbar zu bleiben.

Unzählige Varianten

Schaut man sich einmal unterschiedliche Geschäftsfelder an und deren darauf aufbauenden Use Cases (s. Abb.2), erhält man in der Kombination der Möglichkeiten schon eine recht hohe Ausbeute an Varianten. Nach heutigen Maßstäben setzt bereits dies eine enorme Bandbreite von Integrationsarbeiten voraus, wenn die Produkte nicht auf rein proprietären Lösungen basieren oder bewusst als Insellösung geschaffen wurden.

Das ist allerdings noch nicht alles. Einmal realisierte Use Cases sollten natürlich auch in der Fläche mit anderen Use Cases und Geschäftsfeldern kombiniert werden können, was dann schlichtweg dazu führt, dass eine riesige Anzahl von Möglichkeiten neu existiert, die man auf herkömmlichen Weg nicht mehr kontrollieren kann.

Im Jahr 2020 würde sich die Situation bei Bewahrheitung der Gardner-Studie noch unwirklicher darstellen, weil dann viele Hersteller viele Lösungen anbieten werden und davon ausgegangen werden kann, dass ein hoher Prozentsatz der dann verfügbaren Produkte als offene Systeme angeboten werden und damit auch eine entsprechend hohe Anzahl von Verknüpfungsmöglichkeiten entstehen. Mit aktuell verfügbaren Standards und Technologien ist es dann alleine nicht mehr getan, um die Szenerie überhaupt noch ansatzweise beherrschen zu können.

Natürlich sind diese Beschreibungen als Chance zu verstehen und nicht als Unterstützung für IT-technische Untergangsszenarien. Dennoch erscheint es wichtig, nicht nur dem legitimen Marketinggedanken der Hersteller und Firmen bei der Entwicklung ihrer Produkte zu folgen, sondern das Offene eines Systems und den darauf aufbauenden Datenverkehr gezielt zu hinterfragen. Die Notwendigkeit, offene Systeme zu schaffen, sollte weiterhin Ziel sein. Im Sinne des IoT-Gedankens aber weg von typischen Herstellerabhängigkeiten und hin zur Nutzung und Etablierung neuer technischer Möglichkeiten, um den kommenden Herausforderungen gewachsen zu sein.

Davon ausgehend, dass die im vorherigen Abschnitt skizzierten Szenarien so eintreten, müssen andere Wege und Mittel gefunden werden, Herr der Komplexität zu werden. Aus der Perspektive eines Otto Normalverbrauchers betrachtet, ist dies sogar als zwingend anzusehen.

Eine Möglichkeit bietet die technische Bindung der den Geräten und Sensoren unterliegenden Protokollströme und Semantiken, mittels der sog. Protokollkonvergenz. Konvergenz im Sinne einer technischen Symbolik dient dazu, heutige und zukünftige Sensoren und Geräte allgemeingültig anzusprechen, sozusagen zu verweben. Hierbei sollte es keine Rolle spielen, ob derartige Geräte in unterschiedlichen Infrastrukturen betrieben werden oder von unterschiedlichen Herstellern stammen. Ebenso sollte es möglich sein, die Geräte mittels einer einzigen Anwendung zu kontrollieren oder aus der Sicht eines Entwicklers das Verhalten der Sensorik generisch ansprechen zu können.

Üblicherweise werden heutige IoT-Lösungen über eine eigenständige Zentraleinheit angesprochen und verwaltet. Der Benutzer kann dann über die üblichen Zugangsarten – sei es per Web-Frontend oder App – die eingebundenen Geräte ansprechen und administrieren. Die Zentrale besteht in der Regel aus einer Kombination von Hard- und Software. Während für den Hardware-Unterbau mittlerweile Systeme wie der Raspberry Pi sehr gute Dienste leisten, können für die Software z. B. Technologien wie OSGi genutzt werden, die die einfache Integration und Administration entsprechender Software-Module unterstützen.

IoT wird häufig in Kombination zu Sensoren gesehen, die sich über Bluetooth und WLAN anbinden lassen. Das ist der Tatsache geschuldet, dass heutige Endgeräte über beide Technologien gleichzeitig verfügen und somit die direkte Steuerung der Sensoren unter Umgehung einer Zentraleinheit ermöglichen. Weder Bluetooth noch WLAN stellen jedoch Sensorprotokolle im herkömmlichen Sinne dar, da die Ansprechsemantik der Geräte in der Regel keiner Standardisierung folgt und somit herstellerspezifisch, also proprietär, ist. Will man also Geräte über standardisierte Sensorprotokolle betreiben, wird die zuvor erwähnte Zentraleinheit – sozusagen als Intermediate-Plattform – benötigt.

Sensorprotokolle gibt es in vielfältigen Ausführungen und gab es auch schon bevor das IoT so richtig Fahrt aufnahm. In diesem Artikel betrachten wir daher vornehmlich die beiden bekanntesten Protokollvarianten: Zigbee und Z-Wave. Es handelt sich in beiden Fällen um Funkprotokolle, die auf eigenständigen Standards basieren und sich recht einfach mittels eines USB-Sticks an einer dezidierten Hardware betreiben lassen. Für den hypothetischen Fall, dass man die beiden vorgenannten Sensorprotokolle konvergieren lassen möchte, wäre eine Zusammenführung der Protokolle über eben zwei USB-Sticks an einer Zentraleinheit notwendig. Da die USB-Sticks als Verbindungsglied zwischen einer Rechnereinheit und dem eigentlichen Netzwerk fungieren, werden diese auch Koordinatoren genannt. Für die vorgenannten Sensornetzwerke gilt, dass man pro logisch adressierbarem Netzwerk nur einen Koordinator etablieren kann, der dann wiederum Sensoren und Geräte bis zu einer gewissen Anzahl im Netzwerk eigenständig verwaltet (s. Abb.3). Das bedeutet allerdings auch, dass alle Daten, die in das Netz gelangen und aus diesem empfangen werden, nur über den Koordinator laufen und letzterer damit den SPoF (Single Point of Failure) darstellt, da ohne diesen keine Kommunikation erfolgen kann.

Um also Sensordaten konvergieren und somit interpretieren zu können, ist es notwendig, den Eingangsstrom permanent zu überwachen und dies für jedes zu konvergierende Sensornetzwerk. Aktuelle funkbasierte Sensorprotokolle arbeiten in der Regel sequenzorientiert. Eine Sequenz stellt hierbei eine Kombination aus Kommandos und Befehlen (Metadaten), sowie deren dazugehörigen Parameterwerten dar. Kommandos sind durch das verwendete Protokoll standardisiert. Parameterwerte können gleichermaßen als echte Parameter oder auch als eigenständiger Befehlssequenz- bzw. Nutzdatenbereich für einen im Netzwerk anzusprechenden Sensor verwendet werden. Letzteres gilt z. B. für ein Zigbee-Netzwerk, welches den Herstellern erlaubt, den Bereich der Nutzdaten sensorspezifisch zu nutzen, obwohl das eigentlichen Protokoll die generelle Steuerung der Sensoren übernimmt.

Letzteres ist Segen und Fluch zugleich, denn obwohl ein derartiges Sensornetzwerk standardisiert wurde, können darin befindliche Komponenten nicht herstellerübergreifend angesprochen werden, da jeder Hersteller seine eigene für ihn passende Semantik entwickelt hat, die Geräte anzusprechen. Das führt mitunter auch dazu, dass sogar Produkte ein und desselben Herstellers nicht kompatibel zueinander angesprochen werden können, da sich die Befehlssequenzen in den Produktlinien zu stark unterscheiden.

Der reine Betrieb des Sensornetzwerkes über entsprechende Koordinatoren bietet von sich aus natürlich noch nicht den gewünschten Mehrwert einer Konvergenz. Es liegt auf der Hand, dass entsprechende Datenströme auf bestimmte Art und Weise kombiniert und interpretiert werden müssen um diese gezielt konvergieren zu lassen. Aus Datenperspektive wird dies auch als Multiplexing bezeichnet. Sobald mehr als eine Netzwerkinfrastrukturkomponente konvergieren soll, spricht man allgemein auch von einem koordinativen Multiplexing. Abb.5 symbolisiert dieses Szenario.

Will man z. B. unterschiedliche Sensoren dreier Hersteller (H1 – H3) von zwei unterschiedlichen Netzwerktypen (K1 und K2) über deren Koordinatoren betreiben, würde man Konvergenzregeln zwischen den beiden Sensornetzwerken benötigen und zusätzlich für die in einem Netzwerk unterschiedlichen Sensoren unterschiedlicher Hersteller.

Multiplexing, als Bestandteil eines Konvergenzvorganges, stellt sich nicht als ein einziger Prozess dar, sondern als eine Ansammlung unterschiedlicher Prozessmuster und deren Anwendung. Letztere variieren in Abhängigkeit des genutzten Sensorprotokolls erheblich.

Man unterteilt das Multiplexing grob in drei Teilbereiche, die als Source (Quelle), Mediator (Vermittlung) und Compounder (Verknüpfung) bekannt sind. Während die Source immer den Eingangsstrom eines Sensorprotokolls darstellt, handelt es sich beim Mediator um verschiedenste Konvergenzmuster, die auf den Datenstrom angewandt werden. Der Compounder wiederum verknüpft aus den Ergebnissen des Mediators die für andere Systeme verwertbaren Daten, die zum Beispiel wiederum einen Datenstrom oder eine Nachricht darstellen oder auch nur aus reinen Nettodaten bestehen können. Vorteilhafterweise können die resultierenden Objekte auch wiederum als Eingangsobjekte verwendet werden, um so Objekthierarchien in der automatischen Erkennung von Datenmustern zu ermöglichen.

Handelt es sich zum Beispiel bei dem resultierenden Objekt um einen reinen Datenstrom, könnten die Daten über die oben erwähnte Zentraleinheit einem IP-Netzwerk mittels standardisierter Adapter (z. B. XML, HTTP, SOAP, JMS etc.) oder Technologien zur Verfügung gestellt werden. Eindeutiges Ziel des Multiplexing ist es, aus n-verschiedenen Sensorprotokolldatenströmen einen IP-Datenstrom zu generieren, der zudem eine bidirektionale Kommunikation ermöglicht. Somit also das Szenario berücksichtigt, die Sensornetzwerke einer Kontrolle von außen zu unterziehen. Hierbei muss das Multiplexing natürlich auch in umgekehrter Richtung angewandt werden können, in dem aus einem IP-Datenstrom die angeschlossenen Sensordatenströme bedient werden.

Grundsätzlich kann das Prinzip einer Sensorprotokollkonvergenz auch auf Industrieprotokolle angewandt werden. Da diese aus Geschwindigkeitsgründen häufig Binärdaten versenden und prozessbedingt nur einmal erzeugt werden, wird somit ein ausgefeilteres Erkennungsverfahren benötigt.

Ziel des Einsatzes einer Protokollkonvergenz sollte sein, den Erkennungs- und Betriebsprozess automatisiert ablaufen zu lassen und somit die Notwendigkeit des Eingriffs durch den Anwender zu reduzieren. In jedem Fall aber gilt, je mehr Daten aus dem physischen Sensornetz bezogen werden können und je mehr Daten von den beteiligten Sensoren erzeugt werden, desto genauer und spezifischer können die Daten für Diagnosezwecke und Schaltszenarien automatisiert verwendet werden und desto genauer kann eine Konvergenz in verschiedenen Sensornetzwerken und über den darin befindlichen Sensoren realisiert werden.

Die Anwendung einer Protokollkonvergenz kann aber auch technische Grenzen aufzeigen, die das folgende hypothetische Szenario einmal verdeutlichen soll:

Gehen wir davon aus, dass eine oder auch mehrere Kameras nur dann auf Aufnahme schalten sollen, wenn einer der zusätzlich vorhandenen Rauchmelder einen Alarm signalisiert:

1. Wie und was kann konvergiert werden, wenn weder die Kamera noch die Rauchmelder vom gleichen Hersteller stammen?
2. Wie und was kann konvergiert werden, wenn die Rauchmelder von einem Hersteller stammen aber die Kameras nicht?
3. Wie und was kann konvergiert werden, wenn die Kameras und auch die Rauchmelder vom gleichen Hersteller stammen, die Bedienung aber auf gänzlich anderen technischen Gegebenheiten basiert? Überwachungskameras neuer Generationen werden in der Regel IP-technisch eingebunden und unterliegen damit einem anderen Ansprechverhalten als "dumme" Rauchmelder, die in der Regel nur ein Ereignis senden.
4. Wie und was kann konvergiert werden, wenn sich Kameras und Rauchmelder nur durch eine herstellerspezifische Software steuern lassen und somit keine Interaktion untereinander zulassen?

Variante 1 und auch 2 könnten über eine Konvergenzregel verknüpft und somit konvergent betrieben werden. Bei Variante 3 wäre in Abhängigkeit der Semantik, auf die die Sensorik reagiert, ein konvergenter Betrieb möglich. Bei Variante 4 ist ein konvergenter Betrieb aufgrund der verschlossenen, unzugänglichen Kommunikation nicht möglich. Für letztere Variante gilt sicherlich, dass derartige Lösungen nicht den zukünftigen Anforderungen und Notwendigkeiten der 2020er-Szenarien gerecht werden und diese daher nicht die erste Wahl darstellen sie einer Konvergenz zuzuführen.

Geht man davon aus, dass eine Protokollkonvergenz nach den oben erwähnten Schemata erfolgen kann und sich hersteller- und netzwerkübergreifend Komponenten ansprechen lassen, führt das unweigerlich zu der Notwendigkeit, dies in Koordination zu tun. Das bedeutet, dass die verschiedenen Aspekte der gemeinsamen Koordinierung über Hersteller- und Sensorgrenzen in Form von frei definierbaren Szenarien ermöglicht werden muss. Um dies zu erreichen müssen andere Verfahren angewandt werden, z. B. durch die sogenannte transaktionale Konvergenz.

Wie die Bezeichnung schon vermuten lässt, werden die oben besprochenen Konvergenzkriterien und -verfahren über transaktionale Beziehungen zueinander verknüpft. Das bedeutet letztlich nicht mehr, als dass die zu beschaltenden Szenarien in bestimmten Reihenfolgen ablaufen, gruppiert werden oder in Abhängigkeit voneinander unter bestimmten Gesichtspunkten Kriterien erfüllen müssen, um ablaufen zu können. Man unterscheidet zudem zwischen horizontaler (funktionsorientierter) und vertikaler (mediumorientierter) transaktionsorientierter Konvergenz. Ein Beispiel soll das Prinzip dahinter noch einmal verdeutlichen.

Hypothetisches Beispiel: Unterschiedliche Sensoriken, die von unterschiedlichen Herstellern stammen, müssen in drei verschiedenen Sensorprotokollen (Zigbee, Z-Wave und EnOcean) zentral, aber abhängig voneinander Daten senden und entsprechende Aktionen auslösen. Zusätzlich soll eine WiFi-Kamera eingebunden werden und die beteiligten Netzwerke sollen sich eigenständig koordinieren.

Die folgende Tabelle schlüsselt noch einmal detailliert die Abhängigkeiten aus Abb.7 zueinander auf. Hierbei geht es um drei Haupttransaktionen, die unterschiedliche Ausprägungen besitzen. Primär gilt, dass die Nichterfüllung einer der beteiligten Transaktionen unweigerlich zu einem Abbruch aller beteiligten Sequenzen führt und dies solange aufrechterhalten bleibt, bis alle beteiligten Einzelbedingungen erfolgreich abgeschlossen wurden.
 

Unabhängig davon, welche Werte genau in Sequenz #1 gemessen werden, handelt es sich in diesem Fall um eine funktionsorientierte (horizontale) Konvergenz. Der Grund liegt darin, dass sich alle Komponenten in ein und derselben Infrastruktur (Zigbee) befinden und nur Sensoriken verschiedener Hersteller genutzt werden.

Das gleiche Prinzip steckt hinter Sequenz #2 (Z-Wave). Zusätzlich besitzt diese aber noch eine Abhängigkeit zu Sequenz #1, was dazu führt, dass man in diesem Fall von einer mediumorientierten (vertikalen) Konvergenz spricht, da die beteiligte Transaktion über unterschiedliche Netzwerke aufgespannt wird.

Sequenz #3 symbolisiert ebenfalls ein mediumorientiertes Konvergenzverhalten, da sich die Bedingung in Abhängigkeit zur Transaktion #2 befindet. Da es sich bei Aktion #3 zusätzlich um eine Schaltsequenz handelt, die sich aber über zwei weitere unterschiedliche Netzwerke aufspannt (EnOcean und WiFi), handelt es sich in diesem Fall um eine weitere mediumorientierte Konvergenz.

Dieses hypothetische Beispiel zeigt recht deutlich, dass der konvergente Betrieb mehrerer Sensornetze möglich, aber komplex zu realisieren ist, wenn keine Transaktionalität gegeben ist. Selbst der Betrieb mehrerer Sensoren unterschiedlicher Hersteller in nur einem Sensornetzwerk verlangt schon einiges an Überblick und Koordination in der Entwicklung, um für einen Endanwender nutzbare Produkte zu konzipieren. Der Betrieb konvergenter Sensorprotokolle wird daher natürlich nicht nur von der technischen Machbarkeit geprägt, sondern auch von der Bedienung und der Kontrolle entsprechender Oberflächen zur Steuerung des Ganzen, abhängig sein, damit sich auch der nicht-technikaffine Nutzer sofort zurechtfindet und in der Lage ist, die von ihm präferierten Sensoren zu kontrollieren und zu steuern.

Sensorprotokolle werden in verschiedenen Varianten und Bereichen angeboten: standardisiert und nicht standardisiert. Die in den vorherigen Abschnitten benannten Sensorprotokolle Zigbee [4] und Z-Wave [5] sind vor allem in den USA und Kanada stark vertreten. Für beide Varianten stehen allerdings weltweit viele Sensorgeräte, Aktoren und Produkte zur Verfügung. Während Zigbee für einen Entwickler lizenzfrei genutzt werden kann, um dafür Software zu entwickeln, muss bei Z-Wave eine kostenpflichtige Lizenz in Form eines Software Development Kits bezogen werden. Das Kit beinhaltet neben einem Embedded System auch den zur Anbindung notwendigen USB-Stick, Sender- und Empfängerplatinen und einen Zugang zum Portal um gut strukturierte Dokumentationen einsehen und für eigene Zwecke nutzen zu können. Will man auf Basis dieser Technologien eigene Hardware (also Sensoren und Geräte) entwickeln, müssen diese eine entsprechende Zertifizierung durchlaufen. Beide Standards sind auch in Deutschland verbreitet, wenngleich bei Z-Wave der subjektive Eindruck entsteht, dass dieser in Anzahl marktreifer Produkte stärker vertreten ist.

Neben den beiden o. a. Sensorprotokollen gibt es auch sog. Messaging-Protokolle, die speziell auf Sensorkommunikation ausgerichtet sind und als Vermittler zwischen den Komponenten agieren können. Welche Komponenten hiermit betrieben werden, ist dabei den Komponentenherstellern überlassen. Bekanntestes Beispiel ist sicherlich neben MQTT (Message Queuing Telemetry Transport) auch XMPP (eXtensible Messaging and Presence Protocol) und das CoAP (Constrained Application Protocol) zu nennen. Ihnen allen gemein ist, dass sie auf TCP/IP bzw. UDP/IP basieren und in der Hauptsache über Broker-Funktionalitäten aktiviert werden. Sensoren, die mittels der vorgenannten Protokolle kommunizieren, müssen eine entsprechende Implementierung besitzen oder über einen Vermittler (typischerweise Broker genannt) Daten austauschen.

Wie oben schon erwähnt, setzen viele Hersteller auch auf Technologien wie Bluetooth Low Energy (BLE) sowie WiFi. Einer der größten Vorteile von Bluetooth wie WiFi ist sicherlich, dass beide in nahezu allen gängigen Smartphones und Geräten eingebunden sind und sich auch mittlerweile viele proprietäre Produkte darüber anbinden lassen. Aufgrund der technologischen Konzeption sind BLE-Produkte in der Regel Peer-to-Peer gesteuert, d. h. sie lassen nur eine Steuerung von Produkt zu Endgerät bidirektional zu und sind nicht in einem MeshUp-Netzwerkverbund (wie Zigbee und Z-Wave) nutzbar. Im deutschsprachigen Raum werden mittlerweile auch Sensoren und Aktoren anderer Protokollstandards  angeboten, wie z. B. EnOcean [6], 6LoWPAN [7] und auch der weniger bekannte Wireless M-Bus [8] der Fa. Silicon Labs, auch aus den USA stammend. In diesem Artikel beschränken wir uns aktuell auf die Standards Zigbee und Z-Wave um die Prinzipien hinter einer Protokollkonvergenz zu verdeutlichen.

Zigbee kann in einem sogenannten MeshUp-Modus betrieben werden. Der MeshUp-Modus ermöglicht ein Routing zwischen den verschiedenen Knoten (den Sensoren) untereinander, das u. a. die Sensorausfallraten verringert, da Daten über Umwege zum nächsten Netzwerknoten gelangen können und somit zum Koordinator. Zigbee-Komponenten bestehen daher aus drei Kategorien: Einem Koordinator, einem Router und dem spezifischen Endgerät. Der Koordinator existiert in jedem logischen Netzwerk nur einmal, während Router und Endgeräte mehrfach vorhanden sein können. Eine Router-Komponente routet nicht nur, sondern verwaltet auch die über sie kommunizierenden Endgeräte. Ein einfacher Einstieg in die Zigbee-Sensorwelt ist mit den Modulen von Digi [9], den sogenannten XBee-Modulen, gegeben. Neben der nativen Ansprache des Zigbee-Stacks auf Basis einfacher AT-Befehle, unterstützt Zigbee unterschiedliche Command Sets, die sich in Form einer sog. Cluster Library widerspiegeln. Cluster Libraries kapseln in erster Linie Funktionalitäten, die für spezielle Anwendungsfälle gedacht sind und somit die gezielte Entwicklung eines Sensors für spezifische Umgebungen ermöglichen. Prominentes Beispiel sind hier die Hue-Lampen von Philipps, deren Ansprechsemantik über die sog. Zigbee Light Linking API gesteuert wird. Daneben gibt es noch APIs für Gebäude- und Hausautomatisierung, eHealth, Smart Energy uvw.

XBee-Module der Fa. Digi kommunizieren auf Basis von Operationen. Eine Operation stellt dabei eine in sich abgeschlossene Aktion dar, die vom Koordinator ausgeführt wird oder an die entsprechende Komponente zur Ausführung weitergeleitet wird. Man unterscheidet grundsätzlich zwischen local- und remote-Kommandos.

Local-Kommandos werden vom Koordinator als Befehl interpretiert und dienen in der Hauptsache der Netzwerkadministration. Remote-Kommandos sprechen einen spezifischen Sensor an bzw. werden von diesem ausgeführt. Korrekterweise muss erwähnt werden, dass XBee-Operationen bei der Ausführung auf das eigentliche XBee-Modul wirken und keine direkten Auswirkungen auf den mit dem Modul verbundenen Sensor haben. Die Ansprache des Sensors erfolgt sozusagen nachgelagert durch den sogenannten Payload (Nutzdaten) in der Operation. Abbildung 8 verdeutlicht diesen Zusammenhang noch einmal anhand der Operation 0x08 (AT-Command) und 0x10 (Transmit Request). Aus der Perspektive des Koordinators betrachtet wird z. B. mittels der Operation 0x08 ein lokales Kommando über den Koordinator ausgeführt. Die in der Operation befindlichen Parameter sind hierbei AT-kommando- und nicht sensorspezifisch zu interpretieren. Sie dienen also der Administration des vorliegenden Netzwerkes und werden auch Metadaten genannt.

Im darunterliegenden Fall handelt es sich bei der Operation 0x10 um ein remote-Kommando, dass von einem Sensor bzw. dessen XBee-Modul interpretiert wird. Das Kommando wird zwar über den Koordinator versendet, aber an einen dezidierten Sensor weitergeleitet. Der in der Operation befindliche Nutzdatenbereich ist daher sensor- bzw. herstellerspezifisch zu interpretieren und unterscheidet sich natürlich von Sensor zu Sensor erheblich. Eine mögliche Konvergenz kann also auf Basis dieser Nutzdaten erfolgen und ist somit funktionsorientiert ausgelegt, d. h. auf ein Infrastrukturmedium beschränkt. Der Einsatz einer Konvergenz wirkt sich in diesem Fall also in erster Linie auf die Nutzdaten aus, die zum Sensor transportiert werden und weniger auf das Protokoll.

Anders verhält es sich in Abbildung 9. Es handelt sich hierbei wiederum um Operation 0x10, die ein spezifisches Kommando an einen explizit adressierten Sensor über den Koordinator weiterleitet. Zusätzlich wird auch ein Z-Wave Sensor in einem eigenen Z-Wave Netzwerk und dem darin befindlichen Koordinator angesprochen, deren Nutzdatenbereich sich so wie das Kommando gänzlich von dem des Zigbee-Sensors unterscheidet. Um diese beiden Sensoren konvergieren lassen zu können, werden zu den sensor- bzw. herstellerspezifischen Nutzdatenbereichen auch die Metadaten des jeweiligen Netzwerkes benötigt. Es wirkt also eine mediumorientierte (vertikale) Konvergenz. Konvergenz bedeutet in diesem Fall aber auch, dass die Netzwerke nach wie vor physisch voneinander entkoppelt sind und nur über die eine Konvergenzregel miteinander interagieren. Somit wäre auch eine getrennte Administration nach den allgemeinüblichen Prinzipien möglich, ohne die Konvergenzregel zu verletzen.

Z-Wave

Ebenso wie ein Zigbee-Netzwerk lässt sich das Z-Wave-Netzwerk in einem MeshUp-Modus betreiben. Auch hier wird die Hauptfunktionalität über einen Koordinator gesteuert und die Netzwerkintelligenz über Router verteilt. Unterschiedliche Z-Wave-Netzwerke können logisch mittels einer sogenannten Home-ID separiert werden und damit die in den jeweiligen Netzwerken betriebenen Sensoren. Im Gegensatz zu einem Zigbee- ist es in einem Z-Wave-Netzwerk möglich, Home-IDs über die Koordinatoren auszutauschen und somit die jeweils zugeordneten Sensoren übergreifend zu verwalten. Ein Sensorknoten (Node) wird über eine eindeutige 8-bit große Node-ID identifiziert, die innerhalb des Netzwerkes über die Home-ID eindeutig ist. Mittels der Node-ID können maximal 255 adressierbare Knoten zu jeweils einer korrespondierenden Home-ID verwaltet werden. Das Z-Wave-Protokoll bedient sich vier unterschiedlicher Datenformate um Kommandos im Netzwerk zu versenden. Es handelt sich um Singlecast (zielgerichtete Versendung an einen expliziten Sensorknoten), Transfer Acknowledge (Quittierung), Multicast (Versendung zu einer bestimmten Anzahl von Sensoren ohne Quittierung) und Broadcast (Versendung zu allen im Netzwerk bekannten Sensorknoten ohne Quittierung). Alle vier Formate nutzen die gleiche Datenstruktur, die sich wie in Abb.10 darstellt. Die eigentlichen Kommandos werden über sogenannte Kommandoklassen beschrieben und nicht über Operationen wie in einem Zigbee-Netzwerk definiert. Z-Wave-kompatible Sensoren und Geräte unterstützen entsprechende Kommandoklassen für die sie konzipiert wurden und sind auch in der Lage, entsprechende Kommandoklassen anderer Geräte zu unterstützen. Eine Kommandoklasse repräsentiert hierbei eine bestimmte Funktionalität, die sich auf verschiedene Kommandos innerhalb der Klasse verteilt. Somit kann zum Beispiel ein spezifischer Alarmsensor eines bestimmten Herstellers nur Kommandos einer Alarm-Kommandoklasse unterstützen. Für einen Alarmsensor eines anderen Herstellers würde das gleiche zutreffen. Somit ist die Semantik, die den Sensor anspricht, immer die gleiche. Letztere kann z. B. in der Form Get (gibt den Typ eines Alarms zurück), Set (de-/aktiviert den Alarm) und Report (meldet den Alarm) erfolgen. Ein Wert, der bei einem bestimmten Ereignis versendet wird, ist damit schon standardisiert und auch herstellerübergreifend interpretierbar. Der Aufwand zur Realisierung einer horizontalen Konvergenz ist somit weit weniger komplex als in anderen Sensornetzwerken, da die herstellerspezifischen Interpretationen wegfallen.

Funktionsweise

Die oben beschriebenen Sensorprotokolle sind sehr weit entwickelt und standardisiert. Das täuscht allerdings nicht über die Tatsache hinweg, dass diese auch miteinander konkurrieren und versuchen, um die Sensorhersteller zu werben und ihre Marktpräsenz zu erhöhen. Da es sich zudem nicht um die einzigen verfügbaren Protokolle handelt, die eine gewisse Marktdurchdringung erreichen wollen und zudem ständig neue Anforderungen entstehen und neue Sensortypen entwickelt werden, ist weiterhin mit einer erhöhten Fragmentierung verschiedenster Technologien zu rechnen und ein konvergenter Betrieb damit unerlässlich.
Abbildung 11 zeigt daher noch einmal das Prinzip hinter dem Einsatz entsprechender Strategien, die man anwenden könnte, um aus der Sicht eines Endbenutzers den größtmöglichen Nutzen aus dem konvergenten Betrieb zu ziehen.

Autor

Oliver Heuser

Oliver Heuser arbeitet als beratender Enterprise-Architekt und -Coach. Sein besonderes Interesse gilt speziell den Themen IoT und Industrie 4.0.
>> Weiterlesen

Das könnte Sie auch interessieren

IoT: Chancen und Herausforderungen für Software-Entwickler:innen

Schrumpfende IoT-Landschaft

Vernetzt, smart, komplex: Den Wandel zu AIoT meistern

Das Internet der nicht übertragbaren Dinge

(I)IoT-Lösungen mit Amazon Web Services

Smart Cities und IT-Security für den öffentlichen Sektor