Über unsMediaKontaktImpressum
Bernd Behler 17. April 2018

IoT braucht standardisierte Daten

Das Internet der Dinge findet immer neue Anwendungsbereiche: von Gebäudeautomatisierung über Smart City bis hin zum vernetzten Auto und der intelligenten Fabrik. Unterschiedliche Komponenten und Produkte müssen miteinander kommunizieren und zahlreiche Daten austauschen können, um neue Services zu ermöglichen. Doch unterschiedliche Kommunikationsstandards und Datenformate hemmen die Entwicklung. Welche Möglichkeiten gibt es, um zu einer gemeinsamen "Sprache" zu finden?

Das Internet der Dinge ist mehr als eine Sammlung von IP-fähigen Geräten. Der Wesenskern des IoT ist nicht die technische Vernetzung, sondern das, was sich daraus ergibt: eine Kommunikation direkt von Maschine zu Maschine (M2M), ohne menschlichen Bediener, sowie autonome Prozesse aufgrund der ausgetauschten Daten. Aber auch Anwendungen, die in gewisser Weise intelligenter sind als reine Datenabfragen der Vergangenheit zählen zum IoT. In der Industrie sind hier unter anderem selbstorganisierende Fertigungsstraßen zu nennen oder auch Predictive Maintenance, wenn die Maschine also beispielsweise den Grad der Abnutzung selbst erkennt und dementsprechend rechtzeitig eine Wartung anfordert. Damit dies alles funktioniert, müssen Maschinen und Geräte nicht nur Daten senden und empfangen, sondern auch "verstehen", was diese Daten bedeuten. Ein solcher Informationsfluss bedarf aber nicht nur gemeinsamer Protokolle für die Vernetzung und Datenübertragung, sondern einer gemeinsamen "Sprache", die zusätzliche Beschreibungen zu den Daten ermöglicht.

Babylonische Sprachverwirrrung

Anders als bei der Office-IT, deren Kommunikation auf einem einheitlichen Ethernet-Standard basiert, gibt es im Internet der Dinge unzählige Dialekte: Industrie-Netze, Gebäudetechnik und diverse andere Anwendungen nutzen verschiedene Dialekte bei Feldbussen, Ethernet-Verkabelungen und drahtloser Kommunikation. Oft sind diese Standards herstellerspezifisch. So kennt allein das Industrial Ethernet sechs unterschiedliche Standards, denen Maschinenbauer und Anlagenbetreiber mit Multiprotokoll-Komponenten und Netzwerk-Konvertern zu Leibe rücken, um eine durchgängige IP-Kommunikation zu gewährleisten.

Ähnlich verhält es sich mit den Datenstrukturen von Sensoren und Aktoren, von Geräten und Maschinen. Auch diese sind oft herstellerspezifisch und daher nicht kompatibel zueinander. Gemischte Umgebungen bei der Komponentenwahl, Maschinen oder Geräte von verschiedenen Lieferanten, historisch gewachsene Infrastrukturen in früher abgegrenzten Teilbereichen oder das Zusammentreffen von unterschiedlichen Standards beispielsweise bei Firmenübernahmen sind nur einige Szenarien, die das Problem der "Babylonischen Sprachverwirrung" deutlich machen. Diese aufzuheben ist kein einfaches Unterfangen.

Harmonisierungs-Initiativen

Obwohl die Industrie jahrzehntelang gut mit einer Vielzahl von Standards leben konnte, ist inzwischen ein langsamer Wandel zu bemerken. Denn die mit den unterschiedlichen Übertragungsprotokollen und Datenformaten verbundenen Kosten – für Softwareentwicklung, zusätzliche oder aufwändigere Komponenten und daraus resultierende höhere Service- und Lagerhaltungsaufwände sowie den Zeitverlust beim Engineering – machen einen immer höheren Anteil aus, den die Hersteller im preissensitiven Wettbewerb gerne drücken würden. Eine übergreifende Standardisierung würde vieles erleichtern.

Erste Initiativen in dieser Richtung gibt es bereits. Zu nennen ist das Beispiel EEBUS, ein offener Kommunikationsbus, der von mehr als 60 Herstellern aus den Bereichen Smart Home, vernetzte Haustechnik, Elektromobilität und Energie getragen wird. Sieht man sich die Entstehung eines neuen Standards an, dann wird deutlich, wo die Probleme liegen. Die teilnehmenden Unternehmen entsenden Vertreter mit spezifischen Wünschen und Vorschlägen. Oft kann man sich – nach langwierigen Verhandlungen, die mehrere Jahre dauern können – nur auf den kleinsten gemeinsamen Nenner einigen. Das Ergebnis ist dann ein Standard, der gegenüber den ursprünglichen Anforderungen nur stark vereinfacht ist und unter Umständen nicht allen IoT-Funktionen gerecht wird.

