まとめ： 進化する自動車： ゾーン・アーキテクチャ
レイモンド・イン：
『The Tech Between Us』へようこそ。ソフトウェア・ デファインド・ビークルにおける対話の締めくくりです。ETASのCTOであるクリスチャン・ウーバー氏に再び登場していただき、ソフトウェアレイヤーの自由度を高めるために、より強力なハードウェアとソフトウェアの共同設計の必要性について探ります。今までのエピソードをお聞き逃しの方は、mouser.com/empowering-innovationにアクセスください。
ではクリスチャンさん、ゾーン・アーキテクチャの話に移るにあたり、現在のソフトウェア・エンジニアリング・プロセスはどのように変化していくのでしょうか？たとえば、コードの記述方法、テスト方法、更新頻度などはいかがでしょう。
クリスチャン・ウーバー：
私たちは、マイクロコントローラで行うすべての作業を大規模な実行テーブルに統合してきました。20ミリ秒、100ミリ秒、10ミリ秒ごとに実行するなど、細かくスケジュールされています。機能の全てが、このような密に詰まったスケジュールに統合されなければなりません。それを行うことで、実際のハードウェアに自然にそして密接に結びつくわけです。アーキテクチャ的には、どんなハードウェア抽象化レイヤーを導入しても構いません。このような統合パターンで多くの機能をマイクロコントローラにしっかりと詰め込んで、それを97%ほどの利用率で使用する場合、変更する全てのことがハードウェアに高度に依存することになるのです。シミュレーションを行いたい場合、そのシミュレーションがハードウェアと全く同じである必要があります。そうでない場合、無価値となります。
そのような関数を書き続ける限り、システムを安定した方法で進化させるのは非常に困難です。実際のハードウェアのサイクルに密接に結びついてしまうのです。それに依存しないようにするためのコツがあるのですが、一つは、実際の物理的な時間に依存しない関数を書くことです。主に入力ポートのデータに依る関数を書きます。つまり、同じデータを入力すると、常に同じ結果が得られます。そして、それを基に、より複雑な関数を作成するのです。同じデータを入力すると、タイミングや揺れ方に関係なく、常に同じデータが出力されると保証できれば、あとはこの関数を展開するために十分に高速なハードウェアを見つければいいだけなのです。通常、これでうまく動作します。
それには関数の書き方を変える必要があり、開発者の仕事の大部分は、「今はこのタイムスライスにいる。もう10秒も経った」と言ったメンタルモデルを持っていました。7～8ミリ秒後には「あとどれくらい時間がある？」とランタイムに尋ね始めるのです。その答えに応じて、タイムスライスが終わる前に追加の処理をします。そのように関数を作成すると、ハードウェアの実際のマイクロタイミングに超依存することになってしまい、関数を他の場所にはどこにも移すことはできません。この関数の呼び出しを開発者から取り除いた場合、ランタイムに残り時間を聞くことはできませんし、計算の基礎となる物理的な時間の概念さえありません。あるのはメールボックスだけです。新しいデータがあればそこに入れます。アクティベーションを受け、実行し、そのデータを変換します。そしてアウトボックスに入れるのです。
この世界ではそれだけなのです。 入力データが表示され、計算が終わったら、それをアウトボックスに入れるだけです。そして以前に知っていたことはすべて忘れてしまいます。 もう一度きいても何も残っていません。これが気に入らない場合は、覚えておきたい内容をアウトボックスに入れておき、再度聞かれたときにインボックスに返信できるようにしないといけません。 これが、従来の組み込み開発をしてきた多くの機能開発者が経験するメンタルモデルの変化です。 ですが、この方法はシステムの開発拡張をどれだけできるかにおいて、莫大な利点が得られます。というのもそういったシステムがあり、クラウド上に仮想テストを構築すると想像してみてください。依存するのは実際のデータだけになるからです。
実際のタイミングなどへの依存性はありませんし、この関数はどこでも実行できます。また、常に同じ結果を生み出します。そして、それを開発者に返しますとと、非常に迅速な高品質のフィードバックが得られます。もし提出したコードが機能的に正しく動作し、前回の反復よりも良くも悪くも後退していないのであれば、開発者同志の協力がはるかに容易になります。ですので、これが変化している開発パラダイムですね。要するに重要なポイントは抽象化レイヤーではなく、提供する関数の依存関係の削減です。私たちは本当にそれらをデータ依存のみにしようとしているのです。その結果、長期的に多くの柔軟性を得ることができるのです。
レイモンド・イン：
あなたがおっしゃったように、完全なパラダイムの思考変化が必要になるのですね。特に、下位レベルのマイクロコントローラのコードの書き方は、時間の依存関係を取り除いています。あなたは入ってくるデータと出ていくデータを持っているようなものだとおっしゃっただけですが、その間で何をするかはあなた次第なのですね。
クリスチャン・ウーバー：
はい。メンタルモデルが大きく変わります。また、開発実行者は、機能開発に対して開発者に報酬を支払っていると考えていることもあります。組み込みエンジニアの分野では、彼らの仕事のほんの一部に過ぎません。
レイモンド・イン：
そうですね。
クリスチャン・ウーバー：
もちろん、多くのコミュニケーションが必要です。 実際に何が機能するのか見つけなければならないことが沢山あります。しかし、組み込み開発における重要な部分は、同僚と一緒に作成したすべての要素を、非常に緊密なパッケージの中で一緒に実行させることです。 統合、小型化、安定性の確保、振動の防止などが含まれます。これは大変な作業です。 そして、実際にすべてが物理的なタイミングに基づいてますから、どのように相互作用するかです。これを取り出して、「外部から見えるのはインボックス内のトレイ内のデータだけ、そしてそのデータとアウトボックストレイへの効率的な変換だけに目を向けて。」と言われた場合、これは大変な制約になるのですが、同時に新たな自由を得ることになるのです。 特に、最新のC++ を扱い、純粋関数や新しいメモリ・セマンティクスなどを操る開発者にとってはそうです。 実際彼らは関連付けることに非常に長けていて、この種のパターンを試したり、そういった関数を書いたりするのが大好きなのですね。
レイモンド・イン：
なるほど。現在新しいマイクロコントローラが登場していますが、依然として本質的に制御レベルのコアです。 たとえば、ARMの新しいCortex M85 をご存知かどうかわかりませんが、 それには驚くべき機能が備わっています。 マイクロコントローラ開発者や機能開発者は、単純なCPU サイクルと同じ下位レベルの単純な計算能力を最大限に利用し、彼らが達成しなければならないことを実現できるの でしょうか？
クリスチャン・ウーバー：
まあ、たしかにそのスペースはあると思います。しかしシステム全体をデータに依存した書き方はできません。 解決すべき問題全体のサブセットにのみ適しています。 私たちがマイクロコントローラ分野で開発した専門知識を、マイクロコントローラコースのより大きなファームに応用できるケースはたしかにありますし、これまでやってきたことをそのまま継続するだけです。
ハイパーバイザーのような付加的な利点があれば、システムの利用方法をより簡単に変更できるかもしれない。しかし、全体的には、マイクロコントローラ形式のプログラミングという、非常に古典的な方法で継続することになります。確かにその余地はたくさんあると思います。たとえば、ビークルダイナミクスは、本当に高精度の操縦を行うという目標にはまだほど遠いです。各車輪で何ができるかというと、まるで路面にぴったりと張り付くような、本当に驚くようなことができます。 超リアルタイムのレイテンシ重視で私たちがまだ手をつけていないものがたくさんあります。そして、安全な方法でそれらを利用したい場合は、マイクロコントローラ形式のプログラミングが必要です。
レイモンド・イン：
わかりました、では、少し方向転換しましょう。すでに少し話をしてきましたが、再び純粋な低レベルのマイクロコントローラの従来のECUタイプのスペースから、より高レベルの計算プラットフォームへの移行について話しましょう。コードの移行の難しさについても、マイクロコントローラエンジニアが特定の時間スライスを取得できなくなるなど潜在的な変化についてもお話しいただきました。彼らはより大きな枠内で作業する必要があります。他にどのような種類の変更が必要でしょう？高レベルに移行するクラウドベースのテストを使用してテストすることについては簡単に触れていただきましたが、安全性重視の機能を維持するため新しいプラットフォームを効果的にテストするためには、他にどのような種類の変更が必要になるのでしょうか？
クリスチャン・ウーバー：
非常に重要な点をご指摘くださいました。私たちは、より高い頻度で段階的に作業できるような高性能なソフトウェア配信組織になりたいと考えています。これは、高品質のテストなしには不可能であり、通常はかなりの程度自動化されています。テストはクラウド上で実行する必要があり、そこではテストを実行するための安価な動的コンピューティングリソースがたくさんあります。そして、自動車プロジェクトにもパターンがあり、 過去20年ほど、私たちは各タスクフォース後に振り返りを行ってきました。そして毎回、仮想テストにもっと早く投資すべきだったという結論に達していました。実際のテストを行える本物のハードウェアの入手がいつも遅すぎるか、高品質のシミュレータの登場が遅すぎるかのどちらかでした。最近では多少改善されてきているので、仮想ハードウェアがより早く利用できるようになりました。しかし、そのような場合でも、非常に計算集約的であり、60回などの短いテストサイクルのために3倍の計算リソースを支払うようなことはできません。しかし、ここがIT業界から多くを学べるところです。テスト・ピラミッドを作り、上部に実際のハードウェア、その下部に仮想ハードウェアを置きます。そして、さまざまな種類のテスト、特に私たちが話したデータ実行のためのテストを行います。そのため、ピラミッドの下方で多くのことを行い、クラウドベースの環境で共同作業を行う開発者に、非常に迅速なテスト・フィードバックを提供できます。したがって、クラウドは、何百人もの開発者が互いに協力しあうのに非常にすばらしい場所なのです。
そして、実際にクラウドで組込み開発を行うには、二年目の開発者に代表的なテスト動作を提供する必要があります。すでにお話ししましたように、機能開発は開発時間のごく一部に過ぎないからです。多くの開発時間は、多くの機能を狭いスペースに収めることに費やされます。また、クラウド上の仮想ターゲットがデスク上の作業と異なる動作をするのであれば、人々はクラウドを使わずデスク上で作業を続けるでしょう。これでは協力的ではありませんし、段階的でもありません。これでは単なる古いモデルになってしまうのです。そのため、クラウドベースの環境で、高品質のテストと迅速なフィードバックのためのスマートなテスト・ソリューションを提供することが、将来的に本当に重要になってくるのです。また、私たちが大いに投資しているポートフォリオのテーマでもあります。
わかりました。さて、テストについては、私たちが常に低レベルの組み込み世界で使用しているMCUにも、どんなものにも開発キットがあります。そして、メルセデス用の開発キットというものは実際には存在しないと思います。ですからおっしゃる通りですね。システムの実際の動作を正確に模倣した仮想化システムが必要なのですね。
クリスチャン・ウーバー：
そうです。同じでなければ価値がなく、だれも使わないでしょう。机上で開発キットを続けるだけになります。
レイモンド・イン：
まさにそうですね。
ここで、エピソードの後半に進む前に、ゾーン・アーキテクチャの特定の使用例に焦点を当ててみましょう。ソフトウェア・デファインド・ビークルでは、ゾーン・アーキテクチャの柔軟性と拡張性により、安全性、効率性、パーソナル化を向上させながら、変化するニーズに車両がどのように適応できるようになるのでしょうか?この使用例やその他の限定コンテンツは、mouser.com/empowering-innovation にアクセスしますとご覧になれます。
アップデートやソフトウェアの更新サイクルについても少しお話いただきましたが、消費者向け機器は常に更新されています。また、車載用ソフトウェアが新しいコンピューティングプラットフォームのために行われているような、新しいアーキテクチャや新しいプラットフォームへの移行もあるのでしょうか？
クリスチャン・ウーバー：
興味深い質問ですね。確かに、より頻繁な更新の需要があり、特に高度に集中化されたアーキテクチャではそれが可能だと言う新しいプレーヤーの証明もあります。しかし、どのような更新がされているのかを注目しなければなりません。ドライブモードや顧客を喜ばせる機能のようなものを提供するのはとても簡単です。しかし、それは安全性重視のものではなく、宣伝用の仕掛けなだけです。それはたしかに可能です。 そのような更新が簡単にでき、技術スタックの少なくとも一部を確実に確保する必要はありますし、以前よりもはるかに高速に行えます。インフォテインメント・システムでも、SDVエッジ・スタックでもいいです。しかし、その一方で、OEMやボッシュのティア１である私たちが実際にどのような機能に投資しているかというと、どれくらいかがこういったからくり戦略への投資であり、どれくらいがそれ以外への投資なのかを考える必要があります。
実際、路上での車両の実際の動きに影響を与える本格的な車両機能に、多くの投資が行われていることがわかります。つまり、安全性が重要であり、そして非常にダイナミックなのです。また消費者がビークルダイナミクスにおけるマイクロ秒単位の動作にどれほど敏感であるかは驚くべきことです。自分の車に素晴らしいアプリケーションがあり全てがフィットし、全てがうまく連動しているのか、それともデフォルトの設定に少し余分な調整が加えられているだけなのかを実感できます。ですから、これらの機能の多くは、車両力学や安全性、実際の物理的な世界に関するものなのです。そして、ユーザー管理の個別更新メカニズムを提供することは、私たちが考えているよりもはるかに難しい問題です。したがって、容易な更新や高頻度の更新、またはユーザーによって行われた更新を行うのが簡単な機能のクラスがあると思います。車両の一部で、実際に相互作用する機能について話しましたが、それは提供される更新または更新の組み合わせに関係なく、OEMが常に車両が安全な状態になるように構成する責任があると考えられます。私はそれが二つの方法で実現できると思います。
まず、車両の一部分は安全上重要な機能がすべて含まれているのです。そして、それらはOEMが管理するプラットフォーム・リリースにて一緒にリリースされます。OEMは車両に搭載する前にすべてのテストを行い、すべてのテストとお互いの組み合わせを行うので「これがベースプラットフォームのバージョン1.3です。これが搭載されるなら、安全であることを証明します」と私たちは言えるのです。次に、車両技術スタックの別の部分があり、より独立したアップデート、つまりユーザー主導のアップデートがあります。これはインフォテインメントでもいいです。SDVスタックでは、ベースプラットフォームは車両の他の領域から十分に分離されていると言えます。あらゆる条件下で、なぜこのように分離されているのかは安全性を十分に説明する必要があるからです。そして、分離されてることでよりダイナミックな更新動作を可能にすることができます。本当に良いエンド・ツー・エンドの顧客経験を実現するためには、これら両方を提供する必要があると思っています。高速プラットフォームを車両に導入するだけでは十分ではないのです。OEMが常に路上での安全運転を保証するという責任を果たすことと、新しいダイナミック・プラットフォームでより高い更新頻度を実現するという良い組み合わせが必要なのです。
レイモンド・イン：
そうですね、あなたがおっしゃるように、人を喜ばせる機能があり、それは消費者向けの機能やアドオンを備えていることです。一方で自動車が安全であること、信頼性の高い方法で動作し続けそれを保証するという基本的なことは、消費者は認識していなかったりさほど気にかけておらず、 機能するのが当然と考えていたりしますよね。 人々が話すのは「新しいアプリがアップデートされた。」といったことですので、たしかにわかります。 それを二つの異なるレベルで、一つは機能が多いけれども重要ではないレベル、もう一つは「これはなければならない!」と言ったレベルで行っているのですね。
クリスチャン・ウーバー：
具体的な例を一つ挙げますと、 バッテリー管理です。古典的な組み込みスタイルで書かれた、高い安全性を確保する機能です。これにより、バッテリーが過熱しないようにし、安全な物理的パラメータの範囲内に保ちます。古典的な開発モードでは、これらの機能が割り当てられたバッテリーコントローラがあり、充電ステーションとの通信方法や、充電プロバイダのバックエンドネットワークとの通信方法など、他のすべての機能が含まれていました。しかし、そうである必要はありません。基本プラットフォームで提供する必要があるのは、バッテリが損傷されないようにすることだけです。SDVスタックは、技術革新やエコシステムの勢いにはるかに容易に対応できます。ワイヤを介した新しい標準、充電プロバイダ、新しい提携関係、新しいプロトコルが存在するのです。この機能をはるかに動的で容易に更新可能なスタックに割り当てることができます。そして、これらの機能はバッテリを制御する安全性の重要な機能と通信しているのです。これからは、これら両方のベストの組み合わせが増えていくと私は思っています。
レイモンド・イン：
わかりました。そうですね、バッテリの充電や維持は少しは変わりますが、あなたがおっしゃったようにエコシステム、提携、充電器の利用可能性ほど頻繁に変わりませんよね。特にグリッドに接続し、充電のタイミングがわかるようになると、すべてが非常に動的に変化しますね。
さてここまでで現在のドメイン・ベース、MCUベースのプラットフォーム・アーキテクチャから、集中型ゾーン・アーキテクチャのような新しいアーキテクチャに移行する際の課題について、多くのことをお話いただきました。文化的なレベルではどうなるでしょうか? データセンターの文化とそして自動車業界の文化があるとおっしゃいましたが、この二つは必ずしも企業そのものではないですが、いずれ融合するものとお考えですか？それとも、自動車業界とデータセンターのそれぞれの文化は引き続きまだ別物となるのでしょうか？
クリスチャン・ウーバー：
いい質問ですね。まず最初に起こるべきことは、ある程度はすでに起こっているのですが、古典的なマイクロコントローラの専門家が懸念を持っていたことです。車両の新しい種類のアーキテクチャパターンでは、保証されたレイテンシ、ジッタ、負荷ジッタなどに関してすべての状況下では解決されてないのです。そう言ったことが沢山あるのです。たとえば、時間に敏感なネットワーキングを備えたゾーン・アーキテクチャの場合、新しいイーサネット標準は、ゾーンを相互に接続するバックボーンにこの種の機能を実際に提供できます。レイテンシが重要視されている機能などに対して、高度に保護された高速通信パスレーンを提供することができます。しかし、これは今のところ実現していません。そして、多くの企業がIT担当者を自動車組織のリーダーに任命してきています。IT担当者がやってきて「ああ、これは全部もっとずっと簡単にできる」と言い、結局あなたは昔ながらのやりかたをするのです。
こういった衝突が起きる原因は、彼らは新しいソリューションでは解決されない正当な懸念を持っており、そしてカルチャーが同じではないからです。ですから改善するためには、新しいシステムが実際にこれらの機能を提供することです。実際に問題を一緒に解決し始めることができる基本アーキテクチャがあるので、こうして初めてカルチャー適応が始まるのです。
そして、異なる分野の人々が一緒に問題を解決できるようになれば、ずっと簡単なものになり、両方の世界の長所を組み合わせたものになるのです。そして、私たちはかつてないほどそれに近づいていると思います。
レイモンド・イン：
そうですね、たのしみです。さてこのポッドキャストでも何度も登場しているのが、人工知能と機械学習の技術です。明らかにその技術が今後自動車の自律性や、ドライバーの安全性においてたくさん導入されると思います。ソフトウェアの面では、安全上重要なシステムや要求される安全レベルを維持するために、どのように自動車に統合されていくと思われますか。
クリスチャン・ウーバー：
こちらも良い質問ですね。ひとつ確かなことは、これらはマイクロコントローラで展開することはできないということです。計算負荷が高すぎるからです。他の種類のアーキテクチャ、CPU、専用アクセラレータの方が合理的となります。
レイモンド・イン：
たしかに。
クリスチャン・ウーバー：
しかし一方で、これらのアーキテクチャはバッチ処理用に最適化されたデータセンターからきたものです。 そして、多くの場合、レガシーで重要なものは最適化されていません。ですからそれが解決すべき最初の技術的課題なのです。二年前には、長時間実行されているGPUタスクを安全重要視のもので中断することは不可能でした。そのためのAPIがなかったのです。ですが、そのようなことはまだ完全には達成されていませんが、いろいろと改善されてきています。またアクセラレータやGPUに、ASIL Bのような中程度の安全ペイロードを搭載し、さらにアーキテクチャを発展させることで、実際に展開できるユースケースも増えてきています。しかし、それは依然として難題です。ですから、超ミッションクリティカルなASIL Dのようなものをマイクロコントローラの環境に置くことはないと思います。私たちはハードウェアとソフトウェアの共同設計マイクロコントローラを導入していますが、これはまさに私たちの安全対策の要です。ただ、コードとランタイムの最適化が多すぎるため、これを5年以内にGPUで期待することはないでしょう。ですから、おそらく組み合わせになると思います。 中程度の安全性であるQM、ASIL B、または ASIL A があり、さらに多様性やさまざまなバリエーションがありますから、マイクロコントローラやCPU上で動作するものと組み合わせることで、安全なシステムが構築されます。しかし、これはまだ発展途上であり、非常に興味深いトピックだと思います。
レイモンド・イン：
その通りですね。人工知能の深層学習は、世の中にあるほとんどすべて事柄、技術に影響を及ぼすでしょうが、新型車の自律走行機能ほど影響を及ぼすものはないのではないでしょうか。
クリスチャン・ウーバー：
興味深い側面もあります。GPUは、外部環境に対するより強力な知覚など、新しいクラスの機能のための優れたホスト、あるいはアクセラレータです。こういったテクノロジーが提供するものと、私たちが必要としているものがうまくマッチしているのです。一方で、シンプルなLinuxのエッジスタックで、OEMがMLベースの実験を導入しているようなケースも多く見受けられます。非常にシンプルなトリガー機能で、車両内の物事をモニタし、実験を実行しますが、何が相関しているかなどの仮説をたてているのです。予測を使用し、車両にML機能を簡単に導入できるようになり、簡単に更新できるようになれば、OEMは創造性を発揮していろいろなことを試せるようになるでしょう。これはユーザーに売り込む機能ではなく、常に実験をくりかえしているもので、OEMはそこに多くの価値の見出しているようです。
レイモンド・イン：
興味深いですね。そういったことが進行中だったとは思ってもみませんでした。すでに車両に搭載されていたのですね。
クリスチャンさん、自動車や車両のソフトウェア面に関する専門知識と見識を共有していただき、本当にありがとうございます。ハードウェアの古参者として多くのことを学ばせていただきました。本日はお時間をいただき、本当に感謝しています。
クリスチャン・ウーバー：
どうもありがとうございました。私も実に楽しかったです。
レイモンド・イン：
これにてゾーン・アーキテクチャとソフトウェア・デファインド・ビークルについての探究を締めくくりたいと思います。クリスチャンさん、本日はThe Tech Between Us!のゲストでお越しくださり、本当にありがとうございました。 最新のテクノロジーとソリューションに関してさらに多くのコンテンツをお探しの場合はmouser.com/empowering-innovation をご覧ください。