SSV Software Systems
Bauplan für IoT-Anwendungen
Industrielle IoT-Applikationen sollen sich möglichst schnell amortisieren, anderseits aber auch für einen langen Produktlebenszyklus ausgelegt sein. Aus Entwicklersicht hilft bei diesem Technologie-Spagat ein guter Plan, ein modulares Konzept und wiederverwendbare Komponenten.
Die Anwendungsentwicklung im Internet der Dinge wird zu einer immer größeren Herausforderung. Ein nahezu unüberschaubares Angebot unterschiedlicher Technologiebausteine plus ein globales Wettbewerbsumfeld, das es in dieser Intensität in der Informationstechnik nie zuvor gegeben hat, sowie sich abzeichnende Gesetzesinitiativen zur Cybersicherheit wie etwa der EU Cyber Resilience Act sind das eine. Mehrdimensionale Kostenaspekte, eine möglichst schnelle Markteinführung neuer Produkte und Lösungen, unsichere globale Hardware-Baustein-Lieferketten sowie der Fachkräftemangel für Entwicklung, Installation und Service sind weitere Einflussgrößen. Alles in allem sind IoT-Lösungsentwickler gut beraten, sich so etwas wie einen Bauplan mit wiederverwendbaren Funktionskomponenten zu schaffen. Allgemeingültige Standards für alle IoT-Anwendungskategorien existieren allerdings nicht. Insofern ist Eigeninitiative erforderlich.
Am Datenfluss orientieren
Bauplan für IoT-Anwendungen
Viele IoT-Anwendungen sind ursprünglich aus einem Proof of Concept (PoC) entstanden und wurden solange verändert, bis ein gewisser Grad an Praxistauglichkeit und Anwendernutzen existierte. In diesem Zustand werden sie nun genutzt und auf Grund veränderter Kundenanforderungen ständig weiterentwickelt. Die Folge dieser Vorgehensweise ist vielfach eine relativ schlechte Dokumentation der Gesamtzusammenhänge. Das hat nicht nur negative Auswirkungen auf die Zuverlässigkeit und Wartung einer Anwendung, sondern auch auf die Betriebssicherheit und die Wettbewerbsfähigkeit des Anwendungsanbieters. Insofern sollten sich professionelle IoT-Entwickler jeweils einen Standard-Bauplan für die eigenen Anwendungen schaffen. Damit lässt sich eine Lernkurve mit Erfahrungswerten und darauf aufbauende Sicherheitskonzepte zu den einzelnen Bausteinen realisieren und über den gesamten Anwendungslebenszyklus weiterentwickeln.
In Bild 1 zeigt der linke Teil ein Beispiel, das sich am Daten- und Informationsfluss orientiert. Die gesamte IoT-Anwendung ist modular als End-to-End-Lösung dargestellt. Links unten ist ein Device-Endpunkt (IoT Device), rechts der Web Client eines menschlichen Nutzers (User) oder eine IT-Anwendung zu finden. Zwischen diesen beiden sicherheitskritischen Punkten sind Authentizität, Datenintegrität sowie eine kontextbezogene Vertraulichkeit erforderlich. Hier eine kurze Übersicht der wiederverwendbaren Einzelbausteine:
- IoT Device: Sensoren, die Daten erfassen und Aktoren, die Aktionen ausführen (Ventil schließen oder öffnen).
- Device Hub: Kommunikations- und datentechnisch der Knotenpunkt für die Verbindungen zu den einzelnen Sensoren und Aktoren.
- Device Logic: Laufzeitumgebung mit Softwarefunktionen, um den Datenfluss zwischen den Sensoren und Aktoren sowie übergeordneten Datenbankfunktionen zu ermöglichen.
- Database: Sammelbegriff für die Speicherfunktionen einer IoT-Applikation. Implementierungsdetails der Datenbankfunktionen werden individuelle bestimmt.
- Business Logic: Laufzeitumgebung mit Softwarefunktionen, um den Datenfluss zwischen den externen Nutzern und Anwendungen sowie den Datenbankfunktionen einer IoT-Anwendung zu ermöglichen.
- Web Server: Kommunikations- und datentechnischer Knotenpunkt für die Verbindungen zu den externen Nutzern und weiteren Anwendungen.
- Web Client: Benutzer und Anwendungen, die sich einer bestimmten IoT-Anwendung zuordnen lassen. Sie sind in der Regel die Datenkonsumenten, vielfach auch Datenquellen.
Ein einfaches Praxisbeispiel
Im rechten Teil von Bild 1 werden die zuvor beschrieben IoT-Anwendungsbausteine auf eine industrielle IoT-Condition-Monitoring-Anwendung übertragen. Als IoT Device dient eine Steuerung (SPS) plus Gateway, um veränderte SPS-Zustandsdaten an einen MQTT Broker (Device Hub) zu übertragen. Beim Eintreffen neuer Zustandsdaten erzeugt der Broker ein Ereignis (Event). Dadurch wird jeweils ein Device-Logic-Prozess gestartet. Dieser übernimmt die MQTT-Daten vom Broker, wandelt sie in das von der Anwendung benötigte Format um und speichert ein neues Datenobjekt in der Anwendungsdatenbank (ADB, die Database dieses Beispiels).
Die rechtsseitige Datenbankschnittstelle ermöglicht externen Nutzern und IT-Anwendungen Zugriff auf die Condition-Monitoring-Daten. Menschliche User können per Webbrowser, Anwendungen z. B. per REST-API auf die jeweiligen Daten zugreifen. Neben diesen typischen Web Clients wären auch OPC UA-basierte Datenzugriffe realisierbar. Jeder externe Web-Server-Zugriff erzeugt einen Ereignis-Trigger für die Business Logic der IoT-Applikation, um bestimmte Aktionen auszuführen. Dieser Anwendungsteil lässt sich in der Praxis beispielsweise per WSGI (Web Server Gateway Interface) realisieren. Er sorgt dafür, dass eine Web-Client-Anfrage über ADB-Zugriffe mit entsprechend aufbereiteten Daten versorgt wird. Für einen Benutzerzugriff werden diese Daten dynamisch in eine Webseite eingebaut. Die REST-basierte Anfrage einer anderen Anwendung wird vom WSGI-Prozess beispielsweise mit einem JSON-Objekt beantwortet, in dem dann die benötigten Daten enthalten sind.
Den Datenfluss dokumentieren
Zu jeder professionellen IoT-Anwendung gehört auch ein Datenflussdiagramm (DFD), aus dem die externen Entitäten, Prozesse, Datenspeicherfunktionen, Daten- und Informationsflüsse sowie Vertrauensgrenzen hervorgehen. Für die DFD-Erstellung existieren verschiedene Symbole und Notationen. Entitäten werden durch Rechtecke, Prozesse mittels Kreisen und Speicherfunktionen durch zwei waagerechte Linien, die parallel verlaufen, dargestellt. Im Inneren dieser Symbole ist jeweils eine Beschriftung zu finden. Der Datenfluss ist durch Pfeile gekennzeichnet. Zur Darstellung der Vertrauensgrenzen werden strichpunktierte Linien verwendet. Bild 2 zeigt das DFD für die zuvor beschriebene Condition-Monitoring-Beispielanwendung. Es wurde nach allgemeingültigen DFD-Regeln erstellt:
- Jeder einzelne Prozess sollte mindestens einen Eingang und einen Ausgang besitzen.
- Ein Datenspeichersystem muss einen eingehenden und einen ausgehenden Datenfluss haben. In einigen Anwendungsfällen wird der eingehende Datenpfad aus Vereinfachungsgründen weggelassen (z. B. ein Speichersystem für statische Webseiten; das Einspeichern der Webseiten in eine Datenbank wäre eine Teilanwendung mit eigenem DFD).
- Daten, die in einer Datenbank gespeichert werden, müssen mindestens einen Prozess durchlaufen.
- Alle Prozesse eines DFD besitzen einen Datenfluss zu einem anderen Prozess, Datenspeicher oder einer Entität.
- Daten, die in einem System gespeichert werden, müssen immer einen Prozess durchlaufen.
- Nur Prozesse verändern Daten, ein Datenspeichersystem hingegen nicht.
In ein DFD lassen sich auch die jeweiligen Kommunikationsprotokolle eintragen, die zwischen Entitäten und Prozessen zur Datenübertragung genutzt werden. Des Weiteren sollten im DFD die Vertrauensgrenzen markiert sein, um im Rahmen einer Bedrohungsanalyse für die erforderliche Cybersecurity zu sorgen. Wird das DFD am Anfang einer IoT-Lösungsentwicklung erstellt, ist ein Security by Design möglich.
Digitaler Zwilling als Erweiterung
Eine zentrale Datenbank mit einem IoT-Interface auf der einen und einer Web-Client-Schnittstelle auf der anderen Seite bietet des Weiteren ein ideales Umfeld zur Implementierung digitaler Zwillinge. Dafür sind zusätzliche Datenspeichermöglichkeiten erforderlich, zum Beispiel für die Konstruktions- und Konfigurationsdaten einer Maschine beziehungsweise Anlage. Im nächsten Beitrag der Serie ‚Digital Twin‘ geht der Autor auf die Aspekte ein.
Das könnte Sie auch interessieren
IoT-Welt
Siemens kooperiert mit Hilscher
Advertorial
Skalierbare Integration von Maschinendaten in…
Grossenbacher
IoT-Gateways nach Maß statt von der Stange
Verwandte Artikel
SSV Software Systems GmbH
Mit Fokus: Nachhaltigkeit
Das E-Paper der Ausgabe 01/02
SSV Software Systems
Das virtuelle Edge-Gateway
Mitmachen und gewinnen
Produkte des Jahres 2023 – Ihre Stimme zählt!
SPS
ifm
Cloudbasierte Maschinendiagnose im Fokus
iC-Haus
Veränderungen in der Geschäftsführung
