Figure 7.22: Example for an ActionList using ActionListItem Sleep

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Zustandsdiagramm-Ausschnitt (State Machine State) mit eingebetteter Aktionsliste (<<ActionList>>).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (SM) gemäß AUTOSAR_AP_SWS_StateManagement (Releases R23-11, R24-11, R25-11; bezugnehmend auf RS_SM_00001, RS_SM_00005, SWS_SM_00601).
• Technischer Zweck: Spezifikation und Veranschaulichung der Ausführungssemantik einer ActionList beim Eintritt in den Zustand Shutdown. Der Fokus liegt auf der deklarativen Steuerung heterogener Aktionen (Agenten-Kommunikation, Synchronisationsbarrieren, Wartezeiten und Function-Group-Zustandswechsel) innerhalb einer deterministischen Zustandsübergangskette.

2. Komponenten, Entitäten & Schnittstellen

• <<StateMachineState>> Shutdown:
  • Konkreter Zustand innerhalb eines SM-Zustandsautomaten (SWS_SM_00601).
  • Dient als Trägerzustand für die Entry- bzw. Do-Aktivität in Form einer ActionList.
• <<ActionList>>:
  • Container-Metaklasse zur sequenziellen/parallelen Bündelung diskreter ActionListItem-Instanzen (SWS_SM_00620).
• Enthaltene ActionListItem-Entitäten & Schnittstellen:
  • Agent1.start(PrepareForShutdown): Aufruf/Event an einen externen bzw. internen Funktionsagenten (Agent1) mit Übergabe des Parameters bzw. Teilzustands PrepareForShutdown (asynchrone Interaktionsschnittstelle, z. B. via ara::com Field/Method/Event).
  • Agent2.stop: Stop-Kommando an Agent2 zur Beendigung der jeweiligen Prozess- bzw. Funktionsgruppe.
  • SYNC (ActionListItemSync): Metamodell-Synchronisationsbarriere (SWS_SM_00621). Unterbricht das Voranschreiten in der ActionList, bis alle vorhergehenden asynchronen Aktionen quittiert wurden oder ihren Zielzustand erreicht haben.
  • Agent1.stop: Nachgelagerter Stopp-Befehl an Agent1, nachdem dieser die Vorbereitungen abgeschlossen hat.
  • Sleep(120s) (ActionListItemSleep): Zeitgesteuertes Verzögerungselement (SWS_SM_00624). Blockiert das Weiterschreiten in der ActionList für die parametrierte Dauer von 120 Sekunden (z. B. für Nachlaufzeiten, Data-Flushes oder Busruhe-Vorbereitungen).
  • MachineFG::Shutdown: Zustandsänderungsanforderung an das Execution Management (EM) via ara::exec::FunctionGroupState für die Maschinen-Funktionsgruppe MachineFG (SWS_SM_00651).

3. Dynamisches Verhalten & Sequenzablauf

1. Zustandseintritt: Die State Machine wechselt in den Zustand Shutdown. Die zugeordnete ActionList wird instanziiert bzw. sequenziell gestartet.
2. Parallele/Asynchrone Initiierung:
   • Agent1.start(PrepareForShutdown) wird non-blocking abgesetzt.
   • Agent2.stop wird unmittelbar danach non-blocking getriggert.
3. Synchronisationsbarriere (SYNC):
   • Die Abarbeitung der ActionList pausiert. State Management wartet auf Bestätigungen (Responses/Acknowledgements) für Agent1.start und Agent2.stop.
4. Sequenzieller Folgeaufruf:
   • Sobald beide Quittungen vorliegen, wird Agent1.stop abgesetzt und synchron/asynchron abgeschlossen.
5. Zeitverzögerung (Sleep):
   • Das Element Sleep(120s) pausiert die weitere Bearbeitung der ActionList für exakt 120.000 ms.
   • Die Verzögerung läuft timerbasiert; andere, unbeteiligte Zustandsautomaten und die interne Event-Loop von SM dürfen dadurch nicht blockieren.
6. Abschluss & Maschinenübergang:
   • Nach Ablauf des Timers wird MachineFG::Shutdown angefordert.
   • Execution Management leitet den finalen Shutdown der Machine-Function-Group (SIGTERM/SIGKILL-Kaskaden der verbleibenden Prozesse) ein.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsmodell (ARXML):
  • Entwickler müssen ActionListItems im ARXML-Manifest typisieren. Sleep erfordert die Angabe einer Zeiteinheit (TimeValue in Sekunden/Millisekunden) gemäß Schema AUTOSAR_MOD_StateManagement.
• Event-Loop & Threading:
  • ActionListItemSleep darf im SM-Daemon keinesfalls über ein synchrones OS-Sleep (wie posix::nanosleep / std::this_thread::sleep_for) auf dem Dispatcher-Thread realisiert werden, da sonst Watchdog-Triggerung (ara::phm), IPC-Abfertigung (ara::com) und Signalhandling eingefroren würden. Es muss ein asynchroner Timer (z. B. via timerfd, Epoll oder Asio-Timer) genutzt werden.
• Watchdog- & Power-Management-Wechselwirkungen:
  • Eine Wartezeit von 120 s übersteigt typische Watchdog-Alive-Supervision-Zyklen (ara::phm). Beteiligte Entitäten müssen während dieser Phase ordnungsgemäß de-registriert oder die Checkpoints angepasst werden.
  • Hardware-Versorgung (Klemme 30/15 Nachlaufsteuerung) muss für die Dauer des Sleep garantiert sein, um Brownouts oder unvollständige Shutdowns zu verhindern.
• Fehlerbehandlung (Error Handling):
  • Schlägt eine Quittung vor dem SYNC fehl oder tritt ein Timeout bei Agent1/Agent2 auf, greift das in SWS_SM_00620 spezifizierte Fallback-Verhalten (Triggerung einer Transitions-spezifischen Recovery-ActionList oder Eskalation an das PHM/Platform Health Management).