Adaptive Platform

Intermediate10 min read

Assumes: 4.2 Classic Platform

TL;DR

AUTOSAR Adaptive targets HPC SoCs running POSIX OSes (Linux, QNX), the compute class your Qualcomm cockpit platform lives in. Instead of static ARXML and signal-based COM, Adaptive uses dynamic manifests, C++14/17 processes, and service-based communication via ara::com over SOME/IP. Key APIs include ara::exec (process lifecycle), ara::diag (diagnostics), and ara::log (logging). Your platform runs Adaptive-style services on QNX/AAOS even if nobody labels the folder “AUTOSAR.”

Classic AUTOSAR owns the MCU ECUs. Adaptive owns the domain controller and cockpit SoC where you actually write code. This page maps the architecture you’ll recognize in integration specs, middleware layers, and supplier deliverables. One is from the age of microcontrollers; the other was born for Snapdragons. Together, they fight crime (and integration bugs).

Target: HPC System-on-Chips

Adaptive addresses a hardware class Classic was never designed for:

Characteristic	Typical Adaptive Platform
Silicon	Qualcomm SA8155P/SA8295P, TI Jacinto, NVIDIA DRIVE, NXP S32G
RAM	GB (LPDDR)
OS	POSIX: Linux, QNX, sometimes PikeOS
Language	C++14/17
Config	Dynamic: machine manifest, service manifest, updated at runtime/OTA
Communication	Service-based: SOME/IP, optionally DDS
Execution unit	Processes (not static OS tasks)
Lifecycle	OTA individual applications/services

Adaptive means POSIX processes talking services, not static signal tasks on an MCU.

Classic vs Adaptive: Side-by-Side

Dimension	Classic	Adaptive
Hardware	MCU (AURIX, RH850, S32K)	HPC SoC (Qualcomm, TI, NVIDIA)
OS	AUTOSAR OS (OSEK)	POSIX (QNX, Linux)
Language	C	C++14/17
Config timing	Build-time (ARXML)	Runtime (manifest)
Config format	ARXML → code generation	JSON/manifest → Execution Manager
Communication model	Signals (ComSignal)	Services (ServiceInterface)
Protocol	CAN, LIN, FlexRay	Ethernet SOME/IP (+ CAN via gateway)
Execution	OS Tasks + Runnables	POSIX Processes
Discovery	Static routing tables	Dynamic (SOME/IP-SD)
Update	Full ECU reflash	Per-process OTA
Typical safety ASIL	Up to ASIL-D on ECU	Up to ASIL-B on domain (varies)
Your stack	Gateway, body ECUs	QNX VM, AAOS, middleware services

Architecture Overview

flowchart TB
    subgraph AdaptiveApps["Adaptive Applications (C++ Processes)"]
        APP1["Navigation Service<br/>ara::com provider"]
        APP2["Vehicle Data Consumer<br/>ara::com client"]
        APP3["Diagnostic App<br/>ara::diag"]
    end

    subgraph ARA["Adaptive AUTOSAR (ara:: APIs)"]
        COM["ara::com<br/>Proxy · Skeleton · SOME/IP binding"]
        EXEC["ara::exec<br/>Execution Management"]
        LOG["ara::log<br/>Logging & Trace"]
        DIAG["ara::diag<br/>UDS over DoIP"]
        PER["ara::per<br/>Key-Value Storage"]
        CORE["ara::core<br/>Error handling · Future/Promise"]
    end

    subgraph Middleware["Communication Middleware"]
        SOMEIP["SOME/IP + SOME/IP-SD<br/>Service discovery"]
        IAM["Identity & Access Management"]
    end

    subgraph OS["POSIX Operating System"]
        QNX["QNX Hypervisor / Linux"]
        PROC["Process scheduler · IPC · Sockets"]
    end

    APP1 --> COM
    APP2 --> COM
    APP3 --> DIAG
    APP1 --> LOG
    APP2 --> PER
    COM --> SOMEIP
    EXEC --> APP1
    EXEC --> APP2
    EXEC --> APP3
    SOMEIP --> PROC
    DIAG --> PROC
    QNX --> PROC

