Figure 11.5: Scenario: Recover by System State Change

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm mit Interaktionsreferenz (ref).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R24-11), Spezifikation AUTOSAR_AP_EXP_SWArchitecture, Kapitel 11 (System Lifecycle Management / Recover from Supervision Failure).
• Technischer Zweck: Darstellung des kanonischen Recovery-Pfads (Recover by System State Change) nach Auftreten eines Überwachungsfehlers (Supervision Failure). Es demonstriert die strikte Entkopplung zwischen Fehlerdetektion (Platform Health Management, PHM) und Fehlerbehebungsstrategie (State Management, SM) unter Einbeziehung des Prozess-Lifecycle-Managers (Execution Management, EM).

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Functional Cluster (Lebenslinien):
  • «aapFunctionalCluster» :Platform Health Management (PHM): Überwacht Alive-, Deadline- und Logical-Supervisions sowie Health-Channels von Prozessen und Anwendungen.
  • «aapFunctionalCluster» :State Management (SM): Zentraler Koordinator für Systemzustände, Funktionsgruppenzustände (Function Group States) und fahrzeugspezifische Recovery-Entscheidungen.
  • «aapFunctionalCluster» :Execution Management (EM): Verantwortlich für Start, Stopp, Determinismus und Zustandsübergänge konfigurierter Prozesse/Function Groups.
• Stereotypen & Notationen:
  • «aapFunctionalCluster»: Kennzeichnet funktionale Plattform-Kernkomponenten der AUTOSAR Adaptive Platform.
  • «aapInformative»: Markiert nicht-normative Schnittstellen, interne Kontrollflüsse oder exemplarische Hilfsfunktionen, die nicht als feste C++-API standardisiert sind.
  • ref: UML-Interaktionsreferenz auf das ausgelagerte Sub-Szenario Change System State.
• Schnittstellen & Operationen:
  • Offer(): Service-Bereitstellung / Registrierung des Recovery-Interfaces von SM gegenüber PHM (typischerweise IPC/ara::com-basiert oder plattform-interne Kopplung).
  • supervisionFailed() («aapInformative»): Interner oder watchdog-getriebener Trigger bei Verletzung einer definierten Überwachungsregel (Checkpoint-Zeitfenster, Alive-Zähler, Graph-Traversierung).
  • handleFailedSupervision() («aapInformative»): PHM-interne Regelauswertung und Zuordnung der fehlgeschlagenen Supervision zu einer konfigurierten Recovery-Aktion.
  • RecoveryHandler(): Normative Callback-/Ereignisschnittstelle von PHM an SM zur Signalisierung des aufgetretenen Fehlers samt Kontext.
  • determineDesiredFGState(): desiredState («aapInformative»): SM-interne Entscheidungstabelle/Regelwerk zur Bestimmung des neuen Zielzustands der betroffenen Function Group(s).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung / Service Offer:
   • State Management bietet seine Service-Schnittstelle via Offer() an, sodass PHM den Recovery-Kanal auflösen und binden kann.
2. Fehlerdetektion (Supervision Failure):
   • Ein Prozess verletzt eine Überwachungsbedingung. PHM registriert dies über den Trigger supervisionFailed().
3. PHM-interne Evaluierung:
   • PHM führt handleFailedSupervision() aus und ermittelt anhand des Health Channel / Supervision Mapping im Manifest, dass eine Systemreaktion via State Management konfiguriert ist.
4. Fehlersignalisierung an SM:
   • PHM ruft synchron oder asynchron RecoveryHandler() am State Management auf und übergibt die Identifikatoren der gescheiterten Supervision.
5. Zielzustandsermittlung im SM:
   • SM führt determineDesiredFGState() aus. Abhängig von Sicherheitskonzept und Kontext wird ein neuer desiredState für die betroffene Function Group bestimmt (z. B. Fallback auf sicheren Zustand, Degradation oder Neustart-Zustand). Hinweis: Der Zustand kann formal dem aktuellen Zustand entsprechen, falls ein lokaler Prozess-Neustart innerhalb derselben State-Definition projektiert ist.
6. Zustandstransition via Execution Management:
   • Übergang in das referenzierte Sequenzfragment ref Change System State: SM interagiert über die ara::exec::StateClient-API mit Execution Management, um die Zielzustände der Function Groups einzusteuern. EM stoppt oder reinitialisiert die entsprechenden Prozesse deterministisch.

4. Normative Relevanz & Entwickler-Hinweise

• Architekturprinzip (Separation of Concerns): PHM terminiert oder manipuliert in diesem Szenario keine Prozesse eigenmächtig. Die Hoheit über Prozess-Lifecycles liegt exklusiv bei Execution Management, gesteuert durch die fahrzeugspezifische Richtlinienkomponente State Management.
• Implementierungsverantwortung (OEM vs. Tier-1/Stack-Vendor):
  • PHM und EM sind standardisierte BSW-Cluster des Stack-Herstellers.
  • Das State Management (inkl. RecoveryHandler-Reaktion und determineDesiredFGState) ist maßgeblich applikations-/OEM-spezifisch implementiert. Entwickler müssen sicherstellen, dass die Handler-Logik nicht blockierend arbeitet, um Deadlocks in Fehlersituationen zu verhindern.
• Manifest-Konfiguration:
  • In den Adaptive Platform Machine- und Execution Manifesten müssen die Supervision Recovery Actions explizit auf Benachrichtigung des State Managements (RecoveryNotification) konfiguriert sein, anstatt auf direkte Aktionen (wie Watchdog-Reset oder lokale Prozessneustarts durch PHM).
• API-Verbindlichkeit: Methoden mit dem Stereotyp «aapInformative» stellen Implementierungsrichtlinien dar; der verbindliche Integrationsvertrag besteht primär im Empfang des RecoveryHandler-Signals und der anschließenden Ansteuerung des ara::exec::StateClient.