IoT-Architekturen

Wenn wir das Thema gemeinsam genauer betrachten und unsere methodische Vorgehensweise auf Ihren Anwendungsfall anwenden, werden wichtige Zusammenhänge in der Systemarchitektur und deren konkrete Umsetzung ersichtlicher.

Ein Vorteil bei der Erstellung einer IoT-Architektur: es gibt eine große Auswahl unterschiedlicher IoT-Plattform-Anbieter und Referenzarchitekturen, die als Orientierungshilfe verwendet werden können. Die IoT-Anbieter geben dabei Empfehlungen oder Beispiele für die Architektur eines funktionierenden IoT-Systems auf Basis ihrer Plattform aus. Vor diesem Grund ist es wichtig, sich frühzeitig mit der Frage nach der Plattformauswahl zu beschäftigen.

Full-stack-Architektur.Quelle: eigene Darstellung

In Kombination mit der Auswahl bietet eine Beratung für Systemarchitekturen spezielle Metriken und Methoden an, die das Gesamtsystem betrachten. Dabei kann die Architekturberatung bis ins Detail das Domänenwissen und die Bedürfnisse der Nutzer in die Softwarebausteine betrachten. Dadurch soll die Architektur mit ihren Bausteinen zum Anwendungsfall passen und möglichst verständlich, effizient und zukunftsorientiert arbeiten.

Architektonische Rahmenbedingen

Falls vor der Architekturberatung eine Plattformauswahl durchgeführt wurde, können folgende architektonische Rahmenbedingen festgelegt worden sein:

• Lokale On-Premise-Lösung, die in der eigenen Firma oder nah an den Endgeräten auf eigener Computer- oder Server-Hardware läuft, ohne die Daten in eine Cloud übertragen zu müssen.
  • VPN-Verbindungen, die einzelnen, externen Computersystemen einen Fernzugriff oder Remote Control auf das lokale On-Premise-System ermöglicht.
  • Dezentrale Architekturen, deren Server über ein verschlüsseltes Netzwerk miteinander verbunden sind und als Fog Computing oder lokale Cloud bezeichnet werden kann.
• Hybrid-Cloud-System, das eine On-Premise-Installation mit einer Cloud-Plattform verbindet und entweder stärker auf die On-Premise-Seite oder die Cloud-Seite ausgerichtet ist.
  • Cloud-Bursting, bei der ein Großteil der zu verarbeitenden IoT-Daten in einem eigenen Rechenzentrum ausgeführt werden und ein Bruchteil der Rechenlast an eine Public Cloud gesendet wird, um Auslastungsspitzen des eigenen Rechenzentrums abzufedern.
  • Private & Public Cloud, bei der mehr Ressourcen in der Cloud verwendet werden als bei einer Cloud-Bursting-Herangehensweise und einige Anwendungsfälle nicht von der On-Premise Installation erfüllt werden – beispielsweise in Richtung neuer Technologien wie Machine Learning ohne eine hohe initiale Investition.
• Public-Cloud-IoT-Plattform, die alle Daten der Geräte verteilt, auswertet und verwaltet.
  • Monitoring-IoT-Plattform: IoT-Geräte werden ausschließlich vor Ort bedient, können aber ohne Steuerungsanwendungen nur fernüberwacht werden.
  • Pure-IoT-Plattform, deren IoT-Geräte aus der Plattform heraus überwacht und gesteuert werden können.
  • Edge-Cloud, bei der Teile aus der Cloud-IoT-Plattform direkt auf einem Edge-Gerät ausgeführt werden können.

Zusammenfassend lassen sich diese übergreifenden Topologien (On-Premise-, Hybrid-Cloud und Public-Cloud-IoT-Plattform) in einer allgemeinen IoT-Referenz-Architektur darstellen, die sinnvoll auf die Hardware-Komponenten in der Cloud oder On-Premise verteilt und skaliert werden müssen.

Als Einstieg lässt sich die allgemeine Architektur von generischen IoT-Systemen mit den dazugehörigen Plattformen betrachten. Unabhängig davon, ob On-Premise oder in Richtung Cloud – die digitalen Daten von Sensoren, Aktoren und smarten Produkten müssen über eine Art Gateway an eine Nachrichtenverteilung (Bus-System, Broker oder Hub) gesendet werden. Anschließend können sie an eine Rules-Engine oder an Steuerungs-Anwendungen übertragen werden, um von dort Nachrichten zurück an Aktoren und Smart Products zu senden.

