Software-Defined Vehicle: AUTOSAR Classic vs Adaptive Architecture (2026)

A modern premium car can contain well over a hundred electronic control units, each with its own firmware, its own supplier and its own update story. That is the legacy the software-defined vehicle (SDV) is meant to escape. The pitch is simple: decouple features from hardware, ship them as software, and keep improving the car for a decade after it leaves the factory. The engineering reality is less glamorous. The brake controller still has to meet a hard deadline every millisecond, while the infotainment stack wants a full Linux userland and a monthly release train.

Those two worlds are exactly what AUTOSAR Classic and AUTOSAR Adaptive were built for, and they are complements, not rivals. This guide explains where each one fits in a modern vehicle, how SOME/IP and DDS carry data between them, how domain and zonal electrical/electronic (E/E) architectures change the wiring and the compute, and what UNECE R155, R156 and ISO/SAE 21434 demand from the update pipeline.

What this covers: domain vs zonal vs central-compute E/E design, Classic vs Adaptive internals, SOME/IP and ara::com, DDS, hypervisors and mixed criticality, OTA and cloud backends, regulation, a migration path, and the failure modes that actually bite.

Context and Background

For about two decades the dominant automotive pattern was the distributed ECU: one function, one box, one supplier. Add a feature and you add a controller and a wire. The result is a network of dozens of CAN and LIN buses, a few FlexRay or Ethernet backbones, and a wiring harness that is among the heaviest and most expensive parts of the car. If you want the bus-level background, our complete technical guide to the CAN bus protocol covers arbitration, framing and CAN FD, which remain the lingua franca of the low-level vehicle network.

AUTOSAR (AUTomotive Open System ARchitecture) is the industry partnership that standardised the software side. The Classic Platform targets deeply embedded, hard real-time microcontrollers and has been in series production for many years. The Adaptive Platform was introduced for high-performance computers that run a POSIX operating system, need dynamic deployment and talk over Ethernet. AUTOSAR publishes both as numbered releases; the Adaptive specification set in release R25-11, dated 27 November 2025, raised the minimum C++ version to C++17, added a safe API for hardware accelerators, suspend-to-RAM in state management, and a Remote Persistency cluster accessed through ara::com services (AUTOSAR AP release overview, R25-11).

The SDV conversation adds three pressures on top of the standards. First, compute is consolidating: domain controllers, then zonal gateways, then one or two central high-performance computers (HPCs). Second, regulation made post-sale software a legal object: UNECE R155 requires a cybersecurity management system and R156 a software update management system, both in force since the summer of 2022 for new vehicle types. Third, the business wants a continuous delivery loop, so the car has to behave like a managed fleet of edge devices. That last point is why this topic belongs next to industrial IoT: the same fleet, OTA and digital-twin patterns apply, just with a much harsher safety envelope. We cover the update half in depth in our guide to secure IoT OTA firmware update architecture.

A caution on vocabulary. “Software-defined vehicle” has no standard definition. Treat any claim that a vehicle “is an SDV” as a statement about its architecture and release process, not a certification. The useful test is operational: can the OEM change vehicle behaviour after delivery without touching hardware, and can it do so safely, audibly and reversibly?

From Domain to Zonal to Central Compute: The Reference Architecture

Short answer: A software-defined vehicle replaces many function-specific ECUs with a few zonal controllers that handle I/O by physical location, connected by an Ethernet backbone to one or more central compute nodes that run service-oriented software. Classic AUTOSAR typically stays in the safety-critical real-time edge, Adaptive AUTOSAR or Linux runs on the HPC.

The shift happens in three recognisable stages, and most vehicles on the road in 2026 sit somewhere between stage one and stage two.

Figure 1: Reference software-defined vehicle architecture. Zonal controllers aggregate sensors and actuators by location, an Ethernet backbone links them to central compute and a telematics gateway connects the vehicle to the cloud.

Figure 1 shows the target shape. Sensors and actuators connect to the nearest zonal controller over CAN, CAN FD, LIN or 10BASE-T1S. Each zonal controller forwards traffic over automotive Ethernet (100BASE-T1 or 1000BASE-T1, standardised in IEEE 802.3bw and 802.3bp) to the central compute. A telematics control unit handles the cellular uplink to the OEM backend. Safety-critical actuation, such as braking and steering, keeps a deterministic path and, in most designs, its own redundant controller.

