進化する自動車：ゾーン・アーキテクチャ

レイモンド・イン：
「The Tech Between Us」へようこそ。 ETAS のCTO、クリスチャン・ウ-バー氏とのゾーン アーキテクチャとソフトウェア デファインド ビークル(SDV)についてお話をうかがっています。前回のパート1をお聞き逃しの場合は、Empowering Innovation Together Web サイトにアクセスください。
自動車が文字通り車輪のついたコンピューターになりつつあるというようなマーケティング上の話はよく耳にするかと思います。そして、それはある意味真実ですが、マーケティング上の話しであることは明らかです。実際の自動車は、動くコンピューティング プラットフォームになるまでにどの程度の変化を遂げたのでしょうか。もちろん、アーキテクチャの側面もありますが、あなたがおっしゃっていたように、開発的な側面や人的な側面もあるでしょう。その移行はどのように進んでいると思われますか。

クリスチャン・ウーバー：
それはOEM側のどの立場によるかで異なりますが、どのように実現できるかとか、得られるメリットなどをたしかにいくつかの企業は示してくれたりしてますし、よりソフトウェア指向の車両を提供することで、顧客の購買情熱を駆り立ててもいると思います。
一方で、この業界が売り込んできた SDV技術がまだすべての企業で具体化されていないことも確かです。文化的な慣性もあるでしょうが、まだその約束を完全に果たしていないのです。問題に対する部分的な解決策は数多く存在しますが、中核となるビジネスに目を向けてみると、安全上重要なシステムを顧客に提供し、道路で使用できるようにするための作業工程があるわけです。それからクラウドが車両に導入されると言われていますよね、すべてがコンピュータのように起動し、車がデータセンター、スマホとして動くと。

レイモンド・イン：
たしかに。

クリスチャン・ウーバー：
そんなに多くの顧客が本当にそのような経験をしてるわけではありません。これを買ったから、もっと速く、もっとコスト効率がよくなったと、そう簡単にはいかないのです。多くのデータセンター・テクノロジーが1対1で自動車に転用できるものではない事と関係していると思います。一つ例を挙げましょう。クラウドのエコシステムでは、非常に信頼性の高いシステムがあります。たとえば年間数秒のダウンタイムしかないミッション・クリティカルなシステムです。高品質で可用性が高く、すばらしい仕事をしています。しかし、クラウドで使用される設計パターンは、負荷が発生した場合、より多くのシステムにスケールアウトすることを前提としています。
車ではそんな事はできません。そこにあるのは車両に搭載されたコンピューターだけなのです。その限界に達した場合、他の故障モード、劣化モード、このコースをどう処理するかという他のモードが必要になります。クラウドからパターンをコピーするのはマシンを1台増やすようなものですから無理です。私たちの業界は、新技術を取り入れ、それを自動車に搭載すれば、すべてが良くなると仮定しているところがあり、いささかおめでたすぎると私は思っています。
レイモンド・イン
たしかに。完璧な世界であればの事ですよね。
クリスチャン・ウーバー
そうです。もうひとつは、物理的なアクチュエータの分野です。まず人命にかかわるような安全性の要求があり、責任者が署名します。次にITシステムの同様な要求があり、そこでも大きな脅威があります。また他のプロセスや慣習もあります。「私は署名しました。責任持って、道路で走らせて安全です」と言える状態にまでどうやって到達できるかです。
これが意味していることは、例えば、特にマイクロコントローラーの分野では、私たちが運用領域を実際に深く理解し、異なる機能間の妨げが全くないことをいかに保証するか非常に堅牢なアプローチを採用しているということです。また、私たちは非常に定期的な、時計仕掛けのようなアルゴリズムを使用しています。例えば、10ミリ秒ごとに作動させるというように。そして、ビークルダイナミクス関数を作動させれば、アルゴリズムは10ミリ秒ごとと仮定するでしょう、そうでなければ不安定になりますから。それを保証できない場合、最新の設計ではより高い保証は非常に難しくなるでしょう。本当に問題が発生し、システム全体が振動するようになってしまいます。得をするよりももっと問題が発生してしまうのです。この点が過小評価されていたと思います。特にアルゴリズムの領域では、ビークルダイナミクスなどに関する豊富な素晴らしい理解があるのですが。そしてこれはマイクロコントローラ用に作られたものです。つまりマイクロコントローラ用のソリューションを持ってはいますが、それをそのまま、ハードウェア・アーキテクチャにコピーして、すべてがうまくいくと仮定することはできないのです。そんな風にはうまくはいかないのです。
レイモンド・イン
私はマイクロコントローラーのエンジニアですが、そのような環境でのマイクロコントローラーは、センサーであれアクチュエーターであれ何であれ、実際のものと非常に緊密に結合しています。Linux やその他のオペレーティング システムが作動している、より高性能で大規模なCPUやGPUプラットフォームに移行するのとは対照的に、イベント間のサイクルをカウントすることさえあります。だから、あまりうまく変換できないのですよね。
クリスチャン・ウーバー
そのとおりです。中型クラスのCPU、マイクロコントローラーの例を見てみましょう。これは本当に時計仕掛けのように動きます。すべてのサイクルが前回のサイクルと同じですから本当に頼りになります。エンジニアは満たすべき条件について、非常によく理解していますからマイクロコントローラーがそのように作動するのです。マイクロプロセッサーは汎用的で幅広いユースケースに最大のスループットを発揮し最適化します。例えば、マイクロコントローラーは非常に短い、いわゆるパイプラインを持っています。これは一連の段階で一連の計算を行い、出力を生成するにすぎません。

