Network Dependent Block of Communication Stack for CAN

Translate in your language

In my last article, we have discussed generic and bus independent blocks of AUTOSAR Communication stack in brief. If you have not read that article, then I recommend reading it before going further.    

CAN Communication stack 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 lower level operations like: which bus is used, or if the data to be transmitted will not fit in CAN frame, etc. These lower level operations are handled by Communication stack. CAN communication stack supports standard CAN as well as CAN FD (if supported by hardware).
Com Stack for CAN
Fig:Network Dependent blocks for Com Stack - CAN

Above figure shows the detailed layers involved in CAN communication stack 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 will have their own respective bus dependent blocks but network/bus independent blocks will be reused. Lets see each block in brief :

1. CAN NM: This is CAN dependent module but it is hardware independent i.e. it will be used only if CAN bus is used in the application but its software implementation is hardware independent. 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 implementing a service to detect all present nodes or check if all nodes are ready to sleep. CAN NM function provides a adaption layer between Network management Interface (Nm) and CAN Interface (CanIf). 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 article. If you want to get understanding of generic Network Management then check out this link.

2. CAN State Manager (CanSM): AUTOSAR BSW provides a specific state manager for respective bus/network. CanSM is used to change modes of CAN network. In ECU, there can be multiple communication network/buses and each network has a unique network handle associated with it. The ComM module keeps track of communication modes of network by requesting from such network handles. 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 network. 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 implements 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 by unpacking signals from it. CanTp also has services to detect errors in segmentation. CanTP is based on  ISO 15765 which is standard for CAN. The PDUR determines whether to use this module or not by considering the size of PDU, if the PDU fits with a single CAN frame then it is forwarded directly to next module instead of CanTp module or if the PDU don’t fit in single CAN frame then that PDU goes through CanTp and then to lower layers. Same mechanism is followed when PDU is received.

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 (CanSM) uniformly. 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 in a MCU, external CAN transceiver is used which is generally on-board of ECU. This block provides drivers for 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 chips are not suitable for a application, in that case 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 message which is ready to transmitted:

Simplified journey of a CAN signal from Top layer to lowest layer
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 because in this case PDU is assumed to be greater than the maximum allowed size of CAN frame, then it will be segmented in multiple PDUs.You should also notice the PDU name changes for each layer, I explained this in other article. 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 please ask it in comments box below. 
 
If you 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!!😊

Like us on Facebook!

Subscribe for newsletters!

8 thoughts on “Communication Stack – CAN”

    1. Admin_Alpha

      Hi Pradhan,
      Thank you for your kind words! Please do subscribe for future articles and like on facebook to be in touch

      Reply

Let me know your comments or doubts...

This site uses Akismet to reduce spam. Learn how your comment data is processed.