CAN Interface (CanIf)

CanIf ist die hardwareunabhängige Schicht zwischen CAN-Treibern bzw. Transceivern und den oberen Kommunikationsmodulen. Es bildet Sendeaufträge auf Can_Write() ab, puffert bei belegter Hardware und leitet Bestätigungen sowie gefilterte Empfänge an konfigurierte Callbacks weiter [SWS_CANIF_00318]. Controller- und Transceivermodi steuert es im Auftrag von CanSm und meldet BusOff und Moduswechsel zurück. PDU-Kanalmodi schalten Sende- und Empfangspfad getrennt. Gesendet wird nur, wenn der Controller in CAN_CS_STARTED und der Sendepfad freigegeben ist [SWS_CANIF_00317].

mehr ›

Das CAN Interface (CanIf) übernimmt alle hardwareunabhängigen Aufgaben der CAN-Kommunikation. Dazu gehören Sendeaufträge, Bestätigungen, Empfangsindikationen, Fehlermeldungen sowie Start und Stopp von CAN-Controllern SWS CanIf S. 13. Auf Hardwarepuffer greift CanIf nur über CanDrv-Dienste zu [SWS_CANIF_00023]. Controller und Transceiver mehrerer Treiber spricht es über abstrakte IDs an [SWS_CANIF_00653]. Welche Callbacks in PduR, CanNm, CanTp, CanSm oder EcuM aufgerufen werden, legt die Konfiguration fest [SWS_CANIF_00011] [SWS_CANIF_00724].

Kontextdiagramm: CanIf zwischen oberen Kommunikationsmodulen, Modusverwaltung und den Treibern für Controller und Transceiver. Quellen: [SWS_CANIF_00012], [SWS_CANIF_00358], SWS CanIf S. 21

EcuM initialisiert CanIf mit CanIf_Init(). Danach steht jeder Kanal auf CANIF_OFFLINE [SWS_CANIF_00864], und bis dahin lehnen die Dienste mit E_NOT_OK ab [SWS_CANIF_00661]. Der Controllerstart über CanIf_SetControllerMode() läuft asynchron. Den Abschluss meldet CanIf_ControllerModeIndication(), die CanIf an CanSm weitergibt [SWS_CANIF_00003] [SWS_CANIF_00711]. Erst danach nimmt CanIf_SetPduMode() Anforderungen an [SWS_CANIF_00874]. Die PDU-Kanalmodi schalten Sende- und Empfangspfad getrennt. Controllerereignisse wie SLEEP, STOPPED oder BusOff setzen sie zwangsweise [SWS_CANIF_00865] [SWS_CANIF_00866].

Zustandsdiagramm: Die vier PDU-Kanalmodi und ihre Übergänge durch CanIf_SetPduMode() und Controllerereignisse. Quellen: [SWS_CANIF_00137], [SWS_CANIF_00866], SWS CanIf Abb. 7.8 S. 61

Beim Senden ruft CanIf_Transmit() Can_Write() auf [SWS_CANIF_00318]. Ist die Hardware belegt, puffert CanIf die L-PDU, sofern ein Puffer konfiguriert ist [SWS_CANIF_00381]. Bei der nächsten Bestätigung sendet es den Eintrag mit der höchsten Priorität nach [SWS_CANIF_00668]. Empfangene L-PDUs durchlaufen Software-Filter und Längenprüfung, bevor CanIf sie an <User_RxIndication> weiterleitet [SWS_CANIF_00389] [SWS_CANIF_00056].

Im Fehlerfall setzt ein BusOff den Kanal auf CANIF_TX_OFFLINE und wird an CanSm gemeldet [SWS_CANIF_00724]. Beim Stopp eines Controllers bestätigt CanIf alle ausstehenden Sendeaufträge mit E_NOT_OK [SWS_CANIF_00739]. Parameter- und Laufzeitfehler gehen an den DET [SWS_CANIF_91006] [SWS_CANIF_91007].

mehr ›

Rolle: hardwareunabhängige Drehscheibe zwischen CAN-Treibern und Kommunikationsstack

