AUTOSAR, SOME/IP and virtualised head units

CAN is a broadcast of signals. SOME/IP is a set of services you call and subscribe to. That shift — signal-oriented to service-oriented — is most of what "software-defined vehicle" means in practice, and it changes how the Android side is built.

Classic vs Adaptive AUTOSAR#

Android talks to both, but usually indirectly: a gateway ECU or the vendor network service on the same SoC translates, and the Vehicle HAL is what Android sees regardless.

SOME/IP in one page#

Scalable service-Oriented MiddlewarE over IP. Four mechanisms:

• Service discovery — services announce themselves; clients find them at runtime rather than being wired together at build time.
• Method calls — request/response RPC.
• Events — server-pushed notifications.
• Fields — a value with a getter, setter and change notification.

Interfaces are described in Franca IDL and code is generated from it, the same way you would generate from a .proto.

package com.oem.vehicle
 
interface SeatComfort {
    version { major 1 minor 0 }
 
    attribute UInt8 massageIntensity        // field: get, set, notify
    attribute Boolean heatingEnabled
 
    method setMassageProgram {
        in  { UInt8 seatId  UInt8 program }
        out { Boolean accepted }
        error { INVALID_SEAT NOT_AVAILABLE }
    }
 
    broadcast seatOccupancyChanged {
        out { UInt8 seatId  Boolean occupied }
    }
}

Mapping that onto the VHAL model:

Virtualised head units#

Modern vehicle computers consolidate what used to be several ECUs onto one SoC, with a hypervisor partitioning it.

┌──────────────────────────────────────────────────────┐
│                     Hypervisor                       │
├──────────────┬──────────────┬────────────────────────┤
│  Guest: RTOS │  Guest: AAOS │  Guest: cluster/safety │
│              │              │                        │
│  vehicle net │ infotainment │  telltales, ADAS view  │
│  safety fns  │ apps, media  │  ASIL-rated            │
│  early boot  │              │                        │
└──────────────┴──────────────┴────────────────────────┘
        │              │                  │
        └──── shared memory / virtio ──────┘

Why this shape:

• Freedom from interference. A safety-rated cluster cannot be affected by an infotainment crash. The hypervisor is what lets them share silicon anyway.
• Boot ordering. The RTOS guest is up in milliseconds and can drive the rear-view camera and telltales long before Android is ready.
• Mixed criticality. ASIL-rated functions live in a guest certified for it; Android does not have to be.

What changes for the Android side#

Your VHAL no longer talks to a CAN controller. It talks to the RTOS guest through a virtio channel or shared memory ring.

Practical consequences:

• Latency has a new hop. Budget for the inter-guest transport, and measure it rather than assuming.
• The other guest boots first. Android must handle vehicle state that changed before it existed — you will receive an initial burst at startup.
• Resource contention is real. CPU and memory are partitioned; a hypervisor misconfiguration shows up as mysterious Android jank that profiling inside Android cannot explain.
• Debugging spans guests. A signal wrong on screen may be wrong in the RTOS guest, and no amount of adb will show you that.

Android Virtualization Framework#

AOSP also has its own virtualization support (AVF), used for isolated workloads in protected VMs. It solves a different problem from a cockpit hypervisor — it is Android isolating a workload from itself, not a safety domain isolating itself from Android — but the two increasingly appear on the same device, and it is worth knowing which one someone means.

What actually matters in practice#

For most engineers on an SDV programme, the day-to-day reality is narrower than the architecture diagrams suggest:

1. Signals arrive through some transport you do not control.
2. Something converts them into VHAL properties.
3. Everything above that is ordinary AAOS work.

The value of understanding the layer below is knowing where to look when a value is wrong — and being able to say, with evidence, whether the defect is in Android or arrived that way.

Next#

The debugging toolkit that makes all of the above tractable.