Autosar(Automotive Open Source Architecture) is a global partnership of ECU development entities related to the automotive SW industry. Autosar permits the handling and management of complexity of E/E architectures to increase reusability and interchange of ECUs architectures among OEMs or suppliers.

Autosar promotes architecture standardizations that yield improvement of performance, safety, security, and environmental care for complex automotive systems.

In the SW context, Autosar allows to:

  1. Decouple Software (SW) and Hardware(HW) by the abstraction of HW drivers and services management inside different layers of basic SW modules.
  2. Decouple of SW entities with different common functionalities by horizontal grouping.
  3. Reuse of SW that improves quality and efficiency.

To illustrate more how Autosar decouples HW and SW, a system without Autosar standardized architecture is shown in the following image, the SW is highly dependent on the HW specifications, so reusability is mostly impossible and the SW development might be inefficient. When “migrating” to an Autosar architecture system, SW is decoupled against the HW detailed specs and it is further divided into basic SW and application SW. This permits a high rate of reusability that yields a high degree of efficient SW development.

Autosar Features

Autosar principal features are:

  1. Architecture: SW architecture with configurable basic SW, a middleware called RTE (Run-Time Environment) to handle the communication, and application SW design.
  2. Methodology: ECU description formats and templates to configure processes of basic SW and application SW integration.
  3. Application interface: Standardized interface set to application communication to use on a wide variety of automotive domains.
  4. Tests: acceptance test to validate the behavior of Autosar communication and application SW.

Principal challenges of Autosar are the infrastructure support solution, highly automatized complex systems, Car2X applications, hard real-time systems, high-velocity transmission, and systems with frequent interaction from sensors, actuators, and other ECUs.

To support these highly demanding systems types, Autosar relies on 4 pillars to form the standard solution for the automotive ECUs development:

  1. Functional Safety: mature safety features such as robust watchdog, safe E2E communication, and so on.
  2. Efficiency: Flexibility based on the use of Complex Device Drivers and cost-effectiveness by supporting different microcontrollers.
  3. Mature application: Established development process and improved quality due to widespread implementations.
  4. Performance: Hard real-time capabilities, event trigger support, and scalability by configurations.

Autosar Classic and Adaptive Autosar

Autosar architecture has two variations, Autosar Classic and Adaptive Autosar. Autosar Classic is focused on effective solutions while Adaptive Autosar is focused on flexible solutions.

Adaptive Autosar is out of scope for this introduction.

Autosar Layered Software Architecture

The following diagram is a simplified example of a system with AUTOSAR which involves two entities. SWCs and VBF.

Autosar Software Components (SWCs) is an application-level encapsulation of functionalities in conjunction with interfaces, the fulfillment of requirements, and Software Component description (SWCD) that implement a specific functionality of a system.For example, the image above indicate a high level view of the mechanisms, logic, and algorithms that are implemented to map the range of sensitivity and responsiveness of the throttle.

Besides the intra-ECU communication, the application might require communication with other ECUs so inter-ECU communication is available by the use of vehicle network protocols supported by Autosar (CAN, LIN, FlexGate, and Ethernet).

SWCs can contain multiple port clusters. These clusters can group interrelated interfaces. For example, there are 2 types of ports used in Autosar SWCs:

  1. Sender / Receiver are interface ports that support n: 1 or 1: n communication. This communication is based on the transmission of data elements. These data elements are sent by the sender and requested by the receiver through application runnable. The Sender / Receiver calls are synchronous and are performed in the same context as the sender. In this context, communication boundaries are ports that are configured based on runnable of the involved SWC.
  2. Client / Server are interface ports that support n: 1 communication, the call to a server is implemented from runnable of the server-SWC and can be synchronous or asynchronous, as well as using the same client context (unmapped server) or within another context (mapped server). Multiple clients can request/invoke services/functions from the server.

VBF (Virtual Bus Function) is the abstract mechanism that allows communication of SWCs inside an ECU or among ECUs.

Autosar architecture divides the application SW (ASW) and basic SW (BSW) to maintain flexibility and reuse by decoupling different contexts. BSW is further divided into different layers: Service Layer, ECU Abstraction layer, uC Abstraction Layer, and Complex Device Drivers. The following image shows the basic structure of Autosar SW Architecture.

