Figure 7.9: Example for Controller StateMachineStates with MachineFG

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Zustandsdiagramm (State Machine Diagram) mit AUTOSAR-spezifischen Profil-Stereotypen (<<StateMachine>>, <<StateMachineState>>, <<ActionList>>).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (ARA), Kernkomponente State Management (SM) nach AUTOSAR_AP_SWS_StateManagement. Das Diagramm exemplifiziert das Zusammenspiel zwischen einer SM-Zustandsmaschine (Controller), den darin gekapselten Aktionslisten (ActionList), den Prozess-/Applikationslebenszyklen (Agent1, Agent2) und den Zuständen der zentralen Maschinen-Funktionsgruppe (MachineFG) unter Kontrolle des Execution Management (EM) gemäß RS_SM_00001, RS_SM_00005 und SWS_SM_00648.

2. Komponenten, Entitäten & Schnittstellen

• <<StateMachine>> Controller: Oberste Zustandsmaschinen-Entität im State Management, welche den globalen Lebenszyklus der Partition/Maschine steuert.
• Zustände (<<StateMachineState>>):
  • Initial State: Boot-/Initialisierungsphase der Maschine.
  • Normal Mode: Regulärer Betriebsmodus für Applikationen.
  • Shutdown: Gesteuerter De-Initialisierungs- und Herunterfahrzustand.
  • Restart: Geordneter Neustartzustand der Plattform/Maschine.
  • Pseudozustände: Initial State (Eintrittspunkt, gefüllter schwarzer Kreis) und Final State (Terminierungspunkt, Bullseye/Doppelkreis).
• Aktionslisten (<<ActionList>>):
  • Pro Zustand definierte, deterministische Sequenz auszuführender Operationen (im Zustand Restart herstellungsbedingt mit Tippfehler als <<ActionListl>> annotiert).
• Zustandskontrollierte Entitäten & Direktiven:
  • MachineFG::<State> (fett hervorgehoben): Zustandsanforderung an die vom Execution Management verwaltete vordefinierte Funktionsgruppe MachineFG (Startup, Shutdown, Restart) über das ara::exec::StateClient-Interface.
  • Agent<N>.<action>: Prozess- bzw. Funktionsgruppensteuerung auf Applikationsebene (start, stop).
  • SYNC: Synchronisationsbarriere innerhalb der Aktionsliste; erzwingt das synchrone Warten auf den Vollzug vorangegangener asynchroner EM-Operationen bzw. Prozesszustandswechsel.
• Kardinalitäten & Übergänge:
  • Deterministische 1:1-Übergänge vom Start in Initial State und weiter in Normal Mode.
  • Disjunkte Verzweigung von Normal Mode nach Shutdown oder Restart (externe Trigger).
  • Konvergierende Transitionen von Shutdown und Restart in den gemeinsamen Endzustand (Final State).

3. Dynamisches Verhalten & Sequenzablauf

1. Systemstart (Initial State):
   • Eintritt via Initial-Transition nach Power-On/Reset.
   • Schritt 1: Anforderung MachineFG::Startup an Execution Management (Initialisierung grundlegender Plattformdienste).
   • Schritt 2 (SYNC): SM blockiert die weitere Abarbeitung der Liste, bis EM den erfolgreichen Wechsel von MachineFG in den Zustand Startup asynchron meldet (ara::core::Future::GetResult bzw. interner Callback).
   • Schritt 3 & 4: Start von Agent1 (Agent1.start) und explizite Sicherstellung des Ruhezustands von Agent2 (Agent2.stop).
2. Betriebsphase (Normal Mode):
   • Transition von Initial State nach Normal Mode.
   • Bekräftigung/Beibehaltung von MachineFG::Startup.
   • Starten der aktiven Anwendungslogik (Agent1.start bleibt aktiv, Agent2.start wird angestoßen). Da kein SYNC zwischengeschaltet ist, können Agent-Starts parallel/asynchron abgesetzt werden.
3. Abschaltpfad (Shutdown) / Neustartpfad (Restart):
   • Trigger (z. B. Klemme-15-Aus, Diagnosebefehl, Update-Request) triggert die Transition von Normal Mode in Shutdown oder Restart.
   • Schritt 1 & 2: Zuerst werden alle Applikationsprozesse gestoppt (Agent1.stop, Agent2.stop).
   • Schritt 3 (SYNC): Zwingende Synchronisationsbarriere. SM wartet, bis alle Prozesse sauber terminiert sind, Ressourcen freigegeben und POSIX-Signale (SIGTERM/SIGKILL) durch EM abgewickelt wurden.
   • Schritt 4: Erst nach vollständiger Bestätigung aller Prozess-Terminierungen wird MachineFG::Shutdown bzw. MachineFG::Restart an EM gesendet, um Systemdienste abzuschalten und den Machine-Off/Reboot über das OS einzuleiten.
4. Terminierung:
   • Übergang in den Final State nach Abarbeitung der letzten Aktion.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Modellierung (ARXML):
  • Jede ActionList bildet sich direkt in den ARXML-Beschreibungen von State Management ab (PortInterface, Rule, ActionList, StateClient-Mapping).
  • Entwickler müssen ActionListExecutionEnum und Abhängigkeiten zwischen FunctionGroupState und Prozessstarts modellieren.
• API-Vertrag (ara::exec::StateClient & SWS_SM_00648):
  • MachineFG-Wechsel werden über SetState() initiiert. Ein SYNC-Eintrag im Schaubild verpflichtet die State-Management-Implementierung, das zurückgegebene ara::core::Future vor dem nächsten Listenschritt aufzulösen (wait() / Callback-Kette).
• Vermeidung von Inversion / Race Conditions:
  • Die gezeigte Sequenz (Agent*.stop → SYNC → MachineFG::Shutdown) ist das normative Entwurfsmuster gegen vorzeitiges Entziehen von Plattform-Ressourcen (z. B. Persistenz, IPC, Logging), während Applikations-Agents noch Daten flashen oder Shutdown-Hooks ausführen.
• Konfigurationspflicht für Integratoren:
  • Timeouts für SYNC-Barrieren müssen im Manifest so kalibriert sein, dass hängende Prozesse über EM-Recovery-Mechanismen (Escalation to SIGKILL / Dem-Event) abgefangen werden, bevor der SM-Watchdog anschlägt.