Figure 3: Data exchange between watchdog driver and hardware

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (sd Data Exchange w. watchdog hardware).
• Architektur-Kontext: AUTOSAR Classic Platform (MCAL / System Services), Spezifikationsstand R2.1.20.
• Funktionale Einordnung: Interaktionsmuster zwischen der Abstraktionsschicht (Watchdog Interface, WdgIf), dem konkreten Hardware-Treiber (Watchdog Driver, Wdg) und der physikalischen Watchdog-Peripherie (Watchdog Hardware, intern/On-Chip oder extern via SPI/DIO). Es visualisiert den periodischen Refresh-Mechanismus bei hardwareseitig wechselnden Ansteuerungssequenzen (Challenge-Response-, Token- oder Fenster-Watchdogs).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • Watchdog Interface (WdgIf): Obere Abstraktionsschicht (BSW), zuständig für das Routing der Trigger-Aufrufe an den spezifischen WDG-Treiberkanal.
  • Watchdog Driver (Wdg): MCAL-Treiber (konform zu AUTOSAR_SWS_WatchdogDriver), kapselt die registerspezifischen Schreib-/Lesezugriffe auf die Ziel-Hardware.
  • Watchdog Hardware: Physikalische Überwachungsschaltung (Microcontroller-interner Watchdog-Timer oder externes Watchdog-ASIC/PMIC).
• Schnittstellen & Interaktionen:
  • Wdg_Trigger(void): Synchrone C-Funktionsschnittstelle (API) vom WdgIf zum Wdg.
  • trigger WDG hardware: Hardwarenahe Schreiboperation (Memory-Mapped I/O Registerzugriff oder SPI-Kommando) zur Rücksetzung des Überwachungszählers.
  • update activation code: Hardware-Statusaktualisierung bzw. Bereitstellung eines veränderten Aktivierungscodes (z. B. LFSR-Folgecode, invertierter Toggle-Wert, Challenge-Token oder Next-Window-Sequenz) von der Hardware an den Treiber.
• Beziehungen & Stereotypen:
  • Direkte 1:1-Steuerungsbeziehung pro Treiberinstanz.
  • Schichtenbindung: WdgIf operiert hardwareunabhängig; Wdg operiert streng hardwarespezifisch und hardwarenah.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm stellt zwei aufeinanderfolgende Trigger-Zyklen dar:

1. Zyklus 1 – Trigger-Aufruf:
   • Watchdog Interface ruft synchron Wdg_Trigger(void) auf.
   • Watchdog Driver bedient die Hardware über trigger WDG hardware unter Verwendung des aktuell gültigen Aktivierungscodes.
   • Der Aufruf Wdg_Trigger(void) kehrt synchron per return zum Watchdog Interface zurück.
2. Zyklus 1 – Code-Aktualisierung (Hardware-Feedback):
   • Nach erfolgtem Trigger modifiziert die Hardware ihren Zustand und signalisiert/aktualisiert einen neuen Aktivierungswert (update activation code), der asynchron oder beim nächsten Registerzugriff durch den Treiber erfasst/abgeglichen wird.
3. Zyklus 2 – Folgetrigger mit modifiziertem Code:
   • Watchdog Interface setzt den nächsten periodischen Aufruf Wdg_Trigger(void) ab.
   • Watchdog Driver führt trigger WDG hardware mit dem im vorherigen Schritt aktualisierten Aktivierungscode aus.
   • Funktionsrückkehr via return.
   • Die Hardware generiert wiederum die nächste Iteration des Codes (update activation code).

4. Normative Relevanz & Entwickler-Hinweise

• Treiber-Implementierung (MCAL):
  • Der Treiber darf keine statischen Refresh-Konstanten „blind“ schreiben, sofern die Hardware dynamische Token/Codes erwartet. Der Treiber muss interne Zustandsvariablen zur Verfolgung des Codes verwalten oder Statusregister vor/nach dem Schreibzugriff auslesen.
  • Reentrancy: Wdg_Trigger() ist non-reentrant. Gleichzeitige Aufrufe aus verschiedenen Task-Kontexten oder ISRs führen zu Race Conditions bezüglich des activation code und lösen unweigerlich einen Watchdog-Reset aus.
• API-Einschränkungen & Versionskontext:
  • Die Schnittstelle Wdg_Trigger(void) entspricht dem frühen AUTOSAR-Standard (R2.1.20). In späteren AUTOSAR-Releases (R4.x+) wurde dieses synchrone Triggering abgelöst durch das Konzept Wdg_SetTriggerCondition(Timeout) in Kombination mit der internen zyklischen Treiberfunktion Wdg_MainFunction(), um die Trennung von logischem Software-Monitoring (WdgM) und physikalischer Hardware-Bedienung zu schärfen.
• Echtzeitanforderungen:
  • Wdg_Trigger(void) muss strikt deterministisch innerhalb des zulässigen Hardware-Fensters (Open Window) ausgeführt werden. Blockierende SPI-Transfers bei externen Watchdogs müssen timing-optimiert abgewickelt werden.