DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-00f03948ae751d9a 691 × 583 px 2 Release(s)

Figure 11.23: Scenario: Report Supervision Failure

SHA-256 Inhalts-Fingerabdruck: 00f03948ae751d9ac2c08e4d0f2673fdf35672ec8408f67d4efe63a0d7dc19f8
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

  • Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombiniertem Fragment alt mit drei Alternativpfaden).
  • Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Releases R24-11 und R25-11, Spezifikation AUTOSAR_AP_EXP_SWArchitecture (Kapitel 11.5 Platform Health Management).
  • Funktionale Einordnung: Standard-Fehlerbehandlungspfad (Default Scenario) bei Verletzung einer Überwachungsbedingung (Supervision Failure). Es beschreibt die Interaktion zwischen überwachter Applikation, Überwachungsinstanz (PHM), zentraler Zustands- und Recovery-Steuerung (SM) sowie dem Hardware-/System-Watchdog zur Absicherung funktionaler Sicherheit (ISO 26262).

2. Komponenten, Entitäten & Schnittstellen

  • Beteiligte Entitäten (Lifelines):
    • :Adaptive Application: Standard-Benutzerprozess im User Space, der Checkpoints an das Health Management meldet.
    • «aapFunctionalCluster» :Platform Health Management: Adaptiver Funktionscluster (PHM) zur Auswertung von Alive-, Deadline- und Logical-Supervisions.
    • «aapFunctionalCluster» :State Management: Adaptiver Funktionscluster (SM) zur systemweiten Koordination von Function Groups, Machine States und Recovery Actions.
    • :Watchdog: Abstrahierte Plattform-/Hardware-Watchdog-Entität (Watchdog Driver / Daemon) zur Ausführung harter Systemreaktionen (Machine Reset).
  • Schnittstellen & Methodenaufrufe:
    • Offer(): Registrierungsmethode von SM bei PHM zur Bereitstellung des Recovery-Dienstes.
    • ReportCheckpoint(wrongCheckpointId): API-Aufruf von Applikationsseite an PHM (z. B. via ara::phm).
    • «aapInformative» handleSupervisionFailure(): PHM-interne, rein informative Fehleranalyse und Zustandsauswertung.
    • RecoveryHandler(): Callback-/Notification-Interface von PHM an SM zur Einleitung von Recovery-Maßnahmen, mit synchroner Rückmeldung (:kActionHandled oder :kFireWatchdogReaction).
    • :kActionHandled: Rückgabewert/Antwortnachricht von SM an PHM bei erfolgreicher lokaler Fehlerbehandlung.
    • :kFireWatchdogReaction: Rückgabewert/Antwortnachricht von SM an PHM zur expliziten Beauftragung einer Watchdog-Eskalation.
    • FireWatchdogReaction(): Aufruf von PHM an den Watchdog zur Auslösung eines Maschinen-Resets (angefordert durch SM oder durch Timeout).
    • StopOffer(): Deregistrierungsmethode von SM bei Einleitung des Shutdowns.

3. Dynamisches Verhalten & Sequenzablauf

  1. Präbedingung (Initialisierung):
    • :State Management ruft lokal Offer() auf, um sich beim PHM als aktiver Empfänger für Überwachungsfehler zu registrieren.
  2. Fehler-Trigger:
    • :Adaptive Application sendet ReportCheckpoint(wrongCheckpointId). Dies repräsentiert beispielhaft eine Transition-Verletzung innerhalb einer Logical Supervision (Graph-Inkonsistenz).
  3. Fehleranalyse & Signalisierung:
    • PHM erkennt den Überwachungsfehler und führt intern «aapInformative» handleSupervisionFailure() aus.
    • PHM delegiert die Fehlerbehebung über den Aufruf RecoveryHandler() an :State Management.
  4. Verzweigung im Fehlerbehandlungspfad (alt):
    • Pfad 1 ([action handled]): :State Management behandelt den Fehler erfolgreich (z. B. Prozess-Neustart) und antwortet mit :kActionHandled. PHM unternimmt keine weiteren Schritte.
    • Pfad 2 ([watchdog reaction requested]): :State Management entscheidet auf Systemebene, dass eine Watchdog-Aktion erforderlich ist, und antwortet mit :kFireWatchdogReaction. PHM ruft daraufhin FireWatchdogReaction() am :Watchdog auf.
    • Pfad 3 ([timeout]): Antwortet :State Management nicht innerhalb des im Manifest konfigurierten Timeouts, greift der Timeout-Pfad und PHM ruft autonom FireWatchdogReaction() am :Watchdog auf.
  5. Postcondition / Shutdown:
    • Beim regulären oder fehlerbedingten Herunterfahren ruft :State Management StopOffer() auf, um weitere Aufrufe von RecoveryHandler() durch PHM zu unterbinden.

