AUTOSAR Architecture: How Modern Automotive ECUs Are Structured

AUTOSAR architecture is the standardised software framework that defines how modern automotive ECUs are structured — separating hardware abstraction, operating system services, network communication, and application logic into defined layers with standardised interfaces that enable software portability and reuse across different vehicle platforms and ECU hardware. Developed by the AUTOSAR consortium (including BMW, Bosch, Continental, Delphi, Ford, and more than 200 partner companies), the automotive software platform addresses the fundamental challenge that had plagued AUTOSAR ECU development before its introduction: each ECU supplier wrote proprietary, hardware-specific code that was inseparable from the hardware it ran on — impossible to reuse, difficult to validate independently, and expensive to maintain. AUTOSAR architecture solves this by defining a layered platform where application software components (SWCs) are written against standardised APIs, completely unaware of the underlying microcontroller hardware — enabling the same engine control software to be retargeted to a different MCU simply by replacing the AUTOSAR MCAL layer. Understanding the AUTOSAR architecture layers — MCAL, BSW, AUTOSAR RTE, and Application — is fundamental for engineers working in AUTOSAR ECU development, ECU testing, or automotive software validation.

AUTOSAR Architecture Layers Explained

The AUTOSAR architecture divides ECU software into four main layers. From hardware to application:

• AUTOSAR MCAL (Microcontroller Abstraction Layer): The hardware interface layer — AUTOSAR MCAL provides standardised C APIs for microcontroller peripherals: ADC (analogue-to-digital converter), PWM (pulse width modulation), SPI (serial peripheral interface), CAN driver, LIN driver, FlexRay driver, and memory drivers (Flash, EEPROM). AUTOSAR MCAL is the only layer that is hardware-specific; all layers above the MCAL are hardware-independent.
• BSW (Basic Software): The middleware layer of the automotive software platform — provides operating system (AUTOSAR OS, derived from OSEK), communication stack (CAN interface, PduR, Com modules for CAN bus message management), diagnostic services (DCM module implementing the UDS diagnostic protocol), NvM (non-volatile memory management), and watchdog services. The BSW is configured for each project using AUTOSAR configuration tools.
• AUTOSAR RTE (Runtime Environment): The virtual functional bus of the AUTOSAR architecture — AUTOSAR RTE is automatically generated code that routes Runnables (periodic or event-triggered software functions) and port connections between SWCs, and between SWCs and the BSW. Application SWCs call AUTOSAR RTE APIs (Rte_Read, Rte_Write, Rte_Call) without knowing whether the data comes from a local SWC, a CAN bus signal, or a sensor input — the automotive software platform RTE handles all routing transparently.
• Application SWC Layer: The functional software components — engine speed control, fuel injection management, gear shift logic, lamp output management — written by application engineers against the standardised AUTOSAR architecture APIs. SWCs are the most reusable part of AUTOSAR ECU development: the same SWC can be deployed on a different ECU hardware simply by reconfiguring the MCAL and regenerating the AUTOSAR RTE.

Classic AUTOSAR vs Adaptive AUTOSAR

AUTOSAR ECU Development and CAN Bus Configuration

In AUTOSAR ECU development, CAN bus communication is configured through the AUTOSAR BSW communication stack — not written as manual CAN driver code. The network topology is described in ARXML (AUTOSAR XML) files: the System Description file defines all network messages and signals (equivalent to a DBC file but in AUTOSAR format); the BSW module configuration tools generate the AUTOSAR MCAL CAN driver configuration, CAN Interface (CanIf), PDU Router (PduR), and COM module signal routing automatically. Engineers configure AUTOSAR ECU development workflows in tools (VECTOR DaVinci, EB tresos, ARCCORE) that generate the BSW and AUTOSAR RTE code from the graphical configuration — the application SWC developer never writes CAN register-level code directly.

AUTOSAR ECU Development Support with Precisol Automation

Precisol Automation's CAN to USB Adapter provides the CAN bus interface for AUTOSAR ECU development bench testing — connecting AUTOSAR ECU hardware to PC-based analysis tools for CAN signal monitoring, UDS diagnostic protocol testing, and ECU software validation. The CAN Data Logger captures complete CAN bus communication during AUTOSAR architecture integration testing and vehicle validation.

See automotive software platform validation in practice in our automotive ECU software validation case study, or explore ECU simulator applications where AUTOSAR ECU development bench testing uses Precisol CAN tools.

Frequently Asked Questions