自動運転ソフトウェアとハ​​ードウェアのデカップリング技術とその動向に関する研究

「ソフトウェア デファインド カーの時代において、ソフトウェアの地位はますます高まっており、スマート カー業界の発展にはソフトウェアとハ​​ードウェアの分離が必要です。」

上記と同様 これは皆さんもご存じかと思いますが、ここ数年のスマートカー開発で、自動車のサプライチェーンの構成は激変し、ソフトウェアとハ​​ードウェアの分離が進みました。この問題は、OEM とサプライヤーの両方が解決しようとしている問題です。

しかし、規格の統一は依然として難しく、インターフェースも各社で異なります。あれから何年も経った今でも、ソフトウェアとハ​​ードウェアの分離は依然として多くの困難に直面しています。

01 ソフトウェアとハ​​ードウェアの分離の背景

EE アーキテクチャの進化

(このトピックに詳しい読者はスキップして、次のセクションに直接お進みください)

数年前、車両には 12 個ほどの ECU しかありませんでした。 . 20 ですが、電子エンターテイメントの消費主義が人々の生活のあらゆる側面に侵入し続けるにつれて、人々の車に対する機能要件は徐々に増加しています。分散アーキテクチャのコンテキストでは、各新機能には対応する機能の継続的な追加が必要です。ECU。これは自動運転車に特に当てはまり、その結果、自動運転車に搭載される ECU の数は、多くても 100 ～ 200 近くまで増加しています。

