Figure 9.3: Interfaces for state reporting

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR AP Architecture Blueprint).
• Technischer Zweck: Spezifikation des Zustandsmelde-Mechanismus (State Reporting) zwischen OS-Prozessen und dem Plattform-Daemon des Functional Clusters Execution Management (EM) gemäß AUTOSAR Adaptive Platform R21-11.
• Architektonische Einordnung: EM ist für den deterministischen Lebenszyklus aller Prozesse zuständig. Die Schnittstelle entkoppelt den überwachenden Daemon von der überwachten Applikation über eine clientseitige Laufzeitbibliothek.

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Application (UML-Komponente):
  • Repräsentiert den Instanz-Prozess einer Anwendungs- oder Plattform-Software auf der Adaptive Machine.
• Execution Management (UML-Komponente):
  • Stereotyp: «aapFunctionalCluster», Ausprägung: daemon-based.
  • Zentraler Hintergrunddienst im User Space zur Prozessverwaltung, Zustandsverifikation und Integritätsprüfung.
• ExecutionClient (Schnittstelle):
  • Stereotypen: «aapAPI», «aapNativeInterface».
  • C++-Laufzeitschnittstelle (ara::exec::ExecutionClient), lokal in den Prozess der Applikation gelinkt.
  • Operationen:
    • + Create(): Statische Erzeugungsmethode / Factory-Funktion (im UML-Klassendiagramm unterstrichen dargestellt) zur Instanziierung des ExecutionClient.
    • + ReportExecutionState(ExecutionState): Result:
      • Parameter: ExecutionState (Typ ara::exec::ExecutionState, z. B. kRunning).
      • Rückgabe: Result (ara::core::Result<void> für fehlerbasiertes Error-Handling ohne C++-Exceptions).
• Beziehungen:
  • Adaptive Application → ExecutionClient: «use»-Abhängigkeit; die Applikation instanziiert und ruft die Client-Klasse auf.
  • Execution Management daemon-based → ExecutionClient: Schnittstellenrealisierung (Interface Realization, gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze); der Daemon implementiert die serverseitige Logik hinter der nativen API via Betriebssystem-IPC.

3. Dynamisches Verhalten & Sequenzablauf

1. Prozessstart: EM erzeugt den Prozess der Adaptive Application (via OS-Systemaufrufe fork/exec gemäß dem zugrundeliegenden ExecutionManifest).
2. Initialisierung: Die Applikation führt ihre interne Initialisierung aus (Plattformbasis, Memory Allocations, Threads, ara::core::Initialize()).
3. Zustandsmeldung:
   • Sobald die Applikation funktionsbereit ist, ruft sie synchron ReportExecutionState(ExecutionState::kRunning) am lokalen ExecutionClient auf.
   • Der ExecutionClient serialisiert die Nachricht und übermittelt sie per schneller OS-Interprozesskommunikation (Unix Domain Sockets, Pipes oder POSIX Message Queues) an den EM-Daemon.
4. Zustandsübergang in EM:
   • Der EM-Daemon empfängt den Report, verifiziert die Prozessidentität (PID/UID) und schaltet den internen Prozessstatus auf Running.
   • Die Operation kehrt zur Applikation mit einem erfolgreichen ara::core::Result<void> zurück.
5. Timeout- und Fehlerbehandlung:
   • Sendet die Applikation den Status kRunning nicht innerhalb des im Manifest konfigurierten startupTimeout, deklariert EM einen Startup-Fehler.
   • Mögliche Konsequenzen: Prozess-Terminierung (SIGTERM/SIGKILL), Restart-Versuch oder Fehlermeldung an das State Management (SM) zur Einleitung von Recovery-Aktionen.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Pflicht: Jeder durch EM gestartete Prozess (sowohl Adaptive Application als auch Plattform-Cluster-Dienste) muss seinen Zustand über ara::exec::ExecutionClient melden. Ein Unterlassen führt zum Timeout-Abbruch durch EM.
• Native Interface vs. ara::com: ExecutionClient ist bewusst ein «aapNativeInterface» und kein serviceorientierter ara::com-Dienst. Dies gewährleistet, dass das State-Reporting ohne Abhängigkeit von Communication Management, IPC-Daemonen oder Service-Discovery in frühesten Boot-Phasen sicher funktioniert.
• Timing-Budgetierung: Embedded-Entwickler müssen sicherstellen, dass die Vorinitialisierung (inklusive Blockaden durch Dateizugriffe, Hardware-Initialisierung etc.) vor dem ReportExecutionState-Aufruf strikt unter dem konfigurierten startupTimeout des ExecutionManifest bleibt.
• Aufruf-Position: Der Aufruf von ReportExecutionState(ExecutionState::kRunning) markiert den Eintritt in die zyklische Arbeitsphase bzw. Service-Bereitschaft und sollte unmittelbar vor Eintritt in die Event-Loop / Worker-Threads erfolgen.