Gerade neue digitale Geschäftsmodelle leben davon, dass Betriebs- und Wartungsdaten während des Produktlebenszyklus an den Hersteller zurückfließen. Die Grundlage dafür sind IIoT-Systeme. In der Praxis ist in den letzten Jahren zugleich deutlich geworden, dass jeder einzelne Anwendungsfall seine ganz spezifischen Pain Points hat. Systeme von der Stange gibt es kaum. Hinzu kommen mehrere typische Herausforderungen. Ob bei Remote Services, vorbeugender Wartung oder Fernwartung: Software-Updates und Maschinenzugriff müssen auch aus der Ferne möglich sein. Das Thema Security ist also eng damit verbunden, denn alle Devices und deren Betriebssysteme müssen über den Lebenszyklus einer IIoT-Plattform – also durchaus zehn bis zwanzig Jahre – sicher und aktuell gehalten werden. Bisher wurde im IoT-Bereich vieles erst einmal in Proofs of Concept ausprobiert, die Security stand oft nicht im Vordergrund. Doch der Gesetzgeber hat angesichts der Cyberbedrohungslage nachjustiert. Die EU-Richtlinie des Netzwerk- und Informationssystemgesetzes – kurz NIS2 – legt Cybersecurity-Mindeststandards für kritische Infrastrukturen in der EU fest und greift für viele Unternehmen ab 50 Mitarbeitern und zehn Millionen Euro Umsatz. Es gilt sicherzustellen, dass ein Device nicht gehackt und weder als Teil eines Bot-Netzes missbraucht, noch zum Einfallstor in ein Unternehmensnetzwerk werden kann. Dafür müssen alle Komponenten abgesichert sein, etwa auch IoT Gateways oder Edge-Rechner. Viele Unternehmen haben sich auf diese Herausforderung noch nicht eingestellt – es ist damit zu rechnen, dass es ähnlich wie beim DSGVO-Start ein unangenehmes Erwachen geben wird.
Projektkomplexität ist gestiegen
IoT-Vorhaben bringen in der Regel ein ganz anderes Maß an Komplexität mit, als es bisher bei Elektronikprojekten der Fall war. Sie übersteigt häufig den bisherigen Erfahrungshorizont der Anwenderunternehmen, die sich jetzt mit der Tragfähigkeit neuer Geschäftsmodelle und den Einsatzpotenzialen von Technologien wie AI, Edge und Cloud auseinandersetzen müssen. Es geht weniger um die Features eine Steuerung und mehr um das Potenzial dessen, was beispielsweise wirtschaftlich und hinsichtlich der Kundenbindung mit einem System zu erreichen ist. Mit der Wartung und Pflege einer hohen Zahl an international verteilten IoT-Devices im Feld ist ein erheblicher Aufwand verbunden. Viele Unternehmen wünschen sich diese Leistung als Service, da sie nicht zum Kerngeschäft zählt.
Herausforderungen antizipieren
Doch am Anfang eines IoT-Projektes steht die Definition des digitalen Geschäftsmodells. Hier sollten die wesentlichen Herausforderungen antizipiert werden. Ein Beispiel ist die Umsetzung eines neuen Geschäftsmodells bei einem Molkereiunternehmen. Gemeinsam mit Kontron wurde eine Gastronomiemaschine entwickelt, die aus kleinen Milchkonzentrat-Containern im Bag-in-Box-Format Milchschaum herstellt. Neigt sich das Konzentrat dem Ende zu, können die Geräte automatisch Nachschub bestellen. Ein international aufgesetzter Business Case, der sich bewährt hat: Ziel des Unternehmens ist es, möglichst viele Geräte ins Feld zu bringen und damit den Milchumsatz dauerhaft bei Gastronomiekunden zu platzieren. Bei einem solchen Use Case müssen schon bei der Auswahl der Komponenten viele Fragen beantwortet werden: Wo stehen die Geräte typischerweise? Gibt es Settings, in denen keine Mobilfunkverbindung vorhanden ist, also Offline-Fähigkeit gegeben sein muss? In welche Regionen sollen Geräte verkauft werden? Nur in der EU oder auch in andere Länder? Dafür sind jeweils spezielle Zulassungen erforderlich. Hinzu kommt die Frage, wie der gewählte Mobilfunkpartner aufgestellt ist. Hat er wiederum Roaming-Partner vor Ort in den anderen Zielländern? Dürfen die Endkunden ihre lokalen SIM-Karten in das Gerät stecken oder soll das aus Sicherheitsgründen nicht möglich sein, damit der Anbieter hier die Führung behält? Was genau will man den Endkunden an Funktionalität bieten? Es gibt also eine Vielzahl von Stolpersteinen, die im Vorfeld aus dem Weg geräumt werden müssen, damit ein IoT-System dauerhaft sicher funktioniert und die Endgeräte erreichbar bleiben. In vielen Umfeldern wie etwa Krankenhäusern oder Flughäfen müssen zudem Connectivity-Fragen bedacht werden, beispielsweise wenn es um die Ortung von Devices an Betten, Rollstühlen oder Förderfahrzeugen per WLAN, Funk oder Bluetooth geht.
Entwicklungsmethoden abstimmen
Um den Überblick zu behalten, sollten Unternehmen ein Lastenheft mit den Anforderungen an Hardware, Software und Services erstellen. Dies ist besonders wichtig, weil hier Welten aufeinandertreffen, etwa die agilen Entwicklungsmethoden im Softwarebereich und die ganz anderen Anforderungen in der Hardwareentwicklung. Sie lassen sich deutlich weniger hybrid und gleitend gestalten. Um am Ende die Erfüllung aller Anforderungen prüfen zu können, führt an einer ordentlichen Dokumentation kein Weg vorbei. Selbst für die Preisfindung ist eine schriftliche Spezifikation wesentlich. Die Anforderungen an Services, Device-Management und Mobilfunk-Provider müssen definiert werden, damit in der Grundarchitektur alles zusammenpasst.
Hardware-Entscheidungen fallen früh
Insbesondere an der Hardware scheiden sich oft die Geister. Wird ein Mobilfunkgerät gewählt, das nur für die EU funktioniert, dann steht ein Re-Design an, wenn doch der amerikanische Markt adressiert werden soll. In den einzelnen Ländern gibt es spezielle Regularien. In den USA muss ein mobilfunkfähiges Gerät beispielsweise eine FCC-Zulassung (Federal Communications Commission) haben. In manchen Fällen benötigt man zum Betreiben eines Gerätes im Netz eines Mobilfunkproviders auch dessen Freigabe. Liegt sie nicht vor, können Redesigns und Neuzulassungen viel Zeit und Geld kosten. Bei der Hardware müssen also viele Entscheidungen vorab getroffen werden, während sich im Softwarebereich agile Methoden mit Sprints eignen, um auch noch während der Entwicklung weitere Anforderungen an das System einbringen und umsetzen zu können. Dort steht in den Projekten auch der Aufbau von automatisiertem Testing und professioneller Versionsverwaltung auf dem Programm.
Baukasten für standardisierte Systeme
In der Regel starten IoT-Projekte mit einem PoC, in dem zunächst ein kleines System erprobt wird. Wichtig ist, dass der Systemlieferant ein Portfolio besitzt, das die spätere Skalierung nicht ausbremst. Je nach geplanten Stückzahlen geht es neben der Leistung oft um den Preis. Nur selten passt ein fertiges Produkt, denn die Rahmenbedingungen sind zu unterschiedlich. Oft geht es darum, ein Device auf den Use Case zuzuschneiden. Viele Lieferanten haben auch hierfür mittlerweile unterstützende Instrumente im Angebot.
Lange Lebenszyklen bedenken
Da viele Maschinen 20 Jahre und länger im Einsatz sind und danach oft ein Second Life haben, muss auch bei den IoT-Systemen langfristig gedacht werden. Da sich Mobilfunkstandards und andere Protokolle über die Jahre verändern, müssen sich Hardware, Software und Mobilfunkanbindung aktuell halten lassen. Werden offene Standards wie OSM, SMARC oder COM-HPC sowie standardisierte Schnittstellen verwendet, können sich abgekündigte Prozessoren oder CPU-Boards leichter ersetzen lassen. Auch das Betriebssystem muss sich über den Lebenszyklus hinweg sicher gestalten lassen. Um Weiterentwicklungen bei Mobilfunkstandards abzubilden, könnten vorzertifizierte Mobilfunkmodule verwendet werden, die via Standardinterfaces an die Prozessoren angekoppelt sind. Sollten Änderungen nicht durch ein reines Protokoll-Update erfolgen können, kommt der Austausch des Mobilfunkmoduls in Frage. Welche Möglichkeiten die eingesetzte Hardware unterstützt, sollten die Systembetreiber in Spe ebenfalls früh klären.
