クルマとクラウドについて

記事をシェアする:

こんにちは。IBM Cloud Platform Technical Sales坂田です。
自動運転、EV(電気自動車)など今後進化をつづけるクルマにクラウドの技術をどのように役立てるかをテーマに話を進めていきます。

はじめに　〜　車載システム要件

現在の車載システムの複雑性はボーイング旅客機に搭載されるソフトウエアの複雑性を上回る(コード行数が多い)といわれています。多くの機能コンポーネントで構成される複雑なソフトウェアソリューションをセキュアかつ管理 された方法で提供したい場合、最初に考えるのはクラウド・ネイティブ技術を活用してアプリケーション開発をすすめることです。クラウド・ネイティブ環境には、コンテナー,マイクロサービス,DevOpsをはじめとしてアプリケーションの開発、導入、ライブ更新の複雑性を軽減し品質を高めるための、有用な多数のテクノロジー、ワークフロー、デザインパターンがあります。
ただ車載アプリケーションの開発には、コンテナが一般的に利用されている企業用やスマートフォン用のアプリケーション開発では検討されてこなかった特有の課題があります。車載ワークロードには、一歩まちがえると人命に関わる事故にも繋がりかねないため、特に安全性とリアルタイムの要件が厳しく求められます。
安全性要件については車載電子システム向けの国際安全規格ISO-26262 仕様ではASILと呼ばれる安全水準が定められ、車載ソフトには ASIL(Automotive Safety Integration Level)のインテグリティ・レベルに達しているなどの条件が課されて安全認証を取得したコンパイラやツールをクラウドベースのツール・フレームワークに組み込む必要があります。
リアルタイム性に関して、一例をあげると自動運転処理は、データを収集する(センサー)、認知/判断する(コントローラー)、操作する(アクチュエータ)サービスと解釈されます。 飛び出してきた歩行者を認識してブレーキアクチュエーターを操作する処理は、一刻の遅れも許されないリアルタイム性が求められます。
さらに車載アプリケーションの開発プロセスには、クラウド上でアプリをビルド/テスト/デプロイするだけでなく、以下のようにSiL(Software In Loop),HiL(Software In Loop)検証テストも考慮する必要あります。シミュレーターを使いSIL検証実施したあとに一部の機能(入出力のテストなど)は、組み込みシステムの物理的な性質に関連するためハードウェアでの検証が必要になり物理的な ECU に導入し、HiL 検証を実行します。その後、車に導入して道路上での実地の走行テストが開始されます。 DevOpsプロセスには自動車の試験／検証にターゲットを定め、クラウドや研究所での開発、車載テスト走行などに至るまで、幅広く網羅する必要があります。

今日は車載ソフトにクラウド・ネイティブ技術を適用するアーキテクチャーを紹介しますが、理解をスムーズにするため最初にSDVについて簡単に触れます。

SDV(Software Defined Vehicle)について

SDVはSoftware Defined Vehicleの略語でソフトウエアにより規定/管理されたクルマを指し、下記がその全体概要を表した図です。

最も厳しい安全基準を求められるASIL-Dのアプリケーションは通常RTOS(リアルタイムOS)上で稼働します。RTOSは、決定性操作によりアプリ応答時間を保証するもので、代表的なものとしてVxWorks(WindRiver社), QNX(BlackBerry社)等が挙げられます。
近年進化をとげる車載情報機器/IVI (In-Vehicle Infotainment :車載インフォテインメント)は、その多くが安全水準がQM(“品質管理”の仕組みで対応できる領域)であり GPOS(General Purpose OS:汎用OS)と呼ばれるLinux OS, Android 等が利用されます。後ほど紹介するRHIVOS(Red Hat In-Vehicle OS)もこのカテゴリに含まれます。ADAS(Advanced Driver Assistance System:先進運転支援システム)/AD(Autonomous Driving)アプリケーションには機能安全水準ASIL-B/Dの双方に対応するものがあります
上記安全要件の異なる複数ワークロードの同時実行/隔離性を担保するにはHardware層での実装による統合ECU(Electronic Control Unit)以外にHypervisorやContainerを使うケースが考えられます。
またクルマは5G/MEC等の低遅延のネットワーク経由でクラウドに接続します。
OTA（Over The Air）によるソフト更新アップグレードを可能にする他、クラウド上では車と接続/連携する様々なサービスを提供します。
Connected Serviceは、繋がる車からビッグデータを収集し(Vehicle Data Lake)、地図や天気、その他外部ソースからのデータと統合/分析して、地図表示・地点検索・交通情報・ルート案内などの位置情報サービスや運転者補助サービスを提供するものです。また物理的な車載システムをクラウド上でシミュレートするDigital Twinもここに含まれます。

