If you come from Android, AUTOSAR
So start with the problem instead.
The problem AUTOSAR was invented to solve#
In the 1990s and 2000s, every ECU
The result: carmakers paid for the same software many times over, could not move
a function from one supplier to another, and could not swap a microcontroller
without a rewrite.
AUTOSAR is the industry's answer — a standard that separates what a function
does from what hardware it runs on .
Before mains standards, an appliance was wired to a specific building. Standardise
the socket and the appliance stops caring about the building, and the building
stops caring about the appliance.
AUTOSAR standardises the socket between application code and the hardware
underneath it. The application says "give me the wheel-speed signal"; whether it
arrives over CAN, over FlexRay, or from a simulator is somebody else's
configuration problem.
The single most common misunderstanding is that Adaptive replaces Classic. It does
not. They coexist in the same vehicle because they are answers to different
questions.
Classic Platform Adaptive Platform Runs on Microcontroller, no MMU Microprocessor with an OS Operating system OSEK-style, fixed task table POSIX-compatible (often Linux or QNX) Language C, MISRA-constrained C++14 and later Configuration Everything fixed at build time Services discovered at runtime Memory Statically allocated Dynamic allocation allowed Communication Signals on CAN, LIN, FlexRay SOME/IP, DDS — services over Ethernet Updatable in the field Rarely, and awkwardly Yes, by design Typical function Braking, steering, body control Sensor fusion, ADAS, gateways Timing Deterministic, microseconds Best-effort with soft real-time
Read the table one line at a time and a pattern appears. Classic gives up
flexibility to buy predictability . Adaptive gives up some predictability to
buy changeability .
Neither is better. A brake controller that occasionally takes an extra
millisecond is a defect. A parking-assist stack that cannot be improved after
launch is a wasted investment.
AUTOSAR Classic, concretely#
AUTOSAR Classic
The configuration is not a settings file the software reads at startup. It is
input to a code generator that runs at build time and emits C.
your function code (SWC) + ARXML configuration → generator → generated C → compiled binary (signals, tasks, timing, which bus, which ECU)
An engineer needs the door module to report an extra flag — "child lock engaged".
The signal is added to the ARXML database: name, type, which CAN message
it rides in, which bit offset, which ECUs receive it.
The database is shared with every ECU that touches that message, because they
all must agree on the layout down to the bit.
The generator re-runs on each affected ECU, emitting new C.
Every affected ECU is rebuilt, re-tested, and re-flashed.
This is not a slow process because anyone is being careless. It is slow because
the bit layout of a CAN message is a contract between separate binaries built by
separate companies, and there is no runtime negotiation to fall back on.
That is precisely the cost that service-oriented communication removes — and
precisely why an SDV programme wants as few functions as possible stuck down
here.
Why it is still everywhere#
Because for a brake controller, all of that rigidity is a feature.
When you can prove at build time exactly which tasks run, in what order, within
what deadline, and using how much memory, the safety argument becomes
tractable. A regulator can be shown that the worst case was computed, not
hoped for.
You cannot make that argument about a system that allocates memory at runtime and
discovers its peers over a network. That is why ASIL
Do not read "legacy" into Classic. New Classic ECUs are designed every year.
The right mental model is that Classic is the automotive equivalent of firmware —
you would not run a pacemaker on a general-purpose OS either.
AUTOSAR Adaptive, concretely#
AUTOSAR Adaptive POSIX
Applications are separate processes. They start and stop. They find each other
by service discovery rather than by a pre-agreed bit offset. They talk over
SOME/IP DDS
If that sounds like ordinary server software, that is the point. Adaptive is
AUTOSAR admitting that the parts of a car that change fastest should be built
the way changeable software is built everywhere else.
The functional clusters#
Adaptive is organised into functional clusters — the standard's word for
"subsystems the platform provides". The ones you meet in practice:
Cluster What it gives you ara::com Service-oriented communication — the SOME/IP or DDS binding ara::exec Starting, stopping and supervising applications ara::per Persistent storage with integrity guarantees ara::diag Diagnostics — UDS, fault memory ara::sm State management: which applications run in which vehicle state ara::ucm Update and configuration management — the OTA mechanism ara::crypto Key storage and cryptographic operations
ara AUTOSAR Runtime for Adaptive applications . When you see
ara::com::ServiceProxy
The two worth knowing by name are ara::com , because it is how everything
talks, and ara::ucm , because it is how software gets updated — which is the
whole point of the SDV.
What service-oriented buys you here#
Signal-oriented — everyone shouts, everyone listens ECU A ECU B CAN bus ECU C Head unit no addressing · no replies · fixed at build time Service-oriented — components offer and call Seat service offers: setPosition() Light service offers: setBeam() Cockpit app discovers · calls discovered at runtime · request/response · versioned signals: add a consumer and you re-wire · services: add a consumer and nothing changes that difference is what makes features addable after the car ships Signals are broadcast and fixed; services are requested and discovered — Classic sends a signal onto a bus and hopes the right ECU is listening. Adaptive asks a named service for something and gets an answer, or an error.
The service interface gains a new field, versioned.
The provider is rebuilt and deployed.
Consumers that know about the field use it. Consumers that do not, ignore it
and keep working.
No coordinated flash of five ECUs. No bit-offset negotiation.
The difference is not that Adaptive engineers are faster. It is that the change
touches one deployable unit instead of a bus contract shared by many.
How they live together#
A real vehicle runs both, joined by a gateway.
┌──────────────── central compute ────────────────┐ │ │ │ Adaptive: ADAS stack, sensor fusion, gateway │ │ Android: cluster + infotainment │ │ (both on a hypervisor, plus a safety island) │ └───────────────────────┬─────────────────────────┘ │ Automotive Ethernet, SOME/IP ┌───────────────┼───────────────┐ │ │ │ ┌───────┴──────┐ ┌──────┴───────┐ ┌─────┴────────┐ │ Zone (front) │ │ Zone (rear) │ │ Powertrain │ │ Classic │ │ Classic │ │ Classic │ └───────┬──────┘ └──────┬───────┘ └─────┬────────┘ │ CAN, LIN │ CAN │ CAN, FlexRay sensors actuators inverter, motors
Read that top to bottom and you have the shape of a modern vehicle. Classic at
the edges where things must be fast, small and certain. Adaptive and Android in
the centre where things must be changeable. A gateway translating between them.
Your Android work sits at the top of that picture, and almost every vehicle
signal you consume has travelled up through it.
Classic ECUs are the monitoring equipment: single-purpose, always working,
absolutely trusted, and not something you update on a Tuesday.
Adaptive and Android are the records system and the staff: they coordinate,
schedule, present information, and get improved constantly.
You want both. You would not run the heart monitor on the records system, and you
would not schedule appointments on the heart monitor.
Where AAOS fits relative to AUTOSAR#
This confuses people, so state it plainly.
Android Automotive is not an AUTOSAR platform and does not implement AUTOSAR
interfaces. It is a peer that sits alongside Adaptive, usually on the same SoC
under a hypervisor
Concretely: your VHAL vehicle properties CarPropertyManager
That translation layer is one of the most common places an Android automotive
engineer actually touches AUTOSAR — not by writing AUTOSAR code, but by being
the consumer on the other end of its services.
What to be sceptical about#
"We are migrating from Classic to Adaptive." Some functions will move. Brake
control will not. Ask which specific functions, and what the safety argument is.
Adaptive is not automatically safe. Running on POSIX with dynamic memory does
not remove ASIL requirements — it makes them harder to argue. Adaptive supports
safety up to ASIL D on paper; achieving it takes real work, and much of the
industry solves it by keeping the highest-ASIL logic on a separate safety
microcontroller instead.
Adaptive is not free. Tooling is expensive, expertise is scarce, and the
standard is large. Some OEMs have concluded that plain Linux or QNX plus
SOME/IP gets them most of the benefit with less overhead — and that is a
defensible position, not heresy.
The tooling is the real cost. ARXML editing, configuration management and
generator licences dominate. Engineers arriving from open-source ecosystems are
usually more surprised by the tooling than by the concepts.
AUTOSAR exists to decouple vehicle functions from specific hardware , so
software can be reused and suppliers can be swapped.
Classic is statically configured C on a microcontroller — rigid on purpose,
because rigidity is what makes safety provable. It is not legacy.Adaptive is C++ on a POSIX OS with runtime service discovery, updates and
dynamic memory — built for the parts that must change.They coexist : Classic at the edges and in powertrain, Adaptive and Android
in the centre, a gateway between them.
The functional clusters worth remembering are ara::com (communication) and
ara::ucm (updates).
AAOS is a peer, not an AUTOSAR platform — your VHAL is frequently the
SOME/IP client consuming Adaptive services.Be sceptical of migration claims, of "Adaptive is safe by default", and budget
for tooling.
Next#
The other platforms competing for the same sockets — Android, Linux and QNX.
