What is AUTOSAR ComStack? Understanding Communication Within Layers of AUTOSAR Architecture

This blog is part of a series of articles that will attempt to introduce you to the various aspects of the world of AUTOSAR!

AUTOSAR Architecture was introduced to promote standardization in the software development process of Automotive Electronic Control Units (ECU).

Prior to the introduction of AUTOSAR standard, ECU software functions had to be rewritten completely at the time of migration to a new hardware platform.

AUTOSAR Architecture introduced the concept of AUTOSAR MCAL (Microcontroller Abstraction Layer) to ensure that application software was completely independent of the hardware platform. This, in turn, made the software reusable and modular.

Another core aspect of the AUTOSAR architecture is ECU Communication. We will discuss this aspect in detail with the help of AUTOSAR Communication Stack.

Overview of the Software Layers based on AUTOSAR Architecture

As per the Layered AUTOSAR Architecture, the software development is implemented as per the following modules (layers)  (bottom-to-top):

• Basic Software (BSW) Layer – This consists of the following:
  • Microcontroller Abstraction Layer (MCAL)
  • Electronic Control Unit (ECU) Abstraction Layer
  • Services Layer
  • Complex Device Drivers
• Run-Time Environment (RTE)
• Application Layer

Understanding a Generic AUTOSAR Communication Stack (ComStack)

In the AUTOSAR layered architecture, Communication Stack or ComStack facilitates vehicle network communication.

Hence, ComStack can be defined as a software stack that provides communication services to the Basic Software Modules and Application Layer/Application Software.As shown in the AUTOSAR Architecture diagram below, AUTOSAR Communication Stack is part of the BSW (Basic Software) Module:

A typical AUTOSAR Communication Stack has its modules in three sub layers of the Basic Software Layer:

• Services Layer
• ECU Abstraction Layer
• MCAL

Some of the important software modules in this stack are as follows:

• AUTOSAR COM – part of the Services Layer
• Bus Specific Interface Modules – part of the ECU Abstraction Layer (For example -CANIF, LINIF)
• External Bus Drivers – part of the ECU Abstraction Layer (For example – External drivers like CANDrv, LINDrv, FlexrayDrv)
• Bus Transceiver Driver – part of the ECU Abstraction Layer
• Internal Bus Drivers – part of the AUTOSAR MCAL (For example – CANDrv, LINDrv, FRDrv)

Sub modules such as Bus Network Management, Bus State Manager, Bus Transport Protocol, Bus Interface and Bus Driver facilitate the communication. Each of these modules has specific roles to play.

What is CAN Communication Stack in AUTOSAR Architecture?

When the target Bus type for an AUTOSAR compliant software is CAN, the ComStack implementation is executed with respect to CAN Bus. Right from the Interface (IF) and State Manager to low-level drivers, each of these modules need to be configured for CAN Bus.

The following diagram depicts the CAN based Communication Stack (ComStack):

List of different modules of the CAN Communication Stack:

• 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)
• CAN Transceiver Driver (ECU Abstraction Layer)
• CAN Driver (MCAL Layer)

Learn More about the CAN ComStack Software Modules:

1. AUTOSAR COM: AUTOSAR COM is a module between the RTE and the PDU Router. It is based on OSEK COM specification and provides a uniform interface to the CAN Network. It is responsible for providing Signal level access to the application layer and PDU level access to the lower layers, independent of the protocol.It packs the signals to a PDU at the transmitter and unpacks the received PDU to provide signal level access to the application at the receiver. At the PDU level, COM is responsible for grouping of the PDUs, and starting/stopping of the PDU groups.
2. PDU Router: PDU Router is a module responsible for routing the PDU to the respective Bus Specific Interface modules.Above the PDU Router module, all the PDUs are protocol independent. Below the PDUR, all the PDUs are routed to the protocol specific modules.

   PDUR is also the PDU level gateway for transmitting the received PDU from one Bus Specific Interface module to another Bus Specific Interface module.

   The PDU Router also accomplishes the gateway functionality when the PDU is routed from one controller to another over the same protocol.

3. CAN TP: The basic services offered by the CAN TP module are segmentation of messages which have a payload of more than 8 bytes, transmission of the messages with flow control and reassembling the segmented messages at the receiver.
4. CAN Interface: 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.
5. CAN State Manager (CANSM): This module implements the control flow for the respective Bus. The CAN State Manager is a member of the Communication Services group of modules.CAN State Manager handles the start-up and shutdown features that depend on the communication system. It also regulates the various options of COM for sending PDUs and monitoring signal timeouts.
6. CAN NM: The AUTOSAR CAN Network Management is a hardware independent protocol tool that can only be used on CAN network.It coordinates the transition between normal operation and bus-sleep mode of the network. The CAN Network Management (CANNM) function provides an adaptation between Network Management Interface (NMIF) and CAN Interface (CANIF) modules.
7. CAN Transceiver Driver – The primary functionality of the CAN Transceiver Driver includes controlling the external CAN transceiver hardware. The wake-up and sleep processes of the CAN Bus are regulated by the CAN Transceiver Driver. This driver also observes the BUS line and transmits physical network layer diagnostic information to the upper layers.
8. CAN Driver (CANDrv): This 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 the only module that can access the CAN Driver.

Conclusion

AUTOSAR software components are designed as plug and play components and standardized communication is the key here. In the future automotive architecture, we can witness a reduced number of control units, thanks to advancements in communication within AUTOSAR architecture (Virtual Function Bus and RTE).