Digital twins for Automotive development: Moving upstream with Arm, Google Cloud and ecosystem partners

This blog was co-authored by Shankara Nagarajan and Peterson Quadros from Arm, and Florian Haubner and Mike Annau from Google.

---

For decades, hardware dictated the software schedule for vehicles. Teams could develop applications early, however, meaningful integration had to wait for prototype boards and early vehicles. Hardware became a shared bottleneck and many integration issues only emerged when the entire system came together.

The Arm and Google Cloud partnership establishes the foundation for cloud-native software development. Google Cloud enables developers to build and validate software at cloud scale on Arm. Arm provides architectural continuity through ISA Parity and Binary Parity, which keeps software aligned with production. The collaboration enables a continuous shift-left workflow long before production hardware is available.

A digital twin transforms this workflow. Instead of waiting for hardware, developers use a virtual representation of the vehicle as the primary software development platform. It combines the Arm-based virtual platform, the vehicle’s electrical and electronic architecture, environmental simulation, and cloud-native validation. Together, these create a single software factory where applications are developed, integrated, tested, and prepared for production.

The result is a fundamental shift in the development process. Software teams begin integration on the first day of the program instead of waiting until the end. Features mature earlier, validation becomes continuous, and software reaches production hardware with much of the integration already complete. The result is faster development and a more predictable path to production.

One platform for every team 

The digital twin becomes the place where vehicle software comes together. Android applications, Software-defined vehicles (SDV) services, middleware, and operating systems all develop against the same vehicle model instead of separate environments. Every developer, partner, and CI pipeline works from the same platform, making software development consistent from the first commit through to production. Integration is no longer a milestone at the end of the program. It becomes part of daily software development.

Google Cloud helps accelerate software development 

Development starts with Horizon on Google Cloud, using Google Compute Engine instances powered by Google Axion processors to run Android Virtual Devices (Cuttlefish) and execute virtual test suites at scale. Horizon provides a cloud-native development platform that makes Android Automotive software and beyond fast to build, easy to share, and simple to scale. Development environments can be created in minutes and reproduced consistently across global engineering teams, ensuring every developer works from the same environment whether there are 10 engineers or 1,000. As software engineering evolves, the platform also provides an agentic framework and integration points that enable AI agents to participate alongside developers, allowing development and validation workflows to scale in the agentic era. 

​​​Running on Google Axion,​ a ​family of custom Arm-based processors, provides ISA Parity, allowing software to be developed on the same Arm instruction set architecture used in production. Developers target Arm from the first commit, establishing an Arm-native workflow from cloud to vehicle. This accelerates in-vehicle software development, shortens feature cycles, and establishes the Arm-native foundation for scalable virtual platforms and digital twins. 

Arm brings the production platform into development 

Fast software development only creates value when the software behaves the same way on the production platform. Google Axion establishes an Arm-native cloud foundation that creates new opportunities for the modelling ecosystem to deliver Arm-based virtual platforms built around Arm Compute Subsystems (CSS), including Arm Zena CSS​,​ bringing the production compute platform into the development process. Android Automotive, Linux, middleware, and platform software run on a virtual representation of the future hardware months before silicon is available. Because the software was built with ISA Parity, the same binaries execute on these virtual platforms without recompilation. This provides Binary Parity, allowing software to be validated continuously against the production platform throughout development. 

Instead of discovering platform issues during hardware bring-up, teams find them while software is still being developed on the digital twin. Google Cloud helps accelerate software development, ​while​ Arm keeps software aligned with the production platform. 

The virtual harness makes the vehicle real 

A processor, no matter how capable, is only one part of a vehicle. Vehicle software does not operate in isolation. Every feature depends on information flowing continuously between dozens of ECUs. Battery management systems report the state of charge, body controllers report door status, and advanced driver assistance systems (ADAS) publish object detection. Instrument clusters display warnings, while navigation, infotainment, and power management exchange information across Controller Area Network (CAN), Automotive Ethernet, Vehicle Hardware Abstraction Layer (VHAL), and other vehicle networks.

Figure 1: A layered simulation platform that virtualizes compute, electronics, connectivity, and the physical environment, enabling developers to build, integrate, test, and validate Physical AI software from silicon through complete system behavior.