レイモンド・イン：
そうですね。

クリスチャン・ウーバー：
マイクロプロセッサの効率やスループット上の理由から、パイプラインは非常に長く、マイクロコントローラの3、4倍の長さがあり、効率的に使用するためにはパイプラインを埋める必要があります。これは非常に困難なことなので、マイクロプロセッサーはそれを埋めるために多くの動的最適化を行い、次に何が起こるかを見据えています。すでに計算を行い、特にいわゆるマルチレベル・キャッシュを持っているとしましょう。キャッシュは、メイン・メモリを桁違いに高速化したものです。そして、つい最近使ったデータをいれたり、あるいは次の計算で使うかもしれないデータを非常に高速なキャッシュに配置するのです。そしてこれらのパイプラインを常に有意義な作業で満たされるようにします。

スループットという点では素晴らしいが、時計仕掛けのような予測可能な動作という点では非常に不利です。なぜなら、動的な実行でよく振動する傾向があるからです。デバッガーを立ち上げて初めてわかるような不透明な理由で、物事が本当に速くなることもありますし、それを見つけるのは本当に複雑です。常に動的に最適化されているため、見つけ出せないこともあるからです。GPUの場合も同じで、さらに悪いことがあります。CPUやアクセラレーターができるだけ効率的になろうと、その場その場で多くの最適化を行うため、うまく予測できないことがたくさんあるのです。そして、古典的な制御ループの問題には本当に適合しません。もし私が10ミリ秒に1回の割合で起動させるなら、10ミリ秒プラスマイナス5％くらいになるはずです。そして、私のアルゴリズムはそれに依存しています。スループットが上がるので、ジッタを開始することはできなくなります。それですと制御アルゴリズムのエンジニアが持っていない問題を最適化していることになります。エンジニアが求めているのは、非常に予測可能な起動です。それがあってエンジニアは仕事に取り組めるのです。

レイモンド・イン：
そうですね。では、車両にオペレーティング・システムを導入し始めた場合、遅延や予測不可能性の問題は解決するのでしょうか、それとも悪化するのでしょうか？
クリスチャン・ウーバー：
それは考え方次第です。多くのリアルタイム オペレーティング システム開発者は、全てのレジスタ、あらゆるビットを知っています。彼らはシステムを知り尽くしているので、それに基づいてハードウェアとソフトウェアの共同設計を行っているのです。彼らがこれはうまくいくという署名をしたのであれば、彼らは非常に高いプライドと自信を持っていたことになります。
彼らは、見たことも聞いたこともない誰かによって書かれた何十億ものコードのLinux カーネルのようなものを見ています。しかも、それがすべて同じプロセスのカーネル空間で動いていて、何か問題が起きれば、他の1000万行のコード全体がクラッシュする可能性があります。彼らにとっては、このような非常に大規模なアーキテクチャを基に信頼性の高いシステムをリリースできると仮定することは、本当にありえない話なのです。一方で、Linuxがデータセンター分野でどのような実績を残してきたか、どのような問題を解決してきたか、またどのようなパターンを使ってきたか、課題の複雑さを比較してみると、アーキテクチャであってもLinuxはかなりのところまで来ています。Linuxのアーキテクチャを理解していれば、そのアプローチで安全なシステムを構築するためにできることはたくさんあるとわかります。しかし、このようなアーキテクチャをベースにした安全性の要求システムをリリースした経験がないという文化的遺産が混在しています。一方で、まだ解決されていない、認証されていないなど、自動車の具体的な問題もたくさんあるわけです。ですから、私たちは今、非常に興味深い技術的転換期にいるのです。

