Im ersten Teil wurde ein IoT On-Premise-Szenario für IoT und eine vom Aufbau her ähnliche einfache Cloudlösung skizziert. Ausgangspunkt aller hier vorgestellten Szenarien ist dabei der Einsatz des von Datagroup Ulm entwickelten IoT Connectors. Bei dem einfachen Cloud-Szenario aus dem ersten Teil lief der IoT Connector in Docker-Containern innerhalb einer Virtual Machine (VM), die als Infrastructure as a Service (IaaS) in einer Cloudumgebung vorgehalten wurde. Die nun folgenden Varianten zeigen den Einsatz des IoT Connectors in Azure, wobei verschiedene Platform as a Service(PaaS)-Ressourcen verwendet werden.
Mehr Azure-Ressourcen nutzen
Das dritte Szenario einer erweiterten Cloudanbindung empfiehlt sich eher für IoT- und clouderfahrene Unternehmen oder solche, die durch externe Experten unterstützt werden. Denn hier bindet sich das Unternehmen stärker an eine Cloudlösung und einen Cloud Provider. Dieses Szenario bietet allerdings leistungsfähigere Funktionalitäten und Vorteile gegenüber einfachen Cloudszenarios. Kern der Architektur ist weiterhin der IoT Connector, der in diesem Beispiel durch einen AppService gekapselt wird. Die bisher containerbasierten Komponenten – Datenbank, In-Memory-Cache und Datenspeicher – werden nun von Azure als PaaS-Ressourcen bereitgestellt, ebenso die VM für den MQTT-Server (IaaS), der die Übertragung der Telemetriedaten ermöglicht – natürlich wird alternativ auch OPC-UA als Standard unterstützt. Im Zuge einer Smart-Factory-Potenzialanalyse für ihren Kunden KSB identifizierte die Managementberatung NEONEX Opti mierungschancen bei der Beschaffung der Lieferantendokumentation sowie der Erstellung von Unterlagen zur Qualitätsprüfung entlang der Supply-Chain. ‣ weiterlesen
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
NEONEX, Fabasoft Approve & KSB: „Win-win-win-Situation“ durch starke Partnerschaft
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
VM ohne Administrator
Dieses Vorgehen hat einige Vorteile. Anders als beim einfachen Cloudszenario ist keine Adminstration der VM nötig, wenn der MQTT-Server außerhalb von Azure läuft. Läuft er hingegen auf Azure, ist eine Administration der VM nötig, allerdings wesentlich weniger als im vorherigen Szenario, da Datenbank, Storage und Cache PaaS-Dienste sind. Da die Datenbanken, der Cache und so weiter von Azure bereitgestellt werden, ist die Software zudem stets auf dem aktuellen Stand etwa bezüglich Betriebssystem und Virenscanner. Überwacht wird das System ebenfalls über Azure. Durch die Cloudplattform ist die Erreichbarkeit der Ressourcen sichergestellt. Weitere Azure-Ressourcen lassen sich so später leichter integrieren und einzelne Dienste leichter skalieren.
Nah an der Referenzarchitektur
Das vorherige Szenario kann seine strukturelle Nähe zum einfachen Cloudszenario nicht verleugnen. Von der Referenzarchitektur von Azure für IoT-Lösungen ist es aber noch ein gutes Stück entfernt. Dem nähert sich das nun folgende Szenario. Der Azure IoT-Hub wird hier als Tor für die Telemetriedaten genutzt, die von den Maschinen in die Cloud gesendet werden, Ingress. Das und die Verwendung von Stream Analytics verbessert die Skalierbarkeit der Lösung. Die Maschinendaten werden ohne Verarbeitung durch den IoT Connector in einer Azure-Datenbank abgelegt – allerdings werden diese in der Regel durch Azure oder Azure-Ressourcen vorverarbeitet. Um die Daten etwa durch Machine Learning weiterverarbeiten zu können, werden die Rohdaten in der Cloud abgelegt. Externe Schnittstellen lassen sich über Logic-Apps anbinden, wobei deren Verwendung und Integration stark vom jeweiligen Unternehmenssystem abhängt. Die Geräteverwaltung sowie die Visualisierung der Messwerte finden weiterhin im IoT Connector statt. Das Alarming, etwa bei einer Schwellwert-Überschreitung, erfolgt jedoch über Azure Functions.
