TN-14 · 2026-09-12 · Test Engineering Series · Part 7

Classic vs Adaptive AUTOSAR: Not a Succession, a Division of Labor

Automotive software has two AUTOSARs: Classic and Adaptive. A question that comes up all the time: “Is Adaptive the next generation that replaces Classic?” No. CP owns control; AP owns computing — one guards the determinism of body and chassis, the other carries the compute of intelligent-driving domain controllers. This note lays the two platforms side by side, dimension by dimension, explains how they coexist in a modern car, and what it all means for test engineers.

1. Dimension by Dimension

One-line portraits: CP is “the workhorse whose whole life is fixed at compile time” — deterministic, certifiable, no surprises allowed; AP is “the platform that keeps growing after it ships” — dynamic and updatable, at the price of giving up determinism.

2. How They Coexist in a Modern Car

Both sides are present in the E/E architecture — even inside the same domain controller: the SoC runs Linux + AP for perception and planning, while a companion MCU runs CP as the “safety island” — the planned trajectory computed by AP is monitored for safety and, if it comes to it, overridden by the CP side. Between the two, a gateway translates signal ↔ service (CAN ↔ SOME/IP):

┌──────────────── Domain Controller ───────────────┐
│  SoC: Linux + AP—sensor fusion / planning / OTA  │
│          │ planned trajectory                    │
│          ▼                                       │
│  MCU: CP safety island (ASIL D) —                │
│       safety monitoring / fallback execution     │
└─────────┬────────────────────────────────────────┘
          │
       Gateway: signal ↔ service (CAN ↔ SOME/IP)
          │
       Body / chassis ECUs (CP)

“Will AP replace CP?” is the wrong question: as long as a car still has brakes and steering to control, CP stays. The division between the two platforms is not old-vs-new on a timeline; it is a spatial division within one vehicle — compute goes to AP, determinism to CP.

3. What It Means for Test Engineers

• What you test on CP: bus-signal stimulus and observation (CAN/LIN/FlexRay), UDS diagnostics, fault injection — the traditional HIL home turf; PIL is a hard requirement on this side too (fixed-point, the TASKING compiler);
• What you test on AP: service interfaces (SOME/IP), Ethernet traffic, logs and traces, state management, OTA flows; AP applications are largely SIL-tested inside Linux containers first — the SIL share on AP domain controllers is far higher than in the CP era, and that directly reshapes test platforms: the access layer shifts from bus interface cards to Ethernet and containers, and the share of cases pure-software simulation can cover rises sharply;
• Common to both: the test methodology (scenarios, verdicts, regression) is identical on both sides — only the access layer changes;
• Concept mapping: CP’s SWC ↔ AP’s Adaptive Application; CP’s RTE ↔ AP’s ara::com.

CP welds determinism in at compile time; AP keeps flexibility until runtime — and the division of labor on the car follows: life-critical control loops go to the “no surprises allowed” CP, compute-hungry smart features go to the “still growing” AP. A test engineer’s job is not to pick a side; it is to know both access layers and let one methodology cover both.

Appendix: Glossary (in order of appearance)