DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_StateManagement FIG-906bbc8f7a366916 887 × 467 px 1 Release(s)

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

SHA-256 Inhalts-Fingerabdruck: 906bbc8f7a366916795449417aa0143b6e2e1907d0444f91b5f630cff6208c7b

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-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: UML-Sequenzdiagramm (rahmenloses Sequenzdiagramm mit Zeitsprüngen/Unterbrechungen) unter dem Titel Startup to initial StateXYZ.
  • Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R25-11. Dargestellt ist der deterministische Hochlauf der Machine vom OS-Bootstrap über die Prozessinitiierung des State Management durch das Execution Management bis zur Abfrage des Machine-Startup-Ergebnisses und der anschließenden Anforderung des Folgezustands (StateXYZ) via C++-API.

2. Komponenten, Entitäten & Schnittstellen

  • Akteure / Lifelines:
    • Operating System (vormals OS): Host-/POSIX-Betriebssystem zum Starten des Execution Management; Kopf- und Fußboxen vorhanden.
    • Execution Management (vormals EM): Zentraler Plattformcluster für Prozessverwaltung und Zustandsausführung.
    • State Management (vormals SM, farblich hervorgehoben): Plattformcluster für Zustandsentscheidungen.
  • Schnittstellen & Interaktionspfade:
    • main(): Entry-Point-Aufruf des OS zum Start von Execution Management.
    • CreateProcess(SM): Prozesserzeugung von State Management durch Execution Management.
    • ReportExecutionState(kRunning): ara::core::Result<void>: Meldung der Betriebsbereitschaft von SM an EM mit standardisiertem Ergebnistyp ara::core::Result<void>.
    • GetInitialMachineStateTransitionResult(): ara::core::Future<void>: Asynchrone Abfragemethode von SM an EM zur Ermittlung des Abschlusses der initialen Machine-State-Transition.
    • <<future invocation from GetInitialMachineStateTransitionResult>>: Asynchrone Einlösung des Futures durch EM bei Erreichen des initialen Zustands.
    • SetState(FunctionGroupState &stateXYZ): ara::core::Future<void>: Asynchroner Zustandswechselaufruf mit stark typisiertem Referenzparameter (FunctionGroupState &stateXYZ) anstelle von Zeichenketten.
    • <<future invocation from SetState>>: Asynchrone Signalisierung der abgeschlossenen Zustandstransition durch EM an SM.

3. Dynamisches Verhalten & Sequenzablauf

  1. OS-Bootstrap & EM-Start: Das Betriebssystem initialisiert die Plattform und ruft main() des Execution Management auf.
  2. SM-Instanziierung & Statusmeldung:
    • Execution Management startet State Management über CreateProcess(SM).
    • State Management meldet seine Betriebsbereitschaft über ReportExecutionState(kRunning) und erhält synchron ein ara::core::Result<void> zurück.
  3. Synchronisation auf initialen Machine-Zustand:
    • State Management ruft GetInitialMachineStateTransitionResult() an EM auf und erhält ein ara::core::Future<void>.
    • Sobald EM den initialen Maschinenzustand stabil eingenommen hat, wird das Future asynchron aufgelöst (<<future invocation from GetInitialMachineStateTransitionResult>>).
  4. Asynchrone Zustandstransition:
    • State Management stößt den Wechsel in den Zielzustand via SetState(FunctionGroupState &stateXYZ) an.
    • Nach Vollzug aller Prozessstarts/-stopps für stateXYZ signalisiert EM den Abschluss asynchron an SM (<<future invocation from SetState>>).

4. Normative Relevanz & Entwickler-Hinweise

  • Typsicherheit der Zustands-API: Statt untypisierter Zeichenketten ("MachineFG", String-Zustände) erfordert SetState eine typisierte C++-Referenz (FunctionGroupState &stateXYZ), wodurch Fehlkonfigurationen zur Compile-Zeit verhindert werden.
  • Fehler- und Synchronisationsmodell (ara::core):
    • Synchrone Aufrufe wie ReportExecutionState liefern ara::core::Result<void>, was eine standardisierte Fehlerbehandlung ohne C++-Exceptions erzwingt.
    • Asynchrone Abläufe (GetInitialMachineStateTransitionResult, SetState) nutzen ara::core::Future<void>; SM darf nachfolgende Aktionen erst nach erfolgreichem Future-Callback ausführen.
  • Initial-State-Synchronisation: Die Notwendigkeit des aktiven Wartens auf GetInitialMachineStateTransitionResult() verhindert Race Conditions beim Hochlauf, indem sichergestellt wird, dass alle Prozesse des Initialzustands stabil laufen, bevor Folgezustände angefordert werden.
  • Fokus auf SM-Interaktion: Die Reduktion der Schleife über alle Plattformprozesse verdeutlicht normativ das Zusammenspiel zwischen EM und SM als zentralem Kontrollpfad.

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

R20-11 → R25-11 normative Änderung Vorgänger: FIG-00539a5c1d557de7
  • sd Startup to Initial StateXYZ / Interaktionsrahmen: UML-Rahmen und loop [All Platform Processes] entfernt; Titel Startup to initial StateXYZ steht frei über dem Diagramm.
  • OS, EM, SM: Lebenslinien voll ausgeschrieben als Operating System, Execution Management und State Management (farblich blau hervorgehoben); Teilnehmerboxen am Fuß der Lebenslinien ergänzt.
  • Lebenslinien: Zeitunterbrechungen durch rote Punktschraffuren visualisiert.
  • ReportExecutionState(kRunning): Klassenpräfix ExecutionClient:: entfernt; Rückgabetyp ara::core::Result<void> mit synchronem Rückwärtspfeil hinzugefügt.
  • GetInitialMachineStateTransitionResult(): Asynchroner Methodenaufruf mit Rückgabetyp ara::core::Future<void> und nachfolgendem Callback <<future invocation from GetInitialMachineStateTransitionResult>> neu eingeführt.
  • SetState: Signatur von SetState("MachineFG", StateXYZ) auf typsichere C++-Signatur SetState(FunctionGroupState &stateXYZ): ara::core::Future<void> umgestellt; asynchrone Antwort <<future invocation from SetState>> ergänzt.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of State Management AUTOSAR AP R25-11 • Adaptive Application state related to Suspend-to-RAM. See Section 7.5 7.1.1 Machine State A Machine State is a specific type of Function Group State (see Section 7.1.2). Machine States and all other Function Group States are determined and requested by the State Management functional cluster, see Section 7.1.3. The set of active States is significantly influenced by vehiclewide events and modes which are evaluated into State Managements internal States. A Machine State is a specific type of Function Group State (see Section 7.1.2). Machine States and all other Function Group States are determined and requested by the State Management functional cluster, see Section 7.1.3. The set of active States is significantly influenced by vehiclewide 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 Modelled Processes. Each Adaptive Application can declare in its Execution Manifests in which Function Group States its Modelled Processes have to be running. The start-up sequence from initial state Startup to the point where State Management, requests the initial running machine state Driving is illustrated in Figure 7.1 as an example Driving Function Group State is no mandatory Function Group State. Figure 7.1: Start-up Sequence – from Startup to initial running state Driving An arbitrary state change sequence to machine

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_AP_SWS_StateManagement S. 25 7.1 Figure 7.1: Start-up Sequence – from Startup to initial running state Driving