CAN Transport Layer (CanTp)

Der CAN Transport Layer zerlegt Nachrichten, die nicht in einen CAN-Frame passen, steuert den Datenfluss per Flow Control und setzt empfangene Segmente nach ISO 15765-2 wieder zusammen [SWS_CanTp_00033]. Er sitzt zwischen PduR und CanIf, hat keinen eigenen Nutzdatenpuffer und kopiert Sende- und Empfangsdaten segmentweise über die Copy-Dienste der oberen Schicht [SWS_CanTp_00298]. Jede angenommene Übertragung schließt er mit einer Meldung an die obere Schicht ab, erfolgreich mit E_OK, bei Timeout oder Abbruch mit E_NOT_OK. Das alles setzt CanTp_Init voraus; die Timeouts überwacht die zyklische MainFunction.

mehr ›

CanTp ist der CAN Transport Layer. Es zerlegt lange Nachrichten in CAN-Frames, steuert den Datenfluss und setzt empfangene Segmente wieder zusammen; dabei folgt es ISO 15765-2, soweit die Spezifikation nichts anderes regelt [SWS_CanTp_00033]. Das Modul sitzt zwischen PduR und CanIf und hat keinen eigenen Nutzdatenpuffer. Die Daten kopiert es segmentweise über die Copy-Dienste der oberen Schicht [SWS_CanTp_00298] [SWS_CanTp_00216].

Kontextdiagramm: Die Schnittstellen von CanTp zu PduR, CanIf, Modusmanagement, Scheduler und DET. Quellen: [SWS_CanTp_00216], SWS CanTp S. 17

Nach dem Einschalten ist CanTp in CANTP_OFF [SWS_CanTp_00168]. CanTp_Init mit CanTp_ConfigType [SWS_CanTp_00208] versetzt alle Verbindungen in den Ruhezustand [SWS_CanTp_00030]; danach gilt CANTP_ON [SWS_CanTp_00170]. CanTp_Shutdown schließt alle Verbindungen, ohne jemanden zu benachrichtigen [SWS_CanTp_00202] [SWS_CanTp_00200]. Die Verbindungskanäle arbeiten unabhängig voneinander mit eigenen Timern [SWS_CanTp_00122]. Ist ein Sendekanal belegt, weist CanTp neue Aufträge mit E_NOT_OK ab [SWS_CanTp_00123].

Beim Senden wertet CanTp_Transmit nur die Länge (und gegebenenfalls MetaData) aus [SWS_CanTp_00225]. Je nach Länge folgt ein SF oder eine segmentierte Sitzung [SWS_CanTp_00232]. Für jedes Segment holt CanTp die Daten mit PduR_CanTpCopyTxData [SWS_CanTp_00086] und wartet nach FF und jedem Block unter N_Bs auf Flow Control [SWS_CanTp_00315]. Interpretation: Der Aufruf meldet nur die Annahme; das Ende des Transfers kommt asynchron über PduR_CanTpTxConfirmation [SWS_CanTp_00176] [SWS_CanTp_00204]. Frage (offen)

Beim Empfang fordert CanTp zuerst mit PduR_CanTpStartOfReception einen Puffer an [SWS_CanTp_00079]. Danach kopiert es jeden CF mit PduR_CanTpCopyRxData [SWS_CanTp_00269]. Ist der Puffer knapp, fragt CanTp ihn in jeder MainFunction erneut ab und sendet höchstens WFTmax FC(WAIT) [SWS_CanTp_00222] [SWS_CanTp_00223]. Am Ende steht PduR_CanTpRxIndication [SWS_CanTp_00084]. Die Timeouts überwacht die zyklische CanTp_MainFunction [SWS_CanTp_00164].

Sequenzdiagramm: Segmentierter Empfang mit Pufferaushandlung und Flow Control CTS/WAIT. Quellen: [SWS_CanTp_00269], [SWS_CanTp_00222], SWS CanTp S. 38

Fehler behandelt CanTp auf drei Arten. Entwicklungsfehler meldet es an DET und liefert E_NOT_OK [SWS_CanTp_00294]. Protokollfehler wie Timeouts brechen die Sitzung ab und gehen mit E_NOT_OK an PduR [SWS_CanTp_00205] [SWS_CanTp_00311]. Dasselbe gilt für Abbrüche auf Anforderung über die Cancel-Dienste [SWS_CanTp_00255] [SWS_CanTp_00263]. Für ungültige IDs bei den Cancel-Diensten verlangt R20-11 CANTP_E_PARAM_ID [SWS_CanTp_00254], während neuere Releases andere Codes nennen.

