Figure 2: Overview of Watchdog Manager Supervision

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Aktivitätsdiagramm mit zwei Swimlanes (Partitionen: Ausführungskontexte SE context vs. OS Scheduler context), Kontrollflüssen, Datenknoten (Objekt-/Pufferzustände) und Iterationsbereich (For each SE).
• Funktionale Einordnung: AUTOSAR Classic Platform, Basic Software (BSW), System Services Layer (WdgM). Das Diagramm visualisiert die funktionale Entkopplung zwischen der ereignisgesteuerten Erfassung von Checkpoints innerhalb überwachter Software-Entitäten (Supervised Entity – SW-C/BSW-Modul) und der periodisch-zyklischen Aggregation, Bewertung und Watchdog-Servicierung im Task-Kontext des Betriebssystems.

2. Komponenten, Entitäten & Schnittstellen

• Partitionen / Kontexte:
  • SE context: Thread/Task-Kontext der aufrufenden Supervised Entity (SW-C Runnable, BSW-Task).
  • OS Scheduler context: Zyklischer BSW-Task-Kontext (typischerweise 10 ms – 100 ms Raster).
• APIs & Entry Points:
  • WdgM_CheckpointReached(WdgM_SupervisedEntityIdType, WdgM_CheckpointIdType): Synchrone BSW-API, ausgelöst durch die SE zur Meldung des Erreichens eines definierten Kontrollpunkts.
  • WdgM_MainFunction(): Periodische Hauptfunktion des Watchdog-Managers, gerufen durch das BSW Scheduler / OS.
• Interne Datenstrukturen & Puffer (Data Stores):
  • Alive Indication Counters: Puffer für Checkpoint-Trefferzähler je Alive-Überwachung.
  • Result of each Deadline Supervision of SE: Zwischenergebnis (korrekt / fehlerhaft; Zeitfenster zwischen Start- und End-Checkpoint eingehalten/verletzt).
  • Result of each Logical Supervision of SE: Zwischenergebnis (korrekt / fehlerhaft; Programmlaufkontrolle über Transitionen im Kontrollflussgraphen).
  • Result of each Alive Supervision of SE: Auswertung der Trefferzähler gegen konfigurierte Min/Max-Toleranzgrenzen (WdgMExpectedAliveIndications, Toleranzen).
  • Local Supervision Status of SE (state): Lokaler Zustand je SE (WdgM_LocalStatusType: OK, FAILED, EXPIRED, DEACTIVATED).
  • Global Supervision Status (state): Gesamtsystemstatus (WdgM_GlobalStatusType: OK, FAILED, EXPIRED, STOPPED, DEACTIVATED).
• Beziehungen & Abhängigkeiten:
  • 1:n-Beziehung zwischen globalem Status und lokalen SE-Zuständen (For each SE).
  • n:1-Beziehung der Teilüberwachungen (Alive, Deadline, Logical) zum jeweiligen Local Supervision Status.
  • Ausgehende Hardwareschnittstelle: Ansteuerung des Hardware-Watchdogs via Watchdog Interface (WdgIf_SetTriggerCondition).

3. Dynamisches Verhalten & Sequenzablauf

• Asynchroner/Ereignisgesteuerter Pfad (SE context):
  1. Aufruf von WdgM_CheckpointReached() durch SE.
  2. Atomare Inkrementierung des Alive Indication Counter für den referenzierten Checkpoint.
  3. Synchrone Auswertung der Deadline Supervision (Berechnung des Zeitabstands zum korrespondierenden Start-Checkpoint; Prüfung gegen Min-/Max-Deadlines; Ablage des Status correct/incorrect).
  4. Synchrone Auswertung der Logical Supervision (Validierung der Transition vom Vorgänger-Checkpoint im Graphen; Ablage des Status correct/incorrect).
  5. Rückkehr in die Applikation (Terminierung des synchronen Pfades).
• Zyklischer Aggregationspfad (OS Scheduler context):
  1. Periodischer Start über WdgM_MainFunction().
  2. Iteration über alle aktiven Supervised Entities (For each SE):
     • Auswertung der Alive Supervision: Abgleich der akkumulierten Alive Indication Counters gegen konfigurierte Soll-Intervalle/Toleranzfenster für den vergangenen Zyklus; Rücksetzen der Zähler.
     • Determine the Local Supervision Status of SE: Konsolidierung der Einzelergebnisse (Alive, Deadline, Logical) und Fortschaltung des lokalen Zustandsautomaten der SE (z. B. Inkrement/Dekrement von Fehlerzählern; Übergang nach FAILED oder EXPIRED).
  3. Determine Global Supervision Status: Auswertung aller lokalen SE-Statuswerte gemäß Konfigurationsmatrix (z. B. führt ein EXPIRED einer kritischen SE zwingend zu global EXPIRED).
  4. Handle errors: Bei Fehlern Statusmeldungen an Dem (Produktionsfehler/DTC) bzw. Det absetzen; ggf. OS-Partition-Reset oder Mode-Switch triggern.
  5. Set condition for HW watchdog triggering:
     • Bei Zustand OK oder FAILED (innerhalb definierter Toleranzzyklen): Watchdog-Trigger-Wert via WdgIf_SetTriggerCondition() neu setzen.
     • Bei Zustand EXPIRED: Unterdrückung des Triggers (TriggerCondition = 0), um einen kontrollierten Hardware-Reset via Watchdog-Timeout zu erzwingen.

4. Normative Relevanz & Entwickler-Hinweise

• Konkurrenz- & Reentrancy-Anforderungen: WdgM_CheckpointReached() muss reentrant und multikernfähig sein. Der Zugriff auf Alive Indication Counters sowie Zustandsvariablen der Deadline- und Logical-Supervision erfordert OS-Interruptsperren oder atomare Operationen, da Checkpoints preemptiv zu WdgM_MainFunction() und untereinander aus unterschiedlichen Tasks aufgerufen werden.
• Laufzeit-Budgetierung: Alive Supervision ist extrem leichtgewichtig im SE-Kontext (reines Inkrement). Deadline- und Logical-Supervision evaluieren Zeit- und Graph-Bedingungen synchron im Task-Kontext der SE; dies erhöht die Worst-Case Execution Time (WCET) der Applikationstask direkt.
• Jitter & Scheduling-Treue: Die Alive-Überwachung ist hochgradig empfindlich gegenüber Perioden-Jitter der WdgM_MainFunction() sowie der SE-Tasks. Toleranzschwellen (WdgMMinMargin, WdgMMaxMargin) müssen im ARXML passend zur OS-Task-Aktivierung und Watchdog-Manager-Periodizität ausgelegt werden, um Fehlauslösungen (false positives) zu verhindern.
• Modus-Umschaltung (WdgMMode): Im laufenden Betrieb können Überwachungskonfigurationen (welche SEs aktiv sind, welche Checkpoints gelten) über Watchdog-Modi gewechselt werden. Vor dem Auswerten lokaler Zustände muss die Gültigkeit der SE im aktuellen Modus sichergestellt sein.