ECU の継続的な増加により、データ送信に使用されるワイヤー ハーネスの全長と総コストが増加し続けています (Zos Automotive Research の計算によると、現在の分散アーキテクチャが自動運転の実現により、自動車のワイヤーハーネスのコストは 1,000 米ドルを下回ることはなく、サプライヤー管理の難しさも増しています。

さらに、分散アーキテクチャの下では、ACC と AEB の機能はセンサー (内部の MCU) にバインドされており、互いに分離されています (これは、均一性の原則（人間が運転する場合には当てはまりません）、高度な自動運転の要件は、各機能が有機体であるため、同じ SoC を介して実装する必要があることです。

これに関連して、スペース利用率を向上させ、限られたスペース内で ECU のパフォーマンスを最大化する方法が、業界の次の開発の方向性になりました。その結果、車載用 EE アーキテクチャは分散型アーキテクチャから集中型アーキテクチャへの進化の扉を開き、そのためにドメイン コントローラが誕生し、多くの ECU がドメイン コントローラに置き換えられ始め、メイン制御チップが旧バージョンからアップグレードされました。以前の MCU から SoC へ。

ECU は減り続けており、車に残っている ECU も、計算の一部を担当するものから、実行機能のほとんどを実行するだけでよい「ネジ」に変わりました。処理能力が弱くなっています (ECU には計算を処理する本来の能力がまだありますが、機能的に計算の一部を処理する必要はなくなりました)。

EE アーキテクチャは分散型からドメイン集中型に進化し、SoC が MCU に取って代わり、自動車業界が「ハードウェアが王様」の時代から「」の時代に移行するための前提条件を生み出しています。ソフトウェア デファインド カー」をドメイン全体で実現します。

SoC チップは、DSP、GPU、NPU などの複数のモジュールを統合しており、制御ユニットだけでなく、多数の演算ユニットも統合しています。これにより、SoC チップはマルチタスクを同時に実行できるだけでなく、大量のデータを処理する機能も備えることができます。一部の MCU を SoC チップに置き換えることは、会社の複数の部門の普通のリーダーを、1 人でも 100 人にも匹敵する超優秀な CEO に置き換えることに似ています。

ハードウェアが王様の時代では、ソフトウェアとハ​​ードウェアの高度な結合により、OEM はまず、自動車の機能要件に関する分析レポートを作成してくれるコンサルティング会社を見つけます。今後 5 ～ 8 年間、その後レポートに基づいて 5 ～ 8 年間のソフトウェアとハ​​ードウェアの統合計画を策定します。ソフトウェアとハ​​ードウェアが生産ラインに導入されると、自動車メーカーがさまざまなコンポーネントを取り付けて車両を出荷するまで、5 ～ 8 年以内に車両のソフトウェアまたはハードウェアを変更することは困難になります。

ソフトウェア デファインド カーの時代においても、元の自動車工場の統合プロセスに従い、5 ～ 8 年間の自動車製造計画を一度に設定した場合、最初の数年間で車両製造から何年も経っているため、問題はまだそれほど顕著ではありませんが、この計画の期間の後半で車がユーザーに引き渡されるときには、車のハードウェアとソフトウェアの両方が大幅に古くなります。 。

したがって、製品設計段階では、その後の反復の問題を考慮する必要があります。反復問題を解決するには、ソフトウェアとハ​​ードウェアを別々に開発する必要があります。

さまざまな自動車メーカーのハードウェア構成が統合され、ハードウェアが「ロール可能」になった場合、差別化を図るために、OEM は非常に迅速な対応能力でユーザーの変化するニーズを収集できる必要があります。そして、対応するソフトウェアの反復を実行します。現時点で、OEM には 2 つの選択肢があります: 1 つはソフトウェアとアルゴリズムを自社開発し、ソフトウェアとハ​​ードウェアの分離を含むすべての問題を自分たちで解決すること、もう 1 つはソフトウェアとハ​​ードウェアを分離した後に反復要件を提供する適切なサプライヤーを見つけることです。

最初の道を選択する場合、OEM は非常に強力である必要がありますが、すべての OEM がそのような能力を備えているわけではないため、ほとんどの OEM は 2 番目の道を選択するでしょう。その結果、ソフトウェア アルゴリズム企業の地位は向上し始め、自動車サプライ チェーンの関係は、当初の明確な Tier1、Tier2、Tier3 から、境界があいまいな関係へと変化しました。

これに関連して、より強力な競争力、より優れた独立開発、より優れた協力エコシステムを達成するために、ソフトウェアとハ​​ードウェアのサプライヤーもソフトウェアとハ​​ードウェアを分離する必要があります。

しかし、ソフトウェアとハ​​ードウェアの分離というスローガンが数年にわたって叫ばれてきましたが、その効果は理想的なものではありません。

センサー、チップ、アルゴリズムを分離することは困難です

アルゴリズムとセンサーは高度に拘束されているため、実際にはこのようなバインディングは、アルゴリズム エンジニアに多大な問題を引き起こします。例えば、これまで車に搭載されていたカメラを200万画素から800万画素に変更した場合、アルゴリズムを書き換えてはいけません。

さらに、ある Tier1 アルゴリズム エンジニア:

「たとえセンシング アルゴリズムとセンサーを分離する能力があったとしても、分離後に何が起こるでしょうか? センサーを校正するのも非常に困難です。」

ソフトウェアとハ​​ードウェア間の高度な結合により、センサーのデータも高度に制限されます。センサーを交換すると多額の費用がかかり、アノテーションされたデータはすべて無効になり、新たな収集を開始しなければなりません。これはアルゴリズム会社にとって非常に面倒なことです。しかし、現時点ではこの問題に対する良い解決策はありません。

また、車両ごとにセンサーの構成や取り付け位置、取り付け角度が異なるため、アルゴリズムも異なります。センシングアルゴリズムも異なりますし、制御アルゴリズムも異なります。

アルゴリズムとセンサーの分離が単に面倒であるとすれば、アルゴリズムとチップの分離は非常に困難です。

たとえば、著者がソフトウェアとハ​​ードウェアのデカップリングに関連する問題について多くのアルゴリズム エンジニアとコミュニケーションを取ったとき、彼ら全員が抱えている共通の問題点の 1 つが次のとおりであることがわかりました。アルゴリズムの移植に伴い、多くの追加作業が行われました。

これは、アルゴリズムの移行の頻度が予測できないためです。チップ メーカーの競争や製品の反復は市場の好みに影響を与えることが多く、次のトレンドでより優れた新しいチップが売れ筋になるかどうかはわかりません。

市場の好みの変化により、OEM は交換用チップを指定するようになります。現時点では、アルゴリズム エンジニアにとって、このチップに基づくアルゴリズムが改良されたばかりで、新しいアルゴリズムの移植要件が発生する可能性があります。

上記の現象の理由は、アルゴリズムとチップ間の強い結合関係にあります。異なるチップは異なる BSP を提供するため、チップとアルゴリズムを分離するために使用されるミドルウェアを再利用することが困難になり、チップごとに異なるカスタマイズされた適応を行う必要があります。

某 OEM のインテリジェント ドライビング システム担当者は次のように説明しました。

「BSP 下位層へのミドルウェアの適応」 」

##チップ プラットフォームの違いにより、ミドルウェアの再利用が妨げられるだけでなく、同じチップ プラットフォームに基づく 2 つのドメイン コントローラーのハードウェア アーキテクチャも異なります (一部のドメイン コントローラーでは、2 つまたはさらに 1 つのハードウェア アーキテクチャが存在します)。 3 SoC）、ミドルウェアの要件も異なります。

02 ソフトウェアとハ​​ードウェアの分離が直面する技術的ジレンマ

ミドルウェアはソフトウェアとハ​​ードウェアの分離を実現するために必要な最も重要なツールであるため、問題はソフトウェアとハ​​ードウェアの分離はミドルウェアに集中します。

現在のミドルウェアは、実際には機能、ハードウェアプラットフォーム、オペレーティングシステムに応じてカスタマイズする必要があり、最も標準化されたミドルウェアであっても、アルゴリズム会社やOEMが適応させる必要があり、ミドルウェアがあるとは言えません。それはすべてをカバーします。すべてのミドルウェアには何らかの制限や制限があるため、たとえば、通信インターフェイスを迅速に定義できないもの、一部のクロスプラットフォーム サポートに特に適していないもの、他のチップにうまく適合しないものなどがあります。

ミドルウェアに関しては、データ伝送自体から、データの偏向、データエラー、単一モジュールの障害など、データ伝送に影響を与える問題が発生します。例えば、SOME/IPでデータ収集を行う際、データ送信量が多い場合、多くの通信信号が収集できず、パケットロスが発生しやすくなります。

さらに、データ返送エラーは簡単に一連の連鎖反応を引き起こし、最終的には意思決定と実行レベルに影響を与え、悪影響を引き起こす可能性があります。データ共有にはメリットとデメリットがあり、理論的には効率が向上しますが、ソースが間違っているとエラーが続出し、効果的な診断と修正の仕組みが不足していることもあります。

さらに、時間と場所もデータ送信に影響します。たとえば、高速では、Autosar AP のデータ伝送帯域幅に対する要件が高くなりますが、このとき、帯域幅伝送プロトコルとデータ同一回線伝送の間の競合が特に顕著になります。休日には帯域利用が集中し負荷が高くなり、データ通信のニーズに応えられない可能性があります。

上記の問題に加えて、現在のミドルウェアには、不十分なキャッシュ メカニズム、ネストをサポートしていない機能グループ、貧弱なステート マシンの連携などの問題もあります。これらの問題はすべて、アルゴリズム エンジニアに次のことを要求します。既存のミドルウェアに基づいて変更を加えるため、ソフトウェアとハ​​ードウェアを分離することが大幅に困難になります。

03 ソフトウェアとハ​​ードウェアのデカップリングが直面するビジネスのジレンマ

上記の技術的問題に加えて、ソフトウェアとハ​​ードウェアのデカップリングは一連の課題にも直面しています。ビジネスのジレンマ。

プロのミドルウェア メーカー

Vector、RTI、EB、Yitech に代表されるミドルウェア メーカー各社のソフトウェアとハ​​ードウェアに適応できる標準化されたミドルウェアのセットであり、ソフトウェアとハ​​ードウェアの分離に対する各企業の要求をワンステップで実現します。

しかし、現実は想像ほど美しくありません。一方で、少数の大手ミドルウェア企業を除いて、ほとんどのミドルウェア企業の製品は OEM から真の信頼を得ることが難しく、他方で、ほとんどのアルゴリズム企業はミドルウェア メーカーとの協力にあまり積極的ではありません。なぜなら、ミドルウェアメーカーがインターフェースや実装体系を統一してしまうと、自社製品の代替性が高まり差別化が低下することを意味し、アルゴリズム会社からの競争圧力が一気に高まることになるため、耐性がある。

また、スマートカーの技術開発ルートがまだ明確でない場合、OEMは自社の自動車の構成が競合製品と異なることを望み、競争障壁（アプリケーション層）を獲得することを望んでいます。ミドルウェアの差別化はミドルウェアの差別化によってもサポートされる必要があり、標準化されたミドルウェアはこの欲求に反することになります。したがって、OEM は、ミドルウェア会社が開発した標準化されたミドルウェアを使用するよりも、独自のミドルウェアを開発することを希望します。

最終的に、これらのミドルウェアは販売が困難になり、標準化されたミドルウェアだけを行うことは持続できなくなります。

Jiuzhang Zhijia が学んだことから判断すると、Huayutongsoft などとは別に、DDS などの技術的障壁の高いモジュールに重点を置き、長期的な蓄積によって能力を構築しています。一定の競争優位性がある企業を除き、もともと「ミドルウェアベンダー」として位置づけられていた企業の多くは、基本的にここ1、2年で変革（他分野への進出）を始めている。

サプライヤー

アルゴリズム会社、一部のソフトウェアとハ​​ードウェアを製造するティア 1 企業、チップ メーカーはすべて開始しています。ミドルウェアですが、実際にはどの家庭でも読むのに苦労しています。

アルゴリズム会社

アルゴリズム会社にとって、購入する標準化されたミドルウェアが汎用的すぎる場合、解決できない適応問題は数多くありますが、ブラック ボックスによって提供される汎用ミドルウェアを入手した場合、アルゴリズムとうまく一致せず、アルゴリズム エンジニアに大きな困難を引き起こすことになります。また、カスタマイズされたミドルウェアを購入する場合、アルゴリズム会社もミドルウェア メーカーとのやり取りに多くの時間を費やす必要があり、コストが非常に高くなります。

アルゴリズム会社のエンジニアリング ディレクター:

「問題が発生した場合、通常、会社はミドルウェア メーカーに問題を報告しますが、一部のメーカーでは問題が発生しました。低い場合、アルゴリズム会社は、ミドルウェアの問題であることを証明する実際の証拠を提供する必要があります。そうしないと、より多くの人的資源と時間を消費し、開発プロセスに影響を与えることになります。 #「特に、最近ミドルウェアに取り組み始めたアルゴリズム企業は、ミドルウェアに対する専門的な理解があまりありません。実証的な証拠を見つけるのはさらに面倒で時間もかかります。このプロセスに複数の関係者が協力すれば、 OEM は調整する人を見つける必要があり、その結果、問題解決の進捗はさらに延長されます。

したがって、アルゴリズム企業は、自社のアルゴリズムに適合する独自開発のミドルウェアを開発することを選択するだけです。

さらに、国際的なミドルウェア メーカーも、ミドルウェアは高価であり、国内の新興ミドルウェアメーカーが作ったミドルウェアは、自社のアルゴリズムに基づいて開発されたミドルウェアよりも適さない可能性があることも、アルゴリズム会社が独自のミドルウェアを開発する理由の1つです。

## 「自分で調査すれば、プロジェクトの要件についてさらに詳しく知ることができます。ミドルウェア ベンダーに開発を任せるよりも良いでしょうか?

上記に加えて、アルゴリズム会社が自社開発ミドルウェアを開発する理由はもう一つあります。製品の差別化を図るためのミドルウェア

あるアルゴリズム会社のシニア ディレクターは次のように述べています:

「現状、アルゴリズムの違いは大きく異なります。アルゴリズムはすべて C と C でプログラムされているため、それを示すのは困難です。違いを示すには、ミドルウェアのパフォーマンスを向上させ、信頼性を向上させる必要があります。つまり、機能的なエクスペリエンスにおけるいくつかの利点を強化するため。 ”

ただし、アルゴリズム企業も、自社開発ミドルウェアを開発する際に多くの課題に直面します。まず第一に、OEM の自社開発ミドルウェアはサプライヤーの基準を設定することができ、アルゴリズム企業がそうであれば、独自のミドルウェアを開発する場合、OEM や他のサプライヤーに独自の標準に適応するよう説得するのは困難です。

ある L4 企業のソフトウェア ディレクターは次のように述べています。 #「たとえば、Weilai と Xiaopeng は独自のミドルウェアを作成しています。彼らは自動車メーカーであるため、一連の基準を設定してサプライヤーを制約することができます。しかし、それが自動運転アルゴリズムの会社であれば、サポートを提供します。ミドルウェア 自社のツール セットが他のドメインにも適用できることを OEM に説得したり、OEM の他のサプライヤーに独自の標準に従って統合を実装するよう説得したりするのは非常に困難です。 ”

また、アルゴリズム会社が独自にミドルウェアを開発すると、何か問題が起こっても責めることができません。そのため、アルゴリズム会社にとってミドルウェアの開発は必要です。 .

某メインエンジン工場のインテリジェントネットワーク接続担当主任エンジニアはこう言いました:

「保証サービス契約を締結します」つまり、重大な品質事故が発生した場合、第一責任者は自動車メーカーではありますが、当然のことながら速やかにサプライヤーの責任を追及します。アルゴリズム会社がミドルウェアを開発する場合、一度責任が絡むと責任を回避することはほぼ不可能であり、我々は彼らの責任回避を許さない

チップメーカー

チップ メーカーがミドルウェアを作成する目的は、チップのパフォーマンスを実証することです。 技術的な観点から見ると、チップ メーカーがミドルウェアを作成することは、アルゴリズム会社よりもそれほど難しくありません。アルゴリズム会社はさまざまなチップに適応する必要があるため、その作業負荷はチップメーカーがミドルウェアを作成するよりもはるかに複雑で、チップメーカーが作成するミドルウェアは自社のチップに適応できれば十分です。

にもかかわらず、実際には、チップ メーカーが開発したミドルウェアを使用している人はほとんどいません。

現在、ミドルウェアを製造する主体には、ミドルウェアメーカー、アルゴリズム会社、チップメーカー、OEMなどが知られており、ミドルウェアの市場シェアは非常に細かく分かれており、競争は熾烈を極めています。このとき、完成したミドルウェアを開発したい場合、開発したミドルウェアをどこに販売すればよいでしょうか?ミドルウェアは本当に利益を上げるために使用できるのでしょうか?いずれもミドルウェアを開発する前に検討すべき問題となっている。

アルゴリズム会社の専門家は次のように述べています:

「通常、チップ会社のミドルウェアは使用しません。なぜなら、チップ会社は環境に配慮してミドルウェアを作っているからです。彼らのミドルウェアにはより多くの機能があるかもしれませんが、パフォーマンスが必ずしも最適であるとは限りません。つまり、ミドルウェアには、次のような特徴があります。 AI の抽象化、データ レコードの再生、点群の処理などの多くの機能がすべて実行された可能性がありますが、この場合は問題が発生します。アルゴリズムが元々行っていたすべてのことをミドルウェアが実行してしまい、パフォーマンスが低下します。完全に保証されており、複数のアルゴリズム会社のニーズを考慮する必要があり、柔軟性は悪化します。」

一部のチップ メーカーは、 「ミドルウェアで良い仕事をしているが、市場競争のプレッシャーが高いことを考えると、研究開発には多くの人的資源と物的資源を投資する必要がある。有能なチップメーカーのほとんどは、ミドルウェアで良い仕事をするためにあまり多額の投資をする意欲がない」しかし、ミドルウェア、つまりチップ自体で優れた仕事をすることに重点を置くことを好みます。

したがって、ほとんどのチップ メーカーが自社開発したミドルウェアは非常に軽量であり、基本的には顧客にチップのパフォーマンスをデモするためにチップ上で実行できるデモ ミドルウェアです。このようなデモ ミドルウェアは、ソフトウェアとハ​​ードウェアを切り離すのに実質的な助けにはならないでしょう。

オリジナル OEM

OEM にとって、ミドルウェアのカスタマイズのニーズは常に存在します。

某 OEM のインテリジェント ドライビング システム担当者は例を挙げました:

「たとえば、信号機を書くとき」認識アルゴリズムや両眼視アルゴリズム、従来のアルゴリズムや競合他社のアルゴリズムとは異なるものにしたい場合は、ミドルウェアのデータのサブスクリプション、共有、記録、再生、送信、ストレージ、診断などが含まれる、カスタマイズされたミドルウェアのセットが必要です。しかし、これらの機能は、OEM が要求するシステムまたは機能メカニズムの下で完全な動作を保証することはできません。競合が発生する可能性があります。現時点では、ミドルウェア サプライヤーが解決を支援する必要があります。」 # ただし、より強力な機能を持つ一部の OEM は、サードパーティのミドルウェア会社やアルゴリズム会社のミドルウェアを使用するよりも、独自のミドルウェアを開発することに積極的です。

まず第一に、RTI の DDS などのクローズド ソース ミドルウェアの購入は、多くの場合ミドルウェアのカスタマイズを意味し、より高価なコストが必要となるだけでなく、プロジェクトのドッキング サイクルも遅延します。対照的に、自社開発のミドルウェアは、カスタマイズの方向を完全に制御し、独自のデータを取得し、製品を無制限に作成できることを意味します。これにより、製品開発プロセスとその後の変換をより適切に制御し、起こり得る問題を解決できます。特定ミドルウェアサプライヤーの故障による量産納期遅延の影響。

次に、自社開発のミドルウェアは、OEM にとって特定の技術的障壁となる可能性もあります。一部の強力な OEM では、一部の上位層アプリケーション層を完全に独自に管理しています。上位層アプリケーションのニーズに応じて独自のミドルウェアを作成したり、一部のミドルウェアをより適切にカスタマイズしたりできます。上位層アプリケーションでもいくつかの機能を作成できます。 。

実際、ミドルウェア テクノロジがまだ成熟しておらず、将来のトレンドがまだ十分に明らかになっていないときに、業界の上流および下流の企業がミドルウェアを作成する理由は、ミドルウェアの境界をテストするためです。 2 つ目は、業界全体の境界を探索することです。

しかし、OEM のオートパイロット エンジニアの多くは、「アルゴリズム会社と比較して、OEM の自社開発ミドルウェアにはほとんど利点がない」と考えています。

まず第一に、ほとんどの OEM にはアルゴリズム機能の蓄積があまりありません。ミドルウェアの作成に特化したチームを設立するコストは膨大ですが、その結果はこれを専門に行うサプライヤーほど良くない可能性があり、そのような消費によって引き起こされる苦痛は、複数のサプライヤーを調整することによる苦痛をはるかに上回っています。 。それは、自分の弱いプロジェクトによって引き起こされる苦痛が、自分の強力なプロジェクトの新たな挑戦よりも苦痛になるようなものです。

第 2 に、OEM が自社開発のミドルウェアを開発して十分なサンプル フィードバックを得るのは難しく、製品の反復にはつながりません。サプライヤーのアルゴリズムとミドルウェアは誰もが使用するようになり、顧客ベースが増加するにつれて、バグに対する顧客のフィードバック率が高くなり、製品の反復的な進歩につながります。ただし、OEM が独自の製品を開発し、十分なサンプル データが不足しているため、反復が遅くなります。

さらに、主要なエンジン メーカーが独自のミドルウェアを開発したい場合、他社から技術的な人材を引き抜かれることは避けられません。しかし、大企業の一部門に所属しているタレントの場合、そこまで強い使命感を持っていないかもしれませんが、やはり「空は落ちてくる、上にはまだそれを支えてくれる人がいる」という感覚が常にあります。結果的には、採用した人材の能力を8割発揮できれば理想的と言えます。しかし、同じ技術的才能のある人が単独で仕事に取り組み、その研究が個人的な興味に関連したものであれば、間違いなくそれをうまくやり遂げなければならないという大きなプレッシャーとモチベーションを感じることになるでしょう。そのような環境では、彼はより多くの才能を発揮できることがよくあります。

最後に、OEM にとって、自社開発のミドルウェアには研究チームを編成するために多くの人材が必要です。全員が解雇されるリスクがあり、大量の従業員が解雇されると、現従業員の間で「会社が不安定だ」という感情が高まる。

OEM の「自社開発ミドルウェア」は単なるマーケティング スローガンであることが多いようですが、すべての OEM が自社開発したミドルウェアが不可能であるという意味ではありません。 、十分に強力で、成功した自社開発アルゴリズムは、自社開発ミドルウェアで成功する可能性が高くなります。しかし相対的に言えば、独自のアルゴリズムを開発することが難しいほとんどの OEM にとって、ソフトウェアとハ​​ードウェアの分離に関する要件は依然としてサプライヤーによって満たされる必要があります。

04 ミドルウェアは「本来の目的から逸脱している」

ミドルウェアの誕生は、もともとソフトウェアとハ​​ードウェアでは解決できない問題を解決するために生まれました。したがって、ミドルウェアがブロック効果を持ち、プロセスを合理化し、すべてのソフトウェアとハ​​ードウェアに適応でき、上位レベルのソフトウェア アプリケーション エンジニアが安心して仕事を行えるソフトウェアになることを当初は期待していました。ハードウェア適応の問題、アルゴリズムについて。

しかし、現実は当初の願いとは裏腹です。

一方で、ミドルウェアは高度なカスタマイズを示します。

アルゴリズム会社のソフトウェアアーキテクトは次のように紹介しました:

「各車種または各チッププラットフォームに合わせたミドルウェアの適応、機能は異なります」 、提供される基盤となるソフトウェアは、ミドルウェアに対する適応性が異なります。たとえば、一部の車両は QNX オペレーティング システムを使用し、一部の車両は Linux オペレーティング システムを使用します。これら 2 つのオペレーティング システムには、ミドルウェア用にいくつかのカスタマイズがあります。Content.

「基盤となるオペレーティング システムに加えて、ソフトウェア アプリケーション層にはミドルウェアに対するいくつかの差別化された要件もあります。たとえば、特定のプラットフォームに基づいて、特定の特別な機能を有効にする必要があります。通信方法、従来のイーサネットのような一般的なリンクではなく、PCIe やメモリなどの特殊なリンクを通じてデータを送信する必要があるため、ミドルウェアがさまざまなリンクをサポートできるようにミドルウェアをカスタマイズする必要があります。

「一部の自動運転ソフトウェア メーカーまたは OEM は独自のログ記録方法を持っていますが、一部のメーカーはそうでない場合があります。ログ記録機能を提供するにはミドルウェアが必要であるため、さまざまなユーザーに応じて、ミドルウェアは対応するものを生成します。

カスタマイズとは、標準化以外の要件を満たすためにミドルウェア メーカーが人員を割り当てる必要があるかどうか、またはアルゴリズム会社/ホスト メーカーに専用のドッキング アルゴリズムを送信するよう依頼するかどうかを意味します。エンジニアがミドルウェアへの個別の適応調整を行うには、追加の人的資源と物的リソースが必要です。

そして、カスタマイズされたミドルウェアにより、アルゴリズムがデータを解析する際に新たな困難が生じます。

OEM のエンジニアは率直にこう言いました:

「V2X を量産車に搭載する場合、さまざまなブランドのミドルウェアが必要になる」 "

車種が異なると、QoS (サービス ポリシー) が異なり、データの解析に問題が発生します。そのため、車両間の通信に問題が発生する可能性があります。"

###Another 一方で、「AUTOSAR 標準を回避して独自に作成するプレーヤーが増えています。ミドルウェアも AUTOSAR 標準に従って作成されている場合でも、カスタマイズの度合いも非常に高くなります。」某OEMのシステム専門家はこう語る。あらゆる企業が独自のミドルウェアを開発している現在、ほとんどのミドルウェアは自社のアルゴリズムやインターフェースなどにのみ適応しており、不整合現象は悪化の一途をたどっています。 ######

メインエンジンメーカーであっても、アルゴリズム会社であっても、ミドルウェアが使いやすいか、ソフトウェアとハ​​ードウェアが切り離されているかではなく、実際の課題を解決できるかどうかがプロジェクト協力時に最も重要視されます。問題が発生しました。購入したミドルウェアで問題が解決せず、期待した効果が得られなかった場合、両者はオリジナルのミドルウェアをベースに様々な内容を修正・追加する必要があり、「結合」が継続する状況が発生します。避けられない現象となっています。

ですから、プロセスを簡素化し、作業負荷を軽減するというミドルウェアの本来の目的を思い返すと、ため息をつかずにはいられません。

05 ソフトウェアとハ​​ードウェアの分離をどのように達成できるでしょうか?

では、ソフトウェアとハ​​ードウェアの分離を実現したい場合、どのような角度から始められるでしょうか?

一方で、ハードウェアの仮想化は最初にオペレーティング システム レベルで実行でき、インターフェイスや通信プロトコルなどを標準化できるため、上位層のアプリケーションは必要ありません。基盤となるシステムのさまざまな問題を考慮するには、チップメーカーとオペレーティングシステムメーカーの間の綿密な協力が必要であるか、チップメーカーが独自のOSを開発しているため、依然として多くの困難があります。

一方、ミドルウェアの将来の形はまだ不透明ですが、確かなことが 1 つあります。

#1. ミドルウェア ベンダーは、Autosar 自体をベースにして Autosar を簡素化するツール型のミドルウェアを開発します。 Autosar自体は非常に複雑なため、技術者が習得するのは容易ではないが、簡易版の開発ツールが提供できれば、自社開発が必要な上流メーカーや下流メーカーにも提供するとよいだろう。ミドルウェアが独自に開発したミドルウェア プロセスを最適化するという選択肢があります。

2. ミドルウェアメーカー、メインエンジンメーカー、サプライヤーがミドルウェアアライアンスを形成し、チップ工場またはメインエンジン工場が中心となってルールを統一します。市場の境界を試す際には、非常に強力なOEMやチップ工場が主導権を握り、業界アライアンスの統一規格を形成し、OSやインターフェースなどを統一して業界標準を形成することになる。

3. 完全なオープンソース: チップ会社が独自の OS を作成し、上流および下流の企業がこれに基づいて開発できるようにします。チップ メーカーは、NVIDIA の CUDA のようなオープン ソース ツールキットを作成します。これは、独自の OS とミドルウェアを開発するだけでなく、完全にオープン ソースでもあり、上流と下流の顧客がツールを一緒に使用して、適応開発を改善し、優れたエコシステムを確立できるように支援します。

4. サービスとして、カスタマイズされたミドルウェア サービスと保守作業をサプライヤーに提供します。市場の上限が低く、ミドルウェアを統合することが難しいため、ミドルウェアは独立した製品ではなく、カスタマイズされたサービスになる可能性があります。ミドルウェア メーカーはミドルウェア研究の経験に優れているため、このようなカスタマイズされたサービスを提供するのに有利な立場にあります。

かつて、さまざまな携帯電話ブランドが全盛でしたが、2005 年から 2010 年にかけて、「レンガフォン」とスマートフォンが並走していた頃は、市場には 200 種類の携帯電話インターフェイスが流通しています。携帯電話のブランドが異なれば、充電インターフェースも異なり、ヘッドフォンインターフェースも異なり、同じ形状でサイズが異なる大小さまざまなインターフェースがあり、同じブランドの携帯電話であっても充電インターフェースが異なります。

当時、デジタル専門家は出張の際、充電器を5～6種類、ケーブルを5～6本持っていくことがよくありました。たとえユニバーサル充電器が登場したとしても、タブレット端末のバッテリーを引き抜いて充電するしかなく、スマートフォンの充電ポートとヘッドフォンジャックのサイズが異なるという問題は依然として解決されていません。

このような混沌とした無秩序な時期は、現在のスマートカーの開発と同様に、携帯電話の普及後、携帯電話技術の発展が最も輝かしく活発な時期でもあります。 。現在、携帯電話のインターフェースは基本的に統一されており、数百社の携帯電話メーカーが自主研究の過程で徐々にその数を減らし、最終的に市場の最終決定の下で標準を形成しました。

スマート カー業界は、家電市場、特に携帯電話市場の影響を深く受けています。過去 2 年間、業界の誰もが非常に衝動的であるように見え、誰もが迅速に進歩することを熱望しています。終了状態。短時間でマスターを選択することを望んでいます。しかし、自動車製造業界は実は遅成長産業であり、車両の生産から量産、そして消費者市場に至るまで、数千万のユーザーからのフィードバックを収集することによってのみ、継続的に最適化を図り、標準を形成することができます。そしておそらく現時点でのみ、ミドルウェアが真に統一されて標準を形成できるのでしょう。

将来技術が成熟すると、ミドルウェアはASICチップ上に固められた基本ソフトウェアとして利用される可能性があり、ミドルウェア単体の形で登場しなくなるかは不明。

06 最後に一言

とはいえ、そうは言っても、関係者全員が多くの困難に直面している現在、ミドルウェアは適切でしょうか？誰がやるの？

全体として、標準のミドルウェアを使用してソフトウェアとハ​​ードウェアの分離を完全に実現するという目標を目指す場合、最も適切なミドルウェアは実際にはチップ メーカーです。

理由は 2 つあります。まず、アルゴリズムの適応は最終的にはチップ プラットフォームに基づいており、チップが基礎となります。第二に、チップ企業の数はアルゴリズム企業に比べて少なく、それらを統合することは比較的難しくありません。

しかし、現在、誰もがカスタマイズを期待しているという前提に基づいて、カスタマイズされたミドルウェアに最も適しているのはアルゴリズム会社です。

「チップ企業は、検証メカニズムを追加するかどうか、BSP をスケジュールして高速化する方法など、チップ自体のアプリケーションにより注意を払っています。チップ企業はこれらの要件を実装できます。 「しかし、チップ会社はアプリケーションを制御することはできません。ソフトウェアとミドルウェアはより優れた最適化提案を提示し、クライアントは成熟したソリューションのみを使用できますが、このソリューションはソフトウェアのすべてのニーズを満たすことができない可能性があります。」

ご覧のとおり、アルゴリズム社は実務上最もカスタマイズの依頼が多く、ミドルウェアの適応も最も求められる役割です。カスタマイズしたミドルウェアを直接作成できるのが最も便利です。独自のアルゴリズムに適応します。

某 OEM のチーフエンジニアも同様の見解です。

「今のところ、上位レベルの機能サービスに比較的重点を置いています」 、および自動運転ソリューションの供給プロバイダーは、アプリケーション層からの機能的アプリケーションと抽象的なミドルウェアを深く理解しており、基礎となる主流のチップハードウェアソリューションプロバイダーとよりよく一致することができ、全体的なソリューションはより合理的です。」

以上が自動運転ソフトウェアとハ​​ードウェアのデカップリング技術とその動向に関する研究の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。