The Problem That Created AUTOSAR
In the early 2000s, a major European OEM developing a new vehicle platform faced a systemic challenge. Twelve Tier-1 suppliers were delivering ECUs across braking, steering, body, and powertrain domains. Each supplier had built proprietary communication stacks and hardware abstraction layers locked to specific microcontrollers. Swapping one radar supplier meant rewriting the entire ADAS ECU software stack from scratch.
Multiply this across 30 vehicle programs, 40 ECUs per vehicle, and annual platform refreshes software reuse was close to zero and development costs were spiraling. With ISO 26262 emerging on the horizon, the lack of standardisation across suppliers was becoming a serious liability.
In 2003, a consortium of OEMs and Tier-1 suppliers, BMW, Bosch, Continental, Daimler, Ford, Siemens VDO, Toyota, Volkswagen, and others, came together to solve this. They created AUTOSAR: AUTomotive Open System ARchitecture. The goal was to define a standard software architecture for automotive ECUs that separates application software from hardware, enabling components to be developed independently of the underlying microcontroller and reused across ECU generations and vehicle programs.
What AUTOSAR Is and Is Not
AUTOSAR is a software architecture standard and a set of specifications. It defines how software shall be structured, how components shall communicate, what standard services shall be provided, and how configurations shall be described in ARXML (AUTOSAR XML) files.
AUTOSAR is not a software product you download and install. It is not an RTOS, a compiler, or an IDE. The actual software implementing the AUTOSAR specification is delivered by commercial vendors, Vector Informatik (MICROSAR), ETAS (RTA-BSW), and Elektrobit (tresos) among others. In practice, “we use AUTOSAR” means: “we have licensed a commercial AUTOSAR stack, configured it using AUTOSAR-compliant tooling, and structured our application code to interface with it via the standard RTE.”
AUTOSAR Classic
Classic AUTOSAR was the original specification, designed for microcontroller-based ECUs, engine controllers, body control modules, brake controllers, and HVAC units. These ECUs run on MCUs such as the Renesas RH850, Infineon AURIX, or NXP S32K, with fixed software configurations, deterministic real-time behaviour, and static communication matrices.
Classic AUTOSAR uses an OSEK/AUTOSAR OS, a static, priority-based real-time operating system where tasks, alarms, and resources are configured entirely at build time. There is no dynamic memory allocation, no runtime task creation, and no service discovery. Everything is pre-determined, which is exactly what functional safety and determinism demand. Classic AUTOSAR remains dominant across the majority of production ECUs today.
The Classic architecture comprises distinct layers, each with a specific responsibility:
MCAL (Microcontroller Abstraction Layer): The lowest software layer, containing drivers for every MCU peripheral, ADC, PWM, CAN, SPI, Flash, and Watchdog. It presents a standard API upward regardless of which MCU sits beneath. Changing the target MCU ideally requires swapping only the MCAL.
ECU Abstraction Layer: Abstracts the ECU’s specific hardware topology. The I/O Hardware Abstraction (IoHwAb) module provides a hardware-neutral interface for reading sensors and commanding actuators.
Services Layer: The heart of Classic BSW, providing AUTOSAR OS (task scheduling), Communication Stack (CAN/LIN/FlexRay handling), Diagnostic Stack (UDS, DTC storage), Memory Stack (NvM, Flash emulation), and ECU state management.
Complex Drivers: A pragmatic escape hatch for hardware with timing requirements too specific for standard MCAL abstraction — radar front-ends, display controllers, and motor commutation logic.
RTE (Runtime Environment): The Virtual Function Bus that completely decouples Application SWCs from BSW. SWCs communicate only through declared ports; the RTE generator produces the glue code routing data between them.
Application Layer: Contains the actual vehicle function logic as Software Components (SWCs). A well-written SWC contains zero hardware-specific code and can be validated on a PC simulation environment before target hardware exists.
AUTOSAR Adaptive
As vehicles incorporated high-performance compute platforms, ADAS domain controllers, V2X gateways, central compute units, running Linux or QNX on multi-core ARM Cortex-A processors, Classic AUTOSAR’s static model became a constraint.
Adaptive AUTOSAR, introduced in 2017, addresses this by targeting POSIX-compliant operating systems. It introduces a Service-Oriented Architecture (SOA) where applications expose and consume services dynamically at runtime, communicating over Ethernet via SOME/IP. Applications can be updated over-the-air without rebuilding the entire ECU software image.
Critically, Adaptive does not replace Classic, they coexist. A centralised compute platform might run Adaptive AUTOSAR on its main application processor while peripheral zone ECUs continue on Classic, communicating across the vehicle Ethernet backbone. Most vehicle architectures will remain hybrid for at least the next decade.
What Comes Next
This article has covered the foundational architecture and layers of both AUTOSAR Classic and Adaptive. In the next article in this series, we will explore the AUTOSAR development toolchain, the ARXML-driven workflow, BSW configurators, RTE generation, and how the entire process comes together from system design to ECU flash.