Fachbereich Maschinenbau Fachgebiet Datenverarbeitung in der Konstruktion Konzept zur Modularisierung von Komponenten des Digitalen Prozesszwillings Concept for the Modularization of Components of the Digital Process Twin Bachelorarbeit von Robert Knobloch (Matrikelnummer: 2367563) Tag der Einreichung: 8. Oktober 2022 Betreuer: Vladimir Kutscher Betreuer: Christian Plesker Veröffentlicht unter CC-BY 4.0 International https://creativecommons.org/licenses/by/4.0 4 https://creativecommons.org/licenses/by/4.0 Zusammenfassung Digitale Prozesszwillinge (DPTs) sind vernetzte Software-Systeme im Industrie-4.0-Kontext, die Produktionsprozesse digital abbilden, überwachen und steuern. Damit können Pro- duktivitätssteigerungen erzielt und Wertschöpfungsketten flexibilisiert werden. Allerdings kann der Betrieb von DPTs zu sehr hohen Anforderungen an die ausführende Rechen- ressource führen. Zu diesen Anforderungen gehören eine hohe und variable benötigte Rechenleistung, Zuverlässigkeit und Ausfallsicherheit. Diese können mit monolithischen DPT-Architekturen nicht immer ausreichend erfüllt werden. Außerdem sind monolithische DPTs schwer wartbar, da einzelne Teile nur umständlich ersetzt werden können. Wenige wissenschaftliche Arbeiten befassten sich aber bisher mit nicht-monolithischen Digitalen Zwillingen. Der Aufbau eines DPT in modularer statt monolithischer Architektur verspricht eine länge- re Lebensdauer durch bessere Wartbarkeit und Austauschbarkeit der DPT-Komponenten. Außerdem lassen sich die Module mittels Software-Virtualisierung durch Container von der physischen Hardware trennen und so flexibel zwischen beliebigen Hosts bewegen. Diese Portabilität erlaubt die horizontale Skalierung des DPT, Ausfalltoleranz sowie eine Auslagerung von Modulen in die Cloud. Austauschbarkeit und Wiederverwertbarkeit der Module sowie Portabilität der Container-Technologie ermöglichen zudem ein hersteller- übergreifendes Ökosystem für den DPT. In dieser Arbeit werden die Komponenten eines DPT modularisiert und containerisiert. Es wird eine Architektur für diesen containerisierten, modularisierten DPT (CMDPT) ge- schaffen, welche insbesondere die benötigte Infrastruktur für den Betrieb spezifiziert. Das Konzept wird in einer prototypischen Implementierung umgesetzt. Die Validierung des Konzepts zeigt, dass der CMDPT neue Anwendungsgebiete für den DPT schafft, die zu- grundeliegenden Technologien aber in Hinsicht Echtzeit und Latenz noch nicht ausgereift sind. 5 Abstract Digital Process Twins (DPTs) are connected software systems in the industry 4.0 context, which digitally represent, monitor and control production processes. This technology promises productivity gains and can improve the flexibility of supply chains. On the other hand, DPTs are setting difficult-to-achieve requirements for the executing computing resource, such as high and variable performance, reliability and fault tolerance. These requirements might not be satisfyingly met by a monolithic DPT architecture. Monolithic DPTs are also more difficult to maintain because components can not be easily replaced. Few scientific works have yet proposed explicitly non-monolithic digital twins. A modular DPT promises a longer lifespan through improved maintainability and the ability to replace components. The modules are detached from the physical hardware using container software virtualization. This way the modules can be quickly and reliably migrated between hosts. This portability enables the horizontal scaling of the modules and the moving of modules to the cloud. Horizontally scaled modules also gain fault tolerance to a degree. The exchangeability and reusability of the modules enable a producer-independent module ecosystem. In this thesis, the components of a DPT are modularized and containerized. An architecture for this containerized, modularized DPT (CMDPT) is created, which provides the required infrastructure for its operation. This concept is realized in a prototypical implementation which demonstrates the characteristics of the CMDPT. The validation of the concept shows new areas of applications for the DPT, but also notes that underlying technologies might not yet have the required real-time and latency capabilities. 6 Abkürzungsverzeichnis CMDPT Containerized Modular Digital Process Twin DPT Digital Process Twin DT Digital Twin HMI Human-Machine Interface IF-DTiM Implementation Framework of Digital Twins for Intelligent Manufacturing MMI Machine-Machine Interface MOM Message-Oriented Middleware OCI Open Container Initiative SoA Service-orientierte Architektur VM Virtuelle Maschine 7 Abbildungsverzeichnis 2.1. Digitaler Zwilling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2. Digital Process Twin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3. Software-Virtualisierungsarchitekturen . . . . . . . . . . . . . . . . . . . . 21 2.4. Container-Image Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5. Container-Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1. Single-Host Containerized Modular Digital Process Twin (CMDPT) . . . . 42 3.2. Distributed Modular Digital Process Twin - DPT View . . . . . . . . . . . . 49 3.3. Distributed Modular Digital Process Twin – Host View . . . . . . . . . . . 51 3.4. Digital Process Twin Clustered Module . . . . . . . . . . . . . . . . . . . . 52 4.1. Dockerfile Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.2. Waypoint Index UI des CMDPT . . . . . . . . . . . . . . . . . . . . . . . . 61 4.3. Waypoint Detail UI des CMDPT . . . . . . . . . . . . . . . . . . . . . . . . 62 4.4. Single Host Implementierung Log . . . . . . . . . . . . . . . . . . . . . . . 63 4.5. CMDPT Services im Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.6. Host-basierte Übersicht verteilter CMDPT . . . . . . . . . . . . . . . . . . . 67 4.7. Skalierung der CMDPT-Module im Admin-UI . . . . . . . . . . . . . . . . . 67 8 Tabellenverzeichnis 5.1. Verifizierung der Anforderungen des CMDPT . . . . . . . . . . . . . . . . . 69 9 Inhaltsverzeichnis 1. Einführung 13 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3. Methodik und Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2. Stand der Technik 16 2.1. Der Digitale Zwilling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2. Der Digitale Prozesszwilling . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3. Software-Virtualisierung mit Containern . . . . . . . . . . . . . . . . . . . 19 2.3.1. Virtuelle Maschinen . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3.2. Funktionsweise der Container-Technologie und Unterschiede zu Virtuelle Maschinen (VMs) . . . . . . . . . . . . . . . . . . . . . . . 20 2.3.3. Container Engines, Runtimes, Managers und Orchestators . . . . . 21 2.3.4. Images und Union-Mount . . . . . . . . . . . . . . . . . . . . . . . 22 2.3.5. Volumes und Networking . . . . . . . . . . . . . . . . . . . . . . . 22 2.3.6. Open Container Initiative . . . . . . . . . . . . . . . . . . . . . . . 23 2.4. Container-Orchestrierung im Container-Cluster . . . . . . . . . . . . . . . 24 2.5. Echtzeit-Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.6. Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.1. Daemon und Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.2. Erstellen von Images mittels Dockerfile . . . . . . . . . . . . . . . . 26 2.6.3. Arbeiten mit Containern . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.4. Docker-Compose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.5. Docker Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.7. Software-Modularität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.8. Service-orientierte Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.8.1. Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.9. Message-oriented Middleware . . . . . . . . . . . . . . . . . . . . . . . . . 30 10 2.10.ZeroMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.11.Bestehende Konzepte zur Containerisierung von Digitalen Zwillingen . . . 31 2.11.1.Der Digitale Zwilling im Cloud- und Fog-Computing . . . . . . . . 32 2.11.2. IF-DTiM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3. Konzept zur Modularisierung des Digitalen Prozesszwillings 34 3.1. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2. Charakteristika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.1. Modularität des DPT . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.2. Modularität durch Container . . . . . . . . . . . . . . . . . . . . . 37 3.3. Konzeptionierung für nicht-verteilte Systeme . . . . . . . . . . . . . . . . . 41 3.3.1. Container-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3.2. Image-Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3.3. Modul-Ebenen des CMDPT . . . . . . . . . . . . . . . . . . . . . . . 43 3.3.4. Volumes und Zustand . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3.5. Modul-Basis als Base-Image . . . . . . . . . . . . . . . . . . . . . . 45 3.3.6. Service-orientierte Architektur . . . . . . . . . . . . . . . . . . . . . 45 3.3.7. Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.3.8. Auswahl einer geeigneten Messaging-Technologie . . . . . . . . . . 46 3.3.9. Auswahl geeigneter Containertechnologien . . . . . . . . . . . . . . 47 3.4. Konzeptionierung für verteilte Systeme . . . . . . . . . . . . . . . . . . . . 48 3.4.1. Container-Orchestrator . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.4.2. Module im Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.4.3. Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.4.4. Auswahl geeigneter Container-Orchestratoren . . . . . . . . . . . . 51 4. Prototypische Implementierung 54 4.1. Beschreibung der Rechenumgebung . . . . . . . . . . . . . . . . . . . . . . 55 4.2. Programmstruktur der Module . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.1. Programmiersprache . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.2. Base-Image/Modul-Basis und Kommunikation . . . . . . . . . . . . 55 4.2.3. Microservices / Service-orientierte Architektur . . . . . . . . . . . . 56 4.3. Container-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.1. Erstellen von Images mit Dockerfiles . . . . . . . . . . . . . . . . . 57 4.3.2. Docker-Compose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.3. Portainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.4. Implementierung des Entwicklungsprozesses für CMDPT-Images . . . . . . 59 4.4.1. Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 11 4.4.2. Erstellen und Abspeichern der Images . . . . . . . . . . . . . . . . 60 4.5. Betrieb auf einem einzelnen Host . . . . . . . . . . . . . . . . . . . . . . . 60 4.5.1. Installation des CMDPT mit Docker-Compose . . . . . . . . . . . . 60 4.5.2. Demonstration von Kommunikation und SoA . . . . . . . . . . . . . 62 4.6. Betrieb im Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.6.1. Auswahl eines Orchestrators . . . . . . . . . . . . . . . . . . . . . . 64 4.6.2. Rechenumgebung der Nodes . . . . . . . . . . . . . . . . . . . . . . 64 4.6.3. Docker-Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.6.4. Administratives Interface . . . . . . . . . . . . . . . . . . . . . . . 65 4.6.5. Hinzufügen/Anpassen von Modulen . . . . . . . . . . . . . . . . . 65 4.6.6. Überblick über den verteilten CMDPT . . . . . . . . . . . . . . . . . 66 4.6.7. Skalierung der Module . . . . . . . . . . . . . . . . . . . . . . . . . 66 5. Verifizierung und Validierung 68 5.1. Verifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.2. Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 6. Ausblick 75 A. Docker-Compose des nicht-verteilten CMDPT 77 B. Operational Data Interface 80 12 1. Einführung Eine neue Welle von Veränderungen erfasst zurzeit die Industrie. Diese wird angeführt vom Konzept Industrie 4.0, das die Integration aller Assets eines Unternehmens in einen virtuellen Raum vorsieht. Dieser Raum ist für alle Ebenen in der Wertschöpfungskette, vom Produkt über die Maschinen bis zum Management, zugänglich. Dadurch lässt sich ein produzierendes Unternehmen komplett neu strukturieren, Prozesse können betriebsweit vollautomatisiert, flexibilisiert und mittels maschineller Intelligenz optimiert werden. „Die Deutsche Industrie […] sieht großen Nutzen und riesige Chancen durch Industrie 4.0“ [Abe+15, S. 3]. Good-Practice-Beispiele zeigen, dass auch einfache Lösungen schon besonders bei kleinen und mittleren Unternehmen die Effizienz in der Produktion enorm steigern können [Abe+15, S. 3]. Die Wandlung zu Industrie 4.0 erfordert die digitale Repräsentation physischer Assets, und damit für jedes Asset ein virtuelles Echtzeitabbild, den Digital Twin (DT). Das virtuelle Echtzeitabbild, verteilte Intelligenz und die schnelle Vernetzung und Konfiguration der Komponenten sind drei von sieben Basismerkmalen der Umsetzung von Industrie 4.0, die die Firma Bosch in einer Studie ausfindig machte [Han17, S. 131]. Das in dieser Arbeit vorgeschlagene Konzept betrifft alle drei dieser Merkmale. Dafür wird sich auf die Industrie-4.0-Technologie Digital Process Twin (DPT) fokussiert. Der DPT findet Verwendung als Echtzeitabbild und Manager eines Produktionsprozesses, und ist daher besonders relevant für die Industrie. Das Konzept des DPT ist besonders vielversprechend für die Verbesserung von Effizienz, Zuverlässigkeit und Sicherheit in der Produktion. Der DPT bedarf jedoch stetiger Weiterentwicklung, um in der Praxis die hohe Hürde zu überschreiten, bei der Betriebe dessen Einsatz beschließen. 13 1.1. Motivation Digitale (Prozess-)Zwillinge können in ausgereifter Form sehr anspruchsvolle und kompli- zierte Technologien sein, an die höchste Anforderungen gestellt werden. Ein Problem bei einer monolithischen Architektur des DPT ist, dass der DPT-Entwickler in allen Aspekten und für den gesamten Lebenszyklus diesen Anforderungen gerecht werden muss. Es ist sehr schwer, Teile eines monolithisch programmierten DPT separat zu entwickeln oder wiederzuverwerten, da dessen Teile voneinander abhängig und stark integriert sind. Die Standardisierung einer facettenreichen und sich wandelnden Technologie wie dem DPT stellt sich zudem als sehr schwierig heraus. Hersteller oder Forscher tendieren dazu, ihre eigenen, miteinander inkompatiblen Architekturen zu entwickeln. Dies fördert zwar die Innovation in der frühen Phase, bremst aber eine Weiterentwicklung aus. Auch ist die oft enge Bindung der Software eines DPT an die Hardware ein Problem. Kommt es zu Problemen mit der Hardware, ist der DPT direkt betroffen und kann nicht flexibel auf andere Hardware migriert werden. Die Hardware-Last kann zudem stark schwanken und so zu unnötiger Ressourcenbelegung oder Überlastung führen. Ersteres ist aus wirtschaftlichen Gründen unerwünscht, da die reservierte Rechenleistung anderweitig genutzt werden könnte. Eine Überlastung kann bei kritischen Anwendungen zu erheblichen Verzögerungen und ungewünschtem Verhalten führen. Die Software-Containertechnologie entkoppelt die Software zu einem gewissen Grad von der physischen Hardware. Das erleichtert die Installation, Migration und den Betrieb von einer großen Anzahl an Software-Paketen. Die Container-Technologie kommt gerade im Distributed Computing heutzutage sehr stark zum Einsatz, um durch Virtualisierung der Software die flexible Skalierbarkeit der reservierten Rechenleistung zu ermöglichen und den Betrieb in der Cloud zu vereinfachen [Sus20] [Wat20]. Deswegen könnte die Container-Technologie ein nützliches Werkzeug sein, um monolithische Architekturen von DPTs aufzubrechen. 1.2. Zielsetzung Das Ziel dieser Arbeit ist die Schaffung eines Konzeptes zur Anwendung des Prinzips der Modularität auf den Digitalen Prozesszwilling unter Verwendung der Containertechnologie. Dafür soll eine System-Architektur erarbeitet werden. Eine Verifikation und Validierung des Konzeptes soll über eine prototypische Implementierung erfolgen. 14 1.3. Methodik und Struktur Die Ausarbeitung des Konzeptes folgt induktiv sowie deduktiv auf der Grundlage vorhande- ner Forschung. Verschiedene in der Literatur größtenteils separat betrachtete Technologien wie der Digitale Zwilling, die Container-Technologie und die Softwaremodularisierung sollen hierbei auf ihr Zusammenspiel untersucht werden, um mögliche Synergieeffekte zu nutzen. Deren Erkenntnisse werden induktiv im Konzept verarbeitet. Der Teil „Stand der Technik“ (Kapitel 2) erläutert diese Technologien, darunter den DPT, die Software- Virtualisierung, sowie die Modularisierung von Software mit deren Anwendungsfällen und einhergehenden Vor- und Nachteilen. Die Arbeiten, die diese Brücke zwischen DT und Container-Technologie schon teilweise geschlagen haben ([Ala+20], [Bor+17], [Hun+22]) werden ebenfalls untersucht. In keiner dieser Arbeiten wird eine Containerisierung DT-interner Module vorgeschlagen, wie sie in der vorliegenden Arbeit am DPT vorgenommen wird. Es fehlt in den genannten Veröffentlichungen zudem eine ausführliche Charakterisierung des modularen Aufbaus von DT-Systemen. Der Beitrag der Arbeiten zum Konzept wird deswegen deduktiv abgeleitet. Die Arbeiten können außerdem wertvolle Hinweise für die Praxis liefern. Das Konzept (Kapitel 3) wird von einer Auswahl und Entwicklung geeigneter Anforde- rungen an den Containerized Modular Digital Process Twin (CMDPT) angeführt. Es folgt eine Erläuterung der Charakteristika, welche die Synergie der untersuchten Technologien auszeichnet. Dabei wird auch auf auftretende Herausforderungen eingegangen, die teil- weise schon in anderen Forschungsarbeiten qualitativ und quantitativ ermittelt wurden. Die Charakteristika stellen das grundlegende Prinzip des Konzeptes dar. Anschließend wird eine konkrete Architektur für den CMDPT entwickelt. Dabei werden Auswahlen an geeigneten Implementationen der verwendeten Technologien getroffen. Als Proof of Concept wird in Kapitel 4 ein Teil des CMDPT in einer ersten skizzenhaften Ausführung auf das Projekt AI-in-Orbit-Factory angewandt und die dabei ermittelten Vortei- le und auftretenden Schwierigkeiten dokumentiert. Diese prototypische Implementierung dient dann in Kapitel 5 als Grundlage für die Verifikation der Anforderungen an das Konzept. Dort wird das Konzept anschließend auch anhand realistischer Anwendungsfälle validiert. Im abschließenden Kapitel 6wird ein Ausblick auf die Weiterentwicklung des DPT vor dem Hintergrund dieses Konzeptes gegeben und die Gebiete mit Forschungsbedarf ermittelt. 15 2. Stand der Technik Das Konzept des CMDPT und dessen prototypische Implementierung vereinen eine Viel- zahl an Technologien. Daher wird in diesem Kapitel diesbezüglich eine Übersicht über den Stand der Technik gegeben. Behandelt werden insbesondere DT und DPT, die Container-Technologie und Software-Modularität. Das Kapitel schließt mit einer Betrach- tung bestehender wissenschaftlicher Arbeiten an der Schnittstelle von DT und Container- Technologie. 2.1. Der Digitale Zwilling Der Digital Twin (DT) erweitert ein physisches Asset um einmöglichst identisches virtuelles Objekt. Das Prinzip wurde von Michael Grieves im Jahr 2002 vorgeschlagen [GV17, S. 93]. Ein DT zeichnet sich vor allem durch einen bidirektionalen Datenfluss zwischen dem virtuellen Modell (Digitaler Zwilling) und dem reellen Gegenstand (physischer Zwilling) aus [GV17, S. 93], wie zu erkennen in Abbildung 2.1. Diese Kopplung geschieht durch „Sensoren, Datenbanken, Smart Devices und Prozessmanagement-Systeme“ (aus dem engl. nach [DTB22, S. 3]). Dadurch soll der Zustand und das Verhalten des physischen Zwillings während des gesamten Lebenszyklus simuliert und vorhergesagt werden [NE22, S. 42]. Die Daten, die das Abbild des physischen Zwillings formen, werden im Digitalen Schatten gespeichert, einer Teilmenge des DT [Sta+20, S. 47] Die Berechnungen des DT dienen wiederum der Einflussnahme auf den physischen Zwilling. Der Einsatz eines DT hat in allen Phasen des Lebenszyklus vielseitige Vorteile für den physischen Zwilling und dient als Grundlage für ein weites Gebiet an Funktionalitäten [NE22, S. 43]. Das „Urmodell“ [Sta+20, S. 48] eines DT, der Digitale Master, kann schon am Anfang des Lebenszyklus im iterativen Entwicklungsprozess eingesetzt werden, um das Bauen von teuren Prototypen zumindest teilweise zu ersetzen [GV17, S. 100, 112] [Sta+20, S. 48]. Dabei entstehen sogenannte Digitale Prototypen [Sta+20, S. 48]. 16 Physical Twin Automatic Data Flow Digital Twin Abbildung 2.1.: Allgemeines Prinzip des digitalen Zwillings, angelehnt an [Kri+18, S. 1017] In dieser frühen Phase erlaubt der DT das effiziente Aufdecken von unerwünschtem und unerwartetem Systemverhalten. Auch während des Betriebs können unerwartete Situationen mit der Hilfe des DT vorhergesagt und bewältigt werden. Dadurch kann die Zuverlässigkeit des Systems erheblich verbessert werden [GV17, S. 103]. Es gibt auch Herausforderungen bei der Einführung von DTs, wie Grieves [GV17, S. 108, 109] sie selbst anführt: 1. Der DT braucht für dessen volle Funktionstüchtigkeit Modelle der Verhaltensweisen des physischen Zwillings in allen verschiedenen technischen Disziplinen. Maschi- nenbauer, Elektrotechniker, Informatiker, Physiker etc. müssen von vornherein ein einheitliches virtuelles Modell entwickeln und ihre Informationen über ein Produkt zusammenführen. Die häufige Fachbarriere zwischen ihnen stellt ein Hindernis dar. 2. Der Umfang und die Tiefe der möglichen Simulationen ist aufgrund des mangelnden Verständnisses der realen Welt und der Rechenleistung und Datenübertragungsge- schwindigkeit aktueller Technik limitiert. Diskrepanzen zwischen den Zwillingen sind daher unvermeidbar. 2019 erweitert Grieves die Liste an Herausforderungen [Gri19, S. 29, 30]: 3. Die Cyber-Sicherheit ist ein ernstzunehmendes Thema, besonders beim Einsatz des DT während des Betriebs. Digitale Zwillinge müssen sich selbst vor Cyberangriffen schützen können. 4. Die Datenflut, die durch die Anforderung an präzise Abbildung des physischen Systems entsteht, muss zu nutzbaren Informationen zusammengefasst werden. 17 5. Die vielen verschiedenen Implementationen des DT von unterschiedlichen Herstel- lern sollen miteinander kompatibel sein. Es braucht daher eine Standardisierung. Die akademische Forschung über Digitale Zwillinge nahm in den letzten fünf Jahren stark zu. Untersucht wurde dabei unter anderem der Einsatz in der Produktion, Lagerhaus- management, Asset Management in der Schifffahrt und im Katastrophenschutz [DTB22, S. 3, 4]. Dennoch ist die Entwicklung in einer noch frühen Phase: Eine 2018 durchge- führte Studie zum DT kategorisiert 55 Prozent der Literatur dazu als „Konzept“ [Kri+18, S. 1018]. In der umfassenden Vision sollen Digitale Zwillinge auf den verschiedenen Ebenen des Pro- duktionsprozesses kooperieren. Diese Multi-DT Systeme sind jedoch noch kaum erforscht und die Realisierbarkeit unklar [BB22, S. 11]. 2.2. Der Digitale Prozesszwilling Der DPT ist eine angepasste Version des DT auf Prozessebene und übernimmt zusätzlich zu bekannten DT-Funktionen umfängliche Aufgaben im Produktionsprozess. In dieser Arbeit wird die Definition des DPT von Kempf et al. [Kem+21, S. 7] übernommen: „Der Digitale Prozesszwilling orchestriert die Produktion einer Produktinstanz durch das Zuordnen der relevanten Produktkomponenten, das Instanziieren des Digitalen Produktzwillings als Auftakt des physischen Produktionsprozesses und das Bereitstellen von Informationen für die Digitalen Zwillinge der Produktionsmaschinen“ [Zitat aus dem Englischen]. Der DPT divergiert von der Definition des allgemeinen DT vor allem durch die Abwesenheit eines konkret greifbaren physischen Zwillings. Der Produktionsprozess nimmt dessen Rolle ein. Ein DPT braucht daher auch keine eigenen Aktoren oder Sensoren. Stattdessen steht der DPT als Akteur und Manager mehrerer DTs, vor allem von Produktions- und Produktzwillingen, im Vordergrund. Es wird von den Autoren [Kem+21, S. 7] insbesondere betont, dass der DPT keine klassi- sche Automatisierungshierarchie realisieren soll. Stattdessen stellt der DPT eine autonome Einheit dar, die selbstständig unter Bezugnahme der Informationen „von oben“ (Auftrag) und „von unten“ (Produktionsmittel) Entscheidungen trifft. Abbildung 2.2 zeigt die von Kempf et al. [Kem+21, S. 8] vorgeschlagene Architektur eines DPT mit vier Ebenen. Die oberste Ebene ist die Mensch-Maschine-Schnittstelle. Darunter folgt die Daten-Ebene, in der eine vollständige Selbstbeschreibung des DPT, 18 Abbildung 2.2.: Der Digitale Prozesszwilling (DPT). Quelle: [Kem+21, S. 8] sowie jeweils ein Datenspeicher für den Prozessbetrieb (Operation Data Storage) und technische Modelle und Dokumente (Technical Data Storage) enthalten sind. Die dritte Ebene enthält sämtliche nicht anderweitig kategorisierten Funktionalitäten („Models and Services“) des DPT, wie die Produktionsplanung und -überwachung, die Erstellung der Produkt-DTs und weiteres. Diese Ebene ist beliebig erweiterbar. Die unterste Ebene ist die Schnittstelle zu den relevanten Digitalen Zwillingen des Prozesses, hauptsächlich den DTs der Produktionsmaschinen, der Produkte und anderen DPTs (Maschine-Maschine Schnittstelle). 2.3. Software-Virtualisierung mit Containern In diesem Abschnitt wird zuerst die Software-Virtualisierung anhand der etablierten Technik der Virtuellen Maschinen erläutert. VMs sind nicht zwingend relevant für das vorgeschlagene Konzept, aber wichtig für das Verständnis der Container-Technologie. Zuerst wird deren Funktionsweise vorgestellt, danach folgt ein Überblick über Features von modernen Container-Engines wie Union-Mount, Repositories, Volumes und Networking. 19 2.3.1. Virtuelle Maschinen Die Software-Containertechnologie existiert vor allem im Kontrast zu der Virtualisierung von Software über Hypervisoren. Virtualisierung im Allgemeinen strebt die Emanzipation der Software von der Computer-Hardware und dem Betriebssystem an. Dafür wird die Software auf einem virtuellen Computer betrieben, der mithilfe eines Hypervisors auf einem physischen Rechner (Host) laufen kann. Der Hypervisor teilt die Ressourcen des Hostsystems auf ggf. mehrere dieser virtuellen Maschinen auf [Red20]. Die Virtuelle Maschinen betreiben ein komplettes Gast-Betriebssystem auf dem Host- Computer, sodass ein signifikanter Overhead entsteht. Dieser bindet Systemressourcen, führt zu einem sehr langsamen Startprozess [Pah15, S. 25], und schränkt dadurch die Mobilität der VM zwischen mehreren Hosts ein. Die Gast-Betriebssysteme bieten eine vollwertige Rechenumgebung für die zu betreibenden Applikationen. Zusammen gebündelt wird die gesamte Software einer VM als Image gespeichert. Aufgrund des großen Overhead jeder einzeln virtualisierten Software, lohnt es sich nicht, Microservice-Architekturen (siehe Kap. 2.8) aufzubauen. Modularität lässt sich durch diese Technologie daher schwer erreichen. Die Vorteile von Virtualisierung sind bessere Ressourceneffizienz, erhöhte Sicherheit durch Isolation der VMs und schnelle Einsatzbereitschaft der Software auf beliebigen Hosts [ES21, S. 180]. Der Einsatz von VMs findet sich vor allem in der Infrastructure-as-a-Service (IaaS) Cloud, da mit VMs den Nutzern die volle Kontrolle über die geliehene Hardware gegeben werden kann. 2.3.2. Funktionsweise der Container-Technologie und Unterschiede zu VMs Die Container-Technologie ist eine neuere Virtualisierungstechnik und eliminiert den Gebrauch des Gast-Betriebssystems. Stattdessen teilen Container sich den Systemkernel des Hosts, siehe Abb. 2.3. Die Aufgaben des Hypervisors werden in diesem Fall vom Kernel selbst übernommen: Die Isolierung des Dateisystems und der Prozesse des Containers vom Host wird über Linux-Namespaces implementiert, die Zuteilung und Verwaltung der Host-Ressourcen mit cgroups (Linux Control Groups) [Pah15, S. 25]. Ein Container-Image enthält lediglich die Anwendung mit ihren Abhängigkeiten. Dadurch werden die Größe der Images und die rein zum Betrieb der virtualisierten Software benötigte Rechenleistung reduziert, welches besonders beim Betreiben einer großen Zahl an virtuellen Umgebungen relevant ist. Die Anzahl an separaten Applikationen in einem 20 Container wird Granularität genannt [Pah15, S. 27], bei Microservice-Architekturen (siehe Kap. 2.8) beträgt diese Eins. Felter et al. [Fel+15, S. 172] bemaßen in ihren Untersuchungen die Performance von Docker, einer Container-Engine (siehe Kap. 2.6), gegenüber KVM, einer VM Infrastruktur, als immer besser oder gleich. Außerdem seien Virtuelle Maschinen schlechter für den Einsatz bei hohen Datenübertragungsraten oder Anwendungen mit der Anforderung nach niedrigen Latenzen geeignet. Gerade diese Umstände sind aber relevant im Fall einer Verwendung im Industrie-4.0-Kontext. Da die Isolation der Kernel der verschiedenen virtuellen Umgebungen von der Host- Maschine nicht mehr gegeben ist, wird die Systemsicherheit bei Containern jedoch schwä- cher eingeschätzt als bei VMs [KS17, S. 176]. Das muss bei kritischen Applikationen beachtet werden. Abbildung 2.3.: Software-Virtualisierungsarchitekturen, links VM, rechts Container. © [2015] IEEE. Quelle: [Pah15, S. 25] 2.3.3. Container Engines, Runtimes, Managers und Orchestators Der Betrieb von Containern wird auf verschiedenen Abstraktionsebenen von unterschiedli- chen Programmen ermöglicht. Die Container Runtime ist das Programm, das auf niedrigster Ebene für den Aufbau und Betrieb der Container zuständig ist [Doc17]. Der Container Manager instruiert die Container Runtime. Der Container Manager ist ein „Satz an APIs, um auf einfache Art und Weise den gesamten Lebenszyklus eines Containers zu ver- walten“ [Emi19, S. 224] [aus dem Englischen]. Ein Container Orchestrator wiederum wird benötigt, um große Mengen an Containern auf einer großen Anzahl an Hosts zu 21 verwalten. Der Orchestrator ist unabdingbar für den Betrieb von verteilten Applikationen auf einem Rechen-Cluster (siehe Kap. 2.4). Jede unabhängige Recheneinheit im Cluster benötigt zusätzlich zum Orchestrator noch eine eigene Container-Runtime. Container Engine ist ein loser Begriff, der meist eine größere Sammlung an Programmen für den Betrieb von Containern in verschiedenen Einsatzmöglichkeiten bezeichnet. Oft fällt der Begriff mit dem Begriff des Container-Managers zusammen, kann aber auch wie im Fall der Docker-Engine zusätzlich einen Orchestrator beinhalten [Doc22f]. Der de facto Industriestandard-Orchestrator ist Kubernetes [Pah15, S. 30] [Hun+22, S. 3] und der de facto Standard-Container-Manager Docker [Pah15, S. 30]. Docker verwendet die Container-Runtime containerd, die dadurch ebenfalls zum Industriestandard wurde. Kubernetes und containerd sind die in ihrem Feld von der Cloud Native Computing Foundation (CNCF) am meisten empfohlenen Programme, da diese lang erprobt und erfolgreich sind [CNC22]. Die CNCF ist Teil der Linux Foundation. 2.3.4. Images und Union-Mount Eine Besonderheit der Containerarchitektur bei modernen Container-Runtimes wie contai- nerd ist der Aufbau von Images in Schichten. Dafür kommt ein Union-Mount zum Einsatz, welcher mehrere separate Dateisysteme als ein einziges lesbares Dateisystem zugänglich macht. Eine oder mehrere schreibgeschützte Image-Schichten bilden die Basis, auf der die schreibfähige Container-Schicht mit der Applikation sitzt, die wiederum als Image-Schicht eines anderen Containers dienen kann [Pah15, S. 26], siehe Abbildung 2.4. Ein beispielhafter Aufbau (Abbildung 2.4) eines Container-Stacks wäre ein Ubuntu Base- Image (1. Schicht), auf dem der Emacs-Texteditor (2. Schicht) und ein Apache Webserver (3. Schicht) aufgesetzt wird. Darauf sitzt die oberste Schicht, die schreibbar ist und die Applikation enthält. Das erstellte Container-Image dieser Applikation könnte wiederum genutzt werden, um eine Schicht hinzuzufügen, welche die Applikation nutzt und erweitert. Dieser neue Container enthält dann selbstverständlich auch alle Schichten des alten Containers. Dieses System hat den Vorteil der Wiederverwendbarkeit der Image-Schichten. 2.3.5. Volumes und Networking Da Container keinen beständigen Datenspeicher haben, weil Laufzeitdaten nach der Zer- störung eines Containers mit verloren gehen, existieren unabhängig der Container sog. Daten-Volumes. Das sind von der Container-Engine verwaltete Speicherelemente. Volumes 22 https://kubernetes.io/ https://www.docker.com/ https://containerd.io/ Abbildung 2.4.: Container-Image Architektur anhand des Beispiels eines Apache Webser- vers. © [2015] IEEE. Quelle: [Pah15, S. 26] sind nicht Teil des Union-Mount Dateisystems, können von mehreren Containern benutzt werden und unabhängig von denen existieren [Pah15, S. 27]. Die Isolation des Datei- systems kann aber auch bewusst durch die Verwendung von Bind-Mounts durchbrochen werden [Doc22i]. Dabei wird ein Teil des Host-Speichers in den Speicher des Containers projiziert. Das ist vor allem während der Entwicklung praktisch, negiert aber viele Vorteile der Container-Technologie, wie die Unabhängigkeit von der ausführenden Ressource, die Portabilität und die Sicherheit eines isolierten Dateisystems. Um Container zu vernetzen, können entweder deren Ports an die des Hosts geknüpft (mapping) oder Container untereinander vernetzt werden (linking) [Pah15, S. 27]. Letzte- res wird meist über die von Container-Managern erstellten Netzwerke realisiert, an denen die Container teilhaben können. 2.3.6. Open Container Initiative Die Open Container Initiative (OCI) ist ein Projekt der Linux Foundation mit dem Ziel der Standardisierung von Container Images und Container Runtimes [Ope20]. Der OCI- Standard hat sich aufgrund der Mitarbeit und Konformität der gängigsten Container- Engine Docker etablieren können. 23 2.4. Container-Orchestrierung im Container-Cluster Eine Applikation, die containerisiert in einer Microservice-Architektur (siehe Kap. 2.8) vorliegt, kann durch Verwendung eines Orchestrators auf ganzen Host-Pools betrieben werden. Dafür bedarf es jedoch eines sehr hohen Grades an Organisation und Kooperation zwischen den Hosts, im Cluster Nodes genannt. Diese wird durch den Orchestrator er- reicht. Der Microservice kann skaliert werden, indem der Orchestrator mehrere identische Container erstellt und die eingehenden Anfragen über Load-Balancing aufteilt. Die resul- tierende Computing-Plattform, gezeigt in Abb. 2.5, wird Cluster genannt. Die einzelnen Programmeinheiten im Cluster werden Services genannt. Abbildung 2.5.: Container-Cluster Architektur, Orchestrator nicht gezeigt. © [2015] IEEE. Quelle: [Pah15, S. 27] Ein Orchestrator soll u. a. folgende Fähigkeiten haben [Kha17, S. 44]: • Planung und Zustandsmanagement des Clusters, • Sicherstellen von Ausfalltoleranz im Cluster, 24 • Sicherstellen der Sicherheit des Clusters, • Vereinfachung der Vernetzung innerhalb des Clusters, • Überwachung des Cluster-Zustands. Der verbreitetste aktive Open-Source Orchestrator ist Kubernetes (siehe 2.3.3). Als Alter- native dazu dienen vor allem HashiCorp Nomad, Apache Mesos zusammen mit Marathon, und Docker Swarm. Docker Swarm ist in der Docker-Engine mitenthalten. 2.5. Echtzeit-Container Echtzeit beinhaltet keine Aussage über die Schnelligkeit von Berechnungen und Übertra- gungen, sondern deren zeitlichen Determinismus [Str+20, S. 3]. Stuhár et al. [Str+20, S. 3] unterscheiden zwischen Systemen, die bei Verfehlen einer Deadline lediglich Fehl- verhalten aufweisen („soft real-time“) und denen, die ausfallen („firm real-time“) oder schwere Konsequenzen mit sich ziehen („hard real-time“). Hinze untersucht in [Hin+19] und [Hin+18] den Einsatz von containerisierter Echtzeit- Software in Industriesteuerungen. Ziel ist die Regelung eines Roboters mittels Simulation und Machine Learning [Hin+19, S. 65, 66]. Das Ziel dringt damit in Forschungsbereiche des DT ein. Diese Regelung muss zeitlich determinierte Feedback-Loops aufweisen und benötigt daher Echtzeitfähigkeit. Das ist eine besondere Herausforderung, wenn die Software in einzelne Teile zerlegt wird, die miteinander kommunizieren müssen. Der PREEMPT-RT Patch für den Linux-Kernel ermöglicht Echtzeitanwendungen unter Linux [TMV18, S. 3]. Da Container sich den Host-Kernel teilen, erben sie diese Fähigkeit. Der Betrieb von Simulationen in Containern mit diesem Patch ermöglicht bei genauer Kenntnis des Rechensystems eine bestimmbare obere Grenze für Latenzen [Hin+18, S. 6]. Genauere Untersuchungen dazu fehlen jedoch noch größtenteils. Dieses Fehlen von weitergehender Forschung zu Echtzeit-Container kritisieren Stuhár et al. [Str+20, S. 7, 8]. Es gebe zudem keineWerkzeuge für den Einsatz von Echtzeit-Containern, keine Forschung zu Echtzeit-Container-Kommunikation und keine Sicherheitsanalysen. Demnach ließe sich ein verlässlicher Einsatz von Echtzeit-Containern noch nicht garantie- ren. 25 2.6. Docker Docker ist eine Open-Source Container-Engine und der de facto Industriestandard für Container-Manager [Pah15, S. 30]. Docker ist ein Werkzeug, mit dem der gesamte Le- benszyklus eines Containers verwaltet werden kann. Die Engine baut auf der eigenen Container-Runtime containerd auf und enthält zusätzlich einen Container-Orchestrator, Docker Swarm (siehe 2.3.3). Docker ist verfügbar für Linux, Windows und Mac OS. Auf die grundlegende Funktionsweise von Containern wird in 2.3 eingegangen. Für ausführliche und aktuelle Erläuterungen zur Engine wird auf die Dokumentation von Docker verwiesen. 2.6.1. Daemon und Client Auf dem Container-Host läuft der Docker Daemon. Dieser ist ein Server-Prozess mit REST- API, der Anweisungen vom Docker-Client, dem User-Interface, annimmt. Der Daemon nutzt containerd für die Low-Level Arbeit mit den OCI-Images. [Doc22a] 2.6.2. Erstellen von Images mittels Dockerfile Die Anweisungen zum Erstellen von Images werden in der sogenannten Dockerfile festge- halten. Jedes Image erhält eine separate Dockerfile. Grundsätzlich ist der Ausgangspunkt eines jeden Images ein Base-Image, das zuerst ange- geben wird. Im Fall eines Python-Programms würde daher in der Dockerfile zuerst das Python-Image spezifiziert. Danach wird das Programm in die schreibbare Ebene des Con- tainers kopiert, die nötigen Bibliotheken z. B. mittels des Python Package Managers (pip) installiert und der Ausgangsbefehl für den Container bei Containerstart angegeben. Dieser ist in diesem Fall dann der Python-Befehl mit der Angabe des Pfades des Programmes. [Doc22c] Die Dockerfile wird von Docker gelesen und das entsprechende Image gebaut und gespei- chert. Jede Anweisung der Dockerfile erstellt eine neue Image-Schicht. Bei Bedarf kann das Image dann auf eine externe Registry geladen werden. 26 https://docs.docker.com 2.6.3. Arbeiten mit Containern Der Docker Client beinhaltet CLI-Befehle (Command Line Interface) für alle Aspekte des Container-Managements, darunter sind das Starten und Stoppen von Containern, Networking, Logging, Port-Forwarding, Monitoring und weitere. Der Nutzer ist aber nicht zwingend auf den Client angewiesen, da auch andere Programme auf die API des Docker Daemon zugreifen können. So kann beispielsweise das Docker SDK für Python zur Entwicklung eines solchen Programmes verwendet werden. 2.6.4. Docker-Compose Das Tool Docker-Compose ermöglicht einen benutzerfreundlicheren Umgang mit Applika- tionen, die aus mehreren Containern bestehen, als das manuelle Verwalten mit einzelnen Client-Befehlen. In einer YAML Datei wird die Zusammensetzung der Applikation, Vernet- zung der Container, das Port-Forwarding, zugehörige Volumes und weiteres beschrieben. Die Datei trägt standardmäßig den Namen „compose.yaml“. Durch die dortige Spezifizie- rung kann das Deployment von Multi-Container-Applikationen automatisiert werden. Anschließend dient diese compose.yaml dem Docker-Compose Werkzeug dazu, den be- schrieben Zustand der Multi-Container Applikation durch Anweisung des Docker Daemons zu erreichen. Zudem bietet das Command Line Interface von Docker-Compose viele Funk- tionen, die den gesamten Lebenszyklus dieser Multi-Container Applikation abdecken. 2.6.5. Docker Swarm Docker Swarm ist der in der Docker Engine enthaltene Container-Orchestrator. Dadurch wird das Deployment von Multi-Container Applikationen auf Computer-Clustern ermög- licht (siehe Kap. 2.4). Auf allen Teilen eines Swarm-Clusters muss der Docker Daemon aktiv sein. Eine Instanz der Docker Engine im Cluster wird Node genannt. Nodes können die Rolle ei- nesManagers oder einesWorkers einnehmen, aber auch beide gleichzeitig. Die Manager ar- beiten kontinuierlichen an der Erreichung des vom Nutzer gewünschten Cluster-Zustands. Gibt es mehrere Manager, einigen sie sich untereinander mit einem Konsens-Algorithmus über den Zustand des Clusters. Die Worker bekommen Arbeit von den Managern zugeteilt und führen diese aus. [Doc22f] 27 Der Nutzer definiert Applikationen, die er auf dem Cluster betreiben will, als Services. Zu einem Service gehört ein Container-Image sowie Definitionen zu der Vernetzung mit anderen Services, geöffnete Ports, CPU- und Speicherbeschränkungen, Anzahl an der Replika-Tasks etc. [Doc22d] Arbeit wird in Form von Tasks verteilt. Ein Task ist eine Anweisung zur Ausführung eines Containers, die der Orchestrator auf Grundlage des gewünschten Cluster-Zustands erstellt. Tasks können immer Services zugeordnet werden. Ein Service wird skaliert, indem zusätzliche Tasks generiert und verteilt werden. [Doc22d] 2.7. Software-Modularität Die Eigenschaften eines Software-Systems werden zum großen Teil von dessen Architektur bestimmt. Verschiedene Komponenten eines Systems zu modularisieren geht mit Vor- und Nachteilen einher, die sich meistens analog auch bei der Gestaltung von physischen Systemen finden lassen. Nach Balzert [Bal09, S. 41] ist ein Modul eine funktionelle Einheit begrenzten Umfangs, die in sich abgeschlossen und unabhängig vom Kontext entwickelt und getestet werden kann. Die Schnittstellen des Moduls nach außen sollen klar definiert sein. Vorteile Ein großer Vorteil der Nutzung vonModulen ist derenWiederverwendbarkeit. Hochwertige Module, die sich in der Praxis schon bewiesen haben, können auch in einem neuen Projekt Verwendung finden. Dadurch kann dessen Qualität unter großen Einsparungen von Zeit und Ressourcen gesichert werden [VFN20, S. 3]. Modulare Systemteile lassen sich leichter ersetzen und erweitern, besser warten und überprüfen und können in großen Teams zu einer produktiveren Zusammenarbeit führen [Bal09, S. 42]. Die Austauschbarkeit fördert außerdem die Standardisierung der Komponenten, da verschiedene Ausführungen eines Moduls mit dem Gesamtsystem kompatibel sein müssen, um gleichermaßen einsetzbar zu sein. Modularisieren bedeutet vor allem abstrahieren [Bal09, S. 42]. Ein modularer Ansatz fordert vom Entwickler ein abstrakteres Denken, welches zu einer klareren Struktur der 28 Software führen kann. Bei monolithischer (aus einem Stück bestehender) Software hinge- gen kann eine fehlende Trennung der Funktionalitäten zu erschwerter Verständlichkeit führen. Nachteile Falls eine Abstrahierung aber gar nicht nötig oder hilfreich ist, kann eine vor allem zu fein granulierte Modularität jedoch unnötige Komplexität und Rechenaufwand bedeuten. Deshalb kann bei kleinen, experimentelleren Systemen, die nicht längere Zeit verwendet werden sollen, eine monolithische Softwarearchitektur den Entwicklungsaufwand senken und überflüssige Rechenkosten vermeiden. Modularisierung wirft außerdem neue Herausforderungen auf. Besonders in der Domäne der verteilten Systeme führt sie zu der Notwendigkeit von schnellem, Durchsatz-starkem und zuverlässigem Datentransfer innerhalb eines Systems, welcher nicht immer gegeben ist oder garantiert werden kann. Granularität Wie in Abschnitt 2.3 schon angeschnitten ist die Granularität der modularen Architektur einer der definierenden Kennwerte. Kleinere Module verstärken die Vorteile der Modu- larität, wie die Wiederverwertbarkeit, aber auch deren Nachteile, wie die Belastung der Datenleitungen [VFN20, S. 11]. 2.8. Service-orientierte Architektur Die Service-orientierte Architektur (SoA) ist eine Art und Weise, die Funktionalitäten eines Programmes zugänglich zu machen. „SoA ermöglichen es, vormals monolithische, komplexe Softwaresysteme zu modularisieren.“ [C M+06, S. 12] Ein Service in der SoA zeichnet sich durch folgende Eigenschaften aus [C M+06, S. 12, 13]: 1. Der Zugang zu den Funktionalitäten des Services erfolgt über festgelegte Schnitt- stellen. 2. Der Service-Provider ist agnostisch gegenüber der Identität des Service-Konsumenten. 29 3. Der Service-Konsument kennt nicht die konkrete Implementierung der Services. 2.8.1. Microservices Der Begriff Microservice bezeichnet den Baustein einer Architektur, in der die atomaren Funktionen einer Applikation in einzelne, unabhängige und zustandslose Services auf- geteilt werden. Die Microservice-Architektur kann daher als ein spezifischer Einsatz des Prinzips der Software-Modularität (siehe Kap. 2.7) betrachtet werden. Die Transformation hin zu einer Microservice-Architektur geschieht vor allem mit der Absicht, die Applikation zu skalieren, indem die Instanzen einzelner Microservices vervielfältigt werden [Nis+22]. Da diese klein sind, ist die feine Einstellbarkeit der Skalierung möglich. Einzelne Funktio- nalitäten können so abhängig von der Verteilung der Belastung innerhalb einer Applikation skaliert werden [Nis+22]. 2.9. Message-oriented Middleware Message-Oriented Middleware (MOM) ist Software zur Kommunikation in verteilten Systemen. MOMwird zwischen heterogene Teilnehmer eines verteilten Systems geschaltet, um einheitlich und zuverlässig Nachrichten austauschen zu können [Yon+19, S. 88]. Die Fähigkeiten von MOM umfassen die Komposition einer Nachricht sowie deren Handhabung über den gesamten Lebenszyklus. Sie umfasst zudem meist Sicherheitsmechanismen, Transaktionsgarantien, Monitoring und abhängig von der konkreten Software weitere Funktionalitäten [Yon+19, S. 89]. Der große Vorteil von MOM ist die lose Kopplung der Teilnehmer. Ein Client bringt eine Nachricht an die MOM an, die sich um den gesamten Transport kümmert [Cur05, S. 5]. Oft wird ein Broker eingesetzt, ein separates Programm, das zwischen Absender und Empfänger verortet ist und die Nachrichten weiterleitet. Dadurch muss jede Seite nur den Broker, nicht den Absender oder Empfänger einer Nachricht kennen. MOM stellt unabhängig vom Einsatz eines Brokers eine neutrale Ebene zwischen Absender und Empfänger dar, sodass diese sich nicht strikt aufeinander abstimmen müssen [Cur05, S. 5]. Zwei der Zustellungsmodi von MOMs sind Point-to-Point und Publish-Subscribe. Bei Point-to-Point werden Nachrichten von einem Absender zu einem explizit genannten Emp- fänger gesandt. Publish-Subscribe zeichnet sich dagegen dadurch aus, dass vom Absender 30 (Produzent) eine Nachricht mit einem bestimmten Topic produziert und veröffentlicht wird (publish). Mehrere Konsumenten können dieses Topic abonnieren (subscribe) und empfangen dann entsprechende Nachrichten. [Yon+19, S. 90] 2.10. ZeroMQ ZeroMQ ist ein Messaging-Framework, das keine Broker benötigt (brokerless architecture) und spezifisch für verteilte Systeme entwickelt ist [Zer22a]. Durch die Vermeidung eines Brokers können Ressourcen eingespart, Bottlenecks/Single Point of Failures verhindert und der Nachrichtenweg verkürzt werden. Dadurch wird ein hoher Durchsatz und niedrige Latenz erzielt [Yon+19, S. 95], jedoch Flexibilität eingebüßt, da Kommunikationspartner sich gegenseitig kennen müssen und nicht nur einen zentralen Broker. ZeroMQ führt in Untersuchungen von Sommer et al. [Som+18, S. 1221] sowohl in Latenz als auch Durchsatz gegenüber Apache Kafka, AMQP und MQTT. Da es jedoch in seinem Umfang minimal ist, fällt es bezüglich zusätzlicher Funktionalität hinter den anderen zurück [Som+18, S. 1222]. Auch wenn ZeroMQ aufgrund des fehlenden Brokers streng genommen nicht als vollwer- tige MOM gezählt werden kann [Som+18, S. 1220], erfüllt es dieselben Aufgaben. Die Nutzung der API von ZeroMQ erfolgt unabhängig von der Transportart (TCP, inter-process, Websocket etc.). Diese wird während der Laufzeit des Programmes ausgewählt [Zer22a]. Tasci et al. sprechen ZeroMQ aufgrund niedriger Latenzzeiten eine prinzipielle Eignung für Echtzeitsysteme zu [TMV18, S. 5]. Die Entwickler von ZeroMQ konnten zeigen, dass bei Verwendung auf einem Linux-Betriebssystem mit Real-Time Kernel (siehe Kap. 2.5) Latenzspitzen vermieden werden können [Zer22b]. Es konnten im Test Latenzen über 75 Mikrosekunden ausgeschlossen werden. Dieser Determinismus ist unabdingbar für den Betrieb in Echtzeit. 2.11. Bestehende Konzepte zur Containerisierung von Digitalen Zwillingen Wie in 1.3 erwähnt, wurde in einigen wenigen wissenschaftlichen Arbeiten schon die Containerisierung von allgemeinen DT-Strukturen behandelt. 31 2.11.1. Der Digitale Zwilling im Cloud- und Fog-Computing Borodulin et al. [Bor+17] schlagen die Migration des DT in die Cloud vor. Dies sei eine Lösung für die Anforderung an Performance und Flexibilität des DT. Ein detailliertes Konzept stellen sie in ihrem Paper nicht vor. Alternativ zum Betrieb des DT in der Cloud steht der Einsatz in einer Fog-Computing- Umgebung. Fog-Computing ist ein Konzept, welches zwischen den Smart-Devices (Senso- ren, Maschinen, genannt Edge) und der Cloudmehrere Ebenen mit sogenannten Fog-Nodes ansiedelt [Ior+18]. Diese sind geografisch verteilte aber zusammenarbeitende Rechenein- heiten, die näher an den Smart-Devices sind als die Cloud-Server. Fog-Nodes verarbeiten von Smart-Devices kommende Daten und senden nur nicht-Latenz-kritische Daten weiter an die Cloud. Das verringert die Latenz und erhöht den möglichen Durchsatz. [Ior+18, S. 2] Alaasam et al. [Ala+20] schlagen den Betrieb eines DT in solch einer Fog-Computing- Umgebung vor. Ihr Augenmerk liegt auf der Verarbeitung von Event-Streams, also konti- nuierlichen Strömen an Daten von z. B. Sensoren, durch den DT in der Fog-Umgebung. Verarbeitet werden die Datenströme mit Apache Kafka, einer speziell dafür zugeschnittene Software. Untersucht wird dabei vor allem das Verhalten während der Migration des DT zwischen Hosts in der Fog-Umgebung. Diese Migration ist eine wichtige Fähigkeit, um Ausfallsicherheit zu gewährleisten. Das Paper beschreibt vor allem die Schwierigkeit, die der Betrieb von Zustands-behafteten Services in der Fog-Umgebung bereitet. 2.11.2. IF-DTiM Die Entwickler des Implementation Framework of Digital Twins for Intelligent Manufactu- ring (IF-DTiM) schlagen die Containerisierung von DT-Applikationen mittels Docker und den Betrieb im Cluster mit Kubernetes vor [Hun+22]. Das Konzept geht auch darüber hinaus auf Aspekte der Künstlichen Intelligenz, Virtuellen Realität und weitere im Rahmen dieses Konzeptes ein. Es wurde gezeigt, dass durch die Containerisierung eine größere Anzahl verschiedener „Intelligent Services“ und Cloud-Services im Plug-and-Play Stil eingebaut werden können. Die in sich abgeschlossenen Images, das schnelle Deployment, Fehlertoleranz, Autoscaling und Load Balancing sind weitere genannte Vorteile [Hun+22, S. 15]. Die Kommunikation läuft ähnlich wie bei [Ala+20] (siehe 2.11.1) über die Event-Streaming- Plattform Apache Kafka. Im Best Effort konnten mit dem Kafka-Cluster zuungunsten der 32 Fehlertoleranz Latenzen von 1,13ms erreicht werden [Hun+22, S. 13], sie bewegt sich da- mit gerade noch im von Hinze hinnehmbaren Bereich von Latenzen in Steuerungssystemen in der Industrie (siehe Kap. 2.5). Anstatt jedoch den DT selbst zuModularisieren, werden die intelligenten Applikationen aus dem DT herausgetrennt und containerisiert [Hun+22, S. 4]. Diese rechenaufwändigen Services laufen in einem Container-Cluster in der Cloud, während die DTs in einem Container-Cluster an der Edge, also in geografischer Nähe der Maschinen betrieben werden (siehe 2.11.1). Das Konzept schlägt nicht explizit die Containerisierung einzelner interner Teile des DT vor, es wird jedoch angemerkt, dass der Betrieb von DT-Applikationen in Microservice-Architektur möglich sei [Hun+22, S. 7]. 33 3. Konzept zur Modularisierung des Digitalen Prozesszwillings Ausgehend vom Stand der Technik aus Kapitel 2 werden in diesem Kapitel Anforderungen an das Konzept eines Containerized Modular Digital Process Twin (CMDPT) entwickelt und dessen Charakteristika erläutert. Die Charakteristika sind wichtig für die Begründung der CMDPT-Architektur, die in zwei unterschiedlichen, aber aufeinander aufbauenden Konzeptionierungen ausgearbeitet wird. Die Konzeptionierung des CMDPT im Cluster (Kap. 3.4) birgt einen signifikanten Mehrwert zu der auf einem einzelnen Host (Kap. 3.3), ist jedoch mit einer erhöhten Komplexität und größerem Hardware- und Rechenaufwand verbunden. Entsprechend unterscheiden sich die Anwendungsfälle. 3.1. Anforderungen Zu Beginn der Forschungsarbeit stand das Ziel einer modularen Architektur des DPT und damit verbundener Funktionsweisen. Aus diesem Ziel, den Definitionen von DPT (Kap. 2.2) und Modul (Kap. 2.7), sowie dem nach weiterführenden Überlegungen entwickelten gewünschten Nutzen des Konzeptes ergeben sich folgende Anforderungen. Diese dienen als Grundlage für die zielgerichtete Entwicklung des Konzeptes des CMDPT in Kapitel 3.3. Folgende Anforderungen ergeben sich aus der zu dieser Arbeit führenden Zielsetzung eines modularen DPT mit bestimmter Funktionsweise: 1. Modulare Architektur des DPT, 2. Fähigkeit der flexiblen Verknüpfung der Module, 3. Unabhängigkeit der Module von der ausführenden Ressource, 4. Auslagerungsfähigkeit von Modulen auf externe Ressourcen. 34 Aus der Definition des DPT (Kap. 2.2) ergeben sich folgende Anforderungen: 5. Existenz von jeweils eigenen Modulen für (siehe Abb. 2.2 in Kap. 2.2): a) Digital Process Twin Interface, hier Human-Machine Interface (HMI) genannt, b) Data Storage, bestehend aus Manifest and ID, Operational Data Storage und Technical Data Storage, c) Digital Process Twin Models and Services, hier Functionalities genannt, d) Digital Process Twin Communication and Aggregation, hier Machine-Machine Interface (MMI) genannt. 6. Alle nicht unter 5. aufgezählten möglichen Erweiterungen des DPT müssen sich unkompliziert Modularisieren lassen. Aus der Definition eines Moduls (Kap. 2.7) ergeben sich folgende Anforderungen: 7. Kontextunabhängigkeit der Module, 8. Eigenständige Existenz der Module, 9. Existenz einheitlicher Schnittstellen der Module, 10. Kommunikationsfähigkeit der Module untereinander und nach außen. Um einen signifikanten Mehrwert zu bieten, werden vom Autor selbst folgende Anforde- rungen gestellt (in kursiv folgt die Begründung): 11. Es gibt keine nicht-containerisierten Module des DPT, um vollständige Portabilität zu gewährleisten. 12. Die Module sollen als Microservice ausgelegt und daher nur lose gekoppelt sein, um die Skalierbarkeit in einer SoA zu gewährleisten (siehe Kap. 2.8). 13. Die Module des DPT sind bezüglich ihrer zugewiesenen Ressourcen über mehrere Hosts hinweg skalierbar, eine Erweiterung der Anforderung 4, um stets die nötigen Ressourcen bereitzustellen, aber auch keine Rechenressourcen zu verschwenden. 14. Es gibt einen zentralen Speicherort für alle Container-Images für einen praktischen Entwicklungsprozess und unkompliziertes Deployment. 35 3.2. Charakteristika Im folgenden Abschnitt sollen die Prinzipien der Containerisierung und Modularisie- rung des DPT erläutert werden. Zusammen ergibt dies die gewünschte charakteristische Beschreibung eines Containerized Modular Digital Process Twin (CMDPT). 3.2.1. Modularität des DPT Die Modularisierung eines DPT führt zu einer signifikanten Änderung von dessen System- eigenschaften. Diese werden im Folgenden beschrieben, noch unbeachtet der Containe- risierung der Module. Daraus folgen die Gründe für die Modularisierung des DPT, bzw. auch allgemeiner des DT. Reduktion der Kompliziertheit Digitale Zwillinge, vor allem im ausgereiften Stadium, sind komplizierte Systeme. Das Verhalten von komplizierten Systemen ist berechenbar, doch die Anzahl der Komponenten ist groß und die Funktionsweise ist nur für Experten wirklich zugänglich [SM11, S. 68]. Eine Modularisierung des DT schafft klare Abstraktionsebenen (siehe Kap. 2.7), die allen Anwendern beim Verständnis des Systems helfen können. Ein Physiker, der die Simulationen für den DT entwickelt, muss sich so nur mit der standardisierten Schnittstelle des DT für Simulationsdaten auseinandersetzen, und kann den Rest vernachlässigen. Arbeitsteilung Eine vollständige Arbeitsteilung für die verschiedenen Teile des DPT kann nur mit Modulen stattfinden. Firma X und Firma Y könnten durch den Einsatz von Modulen unabhängig voneinander Module A und B für den DPT entwickeln, ohne voneinander oder der spe- zifischen Realisierung des DPT abhängig zu sein. Dies erlaubt Spezialisierung und ist vorteilhaft für die langfristige Weiterentwicklung des DPT. Die Einbindung von allgemei- nen Container-Modulen wie Datenbanken als generische Images in den DPT ist schon jetzt mit geringem Zeitaufwand und Wissen möglich (siehe Implementierung, Kapitel 4). Die Entwickler solcher Images müssen keinerlei Bezug zum DPT haben. 36 Austauschbarkeit Da Module kontextunabhängig sind und über festgelegte Schnittstellen verfügen (2.7) sind sie leicht austauschbar. Der Lebenszyklus der Module ist nicht mehr von dem des DPT abhängig. So kann ein DPT auf undefinierte Zeit betrieben werden. Nach und nach können einzelne Module durch neuere ersetzt werden. Wiederverwertung, Wartung, Erweiterung Die einzige Voraussetzung für den Betrieb eines Moduls in einem beliebigen Umfeld ist, dass dessen Schnittstellen kompatibel sind. Gibt es eine Standardisierung, ist dies gegeben. Dadurch können Module in neuen Projekten wiederverwertet und ohne Probleme erweitert werden. Außerdem wirkt sich die Modularisierung positiv auf die Wartbarkeit des DPT aus. Ein Spezialist bräuchte für die Wartung eines Moduls nur das spezifische Modul zu betrachten und könnte den Kontext vernachlässigen. Zumal kann Wechselwirkung, also ein Fehler eines Moduls aufgrund eines anderen Moduls, ausgeschlossen werden, insofern dieser nicht über eingehende Nachrichten zustande kam. Dies erleichtert die Fehlersuche im System enorm. Standardisierung Die Standardisierung der Module wäre für Modulentwickler und deren Kunden von großem Interesse. Das fördert die Standardisierung auf diesem neuen Gebiet. Schon der Erfinder des DT, Michael Grieves, sah Standardisierung bzw. Interoperabilität als ein wichtiges Vorhaben [Gri19, S. 30, 31] (siehe auch Kap. 2.1). Das Schichtensystem der modernen Container-Images ermöglicht zudem das Entwickeln von Modul-Basen, also Base-Images, die als Grundlage für eine Standardisierung in der Industrie 4.0 dienen könnten. 3.2.2. Modularität durch Container Wie in 2.3 gezeigt, zeichnen sich Container durch gute Performance und kompakte Images in der Software-Virtualisierung aus. Ein vollwertiges DPT-Modul kann massiv von der 37 Flexibilität und Portabilität der Virtualisierung und der Einfachheit in Konfiguration und Betrieb der Containertechnologie profitieren. Jedoch treten durch diese Synergie auch neue Herausforderungen auf. Im Folgenden soll genauer auf Gründe für und Probleme mit der Modularisierung des DPT durch Container eingegangen werden. Kontextunabhängigkeit Um als vollkommene Module nach Balzert (siehe Kap. 2.7) gelten zu können, müssen die DPT-Module unabhängig vom Kontext funktionieren und in sich abgeschlossen sein (Anforderung 7). Dies soll durch Containerisierung der Module erreicht werden. Ein Grund für die Virtualisierung ist die Unabhängigkeit von der Hardware und Isolation der Software (siehe Kap. 2.3). Der einzige benötigte Kontext für den Betrieb eines Containers ist die Container-Runtime und der Host-Kernel. Da diese in diesem Konzept als über alle Hosts homogener Kontext angesehen werden, kann ein Container-Modul wenn auch in einer schwachen Formulierung als kontextunabhängig gelten. Es soll zudem keine Abhängigkeiten (z. B. Bibliotheken) geben, die das Modul benötigt und die nicht im Container-Image enthalten sind. Das hat den Vorteil, dass die Installation eines DPT- Moduls sehr einfach und an keine Rahmenbedingungen geknüpft ist außer der Existenz der Container-Runtime. Portabilität Ein Programm, das virtualisiert gespeichert ist, benötigt keinen individuellen Installations- prozess. Durch die Isolation des Programmes vom Hostsystem und anderen Containern können außerdem keine Software-Konflikte entstehen. Das Programmverhalten sollte auf jedem Host identisch sein, da alle benötigten Abhängigkeiten mitgeliefert werden. Es kann also beispielsweise nicht sein, dass ein System-Update oder die neue Version einer Bibliothek oder SDK die Software untauglich macht, es sei denn, diese wird bewusst im Image aktualisiert. Die Startzeit eines Containers beträgt zudem üblicherweise nur wenige Sekunden und die Imagegrößen kompakter Programme sind unter 100 MB. Die Images können zügig heruntergeladen und die Container zeitnah gestartet werden. Das alles lässt sich als sehr gute Portabilität zusammenfassen. Diese Portabilität greift einige Probleme an, die vor allem in der Forschung präsent sind. Boettiger [Boe15, S. 72] fasst die Probleme zusammen, die eine große Herausforderung für 38 die Reproduzierbarkeit in der Forschung darstellen: Die Schwierigkeit, exakte Software- Bedingungen zu replizieren 1. da Code oft eine unüberschaubare Anzahl an Abhängigkeiten besitzt, 2. wenn der Installationsprozess der Software schlecht dokumentiert ist, 3. die Abhängigkeiten regelmäßige Updates erhalten („code rot“). Der DPT ist noch größtenteils ein Forschungsthema, die Schwierigkeiten können aber auch auf die Industrie übertragen werden. Die Portabilität von Containern verhindert diese Probleme, wenn Forscher ihre Software als Images bereitstellen. Gleiches gilt analog auch für die Industrie-Praxis. Zusätzlich könnten Forscher, die eine Arbeit replizieren wollen und nicht die nötige Rechenleistung zur Verfügung haben, Container leicht auf Cloud-Plattformen auslagern [Boe15, S. 75]. Dies ist die geforderte Auslagerungsfähigkeit der Module (Anforderung 4). Die Portabilität der Container konnte sich im Projekt IF-DTiM (siehe 2.11.2) im DT-Kontext schon bewähren: Die Autoren merken das “standard and effortless software packaging and deployment” [Hun+22, S. 4] positiv an. Aus der Portabilität lässt sich eine besondere Prädestination der Containertechnologie für die Modularisierung des DPT ableiten. Die Portabilität ermöglicht, dass Module, gleich wie beispielsweise ein Elektromotor oder eine Lagerung, ohne Probleme Hersteller- und Projektübergreifend unkompliziert und schnell eingesetzt und auch wieder ausgebaut werden können. Skalierbarkeit und Hochverfügbarkeit Eine Literaturstudie aus 2022 nennt die Skalierbarkeit des DT als in der Forschung be- trachtete Problematik [BB22, S. 11]. Die Skalierbarkeit von auf Containerbasis-Architektur gebauten Systemen ist gerade zurzeit ein Hauptgrund für deren Einsatz in der Cloud- Computing-Industrie (siehe Kap. 1.1). Die Container-Engine kann einem Container System- Ressourcen dynamisch zuweisen oder entziehen. Damit wird die Ressourcennutzung optimiert und längerfristige Überlastung verhindert. In Clustern (siehe Kap. 2.4) können Anwendungen auf Rechnernetzen betrieben werden, in denen die Anzahl und Verteilung der Container so gewählt wird, dass der Rechenaufwand aufgeteilt (Skalierbarkeit und Load-Balancing) und der Ausfall von Hosts kompensiert werden kann (Hochverfügbarkeit). Skalierbarkeit, Load-Balancing und Hochverfügbarkeit 39 der Cluster konnten im Projekt IF-DTiM (siehe 2.11.2) klare Vorteile für DT-Systeme darstellen [Hun+22, S. 15]. Für den Betrieb im Cluster oder in der Cloud ist für DTs die in 3.2.2 besprochene Echtzeit- problematik sowie die erhöhte Latenz kritisch. Dem Latenz-Problem der Cloud kann mit dem alternativen Betrieb des DT in einer Fog-Computing-Umgebung begegnet werden, siehe 2.11.1. Probleme in der Datenübertragung Auch wenn Container als Virtualisierungstechnik mit geringem Overhead verstanden werden, kann dieser beim Datentransfer nicht vernachlässigt werden. Kratzke [Kra17, S. 3] konnte eine Verschlechterung in der Transferrate bei containerisierten Applikationen von ca. 10 % für Pakete über 100 kB bis zu 20 % für Pakete unter 100 kB nachweisen. Dies ist auf den zusätzlichen Overhead im Networking zurückzuführen. Des Weiteren ist klar, dass isolierte Module auf die Kommunikation untereinander ange- wiesen sind. Das führt zu sehr hohen Anforderungen an die Bandbreite, Zuverlässigkeit und Schnelligkeit der Kommunikation untereinander, vor allem bei Echtzeitanwendungen wie dem DT. Grieves listete die Datenflut, die zur genauen Simulation des DT nötig ist, in seiner Aufzählung bestehender Probleme des DT, siehe Kap. 2.1. Bei hochperformanten oder kritischen Anwendungen muss dieser Punkt also ausführlich geprüft werden. Es konnte aber gezeigt werden, dass zumindest die durchschnittlichen Latenzen der con- tainerisierten Software ausreichend sind für viele Industrieanwendungen (Zykluszeiten ungefähr 1ms [MSF16, S. 1839]) [Hin+19, S. 72]. Echtzeitproblematik Aus der Forderung, ein Digitaler Zwilling solle die Realität möglichst genau abbilden, lässt sich ableiten, dass die Datenverbindung zwischen physischem und digitalen Zwilling in Echtzeit stattfinden muss. Jede Aktion des Zwillingspaares muss also in einer fest garantierten Zeit ausgeführt werden können. Handelsübliche Personal Computer garantieren dies bei keiner ihrer Berechnungen. Es muss im Zweifelsfall der besondere Aufwand betrieben werden, Con- tainer in Echtzeit zu betreiben (siehe Kap. 2.5). Dieses Forschungsgebiet ist noch nicht 40 ganz erschlossen: Struhár et al. [Str+20, S. 7, 8] kritisieren u. a. die fehlenden Werk- zeuge für den verlässlichen Einsatz von Echtzeit-Containern, fehlende Erforschung von Echtzeit-Container-Kommunikation, sowie fehlende Sicherheitsanalyse zum Betrieb von Echtzeit-Containern. Dies stellt noch ein Hindernis für den CMDPT dar. Der Einsatz des CMDPT wird daher vom Autor vorerst für echtzeitkritische Applikationen nicht empfohlen. 3.3. Konzeptionierung für nicht-verteilte Systeme In diesem Abschnitt wird die Architektur des Konzepts entwickelt, das die in Kapitel 3.2 be- schriebenen Charakteristika der Modularisierung des DPT durch Containerisierung besitzt, den sogenannten Containerized Modular Digital Process Twin (CMDPT). Die Architektur, dargestellt in Abbildung 3.1, konkretisiert vor allem die notwendige Infrastruktur, die für den Betrieb von Container-Modulen nötig ist. Zunächst wird sich auf den Einsatz der Container auf einem einzelnen Host fokussiert. In Kapitel 3.4 wird diese Architektur auf den Betrieb im Cluster ausgeweitet. Rahmenbedingungen sind dabei weiterhin die in Kapitel 3.1 aufgeführten Anforderungen an das Konzept. 3.3.1. Container-Infrastruktur Die Entwicklung des Konzepts beginnt mit der Bereitstellung der notwendigen Container- Infrastruktur, ohne die der Betrieb des CMDPT nicht möglich wäre. Der DPT läuft nach Anforderung 11 in seiner Gesamtheit containerisiert in der Container-Runtime. Dies ist erforderlich, um die Portabilität des DPT zu gewährleisten und alle Vorteile der Containe- risierung zu nutzen. Die Container-Runtime wird in Abb. 3.1 als Teil der Container-Engine gehandelt (siehe 2.3.3). Die Container-Runtime selbst muss auf dem Host manuell installiert werden. Es empfiehlt sich die Installation einer Container-Engine, die die Container-Runtime und zusätzliche Werkzeuge für den Umgang mit Containern enthält, insbesondere auch einen Container- Manager. Der User kann diese Werkzeuge benutzen, um die Module des CMDPT her- unterzuladen und zu starten. Soll die Verwaltung des CMDPT über das Administrative Interface (siehe 3.3.3) erfolgen, wird dieses Modul zuerst manuell gestartet. Danach kann der CMDPT über das Admin-Interface zusammengestellt werden. 41 Abbildung 3.1.: Single-Host-Architektur des Digitalen Prozesszwillings mit containerisier- ten Modulen CMDPT Die Werkzeuge der Container-Engine sind auch nach Start aller Module sehr hilfreich für den Betrieb des CMDPT. Die Container und damit auch die Module können während der Laufzeit des DPT mit dem Container-Manager dynamisch aktualisiert oder ausgetauscht werden, manuell oder über das Admin-Interface. Neue Module können hinzugefügt und 42 Verbindungen zwischen den Modulen modifiziert werden. Für maximale Flexibilität enthält jeder Container genau ein Modul. Wären mehrere Module in einem Container enthalten, wären diese nicht mehr kontextunabhängig und eigenständig ausführbar. Damit wären Anforderungen 7 und 8 verletzt. Außerdem ließen sich die Module nicht unabhängig voneinander austauschen (siehe 3.2.1). Die genaue Granularität der Module muss nach den in 2.7 genannten Abwägungen gewählt werden. 3.3.2. Image-Repository Das Image-Repository ist der Speicherort für die Images aller Module des CMDPT. Damit wird Anforderung 14 erfüllt. Die Container-Engine bezieht ihre Images stets von einer oder mehreren dieser Repositories. Jeder Entwickler von Modulen des CMDPT kann ein eigenes Repository besitzen, auf dem dessen Software-Images abgelegt werden. Viele nicht-DPT-spezifische Module wie SQL-Datenbanken oder Webserver liegen häufig bereits als Images auf öffentlichen Image-Repositories (z. B. Docker-Hub) vor und können ohne Probleme direkt von dort bezogen werden. Der CMDPT ist also keinesfalls auf ein Image- Repository als Quelle der Images beschränkt. Jedoch sollte bestenfalls ein betriebseigenes Image-Repository existieren, das alle Images (als Kopie) hält, um von externen Ausfällen nicht betroffen zu sein. 3.3.3. Modul-Ebenen des CMDPT Die grundlegende Modul-Struktur des CMDPT geht aus dem DPT-Konzept von Kempf et al. [Kem+21] hervor (siehe Anforderung 5). Die Ebenen des CMDPT werden davon aus- gehend zum einfacheren Verständnis neu benannt. So entstehen die Kategorien „Human Interface“ (HMI), „Data“, „Functionality“ und „Machine Interface“ (MMI). In Abbildung 3.1 ist auf der Ebene „Functionality“ die Erweiterbarkeit durch weitere Funktionalitäten als Module angedeutet. Im Realfall werden einige Module hier eingefügt werden müssen, damit der Einsatz des DPT zu nennenswerten Vorteilen für die Produktion führt. Die hier abgebildete Anzahl an Containern soll daher nicht final sein. 43 Human-Machine Interface Auf der Human-Machine Interface Ebene existieren zwei Module für den Zugriff auf den CMDPT durch Menschen. Es existiert das User-Interface, das Zugriff auf das Frontend vom DPT gibt. Das ist eine Schnittstelle, die einem technischen Mitarbeiter die Möglichkeit gibt, den Produktionsprozess selbst zu überwachen und zu steuern. Ein generisches User-Interface gibt es nicht, es muss von Modulen geliefert werden. Außerdem gibt es das Admin-Interface, das nutzerfreundlichen Zugriff auf die Verwaltung der einzelnen Module und die Container-Engine gibt. Dieses ist generisch und nicht abhän- gig von einem DPT-Anwendungsfall, wie das User-Interface. Das Admin-Interface muss lediglich Instruktionen an die Container Engine weitergeben und grafische Oberflächen anzeigen. Im Admin Interface können die Logs gelesen, Module gestartet, gestoppt oder ausgetauscht werden. Das Management des CMDPT kann nach Instanziierung des Admin-Interface- Containers darüber erfolgen. Alternativ kann der Admin bei Kenntnis der Container-Engine auch direkt mit dem passenden Command Line Interface arbeiten. Das Admin-Interface ist also kein zwingend notwendiges Modul. Data-Ebene Die Data-Ebene enthält exklusiv den Zustand des DPT (siehe 3.3.4). „Manifest and ID“ enthält eine Selbstbeschreibung des CMDPT. Dazu gehört eine Identifikationsnummer und eine Beschreibung des Aufbaus des CMDPT. „Operational Data Storage“ enthält alle Daten, die für den Betrieb des CMDPT relevant sind. Dazu gehören unter anderem Simulationsdaten, Prozessdaten und Produktdaten. „Technical Data Storage“ enthält Modelle und Dokumente zu dem Produktionsprozess und den Modulen. Functionality-Ebene Auf der Functionality-Ebene existieren alle Services, die der DPT anbietet und die nicht zu einer der anderen Ebenen gehören. Dazu gehören z. B. Simulationen, die Orchestrierung des Produktionsprozesses, das Erstellen von Product-DTs etc. Zu Beachten ist, dass die Services auf dieser Ebene keinen Zustand halten dürfen, sondern dafür auf das Operational Data Storage zugreifen. 44 Machine-Machine Interface Die Machine-Machine-Interface-Ebene ist zuständig für jegliche Kommunikation nach außen zu anderen Maschinen bzw. DTs. Angedacht sind an dieser Stelle vor allem die DTs der Produktionsmaschinen sowie andere DPTs. 3.3.4. Volumes und Zustand Dass alle Module des CMDPT containerisiert sind, hat zur Folge, dass die Module an sich zustandslos sind. Container haben keinen beständigen Speicher (siehe Kap. 2.3). Der Zustand des CMDPT besteht aus dessen eigener Struktur, die durch die Modularisie- rung dynamisch ist, und den in den Volumes gespeicherten Daten. Ersteres wird von der Container-Engine selbst, sowie als Selbstbeschreibung im „Manifest and ID“ gespeichert. Volumes sollen ausschließlich in der Daten-Ebene des CMDPT existieren, um eine klare Trennung von Daten und Funktionalität/Logik sicherzustellen. Davon profitiert vor allem die Skalierbarkeit des CMDPT im Container-Cluster (siehe Kap. 3.4), da eine Microservice- Architektur begünstigt wird. 3.3.5. Modul-Basis als Base-Image Um Kompatibilität zwischen den verschiedenen Modulen zu vereinfachen, existiert eine Modul-Basis, die vor allem Funktionen zur Kommunikation zwischen den Modulen bereit- stellt. Die Kommunikation wird dadurch nicht mehr Aufgabe der Modul-Entwickler sein. Das fördert die Einheitlichkeit der Module. Jedes Modul-Image baut auf diesem Base-Image auf und erbt damit dessen Funktionalitä- ten (siehe Kap. 2.3). 3.3.6. Service-orientierte Architektur Die Art der Interaktion der Module miteinander wird über die Service-orientierte Ar- chitektur bestimmt (siehe Kap. 2.8). Jedes Modul agiert als Server (Service-Provider), als Client (Service-Konsument) oder beides. Ein Server empfängt Anfragen (requests) und verarbeitet und beantwortet sie unabhängig vom Anfrager. Diese Service-Architektur 45 ermöglicht es, „vormals monolithische, komplexe Softwaresysteme zu modularisieren“ [BV20, S. 12]. 3.3.7. Kommunikation Da die Container-Prozesse voneinander isoliert sind, müssen sie über Netzwerkschnittstel- len miteinander kommunizieren. Die Container-Engine erstellt und verwaltet ein CMDPT-internes Netzwerk, dem alle Container des CMDPT angehören. Das öffnet die Transportwege für die Kommunikation, ohne Kommunikation nach außen zuzulassen, die nicht speziell eingerichtet ist. Damit die Austauschbarkeit der Module funktionieren kann, muss jedes Modul über klare Kommunikationsprotokolle verfügen. Dies ist ebenso eine Anforderung der SoA (siehe Kap. 2.8). Es wird eine MOM in der Modul-Basis eingesetzt, die den größten Teil des Nachrichtensystems bereitstellt. Es muss aber weiterhin Absender und Empfänger bekannt sein, welche Art von Nachrichten das jeweils andere Modul empfängt und sendet. Das wird in einem Nachrichtenprotokoll spezifiziert. Es wird ein Beispiel für solch ein CMDPT-Nachrichtenprotokoll angeführt: Es steht fest, dass Modul A eine Anfrage an Modul B stellen kann, die die Nachricht „GET_COORDI- NATES“ enthält. Modul B antwortet darauf mit einer Bestätigung und den Koordinaten. Jedes Modul von Typ A oder B von einem anderen Hersteller kann problemlos eingebaut werden, wenn es dieses Protokoll implementiert. Die Adressen der Server/Service-Provider können bei den Clients/Service-Konsumenten über Umgebungsvariablen im Container festgelegt werden, eine Funktionalität, die von den Container-Engines geliefert wird. Damit lassen sich die Module einfach und schnell neu verknüpfen (Anforderung 2). Die Adressen der Container liegen entweder in Form von IP- Adressen oder als Domain-Namen bei Vorhandenseins eines DNS-Servers in der Container- Engine vor. Letzteres ist aufgrund der größeren Flexibilität deutlich vorzuziehen und ist als verbreitetes Werkzeug zumindest bei Docker und Kubernetes vorhanden [Doc22h] [Kub22]. 3.3.8. Auswahl einer geeigneten Messaging-Technologie In [Yon+19] wird eine Auswahl moderner MOMs verglichen. Darunter sind MQTT, Apache Kafka, RabbitMQ, ActiveMQ, RocketMQ und ZeroMQ. 46 Da das Konzept des DPT trotz der Erweiterbarkeit mit beliebigen Modulen feste Kom- munikationswege zwischen den Modulen vorsieht, eignet sich eine Publisher-Subscriber Architektur (siehe Kap. 2.9) prinzipiell weniger. Pub-Sub eignet sich eher für lose Verknüp- fungen und Systeme, bei denen mehrere Teilnehmer Nachrichten aus dem gleichen Pool abgreifen. Publish-Subscribe ist hauptsächlich für unidirektionale Kommunikation mit vielen Konsumenten konzipiert, die DPT-Module sollten aber bidirektional kommunizie- ren können [Mic22]. Es steht im DPT zudem ein Produzent eher wenigen Konsumenten gegenüber, die unterschiedliche Informationen benötigen. Stattdessen soll ein Point-to-Point Zustellsystem verwendet werden. Point-to-Point wird jedoch weder von Kafka noch MQTT unterstützt [Yon+19, S. 94]. Yonggue et al. empfehlen ZeroMQ für Anwendungen, bei denen Performance Priorität hat [Yon+19]. Im Experiment durch Sommer et al. [Som+18, S. 1221] führt ZeroMQ sowohl in Latenz als auch Durchsatz gegenüber Apache Kafka, AMQP (implementiert von RabbitMQ [Yon+19, S. 95]) und MQTT. Da Performance ein kritischer Faktor in DT-Anwendungen ist (siehe Kap. 2.1), wird der Empfehlung nachgekommen. Für den Einsatz sprechen auch die weiteren Eigenschaften von ZeroMQ wie Abwesenheit eines Brokers und Eignung für Echtzeit-Anwendungen, die in 2.10 erläutert sind. 3.3.9. Auswahl geeigneter Containertechnologien Auch wenn das vorgeschlagene Konzept nicht auf eine spezifische Container-Engine auf- baut, wird an dieser Stelle eine Auswahl an geeigneten Technologien diskutiert. Hierbei werden grundsätzlich nur aktiv gepflegte Projekte in Betracht gezogen, um eine Zukunfts- perspektive zu schaffen. Gesucht wird ein Container-Manager (zu den Unterschieden zwischen Engine, Manager etc. siehe 2.3.3), der Werkzeuge für den gesamten Container- Lebenszyklus mitbringt. Die Containertechnologie sollte Open-Source sein und den OCI- Standard unterstützen. In diesem Fall kann der Manager mit allen gängigen Images, und auch denen, die im Rahmen dieses Konzeptes entstünden, umgehen. Damit kommen vor allem Docker, Podman (https://podman.io/) und Apptainer (http://apptainer.org/) in Betracht. Docker ist der de-facto Industriestandard für Container-Manager (siehe 2.3.3). Das IF-DTiM, ein großes Projekt, das Container im DT-Kontext einsetzt (siehe 2.11.2), verwen- det Docker. Die Docker-Engine enthält zudem den Container-Orchestrator Docker-Swarm, der aber in einem nicht-verteilten Einsatz keine Verwendung findet. Für eine ausführliche Beschreibung von Docker wird auf 2.6 verwiesen. 47 Podman ist eine Container-Engine, die das Command Line Interface von Docker übernimmt aber keinen Daemon besitzt. Ein Daemon wie der Docker Daemon ist ein Hintergrundpro- zess, der notwendig für die Funktionalität der Software ist. Dadurch braucht Podman im Betrieb keine Root-Privilegien [Con21], was sich positiv auf die Sicherheit auswirkt. Apptainers Use Case ist wissenschaftliches High-Performance Computing [KSB17], wäh- rend Docker und Podman General Purpose Container-Manager sind. Dordevic et al. [Dor+22] untersuchten die Performance-Unterschiede zwischen Docker und Podman und fanden kaum Unterschiede. Stattdessen solle die Auswahl der Container- Engine nach Präferenz der Features erfolgen [Dor+22, S. 5]. Emilsson konnte ebenfalls keine signifikanten Unterschiede feststellen [Emi20, S. 24]. Empfehlung Die Vorrangstellung von Docker ist das wohl beste Argument in dieser Auswahl. Dadurch sollte es Unternehmen gut gelingen, Fachkräfte für den Betrieb des containerisierten DPT zu finden. Ist ein Umstieg auf ein verteiltes System eine Möglichkeit, profitiert Docker zudem von dessen integrierten Container-Orchestrator Docker-Swarm (siehe 3.4.4). 3.4. Konzeptionierung für verteilte Systeme In diesem Kapitel wird die Architektur für verteilte Systeme untersucht. Dabei soll der CMDPT in einem Cluster betrieben werden und dort horizontal skalierbar sein (Anfor- derung 13). Die CMDPT-Architektur für nicht-verteilte Systeme wird dementsprechend erweitert, siehe Abbildung 3.2. Daher wird auf die Aspekte des CMDPT, die schon in der Single-Host-Konzeptionierung erläutert wurden, nicht erneut eingegangen. Stattdessen werden die Unterschiede zum nicht-verteilten System beschrieben. Das Container-Cluster agiert als eine zusammenhängende Recheneinheit und kumuliert die Rechenleistung der Hosts. Der DPT liegt hier nicht mehr lokal gebunden, sondern delokalisiert und dezentral im Cluster vor. Das Management dieses verteilten Systems soll auch nicht zentral stattfinden, sondern unter Absprache aller beteiligten Recheneinheiten. Dadurch soll ein Single Point of Failure möglichst vermieden werden. 48 Abbildung 3.2.: Der modularisierte, containerisierte Digitale Prozesszwilling im Cluster aus Sicht des DPT 3.4.1. Container-Orchestrator Im Cluster reicht ein einfacher Container-Manager nicht mehr aus, um das hochdynami- sche Netzwerk aus Containern und Hosts zu verwalten. Stattdessen kommt ein Orchestra- 49 tor zum Einsatz. Der Orchestrator unterhält Instanzen von sich auf jedem Host, wie zu erkennen in Abbildung 3.3. Es sind nur exemplarisch Module abgebildet. Diese sind mit- einander vernetzt und steuern das Cluster autonom. Der Nutzer legt einen gewünschten Cluster-Zustand fest, den der Orchestrator zu erreichen versucht. Die Low-Level Container-Arbeit wird weiterhin von Container-Runtimes verrichtet, die auf allen Hosts aktiv sein müssen. Die Runtimes erhalten Befehle von der lokalen Orchestrator- Instanz. 3.4.2. Module im Cluster Der innere Aufbau des DPT ändert sich nicht, sodass Abbildung 3.2 stark an Abbildung 3.1 angelehnt ist. Die gleichen Modul-Images wie im nicht-verteilten Konzept werden vom Image-Repository bezogen. CMDPT-Module nehmen im Cluster die Rolle von Services ein (siehe Kap. 2.4). Der Container-Orchestrator verwaltet die Services, die innerhalb des Cluster-Netzwerkes miteinander kommunizieren. Zu beachten gilt, dass ein Service/Modul als Gruppierung mehrerer identischer Container dieses Moduls auf verschiedenen Hosts zu betrachten ist. Auf diese Weise wird die horizontale Skalierbarkeit realisiert. Für unproblematisches Verhalten bei der Skalierung müssen die Module aber als Microservice entworfen und zustandslos sein (siehe 2.8.1). Die Module können auch im Cluster von der Portabilität der Container profitieren und unkompliziert installiert, gestartet, aktualisiert und ausgetauscht werden. 3.4.3. Kommunikation Die Grundsätze der Kommunikation im verteilten System ändern sich nicht im Vergleich zur Single-Host-Kommunikation aus 3.3.7. Da der CMDPT in diesem Modell auf verschiedenen Hosts verteilt ist, müssen die einzelnen Container miteinander über lokale Netzwerke kommunizieren. Dafür tauschen sie untereinander Nachrichten asynchron über TCP aus. Sobald ein Modul skaliert in Form mehrerer identischer Container vorliegt, ist jedoch nicht eindeutig, zu welchem Container eine Nachricht geleitet werden soll, die an das Modul adressiert ist. Dafür soll ein Load Balancer die eingehenden Nachrichten gleichmäßig auf die einzelnen Container des Moduls verteilten. So werden die gegebenen Ressourcen optimal genutzt. Antworten auf eine Anfrage müssen exakt an den anfragenden Container 50 Abbildung 3.3.: Der modularisierte, containerisierte Digitale Prozesszwilling im Cluster aus Sicht der Hosts zurückgeleitet werden. Dafür wird einer Anfrage stets ein Absender beigefügt, der den anfragenden Container identifiziert. Die Auswahl der geeigneten Messaging-Technologie wird aus 3.3.8 übernommen, da ZeroMQs Fähigkeiten agnostisch gegenüber den Transportwegen sind. 3.4.4. Auswahl geeigneter Container-Orchestratoren Zum Betrieb des DPT in einem Cluster ist ein Container-Orchestrator nötig (siehe Kap. 2.4). Moderne, verbreitete Lösungen sind Kubernetes, Docker Swarm, Apache Meses (mit Marathon) und HashiCorp Nomad. 51 Abbildung 3.4.: Ein Modul im Cluster-DPT Mercl und Pavlik empfehlen die Nutzung von Docker Swarm für den Einsatz auf kleinerem Maßstab und Kubernetes für großflächigeren Einsatz in komplizierteren Projekten [LJ19, S. 684]. Dies lässt sich auch aus den Analysen von Pan et al. herleiten: Der Einsatz von Docker Swarm ist für den Docker-Nutzer einfach („out of the box“), da Swarm auf natürliche Art und Weise mit dem Rest der Engine integriert [Pan+19, S. 192, 198]. Kubernetes ist dagegen eine größere, komplexere Software mit einer steilen Lernkurve für den Nutzer [Pan+19, S. 192]. Die erweiterte Funktionalität sei für großflächige Einsätze sehr vorteilhaft, die zusätzliche Infrastruktur für kleine Cluster aber teuer [Pan+19, S. 198]. Jawarneh et al. konkludieren: „[...] Kubernetes is one of the most complete orchestrators nowadays on the market. That explains why practitioners gravitate toward preferring it to other ones. At the same time, its complex architecture introduces, in some cases, a significant overhead that may hinder its performances.“ [Jaw+19, S. 6] Die Verbreitung von Kubernetes ist im industriellen Einsatz hilfreich für die Verfügbarkeit von Fachkräften, die solche Systeme überwachen, bedienen und warten können. Weitere, aber weniger übliche Lösungen sind ein Apache Mesos Cluster mit dem dafür konzipierten Container-Orchestrator Marathon und HashiCorp Nomad. Mesos ist eine Ressource-Management-Ebene, die in Clustern Einsatz findet, um Cluster-Ressourcen fair zwischen verschiedenen Cluster-Computing Frameworks aufzuteilen [Hin+11, S. 13]. Damit können noch weit mehr Aufgaben erfüllt werden als Container-Orchestrierung. Es 52 hat auch den Vorteil des guten Zugangs zu Apaches Ökosystems. HashiCorp Nomad ist eine Orchestrierungs-Software, die auch das Management von nicht- containerisierten Applikationen und Virtuellen Maschinen übernehmen kann [Has22]. Nomad wird im Gegensatz zu Kubernetes Komplexität als einzelne Binary entwickelt und kann auf HashiCorps Software-Ökosystems zurückgreifen. Empfehlungen Die Verbreitung und Reife von Kubernetes spricht für sich als die im Moment für den ernsthaften Einsatz empfohlene Technologie. Dafür spricht auch dessen Einsatz im Projekt IF-DTiM (siehe 2.11.2). Docker Swarm kann als einfache, schnelle und leichte Alternative für experimentelle Einsätze empfohlen werden, besonders, wenn Docker schon im Einsatz ist. 53 4. Prototypische Implementierung Es folgt die Beschreibung der prototypischen Implementierung des CMDPT für verteilte und nicht-verteilte Systeme, basierend auf deren Konzeptionen aus Kapiteln 3.3 und 3.4. Zur Untersuchung der Charakteristika aus Kap. 3.2 werden nur exemplarisch Module implementiert. Dafür werden drei Komponenten eines DPT, die im Rahmen des AI-in-Orbit Factory Projekts an der TU Darmstadt entwickelt wurden, auf die Verwendung im CMDPT hin umgeschrieben und containerisiert. Dabei handelt es sich um: 1. Das Operational Data Storage (siehe 3.3.3), bestehend aus a) einer MongoDB Datenbank, b) einem Interface-Modul, das auf eingehende Anfragen hin die Datenbank modi- fiziert, c) einem Verwaltungs-UI für die Datenbank (mongo-express), 2. dem Interface zur Steuerung des EVA Automata Roboterarms und 3. einer UI für den Prozessablauf des Roboters, bestehend aus a) einer Django-Applikation, die über den WSGI-Server Gunicorn Anfragen entge- gennimmt und b) einem NGINX Webserver. Bei der Auswahl der Containertechnologie wird der Empfehlung aus 3.3.9 nachgekommen und die Docker Engine gewählt. Um beide Möglichkeiten der Verwaltung der Multi- Container Applikation abzudecken, wird für das nicht-verteilte System Docker-Compose und für den Cluster das Administrative UI (Portainer) verwendet. Das Kapitel beginnt mit einer Beschreibung der Rechenumgebung, es folgt eine Erläuterung zu der inneren Programmstruktur der Module, den verwendeten Container-Werkzeugen 54 und dem Entwicklungsprozess für CMDPT-Images. Daran schließt der Betrieb des CMDPT- Prototypen auf einem einzelnen Host und im Cluster an. 4.1. Beschreibung der Rechenumgebung Die Implementierung des verteilten sowie nicht-verteilte CMDPT erfolgt auf einem ASUS UX3410U Notebook mit einer Intel i7-7500U CPU @ 2,7 GHz, 8 GB RAM und einer Arch Linux Distribution, auf der Docker installiert ist. 4.2. Programmstruktur der Module In diesem Abschnitt werden die Programme, die als Module des CMDPT containerisiert werden, untersucht. 4.2.1. Programmiersprache Für die Implementierung wird Python als die primäre Programmiersprache des Projekts AI-in-Orbit Factory übernommen. „Python ist eine interpretierte, objektorientierte, high- Level Programmiersprache mit dynamischer Semantik.“ [Gui22] [aus dem Englischen] Im Rahmen dieses ersten Konzeptes ist dies eine sinnvolle Wahl, da in erster Linie die Charakteristika des CMDPT demonstriert werden sollen, und Rechenleistung für den Demonstrator des Projekts zu dem Zeitpunkt eine untergeordnete Rolle spielt. Die gute Lesbarkeit von Python erleichtert außerdem das Verständnis der Implementierung. 4.2.2. Base-Image/Modul-Basis und Kommunikation Um Einheitlichkeit zu schaffen, wird allen Modulen eine Modul-Basis in Form eines Base- Images zugrunde gelegt (siehe 3.3.5). Das Base-Image basiert selbst auf dem offiziellen Python-Alpine-Image von Docker-Hub (https://hub.docker.com/), dem größten öffentli- chen Image-Registry. Alpine Linux ist eine sehr kompakte Linux-Distribution und daher beliebt für den Einsatz in Containern. Ein Alpine-Image ist nicht größer als 8 MB [Alp22] und enthält nur die notwendigsten Programme für den Container-Betrieb. 55 Die Modul-Basis besteht aus einer Python-Klasse mit dem Namen BaseModule, welche etwaige Module entweder als Objekt instanziieren oder von der die Module als Klasse erben. Die Modul-Basis implementiert in diesem Prototyp ausschließlich die Kommu- nikation der Module miteinander. Dafür gibt es eine Methode zur Registrierung von Server-Verbindungen von der Client-Seite aus (register_connection), die aufgerufen wer- den muss, bevor der Client erste Kommunikation anstoßen kann. Dazu kommen separate Methoden für den Empfang und Versand von Nachrichten von Client- und Server-Seite. Die Kommunikation wird über ZeroMQ DEALER/ROUTER Sockets implementiert. Jedes Modul erhält einen ROUTER-Socket für die allgemeine Server-Rolle und einen DEALER- Socket für jede Client-Verbindung. Die DEALER-Sockets der Clients verbinden sich mit den ROUTER-Sockets der Server. Dadurch kommt es, dass jeder DEALER-Socket nur eine, jeder ROUTER-Socket aber mehrere Verbindungen verwaltet. Dafür ist der ROUTER-Socket ausgelegt: Die einkommenden Verbindungen erhalten Identitäten, über die der Socket die einzelnen Clients separat ansprechen kann. 4.2.3. Microservices / Service-orientierte Architektur Einzelne Funktionalitäten des CMDPT werden als Microservices implementiert (siehe 3.3.6). Exemplarisch soll dafür das Interface des Operational Data Storage angeführt werden. Der Python-Code dieses Interfaces ist in Appendix B gegeben. Der Code wurde im Anhang gekürzt und enthält nur den Teil für die Bearbeitung von Requests bezüglich der Waypoints des EVA Automata Roboters. Besonders hervorzuheben ist hierbei die Service-Schleife, die während der Laufzeit des Services auf eingehende Nachrichten (Requests) wartet und den jeweiligen Funktionen zuordnet. Dies geschieht über Pythons Structural Pattern Matching. Die Funktionen greifen über PyMongo auf die in einem separat laufenden Container betriebenen MongoDB Datenbank zu. PyMongo ist eine Python Bibliothek für die Modifikation von MongoDB Datenbanken. Die Nachrichten in dieser Implementierung sind standardisiert und bestehen aus einem Tupel JSON-kompatibler Datentypen. Das erste Element des Tupels gibt den Typ der Nachricht (Request-Typ) an. Die nächsten Elemente enthalten für den Request zu über- mittelnde Daten. Das stellt ein primitives Nachrichtenprotokoll dar, wie in 3.3.7 gefordert. Auf diese Weise können alle Module die Struktur eingehender Anfragen verstehen. 56 4.3. Container-Werkzeuge Für den Umgang mit Images und Containern gibt es sehr hilfreiche Werkzeuge, die bei der Implementation des Prototyps Verwendung finden. Das Erstellen von Images mit einer sogenannten Dockerfile sowie das Verwalten von Multi-Container Applikationen mit Docker-Compose sind Fähigkeiten, die von Docker bereitgestellt werden. Die grafische Nutzeroberfläche Portainer dagegen ist ein unabhängiges Open-Source-Projekt, das hier Anwendung als Administrative User Interface des CMDPT findet. 4.3.1. Erstellen von Images mit Dockerfiles Die Instruktionen für den Aufbau des Images erhält die Container-Engine über die Do- ckerfile (siehe Kap. 2.6). Die Dockerfile des Interfaces der MongoDB-Datenbank ist in Abbildung 4.1 abgebildet. Ausgehend vom Base-Image, das von der Registry bezogen wird, wird die Python-Bibliothek PyMongo mit dem Package Installer for Python installiert. Anschließend wird der Pro- grammcode in den Container kopiert und der Modulname als Umgebungsvariable festge- legt. Die letzte Zeile gibt den bei Containerstart auszuführenden Befehl an, in diesem Fall ist es das Starten des Python-Programms. Diese Datei ist ausreichend, um mit docker build das Container-Image zu bauen. Bei großen Projekten bietet sich es jedoch auch an, nicht alle Images einzeln zu bauen, sondern auf der Werkzeug Docker-Compose zurückzugreifen, das den Bau von mehreren Images gleichzeitig automatisieren kann. Abbildung 4.1.: Die Dockerfile des Operational Database Interface 57 4.3.2. Docker-Compose Docker-Compose ist ein Werkzeug, mit dem der gewünschte Zustand der Containerkon- stellation in einer YAML-Datei festgehalten und von dieser ausgehend umgesetzt werden kann. Außerdem kann damit der Bau von Images für Multi-Container Applikationen automatisiert werden. Die Docker-Compose Datei (compose.yaml) des nicht-verteilten DPT-Prototypen ist in Anhang A gegeben. Jedes Modul wird unter dem Abschnitt „services“ eingetragen. Ein Modul-Eintrag ent- hält den Ort der Dockerfile zum Bauen des Images, sowie den Image-Namen inklusive gegebenenfalls der Registry-Adresse. In diesem Fall wird die Registry-Adresse durch die Umgebungsvariable REGISTRY festgelegt. Dazu kommen Informationen für den Betrieb des Containers. Hierbei handelt es sich um verbundene Volumes und Netzwerke. In diesem Konzept soll nur die Data-Ebene Zustand erhalten (siehe 3.3.3), weshalb nur der Datenbank ein Volume zugewiesen wird. Alle DPT-Module werden in einem Netzwerk „dpt“ miteinander verbunden, abgesehen von dem Webserver, der nur eine Verbindung zum WSGI-Server benötigt. Beiden wird daher ein separates Netzwerk „webserver“ zugewiesen. Für Module, auf die von Außen zugegriffen werden soll, werden Ports freigegeben. Das betrifft vor allem die UI. Um den einzelnen Modulen die Kommunikationspartner zuzuweisen, werden Umgebungsvariablen zugewiesen, jeweils mit dem Service-Namen des Partners. 4.3.3. Portainer Alternativ zu der manuellen Verwaltung des CMDPT über den Docker Client oder mit Docker-Compose wird der Einsatz einer grafischen Nutzeroberfläche für diese Zwecke vorgeschlagen. Dafür eignet sich Portainer (https://www.portainer.io/), auch aufgrund dessen Fähigkeit zum Betrieb im Cluster. Portainer wird vor der Instanziierung des CMDPT über den Docker Client installiert. Anschließend können die einzelnen Module über das Interface intuitiv installiert und konfiguriert werden. Portainer verfügt außerdem über ein User-System, das verschiedenen User-Gruppen verschiedene Befugnisse zuteilen kann. 58 4.4. Implementierung des Entwicklungsprozesses für CMDPT- Images Bevor der CMDPT zum Einsatz kommen kann, müssen dessen Module entwickelt, con- tainerisiert und abrufbar gespeichert werden. Auf die Entwicklung der Module wird in Kap. 4.2 eingegangen. Im Folgenden wird auf die Installation und Verwendung des Image- Repositorys (Docker Registry) sowie das Erstellen und Abspeichern der Modul-Images eingegangen. 4.4.1. Registry Für das Image-Repository (siehe 3.3.2) kommt Docker Registry zum Einsatz. Docker Registry ist die von Docker entwickelte und empfohlene Applikation zum Speichern und Bereitstellen von Container-Images. Die Registry wird als Container (Single-Host) oder Service (Cluster) installiert. Dafür muss ein Port, z. B. Port 5000, am Container freigegeben werden. Für die Installation mit dem Docker-Client genügt daher der Befehl [Doc22b]: docker run -d -p 5000:5000 --name registry registry:2 Images können auf der Registry gespeichert werden, indem sie zuerst nach folgendem Muster benannt werden: [IP]:[Port]/[Name] und dann mit docker push [Image-Name] hochgeladen werden. Anschließend kön- nen sie von beliebigen Maschinen mit docker pull [Image-Name] heruntergeladen werden. Für diese Implementierung wird eine Registry auf einer virtuellen Maschine mit der IP 192.168.56.104 installiert. Das zeigt die Auslagerungsfähigkeit des Image Reposito- ries. Diese Registry findet Verwendung sowohl in der Single-Host- als auch der Cluster- Implementierung. Die Verwendung einer Registry ist bei einer Single-Host-Implementierung jedoch optional, solange die Images lokal gebaut wurden. 59 https://hub.docker.com/_/registry/ 4.4.2. Erstellen und Abspeichern der Images Mithilfe der compose.yaml aus Appendix A werden die Images aus dem Quellcode gebaut. Dafür braucht es zwei Befehle: „export“ legt eine Umgebungsvariable mit der Adresse der Registry fest, „docker compose build“ instruiert Docker-Compose, das Bauen der Images zu veranlassen. Da alle Module auf dem Base-Image aufbauen, wird es explizit zuerst gebaut. Folgende Befehle sind also auszuführen: export REGISTRY=192.168.56.104:5000 docker compose build base-module docker compose build Dafür wird für jedes Modul eine Dockerfile im Quellcode-Ordner erstellt, die der Container- Engine die Anleitung für den Bau liefert (siehe 4.3.1). Wird eine Registry auf dem Host oder anderswo betrieben, können die gebauten Images dort aufgespielt werden: docker compose push Möglicherweise muss die IP der Registry noch auf allen Hosts zu den „insecure_registries“ in Dockers daemon.json hinzugefügt werden. Das ist der Fall, wenn die Verbindung zur Registry nicht über ein TLS Zertifikat geschützt ist. Vom ungeschützten Betrieb der Registry ist in der Praxis stark abzuraten. Siehe hierzu [Doc22g]. 4.5. Betrieb auf einem einzelnen Host In diesem Abschnitt wird die Konzeption aus Kap. 3.3 im Betrieb prototypisch an den exemplarischen Modulen umgesetzt. Dabei handelt es sich um den Betrieb in virtualisiert modularer Bauweise,