Das CAN Interface (CanIf) übernimmt alle hardwareunabhängigen Aufgaben der CAN-Kommunikation einer ECU. Die darunterliegenden CAN-Treiber kümmern sich nur noch um ihre konkrete Hardware. CanIf bearbeitet Sendeaufträge, Sendebestätigungen, Empfangsindikationen und Fehlermeldungen und startet bzw. stoppt CAN-Controller SWS CanIf S. 13. Auf Hardwarepuffer greift es ausschließlich über Dienste des CanDrv zu [SWS_CANIF_00023]. Steuerdienste arbeiten mit einer abstrakten ControllerId, die die Controller aller CanDrv-Instanzen ab 0 durchnummeriert [SWS_CANIF_00653]. Für Transceiver gilt dasselbe mit der TransceiverId [SWS_CANIF_00655].

Nach unten fasst CanIf die APIs mehrerer CanTrcv-Treiber zu einer einheitlichen Schnittstelle zusammen, enthält aber selbst keine Transceiverlogik SWS CanIf S. 21. Auch bei mehreren CanDrvs gibt es jeden Callback nur einmal. CanIf erkennt den aufrufenden Treiber an der ControllerId in Can_HwType SWS CanIf S. 68.

Nach oben ruft CanIf konfigurierbare Callbacks wie <User_TxConfirmation> und <User_RxIndication> auf [SWS_CANIF_00011] [SWS_CANIF_00012]. Die Konfiguration legt den konkreten Empfänger fest, etwa PduR_CanIfRxIndication [SWS_CANIF_00442] oder CanTp_TxConfirmation [SWS_CANIF_00550]. BusOff und Moduswechsel meldet CanIf an CanSm oder ein CDD [SWS_CANIF_00724] [SWS_CANIF_00711]. Wake-up-Validierungen gehen an EcuM [SWS_CANIF_00563].

Kontextdiagramm: CanIf vermittelt zwischen den oberen Kommunikationsmodulen, der Modusverwaltung (CanSm, EcuM) und den Treibern für CAN-Controller und Transceiver. Fehler-, Sicherheits- und Mirroring-Meldungen gehen an DET, IdsM und Mirror. Quellen: [SWS_CANIF_00011], [SWS_CANIF_00724], [SWS_CANIF_00358], [SWS_CANIF_00905], [SWS_CANIF_00913], SWS CanIf S. 13

Der Funktionsumfang hängt stark von der Konfiguration ab. CanIf_Init() liest aus den Konfigurationscontainern unter anderem die Zahl der Controller und die Zuordnung der HTHs/HRHs SWS CanIf S. 22. HTH und HRH sind Handles auf logische Sende- bzw. Empfangsobjekte [SWS_CANIF_00291] [SWS_CANIF_00292]. Viele Dienste lassen sich per Pre-Compile-Schalter abwählen, z. B. CanIf_ReadRxPduData() [SWS_CANIF_00330] oder CanIf_SetBaudrate() [SWS_CANIF_00871]. Ist für einen nicht verpflichtenden Callback kein Name konfiguriert, entfällt der Aufruf SWS CanIf S. 133. <User_ControllerBusOff> muss dagegen immer konfiguriert sein [SWS_CANIF_00524].

Von der Initialisierung zum gestarteten Controller

EcuM ruft CanIf_Init() auf [SWS_CANIF_00001]. Dabei initialisiert CanIf Variablen, Flags und Puffer [SWS_CANIF_00085] sowie alle Sende-L-PDU-Puffer [SWS_CANIF_00387]. Jeder Kanal startet in CANIF_OFFLINE [SWS_CANIF_00864]. Die Controller bleiben danach im Modus STOPPED, in dem weder gesendet noch empfangen wird. CanDrv und CanTrcv initialisiert EcuM separat SWS CanIf S. 40. Vor der Initialisierung liefern alle Dienste außer CanIf_Init() und CanIf_GetVersionInfo() E_NOT_OK [SWS_CANIF_00661]. Wer CanIf_DeInit() [SWS_CANIF_91002] aufruft, muss sicherstellen, dass keine Übertragungen mehr laufen SWS CanIf S. 81.

Der Controllerstart läuft asynchron. CanIf_SetControllerMode() [SWS_CANIF_00003] ruft Can_SetControllerMode() auf [SWS_CANIF_00308]. Den vollzogenen Wechsel meldet der Treiber später mit CanIf_ControllerModeIndication() [SWS_CANIF_00699], und CanIf reicht die Meldung an CanSm weiter [SWS_CANIF_00711]. Im Polling-Betrieb erkennt Can_MainFunction_Mode() den Wechsel SWS CanIf S. 152. Erst in CAN_CS_STARTED nimmt CanIf_SetPduMode() Anforderungen an [SWS_CANIF_00874].