レイモンド・イン：
そうですね。自動車業界全体が、そして自動車そのものが、コネクテッド化、自律化、電動化という大きな転換期を迎えているのは明らかです。つまり、全体が変化しようとしています。これまでも変化してきましたし、当分の間は変化し続けると思います。

クリスチャン・ウーバー：
はい。それから安全性やジッター遅延など、今お話ししたような技術的な課題があります。そして、これらの影響や引き合いが入ってきます。例えば、インフォテインメントに対する要求は、シャシーに対する要求とはまったく異なることがよくあるのです。また、現在注目されているのは、パワートレイン・アクチュエーターや、高価な車の電気モーターをホイールごとに一つづつビークルダイナミクスなどといかに統合するかということです。そして、ブレーキとパワートレインという従来の領域を超えて、それらを結びつけると、車両全体にわたって最適化できる非常に厳しい制御問題が発生します。ですから、興味深いことがたくさん起こっています。そして課題も独特です。例えば、最初に仮定したのは、「インフォテインメントとドライブアシスト、あるいは自動運転のためにGPUを共有するのは素晴らしいアイデアではないか」ということです。

レイモンド・イン：
そうですね。

クリスチャン・ウーバー：
基本的に同じ種類の資源ですから。そして、それを共有する方がはるかにコスト効率がよくなるのではないかと。そして、これが実現しないとは断定したくありませんでした。ですから、私たちはこれに対して有望なアプローチをいくつも探しました。けれども現在の市場全体の状況を見ると、自動車メーカーにとっては最良のものではなく、最悪のものだったのです。実際のADAS（先進運転支援システム）機能に使えるようにするには、SOC（システム・オン・チップ）サプライヤーに安全認証のための追加料金を支払わなければならなかったためです。つまり、費用対効果が得られなかったのです。一方で、ADASシステムをインフォテインメント・システムから保護する必要があるため、アーキテクチャに多くの障害が追加されました。そして、多くの自動車メーカー、特にコストに敏感なメーカーから「これはインフォテインメント専用だから、その間で私たちエンジニアが対応すべきことはない。」とこう言われるのも理にかなっています。アンドロイドなどを導入すればいいだけです。もしメーカーが運転支援機能を購入するのであれば、これは別のSOCか別のコアになります。現時点では、このような統合されたアーキテクチャのコスト上のメリットは実現されていませんが、将来的にも実現できないと断定したくはありません。

クリスチャン・ウーバー：
しかし、要求は実にさまざまです。つまり、インフォテインメントにおける最大の要求は、技術の進歩に遅れずについていくことです。システムをアップデートすること、OEMによってリリースもテストさえもされていないアプリを提供する事ですが、アプリをアップロードし販売できる、堅牢なフレームワークを提供しています。これは、メーカーが持つ他の多くのニーズとまったく異なるニーズです。　

レイモンド・イン：
そうですね。つまり、インフォテインメント・システムは、スマホやウェアラブル端末のような消費者向けデバイスに近いもので、それに対して車の他の部分は、安全重視の自動車システムの領域にまだ存在しているということですね。

クリスチャン・ウーバー：
まさにその通りです。

レイモンド・イン：
マイクロコントローラーからより高度なコンピューティング、あるいはGPUタイプのプラットフォームへの移行について話してきましたが、このような新しいアーキテクチャや新しいプラットフォームに対応するために、エンジニアは車載用のコードを書き直さなければならないのでしょうか？これらの新しいタイプのアーキテクチャや新しいプラットフォームに対応するために、自動車用コードは文字通り何十億行にもなるのでしょうが、そんな書き換えが可能なのですか？

クリスチャン・ウーバー：
簡単に言うと、答えはノーです。とはいえ、非常に興味深い質問なので、ウィンドウ・アクチュエータの例に戻りたいと思います。ボッシュでは以前、ノマディック・ファンクションと呼ばれる、現在私たちのポートフォリオのハードウェアの一部と緊密に結合しているファンクションを特定するための演習を行ったことがあります。必要な場所に簡単に移動できるという前提があるものです。

