Checkliste für eine IoT-Referenzarchitektur

Diese Referenzarchitektur (RA) soll einerseits helfen, eigene IoT-Lösungen zu bauen und sie andererseits bei der Bewertung kommerzieller IoT-Lösungen unterstützen. Die Referenzarchitektur ist beides, Guide für eigene Entwicklungen und Checkliste/Bewertungstool für IoT-Lösungen von Anbietern. Außerdem, so die Wahrnehmung des Workstreams, habe ein Anbieter immer eine Herkunft und einen Schwerpunkt. Deshalb brauche es eine neutrale, an den Anwenderbedürfnissen ausgerichteten RA, um kommerzielle Lösungen auch in ihrem Aufbau und ihrer Funktionalität beurteilen zu können.

Fünf Prinzipien der IoT-Referenzarchitektur

Da die Teilnehmer des Workstreams bereits vielfältige eigene Erfahrungen mit IoT-Lösungen und Plattformen gesammelt haben, wurden diese vor der Entwicklung der eigentlichen Referenzarchitektur zu fünf Prinzipien verdichtet, auf denen die RA aufbaut:

1. Unternehmensübergreifend für Ökosysteme: IoT-Lösungen machen nicht halt vor Unternehmensgrenzen. Deshalb ist die RA so aufgebaut worden, dass sie dank API-Management, Integration und Connectivity übergreifend in verschiedenen Ökosystemrollen funktioniert.

2. Anbindung an die Enterprise IT: IoT-Lösungen funktionieren nicht losgelöst von der "klassischen" Enterprise IT. Deshalb muss eine IoT-RA dieses Zusammenspiel berücksichtigen. Wichtig war den Teilnehmern der Arbeitsgruppe vor allem, die Weiterentwicklung der klassischen IT im Zuge der fortschreitenden Digitalisierung zu berücksichtigen. Da digitale Geschäftsmodelle bei weitem nicht allein über IoT-Lösungen abgewickelt werden können und sollten, sondern auch in der Enterprise IT, muss sich diese den neuen Anforderungen anpassen. Deshalb entwickelt sich die Architektur der klassischen IT ebenfalls weiter und sollte künftig auch Elemente der IoT-Architektur aufweisen.

3. Inkrementelle Umsetzung der RA: Die Teilnehmer wollten eine Referenzarchitektur schaffen, die sowohl die Elemente enthält, die für Pilotprojekte gebraucht werden als auch solche, die für unternehmensweite IoT-Vorhaben eine Rolle spielen.

4. Schlankheit: Die RA sollte ausschließlich Elemente enthalten, die wirklich für eine IoT-Lösung benötigt werden. Alles, was nur "nice to have" ist, sollte die RA in einem ersten Schritt außen vor lassen.

5. Wiederverwendbarkeit: Die realisierte Architektur auf Basis der RA soll mit wiederverwendbaren Elementen eine möglichst große Zahl von IoT-Anwendungsfällen auf der Unternehmens-Roadmap unterstützen.

Aus diesen Prinzipien haben die Workstream-Teilnehmer folgende Vorgaben für die praktische Arbeit mit der Referenzarchitektur formuliert:

Die Architektur steht auf drei Säulen

Die Architektur steht auf den drei vertikalen Säulen Edge-, Integration- und Enterprise Tier. In diese quasi eingehängt werden die säulen-übergreifenden Ebenen Infrastructure-Management, Monitoring und Engineering. Hinzu kommen ein Security Layer, ein API-Management, ein Third Party Ecosystem- und ein Netzwerk-Layer (siehe Grafik).

In der Edge-Säule befinden sich die digital erweiterten (zum Beispiel mit Sensoren und Aktoren ausgestatteten) physischen Dinge, ihr Monitoring, das sie betreffende Infrastruktur-Management sowie die entsprechende Connectivity, welche die Devices mit dem Integration Layer verbindet.

