メインコンテンツへスキップ

The Garage ポッドキャスト:シーズン1 第6話

現代の自動車におけるクラウドの役割(第2部)

AWSの自動車部門に所属するステファノ・マルザーニ氏との対談

AWSのソフトウェア定義車両(SDV)担当WWテクニカルリード、ステファノ・マルザーニ氏をゲストに迎えた2部構成のエピソードの第2部です。本編では、プロトタイピング、機械学習/AI 、およびADAS/自動運転について議論します。

音声のみのバージョンを聴く:

エピソードの文字起こし | 現代の自動車におけるクラウドの役割(第2部)

概要

ジョン:本日の「The Garage 」では、自動車向けクラウドコンピューティングをテーマにした2回シリーズの第2弾をお届けします。今回の特別ゲストは、AWSのステファノ・マルザーニさんです。第1弾では、クラウドコンピューティングにおけるデータとコンピューティングの側面についてお話ししました。今日のエピソードでは、その続きとして、プロトタイピング、データ分析、AI 、そしてADASや自動運転におけるクラウドの活用について取り上げます。それでは、AWSのステファノ・マルザーニさんとの対談を続けましょう。さあ、始めましょう!

トピック3:クラウド上でのプロトタイピングと「環境の同等性」

ジョン:実は、その話から3つ目のトピックである「プロトタイピング」へと、絶妙な流れですね。先ほども触れましたが、私たちは最近ロバート・デイ氏と話をしたのですが、Armでは、Armアーキテクチャが車内の幅広いサブシステムに採用されつつあるとのことです。ご存知の通り、私はArmで14年間働いてきたことを誇りに思っています。ですから、この話題には少し特別な思い入れがあります。ロバート氏もそのことについて多く語っていました。 しかし、それは同時に――これはあなたがおっしゃっていたポイントの一つだと思いますが――Gravitonがクラウドに存在し、クラウド上にArmベースのインスタンスがあること、そして車内にもArmベースのインスタンスがあることが、プロトタイピングにおいて非常に興味深い可能性を切り開くということでもあると思います。

ステファノ:その通りです。 これを「環境的パリティ」と呼んでいますよね?この用語を使い始めたのは、2021年のArm Dev Summitカンファレンスでした。私たちが発表したワークショップは、業界内でかなり大きな反響と注目を集めました。このコンセプトを初めて提示した際、「なぜクラウド上のArmアーキテクチャを使って、自動車で動作しているのと同じArmアーキテクチャ上で動作するソフトウェアを実行できないのか?」という問いを投げかけたのです。 同じArmアーキテクチャとはいえ、同じプロセッサというわけではありません。Gravitonを車に搭載するつもりなど、全くありませんよね? 実際に車に搭載されているECUは、Qualcomm、Nvidia、NXPなど、様々なサプライヤーから供給されていますが、これらはすべてArmコアをベースにしています。そして、そのArmコアは、Gravitonに搭載されているコアと全く同じものです。そうでしょう? ARM 64に関して言えば、もちろん厳密には同じCPUではありません。当社のGravitonはNeoverseアーキテクチャに基づいているのに対し、自動車では多くの場合Cortexが採用されていますが、命令セットの大部分は同じです。

クラウドおよび車載環境におけるARMプラットフォームでの実行

ステファノ:それがロードできる理由なんです。このアイデアを思いついた後、実際に実現しました。その結果、従来はエミュレーション環境や物理ハードウェアでしか動作しなかった多種多様な組み込みOSが、今ではAWSクラウド上のGravitonでネイティブに動作するようになりました。 QNX、VxWorks、Yocto Linux、AGLといったシステムです。組み込み開発者にとっては新たな開発手法であり、驚くほどの反響をいただいています。正直なところ、彼らも「えっ、待って、クラウド上でこのプロセスを起動しただけなのに、目の前にQNXのプロンプトが表示されている。まるでECUを使っているみたいだ」と、驚いているほどです。 ええ、まさにそれが私たちが「環境の同等性」と表現しているものです。そこで作業を開始できます。ハードウェアは必要ですが、開発を始めるために必ずしも必要というわけではありません。

クラウドでのソフトウェア開発を始めましょう

ステファノ:それは現在、この業界にとって大きなボトルネックであり、プロトタイピングの観点からも重要な問題ですよね? 開発者、特に優秀な開発者が作業するためのハードウェアを常に必要としている場合、需要を満たせるハードウェアが存在しない以上、低コストのイノベーションを活用せざるを得ないでしょう。

ジョン:もちろん。 そして、テストの観点から言えば、回帰テストについてです。以前のエピソードでも触れましたが、私たちもクラウドベースでのテストを開始しました。つまり、ラックに並んだシステムを遠隔で電源のオン・オフを繰り返す代わりに、仮想インスタンスやEC2を利用できるようになったのです。私たちもその方式を採用しています。そのメリットを実感しており、現在、それを積極的に活用しています。

