PAVE360 Automotive Digital Twin: Virtual ECU Architecture

A modern premium car runs software on dozens of electronic control units, and the newest designs concentrate that software onto a handful of high-performance system-on-chip (SoC) computers. The silicon for those computers often does not exist when the software teams need to start. The classic answer, waiting for prototype boards and then debugging on a bench, no longer fits a product cycle in which features arrive through over-the-air updates. The PAVE360 automotive digital twin from Siemens is one of the most developed attempts to break that dependency: it models the chip, the ECU, the vehicle network and the driving world as one executable system, so software can run months before hardware is available.

This matters now because Siemens moved the product from a bespoke engineering programme to a packaged, cloud-hosted offering. It announced PAVE360 Automotive in December 2025 and tied it to Arm’s Zena compute subsystem. If you architect software-defined vehicle (SDV) toolchains, you need to know what is actually inside such a twin, what fidelity it delivers, and where it stops. You will leave with a layered mental model, a clear view of how virtual ECUs differ from the models you already run in software-in-the-loop (SIL) and hardware-in-the-loop (HIL) benches, and a checklist for deciding whether the approach fits your programme.

What this covers: the history and current state of PAVE360, its layered reference architecture, how virtual ECUs and SoC models are synchronised with vehicle and world models, an example CI workflow, capacity and fidelity trade-offs, failure modes, and practical adoption advice.

Context and Background

PAVE360 is older than the SDV buzzword. Siemens introduced it on 15 November 2019, two years after Siemens absorbed Mentor Graphics, as a pre-silicon autonomous-vehicle validation environment. The pitch was “chip to city”: model everything from SoC intellectual property blocks up through a full vehicle driving in a simulated smart city, and close the loop between sensing, decision and actuation before any silicon is fabricated (Siemens announcement, 2019). The heritage is electronic design automation (EDA), not mechanical simulation, and that shapes the product: its centre of gravity is the chip and the software that runs on it.

Since then the platform has been extended along three axes. In November 2023 Siemens announced PAVE360 on AWS with Arm-based technology, so that simulation runs on elastic cloud capacity rather than on-premises emulator farms (Siemens on AWS and Arm). In March 2025 it added support for AMD Radeon PRO V710 GPUs and AMD EPYC CPUs on Microsoft Azure, because scenario rendering and AI model execution need graphics acceleration (Digital Engineering 24/7). In June 2025 it announced support for Arm’s Zena Compute Subsystem (CSS), enabling software development for that platform before physical silicon exists (Siemens and Arm, June 2025).

The December 2025 announcement is the packaging step. Siemens described PAVE360 Automotive as a pre-integrated, cloud-based digital twin offering built on its Innexis software environment, aimed at ADAS, automated driving and in-vehicle infotainment (IVI). It claims setup time falls from months to days, and that integrating Arm Zena CSS can shorten software development timelines by up to two years. It was available to selected customers at announcement, with general availability planned for February 2026 and a live demonstration at CES 2026 (Siemens press release, 18 December 2025). Those are vendor claims, and the “up to two years” figure is an upper bound that depends on the baseline programme; I treat it as a marketing ceiling, not a planning number. I could not find independent, published programme-level measurements, so anything more precise would be invention.

It helps to place PAVE360 among the tools you probably already run. Model-in-the-loop and SIL environments execute compiled code against plant models on a workstation; they are fast but they abstract the processor. HIL rigs run production code on real ECUs against real-time simulated plants; they are faithful but scarce, late and expensive. Virtual ECUs sit between the two: they run the production binary on a functional model of the processor and peripherals. PAVE360’s ambition is to keep that binary-level fidelity while adding the SoC internals (interconnect, accelerators, safety island) and the surrounding vehicle, so timing and integration questions become answerable early.

There is a related standards story. Functional Mock-up Interface (FMI) packaging of plant models, and the co-simulation techniques covered in our guide to FMI, FMU and co-simulation for digital twins, are the lingua franca on the vehicle-dynamics side. PAVE360 sits where that world meets SystemC-style hardware modelling, and understanding the seam between them is most of the architecture.

The Reference Architecture: Five Layers Around the Silicon

