loading
loading
Building full virtual vehicles on Google Cloud: From AAOS to the smallest MCU Florian Haubner Industry Architect Lead Automotive Per Sigurdson CEO & co-founder, RemotiveLabs Imagining traditional gearheads getting their hands on software-defined vehicles is an amusing thought experiment. With their socket wrenches and air compressors at the ready, they might be confused to encounter core functions more likely to run on 1s and 0s than oil and belts. But across the auto industry these days, more and more vehicles feature prominent systems built using cloud-native development, continuous integration/continuous delivery, fast digital iteration, and plenty of AI. But there’s still a big gap to be found in many automakers’ and Tier 1 suppliers’ cloud-based development processes. On the one hand, these companies are commonly using software to develop vehicles’ digital entertainment and information screens, or other onboard high-performance computers. On the other, the dozens of microchips and control modules that make a car a car these days — such as gateways, body controllers, zone control units, sensor and actuator nodes — are still frequently hardwired to physical chips when they’re constructed, making them very difficult to update, reprogram, or expand after the vehicle drives off the factory floor. Teams have to wait for benches, samples, and rigs, and integration can easily slip to the end of the development process, where defects are most expensive to fix. This inherent inefficiency has become a leading bottleneck. After all, manufacturers can’t really claim vehicles are software-defined if most of their electronics only function when connected to physical hardware and if developers are leaning heavily on actual hardware. With Horizon, our agentic innovation platform for developing software-defined vehicles, our vision is to help manufacturers avoid these inefficiencies by working with partners like RemotiveLabs. The cockpit already runs in the cloud The Android team has invested a significant amount of time and effort over the last few years on enabling seamless development of the many digital systems in vehicles’ cockpits. Android Automotive OS (AAOS) runs inside Google’s official virtual testing environment for Android, Cuttlefish, which itself runs comfortably on Arm-based Google Cloud instances. With this approach, developers can build, boot, and test virtual versions of their infotainment stacks on the same Arm architecture that ships in vehicles. And with the recent launch of Android 17 and AAOS SDV, this capability is also extended to further domains, whenever AAOS SDV is used. Deploying it with Cuttlefish, for example, proves the model: representative software, on representative architecture, in the cloud, on demand. The question that still needs to be answered is how to extend that model to the rest of the vehicle, especially when other operating systems are involved. The harness around the virtual vehicle That’s where RemotiveTopology comes into play. As the harness around the virtual vehicle, it’s the layer that connects AAOS in Cuttlefish to a full, simulated electrical and electronic (E/E) architecture: the rest of the vehicle’s onboard computers, its data networks, and the live signals that make the system function like a real vehicle rather than a collection of standalone apps. RemotiveTopology automatically utilizes manufacturers’ existing network design files to build a working, virtual version of their cars’ networks. This is vehicle-as-code: the E/E architecture expressed as an executable specification, versioned and provisioned like infrastructure-as-code. In this way, an entire vehicle can be spun up on demand. Cockpit software talks to the rest of the vehicle exactly as it would in a real vehicle. As a result, developers get full and continuous signal and cross-domain visibility, so they can see real-time system status. And because it is built on standard Linux tooling, the same topology runs on a laptop and in a contiguous integration pipeline on Google Cloud. Integrate across domains early, not late The payoff for using this approach is that all onboard systems can be developed and integrated with software before any of them are connected to a vehicle’s hardware. That’s beneficial because the most difficult (and latest) integration in a vehicle’s development is bringing all its systems together. For example, advanced driver assistance systems (ADAS) produce object lists, trajectories, and mode requests that the cockpit has to render and react to, while the infotainment system and information cluster have to reflect driving state while body and chassis nodes sit in the loop. With the full topology live on Google Cloud, the infotainment system and ADAS can operate simultaneously within a virtual vehicle, exchanging real signals over the simulated network. This means it’s possible to exercise handoffs like an ADAS event surfacing in the cluster or a driver-mode change rippling across domains from day one in continuous integration long before the benches and samples line up. In this way, developers can be confident they’ll discover multi-domain integration long before the end of the process so that they can test continuously from the start. The full vehicle frontier At the heart of this work is a shared desire to bring scalable software development to even the smallest and most common nodes in a vehicle, its microchips and control modules. That’s because these are the parts that have traditionally been wired to hardware, and as a result are the biggest blocker to fully software-defined vehicles. The ultimate goal is that the same software that runs in the cloud can run on vehicles’ actual control modules with no re-tooling or re-validation needed to move between them. That parity is natural with Arm-based Google Cloud infrastructure because the cloud and the car share an instruction set. Google's Axion makes it straightforward: C4A metal, a bare-metal Arm instance, is provided explicitly for automotive systems development and Android software development, giving direct hardware access without unnecessary software layers and delivering the consistent performance that vehicle systems require. Taken together, this holistic system allows teams, for the first time, to develop and integration-test an entire vehicle’s systems in the cloud and then apply it to the actual vehicle without having to rewrite it. Why now, and where to start The payoff is not abstract. Treating the vehicle as code and moving integration into the cloud compresses the slowest, most expensive phase of a program. Early customer engagements with RemotiveLabs have measured more than 10x faster integration cycles. And the development loop is now changing faster than the hardware loop: AI-assisted and agentic workflows can rapidly generate, test, and refine vehicle software, but only virtual systems provide the required scale. Every element that can’t be virtualized can slow the entire development process down. RemotiveTopology provides this architecture as vehicle-as-code and makes it accessible for developers, testers, and autonomous AI agents alike. Best of all, there is no new third-party tooling to adopt just to get started. Instead, RemotiveLabs publishes an open-source simplified vehicle on GitHub that anyone can run in minutes on standard Linux tooling and platform definitions already in place. Full existing toolchains plug in as a manufacturer or Tier1 supplier scales, and RemotiveTopology can be easily dropped into an Arm-based Google Cloud environment. For those building software-defined vehicles whose virtual development stops at the cockpit, it’s time to start with an open-source example, bring unique platform definitions, and run an entire vehicle in the cloud. RemotiveTopology is available in Horizon for easy usage in combination with other Horizon modules.
document fetched 2026-10-24 11:20 · canonical https://cloud.google.com/blog/topics/manufacturing/building-full-virtual-vehicles-on-google-cloud-from-aaos-to-the-smallest-mcu