Mental Model

If Classic is a factory with fixed assembly lines, Adaptive is a cloud-native microservice cluster on wheels. Each Adaptive Application is a container-like process — started, stopped, and updated independently. ara::com is the service mesh (register, discover, call). The Execution Manager is Kubernetes for car software — reads manifests, launches processes, enforces dependencies. SOME/IP-SD is DNS for services — “who provides VehicleSpeed right now?”

Mnemonic: Adaptive = AUTOSAR went to college — learned POSIX, services, and dynamic deployment.

Think About It

Adaptive AUTOSAR runs on POSIX. Could you run it on a Raspberry Pi? What’s missing?

Reveal Answer

You can run SOME/IP and C++ services on a Pi, but you lack the automotive Adaptive stack: Execution Manager, certified ara:: functional clusters (com, exec, diag, per), SOME/IP-SD with automotive timing, E2E protection, and IAM/security bindings. A Pi also misses vehicle manifests, supplier-qualified middleware (Vector, EB, ETAS), and ISO 26262 / cybersecurity evidence OEM programs require. It’s a useful dev sandbox, not a homologated Adaptive Platform ECU.

POSIX OS: Linux, QNX, and Your Platform

Adaptive deliberately does not define its own OS. It runs on POSIX-compliant operating systems. QNX serves as the safety VM for real-time services and hypervisor guests — the primary choice for ASIL-rated Adaptive apps. Linux handles IVI, ADAS fusion, and high-compute workloads, common for non-safety Adaptive clusters. PikeOS combines a safety-certified hypervisor with a POSIX guest for mixed-criticality platforms.

On a Qualcomm cockpit platform, you’ll typically see:

• QNX running safety-critical and real-time Adaptive services
• AAOS (Linux-based) running infotainment, which may consume Adaptive services via SOME/IP or IPC bridges
• Hypervisor isolating VMs with separate Adaptive application sets per VM

Adaptive assumes processes, threads, sockets, and file I/O (standard POSIX), not OSEK tasks and alarms.

ara::com over SOME/IP

ara::com is the Adaptive communication API. It abstracts service-oriented middleware behind C++ interfaces:

Provider (Server) Side

// Skeleton: implements the service interface
class VehicleSpeedSkeleton : public ara::com::skeleton::VehicleSpeedSkeleton {
  void UpdateSpeed(float speed) {
    VehicleSpeedEvent.Send(speed);  // Event notification to subscribers
  }
};

Consumer (Client) Side

// Proxy: calls a remote service
auto proxy = VehicleSpeedProxy::Create(handle);
proxy->VehicleSpeedEvent.Subscribe([](float speed) {
  // Handle speed update
});

Under the hood, SOME/IP carries the bytes over Ethernet:

• Service ID / Instance ID / Method ID / Event ID: addressing
• SOME/IP-SD: service discovery (offer/find/subscribe)
• Serialization: payload packing (often aligned with Franca IDL definitions)

This is the same SOME/IP from Module 3.3. Adaptive standardizes the API surface (ara::com) above it.

Common Gotcha

Beginner thinks “we use SOME/IP but not AUTOSAR.”

Reality: SOME/IP is the wire protocol; Adaptive defines how applications bind to it (ara::com proxies/skeletons), how services are deployed (manifests), and how processes are managed (ara::exec). You may have a proprietary SOME/IP stack that follows Adaptive patterns without formal certification — ask which ara:: APIs are implemented vs custom equivalents.

Common Gotcha

Beginner thinks AUTOSAR Adaptive is just Classic AUTOSAR running on Linux.

Reality: completely different execution model. Classic uses static ARXML, OSEK tasks, C, and signal-based COM. Adaptive uses dynamic manifests, POSIX processes, C++14/17, and service-based ara::com over SOME/IP. They share the AUTOSAR name — not the architecture.

Dynamic Manifest-Based Configuration

Classic freezes config in ARXML at build time. Adaptive deploys via manifests interpreted at startup (and updatable via OTA):

