Google Cloud and RemotiveLabs bring full virtual vehicles to the cloud

The gap in software-defined vehicles

According to Google Cloud, many automakers and Tier 1 suppliers already use cloud-native development, continuous integration and delivery, and AI for infotainment screens and other high-performance onboard computers. The many microchips and control modules that make up a modern car are a different story. Gateways, body controllers, zone control units, and sensor and actuator nodes are still frequently hardwired to physical chips, which makes them hard to update, reprogram or expand after a vehicle leaves the factory.

The result, the company says, is that teams wait for benches, samples and rigs, and integration slips to the end of development, where defects are most expensive to fix. Google Cloud calls this a leading bottleneck and argues that vehicles cannot be called software-defined if most of their electronics only work when connected to physical hardware.

From the cockpit to the whole vehicle

The cockpit side is already in the cloud, according to the post. Android Automotive OS (AAOS) runs inside Cuttlefish, Google's official virtual testing environment for Android, which in turn runs on Arm-based Google Cloud instances. Developers can build, boot and test virtual infotainment stacks on the same Arm architecture used in vehicles. Google says the recent launch of Android 17 and AAOS SDV extends this capability to further domains.

RemotiveTopology is meant to cover the rest. It acts as the harness around the virtual vehicle, connecting AAOS in Cuttlefish to a simulated E/E architecture that includes other onboard computers, data networks and live signals. It uses manufacturers' existing network design files to build a working virtual version of a car's networks. Google Cloud describes this as vehicle-as-code: the architecture expressed as an executable specification, versioned and provisioned like infrastructure-as-code. Because it is built on standard Linux tooling, the same topology runs on a laptop and in a continuous integration pipeline on Google Cloud.

Earlier integration across domains

The authors, Florian Haubner of Google Cloud and Per Sigurdson, CEO and co-founder of RemotiveLabs, point to cross-domain integration as the hardest and latest step in vehicle development. ADAS produces object lists, trajectories and mode requests that the cockpit has to render and react to, while the infotainment system and information cluster must reflect driving state.

With the full topology running on Google Cloud, infotainment and ADAS can operate together in one virtual vehicle and exchange real signals over the simulated network. Teams can test handoffs such as an ADAS event appearing in the cluster, or a driver-mode change spreading across domains, in continuous integration from the start.

The stated goal is that the same software running in the cloud can run on actual control modules without re-tooling or re-validation. Google ties that parity to the fact that cloud and car share an instruction set. It also points to Axion C4A metal, a bare-metal Arm instance provided explicitly for automotive systems development and Android software development.

What it means for development teams

Google Cloud says early customer engagements with RemotiveLabs have measured more than 10x faster integration cycles. It also argues that AI-assisted and agentic workflows can quickly generate, test and refine vehicle software, but that only virtual systems offer the needed scale, since any element that cannot be virtualized slows the whole process.

The company says no new third-party tooling is required to get started. RemotiveLabs publishes an open-source simplified vehicle on GitHub that can be run in minutes on standard Linux tooling. Existing toolchains can be added as a manufacturer or Tier 1 supplier scales, and RemotiveTopology can be dropped into an Arm-based Google Cloud environment. It is available in Horizon, Google's agentic platform for developing software-defined vehicles, alongside other Horizon modules.