【ITニュース解説】Building full virtual vehicles on Google Cloud: From AAOS to the smallest MCU

現代の自動車開発において、大きな変革が起きている。かつて車は多くの機械部品で構成され、修理や改良は物理的な作業が中心だった。しかし今日では、ソフトウェアが車の機能の大部分を定義する「ソフトウェア定義型車両（SDV）」への移行が加速している。これは、車の情報表示スクリーンやエンタメシステムといった高機能な部分だけでなく、ブレーキやエンジン、ライトの制御など、車の根幹をなす無数の小さなコンピューターや制御モジュール（マイクロチップ）にまで及ぶ動きである。

現状、多くの自動車メーカーや部品メーカーの開発プロセスには課題がある。デジタルエンタメシステムなどは、クラウド環境を活用したソフトウェア開発手法で効率的に作られている一方、車両の中枢を制御する数十個のマイクロチップや制御モジュールは、いまだに物理的なチップに直接配線されて設計されることが多い。このため、一度車両が工場を出ると、これらの部品の機能更新やプログラムの変更、拡張が非常に困難となる。開発チームは、物理的な試作品やテストベンチが準備できるまで待たなければならず、システム全体の統合テストは開発プロセスの最終段階にずれ込みがちである。この段階で問題が発見されると、修正にかかるコストは非常に高額になるという非効率性が、SDV実現の大きな障壁となっていた。

この課題を解決するため、Google CloudはRemotiveLabsと協力し、自動車メーカーが車両開発の非効率性を回避できる革新的なプラットフォーム「Horizon」を提供している。このプラットフォームは、車両全体を仮想環境で構築し、ソフトウェアを開発・テストすることを可能にする。

車のコックピット、具体的にはインフォテインメントシステムなどのデジタルシステムについては、すでに仮想化が進んでいる。GoogleのAndroidチームは、車両のデジタルコックピットをシームレスに開発するために多大な努力を払ってきた。Android Automotive OS（AAOS）は、Googleが提供する公式のAndroid仮想テスト環境「Cuttlefish」内で動作する。このCuttlefish自体が、Google Cloud上で提供されるArmベースのインスタンス（仮想サーバー）で快適に実行される仕組みである。これにより、開発者は、実際に車に搭載されるArmアーキテクチャと同じ環境で、仮想的なインフォテインメントシステムを構築し、起動し、テストできる。最近のAndroid 17およびAAOS SDVの登場により、この仮想化能力はさらに多くの車両ドメインに拡大された。つまり、代表的なソフトウェアを、代表的なアーキテクチャ上で、クラウド環境で、必要な時にすぐに利用できるモデルが確立されたのだ。しかし、このモデルを車両全体の他の部分、特に他のOSが関与する領域にどう拡張するかが、次の課題であった。

ここで登場するのが「RemotiveTopology」という技術である。RemotiveTopologyは、仮想車両を構成する「ハーネス（配線）」のような役割を果たす。これは、Cuttlefish内で動作するAAOSと、車両全体の仮想的な電気・電子（E/E）アーキテクチャ、つまり車の他のオンボードコンピューター、データネットワーク、そしてシステムを実車のように機能させるリアルタイム信号とをつなぐ層である。RemotiveTopologyは、自動車メーカーが既存で持っているネットワーク設計ファイルを自動的に利用し、その車のネットワークの仮想版を動作可能にする。これは「vehicle-as-code（車両をコードとして扱う）」という考え方である。E/Eアーキテクチャは実行可能な仕様としてコードで表現され、ITインフラをコードで管理する「infrastructure-as-code」のようにバージョン管理され、必要な時に準備できる。これにより、車両全体をオンデマンドで仮想環境上に立ち上げることが可能になる。コックピットのソフトウェアは、あたかも実車であるかのように車両の他の部分と通信する。その結果、開発者はシステムの状態をリアルタイムで確認でき、車両全体の信号と異なるドメイン間の連携を継続的に可視化できる。また、標準的なLinuxツールをベースに構築されているため、同じトポロジーがノートパソコン上でも、Google Cloud上での継続的インテグレーションパイプライン（ソフトウェアを継続的に統合・テストする自動化されたプロセス）内でも実行できる。