自動車分野における検証の難しさ

ステファノ:うん。うん、その通りだね。これもまた、開発者にとっても、検証段階にとっても、大きなメリットだよね? 考えてみてください。それでも、今の自動車は、文字通り、十分にテストされていないシステムなんです。これは歴史的な理由によるものです。このエピソードの冒頭でもお話しした通り、自動車は現在、現代の内燃機関車に搭載されている150個以上のECUで構成されたシステムから、統合されたコンピュータを備えた、30個や40個といったはるかに少ない数のECUで構成されるシステムへと、大きな変革を遂げつつあります。 センシングやアクチュエーションのためのマイクロコントローラベースの周辺ユニットは依然として存在します。しかし、大規模な演算処理は、8、12、16、40といった多数のArmコアを搭載した、極めて統合されたアーキテクチャによって行われるようになるのです。これは非常に重要なことですよね? 極めて重要なトレンドなのです。

クラウドを通じて開発者の力を引き出す

ステファノ:開発者に、これらのユニットを机の上に置いて作業することを期待することはできません。すでに述べた理由から、開発者にはクラウドネイティブな環境を提供する必要があります。なぜなら、そこにはデータがあり、コンピューティングの選択肢があり、Gravitonがあるからです。つまり、開発者がツールを探し、作業を行い、ハードウェア上にデプロイし、ハードウェア上でテストを継続できるのは、その環境こそが自然な場であり、その逆は成り立ちません。

今後5年間で、自動車用ソフトウェアの市場規模は3倍に拡大する見込みだ

ステファノ:だって、ハードウェアから着手してしまえば、イノベーションは殺されてしまいますから。ご存知の通り、SDV分野では、一部のアナリストの予測によると、今後5年間でコード量が1億行から3億行へと3倍になると見込まれています。それでもなお、開発者にハードウェアを使って自動車用コードを作成することを期待して、どうやってその目標に到達できるというのでしょうか?

ジョン:うわっ、それはすごい数字だね。その統計は初めて聞いたよ。今後3年間で3倍になるってこと?

ステファノ:5年。

ジョン:それはすごいですね。そういえば、私も考えていたんですが、ここには好循環もあるような気がします。以前のエピソードでワークロードの統合について話し合いましたし、先ほどもその点に触れていましたよね。また、仮想化の重要性や、これらのアプリケーションを並行して実行しつつも互いに干渉しないようにすることについても議論しました。 このクラウドプロトタイピングのアプローチと仮想化は、かなり相乗効果が高いように感じます。というのも、そこで試したのと同じワークロードを、今度は並行して共存させることができるからです。そして、あなたが言及していた「環境の均一性」というアプローチにも、非常に近いものだと思います。

ステファノ:ええ、その通りです。まったくその通りです。改めて考えてみれば、12コアや16コアといったプロセッサを使うようになったとき、それらすべてを単一のOSだけで使い切ることはありません。つまり、これらのコアを分割して、複数のOSを実行する必要があるということです。 しかし、これはまさにクラウドで行われていることそのものです。Gravitonプロセッサの64コア上で、ハイパーバイザーが複数のOSを管理していますよね。まったく同じ仕組みです。もちろん、電子機器の認定やその他多くの点では異なります。しかし、ソフトウェア工学の観点から見れば、2つの環境を非常に近い形で実現することが可能です。

ジョン:つまり、プロトタイピングやテストの段階で、最終的な実装においてどのように機能するかがほぼ実証されるわけですね。これはとても興味深いことです。これは、私にとって非常に魅力的で、技術的にも非常に興味深く、開発ツールとしても非常に強力なものだと思います。

設計サイクルを加速させる「シフト・レフト」

ジョン:それに、ご存知の通り、以前も話しましたが、数年前から「シフト・レフト」という考え方、つまり仮想プロトタイピングやクラウドなどを活用して設計サイクルを加速させる方法について注目が集まっています。また、最近のエピソードでも取り上げましたが、設計サイクルに対しては「より迅速に設計せよ」というプレッシャーがかかっており、OEMやティア1サプライヤーにとっての競争環境はますます厳しくなっていると思います。 こうした取り組みによって設計サイクルを短縮できれば、競争力を高め、コストを削減できるだけでなく、あなたが話していたようにソフトウェアの行数が増加しているという、その膨大な複雑さを実際に管理できるようになると思います。それを実現するには、「分割統治」の原則を適用する必要があるでしょう。そうでなければ、それを巨大なモノリシックなシステムとして捉えてしまうと、検証は不可能になってしまいます。

自動車のリコールにより400億~500億ドルの損失

