自動運転とコネクテッドカー技術が自動車産業の構造を根底から覆している現代、多くの車載インフォテインメント（IVI）システムの中核を担っているのが AAOS (Android Automotive OS) だ。スマートフォンで慣れ親しんだ利便性を車内に持ち込むことは魅力的だが、エンジニアにとってその裏側は戦場に近い。スマホのアプリがクラッシュしてもユーザーは不機嫌になるだけだが、時速100kmで走行する Automotive システムのエラーは、ドライバーの生命に関わるリスク直結するからだ。OEMやTier-1サプライヤーにとって、テストは単なる「工程」ではなく、事業継続のための「生存戦略」である。本稿では、AOSPのドキュメントを読み漁るだけでは見えてこない、現場視点でのテスト手法を叩き込む。
なぜAAOSのテストは「スマホの10倍」難しいのか
通常のAndroid開発とAAOS開発の決定的な違いは、ハードウェアの多様性とライフサイクルの長さにある。スマートフォンは数年で買い替えられるが、自動車は10年以上使われる。この期間、システムは安定稼働し続けなければならない。
さらに、AAOSは単なるOSではなく、車両ネットワーク（CAN/LIN）や、独自のHAL（Hardware Abstraction Layer）と密接に連携する。ここで重要になるのが、Googleが提供する標準テストスイートと、ベンダー独自の検証のバランスだ。公式の Android Test Infrastructure を理解せずして、量産車にコードを載せることは許されない。
Google Automotive Services (GAS) を搭載して出荷する場合、後述するCTS/VTSの全項目パスは絶対条件だ。1つのテスト失敗が、車両の発売延期（SOP遅延）を招くことを肝に銘じてほしい。
2大障壁：CTSとVTSの完全攻略
AOSP開発者が避けて通れないのが、CTS (Compatibility Test Suite) と VTS (Vendor Test Suite) だ。これらは似て非なるものであり、ターゲットとするレイヤーが明確に異なる。
- CTS (Compatibility Test Suite): アプリケーションレベルの互換性を保証する。APIが期待通りに動作するか、標準的なAndroidの挙動と一致するかを検証する。
- VTS (Vendor Test Suite): カーネルとHAL（ハードウェア抽象化レイヤー）の正確性を保証する。AAOSにおいては、車両固有のHAL（Vehicle HALなど）が正しく実装されているかを叩くため、CTS以上に重要度が高いことが多い。
現場でよくあるのが、「CTSは通ったがVTSでカーネルパニックが起きる」というケースだ。これは下位レイヤーの実装ミスを示唆している。以下は、開発用PCからVTSを実行するための基本的なコマンドラインフローだ。
// 1. 環境設定（AOSPビルド環境にて）
$ source build/envsetup.sh
$ lunch aosp_car_x86_64-userdebug
// 2. VTSのビルド（数時間かかる場合もあるため注意）
$ make vts
// 3. VTSコンソールの起動と実行
$ vts-tradefed
// 特定のモジュールのみを実行する場合（全実行は時間がかかりすぎるため推奨）
tf > run vts -m VtsHalVehicleV2_0Target
// 解説: Vehicle HAL 2.0の実装をターゲットに絞ってテストを実行するテストカバレッジの多層構造
CTS/VTSさえ通れば良いというわけではない。実際の生産ラインでは、より多層的なアプローチが必要になる。以下の表は、AAOS開発におけるテストレイヤーの役割分担を整理したものだ。
| テスト種別 | 対象レイヤー | 主なツール/手法 | 目的 |
|---|---|---|---|
| Unit Test | Java/Kotlin/C++ | JUnit, Google Test | ロジック単体の正当性検証 |
| CTS | Framework API | cts-tradefed | Androidエコシステムとの互換性 |
| VTS | HAL / Kernel | vts-tradefed | ハードウェアインターフェースの遵守 |
| System Test | Integration | Python Scripts, Appium | UI操作を含むエンドツーエンド検証 |
| Field Test | Full Vehicle | 実車走行 | 実環境（振動、熱、通信断）での安定性 |
結論：品質への投資は裏切らない
AOSP Automotiveの開発において、テストエンジニアリングは開発の「付属品」ではなく「中核」だ。CTSやVTSの複雑さに圧倒されるかもしれないが、これらはGoogleが世界中のデバイスで蓄積した「地雷」を避けるための地図でもある。初期段階からCI/CDにこれらのテストを組み込み、常にグリーンな状態を保つことこそが、最強のAutomotiveシステムを構築する唯一の近道である。
Post a Comment