Application Layer in AUTOSAR – AUTOSAR Tutorials Part 2

This article is the continuation of the Series on AUTOSAR Tutorials and carries the discussion on AUTOSAR. The aim of this series is to provide easy and practical examples that anyone can understand. In the last article, we have seen the Introduction to AUTOSAR. In this tutorial, we are going to see the Application Layer in AUTOSAR – AUTOSAR Tutorials Part 2.

Application Layer in AUTOSAR – Introduction

The application layer in AUTOSAR (AUTomotive Open System ARchitecture) is a crucial component within the overall software architecture of automotive systems. It is the top most layer in AUTOSAR Software Architecture, and it is responsible for executing the application software and managing the interaction between different software components. The application layer provides a standardized framework that enables seamless integration of various applications, such as vehicle functions, services, and features, across different ECUs (Electronic Control Units) in a vehicle. It helps to facilitate communication, data exchange, and coordination among these applications, ensuring the efficient and reliable operation of the entire automotive system.

This layer consists of many software components (SWC) which execute the set of tasks to fulfill the functionality of the vehicle. Each SWC contains many runnable. These software components (SWC) are connected with the help of ports. These ports give communication between two SWCs as well as with BSW.

application layer in autosar

Software Component (SWC)

The below image represents the typical view of Software component (SWC),

application layer in autosar

The software component is a small application that is created for some specific functionality in ECU. The main purpose of having a software component is to make the software independent of hardware and make the software reusable. while creating a new component type under the application component type in the DaVinci Developer tool, the developer needs to select either one of the types mentioned below.

There are 2 types of software components. they are,

  1. Atomic SWC
  2. Composition SWC

Atomic SWC

An atomic software component is a self-contained unit which is having application software. It encapsulates the implementation of the functionality. It only exposes the connection points to the outside world through the port prototype.

Under Atomic SWC there are a few sub-types,

  1. Application SWC – This is normal hardware-independent application software.
  2. Sensor/Actuator SWC – This is used to handle sensor and Actuator input/outputs.
  3. Non-volatile memory block SWC – This is used when we are using NVRAM.
  4. Calibration parameter SWC- This is used for sharing calibration parameter values with other devices.
  5. Complex device driver SWC- This is used when we are developing complex device drivers which are not supported by AUTOSAR.
  6. Service SWC- This is used when we are using services provided by the service layer which is placed in the BSW layer.
  7. Service proxy SWC- It serves as a proxy to one or more remote ECUs, providing internal services. Its primary function is to distribute vehicle mode information across the system.
  8. ECU abstraction SWC- This is used to access the I/O by directly interacting with specific BSW modules.

Composition SWC

Composition SWC is a group of individual software components combined into one software component to make the ECU. This type of grouping facilitates abstracting SWCs and standardizing software development.

Runnable Entity

 As discussed earlier, application software components are having certain entities, those are called as the Runnable, which are basically embedded c logics. During configuration with the help of tools, a skeleton is generated in respective source files of SWCs, later developers must write their logic inside the skeleton to run the specific task.

There are 3 types of runnable entities,

  1. Init Runnable
  2. Periodic Runnable
  3. Server Runnable
Init Runnable

The Init Runnable is an important part of the AUTOSAR architecture as it allows the ECU to perform the necessary tasks during the initialization phase and prepare for normal operation. These can be used to verify that the controller is properly configured and ready to perform its intended function.

Periodic Runnable

If an executable is configured as Periodic, it will be called periodically at the configured time.  So the developer needs to give the minimum interval during configuration.

Server Runnable

This is used to provide services to other components in the system. This is typically triggered by an external request, such as a request from another component to access certain data or perform a certain task.

Trigger points

While configuring runnable developers must mention the trigger point type as well as access points, and trigger points, it tells under which condition the runnable needs to be triggered or called. There are few types of trigger points are mentioned below,

  1. Init
  2. Periodic
  3. Background
  4. On-data reception
  5. On-data reception

Access point type

In case if the runnable wants to use the port prototype, the developer must mention the access point type. The types of access points are,

  1. Read data
  2. Write data
  3. Invoke operations
  4. Read received mode