ステファノ:その通りです。他にもメリットはあります。ですから、間違いなく「シフトレフト」ですね。テストのスケールアウトが可能になるため、コードの品質が向上します。これは間違いなく、非常に、非常に重要なことです。 自動車業界で考えてみてください。今でも、リコールによる損失は毎年400億~500億ドルにも上ります。その70%はソフトウェアの不具合が原因です。報告された事例の70%がそうです。考えてみてください。これは品質が低いということになるのではないでしょうか?そう言ってもいいですよね?

ジョン:うん。

ステファノ:テストが不十分だ。

ジョン:その通りです。

ステファノ:シフトレフトじゃない。

ジョン:うん。

ステファノ:そうですよね?つまり、左シフトすることで、コストを削減し、品質を向上させるわけです。でも、エンドユーザーについても考えておきたいですね。というのも、実際に見られるのは、開発のためにこれらのECUを各所に送り回す必要がなければ、クラウド上でのコラボレーションが可能になるということです。これは非常に重要です。実際、SDVの驚くべき点の一つですね。先ほど、テレマティクスやテレマティクスサービスに基づくADAS/AVサービスについて話し合いました。

クラウドを活用した車載HMIの開発

ステファノ:クラウド上でのHMI(ヒューマン・マシン・インタラクション)、ユーザーインターフェース、ユーザーエクスペリエンスの開発が飛躍的に増加しています。私にとっては、これは素晴らしいことです。その理由もすぐにわかるでしょう。 その理由がわかるのは、初めてクラウド上に仮想ECUが実現し、ブラウザ上でユーザーインターフェースを表示できるようになったからです。クラウドは世界中に展開されているため、私はすぐに世界中の協力ネットワークの全員にそれを提示することができます。だから、日本の同僚や南アフリカの同僚に、「現地の好みに合わせて、私の新しいユーザーインターフェースについてどう思うか?」と尋ねたり、「これを調整できるか?」、「手直しできるか?」と依頼したりできるのです。

ジョン:それから、ローカライズや言語についても。

ステファノ:HMIシステムの開発方法において、文字通り革命的な変化です。あちこちにハードウェアを設置する必要がなくなり、いわゆる「クラウドネイティブ」「クラウドファースト」というアプローチでHMI開発を行うことになるからです。すでにこの手法の導入を試みているお客様もいらっしゃいます。 また最近、ベルリンで開催された前回のAWSサミットで、BMWと共同で、クラウド上でのHMI開発プラクティスに関する非常に興味深いプレゼンテーションを発表しました。もちろん、その資料もご提供可能です。素晴らしいデモンストレーションでした。とはいえ、常にBMWの事例ばかりを挙げるわけではありません。例えば、CESでマレリ社と共同で行ったデモについてもお話しできます。マレリ社はティア1サプライヤーです。 同社は当社のブースで、初のクラウドネイティブHMIシステムを披露しました。これは非常に素晴らしいものでした。なぜなら、私たちがクラウド上でHMIアプリケーションを開発し、イタリアのミラノにデプロイしている様子が見て取れたからです。あるエンジニアがクラウド上で開発を行い、その後、ラスベガスのブースにデプロイしたのです。繰り返しになりますが、クラウド開発から始め、特定のハードウェアソリューション上でデプロイとカスタマイズを行う、という流れですね。 考えてみれば、これは本当に、本当に強力な仕組みです。単に強力というだけではありません。これはSDV(Software-Defined Vehicle)ですよね? ソフトウェア定義なのです。そうでなければ、ハードウェアから始めればハードウェア定義になります。真にソフトウェア定義であるためには、ソフトウェアから始め、その後でデプロイする必要があります。

SDVはリコールコストを削減できる

ジョン:その通り、その通りです。今、本当にたくさんの点に触れてくれましたね。特に、リコールについておっしゃっていた点は、ぜひ見逃したくないと思います。 ソフトウェア開発の負担が大きいOEMからは、「このソフトウェア定義の車両機能を導入するのは難しすぎる」という懸念をよく耳にします。確かにその通りですが、先ほどおっしゃったように、400億ドル、500億ドルという数字を考えると、その多くはソフトウェア関連のものです。数十億ドルの節約につながる可能性があるのに、それに対応する機能を導入しないなんて、正気の沙汰ではありません。

ステファノ:ええ、コンティのマーティン・シュタム氏をゲストに迎えた『All Things Automotive』の回はとても素晴らしい内容でした。

ジョン:ああ、そのエピソード、見たよ。

ステファノ:ああ、それ見た? なぜそうなるのか、彼が説明しているところだよ、ね?

ECUの統合