At its core, the PAVE360 automotive digital twin is a stack of executable models joined by a synchronisation backplane: virtual hardware at the bottom, production software on top of it, a simulated vehicle network around it, and a scenario-driven world model feeding synthetic sensor data. The layers run under one time-management scheme so that the software experiences a consistent, repeatable timeline.

Figure 1: Layered architecture of a PAVE360-style automotive digital twin, from SoC and virtual ECU models up through the network, backplane and scenario simulator.

The figure shows the twin as four executable domains coordinated by a synchronisation backplane, with cloud infrastructure underneath and engineering tools (requirements, test management, CI) attached on the side. Reading bottom-up: SoC and virtual-ECU models hold the production software; a simulated vehicle network connects the ECUs; the backplane keeps clocks and messages aligned across models of different speed; and a scenario simulator produces sensor input and consumes actuator output.

Layer 1: SoC and virtual hardware models

The lowest layer represents the processor complex. For the Zena-based reference designs, the model represents Arm’s Zena CSS, which Arm describes as a 16-core Cortex-A720AE application cluster, a Cortex-R82AE-based Safety Island for real-time and safety functions, a coherent mesh interconnect (CMN S3AE), a Runtime Security Engine and TrustZone-based security (Arm newsroom). Arm also names virtual platforms from Cadence, Siemens and Synopsys as ways to simulate at the CSS level.

The key idea is mixed fidelity. Siemens’ product material describes hybrid simulation that mixes virtual models with register-transfer-level (RTL) code, and moving between fast virtual models and deeper analysis (Siemens PAVE360 product page). In practice that means the parts of the SoC your software barely touches are abstract, fast functional models, while a block you are designing or debugging, such as a custom accelerator, can run as RTL on an emulator like Siemens’ Veloce, which Siemens lists among the integrated products. The trade is always speed versus timing accuracy, and Layer 1 is where you choose it per block.

Layer 2: Virtual ECUs and production software

On top of the hardware models sit the virtual ECUs. Siemens’ blueprint material names IVI and ADAS ECU models based on Arm Zena CSS as the starting reference designs (PAVE360 blueprint blog). The CES 2026 booth material lists partner software running on them, including Elektrobit’s EB corbos Linux for Safety Applications, Qt’s cluster applications, Sensory voice recognition and the Autoware autonomous-driving framework via KPIT (CES 2026 preview).

The point of a virtual ECU in this context is that the same binary image, bootloader, hypervisor, operating system and application that will ship runs in the twin. That is what separates it from a SIL setup where the algorithm is recompiled for x86. If a race condition depends on cache coherency, interrupt latency or a driver interacting with a peripheral register, a binary-level model can expose it; a recompiled algorithm cannot.

Layer 3: The simulated vehicle network

ECUs never live alone. The blueprint describes virtual ECUs connected through a simulated vehicle network so ADAS and IVI domains can communicate. Siemens’ Innexis Virtual System Interconnect is described as connecting and synchronising communications between domains, systems, protocols and tools based on automotive standards. In a real vehicle that traffic is CAN, CAN FD, automotive Ethernet and service-oriented middleware such as SOME/IP; a credible twin needs message-level models of those buses, including arbitration, latency and fault injection, so that a gateway or diagnostic bug shows up in simulation.

Time, Synchronisation and Scenario Coupling

Getting layers to run together is harder than building them. A virtual ECU may run at a fraction of real time, a vehicle-dynamics model may be faster than real time, and an emulated RTL block runs at kilohertz-to-megahertz rates. The backplane’s job is to make all of them agree on what “now” means.

Why the backplane is the real product

Consider a camera frame that arrives at 30 frames per second. The scenario simulator produces it at simulated time t, the virtual ADAS ECU consumes it, and the resulting brake command must return to the vehicle model before the next control step. If the ECU model is running 20 times slower than wall clock, either the world model waits (simulated time advances only when the slowest participant is ready) or the results become nondeterministic. Conservative synchronisation, where every participant grants time only up to an agreed horizon, makes results reproducible at the cost of throughput.

