News

15.03.2019

IoT-Referenzarchitektur des CBA Lab zeichnet sich durch Produktneutralität und Wiederverwendbarkeit aus

Das Cross-Business-Architecture Lab hat eine Referenzarchitektur (RA) für IoT-Lösungen entwickelt. Anders als die meisten RA im kommerziellen IoT-Umfeld gestalteten die in der CBA-Lab-Arbeitsgruppe IoT-Pattern and Architecture beteiligten Mitgliedsunternehmen ihre Referenzarchitektur von Anfang an produktneutral und in ihren einzelnen Elementen wiederverwendbar.

von Dr. Verena Schmidtmann*

Die RA soll den CBA-Lab-Mitgliedern 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.

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 5 Prinzipien verdichtet, auf denen die RA aufbaut:

• 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.
• 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.
• 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.
• 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.
• 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:

	Vorgabe	Erklärung
1.	Um eine möglichst hohe Wiederverwendbarkeit sicherzustellen, sollte sowohl in der Edge-Schicht als auch in der Integration-Schicht so wenig wie möglich spezifische Business-Logik oder vendor-spezifische Technologie einfließen.	Ohne festgelegte Business-Logik lassen sich die Devices und ihre Daten nahe der physikalischen Ebene mit Sensoren oder Aktoren für viele verschiedene Dinge einsetzen. Wenn die Mustererkennung in einem Geldauszahlungsautomaten allerdings nur Euro erkennt, kann der Automat nur für die Ausgabe von Euro verwendet werden.
2.	Im Bereich Monitoring und Infrastruktur sollte besonders großer Wert auf Wiederverwendbarkeit gelegt werden.	Monitoring oder Netzwerk sind IoT-Service agnostisch und sollten deshalb auch für alle Services funktionieren.
3.	Bei den Edge-Devices und Gateways sollten möglichst wenige Varianten zugelassen werden, ohne die Fähigkeit zu verlieren, neue Devices und Gateways adäquat einsetzen zu können.	Je größer der (unnötige) Variantenreichtum, desto komplexer geraten Schnittstellenmanagement, Betrieb und Monitoring.
4.	Streaming-Verarbeitung sollte gegenüber Batch-Betrieb der Vorrang gegeben werden.	Für sehr viele IoT Use Cases müssen Daten schnell transportiert und analysiert werden. Ideal ist dann eine Auswertung nahe Echtzeit, wie Streaming das erlaubt.
5.	Für alle Lösungsbereiche gilt Cloud First.	Das verbessert Skalierbarkeit, Sicherheit, Modularität, Interoperabilität, Integrierbarkeit und Widerstandsfähigkeit.
6.	Überall dort Standards einsetzen wo möglich und wo angebracht.	Standards machen Systeme tendenziell weniger komplex und bieten tendenziell mehr Unabhängigkeit von einzelnen Lieferanten.
7.	Offene APIs sollten gegenüber vordefinierten und spezialisierten Plattformen bevorzugt werden.	Spezialisierte Plattformen fördern den Vendor-Lock-in, APIs nicht. Professionelles API-Management macht die zusätzliche Komplexität beherrschbar.
8.	Vendor-Lock-in gilt es zu vermeiden.	Anwenderunternehmen mit ausreichend eigenem Know-how und eigenen Capabilities sollten zu starke Abhängigkeiten vermeiden, weil sie sonst gerade in Bezug auf neue Technologien und die Umsetzung neuer IoT Use Cases entscheidend gehemmt werden können.
9.	Daten als Vermögen und wertvollen Rohstoff betrachten.	Daten sind das Ausgangsmaterial für jedes IoT-basierte Geschäftsmodell. Sie sollten daher wie jeder andere wertvolle Rohstoff bewirtschaftet werden.
10.	Bandbreite muss optimal genutzt werden.	In der IoT-Welt ist Connectivity Trumpf. Hohe verfügbare Bandbreite bedeutet große Verarbeitungsgeschwindigkeit. Diese ist jedoch nicht immer notwendig. Oft sind andere Anforderungen entscheidender. Für die Kosten bspw. ist entscheidend, genau zu wissen, wann welcher Service wie viel Bandbreite benötigt.
11.	Es muss Security by Design gelten.	Gerade im IoT-Bereich, in dem sich physikalische Welt mit virtueller Welt verbindet, gelten zwar höchste Sicherheitsanforderungen, gleichzeitig lässt das Sicherheitsniveau gerade im physikalischen Bereich zu wünschen übrig. Diese Schwachstellen lassen sich nur einengen, wenn Security von Anfang an berücksichtigt wird. Die RA sieht hierzu diverse wichtige Funktionen vor.
12.	Software ist wichtiger als Hardware.	Im Zeitalter von Cloud, DevOps und Zero-Code-Entwicklungen eigentlich eine Binsenweisheit, aber wenn es um Priorisierung von Investitionsentscheidungen geht, gibt diese Einsicht Orientierung.

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 unten).

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.

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 Vorstandsmitglied Schweichhart.

 

 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.

*Dr. Verena Schmidtmann hat den Workstream IoT-Pattern/Architekturen des Cross-Business-Architecture Lab geleitet, in dem die Referenzarchitektur entstanden ist. Sie ist Partnerin in der IT- und Unternehmensberatung Detecon.

Zurück