ステファノ:従来、メーカーやOEMは、新しい機能を統合する必要に迫られていました。つまり、「よし、ECUをもう1つ、もう1つ、さらに1つと追加していけば、最終的には150個になる」というわけです。しかし、その組み合わせによる影響を考えると、これらすべての要素が組み合わさったあらゆるケースを網羅的にテストすることは不可能です。 だからこそ――そしてこれは業界にとって良いことなのですが――電動化やその他のトレンドに後押しされて、変化が進んでいます。あの有名なCASE、つまりコネクテッド(Connected)、自律走行(Autonomous)、シェアリング(Shared)、電動化(Electrified)、そしてユーザー体験(User Experience)です。こうした統合が進んでいるのです。

無駄な機能を追加せずにソフトウェアを効果的に統合する

ステファノ:正直なところ、この分散システム全体に散在しているソフトウェアを変換し、これらの一元化されたユニットに統合することこそが課題ですが、これは業界にとって恵みでもあります。しかし、ここで「しかし」があります。単に「よし、このECUにソフトウェアがあるんだから、それをそのまま一元化されたユニットに放り込めばいい」と言うだけではいけないからです。 それは「ブロートウェア」です。爆発寸前だと言っても過言ではありません。統合ユニットは、コスト最適化された単一のECUとは根本的に異なるため、システムのアーキテクチャを再構築する必要があります。リソースの観点から見ても、そこに搭載されているソフトウェアは、その「ほぼカスタム」なハードウェアのために特別に設計されたものなのです。 だからこそ、こうした事例が数多く見られるのです。皆さんもご存知の通り、例えば私たちがAutoware Foundationと共同で取り組んだOpen AD Kitのプロジェクトでは、自律走行用のソフトウェア――これは従来、いわゆる「モノリス」と呼ばれる単一構造でした――をマイクロサービスに分解し、より高いモジュール性と柔軟性が求められるハードウェア・ソフトウェアプラットフォームに対応できるよう、アーキテクチャを再構築しました。 差分更新、ですよね? インターフェースの標準化。これらすべては、自動車業界全体を再構築する上で極めて重要な概念なのです。

SOAFEEと自動車業界の標準規格

ジョン:そういえば、今あなたが話してくれた内容は、最近ロバート・デイとSOAFEEについて交わした会話と非常に相乗効果がありますね。SOAFEEについては、アマゾンが創設メンバーの一つだったと承知していますし、あなたもこの取り組みを大いに支持されていますよね。SOAFEEが目指していることの多くは、あなたが言及したような標準や、一貫性のあるインターフェースを提供することです。でも、その話はまた別の機会にしましょう。

ステファノ:ええ、その通りですね。ところで、本当に充実した議論ですね。SOAFEEは素晴らしい取り組みだと思います。ご存知かもしれませんが、SOAFEEはオープンスタンダードとオープンソースに基づいたリファレンス実装を提供することを目的としています。 ああ、本当に、自動車業界にはオープンスタンダードとオープンソースがすごく必要ですよね? だからこそ、Yocto、COVESA、Eclipse SDV、AUTOSARといったイニシアチブが極めて重要なのです。そして、SOAFEEにおいて私たちが注目している非常に前向きな兆候の一つは、皆で協力し始めていることですよね? そこを徹底していく必要がありますよね? 本当に、オープンスタンダードこそが鍵ですから。標準規格そのもので競争するわけではありません。それは、それはあり得ないですよね。競争するのは――標準が定義された後――顧客が本当に、本当に必要とし、求めているもの、つまり標準には含まれていない部分について、イノベーションを始められる段階になってからです。「ああ、この標準が完璧に実装されているから、この車を買う」なんて言う人がいたとしても、それは理にかなっていませんよね?

ジョン:その通りです。標準規格を土台としつつ、その上に付加価値による差別化を実現することです。

ステファノ:基盤としてね。確かに、これもまたコスト削減や最適化の一つの手段だよ。ありふれた機能で差別化を図るために、なぜ時間とお金を費やす必要があるんだ?

ジョン:ここまでご覧いただき、もしこのエピソードを楽しんでいただけたなら、ぜひ「いいね!」を押していただき、The Garage でチャンネル登録もお願いできれば幸いです。私たちはおよそ2週間ごとにエピソードを撮影していますので、次のエピソードでもまたここでお会いできるのを楽しみにしています。

トピック4:機械学習と分析

ジョン:ステファノ、これまで本当にさまざまな分野について話し合ってきましたが、次は人工知能や機械学習、そしてより広くはデータ分析についてお話ししたいと思っています。というのも、私たちが収集しているこの素晴らしいデータレイクや、御社が提供する特殊なコンピューティングタイプにおける計算能力などについて、すでに話し合ったからです。 それに、プロトタイピングの重要性なども話しましたね。しかし、機械学習と分析というこの分野全体は、おそらく最も魅力的な領域の一つであり、それらを組み合わせることで、これまで不可能だったことを実現できるのです。