Im Integration Tier werden auf der einen Seite die Daten aufgenommen, konsolidiert und analysiert, die im Edge-Tier entstehen. Auch ein Digital-Twin-Abbild der realen Objekte kann hier gehalten werden oder eine KI-Anwendung finden. Gleichzeitig werden hier Steuerbefehle des Enterprise Tier verarbeitet und an das Edge weitergegeben. Außerdem werden hier Management-Aufgaben für die Devices und Daten erledigt. Eine zentrale Aufgabe des Integration Tiers ist die Entkopplung von Enterprise und Edge, auch um Lieferantenunabhängigkeit und Austauschbarkeit von Devices sicherzustellen.

Das Enterprise Tier beinhaltet domänenspezifische Applikationen und Services, die via Integration Tier die physikalische Ebene steuern. Das Enterprise Tier bietet außerdem Systeme zur Entscheidungsunterstützung sowie Interfaces für Nutzer und Betriebsspezialisten. Es ist die Anbindung der IoT-Welt an die betriebswirtschaftliche Welt des Unternehmens.

Im Prinzip eine einfache Matrixstruktur

Verbunden werden die Säulen durch die unterschiedlichen Connectivity-Einrichtungen wie das Proximity-Network, das die Edge-Devices mit der Integrationsschicht konnektiert, sowie weiteren Netzwerke, die auch die Verbindung zu Cloud-Services herstellen. Wichtig ist außerdem das 3rd Party Ecosystem, mit dem Services von Dritten, also anderen Providern oder Zulieferern von Daten und Infrastruktur, angebunden werden oder denen wiederum Daten und Services angeboten werden können.

Quer zu den drei Tiers liegen die Ebenen oder Tätigkeitsbereiche Engineering, Monitoring und Infrastruktur-Management. Wobei die beiden unteren Ebenen unabhängig möglichst von den jeweiligen Services und Geschäftsmodellen gestaltet werden sollen. Hier liegt eine starke Betonung auf Wiederverwendbarkeit. Die Engineering-Ebene dagegen ist service- und geschäftsmodellspezifisch. Aber selbst hier sollten eine Abbildung möglichst vieler IoT Use Cases und ein unternehmensweiter IoT-Einsatz das Ziel sein.

"Die Referenzarchitektur ist im Prinzip eine einfache Matrixstruktur, allerdings steckt der Teufel, wie immer, im Detail", erklärt Karsten Schweichhart, Vorstandsmitglied des CBA Lab. Er betont, wie wichtig Herstellerunabhängigkeit ist. "Alle Teilnehmer der Arbeitsgruppe legen Wert auf die Feststellung, dass es nicht ausreicht, die IoT-Plattform eines Herstellers zu implementieren. Jede Säule steht in Beziehung zu den anderen. Auch die Enterprise-Säule verändert sich durch die Anforderungen neuer IoT-Geschäftsmodelle."

Wenn beispielsweise ein Anbieter von Waschmaschinen seine Geräte so einrichtet, dass sie selbsttätig Waschmittel bestellen können, muss das ERP-System, das die Bestellungen verarbeitet und abrechnet, in der Lage sein, mit einer großen Menge kleiner Bestellmengen wirtschaftlich sinnvoll umzugehen. "Vorübergehend kann man zwar einen Workaround schaffen, aber da ein solches IoT-Geschäftsmodell in der Regel nicht das einzige ist, das implementiert wird, muss eine entsprechende Architektur aufgebaut werden, die mit solchen Anforderungen grundsätzlich umgehen kann", betont Schweichhart.

Das Beispiel Digital Twin

Wie eng die Beziehungen zwischen den verschiedenen Säulen sind, zeigt das Beispiel Digital Twin. Während im Edge Tier das physische Objekt mit Sensoren und Aktoren beheimatet ist, wird es im Integration Tier durch seinen Digital Twin repräsentiert, der wiederum Steuerbefehle aus dem Enterprise Tier erhält.

An einem Predictive-Maintenance-Beispiel lassen sich die Zusammenhänge nachvollziehen. Der Sensor in einer Fräse meldet eine ungewöhnlich hohe Drehzahl eines Fräskopfes. Der Kennwert wird im Integration Tier auf Basis des Verhaltens des Digital Twins analysiert. Daraus werden die Verschleißwerte des Fräskopfes errechnet und an das Enterprise Tier weitergeleitet. Hier wird aufgrund des Verhaltens die verbliebene Lebensdauer des Fräskopfes prognostiziert und ein Austausch zu einem bestimmten Zeitpunkt angestoßen.