Stage one: domain architecture

In a domain architecture, ECUs are grouped by function: powertrain, chassis, body, infotainment, ADAS. Each domain has a domain controller that gateways between its internal buses and a central gateway. This is evolutionary and low risk, and it is where much of the installed base sits. The downside is that physical wiring still follows function, so a feature that spans domains, such as a remote-start that touches body, powertrain and telematics, needs coordination across suppliers and gateways.

Stage two: zonal architecture

A zonal architecture groups by physical location instead. A front-left zone controller owns the headlamp, the wheel-speed sensor, the door module and the local power distribution, regardless of which “function” each belongs to. The wiring harness shortens because each sensor runs to the nearest zone, not to a distant functional ECU. Vendors and OEMs have publicly claimed meaningful harness weight and cost reductions from this; those numbers vary by programme and are vendor claims, so treat any single percentage with caution.

The deeper benefit is not copper. Zonal controllers act as I/O and power-distribution nodes with a thin software layer, which means application logic can migrate to central compute without rewiring. A zone controller usually runs Classic AUTOSAR, because it needs deterministic I/O, fast start-up and functional safety up to ASIL-D on some paths.

Stage three: central compute

Central compute concentrates application software on one or two HPCs, typically system-on-chips with multi-core Arm Cortex-A clusters plus real-time Cortex-R or lockstep cores, GPUs or NPUs for perception, and a hardware security module. Here the Adaptive Platform, a hypervisor-hosted Linux, QNX or Android Automotive live side by side. Services run as processes that can be started, stopped and updated independently, and communicate by service discovery rather than by static signal tables. This is the tier where the vehicle starts to resemble a small data centre, and where ideas from robotics middleware apply; our ROS 2 on Jetson Orin warehouse robotics tutorial shows the same publish-subscribe thinking on an embedded GPU module.

Why centralisation is not free

Consolidation concentrates risk. One HPC failing can take down functions that used to fail independently, so freedom from interference becomes a first-class design property rather than a nice-to-have. Thermal envelope, power draw during sleep, boot time and the blast radius of a single bad release all grow with the size of the central node. Several OEMs have publicly discussed delays in their SDV programmes, which is a reminder that the architecture is easy to draw and hard to ship. We will return to this under failure modes.

AUTOSAR Classic vs Adaptive: What Actually Differs

Short answer: AUTOSAR Classic is a statically configured, OSEK-derived platform for microcontrollers, with a Basic Software stack and a generated Runtime Environment (RTE) that fixes everything at build time. AUTOSAR Adaptive runs on POSIX operating systems on application processors, with C++ applications, dynamic service discovery, and manifests that let software be deployed and updated independently.

The two platforms solve opposite halves of the same problem. Classic optimises for determinism, memory footprint and certifiability. Adaptive optimises for flexibility, performance and incremental delivery.

Figure 2: Layered comparison of the AUTOSAR Classic stack (MCAL, Basic Software, RTE, software components) and the Adaptive stack (POSIX OS, functional clusters, ara::com, adaptive applications).

Classic Platform internals

A Classic ECU is built in layers. The microcontroller abstraction layer (MCAL) wraps the silicon drivers. Above it the Basic Software (BSW) provides the ECU abstraction, services layer and complex drivers: communication stacks for CAN, LIN, FlexRay and Ethernet, diagnostics (UDS over CAN or DoIP), memory services, mode management and the operating system. The OS is derived from OSEK/VDX: statically configured tasks and ISRs, fixed-priority preemptive scheduling, and the AUTOSAR OS extensions such as timing protection, memory protection and OS-Applications for partitioning.

On top sits the RTE, a code-generated layer that connects application software components (SWCs) to each other and to the BSW through ports. SWCs are written in C against generated interfaces; they declare runnables that the RTE maps to OS tasks. Because the RTE and BSW configuration is produced by tooling from an ARXML description, the entire system is known at build time. That is the point: worst-case execution time analysis, schedulability analysis and safety arguments depend on it.