Sequenzdiagramm: Die Startanforderung wird sofort quittiert, der Moduswechsel aber erst später indiziert. Danach können die PDU-Pfade freigeschaltet werden. Quellen: [SWS_CANIF_00308], [SWS_CANIF_00711], [SWS_CANIF_00874], SWS CanIf S. 156

PDU-Kanalmodi: Sende- und Empfangspfad getrennt schalten

Jeder Kanal eines Controllers hat einen Modus vom Typ CanIf_PduModeType [SWS_CANIF_00137]. Obere Schichten setzen ihn mit CanIf_SetPduMode() und lesen ihn mit CanIf_GetPduMode() [SWS_CANIF_00008] [SWS_CANIF_00009]. Die Modi im Einzelnen SWS CanIf S. 58:

• CANIF_OFFLINE: Sendeaufträge werden mit E_NOT_OK abgewiesen und die Puffer geleert. Indikationen und Bestätigungen werden unterdrückt [SWS_CANIF_00073].
• CANIF_TX_OFFLINE: Nur der Sendepfad ist gesperrt, der Empfang bleibt aktiv [SWS_CANIF_00489].
• CANIF_TX_OFFLINE_ACTIVE: Sendeaufträge werden sofort bestätigt, ohne an CanDrv weitergegeben zu werden [SWS_CANIF_00072].
• CANIF_ONLINE: Senden und Empfangen sind voll aktiv [SWS_CANIF_00075].

Controllerereignisse setzen den Kanalmodus zwangsweise. CAN_CS_SLEEP führt zu CANIF_OFFLINE [SWS_CANIF_00865]. CAN_CS_STOPPED und BusOff führen zu CANIF_TX_OFFLINE [SWS_CANIF_00866].

Zustandsdiagramm: Die vier PDU-Kanalmodi mit Übergängen durch CanIf_SetPduMode() und durch Controllerereignisse. Die drei eingeschränkten Modi sind wie in der Spezifikation zu einem Oberzustand zusammengefasst. Quellen: [SWS_CANIF_00864], [SWS_CANIF_00865], [SWS_CANIF_00866], [SWS_CANIF_00874], SWS CanIf Abb. 7.8 S. 61

Sendepfad: CanIf_Transmit, Pufferung und Trigger Transmit

CanIf_Transmit() [SWS_CANIF_00005] ermittelt das HTH und ruft Can_Write() auf. Das übergebene swPduHandle kommt später in CanIf_TxConfirmation() zurück [SWS_CANIF_00318]. Vorher setzt CanIf die beiden höchstwertigen Bits der CanId [SWS_CANIF_00243]. Liefert Can_Write() E_OK, gilt das auch für den Sendeauftrag [SWS_CANIF_00162].

Angenommen wird ein Auftrag nur unter diesen Bedingungen:

• Der Controller ist gestartet und der Sendepfad ist online oder offline active [SWS_CANIF_00317].
• Bei aktivem PnTxFilter passieren nur CanIfTxPduPnFilterPdus [SWS_CANIF_00750].
• Überlange Daten werden mit CanIfTxPduTruncation gekürzt [SWS_CANIF_00894], sonst abgewiesen [SWS_CANIF_00900].

Neuere Dokumentstellen nennen zusätzlich CanXL_Write() SWS CanIf S. 87. Für R20-11 ist nur Can_Write() normativ.

Aktivitätsdiagramm: So entscheidet CanIf_Transmit() zwischen Ablehnung, simulierter Bestätigung, direktem Senden und Pufferung. Interpretation: Die Reihenfolge der Prüfungen ist zur Lesbarkeit gewählt. Quellen: [SWS_CANIF_00317], [SWS_CANIF_00382], [SWS_CANIF_00072], [SWS_CANIF_00381], [SWS_CANIF_00837], SWS CanIf Abb. 7.5 S. 51