Damit der Fräskopf garantiert noch bis zum angestrebten Austauschtermin hält, wird der Digital Twin instruiert, die Verarbeitungsgeschwindigkeit der Fräse zu reduzieren. Im Zuge der Synchronisation zwischen physischem Device und Twin erhält die Fräse die neuen Steuerinformationen.

Ausgangspunkt für die Realisierung einer IoT-Lösung ist das Geschäftsmodell, das unterstützt werden soll und die Frage, ob ein Unternehmen die Lösung von Ende bis Ende realisiert oder ob es Teil eines Ecosystems ist, das eine übergreifende Lösung anstrebt bzw. ermöglichen soll. IoT-Lösungen können oft beides sein, eine interne oder eine unternehmensübergreifende Lösung.

Beispielsweise kann der Anbieter eines Parkleitsystems selbst die Parkplätze mit Sensoren ausrüsten und ihre Belegung an eine von ihm entwickelte und betriebene App melden, die Endkunden bei der Parkplatzsuche nutzen oder er kann selbst nur einen Teil der Lösung realisieren, in dem er lediglich die Sensordaten zur Verfügung stellt. Da diese Geschäftsmodelle gerade in Ökosystemausprägungen sehr individuell sind, können sie in einer RA zwar als Ausganspunkt einer IoT-Lösung referenziert, aber in Ausprägungen nicht simuliert werden. Die RA muss deshalb in der Lage sein, viele verschiedene Geschäftsmodelle zu berücksichtigen.

Die Rolle bestimmt die Komplexität

Teil des Geschäftsmodells ist die Rolle, die ein Unternehmen in Bezug auf eine IoT-Lösung innerhalb eines Ökosystems anstrebt: Konsument, Teil- oder Full-Service-Provider. Diese Entscheidung hat klare Konsequenzen für die benötigte Architektur. Als reiner Konsument benötigt ein Unternehmen eine mehr oder weniger komplexe Schnittstelle/API, um die Daten in den eigenen Lösungen verarbeiten zu können. Soll aber ein eigener Service aufgebaut werden, müssen größere Teil der RA in den verschiedenen Säulen und Ebenen genutzt werden.

Noch komplexer wird es, wenn der IoT-Service komplett erstellt, anderen zur Verfügung gestellt und mit ihnen abgerechnet werden soll. Die Überlegung nach der Rolle klingt zunächst trivial, aber "es ist sehr schwierig, im laufenden Prozess zusätzliche Ressourcen und Gelder bereitzustellen, wenn die Verantwortlichen nicht schon am Anfang berücksichtigen, welche Kapazitäten und Fähigkeiten sie benötigen, um ihre Aufgabe als Provider eines Service zu erfüllen", erklärt Schweichhart vom Cross-Business-Architecture Lab.

Lessons Learned

• Es ist bei Auswahl einer IoT-Lösung wichtig, den gesamten Lebenszyklus der IoT-Lösung zu betrachten, also Entwicklung, Monitoring und Betrieb. Hier lassen sich insbesondere in den Bereichen Betrieb und Monitoring in der separaten Betrachtung signifikante Wiederverwendungen der IoT-Lösung über verschiedene IoT Use Cases realisieren

• Die IoT-Plattform schlank halten! Für die Wiederverwendbarkeit der Kern-IoT-Plattformfähigkeiten, z. B. im Analytics- und Machine-Learning-Bereich ist es wichtig, diesen Bereich der IoT-Lösung schlank zu halten. Hier sollte man sich nicht zu sehr von Fülle und Passgenauigkeiten der einzelnen Lösungen auf der Anbieterseite für genau einen IoT Use beeinflussen lassen und die Breite der möglichen eigenen Use Cases im Auge behalten.

• Die IoT-Lösung muss nicht nur an die existierende, klassische IT-Welt angeschlossen werden, sondern auch diese selbst transformiert sich zur Umsetzung von IoT-Szenarien. Auswahl und Aufbau von IoT-Lösungen müssen also diesen Fakt berücksichtigen.

• API-Management und die notwendige Entwicklung von technischen bis fachlichen Standards sind essentiell für das Zusammenarbeiten in unternehmensübergreifenden Ökosystemen.