DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_StateManagement FIG-a289afcdbce45d89 932 × 772 px 3 Release(s)

Figure 7.3: State Management Architecture

SHA-256 Inhalts-Fingerabdruck: a289afcdbce45d8955f17668e7f0c015a7b15c404301ded0b3f3106b5fbf4a7f

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

UML-Komponentendiagramm (cmp ArchitectureView) der AUTOSAR Adaptive Platform. Das Diagramm modelliert die Komponenten- und Schnittstellenarchitektur von State Management im Zusammenspiel mit Prozessen (Process1), Plattformclustern (UCM, PHM, DIA, Network Management) und Execution Management.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm umfasst folgende Komponenten und Schnittstellen:

  • Process1: Anwendungs- oder Plattformprozess, kommuniziert mit State Management über CommunicationGroupClient<PowerMode> und CommunicationGroupServer<PowerMode> («ara::com») via Nachrichten (PowerModeMsg, PowerModeRespMsg); nutzt ExecutionClient («ara::exec») und wird per Start / Terminate gesteuert.
  • State Management: Zentraler Knotenpunkt, angebunden an:
    • TriggerIn, TriggerOut, TriggerInOut («ara::com»).
    • CommunicationGroupServer<PowerMode> und CommunicationGroupClient<PowerMode> («ara::com») für Power-Mode-Nachrichten.
    • UpdateRequest («ara::com») von UCM.
    • RecoveryAction («ara::phm») via RecoveryActionHandler von PHM.
    • EcuResetRequest («ara::dia») von DIA.
    • NetworkHandle («ara::com») in Verbindung mit Network Management.
    • StateClient («ara::exec») und ExecutionClient («ara::exec») zu Execution Management.
  • UCM: Stellt den Service UpdateRequest («ara::com») bereit mit Methoden PrepareRollback(vector): void, PrepareUpdate(vector): void, ResetMachine(): void, StartUpdateSession(): void, StopUpdateSession(): void, VerifyUpdate(vector): void.
  • PHM: Nutzt Schnittstelle RecoveryAction («ara::phm») mit Callback/Handler RecoveryActionHandler().
  • DIA: Bietet EcuResetRequest («ara::dia») mit Methoden EnableRapidShutdown(): void, ExecuteReset(): void, GetLastResetCause(): void, RequestReset().
  • Network Management: Bereitstellung von NetworkCurrentState und NetworkRequestedState («ara::com») für NetworkHandle.
  • Execution Management: Steuerung via Start / Terminate und fork(): int. Stellt StateClient («ara::exec») bereit mit Methoden SetState(), GetExecutionError(): void, GetInitialMachineStateTransitionResult(): void, undefinedStateCallback(): void sowie ExecutionClient («ara::exec», Methode ReportApplicationState()).

3. Dynamisches Verhalten & Sequenzablauf

Der dynamische Ablauf stützt sich auf dedizierte Interaktionskanäle:

  • Power-Management-Abläufe zwischen Prozessen und State Management werden asynchron über getypte Kommunikationsgruppen (CommunicationGroupServer<PowerMode> / CommunicationGroupClient<PowerMode>) über Request/Response-Meldungen (PowerModeMsg, PowerModeRespMsg) abgewickelt.
  • Feld- und Triggerereignisse werden über TriggerIn, TriggerOut und TriggerInOut ausgetauscht.
  • Im Update-Fall interagiert UCM über UpdateRequest zur Vorbereitung und Verifikation von Updates oder Rollbacks sowie für Maschinen-Resets mit State Management.
  • Health-Monitoring-Ereignisse führen über PHMs RecoveryAction zur Einleitung definierter Recovery-Aktionen im State Management.
  • Diagnosegestützte Steuergeräte-Resets und Rapid-Shutdowns initiiert DIA über EcuResetRequest.
  • Netzwerkanforderungen und aktuelle Netzwerkzustände werden über NetworkHandle mit dem Network Management abgeglichen.
  • State Management setzt Maschinen- und Funktionsgruppenzustände über StateClient::SetState() bei Execution Management durch und wertet Übergangsergebnisse oder Fehler aus.
  • Prozesse melden ihren Lebenszyklusstatus per ExecutionClient::ReportApplicationState().