Gleichzeitig kann die Rules-Engine stark mit einer Data Analytics Komponente verknüpft sein, die die Nachrichten mit zusätzlichen Informationen anreichert, oder die Daten direkt in möglicherweise mehreren Schichten von Datenbanken und Speichern ablegt. Die Datenanalyse kann mit Streaming-Daten direkt aus der Nachrichtenverteilung, oder mit historischen Daten aus Datenbanken und Datenspeichern arbeiten, die je nach Anwendungsfall auch mit maschinellem Lernen verknüpft werden können. Data Analytics und die Geschäftslogik profitieren und arbeiten häufig beide mit den gleichen Daten aus den Speichereinheiten bzw. Datenbanken und nutzen sie als Data-Lakes und Data-Warehouses. Verschiedene Anwendungen und Apps bieten ihren Nutzer mit Bedienelementen, die Informationen aus Speichersystemen und Analyse-Werkzeugen über eine Geschäftslogik bekommen. Sofern notwendig, können die Informationen im Geschäftslogik-Baustein für die Nutzer sinnvoll vorbereitet werden.

Diese Bausteine benötigen auf allgemeine oder detaillierte Weise eine Art von Geräteverwaltung, Benutzerverwaltung und IT-Sicherheitsüberwachung mit Logging und Distributed Tracing. Ähnlich wie bei der physischen Zugangskontrolle zu Firmengebäuden mittels Türen und Schlössern, muss geklärt werden, welche Person oder welches Gerät sich in welchem Zeitraum mit dem System verbinden darf und wie dieser Zugriff genau aussieht. Dafür sollten idealerweise alle Personen, Geräte und Komponenten im System identifizierbar sein und aktuell gehalten werden können. Eine Art von Identifizierungskonzept nutzen Sie höchstwahrscheinlich bereits heute schon in Ihrem Unternehmen (häufig in Verbindung mit einem ERP-System oder ähnlichem System) und deshalb muss das auch einem ein IoT-System auf Softwareseite bereitstellen können.

Hier steigen wir tiefer in den Anwendungsfall und dessen Anforderungen ein. Beim Verständnis der Anforderungen und beim Identifizieren einer passenden IoT-Architektur hilft jetzt die Architekturberatung. Sie beleuchtet Ihren spezifischen Anwendungsfall mit Sicht auf die IoT-Architektur.

• Endbenutzer: Logische Sicht (auf Funktionalität)
• Systemingenieur: Verteilungssicht (Topologie, Bausteine, On-Premise/Private & Public Cloud mit Fog und Edge-Computing)
• Systemintegrator: Prozesssicht (Performance, Skalierbarkeit, Durchsatz)
• Programmierer: Implementierungssicht (Software Management)

Die Sichtweisen auf eine Architektur.Quelle: eigene Darstellung

Von Beginn an (mit der Architektur) auf dem richtigen Weg bleiben, die richtigen Fragen stellen und eine Architektur finden, die zum Anwendungsfall passt.

Qualitätsanforderungen und Qualitäts-Iterative und agile Architektur-Ansatz am Twin-Peak-Modell

Beim Twin-Peak-Modell wird eine Architektur aus verschiedenen Sichten konzipiert und mit UML modelliert. Dies wird mit De-Facto-Standards und Best-Practises aus Erfahrungswerten zu einer zielgruppen-orientierte Architektur-Dokumentation verknüpft.

Das Twin-Peak-Modell.Quelle: eigene Darstellung

In Verbindung mit dem Twin-Peak-Modell wird außerdem von unseren Experten Rücksicht auf die Fachsprache und das Domänenwissen in Ihrer Firma genommen (sog. Domain-Driven-Design).

Dabei wird die bestehende Fachsprache aufgegriffen, konkretisiert und/oder eine eigene Fachsprache definiert. Das alles wird in Verbindung mit den Fachexperten, Softwareentwicklern und mit methodischer Unterstützung durchgeführt. Als Resultat daraus wird dieses Wissen methodisch in Softwaresysteme/Microservices und ein Anwendungsdesign überführt.

Schnittstellen in der Architektur sind ein erfolgsentscheidender Faktor, weshalb wir diesem Thema anhand von Best-Practises besondere Aufmerksamkeit widmen. Dafür haben wir Expertise im API-first-Ansatz, API as a Product und in speziellen Werkzeugen für das API Management.

Industrie 4.0

