Google Cloud 虚拟车辆从 AAOS 延伸至最小控制器

Google Cloud 正将其虚拟车辆开发方法从座舱扩展到让软件团队等待硬件的较小控制器。其 10 月 20 日的公告介绍了如何通过 RemotiveLabs，将 Google 的车载操作系统 Android Automotive OS 与模拟车辆网络连接起来。Google Cloud 虚拟车辆旨在让这些原本分离的系统更早进入集成测试。

核心矛盾很实际：单独测试仪表盘，并不能证明它与汽车其他部分交换了正确的信息。软件定义汽车的功能很大程度上依赖软件，但各个组件之间仍需协调运作。Google 正瞄准这样一个缺口：部分软件团队已能远程测试，而另一些团队的工作仍受制于实体设备。

AWS 此前曾介绍相互连接的虚拟汽车组件，这为理解 Google 的方案提供了有用参考。对采购方而言，问题在于这些环境能代表多少量产行为，以及它们实际消除了哪些开发延误。这一区别比演示是否能呈现一个逼真的虚拟座舱更重要。

Google Cloud 虚拟车辆将集成扩展至座舱之外

该公告将重点从运行单个车辆应用，转向测试车辆系统之间的连接。

Google 的虚拟车辆架构将 Android 的虚拟测试环境与 RemotiveTopology 相结合；后者是一种用于描述和运行互联车辆组件的工具。其所述目标覆盖范围从座舱计算延伸至微控制器单元，即 MCU——嵌入控制系统中的小型计算机。

这是一项开发方案，并不意味着车辆硬件已不再必要。它同样涉及工程师构建和测试软件的地点。读者不应将云端开发理解为要求行驶中的车辆依赖远程服务器。

电子控制单元，即 ECU，是负责特定车辆功能的计算机。关键的集成问题在于，当其输出成为另一组件的输入时会发生什么。一个组件可能符合其开发者的预期，但仍可能与另一团队对共享信号的理解不一致。

以一个说明性的驾驶模式切换为例。座舱可能显示所请求的模式，而另一组件仍报告先前状态。每个应用都可能通过独立检查，但组合后的行为仍会不一致。测试这种交互可让分歧显现出来。

这个例子也说明，虚拟车辆需要的不只是精美的屏幕。真正有用的产物，是由软件、连接、输入和预期响应构成的可执行安排。它的价值取决于这种安排能回答哪些工程问题。

因此，评估此类环境的产品经理应询问：开发流程发生了什么变化？团队能否在设备到位前调查接口分歧？另一位工程师能否复现故障？供应商更新软件后，相同场景能否继续运行？

这些问题将宽泛的基础设施公告转化为可评估的工程主张，也为相关说法划定了边界。一个能及早发现通信错误的环境，即便无法复现量产车辆的每一种物理特性，依然可能很有价值。

对于开发者而言，直接机会是更早接触相邻系统。对于项目负责人而言，则是更早获得关于集成假设的证据。这些收益需要对参与组件作出有用的表征，而不只是提供更多可用的云端算力。

这也是 Google 强调较小控制器的重要原因。随着开发环境触及阻碍有意义测试的依赖关系，它的相关性会提高。然而，只有新增组件代表工程师确实需要考察的行为，扩大范围才会有帮助。

供应商面临更早交付可测试行为的压力

更早集成改变了汽车制造商对供应商的需求，包括这些信息必须何时变得可用。

按照 Google 所描述的方法，开发里程碑转向对共享环境作出可运行的贡献。这种贡献可能包含量产软件，或对预期行为的有限表征。无论哪种情况，其范围都需要明确。

对于供应商而言，这带来了一项需要协商的额外交付物。仅提供网络描述，并不能回答组件如何响应的所有问题。提供可执行软件则会引出有关访问权限、维护以及该软件允许用途的独立问题。

汽车制造商也面临相应责任。必须有人决定哪些组件版本应当组合、哪些假设仍属暂定，以及哪些故障会阻碍后续开发。将测试前移并不会自动分配所有权。

