In Phase II modellierte B2 MAKI-Komponenten als Geflechte von Verarbeitungselementen. Die Einbeziehung von In-Network-Processing (INP) ermöglichte es, Verarbeitungselemente auf den bestgeeigneten Netzwerkressourcen zu (re)platzieren, z.B. in der Nähe von Endsystemen oder Servern. Wichtige Ergebnisse betrafen Scheduling-Konzepte, die eine deutlich verbesserte Auslastung der Netzwerkressourcen erzielen. Mit VirtualStack gelang zudem die Weiterentwicklung fortgeschrittener Konzepte der Virtualisierung und Softwaredefinierter Kommunikationssysteme zu einem Ende-zu-Ende-Ansatz. Statische oder dynamische Vorkonfiguration von MAKI-Multi-Mechanismen-Stacks ermöglichen dabei schnelle Transitionen und Koexistenz; die Kopplung von MAKI-Multi-Mechanismen mit Altanwendungen sowie Hardware-Beschleunigung wird ermöglicht.
In Phase III will B2 einen Schwerpunkt auf Anwendungen mit missionsentscheidenden Anforderungen legen, dabei aber die Ausführungsflexibilität und -leistung auch für andere Anwendungsarten verbessern. Zu diesem Zweck werden drei allgemeine konzeptionelle Leitlinien für die Forschung in Phase III wie folgt festgelegt.
(A) Flexible Anwendungen (FlexApps). Als Leithypothese wird angenommen, dass viele Netze morgen wie heute nicht in der Lage sein werden, die Anforderungen von Anwendungen – insbesondere missionsentscheidender Art – jederzeit in der gewünschten Qualität zu erfüllen. Daher sollen die Entwickler mit Mitteln ausgestattet werden, um mehrere alternative Varianten von Anwendungen zu spezifizieren, die zur Laufzeit ausgewählt und -gewechselt werden können mit dem Ziel, verbindliche Garantien zu gewährleisten; nichtsdestotrotz soll bestmögliche Funktionalität bereitgestellt und Kontextabhängigkeit berücksichtigt werden. Die in FlexApps bereitgestellten Alternativen und deren Austausch ähneln offensichtlich Mechanismen und Transitionen; B2 legt somit den Grundstein für die Ausweitung des MAKI-Prinzips auf (missionsentscheidende und andere) Anwendungen.
(B) Ergebnisgüte vs. Dienstgüte (QoR vs. QoS). Damit die B2-Laufzeitunterstützung unter FlexApp-Varianten geeignet auswählen kann, ist für jede Variante ein Paar zusammengesetzter Werte (<QoR>, <QoS>) zu spezifizieren. QoR (Quality of Result) spezifiziert die Qualität, die eine Variante der Umwelt zusichert, während QoS die erforderliche Dienstqualität des zugrunde liegenden Kommunikationssystems und der Laufzeitumgebung widerspiegelt. Bspw. könnte eine automobile Fahrerassistenz-FlexApp mit kamerabasierter Objekterkennung in zwei Varianten existieren: einer, die nur die GPU-Knoten eines nicht-transitionsfähigen Fahrzeugnetzwerks nutzt und einer, die Edge Computing einbezieht; die zweite könnte ggf. QoS-Garantien fordern, die nur in Innenstädten erreicht werden, dafür aber kleinere Sicherheitsabstände ermöglichen. Die Einbeziehung des Fahrzeugnetzes macht die Notwendigkeit kooperativer Transitionen deutlich.
(C) Microservice-basierte Laufzeitunterstützung. Aus den Erfahrungen und Ergebnissen von Projekt C7 leiten wir ab, dass das äußerst leichtgewichtige und modulare Konzept von Microservices grundsätzlich für hochflexible und skalierbare verteilte Ausführung besonders geeignet ist. Ressourcennutzung in der Nähe von Endsystemen (z.B. mittels Edge Computing) ermöglicht Latenz-, Zuverlässigkeits- und Bandbreitengarantien. Wichtiger Nachteil gegenüber herkömmlichem Cloud Computing ist aber die erheblich geringere Elastizität: Rechen- und Speicherressourcen sind bei Edge Computing naturgemäß beschränkt, bei Cloud-Computing können sie dagegen als unendlich idealisiert werden. C7 vollzog wesentliche Schritte auf dem Weg, die genannten Vorteile auszunutzen, den Nachteil aber deutlich zu mildern, v. a. durch neuartige Skalierbarkeits- und Caching-Ansätze. Als unterster Kern der Laufzeitunterstützung sind daher neue Konzepte für eine zum Gesamtkonzept von B2 passende Microservice-basierte Ablaufumgebung geplant.
Zusammenfassend sind in Phase III insbesondere die folgenden vier großen Anstrengungen erforderlich: i) Neue Microservice-basierte Konzepte sind zu entwickeln, um bessere Batching- und Mobilitätsunterstützung zu erreichen und Microservice-inhärente Probleme zu mildern, z.B. in Bezug auf zustandsbehaftete Microservices und Datenflussabhängigkeiten. ii) Um vorhandene Resultate wie VirtualStack Microservice-fähig zu machen, sind ebenfalls neue Ansätze erforderlich. iii) Für die FlexApp-Varianten sind auf QoR/QoS-Basis Optimierungs- und Scheduling-Verfahren zu konzipieren, Varianten-Übergänge sind als Transitionen mit denen des Kommunikationssystems und der Ablaufumgebung zu verzahnen, also den beiden zuvor genannten Anstrengungen. iv) Der Mehraufwand für Anwendungsentwickler angesichts mehrerer (FlexApp-)Varianten und nötiger QoR/QoS-Vorgaben muss reduziert werden. Das erfordert neue Konzepte zur interaktiven Gütemaß-Bestimmung und zur FlexApp-Spezifikation sowie (mit Teilprojekt A2) programmiersprachliche Unterstützung.
B2 investigates the coordination and execution of MAKI communication systems, i.e., their mechanisms, transitions, and applications – and thus, in particular, the last phase of the MAPE cycle (Monitoring, Analysis, Planning, Execution), which is dealt with in area B of MAKI. Here, B2 designs distributed runtime environments that have advanced planning, resource allocation, and component (re)placement capabilities. Phase II focused mainly on efficiency and adaptability, and on development aspects such as separation of concerns. Project C7 (ending with Phase II) provided critical groundwork for phase III of B2.