In AUTOSAR, all communication between SWC and lower layers is done using ports. A port is a channel or connection used to transmit data between SWCs or BSW modules. Since AUTOSAR is intended for standardization, the data that will be transferred between entities must be known at configuration time. Ports belong to exactly one SWC at a time. The port may or may not be connected to the other end. Connectors are used to connect two ports.

There are two types of ports,

1. Required Ports(R-Port)- This type of port is used when data is to be received or required.

2. Provider Ports(P-Port)-  This type of port is used when data is to be transmitted or SWC is a provider of some service to other entities. 

Port Interface

The Port interface acts as a door between software components (SWC) to communicate with one another. The term Port Interface refers to the highest level of description of information transferred between components in an AUTOSAR system. The Port interface is reusable, and it is configured during the system configuration phase.

There are two types of port interfaces,

  1. Sender/Receiver interface
  2. Client/Server interface
Sender/Receiver interface

In this type of communication interface data elements are transferred from one software component to another. The data element type may be int, float, char, array, and record. This interface is mostly used between application software components. A port may contain many data elements. The communication between software components is 1: n or n:1.


Rte_Read_<port name>_<data element>

Rte_Write_<port name> _<data element>

Client/Server interface

The Client calls an operation of a Server asynchronously or synchronously. Communication between client and server is 1:1 or n:1. Operations can be called individually. This communication interface takes place most frequently between the application and services of the Basic Software (diagnostics, memory management, etc.). The operation may be requesting for turn on the light and get some data from memory, etc.,




To understand better the concept of SR Interface and CS Interface let’s take the below example,

We have two sensor actuators one is for right door motion and another one is for left door motion called Right Door Sensor, Left Door Sensor, and right Door Sensor is a Sender port(P- Port) it will write the door state and Left Door State, and the Right Door State is an SWC’s is a Receiver Port(R-Port) it will read the door state.

CDD SWC for the Right door state and CDD SWC for the Left door state are acting as Server Ports (P- Port) it will get the input from Actuators, and it will serve the door state and Interior Light state acting as a Client Port(R-Port) and it will get the interior light state whether it is ON or OFF based on door state.

Port Prototypes

Port Prototypes are intended to be used for attaching Software Connectors that establish an actual connection between SWC prototypes.


A connector is used to complete the connection between the port prototypes.

There are 2 types of connectors,

  1. Assembly connector
  2. Delegate connector
Assembly connector

Assembly connectors are used to connect two ports in a single software component. 

Delegate connector

Delegation connectors are used when some port of SWC needs to be exposed to the outer world of the Composition (ECU).


The application layer in AUTOSAR is a fundamental part of the automotive software architecture. Its main purpose is to execute application software and facilitate communication between different software components. It provides a standardized framework for integrating various vehicle functions, services, and features across multiple ECUs. The application layer plays a vital role in ensuring the efficient and reliable operation of the automotive system as a whole.

In our next article, we will discuss the Run Time Environment (RTE) Layer in AUTOSAR.

You can also read the below tutorials.

Linux Device Driver TutorialsC Programming Tutorials
FreeRTOS TutorialsNuttX RTOS Tutorials
RTX RTOS TutorialsInterrupts Basics
I2C Protocol – Part 1 (Basics)I2C Protocol – Part 2 (Advanced Topics)
STM32 TutorialsLPC2148 (ARM7) Tutorials
PIC16F877A Tutorials8051 Tutorials
Unit Testing in C TutorialsESP32-IDF Tutorials
Raspberry Pi TutorialsEmbedded Interview Topics
Reset Sequence in ARM Cortex-M4BLE Basics
VIC and NVIC in ARMSPI – Serial Peripheral Interface Protocol
STM32F7 Bootloader TutorialsRaspberry PI Pico Tutorials
STM32F103 Bootloader TutorialsRT-Thread RTOS Tutorials
Zephyr RTOS Tutorials – STM32Zephyr RTOS Tutorials – ESP32
AUTOSAR TutorialsUDS Protocol Tutorials
Product ReviewsSTM32 MikroC Bootloader Tutorial
VHDL Tutorials
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Newest Most Voted
Inline Feedbacks
View all comments
Table of Contents