mehr ›

Rolle im CAN-Stack: Transportprotokoll zwischen PduR und CanIf

CanTp ist der CAN Transport Layer. Er zerlegt Nachrichten, die nicht in einen einzelnen CAN-Frame passen, in Segmente, steuert den Datenfluss und setzt empfangene Segmente wieder zusammen (SWS CanTp S. 24, SWS CanTp S. 17). Grundlage ist ISO 15765-2: Jede Empfehlung dieser Norm gilt, sofern die Spezifikation sie nicht ausdrücklich ausschließt [SWS_CanTp_00033]. Segmentierung und Reassemblierung führt CanTp nur im Zustand CANTP_ON aus [SWS_CanTp_00238].

Nach oben stellt CanTp dem PduR folgende Dienste bereit: CanTp_Transmit [SWS_CanTp_00212], CanTp_CancelTransmit [SWS_CanTp_00246] und CanTp_CancelReceive [SWS_CanTp_00257]. Selbst ruft CanTp nach oben PduR_CanTpStartOfReception, PduR_CanTpCopyRxData, PduR_CanTpCopyTxData, PduR_CanTpRxIndication und PduR_CanTpTxConfirmation auf, nach unten CanIf_Transmit [SWS_CanTp_00216]. Die untere Schicht meldet empfangene Frames über CanTp_RxIndication [SWS_CanTp_00078] und Sendebestätigungen über CanTp_TxConfirmation [SWS_CanTp_00076]. Beide Funktionen müssen im Interrupt-Kontext aufrufbar sein [SWS_CanTp_00235] [SWS_CanTp_00236]. Neuere Dokumentstellen nennen als Aufrufer den L-SDU Router (LSduR) (SWS CanTp S. 27). Die Requirements von R20-11 sprechen dagegen vom CAN Interface, etwa [SWS_CanTp_00031] und [SWS_CanTp_00335].

CanTp hat keinen eigenen Nutzdatenpuffer. Sendedaten holt es direkt bei der oberen Schicht ab [SWS_CanTp_00298], empfangene Daten kopiert es unmittelbar in deren Speicher (SWS CanTp S. 35). Daraus ergeben sich Sperrfristen für die obere Schicht (SWS CanTp S. 35):

• Den Sendepuffer hält sie gesperrt, sobald CanTp_Transmit mit E_OK zurückkehrt, bis PduR_CanTpTxConfirmation eintrifft.
• Den Empfangspuffer hält sie gesperrt, sobald sie BUFREQ_OK auf PduR_CanTpStartOfReception geliefert hat, bis PduR_CanTpRxIndication eintrifft.

Kontextdiagramm: CanTp sitzt zwischen PduR und CanIf. Es wird vom Modusmanagement initialisiert, vom Scheduler zyklisch angestoßen und meldet Fehler an DET. Quellen: [SWS_CanTp_00216], [SWS_CanTp_00217], [SWS_CanTp_00164], SWS CanTp S. 17, Mode Management Guide S. 54

Lebenszyklus: CANTP_OFF, CanTp_Init und unabhängige Verbindungskanäle

CanTp kennt die Zustände CANTP_OFF und CANTP_ON [SWS_CanTp_00027]. Nach dem Einschalten ist das Modul in CANTP_OFF [SWS_CanTp_00168]; nur dort darf die Post-Build-Konfiguration aktualisiert werden [SWS_CanTp_00169].

CanTp_Init erhält einen Zeiger auf CanTp_ConfigType [SWS_CanTp_00208] [SWS_CanTp_00340]. Die Funktion initialisiert alle globalen Variablen und setzt jede Verbindung in den Ruhezustand CANTP_RX_WAIT bzw. CANTP_TX_WAIT [SWS_CanTp_00030]; danach gilt CANTP_ON [SWS_CanTp_00170]. Die Umgebung muss CanTp_Init vor jeder weiteren Nutzung aufrufen [SWS_CanTp_00199]. Im Leitfaden zum Modusmanagement übernimmt das eine BswM-Regel nach NvM_ReadAll (Mode Management Guide S. 54). Ein erneuter Aufruf in CANTP_ON verwirft alle laufenden Verbindungen und führt in den Ruhezustand zurück [SWS_CanTp_00273] [SWS_CanTp_00111].

