DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_PlatformDesign FIG-d627a541d02f2051 932 × 520 px 2 Release(s)

Figure 7.2: Overview of ’lightweight’ StateMachine concept

SHA-256 Inhalts-Fingerabdruck: d627a541d02f20512ffd7c8ce7982364bf419e47205ed75822052ecb2aa130d2

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

Konzeptionelles Architektur- und Zustandsdiagramm zur Veranschaulichung des erweiterten „lightweight“ StateMachine-Konzepts im AUTOSAR Adaptive Platform Design (State Management). Das Diagramm stellt das Zusammenwirken zwischen State Management (<<SM>>), Execution Management (<<FC>> EM), Platform Health Management (<<FC>> PHM), Network Management (<<FC>> NM), Network Handles (nh1, nh2), einer externen Steuerungsapplikation (SMControlApplication) sowie den verwalteten Funktionsgruppen (<<FunctionGroup>>) und Prozessen dar.

2. Komponenten, Entitäten & Schnittstellen

  • SMControlApplication (<<SM>>): Steuernde Applikation, sendet Steuerbefehle (<<control>>) an das State Management.
  • State Management (<<SM>>): Beinhaltet die Kern-Zustandsmaschine <<StateMachine>> mit den Zuständen Off, Parking, Driving und Fallback.
  • <<FC>> NM (Network Management): Verarbeitet Netzwerkanforderungen (<<request from network>>) von <<NetworkHandle>> nh1, leitet Netzanforderungen (<<request>> Nh1_Full) an die State Machine weiter und nimmt Anforderungen aus der Machine entgegen (<<request from Machine>> an <<NetworkHandle>> nh2).
  • Zustandsübergangstabelle: Definiert reguläre Transitionen über Trigger Value, Current State und Next State (Trigger 1 bis 5) sowie netzwerkbezogene Trigger-Zustände (Nh1_NoCom, Nh1_Full).
  • Fehlerbehandlungstabelle (Execution Error / Next State): Ordnet dem Fehler ANY den Zielzustand Fallback zu.
  • <<ActionList>>: Bei Eintritt (entry / ActionList) ausgeführte Aktionsfolge, bestehend aus <<ActionItem>> SetState(fg1/s1), <<ActionItem>> SYNC sowie <<ActionItem>> NmRequest(nh2).
  • <<FC>> EM (Execution Management): Führt State-Aktionen aus (<<performed by>>), steuert Prozesse (<<control>>) und verwaltet die Funktionsgruppen (<<manage>>).
  • <<FC>> PHM (Platform Health Management): Überwacht Prozesse (<<supervise>>) und meldet Ausführungsfehler (<<report>> executionError bzw. executionError) an die Fehlerbehandlung des State Managements.
  • <<FunctionGroup>> fg1 / <<Process>>: Repräsentiert die überwachten und gesteuerten Prozessinstanzen.

3. Dynamisches Verhalten & Sequenzablauf

  1. Steueranforderungen können über SMControlApplication (<<control>>) oder netzwerkseitig über <<NetworkHandle>> nh1 via <<request from network>> an <<FC>> NM und als <<request>> Nh1_Full an die State Machine gelangen.
  2. Anhand des Triggers und des aktuellen Zustands schaltet die Zustandsmaschine um (z. B. Trigger 1 von Off nach Parking).
  3. Beim Zustandsübergang wird die zugeordnete ActionList ausgelöst (entry / ActionList).
  4. Innerhalb der Aktionsliste werden Funktionsgruppen über das Execution Management geschaltet (SetState(fg1/s1) via EM) sowie Netzwerkanforderungen initiiert (<<ActionItem>> NmRequest(nh2) via <<performed by>> an <<FC>> NM, welches <<request from Machine>> an nh2 absetzt).
  5. Das Execution Management führt das Umschalten der Funktionsgruppen und Prozesse durch (<<manage>>, <<control>>).
  6. Bei Ausführungsfehlern im Prozess meldet PHM via <<supervise>> einen executionError an das State Management (<<report>> executionError), was die Überführung in den Fallback-Zustand bewirkt.

4. Normative Relevanz & Entwickler-Hinweise

Architektur- und Verhaltensspezifikation für das State Management unter Einbindung des Network Managements. Entwickler müssen berücksichtigen, dass das State Management sowohl als Konsument von Netzwerkanforderungen (NmRequest) über NetworkHandle agiert als auch selbst über Aktionen der ActionList Netzanforderungen auslösen kann (NmRequest(nh2)). Die Interaktion mit dem Execution Management und die Fehlerbehandlung via PHM bleiben dabei synchronisiert integriert.

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

R22-11 → R23-11 normative Änderung Vorgänger: FIG-3b5ea25b653f5909
  • Ergänzung der Network Management Functional Cluster <<FC>> NM sowie der zugehörigen Entitäten <<NetworkHandle>> nh1 und <<NetworkHandle>> nh2.
  • Ergänzung des Action-Items <<ActionItem>> NmRequest(nh2) in <<ActionList>> mit Aufrufbeziehung <<performed by>> zu <<FC>> NM.
  • Ergänzung einer Trigger-Eingangsbeziehung von <<NetworkHandle>> nh1 über <<request from network>> an <<FC>> NM und weiter als <<request>> Nh1_Full an die State Machine.
  • Erweiterung der Transitionstabelle um netzwerkbezogene Trigger-Zeilen (Nh1_NoCom, Nh1_Full).
  • Einblendung von rot gepunkteten Hilfslinien/Rasterlinien und Rechtschreibprüfungs-Wellenlinien in der Diagrammfläche.
R23-11 → R24-11 redaktionell Nachfolger: FIG-83d07987e6012b7b
  • Verschiebung der Beschriftungen bzw. Pfeile: Der Rückwärtsübergangspfeil (Transition 3) zwischen <<State>> Driving und <<State>> Parking ist minimal vertikal/horizontal verschoben.
  • Geringfügige Verschiebung der Positionierung der Trigger-Tabelle links oben.
R24-11 → R25-11 redaktionell Vorgänger: FIG-83d07987e6012b7b
  • Rücknahme der minimalen Positionsverschiebungen der Transitionstabelle und des Transitionspfeils 3 auf den Stand von FIG-d627a541d02f2051.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Vorkommen in AUTOSAR-Releases (2)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R23-11 AUTOSAR_AP_EXP_PlatformDesign S. 40 7.2 Figure 7.2: Overview of ’lightweight’ StateMachine concept
R25-11 AUTOSAR_AP_EXP_PlatformDesign S. 41 7.2 Figure 7.2: Overview of ’lightweight’ StateMachine concept