Figure 11.6: Scenario: Recover from Supervision Failure

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit Interaktionsreferenz ref).
• Technischer Zweck: Spezifikation des standardisierten Recovery-Mechanismus bei Verletzung einer Laufzeitüberwachung (Supervision Failure) innerhalb der AUTOSAR Adaptive Platform (AP, Release R23-11, Dokument AUTOSAR_AP_EXP_SWArchitecture).
• Funktionale Einordnung: Kollaboration zwischen den drei zentralen Functional Clustern Platform Health Management (PHM), State Management (SM) und Execution Management (EM) zur koordinierten Fehlerreaktion und Überführung betroffener Prozesse oder Funktionsgruppen in einen definierten Zustand.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • «aapFunctionalCluster» :Platform Health Management: Verantwortlich für Alive-, Deadline-, Logical- und Health-Channel-Supervision von Prozessen.
  • «aapFunctionalCluster» :State Management: Systemspezifische Steuerinstanz (Policy Manager) für Systemzustände und Function Group States (FG States).
  • «aapFunctionalCluster» :Execution Management: Laufzeitumgebung zur Prozess-Instanziierung, -Zustandssteuerung und Durchsetzung von FG-Zustandsübergängen.
• Schnittstellen & Operationen:
  • Offer(): Service-Angebot / Registrierung des Recovery-Interfaces durch SM gegenüber PHM (typischerweise via ara::com oder Cluster-interne IPC).
  • supervisionFailed(): Lokales Fehlerereignis / Trigger in PHM (z. B. Checkpoint-Verletzung, Timeout, Transitionsfehler).
  • handleFailedSupervision(): PHM-interne Auswertung zur Zuordnung der konfigurierten Recovery-Aktion (SupervisionAction).
  • RecoveryHandler(): Callback-/Event-Aufruf von PHM an SM zur Übermittlung des Fehlers und Kontextes.
  • determineDesiredFGState(): desiredState: SM-interne Entscheidungslogik zur Bestimmung des neuen Zielzustands der Function Group.
  • ref Change System State: Wiederverwendbare Interaktionsreferenz, die das standardisierte Protokoll zwischen SM und EM zur Durchführung von Zustandsübergängen kapselt.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungsphase:
   • SM signalisiert PHM über Offer() die Bereitschaft zur Entgegennahme von Recovery-Benachrichtigungen.
2. Fehlerdetektion & Behandlung:
   • PHM detektiert eine Überwachungsverletzung über den Trigger supervisionFailed().
   • PHM führt intern handleFailedSupervision() aus und ermittelt anhand des Manifests die definierte Recovery-Strategie.
   • PHM delegiert die Fehlerreaktion via synchronen oder asynchronen Aufruf RecoveryHandler() an SM.
3. Zustandsbestimmung & Ausführung:
   • SM wertet den Vorfall aus und berechnet mit determineDesiredFGState() den nächsten Soll-Zustand (desiredState) der betroffenen Function Group(s).
   • Ist ein Zustandswechsel erforderlich (z. B. Übergang in SafeState, Restart der FG, Deaktivierung degraded Features), initiiert SM das Szenario Change System State (ref), in welchem EM angewiesen wird, die entsprechenden Prozesse zu terminieren bzw. neu zu starten. Bleibt der Soll-Zustand identisch mit dem Ist-Zustand, endet der Pfad ohne weitere EM-Interaktion.

4. Normative Relevanz & Entwickler-Hinweise

• Architektonische Trennung (Separation of Concerns): PHM übernimmt strikt die Fehlererkennung und -qualifikation, besitzt aber keine System-Entscheidungshoheit bezüglich Zustandswechseln. Das SM fungiert als alleinige Instanz (Policy Authority) für Zustandsübergänge.
• Manifest-Konfiguration (ARXML):
  • Für beaufsichtigte Prozesse müssen Supervision-Elemente (Alive, Deadline, Logical) mit einer RecoveryNotification anstelle harter Watchdog-Resets verknüpft sein.
  • Die Bindung zwischen PlatformHealthManagement und StateManagement muss über die entsprechenden Service- oder Schnittstellen-Deployments konsistent konfiguriert sein.
• API-Vertrag & Fehlertoleranz:
  • Der RecoveryHandler im SM muss deterministisch und nicht-blockierend reagieren, um die Einhaltung der maximal zulässigen Fehlerreaktionszeit (Fault Reaction Time / Safe State Transition gemäß ISO 26262) zu gewährleisten.
  • Entwickler des State Managements müssen Strategien für zyklische oder wiederholte RecoveryHandler-Aufrufe vorhalten (z. B. Eskalation nach maximaler Retry-Anzahl von Prozess-Neustarts zu sicherem ECU-Reset/Degradation).