Figure 7.1: Start-up Sequence – from Startup to initial running state Driving

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.0 Sequenzdiagramm (sd Startup to Initial StateXYZ) mit Interaktionsrahmen (loop).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R20-11. Dargestellt ist der deterministische Hochlauf der Machine von der Initialisierung des POSIX-Betriebssystems über das Aufsetzen der Basisinfrastruktur durch das Execution Management (EM) bis zur Anforderung des ersten operationalen Anwendungszustands (StateXYZ der Funktionsgruppe MachineFG) durch das State Management (SM).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • OS: Host-/POSIX-Betriebssystem bzw. Initialisierungssystem (Kernel/Init), verantwortlich für den Start des ersten Userspace-Root-Prozesses.
  • EM (Execution Management): Zentraler funktionaler Cluster der AUTOSAR Adaptive Core Platform zur Steuerung von Prozesslebenszyklen und Function Group States.
  • SM (State Management): Funktionaler Cluster zur Auswertung fahrzeugweiter Ereignisse, Regelverarbeitung und Anforderung von Zielzuständen an das EM.
• Schnittstellen & Interaktionspfade:
  • main(): Entry-Point-Aufruf des OS zur Instanziierung des EM-Daemon-Prozesses.
  • CreateProcess(SM): Plattformspezifische Prozesserzeugung (z. B. fork/exec oder posix_spawn) durch EM basierend auf dem Execution Manifest.
  • ExecutionClient::ReportExecutionState(kRunning): Standardisierte C++-API (ara::exec::ExecutionClient), über die Applikationen/Cluster ihren betriebsbereiten Zustand an EM melden.
  • SetState("MachineFG", StateXYZ): Zustandswechselanforderung von SM an EM für die Funktionsgruppe MachineFG in den Zielzustand StateXYZ (standardisiert über ara::exec::StateClient::SetState).

3. Dynamisches Verhalten & Sequenzablauf

1. OS-Bootstrap & EM-Start: Das Betriebssystem schließt den Kernel-Boot ab und startet synchron über main() den EM-Prozess.
2. Plattform-Initialisierung (loop [All Platform Processes]):
   • EM liest das Machine- und Execution-Manifest aus und ermittelt alle Prozesse, die dem initialen Zustand zugeordnet sind.
   • Iterativ stößt EM für alle Plattformprozesse (stellvertretend SM) die Prozesserzeugung an (CreateProcess).
   • Jeder gestartete Prozess führt seine Low-Level-Initialisierung durch und meldet synchron über ExecutionClient::ReportExecutionState(ara::exec::ExecutionState::kRunning) seine Bereitschaft an EM.
3. Abschluss Plattform-Startup & Transition:
   • Sobald SM und die erforderlichen Plattformprozesse laufen, wertet SM seine internen Startbedingungen aus (ohne separate Rückmeldung ConfirmMachineState von EM).
   • SM fordert bei EM den Folgezustand an: SetState("MachineFG", StateXYZ).
   • EM initiiert daraufhin das Starten aller weiteren Prozesse, die für MachineFG/StateXYZ im Manifest hinterlegt sind.

4. Normative Relevanz & Entwickler-Hinweise

• Zustandssemantik: Startup ist der zwingend vorgeschriebene initiale Funktionsgruppenzustand nach dem Booten. Der Folgezustand StateXYZ der Funktionsgruppe MachineFG ist ein generischer Platzhalter für einen projektspezifischen operationalen Zustand; Name und Anzahl operationaler Zustände sind im Manifest frei konfigurierbar.
• ExecutionClient-Reporting-Pflicht:
  • Jeder gestartete Prozess (Plattform- und Standard-Applikationen) muss ReportExecutionState(kRunning) absetzen.
  • Unterbleibt diese Meldung innerhalb des im Manifest parametrierten Startup-Timeouts (startupConfigs), deklariert EM den Prozessstart als fehlgeschlagen und löst die konfigurierte Recovery-Action aus (z. B. Restart, Fallback-Zustand).
• Entkopplung SM / EM:
  • SM trifft Richtungsentscheidungen (Policy/State Logic), besitzt aber keine eigene Prozessausführungsberechtigung.
  • EM setzt Richtlinien deterministisch durch (Mechanism/Execution), initiiert aber keine autonomen Zustandswechsel außerhalb der Manifest-Definitionen ohne Anforderung durch SM via ara::exec::StateClient.
• Synchronisationsmodell: Der Aufruf SetState über den ara::exec::StateClient arbeitet asynchron und liefert ein ara::core::Future<void> zurück. Entwickler von SM-Modulen müssen auf das Einlösen des Promises warten, bevor nachgelagerte Funktionsgruppen geschaltet werden.