AMD’s move to bring a Virtualized Automotive Stack (VAS) to Microsoft Azure — pairing Radeon PRO V710 GPUs and EPYC CPUs with Xen-based nested virtualization and Siemens’ PAVE360 digital‑twin environment — promises to accelerate “shift‑left” development for software‑defined vehicles, but it raises important technical questions about VM feature support, performance trade‑offs, and safety/security posture that OEMs and Tier‑1s must verify before committing to cloud‑first validation pipelines.
The automotive industry is accelerating toward software‑defined vehicles (SDVs), where a growing proportion of vehicle functionality is implemented in software and validated across integrated systems rather than siloed ECUs. Cloud compute, simulation, and digital twins are now central to the “shift‑left” movement: moving integration, validation, and safety analysis earlier into the development lifecycle to find system‑level defects before hardware prototypes exist. AMD’s announcement of a Virtualized Automotive Stack (VAS) on Azure, together with Siemens’ PAVE360 and Microsoft’s NVads V710 v5 virtual machines, is framed as a way to scale that approach using GPU‑accelerated simulation and nested virtualization. This article unpacks the technical claims, verifies key specifications, highlights the practical benefits for vehicle development teams, and flags potential risks and unknowns. The goal is to give engineering leaders and program managers a clear, evidence‑based view of what’s new, what’s already proven, and what requires rigorous validation before adoption.
Source: Technology Record AMD collaborates with Microsoft and Siemens to improve development of software-defined vehicles
Background
The automotive industry is accelerating toward software‑defined vehicles (SDVs), where a growing proportion of vehicle functionality is implemented in software and validated across integrated systems rather than siloed ECUs. Cloud compute, simulation, and digital twins are now central to the “shift‑left” movement: moving integration, validation, and safety analysis earlier into the development lifecycle to find system‑level defects before hardware prototypes exist. AMD’s announcement of a Virtualized Automotive Stack (VAS) on Azure, together with Siemens’ PAVE360 and Microsoft’s NVads V710 v5 virtual machines, is framed as a way to scale that approach using GPU‑accelerated simulation and nested virtualization. This article unpacks the technical claims, verifies key specifications, highlights the practical benefits for vehicle development teams, and flags potential risks and unknowns. The goal is to give engineering leaders and program managers a clear, evidence‑based view of what’s new, what’s already proven, and what requires rigorous validation before adoption.What AMD, Microsoft and Siemens announced
- AMD introduced the Virtualized Automotive Stack (VAS), delivered on Azure NVads V710 v5‑series VMs that use AMD Radeon PRO V710 GPUs and AMD EPYC CPUs. The VAS package incorporates VirtIO device support and a Xen hypervisor running on top of Microsoft Hyper‑V, which AMD says enables nested virtualization for mixed‑criticality automotive workloads.
- Microsoft published details of the NVads V710 v5‑series (Azure documentation and Azure HPC blog), describing VM SKUs sized to deliver GPU‑accelerated graphics, visualization, and small‑to‑medium AI inference workloads on Radeon PRO V710 accelerators and EPYC hosts. The Microsoft material provides the VM dimensions, regions, and workload guidance.
- Siemens extended its PAVE360 digital‑twin environment to run on AMD GPUs and EPYC CPUs on Azure, enabling system‑of‑systems validation and large‑scale scenario simulation for SDV development. Siemens positions PAVE360 as a vehicle‑level simulation and validation platform that benefits from the added graphics and compute available in Azure NVads V710 instances.
Technical anatomy: VAS, NVads V710 v5, Xen, VirtIO, and PAVE360
AMD Virtualized Automotive Stack (VAS)
The VAS is described as a middleware layer that combines device virtualization (VirtIO), a guest‑level Xen hypervisor, and integration with Hyper‑V host services to support nested virtualization scenarios in the cloud. The aim is to let engineers run mixed‑criticality workloads (safety‑relevant code next to rich‑media or infotainment code) within the same top‑level VM, but logically isolated into nested guest partitions that emulate zonal or SoC consolidation. AMD frames VAS as an enabler for earlier system‑level validation in centralized cloud environments. Key technical components called out by AMD:- VirtIO drivers and virtual device model for efficient I/O in nested guests.
- Xen as the nested guest hypervisor to host mixed‑criticality functions in isolated domains.
- Hyper‑V as the top‑level host hypervisor provided by Azure.
- Use of Radeon PRO V710 for GPU‑accelerated visualization and acceleration of perception/inference tasks.
Azure NVads V710 v5‑series
Microsoft’s NVads V710 v5 documentation spells out the VM host spec and the exposed VM sizes. Highlights include:- Host CPUs: AMD EPYC 9V64 F (Genoa family) on the documented host configuration, with multiple VM size options (4–28 vCPU ranges and 16–160 GiB memory depending on size).
- Accelerator: AMD Radeon PRO V710 (hardware product line); Azure offers partitioned GPU options from 1/6th GPU up to full GPU allocations per VM SKU. Microsoft’s blog and SKU docs describe target workloads such as visualization, VDI, small LLM inference, and cloud gaming.
Siemens PAVE360
PAVE360 is Siemens’ systems‑of‑systems digital twin environment for SDV development. Siemens’ notice confirms PAVE360 runs on Azure instances that include Radeon PRO V710 and EPYC compute, enabling large scenario libraries and system‑level validation for ADAS, perception stacks, and infotainment visualizations. Siemens emphasizes the ability to scale many virtual scenarios to uncover corner cases earlier in development.Verifying the key technical claims (what the public record supports)
- AMD’s announcement of VAS on Azure is confirmed by AMD’s corporate blog and aligns with Siemens’ public statement about supporting PAVE360 on AMD GPUs in Azure. Both vendors explicitly reference Radeon PRO V710 and EPYC CPUs on Azure.
- The NVads V710 v5‑series exists in Microsoft’s product documentation and Azure blog posts, with VM sizing, memory, and region availability spelled out. Microsoft positions these VMs for graphics, visualization, and modest AI inference workloads.
- Radeon PRO V710 physical hardware specifications (GPU architecture, memory size, and performance claims) are listed on AMD’s product pages and corroborated by independent hardware databases and press coverage: the V710 is a RDNA‑3‑based professional accelerator with a high‑capacity GDDR6 frame buffer intended for data center/visualization use. AMD’s own materials and hardware databases indicate a 28‑GB physical memory class for the V710.
- Siemens PAVE360 support for AMD GPUs on Azure is described in Siemens’ official release; Siemens frames the integration as expanding cloud platform options for large‑scale SDV validation.
Critical contradictions and red flags to verify before program adoption
Two technical areas deserve immediate scrutiny because public documentation contains conflicting or cautionary information.Nested virtualization support: vendor claim vs. Azure docs
- AMD’s VAS announcement claims the stack enables nested virtualization on Azure GPU instances via Xen running on top of Hyper‑V. That is a central part of the VAS pitch because nested guests are the mechanism used to separate mixed‑criticality domains in a consolidated SoC emulation.
- However, Microsoft’s own NVads V710 v5‑series documentation historically lists “Nested Virtualization: Not Supported” for GPU instance families, and Azure documentation and forums have repeatedly noted that GPU VMs generally do not support nested virtualization as a supported scenario. Public Microsoft guidance (and long‑standing Azure constraints) indicate the GPU virtualization stack and vendor vGPU technologies typically preclude supported nested hypervisor scenarios.
GPU frame buffer and memory exposure: 28 GB vs. 24 GiB
- AMD’s product pages and third‑party hardware listings indicate the Radeon PRO V710 has 28 GB of GDDR6 memory on the physical card.
- Microsoft’s NVads V710 VM documentation lists exposed GPU frame buffer sizes in the VM sizes that top out at 24 GiB for a full GPU allocation in that VM family. That suggests Azure’s VM partitioning or driver mappings present a slightly smaller usable frame buffer to guest VMs or that certain VM SKUs map to device partitions with 24 GiB.
Practical benefits for vehicle software development teams
When the technical details are validated, the combined offering yields several important practical benefits to SDV programs:- Shift‑left validation at scale: Engineers can run thousands of scenario permutations and software stack configurations in parallel, uncovering integration and safety corner cases earlier than is practical with physical prototypes. PAVE360 plus high‑memory GPU instances accelerates system‑level simulation runs.
- Mixed‑criticality emulation: Nested Xen guests (if supported) provide a way to partition safety‑critical and non‑safety workloads within a single simulated SoC, letting teams validate resource arbitration, timing, and isolation behavior under load. This is particularly valuable for consolidated zonal or central compute architectures.
- Faster integration cycles: Cloud‑based validation reduces the need for early silicon runs and allows software features — infotainment, instrument clusters, perception models — to be validated sooner and iterated faster, shortening delivery timelines.
- Scalable AI inference and visualization: Radeon PRO V710 hardware claims and NVads V710 VM guidance show suitable capability for AI inference (small to medium LLMs or perception models) and high‑fidelity visualization for cockpit and sensor simulation workloads.
- Vendor interoperability: A jointly engineered stack (AMD VAS + Azure + Siemens PAVE360) reduces integration friction compared to stitching together multiple unsupported software layers. Where vendor collaboration exists, enterprise support and roadmaps are easier to coordinate.
Risks, limitations, and security considerations
Moving system‑level, mixed‑criticality validation into the cloud introduces architectural and operational risks that are especially salient for automotive safety and security.Isolation and attack surface
Consolidating safety‑critical and non‑safety workloads—even when isolated by nested hypervisors—expands the attack surface if any hypervisor or driver stack is misconfigured or compromised. Nested virtualization adds complexity and additional hypervisor layers that must be audited and hardened to automotive functional safety (ISO 26262) and cybersecurity (ISO/SAE 21434) requirements. Vendor claims about “isolation” are a start, not a substitute for independent penetration testing and formal verification.Supportability and warranty
If nested virtualization or GPU partitioning is provided only in preview or partner SKUs, program teams may face limited Microsoft support and unclear SLAs. That can be a major risk for fleets that expect long‑term reproducibility and traceability of validation artifacts. Confirm whether the NVads V710 nested setup is GA, preview, or partner‑only and secure explicit support commitments before embedding it into certified validation processes.Determinism and timing
Cloud VMs run on shared hardware with host scheduler, noisy neighbor effects, and non‑deterministic interrupt latencies. For safety‑critical timing analysis, engineers must either push timing‑sensitive verification to hardware prototypes or build in conservative margins and repeated statistical testing in the cloud. Nested virtualization can complicate timing predictability and must be characterized for worst‑case execution times.Data governance and privacy
Cloud‑based digital twins and cockpit AI entail telemetry and training data flows that span geographies. Ensure clear data‑handling policies for telemetry, model training data, and personalization features to meet GDPR and regional privacy regimes. Cloud platforms provide tooling, but contractual clarity is essential for OEM‑level PII and telemetry ownership.Cost and operational overhead
Running large numbers of GPU‑accelerated simulations is compute‑intensive and costly. The cloud makes scale possible, but program managers must model ongoing costs (simulation runs, storage, model training, transfer), and choose a hybrid approach that bursts to cloud when it’s cost‑effective while keeping sensitive, low‑latency validation on local hardware.Recommendations for engineering teams and program managers
- Validate the nested virtualization claim empirically and contractually.
- Request an Azure‑supported, documented configuration that explicitly enables Xen nested guests on NVads V710 v5 instances, or secure a partner preview environment with written support terms. Do not assume nested virtualization is supported simply because a vendor blog says it is.
- Benchmark representative workloads.
- Run the exact perception, inference, and cockpit rendering workloads you plan to use. Measure memory usage (watch for the 24 GiB vs 28 GB frame buffer question), latency, worst‑case execution, and any GPU driver or device errors. Use the same VM SKUs you plan to deploy in CI/CD pipelines.
- Test isolation and security.
- Commission independent penetration testing and hypervisor fuzzing against the full stack (Hyper‑V + Xen + VirtIO + AMD drivers). Validate isolation between nested guests and confirm there are no covert channels or resource‑based side‑effects that could violate safety isolation assumptions.
- Clarify support scope with vendors.
- Negotiate explicit SLAs and long‑term support commitments for the specific VM SKUs and stack configuration you’ll rely on for validated artifacts that enter your safety case or certification evidence.
- Adopt a hybrid validation strategy.
- Use cloud scale for scenario mass testing, regression, and model training, but maintain hardware‑based validation for final certification runs and microsecond‑level timing checks. Treat cloud validation as complementary, not a one‑for‑one replacement for edge hardware testing.
What OEMs and Tier‑1s should ask vendors today
- Is nested virtualization for NVads V710 v5 a generally available, supported capability? If not GA, what is the roadmap and what support terms are available for previews?
- How does Azure partition or expose Radeon PRO V710 memory to guests, and what explains the 24 GiB vs 28 GB discrepancy between Azure docs and AMD hardware specs?
- What formal safety and security engineering work (MISRA, ISO 26262, ISO/SAE 21434) have you completed for the VAS stack and the Xen/Hyper‑V integration? Can you provide test artifacts and third‑party attestations?
- What is the expected cost profile for large‑scale PAVE360 scenario runs, and are there cost‑optimization patterns you recommend (spot/low‑priority preemptible pools, hybrid caches, incremental snapshots)?
Final assessment
The AMD + Microsoft + Siemens collaboration is a credible, pragmatic attempt to operationalize cloud‑scale digital twin and mixed‑criticality validation for software‑defined vehicles. The architecture is promising: high‑memory Radeon PRO V710 hardware, EPYC compute hosts, a virtualization stack tuned for device passthrough and nested Xen guests, and a system‑level simulation engine from Siemens together address a real pain point in modern automotive software development. However, two non‑trivial caveats make this an engineering project rather than a drop‑in migration: the current public documentation indicates that GPU VM families generally do not support nested virtualization, and cloud‑exposed GPU frame buffer sizes differ from physical card specs — both matters that materially affect workload behaviour, isolation, and lifecycle support. Engineering teams should treat the vendor announcements as a roadmap and a capability demonstration, not as an unconditional, production‑grade guarantee. Rigorous validation, contractual clarity, and hybrid execution strategies are essential to realize the claimed benefits while containing safety, security, and cost risks. The industry clearly needs these capabilities: consolidated SoCs, zonal architectures, AI‑infused cockpits, and continuous integration demand cloud‑scale simulation and earlier system validation. The AMD/Microsoft/Siemens collaboration is a significant step toward making that practical. But the path from vendor announcement to certified, fleet‑ready validation remains a careful engineering climb — one that requires empirical verification at each rung.Source: Technology Record AMD collaborates with Microsoft and Siemens to improve development of software-defined vehicles