4. Normative Relevanz & Entwickler-Hinweise

  • Normative Schnittstellen & Statuscodes:
    • Der Methodenaufruf RecoveryHandler() fordert eine explizite Rückmeldung von :State Management mit den definierten Rückgabewerten :kActionHandled (Erfolg der lokalen Wiederherstellung) oder :kFireWatchdogReaction (Eskalationsanforderung an PHM).
    • Nur bei Ausbleiben dieser Rückmeldung innerhalb des im Manifest definierten Timeouts ist PHM autorisiert, eigenständig FireWatchdogReaction() auszulösen.
  • Informative Bestandteile:
    • Die Methode handleSupervisionFailure() ist mit dem Stereotyp «aapInformative» gekennzeichnet; ihre konkrete Realisierung innerhalb des PHM ist nicht normativ vorgeschrieben, sondern dient als Implementierungsleitfaden.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R23-11 → R24-11 normative Änderung Vorgänger: FIG-5398aad1d66b4955
  • Kombiniertes Fragment: Ersetzung des bedingten Fragments opt [timeout] durch ein Alternativ-Fragment alt mit drei Zweigen ([action handled], [watchdog reaction requested], [timeout]).
  • Schnittstelle / Antwortnachrichten RecoveryHandler(): Ergänzung der Rückgabewerte :kActionHandled (im Zweig [action handled]) und :kFireWatchdogReaction (im Zweig [watchdog reaction requested]) von :State Management an :Platform Health Management.
  • Ablauf FireWatchdogReaction(): Auslösung am :Watchdog erfolgt nun zusätzlich explizit nach Erhalt von :kFireWatchdogReaction im Zweig [watchdog reaction requested].
  • Methode handleSupervisionFailure(): Ergänzung des Stereotyps «aapInformative».
  • Aktivierungsbalken (:State Management): Verlängerung des Aktivierungsbalkens auf der Lebenslinie von :State Management bis zum Senden der jeweiligen Antwortnachricht.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» | :Platform Health | Management | «aapFunctionalCluster» | :State Management | :Adaptive Application | alt | [action handled] | [watchdog reaction requested] | [timeout] |           |  |  |   |  |    |   |  |  |   |   |    |   |      |  |   |  |     |   |  |  |   | :Watchdog | StopOffer() | FireWatchdogReaction() | :kFireWatchdogReaction | ReportCheckpoint(wrongCheckpointId) | Offer() | RecoveryHandler() | FireWatchdogReaction() | :kActionHandled | «aapInformative» handleSupervisionFailure()

Begleitender Spezifikationstext:

  :Watchdog StopOffer() FireWatchdogReaction() :kFireWatchdogReaction ReportCheckpoint(wrongCheckpointId) Offer() RecoveryHandler() FireWatchdogReaction() :kActionHandled «aapInformative» handleSupervisionFailure() Figure 11.23: Scenario: Report Supervision Failure Figure 11.23 illustrates the default scenario for Report Supervision Failure. As a precondition, State Management needs to call the method Offer() in order to register for notifications. Whenever Platform Health Management detects a supervision failure it notifies State Management by invoking the callback method RecoveryHandler(). If the call to State Management does not return within the timeout configured in the Manifest, Platform Health Management needs to call the method FireWatchdogReaction() to perform a restart of the Machine. During its shutdown State Management needs to call the method StopOffer() to disable further invocations of RecoveryHandler(). 11.5.1.3 Recover from Critical Supervision Failure 11.5.1.3.1 Scenario: Recover from Critical Supervision Failure in Execution Management 234 of 269 Document ID 982: AUTOSAR_AP_EXP_SWArchitecture

Vorkommen in AUTOSAR-Releases (2)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R24-11 AUTOSAR_AP_EXP_SWArchitecture S. 214 11.24 Figure 11.24: Scenario: Report Supervision Failure
R25-11 AUTOSAR_AP_EXP_SWArchitecture S. 234 11.23 Figure 11.23: Scenario: Report Supervision Failure