Red Hat In-Vehicle OS (RHIVOS)について

２０２１年４月にRed Hat社よりRed Hatベースの車載Linux OSが発表されました。主要SoC(System On Chip)のリファレンスボード上で動作するOSを順次リリース予定です。GM(General Motor)社が2023年リリース予定のUltifi プラットホームにてRHIVOSの採用検討を進めると発表がありました(2022年5月)

-OSS(オープン・ソース・ソフトウェア)に関して
RTOSに比べてLinuxをベースとしたOSであり、OSSコミュニティによる開発/保守ベースなので透明性が高く、開発者が多い、ツール豊富でアプリ開発の柔軟性が高い、各種オープン化推進コミュニティ団体とも連携しており、実際はLinux Foundation 配下のELISAにて安全性基準に関するOS要件を抽出して、CentOS Stream Automotive SIGにて自動車関連のOSSを作成した後に商用版Red Hat In-Vehicle OSが完成します。

-安全性要件について
レッドハットはExida社とともに現在車載システムの機能安全に関する国際規格ISO26262認証取得に向けた準備を進めています。製品リリース時には安全要求レベルASIL-Bをサポートした 初のLinux車載OSとなります。機能安全はOSのリリース時のみならず、ソフトウエア・アップデート等のイベントの際においても継続的 にサポートされます

-ユースケースについて
最適なユースケースは統合コックピット、IVI、ADAS、セントラルECUのゲートウェイ機能等です。特に統合コックピット、セントラルECUといったミックスト・クリティカリティ(異なる安全性要件のワークロードの混在)が必要とされるユースケースに向いています。

-統合コックピットにおけるミックスト・クリティカリティーについて
統合Digitalコックピットで使用する場合、メータークラスター(機能安全ASIL-Bが要求される領域)とIVIインフォテインメント(安全性との関連なく,適切なQM「品質管理」の仕組みで対応できる領域)とが独立して稼働しているのでIVIがクラッシュしてもメーター・クラスター側に影響がでない、つまり隔離性が担保されます

クラウド・ネイティブ技術の活用について

次に車載ソフトに利用されるクラウド・ネイティブ技術を解説します。

コンテナとは、アプリケーション コードに、ソフトウェア サービスの実行に必要な特定バージョンのプログラミング言語ランタイムやライブラリなどの 依存関係を加えた軽量のパッケージを指します、コンテナは車載ソフト向きといわれます。その理由として1.ポータビリティに高く、クラウド/エッジ(クルマ)間や異なる車種間の異種プラットホーム上でのアプリ稼働を容易にする2.隔離性を有しており異なる安全性要件もつアプリの分離が可能(安全基準が低いアプリ障害がより高いアプリに影響を与えない)3.軽量である(必要システムリソースが小さい) 4.システム不変性(Immutable System)の特質から頻繁にソフトウエア更新しても安定性が担保できる。これは近年のIVIではOSSが多く利用されており今後OTA アップグレードが頻繁におこなわれるようになるので特に重要です。
マイクロサービスはアプリケーションを明確に定義されたインターフェースで単機能モジュールに分割することを言いますが、この疎結合により1つのアプリの変更がシステム内の他アプリに影響を与えないので、個々のアプリ試験と統合テストを分離できるとともにアプリ単位の開発・リリース・保守が容易に行えます。大規模・複雑アプリケーションの開発期間の短縮、コスト削減だけでなくソフトウエア品質向上にも寄与します。
クラウド・ネイティブ・システムで必須となるコンテナ・オーケストレーターは、「Kubernetes（K8s）」がデフォルトの業界標準になりつつありますが車載では、「Lightweight Kubernetes（K3s）」が、フットプリントが小さいため、組み込み環境やリソースに制約のある環境などに適していると言われ候補の一つになるでしょう。