ステファノ:その通りです。そして、それは常に、いわゆる「ビッグ・ループ」という視点に立っているんですよね。これは非常に重要なことです。ご存じの通り、科学者たちは、モデルを正しく構築する上でデータセットが最も重要だとよく言っていますよね?ですから、私たちも常にそれを指針としています。つまり、クラウドに保存する適切なデータを選定するということです。

SageMaker によるデータ収集とアノテーション

ステファノ:つまり、状況に応じて何が重要かを判別するために、車にはある程度のAIが必要ですよね?例えば、急ブレーキをかけた場合などです。その理由は何か、あるいは複数の要因が絡んでいるのかもしれません。また、車載テストについても、この極めて重要な機能については今から詳しく話し合います。 とにかく、データが選定されたら、そこでは機械学習を少し活用して、データを自動的に更新する必要があるんですよね?データを送信し、収集し、クリーニングし、データレイクを整理する。完璧ですね。そして、このデータの一部を使って、その一部にアノテーションを付けるわけです。 つまり、お客様はご自身の目的に合わせてアノテーションを行います。そのためのツールとして、「SageMaker Ground Truth」があります。そして、アノテーションが完了したデータを使って、モデルのトレーニングと検証を行います。ここには様々な選択肢があります。SageMakerは、そのためのプラットフォームです。

AWSにおける機械学習向けのその他のフレームワーク

ステファノ:もし本当に機械学習の深い専門知識をお持ちであれば、例えばPyTorchのような基本的なフレームワークを使って、その低レベル部分まで深く掘り下げることもできますし、一方で、いわゆるAI サービスを利用することもできます。例えば、画像を送信するだけで対象物のリストが返ってくるような認識サービスなどです。そうです、文字起こしやAI といったサービスです。つまり、こうした3つの層があるわけです。

新型モデルの車載検証

ステファノ:SageMakerを使ってモデルをトレーニングする際、通常はエッジにデプロイしますが、これもまた大きなループになります。つまり、デプロイはされていますが、まだ本番環境には投入されていません。これは車載テスト用のものです。 現在、本番環境で稼働しているこのソフトウェアの別のバージョンがあります。したがって、最初の段階では、このモデルが本番環境のモデルと比べてパフォーマンスが劣るか、あるいは優れているかを分析します。そのため、実際の環境下で、場合によっては多数の車両に展開してテストを行うことになります。これは、コンピュータの処理能力に制約があるためです。そのため、そこではもう少し余裕があり、追加の計算処理を実行することができます。

エッジケースの発見

ステファノ:その通りです。先ほどおっしゃったように、特別なケース、いわゆる「エッジケース」を見つけるためには、開発の初期段階で抽象的なレベルでそれらを想像するだけでは不可能です。機械学習モデルの性能を検証するには、実際に多くの車両を走行させる必要があります。 そして、それを評価し、モデルがより優れていて性能の低下がないと判断できれば、モデルを切り替えて本番環境に投入し、このループが続くわけですよね? 対象となる車両の数はますます増えていきます。このように、機械学習は単なる「魔法のようなトレーニング手法」ではなく、まさにこの「インテリジェントなループ」そのものなのです。そして、ワークフローを定義することは非常に重要です。こうしたワークフローを管理するためのツールは数多くあり、その一部はSageMaker自体に組み込まれています。

MLワークフローを管理するためのツール

ステファノ:他にも、例えばデータ管理に関しては、Airflowの実装および管理型実装があり、「Managed Workflow with Apache Airflow」と呼ばれています。そして、これを使ってこれらすべてのワークフローを構成しているわけです。私も前の職場でAirflowを使っていましたが、この種のパイプラインを構成するには非常に強力なツールですよね。そうですよね。そして、それは非常に、非常に重要な部分です。 これらすべてについて、お客様はいわゆる「ワークベンチ」で利用することが多くなっています。ますます多くのお客様から、ブラウザ上の単一のスペースにアクセスして、必要なツールを見つけられるようにしてほしいという要望をいただいています。これらのツールには、データパイプライン、ワークフロー、機械学習関連のデータ、データレイクへのアクセス、業界固有のツールなどが含まれます。ごく最近、例えばdSPACEのイベントでは、MathWorksとのコラボレーションによるこのワークベンチに関する発表を行いました。 つまり、そのスペース内でこれらのツールを利用できるわけです。これにより、作業に集中できるだけでなく、環境の統一性、グローバルな展開、環境へのグローバルなアクセス、統合、そして自動化の構築が可能になります。 最近、当社のCEOがLinkedInに投稿したところによると、このアプローチを採用したことで、トヨタは年間1,000万ドルのコスト削減を実現したとのことです。ツールを整理し、共通のインターフェースを通じて提供し、そこから自動化を構築できる可能性を得られるだけで、悪くない成果ですよね。

