CanTp is a module between PDU router and CAN interface module. The main purpose of the CAN TP module is to segment and reassemble CANI-PDUs exceeding 8 bytes or exceeding 64 bytes in case of CAN FD. The PDU router deploys AUTOSAR COM and DCMI-PDU to different communication protocols. Routing through network system types (such as CAN, LIN, and Flex Ray) depends on the I-PDU identifier. The PDU router can also determine if a transport protocol must be used. Finally, when there is no transrating, the module performs the gateway function.

CanIf provides the same mechanism to access CAN bus channels. From the location of the CAN controller (on-chip/on-board), the ECU hardware layout and the number of CAN drivers are extracted. Because CanTp only handles transport protocol frames (i.e. SF, FF, CF and FCPDU), depending on the N-PDU ID, the CAN interface has to forward the I-PDU to CanTp or PduR.

2. Function description

A description of the CAN transport layer functionality is provided here. It explains the services provided to the upper and lower layers and the internal behavior of the CAN transport layer.

The CanTp module provides services for segmentation, transmission with flow control, etc., and reassembly of messages. Its main purpose is to send and receive information which may or may not fit within a single CAN frame. Message CAN frames that do not fit into a single message are split into multiple parts so that each part can fit in a single CAN frame.

2.1 Services provided to upper layers

The service interfaces of the CanTp module can be mainly divided into the following types:

initialization and shutdown
Communication service

2.1.1 Initialization and shutdown

[Specification] The CanTp module shall have two internal states, CANTP_OFF and CANTP_ON.

[Specification] CanTp module should be in CANTP_OFF state after power on.

[Specification] In state CANTP_OFF, CanTp shall allow updating the post-build configuration.

[Specification] When CanTp has been successfully initialized with CanTp_Init(), the CanTp module will change to the internal state CANTP_ON.

[Specification] Only when CanTp is in the CANTP_ON state, the CanTp module can perform segmentation and reassembly tasks.

[Specification] The function CanTp_Init should initialize all global variables of the module, and set all transport protocol connections to the substate of CANTP_ON, in which there is no segmented transmission and segmented reception (Rx thread in state CANTP_RX_WAIT, Tx thread in state CANTP_TX_WAIT ).