レイモンド・イン： 
はい。

クリスチャン・ウーバー：
例えば、窓が閉まっている場合の安全対策として、アクチュエーターは単純に電流が増加し、即座にアクチュエーターを停止させます。この機能は非常に些細なものなので、どこでも実行できるのです。実際に実行するためのコスト計算をするなら、この機能を引っ張ってくるだけです。それ自体は本当に些細な機能ですがそれを中央のデバイスで実行すると、突然、あなたの命が危険にさらされることになります。その間にある接続バスが時々応答しなくなったり、システム上で何をするにしても、あなたの手が血で染まるのを防ぐために、必要なときにブロックされる可能性があることを証明しなければなりません。そして、この機能の移行にかかる総費用は、計算方法にもよりますが、費用対効果はまったくないのです。
つまり、機能的には些細なことなのですが、非機能的な要件がすべて付随している別のデバイスに移行することは、費用対効果はありません。そこで私たちは、何が移行できるか、何が可能かなど、この種の分析を多く行いました。その結果、当初考えていたほど経済的に意味があるものは見つからなかったのです。特に安全性に関しては。
一方、セントラル・デバイスに多くのものを集中させるようになり、セントラル・デバイスがCPUやGPUのような資源を多く持つようになった場合、議論しましたように、制御機能のクラスによっては最適とは言えなくなります。ですから関数を書き直すことも、新しいプラットフォームに移行することも意味をなしません。技術的にはハードウェア・ソフトウェアは、他に何もないと適合しないからです。そこで私たちは、この機能の移行をより簡単にする抽象化レイヤーが必要だと考えました。
しかし、抽象化レイヤーは、CPU上で制御のような機能を効率的に実行したい場合、そのために作られたのではない動作モードでCPUを使うことになります。特に設計者としては、非機能要求の観点から懸念事項の分離を行うべきだという、より微妙な見解を持つようになりました。そして、機能というものを見てみると、機能は一つのものではありません。従来、ある部門には、ある機能を担当する人たちがいて、その人たちは機能を実装するのに一つのデバイスを持っていました。これがマイクロコントローラーだとすると、彼らが行うことはすべてマイクロコントローラーのロジックのようなもので、私のアクティベーションは20ミリ秒とか、60ミリ秒とかでしょうか。そして、彼らが行うことはすべて、そのような考え方と統合の枠組みの中で行われます。機能そのものを見てみると、機能が行うことすべてが必ずしも時計仕掛けのような定期的な起動を必要とするわけではないことがわかります。
車両のコンピューターの他の機能と通信する部品とか、そういうものがたくさんあるのです。そして、そのようなものを取り出して、機能の別の部分にある車両コンピュータに置くことができるのです。例えば、常に安全な状態を維持するための高精度アクチュエーター制御です。アクチュエーターの近くにあるゾーンコントローラーにその機能を持たせ、そこでその機能を実行させます。重要なのは、すべてをどこにでも移動できるようにすることではなく、機能以外の観点から実際に問題を見てみることです。どの部分がマイクロコントローラー上で実行する必要があるかと。例えば、ワークロードのどの部分がGPUやCPUに適しているのか。また、GPUやAIアクセラレータで実行することで本当に恩恵を受ける知覚を含むような新しいユースケースを見た場合、それをマイクロコントローラで開発・展開するのは全く適していないのです。ですから、このような事はすでに起こっているわけです。重要なのは、実行プラットフォームのようなマイクロコントローラから本当に恩恵を受ける必要があるものを持つ機能を分割し、ハードウェアが提供するものとソフトウェアが必要とするものの最適なマッチングを考え、マイクロコントローラ上でそれを実行させることです。

レイモンド・イン：
残りの議論に移る前に、ゾーン・アーキテクチャに関する記事のひとつに少し触れてみましょう。「仮想化とソフトウェア・デファインドカー」という記事では、ゾーン・アーキテクチャと単一または少数のCPUに制御を集中させる設計のトレードオフを強調しています。完全な自律走行型とコネクテッド、ソフトウェアデファインドビークルにおいて5億行のコードをどのように処理するのが最善なのでしょうか？記事全文はmouser.com/empowering-innovationにアクセスされるとお読みになれます。

