5 Lösungsansätze für mehr Interoperabilität im IoT

Die Basis für smarte Produkte: Intelligente Datenmodelle

20.03.2018
Von   IDG ExpertenNetzwerk
Jan Rodig leitet das Kompetenzfeld Digital Performance & Analytics bei der Unternehmensberatung Struktur Management Partner. Er ist Experte für die Konzeption und Umsetzung von Digitalstrategien, für digitale Geschäftsmodelle und Digitalorganisationen. Herr Rodig ist Co-Autor mehrerer IoT-Fachbücher, Mitglied der BMWi-Initiative Plattform Industrie 4.0 und war bis 2019 CEO eines von ihm mitgegründeten IoT-Softwaredienstleisters.
Mangelnde Interoperabilität führte in der Vergangenheit oft dazu, dass Anbieter ihren Kunden für jeden Gerätetyp eine eigene Software-Anwendung bereitstellten. Die Folge: Kosten für Programmierung und Wartung explodieren, Release-Zyklen dehnen sich in die Unendlichkeit. Gibt es eine Lösung für diese Probleme?"

Viele Hersteller anspruchsvoller physischer Produkte haben diese bereits “smart” gemacht oder arbeiten zumindest aktuell daran. Auf dieser Basis möchten sie ihren Kunden digitale Mehrwertdienste anbieten und neue Geschäftsmodelle realisieren. Doch im Rahmen der technischen Umsetzung solcher Vorhaben stößt man in der Regel schnell auf größere “Altlasten”: Die Firmware, also die auf den Geräten, Maschinen oder Anlagen laufende Software, ist häufig heterogen – verschiedene Baureihen, Gerätetypen und Produktgruppen senden ganz unterschiedliche Datenstrukturen.

Mangelnde Interoperabilität ist aktuell eines der größten Hindernisse im IoT.
Mangelnde Interoperabilität ist aktuell eines der größten Hindernisse im IoT.
Foto: chombosan - shutterstock.com

Dies war in der Vergangenheit unproblematisch, da es schlicht noch keinen Bedarf für eine Vernetzung gab. Doch mit dem IoT kommen vermehrt Wünsche der Kunden auf, die Werkzeugmaschine, die Produktionsanlage, den Rasenmäher oder die Heizung per App überwachen und steuern zu können. Damit steht ein Hersteller plötzlich vor Problemen, die unterschiedlichen Daten aus den einzelnen Geräten zu “übersetzen” – wie geht man damit am besten um?

Aus der Erfahrung zahlreicher praktischer Projekte, gibt es für die technische Umsetzung solcher Vorhaben fünf Lösungsansätze – ein Überblick über deren jeweiligen Vor- und Nachteile.

Der Klassiker: eine App je Gerätetyp

Wenn ein Wettbewerber auf einer Messe unerwartet eine neue digitale Innovation vorstellt, die man selbst noch nicht im Portfolio hat, muss es oft sehr schnell gehen. Die Kunden fragen nach, der Vorstand will Ergebnisse sehen, für umfassende Analysen ist keine Zeit. Das führte in der Vergangenheit oft dazu, dass jeder Produktverantwortliche eine separate App erstellen ließ.

Was auf der Ebene unterschiedlicher Produktfamilien und -klassen aufgrund unterschiedlicher Zielgruppen, Einsatzzwecke und Funktionalitäten der Geräte häufig sinnvoll ist, endet jedoch in der Regel auf der Ebene von Produktlinien und Produkttypen: Warum muss es beispielsweise für jede Heizung eines Herstellers eine eigene App zur Bedienung geben, wenn deren Funktionalitäten exakt die selben sind? Was für den Kunden verwirrend ist, ist für den Anbieter teuer: Die Entwicklung und Pflege vieler ähnlicher Apps ist natürlich deutlich aufwändiger, als bei einer einzigen App.

Theoretisch prima: Firmware-Updates

Der naheliegendste Ansatz wäre, die Firmware auf den verschiedenen Geräten anzupassen und so die Datenstrukturen zu vereinheitlichen. Doch nur in den seltensten Fällen lässt sich die Firmware einfach online aktualisieren. Somit müssten entweder alle Produkte von den Kunden zurückgeschickt werden oder Techniker müssten jedes einzelne Gerät bei den Kunden vor Ort individuell aktualisieren.

Das ist für einen Anlagenbauer mit einigen hundert Anlagen “draußen” kein Problem, da dann ohnehin regelmäßig Wartungstechniker beim Kunden vor Ort sind. Bei größeren Stückzahlen im Feld und dazu noch vielen verschiedenen Gerätetypen und Produktgenerationen ist dieser Ansatz jedoch weder praktikabel noch wirtschaftlich vertretbar, insbesondere wenn der Wert des einzelnen Produktes relativ gering ist. Weiterhin ist der Entwicklungs- und Testaufwand für solch ein Firmware-Update immens, denn jeder Fehler führt zu unzufriedenen Kunden und erfordert ein neues aufwändiges Update – wieder durch Einsendung der Geräte oder den nächsten Technikerbesuch beim Kunden.