Meldet Can_Write() CAN_BUSY und ist CanIfPublicTxBuffering aktiv [SWS_CANIF_00063], versucht CanIf, die L-PDU zu puffern [SWS_CANIF_00381]. Das setzt eine Puffergröße größer null voraus [SWS_CANIF_00835]. Liegt dieselbe L-PDU schon im Puffer, wird sie überschrieben [SWS_CANIF_00068]. Ist der Puffer voll, wird eine neue L-PDU mit E_NOT_OK abgewiesen [SWS_CANIF_00837]. Eine L-PDU liegt immer nur an einer Stelle: im Hardwareobjekt oder im CanIf-Puffer SWS CanIf S. 43.

Bei CanIf_TxConfirmation() [SWS_CANIF_00007] benachrichtigt CanIf den zuständigen Nutzer über <User_TxConfirmation> mit E_OK [SWS_CANIF_00383]. Im selben Aufruf prüft es die Puffer des frei gewordenen HTH [SWS_CANIF_00386]. Den wartenden Eintrag mit der höchsten Priorität übergibt es an Can_Write() [SWS_CANIF_00668] [SWS_CANIF_00070]. Bei E_OK entfernt es den Eintrag sofort aus dem Puffer [SWS_CANIF_00183]. Neuere Dokumentstellen nennen den Callback LSduR_CanIfTxConfirmation() SWS CanIf S. 157. In R20-11 gilt <User_TxConfirmation>.

Sequenzdiagramm: Bei belegter Hardware wird die L-PDU gepuffert. Die Bestätigung eines früheren Auftrags stößt dann das Nachsenden aus dem Puffer an. Quellen: [SWS_CANIF_00381], [SWS_CANIF_00386], [SWS_CANIF_00668], [SWS_CANIF_00183], SWS CanIf S. 138, SWS CanIf S. 143

Bei Triggered Transmission übergibt der Nutzer keine Daten, sondern einen NULL-SduDataPtr [SWS_CANIF_00882]. Ist die Hardware frei, holt der Treiber die Daten über CanIf_TriggerTransmit() [SWS_CANIF_00883]. CanIf leitet den Aufruf an <User_TriggerTransmit> weiter und gibt dessen Ergebnis zurück [SWS_CANIF_00885]. Ist die Hardware belegt, puffert CanIf nur den Transmit Request [SWS_CANIF_00881]. Die CanId dynamischer L-PDUs lässt sich mit CanIf_SetDynamicTxId() ändern [SWS_CANIF_00189]. Alternativ stammt sie aus den MetaData [SWS_CANIF_00855] SWS CanIf S. 34.

Sequenzdiagramm: Bei Trigger Transmit holt der Treiber die Daten erst dann beim Nutzer ab, wenn das Hardwareobjekt frei ist. Quellen: [SWS_CANIF_00882], [SWS_CANIF_00885], [SWS_CANIF_00881], SWS CanIf Abb. 9.6 S. 137

Empfangspfad: Filtern, Länge prüfen, weiterleiten

Nach einem Empfang ruft der Treiber CanIf_RxIndication() mit Mailbox und Daten auf [SWS_CANIF_00006]. Die Verarbeitung läuft in drei Stufen:

• Software-Filter: Für BasicCAN-HRHs filtert CanIf per Software [SWS_CANIF_00663] SWS CanIf S. 39. Eine Ablehnung beendet die Verarbeitung [SWS_CANIF_00389].
• Längenprüfung: Sie folgt, falls konfiguriert [SWS_CANIF_00390], und akzeptiert mindestens die konfigurierte Länge [SWS_CANIF_00026].
• Weiterleitung: Akzeptierte L-PDUs gehen an den konfigurierten <User_RxIndication> [SWS_CANIF_00056] [SWS_CANIF_00135]. Bei dynamischen L-SDUs landet die CanId in CAN_ID_32 [SWS_CANIF_00848].

Aktivitätsdiagramm: Software-Filter und Längenprüfung entscheiden, ob eine empfangene L-PDU indiziert wird. Konfigurationsabhängige Nebenwirkungen sind parallel dargestellt. Quellen: [SWS_CANIF_00421], [SWS_CANIF_00389], [SWS_CANIF_00168], [SWS_CANIF_00199], [SWS_CANIF_00392], SWS CanIf Abb. 7.6 S. 51