さて、それではクリスチャンさん、水晶玉を取り出していただき、あなたの未来予測をお聞かせください。
現在は2024年です。自動車メーカーは何年も先を見据えて取り組んでいるでしょうから、技術的な観点からすると、2027年ー2028年モデルに今取り組んでいるかと思われます。それよりさらに10年先の2034年モデルを取りあげましょうか。本日お話しいただいた変化が業界全体で2034年モデルにはどの程度、実装されているとお思いですか？

クリスチャン・ウーバー：
10年というのは長いですから、難しいですね。Dockerをご存知の方は多いと思います。この会社とテクノロジーはデータセンター分野のすべてを変えました。しかし発明からわずか6年で、会社自体も、市場では多かれ少なかれ無意味な存在になってしまいました。なぜなら、みなが同様の技術を使っていましたが、異なる技術セットでしたから。10年というのは長いです。私が思うにはマイクロコントローラーはこれからも残るという事です。それは、自動車における特に安全性が重要な制御分野の問題に非常に適しています。アクチュエーターに近いところでは、ゾーン・アーキテクチャが非常に普及するでしょう。ほぼ完全に集中化されたオプションも出てくると思います。また、システムの大部分において、ハードウェアとソフトウェアの分離がより改善されるでしょう。私たちがうまく仕事をすれば、車両内で機能をホストする場所を見つけようとする機能アーキテクチャから進んで、それらをよりよく分離することになると思います。そして、車両の周囲で何が起こっているかを常に監視する、非常に大規模で専門的なAIかGQアクセラレーターを持つことになるでしょう。私はこれはOEMが現在認識していない、未開拓の価値の多くだと考えています。高解像度センサーが常に外界を向いていて、何百万台もの車両で常にセンサーの入力から価値を生み出すAI機能があるかもしれません。Googleストリートビューライブのようなものです。どこかに行くと、二か月前や一年前の写真を見るのではなく、実際にそこで何が起こっているかをほぼリアルタイムで見ることができ、それは車両が必要に応じて起動し、そこで何が起こっているかをアップロードし始めることで合成的に生成されると思います。
その点では、未開発の可能性がたくさんあると思います。そして、今から10年後の良いシナリオは、懸念事項の分離が非常にうまくいくことです。マイクロコントローラーに配備すべきものの実装方法を学ぶでしょう。おそらく、集中型の車両用マイクロコントローラー・ファームができ、そこでマイクロコントローラーのために多くの呼び出しが多数ありますが、それらは同じパッケージ上にあります。帯域幅の広いバックボーンを帯状に配置し、車両内のさまざまなセンサーエリアを、干渉のない堅牢な接続と遅延保証で結びます。エッジスタックとインフォテインメントについては、二つのシナリオがあります。低コストのシナリオはSDVです。インフォテインメントだけです。つまり、二つの世界を持つということです。インフォテインメントとそれ以外の部分です。車両の残りの部分は古典的なプラットフォーム・スタイルです。高速アクチュエーションが必要な場所では、インフォテインメント領域で実現します。アンドロイド・オートか、あるいは接続されたスマホを使えばさらに安価になります。そして、ここでSDVが実現します。充電コントローラーも更新され、そこには多くのものが展開されています。 今日のプレミアム製品のような大型インフォテインメント システムを使用すると、さらにプレミアムな方法があるかもしれません。これには、展開が非常に簡単なSDVのようなエッジ スタックも含まれる可能性があります。 また、車両機能も追加されます。しかし、それはマイクロコントローラーの領域外であればどこでも可能でしょう。使用している特定のハードウェアと強い結合を持つことは非常にまれになると思いますし、これはマイクロコントローラーでしか見られません。

レイモンド・イン：
私たちが話してきたことの多くが、うまくいけば実装されるような感じですね。あなたがおっしゃったように、テクノロジーの世界では10年は長いです。
さて、本日のエピソードはここまでです。次回は、ETASのクリスチャン・ウーバー氏との対談の締めくくりとして、ソフトウェアデファインドビークルのコードを書く、更新する、そして考えるために必要な変化を探ります。また、アプリケーション・コードの開発者とマイクロコントローラー・コードの開発者の間の変化についても触れる予定です。これらすべてと「Empowering Innovation Together」シリーズ全体は、mouser.com/empowering-innovationでご覧いただけます。