This is the same trade-off familiar from FMI co-simulation master algorithms, with a step size and a set of participants. The difference is that here one participant is an entire computer executing an operating system. That participant cannot be paused at an arbitrary point the way a simple FMU can, and it produces a lot of state. Siemens describes the Innexis layer as the environment that ties these participants together and lets the twin be scaled by adding more software and models (Siemens press release).

Figure 2: Time-synchronised exchange between the scenario simulator, the backplane and a virtual ADAS ECU, showing how simulated time advances only when the slowest participant is ready.

Scenario coupling and physical models

The world model is where vehicle dynamics and sensors enter. Siemens lists Simcenter Prescan for testing complete vehicle behaviour with virtual ECUs and realistic driving scenarios, and Simcenter Amesim for physical models of actuators and vehicle dynamics. The December 2025 blueprint blog adds an “AI-infused” scenario simulator that supplies virtual sensor data and receives data from the electronics model.

Two fidelity issues deserve attention. First, synthetic sensor data is only as good as its sensor model: a rendered camera image lacks the noise, flare and rolling-shutter artefacts of a real imager, so perception networks validated on it may behave differently on the road. Second, actuator and vehicle-dynamics models must be validated against measured vehicles before you trust closed-loop conclusions. Neither problem is unique to PAVE360; both are inherited from any virtual validation scheme, and both are why the twin complements rather than replaces road testing. For a deeper treatment of how scene assets and physics are shared across tools, see our overview of OpenUSD for industrial digital twins.

Virtual-to-vehicle: closing the loop with real hardware

The product page describes a virtual-to-vehicle backplane that connects digital prototypes with physical hardware. At CES 2026 Siemens demonstrated a real production vehicle operating in a virtual environment, with IVI and ADAS applications running in the cloud-hosted twin and activating physical car features. The engineering meaning is that the same interfaces can be switched between virtual and real endpoints, so a function can migrate from pure simulation to a vehicle bench without rewriting the test harness. Latency across the cloud link constrains what can be closed in the loop, so hard real-time control loops still belong on real or near-real hardware; supervisory and infotainment functions tolerate the round trip.

Deeper Analysis: A Shift-Left Workflow, Fidelity Ladder and Worked Numbers

The architecture only pays off if it changes how teams work. Siemens’ pitch is shift-left: move integration and system testing from the end of a programme, when silicon and boards arrive, to the point where the first software commit exists. Here is what that looks like operationally.

A continuous-integration pipeline around the twin

The blueprint blog stresses that multiple developers can work in parallel across domains while continuous integration and delivery flows keep the system consistent, and the CES material lists a CI/CD pipeline integration from Tata Technologies. The pattern below is my illustration of how a team would wire it; it is not Siemens’ published configuration.

Figure 3: A shift-left pipeline in which every commit is built for the target, booted on a virtual ECU, exercised in scenario regressions and only then promoted to hardware benches and vehicles.

The pipeline has four stages. A commit triggers a cross-build for the target architecture, producing the same image format used for production. The image boots on a virtual ECU in the cloud twin, where smoke tests confirm boot, hypervisor partitioning and inter-domain messaging. A scenario regression then replays a library of driving situations and checks pass criteria. Only builds that pass are promoted to HIL rigs and vehicles, where the scarce physical resources are spent on the residual risk that simulation cannot retire.

A minimal, illustrative job definition might look like this (tool names and flags are placeholders, not a Siemens API):

# Illustrative only - adapt to your own CI system and twin launcher
stages: [build, boot, scenarios, promote]

build_target:
  stage: build
  script:
    - cmake --preset aarch64-safety && cmake --build build --parallel
    - ./tools/pack_image.sh build/ artifacts/ecu_adas.img

boot_on_virtual_ecu:
  stage: boot
  script:
    - twin-launch --platform adas-ecu --image artifacts/ecu_adas.img --timeout 900
    - twin-assert --log boot.log --expect "hypervisor: partitions ready"

scenario_regression:
  stage: scenarios
  parallel: 40   # one shard per scenario family
  script:
    - twin-run --scenario-set $SCENARIO_SHARD --seed 42 --report out/$CI_JOB_ID.json
    - ./tools/check_kpis.py out/$CI_JOB_ID.json --max-collision 0 --max-brake-latency-ms 150

