Figure 9.11: BusOff notification

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm.
• Funktionale Einordnung: AUTOSAR Classic Platform (CP), Kommunikationsstack (CAN-Subsystem). Spezifiziert die synchrone Benachrichtigungskette und Fehlerbehandlung bei Detektion eines CAN Bus-Off-Zustands (Transmit Error Counter TEC > 255) von der Hardware-Peripherie über den MCAL-Treiber (Can) und die Abstraktionsschicht (CanIf) bis zur zuständigen oberen Schicht (CanIf_User_Cbk, primär CanSM).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • «Peripheral» CanController: Physikalische CAN-Hardware / On-Chip-Controller.
  • «module» Can: Hardwarenaher MCAL-Treiber (CAN Driver).
  • «module» CanIf: Hardware-unabhängige CAN-Schnittstelle (CAN Interface).
  • CanIf_User_Cbk: Obere Schicht / Anwender-Callback (normativ: CanSM_ControllerBusOff, alternativ CDD).
• APIs & Interaktionen:
  • BusOff Detection(): Hardware-Signalierung (Interrupt oder Status-Register-Polling).
  • Set CAN Controller to STOPPED mode, if necessary(): Treiber-Registerzugriff zur Erzwingung des Zustands CAN_CS_STOPPED.
  • CanIf_ControllerBusOff(uint8 ControllerId): Normative Treiber-zu-Interface-Callback-API ([SWS_CANIF_00218]).
  • Change to CAN_CS_STOPPED(): Interne Modusaktualisierung im CanIf.
  • Reset transmit queue(): Pufferverwaltungs-Aktion im CanIf.
  • <User_ControllerBusOff>(uint8 ControllerId): Konfigurierbarer Callback ([SWS_CANIF_00014], typischerweise CanSM_ControllerBusOff).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: CanController wechselt hardwaredenseitig in den Bus-Off-Zustand. Auslösung von BusOff Detection() an das Modul Can (via Bus-Off-ISR oder Polling-Zyklus in Can_MainFunction_BusOff()).
2. Hardware-Stopp: Modul Can prüft den Controller-Status und setzt diesen bei Bedarf aktiv in CAN_CS_STOPPED (Set CAN Controller to STOPPED mode, if necessary()), um jegliche weitere Busaktivität sicher zu unterbinden.
3. Notification-Kaskade: Can ruft synchron CanIf_ControllerBusOff(ControllerId) auf.
4. Zustandsübergang & Buffer-Flush:
   • CanIf setzt den internen Controller-Zustand auf CAN_CS_STOPPED.
   • CanIf leert synchron die softwareseitigen Sende-Warteschlangen (Reset transmit queue()). Verhindert das Re-Transmittieren veralteter L-PDUs nach Re-Initialisierung/Neustart des Controllers.
5. Upper-Layer-Benachrichtigung: CanIf delegiert das Ereignis synchron an den konfigurierten Callback <User_ControllerBusOff>(ControllerId).
6. Return-Pfad: Synchroner Rücksprung über alle Schichten bis zur Terminierung des ISR- bzw. Polling-Kontexts.

4. Normative Relevanz & Entwickler-Hinweise

• Ausführungskontext (ISR vs. Task): Ist CanBusoffProcessing auf INTERRUPT konfiguriert, wird die gesamte Benachrichtigungskette (Can → CanIf → CanSM) im Interrupt-Kontext ausgeführt. <User_ControllerBusOff> darf daher weder blockieren noch zeitkritische Operationen ausführen. Bei POLLING läuft die Kaskade im Kontext von Can_MainFunction_BusOff().
• Bus-Off-Recovery-Trigger: Der Callback startet in der CanSM den normativen Bus-Off-Recovery-Zustandsautomaten (BOR-Algorithmus mit schnellen/langsamen Recovery-Timern T_BOR_1 / T_BOR_2).
• Queue-Verhalten & Datenverlust: Durch Reset transmit queue() werden alle im CanIf gepufferten Tx-PDUs unwiderruflich verworfen (CanIfPublicTxBuffering == TRUE). Höhere Layer (PduR, Com) erhalten keine explizite Cancellation-Benachrichtigung und müssen Timeouts/Re-Transmissionen über Com-Deadline-Monitoring abfangen.
• Konfigurationsparameter:
  • CanIfDispatchUserCtrlBusOffUL: Konfiguration des Zielmoduls (Standard: CAN_SM, alternativ CDD).
  • CanIfDispatchUserCtrlBusOffName: Spezifischer Funktionsbezeichner des Callbacks.