这正是进度压力转化为组织压力的地方。虚拟环境可以在实体集成之前暴露分歧，但参与团队仍需要一套流程来解决它。无论测试在哪里运行，一个未得到回答的接口问题依然没有答案。

一个有用的验收标准应明确供应商贡献必须支持的行为。例如，团队可能要求某组件报告状态转换，并处理被拒绝的请求。这比笼统要求与虚拟车辆兼容更具可操作性。

这一差别对较小供应商同样重要。采购方应评估产出并维护有用虚拟贡献所需的工作量。否则，工作可能被转移至上游，却没有明确约定谁为其提供资金或保持其更新。

现有工程知识也需要伴随可执行环境流动。当决策分散在消息、接口文档和会议记录中时，测试结果就会难以解读。即使故障可以复现，仍需要解释参与团队原本预期的是什么。

一个可搜索的工程知识库可帮助团队在技术文档旁检索这些决策。它与测试环境的用途不同：前者用于保留理解和解决结果所需的背景信息。

因此，压力落在的并不只是嵌入式软件开发者身上。架构团队需要一致的定义，采购团队需要清晰的交付物，项目经理需要与可观察行为挂钩的里程碑。虚拟集成策略会触及上述每一项职责。

对于企业采购方，这意味着一种具体的评估方法：选择一项现有集成依赖关系，并梳理每个参与方必须提供什么。该过程将揭示拟议平台究竟消除了等待，还是仅仅更早暴露了缺失的共识。

两种结果都能提供信息。更早可见是有用的，但采购方在评估供应商的进度主张时，应将其与问题已得到解决区分开来。

车辆即代码将连接关系纳入软件范畴

这一机制依赖于让系统安排与其中运行的软件一样可复现。

车辆即代码意味着以工具能够解读和执行的文件来表达车辆电子架构。架构描述成为工程师可以审查、版本管理和复用的内容，并为参与组件提供共同参考。

RemotiveLabs 的车辆即代码概念区分了平台描述与可运行实例。平台描述可用组件及其通信路径；实例则选择要执行的特定配置。

这种区分避免了一个重要误解。描述完整架构并不意味着该架构中的每个组件都会在每项测试中运行。只要其边界保持清晰，聚焦的配置就可以回答更狭窄的问题。

该文档还区分了量产软件、模仿组件行为的行为模型，以及提供测试控制响应的模拟对象。这些表征服务于不同目的。它们的存在应影响工程师对测试通过结果的解读。

例如，模拟对象可以提供测试显示屏错误处理所需的精确响应。该结果能说明显示屏的某些有用信息，却较少说明最终量产控制器是否会在等效条件下生成该响应。

分析优势来自于追踪这些区别，而非将其隐藏。测试环境应让人能够识别实际运行了什么。否则，“完整车辆”这一表述可能会掩盖架构覆盖范围与量产软件覆盖范围之间的差异。

配置一致性是另一项约束。RemotiveLabs 的平台描述可纳入既有的汽车网络文件，包括描述系统或通信信息的 ARXML 和 DBC 格式。其文档要求在组合相关文件时使用兼容的名称、设置和版本。

这一要求值得关注，因为导入文件并不能协调相互矛盾的工程决策。如果团队提供不兼容的定义，自动化环境仍需要作出解决。可复现性让分歧更容易调查；它并不决定哪个定义正确。

对 Google Cloud 虚拟车辆而言，实际承诺是软件与其周边系统之间可审查的关系。软件变更可针对已知安排进行评估。架构变更同样可成为审查中明确的一部分。

持续集成，即自动构建和测试变更的实践，为这种关系提供了环境。有用的证据单元，成为在明确配置中测试的软件修订版本。脱离该配置的结果较难令人信任。

这改变了团队讨论覆盖范围的方式。仅计算连接的组件数量是不够的。采购方需要了解测试了哪些交互、哪些实现参与其中，以及哪些假设提供了其余行为。

因此，最有力的演示应展示某项工程分歧如何变得可复现，随后又如何得到解决。这比笼统宣称整车可以在云端启动，更能说明问题。

