フォルクスワーゲンがコンテナでデジタルツインを構築

VolkswagenがOpenShiftでコンテナ環境を整備。コンテナで各種ECUをエミュレートして、その上で実行するソフトウェアのテストを行っているという。同社のデジタルツイン構築の詳細を紹介する。

公開 2021年10月04日 08時00分

更新 2023年02月08日 12時21分

著者

Cliff Saran

[Computer Weekly]

印刷する連載新着通知を受け取る

　現代の自動車はパラメーターを管理・監視する多数のコンピュータで構成され、安全性を高め、燃料効率を改善し、構成部品の故障を減らす。

　ソフトウェアは個別テストだけでなく、他の車載システムに悪影響を及ぼさないことを確認する統合テストも必要だ。

　McKinsey & Companyは2018年、自動車に搭載されるソフトウェアのライン数（コード量）が、約1000万（2010年）から約1億5000万（2016年）になっていると発表した。

　「雪だるま式に増大する複雑さが原因で、ソフトウェアの品質に重大な問題が起きている。最近の何百万台もの自動車のリコールを見ても明らかだ」と、McKinseyは「Rethinking car software and electronics architecture」で警告している。

　自動車に組み込むソフトウェアが減る可能性は低い。そう考えたVolkswagenは、Red Hatの協力を得てソフトウェア統合プラットフォームを構築した。コンテナオーケストレーションシステム「Red Hat OpenShift」を基盤とするこのプラットフォームによって、ECU（電子制御ユニット）用ソフトウェアの開発とテストができるようになった。

　「車載ソフトウェア開発では、コンテナが重要な役割を果たす可能性がある」と語るのはVolkswagen Group傘下企業CARIADのマーカス・グレル氏（最高製品責任者）だ。

　「当社はスケーラブルなテスト環境を構築するためにコンテナを使っている。いつかこのアイデアを車上で使う機会があるかもしれない。安全性関連の機能にコンテナを使う可能性はかなり少ないが」

　Volkswagenの電気開発部門は、電動ミラーやECUなどのテストを行っている。車両には最大60個のECUが搭載される可能性があり、それぞれで広範なテストを要する。1つのECUを更新または追加するたびに関連するテストを全て繰り返さなければならず、統合はより複雑になる。

　Volkswagenがソフトウェアテストを刷新する必要があったもう一つの要因が、統合テスト環境にオンデマンドでプロビジョニングする能力が欠けているために起きていた遅延だった。OpenShiftの標準インフラを組み合わせることでコンテナモデルをECUに動的にリンクできるようになり、テストベンチの提供時間が数日から数時間に短縮されるという。

　「仮想と物理の両コンポーネント用の共有環境を作ることによって、車両にソフトウェアをリリースする開発、テスト、デプロイのサイクルを標準化・自動化したいと考えている」（グレル氏）

　同社は、コンテナ内でECUのシミュレーションをしている。「さまざまな種類の『仮想ECU』を利用できる。ECUをエミュレーションして、その上でソフトウェアを実行できる」（グレル氏）

　統合テストの結果と路上テストの結果を結び付けることも計画している。

　Volkswagenは、車両プラットフォーム、各モデル、各機器ラインにもOpenShiftによるデジタルツインを適用しようとしているという。

　新プラットフォームには他にもRed Hat製品が含まれている。OpenShift用のプライベートコンテナレジストリには「Red Hat Quay」を使い、コンテナイメージを格納、構築、デプロイする。「Red Hat Runtimes」はクラウドネイティブアプリケーションの開発と保守に必要なツールを提供する。メッセージングは「Red Hat AMQ」で管理し、「Red Hat Virtualization」は「Red Hat Enterprise Linux」で仮想化ワークロードを実行するためのソフトウェア定義プラットフォームを提供する。

印刷する