kevinferron.comKevin Ferron

The software stack

The layers of a software-defined vehicle, from silicon to cloud: hardware and SoC, operating system and hypervisor, middleware and services, applications, and the backend.

  • SoC
  • Hypervisor
  • Middleware
  • SOA
  • Cloud

A software-defined vehicle is one where the software can change without the hardware changing. For that to work, the code has to be separated from the chip it runs on, and the parts of the code have to be separated from each other.

This page uses a five-layer picture to organise that, from the hardware abstraction at the bottom to the cloud at the top. The five-layer split is SDVGuru’s way of putting it, not a standard. The facts in each layer are from AUTOSAR, the Object Management Group and Eclipse.

AUTOSAR is the long-standing reference. Its Classic platform covers small controllers with fixed, statically configured software. Its Adaptive platform covers bigger processors, with services that applications find at runtime. The two can run side by side in the same car.

Where the sources are silent, the page says so. They do not cover hypervisor or RTOS products, for instance, so the operating-system layer says only what AUTOSAR Adaptive assumes of it.

Open source sits beside the stack rather than in it. Eclipse S-CORE aims at an open core stack for vehicles, and it is a plan until its first release lands.

Beside the stack

Layer 3 of 5

Middleware

How software parts find and talk to each other. In Adaptive it is a set of functional clusters between the OS and the applications.

  • Adaptive organises its services into functional clusters that sit above the OS and below applications. Unlike Classic, the clusters are not stacked as layers.
  • Clusters named on the page include Communication Management, Execution Management, Diagnostic Management, Network Management, Persistency, Time Synchronization, Cryptography, Platform Health Management, Log and Trace and Firewall.
  • SOME/IP supports remote procedure calls, event notifications and serialization. Over UDP its payload should be 0 to 1400 bytes; larger payloads go over TCP or SOME/IP-TP segmentation.
  • DDS defines a data-centric publish-subscribe model: the APIs and the communication behaviour, including quality of service. Version 1.4 dates from March 2015.
  • AUTOSAR Adaptive supports DDS security.
  • Adaptive Diagnostic Management supports UDS (ISO 14229-1) over DoIP (ISO 13400-2) and SOVD (ASAM 1.0.0) over HTTP/REST.

Not stated in the sources

  • SOME/IP service discovery (a separate AUTOSAR document) was not read.

The five layers are SDVGuru’s framing, an opinion piece, not a standard. The facts inside each layer are from the specifications named beside them.

Sources

  1. SDVGuru SDV Architecture 2026: The Definitive Guide (S. Amin). June 2026; framing only, no figures.

    • Framing only: five layers, hardware abstraction to cloud backend
    • Framing only: edge versus cloud

  2. AUTOSAR Adaptive AUTOSAR Adaptive Platform. R25-11.

    • Layer facts
    • Adaptive: services found at runtime; coexistence with Classic
    • POSIX OS and PSE51
    • ARA, the runtime for adaptive applications
    • Signal-to-service translation; coexistence with Classic
    • Current release
    • Functional clusters
    • Cluster names
    • Adaptive supports DDS security
    • Diagnostic Management
    • Service-oriented architecture
    • Standardized app-interfaces and vehicle services
    • Vehicle Update and Config Management (V-UCM)

  3. OMG DDS Data Distribution Service. v1.4, 2015.

    • DCPS model
    • DCPS model; version history

  4. Eclipse SDV Eclipse SDV. as read October 2026.

    • Projects named on the home page
    • Home page description and project list

  5. AUTOSAR Classic AUTOSAR Classic Platform. R25-11.

    • Classic: fixed, statically configured software
    • Three software layers on a microcontroller
    • BSW structure
    • Virtual functional bus (VFB) and .arxml
    • Current release
    • Communication via RTE and VFB ports

  6. Eclipse S-CORE Eclipse Safe Open Vehicle Core (S-CORE). incubating; v1.0.0 planned for 2026-12-14.

    • Project status and planned v1.0.0 date

  7. AUTOSAR SOME/IP SOME/IP Protocol Specification (AUTOSAR FO PRS, Doc ID 696). R25-11, 2025-11-27.

    • Scope; payload size over UDP (R25-11, Doc ID 696)

Everything here is paraphrased from the pinned sources, not quoted, and figures are attributed to them. Anything illustrative is labelled as such. Where a source is silent the page says so instead of filling the gap.