ジョン:あなたの話で興味深いと思うのは、そこにはいくつかの要素があるという点です。まず、データ、つまり生データから始めること。そして、モデルを構築し、調整し、改善する能力を持つこと。さらに、それが整えば、クラウド上には、これらを連携させて後処理や分析を行うためのさまざまなツールやモジュールが用意されています。その種類も多岐にわたります。ですから、その一連のプロセス全体が、非常に重要だと私は思います。

ステファノ:その通りです。だからこそ、例えば、私たちはこれを整理し、オープンソースイニシアチブである自動運転データフレームワークを通じて公開しました。これは、顧客がこうした構成やワークフローを構築するためのオープンソースのリファレンスを手にできるようにするためです。 そして、そうですね、正直なところ、当社の顧客の多くは、まさにこの方法でツールの大部分を採用しています。例えばトヨタのような顧客は、ワークフローの一環として、当社のPインスタンスを利用して、AWS上でモデルをトレーニングするための当社のコンピューティング環境やディスカッションに接続しています。しかし繰り返しになりますが、これは単発の孤立した活動ではありません。あくまでワークフローの一部に過ぎないのです。この点を考慮に入れることが非常に重要です。

トピック5:ADASと自動運転

ジョン:さて、ここで最後のトピックであるADASと自動運転に移るのに、今が絶好のタイミングかもしれません。これは私たちが数年にわたり共同で取り組んできた分野であり、豊富な経験を持っています。 クラウドがADASの進化にとっていかに重要か、いや、不可欠であるかについて話しましょう。また、私たち全員が歩んでいる自動運転への道のりの可能性についても触れておきたいと思います。それはかなり長い道のりですが、着実に前進しています。

ステファノ:その通りです。繰り返しになりますが、私はこの件について非常に情熱を持っており、この点についてはすでに議論も始めていますが、自動運転や自動運転機能、そして自動車全般における自律性について、段階的なアプローチを提供することに強い情熱を抱いていますよね?

ADASによる短期的なメリット

ステファノ:ADASシステム、いわゆるレベル2やレベル3と呼ばれるものには、今や非常に大きな価値があるからです。これは非常に重要なことです。何と言っても、人命を救うからです。それだけの単純な話ですよね? そこで、私たちは最近、最新世代のADASを搭載した車をテストしましたが、その性能は素晴らしいものでした。 この車には、自動緊急ブレーキ機能を実際に備えたシステムが搭載されています。例えば、運転中に気を散らしていて障害物があった場合、車が自動的にブレーキをかけてくれます。単純なことですが、これが機能すれば人命を救うことになります。ですから、私にとっては極めて重要な要素です。そして、自動運転とは、こうした機能が徐々に自動化されていく集合体になるだろうと、私はますます確信しています。 ですから、車両で自動化されていく段階的な機能についても、考慮し、提供していくことが重要です。これが私の見解です。そして、私たちがクラウドを活用する方法は、先ほど議論したすべて、つまり多様なコンピューティングオプション、データレイクの可能性、データレイクの構成、そして機械学習ツールといった要素を活用するものであり、これらはADASや自動運転車の開発に必要な基本要素です。 コンピューティングオプションには、ADASに特有の2つの理由から、非常に重要な側面がもう一つあります。それは、現場から頻繁にデータを収集し、そのデータをS3上のデータレイクに保存することです。そして、そのデータを検証に利用しますよね? 通常、開発中のアルゴリズムに対して、車両から収集したデータを再生し、それらが前世代のものよりも優れているか、あるいは劣っているかを評価するのです。 あるいは、コンピューティングリソースを活用して、別の側面で合成シミュレーションを行うこともあります。例えば、ヴァレオ(Valeo)との素晴らしいユースケースがあります。これは、残念ながらCOVID-19の影響で中止となり、誰も参加しなかったCESで発表する予定でしたが、私たちは素晴らしいデモを用意していました。YouTubeに動画があります(もちろんリンクも掲載できます)が、そこではヴァレオが2つの技術、すなわちIPG CarMakerとForetellixを活用して、 合成シミュレーションを通じてシナリオの数を増やし、AWS上でシナリオの異なるバリエーションを数千通りまで拡張しています。これは、AWSにはスケーラビリティがあり、コンピューティングリソースの弾力性と可用性があるためです。そして、これらのエッジケースをすべて網羅し、分析に何か見落としている点がないかを徹底的に検証しようとしているわけです。

エッジケースの特定

ステファノ:そして、先ほど話し合った通り、いわば「シフト・レフト」の観点から、ソフトウェアが実際に車両に搭載される前にこの問題を解決するよう努めるわけです。つまり、繰り返しになりますが、これはワークフローを再構築する問題であり、AWSには、お客様がそれを実現するためのあらゆるツールが揃っています。もし必要なツールがない場合でも、お客様と協力してそれらを構築していくことを喜んでお引き受けします。

自動運転の分解