The service Layer is the highest level of BSW cluster. The service Layer interacts with ASW through RTE. It contains the OS logic, Autosar stack managers, memory services, diagnostic services, state machine management, and logical program flow monitoring through Watchdogs.

The ECU Abstraction Layer supplies the APIS coming from the uC Abstraction Layer to the service layer regardless of the external or internal location of the specific uC peripheral.  

The uC Abstraction Layer contains all the internal HW drivers which are accessed by upper-level SW and permit direct access to the uC internal structure and peripherals. This layer permits a higher level of abstraction of HW drivers that avoids the SW dependency over uC specific specifications.

Complex Device Drivers provide the possibility of integrating special-purpose functionalities that are not specified by any Autosar stack or have high timing requirements or their migration does not allow integration on the Autosar stack. This layer is a direct extension from the drivers of HW to RTE.

RTE (Run-Time Environment) is the layer that permits service communication between ASW and BSW. RTE makes ASW independent from the ECU specific mapping.

ASW is a component style layer that contains all the application level SW components that are involved in specific features of the ECU. SW compositions are groups of several SW components connected together based on an associated feature/responsibility. The Sensor/Actuator SW component logic can monitor sensors or control actuators that cannot be defined on BSW so they are defined at ASW due to their strong dependency on local signals at the application level.

Autosar BSW stack and modules

An Autosar stack is the set of BSW modules that are in charge of a specific standardized feature. For example, the COM stack is in charge of the intra-ECU or inter-ECU communication. COM can be subdivided based on the supported vehicle network protocols (CAN, LIN, FlexRay, Ethernet).

Autosar classic can be subdivided into the following type of stacks:

  1. I/O stack. Standardized access to sensors, actuators, and onboard peripherals from external devices connected to the uC.
  2. Memory stack. Standardized access to uC internal/external memory.
  3. Crypto stack. Standardized access to cryptographic primitives or drivers including external HW accelerators such as Hardware Secure Modules (HSM)
  4. Communication stack. Standardized access to vehicle network systems such as CAN, LIN, FlexRay, and Ethernet. 
  5. Off-board communication. Standardized access to Vehicle-X-communication, wireless connection, or general ECU off-board communication systems.
  6. System communication. Standardized process of ECU operating system, timer, error memories, error logs, ECU state management, ECU external/internal watchdog, and library functions.

BSW shall ask for uC internal/external resources by APIs that access the HW driver. Examples of internal drivers can be EEPROMs, ADC samples of a signal, and embedded controllers of CAN, LIN, or Ethernet. Examples of external drivers can be SBCs (network protocol transceiver and external watchdogs). Abstractions of internal drivers are positioned at the uC abstraction layer; whereas the external drivers are positioned at the ECU abstraction layer.

BSW is divided also by functional groups as the following image shows:

BSW Layers Overview

Service Layer Overview

The service layer is the principal source of basic services that are used by the SWCs from the ASW layer. The service layer offers OS functionality, vehicle network communication services, memory services, diagnostic services, and ECU status management services. These services can be group as follows:

  1. System services: is a module group which interfaces can be used by any layer to read the OS status, error handling, event handling regarding diagnostic, watchdog, and intra-communication. The modules of system services are Autosar OS, ECU state manager (EcuM), Diagnostic Event Manager (DEM), Function Inhibition Manager(FIM), Default Error Tracer (DET), Synchronized Time-based Manager(StbM), Time Services (Tm), WatchdogManager (WdgM), Communication Manager (ComM) and Basic SW Mode Manager (BswM).
  1. Memory Services consists only of the NVRAM Manager which is responsible for the correct write/read of non-volatile data of different memory abstraction layers.
  1. Communication Service is a module group for all the vehicle network communication (CAN, LIN, FlexRay, Ethernet) that enables the interface between the HW abstraction and diagnostics. There are also communication modules to handle the communication between ASW and BSW. The modules of the Communication Services cluster are RTE transformers (SOME/IP transformer, Com based transformer, and E2E transformer), Secure Onboard Communication, IPDU Multiplexer, Large Data COM (LDCOM), PDU Router (PDUR), Diagnostic COM Manager (DCM), Diagnostic Log and Trace (DLT), Generic Network Manager and state/network managers for the supported bus transport protocol.
  1. Crypto Services based mainly by the Crypto Service Manager (CSM) that is responsible for the crypto “job” handling and key management. CSM jobs are abstractions that are grouped together with a specific CMS key, CSM queues, and CMS primitives.
  1. Off-board communication services facilitate the functionality by defining interfaces for reception and transmission of standardized V2X communication or any transport protocol layer for geo-networking. Modules of this kind of service are V2X Management, V2X facilities, V2X Basic Protocol, and V2X Geo Networking.