Außerdem betrachten wir Querschnittsfunktionen wie die für die Qualitätsmerkmale Sicherheit, Stabilität, Verfügbarkeit, Performanz, Zuverlässigkeit und Nachvollziehbarkeit. Hier bieten wir ein breites Spektrum an Erfahrungen in verschiedenen Lösungsansätzen für z. B. Distributed Tracing und Application Monitoring. Falls gleichzeitig mit der IoT-Architektur auch der Schritt in Richtung Industrie 4.0, datenbasierte Kommunikation zwischen mehreren Industrie-orientieren Firmen und Interoperabilität gehen soll, erweist sich ein Blick auf die Open Industry 4.0 Alliance als wertvoll.

Die Referenzarchitektur der Open Industry 4.0 Alliance bietet Empfehlungen für Datenmodelle und Schnittstellen, damit auf 4 Schichten unterschiedliche Informationen sinnvoll verwaltet, verteilt, aufbereitet und zur Verfügung gestellt werden können. Mit dem Konzept der 4 Schichten wird eine Architektur aufgebaut, die auf spezifisches Domänenwissen der Experten im Shop Floor und in der Cloud eingeht.

• Die Schichten 1 und 2 verbinden die heterogene Welt an Maschinen, Steuerungen und Verkabelungen über ein klar definiertes Open Edge Application Layer mit der Cloud und stellen den Mitarbeitern auf ihrer Schicht im Shop Floor tiefe Einblicke und Funktionen zur Verfügung. Die Cloud stellt auf ihrer Seite ebenfalls 2 Schichten bereit.
• In Schicht 3 erhalten Operatoren alle notwendigen Werkzeuge und Anwendungen, um eine Übersicht vom Shop Floor zu erhalten und diesen aus Unternehmenssicht auf technischer Ebene zu verwalten.
• Die 4. Schicht speichert die aufbereiteten Informationen aus der Open-Operator-Cloud und den darunterliegenden Schichten und verbindet sogenannte Stammdaten (Master Data) einer Maschine/Gerätes mit Dienstleistungen in einem Marktplatz und einer, aus unternehmerischer Sicht, freischaltbare Open-API-Schnittstelle. Das Gegenstück zu dieser Common-Cloud-Central-Schicht bildet eine Manufacturer-Cloud, wie die eines Sensorherstellers, Maschinenbauunternehmens oder anderer Firmen, die über den Marketplace angeboten werden und für die Open API eigenständig freigeschalten werden können.

So entsteht eine digitale Dienstleistungsplattform, die Dank einheitlicher Konnektivität und Operabilität ,die Unterstützung von allen Mitgliedern der Alliance sicherstellt.

The Open Industry 4.0 Alliance technical architecture – a holistic IIoT framework.Quelle: © Open Industry 4.0 Allience, Konzept

Die Open Industry 4.0 Alliance definiert im Zusammenhang mit der Industrie 4.0 keine neue Spezifizierung, sondern vereint aus den gesammelten Erfahrungen in der Industrie und in den Gremien wie die von OPC-UA oder anderer industrieorientierter Fokusgruppen, diese zu einer nutzenorientierten, erprobten und einheitlichen Richtlinie.

Von uns können Sie eine pragmatische Qualitätsbrille erwarten, die mit methodischem Know-How und zukunftsorientierter Systementwicklung im Industrie-4.0-Charakter modernen Architekturen und Technologien entspricht. Dabei ist Nachhaltigkeit bei der Technologieauswahl und Architektur eine unserer treibenden Kräfte.

Wir beraten zu Architekturen mit jahrzehntelanger Erfahrung sowie technologischem und methodischem Feingefühl für Ihre Domäne und Ihre Anforderungen. Eine agile Architekturberatung gibt Ihnen die Möglichkeit, alle Stakeholder miteinzubeziehen und mit einer passenden Technologie- und Plattformauswahl zu verbinden. Prägnante Visualisierungen der verschiedenen Sichtweisen auf die Architektur, die das Verständnis verbessern und eine zielgerichtete, agile Entwicklung des IoT-Systems nach dem Twin-Peak-Modell erleichtern, bei der die Dokumentation fast von selbst entsteht.

Auf den Punkt gebracht (Auswahl):

• Architekturelle Begleitung Ihrer Digitalisierungsvorhaben.
• Einbeziehung aller Stakeholder, Anforderungen und Visionen.
• Erstellung sämtlicher Artefakte, die Sie für Ihre Entscheidungen benötigen.

Architekturen gibt es in vielen Bereichen

• Enterprise Architecture Management
• Architecture & Cloud
• Augmented Reality & Virtual Reality

Lassen Sie sich von diesen vielfältigen Themen inspirieren und erwarten Sie von uns eine ganzheitliche Beratung!