ジョン:その通りです。自動運転という課題を、単一の課題だと考えている人は多いと思います。しかし実際には、そこには非常に多くのサブタスクが存在します。冗談めかして言えば、「自転車の認識」や「車線維持」といったタスクがある、とよく言っています。冗談はさておき、実際にはさまざまなタスクがあります。これを細かく分解しなければならないのです。つまり、私たちが運転するときは、ただ運転するだけ、それだけの話ですよね。 しかし実際には、機械学習や人工知能がそれを行う際は、さまざまな部分へと分解するんです。そして、先ほどあなたが言及されたことは、非常に興味深いと思います。なぜなら、トレーニングについて考えてみると、人間が運転する場合、ほとんどの場合、かなり退屈ですよね。ただまっすぐ進み続けるだけで、つまらないものです。 ですから、練習しなければならないことよりも難しいのは、急カーブや障害物がある場合もありますが、あなたが言及された点は非常に興味深いです。エッジケースを加速させ、モデルに膨大な数のエッジケースを与えることで、実際の運転シナリオでは不可能なほど、モデルをはるかに迅速に学習させることができるからです。

ステファノ:その通り、その通りです。まったくその通りですね。だからこそ、先ほど話し合ったように、この観点からマイクロサービスが重要になるんです。例えば、知覚モデルだけを差し替えて、残りの部分はそのままにしておきたい場合もあるでしょう? つまり、それぞれ異なるスキルを持つチームが、それぞれの担当する小さな部分に取り組むということです。 つまり、ADASや自動運転車の開発に携わるさまざまな役割を認識することは、極めて重要なポイントなんです。本当に重要な部分ですよね。確かに、これは非常に複雑なシナリオです。しかし、ここには優れた事例がいくつかあります。先ほど私がコンチネンタル社について説明した事例もADAS開発に関するものでしたが、クラウドネイティブのアプローチを採用することで、彼らが時間やコストの削減、そしてアジリティの向上という点でどのような成果を上げたかが、はっきりとわかるはずです。 それが、私たちが彼らと共同で開発したこのCAEDGE演習の狙いでした。ちなみに、これもソフトウェア定義車両(SDV)の体験の一環でした。ですから、これは素晴らしい参考事例です。コンチネンタル社とのコラボレーションこそが、こうした概念の多くについて考え始めたきっかけなのです。本当に素晴らしいコラボレーションでした。

AWSととの連携Sonatus

ジョン:この会話の締めくくりとして、Sonatus とAWSが協力している分野について、少しお話しできたらと思います。

ステファノ:ええ、喜んで。というのも、the garage でいくつかの素晴らしいデモを見ることができたからです――ちなみに、それらを見せてくれて本当にありがとう。 本当に素晴らしいですよね。例えば、車両のロジックを制御したり、新しい状況に応じて新しいロジックを展開したりといった機能のいくつかは、SDVやビッグループ更新について私たちが議論していた内容と完全に一致しています。実際にそれが実現されているのを目の当たりにできるのです。本当に素晴らしい光景です。そして、ええ、これは素晴らしいコラボレーションですね。まさに完璧な事例です。 つまり、単にデータを送信したり収集したりするだけでなく、データプレーンの概念を実装し始めているのです。確かにデータの収集は必要ですが、コントロールプレーンについても同様です。クラウドからエッジへ、そして再びクラウドへと、このマイクロロジックを管理する可能性について言えば、エッジ側で一部のマイクロロジックや機械学習を実行しつつ、クラウド側でもそれらのマイクロロジックや機械学習を運用する必要があります。 また、統合やARMコアについて考えてみると、これは私たちが「クラウドからエッジまでの連続体」と呼んでいるシステムそのものです。そして、御社の製品シリーズを通じて、このビジョンを実現する上で、本当に素晴らしい仕事をしていると思います。

ジョン: そうですね、本当にありがとうございます。先ほどデータについてお話ししましたが、当社の「Collector」製品は非常に高度に最適化されており、厳選された高価値なデータを収集・調整し、クラウドへ送信します。この点については、皆様と協力して取り組んでいます。そして、先ほどご言及いただいた、当社が最近リリースした「Automator」製品は、この「スマートデータ」という概念を基に、車内・車外を問わず、具体的なアクションを実行することを可能にします。 車両テストについてはあまり触れられませんでしたが、車両テストの課題もますます複雑化しています。そこで、この技術を新しい方法で活用し、例えば生産ワークフローの改善や、より優れた下流サービスの提供につなげられることを楽しみにしています。先ほど、コネクテッドカーや、ユーザーへの下流機能、さらには下流の付加価値サービスプロバイダーへの提供についても言及されていました。

実際のECUを使用することの重要性

