„DevOps ist die Vereinigung von Menschen, Prozessen und Produkten um einen kontinuierlichen Mehrwert an den Endnutzer zu liefern“ [Bro15]. Dieses Zitat stammt von Donovan Brown, der als Principal DevOps Manager für Microsoft das Thema DevOps sehr gut auf den Punkt bringt. Denn das große Ziel von DevOps ist es, dem Endnutzer einen kontinuierlichen Mehrwert zu liefern. DevOps besteht dabei aus verschiedenen Aspekten, die bessere Kollaboration zwischen Dev und Ops fördern. Die Kollaboration findet im gesamten Entwicklungsprozess statt (siehe Abbildung 1) und wird geprägt durch Continuous Integration und Continuous Feedback.
Bei Continuous Integration geht es darum, mit einer voll automatisierten Pipeline ohne manuelle Aufwände den Code von Entwicklern direkt in Systeme auszuliefern. Continuous Feedback kümmert sich um den Rückfluss der Daten, sodass zu Funktionalität auch Business Value abgeleitet und auch der Zustand der Anwendung überwacht werden kann.
Viele Aspekte können auch in IoT-Projekten angewendet werden, was im Laufe des Artikels näher betrachtet werden soll.
Abb. 1: Der DevOps-Zyklus [Quelle: https://docs.microsoft.com/en-us/azure/devops/learn/what-is-devops]
Was ist IoT?
IoT steht für Internet of Things und beschreibt die Kommunikation und Vernetzung von „intelligenten“ Geräten wie Sensoren nicht nur untereinander, sondern auch nach außen über das Internet [GRLIoT].
Die Zielgruppen für IoT lassen sich dabei auftrennen in Verbraucher und Industrie. Für Verbraucher gibt es IoT-Szenarien wie Home Automation, E-Health oder Smart Automotives. Wer heute seine Beleuchtung oder Heizung zuhause über sein Smartphone steuert, ist bereits mitten im IoT. Für die Industrie gibt es das sogenannte Industrial Internet of Things. Dies beschäftigt sich mit der Anbindung und Vernetzung von Maschinen über das Internet. Obwohl hier zwischen zwei Zielgruppen unterschieden wird, können beide Bereiche voneinander profitieren, denn die Konzepte dahinter sind meist die gleichen.
Im Folgenden wollen wir uns mit IoT im industriellen Umfeld beschäftigen, dem sogenannten IIoT (Industrial Internet of Things). Im Gegensatz zu Machine-to-Machine-Communication (M2M) geht die Kommunikation bei IIoT über Systemgrenzen hinweg. Das bedeutet, dass Maschinen nicht mehr nur im Maschinennetzwerk miteinander vernetzt sind, sondern über das Internet auch über die Grenzen der eigenen Infrastruktur hinweg. Diese Anbindung an das Internet wird dann meist mit Anbindung an die Cloud oder an bestimmte cloudbasierte Dienste gleichgesetzt.
Der Vorteil der Cloud: Die großen Cloudanbieter wie Microsoft, Google oder Amazon unterstützen ihre Kunden alle im Bereich IoT, um eine Anbindung und Vernetzung mit so wenig Aufwand wie möglich durchzuführen. Hier gibt es nicht nur fertige IoT-Plattformen, die einfach eingekauft und genutzt werden können. IoT besteht aus vielen kleinen Diensten, wie für die Kommunikation mit Geräten, die auch über Cloudanbieter eingekauft und somit nicht selbst entwickelt werden müssen.
Meist wird im gleichen Zuge zu IIoT noch von Industrie 4.0 gesprochen. Diese beschäftigt sich mit der intelligenten Vernetzung von Maschinen und Abläufen. Das IIoT ist dabei ein Hilfsmittel, um die Industrie 4.0 zu erreichen.
Unser Szenario
Um die Anwendungsfälle im IIoT etwas greifbarer zu machen, wollen wir anhand eines Beispiels (siehe Abbildung 2) zeigen, wie Maschinen an das Internet angebunden und miteinander vernetzt werden können.
Abb. 2: Vernetzung von Maschinen ins Internet [Quelle: Eigene Darstellung]
Dazu nutzen wir eine mit Fischertechnik gebaute Taktstraße [FischerT]. Diese besteht aus einem Förderband, über welches Teile befördert und an einer Bohr- und Frässtation bearbeitet werden. Über eine Siemens S7-Steuerung [Simatic] wird die Taktstraße gesteuert. Die Steuerung kommt mit einem integrierten OPC-UA-Server, über den sowohl Daten wie die Durchlaufzeit von Teilen ausgelesen als auch Daten wie die aktuelle Bohrzeit gesetzt werden können. OPC UA steht für Open Platform Communications Unified Architecture [OPCUA] und beschreibt ein Protokoll für den Austausch zwischen Maschinen. Durch die Anbindung über OPC UA bekommt das Szenario eine entsprechende Abstraktion, denn dadurch kann auch jede beliebige Maschine, die OPC-UA-fähig ist, damit angebunden und vernetzt werden.
Im nächsten Schritt müssen die Daten vom OPC-UA-Server in die Cloud übertragen werden. Dazu könnten auf jeder Steuerung die Daten direkt verschickt werden. Hier ergibt sich jedoch das Problem, dass auf einmal jede Maschinensteuerung auch an das Internet angebunden sein muss. Aus Gründen der Sicherheit ist das jedoch meist nicht gewünscht. Denn dadurch müsste jede Steuerung auch immer mit den neusten Updates ausgestattet werden, um keine Sicherheitslücke zu haben. Ein weiteres Problem mit diesem Ansatz ist, dass Daten im Rohformat übertragen werden. Unter Umständen ist es aber sinnvoll, die Daten erst einmal zu filtern, zu aggregieren und auch mit anderen Daten anzureichern.
Dieses Vorgehen ist keine neue Erfindung und im Bereich Data Warehousing bereits unter Extract, Transform, and Load (ETL) [MS_ETL] bekannt. Dabei werden Daten erst einmal aus unterschiedlichen Quellen zusammengeführt (Extract), um diese dann zu transformieren (Transform) und letztendlich in die Zielumgebung zu laden (Load). Darüber hinaus gibt es noch viele Fragen, die es zu beantworten gilt, um wirklich von IIoT im eigenen Anlagenpark zu sprechen. So ist beispielsweise zu klären, was passiert, wenn es keine Internetverbindung mehr gibt? Gehen die zu sendenden Daten dann verloren? Wie kann zwischen Daten unterschieden werden, die der Anlagenbetreiber zur Überwachung der Anlage nutzen möchte, und denen, die der Maschinenbauer gerne zur Optimierung der Wartung hätte (Predictive Maintenance)?
Was ist Edge-Computing?
Vor diesem Hintergrund kommt nun Edge-Computing zum Einsatz. Am Rand des Maschinennetzwerks (Edge) werden die oben genannten Fragen durch den Einsatz eines Gateways, welches in diesem Zusammenhang gern als IoT-Edge-Gateway bezeichnet wird, beantwortet. Dabei handelt es sich um einen Computer, welcher je nach Bedarf von einem Router über einem Raspberry Pi bis hin zu einem Industrie-PC alles sein kann. All die genannten Vertreter haben eines gemeinsam: Die eigentliche Logik zum Lösen der vorher genannten Aufgabenstellungen ist in Softwaremodulen abgebildet. Diese kommunizieren wie eingangs schon beschrieben nach innen ins Maschinennetzwerk, zum Beispiel über Standards wie OPC UA, und nach außen ins Internet, beispielsweise über HTTPS oder MQTT [MS_MQTT].
Die Ausstattung, Pflege und Weiterentwicklung dieser Edge-Devices ist jedoch sehr ähnlich zu anderen Plattformen, auf denen Softwarelösungen bereitgestellt werden. So stellt sich zunächst die Frage der initialen Konfiguration (Provisionierung), wenn ein solches Edge-Gateway beim Anlagenbetreiber in Betrieb genommen wird. Dieses Thema adressieren wir in unserem Szenario über einen Device Provisioning Service [MS_DPS] im Cloud-Backend. Darüber hinaus muss es auch möglich sein, die Edge-Gateways zu aktualisieren und neue Softwaremodule bereitzustellen. Die Anforderungen gehen bis hin zur Aktualisierung des Betriebssystems oder der Firmware der Gateways. Es muss also möglich sein, dass das Entwicklungsteam Updates bereitstellt und diese auf den Gateways, ohne große manuelle Schritte, installiert werden. Denn nur so lassen sich kurze Update-Zyklen ermöglichen, die wiederum wichtig sind, um schnelles Feedback zu einer Funktionalität zu erhalten. Wir setzen dafür auf eine CI/CD-Pipeline, die später im Artikel noch näher erklärt ist.
Das Thema Feedback bringt uns auf einen weiteren wesentlichen Aspekt, wenn wir über DevOps in IoT-Projekten sprechen. Der Einsatz der Softwaremodule auf dem Edge-Gateway darf keine Einbahnstraße sein. Nur durch Zugriff auf Monitoring-Daten der Gateways ist es möglich, frühzeitig Fehlverhalten oder zumindest ungewünschte Szenarien zu entdecken. Was im Bereich moderner Webanwendungen völlig normal ist, nämlich der Einsatz von Applikationstelemetrie wie durch Application Insights [MS_AI], ist auch hier unverzichtbar, wie weiter unten noch im Abschnitt „Continuous Feedback“ näher beschrieben wird.
Im Folgenden berichten wir aus unserer eigenen Entwicklungserfahrung in IoT-Projekten am Beispiel der Intelligent Factory [AIT]. Einige der angesprochenen Herausforderungen wie die Provisionierung, das Remote Update sowie das Monitoring der Edge-Gateways haben wir dort bereits adressiert.
Dev vs. Ops und IT vs. OT
Vergleicht man die Probleme, die DevOps zu lösen versucht, mit denen, die in einem IoT-Projekt auftreten können, so erkennt man gewisse Parallelen. In DevOps geht es unter anderem darum, die Mauer zwischen Entwicklung (Dev) und Betrieb (Ops) einzureißen. Entwickler sollen nicht nur für die Programmierung der Anwendungen verantwortlich sein, sondern auch deren Betrieb sicherstellen. Dabei geht es in aller erster Linie darum, das Mindset eines Entwicklungsteams zu ändern, sodass auch der Betrieb der Applikation von Anfang an im Fokus steht. Sind Entwickler innerhalb eines IoT-Projekts nun auch verantwortlich für den Betrieb, so müssen diese auch sicherstellen, dass die Hardware funktioniert. Des Weiteren sind IIoT-Lösungen nah an produktionsnahen Steuerungen angesiedelt und kommunizieren gegebenenfalls sogar mit ihnen. Es werden also weitere Kompetenzen im Projektteam benötigt.
So wie in traditioneller Abteilungsstruktur Entwicklung und Betrieb getrennt waren, ist die Operational Technology (OT) getrennt von der Information Technology (IT). Abbildung 3 zeigt die verschiedenen Ebenen eines Fertigungsunternehmens, die aufeinander aufbauen, und die Zuordnung der jeweiligen Ebene zu den Bereichen IT und OT.
Abb. 3: OT vs. IT im IoT-Umfeld [Quelle: Eigene Darstellung und [Hub19]]
Dabei übernimmt die IT die oberen Ebenen, bei denen es um Speichern, Verarbeiten und Analysieren von Daten sowie die Bereitstellung von Business-Anwendungen wie Enterprise Resource Planning (ERP) und Product Lifecycle Management (PLM) geht. Die OT ist zuständig von der Steuerung operativer Abläufe von Systemen im Bereich der Produktionsplanung und -steuerung bis hin zur Steuerung, Überwachung und Kontrolle von Maschinen und Anlagen. Die Kommunikation der jeweiligen Systeme verläuft immer zwischen den einzelnen Ebenen. Deshalb kann ein Sensor auch nicht direkt mit dem Internet kommunizieren, sondern gibt seine Daten an die Maschine weiter.
Gemäß der Definition fällt Edge-Computing mit der Auswertung und Interpretation maschinennaher Daten in den Bereich der OT (vgl. [Hub19]). Da die Software und Speichersysteme jedoch von der Information Technology (IT) kommen und auch diese die Kommunikation in Richtung Internet verwaltet, wird deutlich, dass IT und OT näher zusammenwachsen und miteinander reden müssen.
Dadurch ergeben sich neue Herausforderungen für das Entwicklungsteam. Neben dem Know-how zu Software und der Domäne muss sich das Kompetenzfeld des Entwicklungsteams erweitern. Zunächst einmal spielen in dem Umfeld die Themen Safety und Security eine wichtige Rolle. Darüber hinaus ist auch noch Wissen von Hardware über industrielle Kommunikationsstandards bis hin zu Verständnis zu Produktionsabläufen erforderlich.
Wie lassen sich nun DevOps-Praktiken und -Prinzipien in IoT-Projekten anwenden? Im Folgenden wollen wir uns Schritt für Schritt am Entwicklungsprozess entlanghangeln. Dabei gehen wir speziell darauf ein, wie ein hochgradig automatisierter Auslieferungsprozess umgesetzt werden kann. Außerdem berichten wir, mit welchen technischen Möglichkeiten kontinuierlich Feedback eingesammelt sowie der Gesundheitszustand von den Edge-Gateways geprüft werden kann. Dies dient dazu, den Betrieb der Devices sicherzustellen und wertvolle Erkenntnisse für die nächste Iteration in der Entwicklung zu liefern.
Continuous Integration
Das Konzept von Continuous Integration beschreibt den automatisierten Prozess vom Kompilieren und Testen des Quellcodes, sobald Code ins Versionskontrollsystem eingecheckt wurde. Entwickler arbeiten heute meist isoliert an ihren Aufgaben und führen ihren Code zurück, sobald sie die Aufgabe abgeschlossen haben. Mit verteilten Versionskontrollsystemen wie Git wird Entwicklern ermöglicht, auf isolierten Feature-Branches zu arbeiten und am Ende ihren Stand über einen Pull Request auf den Haupt-Branch zurückzuführen. Durch Continuous Integration wird dann sichergestellt, dass der Stand auf dem Haupt-Branch immer noch den Qualitätsvorgaben entspricht, indem etwa der Build funktioniert und alle Tests erfolgreich durchlaufen.
Im nächsten Schritt kann dann über Continuous Delivery der aktuelle Stand vollautomatisch gebaut, getestet und ausgeliefert werden. Das kann über mehrere Stufen passieren. In der ersten Stufe wird erst auf eine Entwicklungsumgebung ausgerollt, in der nächsten auf ein Testsystem und am Ende auf das Produktivsystem. Da ein automatisiertes Ausliefern auf das Produktivsystem erst sinnvoll ist, nachdem der Stand auf dem Testsystem erfolgreich getestet wurde, kann zusätzlich noch über einen manuellen Freigabeprozess die Automatisierung angestoßen werden.
Es stellt sich nun die Frage, wie in einer kontinuierlichen Art und Weise Anwendungen und Updates auf das Device übertragen werden können. Für dieses Szenario bietet der Azure IoT Hub die Edge-Funktionalität [MS_Edge]. Mit Azure IoT Edge wird eine Runtime geliefert, die auf dem Device läuft. Diese stellt eine Umgebung bereit, in der Anwendungen als Docker Container [DockCon] ausgeführt werden können. Dadurch laufen die Anwendungen isoliert voneinander.
Um die Anwendungen auf das Device herunterzuladen und auch aktuell zu halten, werden die Container in einer zentralen Docker Container Registry [MS_ACR] gespeichert. Aus der Cloud heraus kann nun gesteuert werden, welche Container in welcher Version auf das Device installiert werden sollen. Die Runtime kümmert sich dann zyklisch um die Überprüfung, ob Container aktualisiert oder zusätzliche Container herunterladen werden müssen. Um nun vom Code zum Deployment auf das Device zu kommen, kann die Pipeline wie in Abbildung 4 gezeigt aussehen.
Abb. 4: Deployment-Prozess eines IoT Edge-Moduls auf ein Device [Quelle: Eigene Darstellung]
Über einen Continuous Integration Build wird das Kompilieren der Anwendung und das Erstellen des Docker Images getriggert. Das fertige Docker Image wird dann in die Docker Registry hochgeladen. Damit der neuste Stand nicht direkt auf alle Devices in der Produktivumgebung ausgeliefert wird, sorgt Continuous Delivery mit unterschiedlichen Umgebungen für den Auslieferungsprozess. Damit zugeordnet werden kann, welche Version gerade in welcher Umgebung (Entwicklung, Preview oder Produktion) ausgeliefert ist, wird das Container Image mit einem entsprechenden Tag versehen. So haben standardmäßig alle Container Images, die aus dem CI-Build fallen, ihre Versionsnummer und das Suffix build als Tag (z. B. 1.2-build). Um nun eine Version in der nächsten Umgebung bereitzustellen, wird letztendlich nur das Image geladen und mit einem neuen Tag versehen, zum Beispiel 1.2-dev für die Entwicklungsumgebung oder 1.2 für die Produktivumgebung. Somit kann immer genau zugeordnet werden, welche Version für welche Umgebung verwendet werden soll. Damit das Container Image am Ende auf die entsprechenden Devices ausgeliefert wird, wird ein separates Deployment gestartet. Hierzu wird ein IoT Edge Deployment Manifest [MS_Mani] erstellt. Dieses Deployment Manifest beinhaltet alle Module, deren Version und Konfiguration, die auf die Devices ausgerollt werden soll. Ein Modul ist dabei eine Anwendung, die als Docker Container auf dem Device läuft. Das Deployment Manifest wird im IoT Hub hochgeladen und beim nächsten zyklischen Prüfen übernimmt die IoT Edge Runtime das Aktualisieren des Device.
Wie so ein Continuous Integration und Continuous Deployment konkret am Beispiel von Azure DevOps aussehen kann, zeigt Abbildung 5. Der Continuous Integration Build übernimmt das Erstellen des Docker Image für die Prozessorarchitekturen ARM und x64. Beide Images werden dann in einem Docker Manifest [DockMan] zusammengefasst. Das sorgt dafür, dass je nach verwendetem Prozessor nicht unterschiedliche Images auf die Devices ausgeliefert werden müssen, sondern die Docker Runtime auf dem Device kann selbstständig entscheiden, welches spezifische Image es installieren muss.
Abb. 4: Deployment-Prozess eines IoT Edge-Moduls auf ein Device [Quelle: Eigene Darstellung]
Im Continuous-Deployment-Prozess werden die Images je nach Umgebung automatisch neu getagged und ein neues Deployment Manifest erstellt, um die entsprechende Version auf die Devices auszurollen.
Dadurch ergibt sich eine durchgängige Pipeline, die beim Push von neuem Code voll automatisiert die entsprechenden Module baut und für die Installation durch die IoT Edge Runtime auf den einzelnen Geräten bereitstellt.
Continuous Feedback
Wie auch bei normalen Anwendungen reicht es nicht aus, nur Telemetrie- oder Protokolldaten zu senden. Um den Betrieb der Geräte in einem IoT-Szenario sicherzustellen, ist es wichtig, nicht nur Telemetriedaten der Softwaremodule zu bekommen, sondern es müssen auch Systemlogs und Telemetriedaten zu Hardware und Betriebssystem übermittelt werden. Zusätzlich muss bei einem Problem mit dem Gerät reagiert werden können. Es ist nicht nur wichtig, sich auf das Gerät von der Ferne verbinden zu können, um so mögliche Fehler direkt auf dem Gerät beheben zu können, sondern auch Updates auf Software bis hin zur Hardwareebene müssen machbar sein.
Für die Applikationstelemetrie der Softwaremodule können verschiedene Ansätze gewählt werden. Wie auch bei normalen Anwendungen reicht es meist aus, auf bestehende Services wie Application Insights oder den Elastic Stack [ELK-Stack] aufzubauen, je nachdem wo die Daten später abgelegt werden sollen. Ein weiterer Ansatz kann sein, die Daten als einfache Nachricht an den IoT Hub zu senden. Dadurch wären sowohl die Telemetriedaten des Device als auch die der Softwaremodule in derselben Datensenke zusammen. Die Trennung der Daten kann dann in der Cloud passieren. Bei Telemetriedaten sollte beachtet werden, dass im Gegensatz zu normalen Anwendungen das IoT-Device nicht zwingend über eine permanente Verbindung ins Internet verfügt oder auch nicht immer die entsprechende Datenbandbreite oder das entsprechende Datenvolumen hat, wenn dieses zum Beispiel über Mobilfunk mit dem Internet verbunden ist.
Auch beim Thema Systemlogs gibt es ähnliche Ansätze und die gleichen Probleme wie bei den Telemetriedaten der Softwaremodule. Zu Diagnosezwecken ist es hilfreich, auch die Systemlogs zu bekommen. Diese müssen aber nicht zwangsläufig immer übertragen werden, sondern können auch bei Bedarf angefordert werden. Einen solchen Ansatz stellt auch schon die IoT Edge Runtime bereit. Über einen Befehl, der an das Device gesendet werden kann, können Logs der Softwaremodule in einen Blob Storage übertragen werden. Für die Systemlogs könnte man sich über ein eigenes Custom-Modul eine ähnliche Funktionalität zum Übertragen von beliebigen Systemlogs erstellen. Hier bietet sich Logstash aus dem Elastic Stack an, um erst einmal lokal die verschiedenen Logdateien zu sammeln, um diese dann anschließend an beliebige Datenziele wie die Azure Cloud zu übertragen.
Wurde erst einmal ein Fehler festgestellt, so sollte es auch die Möglichkeit geben, sich Remote auf das Gerät zu verbinden. Hier gibt es wiederum verschiedene Ansätze von fertigen Lösungen bis zu einer einfachen VPN-Verbindung, über die das Gerät per SSH oder Remotedesktop angesprochen werden kann. So wird sichergestellt, dass nur in Ausnahmefällen, bei denen das Gerät überhaupt nicht mehr reagiert oder ansprechbar ist, ein Techniker vor Ort sein muss. Auch das Thema Remote Update ist umfangreicher, als es auf den ersten Blick scheint. Denn meist reicht es nicht aus, nur die neusten Software-Updates oder Security-Patches einzuspielen. Bei IoT-Devices, die jahrelang im Feld stehen können, muss unter Umständen auch das Betriebssystem oder sogar die Firmware aktualisiert werden können. Doch das Vorgehen birgt mehr Risiken, als ersichtlich sind. Was ist, wenn bei einem Remote Update ein Fehler auftritt? Damit das Gerät danach nicht lahmgelegt wird, muss eine Rollback- und Fallback-Strategie berücksichtigt werden. Hier muss das Rad nicht neu erfunden werden, dafür gibt es Anwendungen wie Mender [Men], die sowohl den Client für das Device liefern als auch das Backend zum Bereitstellen von Updates zur Verfügung stellen.
Zusammenfassend lässt sich sagen, dass es noch nicht ausreicht, nur Software zu entwickeln und diese auf ein Gerät auszuliefern. Der komplette Betrieb muss sichergestellt werden und das unter Umständen für die nächsten 10 bis 15 Jahre.
Fazit
Die Grundprinzipien der DevOps-Bewegung haben auch bei IoT-Projekten Gültigkeit. Die einzelnen Herausforderungen erweitern sich jedoch, wenn man hardwarenahe, industrielle Lösungen bereitstellt, im Vergleich zu einer reinen Softwareanwendung. So muss sich das Entwicklungsteam zwangläufig auch mit Hardware, wie dem Edge-Device selbst, Netzwerkinfrastruktur oder der Anbindung von Steuerungen und Standards wie OPC UA auseinandersetzen.
Doch das ist gar kein Nachteil. Insbesondere bei Lösungen im industriellen Umfeld, die hohe Anforderungen an Lebensdauer, Sicherheit, Robustheit und Wartbarkeit haben, ist es enorm wichtig, von Beginn der Entwicklung den Blick auch auf den Betrieb der Lösung zu werfen. Auch die Aspekte des kontinuierlichen Feedbacks helfen dabei, die Qualität der Lösung sicherzustellen und die Weiterentwicklung zu optimieren. So entfaltet sich DevOps in IoT-Projekten zu einem Erfolgsfaktor und ist nicht nur eine Hilfe, sondern fast schon eine Notwendigkeit, um das Beste aus beiden Welten zu vereinen.
Literatur & Links
[AIT] AIT Intelligent Factory, siehe: https://www.aitgmbh.de/unsere-leistungen/industrial-iot/
[Bro15] D. Brown, What is DevOps?, Blog, 1.9.2015, siehe: http://donovanbrown.com/post/what-is-devops
[DockCon] Docker: What is a container?, siehe: https://www.docker.com/resources/what-container
[DockMan] Docker Manifests, siehe: https://docs.docker.com/engine/reference/commandline/manifest/
[ELKStack] Elastic Stack, siehe: https://www.elastic.co/what-is/elk-stack
[FischerT] Taktstraße mit 2 Bearbeitungsstationen 24V - Education, siehe: https://www.fischertechnik.de/de-de/produkte/lehren/trainingsmodelle/96790-edu-taktstrasse-mit-2-bearbeitungsstationen-24v-education
[GRLIoT] Gründerszene-Lexikon, Definition: Internet of Things, siehe: https://www.gruenderszene.de/lexikon/begriffe/internet-of-things
[Hub19] W. Huber, Industrie 4.0: So unterscheiden sich IT und OT, ChannelPartner, 15.3.2019, siehe: https://www.channelpartner.de/a/so-unterscheiden-sich-it-und-ot,3335362
[Men] Mender Remote Update, siehe: https://mender.io/products/open-source
[MS_ACR] Azure Container Registry, siehe: https://azure.microsoft.com/en-us/services/container-registry/
[MS_AI] What is Application Insights?, siehe: https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview
[MS_DPS] Azure Device Provisioning Service, https://docs.microsoft.com/en-us/azure/iot-dps/about-iot-dps
[MS_Edge] Azure IoT Edge, siehe: https://azure.microsoft.com/en-us/services/iot-edge/
[MS_ETL] Microsoft: Extract, transform, and load, siehe: https://docs.microsoft.com/en-us/azure/architecture/data-guide/relational-data/etl
[MS_Mani] Azure IoT Edge Deployment Manifest, siehe: https://docs.microsoft.com/en-us/azure/iot-edge/module-composition
[MS_MQTT] IoT Hub MQTT Support, siehe: https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-mqtt-support
[OPCUA] Unified Architecture, siehe: https://opcfoundation.org/about/opc-technologies/opc-ua/
[Simatic] Siemens S7 1500, siehe: https://new.siemens.com/global/en/products/automation/systems/industrial/plc/simatic-s7-1500.html