Three details matter more than the syntax. Fix random seeds so failures are reproducible. Shard scenarios across cloud instances, because one virtual ECU is far slower than a real one. And record the twin version, model versions and scenario library hash with every result, since a passing run is only evidence relative to the model that produced it.

A fidelity ladder rather than a single twin

Teams often ask whether the twin should be cycle-accurate. Usually not. A more useful framing is a ladder, with each rung trading speed for accuracy, and the ability to move a component up or down the ladder is the feature.

Figure 4: The fidelity ladder: cheap and fast at the algorithm rung, progressively more accurate and scarce toward emulated RTL and real hardware in the loop.

At the bottom, algorithm-level models run near or above real time and suit functional exploration. Next, virtual ECUs run production binaries against functional processor models: fast enough for regression, accurate enough for software integration bugs. Above them, hybrid simulation replaces selected blocks with RTL, which is where performance and power questions get real answers but at a large slowdown. At the top sits real silicon on a HIL bench, the reference for timing and electrical behaviour.

Illustrative capacity arithmetic

Precise throughput figures for PAVE360 are not published, so the following is a worked example with assumed numbers, meant to show how to reason, not to predict your results. Suppose a virtual ADAS ECU runs at 1/20 of real time when executing your full perception stack. A 60-second driving scenario then takes 20 minutes of wall-clock time. A regression library of 2,000 scenarios of that length needs 2,000 x 20 = 40,000 minutes, roughly 667 hours, on one instance. Sharded across 40 instances, that becomes about 16.7 hours, which is an overnight run. Now suppose you also run the full library on every commit for ten developers: the arithmetic explodes, so you tier it. A 50-scenario smoke set (about 17 hours of serial time, under half an hour across 40 shards) gates each merge, while the full library runs nightly.

That tiering is not a detail. The economics of virtual validation are dominated by compute per simulated second, and cloud instance-hours become a line in the programme budget. Siemens’ cloud partnerships with AWS, and Microsoft Azure with AMD GPUs, exist because that compute has to be elastic; the AWS announcement itself frames the benefit as near-real-time simulation speeds and avoiding on-premises infrastructure upgrades.

Where PAVE360 sits against SIL, HIL and other virtual platforms

Dimension	Classic SIL	Virtual ECU on a twin	HIL bench	Vehicle testing
Runs production binary	No, recompiled	Yes	Yes	Yes
Processor internals visible	No	Yes, model-dependent	Limited (debug ports)	Very limited
Available before silicon	Yes	Yes	No	No
Scales elastically	Yes	Yes, compute-bound	No, physical racks	No
Timing fidelity	Low	Model-dependent	High	Exact
Cost per test hour	Lowest	Low to medium, cloud	Medium to high	Highest
Typical use	Algorithm and logic	Software integration, pre-silicon	Timing, I/O, fault injection	Final validation

Other vendors also supply virtual platforms: Arm’s own material names Cadence and Synopsys alongside Siemens for CSS-level simulation. The differentiator Siemens emphasises is breadth of integration: the twin connects to Teamcenter and Polarion for lifecycle data, and to Prescan and Amesim for the world. If your organisation already models systems in SysML v2, our tutorial on SysML v2 and PLM integration shows how requirements and architecture models can feed test intent into a twin like this.

Traceability: the PLM connection

The Arm announcement lists Teamcenter and Polarion among the integrations. That matters for compliance. ISO 26262 asks for evidence that safety requirements are verified, and UNECE regulations R155 (cybersecurity management) and R156 (software update management) require documented processes across a vehicle’s life. A twin that records which requirement each scenario covers, which software baseline it ran on and which model version produced the result turns simulation output into traceable evidence rather than a folder of logs. The question to ask any vendor is whether the twin’s results can be accepted by your assessor as verification evidence for a given safety level; that depends on tool qualification of the models, which is a customer-and-assessor conversation, and I found no published claim that PAVE360 results are pre-qualified.