The Virtual Harness, powered by RemotiveTopology from RemotiveLabs,

recreates that entire electrical architecture in software. Running on Google Cloud, it connects Arm-based virtual platforms, including those built around Arm Zena CSS, to a complete virtual vehicle. This gives software the same system context that it will have in production. Instead maintaining separate test environments, engineering teams develop against the same virtual vehicle. Android Automotive OS receives live vehicle signals through VHAL properties, middleware communicates with shared services, platform software exchanges messages across virtual networks, and test teams validate complete vehicle features rather than individual components.

Every team sees the vehicle behaving as one system and can continuously iterate over it, maturing over time while retaining a consistent picture across development teams. When a signal changes, every component responds. When a new service is introduced, every subsystem can interact with it. When a fault is injected, its impact can be traced across the entire software stack. The Virtual Harness becomes the program’s shared engineering model, giving developers, platform teams, partners, and continuous integration (CI) pipeline a common view of the vehicle. Everyone develops against the same electrical architecture, making integration and validation fast-paced, continuous, and iterative.

Simulation brings the world to the vehicle

Once the virtual vehicle exists, it needs somewhere to operate. Environmental simulation provides that world. Roads, traffic, weather, pedestrians, sensors, and driving scenarios expose software to realistic operating conditions. Recorded vehicle playback adds another dimension. It replays real journeys, vehicle signals, and system behavior for debugging and regression testing.

The Virtual Harness provides the vehicle while Playback and simulation provide the operating environment. The 'TopologyBroker’ acts as the central entry point between these tools and the vehicle topology. Together, they create a complete digital twin where developers can validate complete vehicle behavior long before physical hardware exists.
        

 

Figure 2: RemotiveTopology as the Virtual Harness          

Continuous validation at cloud scale

Running on Google Cloud, the infrastructure scales easily as development cycles increase. Hundreds of developers can work in identical environments without competing for prototype hardware. Every build uses the same Zena CSS virtual platform, Virtual Harness, and playback or simulation scenarios.

The workflow extends directly into CI/CD. Every software build can automatically deploy to Zena CSS virtual platforms, connect to the Virtual Harness, replay repeatable scenarios, and validate the complete vehicle. Applications, middleware, operating systems, communication buses, and vehicle services are observed together. This makes regressions visible long before software reaches hardware. CI/CD becomes much more than an automated build process. It becomes continuous integration, observation, and validation of the complete software-defined vehicle.

Ready for Agentic AI    

The same platform also supports agentic workflows acting within the continuous delivery pipeline and digital twin environment, operated on Google Axion instances. Leveraging Gemini Enterprise Agent Platform, Horizon SDV ultimately graduates from a software factory to an agentic innovation platform ready for AI scale. Agents then not only write code but spin up virtual devices with Cuttlefish and test whole topologies with Virtual Harness.

As the software matures, the same code moves to Zena CSS virtual platforms, where it is then validated against the production compute platform. The Virtual Harness provides the complete vehicle context. Developers can observe signal flows, service interactions, and system behavior across Android applications, middleware, operating systems, and vehicle services. The result is a continuous development workflow. Developers move quickly through virtual development cycles in Horizon. They then validate against the production architecture by using Zena CSS virtual platforms, the Virtual Harness, and the repeatable scenarios used throughout CI/CD.

Building software before hardware

This is where the Google Cloud and Arm collaboration comes together. Google Cloud provides a cloud-native development platform for building, testing, and scaling Android Automotive software across global engineering teams. Arm extends that workflow with ISA Parity, Zena CSS virtual platforms, and Binary Parity, helping to ensure software remains aligned with the production platform throughout development. RemotiveLabs completes the environment with the Virtual Harness. Playback and environmental simulation provide the context needed to validate complete software-defined vehicle features.

This combination enables a continuous software development workflow. Every developer, engineering team, and CI pipeline works against the same virtual vehicle. They use the same Arm-native production architecture with ISA Parity and the same repeatable validation scenarios.

The digital twin shifts software development upstream. Software is developed, integrated, and validated in the cloud against production-representative platforms and realistic vehicle scenarios long before hardware is available. Hardware no longer marks the beginning of software integration. It confirms software readiness for production.

Learn more about Arm Zena CSS