The cost of this model is rigidity. Adding a signal usually means regenerating and reflashing the whole ECU image. Communication is signal-based and statically routed, so a new consumer for an existing signal means changing the configuration of the sender, the gateway and the receiver.

Adaptive Platform internals

The Adaptive Platform is a set of functional clusters specified by AUTOSAR, running on top of a POSIX-based operating system. The R25-11 specification set includes clusters such as Execution Management, Communication Management, State Management, Diagnostics, Update and Configuration Management, Vehicle Update and Configuration Management, Cryptography, Log and Trace, Persistency, Platform Health Management, Time Synchronization, Network Management, Firewall and an Intrusion Detection System Manager (AUTOSAR R25-11 release overview). Applications are C++ executables linked against the ARA (AUTOSAR Runtime for Adaptive Applications) APIs.

Two ideas carry most of the weight:

• Execution Management (EM) starts, supervises and stops processes according to an Execution Manifest and a Machine Manifest. A function group can be switched between states (for example off, startup, driving, diagnostics), and EM starts the right set of processes for each state, honouring declared dependencies.
• Communication Management (CM) exposes the ara::com API. Applications are service providers or consumers: they offer or find service instances, subscribe to events, call methods and read or write fields. The binding underneath, SOME/IP in the specification’s primary profile, with DDS as an additional supported binding, is selected by configuration, not by application code.

Because deployment is described by manifests rather than compiled-in, an application can be installed, updated or removed without regenerating the whole platform image. That does not mean updates are casual; they still go through safety and security release processes. It means the unit of change shrinks from “the ECU image” to “the application and its manifest”.

Side-by-side comparison

Dimension	AUTOSAR Classic	AUTOSAR Adaptive
Target hardware	Microcontrollers (MCU), tens of MHz to a few hundred MHz, KBs to MBs of RAM	Application processors (MPU/SoC), multi-core, GBs of RAM
Operating system	OSEK-derived AUTOSAR OS, static configuration	POSIX (for example QNX, Linux, with a defined OS interface)
Language	C (mostly)	C++ (minimum C++17 as of R25-11)
Scheduling	Static, fixed-priority, build-time analysable	Dynamic processes, POSIX scheduling
Communication	Signal-based CAN, LIN, FlexRay, plus SOME/IP in recent releases	Service-oriented, ara::com over SOME/IP or DDS
Configuration	ARXML and generated RTE, full-image build	Manifests, independent application deployment
Update unit	Whole ECU image (some partial reflash)	Application or cluster, through UCM
Typical use	Brake, steering, powertrain, zone I/O	ADAS, gateways, connectivity, central compute
Safety certification	Mature up to ASIL-D	Possible but heavier; safety usually via architecture and partitioning

Two caveats on that table. First, the boundaries are porous: Classic has gained Ethernet and SOME/IP support, and the AUTOSAR project defines a Classic-to-Adaptive interoperability story, so a Classic ECU can consume an Adaptive service. Second, “Adaptive can reach ASIL-D” is contested in practice; real programmes tend to place the highest-integrity function on a Classic or bare-metal safety island and use the Adaptive side for the QM to ASIL-B portion, a pattern we discuss under hypervisors below. Where exact support claims matter, check the version of the specification your supplier ships against.

Service-Oriented Communication: SOME/IP, ara::com and DDS

Short answer: SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the automotive service protocol that carries remote procedure calls, events and fields over UDP or TCP, with SOME/IP-SD announcing service availability. ara::com is the C++ API that hides it. DDS is the alternative publish-subscribe middleware with rich QoS, standardised by the OMG.

Service orientation is the real architectural change in the SDV. Signals on a CAN bus are broadcast whether anyone is listening; services are discovered, subscribed to and torn down at runtime.

Figure 3: SOME/IP service lifecycle. A provider offers a service via SOME/IP-SD multicast, a consumer finds it, subscribes to an event group, and then receives notifications and issues method calls.

The SOME/IP wire format

