In den vergangenen Jahren haben sich industrielle Prozesse zunehmend in Richtung hochgradige Automatisierung entwickelt, um menschliche Interaktionen so weit wie möglich zu minimieren. Das Konzept des Industrial Internet of Things (IIoT) sieht dabei den Einsatz zahlreicher Sensoren und Aktuatoren vor. Die von den Sensoren erzeugte neue Datenmenge muss jedoch verarbeitet und in Steuerbefehle für die Aktuatoren umgewandelt werden. Da Cloud Computing (CC) aufgrund unvorhersehbarer Netzwerklatenzen nicht die richtige Wahl ist, wird Edge Computing (EC) eingesetzt, um Steueranwendungen auszuführen, die in der Regel Echtzeit-Anforderungen haben. Um den Einfluss der Anwendungen aufeinander zu minimieren, wird auf Edge-Servern oft Virtualisierung verwendet. Insbesondere die Container Virtualisierung mit ihren Vorteilen von kleinen Images und schnellen Startzeiten ist in industriellen Umgebungen hilfreich. Zur Erfüllung der zeitlichen Anforderungen einer Anwendung auf einem Edge-Server gibt es mehrere Möglichkeiten. Diese Arbeit verwendet den Hierarchical-Constant-Bandwidth-Server (HCBS)-Patch für den Linux-Kernel. Dieser Patch ermöglicht das Scheduling von Containern nach einem Earliest-Deadline-First (EDF)-Schema und Prozesse innerhalb von Containern nach einem Fixed-Priority (FP)-Schema. Der in der Container Virtualiserung übliche Orchestrator reduziert nicht nur den Energie- und Ressourcenverbrauch, indem nicht mehr benötigte Container gestoppt werden, sondern verbessert auch das Echtzeitverhalten des gesamten Systems. Denn der Orchestrator kann Container, deren Anwendungen Deadlines verpassen, auf einen anderen Server im Cluster mit mehr verfügbarer CPU-Zeit bewegen. Es stellen sich jedoch zwei Fragen, wenn Container Virtualisierung im Kontext von Echtzeitsystemen verwendet wird: 1.) Welcher Container muss auf welchem Server gestartet werden, um alle Anforderungen des Containers zu erfüllen, und wie viel CPU-Zeit benötigt er? 2.) Wie kann das Echtzeitverhalten zur Laufzeit aufrechterhalten werden, wenn Störungen durch andere Anwendungen dazu kommen? Für die Beantwortung von Frage Nummer 1 stellen wir mehrere Solver bereit, die wir hinsichtlich Leistung und Optimalität vergleichen. Bezüglich Frage Nummer 2 implementieren wir einen Mechanismus, der das Verpassen von Deadlines mithilfe von Time-Utility Funktionen reduziert, indem er die CPU-Zeit eines Containers erhöht oder diesen auf einen anderen Server verschiebt. Schließlich evaluieren wir unsere Controller anhand synthetischer Testfälle.
de
During the past years, industrial processes have developed towards a highly automated nature to remove human input wherever possible. This is enabled by many sensors and actuators, following the idea of the Industrial Internet of Things (IIoT). However, this new amount of data created by the sensors needs to be processed and converted to control commands for the actuators. As Cloud Computing (CC) is not sufficient, due to the unpredictable network latencies, Edge Computing (EC) is employed to run control applications, which typically have real-time (RT) requirements. To keep the influence of the applications on each other to a minimum and increase security at the same time, virtualization is often used on edge servers. Especially container-based virtualization with its benefits of small image size and rapid deployment is useful in an industrial setting. To fulfill the temporal requirements of an application on an edge server multiple adaptations are possible. We use the hierarchical-constant-bandwidth-server (HCBS) patch for the Linux kernel. This patch allows scheduling containers following an earliest-deadline-first (EDF) scheme and tasks inside containers following a fixed priority (FP) scheme. An orchestration layer that manages the containers and decides which container runs on which server is typically used together with container-based virtualization. This layer not only reduces the energy and resource usage by stopping no longer required containers but also helps to improve the RT behavior of the whole system. If an application inside a container misses its deadlines due to, for example, overutilization of the server, the orchestrator can relocate this container to a different node in the cluster. However, two critical questions need to be answered when using container-based virtualization in the context of RT systems: 1.) Which container has to be started on which server to fulfill all the container's needs, and how much CPU time does it need? 2.) How can the RT performance be maintained at runtime when interferences from other applications come into play? We answer question number 1 by providing multiple solvers, which we evaluate and compare in terms of performance and optimality. Regarding question number 2 we implement an online adaptation mechanism that reduces deadline misses of the tasks based on time-utility functions. We either increase the CPU time of a container or relocate it to a different node. Finally, we evaluate our hierarchical controllers with a real-world test bed.
