Most teams asking the AUTOSAR Adaptive migration question are asking the wrong version of it. The right version is not "should we move to Adaptive." The right version is "which workloads on our next platform need Adaptive, and what is the safety-architecture cost of putting them there."
AUTOSAR Classic is well-understood, ISO 26262 ASIL-D-capable, and the right answer for tightly resource-constrained ECUs. AUTOSAR Adaptive is the right answer for service-oriented compute, over-the-air-updatable workloads, and high-performance perception and planning. The two coexist on most current vehicle programs, communicating across SOME/IP and other automotive Ethernet protocols. The interesting engineering question is the boundary between them.
Three forces have made the Adaptive question concrete in the last 24 months. The first is the software-defined vehicle (SDV) architecture push, which moves vehicle function out of fixed ECUs and into zone or central compute platforms that need to be updatable over the air. Adaptive was designed for that runtime model; Classic was not. The second is the ADAS perception and planning workload, which runs on multi-core, GPU-augmented, sometimes vision-accelerator-equipped compute platforms. Classic's static, statically-scheduled execution model does not fit those platforms; Adaptive's POSIX-based runtime does. The third is the service-oriented architecture (SOA) shift in the supplier ecosystem, where Tier-1 suppliers and OEMs are increasingly contracting at the service interface level rather than the ECU level. SOA in the vehicle has SOME/IP as its dominant protocol, and ara::com (Adaptive's communication management API) as its native implementation.
The AUTOSAR Adaptive Platform Specification has reached release R25-11 (the R24-11 release event took place in December 2024, with R25-11 following at the 2025 release event) and is now mature enough that the architectural questions are about which workloads to put on it, not whether the platform itself is ready. The functional safety questions, by contrast, remain open. The Adaptive Platform is POSIX-based, which makes it harder to demonstrate the timing determinism and memory protection guarantees that ISO 26262 ASIL D normally requires of a safety-relevant runtime. Programs targeting ASIL D safety mechanisms on Adaptive typically carve those mechanisms onto a separate safety microcontroller running Classic, leaving Adaptive in an ASIL B or QM role on the high-performance compute platform.
Three workload patterns make Adaptive the defensible choice over Classic. Each comes with a different safety-architecture cost.
Service-oriented architecture (SOA) workloads. When the program targets a vehicle-level SOA where functions are decomposed into services rather than ECUs, and those services need to be updatable independently over the air, Adaptive is the runtime that supports that model. Classic's static configuration model does not. The SOA workload also tends to be middle-of-the-vehicle compute (zone controllers, central platforms), where the workload is dominated by sensor fusion, planning, body control coordination, and infotainment rather than tight real-time inner loops. Safety-mechanism cost: typically ASIL B on the Adaptive side, with safety-critical inner loops carved onto a separate Classic ECU.
ADAS perception and planning workloads. Camera, radar, and LiDAR perception stacks; object tracking; trajectory planning; sensor fusion. These workloads are compute-heavy, often GPU-accelerated, and require dynamic memory and process isolation. AUTOSAR Classic's deterministic, fixed-allocation memory model is fundamentally mismatched to them. Adaptive's POSIX-based runtime supports them natively. Safety-mechanism cost: rising. ADAS at SAE Level 2+ typically lands at ASIL B; SAE Level 3 and higher pushes into ASIL D territory on specific signals, and demonstrating ASIL D on Adaptive requires significant safety-architecture work (lockstep architecture or external safety supervisor; see LHP Safety Supervisor Software).
Over-the-air (OTA) updatable application workloads. Any application that needs to ship updates between vehicle releases, including connected services, navigation, telematics, and increasingly diagnostics. OTA on Classic is possible but architecturally cumbersome; on Adaptive it is native. Safety-mechanism cost: depends on the application; OTA-updatable infotainment is QM, OTA-updatable safety-relevant functions require a robust update verification chain regardless of platform.
Two workload patterns do not pay for Adaptive migration. The first is tightly resource-constrained safety-critical ECUs at the edge (chassis control, braking, steering ECUs running on automotive-grade microcontrollers with limited RAM and a single core). Classic is the right answer; Adaptive's runtime overhead does not fit, and the safety-mechanism redesign would lose program time without unlocking the workload's needs. The second is legacy ECUs whose function does not change. A door control module that has shipped on Classic for three product generations does not benefit from Adaptive migration; the migration cost is wasted unless there is a SOA reason to integrate the function into a zone controller.
Three architectural patterns are common in current Adaptive-based programs.
Pattern 1: Adaptive at QM with safety mechanisms on a separate Classic ECU. The Adaptive compute platform runs the high-throughput workload at QM (Quality Management; no ASIL allocation). A separate safety microcontroller running Classic or a bare-metal RTOS implements the safety mechanisms (range checks, plausibility checks, timeout monitoring) on the safety-relevant signals. The two communicate over a fault-tolerant link, typically using End-to-End (E2E) protection profiles. This is the most common defensible architecture for current SDV programs.
Pattern 2: Adaptive at ASIL B with safety mechanisms inside the Adaptive partition. Achievable, with significant engineering effort. Requires demonstrating that the POSIX runtime, the ara::com communication, the dynamic memory allocator, and the IPC mechanisms each meet the freedom-from-interference (FFI) requirements of ISO 26262:2018 Part 6, Clause 7.4.10 (with the interference categories spelled out in Part 6 Annex D: spatial, temporal, and exchange of information) between mixed-criticality partitions. The safety mechanisms run in Adaptive processes with documented FFI, typically backed by memory protection unit (MPU) configuration and a partition-aware scheduler.
Pattern 3: Adaptive at ASIL D. Rare in 2026. Achievable in principle with extensive additional safety architecture: lockstep cores, redundant Adaptive instances, external safety supervisor, and a safety case that explicitly addresses the POSIX OS's qualification status. The cost is high enough that most ASIL D safety mechanisms remain on Classic or bare-metal RTOS while the Adaptive side stays at ASIL B or QM.
The pattern selection drives the migration cost more than the AUTOSAR license. A program that can live with Pattern 1 has the cleanest migration path. A program that needs Pattern 3 should expect the safety-architecture redesign to dominate the program's engineering budget for the migration cycle.
LHP runs Adaptive migration engagements with three phases. Phase 0 is a workload-mapping assessment: which functions belong on Adaptive given their workload pattern, which belong on Classic given their safety-criticality and resource constraints, and where the SOME/IP service boundaries should land between them. Phase 1 is the platform selection and safety-architecture design, including the freedom-from-interference argument for the Adaptive side and the safety-mechanism design for the Classic side. Phase 2 is the migration of selected workloads to Adaptive, with the safety case extended to include the Adaptive evidence base alongside the existing Classic evidence base. The methodology integrates the LHP Functional Safety Certifiable Framework on the safety architecture side, the LHP MBSE Audit methodology on the systems-engineering side, and LHP Safety Supervisor Software where an external safety supervisor pattern is applicable.
For programs already in mid-migration, LHP runs a focused audit on the Adaptive safety-architecture argument, identifies the freedom-from-interference gaps, and returns a prioritized remediation roadmap before the next ISO 26262 assessment.
If your next program is a 2026 to 2028 vehicle launch with any combination of SDV architecture, zone or central compute platforms, ADAS at SAE Level 2+ or higher, or OTA updatable applications, AUTOSAR Adaptive is in the architecture conversation. The question is which workloads land on Adaptive and what the safety-architecture cost is for each.
The concrete step worth taking this quarter: pull the workload list for the next platform and tag each workload by (a) does the workload need SOA or OTA, (b) does the workload need ADAS-class compute, (c) what is the workload's ASIL tier. The workloads that answer yes to (a) or (b) and live at ASIL B or below are the candidates for Adaptive. The workloads at ASIL D belong on Classic or a bare-metal RTOS until the safety-architecture case for ASIL D on Adaptive matures. The boundary between those two sets is the migration plan.
AUTOSAR Classic, defined in the Classic Platform Specification, is the static-configuration, statically-linked, fixed-address-space runtime designed for resource-constrained safety-relevant microcontrollers. It targets ISO 26262 up to ASIL D natively. AUTOSAR Adaptive, defined in the Adaptive Platform Specification, is a POSIX-based, dynamically-linked, IPC-driven runtime designed for high-performance compute platforms running service-oriented workloads. It is well-suited to SOA, OTA, and ADAS perception workloads. The two are not interchangeable; they target different workload patterns and coexist on most modern vehicle programs.
Achievable, rarely in 2026. ASIL D on Adaptive requires significant additional safety architecture (typically lockstep cores, redundant Adaptive instances, external safety supervisor) plus a safety case that explicitly addresses the qualification status of the underlying POSIX operating system, the dynamic memory allocator, and the IPC mechanisms. Most current programs that need ASIL D safety mechanisms keep those mechanisms on a separate Classic or bare-metal microcontroller and run the Adaptive side at ASIL B or QM. The two are coupled over an E2E-protected link.
AUTOSAR Adaptive uses SOME/IP (Scalable service-Oriented MiddlewarE over IP) as its primary service-oriented communication protocol, with ara::com as the platform's communication management API. The SOME/IP protocol is the same one used outside Adaptive for vehicle-level service communication over automotive Ethernet, which means an Adaptive ECU can interoperate with non-Adaptive ECUs over the same protocol. The ara::com API is the Adaptive-specific programming model for service discovery, event subscription, and method invocation.
No. The defensible architecture for most 2026 to 2028 vehicle programs is mixed: AUTOSAR Classic on the safety-critical edge ECUs (chassis, braking, steering, body control where appropriate) and AUTOSAR Adaptive on the high-performance compute platforms (zone controllers, central platforms, ADAS compute). The two communicate over SOME/IP and other automotive Ethernet protocols. The migration question is which workloads move to Adaptive, not whether the entire vehicle does. Programs that frame the question as all-or-nothing typically over-migrate and incur safety-architecture costs they did not need to incur.
Since 2001, LHP Engineering Solutions has helped companies deliver technology that must perform as intended, every time. Our clients operate in safety-critical, operation-critical, and mission-critical environments such as on-highway, off-highway, aerospace, defense, and oil & gas, where failure is not an option, and delays cost market share.
LHP helps organizations design, architect, validate, and monitor complex systems. Our global team of engineers supports the development of advanced technologies, including high-voltage power electronics, hybrid and electric powertrain controls, connectivity, and ADAS platforms, enabling OEMs and Tier-1 suppliers to bring next-generation products to market quickly and with confidence.
In compliance-driven industries, LHP uses our model-based systems engineering (MBSE) approach, enhanced through AI, to help companies move quickly while meeting rigorous standards, including functional safety, ASPICE, and cybersecurity. Our teams have helped global technology companies achieve functional safety certification and ASPICE compliance in months rather than years, and established enterprise-grade safety and cybersecurity management systems for leading OEMs.
When organizations must make major technology leaps, such as launching next-generation platforms, future-proofing vehicle architectures, or proving new concepts to secure market-defining programs, LHP delivers the engineering disciplines, solutions, and on-time execution required to succeed.
Because in industries where technology must perform as intended, precision engineering matters.
Adam Saenz : Sep 25, 2018 8:19:00 PM
Improving driving safety through the reduction in opportunities for human error has been a focus of automotive manufacturers since the 1970s when...
Steve Neemeh : Jun 9, 2020 10:14:54 AM
What the future holds for ADAS control systems Introduction
Steve Neemeh : Oct 9, 2025 10:00:01 AM
Artificial Intelligence (AI) is no longer a side feature in vehicle safety and embedded software development. It is rapidly becoming the core driver...
Adam Saenz : Mar 23, 2022 9:50:26 AM
What is SOTIF? (Safety of the Intended Functionality) ISO/PAS 21448 The practical operation of automated vehicles in a real-world environment...
Elias Hernandez : Sep 9, 2020 1:40:34 PM
What Is Adaptive AUTOSAR? A Compelling Overview on Current and Future Trends.
Marty Muse