CAN Transport Layer (CanTp)

The CAN Transport Layer segments messages that do not fit into a CAN frame, controls data flow via flow control, and reassembles received segments according to ISO 15765-2 [SWS_CanTp_00033]. It is situated between PduR and CanIf, has no payload buffer of its own, and copies transmit and receive data segment by segment via the copy services of the upper layer [SWS_CanTp_00298]. It concludes each accepted transmission with a notification to the upper layer—successfully with E_OK, upon timeout or abort with E_NOT_OK. All of this requires CanTp_Init; the timeouts are monitored by the cyclic MainFunction.

more ›

CanTp is the CAN Transport Layer. It segments long messages into CAN frames, controls data flow, and reassembles received segments; in doing so, it follows ISO 15765-2 unless the specification governs otherwise [SWS_CanTp_00033]. The module is situated between PduR and CanIf and has no payload buffer of its own. It copies data segment by segment via the copy services of the upper layer [SWS_CanTp_00298] [SWS_CanTp_00216].

Context diagram: The interfaces of CanTp to PduR, CanIf, mode management, scheduler, and DET. Sources: [SWS_CanTp_00216], SWS CanTp p. 17

After power-on, CanTp is in CANTP_OFF [SWS_CanTp_00168]. CanTp_Init with CanTp_ConfigType [SWS_CanTp_00208] transitions all connections into the idle state [SWS_CanTp_00030]; thereafter, CANTP_ON [SWS_CanTp_00170] applies. CanTp_Shutdown closes all connections without notifying anyone [SWS_CanTp_00202] [SWS_CanTp_00200]. The connection channels operate independently of one another with their own timers [SWS_CanTp_00122]. If a transmit channel is occupied, CanTp rejects new requests with E_NOT_OK [SWS_CanTp_00123].

During transmission, CanTp_Transmit evaluates only the length (and MetaData if applicable) [SWS_CanTp_00225]. Depending on the length, an SF or a segmented session follows [SWS_CanTp_00232]. For each segment, CanTp fetches the data with PduR_CanTpCopyTxData [SWS_CanTp_00086] and waits for flow control under N_Bs after FF and after each block [SWS_CanTp_00315]. Interpretation: The call reports only acceptance; the end of the transfer is signaled asynchronously via PduR_CanTpTxConfirmation [SWS_CanTp_00176] [SWS_CanTp_00204]. Question (open)

During reception, CanTp first requests a buffer with PduR_CanTpStartOfReception [SWS_CanTp_00079]. Thereafter, it copies each CF with PduR_CanTpCopyRxData [SWS_CanTp_00269]. If the buffer is scarce, CanTp queries it again in each MainFunction and transmits at most WFTmax FC(WAIT) [SWS_CanTp_00222] [SWS_CanTp_00223]. At the end stands PduR_CanTpRxIndication [SWS_CanTp_00084]. Timeouts are monitored by the cyclic CanTp_MainFunction [SWS_CanTp_00164].

Sequence diagram: Segmented reception with buffer negotiation and flow control CTS/WAIT. Sources: [SWS_CanTp_00269], [SWS_CanTp_00222], SWS CanTp p. 38

CanTp handles errors in three ways. It reports development errors to DET and returns E_NOT_OK [SWS_CanTp_00294]. Protocol errors such as timeouts abort the session and are passed to PduR with E_NOT_OK [SWS_CanTp_00205] [SWS_CanTp_00311]. The same applies to aborts upon request via the cancel services [SWS_CanTp_00255] [SWS_CanTp_00263]. For invalid IDs in the cancel services, R20-11 requires CANTP_E_PARAM_ID [SWS_CanTp_00254], whereas newer releases specify different codes.

more ›

Role in the CAN stack: Transport protocol between PduR and CanIf

CanTp is the CAN Transport Layer. It segments messages that do not fit into a single CAN frame into segments, controls data flow, and reassembles received segments (SWS CanTp p. 24, SWS CanTp p. 17). The basis is ISO 15765-2: Every recommendation of this standard applies unless the specification explicitly excludes it [SWS_CanTp_00033]. CanTp executes segmentation and reassembly only in state CANTP_ON [SWS_CanTp_00238].

