高度な自動運転システムの開発において解決すべき課題についてお話しします

次世代のインテリジェントコネクテッドカーには、高度な自動運転システムが必須です。車両が自動運転をいかに実現するかという課題の解決だけでなく、機能開発の問題や性能向上の問題など、現世代の自動運転では解決できない課題の解決も求められます。例えば、最近のNIO自動運転事故から、真の自動運転を実現するためには、自動運転システムが現在のエッジシナリオの多くを解決する必要があることは容易に理解できます。これらのシナリオはすべて、システムの機能安全性に大きく影響するシナリオです。たとえば、ほとんどの OEM が Tesla の例に倣い、データ収集とシミュレーションに同様のシャドウ モードを採用したい場合、開発プロセス中に落とし穴を回避する方法も検討する価値のある問題です。

また、高度な自動運転のアーキテクチャを構築するにはSOAベースの開発モデルが用いられるため、汎用性、効率性、信頼性という目標を達成するためにSOAの効率性をどのように向上させるかが、解決すべき課題となっています。

この記事では、開発者に参考となることを目的として、上記の 3 つの困難かつ緊急の問題について詳しく説明します。

静止物体の衝突検出を改善する方法

開発とテストの観点から、解決が困難であったり問題を引き起こす可能性があるシナリオをいくつか収集しました。その中でも、静止したターゲットの認識はその一つです。完全な視覚の観点から見ると、現在の自動運転製品はすべて、単眼または三眼の視覚に基づいて検出します。しかし、この検出方法には、変えることのできない固有の欠陥があります。この方法はディープラーニングマシンビジョンに基づいているため、認識、分類、検出が同じモジュールで実行され、通常はセグメント化できないというパフォーマンスがあります。つまり、ターゲットを分類できない場合、特定のターゲットを効果的に認識できないことがよくあります。この認識の失敗は、自動運転車の衝突に簡単につながる可能性があります。

認識に失敗した理由を説明し、この種の問題を解決する方法をまとめるためには、次の点を強調する必要があります。まず、トレーニングデータセットは現実世界のすべてのターゲットを完全にカバーすることはできないということです。多くの静止ターゲットは必ずしも標準的な車両ではなく、特殊な形状の車両、落石、不規則な工事標識である可能性もあります。したがって、開発段階でトレーニングされたターゲットタイプは、実際の自動運転認識シナリオではあまり使用できません。

2 つ目は、画像にテクスチャの特徴が欠けていることです。テクスチャの特徴は、複数のピクセルを含む領域で統計的に計算され、回転不変であることが多いです。ノイズに対する耐性が非常に高いです。そのため、テクスチャの少ないトラックの車室や白い壁などは、視覚的に識別することが難しい場合があります。

さらに、ディープラーニングが静止したターゲットに対して優れた認識能力を実現できない理由を説明する必要があります。ディープラーニングにおけるマシンビジョン、特に単眼カメラ検出に基づくマシンビジョン画像は、背景としてすべての静的ターゲットを排除するため、ビデオ理解プロセスにとって重要な移動ターゲットを適切に選択できます。この方法は、認識効率を向上させるだけでなく、エンコードビットレートを削減することもできます。同時に、誤検出を防ぐために、移動ターゲットと静止ターゲットも分離する必要があります。たとえば、道路の両側に車が駐車している場合、移動ターゲットの優先度は当然、静止ターゲットよりも高くなります。次に、通常は背景減算、3フレーム法、またはオプティカルフロー法を使用して識別します。通常、このタイプの認識アルゴリズムには1〜2秒かかります。ただし、リアルタイム要件が高い自動運転の場合、この間に衝突が発生している可能性があります。