AAOS 虚拟测试仍存在硬件边界

即使是高保真软件环境，也仍需要清楚说明其围绕依赖硬件行为所划定的边界。

Cuttlefish 是 Android 的可配置虚拟设备，也是这一架构中成熟的一环。Google 的虚拟 Android 设备文档介绍了如何在本地或远程运行它，并强调其对 Android 框架行为的保真度。文档也指出了与硬件特定实现相关的差异。

这一限定与该公告直接相关。Android Automotive OS，通常简称为 AAOS，可以参与更大范围的测试安排，但这并不意味着所有参与其中的硬件交互都完全等同。扩展环境的覆盖范围，并不会消除其内部的差异。

硬件抽象层是连接操作系统与设备特定功能的软件。Cuttlefish 的文档明确将这一领域列为其与物理设备存在差异的来源。买方在解读更广泛的虚拟车辆主张时，应保留这一限定。

对于共享处理器架构，也应保持同样的审慎态度。相似的执行基础可以支持一种开发策略，但买方仍需要获得有关具体目标的证据。一项关于软件兼容性的声明，应明确所比较的软件、硬件假设和行为。

当标题从座舱计算延伸至最小的 MCU 时，这一点尤其重要。呈现控制器的信息，与执行其生产软件并不相同。执行该软件，也不同于复现其与物理环境的每一项交互。

这些区别并不会削弱虚拟测试的价值。它们界定了测试结果能够证明什么。当其假设与工程师试图回答的问题相吻合时，范围明确的结果可以极具价值。

问题出现在叙述过程中范围被扩大时。一次成功的接口测试可能被表述为整个系统完全等效的证明。一次云端演示可能被表述为剩余验证工作已经消失的证明。这两种结论都不会自动成立。

Google 和 RemotiveLabs 表示，在早期客户合作中，集成周期加快了 10 倍以上。该公告没有提供足够的方法论细节，无法将这一数字视为通用基准。读者在将其应用于自身项目之前，需要了解基线、测量的活动和剩余工作。

评估应区分等待时间与工程投入。消除设备排队等待很有价值，但它衡量的内容不同于缩短缺陷调查时间。将这些结果合并为单一的加速数字，可能掩盖实际收益。

买方还应询问，发现的问题能否在测试环境变化后依然成立。虚拟环境中识别的问题，是否会在预期的物理条件下出现？其拟议修复方案是否同时适用于两种环境？这些问题有助于评估相关性，而无需要求普遍等效。

由此得出的判断，比“硬件已被取代”的说法更为狭窄且更具实用性。AAOS 虚拟测试可以支持更早开展集成，同时工程师仍需确定哪些结论能够跨越硬件边界成立。

AWS 为互联虚拟组件提供了先例

Google 的方法加入了既有努力，即让汽车集成更少依赖物理开发目标。

AWS 于 2024 年 6 月 13 日介绍了一种相关架构，采用 Panasonic Automotive vSkipGen 和 ETAS RTA-VRTE StarterKit。其互联虚拟目标连接供应商环境，以支持更早进行集成。已发布的方案还支持协作，同时无需参与者暴露其源代码。

这一先例为当前公告提供了背景。通过云基础设施连接汽车软件组件，是一个已经确立的发展方向。Google 的贡献应根据其具体集成路径、支持的环境以及对参与工程团队的实用性来评估。

这一比较并不能确定胜者。所引用的材料描述了不同的安排，且没有提供共同基准。关于相对完整性或性能的主张，需要等效的工作负载和明确匹配的评估标准。

对于希望从竞争角度理解 Google 虚拟车辆的读者而言，有价值的比较在于开发依赖关系。哪种方法适合项目已在使用的组件？哪些供应商贡献可以参与？现有测试在能够运行之前还需要完成哪些工作？

在这一比较中，安全边界同样值得关注。供应商需要在控制其工作访问权限的同时开展合作。买方应评估拟议安排是否支持所需协作，并保留参与者之间已商定的边界。

