Download link for CP AUTOSAR document

1. First, let’s look at the COM stack architecture diagram
1 CAN communication protocol stack concept

The AUTOSAR communication stack is located between the runtime environment (RTE) and the microcontroller abstraction layer (MCAL), which can simplify communication services between ECUs and enable data interaction between different types or rate buses. In the AUTOSAR communication stack, the communication module (Com), diagnostic communication management module (Diagnostic Communication Manager, Dem), protocol data unit routing module (PduR), protocol data unit multiplexing module (I-PDU multiplexer, IpduM), bus-related transmission module (such as CanTp, FrTp, etc.), and communication and network management-related modules; the ECU abstraction layer is bus-related interface module (such as CanIf, LinIf, etc.); the microcontroller abstraction layer is bus-related driver module (such as Can, Lin, etc.)

The AUTOSAR communication stack hides the properties of bus-related protocols and packets from the application layer. Taking basic CAN communication as an example, its transmission mechanism is RTE->COM->PduR->CanIf->CAN Driver. The process description is as follows:

The Com module obtains the signal of the application layer and sends it to the PduR module after a certain processing and packages it into I-PDU (Interaction Layer Protocol Data Unit).
The I-PDU target receiving module specified in the PduR module routing protocol sends the received I-PDU to CanIf after a certain processing;
CanIf sends the signal to the CAN driver module in the form of L-PDU (Data Link Layer Protocol Data Unit)

2 Introduction to CAN communication protocol module
2.1 Com module
The Com module is located between the RTE and the PduR module in the runtime environment, and its main functions include:

Load the signal into the I-PDU and transmit it, and parse the signal from the received I-PDU;
Provides signal routing function to package the received I-PDU into the transmitting I-PDU;
Communication sending control (start/stop I-PDU group)
Send a requested reply, etc.
For each Com I-PDU, it is necessary to set the transmission direction (ComIPduDirection), signal processing method (ComIPduSignalProcessing), type (ComIPduSignalRef), I-PDU working group (ComIPduGroupRef), Com signal reference (ComIPduSignalRef), global PDU reference (ComPduIdRef), etc.

2.2 PduR module
The PduR module mainly provides I-PDU-based routing services for communication interface modules, transmission protocol modules, diagnostic communication management modules and communication modules. It plays a role in connecting the past and the future in the communication protocol stack, blocking network details for the upper-level service basic software modules and applications, so that the upper-level basic software modules and applications do not need to worry about running on which bus network. At the same time, the PduR module provides I-PDU-based gateway function, making communication between different buses possible.

2.3 CanIf module
The CAN interface layer (CanIf) is a standard interface for accessing the CAN bus. CanIf abstracts the location information of the CAN controller.It also provides a unified interface to the upper layer module to block the differences in the lower layer, that is, the upper layer does not need to care whether the CAN controller is an on-chip device or an off-chip device of the microcontroller.

The main functions of the CANIf module: complete the initialization of the global variables and configuration buffers in CanIf and the controller; send request service, provide an interface for the upper layer to send PDUs on the CAN network; send confirmation service, notify the upper layer after the sending is successful, or save it in the sending cache after the sending is cancelled; receive instructions service, notify the upper layer after the PDU is successfully received.

The CANIf module is mainly configured as a hardware object handle (Hardware object handle, Hoh), including Hth (Hardware transmit handle) and Hrh (Hardware receive handle), which need to refer to the CAN hardware objects defined in the Can module.

2.4 ComM module
Communication Manager (ComM) can simplify the initialization, network management, etc. of the bus communication stack, and can collect/coordinate bus communication access requests. It mainly provides three communication modes:

COMM_FULL_COMMUNICATION: FULL communication mode, this state can be received and sent
COMM_SILENT_COMMUNICATION:SILENT communication mode, this state can only be received
COMM_NO_COMMUNICATION:NO communication mode, this state cannot communicate
2.5 CanSM module
The CAN State Manager (CAN State Manager, CanSM) is responsible for implementing the abstraction of the CAN network control process. It provides an API for the ComM module to request the CAN network to switch communication modes.

3 MCal Can module[2]
CAN Driver is a communication driver in the microcontroller abstraction layer. It is aimed at the CAN controller inside the microcontroller. It can realize functions such as initialization of the CAN controller, sending/receiving CAN messages, indicating the received messages, confirming the sent messages, wake-up detection, overflow and error handling. The CAN driver can access the hardware and provide an API independent of the hardware to the upper layer.