CanTp_Shutdown schließt alle offenen Verbindungen, gibt die Ressourcen frei und setzt CANTP_OFF [SWS_CanTp_00202]. Dabei benachrichtigt CanTp niemanden über abgebrochene Übertragungen [SWS_CanTp_00200] (SWS CanTp S. 58).

In CANTP_ON laufen mehrere Verbindungen gleichzeitig [SWS_CanTp_00096]:

• Jede N-SDU ist statisch einem Verbindungskanal zugeordnet. Jeder Kanal hat eigene Timer, Puffer und eine eigene Zustandsmaschine [SWS_CanTp_00121] [SWS_CanTp_00122].
• Kanäle sind nur intern sichtbar [SWS_CanTp_00285]. Ihre Anzahl ermittelt das Konfigurationswerkzeug [SWS_CanTp_00289].
• Ist ein Sendekanal in CANTP_TX_PROCESSING, weist CanTp neue Aufträge über CanTp_Transmit mit E_NOT_OK ab [SWS_CanTp_00123]. Dasselbe gilt für eine N-SDU, die bereits in einer laufenden Sitzung steckt [SWS_CanTp_00206].
• Teilen sich mehrere N-SDUs einen Kanal und ist kein freier Kanal verfügbar, lehnt CanTp das Senden ab bzw. bricht den Empfang ab [SWS_CanTp_00288] (SWS CanTp S. 42).

Zustandsdiagramm: Nach CanTp_Init wechseln Empfangs- und Sendekanäle unabhängig voneinander zwischen WAIT und PROCESSING; CanTp_Shutdown führt zurück nach CANTP_OFF. Quellen: [SWS_CanTp_00027], [SWS_CanTp_00030], [SWS_CanTp_00170], [SWS_CanTp_00202], SWS CanTp S. 27

Senden: vom CanTp_Transmit bis zur Bestätigung

CanTp_Transmit erhält TxPduId und PduInfoPtr [SWS_CanTp_00212]. Ohne MetaData wertet CanTp nur die Gesamtlänge SduLength aus und greift nicht auf den Datenpuffer zu [SWS_CanTp_00225] [SWS_CanTp_00299]. Mit MetaData speichert es zusätzlich die Adressinformation für alle SF, FF und CF [SWS_CanTp_00334]. Passen die Daten in eine N-PDU, sendet CanTp einen SF, sonst eröffnet es eine Mehrfach-Frame-Sitzung [SWS_CanTp_00232] (SWS CanTp S. 60). Die maximale Sendelänge (TX_DL) folgt aus PduLength in EcuC [SWS_CanTp_00354]. Interpretation: Der Aufruf meldet synchron nur, ob der Auftrag angenommen ist; der eigentliche Transfer läuft asynchron [SWS_CanTp_00176]. Frage Q-b6d13590324e2906 (offen) Nach der Annahme meldet CanTp das Ende in jedem Fall über PduR_CanTpTxConfirmation [SWS_CanTp_00177] [SWS_CanTp_00204].

Für jedes Segment (SF, FF, CF) ruft CanTp PduR_CanTpCopyTxData auf [SWS_CanTp_00086]; bis zum ersten Aufruf läuft der Timer N_Cs [SWS_CanTp_00167]. Liefert die obere Schicht BUFREQ_E_BUSY, versucht CanTp es später erneut [SWS_CanTp_00184]. Den Retry-Parameter setzt CanTp stets auf NULL, weil ISO 15765-2 keine Wiederholung kennt [SWS_CanTp_00272].

Nach dem FF und nach dem letzten CF jedes Blocks wartet CanTp unter N_Bs auf einen Flow Control Frame [SWS_CanTp_00315]. Mit ihm gibt der Empfänger weitere CFs frei oder verzögert sie [SWS_CanTp_00282]. Ist die Sitzung erfolgreich abgeschlossen, folgt PduR_CanTpTxConfirmation mit E_OK [SWS_CanTp_00090]. Denselben Pull-Ablauf zeigen das 50-Byte-Beispiel (SWS CanTp S. 37) und der Pfad von DCM zu CanTp (SWS PduR S. 104).