このアプローチの大きな利点は、車両のすべてのオンボードシステムを、物理的なハードウェアに接続する前に、ソフトウェアとして開発し統合できる点にある。車両開発において最も困難で、かつ最も遅い段階で行われる統合テストは、すべてのシステムを一堂に集めて連携させることである。例えば、先進運転支援システム（ADAS）が生成する物体のリストや走行経路、モード切り替え要求は、コックピットで表示され、それに応じて反応する必要がある。同時にインフォテインメントシステムや情報ディスプレイは運転状態を反映し、車体やシャシーの制御モジュールも連携して機能しなければならない。RemotiveTopologyによって車両全体のトポロジーがGoogle Cloud上で稼働していれば、インフォテインメントシステムとADASは仮想車両内で同時に動作し、シミュレートされたネットワークを介して実際の信号を交換できる。これにより、例えばADASのイベントがディスプレイに表示されたり、ドライバーモードの変更が複数のドメインにわたって影響を及ぼしたりといった複雑な連携を、開発の初期段階から、継続的インテグレーションのプロセス内でテストすることが可能になる。物理的なテストベンチや試作品が揃うずっと前から、多ドメイン間の統合の問題を発見し、継続的にテストできるため、開発者は高い確信を持って開発を進められる。

この取り組みの核心は、車両の最も小さく一般的な部品であるマイクロチップや制御モジュールにまで、スケーラブルなソフトウェア開発をもたらしたいという共通の願いにある。これらの部品が、これまで物理的なハードウェアに配線され、真のSDV実現の最大の障害となってきたからだ。究極の目標は、クラウドで動作するソフトウェアを、再ツール化や再検証なしに、車両の実際の制御モジュールでそのまま実行できるようにすることである。このクラウドと実車の間の「パリティ（同等性）」は、ArmベースのGoogle Cloudインフラストラクチャを用いることで自然に実現される。クラウドと車が同じ命令セットを共有するからである。GoogleのArmベースプロセッサ「Axion」は、これを特に容易にしている。C4A metalというベアメタルArmインスタンス（仮想化層のない物理サーバーインスタンス）が自動車システム開発やAndroidソフトウェア開発のために明示的に提供されており、不必要なソフトウェア層を介さずに直接ハードウェアにアクセスでき、車両システムが必要とする一貫した性能を提供する。

これら全体的なシステムにより、開発チームは初めて、車両全体のシステムをクラウド上で開発し、統合テストを行い、そのソフトウェアを書き直すことなく実際の車両に適用できるようになった。この効果は抽象的なものではない。車両をコードとして扱い、統合プロセスをクラウドに移行することで、開発プログラムの中で最も遅く、最も高価なフェーズが大幅に圧縮される。RemotiveLabsとの初期の顧客協業では、統合サイクルが10倍以上高速化された実績がある。開発ループは今やハードウェア開発よりも速く変化しており、AIを活用した自律的なワークフローが車両ソフトウェアを迅速に生成、テスト、改善できるが、これを必要な規模で実現できるのは仮想システムだけである。仮想化できない要素が一つでもあると、開発プロセス全体が遅れる可能性がある。

RemotiveTopologyは、このような車両をコードとして扱うアーキテクチャを提供し、開発者、テスター、自律AIエージェントのいずれにとっても利用しやすいものにしている。さらに、新しく特別なツールを導入することなくすぐに開始できるのが最大の利点である。RemotiveLabsはGitHubでオープンソースの簡易車両を提供しており、誰でも標準的なLinuxツールと既存のプラットフォーム定義を使用して数分で実行できる。自動車メーカーや部品メーカーが規模を拡大する際には、既存の完全なツールチェインをそのまま接続でき、RemotiveTopologyはArmベースのGoogle Cloud環境に簡単に導入できる。コックピットの仮想開発で止まっていたSDV開発者にとって、今こそオープンソースの事例から始め、独自のプラットフォーム定義を組み込み、車両全体をクラウドで実行する時が来ている。RemotiveTopologyは、Horizonプラットフォーム内で他のモジュールと組み合わせて容易に利用できる。