Adaptive vs Classic - Architecture Comparison

AUTOSAR Classic Platform was designed in the early 2000s for deeply embedded, resource-constrained ECUs (microcontrollers with 256 KB–2 MB Flash). It uses a static, compile-time-configured BSW stack generated from ARXML, a fixed-cycle OSEK/AUTOSAR OS, and COM-signal-based IPC. Classic dominates body, chassis, and powertrain ECUs where deterministic, ASIL-D real-time behaviour is paramount.

AUTOSAR Adaptive Platform (AP) was introduced in Release R17-03 to address high-performance computing ECUs: ADAS domain controllers, central compute units, and connected gateways running on 64-bit SoCs with 4–16 cores, 4–16 GB RAM, and Linux or QNX. AP uses a POSIX process model, dynamic service discovery, and C++14/17 — a fundamentally different paradigm.

Each Adaptive Functional Cluster (FC) provides a standardised C++ API (the ara:: namespace) to Adaptive Applications. FCs replace Classic BSW modules but operate as OS-level services rather than compiled-in libraries.

Classic COM uses signals: a named value with a fixed PDU position, sent on a bus cyclically or on change. Every signal and its receiver are configured statically in ARXML at design time. Adding a new consumer requires reconfiguration of the entire COM stack.

Adaptive uses Service-Oriented Architecture (SOA): a provider offers a service at runtime; consumers find it via SOME/IP-SD or DDS discovery. The communication topology is dynamic — new consumers can subscribe at runtime without recompiling the provider.

Classic:
  [SWC A] --write signal--> [COM] --PDU Router--> [CAN/Ethernet bus] ---> [COM] --read signal--> [SWC B]
  Topology fixed at compile time.

SOA (Adaptive):
  [App Provider] --OfferService()--> [ara::com CM] <--FindService()-- [App Consumer]
          |                                                                  |
          +--- Event::Send(data) ------SOME/IP / DDS -----------> GetNewSamples(cb)
  Consumer subscribes at runtime; multiple consumers supported without reconfiguring provider.

AUTOSAR Adaptive is not a replacement for Classic — it is a complementary platform for high-compute ECUs. Understanding the boundary between them is the first design decision in any SDV project. The Functional Cluster model provides well-defined C++ APIs that abstract the platform, allowing application code to remain portable across AP implementations from Vector, EB, and APEX.AI.