For the broader question of how a vehicle twin connects to enterprise product data, the composition patterns in our piece on Siemens Digital Twin Composer with OpenUSD and Omniverse are a useful companion: PAVE360 covers the electronics and software twin, while composer-style tools cover the physical and factory-scale twin.

Trade-offs, Gotchas, and What Goes Wrong

A virtual ECU is a model, and every model is wrong in some way. The engineering discipline is knowing which way, and how much it matters for the decision at hand. The following failure modes come up in virtual-platform programmes generally, and they apply to a PAVE360-style twin.

Model divergence from silicon. Virtual platforms are typically built from the architecture specification and early RTL. If the final silicon differs, through an errata item, an undocumented peripheral behaviour or a late microarchitecture change, software validated on the model can misbehave on the chip. Mitigation is a formal correlation step: run a fixed set of directed tests on both the model and the first silicon, and quantify the differences before you retire bench testing. This is one reason the twin shortens the schedule but does not remove hardware validation.

Timing is the first casualty. Functional models tell you what the software does, not always how long it takes. Worst-case execution time, cache and interconnect contention, and safety-island response latency are timing questions; answering them requires either cycle-approximate models or the RTL and emulation rungs of the fidelity ladder. A team that tunes a real-time scheduler purely on a fast functional model may ship a deadline miss that only appears on hardware. Use the twin to find logic and integration bugs early; use higher fidelity or real hardware for timing sign-off.

Simulation speed versus scenario coverage. With a 20-fold slowdown as in the earlier example, coverage becomes a budget question. Teams that run only a handful of hand-picked scenarios gain false confidence. The fix is scenario generation with explicit coverage metrics, in the spirit of scenario-based safety assurance, and honest reporting of what fraction of the operational design domain has been exercised.

Sensor realism and the sim-to-real gap. Synthetic sensor data can differ statistically from real captures. Perception models fine-tuned or validated on synthetic frames can degrade on real ones. Calibrate sensor models against recorded data, and keep a real-data regression set alongside the simulated one.

Cloud latency and cost surprises. Cloud hosting brings elasticity and also two new risks: variable throughput when shared instances are busy, and bills that scale with simulated seconds. Fixed seeds and deterministic scheduling mitigate the first; scenario tiering and spot capacity policies address the second. Data residency and intellectual property are further concerns, since a virtual ECU image contains your production software and often supplier code. Confirm tenancy, encryption and contractual terms with your legal and security teams before you upload it.

Tool qualification and evidence. For ISO 26262 work, tools that could introduce or fail to detect errors need a tool confidence level assessment. A simulator used to claim verification coverage falls in that category. Plan qualification effort early, and do not assume vendor marketing about “validation” equals accepted verification evidence.

Lock-in and integration debt. A twin built on one vendor’s backplane and model formats can be costly to leave. Prefer open interfaces where possible: FMI for plant models, SystemC TLM-2.0 (IEEE 1666) style interfaces for hardware models, and standards-based network models. Ask which parts of your twin are portable if you change vendors, and keep your scenario definitions in an open format.

Organisational friction. Perhaps the most underestimated problem is that the twin crosses team boundaries: chip architects, software platform teams, function developers and validation engineers all consume it, and each owns different model fidelity requirements. Without a named owner for the twin as a product, with versioned releases and a change log, teams drift onto incompatible model versions and results stop being comparable.

The fidelity ladder in Figure 4 also maps each failure mode above to the rung where it is resolved: model divergence at the hardware-in-the-loop rung, timing at the RTL rung, and integration defects at the virtual ECU rung.

Practical Recommendations

Whether you adopt PAVE360 or another virtual platform, the same approach reduces risk. Start with the question you need answered, not the tool. If the risk in your programme is late software integration on new silicon, a virtual ECU on a twin is a strong lever. If the risk is analogue behaviour, power delivery or sensor physics, you need different models and more hardware.

Pick one vertical slice first. A single domain, for example the IVI cockpit or a lane-keeping function, built end to end on the twin, with its CI pipeline and a defined scenario set, teaches you the real cost per simulated hour and the real integration effort in a few months. Siemens’ customer list in its product material, including SiliconAuto for microcontroller development, Wipro and Cognizant as service integrators, Sensory for pre-silicon voice technology and Qt for IVI graphics, points to this kind of narrow-to-broad adoption, though the public material does not disclose programme results, so ask vendors for referenceable numbers.

