Red Hat Summit 2024からRed HatとGMが行った車載システムのセッションを紹介

Red Hat Summit 2024から、Red HatとGeneral Motors（以下、GM）のエンジニアが行った車載システムに関するセッションを紹介する。これは「Containers on Wheels: The foundation of Software Defined Vehicles」と題されたセッションで、プレゼンテーションを行ったのはGMのシステムアーキテクトTomer Peretz氏と、Red HatのシニアプリンシパルエンジニアPierre-Yves Chibon氏だ。

車載システムのセッションをGMとRed Hatのエンジニアが共同で講演

ちなみにPierre-Yves Chibon氏はCentOSのSIG、Automotiveのテクニカルリードを務めている人物だ。

講演を行うGMのPeretz氏（左）とChibon氏（右）

セッションは自動車における安全性についてISO26262によって定められた安全基準、ASIL（Automotive Safety Integrity Level）の解説から始まった。また自動運転にもさまざまなレベルがあることも紹介されている。

ASILについて簡単に解説

この1枚のスライドでASILを理解するのは難しいだろう。より深い理解を得るためにはマクニカがまとめたブログ記事を参照して欲しい。

●参考：ISO26262とASILの基本：【機能安全とは】組み込みシステムにおける安全規格について解説

このブログ記事の引用元は日本新質保証機構のドキュメントである。

●参考：安全規格の紹介（PDF）

そして車載システムの遷移として、中央のコントローラーが自動車のすべての機構を管理するシステムアーキテクチャーについて、Distributed、Domain、Zonalの3つを挙げて解説。ここではそれぞれのアーキテクチャーの特徴を簡単に示している。例として挙げられているAUTOSARは自動車業界の車載システム開発のための国際的パートナーシップで、そこではシステムに関する仕様を制定する作業を行っているという。

アーキテクチャーが進化して固定の機能から、より高度な機能を提供できるように遷移している

Zonal Architectureの解説。最もクラウドっぽいとも言える？

自動運転については2019年にGTCを取材した以下の記事でも書いたが、当時はセダンタイプの乗用車に大柄なセンサー類を屋根の上に設置した上で巨大なGPUサーバーをトランクに収容しないと処理ができないという状態だった。システム自体は5年の歳月を経てかなり集約されたのかも知れないが、1台のECU（Electronic Control Unit）ですべてを制御するのはもはや不可能で、ゾーンごとに分散されたコントローラーがデータ量と処理要件に応じて配備されるゾーン方式が理想の方式ということになる。言わば「車載クラスター」とも呼べるシステムアーキテクチャーだ。

●参考：GTCの記事：自動運転、ロボット、GPUサーバーまで多様なエコシステムを体感できたGTC2019

各アーキテクチャーの特性をセキュリティやレイテンシーなどの観点から整理

このスライドでは、Zonal、Domain、Distributedの3つのアーキテクチャーについて安全性や処理能力、構成の自由度などについて整理して解説している。

3つのアーキテクチャーを実装面から整理。ベアメタルから仮想化に移行したのが現状

そしてよりコンピュータのエンジニア目線から整理したのが次のスライドだ。ここではさまざまな専用ECUによってエンジンや他の機構が制御されていたDistributedから、仮想マシンを応用したDomainに移行したところというのが現在の立ち位置と言うことだろう。

そしてその進化形としてコンテナ上にアプリケーションを実装する方法というのが次のスライドで解説された。

コンテナオーケストレーションによって車載システムを実装

この図ではコンテナをオーケストレーションすることで実装される新しいアプリケーションと仮想マシン上のアプリケーション、そしてレガシーなアプリケーションがそれぞれRed HatのIn-Vehicle Operating Systemで実行されることを示している。またデーモンを除いた軽量化、コンテナランタイムであるcrunをベースにしていることなども盛り込まれている。カーナビゲーションシステムについてはAndroid Autoを使うというのも現実的な解だろう。

より詳しいシステム概念図。systemd、Podmanなどのコンポーネントが提示されている

そして車載システムとして分散されたコンピュートノードのオーケストレーションにはEclipse BlueChiが使われることを解説した。

Eclipse FoundationのBlueChiをコンテナオーケストレーションとして利用

Eclipse BlueChiについては公式ページを参照されたい。

●参考：Eclipse BlueChi

BlueChiが複数のノードをどのように制御するのか？ については次のスライドで簡単に解説された。

BlueChiの複数ノード制御の流れを解説

どのノードもRed Hatのセキュアな車載OSであるIn-Vehicle Operating Systemが使われ、メッセージ交換にはD-Busを使うというのが主な内容だ。

そしてアーキテクチャーの違いを整理したスライドで使った表を再掲し、Zonalなアーキテクチャーと今回紹介したRed HatとGMが共同で開発したアーキテクチャーがどのように要求仕様を満たしているのかを説明した。

要求仕様に対してRed Hat/GMモデルがどのように実現しているのかを説明するスライド

次のスライドでは、このアーキテクチャーだけでは安全に関する要件が高い自動運転などについては実装できないために、ASILのレベルC及びDについてはリアルタイムOS配下のミドルウェア及びアプリケーションによって実装することが説明されている。

既存のシステムとRTOSを混在して実装したアーキテクチャー図

最後にGMとRed Hatによって最新のソフトウェア実装による車載システムが実現できると結論付けてセッションを終えた。

最後にRed HatのChibon氏に「どうしてRed Hatも参加しているAGLを使わないでBlueChiなのか？」という質問をカンファレンス後に投げかけたところ、以下の回答が返ってきた。

Red Hat In-Vehicle Operating SystemのUpstream版であるAutoSDについては2022年3月1日に公開された以下のブログを参照して欲しい。

●AutoSD：CentOS Automotive SIG Announces New AutoSD Distro

Red HatとGMはこのAutoSD/Red Hat In-Vehicle Operating Systemで車載システムの実装を目指している一方で、AGLとも協力するという言わば二股を掛けたカタチになっているが、本命はRed Hat In-Vehicle Operating Systemだろう。AGLはオープンであることが正しいというお題目を掲げているが、機能面で足らない部分もあり、実装の段階では多くの労力が必要となるという。Android Autoを使ってカーナビゲーションシステムを実装するという現実的な発想も採用しながら、安全性を高める作業をGMと進めるRed Hat In-Vehicle Operating Systemについて、引き続き注目していきたい。