Sequenzdiagramm: CanTp fordert die Daten segmentweise bei PduR an, wartet nach FF und jedem Block auf Flow Control und bestätigt zum Schluss mit E_OK. Quellen: [SWS_CanTp_00212], [SWS_CanTp_00086], [SWS_CanTp_00315], [SWS_CanTp_00090], SWS CanTp S. 73

Empfangen: Pufferaushandlung, Flow Control und Reassemblierung

Bei jedem eingehenden SF oder FF meldet CanTp den Empfangsbeginn mit PduR_CanTpStartOfReception [SWS_CanTp_00079]. Die verfügbare Puffergröße kommt über einen Ausgabeparameter zurück und darf kleiner sein als die N-SDU [SWS_CanTp_00080]. Bei einem FF startet CanTp vorher den Timer N_Br [SWS_CanTp_00166]. Den Flow Control sendet es erst, wenn das Ergebnis vorliegt; dessen Inhalt hängt von diesem Ergebnis ab [SWS_CanTp_00064] [SWS_CanTp_00277]. Alle FCs einer Empfangssitzung tragen dieselben Werte für BS und STmin [SWS_CanTp_00067]. Ein FC folgt jeweils nach BS Consecutive Frames [SWS_CanTp_00278].

Nach jedem CF übergibt CanTp die Nutzdaten mit PduR_CanTpCopyRxData und erfährt dabei den verbleibenden Puffer [SWS_CanTp_00269]. Bei CAN 2.0 sind das sechs oder sieben Byte je CF. Reicht der Restpuffer nach dem letzten CF eines Blocks nicht für den nächsten Block, startet CanTp den Timer N_Br [SWS_CanTp_00325] [SWS_CanTp_00082]. Solange dieser Timer läuft:

• fragt CanTp in jedem Lauf der MainFunction den Puffer ab, und zwar mit Länge 0 und NULL_PTR [SWS_CanTp_00222];
• sendet CanTp höchstens WFTmax aufeinanderfolgende FC(WAIT) [SWS_CanTp_00223] (SWS CanTp S. 38).

Endet die Sitzung, erfolgreich oder nicht, ruft CanTp PduR_CanTpRxIndication auf [SWS_CanTp_00084]. Mit und ohne Padding reicht CanTp nur die tatsächlich genutzten Datenbytes nach oben [SWS_CanTp_00116].

Sequenzdiagramm: Segmentierter Empfang mit Pufferaushandlung, blockweisem Flow Control und Wartephase bei knappem Puffer. Quellen: [SWS_CanTp_00079], [SWS_CanTp_00269], [SWS_CanTp_00222], [SWS_CanTp_00084], SWS CanTp S. 76

Aktivitätsdiagramm: So entscheidet CanTp bei einem eingehenden SF oder FF anhand des Kanalzustands und des Ergebnisses von PduR_CanTpStartOfReception. Quellen: [SWS_CanTp_00124], [SWS_CanTp_00337], [SWS_CanTp_00081], [SWS_CanTp_00318], [SWS_CanTp_00353], SWS CanTp S. 67

Adressierung, MetaData und Padding

Funktionale Adressierung (1:n) ist nur für SF erlaubt [SWS_CanTp_00092]. Eine segmentierte Sitzung über einen funktionalen Handle weist CanTp ab und meldet CANTP_E_INVALID_TATYPE [SWS_CanTp_00093] (SWS CanTp S. 39). Bei Extended bzw. Mixed Addressing bestimmt CanTp die N-SDU aus N_TA bzw. N_AE im ersten Datenbyte [SWS_CanTp_00095] [SWS_CanTp_00284] [SWS_CanTp_00283]. Für die Zuordnung der Kennungen gilt (SWS CanTp S. 44):

• Jede NSduId ist genau einer LSduId zugeordnet [SWS_CanTp_00035].
• Die LSduId eines FC identifiziert zusammen mit N_TA oder N_AE genau eine NSduId [SWS_CanTp_00094].
• Mehrere N-SDUs dürfen dieselbe N-PDU nur bei Extended/Mixed Addressing oder bei MetaData referenzieren [SWS_CanTp_00328].