Quick and dirty: Datenstandardisierung in der App

Eine andere Möglichkeit, den unterschiedlichen Daten-Output der verschiedenen Geräte unter einen Hut zu bringen, ist die Erkennung und Umwandlung der Datenformate in der App selbst. Die Endanwendung, also beispielsweise eine iPhone-App, muss dann alle möglichen Datenformate auf einen Nenner bringen können.

Für die erste Version einer IoT-Lösung funktioniert das, erweist sich jedoch meist schon sehr schnell als zu unflexibel und enormer Kostentreiber. Denn zum einen sollen die Anwendungen in der Regel für verschiedene Betriebssysteme wie iOS, Android oder Web zur Verfügung stehen, was in diesem Fall auch erfordert, die gesamte Dateninterpretationslogik mehrfach zu entwickeln. Zum anderen macht es die Weiterentwicklung der App kompliziert: Kommen neue Produkttypen oder Services hinzu, sind aufwändige Anpassungen notwendig – und dies wieder für mehrere Betriebssysteme und für alle angeschlossenen Systeme.

Der Königsweg: separate Datenstandardisierung

Sinnvoller ist es, die Datenstandardisierung sowohl von den Geräten als auch von der Anwendung getrennt zu betrachten. Findet die Vereinheitlichung der Daten auf einem Zwischenlayer wie beispielsweise einer IoT-Plattform statt, macht dies die IoT-Lösung deutlich flexibler. Von den Geräten können die Daten wie bisher abgenommen werden, sie benötigen kein Update. Anschließend werden die Daten in der Cloud vereinheitlicht, so dass die App selbst von der Datenstandardisierung befreit und damit deutlich schlanker ist. Bei Fehlerbehebungen, Änderungen und Erweiterungen ist somit nur eine zentrale Anpassung der zwischengelagerten “Übersetzungsschicht” erforderlich.

Alternativ erfolgt die Vorsortierung und Standardisierung der anfallenden Daten bereits auf den Gateways der Geräte, sofern diese entsprechend dimensioniert sind. So müssen nicht alle Daten in die Cloud geschickt werden. Das spart Rechenpower in der Cloud und senkt das Volumen der zu übertragenden Daten, so dass die Betriebskosten der IoT-Lösung verringert werden.

Die Voraussetzung: intelligente Datenmodelle

Die wahrscheinlich größte Herausforderung ist die Entwicklung eines geeigneten Datenmodells als Basis für die Datenstandardisierung in der Cloud oder auf dem Gateway – schließlich ist es die Grundlage des gesamten IoT-Vorhabens. Dieses sollte so strukturiert sein, dass es flexibel genug ist, um verschiedenste Datenformate integrieren zu können, diese für die App aufzubereiten und auch aktuell noch nicht absehbare zukünftige neue Produkte, Services und Funktionen integrieren zu können.

Weiterhin muss es auch umgekehrt Anweisungen des Nutzers – beispielsweise Steuerungsbefehle wie “Heizung auf 25 Grad einstellen” – erkennen und für die verschiedenen Gerätetypen im Feld übersetzen können. Die Konzeption und Erstellung solcher Datenmodelle sollte daher sorgfältig und idealerweise unter Hinzuziehung erfahrener Experten angegangen werden.

Industriestandards: wünschenswert, jedoch limitiert

Doch ist es überhaupt notwendig, ein eigenes Datenmodell zu entwickeln? In zahlreichen Branchen gibt es übergreifende Standardisierungsinitiativen wie beispielsweise EEBUS (www.eebus.org) im Bereich Smart Home und E-Energy. Diese können zumindest für Neuprodukte einen einheitlichen Aufsatzpunkt schaffen. Doch Standardisierung dauert erfahrungsgemäß aufgrund zahlreicher Abstimmungen und verschiedener Interessen lange, erst recht, wenn sie auf europäischer oder gar globaler Ebene greifen soll. Auch lässt sich oft nicht im Voraus abschätzen, welcher Standard sich am Ende tatsächlich am Markt durchsetzt.

Darüber hinaus kann ein Standard nur einen groben Rahmen vorgeben – zu individuell sind die Anforderungen und Lösungen der einzelnen Hersteller. Anpassungen und Erweiterungen solcher Standards, so es sie denn gibt, werden daher auch künftig notwendig sein. Hersteller sollten deshalb zeitnah ihr eigenes, konsistentes und zukunftsfähiges firmeninternes Datenmodell entwickeln, das später über Adapter an jeden beliebigen Third-Party-Standard angedockt werden kann. (mb)