Figure 7.3: State Management Architecture

1. Diagrammtyp & Architektur-Kontext

UML-Komponentendiagramm (cmp ArchitectureView) im Kontext der AUTOSAR Adaptive Platform. Das Diagramm spezifiziert die statische Architektur und Schnittstellenbeziehungen des Funktionsclusters State Management (SM) zu übergeordneten Applikationen (Application), zu Execution Management (EM) sowie zu Platform Health Management (PHM).

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm enthält folgende Komponenten und Schnittstellen:

• Application: Anwendungssoftwarekomponente, nutzt die Schnittstelle ComponentClient («ara::stm») zum State Management, konsumiert Events/Properties von StateManagement («ara::com», Stereotyp «Property.Subscribe») und ist an ExecutionClient («ara::exec») angebunden; wird über Lifecycle-Signale (Start / Terminate) von Execution Management gesteuert und durch PHM überwacht (Monitor).
• State Management: Zentraler Cluster, stellt ComponentClient («ara::stm») und StateManagement («ara::com») für Clients bereit; interagiert optional per Monitor (optional) mit PHM, nutzt ExecutionClient («ara::exec») und StateClient («ara::exec») in Richtung Execution Management; unterliegt der Lebenszyklussteuerung (Start / Terminate) durch Execution Management.
• Platform Health Management: Überwacht Applikationen (Monitor) und State Management (Monitor (optional)), steuert Request Recovery Action («IFC Interface») und ExecutionClient («ara::exec») in Richtung Execution Management an; unterliegt der Lebenszyklussteuerung (Start / Terminate).
• Execution Management: Stellt Basisfunktionen über Ports bereit (Request Recovery Action, ExecutionClient, StateClient) und kontrolliert Prozesse über Start / Terminate.
• Schnittstellendetails:
  • ComponentClient («ara::stm»): Felder/Methoden ComponentState: ara::core::string, ConfirmComponentState(), GetComponentState(), SetStateUpdateHandler().
  • StateManagement («ara::com»): Feld FunctionGroup_{FunctionGroup}_State: ara::core::string, Methoden ReleaseRequest_{FunctionGroup}(), RequestState_{FunctionGroup}(ara::core::string): FunctionGroupStateReturnType.
  • Request Recovery Action («IFC Interface»): Methoden *EnterSafeState*(), *ProcessRestart*().
  • ExecutionClient («ara::exec»): Methode ReportExecutionState().
  • StateClient («ara::exec»): Methoden GetState(), SetState().

3. Dynamisches Verhalten & Sequenzablauf

Zustands- und Ablaufsteuerung vollziehen sich interaktiv:

• Applikationen melden ihren internen Komponentenstatus via ComponentClient oder fordern Zustandswechsel von Funktionsgruppen über RequestState_{FunctionGroup}() auf der ara::com-Schnittstelle an.
• Zustandsaktualisierungen werden über Property-Subscription («Property.Subscribe») an Applikationen propagiert.
• State Management setzt Zustandsübergänge gegenüber Execution Management mittels StateClient::SetState() um.
• Prozesse melden ihren Ausführungszustand via ExecutionClient::ReportExecutionState().
• PHM überwacht den Systemzustand (Monitor) und fordert im Fehlerfall Wiederherstellungsmaßnahmen über Request Recovery Action (EnterSafeState, ProcessRestart) bei Execution Management an.
• Execution Management steuert den Lebenszyklus aller beteiligten Komponenten über Start / Terminate.

4. Normative Relevanz & Entwickler-Hinweise

Architekturmodell zur Trennung von adaptiver Zustandslogik (State Management) und Ausführungskontrolle (Execution Management). Schnittstellen mit Präfix «ara::com» definieren Service-Oriented-Communication-Schnittstellen (Proxy/Skeleton), während «ara::stm» und «ara::exec» standardisierte C++-Bibliotheksschnittstellen darstellen. Das Interface Request Recovery Action fungiert als maschineninterne Schnittstelle (IFC Interface) zur Fehlerbehandlung zwischen PHM und Execution Management.