車載で利用されるコンテナ・オーケストレーターはクラウドで通常利用されるロード・バランサーやスケールイン/アウトの機能より、むしろ車載ソフトウェアの安全性とリアルタイム要件を実現するサービスのデプロイメント、デバイス/ネットワーク構成管理、モニタリング管理等に焦点が当てられます 。
デプロイメントについては組み込みハードウェアシステムの能力を理解し、最適な形でマイクロサービスを導入できることです。 アプリケーションプロセッサー、リアルタイムプロセッサー、各種のアクセラレーターが混在する環境において ワークロードの安全性/リアルタイム要件を理解して最適な方法で最適なプラットホームにデプロイすることが求められます。 ASIL定義などの車載ソフトウェアのランタイム要件をコンテナ・オーケストレーターのManifestで記述するのが最適解となり、これに合わせてコンテナのランタイムの拡張も必要となります。
構成管理については車載分野特有のSoC(System On Chip)内/外の通信、Ethernet以外のCAN/LIN/FlexRay等への接続、高帯域幅 I/O Deviceへのアクセス/制御などです。アプリのポータビリティをより高めるためにはHypervisorレベルで標準VirtIO等に対応することが望まれます。
モニタリング管理についてはリアルタイム性の高いアプリについてのHealth Check,、ワークロードFailure/Fail Over、リソース制約の高いSoC上のアプリのメモリー利用率監視等が必要です。最終的には車載アプリのIO帯域幅や実行時間の保証を実現することが望まれます。

クラウドネイティブのワークフローであるDevOpsは、開発ワークフローと導入オペレーションが結合されています。この2つの分野を定義／管理された手法で組み合わせることにより、開発／導入の一元化や、アプリケーションの継続的な改善を実現することが可能です。
クラウド上ではGit HUBからダウンロードしたソースのビルド/テストからサーバーへのデプロイまでで完結しますが、その後のSIL統合テスト〜HIL検証〜実地走行試験へと対象が拡がります。そのさい異種環境からくるクロスコンパイルやエミュレーション(最適化チューニング等)を不要にして、車載ソフト開発者が一気通貫でシームレスに開発/テスト/デプロイするためのDevOpsプロセス設計が求められます。
将来的には、DevOpsによりサイバーセキュリティや、OTAによるバグ修正、機能的なソフトウェアアップデートを含めた自動車コンポーネントのライフサイクル全体にわたって車載ソフトウェアを管理することが重要になってくるでしょう。

また今後は車載ソフトへのコンテナ活用を普及させEcosystemを拡大するためにOCI(Open Container Initiative)等のコンテナ標準化推進団体との連携も重要になっていきます。

SOAFEEについて

半導体チップの設計メーカーであるARM 社は、SOAFEE (Scalable Open Architecture for Embedded Edge)プロジェクトを発表しました。クラウド・ネイティブなフレームワークを利用した、リアルタイムに動作し、安全性に配慮したオープンなソフトウェアアーキテクチャおよびリファレンスソフトウェア実装と定義しており、クラウドネイティブな技術と自動車の機能安全およびリアルタイム要件を組み合わせて車載ソフト開発することを目指すものです。このオープンソースのリファレンス・プロジェクトは、クラウド上で車載ソフトウェア開発向けのフレームワークとして提供され、組み込み車載コードとして展開されます。
SOAFEEフレームワークはプロセッサの違いを吸収する仕組みになっており、今後はARM以外のCPUも順次リリースしていく見込みです、またこの上で稼働するソフトウエアの互換性についても、主要な業界標準ソフトウエア・アーキテクチャーであるAUTOSAR(車載ソフトウェア・プラットフォーム標準仕様) Autoware (オープンソースの自動運転用オペレーティング・システム)等にも対応することを唄っています。
自動車メーカーはその上で走るカーナビゲーションなどIVI向けソフトウエアや、HMI(Human Machine Interface)、ADAS/ADを実現するアプリケーションソフトウエアなどを開発していくことになります。SOAFEE SIGメンバーとしてToyota, VW(VOLKSWAGEN)、欧州TIER1サプライヤーのBOSCH、ContinentalまたRedHat社等も賛同しています。