General-Update für Maschinen?

Zunächst einmal muss geklärt werden, welche Daten überhaupt ins Internet der Dinge eingespeist werden, und wie dies vonstatten geht. Würden alle Geräte und Komponenten eines Hersteller die gleiche Daten-Repräsentation verwenden, könnten die darauf aufgebauten Maschinen und Anlagen die Daten direkt über ein Gateway im Netz verfügbar machen oder diese an eine Cloud weiterleiten, die diese Aufgabe übernimmt. Eine solche einheitliche technische Basis gibt es jedoch de facto nicht – allein schon unterschiedliche Entwicklungslinien und -stände stehen dem entgegen. Und auch eine nachträgliche Anpassung ist unrealistisch. Wer wollte entsprechende Firmware-Updates für bereits verbaute, aber nicht mehr im Handel befindliche Komponenten entwickeln – falls diese überhaupt updatefähig wären? Viele Geräte müssten vor Ort upgedated werden, da sie nicht remote zu erreichen sind. Und dann wäre ein solcher Eingriff vermutlich so schwerwiegend, dass Dokumentationen und Zertifizierungen neu zu erstellen wären, um die Betriebsgenehmigung nicht zu verlieren. Alles in allem also ein nicht zu vertretender Aufwand für jede einzelne Anlage.

Ansatzpunkte für eine Vereinheitlichung

Wenn aber nicht an jedem einzelnen Gerät dafür gesorgt werden kann, eine gemeinsame Sprache zu installieren, wo dann? Letztlich bleiben drei Möglichkeiten:

  • an einem Gateway, bei dem die Daten zusammenlaufen,
  • in der Cloud, in der die Daten gesammelt werden, oder
  • im Frontend, also in der IoT-Webanwendung, die die Daten in Form von intelligenten Services nutzt.

Die schlechteste Lösung ist dabei die Integration ins Frontend. Zwar laufen hier alle benötigten Daten zusammen, aber trotzdem ist es keine "zentrale" Stelle im engeren Sinn. Denn oft ist das Frontend nicht nur als zentraler Webservice, sondern als App ausgeführt. Versionen für verschiedene Betriebssysteme – iOS, Android und Windows – und Sprachen werden teils auf unterschiedlicher Codebasis, vielleicht sogar von unterschiedlichen Teams erstellt. Jede Veränderung oder Erweiterung auf Seiten der zu integrierenden Daten führt zu Updates auf allen unterstützten Plattformen, die programmiert, getestet und an die Kunden ausgerollt werden müssen. Dies ist nicht nur aufwändig und teuer, sondern auch schwerfällig im Handling, da der Anwender bis zum Aufspielen der neuen Version mit Service-Unterbrechungen oder Teilausfällen leben muss. Zudem ist das Verfahren fehleranfällig.

Maschinen-Esperanto an zentraler Stelle

Bleiben also das Gateway sowie die Cloud als sinnvolle Ansatzpunkte. Neue Geräte mit zusätzlichen Datenformaten können hier am einfachsten implementiert werden. Das User-Frontend dagegen muss von diesen Veränderungen nichts mitbekommen – es wird nach der Dateninterpretation weiterhin mit unverändertem Output "gefüttert", egal auf welchem Betriebssystem es läuft. Auch der Anwender bekommt von den Veränderungen im Hintergrund nichts mit: er muss weder ein Update aufspielen noch mit Service-Unterbrechungen rechnen.

Die naheliegendste Lösung ist also eine Daten-Interpretation in der Cloud. Hier steht viel Rechenpower und Speicherkapazität zu erschwinglichen Preisen zur Verfügung, und die unterschiedlichen Daten können innerhalb der IoT-Plattform verarbeitet werden. Dementsprechend kann eine Cloud-Anwendung als Zwischenlayer dienen, als Vermittler, der unterschiedliche Datenformate entgegennimmt und standardisierte Daten und Informationen ausgibt.