Every SOME/IP message starts with a 16-byte header: a Message ID composed of a 16-bit Service ID and a 16-bit Method or Event ID (events use the high bit of the second half), a 32-bit Length, a Request ID made of a Client ID and a Session ID, then one byte each for Protocol Version, Interface Version, Message Type and Return Code. Message types distinguish requests, fire-and-forget requests, notifications, responses and errors. The payload that follows is serialised according to the interface description, with fixed rules for alignment, length fields on variable-size data and, since recent revisions, bitfield support in the AP communication specification.

SOME/IP-SD is a special service (Service ID 0xFFFF) carried in SOME/IP messages, by convention on UDP port 30490, that handles OfferService, FindService, SubscribeEventgroup and their acknowledgements. Entries carry TTLs, so a provider that disappears is detected when its offer expires, and a Stop-Offer signals a clean shutdown. The details of the service-discovery state machine (initial wait, repetition phase, main phase) are what make start-up deterministic enough for automotive timing budgets, and they are worth reading in the AUTOSAR specifications rather than trusting a summary.

What ara::com looks like in application code

ara::com generates typed proxy and skeleton classes from the service interface model. The sketch below is illustrative and simplified: real generated names depend on the interface and toolchain, and error handling is abbreviated. It shows the shape of a consumer subscribing to a wheel-speed event.

// Consumer side (illustrative; generated names vary by toolchain).
#include "ara/core/instance_specifier.h"
#include "wheelspeed_proxy.h"          // generated from the service interface
#include <iostream>

namespace proxy = vehicle::wheelspeed::proxy;

int main() {
  // Instance specifier is mapped to a concrete SOME/IP instance in the manifest.
  auto spec = ara::core::InstanceSpecifier::Create("Chassis/WheelSpeedConsumer").Value();

  auto handles = proxy::WheelSpeedProxy::FindService(spec).Value();
  if (handles.empty()) { std::cerr << "no provider yet\n"; return 1; }

  proxy::WheelSpeedProxy svc{handles.front()};

  svc.speedEvent.Subscribe(/*maxSampleCount=*/8);
  svc.speedEvent.SetReceiveHandler([&svc] {
    svc.speedEvent.GetNewSamples([](auto sample) {
      std::cout << "front-left rpm: " << sample->frontLeftRpm << "\n";
    });
  });

  // ... run until the Execution Management terminate signal arrives ...
}

The application never mentions UDP, multicast groups or serialisation. The binding choice (SOME/IP or DDS), the event group IDs and the QoS live in the deployment model and the service instance manifest. That separation is the point: the same application can be redeployed on a different network layout.

Where DDS fits

DDS (Data Distribution Service) is a data-centric publish-subscribe standard from the Object Management Group with a rich set of QoS policies (reliability, durability, deadline, liveliness, history). In vehicles it appears mostly in autonomy and robotics stacks (ROS 2 uses DDS implementations through RMW layers) and in some central-compute designs, and AUTOSAR Adaptive lists DDS as a supported network binding alongside SOME/IP, with a technical report for DDS Security integration. For a protocol-level treatment of discovery, QoS and RTPS, see our DDS Data Distribution Service complete guide.

A practical split many teams adopt: SOME/IP for vehicle-function services that must interoperate across suppliers and with Classic ECUs, DDS (or ROS 2 on top of it) inside the perception and planning compute domain where high-bandwidth, many-to-many data flows and flexible QoS dominate. Gateways bridge the two. That bridging layer is where schemas drift, timestamps get lost and latency budgets quietly blow up, so give it an owner.

Latency and determinism in practice

Switching from signals to services trades a fixed, analysable timing model for a statistical one. A CAN frame at 500 kbit/s has a bounded worst-case latency computed from priority and bus load. A SOME/IP notification crossing an Ethernet switch depends on queueing, so deterministic delivery needs Time-Sensitive Networking (TSN) features from the IEEE 802.1 family, such as time synchronisation (802.1AS), credit-based shaping (802.1Qav) and scheduled traffic (802.1Qbv), plus VLAN and priority configuration. Without them, a burst of camera or logging traffic can delay a control event. The honest design rule is to keep hard control loops on bounded links and use service-oriented Ethernet for state, configuration and soft-real-time data, unless you have verified TSN end to end.

Mixed Criticality: Hypervisors, Partitioning and Safety Islands