4. Normative Relevanz & Entwickler-Hinweise

Vollständig ausdifferenziertes Architekturmodell für State Management in der Adaptive Platform. Die Interaktionen mit den Plattformclustern UCM, PHM, DIA und NM sind über domainspezifische C++- bzw. ara::com-Schnittstellen («ara::phm», «ara::dia», «ara::com», «ara::exec») standardisiert. Die Steuerung der Power-Modi nutzt das Konzept typisierter Communication Groups.

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

R19-11 → R20-11 normative Änderung Vorgänger: FIG-6a398fa523395b14
  • Application1 wird zu Process1 umbenannt.
  • Die obsolete Schnittstelle StateManagement(obsolete) sowie PackageManagement entfallen vollständig.
  • Neu hinzugefügt: Service-Schnittstellen UpdateRequest («ara::com») für UCM, RecoveryAction («ara::phm») für PHM, EcuResetRequest («ara::dia») für DIA sowie CommunicationGroupServer<PowerMode> und CommunicationGroupClient<PowerMode> («ara::com»).
  • Die C++-Schnittstellen zu Execution Management werden wieder als StateClient («ara::exec») modelliert (mit Methoden SetState(), GetExecutionError(): void, GetInitialMachineStateTransitionResult(): void, undefinedStateCallback(): void).
  • TriggerOutApp entfällt zugunsten der PowerMode-Kommunikationsgruppe zwischen State Management und Process1.
R22-11 → R23-11 normative Änderung Nachfolger: FIG-dc1d07b57dfc6dc7
  • Die Entitäten CommunicationGroupServer<PowerMode> und CommunicationGroupClient<PowerMode> entfallen.
  • Als neue Komponente wird SMControlApplication ergänzt (mit ExecutionClient-Port zu Execution Management).
  • Zwischen SMControlApplication und State Management werden die Service-Interfaces StateMachineService («ara::com», Methode RequestState) und UpdateAllowed («ara::com», Methode UpdateAllowed) eingeführt.
  • EcuResetRequest («ara::dia») verliert die zuvor enthaltenen Methoden ExecuteReset(): void und GetLastResetCause(): void.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of State Management AUTOSAR AP R22-11 be plugged into the State Management framework and has standardized interfaces between framework and arbitration logic, so the code can be reused on different platforms. The arbitration logic code might be individually developed or (partly) generated, based on standardized configuration parameters. An overview of the interaction of State Management, AUTOSAR Adaptive Platform Applications and Adaptive Applications is shown in Figure 7.3. Figure 7.3: State Management Architecture 7.2 State Management and Adaptive (Platform) Applications 7.2.1 Interaction between the SM and Adaptive Applications Some Adaptive Applications, including AUTOSAR Adaptive Platform Applications, might have the need to interact with State Management. Therefor State Management provides a service interface TriggerOut with a Notifier 26 of 84 Document ID 908: AUTOSAR_SWS_StateManagement

Vorkommen in AUTOSAR-Releases (5)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R20-11 AUTOSAR_SWS_StateManagement S. 23 7.3 Figure 7.3: State Management Architecture
R20-11 AUTOSAR_SWS_StateManagement S. 23 7.3 Figure 7.3: State Management Architecture
R21-11 AUTOSAR_SWS_StateManagement S. 25 7.3 Figure 7.3: State Management Architecture
R21-11 AUTOSAR_SWS_StateManagement S. 25 7.3 Figure 7.3: State Management Architecture
R22-11 AUTOSAR_SWS_StateManagement S. 26 7.3 Figure 7.3: State Management Architecture