そのため、上記のような認識性能の欠陥を解決するためには、ディープラーニングの不足によって生じる問題を根本から解決する必要があります。マシンビジョンには主に 2 つの学習およびマッチング モードがあります。1 つは手動モデル、もう 1 つはディープラーニングです。後者は通常、画像認識と分類に使用されます。ディープラーニングは主にセグメンテーションとフィッティングを通じて行われるため、原理的にはすべてのピクセルを走査し、トレーニング済みモデルに対して数十億回の乗算と累積を実行し、比較のために異なる重み値を設定する必要があります。人間の視覚とは異なり、マシンビジョンは非全体論的です。本質的には、ディープラーニングとは、収集したデータポイントを既存のデータベースと効果的に照合して、実際の曲線関数に限りなく近い曲線関数を当てはめ、それによって識別が期待される環境ターゲットを識別し、傾向を推測し、さまざまな問題に対する予測結果を提供する方法です。もちろん、特定のデータ セットを表現するときに曲線フィッティングを行うとリスクが生じ、これがフィッティング エラーになります。具体的には、アルゴリズムがデータ内の通常の変動を認識できず、最終的に適合のためにノイズを有効な情報として扱う可能性があります。したがって、このような異常な環境でターゲットを識別できるという問題を本当に解決したいのであれば、SOC チップの AI アクセラレータ機能の向上だけに頼るのは賢明ではありません。 AIアクセラレータは、MAC乗算および累積計算モジュールの高速計算機能のみを解決するためです。

こうした認識やマッチングのエラー問題を真に解決するために、次世代の高性能自動運転システムでは通常、最適化のためにマルチセンサー融合（ミリ波レーダー、ライダー）やマルチカメラ検出を採用しています。運転支援システムを開発した設計者は、現在のミリ波レーダーは金属物体に対して非常に敏感であり、物体検出プロセス中に誤検出による AEB の誤作動が回避されることを認識しておく必要があります。そのため、多くの静止ターゲットは通常フィルタリングされ、同時に、一部の大型トラックや車体の高い特殊作戦車両は、ミリ波レーダーの高さの問題により、ターゲットを検出できないことが多く、見逃されてしまいます。

3 次元ターゲットを再構築するには、従来の方法 (またはディープラーニング以外のアルゴリズム) が必要です。通常、これは、ポイント クラウド再構築用の LIDAR または高解像度 4D ミリ波レーダー、またはオプティカル フロー トラッキング用の双眼カメラを使用することで最適化できます。ライダーに基づくターゲット検出方法は、検出信号（レーザービーム）を放射し、ターゲットから反射された受信信号（ターゲットエコー）を送信信号と比較し、適切な処理を経てターゲットの関連情報を取得するという原理です。したがって、エコー自体のポイントクラウドマッチングもディープラーニングプロセスですが、このプロセスは弾幕画像認識のセグメンテーションとマッチングよりも高速です。

両眼視による静止ターゲットの検出は、視差画像に依存します。純粋な幾何学的関係に基づくこの視差マップにより、静止ターゲットの位置をより正確に特定できます。多くの場合、でこぼこ道、明暗のコントラストが非常に強い道路、および一部の損傷した道路では、単眼視で遠くの物体の検出を完了できますが、3 次元の復元には多くの不確実性があります。ステレオカメラをディープラーニングと統合することで、ステレオポイントクラウドを画像の RGB 情報やテクスチャ情報と融合することができ、遠距離のターゲットの認識や 3D 測定に役立ちます。

ディープラーニングは、一般的な道路参加者をより正確かつ安定的に検出し、複数の機能を統合して、より遠くにある道路参加者の検出を容易にします。ステレオビジョンは、道路上のすべての参加者の 3D 測定とポイント クラウド ベースの検出を同時に実現できます。オブジェクトの種類、設置位置、姿勢に制限されません。ダイナミック レンジングはより安定しており、一般化能力も優れています。ステレオビジョンとディープラーニングを組み合わせて、より遠くにある物体を検出し、ステレオビジョンを使用して 3 次元特性を評価します。

