Figure 9.2: Data exchange between watchdog driver and hardware

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Sequenzdiagramm ohne UML-Kopfrahmen.
• Architektur-Kontext: AUTOSAR Classic Platform (System Services / MCAL), Spezifikationsstand R21-11.
• Funktionale Einordnung: Asynchrone Trigger-Architektur zur Watchdog-Bedienung. Die Festlegung des Überwachungszeitfensters durch den Watchdog Manager (WdgM) ist zeitlich entkoppelt von der zyklischen Hardware-Bedienung, welche über Timer-Interrupts gesteuert wird.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • «module» WdgM: Watchdog Manager zur Überwachung der Programmausführung.
  • «module» WdgIf: Watchdog Interface zur hardwareunabhängigen Weiterleitung an die Treiberinstanz.
  • «module» Wdg: Watchdog Driver (MCAL) zur Ausführung der Servicing-Schreibzyklen.
  • Timer Hardware: Hardware-Zeitgeber als Interrupt-Quelle für die zyklische Triggerung.
  • «Peripheral» Watchdog Hardware: Physikalische Watchdog-Einheit.
• Schnittstellen & Interaktionen:
  • WdgIf_SetTriggerCondition(uint8, uint16): API-Aufruf vom WdgM an WdgIf mit Geräteindex (uint8) und Timeout (uint16).
  • Wdg_SetTriggerCondition(uint16): API-Aufruf vom WdgIf an Wdg mit Timeout (uint16).
  • Wdg_SetTriggerCondition() / WdgIf_SetTriggerCondition(): Synchrone Rückgabepfade.
  • interrupt(): Periodischer Hardware-Interrupt vom Timer Hardware an Wdg.
  • trigger WDG hardware(): Auslösen der Hardware-Bedienung durch Wdg.
  • update activation code(): Rückmeldung des nächsten Aktivierungscodes an den Treiber.
• Zusätzliche Notationselemente:
  • Notizfeld Hint: Access to external Wdg hardware will be done via peripheral drivers as SPI or DIO. zur Verdeutlichung indirekter Peripheriezugriffe bei externen Watchdogs.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm stellt die zeitliche Entkopplung zwischen Bedingungsfestlegung und hardwareseitiger Bedienung dar:

1. Erste Bedingungsfestlegung:
   • WdgM ruft synchron WdgIf_SetTriggerCondition(uint8, uint16) an WdgIf auf.
   • WdgIf delegiert den Aufruf per Wdg_SetTriggerCondition(uint16) an Wdg.
   • Der Aufruf kehrt über synchrone Quittierungen Wdg_SetTriggerCondition() und WdgIf_SetTriggerCondition() an WdgM zurück.
2. Zyklische Triggerung via Timer-Interrupt:
   • Timer Hardware sendet ein asynchrones Signal interrupt() an Wdg.
   • Wdg bedient im Interrupt-Kontext die Watchdog-Hardware per trigger WDG hardware().
   • Watchdog Hardware antwortet mit update activation code().
   • Ein weiterer interrupt() von Timer Hardware löst eine erneute Hardware-Bedienung (trigger WDG hardware()) und anschließendes update activation code() aus.
3. Zweite Bedingungsfestlegung:
   • WdgM setzt erneut die Bedingung über WdgIf_SetTriggerCondition(uint8, uint16) an WdgIf und Wdg_SetTriggerCondition(uint16) an Wdg.
   • Quittierung erfolgt synchron per Wdg_SetTriggerCondition() und WdgIf_SetTriggerCondition().
4. Folgende Interrupt-Triggerung:
   • Timer Hardware löst erneut interrupt() an Wdg aus.
   • Wdg bedient die Peripherie über trigger WDG hardware() und empfängt update activation code().

4. Normative Relevanz & Entwickler-Hinweise

• Architektur und Zeitsteuerung:
  • Die Hardware-Bedienung erfolgt entkoppelt vom Aufruf des Watchdog Managers in einer durch Timer Hardware getriebenen Interrupt Service Routine.
  • Wdg_SetTriggerCondition parametriert ein Timeout-Intervall (uint16). Der Treiber zählt dieses Intervall bei jedem Timer-Interrupt herunter und bedient die Watchdog-Hardware nur, solange die Bedingung gültig (Wert > 0) ist.
• Peripherie-Anbindung:
  • Für externe Watchdog-Bausteine erfolgt der Hardwarezugriff (trigger WDG hardware()) nicht direkt über Prozessorregister, sondern über die entsprechenden Bus- oder Port-Treiber (SPI oder DIO).
• Datentypen und Schnittstellen:
  • Das Interface adressiert Kanäle über uint8 (DeviceIndex) und übergibt Zeitwerte als uint16.