How to Partition ADAS, IVI and Body Functions in a Multi-Domain ECU Without Overbuilding the Platform
Quick Overview
Problem: Each domain passes bring-up on the consolidated platform. Integration then exposes partitioning that cannot be certified, updated or scaled down a trim.
Common failure points: Coexistence claimed without the evidence the standard asks for, temporal interference through shared cache and memory bandwidth, update units that couple three release trains, thermal derating under combined load, body I/O pulled into a compute class it never needed.
Where it appears: Central compute and cross-domain SoC programs, cockpit domain controllers absorbing ADAS, zonal transitions where body supervision migrates inward, platform families that must serve top trim and base trim from one design.
Engineering focus: A function-level partitioning matrix built before silicon selection, coexistence and freedom-from-interference evidence under worst admissible load, update-unit granularity, peripheral ownership and thermal budgeting.
An Illustrative Integration Scenario
The scenario below is a composite drawn from how these programs typically fail, not an account of a single project. The engineering claims that follow are sourced; the narrative is there to locate them.
The architecture passes review. One central compute module, a hypervisor, three guests: an ADAS perception stack, an Android-based cockpit, and a real-time partition carrying body supervision and vehicle-state services. The SoC has more cores and more AI throughput than the workload analysis asked for.
Bring-up goes fine. Perception meets its frame budget. The cockpit boots and drives its displays. Body services talk to the zone controllers.
Integration is where it comes apart, and it comes apart in three directions at once. Perception overruns its budget — but only with the cockpit compositing at full load after a hot soak. The safety assessor looks at the real-time partition, finds a safety-related function sharing a context with non-safety services and no timing evidence separating them, and asks what the coexistence argument is. A low-risk body fix cannot ship on its own, because it is packaged in the same update unit as a perception stack that is mid-validation.
None of that is a capacity problem. The SoC was never short of compute. What had never been engineered was the boundary between the domains.
Wrong Assumption
The assumption is reasonable and almost universal: if the SoC has enough cores, enough TOPS, enough memory bandwidth, and a hypervisor on top, the domains will coexist. Capacity sizing is treated as the hard part and isolation as a configuration step afterwards.
Coexistence is not a capacity property. It is an evidence property. ADAS, IVI and body functions differ on at least seven independent axes — safety integrity, latency bound, data rate, I/O locality, failure-mode expectation, update cadence and trim variance — and a core count answers none of them. A platform can carry four times the compute it needs and still be unable to show that a safety-related function is not delayed by a non-safety video pipeline sharing the last-level cache. At that point the headroom buys nothing.
The Partitioning Matrix, On Three Real Functions
Most articles tell you to partition by criticality and stop there. The useful version is the table itself. Here are three functions that genuinely end up on the same platform discussion, scored on the axes that decide placement.
| Attribute | ADAS perception | IVI rendering and display composition | Power window control |
|---|---|---|---|
| Typical safety integrity | ASIL B to D depending on the function and any decomposition in the OEM’s HARA | QM, though safety-relevant displayed content (e.g. a tell-tale or rear-view image) can carry an ASIL | QM to ASIL A/B depending on the HARA; anti-pinch is the safety-relevant part |
| Latency behaviour | Hard end-to-end deadline, typically tens of milliseconds sensor-to-decision | Soft: a dropped frame is visible, not hazardous — unless it is a safety-relevant display path | Hard but small: a millisecond-scale control and sense loop |
| Data rate into the partition | Multi-gigabit camera, radar and lidar streams | High internal GPU and display bandwidth, low external | Bytes per message |
| I/O locality | Sensors routed to wherever perception runs | Display links routed to wherever composition runs | Motor, Hall or current sense sit in the door |
| Failure expectation | Fail-operational or fail-degraded | Fail-silent is usually acceptable | Fail-safe, and must keep working when central compute is degraded or updating |
| Update cadence | Tied to sensor changes, model retuning and validation campaigns | Consumer cadence, frequent and visible | Rarely, and intolerant of regression |
| Trim variance | Low to moderate — sensor set varies by package | High — screen count, size and resolution | High — number of windows, one-touch, anti-pinch availability |
| Where it belongs | Its own partition on the application/AI domain, with sensor paths terminating there | Its own guest; sharing a die with ADAS is reasonable where the SoC provides isolation mechanisms | Execution stays at the zone or the door; supervision, diagnostics and version state are exposed upward |
Two things fall out of the table that do not fall out of a block diagram.
The first is that ADAS and IVI differ enormously on cadence and criticality but agree on one thing that matters for placement: both want high internal bandwidth and both have their I/O terminating at the compute node. That is why cross-domain silicon targets exactly this pair.
The second is that the window lift disagrees with both on every axis except “hard deadline”, and that its deadline is trivially small. Nothing about it argues for central execution. Everything about its I/O locality and its fail-safe expectation argues against. What it does have is state worth centralising — position, fault codes, software version — which is a service-interface problem, not a compute problem.
Build this table for every function before the silicon shortlist, and overbuilding becomes difficult. Build it after, and the table becomes a justification exercise.
Why It Fails
Coexistence is asserted rather than argued. ISO 26262-6:2018, 7.4.8 is explicit: where software components of different ASILs, or safety-related and non-safety-related components, share an element, each is treated in accordance with the highest ASIL unless the criteria for coexistence in ISO 26262-9:2018, Clause 6 are met. 7.4.9 then says that if software partitioning is used to implement freedom from interference, shared resources must be used such that freedom from interference between partitions is ensured — and carries a note worth memorising: tasks within a software partition are not free from interference among each other. Annex D is informative. It gives the interference categories — timing and execution, memory, exchange of information — and example mechanisms, not a compliance checklist.
The practical consequence is not “the whole guest automatically becomes ASIL B”. It is that the affected scope has to be determined and the coexistence argument has to be made, and both are cheap before silicon selection and expensive after. Teams that skip the step do not get an automatic penalty; they get an open question at the assessment, at the worst possible moment. Where that argument sits in the wider safety case is covered in ISO 26262 functional safety in automotive.
The hypervisor is treated as the argument rather than one of the mechanisms. A type-1 hypervisor partitions what it can address: vCPUs, memory regions, interrupt routing, and device assignment through the SMMU. The shared last-level cache, memory-controller bandwidth and the interconnect sit below that, and which isolation tools you actually get there depends on the SoC, not on the hypervisor.
Arm’s MPAM extension exists to close exactly that gap — it is an optional extension to Armv8.4-A and later that lets software apportion and monitor memory-system resources, usually cache and memory bandwidth. It is worth looking at how far that goes in practice. In Arm’s own automotive reference software stack, MPAM is enabled in Xen, domains can be assigned dedicated system-level cache slices, and the documentation states two limitations plainly: MPAM support in Xen is available for system-level cache partitioning only, and on the reference platform model only the programmer’s view of MPAM is provided, with no functional behaviour change implemented. That is Arm’s own stack, documented honestly. Treat a hypervisor diagram as a mechanism inventory to be checked against your silicon, not as evidence. The broader runtime picture is in hypervisor-based partitioning of safety, infotainment and AI workloads.
Update units are coupled even when partitions are not. ADAS releases move with validation campaigns, cockpit software with a consumer cadence, body functions barely at all. If those ship inside one update unit, the slowest train sets the pace regardless of how clean the runtime isolation is. The vehicle update frameworks address this at the level of granularity and dependency rather than keys: the Uptane standard is built around per-ECU targets metadata, vehicle and ECU version manifests, and explicit dependency-and-conflict resolution across ECUs, so that what gets delivered to one component is checked for compatibility with what is already installed elsewhere. The architectural question is therefore what the smallest safely-shippable unit is, how version compatibility is checked across units, and how recovery works when one fails — not how many signing keys exist.
Thermal and power are left out of the partitioning decision. An application-class automotive SoC with a large AI subsystem and multiple display pipelines sits in a different thermal class from a real-time controller or a body microcontroller. Under combined load at high ambient, it derates. Derating changes execution time, and changed execution time undermines the timing analysis the safety argument rests on. A partition map never checked against the worst admissible thermal envelope is a timing assumption waiting to fail during hot-soak testing.
Body logic and body I/O get moved together. Body functions are I/O-bound, not compute-bound: lighting, access, seats, windows, climate actuation, mostly over LIN, CAN FD and increasingly 10BASE-T1S at the edge. Centralising the logic is often right. Centralising the execution means deciding where the physical I/O terminates, and harness length follows that decision rather than the software one. It also makes a comfort function dependent on central-node availability, and puts a function with a fifteen-year stability expectation into an update domain that changes monthly. This is the layer where body, chassis and lighting ECU work stays close to the actuator for reasons that have nothing to do with compute cost.
Hidden System Complexity
vehicle function → ASIL assignment → partition → vCPU and core allocation → shared LLC and memory-controller bandwidth → SoC thermal envelope → peripheral ownership via SMMU → zonal link (LIN / CAN FD / 10BASE-T1S / Ethernet) → actuator
The decision is taken at the left end. The failure appears at the right end, several layers away.
A timing violation seen at the actuator can originate in a cache allocation three layers up. A non-safety video workload evicting a real-time partition’s working set from the last-level cache produces a latency distribution that looks clean at the mean, acceptable at p95, and wrong in the tail — and only when both workloads peak together. Measure one guest at a time and the platform looks correct.
The silicon vendors have drawn their own conclusions from this, and it is worth reading what each one actually claims rather than flattening them into one story.
Renesas’ R-Car X5H is positioned as a cross-domain SoC built to run ADAS, IVI and gateway functions on one device: 3 nm, 32 Arm Cortex-A720AE cores, six lockstep Cortex-R52 cores with ASIL D support, up to 400 TOPS of AI performance, UCIe chiplet extension, and a hardware-based freedom-from-interference mechanism for mixed-criticality multi-domain integration.
NXP’s S32N55 answers a different question. It is the first member of the S32N vehicle super-integration family, and what it consolidates is real-time vehicle control: 16 split-lock Cortex-R52 cores at 1.2 GHz, split or lockstep up to ASIL D, hardware-enforced isolation, a multi-port TSN Ethernet switch and a CAN hub. There is no large AI or graphics subsystem in that description because that is not what it is for.
Qualcomm’s Snapdragon Ride Flex sits with Renesas on the question it answers — co-locating ADAS and digital cockpit workloads on one SoC — and the publicly stated mechanisms are hardware support for isolation, freedom from interference and QoS, plus a dedicated ASIL-D safety island.
Two of these consolidate ADAS and IVI. One consolidates real-time control. None of them presents an undifferentiated compute block, and each pairs its application domain with a hard real-time or safety element. A platform architecture that ignores that split is working against the hardware it runs on. The wider architectural context is in centralized vs zonal ECU architecture for software-defined vehicles.
Failure Patterns
Pattern 1 — The coexistence question arrives at assessment. A safety-related function shares an execution context with non-safety services. Memory partitioning is in place via the MPU; timing partitioning is not, because the OS was configured without execution budgets and no timing analysis was run under contention. There is no automatic penalty — but there is also no argument, and the scope of what has to be treated at the higher ASIL now has to be established with the board and silicon already frozen.
Pattern 2 — The update-unit deadlock. A body-control defect needs a fast turnaround. The partition is logically independent, but it is packaged in an update unit that also contains the perception stack, and that stack is mid-validation. The fix waits, and the support cost of waiting eats into the consolidation’s business case.
Pattern 3 — Combined-load derating. Perception meets its budget in isolation and the cockpit meets its budget in isolation. Run both at peak through a hot-soak cycle and the SoC derates, pushing perception past its deadline. It never reproduces on the bench, because the test matrix was written per domain by the team that owned that domain.
Software-Defined Vehicle Platform Engineering
Multi-domain ECUs get overbuilt when partitioning is settled after silicon selection instead of before it. The expensive failures — unresolved coexistence arguments, coupled update trains, combined-load timing violations, trim-level cost inflation — are architecture and evidence failures, not capacity failures, and more compute closes none of them. Promwad works on E/E architecture selection, compute partitioning, embedded OS and virtualisation, ECU software and ASPICE-aligned delivery for automotive and transportation platforms.
Engineering Experience Across Automotive Compute Platforms
An IVI Platform Where Two Operating Systems Had to Share One Device
A supplier of IVI systems for luxury cars came to Promwad during a phase where simultaneous programs for several OEMs had outrun its internal engineering capacity. The work had to be ASPICE-compliant and the platform had to carry a next-generation IVI stack.
The device is built on a Qualcomm SA8155 SoM. Promwad’s team developed software to test the hardware, built the board support package, and ported both QNX and Linux for the final configuration — bringing up the video subsystem on QNX, configuring camera serial-data drivers, developing audio codec drivers, resolving GPIO interrupt behaviour and adding GPIO expander support on QNX.
The second workstream was the architecture itself, developed to ASPICE SWE.2: identifying applications, services and libraries, specifying which subsystem each runs on, defining required and provided interfaces for every component, and producing sequence diagrams showing how the architecture is exercised in real system scenarios.
That second list is the part worth noting. “Which subsystem does this component run on, and what interface does it expose across the boundary” is the partitioning matrix in ASPICE form. On a multi-domain platform it is also the artefact a coexistence argument is later built on, which is why it belongs in the architecture phase rather than in integration. The published write-up is IVI system architecture design and BSP development under ASPICE.
A shorter analogy from a different domain makes the hardware side of the same point. For an industrial battery system, Promwad designed a dual-MCU BMU architecture built for SIL2 certification readiness: a primary NXP S32K37xx for processing and control, and an independent S32K1xx for safety monitoring, watchdog supervision and fault detection, connected over a dedicated SPI channel with protocol-level integrity checks. Supervision was separated in hardware rather than argued for in software. One board covers all three system roles — SoM-equipped coordinator, primary and secondary — with the distinction made at assembly through configuration.
Solution Approach
Step 1: Build the partitioning matrix before the silicon shortlist. One row per function, not per team. Use the attributes in the partitioning matrix above. Functions that agree on safety integrity, failure expectation and update cadence are candidates to share a partition; functions that differ on any of the three carry a burden of proof on whoever wants them merged. This matrix is an input to silicon selection, and it maps cleanly onto the ASPICE SWE.2 architecture artefacts you will need anyway — which is the practical link between ASPICE-aligned development and partitioning that holds up later.
Step 2: Tie the timing evidence to deadlines, not to percentiles alone. Running every guest at peak simultaneously and measuring the safety partition’s response-time distribution — p99.9 included — is the right load test, and it will find most of what a per-domain matrix misses. It is not by itself a safety conclusion. The conclusion has to be stated against the function’s deadline and a justified upper bound on delay under the worst admissible combination of load, temperature and operating mode, with the residual interference you cannot eliminate written into the timing budget rather than assumed away. Where the platform offers cache or bandwidth partitioning, configure it and measure with it off to quantify what it actually buys. Where it does not, cache coloring and throttling are the fallback, and the bound gets correspondingly looser.
Step 3: Decide update-unit granularity before anything else. Define the smallest unit you can safely ship on its own, how version compatibility is checked between units, and how the vehicle recovers when one fails mid-update. Per-partition signing keys and A/B layouts are implementation options that follow from those answers, not requirements that precede them. This is the cheapest of the three steps to get right early and the most expensive to retrofit, because it reaches into the bootloader, the partition layout and the back-end.
A partition that has never been measured with every other partition at peak is a hypothesis. Most multi-domain timing violations are not discovered — they are created, at the moment the test matrix was written per domain by the team that owned that domain.
Real Trade-Offs
One application SoC versus an application SoC plus a safety or real-time device. Single-die consolidation cuts BOM, wiring and package count, and modern cross-domain silicon is built to enable it. A discrete real-time or safety device costs parts and board area and gives physical independence that is far easier to argue. The decision is less about cost than about how much of the argument you want to carry in software.
Static partitioning versus dynamic resource management. Static assignment of cores, memory and devices at build time makes timing analysable and the safety case tractable, at the cost of utilisation. Dynamic allocation improves average efficiency and makes worst-case timing much harder to bound. Safety-relevant partitions generally want static; cockpit and AI workloads generally do not.
Cache and bandwidth partitioning versus peak throughput. Reserving cache portions or bandwidth buys predictability by taking those resources away from everything else. On a shared last-level cache that is a real throughput cost. Measure it on target rather than estimating it, and check what your specific SoC and hypervisor actually implement before budgeting for it.
Centralising body supervision but not body execution. Exposing body-domain state, diagnostics and version information upward gives fleet visibility and OTA coverage without moving the control loops or the I/O. It needs a service interface that did not previously exist. For most programs this is the better half of the consolidation, and it is the pattern zonal architecture in production converges on.
AUTOSAR Adaptive versus Classic versus a custom stack. Adaptive targets high-performance ECUs with a POSIX-based OS, service-oriented communication — SOME/IP among the supported bindings — dynamic deployment and OTA support. Classic remains the fit for deterministic body and control functions, with OS-level memory partitioning and timing protection that map onto freedom-from-interference evidence. Mixing them across one platform is normal; choosing one for everything is how a body function ends up carrying infrastructure it does not need. Selection criteria are in AUTOSAR Adaptive versus custom automotive middleware stacks.
Chiplet scalability versus a fixed monolithic die. Die-to-die AI extension lets one platform serve base and top trim without a new base SoC, which is the trim-variance problem that drives overbuilding. It also adds a boundary the isolation argument has to cross. Worth it when the trim spread is wide; overhead when it is not.
Typical Multi-Domain Partitioning Tasks
Function-Level Partitioning Analysis
Building the per-function matrix across safety integrity, latency bound, data rate, I/O locality, failure mode, update cadence and trim variance, and converting it into a partition map and a silicon requirement before vendor selection.
Coexistence and Interference Evidence
Establishing the coexistence argument under ISO 26262-6 and ISO 26262-9 Clause 6, and producing memory, timing and communication isolation evidence against function deadlines under worst admissible load.
Hypervisor and Platform Integration
Static resource assignment, SMMU-based device ownership, cache and bandwidth partitioning where the SoC supports it, and guest bring-up across Linux, QNX, Android and AUTOSAR environments.
Update and Lifecycle Domain Design
Update-unit granularity, cross-unit version compatibility, and safe recovery, so release cadence is decoupled in the pipeline and not only on the architecture diagram.
When to Review Your Partitioning Architecture
- Silicon was selected on core count and TOPS, and the partition map was produced afterwards.
- A safety assessment asks for the coexistence argument and there is no artefact that answers it.
- Latency is within budget per domain and out of budget only when domains peak together, or only after a hot soak.
- A low-risk body or comfort fix cannot ship without revalidating an unrelated ADAS or cockpit release.
- The base trim carries the compute, memory and cooling specified for the top trim, with no software path to scale down.
- A comfort or body function becomes unavailable when central compute is degraded, rebooting or updating.
- Test plans are written per domain by the team owning that domain, with no combined-load gate between them.
From Partitioning to Platform Implementation
At this point the work is partitioning analysis and isolation evidence, not another round of silicon benchmarking. In practice: the function-level matrix built before silicon selection, timing evidence stated against deadlines under worst admissible load, update-unit granularity decided deliberately, and a thermal budget the timing analysis is actually tied to.
Two decisions sit closest to the architect here. At the compute layer, secure partitioning in automotive hypervisors defines what the runtime can enforce and what it cannot. At the OS layer, the QNX, Zephyr and embedded Linux selection question determines which partitions can carry a certification argument at all.
Related Reading
- Automotive Ethernet backbones in zonal production — what happens to partition boundaries once traffic leaves the die.
- Deterministic networking with TSN in automotive Ethernet — the scheduling layer behind cross-domain timing budgets.
- VirtIO as an SDV platform requirement — how portable a partition map is across silicon generations.
- OTA for ML models in cars — update granularity when a partition carries models rather than firmware.
- Sensor timestamping across gPTP domains in multi-ECU systems — the timing argument extended beyond one device.
Relevant Automotive Engineering Experience
This class of problem shows up most where silicon is selected on throughput and the partition map is written afterwards, in cockpit platforms absorbing ADAS or body supervision without a matching change in verification scope, and in platform families serving a wide trim spread from one compute design. Promwad’s directly relevant delivery includes IVI architecture and BSP work on a Qualcomm SA8155 platform with QNX and Linux ported for the final configuration and the architecture developed to ASPICE SWE.2, and a 360-degree truck camera system brought into compliance with ASPICE CL2 and ASIL-B on a Lattice CrossLink-NX FPGA and NXP S32K148 MCU, with requirements managed in Polarion and unit, integration, HIL and system testing carried through.
FAQ
What is a multi-domain ECU, and how is it different from a domain controller?
Should ADAS, IVI and body functions run on one ECU?
What does ISO 26262 actually require when functions of different ASILs share a device?
Does a hypervisor give freedom from interference by itself?
How do you avoid overbuilding a multi-domain platform?
Can update cadence be separated without separate hardware?
Related Engineering Cases
- IVI System for Luxury Cars: Architecture Design and BSP Development: Qualcomm SA8155 SoM, QNX and Linux ported for the final configuration, software architecture developed to ASPICE SWE.2.
- 360-Degree Camera System Development for Trucks: Lattice CrossLink-NX FPGA and NXP S32K148 MCU, brought into compliance with ASPICE CL2 and ASIL-B, requirements managed in Polarion with HIL and system testing.
- Railway BMU Architecture Built for SIL2 Certification Readiness: Dual-MCU split between control and independent safety supervision, one board covering three system roles.
- In-Vehicle Infotainment Simulator with Qualcomm: IVI and UX validation without target hardware available.