Generische Verbindungen arbeiten mit MetaData. CanTp speichert die Adressinformation aus SF bzw. FF [SWS_CanTp_00330], gibt sie an PduR_CanTpStartOfReception weiter [SWS_CanTp_00331] und prüft folgende CFs dagegen [SWS_CanTp_00333]. Empfängt der Kanal bereits, ignoriert CanTp ein weiteres SF oder FF mit MetaData [SWS_CanTp_00337].

Padding wird je N-SDU aktiviert (SWS CanTp S. 43). Der Füllwert ist CANTP_PADDING_BYTE [SWS_CanTp_00059]. Bei Frames mit höchstens 8 Byte Nutzlast gilt:

• Mit Rx-Padding akzeptiert CanTp SF und letzten CF nur mit 8 Byte [SWS_CanTp_00344] und sendet FCs mit 8 Byte [SWS_CanTp_00347].
• Mit Tx-Padding füllt CanTp SF und letzten CF auf 8 Byte auf [SWS_CanTp_00348].

Passt eine Sendelänge zu keinem gültigen DLC, füllt CanTp bis zum nächsthöheren gültigen Wert auf [SWS_CanTp_00351]. Die Empfangslänge RX_DL leitet CanTp aus der ersten empfangenen CAN_DL ab [SWS_CanTp_00350].

Zeitüberwachung, Laufzeitparameter und Abbruch auf Anforderung

CanTp_MainFunction [SWS_CanTp_00213] wird zyklisch aufgerufen. Sie überwacht N_As, N_Bs, N_Cs, N_Ar, N_Br, N_Cr sowie STmin [SWS_CanTp_00164] (SWS CanTp S. 63). Ihr Takt richtet sich nach CanTpMainFunctionPeriod [SWS_CanTp_00300]. Dieser Wert soll der Zykluszeit des aufrufenden Tasks entsprechen (SWS CanTp S. 77). Als Beispiel nennt die Timing-Analyse einen 5-ms-Task (TR Timing Analysis S. 117).

Zwei Dienste greifen zur Laufzeit auf die Empfangsparameter BS und STmin einer N-SDU zu: CanTp_ChangeParameter ändert sie [SWS_CanTp_00302], CanTp_ReadParameter liest sie [SWS_CanTp_00323]. Beide gibt es nur, wenn CanTpChangeParameterApi = TRUE ist (SWS CanTp S. 61). BS ist nur ein Höchstwert, den CanTp aus Puffergründen unterschreiten darf [SWS_CanTp_00091]. Zwischen FF und letztem CF einer laufenden Empfangssitzung lehnt CanTp jede Änderung mit E_NOT_OK ab [SWS_CanTp_00303] [SWS_CanTp_00304]. Bei generischen Verbindungen gilt eine Änderung für alle [SWS_CanTp_00338].

Laufende Übertragungen lassen sich auf Anforderung abbrechen:

• Senden: Die Funktion wird statisch über CanTpTc aktiviert [SWS_CanTp_00242] und mit CanTp_CancelTransmit ausgelöst [SWS_CanTp_00274]. Bei E_OK bricht CanTp die Übertragung ab [SWS_CanTp_00243] [SWS_CanTp_00256] und meldet PduR_CanTpTxConfirmation mit E_NOT_OK [SWS_CanTp_00255]. Auf der Gegenseite führt das zu einem Timeout (SWS CanTp S. 26).
• Empfangen: CanTp_CancelReceive beendet einen mit FF begonnenen Empfang [SWS_CanTp_00261] und meldet PduR_CanTpRxIndication mit E_NOT_OK [SWS_CanTp_00263]. Bei einem SF oder wenn nur noch der letzte CF aussteht, lehnt CanTp den Abbruch ab [SWS_CanTp_00262] (SWS CanTp S. 60).

Verhalten im Fehlerfall

Entwicklungsfehler. Ist die Erkennung aktiv, meldet CanTp den Fehler an DET und liefert E_NOT_OK [SWS_CanTp_00294] [SWS_CanTp_00217] (SWS CanTp S. 49). Die Codes definiert [SWS_CanTp_00293]. Typische Fälle:

