The article, posted by Google Cloud, argues that while automakers and Tier 1 suppliers have moved cockpit and high-performance computer development to cloud-native processes, most vehicle microcontrollers—gateways, body controllers, zone control units, sensor and actuator nodes—are still built against physical chips. That makes post-production updates, reprogramming, or expansion difficult, and forces teams to wait for benches, samples, and rigs. Integration tends to slip to the end of development, where defects are most expensive to fix.

Google Cloud’s response is Horizon, its agentic innovation platform for software-defined vehicles, used in combination with RemotiveLabs. The starting point is the cockpit: Android Automotive OS (AAOS) runs inside Cuttlefish, Android’s official virtual testing environment, on Arm-based Google Cloud instances. Developers can build, boot, and test virtual infotainment stacks on the same Arm architecture used in vehicles. Recent Android 17 and AAOS SDV releases extend this capability, but the open question is applying the model to the rest of the vehicle, especially when other operating systems are involved.

RemotiveTopology fills that gap. It acts as the harness around the virtual vehicle, connecting AAOS in Cuttlefish to a full simulated electrical/electronic architecture—other onboard computers, data networks, and the live signals that make the system behave like a real vehicle. It automatically consumes manufacturers’ existing network design files to build a working virtual version of the car’s networks. This is described as ‘vehicle-as-code’: the E/E architecture becomes an executable specification, versioned and provisioned like infrastructure-as-code. The entire vehicle can be spun up on demand, and cockpit software talks to the rest of the vehicle exactly as it would in hardware. Because RemotiveTopology is built on standard Linux tooling, the same topology runs on a laptop and in a CI pipeline on Google Cloud.

The main benefit is that onboard systems can be developed and integrated with software before any hardware connection. The article uses ADAS as an example: ADAS produces object lists, trajectories, and mode requests that the cockpit must render and react to, while the infotainment system and cluster reflect driving state, and body and chassis nodes stay in the loop. With the full topology live, infotainment and ADAS run simultaneously inside a virtual vehicle, exchanging real signals over the simulated network. This enables exercising handoffs such as an ADAS event surfacing in the cluster or a driver-mode change rippling across domains from day one in CI, long before benches and samples are available. Teams can therefore discover multi-domain integration problems early and test continuously.

The longer-term goal is to bring scalable software development to the smallest and most common vehicle nodes—the microchips and control modules that have traditionally been wired to hardware and are the biggest blocker to fully software-defined vehicles. The article says the final target is that the same software running in the cloud can run on actual control modules without re-tooling or re-validation, and that parity is natural on Arm-based Google Cloud infrastructure because cloud and car share an instruction set. It points to Google’s Axion, specifically C4A metal, a bare-metal Arm instance provided for automotive systems and Android software development, which gives direct hardware access without extra software layers and delivers consistent performance.

The business rationale is that 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 measured more than 10x faster integration cycles. The article also notes the development loop now changes 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, and anything that cannot be virtualized slows the whole process.

Adoption is intended to be low-friction: RemotiveLabs publishes an open-source simplified vehicle on GitHub that runs in minutes on standard Linux tooling and existing platform definitions. No new third-party tooling is needed to get started; full existing toolchains plug in as a manufacturer or Tier 1 supplier scales, and RemotiveTopology can be dropped into an Arm-based Google Cloud environment. The post closes by urging teams building software-defined vehicles whose virtual development stops at the cockpit to start with the open-source example, add their own platform definitions, and run the entire vehicle in the cloud. RemotiveTopology is available in Horizon.