AUTOSAR Adaptive vs Classic — What's Different and How They Coexist

AUTOSAR — Time for a Clear Overview

If you work in automotive software, AUTOSAR is unavoidable. Yet explaining the exact differences between Classic and Adaptive — and why both exist — is something many engineers struggle with. Let's break it down.

What is AUTOSAR?

AUTOSAR (AUTomotive Open System ARchitecture) is the standardized software architecture for automotive ECUs. It was founded in 2003 by major European OEMs and Tier 1 suppliers. Today, over 350 partner organizations participate worldwide.

The core goal is straightforward: standardize ECU software so it can be reused regardless of hardware changes. Separate hardware from software — that's AUTOSAR's fundamental philosophy.

But as vehicles evolved toward autonomous driving and connectivity, the original standard couldn't keep up. That's why the Adaptive Platform was created.

Classic Platform — The Proven Foundation

Where It's Used

The Classic Platform (CP) is optimized for deeply embedded ECUs: engine control, transmission, braking (ABS/ESC), airbags, and body control. These ECUs share one critical requirement — hard real-time performance. A few milliseconds of delay in brake control can cause an accident.

Key Characteristics

CP's defining feature is static configuration. Everything is determined at build time — which software components run, in what order, how much memory they use, and how they communicate. This enables microsecond-level hard real-time response and supports up to ASIL-D, the highest safety integrity level under ISO 26262.

Communication

CP uses traditional automotive networks: CAN, LIN, and FlexRay. These networks offer limited bandwidth but guarantee real-time transmission, proven over decades of automotive use.

Adaptive Platform — Built for a New Era

Why It Was Created

Autonomous driving (ADAS/AD), connected cars, and OTA updates require high-performance computing. Processing massive sensor data from cameras, lidar, and radar while running complex AI algorithms demands capabilities that CP's static architecture simply cannot provide.

The Adaptive Platform (AP), first released in 2017, was designed for these high-performance computing ECUs. It runs on POSIX-compliant operating systems (typically Linux-based) and uses modern C++14 or later.

Core Feature: SOA

AP's most fundamental characteristic is its Service-Oriented Architecture (SOA). Unlike CP's statically linked communication, AP services are discovered and connected dynamically at runtime. A camera service announces its object detection data availability via Service Discovery, and an autonomous driving module finds and connects to it dynamically. New sensors or algorithm updates can be deployed by replacing individual services without rebuilding the entire system.

ARA — The Standard API Layer

AP defines ARA (AUTOSAR Runtime for Adaptive Applications) as its standard API layer. Applications access platform services — Communication Management, Execution Management, State Management, Diagnostics — through ARA. Applications built on ARA can run on any platform that implements it, regardless of hardware or OS changes.

Communication

AP primarily uses Automotive Ethernet with the SOME/IP (Scalable service-Oriented MiddlewarE over IP) protocol, supporting service discovery, event subscription, and remote procedure calls. Ethernet provides bandwidth orders of magnitude greater than CAN.

Key Differences at a Glance

Architecture

• CP: Static configuration, everything determined at build time
• AP: Dynamic configuration, runtime service discovery and binding

Target ECUs

• CP: Deeply embedded (engine, transmission, brakes, airbags)
• AP: High-performance computing (ADAS/AD, infotainment, central gateway)

Real-Time

• CP: Hard real-time (microsecond-level), ASIL-D capable
• AP: Soft real-time, optimized for high-throughput data processing

Communication

• CP: CAN, LIN, FlexRay
• AP: Automotive Ethernet, SOME/IP

Coexistence, Not Competition

A critical point: AP does not replace CP. They coexist and cooperate.

There's no reason to move brake control to a Linux-based AP. Safety-critical functions requiring microsecond hard real-time response stay on CP. Conversely, autonomous driving perception algorithms can't run within CP's constrained resources.

In real vehicles, CP and AP ECUs connect through gateway ECUs. When an AP-based ADAS ECU determines emergency braking is needed, the command reaches the CP-based brake ECU via the gateway, which translates between Ethernet and CAN protocols.

Since R19-11, CP and AP have been released together annually. The latest release, R24-11 (December 2024), introduced the Automotive API Gateway based on the VISS (Vehicle Information Service Specification) protocol, expanding connectivity between in-vehicle and external services.

The SDV Era Expands Adaptive's Role

As the industry moves toward Software-Defined Vehicles (SDV), vehicle architectures are shifting from distributed function-specific ECUs to centralized computing units managing multiple functions. AP's SOA architecture is central to this shift — enabling service-level management, OTA updates, and dynamic service deployment.

But CP isn't disappearing. Safety-critical functions, real-time control, and low-power ECUs will continue to rely on CP. The CP + AP coexistence model will persist for the foreseeable future.

PopcornSAR's Adaptive AUTOSAR Solutions

PARA is PopcornSAR's Adaptive AUTOSAR middleware platform implementing the ARA specification. Applications built on PARA run in any standard Adaptive AUTOSAR environment.

PACON IDE is an integrated development environment for Adaptive AUTOSAR with a built-in Docker-based Virtual ECU, enabling software development and testing before hardware is available.

AutoSAR.io is an ARXML design tool supporting both CP and AP for system architecture design.

Together, these form the Adaptive AUTOSAR Tool Kit — covering the full development workflow from design (AutoSAR.io) to middleware (PARA) to IDE (PACON IDE). See the PARA product page and PACON IDE product page for details, or contact us to discuss your project needs.