--- url: /kb/embedded/autosar/classic-vs-adaptive/index.md --- # Classic vs Adaptive — Comparison & Decision Guide ## Comprehensive Comparison Table | Dimension | AUTOSAR Classic | AUTOSAR Adaptive | |-----------|-----------------|------------------| | **OS / Runtime** | AUTOSAR OS (OSEK-based, RTOS) — bare metal or minimal RTOS | POSIX.1-2017 OS (Linux or QNX) | | **Programming Language** | C (MISRA-C:2012) | C++14 / C++17 (AUTOSAR C++14 guidelines) | | **Memory Model** | Static allocation only — zero dynamic memory | Dynamic allocation allowed; pool allocators recommended for ASIL | | **Communication Paradigm** | Signal-oriented (PDU / I-PDU, COM stack, CAN signals) | Service-oriented (ara::com: events, methods, fields) | | **Transport Protocols** | CAN, LIN, FlexRay, classical Ethernet (AUTOSAR 4.x) | Automotive Ethernet (SOME/IP, DDS, IPC) | | **Configuration Model** | Fully static — all tasks, messages, timing configured at build time in ARXML | Static topology + dynamic service binding at runtime | | **Deployment / OTA** | Requires ECU reflash (UDS 0x34/0x36/0x37 bootloader sequence) | OTA via ara::ucm — processes can be updated without full reflash | | **Runtime Dynamism** | None — all runnable entities, tasks, messages fixed at build time | Services discovered and bound at runtime; applications can start/stop dynamically | | **Service Discovery** | N/A — all communication paths are statically configured | SOME/IP-SD, DDS SPDP/SEDP — fully dynamic | | **Safety ASIL ceiling** | ASIL D (BSW and AUTOSAR OS are ASIL D qualified) | ASIL B (Adaptive Platform); ASIL D requires ASIL D OS (QNX) | | **Worst-case response** | Deterministic — schedulable with RMA/EDF analysis | Probabilistically bounded — depends on OS scheduler and kernel | | **Context switch overhead** | ~2–10 µs (AUTOSAR OS, optimized RTOS) | ~5–20 µs (Linux/QNX process context switch) | | **Memory footprint** | 64 KB Flash / 8 KB RAM minimum (BSW excluded) | 512 MB RAM minimum (full Linux + Adaptive Platform) | | **Target hardware** | Microcontrollers (MCU): Infineon TriCore, NXP S32K, Renesas RH850 | SoC with application processor: NXP S32G, Renesas R-Car, NVIDIA Orin | | **Processing power** | 100 MHz–1 GHz, single core typical | 4–16 cores, 1–3 GHz per core, GPU/AI accelerator available | | **Software update** | Workshop flash via OBD-II (minutes per ECU) | Wireless OTA (seconds/minutes for active components) | | **Testing approach** | Simulation via MATLAB/Simulink, Hardware-in-Loop (HIL) with dSPACE | Unit tests on x86, SIL (SIL Kit), HIL on target SoC | | **Build system** | Generated by AUTOSAR configurator (DaVinci, ISOLAR) | CMake + Conan; vendor provides ara:: library packages | | **ISO 26262 maturity** | Mature — fully qualified BSW available from all major vendors since 2013 | Maturing — safety-qualified Adaptive stacks emerging (2023–2025) | | **Cybersecurity** | SecOC for CAN; basic key management | TLS/DTLS, SecOC, ara::crypto, ara::iam, full ISO/SAE 21434 support | | **Open connectivity** | No — closed CAN bus; no external IP routing by default | Yes — SOME/IP over Ethernet; V2X; cloud connectivity | | **Software development model** | Tight toolchain coupling; ARXML-driven; limited reuse of non-AUTOSAR OSS | Standard C++ ecosystem; can use open-source libraries (Boost, Eigen, TensorFlow) | *** ## When to Choose AUTOSAR Classic Choose Classic when your ECU has these characteristics: ### Hard Real-Time Control Requirements Classic is the only choice for **cycle-accurate control loops**: ``` Use cases requiring Classic: ───────────────────────────────────────────────────────────────────── Engine Control Unit (ECU/ECM) Injection timing accurate to ±1°CA (~0.1ms at 6000 RPM) Electronic Stability Control Control loop ≤ 1ms (ESC / ABS) Sensor → compute → actuator < 5ms Electric Power Steering (EPS) Torque feedback loop at 1–2 kHz Motor Control (BMS, e-axle) PWM generation with 10 µs resolution Radar front-end firmware Raw ADC data processing, real-time chirp scheduling ``` In all these cases, the worst-case execution time must be **provably bounded** (RMA analysis). Classic OS with static task scheduling provides this guarantee. Linux PREEMPT\_RT does not — even with real-time patches, Linux cannot guarantee worst-case latency below ~20 µs on typical SoCs. ### ASIL D Requirement with Existing Tools ``` ASIL D qualification path: Classic: Proven path — ASIL D BSW (Vector, EB, ETAS) available AUTOSAR OS TÜV-certified ASIL D Adaptive: Possible but complex: → Requires QNX 7.x (ASIL D certified OS) → Only specific Adaptive functional clusters are safety-qualified → Significantly more costly to certify in 2024/2025 ``` ### Resource-Constrained MCU Classic can run on as little as: * 128 KB Flash, 32 KB RAM (minimal BSW) * No MMU required (though MPU recommended for ASIL) * No OS image to store or update ### Signal-Based Closed-Loop Control (No Service Topology Change) If the control topology is fixed for the vehicle lifetime (engine never suddenly adds new sensors mid-production), static signal wiring in Classic is simpler and more certifiable than dynamic service discovery. *** ## When to Choose AUTOSAR Adaptive Choose Adaptive when your system has these requirements: ### Compute-Intensive Algorithms ``` Use cases requiring Adaptive: ───────────────────────────────────────────────────────────────────── ADAS / Autonomous Driving CNN inference, sensor fusion, path planning — cannot run on MCU Camera / Lidar Processing 1080p @ 30fps = 178 MB/s data rate OpenCV, TensorRT, or custom C++ needed High-Definition Map Engine Vector + raster map data access; SQL; map updates from OTA V2X Stack (C-V2X / DSRC) Linux networking stack (WAVE/WSMP/ETSI ITS); certificate management (SCMS) Voice + NLP Large language models need GPU; no MCU can run a wake-word engine ``` ### Dynamic Feature Sets (OTA-Updated Functionality) ``` Adaptive OTA scenarios: - New parking assistant mode pushed OTA during vehicle ownership - Traffic sign recognition model updated with improved CNN weights - New country-specific driving laws added to ADAS feature set - Cybersecurity patch to SOME/IP service interface without reflash ``` Classic requires a full ECU reflash via OBD-II for any software change. ### Service-Oriented Architecture Across Domains When multiple high-power compute domains need to exchange data flexibly: ``` Modern vehicle architecture requiring Adaptive: Zone Controller A Zone Controller B ┌─────────────────────┐ ┌─────────────────────┐ │ Adaptive Platform │────┐ │ Adaptive Platform │ │ - Camera Processing │ SOME │ - Path Planning │ │ - Radar Fusion │─IP/1GbE─ - Object Tracking │ │ - LiDAR Processing │────┘ │ - HD Map Access │ └─────────────────────┘ └─────────────────────┘ │ │ └─────────────── 10 GbE ────────┘ │ ┌─────────────────────┐ │ Central Compute (AP)│ │ - Motion Planning │ │ - V2X │ │ - OTA Manager │ └─────────────────────┘ ``` *** ## Coexistence Patterns: Classic + Adaptive Real vehicles use both platforms simultaneously. Here are the standard integration patterns: ### Pattern 1: Adaptive as Gateway to Classic Domain ``` Adaptive ECU (High-level) Classic ECU (Domain controller) ┌────────────────────┐ ┌─────────────────────────────────┐ │ PathPlanningApp │ │ AUTOSAR Classic BSW │ │ (ara::com Proxy) │ │ ┌──────────────────────────┐ │ │ ↕ SOME/IP │ │ │ SWC: SteeringRequest │ │ │ BridgeService │◄──CAN──► │ │ (AR_PORT: SteeringAngle)│ │ │ (Adaptive SWC) │ │ └──────────────────────────┘ │ │ SOME/IP↔CAN signal │ │ CAN ComStack │ └────────────────────┘ └─────────────────────────────────┘ The Bridge SWC translates: ara::com event (SteeringCommand_Deg) → CAN signal (0x210 byte 0-1, 0.1°/bit) ``` ### Pattern 2: Mixed-Criticality SoC with Hypervisor ``` Single SoC (e.g., NXP S32G274A): ┌──────────────────────────────────────────────────────────┐ │ Jailhouse / XEN Hypervisor │ ├──────────────────────────┬───────────────────────────────┤ │ Safety Partition │ QM Partition │ │ ARM R52 Lock-Step Cores │ ARM A53 Cores │ │ AUTOSAR Classic │ Linux + AUTOSAR Adaptive │ │ ASIL D firmware │ ADAS, OTA, Diagnostics │ │ CAN/LIN/FlexRay │ Ethernet, SOME/IP │ ├──────────────────────────┴───────────────────────────────┤ │ Shared SoC Hardware │ │ (DDR, PCIe, GMAC Ethernet, GPIO) │ └──────────────────────────────────────────────────────────┘ Inter-partition communication: Shared memory region with doorbell interrupt (hypervisor-mediated) Protected by E2E and SecOC if safety-critical data crosses partitions ``` ### Pattern 3: Adaptive Service Consuming Classic Signals via SOME/IP Gateway ``` Classical CAN bus (powertrain signals) │ ┌───────┴────────────────────────────┐ │ Gateway ECU (Adaptive Platform) │ │ │ │ CAN→IP Bridge Service │ │ Reads CAN 0x100 "VehicleSpeed" │ │ Publishes SOME/IP event: │ │ VehicleSpeedService.Speed │ └───────┬────────────────────────────┘ │ SOME/IP over 100BASE-T1 ┌───────┴─────────────────────────────────┐ │ ADAS Domain Controller (Adaptive) │ │ PathPlanningApp: subscribes to Speed │ │ ADASControlApp: subscribes to Speed │ └─────────────────────────────────────────┘ ``` *** ## Migration Strategy: Classic Signal → Adaptive Service For brownfield vehicles transitioning between generations: ``` Phase 1 — Parallel period (coexistence): CAN signal 0x100 VehicleSpeed STILL transmitted on CAN + Gateway ECU mirrors it as SOME/IP VehicleSpeedService Adaptive AAs use SOME/IP; Classic AAs use CAN. No breakage. Phase 2 — Adaptive-primary: New ECUs use SOME/IP only. Gateway subscribes to SOME/IP, publishes to CAN for legacy Classic ECUs. Direction reversed. Phase 3 — Classic sunset: All ECUs on SOME/IP. CAN signal deprecated. Gateway removed. ``` *** ## Section Index — AUTOSAR Adaptive Knowledge Base | File | Topic | Permalink | |------|-------|-----------| | [autosar-01-introduction.md](autosar-01-introduction.md) | AUTOSAR history, partnership, two-platform overview | `/kb/embedded/autosar/introduction/` | | [autosar-02-classic-platform.md](autosar-02-classic-platform.md) | Classic BSW, OS, ComStack, RTE, SWC, diagnostics | `/kb/embedded/autosar/classic-platform/` | | [autosar-03-adaptive-introduction.md](autosar-03-adaptive-introduction.md) | Why Adaptive, use cases, architecture overview | `/kb/embedded/autosar/adaptive-introduction/` | | [autosar-04-adaptive-architecture.md](autosar-04-adaptive-architecture.md) | ARA, all functional clusters, error handling | `/kb/embedded/autosar/adaptive-architecture/` | | [autosar-05-ara-com.md](autosar-05-ara-com.md) | ara::com: Skeleton, Proxy, Events, Methods, Fields | `/kb/embedded/autosar/ara-com/` | | [autosar-06-execution-state-management.md](autosar-06-execution-state-management.md) | EM, SM, FunctionGroups, Machine States | `/kb/embedded/autosar/execution-management/` | | [autosar-07-service-oriented-architecture.md](autosar-07-service-oriented-architecture.md) | SOA principles, SOME/IP wire format, DDS, SD | `/kb/embedded/autosar/soa/` | | [autosar-08-safety-security.md](autosar-08-safety-security.md) | ASIL, PHM, ara::crypto, SecOC, IAM, ISO 26262 | `/kb/embedded/autosar/safety-security/` | | [autosar-09-manifests-tooling.md](autosar-09-manifests-tooling.md) | Application/Execution/Service Instance Manifests, UCM, OTA | `/kb/embedded/autosar/manifests-tooling/` | | [autosar-10-os-posix-memory.md](autosar-10-os-posix-memory.md) | Linux, QNX, POSIX, scheduling, memory, IPC | `/kb/embedded/autosar/os-posix/` | | [autosar-11-development-workflow.md](autosar-11-development-workflow.md) | Code generation, CMake, testing, CI/CD, packaging | `/kb/embedded/autosar/development-workflow/` | | [autosar-12-classic-vs-adaptive.md](autosar-12-classic-vs-adaptive.md) | Full comparison, decision guide, coexistence patterns | `/kb/embedded/autosar/classic-vs-adaptive/` |