Upwards, CanTp provides the following services to PduR: CanTp_Transmit [SWS_CanTp_00212], CanTp_CancelTransmit [SWS_CanTp_00246], and CanTp_CancelReceive [SWS_CanTp_00257]. CanTp itself invokes PduR_CanTpStartOfReception, PduR_CanTpCopyRxData, PduR_CanTpCopyTxData, PduR_CanTpRxIndication, and PduR_CanTpTxConfirmation upwards, and CanIf_Transmit [SWS_CanTp_00216] downwards. The lower layer reports received frames via CanTp_RxIndication [SWS_CanTp_00078] and transmit confirmations via CanTp_TxConfirmation [SWS_CanTp_00076]. Both functions must be callable in interrupt context [SWS_CanTp_00235] [SWS_CanTp_00236]. Newer document passages specify the L-SDU Router (LSduR) as caller (SWS CanTp p. 27). In contrast, the requirements of R20-11 refer to the CAN Interface, such as [SWS_CanTp_00031] and [SWS_CanTp_00335].

CanTp has no payload buffer of its own. It fetches transmit data directly from the upper layer [SWS_CanTp_00298], and copies received data directly into its memory (SWS CanTp p. 35). This results in locking periods for the upper layer (SWS CanTp p. 35):

• It keeps the transmit buffer locked as soon as CanTp_Transmit returns with E_OK until PduR_CanTpTxConfirmation arrives.
• It keeps the receive buffer locked as soon as it has provided BUFREQ_OK in response to PduR_CanTpStartOfReception until PduR_CanTpRxIndication arrives.

Context diagram: CanTp is situated between PduR and CanIf. It is initialized by mode management, triggered cyclically by the scheduler, and reports errors to DET. Sources: [SWS_CanTp_00216], [SWS_CanTp_00217], [SWS_CanTp_00164], SWS CanTp p. 17, Mode Management Guide p. 54

Lifecycle: CANTP_OFF, CanTp_Init, and independent connection channels

CanTp recognizes the states CANTP_OFF and CANTP_ON [SWS_CanTp_00027]. After power-on, the module is in CANTP_OFF [SWS_CanTp_00168]; the post-build configuration may only be updated there [SWS_CanTp_00169].

CanTp_Init receives a pointer to CanTp_ConfigType [SWS_CanTp_00208] [SWS_CanTp_00340]. The function initializes all global variables and sets each connection to the idle state CANTP_RX_WAIT or CANTP_TX_WAIT [SWS_CanTp_00030]; thereafter, CANTP_ON [SWS_CanTp_00170] applies. The environment must call CanTp_Init prior to any further usage [SWS_CanTp_00199]. In the guide to mode management, a BswM rule takes care of this after NvM_ReadAll (Mode Management Guide p. 54). A repeated call in CANTP_ON discards all running connections and returns to the idle state [SWS_CanTp_00273] [SWS_CanTp_00111].

CanTp_Shutdown closes all open connections, frees resources, and sets CANTP_OFF [SWS_CanTp_00202]. In doing so, CanTp notifies no one of aborted transmissions [SWS_CanTp_00200] (SWS CanTp p. 58).

In CANTP_ON, several connections run concurrently [SWS_CanTp_00096]:

• Each N-SDU is statically assigned to a connection channel. Each channel has its own timers, buffers, and its own state machine [SWS_CanTp_00121] [SWS_CanTp_00122].
• Channels are visible only internally [SWS_CanTp_00285]. Their number is determined by the configuration tool [SWS_CanTp_00289].
• If a transmit channel is in CANTP_TX_PROCESSING, CanTp rejects new requests via CanTp_Transmit with E_NOT_OK [SWS_CanTp_00123]. The same applies to an N-SDU that is already engaged in an active session [SWS_CanTp_00206].
• If multiple N-SDUs share a channel and no free channel is available, CanTp rejects transmission or aborts reception, respectively [SWS_CanTp_00288] (SWS CanTp p. 42).

State diagram: After CanTp_Init, receive and transmit channels switch independently of one another between WAIT and PROCESSING; CanTp_Shutdown leads back to CANTP_OFF. Sources: [SWS_CanTp_00027], [SWS_CanTp_00030], [SWS_CanTp_00170], [SWS_CanTp_00202], SWS CanTp p. 27