Short answer: Mixed-criticality vehicle computers use a type-1 hypervisor or a separation kernel to run safety-related and non-safety guests on one SoC with enforced isolation, while a separate safety island (a lockstep MCU core running Classic AUTOSAR) supervises and provides the fail-safe path.

One central computer has to host an ASIL-rated driver-assistance function, a QM infotainment guest and sometimes a third-party app environment such as Android Automotive. ISO 26262 allows decomposition only if the elements are demonstrably independent, which is what a hypervisor and a memory-protection unit provide: spatial isolation (separate address spaces enforced through stage-2 page tables and IOMMU or SMMU), temporal isolation (budgeted CPU scheduling) and controlled communication through virtio or shared-memory channels.

Commercial hypervisors and separation kernels used in automotive include QNX Hypervisor, Green Hills INTEGRITY Multivisor, Wind River and open projects built around Xen or KVM. Which one is right depends on safety certification evidence, device pass-through support and ecosystem, not on a headline benchmark.

Where each AUTOSAR flavour lands

A typical 2026 central-compute SoC splits like this:

• Safety island: a lockstep Cortex-R or equivalent core runs Classic AUTOSAR with an ASIL-D OS, handles watchdog supervision of the application cores, and owns the minimal-risk-manoeuvre logic.
• Application partition: Adaptive AUTOSAR on a certified POSIX OS runs the driving functions, state management and diagnostics.
• Infotainment partition: Linux or Android Automotive as a separate guest with no direct path to actuators.

Platform Health Management in the Adaptive Platform plus alive, deadline and logical supervision on the Classic side give the layered watchdog. The cross-partition link is a narrow, validated interface; anything that bypasses it is a safety finding waiting to happen.

Update, Security and Regulation: The OTA Loop

Short answer: UNECE R155 requires a cybersecurity management system (CSMS) and R156 a software update management system (SUMS). ISO/SAE 21434 defines the engineering process for cybersecurity, ISO 24089 gives implementation guidance for software updates. Together they turn OTA from a feature into an audited process with rollback, integrity checks and fleet traceability.

Figure 4: A regulated OTA pipeline. The OEM backend signs campaign packages, the telematics unit verifies them, the Adaptive update manager stages them, and zonal Classic ECUs receive partial images with rollback and RXSWIN tracking.

What the regulations actually require

UNECE R155 covers cybersecurity: the manufacturer must operate a CSMS covering development, production and post-production, including threat monitoring and response. UNECE R156 covers software updates: a SUMS that identifies target vehicles and their configurations, checks update compatibility, assesses whether an update affects an existing type approval, verifies integrity and authenticity, defines rollback routines for failed or interrupted updates, and uses a Regulatory Software Identification Number (RXSWIN) to identify type-approval-relevant software. UL Solutions summarises the SUMS requirements and notes that type approval needs a UNECE-listed audit and a certificate valid for three years, in combination with the CSMS certificate (UL Solutions: SUMS according to UNECE R156). ISO 24089 is referenced there as implementation guidance.

Dates deserve care. The regulations took effect for new vehicle types in mid-2022; the commonly cited second milestone, applying them to all newly registered vehicles in the EU, was July 2024. Other markets, including Japan, Korea and several others, apply their own timelines and exact scope. Verify the current text on the UNECE site and with your homologation authority before relying on any date in a compliance plan. This article is architecture analysis, not legal advice.

Mapping the pipeline to AUTOSAR

On the Adaptive side, the Update and Configuration Management (UCM) cluster handles package processing on the vehicle, while Vehicle Update and Configuration Management (VUCM) coordinates updates across several UCM instances and ECUs. A package is downloaded, verified (signature and hash checks backed by the Cryptography cluster and a hardware security module), staged to an inactive slot, activated at a safe vehicle state and then confirmed or rolled back. The A/B slot or equivalent is what makes R156-style rollback practical.

On the Classic side, updates arrive through a bootloader that supports UDS flashing (services 0x34, 0x36 and 0x37 for download, transfer and exit), often with dual-bank flash and secure boot chain verification. Zonal controllers typically update as part of a campaign orchestrated by a master, often the central compute node, which also records the resulting software inventory for the RXSWIN trail.

Backend and digital twin