上記のアルゴリズムは、カルマン フィルタリング、スムージング演算、勾配処理などの CPU によって実行される論理演算に依存するか、GPU によって実行されるディープ イメージ ラーニング処理に依存します。したがって、次世代の高レベル自動運転ドメイン制御システムには、そのパフォーマンスが要件を満たすことを保証するために、優れたコンピューティングおよび処理能力が必要です。

シャドウモードは見事突破できるのか？

現在、次世代の高レベル自動運転システムを開発する場合、OEM や Tier 1 では、環境に突然の変化が発生する可能性のあるさまざまな動作条件を完全にカバーできないことがよくあります。この初期データ カバレッジは、多くの場合、極端なシナリオのデータ カバレッジと呼ばれる高品質のデータ収集と処理に依存しています。大量の極限シナリオデータをどのように収集し、それを自動運転のバックグラウンドに送り返すかは、私たちが解決しなければならない重要な問題です。また、その後の自動運転システムが完璧なブレークスルーを達成できるかどうかを評価する重要な要素でもあります。

テスラのシャドウ モードは効率的なデータ収集の先駆者です。 「シャドウモード」の定義は、手動運転状態では、システムとその周囲のセンサーは引き続き動作していますが、車両の制御には参加していません。意思決定アルゴリズムの検証のみを行います。つまり、システムアルゴリズムは「シャドウモード」で継続的にシミュレートされた決定を行い、その決定をドライバーの行動と比較します。両者が矛盾すると、シナリオは「極端な状態」と判断され、データフィードバックがトリガーされます。

ただし、シャドウ モードを完全に理解したい場合は、次の問題の解決に重点を置く必要があります。

1. シャドウ モードは、ラベル付きおよびラベルなしのトレーニング シナリオを含む、より広範囲の極端な動作条件の検出と収集をどのように提供しますか?

シャドウ モードは通常、データ取得と処理の一部であるため、制御端の軌跡差を使用してデータ記録をトリガーする場合を除き、他の動作モードはデータ記録に直接適用されません。自動運転にシャドウ モードを効率的かつ高速に適用する方法が必要な場合は、その取得プロセス中に、制御プロセス全体 (認識、予測、計画、制御のモジュール全体を含む) にわたってディープ ニューラル ネットワークを同時に展開する必要があります。より実用的なシャドウ モードでは、動作範囲を拡大する必要があり、そのためには、データの記録とフィードバックをトリガーするための軌道の比較だけでなく、ターゲットの違いの感知、ターゲットの違いの融合などによってデータの記録とフィードバックをトリガーすることも必要です。このプロセスでは、実際の取得ポートに基づいて対応するデータ取得ユニットを定義する必要があります。これらのユニットは、自動運転モードまたは手動運転モードで動作できます。これらは、データの収集、記録、およびフィードバックのためのハードウェアとしてのみ機能し、車両の制御には影響しません。

2. チップの選択とセンサーの構成が期待どおりにシャドウモードをサポートしているかどうか

自動運転の開発では、シャドウ モードはリソース使用量が少ない単純な論理操作に過ぎず、シャドウ モードを有効にしてもバックグラウンド処理の遅延は増加しないと予想されます。次世代の高レベル自動運転でシャドウモードに基づくデータ収集を実装する場合、シャドウシステム専用の追加チップを構成するか、複数のチップのドメイン制御システム内のチップ内のモジュールを分割してシャドウアルゴリズムのトレーニング専用に使用することを検討する必要があります。

また、これまでのシャドウシステムはL2+システムで動くのが一般的で、データ収集に使うセンサーの種類も比較的単純なものが多い。例えば、ほとんどの企業は5R1V方式でデータ収集を行っている。より高度なものはレーザーレーダー1台で構成されていることもある（現在量産中、あるいは量産間近の国内企業ではこの構成はない）。このセンサー構成で収集したデータが、次世代の高レベル自動運転システムに直接応用できるかどうかは不明だ。これは、環境条件を予測してシステムを実行する単一または少数のセンサーの能力が、複数のセンサーの能力とは大きく異なるためです。したがって、高度な自動運転システムがアップグレードされると、システム全体の制御という点でも、そのセンサー能力は確実に高いレベルに達するでしょう。したがって、後続の自動運転システムが以前の L2 レベルで収集されたシーン データを引き続き適用できるか、または部分的にしか適用できないかを判断するには、再設計と計画が必要です。