Manifest	Purpose
Machine Manifest	Defines the ECU/platform: network endpoints, processor cores, available executables
Service Instance Manifest	Declares which services this machine offers or requires
Execution Manifest	Per-application: binary path, dependencies, startup order, resource limits
Diagnostic Manifest	UDS data identifiers, routines, session configs

The Execution Manager (EM) reads manifests and:

1. Starts processes in dependency order
2. Reports ProcessState (running, terminated, error)
3. Supports controlled restart and OTA replacement of individual apps

This enables OTA of a single service without reflashing the entire SoC image, a core SDV requirement.

Key ara:: APIs

API	Namespace	What It Does	Daily Relevance
Communication	ara::com	Service proxies, skeletons, events, methods, fields	Vehicle data services, ADAS interfaces, cross-VM comms
Execution Management	ara::exec	Process lifecycle, state reporting, dependency resolution	Startup sequencing, crash recovery, OTA deployment
Diagnostics	ara::diag	UDS services, DTC handling, DoIP transport binding	Workshop diagnostics, fleet monitoring
Logging	ara::log	Structured logging with context IDs	Debug traces across Adaptive processes
Persistency	ara::per	Key-value storage with redundancy/wear leveling	Calibration data, user settings, service state
Core	ara::core	Result<T,E>, Future/Promise, error domains	Foundation types used by all ara:: APIs

ara::exec in Practice

When the cockpit SoC boots:

1. EM reads Execution Manifest for all Adaptive apps
2. Starts Platform Services first (logging, communication daemon)
3. Starts Functional Clusters (vehicle data aggregator, navigation, etc.)
4. Reports state to State Management, which may gate AAOS startup on QNX service readiness

If you’ve debugged “AAOS starts but vehicle properties are empty,” the failure may be an Adaptive service not reaching Running state. That’s an ara::exec problem, not an Android problem.

Franca IDL and Service Definitions

Adaptive service interfaces are often defined in Franca IDL (or ARXML service interfaces) and generated into C++ proxy/skeleton classes. A Franca definition specifies methods (request/response), events (fire-and-forget notifications), and fields (event + getter/setter). The generated code binds to SOME/IP via configuration in the service manifest. Changing a method ID means regenerating and redeploying, not editing a DBC file.

Processes, Not Static Tasks

Classic schedules runnables as OS tasks with fixed periods defined in ARXML. Adaptive runs POSIX processes:

Classic	Adaptive
Runnable invoked by OS alarm every 10 ms	Process runs main loop, internal threads
Fixed stack per task	Process heap managed by OS
Static task count	Processes start/stop dynamically
Inter-SWC via RTE	Inter-process via ara::com (SOME/IP or IPC binding)

This enables service-oriented architecture at runtime. A navigation service can restart without taking down the vehicle data aggregator.

Where You'll See This

On a Qualcomm cockpit platform, Adaptive patterns appear as:

• Middleware services on QNX exposing vehicle data via SOME/IP
• Service manifests in OTA packages listing updated process binaries
• Execution Manager logs showing process startup order and failures
• ara::log (or equivalent) output in /var/log or QNX slog
• AAOS VHAL backends that are SOME/IP clients to QNX-hosted Adaptive services
• Integration tests verifying SOME/IP service offer/find before declaring “platform ready”

When reading supplier docs, look for “Adaptive AUTOSAR R20-11” or “ara::com compliant middleware.” That’s your service layer contract.

Connect the Dots

Your Qualcomm platform runs Adaptive services on QNX/AAOS. The SA8155P/SA8295P cockpit SoC is HPC-class silicon. Classic AUTOSAR doesn’t run here natively. QNX hosts real-time Adaptive applications (vehicle data, safety-adjacent services); AAOS consumes vehicle information through SOME/IP or IPC bridges. Module 5 covers the hypervisor layout these processes run inside. Module 6 connects VHAL to the service layer. Module 4.4 shows how those services translate Classic CAN signals from the rest of the vehicle.

The short version