The SDV cloud backend is a fleet-management system: vehicle identity and certificates, campaign targeting by configuration, staged rollouts with canaries, telemetry ingestion, diagnostics and feature entitlements. The architecture is close to industrial IoT fleet management, and a per-vehicle digital twin that tracks installed software, configuration and health is what lets the OEM answer the SUMS question “which vehicles can safely receive this update?” Our OTA firmware update architecture guide covers manifest signing, delta updates and rollback logic in more depth, and most of it transfers directly.

Security controls inside the vehicle

ISO/SAE 21434 expects threat analysis and risk assessment (TARA) for each item, with cybersecurity goals flowing into requirements. In practice, that yields a layered set of controls: secure boot and measured boot on every programmable controller, authenticated diagnostics, message authentication for critical frames (SecOC in Classic, TLS or IPsec on Ethernet links), network segmentation through firewalls and gateway filtering, and an intrusion detection system that reports to a fleet security operations centre. The Adaptive Platform includes Firewall and IDS Manager clusters for exactly this reason.

A Practical Migration Path

Few teams get to start from a clean sheet. A defensible path from a domain architecture to an SDV looks like this, in order.

1. Inventory and classify every function by safety integrity, timing needs and update frequency. This produces the placement map: Classic safety island, Adaptive application, or non-AUTOSAR guest.
2. Introduce an Ethernet backbone and a gateway first. Service-oriented communication can start with a few high-value services (vehicle state, diagnostics, charging) while legacy signals continue on CAN.
3. Define service interfaces centrally. Treat the service catalogue like a public API: versioned, reviewed, backward compatible. Interface drift is the most common cause of integration pain.
4. Move one application at a time into Adaptive, beginning with non-safety, update-hungry ones such as connectivity, navigation backends and diagnostics aggregation.
5. Stand up the update and security process before the features. CSMS and SUMS evidence takes longer than code. An OTA pipeline that cannot roll back is a liability, not a feature.
6. Consolidate zones as hardware generations turn over, keeping the zonal software on Classic with SOME/IP gateways so central compute can evolve independently.

Budget for tooling as much as for code. Model-based configuration (ARXML), service-interface generators, virtual ECUs and hardware-in-the-loop benches are what make weekly integration feasible. Cloud-based virtual validation, running the same binaries against simulated vehicles, is the other major lever, and it is where the digital-twin thinking this site covers elsewhere pays back most directly.

Trade-offs, Gotchas, and What Goes Wrong

The architecture diagrams are tidy; the failure modes are not. These are the ones that recur.

Start-up and shutdown timing. A static Classic ECU is up in tens of milliseconds. An Adaptive node booting Linux, launching dozens of processes and completing service discovery takes seconds. Features that must be available at key-on, such as a rear-view camera, need either an early-boot path or a staged start-up designed with EM function groups. Standby current is the other half: waking a large SoC to handle a remote request drains a 12 V battery if you are careless.

Service-discovery storms and version skew. When many services restart together, SOME/IP-SD traffic spikes. A consumer built against interface version 2 meeting a provider on version 1 fails in subtle ways unless the version policy is explicit. Pin versions, test compatibility matrices in CI, and make failure of discovery a handled state.

Signal-to-service gateway drift. Gateways that translate CAN signals to SOME/IP events copy timestamps, cycle times and validity flags badly. A stale value presented as fresh is worse than an absent one. Carry validity and age explicitly.

Hidden coupling through shared resources. Freedom from interference fails at the shared cache, memory bandwidth and interconnect level, not just at the scheduler. Measure interference under load before relying on partition budgets.

Update blast radius. A defect in a signed campaign reaches every targeted vehicle. Staged rollout, health gates, automatic halt conditions and tested rollback are mandatory. Remember also that an update can invalidate a safety case or type approval; R156 requires that impact assessment.

Vendor claims. Promises of “full SDV in one chip” or specific percentage savings in cost, weight or time to market are marketing until you see the programme data. Ask for the measurement method.

Organisational mismatch. The hardest part is often that supplier contracts, release gates and homologation are still organised around a physical ECU. The software architecture can be service-oriented while the organisation is not, and Conway’s law wins.

Practical Recommendations

