Adaptive 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.

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?”

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

“We use SOME/IP but not AUTOSAR”: SOME/IP is a transport 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 AUTOSAR certification. Ask which ara:: APIs are implemented vs custom equivalents.

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?

A. Signal-based COM over CAN with ComSignal mappingB. Service-based communication via ara::com over SOME/IPC. Direct shared-memory between OSEK tasksD. LIN master-slave polling

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

A. ara::comB. ara::execC. ara::perD. ara::diag

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

A. On body ECU MCUs using AUTOSAR Classic OS tasksB. On the HPC SoC running QNX and/or AAOS with POSIX processesC. Inside the modem AMSS firmware onlyD. On the LIN bus master node