传统汽车开发者面对软件定义汽车时，常会陷入一种错位：车里最重要的功能越来越多跑在代码上，但开发流程却仍被物理硬件绑住。许多车企和 Tier 1 供应商已经把座舱的高性能计算机放到了云端做虚拟开发，可其余的电子控制单元——网关、车身控制器、区域控制器、传感器执行器节点——仍然要等到实物芯片和样件到位才能联调。结果集成被拖到开发流程末尾，缺陷修复成本最高的时候才暴露。

Google Cloud 在官方博客中给出的答案是：把整辆车都变成可运行在云端的虚拟实体。核心组件是 RemotiveTopology，由合作方 RemotiveLabs 提供，定位为虚拟车辆的“线束层”。它连接 Android Automotive OS（AAOS）与完整的模拟电子电气架构（E/E），把车辆的网络、信号、域控制器都虚拟化。RemotiveTopology 能自动利用制造商现有的网络设计文件，生成可执行的车辆网络规格，实现“车辆即代码”（vehicle-as-code）——像基础设施即代码那样进行版本化、部署和扩展。开发者在云端就能让座舱软件与车辆其他部分交换实时信号，行为与真实车辆一致。

这套方案的关键在于让多域集成提前发生。借助 Arm 架构的 Google Cloud 实例和 Cuttlefish 虚拟测试环境，AAOS 跑在云端的 Arm 架构上，与车规芯片同构。RemotiveTopology 再把 ADAS、信息娱乐、仪表、车身、底盘等域全部拉进一个虚拟网络中。ADAS 产生的目标列表、轨迹、模式请求，可以实时传给座舱渲染；驾驶模式切换引发的跨域变化，从第一天起就能在持续集成中验证。开发者在样件和测试台架到位之前，就能发现多域集成的深水问题。

云端与物理硬件之间的迁移也无需重写。Google 提到，Arm 架构天然让云端和车辆共享指令集，而 Google 的 Axion 处理器配合 C4A metal 裸金属实例，可以直接为汽车和 Android 软件开发提供硬件级访问，减少不必要的软件层，保证性能一致性。同一套软件从云端挪到真实控制模块，不需要重新调校或重新验证。

真正的增量来自效率数据。RemotiveLabs 早期客户实测，集成周期加快超过 10 倍。当 AI 辅助和智能体工作流能够快速生成、测试和迭代车辆软件时，虚拟系统提供的规模优势会成为关键——任何无法虚拟化的元素都会拖慢整条开发链路。RemotiveTopology 本身基于标准 Linux 工具链，同一份拓扑既可以跑在笔记本上，也可以跑在 Google Cloud 的 CI 流水线中。

目前 RemotiveLabs 在 GitHub 上发布了开源简化车辆模型，开发者用现有工具几分钟就能启动一辆虚拟车。完整工具链可以随厂商规模平滑接入，RemotiveTopology 也能直接部署到 Arm 架构的 Google Cloud 环境中，作为 Horizon 平台的一个模块使用。

原文也留下一个值得继续追问的问题：这套模式目前清晰覆盖了 AAOS 以及基于 AAOS SDV 的域，但如何扩展到车辆其余部分，尤其是当其他操作系统介入时，仍待回答。