Arm：SDVの実現に向けて

概要

SANJAY：ラスベガスで開催中のCES 2024の会場からお届けする、「Driving Innovation 」ポッドキャストの特別エピソードです。今回のエピソードには、Armの自動車事業担当ディレクターであるロバート・デイ氏をお迎えしています。ロバート氏には、Armの自動車分野における取り組みに加え、SOAFEEイニシアチブを通じたクラウドネイティブソフトウェア開発の実現に向けた取り組みについて詳しくお話しいただきます。ぜひお楽しみください。

議題

ロバート：ありがとうございます。まず、Sonatus 社に感謝申し上げます。CES 2024の素晴らしいブースに私たちを招いてくださり、Armとして「ソフトウェア定義車両」の実現をどのように捉えているかについて少しお話しする機会をいただきました。「ソフトウェア定義車両」については多くの議論がなされています。多くの人々が、これを実際に実現するためのさまざまな方法を模索してきました。そして、それがまさに本日お話ししたい内容です。 では、アジェンダを見ていきましょう。まず、Armとはどのような企業か、自動車分野におけるArmの役割について少しお話しします。その後、「ソフトウェア定義車両」とは何か、なぜソフトウェア定義車両が必要なのかについて掘り下げます。そして最後に、ソフトウェア定義車両の実現を可能にするものと私たちが確信している、いくつかの取り組みについてご紹介します。 まず、Armとはどのような企業かについて簡単にご説明します。当社は、基本的に半導体製品に組み込まれるIP（知的財産）を開発するテクノロジー企業です。創業から30年にわたり、かなりの成功を収めてきました。ご覧の通り、すでに非常に多くのArmベースのチップが出荷されています。また、世界人口の70％が、Armを搭載した製品を使用していると推定しています。 興味深いことに、私は自宅にあるArm製品の数を数え始めたのですが、少し難しくなってきて、途中でやめてしまいました。現在、Armはコンシューマー・エレクトロニクス・ショー（CES）で見られるような民生用デバイスから、自動車分野へと進出しており、この動きは加速しているのです。そして、それがまさに本日お話ししたい内容です。

自動車分野におけるArm

ロバート：つまり、Armは実はここ25年間、自動車業界に関わってきたわけですね。なるほど。 ほぼ創業以来ずっと、当社は車載システムに携わってきました。ただ、これまで主に「ボンネットの下」で活動してきた、といったところでしょうか。さて、ここにある統計データをご覧いただければわかりますが、IVIシステムの85％以上がArm上で動作しています。これは当然のこととも言えます。IVIシステムは、いわば民生用デバイスと同じようなものだからです。ただ、それがたまたま車の中に搭載されているというだけです。 しかし、現在では新しいADAS機能や自動運転機能が導入されるにつれ、アプリケーションプロセスの多くもArmテクノロジーを基盤に構築されています。Armでは、自動車向けに特化した製品を開発してきました。具体的には、CPU、GPU、ISP（画像信号プロセッサ）を用意しており、これらは後ほどご紹介しますが、機能安全性を重要な特徴として備えています。また、Sonatus をはじめとする素晴らしい自動車向けエコシステムも構築されています。

なぜソフトウェア定義型車両なのか

ロバート：では、なぜ「ソフトウェア定義車両」が重要なのでしょうか？まず、OEMの観点から見ると、これにより新たなビジネスモデルや収益モデル、そして顧客との新たな関係性を模索できるようになります。「ソフトウェア定義車両」という名称が示す通り、初期段階でのソフトウェア開発が極めて重要です。車には膨大な量のソフトウェアが搭載されることになるため、一度にすべてを完了させることは不可能です。わかりますか？ しかし、ソフトウェア定義車両こそが自動車業界の生き残りを左右する要素であることが分かってきています。興味深いことに、その変革の道のりはすでに始まっています。これは昨年のガートナーの予測ですが、2023年には、自動車メーカートップ10社のうち50％が、ソフトウェアアップデートを通じて新機能を提供するようになるというものです。 これこそが「ソフトウェア定義車両」の真髄であり、これらの機能をソフトウェアとして導入し、更新やアップグレードを行い、新しい機能を追加できるということです。これが、この取り組みの重要な要素の一つなのです。

