How a 2003 partnership of carmakers and suppliers built a shared software architecture for vehicle control units, from the Classic Platform to the Adaptive Platform for automated driving.
AUTOSAR is a global partnership founded in 2003 that defines an open software architecture for automotive electronic control units. Its three-layer design separates applications from hardware, and its Classic and Adaptive platforms serve embedded control and automated driving respectively. Members include major carmakers and suppliers.
AUTOSAR, short for AUTomotive Open System ARchitecture, is a global development partnership that writes open, standardised software architecture for the electronic control units in cars. Founded in 2003 by carmakers, suppliers and companies from the electronics, semiconductor and software industries, it aims to make vehicle software portable between manufacturers and suppliers, so that engineers can reuse code rather than rebuild it for every model.
What does AUTOSAR set out to do?
AUTOSAR specifies basic software modules, defines the interfaces that applications use and builds a common development method based on a standardised exchange format. Because the basic software can be used in vehicles from different manufacturers and components from different suppliers, the partnership argues that it reduces research and development costs. It also prepares the industry for technologies that have not yet arrived.
The partnership addresses a growing problem. Vehicles now carry dozens of electronic control units, and their software grows more complex as features are added. AUTOSAR tries to manage that complexity by making functions easier to integrate, transfer and update, while still meeting requirements for availability, safety and maintainability through the product's life.
A shared software architecture that lets carmakers and suppliers reuse code across models instead of rebuilding it for each vehicle.
Who founded AUTOSAR and how did it grow?
AUTOSAR was formed in July 2003 by BMW, Robert Bosch GmbH, Continental AG, Mercedes-Benz, Siemens VDO and Volkswagen to develop an open industry standard for automotive electrical and electronic architecture. Ford joined as a Core Partner in November 2003, and Peugeot Citroen and Toyota followed in December of the same year. General Motors joined as a Core Partner in November 2004.
The membership structure has changed since then. Continental acquired Siemens VDO in February 2008, so Siemens VDO was no longer independently represented as a Core Partner. In 2026 the Core Partners include AUMOVIO, BMW, Bosch, Denso, GM, Huawei, Mercedes-Benz, Toyota, Vector and Volkswagen, and those companies oversee the partnership's organisation and direction.
How did AUTOSAR releases develop over time?
The Classic Platform work has moved through three phases. Phase I, from 2004 to 2006, produced the fundamental standard in releases 1.0, 2.0 and 2.1. Phase II, from 2007 to 2009, expanded the architecture and methodology in releases 3.0, 3.1 and 4.0. Phase III, from 2010 to 2013, focused on maintenance and selected improvements, with releases 3.2, 4.1 and 4.2.
| Period | Focus | Releases |
|---|---|---|
| 2004 to 2006 | Fundamental development of the standard | 1.0, 2.0, 2.1 |
| 2007 to 2009 | Expansion of architecture and methodology | 3.0, 3.1, 4.0 |
| 2010 to 2013 | Maintenance and selected improvements | 3.2, 4.1, 4.2 |
| 2013 onward | Continuous working mode for the Classic Platform | Including R4.2 and acceptance tests 1.0 |
| 2016 onward | Adaptive Platform development | 17-03, 17-10, 18-03, 18-10 |
In 2013 the consortium moved the Classic Platform to a continuous working mode, which maintained the standard and added improvements as they were ready. Work on the Adaptive Platform began in 2016, with an initial release published in early 2017. Further releases followed in October 2017 and March 2018, and the major development activities were published with release 18-10 in October 2018. From December 2023 the releases became virtual, with events such as the R25-11 release event.
What is the three-layer architecture?
AUTOSAR uses three layers. The basic software holds standardised modules that have no explicit automotive job of their own, but provide the services that the functional software needs. The runtime environment, or RTE, is middleware that hides the network topology from the software, so components can exchange information within one control unit or across several. The application layer contains software components that interact with the runtime environment.
The architecture is designed so that applications do not need to know the details of the hardware or the network. An application talks to the RTE, which talks to the basic software, and that separation is what allows the same component to run on different hardware with different suppliers.
How is the configuration of a vehicle described?
AUTOSAR's methodology relies on three descriptions. The System Configuration Description holds all system information and the agreed details shared between control units, such as the definitions of bus signals. An ECU extract takes from that description only the information one control unit needs, for example the signals it can access. The ECU Configuration Description holds the basic software settings that are local to a specific unit.
Engineers use the ECU Configuration Description to build the executable software, generating the code for the basic software modules and the components that run on the unit. The foundation standard sits underneath all of this, providing common requirements, technical specifications such as protocols and the shared methodology.
What is the Classic Platform?
The Classic Platform is the standard for embedded real-time control units based on OSEK. Its main output is specifications. The application layer is largely independent of hardware, and communication between components and the basic software goes through the RTE, which is the complete interface for applications.
The basic software is divided into three main layers, plus complex drivers. Services form the top layer and are grouped into functional areas for system, memory and communication. Below them sit the electronic control unit abstraction and the microcontroller abstraction. A central idea is the Virtual Functional Bus, an abstract set of runtime environments that are not yet assigned to any particular unit. Applications map their interfaces to ports on this bus, so they do not need detailed knowledge of the lower technologies.
The Classic Platform can also integrate systems that are not AUTOSAR-based, using the Franca Interface Definition Language. This allowed links to GENIVI, which has since been renamed COVESA.
What is the Adaptive Platform for?
The Adaptive Platform was developed for new use cases that the Classic Platform could not handle. Automated driving is the main example. An automated system replacing the driver must communicate with traffic infrastructure, traffic centres and cloud servers, and it must process large volumes of sensor data, plan driving strategies and monitor the health of its systems. That requires high-performance computing hardware, such as multicore processors or graphics processing units.
Car-to-X applications add demands for secure on-board communication, cross-domain computing, smartphone integration and secure cloud interaction. Remote diagnostics, over-the-air updates and repairs also need dedicated services. The Adaptive Platform supports dynamic deployment of customer applications and uses a core operating system based on the POSIX standard, following a profile of IEEE1003.13 called PSE51. It is built on service-oriented architecture, and it is written in C++, with in-vehicle networking carried by SOME/IP over Ethernet.
The Adaptive Platform includes both specification and code. Unlike the Classic Platform, the Adaptive side ships with working code that speeds up validation and makes the underlying concepts easier to see, and every partner can use it. Its services include update and configuration management, state management, network management and diagnostics.
Who makes AUTOSAR software?
Vendors supply the real-time operating systems, basic software, design tools and compilers that build on the standard. Named suppliers include Elektrobit, which is now part of Continental, ETAS, which is part of Bosch, KPIT Technologies, Siemens, which previously owned Mentor Graphics, Vector Informatik and Tata Technologies. Related tool companies such as dSPACE and MathWorks supply testing, diagnostic and development software.
The partnership also faces rivals. Automotive Grade Linux, the GENIVI Alliance and the COMASSO organisation, which provides an open source AUTOSAR platform, are among the consortia that address overlapping ground.