Transmission: From CanTp_Transmit to confirmation

CanTp_Transmit receives TxPduId and PduInfoPtr [SWS_CanTp_00212]. Without MetaData, CanTp evaluates only the total length SduLength and does not access the data buffer [SWS_CanTp_00225] [SWS_CanTp_00299]. With MetaData, it additionally stores the addressing information for all SF, FF, and CF [SWS_CanTp_00334]. If the data fits into an N-PDU, CanTp transmits an SF, otherwise it opens a multi-frame session [SWS_CanTp_00232] (SWS CanTp p. 60). The maximum transmission length (TX_DL) results from PduLength in EcuC [SWS_CanTp_00354]. Interpretation: The call reports synchronously only whether the request is accepted; the actual transfer runs asynchronously [SWS_CanTp_00176]. Question Q-b6d13590324e2906 (open) After acceptance, CanTp reports the end in any case via PduR_CanTpTxConfirmation [SWS_CanTp_00177] [SWS_CanTp_00204].

For each segment (SF, FF, CF), CanTp invokes PduR_CanTpCopyTxData [SWS_CanTp_00086]; timer N_Cs runs until the first invocation [SWS_CanTp_00167]. If the upper layer returns BUFREQ_E_BUSY, CanTp tries again later [SWS_CanTp_00184]. CanTp always sets the retry parameter to NULL because ISO 15765-2 does not know retries [SWS_CanTp_00272].

After the FF and after the last CF of each block, CanTp waits under N_Bs for a Flow Control frame [SWS_CanTp_00315]. With it, the receiver enables or delays further CFs [SWS_CanTp_00282]. Once the session is successfully concluded, PduR_CanTpTxConfirmation with E_OK follows [SWS_CanTp_00090]. The same pull flow is shown by the 50-byte example (SWS CanTp p. 37) and the path from DCM to CanTp (SWS PduR p. 104).

Sequence diagram: CanTp requests data segment by segment from PduR, waits for flow control after FF and each block, and finally confirms with E_OK. Sources: [SWS_CanTp_00212], [SWS_CanTp_00086], [SWS_CanTp_00315], [SWS_CanTp_00090], SWS CanTp p. 73

Reception: Buffer negotiation, flow control, and reassembly

Upon each incoming SF or FF, CanTp indicates start of reception with PduR_CanTpStartOfReception [SWS_CanTp_00079]. The available buffer size is returned via an output parameter and may be smaller than the N-SDU [SWS_CanTp_00080]. In case of an FF, CanTp starts timer N_Br beforehand [SWS_CanTp_00166]. It transmits the Flow Control only when the result is available; its content depends on this result [SWS_CanTp_00064] [SWS_CanTp_00277]. All FCs of a receive session carry the same values for BS and STmin [SWS_CanTp_00067]. An FC follows after BS consecutive frames in each case [SWS_CanTp_00278].

After each CF, CanTp passes the payload data with PduR_CanTpCopyRxData and thereby learns the remaining buffer [SWS_CanTp_00269]. For CAN 2.0, this is six or seven bytes per CF. If the remaining buffer after the last CF of a block is insufficient for the next block, CanTp starts timer N_Br [SWS_CanTp_00325] [SWS_CanTp_00082]. As long as this timer runs:

• CanTp queries the buffer in each run of MainFunction, specifically with length 0 and NULL_PTR [SWS_CanTp_00222];
• CanTp transmits at most WFTmax consecutive FC(WAIT) [SWS_CanTp_00223] (SWS CanTp p. 38).

When the session ends, successfully or not, CanTp calls PduR_CanTpRxIndication [SWS_CanTp_00084]. With and without padding, CanTp passes only the actually used data bytes to the upper layer [SWS_CanTp_00116].

Sequence diagram: Segmented reception with buffer negotiation, block-wise flow control, and wait phase in case of scarce buffer. Sources: [SWS_CanTp_00079], [SWS_CanTp_00269], [SWS_CanTp_00222], [SWS_CanTp_00084], SWS CanTp p. 76

