Open Access

In the current state of information technology and service provisioning techniques, containers are the leading technology for a stable, reliable and well-serviceable infrastructure. However, many containers simply put next to each other will lead to a mess of problems that containers were employed to solve originally. To overcome such challenges, container orchestrators are being used. Kubernetes is the leading container orchestrator through its extensive feature set, enabling e.g. self-healing capabilities and fast scaling with immense value for infrastructure operations. This thesis looks at a few key aspects that arise when setting up a container-orchestrated landscape using Kubernetes such as what Kubernetes distributions are, how Kubernetes configuration is managed and what GitOps is. In order to answer those questions, two requirements analyses were undertaken to find suitable software solutions for the Business Solutions department of Akkodis. All aspects were further answered with extensive research, resulting in lists of recommendations and suggested workflows. Using this method, a Kubernetes distribution and a backup solution were chosen. The Kubernetes distribution with the highest score is K3s mainly due to its use of ease and Batteries included approach. The backup solution with the highest score is Trilio Backup. GitOps with Infrastructure as Code is a very powerful approach that should be utilized in a Kubernetes cluster paired with Helm charts and Kustomize overlays. To show the recommendations given being useful, a demonstration setup was created. It utilizes the results of the two requirements analyses and uses insights of the other sections to build a small proof of concept using the K3s Kubernetes distribution. An instance of the Kubernetes Dashboard utility was successfully provided using with the ArgoCD GitOps operator. A backup solution was to be implemented using Trilio Backup, but unexpected errors came up which could not be solved in the thesis’ time frame. A few possibilities on the error’s source are suggested with potential solutions.

Bei der empirischen Untersuchung der Praxis der Geschäftsprozessmodellierung ist man auf eine umfangreiche, vielfältige und gleichzeitig zur Aufgabenstellung passende Datenbasis angewiesen. Wir untersuchen eine Reihe öffentlich zugänglicher Modellrepositorys mit BPMN-Modellen, die in den vergangenen Jahren entstanden sind. Wir weisen auf Eigenarten der Repositorys hin, die die Verarbeitung der Daten erschweren und die Datenqualität beeinträchtigen. Besonders diskutiert wird das in bisherigen Arbeiten nicht betrachtete Phänomen von de facto inhaltsgleichen Modellen in bei bitweisem Vergleich verschiedenen Dateien. Wir diskutieren die Auswirkung solcher Duplikate und schlagen eine der jeweiligen Aufgabenstellung angepasste Filterung vor. Wir begründen, warum dieses Vorgehen insbesondere bei Ansätzen zum maschinellen Lernen beachtet werden sollte. Wir stellen fest, dass die empfohlenen Maßnahmen zur Sicherung der Datenqualität in aktuellen Veröffentlichungen häufig noch nicht beachtet werden, was die Aussagekraft von deren Ergebnissen in Frage stellen kann.

Die vorliegende Arbeit wurde initiiert durch das Fehlen einer adäquaten Datenarchitektur für die neu etablierte Fertigungslinie Thermomanagement im Volkswagen Motorenwerk Chemnitz, welche für die Produktion von Thermomodulen zur Kühlung von Autobatterien zuständig ist. Das Hauptziel dieser Arbeit bestand darin, eine passende Datenarchitektur zu entwickeln, die die Erfassung, Verwaltung, Auswertung und Darstellung der sogenannten Bauzustandsdaten effizient bewältigen kann. Zudem sollte die Architektur eine einfache Erweiterungsmöglichkeit bieten, um zukünftig auch andere Datentypen oder Fertigungslinien integrieren zu können. Mit dem exponentiellen Wachstum von Daten im Kontext von Big Data stoßen jedoch lokale Produktionssysteme und Datenarchitekturen zunehmend an ihre Kapazitätsgrenzen. Sie verfügen oft nicht über die erforderlichen Ressourcen, um Daten gewinnbringend zu verarbeiten. Die Fachliteratur und aktuelle Entwicklungen weisen darauf hin, dass Cyber-Physische Produktionssysteme sowie cloudbasierte Datenarchitekturen wie die Cloud Data Platform vielversprechende Lösungen bieten. Diese Architektur basiert auf der bekannten Data-Lake-Architektur und ist unter anderem in der Lage, Daten unabhängig von ihrer Struktur zu erfassen, zu transformieren, zu verarbeiten und kontextübergreifend zu analysieren, und profitiert dabei von den nahezu unbegrenzten und skalierbaren Ressourcen von Cloud-Anbietern wie Amazon Web Services (AWS). Das konkrete Ziel war es, die Cloud Data Platform über den Plant Connectivity Service (PCS) in der Digitalen Produktionsplattform des Volkswagen Konzerns zu implementieren. Aufgrund des Umbaus der Fertigungslinie während des Bearbeitungszeitraums war es notwendig, die Entwicklung der Datenarchitektur durch eine Virtuelle Inbetriebnahme zu ergänzen, die den Fertigungsprozess simulieren kann, um Testdaten generieren zu können. Im Rahmen dieser Arbeit wurden zunächst die theoretischen Grundlagen und Konzepte zu Cyber-Physischen Produktionssystemen, Virtueller Inbetriebnahme, Cloud Computing sowie cloudbasierten Datenarchitekturen erarbeitet. Dabei wurden auch die im Verlauf aufgetretenen relevanten Themen wie Digitaler Schatten und Digitaler Zwilling umfassend behandelt. Für die Virtuelle Inbetriebnahme wurde ein generisches Drei-Ebenen-Architekturmodell in JavaScript entwickelt. Jeder Prozessschritt ist durch verschiedene Parameter konfigurierbar, sodass Aspekte wie die zeitliche Abfolge oder die Zusammensetzung von Referenznummern berücksichtigt werden können. Die durch jeden Prozessschritt erzeugten Datentelegramme konnten anschließend über den im Verlauf instanziierten PCS-Service in unter einer Sekunde in die entwickelte Datenarchitektur, die Cloud Data Platform, übertragen werden. Die Datenarchitektur wurde mithilfe des AWS Cloud Development Kit realisiert. Die zentralen Komponenten umfassen vier Datenbanktabellen, einen Archivspeicher sowie eine Step Function und eine Lambda Function. Diese Architektur ermöglicht es, jedes Datentelegramm innerhalb von 2 Millisekunden zu verarbeiten und anschließend parallel sowohl im Ursprungsformat im Archiv abzulegen als auch transformiert in die entsprechende Datenbanktabelle zu speichern. Zusätzlich wurde eine Dashboard-Anwendung entwickelt, die mithilfe einer weiteren Lambda Function die Datensätze aller Datenbanktabellen mit einer durchschnittlichen Lesegeschwindigkeit von 1500 Millisekunden tabellarisch und farblich darstellt, wobei verschiedene Analysefilter genutzt werden können. Zusammenfassend konnte durch diese Arbeit mit der Cloud Data Platform eine äußerst flexible und einfach erweiterbare cloudbasierte Datenarchitektur implementiert werden. Diese Architektur erfüllt nicht nur alle aktuellen Anforderungen, sondern bietet auch vielfältige Möglichkeiten für zukünftige Big-Data-Analysen. Darüber hinaus gelang es, die Entwicklungskosten um 95% und die Betriebskosten um 20% im Vergleich zu äquivalenten On-Premise-Lösungen zu senken.