• CANTP_E_UNINIT: eine Funktion außer CanTp_GetVersionInfo wird vor CanTp_Init genutzt [SWS_CanTp_00031].
• CANTP_E_PARAM_POINTER: ein Zeiger ist NULL [SWS_CanTp_00319] [SWS_CanTp_00321] [SWS_CanTp_00322].
• CANTP_E_PARAM_ID: CanTp_ReadParameter erhält ungültige Parameter [SWS_CanTp_00324].

Abweichung zwischen den Releases: Für eine ungültige PduId bei den Cancel-Diensten verlangt R20-11 CANTP_E_PARAM_ID [SWS_CanTp_00254] [SWS_CanTp_00260]. Neuere Dokumentstellen nennen stattdessen CANTP_E_INVALID_TX_ID bzw. CANTP_E_INVALID_RX_ID (SWS CanTp S. 59). Für R20-11 gilt das Requirement.

Laufzeitfehler. Sie gehen an den Default Error Tracer [SWS_CanTp_00352]:

• CANTP_E_PADDING: ein Frame ist trotz Padding zu kurz [SWS_CanTp_00345] [SWS_CanTp_00346] [SWS_CanTp_00349].
• CANTP_E_OPER_NOT_SUPPORTED: ein Cancel betrifft eine N-SDU ohne laufende Übertragung [SWS_CanTp_00254].
• Für Protokollfehler nennt die Dokumentstelle zusätzlich CANTP_E_COM, CANTP_E_RX_COM und CANTP_E_TX_COM (SWS CanTp S. 52).

Protokollfehler. Sie beenden die Sitzung mit E_NOT_OK an die obere Schicht [SWS_CanTp_00205]:

• Sendeseite (Meldung über PduR_CanTpTxConfirmation): Datenmangel beim Kopieren [SWS_CanTp_00087], Ablauf von N_Cs [SWS_CanTp_00280], N_As [SWS_CanTp_00310] oder N_Bs [SWS_CanTp_00316], FC mit OVFLW oder ungültigem FS [SWS_CanTp_00309] [SWS_CanTp_00317]. Nach N_As bleibt die N-PDU gesperrt, bis die TxConfirmation eintrifft [SWS_CanTp_00075].
• Empfangsseite (Meldung über PduR_CanTpRxIndication): Ablauf von N_Ar [SWS_CanTp_00311] oder N_Cr [SWS_CanTp_00313], abgelehnte Kopie [SWS_CanTp_00271].
• Abbruch ohne Meldung: Liefert PduR_CanTpStartOfReception BUFREQ_E_NOT_OK, bricht CanTp ab; es folgen weder FC noch Indication [SWS_CanTp_00081].
• Unerwartete N-PDUs behandelt CanTp nach einer Tabelle [SWS_CanTp_00057] (SWS CanTp S. 45).

Der PduR leitet die negative Bestätigung an den Nutzer weiter, z. B. an den DCM, der dann für die Wiederherstellung sorgt (Error Description S. 29, Error Description S. 28). Produktionsfehler behandelt der DEM über den FiM [SWS_CanTp_00291].

Aktivitätsdiagramm: Alle Abbruchursachen münden je Richtung in eine negative Meldung an PduR. Quellen: [SWS_CanTp_00205], [SWS_CanTp_00343], [SWS_CanTp_00355], [SWS_CanTp_00342], [SWS_CanTp_00223], [SWS_CanTp_00084], Error Description S. 28

Weiterführende Detailbelege

• Lebenszyklus und Kanäle: [SWS_CanTp_00027], [SWS_CanTp_00030], [SWS_CanTp_00122]; Zustandsautomat in SWS CanTp S. 27.
• Senden: [SWS_CanTp_00212], [SWS_CanTp_00086], [SWS_CanTp_00204]; Beispielablauf in SWS CanTp S. 37.
• Empfangen und Puffer: [SWS_CanTp_00079], [SWS_CanTp_00222]; 49-Byte-Beispiel in SWS CanTp S. 38.
• Zeitüberwachung: [SWS_CanTp_00164], [SWS_CanTp_00300].
• Adressierung und Padding: [SWS_CanTp_00092], [SWS_CanTp_00330], [SWS_CanTp_00344]; Hintergrund in SWS CanTp S. 43.
• Fehlercodes: [SWS_CanTp_00293] (Entwicklungsfehler), [SWS_CanTp_00352] (Laufzeitfehler); Tabelle der unerwarteten N-PDUs in [SWS_CanTp_00057].