SDVへの準備は整っているでしょうか

ロバート：次の疑問は、消費者として「ソフトウェア定義型車両」を受け入れる準備ができているか、ということです。そして、その対価を支払う用意はあるのでしょうか？ そこで、オーロラ・ラボとストラテジー・アナリティクスが、確か2022年に調査を実施し、消費者に「ソフトウェア定義型の機能やサービスに対して、お金を払う意思はあるか」と尋ねました。ご覧の通り、回答者のほぼ50％が、車内の追加サービスに対して月額20ドルを支払うと答えました。 これは年間で考えるとかなりの額になります。しかも、それは車両の耐用年数全体にわたるものです。中には最大50ドルまで支払うと答えた人もおり、これは実に驚くべきことです。それが1年でいくらになるか、計算する気すら起きません。

SDVに関する新たな要件

ロバート：ソフトウェア定義車両（SDV）の特徴として、従来の自動車産業には新たな要件が課されるという点があります。つまり、ソフトウェア定義の機能を先進機能として提供できる必要があります。イノベーションを推進する一方で、俊敏性も求められます。したがって、これは必ずしも自動車業界というよりは、むしろ従来のソフトウェア業界に近いと言えます。これらの機能は、更新やアップグレードが可能でなければなりません。また、セキュリティが確保され、安全性も備わっている必要があります。 最後に、スケーラビリティも不可欠です。ソフトウェア定義車両の重要な要素の一つは、それらの機能や特徴を、自社のさまざまな車種に横断的に展開できる点にあります。ソフトウェア定義の時代へと突入する中で、このダイナミクスがどのように形作られていくのか、非常に興味深いところです。

Armの自動車向け製品

ロバート：さて、Armでは先ほど自動車向け製品があるとお話ししましたが、Armには「AE（Automotive Enhanced）」と呼ばれる一連の製品ラインがあります。その中には、Cortex-A78AEという高性能CPU製品があります。これには「スプリットロック」という興味深い機能が搭載されており、これによりコアのペアをロックして、より高いレベルの安全性を実現することができます。しかし、高いパフォーマンスが必要な場合は、ロックを解除することも可能です。 そうすれば、実質的にデュアルコアとして動作することになります。これは基本的に当社のAE CPUに搭載されている機能です。また、機能安全対応のGPUである「Mali-G78AE」もあり、こちらは安全なレンダリングを実現するための興味深いパーティショニング機構を備えています。 さらに、「Mali-C78AE」と呼ばれるISPも用意されています。これらの製品はすべて、ソフトウェア定義機能の実行や、車載グラフィックスアプリケーションの実行において極めて重要であり、これらはソフトウェア定義機能の一部となります。また、ISPを活用することで、ADAS機能やその他の用途において、高精細なカメラ画像を車内に取り込むことが可能になります。それでは、SDVについて見ていきましょう。

SDVを支える4つの柱

ロバート：業界関係者と話し合う中で、SDVの実現と提供には、いわば4つの柱があることが分かってきました。その最上位と最下位に位置するのが、言うまでもなく安全性とセキュリティであり、これにはリアルタイム性が不可欠です。これらは自動車業界にとってもともと必要不可欠な要素であり、ソフトウェア定義車両（SDV）にとっても同様に不可欠です。 従来の自動車業界の規格とは別に、いくつかの標準規格が必要です。ソフトウェア定義機能については、その基盤となるAPIや標準規格が不可欠です。また、新しいソフトウェア開発手法も必要となります。 今日はこの点についてさらに詳しくお話ししたいと思います。というのも、他の業界のソフトウェア開発手法を自動車業界に取り入れる上で、これは非常に興味深いアプローチだからです。さて、極めて重要な点として――これについても後ほど詳しく触れますが――車両や車載コンピューティング環境がまだ利用できない段階でも、ソフトウェアを実行できる能力が不可欠です。 早い段階から着手し、シミュレーションなどの作業を行う必要があります。そして、最後に触れる重要な点として、業界内の連携が挙げられます。もはやこのようなサイロ化は許されません。人々は協力し合う必要があります。この問題は、1社だけで解決するには大きすぎるからです。それでは、これらの点について少し見ていきましょう。先ほど述べた鍵の一つは、新しいソフトウェア手法でした。

