Figure 5.1: Interfaces provided by Execution Management to other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm mit Schnittstellen- und Realisierungsbeziehungen (Interface Realization & Usage Dependencies).
• Architektur-Kontext: Veranschaulicht die funktionale Schnittstellenbereitstellung des Functional Clusters Execution Management (EM) für andere plattforminterne Daemon-Cluster der AUTOSAR Adaptive Platform (AP) gemäß SWS Execution Management (R23-11, R24-11, Kapitel 5.1). EM fungiert als POSIX-basierter Prozess- und Laufzeitmanager; die übrigen Plattform-Cluster laufen als eigenständige OS-Prozesse (Daemons) und unterliegen bezüglich ihres Lebenszyklus der Steuerung und Zustandsüberwachung durch EM.

2. Komponenten, Entitäten & Schnittstellen

• Bereitstellender Cluster (Provider):
  • Execution Management («aapFunctionalCluster», Tagged Value: daemon-based): Zentraler Daemon zur Prozessinitiierung, Überwachung und Zustandsverwaltung des Systems.
• Exponierte Schnittstelle (Native Interface):
  • ExecutionClient («aapAPI,aapNativeInterface»): C++-Bibliotheksschnittstelle (ara::exec::ExecutionClient), die prozesslokal instanziiert wird und die IPC-Kommunikation zum EM-Daemon kapselt.
    • + Create(): Factory-Methode zur Erzeugung der Client-Instanz und Aufbau der IPC-Verbindung zum EM-Daemon.
    • + ReportExecutionState(ExecutionState): Übergibt den aktuellen Prozessstatus (insb. ara::exec::ExecutionState::kRunning) an EM.
• Konsumierende Cluster (Clients):
  • State Management («aapFunctionalCluster», daemon-based)
  • Platform Health Management («aapFunctionalCluster», daemon-based)
  • Diagnostic Management («aapFunctionalCluster», daemon-based)
  • Update and Configuration Management («aapFunctionalCluster», daemon-based)
  • Time Synchronization («aapFunctionalCluster», daemon-based)
  • Automotive API Gateway («aapFunctionalCluster», daemon-based)
  • Communication Management («aapFunctionalCluster», daemon-based)
  • Network Management («aapFunctionalCluster», daemon-based)
  • Vehicle Update and Configuration Management («aapFunctionalCluster», daemon-based)
  • Intrusion Detection System Manager («aapFunctionalCluster», daemon-based)
  • Cryptography («aapFunctionalCluster», daemon-based)
  • Firewall («aapFunctionalCluster», daemon-based)
• Strukturelle Beziehungen:
  • Interface Realization (gestrichelte Linie mit geschlossenem, nicht ausgefülltem Dreieck): Execution Management implementiert serverseitig die Semantik des ExecutionClient.
  • Usage Dependency («use», gestrichelte Pfeile): Alle zwölf aufgeführten Daemons binden die ExecutionClient-API statisch/dynamisch ein, um ihren Lebenszyklus an EM zu melden.

3. Dynamisches Verhalten & Sequenzablauf

1. Startup & Prozess-Fork: EM startet den jeweiligen Daemon-Prozess basierend auf dem System-/Machine-Manifest (StartupConfig).
2. Client-Initialisierung: Der Plattform-Daemon führt seine internen Setup-Schritte aus und instanziiert frühzeitig den Kommunikationskanal via ExecutionClient::Create().
3. Zustandsmeldung: Sobald der Daemon initialisiert und betriebsbereit ist, setzt er den synchronen Aufruf ReportExecutionState(ExecutionState::kRunning) ab.
4. IPC-Verarbeitung & Transition: EM empfängt die Meldung über den prozessübergreifenden Kanal (z. B. Unix Domain Socket/Shared Memory), aktualisiert den internen Zustand des Prozesses auf Running und entsperrt abhängige Startup-Stufen (Dependencies im Execution Manifest).
5. Fehlerbehandlung: Erfolgt die Meldung kRunning nicht innerhalb des im Manifest parametrierten startupTimeout, löst EM konfigurierte Recovery-Aktionen aus (z. B. Prozessneustart oder Meldung an das State Management / Platform Health Management).

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag: Für jeden Plattform-Daemon, dessen reportingBehavior im Manifest auf reportsExecutionState konfiguriert ist, ist das Absetzen von ExecutionState::kRunning via ExecutionClient zwingend erforderlich. Ein Unterlassen führt zum Timeout-Fehler (SIGKILL/SIGTERM durch EM).
• Prozessautonomie vs. Plattformdienst: Obwohl funktionale Cluster wie State Management (SM) oder Platform Health Management (PHM) Steuerungs- bzw. Überwachungsfunktionen wahrnehmen, verhalten sie sich gegenüber EM bezüglich ihres Lebenszyklus wie gewöhnliche Adaptive Applications.
• Deadlock-Prävention: Da EM und SM/PHM zirkuläre funktionale Abhängigkeiten aufweisen können (z. B. SM fordert Funktionsgruppenwechsel an, EM startet Daemons), darf ReportExecutionState() in der main() des Daemons nicht durch blockierende Aufrufe an noch nicht aktive Nachbar-Cluster verzögert werden.
• Rückgabewert: Das Ergebnis von ReportExecutionState() muss explizit auf ara::core::ErrorCode geprüft werden; ein fehlerhafter Aufruf indiziert einen Abriss des IPC-Kanals zu EM.