Hier jedoch liegt gleichzeitig auch der Haken. Die Abrechnungsmodelle der IoT-Plattformen sind meist auf die Zahl der übertragenen Daten ausgelegt. Wenn sich die Zahl der Geräte, die Anzahl der Datenpunkte und die Frequenz des Dateneingangs zu hohen Zahlen multiplizieren, dann kann es schnell sehr teuer werden. Senden hunderttausende Geräte jeweils mehrere Status-Informationen und Messwerte in kurzer Zeit, ist zudem schnell ein Datenvolumen erreicht, das die Übertragungskapazitäten an die Grenzen der Leistungsfähigkeit bringt. Dies schafft insbesondere dann Probleme, wenn die IoT-Anwendung in Echtzeit kommunizieren soll, weil sie nicht nur Daten entgegennimmt, sondern nach deren Verarbeitung auch Steuerbefehle für die IoT-Geräte aussendet.

Mit dem Gateway alles im Griff

An dieser Stelle sind deshalb zwei Entscheidungen zu fällen, die miteinander in Verbindung stehen: Welche Daten in die Cloud gebracht werden müssen oder sollen, und an welcher Stelle die Datenstandardisierung erfolgen soll.

Wenn aus den oben genannten Gründen nur ein Teil der Messwerte an die IoT-Plattform in der Cloud übermittelt wird, sollte die Datenstandardisierung oder Dateninterpretation auf jeden Fall im beziehungsweise vor dem Internet-Gateway erfolgen. An dieser Stelle kann dann auch das Datenvolumen für die Cloud reduziert werden, beispielsweise durch eine Vorverarbeitung, die konsolidierte Informationen erzeugt. Das setzt bei hohem Datenaufkommen natürlich eine entsprechende Rechenkapazität voraus – ein reines Gateway oder eine SPS, die zusätzliche Gateway-Funktionen übernehmen kann, reichen dann meist nicht mehr aus. Stattdessen sollte hier ein Industrie-PC zum Einsatz kommen. Man sollte sich andererseits aber auch bewusst machen, dass Big-Data-Analysemethoden und -Anwendungen wie Mustererkennung, Maschinelles Lernen und Künstliche Intelligenz Zugriff auf den vollständigen Datenbestand brauchen, sprich: alles in die Cloud übertragen werden muss. Unter dieser Voraussetzung kann die Standardisierung wahlweise auf Seiten des Gateways oder in der IoT-Plattform erfolgen – in jedem Fall aber vor der Anwendung der Big-Data-Werkzeuge.

Standard(s) für Jeden

Mit OPC UA (UA steht für Unified Architecture) wurde der Versuch unternommen, die Datenstrukturen aus unterschiedlichen Quellen in eine einheitliche Form zu überführen. Wobei die Daten nicht nur ausgelesene Messwerte umfassen, sondern genauso auch die Zielwerte für Arbeitsanweisungen oder Sollzahlen für Alarmierungsschwellen. OPC UA sieht sich nicht als klassisches Protokoll, sondern als Kommunikationsplattform, da die Daten nicht nur standardisiert, sondern auch semantisch beschrieben werden.

Die Logik wird nicht mehr für die Geräte entwickelt, sondern das Gerät passend zur Logik.

Um ein möglichst breites Einsatzspektrum zu erreichen, hat sich die OPC-Foundation entschlossen, den Standard mit branchenspezifischen Erweiterungen zu ergänzen. So gibt es für Verpackungsmaschinen andere Subsets als für Brauereianlagen, für Gebäudetechnik oder für Gesundheitstechnik. Dadurch lassen sich viele spezifische Themen abbilden, etwa die automatische Erkennung, welche Funktionen eine Anlage oder ein Gerät zur Verfügung stellt. Die vielen darin abbildbaren Funktionen sind seine größte Stärke – und zugleich seine größte Schwäche: das Protokoll ist zwangsläufig recht komplex und schwerfällig in der Anwendung. Es muss daher genau abgewogen werden, ob sich der Einsatz eines solch mächtigen Werkzeugs lohnt, das auch einiges an Programmieraufwand in der Steuerung oder dem Internet-Gateway erfordert, und auch ein entsprechend leistungsfähiges Gateway voraussetzt.

Eigene Daten-Konzepte

Sind alle diese Fragen geklärt – welche Daten werden wo gebraucht und wo verarbeitet – kann es nun an den schwierigsten Teil gehen: die Entwicklung eines eigenen, firmeninternen Standard-Datenmodells, da, wie oben gezeigt, echte Branchenstandards weitgehend fehlen, den spezifischen Anforderungen nicht gewachsen sind oder neue technische Hürden aufstellen.