現代の開発プロセス

ロバート：つまり、自動車業界で今必要なのは、最新の開発プロセスを導入し、ソフトウェアの開発期間と展開期間を大幅に短縮することです。また、「環境の互換性」と呼ばれるものを実現する能力も必要です。つまり、クラウド上で開発を行い、エッジ環境に展開する場合、これら2つの環境が同じ命令セットを共有していれば、クラウドで動作するソフトウェアを車内でもそのまま実行できるようになり、非常に有益です。 この点については、後ほどもう少し詳しくお話しします。また、さまざまな半導体ベンダーにわたって容易にデプロイできることも非常に重要です。これにより、車の世代やモデルが変わる際にも、ソフトウェアの移植性を確保できます。そして、これが実際に可能にするのが「シフトレフト戦略」です。これについては、次のスライドで説明します。

自動車業界におけるシフト・レフト戦略

ロバート：この分野における従来の自動車開発は、かなり順次的な流れになっています。つまり、基本的にはまずソフトウェアとSoCを設計し、次にECUの開発を行い、最後にアプリケーションの開発を行うという流れです。つまり、一種の順次的なプロセスなのです。 これら（ソフトウェア設計やSoC、ECU）が整っていない段階では、アプリケーション開発を本格的に始めることはできません。私たちがクラウドネイティブに取り組む際、クラウドを導入します。そして、ここ（上段）にあるクラウド環境で早期にアプリケーション開発を開始できれば、これら（ソフトウェア設計やSoC、ECU）が進行している間にも、ここで実際に開発を進めることができるようになります。つまり、ここでは並行して作業が進むのです。 そして、システム統合が完了したら、それを車両に導入してテストを行う段階になります。実際には、まずここでテストと開発を行っており、車両の準備が整うか、あるいは車載コンピュータの準備が整った時点で、それを車両に導入するのです。これにより可能になるもう一つの点――ここが時間軸における「シフト・レフト」です――それは、継続的な更新とアップグレードが可能になることであり、これはソフトウェア定義車両にとって重要な要素です。 つまり、車両のユーザーに対して、新しいサービスや更新されたサービスを継続的に提供できるようになるのです。これは、OEM（自動車メーカー）と車を運転する人々との間の関係性に、非常に興味深い変化をもたらす可能性があります。というのも、現在、車を購入すると、ディーラーの敷地から車を運転して帰るだけで、その車を製造した会社とはほとんど関係を持たないからです。しかし、更新やサービスが提供されるようになれば、関係が生まれることになります。 こうして、車を運転する人と車を製造する人との間の関係は変わり始めています。では、これをどのように実現すればよいのでしょうか？

SOAFEEイニシアティブ

ロバート：そこで、数年前、私たちは「SOAFEE」というイニシアチブを立ち上げました。これは業界主導の取り組みであり、自動車のソフトウェア定義車両（SDV）向けに、クラウドネイティブなソフトウェア開発体験をもたらすことを目的としています。わかりましたか？ 私たちは、SOAFEE特別関心グループ（SIG）を立ち上げることで、この取り組みを開始しました。この取り組みでまず行いたかったのは、それを実現するためのソフトウェアアーキテクチャを定義することでした。 つまり、SOAFEEはまず何よりも、コードそのものではなくアーキテクチャの定義に重点を置いています。しかし、人々がSOAFEEを本格的に活用するためには、自動車向けのワークロードに対してこれらの新しい方法論の開発や試行を開始できるよう、リファレンスとなるソフトウェア実装が必要だと認識していました。ご覧の通り、SOAFEEの創設メンバーや運営メンバーは、自動車エコシステム全体にわたって幅広く参加しています。 つまり、OEM、ティア1サプライヤー、クラウド関連企業、そして私たちに加え、ソフトウェア関連企業も参加しています。特に、ソフトウェア開発とその統合方法に精通したRed HatやSUSEも参加しています。したがって、運営組織の構成を見るだけでも、私たちが目指す方向性が明確に把握できると考えています。SOAFEEのメンバーについては、後ほどもう少し詳しくご紹介します。