Treat fidelity as a per-block decision. Keep most of the system at the fast functional rung and bring only the blocks under scrutiny up the ladder. Record the rung used in every test report.

Correlate early and often. As soon as the first silicon or an FPGA prototype exists, run a fixed correlation suite against the model and publish the deltas. That habit converts the twin from a promise into an instrument with a known error bar.

Plan the compliance argument before the tooling. Decide with your safety assessor which claims the simulation will support, at which safety level, and what tool qualification that requires. Align requirement identifiers in your PLM and ALM systems with scenario identifiers so the trace is automatic.

A short checklist to take into a vendor evaluation:

Which SoC and ECU reference designs ship today, and which are on the roadmap?
What is the measured simulated-time to wall-clock ratio for a full perception workload on those designs?
Which interfaces are open (FMI, SystemC TLM, network standards) and which are proprietary?
How is determinism guaranteed, and how are runs reproduced months later?
What tool-qualification support exists for ISO 26262 use?
What are the cloud tenancy, data residency and IP protection terms?
How do results flow into Teamcenter, Polarion or your existing ALM?
What is the pricing model: per seat, per simulated hour or per programme?

Finally, keep expectations calibrated. The published claim of months to days for setup and up to two years faster software development is an upper bound from the vendor. Your own baseline, the maturity of your software and your validation strategy will determine where in that range you land.

Frequently Asked Questions

What is the PAVE360 automotive digital twin?

PAVE360 is Siemens’ pre-silicon and system-level digital twin platform for vehicle electronics and software. It combines SoC and virtual ECU models, a simulated vehicle network, a synchronisation backplane and a scenario simulator so production software can be developed and validated before hardware exists. PAVE360 Automotive, announced in December 2025, packages this as a cloud-based, pre-integrated offering built on Siemens’ Innexis environment for ADAS, automated driving and infotainment.

How is a virtual ECU different from software-in-the-loop testing?

Software-in-the-loop usually recompiles algorithm code for a workstation and runs it against a plant model, so processor behaviour is abstracted away. A virtual ECU runs the production binary, including boot code, operating system and drivers, on a model of the processor and peripherals. That exposes integration, concurrency and driver bugs that recompiled code hides, at the cost of slower simulation and the need to build and maintain accurate hardware models.

Does PAVE360 replace hardware-in-the-loop and road testing?

No. It moves most integration and regression testing earlier and reduces demand on scarce benches, but timing sign-off, electrical behaviour, sensor physics and final vehicle validation still need real hardware. Siemens itself describes a virtual-to-vehicle backplane that connects digital prototypes with physical hardware, and its CES 2026 demonstration paired the cloud twin with a real production vehicle, which reflects a hybrid rather than replacement strategy.

Which chips and clouds does PAVE360 support?

Siemens has announced support for Arm’s Zena Compute Subsystem, cloud deployment on AWS with Arm-based technology, and AMD Radeon PRO V710 GPUs with EPYC CPUs on Microsoft Azure. The booth material for CES 2026 also referenced partner software such as Elektrobit’s EB corbos Linux, Qt, Sensory and Autoware. Support for other SoCs depends on model availability, so confirm your target processor with Siemens before planning around it.

How much time does a software-defined vehicle digital twin save?

Siemens claims setup time falls from months to days and that integrating Arm Zena CSS can shorten software development timelines by up to two years. Arm separately cites up to twelve months less silicon development time versus discrete IP designs. These are vendor upper bounds. Independent programme-level measurements were not found in public sources, so validate savings with a pilot on your own workload.

Is PAVE360 generally available?

Siemens announced in December 2025 that PAVE360 Automotive was available to selected customers, with general availability planned for February 2026. I did not find a later independent confirmation of the exact release status when writing this on 30 September 2026, so check with Siemens for current packaging, supported reference designs and pricing before committing.

Siemens PAVE360: Automotive Digital Twin and Virtual ECU Architecture