What changed is that the complete software‑defined vehicle stack can be instantiated on Google Cloud without any physical hardware. By running Android Automotive OS (AAOS) in the Cuttlefish emulator on Arm‑based Compute Engine instances and wiring it to a virtual electrical‑electronic (E/E) topology generated from manufacturers’ network design files, developers can test cockpit software together with the rest of the vehicle’s control modules in a single, on‑demand environment. Practitioners care because the approach eliminates the traditional bench‑time bottleneck, enables true end‑to‑end CI/CD, and brings cloud‑native observability to vehicle‑level signals.
Virtual Vehicle Stack on Google Cloud
The stack consists of three tightly coupled pieces:
- Android Automotive OS (AAOS) – executed inside the Cuttlefish virtual device, which runs on Arm‑based Google Cloud instances that match the hardware shipped in production vehicles.
- RemotiveTopology – a Linux‑based harness that consumes existing network design artifacts, materializes a virtual E/E bus, and connects the AAOS instance to simulated gateways, body controllers, and sensor nodes.
- Vehicle‑as‑code – the network description is treated as an executable specification, versioned and provisioned like infrastructure‑as‑code, allowing the whole vehicle to be spun up repeatedly in CI pipelines or on a developer laptop.
Because both Cuttlefish and RemotiveTopology rely on standard Linux tooling, the same configuration can be used locally and in a cloud‑hosted continuous integration environment.
Implications for Architecture and Implementation
From an architectural perspective, the virtual vehicle replaces a physical test bench with a cloud‑native service model. Engineers must provision Arm‑based Compute Engine VMs (e.g., e2-standard-arm) to match the target silicon. The network topology is expressed in a declarative format that can be stored in source control, enabling reproducible builds and roll‑backs.
Implementation steps typically include:
- Importing the manufacturer’s network design file into RemotiveTopology.
- Launching a Cuttlefish instance with the desired AAOS image (Android 17 and AAOS SDV are now supported).
- Binding the two via the RemotiveTopology bridge, which creates virtual CAN/LIN buses and exposes sensor streams as Linux devices.
Because the environment is fully software‑defined, scaling to multiple concurrent vehicle instances is a matter of allocating additional VM capacity, and the same IaC scripts can be reused across projects.
Operational and Security Considerations
Operationally, the ability to run the full stack in CI means test cycles can be automated, and signal‑level visibility is available throughout the pipeline. Engineers should instrument the virtual buses with standard logging or metrics collectors to capture cross‑domain interactions.
Security practitioners must treat the virtual vehicle as a potentially sensitive workload. The cloud instance hosts vehicle‑level data streams, so isolation mechanisms (e.g., project‑level IAM, VPC segmentation) should be applied. Since the topology runs on standard Linux, existing hardening practices—such as minimal base images, regular patching, and runtime monitoring—remain applicable. Additionally, any ingress of proprietary network design files should be protected in transit and at rest.
Related CloudNinjas coverage: Google Cloud.
What This Means For Practitioners
- Adopt the Cuttlefish + RemotiveTopology workflow to replace late‑stage hardware benches with early‑stage cloud simulations.
- Version vehicle network definitions alongside application code to enable repeatable builds and roll‑backs.
- Integrate virtual‑vehicle tests into existing CI/CD pipelines to catch cross‑domain defects before hardware integration.
- Apply standard cloud security controls to the virtual environment and treat imported network files as confidential assets.
- Monitor emerging support for additional operating systems beyond AAOS to broaden the applicability of the approach.