Figure 7.19: Arbitrary order for ActionListItems

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Zeitablaufdiagramm (Timing Diagram / State Transition Schedule) mit Synchronisationsbarrieren.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation State Management (AUTOSAR_AP_SWS_StateManagement).
• Funktionale Einordnung: Veranschaulicht die sequenzielle und parallele Abarbeitung konfigurierter Aktionslisten (ActionList / ActionListItem) beim Zustandswechsel einer übergeordneten State Machine (StateMachine1). Demonstriert, wie funktionale Abhängigkeiten zwischen Funktionsgruppen (Function Groups, FG) durch gezielte Platzierung von Synchronisationspunkten (SYNC) ohne feste globale Abarbeitungsreihenfolge deterministisch aufgelöst werden.

2. Komponenten, Entitäten & Schnittstellen

• StateMachine1: Übergeordnete Zustandsmaschine des State Management (SM) mit den diskreten Steuerzuständen SM1:Running und SM1:Fallback.
• FunctionGroup (FG1, FG2, FG3, FG4): Durch das Execution Management (EM) kontrollierte logische Gruppierungen von Prozessen. Dargestellte Zustände pro Funktionsgruppe:
  • Off (inaktiv / terminiert)
  • Running (regulärer Betriebsmodus)
  • Fallback (degradierter / sicherer Funktionsmodus)
• ActionList & ActionListItem: Deklarative Metamodell-Strukturen zur Definition von Zustandsübergängen:
  • State-Change-Anforderung: Asynchroner Trigger zur Zustandsänderung einer spezifischen FunctionGroup via Execution-Management-Schnittstelle (ara::exec::StateClient).
  • Synchronisationsbarriere (SYNC): Kontrollflusselement innerhalb der ActionList, das die Ausführung nachfolgender ActionListItems blockiert, bis alle vorangehenden asynchronen Zustandswechsel erfolgreich abgeschlossen und quittiert wurden.
• Schnittstellenbeziehung: State Management fungiert als anfordernde Entität; das Execution Management setzt die Prozesslebenszyklen (Start, Signalierung, SIGTERM/SIGKILL) entsprechend den FG-Zuständen um.

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: Aktivierung von SM1:Running

1. Initiale Auslösung: Die ActionList für SM1:Running wird aktiviert.
2. Parallele Anforderung:
   • Anforderung FG1: Running
   • Anforderung FG2: Running
   • Beide Zustandsübergänge starten asynchron (FG2 erreicht Running vor FG1; FG1 benötigt längere Transition).
3. Erster Synchronisationspunkt (SYNC):
   • Die Abarbeitung der ActionList pausiert an der Barriere.
   • FG3 verbleibt in Off, FG4 verbleibt in Off.
4. Freigabe nach Quittierung: Sobald sowohl FG1 als auch FG2 stabil im Zustand Running sind (vertikale gestrichelte Synchronisationslinie), wird die Barriere entsperrt.
5. Nachfolgende Aktionen:
   • Anforderung FG3: Running (Transitionsphase startet erst nach Erreichen von SYNC).
   • Anforderung FG4: Off (Zustand bleibt unverändert Off).

Phase 2: Transition zu SM1:Fallback

1. Trigger: StateMachine1 wechselt von Running zu Fallback.
2. Veränderte Reihenfolge der Anforderungen (Dependency-Inversion):
   • Anforderung FG1: Fallback
   • Anforderung FG3: Fallback
   • Anforderung FG4: Running (FG4 fährt von Off auf Running hoch).
   • FG2 wird zunächst nicht verändert und verbleibt aktiv auf Running (wichtig für Dienste, auf die FG1/FG3/FG4 während des Herunterfahrens/Umschaltens angewiesen sind).
3. Zweiter Synchronisationspunkt (SYNC):
   • Warten auf vollständige Quittierung der Zustände FG1: Fallback, FG3: Fallback und FG4: Running.
4. Abschließende Aktionen:
   • Nach Passieren der SYNC-Barriere wird FG2: Off ausgelöst.
   • FG2 rampt von Running auf Off ab, während alle anderen FGs ihre neuen Zielzustände bereits stabil eingenommen haben.

4. Normative Relevanz & Entwickler-Hinweise

• Vermeidung von Race Conditions: Zwischen FGs existieren Laufzeit- und IPC-Abhängigkeiten (z. B. Server-Client-Hierarchien). Die freie Platzierbarkeit (Arbitrary order) von SYNC in der ARXML-Modellierung erlaubt es dem Systemarchitekten, Hochlauf- und Shutdown-Ketten strikt abzusichern, ohne hardcodierte Logik im Applikationscode zu implementieren.
• API- & Kommunikationsverhalten: Umschaltkommandos an das Execution Management (ara::exec::StateClient::SetState) sind asynchron und liefern ara::core::Future-Objekte zurück. Ein SYNC-Item korrespondiert intern mit dem Warten (Wait() / .get()) auf die Fertigstellung dieser Futures, bevor die nächste Iteration der ActionList abgearbeitet wird.
• ARXML-Konfigurationsregel:
  • Reihenfolge im Metamodell bestimmt strikt die Ausführungssequenz.
  • Werden mehrere FG-State-Requests ohne dazwischenliegendes SYNC definiert, stößt der State Manager diese unmittelbar parallel/ohne deterministische Reihenfolge an.
• Timeout- und Fehlermanagement: Schlägt eine Umschaltung vor einer SYNC-Barriere fehl (z. B. Prozess reagiert nicht auf SIGTERM innerhalb der EM-Grace-Period oder meldet Fehler), wird der SYNC-Punkt nicht freigegeben. Das State Management muss in diesem Fall die konfigurierte Fehlerbehandlungs-Aktionsliste (Rollback / Safe State) initiieren; nachgelagerte Schritte (wie das Abschalten von FG2) werden nicht mehr regulär erreicht.