Voraussetzung für das eigene Datenmodell ist eine gewisse Flexibilität, die der Entwicklung neuer Geräte oder der Integration zusätzlicher Daten, falls sich neue Anforderungen ergeben, nicht entgegenstehen. Dieser Standard sollte dann als Grundlage dienen, wenn die Firmware für neue Geräte oder Gerätetypen programmiert wird, so dass deren Daten grundsätzlich nicht mehr übersetzt werden müssen. Denn IoT-Funktionen sind künftig nicht mehr nice-to-have, sondern ein Must-have, müssen also bei den Entwicklerteams einen hohen Stellenwert einnehmen. Industrie 4.0 heißt schließlich, dass Geschäftsstrategien und -services im Zentrum stehen, nicht mehr die Technik. Dementsprechend dreht sich die Priorität um: Die Logik wird nicht mehr für die Geräte entwickelt, sondern das Gerät passend zur Logik.

Praktische Umsetzung

Ein intelligentes, übergreifendes Datenmodell zu schaffen ist kein einfaches Unterfangen. Strategie-, Technik- und Anwendungswissen müssen hier zusammenkommen, um ein gutes Ergebnis zu erzielen. Die Übersetzung und Aufbereitung der Daten, die auf diesem Modell basiert, ist ein essenzieller Bestandteil des gesamten IoT-Projekts und entscheidet damit über Erfolg oder Misserfolg des Vorhabens. Sie stellt die Verbindung her zwischen den eingehenden Daten der angeschlossenen Geräte, Maschinen oder Anlagen und der Anwendung am Frontend, die möglichst intelligente Services bieten soll. Und dieser Weg ist keine Einbahnstraße: Anweisungen des Nutzers aus der App – oder aber auch automatisch generierte Steuerbefehle – müssen den Weg zurück finden, beispielsweise zu einer Maschine, die darüber gesteuert wird. Die Übersetzung muss also auch aus Standard-Daten wieder Rohdaten erzeugen können, die die Maschine verstehen kann. Dies gelingt nur dann fehlerfrei, wenn die Abbildungsvorschriften in beiden Richtungen eindeutig ist. Geht hier etwas schief, kann es zu Ausfällen und teuren Stillstandszeiten kommen, die mit zusätzlichem Entwicklungs- und Rollout-Aufwand verbunden sind. Im schlimmsten Fall ist sogar ein Rollback nötig.

Fazit

Die Anforderungen an Hersteller, die in den IoT-Markt einsteigen wollen, sind hoch, aber beherrschbar. Sie müssen sich darüber im Klaren sein, welche Dienste und Angebote ihr Geschäftsmodell künftig umfassen soll. Dazu benötigen sie ein zukunftsfähiges eigenes Datenmodell, das zu den gestellten Anforderungen von heute passt, aber auch genügend Flexibilität für künftige Erweiterungen lässt. Ziel muss ein langlebiger Standard sein, der bei Bedarf über Adapter auch auf externe Datenmodelle abgebildet werden kann, wenn sich später einmal branchenweite Standards herausbilden sollten.

Dagegen macht es keinen Sinn, sich zurückzuhalten, bis solche Standards entwickelt und verfügbar sind. Ebenso gefährlich sind Lösungen der Marke "Quick-and-Dirty". Solche Entwicklungen sparen nur scheinbar Zeit und Geld – ihnen fehlt meist die nötige Flexibilität, weil man sich zu wenig Gedanken über ein langfristig tragfähiges Konzept gemacht hat. Ergeben sich später neue Anforderungen, oder kommen andere Geräte hinzu als ursprünglich gedacht, führt dies schnell zu hohen Entwicklungskosten und Verzögerungen beim Go-to-Market. Wer gar eine Neuprogrammierung starten muss, ist schnell raus aus dem Geschäft. Verzögerungen bis zum "Sankt-Nimmerleins-Tag" akzeptiert kein Kunde mehr. Stattdessen sollten Unternehmen ihre IoT-Projekte systematisch angehen. Die Entwicklungsarbeit im Vorfeld – die Konzeption eines sinnvollen Datenmodells – lässt sich sehr gut über agile Methoden vorantreiben. So werden mit wirtschaftlich vertretbarem Aufwand langfristig einsetzbare Lösungen geschaffen.

Autor

Bernd Behler

Bernd Behler setzt sich seit 20 Jahren mit seinem Team mit viel Leidenschaft für skalierbare, sichere, zuverlässige und zukunftsfähige IoT-, Cloud- und App-Lösungen ein.
>> Weiterlesen
Das könnte Sie auch interessieren
botMessage_toctoc_comments_9210