3. 最も科学的かつ効果的なデータフィードバックを実現するために、どのような標準的な判断方法を採用すべきか

シャドウ モードの起動前提は、人間の運転モードでは、システムの環境を判断する能力がドライバーの能力よりも劣っているはずであると想定されるため、ドライバーによる車両の操作は正確かつ客観的でなければならないということです。しかし、これは本当にそうなのでしょうか?もちろん全部ではありません。たとえば、ドライバーが前方の道路に泥がたくさんあるのを見て、それが車輪を汚し、車の外観に影響を与えることを恐れた場合、それを避けるために車線変更を選択する可能性があります。ただし、この理由でシステムは自動車線変更システムをトリガーしません。このとき、ドライバーの車両制御方法を基準にしてその正しさを判断すると、システムは間違っているはずです。このとき、データ収集とフィードバックをトリガーすることは、実際には無意味または不正確です。したがって、別の観点から見ると、自動運転制御システム全体のリンクにおいて、ドライバーの通常の運転行動は運転バイアスである可能性があり、このデータ収集とフィードバックトリガーモードは、実際には運転体験を向上させる方法です。

4. シャドウモードでは問題箇所の精度をさらに向上させる必要がある

シャドウ モードは視覚的な駆動側で実行されるため、この問題特定方法では、実行側の観点から問題を調べるために逆トレース法がよく使用されます。制御実行プロセスで問題が発生すると、多くの場合、その問題は、意思決定側の問題かどうかを確認するために後回しにされます。意思決定側に問題がない場合、問題は、軌道予測側の問題かどうかを確認するために前倒しされ、さらに、認識側の問題かどうかを確認するために前倒しされます。また、知覚端も広い概念であり、実際のシーンの知覚とその後の融合システムが含まれます。シーンの知覚に問題があるが、融合システムの一連の堅牢なアルゴリズムを使用して、知覚エラーによって引き起こされる誤った決定などの問題を回避している場合は、そのような異常な知覚シーンを個別に選別する必要があります。

このシナリオのデータをフィルタリングするには、プランの両端で認識されたデータ間のジャンプを継続的に記録する必要があります。両端間の大きなジャンプは、データ フィードバックをトリガーします。もちろん、プロセス全体の計算量は非常に大きくなります。現在、自動運転システムの全体的な認識能力はまだ非常に限られています。誤認識が誤った決定につながるシナリオは依然として時々発生します。正しい認識であっても、誤った実行につながる可能性があります。この場合、シャドウシステムは、収集された「予測/決定の失敗」シナリオデータの粒度を絞り込み、無効なデータの収集とフィードバックを除外する必要があります。これにより、トラフィックとストレージスペースの両方を節約できます。

5. 自動運転システムデータのシミュレーション応用能力が確立されているか

返送後のデータの使用方法は、ディープラーニングとデータマッチングの最適化に使用することです。このプロセスでは、まずシーンに基づいてシミュレーションシステムを構築し、次に対応するシーン検出パラメータをシミュレーションシステムに入力して、アルゴリズムのトレーニングと最適化を行います。しかし、実際の道路計測データをシミュレーションに有効活用するには、現状では比較的高い基準が求められているのが実情です。大手 OEM、テスト機関、およびティア 1 はまだこれを実現するための十分な能力を備えていないか、能力が十分に成熟していません。

アーキテクチャのアップグレードによってどのような開発上の問題が発生しますか?

