DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_ExecutionManagement FIG-d6840a27d2da3bf1 828 × 641 px 1 Release(s)

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

SHA-256 Inhalts-Fingerabdruck: d6840a27d2da3bf1abbc5d1bd22111d5effcde56635bd404808524a21667691b
✦ 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-Sequenzdiagramm (Interaktionsdiagramm) mit Interaktionsrahmen loop (All Platform Applications).
  • Funktionaler Kontext: AUTOSAR Adaptive Platform (AP), Release 18-03 (R1.4.0), Functional Cluster Execution Management (ara::exec) in Interaktion mit dem POSIX-Betriebssystem (OS) und dem Functional Cluster State Management (ara::sm).
  • Technischer Zweck: Spezifikation des deterministischen Bootstrappings der Adaptive Machine vom initialen Betriebssystem-Start über das Hochfahren aller Plattform-Applikationen bis zum Übergang in den ersten operativen Machine State (Driving), getriggert durch das State Management.

2. Komponenten, Entitäten & Schnittstellen

  • Akteure / Lifelines:
    • OS: Unterlagerndes POSIX-konformes Betriebssystem (Kernel/Init-System).
    • EM (Execution Management, ara::exec): Zentraler Plattform-Dienst zur Prozess- und Zustandsverwaltung; fungiert als Init-Prozess im AP-User-Space.
    • SM (State Management, ara::sm): Plattform-Applikation zur Entscheidungsfindung bezüglich System- und Funktionszuständen basierend auf Fahrzeug-/Netzwerk-Events.
  • Schnittstellen & Interaktionskanäle:
    • OS -> EM: main(): Standard-POSIX-Prozessinstanziierung / Programmeinstiegspunkt von EM nach Abschluss des Kernel-Boots.
    • EM -> SM: CreateProcess(SM): Betriebssystemnahe Prozessinstanziierung (z. B. via POSIX fork()/exec() oder dedizierte OS-Primitives) innerhalb der Iteration über alle Plattform-Applikationen.
    • ApplicationClient::ReportApplicationState(kRunning): Inter-Process-Communication-API (ara::exec::ApplicationClient), über die sich ein gestarteter Prozess gegenüber EM als betriebsbereit meldet (ara::exec::ApplicationState::kRunning).
    • SetState("MachineState", Driving): Steuerungs-Schnittstelle von SM an EM zur Anforderung eines globalen Machine-State-Wechsels (Funktionsgruppe: "MachineState", Zielzustand: Driving).
    • kSuccess: Typisierte Rückgabewerte bzw. ara::core::Result<void> zur Bestätigung der erfolgreichen Zustandsverarbeitung.

3. Dynamisches Verhalten & Sequenzablauf

  1. Bootstrap Phase:
    • Nach Initialisierung der Hardware und des Kernels ruft das OS die Funktion main() des Execution Managements auf. EM übernimmt als primäre Nutzerraum-Entität die Hoheit über das Lifecycle-Management.
  2. Platform Application Initialization (Loop):
    • EM iteriert synchron über alle im Manifest deklarierten Plattform-Applikationen (loop: All Platform Applications).
    • Für jede Plattform-Applikation (exemplarisch dargestellt an SM) führt EM CreateProcess() aus.
    • SM initialisiert seine internen Datenstrukturen und meldet seine Einsatzbereitschaft via synchroner IPC an EM: ApplicationClient::ReportApplicationState(kRunning).
    • EM quittiert den Statusbericht mit kSuccess.
  3. Transition to Operational State:
    • Sobald alle Plattform-Applikationen (insbesondere SM) kRunning erreicht haben, ist die Plattform betriebsbereit.
    • SM initiiert den ersten regulären Machine-State-Wechsel durch Aufruf von SetState("MachineState", Driving).
    • EM verarbeitet die Anforderung, startet die dem Zustand Driving zugeordneten Applikations-Prozesse und bestätigt den Zustandswechsel an SM mit kSuccess.

