Communication Stack – CAN
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.
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.
Below we will see the journey of CAN message from signal to message which is ready to transmitted:
