Figure 5.3: Interfaces required by Execution Management from other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform UML-Profil / «aap...»-Stereotypen).
• Funktionale Einordnung: Dargestellt sind die normativen Abhängigkeiten (Required Interfaces) des Functional Clusters Execution Management (EM) zu anderen Clustern und der Basisinfrastruktur innerhalb der AUTOSAR Adaptive Platform (AP R23-11 / R25-11).
• Technischer Zweck: Spezifikation der Schnittstellen, die der EM-Daemon zwingend konsumiert, um seine Kernaufgaben zu erfüllen:
  1. Prozesslebenszyklus-Steuerung über das Host-Betriebssystem.
  2. Plattform-Zustandsüberwachung und Alive-Supervision via Platform Health Management (PHM).
  3. Diagnostische und betriebliche Protokollierung via Log and Trace (LT).

2. Komponenten, Entitäten & Schnittstellen

Akteure / Komponenten

• «aapFunctionalCluster» Execution Management (daemon-based):
  • Zentraler Prozesssteuerungs-Daemon der Adaptive Platform.
  • Tritt bezüglich der dargestellten Schnittstellen ausschließlich als Konsument («use») auf.
• «aapFunctionalCluster» Log and Trace:
  • Realisiert (InterfaceRealization) die native Logging-Schnittstelle.
• «aapFunctionalCluster» Platform Health Management (daemon-based):
  • Realisiert die Überwachungsschnittstelle für beaufsichtigte Entitäten.
• Operating System:
  • Host-OS / Kernel-Abstraktion (z. B. POSIX-konformes RTOS wie QNX, Linux, INTEGRITY, PikeOS), welche die Low-Level-Prozessverwaltung implementiert.

Schnittstellen, Operationen & Stereotypen

1. Logger («aapAPI, aapNativeInterface»):
   • Beziehung: EM nutzt («use») die Schnittstelle; Realisierung durch Log and Trace.
   • Typ: In-Process C++ Standard-API (ara::log).
   • Methoden:
     • IsEnabled(): Abfrage der aktiven Log-Filterung/Severity.
     • Log(MsgId, Params): Strukturierte DLT-Nachrichtenerzeugung.
     • LogDebug(), LogError(), LogFatal(), LogInfo(), LogVerbose(), LogWarn(): Rückgabe eines typisierten LogStream-Objekts zur Stream-basierten Formatierung.
     • WithLevel(): Dynamische Zuweisung des Log-Levels zur Laufzeit.
2. SupervisedEntity («aapAPI, aapPortInterface»):
   • Beziehung: EM greift über einen typisierten Port («aapRequiredPort», «use») auf PHM zu; Realisierung durch Platform Health Management.
   • Typ: Service- bzw. IPC-basiertes Interface (ara::phm).
   • Methoden:
     • ReportCheckpoint(): Übermittlung erreichter Checkpoints zur Alive-, Deadline- und Logical-Supervision des EM-Daemons selbst.
3. Multi-Process System Interface («aapInternal»):
   • Beziehung: EM nutzt («use») die interne Betriebssystem-Schnittstelle; Realisierung durch das Operating System.
   • Typ: OS-Kernel/System-Call-Abstraktionsschicht.
   • Methoden:
     • SetProcessConfiguration(): Zuweisen von POSIX-Parametern vor dem Start (Resource Limits, Scheduling-Policies/Prioritäten, CPU-Affinities, User/Group-IDs, Security-Labels/SELinux/AppArmor).
     • StartProcess(): Erzeugung und Ausführung des Zielprozesses (fork/execve, posix_spawn).
     • TerminateProcess(): Geordnetes bzw. erzwungenes Beenden von Prozessen (Senden von Signalen wie SIGTERM, gefolgt von SIGKILL nach Timeout).

3. Dynamisches Verhalten & Sequenzablauf

1. Early Bootstrapping & OS-Kopplung (Synchron):
   • Nach dem Kernel-Init wird der EM-Daemon gestartet.
   • EM liest das Machine Manifest und das Initial Execution Manifest ein.
   • EM ruft synchron SetProcessConfiguration() auf dem Multi-Process System Interface auf, um Prozessattribute (Cgroups, Scheduling, UID/GID) vorzubereiten.
   • EM initiiert über StartProcess() den Start grundlegender Plattform-Daemons (darunter Log and Trace und PHM).
2. Logging-Phase (Synchron / Puffernd):
   • Sobald Log and Trace aktiv ist (oder initial über Early-Buffer/Fallback), instanziiert EM Logger-Objekte.
   • EM meldet Zustandsübergänge von Function Groups und Prozesslebenszyklen via LogInfo(), LogError() etc. als deterministische Streams.
3. Health-Supervision-Zyklus (Asynchron / Event-basiert):
   • Zur Laufzeit führt EM zyklische Überwachungs- und Zustandswechsel-Routinen aus.
   • EM ruft an definierten Ausführungsmarken SupervisedEntity::ReportCheckpoint() auf.
   • Bei Ausbleiben von Checkpoints (z. B. EM-Deadlock) leitet PHM plattformweite Recovery-Aktionen (Watchdog-Trigger, Core-Reset) ein.
4. Shutdown / State Transition (Synchron & Asynchron):
   • Bei Wechsel einer Function Group oder Machine State Termination ruft EM TerminateProcess() auf.
   • EM wartet asynchron auf den Exit-Status des Prozesses via OS-Signale (SIGCHLD), überwacht die Termination-Timeouts und loggt das Ergebnis über Logger.

4. Normative Relevanz & Entwickler-Hinweise

• Architektonische Schranke («aapInternal» vs. «aapAPI»):
  • Multi-Process System Interface ist nicht Teil der portablen ara::-Applikationsschnittstellen, sondern muss im Adaptive Core Plattform-Port (BSP/OS-Integrator) implementiert werden.
  • Applikationen dürfen dieses Interface unter keinen Umständen aufrufen; die Prozesskontrolle obliegt exklusiv dem Execution Management.
• Bootstrap-Dilemma & Zirkularität:
  • Da EM Log and Trace und PHM selbst per StartProcess() startet, muss die EM-Implementierung zirkuläre Abhängigkeiten während des Startups behandeln:
    • Vor Verfügbarkeit des Logger-Dienstes muss EM interne Early-Logging-Mechanismen (z. B. stderr, Ringpuffer oder Kernel-Console) nutzen.
    • Vor Bereitstellung des PHM-Daemons dürfen Checkpoint-Reports nicht blockieren (Fallback auf Fail-Silent oder lokales Queuing).
• Port-Konfiguration im Execution Manifest:
  • Die Verwendung von SupervisedEntity erfordert ein entsprechendes Deployment im Manifest: Definition der Checkpoint-IDs, Supervision-Zyklen und Zuordnung des «aapRequiredPort» zum Modell des PHM.
• Sicherheit & Privilegien:
  • Das OS-Interface bedingt Root- bzw. CAP_SYS_ADMIN/CAP_SETUID-Rechte für den EM-Daemon, um Isolation, Sandbox-Flags, UID-Drops und Scheduling-Prioritäten für andere Prozesse bindend zu setzen.