CAN Data Transfer in AUTOSAR Classic Platform System

Introducing a mechanism that is sending data payload over CAN network, employed in modern AUTOSAR systems. Without going too deep into the implementation details, we would like to provide a short overview of basic principles.

When talking about modern general-purpose operating systems, such as Linux for instance, in many cases it is possible to find a shortcut in hardware accessing procedure. For example, device memory can be accessed directly from Linux user space if the corresponding device driver provides functionality to map device memory buffers directly into user process memory space.

AUTOSAR specification, however, is quite strict in this regard. An application is not allowed to access device memory buffers directly, but use strictly defined interfaces instead. The Picture below represents a typical simplified workflow.

Sender

As seen above, Sender code is not allowed to access CAN Driver module directly. Instead, it should do that only via the CAN Interface module. In fact, according to AUTOSAR specification, CAN Interface is the only module which is allowed to access CAN Driver.

CAN Interface module exports hardware independent API interface to the Sender code. API interface provides possibility for Transmit Request, Transmit Confirmation, Reception indication, CAN Controller mode and PDU mode control functionality.

At the same time, CAN Driver provides API interface to CAN Interface module. This API interface is also hardware independent. However, the CAN Driver module itself is working with a certain CAN hardware controller and therefore, is hardware dependent. When moving to a new hardware, it is sufficient to only update CAN Driver module and keep all the upper layers unchanged. Previously, in such situations a lot of code base is needed to be reimplemented. The AUTOSAR approach though, makes the development process simpler, faster and cheaper in terms of project life cycle and considered as a major advantage.

As mentioned above, for Sender code it is only sufficient to reference CAN Interface API calls in order to send payload to CAN bus without paying attention to hardware specifics. If Sender requires to transmit payload which is bigger than a single CAN frame size, it should segment it into smaller data chunks which are fit to frame size — or, in other words, pack data into CAN-TP protocol. Such segmentation, transmission control as well as data flow control are done by CAN Transport Protocol Layer — a typical user of CAN Interface module.

Once segmented data has reached the CAN Interface module, a CAN driver is requested to send it further to the chain. If transmit is allowed, data is then forwarded to CAN Controller, which forwards it to CAN Transceiver and in turn puts data to the CAN bus.

Receiver

Depending on configuration, the CAN Interface module can switch CAN Driver into either Interrupt mode or into Polling mode, or even into Mixed mode when CAN Driver utilises both approaches to notify upper layers about events — event driven and polling.

Before the message reaches the CAN controller on a Receiver side, the controller itself can be configured to filter out messages with IDs in which Receiver is not interested in. This is a useful feature in terms of reducing CPU cycles on a receiver side while processing incoming data traffic. Hardware filtering can be established via CAN Driver configuration parameter. In addition to hardware filtering, it is possible to optionally utilise software filtering as well. CAN Interface module can be configured to pass messages which have either one single specified message ID or messages with IDs from a given list or messages with IDs from specified range.

A standard CAN frame structure is shown in the picture above. Filtering is performed by analysing 11-bit Identifier fields for each incoming CAN message. Usually incoming filtering is done by applying a bit mask to Identifier value. Micro controllers build a filter in a vendor specific way. Some of them might invert the specified mask before applying it to the identifier, others may not.

It is worth mentioning that the CAN Controller can work either in FullCAN or BasicCAN mode. These terms are mentioned in specification, but not defined there. Instead, they are defined by manufacturers. The difference between the two is that FullCAN offers to Receiver multiple RX object buffers when each of them can be configured to receive frames with a certain ID. On the other hand, BasicCAN is represented by a large single FIFO buffer which can either be configured to receive a single or multiple CAN messages with specific IDs.

Once the message filtering stage is passed, the CAN frame reaches CAN Transport Protocol Layer on the Receiver side. At this stage, the Receiver is responsible for disassembling CAN-TP payload and turning it into the original data which was sent by the Sender.

References

1. Specification of CAN Interface AUTOSAR CP Release 4.3.1, https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SWS_CANInterface.pdf.

2. Specification of CAN Transport Layer AUTOSAR CP Release 4.3.1, https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SWS_CANTransportLayer.pdf