Communication Stack Overview

The communication stack is a prime example of how the Autosar layered architecture works. Learn how to go from Software Component data to CAN bus here

One of the most important abilities of an ECU is to communicate with the outside world. If you have learned about Software Components (if not, here is a good place to start Types of Software Components (opens in a new tab)), you know you won't care about which is the underlying hardware that will communicate with the outisde world. You just want to send and receive data. For this, Autosar implements a group of BSW (Basic SoftWare) modules, which make up the communication stack (COM stack, for short). The idea of this stack is not only to create indirection at the SW-C level. As long as you have an upper layer, you add a level of indirection, which makes reusability easier, the act of not having to reconfigure everything every time you have a new project. Today, we'll look at the very essential COM stack modules, the bare minimum for you to communicate.

In a working environment, the communication stack gets partially configured through a file delivered by the OEM (if you are a tier 1, let's assume that's the case), such as a dbc (database CAN). The dbc is a readable file that contains all the information on the CAN bus messages of a specific ECU, or vehicle network. There are a lot of people involved in reverse-engineering these files, so that one can learn about their vehicles. You can check an example of this in the opendbc (opens in a new tab) repository. Maybe, you can even check if your car is part of the list and have a fun weekend project. Bottom line, this file "somehow" (let's leave it this way, it's not the scope of this article and we'll cover it eventually) gets converted to ARXML and imported into your Autosar environment. Often, this ARXML file does not contain all the necessary information and you will have to go manually and solve the problems within the COM stack, or even add PDU's and signals, in a worst-case scenario situation. This is where knowing the COM stack comes in handy.

Another scenario where knowing the COM stack is useful is while debugging it. Imagine that your messages do not reach their destination correctly, in any direction. You will have to verify the COM stack from the top to bottom (or bottom-up, depending on the direction of your communication). You will have to verify which is the point of failure inside the stack, and reconfigure it in a way to make it work. Bottom line, it's an important part of the layered architecture to master.

So, after this thorough explanation, this is the COM stack (at least partially, as there can be more modules involved, which we'll introduce gradually in future article, but to simplify and make it understandable more easily, today we'll look at this partial implementation), with a possible path of communication highlighted:

Modules involved in the Autosar communication stack (simplified)

In the picture, you can see a possibility of the modules involved in sending and receiving data from a Software Component to the CAN bus signals. Let's go one by one, the modules involved:

• Software Component (SW-C) - The SW-C wants to communicate, so, it uses the sender-receiver ports to output data into the RTE, which will take care of forwarding the data into the respective BSW module. Keep in mind, the sender-receiver interface is not just limited to COM communication. You can exchange data to other SW-C's through this mechanism, for example. If you want to learn more about ports and interfaces, you can check our article Types of Interfaces and Ports (opens in a new tab).

• RTE (Run-Time Environment) - Makes the bridge between the application layer and the BSW.

• COM (COMmunication) - Sitting between the RTE and the PDU Router, it defines all the signals used by the port in the Software component, and converts them into from data structures into a PDU, and vice-versa. Aside from this, it can group PDU's and allow you to control these groups, activating or deactivating them. It does not care about the underlying protocol the message is being transmitted from or received to.

• PDUR (PDU Router) - Routes the PDU's to the specific bus interfaces / transport protocols, in case of transmission, and to the upper-layers. One thing to keep into consideration is that you can direct the PDU's to multiple modules.

• CAN-TP (CAN Transport Layer) - Extends the capabilities of CAN, enhancing the limited PDU size, by segmenting PDU's longer than 8 bytes. And yes, the PDUR can communicate directly to CAN-IF, for PDU lengths up to 8 bytes. You can learn about the specifics of CAN-TP in our article CAN-TP Overview (opens in a new tab).

• CAN-IF (CAN Interface) - Responsible for configuring the CAN PDU parameters, such as the CAN-ID, the type of identifier, the CAN hardware object handles, and forwarding the PDU's to the upper layers, which can be the PDU Router, but you can also forward it to other modules, such as XCP (we covered the XCP module in the article What is XCP (opens in a new tab), if you want to learn more). It also handles the communication with the CAN transceiver, requesting the sending of PDU's and receiving an indication upon reception.

• CANTrcv (CAN Transceiver) - As part of the MCAL, it sends and receives data through the CAN bus. It abstracts the CAN transceiver hardware. You can learn more about the CAN protocol in CAN Protocol Overview (opens in a new tab)

In our example, you can see we limited our example to CAN communication, but Autosar also supports other communication layers, such as FlexRay, Ethernet and Lin. These modules all contain their specific BusTP, BusIf, and MCAL drivers. They have their own quirks, characteristic to the communication protocol.

As some final notes, we want you to understand that there can be more modules involved in the COM stack. Today, our main focus was to deliver a limited overview, with only the necessary modules for you to communicate. Some modules we left out are the CAN-SM (CAN State Manager) and I-PDUM (I-PDU Multiplexer), which we'll cover in the near future. For today, we hope you got to grips with the basics of the communication stack.

Author: Micael Coutinho (opens in a new tab)

References:

• Specification of Communication - Autosar Specification (opens in a new tab)

• Specification of RTE - Autosar Specification (opens in a new tab)

• Specification of CAN Interface - Autosar Specification (opens in a new tab)

• Specification of CAN Transceiver Driver - Autosar Specification (opens in a new tab)