AUTOSAR Adaptive

AUTOSAR Adaptive is the AUTOSAR platform designed for high-performance vehicle computers. Where AUTOSAR Classic is statically configured for small real-time controllers, Adaptive runs on POSIX operating systems (typically Linux or QNX) on application processors, and supports installing, starting and stopping applications during the vehicle’s life. First released in 2017, the Adaptive Platform is the AUTOSAR partnership’s answer to a class of hardware its Classic Platform was never designed for.

Its core concepts are service-oriented: applications communicate through service interfaces over automotive Ethernet (commonly SOME/IP), discover each other at runtime, and are described in machine-readable manifests. The platform specifies functional clusters for execution management, communication, update and configuration management, diagnostics, and security.

What the Adaptive Platform specifies

Adaptive applications are C++ programs written against a set of standardized APIs known as ARA, the AUTOSAR Runtime for Adaptive Applications. Beneath those APIs, the platform is organized into functional clusters. Execution management controls the lifecycle of applications — which processes exist, when they start, and in which machine states they are allowed to run. Communication management provides the service-oriented middleware: applications offer and consume typed service interfaces, with events, methods and fields, and the platform maps those interfaces onto network bindings such as SOME/IP. Further clusters cover persistency, time synchronization, state management, diagnostics, and security functions such as cryptographic services and access control.

Deployment is manifest-driven. Machine-readable manifests describe what an application needs, which service instances it provides, and how it maps onto a specific machine — information the platform interprets at integration time and at runtime, rather than compiling it into a fixed image. That is the structural difference that makes field updates a designed-in capability instead of a full-image reflash.

Classic vs. Adaptive

The two platforms come from the same partnership but answer different questions, and the differences run through every layer. Classic runs on microcontrollers with memory measured in kilobytes or megabytes; Adaptive targets application processors — multicore SoCs with memory in gigabytes. Classic’s OSEK-heritage operating system schedules a task set fixed at build time; Adaptive applications are processes on a POSIX OS, scheduled dynamically. Classic applications are written in C against generated interfaces; Adaptive applications are written in C++ against standardized library APIs. Communication differs most visibly: Classic is signal-based, with statically routed signals on buses like CAN, while Adaptive is service-oriented, with services discovered and bound at runtime over Ethernet.

Configuration is the deepest split. In Classic, everything — tasks, communication matrices, memory layout — is decided before the ECU is built, which enables exhaustive timing analysis and certification at the highest ASIL levels, but means new software requires reflashing a complete image. In Adaptive, the set of installed applications can change over the vehicle’s life. Adaptive is designed to host safety-related applications too, but its certification arguments lean more heavily on the chosen operating system and on partitioning than Classic’s do. In practice the platforms are deployed together: Classic on zone controllers and actuator ECUs, Adaptive on the computers above them — a division of labor, not a migration path.

Where Adaptive runs in the vehicle

Adaptive’s home is the high-performance computer: central compute units, domain controllers for driver assistance, and gateway or connectivity computers that bridge the vehicle to the backend. These machines host workloads Classic cannot express — perception pipelines, planning functions, connectivity stacks, update clients — and they are the focal point of OEM vehicle OS programs. On such machines Adaptive rarely runs alone; it typically sits alongside container runtimes, POSIX applications outside the AUTOSAR world, and in many designs a hypervisor separating safety-relevant partitions from infotainment.

History

Work on the Adaptive Platform began in the mid-2010s, as automated driving and connectivity plans made clear that vehicles would carry computers whose software had to change over their lifetime. The first release came in 2017, and the platform has evolved through regular releases since, maturing from early demonstrators into production deployments over the following years. Its arrival marked a strategic turn for AUTOSAR: the partnership that had standardized the deeply embedded world extended its scope to the computers that define the software-defined vehicle.

Adaptive in the SDV stack

Adaptive is one answer to the SDV middleware question, not the only one. OEM vehicle OS programs mix Adaptive with open-source stacks from Eclipse SDV and COVESA, container runtimes, and proprietary middleware — the competitive question in the sector is precisely which combination wins the central computer. Adaptive’s strength in that contest is its standardized, automotive-grade specification and its integration with the Classic world below it; its friction point is that developers arriving from cloud and mobile backgrounds often prefer the container- and framework-based tooling they already know. Most production architectures land on a hybrid, with Adaptive handling vehicle-facing, safety-adjacent services and other stacks handling the rest.

Current state as of 2026 and what to watch

Adaptive is in series production across multiple OEM programs, most commonly on gateway and central computers, and commercial platform implementations are available from the established basic-software vendors. The open question is one of proportion: how much of the high-performance computer’s software will be specified by AUTOSAR, and how much by cloud-native and open-source layers around it. Watch three things — how deeply Adaptive integrates with containerized workloads in next-generation vehicle OS stacks, whether service-oriented diagnostics and update management converge with the mechanisms the rest of the software industry uses, and how the division of labor with Classic shifts as zone controllers grow more capable. The likeliest trajectory is not that Adaptive wins or loses the central computer outright, but that it settles into a defined role within a larger, mixed stack.