AUTOSAR (Automotive Standard Software Architecture)
1. Overview
A. Definition
AUTOSAR (AUTomotive Open System ARchitecture) is an open automotive software platform standard that decouples the software of a vehicle's electronic control units (ECUs) from the hardware and enables reuse, portability, and collaboration through a standardized layered structure, interfaces, and exchange format. It began in 2003 with a development partnership formed by BMW·Bosch·Continental·Daimler·Ford·GM·PSA·Toyota·Volkswagen and others, grounded in the philosophy of "Cooperate on standards, compete on implementation."
The background for AUTOSAR's emergence lies in the rapid "softwarization" of the vehicle. Braking·steering·driving functions that were implemented mechanically·hydraulically until the 1990s shifted to electronic control, and the ECUs mounted in a premium car exploded to several dozen to a hundred-plus, with software scale growing to tens of millions up to 100 million lines (LoC). Yet because each ECU's software was tightly coupled to a specific microcontroller·supplier, inefficiency accumulated: whenever a part was swapped or a function moved to another ECU, the software essentially had to be rewritten. As the OEM, the first-tier supplier (Tier-1), and the semiconductor company (Tier-2) each developed with their own structures, integration·verification costs and recall risk also grew.
Therefore AUTOSAR's core idea is hardware abstraction — "let applications work without knowing the hardware" — and modularization, "software components (SWC) that can be assembled like parts." If application logic is described as components atop a Virtual Function Bus (VFB), and standardized middleware beneath it is made responsible for communication·memory·diagnostics·network, then even when the same function is relocated to a different ECU·different semiconductor, it can be reused without touching the application code. Beyond mere code reuse, this carries the meaning of industrial governance: fixing the division of roles and the collaboration contract among OEM-Tier-1-Tier-2 into standard interfaces.
B. Two generations of platforms — Classic and Adaptive
To understand AUTOSAR accurately, one must distinguish two platforms of different character. The Classic Platform (CP), developed since 2003, is a static structure for deeply embedded ECUs where real-time·high-reliability is required, such as braking·engine·airbag. Atop an OSEK/VDX-based real-time OS, all resources are fixed at build time, prioritizing determinism and functional safety ([[iso-26262]]). By contrast, the Adaptive Platform (AP), announced in 2017, is a dynamic structure for high-performance computing (HPC) ECUs that need high-performance computation and flexibility, such as autonomous driving·infotainment; it adopts a POSIX-based OS, C++, and a service-oriented architecture (SOA) to support runtime service discovery·OTA updates.
The fundamental reason these two are separated is that the "nature of the problems they handle" differs. Software controlling the wheels lives or dies by predictable response on the order of a millisecond and "never stopping," so static configuration and a simple execution model are advantageous. Conversely, software that fuses dozens of camera streams with deep learning to plan a path needs a rich runtime that leverages multicore·GPU and the update capability to continuously improve functions. AUTOSAR did not try to satisfy both requirements with a single structure; instead, it chose the path of letting two platforms of different purpose coexist while guaranteeing interoperability through a common base (Foundation). This separation is precisely the starting point for understanding the whole AUTOSAR structure.
2. Overall structure — Classic·Adaptive·Foundation and the methodology
The AUTOSAR standard consists of three standard bundles. The Classic Platform (CP), the Adaptive Platform (AP), and the Foundation (FO) which defines the common artifacts·conventions shared by the two platforms. On top of this, the Methodology that defines how software is described·configured·deployed, and ARXML (AUTOSAR XML), an XML format that exchanges all artifacts machine-readably, run through the entire process. In other words, AUTOSAR is a system made of two "execution platforms," one "common convention," and a "development methodology" that binds them.
graph TD
subgraph STD["AUTOSAR standard system"]
FO["Foundation (FO)<br/>common requirements·conventions·protocols(SOME/IP, etc.)"]
subgraph CP["Classic Platform (CP)"]
CPA["deeply embedded ECU<br/>static config·real-time·functional safety"]
end
subgraph AP["Adaptive Platform (AP)"]
APA["high-performance computing ECU<br/>dynamic·SOA·OTA"]
end
METH["Methodology & ARXML<br/>model-based description·config·exchange"]
end
FO --> CP
FO --> AP
METH --> CP
METH --> AP
CP -. "SOME/IP·DDS gateway" .-> AP
As the structure diagram above shows, Foundation defines the minimal intersection of common protocols and meta-model so that the two platforms can communicate·interoperate with each other. For example, the service-oriented communication protocol SOME/IP is specified in Foundation so that Classic and Adaptive can exchange services over Ethernet with the same convention. In the past each platform redundantly defined requirements on its own, but with the introduction of Foundation both sides reference a once-defined common convention, which reduces redundancy·inconsistency and secures the interoperability of CP↔AP mixed architectures.
The roles of the methodology and ARXML are also central. Before writing code directly, AUTOSAR first describes software components·ports·interfaces·ECU resources as a model in ARXML form, and from this model auto-generates RTE·communication-stack configuration code. In an actual mass-production project, the OEM delivers the system design to the Tier-1 as ARXML, the Tier-1 receives it and refines the ECU Configuration, and merges it with the MCAL settings supplied by the semiconductor company to generate the final binary. In this way ARXML is both a contract document that hands off design responsibility across companies and the input to automation, revealing that AUTOSAR is not a mere code convention but a "model-based collaboration methodology."
3. Classic Platform — layered structure and components
The backbone of the Classic Platform is thorough layering (layered architecture). In the topmost Application Layer goes function logic such as braking control·engine torque management, in units of software components (SWC, Software Component). Beneath it the Runtime Environment (RTE) relays communication between components and calls to the lower basic software; at the very bottom the Basic Software (BSW) provides communication·memory·diagnostics·OS·drivers, and the lowest-level microcontroller executes them.
graph TD
APP["Application Layer<br/>SWC(braking·steering function logic)"] --> RTE["RTE (Runtime Environment)<br/>VFB realization·inter-component comm relay"]
RTE --> SVC["Services Layer<br/>OS·comm·diagnostics·memory·NM"]
SVC --> ECUAL["ECU Abstraction Layer<br/>onboard device·driver abstraction"]
ECUAL --> MCAL["MCAL<br/>Microcontroller Abstraction Layer"]
RTE -. "direct access" .-> CDD["Complex Device Drivers (CDD)<br/>high-speed·special hardware direct control"]
CDD --> MCU
MCAL --> MCU["Microcontroller (hardware)"]
The core concept of this structure is the Virtual Function Bus (VFB). The application developer designs assuming that their SWC connects only logically to other components via "ports," without knowing which ECU·which communication line (CAN/LIN/FlexRay/Ethernet) it will ride on. Once the actual physical placement is decided, the RTE realizes the VFB, automatically connecting it as a function call if within the same ECU, or as a message routed through the communication stack if on a different ECU. Thanks to this, even when a "component that sends the braking-force signal" is moved from ECU A to ECU B, the application code does not change — this is the substance of the relocatability AUTOSAR advocates.
The Basic Software (BSW) is further divided into three layers plus one exception. At the very bottom, the MCAL (Microcontroller Abstraction Layer) wraps the registers·peripherals (ADC·PWM·SPI, etc.) of a specific MCU with a standard API so that the layers above do not know the semiconductor type. Above it the ECU Abstraction Layer abstracts external devices mounted on the board (sensors·transceivers, etc.), and the topmost Services Layer provides platform services such as OS·communication management·diagnostics (UDS)·memory (NvM)·network management. However, for cases such as high-speed cameras or special actuators that cannot tolerate the latency of the standard layers, the Complex Device Driver (CDD, Complex Device Driver) that bypasses the layers and directly controls the hardware is allowed as an exception. Thanks to this design of "abstracting the semiconductor with the MCAL," the OEM can keep the upper application as is even when switching the semiconductor supplier from Renesas to Infineon.
| BSW layer | Role | Representative modules·examples | Abstraction target |
|---|---|---|---|
| Services Layer | provides platform services | OS, Com, Dcm/Dem(diagnostics), NvM, NM | hardware-independent services |
| ECU Abstraction | abstracts onboard devices | upper driver wrappers, I/O handlers | external parts mounted on board |
| MCAL | abstracts the microcontroller | ADC·PWM·CAN·SPI drivers | MCU internal peripherals |
| CDD(exception) | direct control bypassing standard layers | high-speed sensors·special actuators | latency-sensitive hardware |
The Classic Platform's execution model is a static·priority-based real-time OS derived from OSEK/VDX. Tasks·events·resources are fixed at build time, dynamic memory allocation is avoided, and memory protection (MPU) prevents interference when ASILs are mixed. This static character is the opposite of flexibility like autonomous driving, but it is optimal for determinism·safety requirements such as "no matter what, the braking command must go out within 10 milliseconds." In fact, nearly all powertrain·chassis·body ECUs of passenger cars still run atop the Classic Platform today.
4. Adaptive Platform — service-oriented architecture and dynamic execution
The Adaptive Platform directly overturns the limits of Classic — "static·single-purpose·hard to update." Its core execution environment is the ARA (AUTOSAR Runtime for Adaptive Applications), where C++-written applications operate atop a POSIX (PSE51 profile)-based OS by calling the standard APIs provided by Functional Clusters. Because it presumes multicore·virtual memory·dynamic loading, it can handle computationally heavy tasks such as camera·lidar fusion or high-definition infotainment.
graph LR
subgraph APP["Adaptive applications (C++)"]
A1["Perception"]
A2["Planning"]
end
subgraph ARA["ARA: functional clusters"]
COM["ara::com<br/>service-oriented communication"]
EXEC["ara::exec<br/>execution management·state"]
UCM["ara::ucm<br/>OTA update"]
DIAG["ara::diag / per / crypto"]
end
OS["POSIX OS (PSE51)"]
A1 --> COM
A2 --> COM
A1 --> EXEC
COM -->|"SOME/IP · DDS"| NET["vehicle Ethernet backbone"]
EXEC --> OS
UCM --> OS
DIAG --> OS
The biggest paradigm shift of Adaptive is service-oriented communication (ara::com). Whereas Classic periodically transmits "signals" over fixed paths, Adaptive has the service provider register a service and the consumer discover it at runtime (service discovery) to connect. As the transport layer it uses SOME/IP (Scalable service-Oriented MiddlewarE over IP) or DDS (Data Distribution Service) specified by Foundation. Thanks to this dynamic binding, for example, if a new sensor-fusion service is added via OTA, existing consumers can discover·subscribe to that service without recompilation. In other words, the essence of Adaptive is a shift from "communication fixed like wiring" to "loosely coupled communication like an internet service."
Execution management (ara::exec) and update management (ara::ucm) are also capabilities Classic did not have. ara::exec manages the start·stop·state transitions (Machine State·Function Group) of applications, so that even while driving only the required function set can be loaded·switched. ara::ucm standardizes over-the-air updates (OTA), enabling even traditional OEMs to implement the "continuous improvement of vehicle functions" model that Tesla demonstrated. In fact, Volkswagen's software subsidiary CARIAD, the next-generation OS of BMW·Mercedes, and the SDV strategy of the Hyundai Motor Group all adopt the Adaptive Platform (or a variant) as the base of high-performance zonal·central computing architectures.
However, this flexibility creates tension with functional safety·determinism. POSIX's dynamic scheduling and virtual memory make it harder to guarantee "worst-case execution time (WCET)" than Classic's static determinism. So Adaptive targets safety up to the ASIL B level while filling the shortfall with deterministic Ethernet ([[tsn]])·safety-certified hypervisors·execution isolation. In short, Adaptive is a platform that "gains performance and flexibility but takes on the new homework of proving determinism," and that is why, for the time being, a role-sharing coexistence — where Classic handles top-safety-grade functions such as braking·steering, and Adaptive handles perception·planning·HMI — is the realistic solution.
5. Classic vs Adaptive comparison and development methodology
The difference between the two platforms is not a mere technical choice but stems from the difference in "which safety·performance·lifecycle requirements they respond to." The comparison below should be read not as a list of items but together with why each difference arises.
| Category | Classic Platform(CP) | Adaptive Platform(AP) | Why the difference arises |
|---|---|---|---|
| Target ECU | deeply embedded (hundreds of KB~MB) | high-performance computing (GB-class memory) | control vs perception·computation |
| OS | OSEK-based RTOS | POSIX(PSE51) | determinism vs rich runtime |
| Language | mainly C | C++(14 or later) | modularity·OO requirement |
| Config time | static (fixed at build time) | dynamic (runtime loading·discovery) | safety vs flexibility |
| Communication | signal-based (CAN/LIN/FlexRay) | service-oriented (SOME/IP·DDS) | fixed path vs loose coupling |
| Update | full flashing (service shop) | OTA (ara::ucm) | closed system vs continuous improvement |
| Safety grade | up to ASIL D | mainly ASIL B (raised via supplementary design) | difficulty of securing determinism |
In this comparison, the points with the greatest practical implication are the update model and the communication method. Classic's full flashing "replaces the verified binary wholesale," so it is safe, but even to fix a single small bug requires a service-shop visit, leading to recall costs across millions of units. By contrast, Adaptive's OTA improves functions remotely and replaces recalls with software patches, but it must necessarily be accompanied by security design such as [[secure-boot]]·signature verification·rollback so that tampered firmware does not damage safety functions. That is, flexibility and security responsibility grow together.
On the development-methodology side, AUTOSAR standardized a model-based·role-sharing workflow. Roughly, when the OEM designs SWCs·ports·interfaces at the system level and distributes them as ARXML, the Tier-1 maps them onto ECUs (SWC-to-ECU mapping) and configures the BSW, and the RTE generator auto-generates the communication glue code. In actual mass production, commercial toolchains such as Vector (DaVinci·MICROSAR), ETAS, and EB (Elektrobit) take this ARXML model as input, configure thousands of BSW parameters, and generate code. This way of "exchanging models and generating code" is the only realistic method for securing consistency·traceability·automation in a large-scale project involving dozens of ECUs·dozens of suppliers, and at the same time it leaves new management challenges of ARXML interoperability·tool lock-in.
6. Deep dive — latest trends (AUTOSAR in the SDV era)
AUTOSAR issues a regular release each November in the "Rxx-11" form. The most recent, R25-11 (publicly released late 2025), included about 1,900 incorporation tasks across the three standards Classic·Adaptive·Foundation, and the public announcement treated as major themes the Vehicle Data Protocol, security enhancements, DDS support on the Classic Platform, the outlook for Rust adoption on the Classic Platform, and the Common Adaptive Platform Implementation (CAPI) (for detailed changes, refer to the official release-overview documents). Compared with the immediately preceding R24-11 (2024), which incorporated about 2,400 tasks and over 350,000 lines of Adaptive code, one can read that recent releases are shifting their center of gravity from feature additions toward the substantive deepening of security·memory safety·platform integration.
The most notable trend is the convergence with the software-defined vehicle (SDV, Software Defined Vehicle). As functions that were distributed across dozens of ECUs are integrated into a few high-performance central·zonal controllers, a mixed-criticality environment — where ASIL D control and QM-grade infotainment coexist on a single piece of hardware — is becoming common. Here AUTOSAR presents a hybrid architecture in which Adaptive handles the high-performance domain and Classic handles the safety domain, while a hypervisor and a deterministic network such as [[tsn]] isolate·connect the two worlds. In fact, a common-implementation initiative like CAPI converges the Adaptive implementations that differed by OEM, aiming for an "Android-style common base" of vehicle software.
The second trend is memory safety and the rise of Rust. As a result of the Classic Platform's decades-long dependence on C, latent defects from memory errors ([[memory-safety]]) have accumulated. That the outlook for Rust adoption on the Classic Platform was treated as an official agenda item in R25-11 shows that the automotive industry has begun to seriously examine a memory-safe language as a fundamental means of safety·security. The third is security-safety co-design: as a cyberattack becomes a safety threat in a connected car, ISO/SAE 21434 (cybersecurity)·UNECE WP.29 R155/R156 (CSMS/SUMS) and AUTOSAR's crypto·security modules (ara::crypto, SecOC) are being organically combined. As for likely exam directions, convergence-type theses such as "design approaches for a Classic·Adaptive hybrid architecture during the SDV transition" or "an integrated functional-safety·cybersecurity strategy for AUTOSAR-based OTA" are plausible.
7. Considerations and implications
Application strategy — platform mixing and gradual transition: Moving all functions to Adaptive right away is unrealistic. Keeping ASIL D functions such as braking·steering on the verified Classic, and introducing Adaptive starting from areas needing flexibility such as perception·planning·HMI·OTA, is a realistic role-sharing hybrid transition. The professional engineer must have the discernment to design which function goes on which platform (mapping), along the axes of per-function safety grade·real-time requirement·update cycle.
Trade-off — standardization gains vs complexity·tool-lock-in costs: AUTOSAR gives large gains of reuse·collaboration·traceability, but entails costs of configuring thousands of BSW parameters, managing ARXML models, lock-in to commercial toolchains (Vector·ETAS·EB), and a steep learning curve. For small·simple ECUs it can be excessive overhead instead, so a cost-benefit judgment matched to the adoption scale and organizational capability is needed.
Outlook — convergence toward SDV·centralized architecture: As the vehicle evolves into a "computer on wheels," AUTOSAR's role is expanding from a distributed-ECU standard into the software base of central-computing·zone architectures. Once OTA·service-oriented communication·common implementation (CAPI) become common, the hardware lifecycle and the software lifecycle will separate, and a "car that keeps improving even after shipment" will become the standard.
Related technologies — integration of safety·security·network: AUTOSAR is not self-completing on its own. Only when it is organically combined with the functional safety of [[iso-26262]]·[[sotif-iso-21448]], the cybersecurity of ISO/SAE 21434, the deterministic network of [[tsn]], and the security base of [[secure-boot]]·[[memory-safety]] does a safe SDV come into being. The professional engineer should view AUTOSAR not as an individual technology but as the central axis of an integrated architecture that weaves these standards together.
Organization·governance — supply-chain collaboration and model-management system: AUTOSAR's true value comes from the collaborative governance in which OEM-Tier-1-Tier-2 hand off design responsibility via ARXML. Unless interface-change management, model configuration management, and tool-version·release-compatibility management are in place, the gains of standardization are offset by integration chaos. Therefore the professional engineer must have the perspective to design·operate, beyond understanding the technical spec, the process·configuration-management·contract governance that sustains multi-party collaboration.
References
- AUTOSAR, "AUTOSAR Official Website": https://www.autosar.org/
- AUTOSAR, "About AUTOSAR — History": https://www.autosar.org/about/history
- AUTOSAR, "Release R25-11 is Now Available": https://www.autosar.org/news-events/detail/release-r25-11-is-now-available
- AUTOSAR, "Classic Platform": https://www.autosar.org/standards/classic-platform
- AUTOSAR, "Adaptive Platform": https://www.autosar.org/standards/adaptive-platform
In one line: AUTOSAR is an open automotive SW standard that decouples vehicle SW from hardware to enable reuse·collaboration·portability, letting the static·real-time Classic Platform and the dynamic·service-oriented Adaptive Platform coexist bound by the Foundation·ARXML methodology, and expanding into the software base of centralized architectures amid the SDV·OTA·security-safety integration trend.