4. Normative Relevanz & Entwickler-Hinweise

  • Zwingender API-Vertrag (ApplicationClient): Jede Plattform- und Standard-Applikation muss nach Initialisierung zwingend ReportApplicationState(kRunning) aufrufen. Unterbleibt dies innerhalb des im Manifest konfigurierten Startup-Timeouts, deklariert EM den Prozessstart als fehlgeschlagen (Recovery Action / Safe State).
  • Bootstrapping-Reihenfolge: Das State Management kann keine Machine States anfordern, bevor es selbst den Status kRunning gemeldet hat und von EM bestätigt wurde. Applikationen dürfen keine Annahmen über den Zustand Driving vor erfolgreicher Rückkehr von SetState treffen.
  • Manifest-Konfiguration:
    • Plattform-Applikationen müssen im ARXML-Execution-Manifest der initialen Startup-Konfiguration zugeordnet sein (StartupConfig für die Machine-State-Initialisierung).
    • Funktionsgruppen und Zustände (wie "MachineState" und Driving) müssen formal im Manifest als ModeDeclarationGroup bzw. FunctionGroup definiert sein.
  • Synchronisationssemantik: Der SetState-Aufruf ist synchron/blockierend bzw. an ein Future-Objekt (ara::core::Future) gekoppelt; kSuccess wird erst nach dem vollständigen Hochfahren aller für den Zustand Driving definierten Prozesse zurückgemeldet.

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

R18-03_R1.4.0 → R21-11 normative Änderung Nachfolger: FIG-e4f340069869fc8c
  • Interaktionsrahmen loop: Der Schleifenrahmen All Platform Applications um die Applikationsinitialisierung entfällt; dargestellt ist die direkte Prozessinstanziierung von SM.
  • Diagrammrahmen & Bezeichner: Umbenennung des Rahmens von Startup to Initial Driving State zu standardisiertem UML-Rahmen sd Startup to Initial StateXYZ (Generalisierung des Zielzustands von Driving zu StateXYZ).
  • Meldung des Ausführungszustands: Ersetzung von ApplicationClient::ReportApplicationState(kRunning) durch ReportExecutionState(kRunning) ohne explizite synchrone kSuccess-Rückgabe.
  • Initialer Maschinenzustand: Hinzufügen der asynchronen Abfrage GetInitialMachineStateTransitionResult(): ara::core::Future<void> inklusive Rückmeldung via «future invocation» vor Anforderung des ersten Zustandswechsels.
  • Schnittstelle SetState: Ersetzung von SetState("MachineState", Driving) durch SetState(FunctionGroupState &stateXYZ): ara::core::Future<void> (Einführung des Typs FunctionGroupState anstelle von String/Enum).
  • Asynchrones Verhaltensmodell: Ersetzung der synchronen kSuccess-Rückgabewerte durch das asynchrone Future-Muster (ara::core::Future<void> mit Fertigstellungsmeldung SetState(): Transition completed «future invocation»).

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

EM OS | main() | CreateProcess(SM) | SM | ApplicationClient:: ReportApplicationState(kRunning) | SetState("MachineState", Driving) | loop | All Platform Applications | Execution Management | Startup to Initial Driving State | kSuccess | kSuccess

Begleitender Spezifikationstext:

Specification of Execution Management AUTOSAR AP Release 18-03 The Machine States are determined and requested by the State Management functional cluster, see 7.4.5.1. For details on state change management see 7.4.6. 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.6. EM OS main() CreateProcess(SM) SM ApplicationClient:: ReportApplicationState(kRunning) SetState("MachineState", Driving) loop All Platform Applications Execution Management Startup to Initial Driving State kSuccess kSuccess Figure 7.6: Start-up Sequence – from Startup to initial running state Driving An arbitrary state change sequence to machine state StateXYZ is illustrated in Figure 7.7. Here, on receipt of the state change request, Execution Management terminates running Processes and then starts Processes active in the new state before confirming the state change to State Management. 31 of 91 — AUTOSAR CONFIDENTIAL — Document ID 721: AUTOSAR_SWS_ExecutionManagement

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R18-03_R1.4.0 AUTOSAR_SWS_ExecutionManagement S. 31 7.6 Figure 7.6: Start-up Sequence – from Startup to initial running state Driving