クラウドネイティブアーキテクチャ

ロバート：でも、私たちが本当に目指しているのはアーキテクチャの定義だと言ったでしょう。ここにあるように、このアーキテクチャにはクラウド関連の要素と車載関連の要素が混在しています。しかし、重要なのは実際のアプリケーションであり、ここにある要素の多くは、クラウドとエッジの間で不変、あるいは一貫性を保つことになります。 つまり、クラウド上でアプリケーションやサービスなどを開発し、それらをエッジに展開する準備が整った時点で、そのまま動作するはずだということです。そこで、コンテナやオーケストレーションといった技術を活用しています。これらはクラウドの世界で行われていることから借用したものであり、すでに十分に確立されています。 人々はすでにこれらに慣れ親しんでいます。私たちがしなければならないのは、これらを自動車業界に適した形に調整することです。つまり、機能安全、リアルタイム処理、異種混在環境でのコンピューティングといった要素を考慮する必要があるということです。これらは、クラウド環境では必ずしも存在しないものです。これが、SOAFEEが取り組む課題の一つです。

SOAFEE会員

ロバート：ここ2、3年、実はかなり充実したメンバーが集まっています。運営委員会のメンバーも、ここに見えますね。 会員数は、今や115名ほどになっていると思います。こちらを見ていただくと――おそらく見えにくいかもしれませんが――これがSonatus のロゴです。Sonatus はSOAFEEの会員です。これは極めて理にかなっています。というのも、Sonatus が主に取り組んでいるのは、ソフトウェア定義車両（SDV）だからです。つまり、クラウド・トゥ・ビークル（Cloud-to-Vehicle）ですね。彼らはこの分野の優れた専門家であり、私たちと協力できるパートナーです。

SOAFEE ワークグループ

ロバート：それでは、SOAFEEの組織体制について少しお話しします。繰り返しになりますが、どれほど分かりやすく説明できるか自信がありません。まず、AWSのビルが議長を務める運営委員会があります。また、技術運営委員会とマーケティング運営委員会があります。技術運営委員会は、実際の業務を担うすべてのワーキンググループを統括しており、その対象分野はシステムアーキテクチャです。クラウドネイティブについても検討しています。 また、混合重要度（mixed-criticality）や、今後極めて重要になると考えられるハイパーバイザー技術などの技術についても検討しています。そして、こうした成果は、SOAFEEを早期に利用できるようにするためのオープンソースとして公開しているリファレンス実装に反映されています。その他にも取り組んでいることがあります。実は、少しさかのぼると、こちらに別のタイガーチーム、つまり「ブループリント・タイガーチーム」があるのがお分かりいただけると思います。

SOAFEE ブループリント

ロバート：オープンソースのリファレンス実装を公開すること自体は良いことですが、それだけでは「よし、これからは何かやらなきゃ」と人々が自発的に動くことに依存してしまう面がありますよね。 そこで私たちが決定したのは、基本的にこれらの「SOAFEEブループリント」を用意することです。これはリファレンスアプリケーションであり、基本的にはSOAFEE環境で動作する自動車向けのユースケースを想定しています。オープンソースでもクローズドソースでも構いません。私たちが目指したのは、人々が利用できるサンプルアプリケーションをSOAFEEの世界に導入し、OEM各社が公開されているサンプルを活用して迅速に開発を開始できるようにすることです。 これらのブループリントが実際にどのような役割を果たしているのか、少し詳しく説明します。SOAFEEブループリントは、本質的に、ファームウェアやハードウェア上で動作するリファレンス実装にかかる時間を短縮するものです。そして、コンテナがあります。先ほど述べたように、SOAFEEアーキテクチャの一部は、ワークロードのコンテナ化に重点を置いています。つまり、一種のマイクロサービスアプローチです。そのため、異なるコンテナ内で異なるワークロードが実行されています。 こちらをご覧いただくと、さまざまなソフトウェア要素が確認できます。アプリケーション固有のワークロードがあり、コンテナ、オーケストレーション、場合によってはハイパーバイザー、ツール類などすべてを含むベーススタックがあります。そして、最下層にはコンピュートプラットフォームがあります。これが一般的なブループリントの構成です。それでは、具体例を挙げてみましょう。