ECU Abstraction Layer Overview

The ECU abstraction layer provides interfaces of all drivers from the uC Abstraction Layer to the Service Layer. This layer also contains interfaces from external drivers and peripherals that the uC Abstraction Layer cannot support.

The ECU abstraction layer is composed of the following clusters:

  1. Onboard Device Abstraction, contains an abstraction of ECU onboard devices that cannot be considered as sensors or actuators.
  2. Memory Hardware Abstraction, contains abstractions of any peripheral memory devices, either external or internal. The memory drivers are accessed by emulators or abstracted modules. There are also EEPROM emulation APIs.
  3. Crypto HW Abstraction, is a group of modules that abstract crypto primitives by internal access of device drivers.
  4. Wireless Communication HW Abstraction, contains abstractions to wireless communication.
  5. Communication Hardware Abstraction is a group of modules that abstract interfaces by independent allocation (on-chip/on-board) bus access channels.
  6. I/O Hardware Abstraction is a group of modules that abstract I/O devices regardless of their location, either on-chip or on-board by I/O signals representations that are connected to the ECU HW (current measurement, frequency monitoring, etc). These abstractions do not abstract special sensors or actuators allowing that these component types are delegated to SWCs at ASW.

Microcontroller abstraction layer

The microcontroller abstraction layer is the lowest layer of BSW and contains all the uC internal drivers so by means of this, can access all peripherals of the uC directly. The principal objective of this layer is to make functions that are used by services and interfaces independent from the uC HW. This layer is composed of the following clusters:

  1. Direct uC Drivers. Hw drivers that interact with microcontroller resources.
  2. Memory Drivers.HW drivers that interact with memory devices such as external EEPROMs or emulated flash memories.
  3. Crypto Drivers. HW drivers that interact with security devices to optimize cyber-security functions.
  4. Wireless Communication Drivers. HW drivers that interact with wireless or V2X transceiver or devices.
  5. Communication Drivers. HW drivers that interact with transceivers to support specific vehicle network protocol communications.
  6. I/O Drivers. Digital or analog HW drivers to interact with signals for system or functional processes.


RTE is the middle layer that provides communication between SWCs and BSW, making all the SWCs of ASW be independent of the ECU mapping. When an SWC requires to send data to the current ECU (or another ECU), RTE handles and transforms this data on the BSW configurations. For example, one communication flow could be:

  1. SWC sends an output signal from its own logic.
  2. RTE calls Some/IP transformer.
  3. Some/IP transformer converts the signal type data to be a byte array and it saves the data into a buffer.
  4. The byte array is configured to be used by the Safe Transformer to add some data E2E protection mechanisms.
  5. Depending on the configuration, an in-place buffer is used or not to maintain the transformed buffers.
  6. Move through the transformers chain if there are some other transformations required.
  7. When the data is fully transformed, RTE transfers the data into COM.
  8. COM serialize the data coming from RTE based on the configured communication matrix.

Additional Concepts

BSW module types

When reading the BSW modules specs, it is important to denote the following types:

  1. The driver contains the functionality to control and access different data and peripheral internal or external uC resources.
  2. The interface contains the functionality of abstract components or modules with lower levels of abstraction. These interfaces shall not change the context of the data content and they are normally found at the ECU abstraction layer to abstract drivers.
  3. The handler is a specific interface to control the async or sync access from multiple clients to one or more drivers without changing or allowing the change of data content.
  4. The manager contains the service source interfaces as the handler does but a manager allows changes of data content.

Autosar Libraries

Autosar libraries are a complementary collection of functions that can be accessed by all the BSW, RTE, and ASW modules and are related for different purposes. Usually, Autosar libraries contain no complex implementation, do not have state or require initialization, and are synchronous. Some examples of Autosar libraries are: Fixed and float point mathematical functions, interpolation of fixed and float point data, bit handling, and extended solutions based on the different uC architectures.