这些问题使核心张力始终清晰可见：更早的共享测试，还是等待物理设备后再进行集成。云供应商之间的竞争只是背景。工程决策取决于某一具体安排是否能改变实际项目中的这种依赖关系。

因此，买方不应将云品牌视为集成计划的替代品。可用的计算资源只是该安排的一部分。组件、权限、测试所有权和可复现配置，决定了团队能否有效使用这些资源。

可移植性也是一个合理的评估问题，而非可以预设的既定收益。团队应明确哪些描述、测试和模型可以在其他地方复用，也应明确哪些依赖项需要替换。

这很重要，因为工程投入会延续到最初演示之后。开发出有用场景的团队，会希望在组件发生变化时保留这些场景。在大量测试依赖于此之前，评估应审查这一维护路径。

对于 Google Cloud 车辆仿真，其竞争机会在于让既有开发工作流更容易跨越系统边界扩展。买方需要获得这种契合度的证据。仅基于虚拟座舱演示的比较，无法回答核心集成问题。

因此，AWS 的先例强化了这一类别的合理性，同时也提高了差异化的标准。Google 的方法需要展示其具体组合如何改善工程师已经在进行的工作。

关注覆盖范围、可量化结果和可复现示例

下一批证据应揭示哪些内容能够运行、哪些方面得到改善，以及其他团队能够复现什么。

未来几个月，首个值得关注的信号是更明确的组件覆盖范围。有价值的披露应区分生产软件、行为模型和测试控制的替代方案，也应明确所涉及的运行环境和目标假设。

这些细节将通过使范围可评估，增强 Google Cloud 虚拟车辆的论据。缺乏相应实现细节的宽泛架构图，无法消除核心不确定性。读者应寻找有关参与组件的证据，而非更宏大的完整性主张。

覆盖范围还需要与实际工程工作建立联系。新支持的控制器，只有在能够解锁相关交互或消除某项依赖时才具有意义。支持公告在包含工程师如今能够检查的场景时，会更具信息价值。

下一个信号是具有明确边界的客户结果测量。一份有价值的案例研究应说明原有工作流、发生变化的活动，以及之后仍然需要完成的工作。它应区分设备等待、测试执行和缺陷调查。

这类报告将帮助买方判断所报告的加速是否适用于自身情况。来自范围狭窄的集成活动的结果，应始终与该活动相联系。脱离测量范围重复速度提升，几乎无法增加证据价值。

读者还应关注那些使最初叙述更复杂的结果。某个环境可能缩短访问延迟，却增加配置维护工作。它可能更早暴露更多缺陷，却不会立即缩短项目周期。这些结果仍有助于解释该方法在哪些场景下有效。

最后一个信号是从公开示例到持续维护的评估之间更清晰的路径。RemotiveLabs 的虚拟车辆示例提供了一个具体起点，其中包括与 Android 相关的示例。该仓库将其采用 MIT 许可证的示例代码，与底层 RemotiveLabs 软件区分开来。

这一区别对于计划开展评估的任何人都很重要。可公开复用的示例，并不能证明每项所需依赖都采用相同许可证。买方在假定可无限制复用之前，应审查完整的运行时安排和访问要求。

可复现性将增强该公告的实际价值。工程师应能够识别示例版本、理解其假设，并明确它解决了哪些生产环境问题。当另一支团队能够说明其局限性时，一次成功的演示会更具说服力。

对于工程领导者而言，眼下的行动是从现有项目中选择一个尚未解决的集成问题。询问拟议的虚拟环境能否在所需设备到位之前回答它。记录哪些组件包含生产软件、哪些使用替代方案，以及哪些结论仍需要物理确认。

应使该评估的范围足够狭窄，以产出可解释的结果。将这项调查与当前流程比较，包括设置和维护工作量。将软件修订版本、配置、预期行为和观察到的结果一并保留。利用这些记录判断扩展环境是否能够消除另一项依赖。Google Cloud 虚拟车辆将在证据支持更早工程决策的场景中最具价值。从团队当前无法测试的交互入手，然后询问一项可信的虚拟结果能够证明什么。