[Specification] If called when the CanTp module is in the global state CANTP_ON, CanTp_Init returns the module to the Idle state (state = CANTP_ON, but no transmission or reception is performed.

[Specification] When the CanTp module is in the global state CANTP_ON, if CanTp_Init is called, the CanTp module will lose all current connections.

[Specification] The function CanTp_Shutdown should correctly stop the CanTp module

2.1.2 Send request

The transmit operation CanTp_Transmit() will allow upper layers to request data transmission using the CAN transport protocol facilities (segmentation, extended addressing format, etc.).

[Specification] The function CanTp_Transmit() shall be asynchronous.

[Specification] After accepting a transfer request, the CanTp module shall notify its upper layer if the N-SDU transfer is fully processed (regardless of whether it was successful or not).

2.1.3 Send Cancellation

The transfer cancel function allows upper layers to cancel transfers in progress.

[Specification] The transmission can be canceled by CanTp_CancelTransmit().

[Specification] After calling the service CanTp_CancelTransmit(), the transmission on this connection will be aborted.

2.2 Services provided to lower layers

According to the AUTOSAR communication stack specification, the CAN transport layer provides the following two callback functions for the CAN interface: TxConfirmation() and CanTp_RxIndication().

2.2.1 Transmission Confirmation

[Specification] When no transmission confirmation is received after a maximum time (equal to N_As), the CanTp module shall abort the corresponding session. The N-PDU remains unavailable to other concurrent sessions until it receives Tx acknowledgment or not.

[Specification] For the confirmation call, the CanTp module shall provide the CanTp_TxConfirmation() function.

[Specification] CanTp should abort the response session when CanTp_TxConfirmation() is called with result E_NOT_OK.c

2.2.2 Receive indication

The CanIf module should invoke the receive indication function to notify the CanTp module that a new CAN N-PDU frame (that is, a transmission protocol frame) has been received.

[Specification] For receive indication, the CanTp module shall provide CanTp_RxIndication().

2.3 Internal Behavior

The internal operation of the CAN transport layer provides the basic mechanisms to perform the main purpose of this module, which is to transmit messages in a single CAN frame or in multiple CAN frames. The entire behavior of the CAN transport layer will be triggered by events, so CanTp can directly handle the transmission of N-SDUs (respectively L-SDUs) from the PDU router (respectively CAN interface).

2.3.1 N-SDU reception

[Specification] When receiving a SF or FF N-PDU, the CanTp module shall use the PduR_CanTpStartOfReception function to notify the upper layer (PDU router) of this reception.

[Specification] When CanTp_RxIndication requires SF or FFN-PDU (indicating a general connection), the CanTp module shall store the addressing information contained in the metadata, and use this information for the connection with the upper layer, the transmission of the FCN-PDU and the CFN- Identification of PDUs.

2.3.2 N-SDU transmission

The upper layer requests the transmission of N-SDUs by calling CanTp_Transmit(). The parameters of CanTp_Transmit() describe the CAN NSduId and the complete Tx N-SDU length to be sent.

2.3.3 Buffer strategy

Since CanTp has no buffering capability, N-SDU payloads to be transmitted are not duplicated internally, nor are received N-PDUs reassembled internally. The CAN transport layer works directly on the memory area of the upper layer (eg PduR, DCM or COM). To access these memory areas, the CAN transport layer will use the PduR_CanTpCopyTxData() or PduR_CanTpCopyRxData() functions.

Therefore, in order to ensure data consistency, upper layers should lock this memory region until indicated. When the transmit buffer is locked, the upper layer cannot write data in the buffer area. When the receive buffer is locked, the CAN transport layer cannot guarantee the data consistency of the buffer. Upper layers should not read or write data in the buffer.

2.3.4 Tx and Rx data flow

Flow control is used to adjust the ability of the sender to the receiver. The main purpose of this transport protocol is point-to-point communication (ie 1 to 1 communication - physical addressing).

[Specification] The CanTp module shall provide 1 to n communication (i.e. functional addressing [1]) to SFn-pdu (and only SF NSDU) in the form of function.

2.3.5 Relationship between CAN NSduId and CAN LSduId

Describes the connection that exists between CAN NSduId and CAN LSdu Id in order to enable the transmission and reception of Transport Protocol Data Units.

2.3.6 Concurrent Connections

The CAN transport layer is able to manage multiple connections simultaneously (for example, one UDS and one OBD request can be received at the same time).

2.3.7 N-PDU padding

Guarantees full compatibility with all upper layer requirements regarding frame data length (eg OBD requires data length to always be set to 8 bytes, however UDS does not), padding activation is configurable precompilation time per N-SDU using activation Rx N-SDU or CanTpTx Activate Activate Tx N-SDU.

2.3.8 Handling of Unexpected N-PDU Arrival

The behavior of the CAN transport layer upon the arrival of an unexpected N-PDU depends largely on the type of communication direction that handles the N-SDU.

[Specifications] If an unexpected frame is received, the CanTp module should operate according to the following table. This table specifies N-PDU processing taking into account the current CanTp internal state (CanTp state).

2.4 Misclassification

2.4.1 Development errors

2.4.2 Running errors

3. API interface

3.1 API definition

CanTp_Init
CanTp_GetVersionInfo
CanTp_Shutdown
CanTp_Transmit
CanTp_CancelTransmit
CanTp_CancelReceive
CanTp_ChangeParameter
CanTp_ReadParameter
CanTp_MainFunction

3.2 Callback notification

CanTp_RxIndication
CanTp_TxConfirmation

[AUTOSAR] [CAN communication] CanTp

1. Introduction