In this article we will discuss about the communication services in AUTOSAR w.r.t. CAN protocol. Generic functionality of AUTOSAR COM and PduR module is explained in the previous article. In this article I will limit myself to CAN Interface(CanIf) and CAN Driver(CanDrv) modules. Other modules of ComStack pertaining to CAN protocol will be explained in the coming articles.
Communication stack w.r.t. to CAN protocol in AUTOSAR consist of different modules like AUTOSAR COM(Services Layer), PDU Router(Services layer), CAN State Manager(Services Layer), CAN Network Manager(Services Layer), CAN Transport Protocol(Services Layer), CAN Interface(ECU Abstraction Layer) External CAN Driver(ECU Abstraction Layer) and CAN Driver(MCAL Layer). Some modules related to diagnostics, PDU multiplexing and CAN Transceiver are also part of the stack.
Communication Stack – CAN
CAN Interface(CanIf) is a module in the ECU Abstraction Layer which is responsible for services like Transmit Request, Transmit Confirmation, Reception Indication, Controller mode control and PDU mode control.
Basic terms used in CanIf :
Hardware Object Handle :
Hardware Object Handles (HOH) for transmission (HTH) as well as for reception(HRH) represent an abstract reference to a CAN hardware object structure, that contains CAN related parameters such as CanId, DLC and data. During transmission these handles are known as Hardware Transmit Handles(HTH) and during reception Hardware Receive Handles(HRH). CanIf calls CAN driver interfaces using these abstract references and never uses the actual hardware CanId, hence CanIf remains hardware independent.
BasicCAN and FullCAN :
CanIf distinguishes between BasicCAN and FullCAN handling for activation of software acceptance filtering.
A CAN Hardware Object for FullCAN operation only enables transmission or reception of single CanIds.
A CAN Hardware Object for BasicCAN operation of one Hardware Object enables to transmit or receive a range of CanIds.
BasicCAN and FullCAN objects can coexist in a single configuration setup.
CanIf abstracts the CAN hardware object i.e. the CAN frame structure from the MCAL CAN driver using abstract handles called Hardware Object Handles(HOH). It routes the PDU to different CAN controllers and transceivers. It controls the CAN controller state transitions request from CANSM and communicates the state changes to upper layer.
In case of Transmission of a PDU, CanIf is responsible for mapping the Hardware Transmit Handles to the CAN hardware objects, determining the CAN driver on which the PDU has to be transmitted, triggering a call to Can_Write api. Once the Can_Write is completed, notifying the upper about the transmission status of the PDU.
In case of Reception of a PDU, CanIf is responsible for filtering of the received PDU, DLC check, buffering of the received PDU and indicating the upper layer about the PDU reception. Most of these features provided by CanIf are configurable.
CAN Driver(CanDrv) module is a part of the MCAL layer and provides hardware access to the upper layer services and a hardware independent interface to the upper layers. CanIf is only module that can access the CAN driver.
It controls the transmission of CAN frames on the hardware and notifies the upper layer of reception by calling the callback functions. It also provides the interfaces to control the state of the CAN controllers.