ステファノ:そうですね、それは実に興味深いですね。そして、実際のECUを使って開発しているという点も、私が気づいたもう一つの非常に重要なポイントです。 信じてほしいんですが、これは大きな違いなんです。というのも、私はいつも言っているんですが、自動車向けの新しいソフトウェアコンポーネントやハードウェアコンポーネントを開発する際、その50%は開発作業で、残りの50%はVとV[検証(Verification)と妥当性確認(Validation)]だと考える必要があるからです。ADASやAVの場合、いくつか仮定を立ててみましょう。ADASについては、おそらく20対80の割合だと思います。 自動運転車(AV)の場合は、1対99といったところでしょう。そうでしょう? つまり、VとVが本当に重要で、実際にCPU上でコードが実行される様子を見ると、その違いがわかるはずです。もはや評価キットに基づいた机上のプロトタイプだけではないのです。100万台、200万台、1,000万台の車両に搭載されるものなのです。だからこそ、これが決定的な違いを生むのです。

ジョン:その通りですね。そして、私たちもこの技術が採用されることを大変嬉しく思っています。ご存知の通り、今年中には数十車種に搭載され、来年末までには数百万台の車両に搭載される予定です。ですから、これは単なるプロトタイプでも、科学研究プロジェクトでもなく、実際の量産品であるという点で、本当にワクワクします。 そして、いわゆる「実践の場」である実際の量産からは、多くのことを学べます。その分、はるかに難しくなるんです。

ステファノ:そうですね。 自動車業界に携わる人なら誰でも、規制への準拠にどれほどの労力がかかるか理解しているはずだ。それがこの業界の大きな特徴だよね?だから、スマホのように気軽にコードをデプロイするわけにはいかない。そうだろう?これは一般消費者向けデバイスとは異なり、規制対象製品であり、機能安全やサイバーセキュリティといった要件が存在する。それらは最優先事項であり、私たちにとっても極めて重要だ。まさに最優先事項、優先度ゼロだ。

概要

ジョン:そうですね、今日は本当にたくさんの話題に触れましたね。今日取り上げたサブトピックだけでも、それぞれ1時間ずつ話せるほどですが、今日はここで締めくくらなければなりません。まず、ステファノさん、今日お越しいただき、本当にありがとうございました。お招きできて光栄でした。 今日の対談で私も多くのことを学ばせてもらいましたし、あなたとお話しするのはいつも楽しいです。ぜひまたお越しください。

ステファノ:こちらこそ、お招きいただきありがとうございます。いつも楽しい時間を過ごせています。私自身もたくさんのことを学びました。本当に素晴らしかったです。

ジョン:ステファノ、ありがとう。さて、今日のエピソードでは、クラウドのあらゆる側面について、特にAWSの観点から話し合いました。データとその重要性から始まり、データを活用するさまざまな方法、そしてコンピュートや、さまざまな種類の問題を解決するための多様なコンピュートサービスの必要性について、クラウドが自動車業界や車両のワークフローにどのようなメリットをもたらし、どのように改善できるかについて議論しました。 プロトタイピングについても話し、特にクラウド上で車両機能をプロトタイプ化し、実際の車両にデプロイできる点は非常に魅力的です。また、機械学習や分析についても触れ、データ分析がどのようにして多方面で付加価値を生み出せるかについて議論しました。そして最後に、自動運転やADASについてごく簡単に触れ、それらを改善し、そのフローを最適化することがいかに重要かについても言及しました。今回は幅広い話題を網羅した対談となりました。 楽しんでいただけたなら幸いです。また近いうちに『The Garage 』の次のエピソードでお会いできるのを楽しみにしています。どうもありがとうございました。

最近のエピソード

関連リソース

事例研究

マレリとAWS、車内でのパーソナライゼーションを強化Sonatus

マレリ、AWS、およびSonatus は、車内でのダイナミックなパーソナライゼーションへのアクセスを拡大することで、自動車業界の未来を牽引すべく協力しています……。
Driving Innovation Podcast

Sonatus AWSを活用した高度な車両データ収集

Sonatus の最高医療責任者(CMO)であるジョン・ハインライン博士と、AWSのプリンシパル・プロダクト・ソリューション・アーキテクトであるマイケル・ガルシア氏が、Sonatusのリアルタイムデータ収集プラットフォームとAWSの緊密な連携について解説・実演し、動的なデータ強化を通じてOEMおよび下流サービスを実現する仕組みを紹介します。CES 2024のAWSシアターにて収録されました。
「ザ・ガレージ・ポッドキャスト」

AWSが自動車業界にもたらす真の価値

AWSの自動車産業向け製品部門でソフトウェア開発ディレクターを務めるマイク・ドーゼンバッハ氏が、AWSとパートナーとの連携の変遷、クラウド上でのプロトタイピング、機械学習、OTAアップデート、データの重要性などについて語ります。CES 2024にてライブ収録されました。
トップへ戻る