Flüchtige Komponenten in der Edge
Der Einsatz von Edge Computing in Kombination mit dem Mobilfunkstandard 5G bringt eine Vielzahl verschiedener Vorteile mit sich. Zum einen können die Dienstgüteeigenschaften des 5G-Netzwerkes, wie beispielsweise die enorm kurzen Latenzen oder die sehr hohen Datenraten, bestmöglich genutzt werden. Zum anderen kann die Verarbeitung der Daten in der Nähe der Endgeräte einen erheblichen Einfluss auf die Einhaltung von Sicherheitsanforderungen, wie zum Beispiel den Schutz von personenbezogen Daten, haben. Gleichzeitig bietet Cloud Computing auch Vorteile, die so in der Edge nicht verfügbar sind, z. B. skalierbare Rechen- und Speicherkapazitäten oder weltweite Verfügbarkeit.
Um die Vorteile beider Welten in der gesamten Rettungskette eines Notfalls zu nutzen, haben die Mitarbeiter:innen des Lehrstuhls für Software Engineering an der Universität Duisburg-Essen in Kooperation mit der adesso mobile solutions GmbH im Rahmen des Projektes EURIALE, das vom Land NRW im Wettbewerb 5G.NRW gefördert wird, eine Software-Architektur entwickelt, die eine 5G-basierte Anwendung in eine Menge von Cloud- und Edge-Komponenten unterteilt. Der Standard Multi-Access Edge Computing (MEC) wird von dem European Telecommunications Standards Institute (ETSI) entwickelt und definiert die Orchestrierung und Bereitstellung von Anwendungen innerhalb der 5G-Edge. Zudem existieren bereits verschiedene Management-Plattformen zur Verwaltung eigener Anwendungen innerhalb der Cloud.
Darauf aufbauend sieht die entwickelte Architektur vor, die Anwendung in einen Management- und einen notfallspezifischen Teil aufzuteilen. Der notfallspezifische Teil wird dynamisch zur Laufzeit der Anwendung immer dann im Edge erstellt, wenn ein Notfall auftritt, und nach Abschluss aller Arbeiten unwiederbringlich gelöscht. Die dafür notwendigen Software-Komponenten werden daher als flüchtige Komponente bezeichnet: Sie werden nur so lange bereitgestellt, wie ihre Client-Systeme Informationen untereinander austauschen oder Daten innerhalb der Komponente verarbeitet werden müssen. Nachdem dies geschehen ist, werden die Komponenten inkl. der darin enthaltenen Daten umgehend und unwiderruflich gelöscht. Die Verwaltung dieser Komponenten erfolgt über eine Management-Ebene, die in der Cloud gehostet wird, die aber mit den Daten eines Notfalls nicht in Berührung kommt.
In der folgenden Abbildung ist eine Übersicht dieser Software-Architektur zu sehen:
Eine solche Architektur eignet für eine Vielzahl unterschiedlicher Anwendungsfälle und ist nicht auf die Rettungskette beschränkt: Sie kann immer dann zum Einsatz kommen, wenn Daten nur im Edge verarbeitet werden sollen, aber eine übergeordnete Steuerung notwendig ist. Im Rahmen des Projektes EURIALE liegt der Fokus aber auf der Verarbeitung von Informationen zu Notfällen, daher soll die Architektur verwendet werden, um sämtliche Informationen über den Patienten und die Rahmenbedingungen zu sammeln, zu verarbeiten und an die verschiedenen Akteur:innen zu übermitteln. Die Funktionsweise der Architektur wird im Folgenden anhand eines beispielhaften Notfalls erläutert.
Sobald eine neue Notfallmeldung bei der Leitstelle eintrifft (Schritt 1), werden sämtliche relevanten Informationen an das Managementsystem in der Cloud übertragen. Nach der Speicherung dieser eingehenden Daten und ihrer Verknüpfung mit einer eindeutigen ID, stößt die Verwaltung die Erstellung einer neuen flüchtige Komponente an, indem sie die ID und die Standortinformationen des Notfalls an das MEC-System sendet (Schritt 3). Dieses läuft bereits im Edge des 5G-Netzwerks.
Der Orchestrator des MEC-Systems ermittelt anhand der Positionsdaten den Edge-Host, der dem Notfallort örtlich am nächsten ist. Nachdem die Komponente erfolgreich hochgefahren ist, übermittelt das MEC-System die eindeutige URL der Komponente an die Verwaltung, die diese wiederum an alle an dem Notfall beteiligten Personen verschickt. Diese können über verschiedene Client-Systeme auf sämtliche Patientendaten, wie beispielsweise Puls, Elektrokardiogramm, Sauerstoffsättigung oder Temperatur, innerhalb der Komponente zugreifen (Schritt 5). Auch das Krankenhausinformationssystem (KIS) erhält als zusätzliches Clientsystem alle notwendigen Patientendaten zur weiteren krankenhausinternen Verarbeitung.
Nach der Aufnahme der/des Patient:in in das Krankenhaus, werden alle Daten zusammengefasst und an das KIS gesendet. Da alle weiteren Informationen im Krankenhaus gesammelt werden, kann die Software-Komponente ab diesem Zeitpunkt über ein Beendigungssignal, das vom KIS an die Verwaltung gesendet wird, heruntergefahren werden (Schritt 6). Die Verwaltung leitet den Befehl an das MEC-System weiter (Schritt 7), das anschließend die Komponente und alle die darin enthaltenden Daten vollständig und unwiderruflich löscht (Schritt 8)
Eine derartige Bereitstellung sowie die sofortige Löschung solcher Komponenten hat zwei wesentliche Vorteile:
- Dienstgüte (Quality of Service – QoS): Durch die Vor-Ort Bereitstellung der Komponenten auf dem örtlich nächstgelegenen Host können die Eigenschaften des 5G-Mobilfunknetzes optimal genutzt werden.
- Sicherheit: Die Reduzierung der Datenwege minimiert die Möglichkeit von Man-in-the-middle (MITM)-Attacken oder ähnlichen Angriffen.
Die Architektur wurde im Rahmen des Konferenzbeitrags „Towards an Architecture for Deploying Ephemeral Components on the Edge“ auf der 19th International Conference on Software Architecture (ICSA) veröffentlicht und interessierten Fachöffentlichkeit vorgestellt. Link zur Veröffentlichung: 10.1109/ICSA-C54293.2022.00012