Figure 7.3: StateMachine concept - Big picture

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles Architektur- und Komponentendiagramm (UML-basiertes Block- und Verteilungsdiagramm mit Prozess- und Konfigurationsgrenzen).
• Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (SM) (AUTOSAR_AP_EXP_PlatformDesign, Kapitel 7).
• Technischer Zweck: Darstellung der internen Dekomposition des State-Management-Prozesses in Konfigurationsartefakte (Controller, Agents), Implementierungsstrukturen (StateMachine Management) sowie die Interaktionspunkte zu externen Applikationen und benachbarten Plattform-Clustern (EM, PHM, NM, UCM).

2. Komponenten, Entitäten & Schnittstellen

Semantik der Farbkodierung (Legende)

• Rot: Projektspezifisch / OEM-spezifisch, nicht Bestandteil des AUTOSAR-Standards (Not part of AUTOSAR).
• Blau: AUTOSAR-Plattformbestandteil (Part of AUTOSAR).
• Grün: Per ARXML/Manifest modellier- und konfigurierbare Strukturen (Visible in Configuration).
• Lila: Definierte Service- bzw. API-Schnittstellen (Interaction Points).
• Gelb (gestrichelt): Interne Architektur- und Dispatching-Mechanik (Implementation Detail).

Akteure & Komponenten

• SMControlApplication (Rot, Kardinalität: 1..*): Projektspezifische Applikation(en), die fahrzeugspezifische Betriebsstrategien abbilden und Zustandsanfragen an das State Management stellen.
• IAM (Identity and Access Management, Blau): Sicherheitsgate zur Verifikation von Zugriffsrechten der SMControlApplication auf Zustandsänderungen.
• <<Process>> State Management (Blau): Eigener OS-Prozessraum des State-Management-Clusters.
• Externe funktionale Cluster:
  • EM (Execution Management): Verantwortlich für Prozesslebenszyklen und Function Group States (FGS).
  • PHM (Platform Health Management): Meldet Health-Ereignisse und triggert Recovery-Eskalationen.
  • NM (Network Management): Verwaltet partielle/vollständige Netzwerkzustände.
  • UCM (Update and Configuration Management): Steuert Software-Update-Sessions und Rollbacks.

Interne Entitäten (im State Management)

• StateMachine Management (Gelb gestrichelt): Zentraler interner Event-Router/Dispatcher; verbindet Schnittstellen mit den Zustandsautomaten (Manage-Beziehung).
• <<StateMachine>> Controller (Grün): Zentraler Hauptzustandsautomat; steuert den globalen Systemlebenszyklus (Startup, Shutdown) und delegiert Steuerkommandos an die Agents (User configured startup and shutdown).
• <<StateMachine>> Agent (Grün, Multitasking-Instanzen 1..*): Sub-Zustandsautomaten zur Kapselung disjunkter Teilzustände (z. B. Subsystem-spezifische Modi).
• Konfigurationsartefakte innerhalb von Controller & Agent:
  • <<TransitionRequestTable>>: Regelwerk / Matrix zur Abbildung von Trigger-Ereignissen auf Zustandsübergänge.
  • <<RecoveryErrorTable>> (im Diagramm: RecveryErrorTable): Zuweisung von Fehlerereignissen zu definierten Recovery-Aktionen.
  • <<State>> (Multiplizität: 1..*): Modellierte diskrete System-/Funktionszustände.
  • <<ActionItemList>> (Multiplizität: 1..*): Sequenzierte Befehlslisten, die bei Zustandsübergängen ausgeführt werden (z. B. Anforderung an EM).

Interaktionspunkte & Schnittstellen (Lila)

• StateRequest (1..*): Eingehender Port für externe Zustandswechselanforderungen von SMControlApplication (geschützt via IAM).
• StateNotification (0..*): Ausgehender Port / Event zur Benachrichtigung externer Applikationen über Zustandstransitionen.
• StateClient (1..*): IPC-Interface zu EM (Anforderung von Target States für Function Groups).
• RecoveryAction (0..*): Schnittstelle von PHM zur Initiierung von Fehlerreaktionen im State Management.
• NetworkHandle (0..*): Schnittstelle zu NM für Netzanforderungen und Synchronisation mit Buszuständen.
• UpdateRequest (0..1): Schnittstelle zu UCM zur Synchronisation von Update-Modi.

3. Dynamisches Verhalten & Sequenzablauf

1. Ereignis-Eingang & Autorisierung:
   • Eine externe SMControlApplication sendet einen StateRequest.
   • Das IAM prüft die Zugriffsberechtigung. Ist ein Update-Vorgang aktiv (Blocked during update session), werden Anforderungen verworfen bzw. blockiert.
   • Alternativ treffen asynchrone Trigger über PHM (RecoveryAction), NM (NetworkHandle) oder UCM (UpdateRequest) ein.
2. Dispatching & Transitionsevaluierung:
   • StateMachine Management leitet Triggerevents an den Controller oder die zuständigen Agents weiter.
   • Anhand der <<TransitionRequestTable>> (bzw. bei Fehlern der <<RecoveryErrorTable>>) wird geprüft, ob die Transition im aktuellen <<State>> valide ist und welche Schutzbedingungen (Guards) gelten.
3. Aktionsausführung:
   • Validierte Transitionen aktivieren eine zugehörige <<ActionItemList>>.
   • Abarbeitung von Aktionen: Das State Management fordert über den StateClient bei EM den Wechsel von Function Group States (FGS) an oder steuert Hardware-/Netzwerkzustände über NM.
4. Rückmeldung:
   • Nach erfolgreicher Zustandstransition und Bestätigung durch den EM werden registrierte Observer über StateNotification asynchron informiert.

4. Normative Relevanz & Entwickler-Hinweise

• Trennung von Strategie und Plattform: Die betriebliche Steuerlogik (SMControlApplication) ist zwingend vom Plattformkern (State Management) entkoppelt. Applikationsentwickler implementieren keine direkten FGS-Wechsel bei EM, sondern interagieren ausschließlich deklarativ via StateRequest.
• Modellierung / ARXML-Design:
  • Zustände, Tabellen (TransitionRequestTable, RecoveryErrorTable) und Aktionslisten müssen vollständig im Execution- und State-Management-Manifest modelliert werden.
  • Hierarchische Trennung beachten: Der Controller muss Startup und Shutdown deterministisch vorgeben, bevor untergeordnete Agents operieren können.
• IAM-Policies: Jede Applikation, die StateRequest nutzt, erfordert zwingend eine passend konfigurierte IAM-Policy (Grant/Token), da Anfragen andernfalls stillschweigend oder per Security-Event verworfen werden.
• UCM-Einschränkung (Update Session): Während eines Software-Updates sperrt die UpdateRequest-Bindung den externen StateRequest-Pfad. Steuerungsapplikationen müssen defensiv ausgelegt sein und Timeout-/Rejection-Pfade vorhalten.
• Determinismus: Da Aktionen sequenziell über ActionItemList und StateClient abgearbeitet werden, hängen Transitionszeiten direkt von der Reaktionszeit des EM auf Prozessbeendigungen/-starts ab (Gefahr von Timeouts bei synchronen Blockaden).