Open AD Kit

ロバート：最初の例は、「OpenAD Kit」と呼ばれるものでした。これは、Autowareというオープンソースの自動運転ソフトウェア企業と連携したものです。そこで私たちが行ったのは、基本的にAutowareの自動運転スタックを取り込み、それを複数のコンテナに分割することでした。そして、それらのコンテナは仮想ネットワークを介して通信します。ご覧の通り、各コンテナには、マッピング、知覚、計画、車両インターフェースといった異なる機能が格納されています。 最初は、この仕組みが確実に動作することを確認するため、少し手抜きをしました。実際には、1つのコンテナ内でAutowareの完全なコピーを4つ実行していますが、その中で動作させているのはマッピング機能だけという状態です。 より本格的なマイクロサービスアーキテクチャを実現するために必要だったのは、次のことです。つまり、これらの各機能をそれぞれ独自のコンテナに移行させることで、ここではもはや自律走行スタック全体を実行しているのではなく、各機能を個別に実行している状態にすることです。そして、それが現在、このOpenAD Kitのブループリントで私たちが取り組んでいることです。 ブループリントの面白い点は――そしてこれが私たちがブループリントを作成した理由なのですが――業界の皆さんにこれらを活用していただきたいということです。OEMであれば「これができる」という事例として、あるいは他のテック企業であれば自社の技術を組み込んでさらに魅力的なものにしてほしいと考えたからです。そこで昨年、Kern Conceptという企業から、「では、これらのコンテナ化された仕組みを再検討してみよう」という声が上がりました。 そして、ここにある機能の一つ、つまり車両インターフェースは安全機能だと分かっています。これが機能しなければ、車両も機能しません。 わかりますか？ ですから、これは安全システム上で実行されるべきものです。そこで彼らが取ったアプローチは――ここを見ていただくとわかりますが――2つのシステムを用意したのです。こちら側にはAutoware関連の大部分を実行するシステムがあり、もうこちら側には安全機能、つまり基本的に車両インターフェースを実行するシステムがあり、その間には仮想イーサネットではなく、実際の物理的なイーサネット接続が設けられています。 これは、コンテナ化されたマイクロサービスを採用するというのと同じ概念ですが、ここでは異種ネットワーク、つまり異種システム上で実現しています。ご覧の通り、安全関連の処理はこちらの側にあり、この場合はNXP製の安全用マイクロプロセッサ上で実行されます。そして、こちらの側には、必ずしも同じレベルの安全性を必要としないアプリケーションプロセスが配置されています。

SOAFEEの対象プラットフォーム

ロバート：プラットフォームといえば、もうひとつ必要だったのはハードウェアプラットフォームです。マップ上では見えませんが、当社の半導体パートナーの多くがSOAFEEのメンバーとなっています。そして現在、私たちが本当に目指しているのは、彼らにそれぞれのプラットフォームを提供してもらうことです。 それらのプラットフォーム上で、SOAFEE、つまりSOAFEEのリファレンス実装を動作させるのです。ご覧の通り、ルネサスやNXP、マーベルといった企業が参加しています。また、AWSからのネイティブクラウドインスタンスもあります。つまり、ArmベースのプロセッサであるGraviton上で、クラウド内のベアメタル環境でSOAFEEを実行できるということです。さらに、自動車向けではない、興味深い開発者向けプラットフォームもいくつか用意したいと考えていました。 そこで、「Turing Pi」や「Raspberry Pi」を採用しました。実際、昨晩開催されたCOVESAイベントでは、Raspberry PiもSOAFEEを実行していたシステムの一つでした。さて、以上がSOAFEEの概要です。

参加方法