Activity diagram: How CanTp decides on an incoming SF or FF based on channel state and the result of PduR_CanTpStartOfReception. Sources: [SWS_CanTp_00124], [SWS_CanTp_00337], [SWS_CanTp_00081], [SWS_CanTp_00318], [SWS_CanTp_00353], SWS CanTp p. 67

Addressing, MetaData, and padding

Functional addressing (1:n) is permitted only for SF [SWS_CanTp_00092]. CanTp rejects a segmented session via a functional handle and reports CANTP_E_INVALID_TATYPE [SWS_CanTp_00093] (SWS CanTp p. 39). In case of extended or mixed addressing, CanTp determines the N-SDU from N_TA or N_AE in the first data byte [SWS_CanTp_00095] [SWS_CanTp_00284] [SWS_CanTp_00283]. For the assignment of identifiers, the following applies (SWS CanTp p. 44):

• Each NSduId is assigned to exactly one LSduId [SWS_CanTp_00035].
• The LSduId of an FC together with N_TA or N_AE identifies exactly one NSduId [SWS_CanTp_00094].
• Multiple N-SDUs may reference the same N-PDU only with extended/mixed addressing or with MetaData [SWS_CanTp_00328].

Generic connections operate with MetaData. CanTp stores the addressing information from SF or FF [SWS_CanTp_00330], forwards it to PduR_CanTpStartOfReception [SWS_CanTp_00331], and checks subsequent CFs against it [SWS_CanTp_00333]. If the channel is already receiving, CanTp ignores a further SF or FF with MetaData [SWS_CanTp_00337].

Padding is enabled per N-SDU (SWS CanTp p. 43). The fill value is CANTP_PADDING_BYTE [SWS_CanTp_00059]. For frames with at most 8 bytes of payload, the following applies:

• With Rx padding, CanTp accepts SF and the last CF only with 8 bytes [SWS_CanTp_00344] and transmits FCs with 8 bytes [SWS_CanTp_00347].
• With Tx padding, CanTp pads SF and the last CF to 8 bytes [SWS_CanTp_00348].

If a transmit length does not match any valid DLC, CanTp pads up to the next higher valid value [SWS_CanTp_00351]. CanTp derives the receive length RX_DL from the first received CAN_DL [SWS_CanTp_00350].

Time monitoring, runtime parameters, and abort upon request

CanTp_MainFunction [SWS_CanTp_00213] is called cyclically. It monitors N_As, N_Bs, N_Cs, N_Ar, N_Br, N_Cr, and STmin [SWS_CanTp_00164] (SWS CanTp p. 63). Its cycle time is based on CanTpMainFunctionPeriod [SWS_CanTp_00300]. This value shall correspond to the cycle time of the calling task (SWS CanTp p. 77). As an example, the timing analysis cites a 5-ms task (TR Timing Analysis p. 117).

Two services access the receive parameters BS and STmin of an N-SDU at runtime: CanTp_ChangeParameter changes them [SWS_CanTp_00302], CanTp_ReadParameter reads them [SWS_CanTp_00323]. Both exist only if CanTpChangeParameterApi = TRUE (SWS CanTp p. 61). BS is only an upper limit, which CanTp may undercut due to buffer reasons [SWS_CanTp_00091]. Between FF and the last CF of an ongoing receive session, CanTp rejects any change with E_NOT_OK [SWS_CanTp_00303] [SWS_CanTp_00304]. For generic connections, a change applies to all [SWS_CanTp_00338].

Ongoing transmissions can be aborted upon request:

• Transmission: The feature is enabled statically via CanTpTc [SWS_CanTp_00242] and triggered with CanTp_CancelTransmit [SWS_CanTp_00274]. Upon E_OK, CanTp aborts the transmission [SWS_CanTp_00243] [SWS_CanTp_00256] and reports PduR_CanTpTxConfirmation with E_NOT_OK [SWS_CanTp_00255]. On the remote side, this leads to a timeout (SWS CanTp p. 26).
• Reception: CanTp_CancelReceive terminates a reception initiated with FF [SWS_CanTp_00261] and reports PduR_CanTpRxIndication with E_NOT_OK [SWS_CanTp_00263]. In case of an SF or when only the last CF is pending, CanTp rejects the abort [SWS_CanTp_00262] (SWS CanTp p. 60).

