DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_StateManagement FIG-37cedf23af18875f 887 × 651 px 4 Release(s)

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

SHA-256 Inhalts-Fingerabdruck: 37cedf23af18875fa6db4dec87bf165e43ad44d04019b820dc9bce567009c37b

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-description@2 · erstellt am 2026-10-07

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: UML 2.0 Sequenzdiagramm (sd Startup to Initial Driving State) mit Interaktionsrahmen (loop).
  • Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Releases R18-10 bis R19-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 (Driving) 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.
    • ConfirmMachineState(Startup) (im Schaubild: ConfimMachineState): Interne/plattformspezifische IPC-Benachrichtigung von EM an SM über das Erreichen des initialen Funktionsgruppenzustands Startup.
    • SetState("MachineState", Driving): Zustandswechselanforderung von SM an EM (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 Applications]):
    • EM liest das Machine- und Execution-Manifest aus und ermittelt alle Prozesse, die dem Zustand MachineState/Startup zugeordnet sind.
    • Iterativ stößt EM für alle Plattformanwendungen (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 MachineState Startup:
    • Sobald alle für Startup konfigurierten Plattformprozesse kRunning gemeldet haben, gilt der Zustand als eingenommen.
    • EM notifiziert SM über ConfirmMachineState(Startup).
  4. Transition in den operationalen Zustand:
    • SM wertet seine internen Startbedingungen aus und fordert bei EM den Folgezustand an: SetState("MachineState", Driving).
    • EM initiiert daraufhin das Starten aller weiteren Prozesse, die für MachineState/Driving im Manifest hinterlegt sind.

4. Normative Relevanz & Entwickler-Hinweise

  • Zustandssemantik: Startup ist der zwingend vorgeschriebene initiale Machine State nach dem Booten. Der Folgezustand Driving ist rein exemplarisch; Name und Anzahl operationaler Machine States sind projektspezifisch im Manifest frei konfigurierbar (nicht normativ vorgeschrieben).
  • 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.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R19-11 → R20-11 normative Änderung Nachfolger: FIG-00539a5c1d557de7
  • sd Startup to Initial Driving State: Diagrammrahmen umbenannt zu sd Startup to Initial StateXYZ.
  • loop: Schleifenbedingung von [All Platform Applications] zu [All Platform Processes] geändert.
  • ConfirmMachineState(Startup): Interaktion von EM an SM entfällt ersatzlos.
  • SetState: Parameter von ("MachineState", Driving) zu ("MachineFG", StateXYZ) geändert (Funktionsgruppe MachineFG statt MachineState, generischer Zielzustand StateXYZ statt Driving).
  • SM: Lebenslinien-Aktivierung nach CreateProcess(SM) läuft durchgehend bis nach SetState.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of State Management AUTOSAR AP R19-11 • State Management provides ara::com fields as interface to provide information about its current internal States State Management is responsible for handling the following states: • Machine State see 7.1.1 • Function Group State see 7.1.2 7.1.1 Machine State A Machine State is a specific type of Function Group State (see 7.1.2). Machine States and all other Function Group States are determined and requested by the State Management functional cluster, see 7.1.3. The set of active States is significantly influenced by vehicle-wide events and modes which are evaluated into State Managements internal States. The Function Group States, including the Machine State, define the current set of running Processes. Each Application can declare in its Execution Manifests in which Function Group States its Processes have to be running. The start-up sequence from initial state Startup to the point where State Management, SM, requests the initial running machine state Driving is illustrated in Figure 7.1 as an example Driving State is no mandatory State. Figure 7.1: Start-up Sequence – from Startup to initial running state Driving 16 of 41 — AUTOSAR CONFIDENTIAL — Document ID 908: AUTOSAR_SWS_StateManagement

Vorkommen in AUTOSAR-Releases (7)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_StateManagement S. 17 7.1 Figure 7.1: Start-up Sequence – from Startup to initial running state Driving
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_StateManagement S. 17 7.1 Figure 7.1: Start-up Sequence – from Startup to initial running state Driving
R18-10-1 AUTOSAR_SWS_StateManagement S. 17 7.1 Figure 7.1: Start-up Sequence – from Startup to initial running state Driving
R19-03 AUTOSAR_SWS_StateManagement S. 16 7.1 Figure 7.1: Start-up Sequence – from Startup to initial running state Driving
R19-03 AUTOSAR_SWS_StateManagement S. 16 7.1 Figure 7.1: Start-up Sequence – from Startup to initial running state Driving
R19-11 AUTOSAR_SWS_StateManagement S. 16 7.1 Figure 7.1: Start-up Sequence – from Startup to initial running state Driving
R19-11 AUTOSAR_SWS_StateManagement S. 16 7.1 Figure 7.1: Start-up Sequence – from Startup to initial running state Driving