ROBERT: もし興味があって参加したいなら、SOAFEE.ioにはかなり多くの情報が掲載されています。 Slackのチャンネルもありますし、LinkedInにもSOAFEEのページがあります。参加をご希望の場合は、おそらく私に直接ご連絡いただくのが一番良いでしょう。Robert.Day@arm.com までご連絡いただければ、メンバー登録のお手伝いをさせていただきます。以上がSOAFEEについてです。私たちは、これがソフトウェア定義車両（SDV）の実現に向けた非常に興味深い取り組みだと考えています。 注意深く聞いてくださった方ならお気づきかと思いますが、他にも「ソフトウェア定義車両」の実現を支援しているコンソーシアムがいくつか存在します。しかし、各団体はそれぞれ独自の世界で、独自の役割を担っているため、全体像が必ずしも明確ではありません。では、これらはいかにして一つにまとまるのでしょうか？そこで昨年3月、私たちもその一助となるべく取り組むことを決めました。

SDVアライアンス

ロバート：そこで、私たちは新たなアライアンスを結成しました。このアライアンスは昨日発足したばかりです。これは、SDVの実現を目指している4つの組織による、いわば「新たな協力関係」の始まりと言えます。まず、おそらく最も歴史が長い……いえ、最も成熟したコンソーシアムであるAutosarがあります。 次に、かつてGENIVIまたはGEN IVIと呼ばれていたCOVESAがあります。さらに、Eclipse SDVとSOAFEEも参加しています。そして私たちが取り組んでいるのは、これら異なるコンソーシアム間の連携を促進することです。つまり、コンソーシアムのコンソーシアム、あるいは「連携の連携」といったところでしょうか。 これら4つの組織だけでも、500社を超える自動車エコシステム企業が、これらの異なるコンソーシアムに関わっています。これによって実現されること、そして私たちがこのアライアンスとして行おうとしていることは、これらがいかに相互に連携するかを明確にすることです。実際、昨夜の立ち上げイベントでは、これが実現可能であることを示すデモンストレーションとして、各コンソーシアムのシステムの一部を連携させて動作させる様子を披露しました。 これにより、クラウドからエッジまで、コネクテッドカー、オープンソース、オープンスタンダード、リアルタイム処理、そして安全性が、すべて一つのパッケージとして統合されることになります。目標は、これを正しく実現できれば、OEM各社がソフトウェア定義車両（SDV）の開発や展開を行う際の負担を大幅に軽減できるということです。さらに、これによってコラボレーション、より一層の協業が促進されるでしょう。 単なるサイロ化されたコンソーシアム間の協力ではなく、真の意味での連携です。このアライアンスの設立と協業に取り組んできた過去9ヶ月間は、実に興味深い道のりでした。発足した今、本格的な活動が始まります。ですから、今後このアライアンスからどのような成果が生まれるか、ぜひ注目していただきたいですね。繰り返しになりますが、アライアンスへの参加をご希望の場合は、参加組織のいずれかにご連絡ください。 最後に申し上げたいのは、これはオープンなアライアンスだということです。他のコンソーシアムも参加してくれることを期待しています。私たち4団体だけにとどまりません。私たちはまずスタートを切りましたが、他のコンソーシアムにもこのアライアンスや業界全体の共同取り組みに参加するよう呼びかけています。そして、昨夜2社のOEMと話をした際にも聞いた通り、彼らがこれを高く評価していることを私たちは確信しています。 ですから、これが「ソフトウェア定義車両」への道のりの、真の意味での素晴らしい第一歩となることを期待しています。すでに動き出しているとは言いましたが、本格的な実現に向けて私たちが取り組むべき課題は山積みです。そして、コンソーシアムのすべてのメンバーが一丸となり、協力してこれを現実のものにしてくれることを願っています。このスライドは飛ばしましょう。

結論

ロバート：それでは、この場を借りてお礼を申し上げます。Sonatus の皆さまには、このようにソフトウェア定義車両の素晴らしい技術についてお話しする機会をくださったことに、改めて感謝申し上げます。また、オンラインでご覧の皆さまにも、この動画を楽しんでいただければ幸いです。ありがとうございました。