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 vonEMnach Abschluss des Kernel-Boots.EM -> SM: CreateProcess(SM): Betriebssystemnahe Prozessinstanziierung (z. B. via POSIXfork()/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
- Bootstrap Phase:
- Nach Initialisierung der Hardware und des Kernels ruft das
OSdie Funktionmain()des Execution Managements auf.EMübernimmt als primäre Nutzerraum-Entität die Hoheit über das Lifecycle-Management.
- Nach Initialisierung der Hardware und des Kernels ruft das
- Platform Application Initialization (Loop):
EMiteriert synchron über alle im Manifest deklarierten Plattform-Applikationen (loop: All Platform Applications).- Für jede Plattform-Applikation (exemplarisch dargestellt an
SM) führtEMCreateProcess()aus. SMinitialisiert seine internen Datenstrukturen und meldet seine Einsatzbereitschaft via synchroner IPC anEM:ApplicationClient::ReportApplicationState(kRunning).EMquittiert den Statusbericht mitkSuccess.
- Transition to Operational State:
- Sobald alle Plattform-Applikationen (insbesondere
SM)kRunningerreicht haben, ist die Plattform betriebsbereit. SMinitiiert den ersten regulären Machine-State-Wechsel durch Aufruf vonSetState("MachineState", Driving).EMverarbeitet die Anforderung, startet die dem ZustandDrivingzugeordneten Applikations-Prozesse und bestätigt den Zustandswechsel anSMmitkSuccess.
- Sobald alle Plattform-Applikationen (insbesondere
4. Normative Relevanz & Entwickler-Hinweise
- Zwingender API-Vertrag (
ApplicationClient): Jede Plattform- und Standard-Applikation muss nach Initialisierung zwingendReportApplicationState(kRunning)aufrufen. Unterbleibt dies innerhalb des im Manifest konfigurierten Startup-Timeouts, deklariertEMden Prozessstart als fehlgeschlagen (Recovery Action / Safe State). - Bootstrapping-Reihenfolge: Das State Management kann keine Machine States anfordern, bevor es selbst den Status
kRunninggemeldet hat und vonEMbestätigt wurde. Applikationen dürfen keine Annahmen über den ZustandDrivingvor erfolgreicher Rückkehr vonSetStatetreffen. - Manifest-Konfiguration:
- Plattform-Applikationen müssen im ARXML-Execution-Manifest der initialen Startup-Konfiguration zugeordnet sein (
StartupConfigfür die Machine-State-Initialisierung). - Funktionsgruppen und Zustände (wie
"MachineState"undDriving) müssen formal im Manifest alsModeDeclarationGroupbzw.FunctionGroupdefiniert sein.
- Plattform-Applikationen müssen im ARXML-Execution-Manifest der initialen Startup-Konfiguration zugeordnet sein (
- Synchronisationssemantik: Der
SetState-Aufruf ist synchron/blockierend bzw. an ein Future-Objekt (ara::core::Future) gekoppelt;kSuccesswird erst nach dem vollständigen Hochfahren aller für den ZustandDrivingdefinierten Prozesse zurückgemeldet.
Zugeordnete Anforderungen
Diese Angaben zeigt der Versions-Explorer.