Behavior in the event of an error

Development errors. If detection is active, CanTp reports the error to DET and returns E_NOT_OK [SWS_CanTp_00294] [SWS_CanTp_00217] (SWS CanTp p. 49). The codes are defined by [SWS_CanTp_00293]. Typical cases:

• CANTP_E_UNINIT: a function other than CanTp_GetVersionInfo is used before CanTp_Init [SWS_CanTp_00031].
• CANTP_E_PARAM_POINTER: a pointer is NULL [SWS_CanTp_00319] [SWS_CanTp_00321] [SWS_CanTp_00322].
• CANTP_E_PARAM_ID: CanTp_ReadParameter receives invalid parameters [SWS_CanTp_00324].

Discrepancy between releases: For an invalid PduId in the cancel services, R20-11 requires CANTP_E_PARAM_ID [SWS_CanTp_00254] [SWS_CanTp_00260]. Newer document passages state CANTP_E_INVALID_TX_ID or CANTP_E_INVALID_RX_ID instead (SWS CanTp p. 59). For R20-11, the requirement applies.

Runtime errors. They go to the Default Error Tracer [SWS_CanTp_00352]:

• CANTP_E_PADDING: a frame is too short despite padding [SWS_CanTp_00345] [SWS_CanTp_00346] [SWS_CanTp_00349].
• CANTP_E_OPER_NOT_SUPPORTED: a cancel concerns an N-SDU without an active transmission [SWS_CanTp_00254].
• For protocol errors, the document passage additionally lists CANTP_E_COM, CANTP_E_RX_COM, and CANTP_E_TX_COM (SWS CanTp p. 52).

Protocol errors. They terminate the session with E_NOT_OK to the upper layer [SWS_CanTp_00205]:

• Transmit side (notification via PduR_CanTpTxConfirmation): lack of data during copying [SWS_CanTp_00087], expiration of N_Cs [SWS_CanTp_00280], N_As [SWS_CanTp_00310], or N_Bs [SWS_CanTp_00316], FC with OVFLW or invalid FS [SWS_CanTp_00309] [SWS_CanTp_00317]. After N_As, the N-PDU remains locked until the TxConfirmation arrives [SWS_CanTp_00075].
• Receive side (notification via PduR_CanTpRxIndication): expiration of N_Ar [SWS_CanTp_00311] or N_Cr [SWS_CanTp_00313], rejected copy [SWS_CanTp_00271].
• Abort without notification: If PduR_CanTpStartOfReception returns BUFREQ_E_NOT_OK, CanTp aborts; neither FC nor indication follows [SWS_CanTp_00081].
• Unexpected N-PDUs are handled by CanTp according to a table [SWS_CanTp_00057] (SWS CanTp p. 45).

PduR forwards the negative confirmation to the user, e.g. to DCM, which then takes care of recovery (Error Description p. 29, Error Description p. 28). Production errors are handled by DEM via FiM [SWS_CanTp_00291].

Activity diagram: All abort causes lead to a negative notification to PduR for each direction. Sources: [SWS_CanTp_00205], [SWS_CanTp_00343], [SWS_CanTp_00355], [SWS_CanTp_00342], [SWS_CanTp_00223], [SWS_CanTp_00084], Error Description p. 28

Further detailed evidence

• Lifecycle and channels: [SWS_CanTp_00027], [SWS_CanTp_00030], [SWS_CanTp_00122]; state machine in SWS CanTp p. 27.
• Transmission: [SWS_CanTp_00212], [SWS_CanTp_00086], [SWS_CanTp_00204]; example sequence in SWS CanTp p. 37.
• Reception and buffers: [SWS_CanTp_00079], [SWS_CanTp_00222]; 49-byte example in SWS CanTp p. 38.
• Time monitoring: [SWS_CanTp_00164], [SWS_CanTp_00300].
• Addressing and padding: [SWS_CanTp_00092], [SWS_CanTp_00330], [SWS_CanTp_00344]; background in SWS CanTp p. 43.
• Error codes: [SWS_CanTp_00293] (development errors), [SWS_CanTp_00352] (runtime errors); table of unexpected N-PDUs in [SWS_CanTp_00057].