Ergänzend bietet CanIf Abfragedienste. CanIf_ReadRxPduData() liest Daten aus einem eigenen Empfangspuffer [SWS_CANIF_00194] [SWS_CANIF_00198], ist aber nicht für Bereichsempfang gedacht [SWS_CANIF_00329]. CanIf_ReadTxNotifStatus() und CanIf_ReadRxNotifStatus() setzen den Status beim Lesen zurück [SWS_CANIF_00393] [SWS_CANIF_00394]. Dieses „read-and-consume“ sichert zu, dass seit dem letzten Aufruf mindestens ein Ereignis eintraf SWS CanIf S. 55. CanIf_GetTxConfirmationState() fasst die Bestätigungen eines ganzen Controllers zusammen [SWS_CANIF_00734].

Transceiver, Wake-up und Partial Networking

Die Transceiver-Dienste leitet CanIf direkt an den CanTrcv-Treiber weiter. CanIf_SetTrcvMode() ruft CanTrcv_SetOpMode() [SWS_CANIF_00358], CanIf_GetTrcvMode() ruft CanTrcv_GetOpMode() [SWS_CANIF_00363]. Moduswechsel des Transceivers gibt CanIf an CanSm weiter [SWS_CANIF_00712].

Für den Wake-up fragt CanIf_CheckWakeup() die Controller und Transceiver nach der Wake-up-Quelle ab [SWS_CANIF_00395] SWS CanIf S. 56. Zur Validierung speichert CanIf den ersten gültigen Empfang eines gestarteten Controllers [SWS_CANIF_00286]. CanIf_CheckValidation() meldet ihn dann über <User_ValidateWakeupEvent> [SWS_CANIF_00179].

Ist Partial Networking aktiv, legt ein PnTxFilter je Controller eine zusätzliche Schicht über die Kanalmodi [SWS_CANIF_00747]. Er wird bei CAN_CS_SLEEP aktiviert [SWS_CANIF_00749] und mit der ersten Bestätigung oder Indikation wieder deaktiviert [SWS_CANIF_00751] [SWS_CANIF_00896] SWS CanIf S. 70.

Verhalten im Fehlerfall

BusOff: Der Treiber meldet den Fehler mit CanIf_ControllerBusOff() [SWS_CANIF_00218]. CanIf setzt den Kanal daraufhin auf CANIF_TX_OFFLINE [SWS_CANIF_00866] und meldet den BusOff an CanSm [SWS_CANIF_00724] SWS CanIf Abb. 9.11 S. 147. Die Wiederherstellung steuert CanSm über CanIf_SetControllerMode() SWS CanIf S. 160.

Sequenzdiagramm: Ablauf von der BusOff-Erkennung über die Meldung an CanSm bis zum Neustart des Controllers. Quellen: [SWS_CANIF_00218], [SWS_CANIF_00866], [SWS_CANIF_00724], [SWS_CANIF_00918], SWS CanIf S. 154, SWS CanIf S. 160

Controller gestoppt: Beim Eintritt in CAN_CS_STOPPED leert CanIf die Sendepuffer [SWS_CANIF_00485]. Alle ausstehenden Sendeaufträge bestätigt es mit E_NOT_OK [SWS_CANIF_00739]. So erhält jede angenommene PDU eine Bestätigung, positiv oder negativ SWS CanIf S. 54.

Fehlermeldungen: Ungültige Parameter meldet CanIf als Entwicklungsfehler, z. B. CANIF_E_PARAM_CONTROLLERID [SWS_CANIF_00311] [SWS_CANIF_91006]. Laufzeitfehler sind unter anderem CANIF_E_INVALID_DATA_LENGTH [SWS_CANIF_00168] und CANIF_E_STOPPED [SWS_CANIF_00382] [SWS_CANIF_91007]. Ein verlorener Sendeauftrag zeigt sich nur am Rückgabewert oder an der fehlenden Bestätigung Error Description S. 22. Sicherheitsereignisse wie CANIF_SEV_ERRORSTATE_PASSIVE meldet CanIf an den IdsM [SWS_CANIF_00913] [SWS_CANIF_00917].

Weiterführende Detailbelege

• Initialisierung und Lebenszyklus: [SWS_CANIF_00001], [SWS_CANIF_00661], SWS CanIf S. 40
• Sendepfad und Pufferung: [SWS_CANIF_00318], [SWS_CANIF_00836], SWS CanIf S. 46
• Empfangskette: [SWS_CANIF_00415], SWS CanIf S. 50
• Konfigurierbare Callbacks: [SWS_CANIF_00532], SWS CanIf S. 133