フォルクスワーゲンが GPU と OpenShift で自動運転車をテストしている方法

2 年前に Red Hat Open Innovation Labs に参加したとき、フォルクスワーゲンは自動運転車の製造を支援するソリューションを求めていました。ドイツの由緒ある自動車メーカーである同社には、こうした自動車を組み立ててソフトウェアを開発するために必要な内部要素はすべて揃っていました。しかし、自動運転車の場合、問題は往々にして最後のステップで起こります。そのステップとは、すべてのソフトウェアが通過すべき関門、すなわち「テスト」です。

Volkswagen AG のテストテクノロジー総括責任者 Michael Denecke 氏はテストに関する問題を抱えていましたが、解決するための時間に余裕はありませんでした。そのうえ、組織文化の問題にも直面していました。同社では、トップダウン型の文化モデルを改めようと取り組んでいる最中だったのです。

「フォルクスワーゲンでの私の職務は、車に搭載されたすべての電子制御ユニットをうまく連携させることです」と、Denecke 氏は Red Hat Summit 2019 の基調講演で述べています。「自律走行コネクテッドカーに付随する新たな課題や、ドライバー向けシステムの数々の新機能を考慮すると、専用ハードウェアに対して行ってきた従来のテスト方法では不十分であるとわかりました。そこで、ハードウェアで行っているこのすべてのテストを仮想テスト環境に移行したらどうかというアイデアに至りました。そして行き着いたのが、OpenShift でのコンテナ利用です。私たちは仮想テスト環境を OpenShift 環境に取り込みました」

Denecke 氏は熟練した IT プロフェッショナルであり、OpenShift を選んだのには訳があります。「IT クラウドプロジェクトのグループを率いていたので、多くの IT ベンダーを知っていました。いろいろなベンダーに話を持ちかけましたが、実際には、『いいですね、やりましょう』という返事をもらえたのは Red Hat からだけでした」

Marcus Greul 氏は Volkswagen AG の IT プロジェクトマネージャーです。ドイツ・ニーダーザクセン州ウォルフスブルクにてテストおよびシミュレーションの研究開発に従事しており、Denecke 氏のチームに所属しています。

最近の OpenShift Commons Gathering で、Greul 氏はこのように述べています。「自動車開発において、統合テストは最も複雑な作業に数えられます。それには次のような理由があります。車載電子システムは、センサー、アクティベーター、制御ユニットと、複数のコンポーネントから成り立っています。この制御ユニットには 1 つ以上のソフトウェア・コンポーネントが搭載され、このコンポーネントは相互に統合する必要があります。統合テストでは、このような車載電子システムが、コンポーネントのすべての組み合わせに対して統合テストプロセスに合格しなくてはなりません。それぞれのモデル、ライン、車載ソフトウェアバージョン... システムに搭載される車体制御機能が増えれば、テストプロセスに合格するために必要なテストケースも増加します」

こうしたテストの結果に対して、さらに手を加えなければ人間にとって意味のある情報にならないとしたらどうでしょうか。こうしたテストでの操作が単純な「テキスト入力ボックスに長い文字列を入力する」ではなく、「バーチャルハイウェイでバーチャルアクセルを踏む」だとしたら、どうでしょうか。このようなシナリオを設定するだけでも、テストして結果を出すためには土台となる仮想化スタック全体を準備する必要があると Greul 氏は言います。 

Greul 氏は続けます。「まず、仮想環境を構築する時間が必要です。実世界ではテストをしないので、バーチャルカーも必要です... ユーザーとシステムとのやり取りをシミュレーションするため、バーチャルカーにバーチャル運転手を乗せます... テストされるシステム、すなわちテスト対象は、ソフトウェア・コンポーネントの場合もあれば、制御ユニット自体、システム全体、または機能を実行するシステムの組み合わせである場合もあります」