高度な自動運転には、車両と道路の連携、エッジコンピューティング、クラウドサービスなどの複数のアプリケーションシナリオの統合が必要であり、一定の拡張性、汎用性、自律的な進化が必要です。現在の電子・電気アーキテクチャとソフトウェア プラットフォーム アーキテクチャではこれらの要件を満たすことは困難ですが、現在の車載 SOA では上記の問題をうまく解決できます。 SOAはIT分野から生まれました。車載SOA環境における最良の実装方法は、イーサネットをベースとした高凝集性と低結合性の成熟した考え方を継承することです。

したがって、SOA アーキテクチャに基づく高度な自動運転システムを設計するための鍵は、次の機能を実現することです。

1. サービス通信の標準化、すなわちサービス指向通信

SOME/IP は RPC (リモート プロシージャ コール) メカニズムを採用し、「サーバー クライアント」モデルを継承します。 SOME/IP を使用すると、クライアントはタイムリーにサーバーを見つけて、興味のあるサービスに加入できます。クライアントは、「デマンドレスポンス」および「ファイアウォール」モデルを使用して、サーバーが提供するサービスにアクセスできます。サービスは通知を使用して、クライアントがサブスクライブしているサービスコンテンツをプッシュできるため、基本的にサービス通信の問題が解決されます。

しかし、SOA アーキテクチャに基づく通信標準 SOME/IP には、2 つの大きな欠陥があります。

a) 比較的基本的な仕様しか定義されておらず、アプリケーションの相互運用性を確保することが困難です。

b) ビッグデータや高同時実行シナリオに対応するのは困難です。オブジェクトのシリアル化機能がないため、SOME/IP ソフトウェアの相互運用性に問題が発生しやすくなります。 SOME/IP は共有ストレージをサポートしておらず、ブロードキャストベースの 1 対多通信に基づいています。自動運転のシナリオでは、パフォーマンスが問題になる可能性があります。

2. SOA アーキテクチャでは、サービスの再利用と柔軟な再編成を目的としたサービスの分割、つまりサービス指向の再利用と共有設計が必要です。

SOA システム ソフトウェア開発プロセスは、車両全体の機能ロジックの定義に適用する必要があります。アーキテクチャは、需要開発、機能定義、機能実装、サブシステム設計、コンポーネント設計などのプロセスを支配または参加します。サービス指向の再利用設計実装は、プロセス全体を実行し、最終的に機能実装のリンクに反映できる必要があります。

ここで注意すべきは、サービスの再利用には、元のシステムを切り離して新しいシステムを再構築することが含まれるということです。規模が拡大し、新しい機能が追加されると、情報ベースの通信が増加します。このように、予期しない状況が発生すると、処理応答時間が大幅に長くなり、データアクセスの遅延が発生する可能性があります。自動運転システムには極めて高いリアルタイム要件があり、これが SOA アプリケーションの最大の制限でもあります。

さらに、SOA のソフトウェア実装では、サービスベースのソフトウェア アーキテクチャを構築するプロセスで、サービス指向の通信設計とサービス指向の再編成の実装の問題を実行および適応できるかどうかを十分に考慮する必要があります。

次世代の高度な自動運転システムに必要なのは、「現在地はどこか」と「目的地はどこか」という 2 種類の問題だけです。これら 2 種類の問題のうち、1 つは地図の位置決めに依存し、もう 1 つはナビゲーション制御に依存します。基本的なアーキテクチャはサービス指向の設計機能を確立することであり、SOA アーキテクチャが誕生しました。新しいアーキテクチャの下で高レベルの自動運転システム機能の完全なブレークスルーを達成し、全体的な機能体験とパフォーマンスを新しいレベルに引き上げる方法は、自動運転開発者が注力する必要がある重要な課題です。全体的な開発方法に関係なく、認識されるパフォーマンスは量的変化から質的変化へのプロセスである必要があります。解決すべき問題はまだたくさんあり、一つずつ解決し続けなければなりません。