インテリジェントな運転には、さまざまな専攻の人々が協力する必要がありますが、誰もがソフトウェアや自動車ソフトウェアのバックグラウンドを持っているわけではありません。さまざまな背景を持つ人々が記事の内容をある程度理解できるように、この記事では非常に一般的な言語を使用して説明するよう努め、さまざまな写真を使用して説明します。この記事ではあいまいな用語の使用を避け、すべての用語には初めて出現するときに正確な定義が示されます。
インテリジェント運転の概念モデルは、次の 3 つの主要な質問を単純に解決します:
#1. ここはどこですか?
2. どこへ行くのですか?
3.そこに行くにはどうすればよいですか?
「ここはどこ?」という最初の問いは、「環境認識」と「位置決め」の問題であり、理解すべきはクルマ自身の位置です。位置の周囲の静的環境(道路、交通標識、信号機など)と動的環境(車、人など)です。これにより、さまざまなセンサーやアルゴリズム システムを含む一連のセンシングおよび測位技術ソリューションが誕生しました。
2つ目の質問「どこへ行くの?」 自動運転の分野では「計画と意思決定」です。ここから、「グローバル計画」、「ローカル計画」、「タスク計画」、「経路計画」、「行動計画」、「行動意思決定」、「移動計画」などの用語が派生します。言語的な曖昧さのため、これらの用語の中には、同じ意味を別の言い方で表現するものもあります。また、その一部は、場面によっては似ていてもわずかに異なる意味を持つことがよくあります。
特定の用語に関係なく、一般的に、「意思決定の計画」の問題は 3 つの部分に分類されます。
1 . 一定の範囲内で大局的な意味での計画(一般用語:大域計画、経路計画、タスク計画)
#2. 最初のステップの結果を複数の段階に分割する(一般的に使用される)用語: 行動計画、行動意思決定)
3. 各段階のさらなる計画 (共通用語: ローカル計画、動作計画)
# #これらのさまざまな計画のために、問題を解決するための多くのアルゴリズム体系が導出されています。
3 番目の質問「どうすればよいですか?」は、一般に「実行の制御」、つまり計画の目的を達成するための最小の計画を実際に実行することを指します。特に自動車においては、さまざまな制御アルゴリズムに反映されることが多く、制御理論はこれらの問題を解決します。
これら 3 つの問題の解決策は、最終的にはすべてアルゴリズムの問題であるため、ある意味、自動運転の核心はアルゴリズムです。ある意味、ソフトウェア アーキテクチャはこれらのアルゴリズムを実行できなければなりません。優れた搬送システムがなければ、アルゴリズムがどんなに優れていても役に立ちません。
便宜上、基本概念モデルの 3 つの問題を E として表します。 、P、Xは、それぞれ環境(Environment)、計画(Plan)、実行(eXecute)を表す。 E-P-X の各セットには、それぞれの記述問題スペースがあります。
たとえば、問題空間 A を「北京から広州までの運転」と定義し、問題 E については、位置決めの焦点は北京の現在の地区にある可能性があり、問題はありません。ストリート向けに改良する必要がある。雷雨の有無や、省道上の道路構造情報にも注意が必要だ。質問 P:
P-1: 最初のステップは、どの高速道路、国道、地方道を通るかというグローバル パスを設計することです。
P-2: グローバル パスに基づいて、最初に高速道路のどの交差点に行くか、何キロメートル走行するか、サービスエリアに行って給油するか、別の道路に変更するかなど、一連の行動を計画します。
P-3: 各セクションへの具体的な道路経路を計画します。たとえば、高速道路の交差点まで 3 番目の環状道路を使用するか 4 番目の環状道路を使用するか、
XX をどの方向に変更するかは、P によって計画されたすべての手順を実行する必要があります。
問題空間 B を「交差点を安全に通過する」と定義すると、問題 E では、現在の道路情報、信号情報、道路上の車両の状況、歩行者の状況などに注意を払う必要があります。 。 P の質問の場合:
P-1: 最初のステップは、交通規則と道路情報に従って現在の交差点にどの車線で到達するかを計画するなど、交差点を通過する安全な経路を計画することです。目的の交差点に進入し、どの車線に入るのか。
P-2: 2 番目のステップは、最初のステップの根本的な結果に基づいて、最初に減速する、目標車線を切り替える、停止する、などの一連のアクション シーケンスを計画することです。赤信号を待ち、加速を開始し、交差点を通過します。
P-3: 3 番目のステップは、2 番目のステップの各アクションに対して、歩行者や車両などの障害物を回避できる具体的な軌道を設計することです。
XX は、問題 P の出力を実行する責任があります。
この問題空間 B は、通常の計画アルゴリズムによって解決される問題に最も近いものです。 P-1 の最初のステップは「グローバル計画」または「タスク計画」と呼ばれることが多く、P-2 は「行動計画」または「行動意思決定」と呼ばれることが多く、P-3 は「ローカル計画」または「」と呼ばれます。 「行動計画」。「動作計画」。以下の図に示すように、E-P-X は抽象的な基本概念モデルを形成し、問題空間 A と問題空間 B はその特定の範囲における具体的な実装です。
#図 1 2 つの EPX 問題空間
A と B 両方の問題空間は同様の E-P-X 構造を持っていますが、それらが解決する問題は、非常に異なる時間と空間の範囲に及びます。上の図では、A が行うタスク:実際、下の図に示すように、E-P-X モデルはフラクタル再帰構造です。
#図 2 EPX のフラクタル再帰構造
前のレベル X では、次のことが可能です。実行時には、常に次のレベルでさらに粒度の小さい E-P-X に分解されます。「フラクタル」は、「自己相似フラクタル」とも呼ばれ、物事の部分が全体と似た構造を持ち、異なるスケールで対称であるという理解が一般的です。木の枝も木全体と同様の構造をしており、さらに各葉の茎葉も同様の構造をしています。以下の図は、いくつかの典型的なフラクタル構造を示しています。
#図 3 フラクタルの例
これら 6 つのグラフィックには特徴があります。各図のどの部分も図全体と同じ構造になっています。局所領域をさらに拡大すると、局所領域が同じ構造であることがわかります。したがって、全体に適用できる業務処理ロジックがあれば、部分にも適用できます。いくつかの木を育てるのと同じように、枝を取り出して植えると、新しい木が育ちます。ソフトウェア プログラムにマッピングされた式は「再帰」です。これは再帰関数を使用するという意味ではなく、アーキテクチャレベルの再帰を意味します。
「フラクタル」のより学術的な表現は、「分数次元の遠近法と数学的手法を使用して、1 次元の線や 2 次元の面から飛び出て、客観的な物事を記述および研究すること」です。三次元、さらには四次元の時空の伝統的な障壁は、複雑なシステムの実際の属性や状態の記述に近く、客観的な物事の多様性と複雑さとより一致しています。」 「物理的現実」に適した数式を見つけて、それを「プログラム的現実」に変換すると、より簡潔、明確、正確なソフトウェア アーキテクチャと実装方法が見つかります。
E-P-Xは「物理的現実」に基づいて抽象化された構造です。そして、それらのほとんどはさまざまな種類のアルゴリズム作業です。個々のアルゴリズム自体の研究開発は、事前に定義された入出力条件に基づいて独立して実行できます。しかし、アルゴリズムをどのように組み合わせ、適切なタイミングで正しくトリガーし、結果を合理的に使用して、最終的に実用的な機能を形成するか。 「物理的現実」から「プログラム的現実」への橋渡しの中核となるのは、ソフトウェア アーキテクチャです。
自動運転システムはレベル 1 からレベル 5 まであり、上位になるほど、前述の E-P-X モデルの入れ子が深くなります。ソフトウェア アーキテクチャはさらに難しくなります。ほとんどの単一レベル 1 およびレベル 2 関数は、E-P-X モデルの 1 つの層のみを必要とします。 AEB (自動緊急ブレーキ) を例に挙げます。
E 部分 (知覚): 主に前方のターゲット (車、人) の静的な認識と分類、動的追跡、検出距離と速度。
P パート: AEB は前後方向の制御のみを行うため、すべて速度制御によって実現できます。したがって、一定期間にわたる速度を計画してください。
PartX: 速度計画は車両制御ユニットに任せます。
EPX を 1 層だけ使用すれば、AEB 機能が単純になるというわけではありません。実際、量産可能なAEB機能を実装することは非常に困難です。ただし、第 1 レベルの EPX はシナリオに基づいてスケジュールする必要はなく、単一のシナリオでの EPX の実装に焦点を当てるだけでよく、ソフトウェア アーキテクチャは比較的単純です。第 2 章では、L2 機能の共通ソフトウェア アーキテクチャを紹介します。
最小粒度レベルの EPX サイクルであっても、1 つの EXP 実装でこのレベルのすべての問題を解決できるわけではありません。
例: 単純な直線運転のユースケースでは、車両制御アルゴリズムとしてエンド X ユニットを実装できます。このアルゴリズムは、平坦な道路、上り坂、下り坂のすべてのシナリオを処理します。 . .また、スケジューリングユニット(S)を使用すると、Eユニットの情報に基づいて平坦路、上り坂、下り坂を異なるシナリオとして識別し、次のレベルの異なるEXPサイクルに切り替えることができます。次のレベルの各 EXP ループは 1 つのシーンを実装します。実際、平坦路、上り坂、下り坂のすべてのシナリオを解決するために X ユニット制御アルゴリズムが使用されたとしても、アルゴリズムは依然としてこれらのシナリオを内部的に区別します。実際、それは依然として粒度の小さな EXP ループです。
#図 4 EPX スケジューリング
図 4 に示すように、シーンスケジューリング (S) はあらゆるレベルで実行できます。つまり、「シナリオ」の定義にも細かい区分があります。したがって、EPX モデルは EPX-S モデルである必要があります。 L2 より下には明らかな S セクションがありません。
ソフトウェア アーキテクチャの観点から L1 ~ L3 と互換性を持たせるにはどうすればよいか自動駐車支援機能では、縦列駐車、縦列駐車、縦列駐車などのシーン スケジューリングが必要になり始めています。退出、水平駐車、斜め駐車などはすべて異なるシナリオであり、P 部分と X 部分は別々に実装する必要があります。ただし、シーンのスケジューリングは、「人間参加型」S ユニットである HMI インターフェイスを介して手動で選択できます。
レベル 3 上記機能のうち、長時間の連続運転において手動介入が不要な機能です。必然的に、複数の異なる EXP レベルの自動スケジュールが必要になります。このように、L2以下の機能とはソフトウェアアーキテクチャが大きく異なります。これが、多くの企業が L2 と L3 を 2 つの異なるチームに分割する理由の 1 つです。
実際、ソフトウェア アーキテクチャがマルチレベル EXP-S モデルに基づいて意識的に設計されている限り、各 EXP-S ユニットには適切な実施形態があり、実際に一連のソフトウェア アーキテクチャは、L1 から L3 以上の基本的な自動運転をサポートします。 S ユニットは L2 以下の機能に対して弱いというだけですが、そのアーキテクチャ上のステータスは依然として存在します。
まず、L2 機能の一般的なソフトウェア アーキテクチャを見てみましょう。一般的に使用されるについて話します
AEB/ACC/LKAの3つの機能は、総合システムソリューションL2の最も古典的な運転支援機能です。認識部分では、主に前方カメラから対象物(車両、歩行者)の情報を出力し、前方ミリ波レーダーから得られる対象データと融合することで、より正確な速度や距離を取得します。視覚認識とレーダー認識では主にスマート センサー ソリューションが使用されるため、Tier 1 は成熟した Tier 2 サプライヤーから製品を選択できます。 Tier 1 の主な開発作業は、知覚融合と機能ステートマシンおよび車両制御アルゴリズムの実装です。
オプション 1: 視覚認識結果はレーダー認識コントローラーに転送され、レーダー認識コントローラーは認識融合と L2 機能ステート マシンを完了します。
図 5 オプション 1 のトポロジ
オプション 2: 独立した L2ビジョンとレーダーを接続するコントローラー スマート センサー、L2 コントローラーが知覚融合と L2 機能ステート マシンを完成
##図 6 スキーム 2 トポロジ
両方のソリューションがよく使用されます。ソリューション 1 では、より高性能のレーダー コントローラーを使用し、いくつかのコンピューティング ユニットを割り当てて、フュージョン アルゴリズムと機能ステート マシンを実装します。多くのチップ メーカーは、レーダー処理チップを設計する際に、コンピューティング能力のこの部分を考慮しています。たとえば、NXP の S32R シリーズはレーダー ECU 用に特別に設計されており、その複数のコアはレーダー信号処理と L2 機能の実装を同時に実行するのに十分です。結局のところ、最も計算量の多いビジュアル アルゴリズムは別のデバイス上で完成されます。
オプション 2 は、L2 機能コントローラーを実装するために L2 を分離し、2 台のスマート センサーとのプライベート Can 通信を通じてセンシング データを取得します。一般的に、このソリューションでは、将来的に L2 機能の追加を検討でき、必要に応じてさらに多くのスマート センサーを接続できます。
代表的なソフトウェア アーキテクチャスマート センサーを使用するシステム アーキテクチャでは、前方のスマート カメラと前方のミリ波レーダーがそれぞれの観測環境を提供します。のターゲット オブジェクトのセマンティクス。データのこれら 2 つの部分は、Can バスまたは内部 IPC (コンピュータ OS のプロセス間通信) メカニズムを通じて、知覚融合と L2 機能の実装を担当するモジュールに直接転送されます。
ハードウェア ソリューション 1 であってもソリューション 2 であっても、業界で最も一般的に使用されているソフトウェア アーキテクチャは Classic AutoSar に基づいて開発されています。 Classic AutoSar は、車両 ECU に共通の機能を提供し、リファレンス ソフトウェアの実行環境とデータ入出力チャネルを提供します。知覚融合モジュールおよびその他の ACC/AEB/LKA 機能は、1 つまたは複数の AutoSar SWC (ソフトウェア コンポーネント) として実装できます。各開発者は、これらの SWC コンポーネントを分割するかどうか、また分割する方法について独自の合理的なロジックを持っています。ただし、基本的なアーキテクチャはほとんど同じです。
もちろん、Classic AutoSar を使用せず、他の適切な RTOS を基盤システムとして使用することはできません。一般的な機能を開発し、車両 ECU の機能安全基準を満たすことはより困難になる可能性がありますが、アプリケーション機能開発のアーキテクチャは、Classic AutoSar を使用したソリューションとあまり変わりません。
図 7 ACC/AEB/LKA の典型的なソフトウェア アーキテクチャ
##MBD 開発手法
MBD (モデルベース開発) 手法は、知覚融合アルゴリズム、計画および制御実行アルゴリズム、および ACC/ を実装するために業界で一般的に使用されています。 AEB/LKA機能ステータスマシン。次に、ツールを使用して C コードを生成し、それをターゲット プラットフォームに手動で統合します。 MDB 開発方法の利便性の 1 つは、最初に CanOE などのモデル ツールや機器を使用して車両上で直接開発およびデバッグできること、または開発およびデバッグのためにシミュレーション プラットフォームに接続できることです。このように、開発チームは 2 つの部分に分けることができ、1 つの部分はモデル ツールを使用してアプリケーション機能を開発し、もう 1 つの部分はすべての車両 ECU に必要な一連の退屈なタスクを開発して統合します。 一般に、完全自動駐車製品は、ビジョン アルゴリズム (静的障害物認識、動的障害物認識、歩行者認識) を統合する、より統合されたソリューションを採用します。 、駐車スペースライン認識)超音波レーダーアルゴリズム(距離検出、障害物検出)軌道計画と駐車プロセスの制御実行はすべて1つのコントローラーで完了します。より高度な統合により、自動駐車コントローラーの 360 度サラウンド ビュー機能もサポートされます。これには、カメラのサラウンド画像の補正、2D/3D グラフィックス レンダリング ビデオ出力 HMI 生成およびその他の機能のスプライシングもサポートする必要があります。 ##図 8 駐車システムのハードウェア トポロジ スキーム 典型的なソフトウェア アーキテクチャ 2.1.1 と比較して、最も重要な変更点は、「リアルタイム ドメイン」システムと「パフォーマンス ドメイン」システムの区別です。一般に、MCU またはその他のリアルタイム コア (Cortex-R、Cortex-M、またはその他の同等のシリーズ) 上のソフトウェアおよびハードウェア システムを「リアルタイム ドメイン」と呼びます。 SOC の大きなコア (Cortex-A または同等のシリーズ) とその上で実行される Linux/QNX は総称してパフォーマンス ドメインと呼ばれます。これには通常、ビジュアル アルゴリズム アクセラレーションをサポートするソフトウェアおよびハードウェア システムも含まれます。 量産化の技術的難易度という点では、全自動駐車システムは、ACC/AEB/LKAなどのレベル2予防安全機能に比べてはるかに小規模です。しかし、ソフトウェア アーキテクチャの観点から見ると、駐車システムははるかに複雑です。主に次の側面に反映されます:
#図 9 駐車システムのソフトウェア アーキテクチャ リアルタイム ドメインとパフォーマンス ドメインの分割によりシステムの複雑さがもたらされ、リアルタイム要件とコンピューティング リソース要件に基づいて、さまざまな計算に対して異なるハードウェア プラットフォームを選択する必要があります #パフォーマンス領域で OS に Linux を採用すると、OS レベルの実行環境は RTOS よりもはるかに複雑になります ネットワーク通信機器の分野では、これらは管理プレーンと呼ばれることがよくあります。多くは AutoSar AP によって提供される基本的な機能でもあります。実際、CP AutoSar であっても AP AutoSar であっても、通信を担当するモジュールを除けば、その他のほとんどは管理プレーンの機能です。 車両に複数の L2 機能がある場合に連携する方法。以下の図は、簡略化されたマルチコントローラー トポロジの例です。 #図 10 複数の L2 ファンクション コントローラーとドメイン コントローラーのトポロジ スキーム # ※このトポロジーには6台のコントローラーが統合されており、「全自動駐車システム」、「前方スマートカメラ」、「前方ミリ波レーダー」の機能は前述の通りです。左右のコーナーレーダーはミラー状の2台で、それぞれ独立して動作することで「後車接近警報」や「ドア開警報」などの機能を実現します。 「ドライバーモニタリングシステム」は、ドライバーの状態を検知し、運転中にドライバーが疲れていると判断した場合に警告を発し、ドライバーが完全に動けなくなった場合には、他のシステムに速度を落として路肩を寄せるよう通知する。 このトポロジには次の重要なポイントがあります: 複数の独立運転支援機能コントローラーを接続するためのドメイン コントローラーの導入、およびドメイン コントローラーのバックボーン ネットワークへの接続、複数の Can バス運転支援ドメイン、バス帯域幅の不足を回避します。 ソフトウェア アーキテクチャの観点から見ると、各運転支援コントローラーは独立して動作し、独自の機能の開始と停止を独立して決定します。関連する制御信号はドメイン コントローラーに送信され、ドメイン コントローラーはそれらの信号を電源ドメインに転送します。運転支援ドメイン コントローラーは、個々のコントローラーの制御出力を判断する責任があります。ここでドメイン コントローラーが果たせる役割の観点からは、軽いものから重いものまでさまざまな設計が考えられます。軽量ドメイン コントローラー設計では、ドメイン コントローラーは単純なデータ転送のみを実行し、バックボーン ネットワーク上のデータをフィルター処理して、ドメイン内のコントローラーに送信します。ドメイン内のコントローラーからバックボーン ネットワークに制御信号を送信します。この方法では、ドメイン コントローラーの高い計算能力は必要ありません。 ドメイン コントローラーがさらに多くの作業を引き受ける場合、他のコントローラーのリアルタイム ドメイン部分の計算作業を引き継ぐことができます。たとえば、ACC/AEB/LKA の計画制御計算はすべてドメイン コントローラー上で実行されます。これには、他のコントローラーがセンサー データをドメイン コントローラーに送信する必要があり、そのデータはドメイン コントローラーによって均一に処理されます。これには、より高い計算能力が必要です。同時に、ドメイン内ネットワークの帯域幅要件も増加しています。 さらに、ドメイン コントローラーはすべてのセンシング データを取得できるため、画像内のセンサーに依存するなど、いくつかの追加機能を開発することもできます。ドメイン内にある場合もあります。コントローラー 車線変更支援や緊急障害物回避の機能を実現します。 ドメイン コントローラーに機能が徐々に集中していくにつれて、センシング部分を担う他のコントローラーの非認識部分が徐々に弱まっていきます。 仲裁メカニズム 前そういえば、ACC/AEB/LKA 機能の実現、完全自動駐車の実現、および単一の L2 以下のその他の機能はすべて、1 層または 2 層のフラクタル再帰的 EPX-S モデルとして理解できます。 実際、実際の量産品ではACC/AEB/LKAの3つの機能を同時にONにすることができ、それぞれが別々のEPX-Sサイクルとなっています。これは、複数の EPX-S ループを同時に並行して実行できることを意味します。 X 出力が同時に生成された場合、調停メカニズム (Arbitration) によって調停される必要があります。 複数のコントローラーが同時に実行されている場合、ドメイン コントローラーはより高いレベルで調停を行います。 したがって、EPX-S モデルは EPX-SA モデルに拡張する必要があります。次の図に示すように、シナリオ 1 とシナリオ 2 は並列実行される 2 つの EPX-S ループであり、生成される X は調停後に出力されます。 環境提案モデルコンセプトの 単一の L2 機能を実装する各コントローラーには、認識機能の特定の側面があります。これらはすべて、車両の内部および外部環境の属性の特定の側面を記述しており、空間角度と距離、または可視光、超音波、ミリ波、レーザーなどの物理的属性に分類できます。環境全体に対して完全に正確な理想的な 3D モデル システムが確立されている場合、各センサーはこのモデルのフィルターに相当し、「象に触れる盲人」のように、各センサーは理想的なモデルの属性のある側面を表現します。 インテリジェントな運転の認識部分は、実際には、できるだけ多くのセンサーとアルゴリズムを使用して、理想的なモデルに近似することです。利用可能なセンサーが多いほど、アルゴリズムの精度が高まり、理想的なモデルからの逸脱が少なくなります。 L2 のドメイン コントローラーでは、必要に応じて下位コントローラーすべてのセンシング データを取得し、このレベルですべてのデータに基づいて理想値を設定できます。環境モデルの現実的なモデルはまだ理想的なモデルには程遠いものの、全体的な意味ではすでに環境モデルとなっています。 環境モデルによって提供される情報は、すべてのレベルの計画モジュール (P) だけでなく、スケジューリング (S) および調停 (A) フェーズでも使用されます。 より高度に統合された製品ソリューション
概略的なハードウェア トポロジは次のとおりです。 #ハードウェア トポロジ図
複数の単機能 ECU の連携
EPX-SA コンセプト モデル
以上がインテリジェント ドライビング ドメイン コントローラー ソフトウェア アーキテクチャを 1 つの記事で学びましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。