再シミュレーションによる自動運転システムの自動運転解除防止の検証

先進運転支援システム（ADAS）や自動運転システム（AV）のエンジニアリングチームは、初期のテストでは主に合成シミュレーションを使用して自動運転システムをテストすることができます。ADASや自動運転システムが成熟するにつれ、自車両が運行設計領域（ODD）で起こりうる膨大な数のイベントを安全に処理できることを検証するために、より多くの路上テストが必要になります。 

オンロード・テスト中に、自車両が自動運転を解除することがあります（セーフティドライバーがシステムを解除させ、車両の制御を引き継ぐイベントなど）。ADASやAVのエンジニアは、一般的にオープンループ・ログ再生ツールを使用して、自動運転解除イベントを再生し、セーフティドライバーが介入した理由を確認し、オンロード・テストをさらに進める前に、ローカライゼーションや認識スタックの問題を修正します。しかし、オープンループ・ログ再生ツールでは、実際に自動運転解除が必要だったのか、セーフティドライバーが介入しなければ自車両の衝突を回避できたのかを判断することはできません。また、道路上に歩行者がいたり、天候が変わって視界が悪くなったりと、さまざまなパラメータがイベントの結果にどのように影響したかを示すこともできません。

このブログ記事では、オープンループのログ再生と再シミュレーションが、認識・ローカライゼーションシステム（「何が起こったか」）とモーションプランニング・制御システム（「何が起こっただろうか」）の性能をそれぞれ評価し、必要な自動運転解除と不必要な解除を区別し、自動運転システム全体を包括的に検証・確認するのに役立つことを説明しています。

オープンループ・ログ再生:「何が起こったのか」を探る

現在、最も一般的なログ再生のタイプはオープンループです。オープンループ・ログ再生は、記録されたドライブ・データを再生することで、問題の発見、起こったことの分析、改善点の評価を行うことができます。

例えば、自車両が渋滞の終点に近づき、セーフティドライバーが介入して自車両を止め、衝突を回避するというオンロードテストを想定してみましょう（図1）。

オープンループのログ再生は以下のように使用できます。

• 何が起こったかを分析する。ドライブログを再生して、セーフティドライバーが介入した理由を可視化します。この例では、自車両が高速で停車中の車両に接近しているため、ドライバーが介入したことがわかります。
  

• ローカライゼーションと認識のパフォーマンスを評価する。イベントの生のセンサーデータを再生し、スタック出力を手動でラベル付けされたグラウンドトゥルースと比較してパフォーマンスを評価します。
  

• 解決策を探る。オンロードテストを行う前に、ローカリゼーションシステムと認識システムの改善を行います。ローカライズスタックの改良は、更新されたスタックバージョンを使用してイベントを再実行することでテストできます。
  

オープンループ・ログ再生では、自動運転解除を再生して分析することができますが、そのアプローチはローカライゼーションと認識スタックのパフォーマンスの評価に限られます。オープンループ・ログ再生では、スタックの挙動の違いに対応できないため、セーフティドライバーが介入しなかった場合に、モーションプランニングや制御システムがどのように動作したかを評価することはできません。

再シミュレーション:「起こったであろうこと」「起こったはずのこと」「起こったかもしれないこと」を探る

クローズドループ・ログ再生（再シミュレーション）は、オープンループ・ログ再生の限界を緩和するログ再生の手法です。再シミュレーションでは、開発チームがログに記録された実世界のドライブシーンを再現し、シミュレーションを使ってそれを変更することができます。

再シミュレーションは以下のように使用できます。

• 分析し、トリアージする。ドライバーが介入していなかったらどうなっていたかを確認し、自動運転の解除が必要だったかどうか、どの程度の状況だったかを判断します。再シミュレーションツールは、スタックの出力に反応するクローズドループのリプレイを実行することでこれを実現します。再シミュレーションの結果には、スタックのパフォーマンスを測定し、イベントが実際の問題であったかどうかを判断するための数値指標とオブザーバー（合格/不合格のルール）が含まれます。この例では、自動運転解除がなければ自車両が衝突を起こしていたため、自動運転解除は確かに必要でした（図2）。
  