1. Adaptive targets HPC SoCs with POSIX OS, C++ processes, and dynamic manifests.
2. ara::com over SOME/IP replaces Classic’s signal-based COM for service communication.
3. Execution Manager orchestrates process lifecycle: startup order, OTA, restart.
4. Your Qualcomm QNX/AAOS platform is the Adaptive world, even if the codebase doesn’t say “AUTOSAR” on every folder.

Check Your Understanding

1. What communication model does AUTOSAR Adaptive use?

Recall

A. Service-based communication via ara::com proxies over SOME/IP protocolB. Direct shared-memory regions between OSEK tasks on the same MCU coreC. LIN master-slave polling with a fixed schedule table on the body busD. Signal-based COM over CAN with ComSignal mapping defined in ARXML files

2. Which ara:: API manages Adaptive application process startup, shutdown, and dependency ordering?

Recall

A. ara::exec — Execution Management for process lifecycle orchestrationB. ara::com — Communication Management for SOME/IP service bindingsC. ara::per — Persistency for storing application data to non-volatile memoryD. ara::diag — Diagnostics for UDS session handling and DTC management

3. On a Qualcomm cockpit platform, where do Adaptive-style services typically run?

Applied

A. On body ECU MCUs using AUTOSAR Classic OSEK task scheduling tablesB. On the HPC SoC running QNX or AAOS as POSIX user-space processesC. Inside the Qualcomm AMSS modem firmware subsystem only, not the APD. On a LIN bus master node that aggregates body peripheral slave data

4. Classic freezes configuration in ARXML at build time. How does Adaptive deploy and update application configuration?

Applied

A. Identical ARXML workflow with OSEK task tables compiled into the imageB. Kernel module parameters embedded in AMSS modem firmware configurationC. DBC signal files loaded by the Android Car Service during boot sequenceD. Dynamic manifests interpreted at startup and updatable via OTA per-app

5. A zone controller on the vehicle network receives an OTA capsule for one Adaptive software cluster. Which AUTOSAR Adaptive functional cluster handles update orchestration on the HPC?

Synthesis

Connects to: Module 8 — Build, Flash & Update

A. ara::com with SOME/IP-SD discovery and service binding negotiationB. UCM — packages, verifies, and applies software clusters with rollbackC. Classic PduR routing tables on the gateway ECU's flash configurationD. AMSS TelAF modem firmware loader running on the baseband processor

6. Your team runs vehicle-data middleware on QNX (SOME/IP provider) and AAOS infotainment (VHAL consumer). A developer says 'AAOS runs AUTOSAR Adaptive.' What is the most accurate correction?

Synthesis

Connects to: Module 6 — Three Operating Systems

A. AAOS is Android, not AUTOSAR — it consumes data via VHAL bridges to QNXB. Both QNX and AAOS must share identical ara::exec manifests and processesC. Neither VM runs Adaptive — only Classic ECUs on CAN are AUTOSAR-compliantD. Correct — AAOS is a fully certified AUTOSAR Adaptive platform stack

Further Reading

• AUTOSAR Adaptive Platform — Official specification for the AUTOSAR Runtime for Adaptive Applications (ARA), functional clusters, and service-based architecture on POSIX OSes.
• AUTOSAR Adaptive Platform Working Groups — Working groups for ara::exec, ara::com, persistency, and demonstrator integration that define the APIs and lifecycle patterns described on this page.
• Vector — DaVinci Adaptive AUTOSAR Builder — Commercial tooling for Adaptive service interface design, manifest generation, and ara::com proxy/skeleton code generation.
• AUTOSAR Methodology and Templates — Unified methodology covering machine manifests, execution manifests, and service deployment for both Classic and Adaptive platforms.
• Vector — SOME/IP Communication Know-How — Practical guide to SOME/IP wire protocol, service discovery (SOME/IP-SD), and method/event addressing that ara::com binds to in Adaptive deployments.
• ETAS — Adaptive AUTOSAR Solutions — Tier-1 perspective on Adaptive middleware implementation, execution management, and SOME/IP integration on automotive HPC platforms.
• AUTOSAR Cross-Standard Working Groups — Cross-platform specs including E2E protection and secure communication that apply when Adaptive services exchange data with Classic signal domains.