Figure 10.12: Use case Report Supervision Failure

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Use-Case-Diagramm (Anwendungsfalldiagramm) mit domänenspezifischen AUTOSAR-Adaptive-Stereotypen («aap...»).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Dokument AUTOSAR_AP_EXP_SWArchitecture, Cluster Platform Health Management (PHM).
• Technischer Zweck: Spezifikation der Beteiligungsverhältnisse beim Auftreten eines Überwachungsfehlers (Supervision Failure) im PHM. Das Diagramm definiert die funktionale Schnittstelle des Anwendungsfalls Report Supervision Failure, um erkannte Integritätsverletzungen an übergeordnete Kontroll- und Rückfallebenen weiterzuleiten (State Management zur Einleitung von Recovery-Aktionen und Watchdog zur Absicherung der Hardware-/ECU-Ebene).

2. Komponenten, Entitäten & Schnittstellen

• Systemgrenzen (System Boundaries):
  • Adaptive Platform: Äußerer Systemkontext der Laufzeitumgebung.
  • Platform Health Management: Kapselnder Subsystem-Kontext (Funktionaler Cluster), in dem der Use Case verortet ist.
• Akteure (Actors):
  • Watchdog (Qualifizierung: (from Actors)): Primärer externer oder plattformnaher Überwachungsakteur (z. B. HW-Watchdog bzw. Watchdog-Treiber/Daemon), der bei ausbleibendem Triggering den System-Reset forciert.
• Anwendungsfall (Use Case):
  • «aapUseCase» Report Supervision Failure: Spezifischer Anwendungsfall zur Signalisierung determinierter Fehlerzustände (Alive-, Deadline- oder Logical-Supervision-Verletzungen sowie Health-Channel-Meldungen).
• Funktionale Cluster (Functional Clusters):
  • «aapFunctionalCluster» State Management (Zusatzannotation: daemon-based): Zentraler System-Koordinator der Adaptive Platform, ausgeführt als eigener Daemon-Prozess, verantwortlich für State-Transitions, Degraded-Modes und Recovery-Entscheidungen.
• Beziehungen:
  • Assoziation Watchdog ↔ Report Supervision Failure mit Stereotyp «aapParticipates»: Deklariert den Watchdog als involvierten Reaktions- oder Benachrichtigungspartner.
  • Assoziation State Management ↔ Report Supervision Failure mit Stereotyp «aapParticipates»: Bindet das State Management als Empfänger der Fehlerbenachrichtigung zur Einleitung koordinierter Recovery-Maßnahmen ein.

3. Dynamisches Verhalten & Sequenzablauf

1. Fehlerdetektion (PHM-intern):
   • Das PHM registriert eine Verletzung einer definierten Überwachungsregel einer Supervised Entity (z. B. verletztes Timing-Fenster bei Deadline Supervision, fehlerhafte Checkpoint-Reihenfolge bei Logical Supervision oder verpasster Heartbeat bei Alive Supervision).
2. Auslöser (Trigger):
   • Übergang des lokalen oder globalen Supervision-Status in den Zustand EXPIRED bzw. FAILED.
3. Meldung an State Management (asynchron / IPC):
   • PHM signalisiert das Überwachungsereignis über plattforminternes IPC an den Daemon des State Management.
   • Reaktion SM: State Management evaluiert das Fehlerszenario anhand hinterlegter State-Management-Regeln und leitet zielgerichtete Recovery-Schritte ein (z. B. Prozessneustart via Execution Management, Deaktivierung von Funktionsgruppen, Übergang in einen Degraded/Fallback Mode).
4. Interaktion mit dem Watchdog:
   • Je nach Ausprägung und Konfiguration:
     • Passiver/Restriktiver Pfad: PHM setzt das periodische Nachführen/Servicen des Watchdogs für die fehlerhafte Entität aus; bei kritischen Gesamtsystemfehlern wird das Watchdog-Triggern komplett unterdrückt, sodass der Hardware-Watchdog nach Ablauf der Timeout-Zeitspanne einen Hard-Reset erzwingt.
     • Aktiver Pfad: Direkte Deaktivierung oder Übergabe des Fehlerzustands an die Watchdog-Verwaltungslogik.

4. Normative Relevanz & Entwickler-Hinweise

• PHM-Konfiguration (ARXML / Manifest):
  • Entwickler müssen für jede SupervisedEntity Recovery-Aktionen im PHM-Execution- bzw. Service-Instance-Manifest definieren. Die Weiterleitung an das State Management erfordert eine konsistente Modellierung der PHMRecoveryNotification-Schnittstellen und korrespondierender Action-Lists im State Management.
• Architektonische Trennung (Separation of Concerns):
  • Das PHM führt Fehlerreaktionen nicht autonom-vollständig durch, sondern delegiert die Systemreaktion an State Management. Es ist als reiner Detektions- und Meldeknoten konzipiert.
  • Entwickler dürfen Fehler-Recovery (z. B. Prozess-Neustarts, Graceful Shutdowns) nicht direkt in Applikationsprozessen abhandeln; dies muss über definierte Trigger an SM/EM erfolgen.
• Daemon-Abhängigkeit:
  • Da State Management als daemon-based Cluster ausgelegt ist, erfolgt die Kommunikation über Inter-Process Communication (IPC). Bei vollständigem Hängen des Betriebssystems oder des IPC-Subsystems greift die zweite Linie (Watchdog) als autarker Notlauf-Pfad, um Deadlocks der Adaptive Platform deterministisch abzufangen.