Communication Stack - CAN

Network Dependent Block of Communication Stack for CAN

In my last post we have discussed generic and bus independent blocks of AUTOSAR Communication stack in brief. If you have not read that post then I recommend reading it before going further. It will be easier in understanding this by relating it with this post.   

CAN Communication services are a group of modules for vehicle communication system utilizing CAN bus. This provides a uniform interface to the CAN network along with hiding protocol and message properties from application. The application layer is only concerned with data, not with the frame creation and transmission, for it communication services block is used. CAN communication stack supports standard CAN as well as CAN FD if supported by hardware.

Communication for CAN network

Above figure shows the detailed layers involved in CAN communication in AUTOSAR. In this figure, only blocks like: communication services , communication hardware abstraction, communication drivers are considered (as we are discussing only Communication stack related blocks), but this time with detailed blocks in them. Some blocks are network/bus dependent (in dark blue color) and some are network/bus independent (in orange color), the independent ones exist as one instance per ECU or in other words the independent blocks will be reused if more than one type of network bus is used for example CAN and FlexRay in single ECU. Lets see each blocks in brief :

1. CAN NM: This is CAN dependent module but it is hardware independent. It will be used only if CAN bus is used in the application. Its main purpose is to coordinate between different modes of CAN network like bus sleep mode and normal operation. In addition to this, it also provides configurable features like implement a service to detect all present nodes or check all nodes are ready to sleep. CAN NM function provides a adaption layer between Network management Interface (Nm) and CAN Interface (CanIf). For general understanding of Network management check this link. The CAN NM consists of three modes : Network Mode, Prepare Bus Sleep Mode, and Bus sleep mode. We will see this block in detail in future posts.

2. CAN State Manager (CanSM): AUTOSAR BSW provides a specific state manager for respective bus/network. In ECU there can be multiple communication network/buses. Each network has a unique network handle. The ComM module keeps track of communication modes of network by requesting from network handle. ComM knows by its configuration which handle is assigned to CAN or FlexRay or any other network type. For CAN, ComM uses CanSM to request modes of CAN. The CanSM module is responsible for controlling the flow abstraction of CAN networks in AUTOSAR. It changes the modes of CAN network according to requests sent from ComM module. CAN SM uses the API of CANIf module, any change of modes of CAN controller or CAN transceiver will be notified by CANIf to CanSM. Depending on this notifications and state of the CAN network state machine, which the CanSM module shall implement for each configured CAN network, the CanSM module notifies the ComM.

3. CAN Transport Protocol (CanTp): Many times the PDU(message) that needs to be transmitted or received may go beyond the maximum size of supported CAN message. For solving such problems and limitations of CAN AUTOSAR implement CanTp block. Messages that do not fit into a single CAN frame are segmented into multiple parts, such that each can be transmitted in a single CAN frame. This block provides services to perform the segmentation of I-PDUs whose size is greater than maximum allowed size for CAN. This block also provides services which reassembles the received PDUs which are then further transferred to application layer. It also has services to detect errors in segmentation. CanTP is based on  ISO 15765 which is standard in automotive domain. The PDUR determines whether to use this module or not and forwards the PDUs if needed.

4. CAN Interface (CanIf): It represents the interface to the services of CAN Driver for the upper communication layer. It provides unique interface to manage different hardware device types like CAN controller and CAN Transceiver according to ECU hardware layout. Thus multiple underlying internal or external CAN controllers/CAN transceivers can be controlled by CAN state manager. It controls CAN controller state transitions from CanSM and notifies state changes to upper layer. The CAN interface module consists of all the hardware independent tasks which belongs to the CAN communication device drivers of the ECU. These tasks are implemented once in the CAN interface module, so that underlying CAN device drivers can only focus on access and control of the corresponding specific CAN hardware device. CanIf fulfills main control and data flow requirements of the PDU router and upper layer communication modules of AUTOSAR COM stack. Requirements like: transmit request processing, transmit confirmation / receive indication / error notification and start / stop of a CAN Controller and thus waking up / participating on a network.

5. CAN Transceiver Driver: Whenever there is no on chip CAN transceiver, external CAN transceiver is used which can be on board. This block provides drivers such external on board CAN Transceiver chips. It supports CAN Transceiver chips which communicates on SPI.

6. Driver for external CAN ASIC: This as the name suggests will provide drivers for CAN application specific Integrated Circuit (ASIC). There can be cases when standard CAN Transceiver chip are not suitable for a application. In that case the this block comes in to picture. This is very rare case, majority of applications use standard CAN Transceiver chips. 

Below we will see the journey of CAN message from signal to ready to transmit CAN message.

Above figure is a very simplified figure of journey of a CAN signal to becoming a ready to transmit message. The signal is created by the application layer and sent via RTE to AUTOSAR COM, till here signal oriented interface lasts. Below layers cannot differentiate between signals and only understands PDU. So COM packs the signal into a PDU which is further transferred to PduR. PduR then transfers it to CanTp where if PDU is greater than the maximum allowed size of CAN frame, then it will be segmented in multiple PDUs or else will be transferred as it is to below layers. You should also notice the PDU name changes for each layer, I explained this in last post. If you are not sure of PDU name changes then you should check out PDU changes link. The reverse pattern is followed while receiving CAN message, except the CanTp will reassemble PDU segments into a single PDU and transmit to above layers. 

I hope I explained CAN communication stack in easy way. If you have any doubts then just ask it in comments box below. If find any errors in this page please report it. Mistakes and errors are certain as I am human and human is a statue of mistakes! 

Thanks for reading!!😊