DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_StateManagement FIG-6a398fa523395b14 932 × 780 px 2 Release(s)

Figure 7.3: State Management Architecture

SHA-256 Inhalts-Fingerabdruck: 6a398fa523395b14c2e9361a4229e4e7fb92c9e80e6d97a57cc0800eca6aab76

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) im Kontext der AUTOSAR Adaptive Platform. Das Diagramm spezifiziert die Systemarchitektur und Schnittstellenverbindungen von State Management zu einer Anwendungsinstanz (Application1), den Plattformclustern PHM (Platform Health Management), DIA (Diagnostic Management), UCM (Update and Configuration Management), Network Management sowie zu Execution Management.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm umfasst folgende Komponenten und Schnittstellen:

  • Application1: Anwendungsinstanz, nutzt ApplicationClient («ara::exec») und interagiert über ereignisbasierte Ports (TriggerOutApp, TriggerInApp); unterliegt der Ausführungskontrolle durch Execution Management (Start / Terminate).
  • State Management: Zentraler Koordinator mit doppelter Rollenausprägung (State Management und StateManagement (obsolete)). Besitzt Ports für TriggerIn, TriggerOut, TriggerInOut sowie projekt-spezifische Events (Project-Specific event). Bietet die als veraltet markierte Service-Schnittstelle StateManagement(obsolete) für PHM, DIA und UCM via property.subscribe. Nutzt NetworkManagement über NetworkHandle («ara::com»), konsumiert DIA::CurrentStatus via PackageManagement («ara::com») von UCM und ist über ApplicationClient sowie C++-Schnittstellen (Request State Transitions, Get State Information) mit Execution Management verbunden.
  • PHM, DIA, UCM: Plattformcluster, abonnieren Zustände von StateManagement(obsolete). UCM stellt PackageManagement bereit; PHM und DIA steuern oder empfangen Zustandsinformationen.
  • Network Management: Plattformcluster mit Ports für NetworkCurrentState und NetworkRequestedState («ara::com»).
  • Execution Management: Bietet Request State Transitions («IFC Interface», Methode SetState()), Get State Information («IFC Interface», Methode GetState()) und ApplicationClient («ara::exec», Methode ReportApplicationState()). Deklariert zudem die Operation + fork(): int.
  • Schnittstellendetails:
    • TriggerIn («ara::com»): Methode Trigger.
    • TriggerOut («ara::com»): Methode Notifier.
    • TriggerInOut («ara::com»): Methoden Notifier, Trigger.
    • StateManagement(obsolete) («ara::com»): Property <FunctionGroup>_State: ara::core::string, Methoden ReleaseRequest(), RequestState().
    • NetworkHandle («ara::com»): Attribute NetworkCurrentState: boolean, NetworkRequestedState: boolean.
    • PackageManagement («ara::com»): Attribut CurrentStatus: int.

3. Dynamisches Verhalten & Sequenzablauf

Die dynamische Interaktion gliedert sich in:

  • Ereignis- und triggerbasierte Interaktion zwischen Applikationen und State Management über standardisierte oder projektspezifische Trigger-Interfaces (TriggerIn, TriggerOut, TriggerInOut).
  • Abfrage und Notification von Funktionsgruppenzuständen über die veraltete Schnittstelle StateManagement(obsolete) an PHM, DIA und UCM per Property-Subscription.
  • UCM signalisiert Update-Zustände (PackageManagement::CurrentStatus) an DIA und State Management.
  • State Management synchronisiert Netzwerkzustände mit Network Management über NetworkHandle (NetworkRequestedState, NetworkCurrentState).
  • Zustandsübergänge der Maschine und Funktionsgruppen werden direkt über maschineninterne Schnittstellen (Request State Transitions::SetState(), Get State Information::GetState()) bei Execution Management angefordert.
  • Laufzeitstatusmeldungen von Applikationen und Plattformkomponenten erfolgen über ApplicationClient::ReportApplicationState().
  • Prozessinstanziierung und Lebenszyklussteuerung erfolgen durch Execution Management (fork(): int, Start / Terminate).

4. Normative Relevanz & Entwickler-Hinweise

Architektur mit Übergang zu ara::com-basierten Triggermechanismen für applikative Zustandswechsel. Die Kennzeichnung von StateManagement mit dem Suffix (obsolete) markiert die Deprecation des vormaligen Funktionsgruppen-Zustandsservices. Execution-Management-Kopplung erfolgt über direkte C++- bzw. IFC-Schnittstellen («IFC Interface»), während funktionale Cluster über Service-Schnittstellen gekoppelt sind.

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

R18-10_R4.4.0_R1.5.0 → R19-03 normative Änderung Vorgänger: FIG-ca0fec50dc939ced
  • Die Komponente Application wird zu Application1 umbenannt; Platform Health Management wird durch die AUTOSAR-Funktionscluster PHM, DIA und UCM ersetzt bzw. aufgespalten; Network Management kommt als neuer Funktionscluster hinzu.
  • Die Schnittstelle ComponentClient («ara::stm») entfällt und wird durch ara::com-basierte Trigger-Schnittstellen (TriggerIn, TriggerOut, TriggerInOut, TriggerOutApp) ersetzt.
  • Die Schnittstelle StateManagement («ara::com») ist als (obsolete) gekennzeichnet; Execution-Management-Schnittstellen werden von StateClient und Request Recovery Action auf C++-Schnittstellen (Request State Transitions, Get State Information) sowie ApplicationClient («ara::exec») angepasst.
  • Einführung des Interface NetworkHandle («ara::com») zur Interaktion mit Network Management und PackageManagement («ara::com») für UCM.
  • Aufrufschnittstelle fork(): int an Execution Management ergänzt.
R19-11 → R20-11 normative Änderung Nachfolger: FIG-a289afcdbce45d89
  • 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.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Vorkommen in AUTOSAR-Releases (4)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R19-03 AUTOSAR_SWS_StateManagement S. 21 7.3 Figure 7.3: State Management Architecture
R19-03 AUTOSAR_SWS_StateManagement S. 21 7.3 Figure 7.3: State Management Architecture
R19-11 AUTOSAR_SWS_StateManagement S. 21 7.3 Figure 7.3: State Management Architecture
R19-11 AUTOSAR_SWS_StateManagement S. 21 7.3 Figure 7.3: State Management Architecture