• 原因となる問題を解決する。記録されたイベントに対してモーションプランニングとコントロールスタックを実行することで、必要な自動運転解除を回避するために何が起こるべきだったかを決定します。再シミュレーションの結果をもとに、問題の根本原因を特定し、解決策を講じます。解決策が確立されたら、改善されたスタックで再シミュレーションを行い、問題が解決されたことを確認します。
  

• ログデータの補強。同じシナリオの異なるバリエーションで何が起こったかを確認することで、スタック全体のパフォーマンスを評価し、ロングテールイベントのカバー率を高めることができます。エンジニアは、アクターの追加や削除（道路上の歩行者など）、アクターの行動の変更（自車両や他車両の速度を上げるなど）、シーンの他のパラメータの変更（雨や時間帯など）、AVソフトウェアやハードウェアへの不具合の注入（センサーの再起動、サブシステムの一時的なオフライン、センサーハードウェアの不具合など）、センサーデータへのノイズの追加（ライダーデータのノイズなど）を行うことができます。図3は、ログに記録されたアクターを、ウェイポイントによって行動を編集可能な合成アクターに置き換えることで、アクターの行動を修正する例です。図3：ログに記録されたアクター（空のボックス）から動作を抽出し、編集可能な動作を持つ合成アクタ（実線のボックス）に置き換える。
  

再シミュレーション・アーキテクチャ

再シミュレーション・ツールの典型的なアーキテクチャは次のようなものです（図4）。 

まず、生のセンサーデータがオープンループのログ再生で認識スタックに供給され、検出されたアクターが抽出されます。その後、モーションプランニングスタックがクローズドループで実行されます。これをうまく行うためには、自車両の発散を考慮して認識スタックの出力を修正する必要があります。ドライブログでは、検出されたアクターが自車両に対して相対的に報告されることがあります。オープンループの参照フレームから再シミュレーションの参照フレームに移行するためには、異なるアクターの位置を調整して、シミュレーションされた自車両のポーズに合わせる必要があります（座標変換）。プロセス全体を通して、メトリクスとオブザーバーのフレームワークは信号を収集し、自車両のパフォーマンスの評価（合格／不合格）を計算します。

再シミュレーションの技術的課題

再シミュレーションには技術的な課題がつきもので、エンジニアが手作業で調査・修正しなければならないようなコストのかかる不具合が発生することもあります。 

まず、トリアージチームとエンジニアリングチームは、再シミュレーションが正確で再現可能であることを信頼できる必要があります。これは、自動運転解除のないログセクションで再シミュレーションを実行し、自車両の発散が小さいことを確認することで検証できます。

第二に、スタックが車両以外のハードウェアで動作している場合、再シミュレーションに遅れをとる可能性があります。これは、マシンの性能が著しく劣るクラウド上で再シミュレーションを行う場合に特に問題となります。スタックが遅れてしまうと、イベントへの反応が遅れてしまう可能性があります。その結果、自車両のパフォーマンスは不正確で非決定的なものになります（つまり、再シミュレーションを実行するたびに変化します）。再シミュレーションツールは、結果を意味のあるものにし、異なるマシンでも再現できるようにするために、このような事態を防ぐ必要があります。

Applied Intuitionの取り組み

自動運転システムのオンロード性能を総合的に評価するには，オープンループのログ再生とクローズドループの再シミュレーションの両方が必要です．オープンループのログ再生により、エンジニアは自動運転解除時に何が起こったかを調べ、ローカライゼーションや認識のスタック性能を評価することができます。また、再シミュレーションを行うことで、必要な自動運転解除と不必要な自動運転解除を区別し、モーションプランニングと制御スタックの根本的な原因を解決することができます。この2つのアプローチを併用することで、開発チームは自動運転システム全体の検証・妥当性を確認し、安全な自動運転システムをより早く市場に投入することができます。

Applied Intuitionの再シミュレーションツールLogstreamは、オープンループとクローズドループの両方のログ再生を可能にします。Logstreamの機能にご興味のある方は、製品のデモをご希望の方は弊社エンジニアリングチームまでご連絡ください。