自動運転機能のためのハイブリッド Vehicle-in-the-Loop テスト手法の実装

先進運転支援システム (ADAS) と自動運転 (AD) システムを量産車両に安全に使用するには、さまざまな運転シナリオにわたる広範なテストが必要です。このテストは、現在一般的に使用されている 2 つの広範なアプローチの限界により、自動車エンジニアにとって大きな課題となる可能性があります。最初のアプローチは、シミュレーションのみで AD および ADAS 機能をテストするもので、初期のアルゴリズム開発には効果的ですが、アルゴリズムのパフォーマンスに大きな影響を与える可能性のある実際の車両のダイナミクスやハードウェア関連の影響を捉えることができません。実際の車両でテストを実施すればこれらの限界はなくなりますが、この 2 番目のアプローチは時間がかかり、コストがかかり、再現が難しく、特定の運転シナリオでは安全でない可能性もあります。

シミュレーションのみと実車テストの間のギャップを埋めるために、私のチームは Virtual Vehicle Research ハイブリッドテストアプローチを実装しました。このアプローチは、コシミュレーション フレームワークで実際の車両と仮想車両を組み合わせた Vehicle-in-the-Loop テストを組み込むことによって定義され、シミュレートされた交通シナリオで ADAS および AD 機能の安全で現実的なテストを可能にします (図 1)。たとえば、急ブレーキのシナリオでは、このハイブリッド テスト アプローチを適用して、実際の車両の質量、ブレーキ システムのダイナミクス、ハードウェアの遅延、およびモデルで捉えるのが非常に困難または不可能なその他のニュアンスを完全に考慮した自動緊急ブレーキ システムのテストを実行できます。しかも、現実世界での追突事故のリスクは一切ありません。

MATLAB® と Simulink® によるモデルベースデザインを使用して社内で開発した ADAS 機能をテストすることでハイブリッドテスト手法を検証しました。これらの機能には、横方向および縦方向の追跡機能と車線変更決定機能が組み込まれており、アダプティブ クルーズ コントロール (ACC)、車線維持支援 (LKA)、軌道計画 (TP) 機能をサポートします。モデルベースデザインにより、ADAS 機能のモデル化、シミュレーション、コード生成を迅速に行うことができ、低レベルのコーディングや実装の詳細ではなく、アプローチとしてのハイブリッド テストの検証に集中できるようになりました。

ハイブリッドテストの仕組み

ハイブリッド テストでは、AD または ADAS ソフトウェアとハ​​ードウェアを搭載した実際の車両が、他の車両や障害物のない密閉された性能試験場で動作します。制御ソフトウェアは、現実世界の交通を感知してそれに応答するのではなく、車両が性能試験場を移動するときにリアルタイムで継続的に更新される仮想環境と連携します。私たちのセットアップでは、テスト車両は Ford ®のモンデオ ハイブリッドで、車両のスロットル、ブレーキ、ステアリング、シフトを完全に制御できる ADAS キットが搭載されています。性能試験場はオーストリア、グラーツ近郊の ÖAMTC Lang/Lebring テスト トラックです (図 2)。さらに、仮想環境は、オープンソースの連続的な交通シミュレーションパッケージであるSimulation of Urban MObility（SUMO）に基づいており、道路標識、車線座標、その他のインフラストラクチャ要素を含む静的環境はASAM OpenDRIVE ^®フォーマット仕様を使用して定義されています。

テスト車両が複数車線のトラック上を移動すると、その位置、速度、方向が GPS やその他の車載センサーによって取得されます。この情報は、車両内の産業用 PC 上で実行されている仮想環境に中継され、交通シミュレーション内でテスト車両 (自車両) の方向を決定するために使用されます。自車両のシミュレーションと仮想車両および静的インフラ要素に対する位置に基づいて、仮想環境は一連のオブジェクトリストと車線検出情報を生成し、CAN バスインターフェースを介して dSPACE^® MicroAutoBox リアルタイム ハードウェア上で実行される ADAS 制御ソフトウェアに送信します。制御ソフトウェアは、オブジェクト リストと車線情報を使用して、ブレーキ、加速、車線変更、軌道計画に関する決定を行い、それらの決定を実行するために必要な信号を CAN バス経由で車両のステアリング、スロットル、ブレーキ アクチュエータに送信します (図 3)。

ADAS機能のモデリング、シミュレーション、コード生成

私たちは、同僚が別の ADAS アプリケーション用に開発した一連のSimulinkモデルを使用して、Motorway Chauffeur (MWC) と名付けた ADAS 機能の ACC、LKA、軌道計画コンポーネントの開発を開始しました。私たちはこれらのモデルを仮想環境から得られるオブジェクト リストとレーン情報を使用するように調整し、デスクトップ上で一連の閉ループ シミュレーションを実行して、システムの基本機能を検証しました (図 4)。また、Model.CONNECT 統合プラットフォームを使用して、IPG の CarMaker で ADAS 制御モデルのシミュレーションも実行しました。

シミュレーションでADAS機能をテストした後、 Embedded Coder^® を使用してモデルから C++ コードを生成し、車載テストに備えて MicroAutoBox ターゲット ハードウェアにコードを展開しました。

車載テストの実施と結果の後処理

MicroAutoBox ハードウェアと産業用 PC を含むハードウェア セットアップ全体をテスト車両にインストールしました (図 5)。この構成を使用して、仮想交通下でのインフラストラクチャ対車両情報メッセージ (IVIM) に応じた車線変更や速度変更など、さまざまな ADAS および AD 機能を評価するため、性能試験場で多数のテストを行いました。

テスト走行後、 MATLABを使用して車載センサーによって記録されたデータを分析し、車両の速度、ステアリング角度、位置を時間経過とともに示すプロットを生成しました (図 6)。この分析は、Vehicle-in-the-Loop テストを使用して ADAS 機能の重要な評価指標 (KPI) を評価できるため、私たちの研究目標の中心でした。

MATLABでデータを後処理することは、テスト中に発見された問題の分析にも役立ちました。たとえば、あるテストでは、仮想環境から取得されたオブジェクト リスト データを、MobilEye ADAS カメラから直接取得された同様のデータに置き換えました。シミュレーションされたデータを実際のセンサーのデータに置き換えると、制御信号に振動があることに気付きました。分析の結果、この問題は車線検出データの約 300 ミリ秒の遅延に起因していることが判明しました。Simulinkモデルに同じ遅延を導入した後、その後のシミュレーションで同様の振動が見られました。次に、この遅延を考慮して制御アルゴリズムを変更し、コードを再生成して問題を解決できました。

次のステップ

私たちのチームは、実装したハイブリッド テスト方法の開発を続けています。現在、私たちは、今日使用している鳥瞰ビューのイメージの可視化の代わりに交通シナリオに 3D 可視化を使用するなど、いくつかの機能強化を検討しています。計画されているもう 1 つの機能強化は、シミュレーション フレームワークに物理センサー モデルを組み込むことです。これにより、認識アルゴリズムの開発と Vehicle-in-the-Loop テストがサポートされ、ハイブリッド テストでのオンボード センサーのさらなる統合が可能になります。