DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-5398aad1d66b4955 691 × 420 px 1 Release(s)

Figure 11.20: Scenario: Report Supervision Failure

SHA-256 Inhalts-Fingerabdruck: 5398aad1d66b495530ae98fa912b3ab866fa759e94cd6dc2ca1d042fca3efc0d

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-description@2 · erstellt am 2026-10-07

1. Diagrammtyp & Architektur-Kontext

  • Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm mit bedingtem Fragment opt).
  • Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R23-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).
    • handleSupervisionFailure(): PHM-interne Zustandsauswertung und Fehlerverarbeitung.
    • RecoveryHandler(): Callback-/Notification-Interface von PHM an SM zur Einleitung softwarebasierter Wiederherstellungsmaßnahmen.
    • FireWatchdogReaction(): Eskalationsaufruf von PHM an den Watchdog bei Ausbleiben der Reaktion durch SM.
    • StopOffer(): Deregistrierungsmethode von SM bei Einleitung des Shutdowns.

3. Dynamisches Verhalten & Sequenzablauf

  1. Präbedingung (Initialisierung):
    • :State Management ruft intern/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 synchron handleSupervisionFailure() aus.
    • PHM delegiert die Fehlerbehebung über den Callback RecoveryHandler() asynchron/synchron an :State Management.
  4. Eskalationspfad (opt [timeout]):
    • Läuft der im Manifest konfigurierte Timeout ab, bevor :State Management die Bearbeitung von RecoveryHandler() abschließt bzw. quittiert, greift der opt-Zweig:
    • PHM triggert direkt FireWatchdogReaction() am :Watchdog, um einen deterministischen Maschinen-Neustart (Machine Reset / Fail-Safe Transition) zu erzwingen.
  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

  • PHM-Manifest-Konfiguration:
    • Für jede definierte Supervision (Alive, Deadline, Logical) muss im Execution-/Health-Manifest zwingend ein definierter Timeout für die Rückmeldung des SM-Recovery-Handlers hinterlegt werden.
    • Der Watchdog-Reaktionspfad (FireWatchdogReaction) dient als harte Sicherheitsbarriere gegen blockierende oder abgestürzte State-Management-Instanzen.
  • State Management Implementierung:
    • Der RecoveryHandler() muss strikt nicht-blockierend ausgelegt sein. Länger dauernde Recovery-Aktionen (z. B. Neustart einer Prozessgruppe via Execution Management) müssen asynchron angestoßen werden, um den harten Watchdog-Timeout nicht zu verletzen.
    • Vor dem Eintritt in den Shutdown-State muss SM deterministisch StopOffer() aufrufen, um Race Conditions mit spät eintreffenden PHM-Meldungen zu verhindern.
  • Applikations-Entwicklung (ara::phm):
    • Checkpoint-IDs müssen exakt den im Modell definierten Transitionsgraphen entsprechen. Ungültige Checkpoint-Sequenzen werden deterministisch als Supervision Failure gewertet und eskalieren platformweit.

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

R23-11 → R24-11 normative Änderung Nachfolger: FIG-00f03948ae751d9a
  • 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 | :Watchdog | opt | [timeout] | FireWatchdogReaction() | StopOffer() | Offer() | ReportCheckpoint(wrongCheckpointId) | handleSupervisionFailure() | RecoveryHandler()

Begleitender Spezifikationstext:

  :Adaptive Application :Watchdog opt [timeout] FireWatchdogReaction() StopOffer() Offer() ReportCheckpoint(wrongCheckpointId) handleSupervisionFailure() RecoveryHandler() Figure 11.20: Scenario: Report Supervision Failure Figure 11.20 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.2 Scenario: Critical Supervision Failure in State Management «aapFunctionalCluster» :Platform Health Management «aapFunctionalCluster» :State Management :Watchdog     

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R23-11 AUTOSAR_AP_EXP_SWArchitecture S. 179 11.20 Figure 11.20: Scenario: Report Supervision Failure