Figure 7.4: Virtualized environments

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles Schichten- und Bereitstellungsmodell (Execution & Deployment Architecture Diagram) mit annotierten VM-Zustandsräumen.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP R25-11), Spezifikation State Management (AUTOSAR_AP_SWS_StateManagement), Kapitel 7.5.4 (Coordinated Suspend Mode Management for Virtual Machines).
• Technischer Zweck: Darstellung der Entkopplung und Kapselung virtueller Maschinen (VMs) auf einem gemeinsamen Hypervisor. Das Diagramm illustriert das architektonische Prinzip, dass kein zentraler Koordinator direkt in die Applikationsebenen der Gastsysteme eingreift, sondern jede VM als autonome State-Management-Domäne operiert.

2. Komponenten, Entitäten & Schnittstellen

• Hypervisor:
  • Typ-1-Virtualisierungsschicht (Bare-Metal/Microkernel-Ebene).
  • Verwaltet die Partitionierung von CPU-, Speicher- und I/O-Ressourcen sowie die globalen Lebenszykluszustände der virtuellen Instanzen.
• Virtual Machines (VM_1, VM_2):
  • Isolierte Ausführungsumgebungen (Hardware-/OS-Partitionen).
  • Zustandsmenge: Diskrete Zustände [Running, Suspended, Terminated].
    • VM_1: Befindet sich im aktiven Ausführungszustand Running (fett hervorgehoben).
    • VM_2: Befindet sich im Energiespar-/Wartezustand Suspended (fett hervorgehoben; RAM-Inhalte eingefroren).
• Gast-Komponenten je VM:
  • GuestOS: Lokales Betriebssystem (POSIX-kompatibel, z. B. QNX Neutrino, Linux), agiert als Laufzeitbasis für den Adaptive-Stack.
  • State Management (im Diagramm mit typografischem Fehler als „State Managment“ annotiert): Plattform-Instanz von ara::sm innerhalb der VM. Koordiniert Function Groups und Machine State der lokalen VM-Domäne.
  • Application: Eine oder mehrere Adaptive Applications (ara::*), die unter Kontrolle von State Management und Execution Management (ara::exec) laufen.

3. Dynamisches Verhalten & Sequenzablauf

• Dezentraler Suspend-Trigger:
  1. Ein externer Auslöser (z. B. Netzwerk-Signal via ara::com von einem externen Edge State Management oder AUTOSAR Network Management / NM) erreicht die VM.
  2. Das lokale State Management verarbeitet das Signal eigenständig und steuert über das lokale Execution Management (StateClient-API, SetState) den geregelten Shutdown/Suspend der Funktionsgruppen (Applikations-Quiescing).
  3. Nach erfolgreichem Herunterfahren der Applikationsebene signalisiert das Gast-OS bzw. die Plattform-Erweiterung (apext::sm::PowerStateInterface) dem Hypervisor den Übergang in den Zustand Suspended (vgl. VM_2) oder Terminated.
• Wake-Up / Resume-Pfad:
  • Der Hypervisor überwacht externe Interrupts oder Netzwerkaktivitäten.
  • Sobald definierte Wake-Up-Events (z. B. Virtual Ethernet Frame oder CAN-Paket) anstehen, überführt der Hypervisor die betroffene Instanz von Suspended nach Running.
  • Das lokale State Management initiiert daraufhin das geordnete Hochfahren der lokalen Funktionsgruppen.

4. Normative Relevanz & Entwickler-Hinweise

• Fehlen standardisierter Hypervisor-APIs: Gemäß SWS State Management existieren keine standardisierten AUTOSAR-Schnittstellen zur direkten Hypervisor-Orchestrierung. Die Interaktion zwischen VM-Gast-OS und Hypervisor erfolgt herstellerspezifisch (BSP/Hypervisor-VMM-Treiber).
• Keine VM-übergreifende Applikations-Kopplung: State Management verbietet eine direkte, synchrone Durchgriffsteuerung von Host-/Hypervisor-Ebene auf Applikationen innerhalb der VM. Entwickler müssen VM-übergreifende Shutdown-Sequenzen asynchron über Kommunikationsmechanismen (ara::com, Network Management) abbilden.
• Autonomie & Fehlerisolation: Jede VM muss bezüglich State Management, Execution Management und Persistenz (ara::per) autonom überlebens- bzw. herunterfahrfähig sein. Schlägt der Suspend einer VM fehl, darf dies nicht zum Blockieren anderer Partitionen führen.
• Wake-up-Konfiguration: Die VM-Konfiguration im Hypervisor muss explizit festlegen, welche Peripherie- oder Netzwerk-Events einen Hypervisor-Resume aus dem Zustand Suspended triggern dürfen.