DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-442e2fefebc19b75 301 × 254 px 1 Release(s)

Figure 11.18: Scenario: Manage Watchdog

SHA-256 Inhalts-Fingerabdruck: 442e2fefebc19b75f958e7be74b5b917f57c3477c1d8e9e5151bd90b8183bc17
✦ 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 (Interaktionsszenario mit Interaktionsrahmen loop).
  • Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R23-11, Spezifikation AUTOSAR_AP_EXP_SWArchitecture, Kapitel 11 (Platform Health Management, PHM).
  • Technischer Zweck: Darstellung des zyklischen Basismechanismus zur Überwachung der Plattform- und Applikationsintegrität sowie der abgeleiteten Watchdog-Bedienung. Das PHM dient als zentrale Instanz zur Bündelung aller Überwachungsergebnisse vor dem Hardware-/System-Watchdog-Trigger.

2. Komponenten, Entitäten & Schnittstellen

  • «aapFunctionalCluster» :Platform Health Management:
    • Instanz des funktionalen Clusters PHM der Adaptive Platform.
    • Verantwortlich für die Aggregation und Auswertung aller konfigurierten Überwachungsarten (Alive Supervision, Deadline Supervision, Logical Supervision).
  • :Watchdog:
    • Abstrahierte Zielentität (z. B. Watchdog-Daemon, OS-Watchdog-Service oder Hardware-Watchdog-Treiber).
  • Aufgerufene Operationen / Schnittstellen:
    • checkSupervisions(): PHM-interne synchrone Methode (Self-Call) zur periodischen Auswertung aller aktiven Überwachungsmetriken und Checkpoint-Zustände.
    • AliveNotification(): Ausgehender Methodenaufruf vom PHM an den Watchdog zur Bestätigung der Systemlebensfähigkeit (Watchdog Refresh / Kick).

3. Dynamisches Verhalten & Sequenzablauf

  • Zyklus (loop-Block): Läuft deterministisch in einer Endlosschleife, getaktet durch die konfigurierte Zykluszeit der PHM-Hauptverarbeitungsaufgabe.
  1. Zustandsevaluierung: Das PHM führt intern checkSupervisions() aus. Hierbei werden alle empfangenen Checkpoint-Meldungen, Alive-Zähler, Ausführungsreihenfolgen und Latenzzeiten der überwachten Prozesse gegen die im Manifest hinterlegten Schwellwerte validiert.
  2. Watchdog-Triggern: Bei intaktem Gesamtzustand (Supervision Status: OK) setzt das PHM den Aufruf AliveNotification() an die Entität :Watchdog ab, um einen Timeout/Reset des Watchdogs zu verhindern.
  • Fehlerpfad (implizit/Abbruchbedingung): Ergibt checkSupervisions() einen unzulässigen Status (z. B. Deadline-Verletzung, Alive-Counter-Diskrepanz) und greift keine rein lokale Recovery Action, wird AliveNotification() unterdrückt. Dies führt zum gezielten Ablauf des Watchdogs und initiiert den plattformweiten Hardware-/System-Reset.

4. Normative Relevanz & Entwickler-Hinweise

  • Architektur-Entkopplung: Adaptive Applications dürfen den Watchdog niemals direkt bedienen. Die Watchdog-Bedienung erfolgt ausschließlich gekoppelt an die erfolgreiche Evaluierung durch das PHM.
  • Timing & Konfiguration: Das Ausführungsintervall des PHM-Loops, die Supervisions-Toleranzfenster und die Hardware-Watchdog-Timeout-Periode müssen strikt aufeinander abgestimmt werden: $$\text{Watchdog-Timeout} > \text{PHM-Loop-Periode} + \text{Worst-Case Execution Time (WCET)} + \text{Jitter}$$
  • Sicherheitsrelevanz (ISO 26262): checkSupervisions() bildet die funktionale Grundlage für programmablauf- und lebendigkeitsbezogene Sicherheitsziele (Safety Goals). Ein fehlerhaft konfiguriertes Überwachungsmodell im ARXML führt entweder zu unberechtigten System-Resets (False Positives) oder zum Ausbleiben der Fehlerreaktion (False Negatives).

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

R23-11 → R24-11 redaktionell Nachfolger: FIG-4bca87b097bec626
  • Interne Methode checkSupervisions(): Ergänzung des Stereotyps «aapInformative» oberhalb des Methodenaufrufs zur formalen Kennzeichnung als informatives Modellelement.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» | :Platform Health Management | :Watchdog | loop | checkSupervisions() | AliveNotification()

Begleitender Spezifikationstext:

Explanation of Adaptive Platform Software Architecture AUTOSAR AP R23-11 «aapFunctionalCluster» :Platform Health Management :Watchdog loop checkSupervisions() AliveNotification() Figure 11.18: Scenario: Manage Watchdog Figure 11.18 shows the default scenario for Manage Watchdog. Platform Health Management regularly checks its supervisions. Platform Health Management also calls the method AliveNotification() cyclically in order to report aliveness to the Watchdog. 11.5.1.2 Report Checkpoint 11.5.1.2.1 Scenario: Report Checkpoint :Adaptive Application «aapFunctionalCluster» :Platform Health Management «aapFunctionalCluster» :Intrusion Detection System Manager alt [access granted] [access denied] checkAccess() handleReportedCheckpoint() ReportEvent() ReportCheckpoint() Figure 11.19: Scenario: Report Checkpoint Figure 11.19 shows the default scenario for Report Checkpoint. The Adaptive Application reports a checkpoint to Platform Health Management by calling the method ReportCheckpoint(). After that, Platform Health Management checks if the Adaptive Application is allowed to report the checkpoint. Then, Platform Health Management handles the reported checkpoint internally depending on the type of the supervision mode. If access is denied, Platform Health Management reports this event to Intrusion Detection System Manager by calling the method ReportEvent(). 178 of 198 Document ID 982: AUTOSAR_AP_EXP_SWArchitecture

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R23-11 AUTOSAR_AP_EXP_SWArchitecture S. 178 11.18 Figure 11.18: Scenario: Manage Watchdog