Figure 7.16: Parallel ActionListItem execution and SYNC

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Zeitliches Ablauf- und Zustandsüberführungsdiagramm (Timing / Execution State Diagram).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (SM) in Interaktion mit dem Execution Management (EM).
• Technischer Zweck: Spezifikation der Ausführungssemantik von ActionList und ActionListItem bei Zustandswechseln. Das Diagramm demonstriert die asynchrone, nicht-blockierende Beauftragung mehrerer Funktionsgruppen-Zustandswechsel (FunctionGroupStateRequest) sowie die Barriere-Wirkung des Synchronisationselements SYNC.

2. Komponenten, Entitäten & Schnittstellen

• StateMachine1 (SM1): Übergeordnete Zustandsmaschine im SM mit den Makro-Zuständen SM1:Off und SM1:Running. Sie instanziiert und triggert die zugeordnete ActionList.
• Function Groups (FG1, FG2, FG3, FG4): Durch das Execution Management verwaltete logische Gruppierungen von Prozessen (Process) mit den diskreten Zuständen Off, Running und Fallback.
• ActionList & ActionListItems:
  • Geordnete Liste von Aktionen zur Überführung der Funktionsgruppen:
    1. FG1 : Running (Asynchroner Zustandswechselauftrag)
    2. FG2 : Running (Asynchroner Zustandswechselauftrag)
    3. SYNC (Synchronisationsbarriere / Kontrollfluss-Primitiv)
    4. FG3 : Running (Asynchroner Zustandswechselauftrag nach Barrierendurchlauf)
  • FG4 ist nicht Bestandteil der modifizierenden Aktionen und verharrt konstant auf Off.
• Schnittstellen (AP-intern): IPC-Schnittstelle zwischen SM und EM via ara::exec::StateClient::SetState bzw. Interaktion über ara::exec::FunctionGroup unter Rückgabe von ara::core::Future-Instanzen.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialzustand: StateMachine1 befindet sich im Zustand SM1:Off. Sämtliche Funktionsgruppen (FG1..FG4) sind im Zustand Off.
2. Transition & Parallele Beauftragung (Phase 1):
   • Zustandswechsel von StateMachine1 nach SM1:Running triggert die sequenzielle Abarbeitung der ActionList.
   • Die Anforderungen FG1 -> Running und FG2 -> Running werden in definierter Reihenfolge unmittelbar hintereinander abgesetzt.
   • Nicht-blockierender Pfad: SM wartet nicht auf die Quittierung oder Fertigstellung der Transition durch das EM (Ordered requests, without waiting for request to be finished). Beide FGs führen ihre Transition parallel aus; FG2 erreicht den Zielzustand schneller als FG1.
3. Synchronisationsbarriere (Phase 2):
   • Das Auftreten des Elements SYNC unterbricht die Dispatching-Schleife der ActionList.
   • Das SM blockiert die Ausführung nachfolgender ActionListItems, bis alle vor dem SYNC initiierten Transitionen erfolgreich abgeschlossen und vom EM quittiert sind.
   • Der Synchronisationszeitpunkt (strichpunktierte Linie) wird durch den langsamsten Vorläufer bestimmt (hier: Quittierung von FG1).
4. Sequenzfortsetzung (Phase 3):
   • Nach erfolgreichem Abschluss aller Vorläuferoperationen wird die nächste Aktion FG3 -> Running abgesetzt (Next request only when previous ones are finished, due to "SYNC").
   • FG3 wechselt in den Zustand Running.
5. Endzustand: StateMachine1 verbleibt in SM1:Running. FG1, FG2 und FG3 befinden sich in Running, FG4 bleibt unverändert in Off.

4. Normative Relevanz & Entwickler-Hinweise

• Parallelisierung & Bootzeit-Optimierung: Standardmäßig werden ActionListItems asynchron angestoßen (Fire-and-Observe). Dies ermöglicht maximale Nebenläufigkeit beim Hochfahren von Funktionsgruppen und kompensiert heterogene Initialisierungs- und I/O-Laufzeiten im EM.
• Deterministische Abhängigkeitssteuerung: Bestehen funktionale Abhängigkeiten (z. B. Basiskommunikations- oder Logging-Dämonen in FG1/FG2 müssen vollständig einsatzbereit sein, bevor Applikationen in FG3 starten), muss im Modell ein explizites SYNC-Element in die ActionList eingefügt werden.
• Manifest-Konfiguration: Entwickler modellieren diese Kette im ARXML über die Reihenfolge der Elemente in der ActionList. Das Fehlen von SYNC bei impliziten Abhängigkeiten führt zu Race Conditions im Prozessstart; unnötig gesetzte SYNC-Barrieren serialisieren die Ausführung und degradieren die Hochlaufzeit.
• Fehlersemantik: Schlägt eine Transition vor der SYNC-Barriere fehl (z. B. Timeout oder ara::exec::ExecErrc::kSetStateFailed), muss die Fehlerbehandlung der ActionList greifen (Rollback, Eintritt in Fallback-Zustand oder Abbruch des Makro-Zustandswechsels). Der SYNC-Knoten dient hierbei als Aggregationspunkt für den Status vorangegangener Futures.