このようなテストシステムには、人間が目で見て評価できる出力、つまり映像が必要です。そして、このテストは仮想 3D 環境で仮想物理演算によって行われるので、GPU でプロセス全体を変換し、巨大なクラスタ上で短時間に処理できるようにすることが可能です。こうして得られた出力映像を見れば、テストが失敗したときに何が起きたかを確認できます。たとえば、車が道を外れた、別の車にぶつかった、そもそも動かなかったなどです。

「こうしたことは、OpenShift とどのような関係があるのでしょうか。ではここにテストベンチがあると仮定しましょう。このテストベンチでは、必要なコンポーネントはすべて、何らかのハードウェア上で実行されるソフトウェアです。そうしたコンポーネントには、仮想環境、データ分析、他のツール、テストケース、テストケースの実行、交通のシミュレーション、制御ユニットに働きかけるソフトウェア・コンポーネントなどがあります。このすべてをインスタンス化すれば、このテストベンチはほんの数分間で準備できます。以前は準備に数週間かかっていました。しかし爆発的な増加量を考慮すると、これで十分とは言えません。本当に必要なのは、大規模なスケーラビリティと自動化です。完全に自動化されたテストベンチで、数十万件のテストケースを無人で実行する。これが最終的な目的地です」と Greul 氏は語ります。

「2 年前に開始したこのプロジェクトでは、これほどのスケーラビリティと自動化を、どうしたらテストセンターに導入できるかに取り組みました。このテストベンチは OpenShift テンプレートとして記述でき、テンプレートはインテリジェントな自動化システムによってインスタンス化できます。このシステムでは、数百ものテストベンチを自動的に起動することができます」と Greul 氏は言います。

しかし、変化したのは、フォルクスワーゲンがソフトウェアをテストする方法だけではありません。同社の文化もまた、変化を遂げようとしています。ソリューションを見つけるための時間に余裕がないことも相まって、これは Red Hat Open Innovation Labs との共同作業を決めた大きな要因でした。 

Denecke 氏は次のように語ります。「アイデアを上層部にプレゼンする日まで、十分な時間がありませんでした... Red Hat の担当者に相談したところ、『Open Innovation Labs というサービスがあり、スケジュール内に目標を達成するにはこれしかない』と提案してくれました。また、フォルクスワーゲンにとって文化の変革は大きな意味を持ちます。この点からも、Innovation Labs は魅力的でした。Open Innovation Labs での共同作業は、『トップダウン型の管理ではなく、チームに責任を持たせる』というやり方で、これこそフォルクスワーゲンで成し遂げたいことでした」

Denecke 氏は、オープン開発モデルは新しいテストモデルの開発を成功させるため重要だったと言います。「仮想テスト環境が有効だと実証できました。まず、仮想テスト環境と実テスト環境を混在させられることを実証しました。この点は、このアイデアで新しいことだったと思います。また、品質と成功のためには文化の変革と共同作業が重要であることも示せました... マネージャーが部下にかける言葉は『状況はどうなっていますか？』ではなく、『マネージャーとして手伝えることはありますか？』でなくてはなりません」

2 年前、フォルクスワーゲンのチームが Red Hat Open Innovation Labs に参加したとき、既存のテストシステムでは大量に押し寄せる今後の要求には耐えられないと分かっていました。当時、Kubernetes と OpenShift を使用するコンテナ内で GPU をサポートする手段は市販の製品にはありませんでした。そこで、Red Hat とフォルクスワーゲンは共同でこのシステムを開発しました。協力の下、アップストリーム Kubernetes プロジェクトに GPU のサポートを追加し、同時に Red Hat OpenShift でもサポートするようにしました。

現在までに、フォルクスワーゲンのシステムでは、コンポーネント、システム、ソフトウェアのさまざまな組み合わせに対する数十万件のテストが実行されました。アジャイル開発にとって重要な、テスト/レポート/修正のフィードバックループが開発者にもたらされます。これにより、ソフトウェアを作るのと同じスピードでイノベーションを実現することも可能となります。