Use Classic where determinism, footprint and certification evidence dominate, and Adaptive where you need dynamic deployment, high compute and C++ productivity. Do not treat the choice as ideological; the shipping architectures that work combine both under a hypervisor with a safety island.

Make the service catalogue and the update pipeline your two first-class products. Everything else (OS, hypervisor, SoC) can be swapped over a vehicle generation, but interfaces and the signing, staging and rollback process outlive them.

Checklist before a programme gate:

• [ ] Every function has an assigned integrity level and a placement (Classic, Adaptive, guest).
• [ ] Hard control loops run on bounded links; Ethernet services carry state and soft-real-time data, or TSN is verified end to end.
• [ ] Service interfaces are versioned with a documented compatibility policy.
• [ ] Execution Management function groups define start-up order, and key-on features have a measured time budget.
• [ ] Hypervisor isolation is tested under worst-case shared-resource load.
• [ ] OTA packages are signed, verified in hardware-backed trust, staged to an inactive slot and rolled back automatically on failure.
• [ ] CSMS and SUMS evidence, TARA and RXSWIN inventory are current for each release.
• [ ] A staged rollout with halt conditions exists in the backend.
• [ ] Vendor performance and cost claims have been reproduced on your own hardware.

Frequently Asked Questions

What is a software-defined vehicle?

A software-defined vehicle is one whose features, behaviour and user experience are primarily determined by software that can be updated after sale, running on consolidated compute with a service-oriented architecture and a cloud backend. There is no formal standard, so the term describes an architectural and process direction: decoupled hardware and software, over-the-air updates, and continuous delivery under safety and cybersecurity regulation.

What is the difference between AUTOSAR Classic and Adaptive?

Classic targets microcontrollers with a static, OSEK-derived OS, C code, generated RTE and signal-based communication, giving determinism and mature safety certification. Adaptive targets high-performance processors with a POSIX OS, C++ applications, manifest-based deployment and service-oriented communication through ara::com over SOME/IP or DDS. They are complementary, and most modern vehicles use both together.

Is SOME/IP replacing CAN?

No. SOME/IP runs over IP, usually automotive Ethernet, and carries services between higher-level nodes. CAN and CAN FD remain widely used for low-cost, deterministic, low-bandwidth control signals, and zonal controllers typically use them to reach local sensors and actuators. The trend is a hybrid: CAN or LIN at the edge, Ethernet and SOME/IP in the backbone, with gateways translating between them.

What is a zonal architecture and why does it matter?

A zonal architecture groups ECUs and wiring by physical location instead of function. Zone controllers handle local I/O and power distribution and connect to central compute over Ethernet. The result is shorter, lighter harnesses and, more importantly, the freedom to move application software to central compute without rewiring. Claimed cost and weight savings vary by programme and should be verified.

Do UNECE R155 and R156 apply to every car?

They apply to vehicle categories and markets covered by the UNECE WP.29 agreement and national adoption, including the EU, Japan and Korea, with different dates for new types and all new vehicles. R155 requires a cybersecurity management system and R156 a software update management system. Confirm current scope and timelines with your type-approval authority, because they differ by region and vehicle class.

Can Adaptive AUTOSAR run safety-critical functions?

It can host functions up to some integrity levels when the platform, OS and hypervisor have the required evidence and the architecture limits fault propagation. In practice, the highest-integrity actuation path is often kept on a Classic or bare-metal safety island that supervises the Adaptive side. The right answer depends on your safety case, the certified OS and the specific ASIL decomposition.

Further Reading

• CAN bus protocol: complete technical guide for the signal-based network that Classic ECUs and zonal controllers still depend on.
• DDS Data Distribution Service: complete protocol guide for QoS and discovery in the publish-subscribe alternative to SOME/IP.
• ROS 2 Jazzy on Jetson Orin: warehouse robotics tutorial for the same middleware ideas on an embedded GPU platform.
• Secure IoT OTA firmware update architecture for signing, staging and rollback patterns.
• AUTOSAR Adaptive Platform R25-11 release overview, the primary source for current functional clusters.
• UL Solutions on UNECE R156 SUMS for a clear summary of update-management requirements.

By Riju — about