以下がSOAFEE Architecture 全体概要図になります。

コンテナを管理するオーケストレーターの機能を拡張し、リアルタイム処理や機能安全に対応すべきコンテナ／マイクロサービスを区別するほか、必要に応じてリアルタイムOSを割り当てることによりさまざまなASIL レベルのアプリケーションの同時実行がクラウド,クルマの双方で可能になります。これによって、リアルタイム処理や機能安全への対応といったミクストクリティカリティーを考慮した車載ソフトの稼働を実現できるといわれています。(図中Mixed Criticality Aware Orchestrator, Mixed Criticality Aware Platform Feature Discovery)
SOAFEEのリフファレンス実装のEWOAL(Edge Workload Abstraction and Orchestration Layer)では車載ソフト開発者向けにクラウドから車載エッジまで一貫性のある開発環境を提供するものです。ソフトウエア単体だけでなく組み込みOS(現時点ではYocto-Linux Distribution) UPのソフトウエア・スタック 全体のクラウド上での実行を可能にします。クロスコンパイル,エミレーションは不要になり、このソフトウエア・スタックのクラウドから車載エッジへのポータビリティが確保できます。これにより、クラウド内で文字通り車載ソフトの作成/テストが開始でき、クラウドの拡張性を利用して(膨大なシミュレーションデータをインプットにした多数のSIL検証シナリオの並行稼働により)テスト対象範囲を大幅に拡充でき、車載ソフトの開発期間の短縮に貢献できます。

おわりに

SDVの流れは、本稿で紹介したCloud Native技術適用によるテクノロジー面での影響にとどまりません。
そのアーキテクチャーは機能単位に”MCU(Micro Control Unit)/組み込みSWから構成されるモノシリックなサイロ型”から　統一された”プラットホーム/OS/ミドルウエア/アプリの水平レイヤー型”へ進化を遂げ、ビジネスモデルはOEMを頂点とするTIER1/TIER2/TIER3サプライヤーから成る階層型からOEMを中心として各サプライヤーやプラットホーム/ソフトウエアメーカーが水平型に繋がるEcosystemモデルに移行します。これは日本特有のOEMをトップとするピラミッド型産業構造(TIER1/TIER2/TIER3)に見直しを迫るものです。自動車業界は裾野が広い産業ともいわれ、日本経済・地域雇用に与える影響もはかりしれないものがあります。

自動車業界が10年に一度の変革期にあるといわれる所以です。

参考資料/文献

SOAFEE GITLAB
https://gitlab.com/soafee
SOAFEE
https://www.soafee.io/
ARM
https://www.arm.com/

自動車の未来を切り拓くーRed Hat In-Vehicle Operating System
https://www.ibm.com/events/reg/flow/ibm/vkblrvmb/attendee-portal/page/attendee-portal?grant_id=3615f291-1c70-4f19-b20f-dc885fe5bf7b
新たな標準：最新および将来の自動車における Red Hat In-Vehicle Operating System
https://www.redhat.com/ja/blog/new-standard-red-hat-vehicle-operating-system-modern-and-future-vehicles

車載半導体におけるデジタルトランスフォーメーション
https://jasa.or.jp/dl/bizmatch/20211027-1-Kajimoto.pdf
安全性と快適性を両立する自動運転向け車載ユニット(日立評論)
https://www.hitachihyoron.com/jp/archive/2020s/2021/05/05c01/index.html

Virtualizing Mixed-Criticality Systems: A Survey on Industrial Trends and Issues
https://arxiv.org/pdf/2112.06875.pdf

SDV(Software Defined Vehicle)のE/Eアーキテクチャーについて
https://qiita.com/nori0315/items/406c30c0b33d00f7d84f

坂田　直紀
日本アイ・ビー・エム株式会社
クラウド事業本部
テクニカル・セールス