シミュレーションテストケースの品質は、安全な先進運転支援システム (ADAS) と自動運転 (AD) システムの開発に不可欠です。しかし、質の高いテストケースを作成することは難しい作業です。このブログでは、一部のテストケースが他のテストケースよりも優れているさまざまな側面と、ADASチームとADチームがシミュレーションテストケースの品質をどのように向上させることができるかを探ります。
テストケースの品質を高めるには？
ADASおよびADシミュレーションでは、チームが仮想環境におけるシステム（認識、予測、計画、制御モジュールなど）のパフォーマンスを評価するためのテストケースを作成します。質の高いテストケースと質の低いテストケースには、次の 5 つの側面があります。
- リアルさ: 高品質なテストケースは、現実世界で起こり得る状況を表現します。
- 多様性: 高品質のテストケースは、他のテストケースとは明確に区別されます。他のテストケースで表現されている状況とは異なる状況を表現します。
- 関連性: 高品質のテストケースは、ADASまたはADシステムの特定の意図された機能を対象としており、適切な範囲のテストパラメータ値を効果的にカバーします。
- 適応性: 高品質のテストケースは、自車行動の変化に強く、必要に応じて簡単に読みやすく修正できます。
- 評価基準: 高品質なテストケースは、ユーザーがシステムパフォーマンスを正確に評価できるように、関連するメトリックを測定し、適切な閾値を設定します。
質の低いテストケースは、チームのADASまたはAD開発サイクルで次のような問題を引き起こす可能性があります。
- 非現実的な性質: テストケースが、非論理的または自然に不可能な非現実的な状況を説明している場合、そのシミュレーション結果は実際の例とは関係がなく、ADASやADのパフォーマンスにとって意味がありません。
- 限られた視点: テストケースが互いに区別されない場合、チームは同じ状況を何度もテストしてリソースを浪費する一方、他のカバーできていない領域が発生します。
- 無関係: 意図した機能をテストできなかったり、不十分または無関係なバリエーションの範囲をカバーしたりするテストケースは、テストや開発全体を遅らせます。
- 柔軟性に欠けるデータ: 固定的なテストケースや古いテストケースでは、自車の動作やADAS、ADスタックの変化に適応できないため、開発が遅くなります。
- 質の悪い評価: システムパフォーマンスにアクセスするための適切な指標がない、質の低いテストケースは最終的に安全でないADASおよびADモジュールの導入につながります。
高品質なテストケースを作成する方法
ADASまたはADシミュレーションのテストケースを作成する場合、チームは次の4つの領域に細心の注意を払う必要があります。
- アクターの動作とトリガー条件
- パラメータースイープ
- 評価基準と合格/不合格のしきい値
- 新しいマップへのスケーリング
1．アクターの動作とトリガー条件
すべてのシミュレーションテストケースは、自車とシーン内の他のアクター（他の車両、自転車、歩行者など）で構成されています。これらのアクターがどのように振る舞うかは、テストケースの品質において重要な役割を果たします。テストケースの質を高めるには、アクターの行動が多様で、現実的で、関連性が高い必要があります。
まず、チームはテストケースのライブラリでどのアクターの行動が表現されているかを調べる必要があります。アクターは、単純なものからより高度なものまで、さまざまな行動に従う必要があります。単純な動作には、停止、待機、減速、加速などがあります。高度な動作には、アクターが手描きで描いた特定の経路をたどったり、横方向のオフセットを変えて車線の中心をたどったり、設定可能な車線変更軌跡を使用するアクターなどがあります。
次に、チームはモーションモデルとインテリジェンスモデルを活用して、実際の運転行動をよりインテリジェントに表現する必要があります。現実的なアクターモーションモデルは、非現実的な縦方向および横方向の加速度や非物理的な動きを防ぐことができます。優れたテストケースでは、インテリジェント・ドライバー・モデル (IDM) のような行動モデルを使用して、アクターが周囲の交通状況に合わせて動的に速度を調整し、必要に応じて迫り来る衝突に現実的に対応できるようにしています。質の高いテストケースでは、車線変更モデル MOBIL を使用して、アクターが経路上の障害物や他のアクターをダイナミックかつ自然に回避できるようにすることもできます。
最後に、チームはテストケースが自車のシーンへの反応の変化に強固であることを確認する必要があります。静的に定義されたテストケースに共通する問題は、自車行動の変化に適応できないことです。たとえば、構築が不十分なテストケースは、元々 ADAS や AD スタックの現行バージョンへのオーバーフィットによって定義されていた可能性があります。優れたテストケースでは、トリガー条件などの機能を利用して、シーン内のアクターが実行時のイベントに基づいて動くことができます。また、チームは実行時にアクターの振る舞いに動的制約を適用することもできます。これにより、アクターは自車行動のばらつきを考慮して動きを微調整できます。これらの条件付き機能により、ADAS や AD スタックが時間の経過とともに改善または変化しても、テストケースは有効なままになります。また、チームはオブザーバー (合格/不合格の基準で測定および評価された指標) を自動チェックとして使用して、テストケースがテスト対象として設計されたインタラクションを引き続きテストできるようにすることもできます。
2．パラメータースイープ
パラメータースイープを使用すると、各テストケースパラメーターのさまざまな値のシミュレーションを自動的に実行することで、チームはテスト範囲を拡大できます。優れたパラメータースイープにより、チームは関連性と現実性を保ちながら、多様なテストケースを効率的に作成できます。
まず、チームはシーン内のどの変数をパラメータ化するか、そしてそれらのパラメータをどのように「スイープ」するかを決定する必要があります。チームは任意のテストケースパラメーターを変更できますが、変更するのに最も役立つパラメーターはテストケースのタイプによって決まります。他のアクターとの対話を伴う一般的なテストケースでは、一般的にパラメーター化される変数には、アクターの速度、横方向と縦方向の相対位置、自車とアクターの操作の間の相対的なタイミングなどがあります。アクターの行動やインテリジェンスモデルのパラメーターも変化することがよくあります (例えば、カットイン時の横方向の速度やマージ中のアクターの強引さなど)。また、自車とアクターの初期位置を変えることで、地図上の似ているが異なる複数の道路地点でテストケースを簡単にテストすることもできます。
パラメータースイープの範囲は、対象となる運行設計領域（ODD）に関するデータに裏打ちされた調査から得る必要があります。たとえば、チームはドライブログ分析を行って、さまざまなパラメーター (アクターの速度、車線変更の持続時間、最大減速など) に関連する分布を理解する必要があります。
パラメータースイープのさまざまな値が組み合わさって複数の異なるバリエーションが形成されるので、それぞれのバリエーションが適切で、現実的で、有効であることを確認することが不可欠です。たとえば、インタラクションのタイミングを変えながら、自車やアクターの速度も無差別に変化させると、意図したインタラクションを含まない無関係なバリエーションが多数生まれてしまいます。意図したインタラクションを維持するには、パラメータースイープではテストケース内の他のスイープを考慮する必要があります。質の高いテストケースでは、テストケース説明の特定のフィールドに動的な数式を使用します。これらのフィールドでは、パラメータースイープ変数の値を参照して変動を正しく考慮します。
3．評価基準と合格/不合格のしきい値
テストケースの評価基準と合格/不合格のしきい値は、その品質を左右します。評価基準によって、自車がテストケースに合格するか不合格になるかが決まります。合格/不合格の閾値によって、自車が「合格」から「不合格」に、またその逆になるまでの各変数に値を設定します。
たとえば、Applied Development Platform（ADP）には、テストケースの品質を保証し、チームがADASまたはADシステムのパフォーマンスを評価できるようにするための3種類のオブザーバーが含まれています。
- 妥当性オブザーバーはテストケースが意図したテスト設計に関して正確であることを確認します。たとえば、単純なテストケースでは、自車が意図した目的地に到達したかどうかを確認するオブザーバーが含まれる場合があります。別のテストケースでは、妥当性オブザーバーが、自車と他のアクターが互いに一定の距離の閾値内にいたことがあるかどうかを調べる場合があります。
- 主要意図オブザーバーは自車がテストケースの主な目的を達成することを確認します（例：左折シナリオで目的の目的地に到達すること）。
- グローバルオブザーバーは自車が、現実世界のあらゆる状況で満たす必要のあるグローバルな安全・快適基準をすべて遵守することを確認します。
ADASまたはADシステムは、すべてのオブザーバーが合格した場合にのみテストケースに合格します。オブザーバーの合格または不合格の基準は、オブザーバーのタイプによって異なります。オブザーバーの中には、「衝突」や「目的地に到達」のように二元的なものもあれば、連続値を監視して、その値が特定のしきい値を上回ったり下回ったりすると合格するオブザーバーもあります。特定の閾値を選択する必要がある場合には、 Test Suitesはデフォルトでは、関連する研究で確立された値を使用します。また、お客様が事前に定義した閾値を使用することもできます。
評価基準と合格/不合格の閾値を使用して個々のテストケースにおけるADASまたはADシステムのパフォーマンスを評価することに加えて、チームは関連するすべてのテスト範囲に対するADASまたはADの動作を集約して分析する必要があります。これにより、チームは対象とするODD全体にわたるADASまたはADの全体的なパフォーマンスをよりよく理解できます。
4．新しいマップへのスケーリング
チームがADASやADの開発中に基礎となるマップデータを更新または変更する可能性があるため、高品質のテストケースは堅牢でさまざまなマップやジオメトリに対応できる必要があります。Applied Intution のテストケースはマップに依存しないため、マップの変更に強く、チームが必要に応じてさまざまなマップに適応させることができます。マップにとらわれないテストケースでは、一組の座標を基準とした相対的な配置を使用して、初期の自車位置、初期のアクター位置、およびオブザーバーの領域を定義します。相対的な配置によるマップに依存しない方法である抽象シナリオを使用しすることも、テストケースのスケーラビリティを確保するもう 1 つの方法です。
例 1: 低品質のテストケース
以下のビデオは、低品質のテストケースの例を示しています。
このビデオでは、アクターの行動のすべての異なるバリエーションが1つのシーンに重ねて表示されています。自車は緑のライトで交差点に入り、別のアクターは赤信号であるにもかかわらず右から交差点に入ります。テストケースにはデフォルトのオブザーバー (衝突とスタックヘルスオブザーバー...) のみが含まれます。
リードタイム: この例では、自車とアクターの両方が交差点に近づきすぎているため、リードタイムが不十分になり、現実世界でのリアルなインタラクションを表現できません。質の高いテストケースでは、対象のインタラクションが発生する前に、シミュレートされた環境で自車が初期化し、状態を取得できるよう5～10秒を与えます。
オブザーバー: このテストケースにはデフォルトのオブザーバーしか含まれていないため、自車が交差点をまっすぐ進む代わりに右折し始めると、このテストは意味がなくなります。質の高いテストケースには、テストの妥当性を確認し、より広範な安全性と快適性の性能に関する情報を提供するために、複数のオブザーバーが追加されます。
パラメータースイープ: テストケースでは、アクター速度の広い範囲にわたってパラメータスイープを実行しますが、アクターの初期位置やタイミングでは速度の変動は考慮されません。自車が交差点の始点に達する頃には、アクターはすでにそのバリエーションの半分以上で自車の経路を横切っています。これらのバリエーションは容易に合格できるもので、ADASやADのテストには役立ちません。
自車からの反応を必要とする唯一のバリエーションは、遅いアクターのバリエーションです。これは現実の世界ではまれであり、合格するのがより簡単なテストケースでもあります。質の高いテストケースでは、アクターがすべてのバリエーションで同時に同じポイントに到達するように制限することで、アクターの速度が変化するように制御する必要があります。そうすることで、自車は意図したインタラクションを強いられ、パラメータ化された速度範囲全体でカバー範囲が失われることはありません。
特に、このテストケースにはパラメータースイープ変数が 1 つしか含まれていませんが、テストケース内の各追加変数にも同様の原則が適用されます。複数のパラメータースイープを組み合わせる場合、ADAS と AD のテストでは、さらに小さなバリエーションのサブセットが役立ちます。
結果: 上記の問題により、テストケースが理論的にカバーすべき内容のテストに成功していなくても、テストケースは合格する可能性が高くなります。テストケースの説明には、「交差点を 5 ～ 20 m/s で進む赤信号ランナーとの衝突を、自車が安全に回避できるようにすること」と書かれている場合があります。関係者は、このテストケースがパスすることを見て、考えられるあらゆる変動に対して自車の行動が十分であると考えるようになるかもしれません。このような誤った信頼感は、テストプロセスの後半で隠れたリスクや予期せぬ障害につながり、さらに悪い場合には、安全でないADASやADシステムが実際に本番環境に導入されることとなります。
例 2: 高品質テストケース
次のビデオは、高品質のテストケースの例を示しています。
この例では、一定速度の自車に対して、すべての異なるバリエーションでの道路の横断のタイミングをプレビューしています。歩行者の速度、横断角度、横断タイミングはすべて変化しています。テストケースには、安全性、快適性、シナリオの妥当性に関する関連するテスト基準を把握するオブザーバーもあります（図には非表示）。
リードタイム: 自車と歩行者の間の相互作用は、テストケースに入ってから8秒以上経過して行われるため、自車が適切に反応するための十分な時間が与えられます。
オブザーバー: このテストケースは単に衝突をテストするだけではありません。安全関連のオブザーバーには、衝突までの時間を最小限に抑え、オブザーバーは自車が歩行者に近づきすぎないように確認します。快適性を重視するオブザーバーは、横方向と縦方向の最大加速度とジャークに制限を設けています。最後に、テスト妥当性オブザーバーは、シナリオで少なくとも 1 回、自車が歩行者の大まかな近傍にいる間に意図した目的地に到達することを確認します。
パラメータースイープ: テストケースには、上記の低品質の例よりも大幅に多くのパラメータが含まれているため、この相互作用が幅広くカバーされています。チームは必要に応じてより詳細な情報を簡単に追加できます。
歩行者の速度、横断角度、および歩行者が車線を横断する地点には大きなばらつきがありますが、歩行者の動きに（自車が交差点に到達する時間と一致する特定の時間までに車線の中心に到達する）制約を適用することで、すべてのバリエーションにおける相互作用の適切なタイミングを維持します。その結果、道路に向かう歩行者に反応して自車がブレーキをかけないと、衝突が起こります。
結果：上記の高品質なテストケースは、現実の世界で起こり得るセーフティクリティカルな状況を幅広くカバーしています。このテストは、このような場合のADASまたはADシステムの性能に関する貴重なシグナルとなり、強固なシナリオ設計のベストプラクティスを用いることで、将来自車の行動が変化するのを防ぐことができます。
Applied Intuitionのアプローチ
Applied Intuitionは、ADASおよびAD開発チームが高品質のシミュレーションテストケースを構築し、決定論的テストを効果的に実行し、システムをエンドツーエンドで検証するのをサポートします。事前定義されたシミュレーションテストケースである Test Suitesにより、チームはテストケース作成プロセスをすぐに開始でき、テストケースが常に高品質であることを確認できます。詳しくは Test Suitesチームまでお問い合わせください。
.webp)
.webp)
