Figure 5.5: StateMachine interactions

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Interaktions- und Komponentenübersichtsdiagramm auf Betriebssystemprozess-Ebene (Process & Interface Architecture Diagram).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R23-11; Spezifikation AUTOSAR_AP_EXP_InterfacesGuidelines (Kapitel 5: State Management Architecture).
• Funktionale Einordnung: Dargestellt ist das funktionale Zusammenspiel des Functional Clusters State Management (SM) (ara::sm) als zentraler Mediator und Policy-Orchestrator. Es entkoppelt High-Level-Zustandsanforderungen von der direkten Ausführungssteuerung (Execution Management), Netzwerksteuerung (Network Management), Sicherheitsüberwachung (Platform Health Management) und Update-Orchestrierung (Update and Configuration Management).

2. Komponenten, Entitäten & Schnittstellen

Zentrale Steuerungseinheit

• StateManagement (<<Process>>): Plattform-Serviceprozess, der die Anwendungs- und Plattformzustände verwaltet.
• <<StateMachine>>: Gekapselte Logik-/Regelinstanz innerhalb des StateManagement, welche eingehende Ereignisse arbitriert, Transitionsbedingungen validiert und Zielzustände ermittelt.

Externe Prozesse & Interaktionsschnittstellen

1. SMControl Application (<<Process>>):
   • Domänen-/Fahrzeugspezifische Applikation zur Anforderung übergeordneter Betriebszustände.
   • Schnittstelle: <<ara::com>> RequestState (Serviceorientierter RPC-/Field-Aufruf zur Zustandsanfrage an die State Machine).
2. Execution Manager (<<Process>>, EM / ara::exec):
   • Laufzeitumgebung für Prozess-Lifecycle, Function Groups und Machine States.
   • Schnittstelle <<StateClient>> SetState: Ausgehender Aufruf der SM via ara::exec::StateClient::SetState(), um Umschaltungen von Function Group States zu kommandieren.
   • Schnittstelle <<StateClient>> UndefinedStateCallback: Rückkanal vom EM an die SM, falls eine Function Group einen undefinierten Fehlerzustand erreicht (z. B. Prozessabsturz oder Startup-Timeout).
3. PlatformHealth Manager (<<Process>>, PHM / ara::phm):
   • Laufzeitüberwachung (Alive-, Deadline- und Logical Supervision).
   • Schnittstelle <<RecoveryAction>> RecoveryHandler: Eingehender Trigger zur Einleitung deterministischer Wiederherstellungs- oder Degradierungsmaßnahmen (Safe State Transition).
4. Network Manager (<<Process>>, NM / ara::nm):
   • Verwaltung der physischen und partiellen Netzwerkzustände (PNCs).
   • Schnittstelle <<NetworkHandle>> SetNetworkRequestedState: Ausgehende Anforderung des SM zur Aktivierung/Deaktivierung spezifischer Netzwerkmodi (z. B. Full-Com / Request Bus).
   • Schnittstelle <<NetworkHandle>> NetworkStateChangeNotifier: Eingehende Statusrückmeldung bei Bus-Zustandsänderungen.
5. UpdateAndConfiguration Manager (<<Process>>, UCM / ara::ucm):
   • Software-Update- und Paketverwaltung.
   • Schnittstelle <<ara::com>> UpdateRequest: Asynchrone Anforderung (gestrichelte Service-Assoziation), um das Gesamtsystem für Software-Aktualisierungen in einen dedizierten Update-State zu überführen.

3. Dynamisches Verhalten & Sequenzablauf

1. Triggering (Ereigniseingang):
   • Regulär: SMControl Application fordert via ara::com (RequestState) oder UCM via UpdateRequest einen Zustandswechsel an.
   • Reaktiv / Fehlerfall: PHM meldet über RecoveryHandler eine verletzte Überwachungsbedingung; NM meldet über NetworkStateChangeNotifier externe Bus-Wakeups oder Kommunikationsabrisse.
2. Zustandsarbitrierung:
   • Die interne <<StateMachine>> prüft Prioritäten, Guards und Abhängigkeiten (z. B. Darf Zustand X betreten werden, wenn UCM aktiv ist oder PHM einen Fehler meldet?).
3. Zustandsumsetzung (Orchestrierung):
   • Prozess-Lifecycle: SM setzt die Zielkonfiguration über ara::exec::StateClient::SetState ab. EM startet/beendet die betroffenen Prozesse der referenzierten Function Group.
   • Kommunikationssteuerung: Parallel oder sequentiell fordert SM über SetNetworkRequestedState die benötigten Netzwerk-Handles beim NM an.
4. Rückmeldung & Fehlerbehandlung:
   • EM quittiert den Abschluss der Transition asynchron (via ara::core::Future).
   • Schlägt die Transition fehl (z. B. Prozesswechsel überschreitet Execution-Timeout), triggert EM UndefinedStateCallback. SM initiiert daraufhin Notfall- oder Safe-State-Routinen.

4. Normative Relevanz & Entwickler-Hinweise

• Trennung von Mechanism und Policy (Architektur-Grundsatz): Der Execution Manager implementiert keinerlei eigene Entscheidungslogik über Systemzustände; er führt ausschließlich Befehle aus. Sämtliche Transitions-Policies verbleiben im SM-Projektcode bzw. der dortigen State Machine.
• Keine direkten Abhängigkeiten zwischen Applikation und EM: Applikationen dürfen ara::exec::StateClient nicht direkt verwenden, um Plattformzustände umzuschalten. Jegliche Zustandsanforderung muss serviceorientiert über ara::com an das SM delegiert werden.
• Asynchronität & Non-Blocking Design:
  • ara::exec::StateClient::SetState() liefert einen ara::core::Future<void>. SM-Entwickler müssen diesen Zustand non-blocking über Event-Loops oder Callbacks auflösen, um Verklemmungen während langlaufender Prozessstarts zu verhindern.
• FHTI (Fault Handling Time Interval): Die Interaktion zwischen PHM (RecoveryHandler) und SM ist sicherheitskritisch (ASIL-relevant). Die Reaktionszeit des SM auf einen Recovery-Trigger bis zum Erreichen des definierten Safe State muss deterministisch innerhalb des spezifizierten Fehlertoleranz-Zeitintervalls liegen.
• Manifest-Synchronisation: Die im SM deklarierten Zustandsmodelle müssen konsistent mit den FunctionGroup- und ModeDeclarationGroup-Definitionen im Adaptive-System-Manifest (Execution Manifest / Machine Manifest) parametriert sein.