AUTOSAR Classic is a statically configured, C-based platform for deterministic hard real-time control on microcontrollers. AUTOSAR Adaptive is a POSIX- and C++-based runtime for service-oriented, updatable software on high-performance processors. They coexist rather than compete: Classic runs actuation and safety functions, Adaptive runs ADAS, connectivity, and services that change over a vehicle's life.
Key takeaways
- Classic is static by design — tasks, signals, and memory fixed at build time, which is what makes hard real-time guarantees provable.
- Adaptive is dynamic by design — runtime service discovery, updatable applications, statistical rather than absolute determinism.
- Most serious programs ship both, on different silicon, talking over Ethernet.
- The real cost of either is the toolchain, the ARXML data model, and the engineers who can operate them.
- Adaptive adoption has been slower than vendors implied, and many production high-compute nodes run non-AUTOSAR stacks.
How does AUTOSAR Classic actually work?
Classic compiles to one statically linked binary per ECU. Application components sit on a generated Runtime Environment (RTE), which sits on Basic Software — services, ECU abstraction, and a microcontroller abstraction layer that isolates code from silicon.
The operating system derives from OSEK/VDX, with fixed-priority preemptive scheduling and tasks assigned at configuration time. There is no process creation and typically no dynamic memory allocation. Classic does include a Service Discovery module for SOME/IP-SD, but the set of services an ECU may offer or consume is fixed in the configuration at build time. Communication is signal-oriented: CAN, LIN, FlexRay, and Ethernet frames carrying pre-agreed signals in pre-agreed layouts. Classic can speak SOME/IP through the socket adaptor, but deployment is still fixed at build.
What the static configuration buys you
Everything is knowable before the ECU boots. You can compute worst-case execution times, run response-time analysis, prove stack bounds, and argue freedom from interference. That is why Classic remains the choice for ASIL-D functions like braking, steering, and propulsion.
Changing anything means regenerating the RTE and reflashing. The workflow runs through ARXML: a system description is authored, an ECU extract derived per node, the BSW configured against it, code generated. It works, and it is slow.
How does AUTOSAR Adaptive work differently?
Adaptive is not an operating system. It is a runtime — the AUTOSAR Runtime for Adaptive Applications, or ARA — layered on a POSIX OS, with the PSE51 real-time profile as its baseline. In practice that OS is Linux, QNX, or a POSIX-conformant RTOS.
Applications are C++ processes, launched and supervised by Execution Management rather than scheduled as runnables in a fixed table. The platform is organized into functional clusters: ara::com for communication, ara::exec, ara::diag, ara::per for persistency, ara::crypto, and ara::ucm for update and configuration management.
What ara::com changes about integration
ara::com is service-oriented. A service interface defines methods, events, and fields; the toolchain generates a client proxy and a server skeleton. Clients find providers through runtime service discovery instead of being wired to a signal on a bus.
The default network binding is SOME/IP, with DDS and local IPC also specified — we work through those transport trade-offs in middleware and service-oriented architecture.
ara::ucm defines how packages are installed, activated, and rolled back on a running vehicle, the foundation under most OTA update programs.
What are the main differences side by side?
It comes down to binding time and hardware class. Language, operating system, scheduling, and safety ceiling all follow from those two.
| Dimension | Classic Platform | Adaptive Platform |
|---|---|---|
| Language | C | C++ |
| Operating system | OSEK-derived RTOS, in the stack | POSIX PSE51 OS (Linux, QNX), outside it |
| Scheduling | Fixed-priority, static tasks | POSIX threads, dynamic |
| Communication | Signal-oriented; SOME/IP via socket adaptor | Service-oriented ara::com; SOME/IP or DDS |
| Binding time | Build time | Runtime service discovery |
| Deployment | One static image per ECU | Multiple processes, addable and updatable |
| Typical hardware | Microcontroller, no MMU, KB to MB of RAM | Microprocessor with MMU, MB to GB |
| Timing behavior | Deterministic, analytically provable | Soft real-time, characterized statistically |
| Safety in practice | ASIL-D routinely | Lower ASILs typical; ASIL-D hard and costly |
| Natural fit | Actuation, control loops, energy management | ADAS, infotainment, connectivity, gateways |
When should you use Classic, and when Adaptive?
Pick by the properties of the function, not by which platform is newer. If a deadline must never be missed, use Classic. If the function must change after start of production, use Adaptive.
Signals that Classic is right
- ASIL-C or ASIL-D with a provable timing argument required.
- Control loops in single-digit milliseconds or faster.
- Microcontroller target, no MMU, constrained RAM.
Signals that Adaptive is right
- Compute demand needs an application processor: perception, fusion, camera pipelines.
- Functions will be added, updated, or reconfigured over the vehicle lifecycle.
- Several suppliers deliver into one node on different cadences.
This maps onto zonal and domain architectures: zone controllers and actuators stay Classic, central compute runs Adaptive or a Linux equivalent, Ethernet carries services between them.
What does each platform actually cost you?
More than the runtime license, mostly in places that never appear on the quote.
- Toolchain and licensing. A commercial BSW or ARA stack plus its configuration environment, licensed per project, per seat, often per ECU variant. Generated-code ownership and derivative-variant rights are negotiated, not default.
- Configuration complexity. Classic ECU configuration runs to thousands of parameters, all exchanged as ARXML, which does not merge cleanly — parallel team work becomes an integration problem. Adaptive trades that for manifests, deployment mapping, and OS configuration. Different work, not less.
- The skills gap. Classic wants embedded C engineers who think in interrupts, stack depth, and MISRA. Adaptive wants modern C++ engineers fluent in Linux and distributed debugging. Different people, and the second group is scarcer and pricier.
- Timing analysis. On Classic you compute it. On Adaptive you measure it: latency distributions, tail behavior, scheduler jitter, cache and memory-bandwidth effects.
Both need virtual ECUs for evidence before hardware exists, and both feed the same safety and CI/CD workflow.
Where do non-AUTOSAR stacks legitimately fit?
Not every high-compute node needs the Adaptive Platform. Several OEMs run Linux or QNX with their own service framework, using SOME/IP or DDS on the wire while skipping the ARA layer. That is defensible when you own the node end to end and do not need supplier-portable applications.
ROS 2 belongs in prototyping and algorithm development, where its tooling accelerates work. Shipping stock ROS 2 into a production vehicle is another matter; evaluate commercially hardened derivatives that have been through ISO 26262 assessment instead.
Why has Adaptive been harder than the pitch suggested?
Because the specification kept moving while programs were building against it, and vendor implementations lagged unevenly. Teams found gaps between what the standard described and what their stack shipped, then closed them with vendor-specific extensions — which quietly removed the portability that justified the platform.
Interoperability is weaker than it looks on paper. Two conformant stacks exchanging SOME/IP usually work; two sharing application code usually need porting. Adaptive's real product is supplier-portable service interfaces, so if you will not exercise that portability, you are paying for something you will not use. The shift toward software-defined vehicles is real, but Adaptive is one route to it, not the only one.
Frequently asked questions
Does AUTOSAR Adaptive replace AUTOSAR Classic?
No. They target different problems and are designed to coexist in the same vehicle. Classic handles deterministic hard real-time control on microcontrollers, typically at higher ASILs. Adaptive handles high-compute, service-oriented, updatable functions on application processors. A typical modern architecture runs Classic on zone controllers and actuators and Adaptive on central compute, connected over automotive Ethernet.
Can AUTOSAR Classic use SOME/IP and service-oriented communication?
Yes. Classic supports SOME/IP over Ethernet through the socket adaptor and transformer modules, so a Classic ECU can offer and consume services. The difference is binding time: Classic's service configuration is fixed at build, while Adaptive discovers providers at runtime. Classic gives you the protocol, not the dynamism.
What operating system does AUTOSAR Adaptive run on?
Adaptive is a runtime layered on a POSIX operating system, not an OS itself. The specification uses the PSE51 real-time profile as its baseline. Production deployments typically use Linux with real-time patches, QNX, or another POSIX-conformant RTOS. The OS choice affects your safety and security argument significantly, so it is an architecture decision rather than a procurement detail.
Can you achieve ASIL-D on the Adaptive Platform?
It is possible but difficult and costly. The combination of a general-purpose POSIX OS, dynamic memory, MMU-based isolation, and multicore interference makes freedom-from-interference arguments much harder than on a statically configured microcontroller. Most programs keep ASIL-D functions on Classic and use Adaptive for lower-ASIL or QM functions, sometimes with a separate safety monitor on dedicated hardware.
What is ara::com and how does it differ from the RTE?
Both connect software components, but differently. The RTE is generated code implementing fixed, build-time connections between Classic components. ara::com is a runtime API where clients find service providers through discovery, using generated proxies and skeletons from a service interface definition. The RTE knows every connection before boot; ara::com resolves connections while the vehicle is running.
Do you need AUTOSAR at all for a central compute platform?
Not necessarily. Linux or QNX with a custom service framework over SOME/IP or DDS is a legitimate production choice, and several OEMs have taken it. AUTOSAR Adaptive's main value is standardized, supplier-portable interfaces and a defined update and diagnostics model. If you own the node end to end and will not exercise that portability, the return on the added complexity is limited.
How long does it take a Classic team to become productive on Adaptive?
Longer than most plans allow. The gap is not just C to C++; it is dynamic memory, multithreading, POSIX, build and packaging systems, and distributed debugging. Teams typically need dedicated training plus experienced C++ and Linux engineers embedded alongside them. Assuming existing embedded engineers will absorb Adaptive during a program is a common and expensive planning error.
Which functions belong on Classic, which on Adaptive, and which need no AUTOSAR at all is a decision that lasts the life of the platform. GEMMACON works both sides of that line — Classic BSW and RTE integration, Adaptive service design and deployment, and the middleware between them. If you are partitioning a new architecture or unsticking an Adaptive integration, get in touch.
