Google Cloudの仮想車両、AAOSを超えて最小のコントローラーまで拡張
Google Cloudは、コックピットを超えて仮想車両開発のアプローチを拡張し、ソフトウェアチームがハードウェアを待つ原因となる小規模なコントローラーを対象にしている。10月20日の発表では、Googleの車載オペレーティングシステムであるAndroid Automotive OSを、RemotiveLabsを通じてシミュレートされた車両ネットワークと接続する取り組みが説明されている。Google Cloudの仮想車両は、これまで分離されていたシステムを、より早い段階の統合テストに取り込むことを目的としている。
中心にある課題は実務的なものだ。ダッシュボードを単独でテストしても、車両の他の部分と正しい情報を交換していることは確認できない。機能の多くをソフトウェアに依存するソフトウェア定義車両では、依然としてコンポーネント間の連携した動作が必要となる。Googleは、すでにリモートでテストできるソフトウェアチームと、物理機器に作業が縛られているチームとの隔たりを狙っている。
AWSは以前、相互接続された仮想自動車コンポーネントについて説明しており、Googleのアプローチを理解するうえで有用な参照点となる。購入者にとっての問題は、こうした環境がどこまで実運用時の挙動を表現し、実際にどの開発遅延を取り除くのかという点だ。その区別は、デモが説得力のある仮想コックピットを表示できるかどうかよりも重要である。
Google Cloudの仮想車両、統合をコックピットの外へ拡張
この発表は、個々の車載アプリケーションの実行から、車両システム間の接続をテストすることへと焦点を移している。
Googleの仮想車両アーキテクチャは、Androidの仮想テスト環境と、接続された車両コンポーネントを記述・実行するためのツールであるRemotiveTopologyを組み合わせる。この構想は、コックピットコンピューティングから、制御システムに組み込まれる小型コンピューターであるマイクロコントローラーユニット、すなわちMCUまでを対象とする。
これは、車両ハードウェアが不要になったという発表ではなく、開発に関する提案である。また、エンジニアがソフトウェアを構築・テストする場所にも関わる。読者は、クラウドベースの開発が、走行中の車両にリモートサーバーへの依存を求めるものだと解釈すべきではない。
電子制御ユニット、すなわちECUは、特定の車両機能を担うコンピューターである。統合において重要なのは、その出力が別のコンポーネントの入力になったときに何が起こるかだ。あるコンポーネントは開発者の意図どおりに動作していても、共有信号について別チームの解釈と食い違う場合がある。
例として、運転モードの変更を考えてみよう。コックピットは要求されたモードを表示している一方で、別のコンポーネントが依然として以前の状態を報告する可能性がある。各アプリケーションは単独の検証に合格していても、組み合わせた動作は不整合のままである。相互作用をテストすることで、その不一致が可視化される。
この例は、仮想車両に魅力的な画面以上のものが必要な理由も示している。有用な成果物とは、ソフトウェア、接続、入力、期待される応答を実行可能な形で組み合わせた構成である。その価値は、その構成がどのエンジニアリング上の問いに答えられるかに左右される。
したがって、このような環境を評価するプロダクトマネージャーは、開発プロセスで何が変わるのかを問うべきだ。機器が届く前に、チームはインターフェース上の不一致を調査できるのか。別のエンジニアが障害を再現できるのか。サプライヤーがソフトウェアを更新した後も、同じシナリオを実行できるのか。
こうした問いは、広範なインフラ発表を評価可能なエンジニアリング提案へと変える。また、主張の境界も明確にする。通信上の誤りを早期に発見する環境は、量産車両のあらゆる物理的特性を再現しなくても価値を持ち得る。
開発者にとっての直近の機会は、隣接システムへのアクセスが早まることにある。プログラム責任者にとっては、統合に関する前提をより早く検証できることだ。こうした利点には、単に利用可能なクラウド容量を増やすのではなく、参加するコンポーネントを有用に表現することが必要となる。
これが、Googleが小規模なコントローラーを重視する理由である。開発環境は、有意義なテストを妨げる依存関係に届くほど、関連性を増す。ただし、追加されたコンポーネントがエンジニアが実際に検証する必要のある挙動を表現している場合に限り、対象範囲の拡大は役に立つ。
サプライヤーには、より早期にテスト可能な挙動を提供する圧力がかかる
早期統合によって、自動車メーカーがサプライヤーに求めるものと、その情報をいつ利用可能にすべきかが変わる。
Googleが説明するアプローチでは、開発上のマイルストーンは共有環境で実行可能な成果物へと移る。その成果物には、量産ソフトウェア、あるいは期待される挙動を限定的に表現したものが含まれる可能性がある。いずれの場合も、その範囲を明示する必要がある。
サプライヤーにとって、これは交渉すべき追加の納品物を生む。ネットワーク記述だけを提供しても、コンポーネントがどのように反応するかに関するすべての問いに答えられるわけではない。実行可能なソフトウェアを提供する場合は、アクセス、保守、そのソフトウェアの許容される用途について別の問題が生じる。
自動車メーカーにも対応する責任がある。どのコンポーネントのバージョンを組み合わせるか、どの前提が暫定的なままか、どの障害が以後の開発を阻むかを誰かが決めなければならない。テストを前倒ししても、責任の所在が自動的に決まるわけではない。
ここで、スケジュール上の圧力は組織上の圧力となる。仮想環境は物理的な統合より前に不一致を露呈させられるが、参加チームにはそれを解決するプロセスがなお必要だ。未解決のインターフェース上の疑問は、テストの実行場所がどこであっても未解決のままである。
有用な受け入れ基準は、サプライヤーの成果物が対応すべき挙動を特定する。たとえば、チームはコンポーネントに状態遷移の報告と、拒否された要求への対応を求めるかもしれない。これは、仮想車両との一般的な互換性を求めるよりも実行可能性が高い。
この区別は小規模なサプライヤーにとっても重要だ。購入者は、有用な仮想成果物を作成・維持するために必要な労力を評価すべきである。そうしなければ、誰が費用を負担し、最新状態を維持するのかについて明確な合意がないまま、作業が上流へ移される可能性がある。
既存のエンジニアリング知識も、実行可能な環境に追随する必要がある。意思決定がメッセージ、インターフェース文書、会議メモに分散したままであれば、テスト結果の解釈は難しくなる。再現可能な障害であっても、参加チームが何を期待していたのかという説明が必要だ。
検索可能なエンジニアリング知識ベースは、技術文書と並行してチームがそうした判断を取り出すのに役立つ。これはテスト環境とは異なる目的を果たす。すなわち、結果を理解し解決するために必要な文脈を保持することだ。
したがって、その圧力は組み込みソフトウェア開発者だけに及ばない。アーキテクチャチームには一貫した定義が、調達チームには明確な納品物が、プログラムマネージャーには観測可能な挙動に結び付いたマイルストーンが必要となる。仮想統合戦略は、それぞれの責任に関わる。
エンタープライズの購入者にとって、これは具体的な評価アプローチを示唆する。既存の統合依存関係を一つ選び、各参加者が何を提供しなければならないかをたどる。この演習により、提案されたプラットフォームが待ち時間を解消するのか、それとも不足している合意を早期に露呈させるだけなのかが明らかになる。
どちらの結果も情報をもたらす。早期の可視化は有用だが、購入者はサプライヤーの進捗に関する主張を評価する際、それと解決の完了を区別すべきである。
Vehicle-as-codeが接続をソフトウェアの一部にする
この仕組みは、その中で動作するソフトウェアとともに、システム構成を再現可能にすることに依存している。
Vehicle-as-codeとは、車両の電子アーキテクチャを、ツールが解釈して実行できるファイルとして表現することを意味する。アーキテクチャ記述は、エンジニアがレビュー、バージョン管理、再利用できるものになる。これは参加コンポーネントに共通の参照点を提供する。
RemotiveLabsのvehicle-as-codeの概念は、プラットフォーム記述と実行可能なインスタンスを区別している。プラットフォームは、利用可能なコンポーネントとその通信経路を記述する。インスタンスは、実行する特定の構成を選択する。
この区別は重要な誤解を防ぐ。完全なアーキテクチャを記述することは、そのアーキテクチャ内のすべてのコンポーネントがすべてのテストで実行されることを意味しない。対象を絞った構成でも、その境界が明確であれば、より限定的な問いに答えられる。
ドキュメントでは、量産ソフトウェアと、コンポーネントの挙動を模倣する振る舞いモデル、テストで制御された応答を提供するモックも区別されている。これらの表現は異なる目的に使われる。その存在は、エンジニアが成功した結果をどう解釈するかに影響すべきである。
たとえば、モックは、ディスプレイのエラー処理をテストするために必要な正確な応答を提供できる。その結果は、ディスプレイについて有用なことを示す。一方で、最終的な量産コントローラーが同等の条件下でその応答を生成するかについては、示せることが少ない。
分析上の利点は、こうした区別を隠すのではなく追跡することから生まれる。テスト環境では、実際に何が実行されたかを特定できるべきだ。そうでなければ、「完全な車両」という表現は、アーキテクチャのカバレッジと量産ソフトウェアのカバレッジの違いを曖昧にするおそれがある。
構成の一貫性も別の制約となる。RemotiveLabsのプラットフォーム記述には、システムや通信情報を記述するARXMLやDBC形式を含む、既存の車載ネットワークファイルを組み込める。同社のドキュメントでは、関連ファイルを組み合わせる際に、互換性のある名前、設定、バージョンが求められている。
この要件は注意に値する。ファイルを取り込んでも、相反するエンジニアリング上の判断が調整されるわけではないからだ。チームが互換性のない定義を提供した場合、自動化された環境でも解決が必要となる。再現性は不一致の調査を容易にするが、どの定義が正しいかを決めるものではない。
Google Cloudの仮想車両にとって、実務上の約束は、ソフトウェアとその周囲のシステムとの関係をレビュー可能にすることにある。ソフトウェアの変更は、既知の構成に対して評価できる。同様に、アーキテクチャの変更もレビューの明示的な一部となる。
変更を自動的にビルド・テストする実践である継続的インテグレーションは、この関係の場を提供する。有用な証拠の単位は、特定された構成内でテストされたソフトウェア改訂版となる。その構成から切り離された結果は、信頼しにくい。
これにより、チームがカバレッジを議論する方法も変わる。接続されたコンポーネントの数を数えるだけでは不十分だ。購入者は、どの相互作用が実行され、どの実装が参加し、残りの挙動をどの前提が補ったのかを知る必要がある。
したがって、最も強力なデモンストレーションは、エンジニアリング上の不一致が再現可能になり、その後に解決される様子を示すものとなる。これは、車両全体をクラウドで起動できるという広範な主張よりも、多くのことを読者に伝える。
AAOSの仮想テストにはハードウェアの境界が残る
忠実なソフトウェア環境にも、ハードウェア依存の挙動について明確に示された境界が必要である。
Cuttlefishは、Androidの構成可能な仮想デバイスであり、このアーキテクチャにおいて確立された要素です。Googleの仮想Androidデバイスに関するドキュメントでは、ローカルまたはリモートでの実行方法を説明し、Androidフレームワークの挙動に対する忠実性を強調しています。また、ハードウェア固有の実装に関わる差異も示されています。
この留保は発表内容に直接関係します。一般にAAOSと略されるAndroid Automotive OSは、参加するすべてのハードウェアとの相互作用を同等にすることなく、より大きなテスト構成に参加できます。環境の適用範囲を広げても、その内部にある違いがなくなるわけではありません。
ハードウェア抽象化レイヤーは、オペレーティングシステムとデバイス固有の機能を接続するソフトウェアです。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の仮想車両は、その証拠がより早期のエンジニアリング判断を支える領域で最も有用になります。まず、チームが現在テストできない相互作用から始め、信頼できる仮想結果が何を確立するかを問いましょう。
