{"slug": "building-full-virtual-vehicles-on-google-cloud-from-aaos-to-the-smallest-mcu", "title": "Building full virtual vehicles on Google Cloud: From AAOS to the smallest MCU", "summary": "Google Cloud and RemotiveLabs are pitching a virtual-vehicle development model that runs Android Automotive OS (AAOS) inside Google's Cuttlefish virtual testing environment on Arm-based Google Cloud instances, then connects it to a simulated electrical/electronic architecture via RemotiveLabs' RemotiveTopology. The approach, tied to the launch of Android 17 and AAOS SDV, uses manufacturers' existing network design files to spin up an entire vehicle on demand so cockpit software talks to the rest of the car as it would in a real vehicle, addressing a bottleneck where microcontrollers and control modules remain hardwired to physical chips during development.", "body_md": "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.\n\nBut 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.\n\nOn 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.\n\nThis 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.\n\nWith 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](https://www.remotivelabs.com/).\n\nThe 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](https://source.android.com/docs/automotive) (AAOS) runs inside Google’s official virtual testing environment for Android, [Cuttlefish](https://source.android.com/docs/devices/cuttlefish), which itself runs comfortably on [Arm-based Google Cloud instances](https://cloud.google.com/compute/docs/instances/arm-on-compute). With this approach, developers can build, boot, and test virtual versions of their infotainment stacks on the same Arm architecture that ships in vehicles.\n\nAnd with the recent launch of [Android 17 and AAOS SDV](https://source.android.com/docs/whatsnew/android-17-release#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.\n\nThat’s where [RemotiveTopology](https://www.remotivelabs.com/products/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.\n\nRemotiveTopology 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.\n\nThe 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.\n\nWith 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.\n\nAt 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.\n\nThe 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](https://cloud.google.com/products/axion) makes it straightforward: [C4A metal, a bare-metal Arm instance](https://cloud.google.com/blog/products/compute/axion-based-n4a-vms-now-in-preview), 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.\n\nTaken 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.\n\nThe 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.\n\nRemotiveTopology 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](https://github.com/remotivelabs/remotivelabs-topology-examples) 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.\n\nFor 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](https://github.com/GoogleCloudPlatform/horizon-sdv/tree/main/gitops/modules/remotive-topology) for easy usage in combination with other Horizon modules.", "url": "https://wpnews.pro/news/building-full-virtual-vehicles-on-google-cloud-from-aaos-to-the-smallest-mcu", "canonical_source": "https://cloud.google.com/blog/topics/manufacturing/building-full-virtual-vehicles-on-google-cloud-from-aaos-to-the-smallest-mcu/", "published_at": "2026-10-19 14:17:48.313813+00:00", "updated_at": "2026-10-19 14:17:50.660483+00:00", "lang": "en", "topics": ["autonomous-vehicles", "ai-agents", "ai-infrastructure"], "entities": ["Google Cloud", "RemotiveLabs", "Android Automotive OS", "Cuttlefish", "RemotiveTopology", "Android 17", "AAOS SDV", "Google"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/building-full-virtual-vehicles-on-google-cloud-from-aaos-to-the-smallest-mcu", "markdown": "https://wpnews.pro/news/building-full-virtual-vehicles-on-google-cloud-from-aaos-to-the-smallest-mcu.md", "text": "https://wpnews.pro/news/building-full-virtual-vehicles-on-google-cloud-from-aaos-to-the-smallest-mcu.txt", "jsonld": "https://wpnews.pro/news/building-full-virtual-vehicles-on-google-cloud-from-aaos-to-the-smallest-mcu.jsonld"}}