知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-07-05
(54)【発明の名称】自律車両テストのためのサポート・ツール
(51)【国際特許分類】
G08G 1/00 20060101AFI20240628BHJP
G09B 9/04 20060101ALI20240628BHJP
G01M 17/007 20060101ALI20240628BHJP
【ＦＩ】
G08G1/00 D
G09B9/04
G01M17/007 D
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2023575621
(86)(22)【出願日】2022-06-08
(85)【翻訳文提出日】2024-01-25
(86)【国際出願番号】 EP2022065487
(87)【国際公開番号】W WO2022258660
(87)【国際公開日】2022-12-15
(31)【優先権主張番号】2108182.3
(32)【優先日】2021-06-08
(33)【優先権主張国・地域又は機関】GB
(31)【優先権主張番号】2108952.9
(32)【優先日】2021-06-22
(33)【優先権主張国・地域又は機関】GB
(31)【優先権主張番号】2108958.6
(32)【優先日】2021-06-22
(33)【優先権主張国・地域又は機関】GB
(31)【優先権主張番号】2111765.0
(32)【優先日】2021-08-17
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】521163628
【氏名又は名称】ファイブ、エーアイ、リミテッド
【氏名又は名称原語表記】ＦＩＶＥ ＡＩ ＬＩＭＩＴＥＤ
(74)【代理人】
【識別番号】100120031
【弁理士】
【氏名又は名称】宮嶋 学
(74)【代理人】
【識別番号】100107582
【弁理士】
【氏名又は名称】関根 毅
(74)【代理人】
【識別番号】100118843
【弁理士】
【氏名又は名称】赤岡 明
(74)【代理人】
【識別番号】100152205
【弁理士】
【氏名又は名称】吉田 昌司
(72)【発明者】
【氏名】ティム、ヤング
(72)【発明者】
【氏名】ベン、グレーブズ
(72)【発明者】
【氏名】マウリツィオ、モリエッロ
(72)【発明者】
【氏名】ジェイミー、クルックシャンク
【テーマコード（参考）】
5H181
【Ｆターム（参考）】
5H181AA01
5H181BB20
5H181CC03
5H181CC04
5H181CC12
5H181CC14
5H181FF04
5H181FF10
5H181FF22
5H181FF27
5H181FF32
5H181LL09
(57)【要約】
自律車両のパフォーマンスを査定するためのコンピュータ実装方法であって、少なくとも１回の自律運転走行のパフォーマンス・データを入力において受け取ることであって、パフォーマンス・データは、少なくとも１つの認識エラーの時系列と、少なくとも１つの運転パフォーマンス結果の時系列とを備える、受け取ることと、グラフィカル・ユーザ・インターフェースをレンダリングするためのレンダリング・データをレンダリング・コンポーネントにおいて生成することであって、グラフィカル・ユーザ・インターフェースは、パフォーマンス・データを視覚化するためのものであり、認識エラー・タイムラインおよび運転査定タイムラインを備える、生成することと、を備え、タイムラインは時間的に位置合わせされ、少なくとも１回の運転走行の複数の時間ステップに分割され、各時間ステップについて、認識エラー・タイムラインは、その時間ステップにおいて認識エラーが発生したか否かの視覚的指示を備え、運転査定タイムラインは、その時間ステップにおける運転パフォーマンスの視覚的指示を備え、コンピュータ実装方法。
【特許請求の範囲】
【請求項1】
自律車両のパフォーマンスを査定するためのコンピュータ実装方法であって、少なくとも１回の自律運転走行のパフォーマンス・データを入力において受け取ることであって、前記パフォーマンス・データは、少なくとも１つの認識エラーの時系列と、少なくとも１つの運転パフォーマンス結果の時系列とを備える、前記受け取ることと、
グラフィカル・ユーザ・インターフェースをレンダリングするためのレンダリング・データをレンダリング・コンポーネントにおいて生成することであって、前記グラフィカル・ユーザ・インターフェースは、前記パフォーマンス・データを視覚化するためのものであり、
（ｉ）認識エラー・タイムライン、および
（ｉｉ）運転査定タイムライン、
を備える、前記生成することと、
を備え、
前記タイムラインは時間的に位置合わせされ、前記少なくとも１回の運転走行の複数の時間ステップに分割され、各時間ステップについて、前記認識エラー・タイムラインは、前記時間ステップにおいて認識エラーが発生したか否かの視覚的指示を備え、前記運転査定タイムラインは、前記時間ステップにおける運転パフォーマンスの視覚的指示を備える、
コンピュータ実装方法。
【請求項2】
前記認識エラー・タイムラインおよび前記運転査定タイムラインは相互に平行である、請求項１に記載の方法。
【請求項3】
前記運転パフォーマンスは、１つまたは複数の事前定義された運転ルールに関して査定される、請求項１または２に記載の方法。
【請求項4】
前記運転査定タイムラインは、複数の個々の運転ルールにわたって運転パフォーマンスを集約し、前記運転査定タイムラインは、前記個々の運転ルールのそれぞれの運転査定タイムラインを閲覧するために展開可能である、請求項３に記載の方法。
【請求項5】
前記運転査定タイムラインまたは各運転査定タイムラインは、前記運転ルールの計算グラフ表現を閲覧するために展開可能である、請求項３または４に記載の方法。
【請求項6】
前記運転走行は現実世界での走行であり、現実世界での軌跡に運転ルールが適用される、請求項３から５のいずれかに記載の方法。
【請求項7】
グラウンド・トゥルーシング・パイプラインが、グラウンド・トゥルース認識出力を抽出するために使用され、前記グラウンド・トゥルース認識出力は、認識エラーを決定し、運転パフォーマンスを査定するために使用される、請求項１から６のいずれかに記載の方法。
【請求項8】
前記グラウンド・トゥルーシング・パイプラインは自動化される、請求項７に記載の方法。
【請求項9】
グラウンド・トゥルース認識出力の使用なしで少なくとも一部の認識エラーが識別される、請求項１から８のいずれかに記載の方法。
【請求項10】
前記認識エラーは、ちらつく検出結果、または
ジャンプする検出結果
のうちの少なくとも１つを備える、請求項９に記載の方法。
【請求項11】
前記パフォーマンス・データは、関心対象の認識エリアを示す少なくとも１つの数値的認識スコアの時系列を備え、前記グラフィカル・ユーザ・インターフェースは、少なくとも対応する数値的認識スコアのタイムラインを備え、各時間ステップについて、前記数値的認識スコア・タイムラインは、前記時間ステップに関連付けられた前記数値的認識スコアの視覚的指示を備える、請求項１から１０のいずれかに記載の方法。
【請求項12】
前記数値的認識スコアの時系列は、各時間ステップにおける前記認識システムにとっての難易度の尺度を示す困難性スコアの時系列である、請求項１１に記載の方法。
【請求項13】
前記パフォーマンス・データは、少なくとも１つのユーザ定義スコアの時系列を備え、前記グラフィカル・ユーザ・インターフェースは、少なくとも１つの対応するカスタム・タイムラインを備え、各時間ステップについて、前記カスタム・タイムラインは、前記時間ステップで評価された前記ユーザ定義スコアの視覚的指示を備える、請求項１から１２のいずれかに記載の方法。
【請求項14】
前記運転走行はシミュレートされた運転走行であり、前記認識エラーはシミュレートされた認識エラーを備える、請求項１から５のいずれかに記載の方法。
【請求項15】
前記シミュレートされた認識エラーを提供し、グラウンド・トゥルース・シミュレータの状態を、前記スタックの上位レベルのコンポーネントに提供される現実的な認識出力に変換するために、１つまたは複数の認識エラー・モデルが使用される、請求項１４に記載の方法。
【請求項16】
前記シミュレートされた認識エラーは、合成センサ・データおよびシミュレーション・グラウンド・トゥルースに基づいて導出され、前記合成センサ・データは、シミュレーションで生成され、前記スタックの認識システムによって処理される、請求項１４に記載の方法。
【請求項17】
運転ルール、認識エラー、またはシーン・パラメータのうちの１つまたは複数に基づいて、フィルタも前記２つのタイムラインに適用される、請求項１から１６のいずれかに記載の方法。
【請求項18】
請求項１～１７に記載の方法を実装するように構成される１つまたは複数のコンピュータを備える、コンピュータ・システム。
【請求項19】
請求項１～１７に記載の方法を実装するようにコンピュータ・システムをプログラミングするための実行可能なプログラム命令を備える、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、現実のシナリオまたはシミュレートされたシナリオにおける自律車両システムおよび軌道（ｔｒａｊｅｃｔｏｒｙ）プランナのパフォーマンスを評価するためのツールおよび方法、ならびにそれらを実装するためのコンピュータ・プログラムおよびシステムに関する。適用例は、ＡＤＳ（自律運転システム：Ａｕｔｏｎｏｍｏｕｓ Ｄｒｉｖｉｎｇ Ｓｙｓｔｅｍ）およびＡＤＡＳ（先進運転支援システム：Ａｄｖａｎｃｅｄ Ｄｒｉｖｅｒ Ａｓｓｉｓｔ Ｓｙｓｔｅｍ）のパフォーマンス・テストを含む。
【背景技術】
【0002】
自律車両の分野では、大きく急速な発展があった。自律車両（ＡＶ：ａｕｔｏｎｏｍｏｕｓ ｖｅｈｉｃｌｅ）は、その挙動を人間が制御しなくても動作することを可能にするセンサおよび制御システムが装備された車両である。自律車両には、その物理的環境を認識（ｐｅｒｃｅｉｖｅ）することを可能にするセンサが装備されており、そのようなセンサは、たとえば、カメラ、レーダー、およびライダーを含む。自律車両には、センサから受け取られたデータを処理し、センサによって認識されたコンテキストに基づいて安全かつ予測可能な決定を下すことが可能な、適切にプログラムされたコンピュータが装備されている。自律車両は、（少なくとも特定の状況では人間の監督も介入もなしで動作するように設計されているという点で）完全自律型であるか、または半自律型である場合がある。半自律システムは様々なレベルの人間の監視および介入を必要とし、そのようなシステムは先進運転支援システムおよびレベル３の自律運転システムを含む。特定の自律車両またはあるタイプの自律車両に搭載されたセンサおよび制御システムの挙動のテストには様々な側面がある。
【0003】
「レベル５」の車両は、最低限の安全性レベルを満たすことが常に保証されているので、いかなる状況でも完全に自律的に動作することができるものである。そのような車両は、手動制御（ステアリング・ホイール、ペダルなど）を全く必要としない。
【0004】
対照的に、レベル３およびレベル４の車両は完全に自律的に動作することができるが、特定の定義された状況内（たとえば、ジオフェンス・エリア内）でのみ動作する。レベル３の車両は、即時の対応（たとえば、緊急ブレーキ）を必要とするあらゆるシチュエーションに自律的に対処するように装備されていなければならないが、状況の変化は、ドライバーがある限られた時間枠内に車両の制御を取得することを求める「移行要求」を発動してもよい。レベル４の車両も同様の制限を有するが、ドライバーが求められる時間枠内に対応しなかった場合、レベル４の車両は「ミニマム・リスク・マヌーバ」（ＭＲＭ：ｍｉｎｉｍｕｍ ｒｉｓｋ ｍａｎｅｕｖｅｒ）、すなわち、車両を安全な状態にするための適切な措置（たとえば、減速して車両を駐車する）を自律的に実施することも可能でなければならない。レベル２の車両は、ドライバーがいつでも介入できるように準備を整えておくことを必要とし、自律システムが適切に対応できなくなった場合にいつでも介入するのはドライバーの責任である。レベル２の自動化では、いつ介入が求められるかを決定するのはドライバーの責任であり、レベル３およびレベル４では、この責任は車両の自律システムに移り、介入が求められる場合にドライバーに警告しなければならないのは車両である。
【0005】
自律性のレベルが上がり、より多くの責任が人間から機械に移るにつれて、安全性はますます難しい課題となる。自律運転では、保証された安全性の重要性が認識されている。保証された安全性は、必ずしも事故がゼロであることを示唆するものではなく、定義された状況において最低限の安全性レベルが満たされることを保証することを意味する。自律運転が実現可能になるには、この最低限の安全性レベルが人間のドライバーの安全性レベルを大幅に上回らなければならないと一般に考えられている。
【0006】
全体が引用により本明細書に組み込まれている、Ｓｈａｌｅｖ－Ｓｈｗａｒｔｚら、「Ｏｎ ａ Ｆｏｒｍａｌ Ｍｏｄｅｌ ｏｆ Ｓａｆｅ ａｎｄ Ｓｃａｌａｂｌｅ Ｓｅｌｆ－ｄｒｉｖｉｎｇ Ｃａｒｓ」（２０１７）、ａｒＸｉｖ：１７０８．０６３７４（ＲＳＳの論文）によれば、人間の運転は１時間あたり１０－６回のオーダーの重大事故を引き起こすと推定されている。自律運転システムがこれを少なくとも３桁削減する必要があるという仮定に基づいて、ＲＳＳの論文は、１時間あたり１０－９回のオーダーの重大事故の最低安全性レベルが保証される必要があると結論付けており、そのため、純粋なデータ駆動型のアプローチは、ＡＶシステムのソフトウェアまたはハードウェアに変更がなされるたびに、膨大な量の運転データが収集されることを必要とすると指摘している。
【0007】
ＲＳＳの論文は、保証された安全性へのモデル・ベースのアプローチを提供する。ルール・ベースの責任感知型安全論（ＲＳＳ：Ｒｅｓｐｏｎｓｉｂｉｌｉｔｙ－Ｓｅｎｓｉｔｉｖｅ Ｓａｆｅｔｙ）モデルは、以下の少数の「常識的な」運転ルールを形式化することによって構築される。
「１．後ろから人にぶつかってはならない。
２．むやみに割り込んではならない。
３．通行権は与えられるものであり、奪うものではない。
４．見通しの悪い場所では注意せよ。
５．別の事故を起こさずに事故を回避できるなら、そうしなければならない。」
ＲＳＳモデルは、全てのエージェントが常にＲＳＳモデルのルールを遵守していれば事故は起こらないという意味で、安全であることが証明されている。狙いは、求められる安全性レベルを実証するために収集される必要がある運転データの量を数桁削減することである。
「１．後ろから人にぶつかってはならない。
２．むやみに割り込んではならない。
３．通行権は与えられるものであり、奪うものではない。
４．見通しの悪い場所では注意せよ。
５．別の事故を起こさずに事故を回避できるなら、そうしなければならない。」
ＲＳＳモデルは、全てのエージェントが常にＲＳＳモデルのルールを遵守していれば事故は起こらないという意味で、安全であることが証明されている。狙いは、求められる安全性レベルを実証するために収集される必要がある運転データの量を数桁削減することである。
【0008】
安全性モデル（たとえば、ＲＳＳ）は、自律システム（スタック）の制御下で現実のシナリオまたはシミュレートされたシナリオにおいて自エージェントによって計画または実現される軌道の質を評価するための基礎として使用されることができる。スタックは、これを様々なシナリオにさらし、その結果得られる自己軌道を安全性モデルのルールの順守について評価することによってテストされる（ルール・ベースのテスト）。ルール・ベースのテスト・アプローチは、快適性または定められたゴールに向けた進捗状況など、パフォーマンスの他の側面にも適用されることができる。
【発明の概要】
【発明が解決しようとする課題】
【0009】
エキスパートがＡＶシステムの認識エラーと運転パフォーマンスとの両方を査定することを可能にする技術が説明される。ＡＶの認識システムの認識出力をグラウンド・トゥルース認識出力との比較により評価することは、エキスパートが所与のＡＶシステムの全体的なパフォーマンスに対する認識の課題の影響を査定することを可能にする。本明細書では、認識エラーおよび運転パフォーマンスを単一の視覚化に提示して、認識と運転パフォーマンスとの間の相関関係を提供し、全体的な運転パフォーマンスに影響を与える可能性がある認識エラーの原因をエキスパートが特定するのを支援するＵＩが説明される。
【課題を解決するための手段】
【0010】
本明細書における第１の態様は、リアルタイム認識システムをテストするためのコンピュータ・システムであって、リアルタイム認識システムはセンサが装備された車両に配備するためのものであり、コンピュータ・システムは、
センサが装備された車両によって実行される少なくとも１回の現実世界での運転走行（ｄｒｉｖｉｎｇ ｒｕｎ）のデータを受け取るように構成される少なくとも１つの入力であって、データは、（ｉ）センサが装備された車両によってキャプチャされたセンサ・データの時系列と、（ｉｉ）テスト対象のリアルタイム認識システムによってセンサ・データの時系列から抽出された少なくとも１つの関連する走行時認識出力の時系列と、を備える、少なくとも１つの入力と、
グラフィカル・ユーザ・インターフェース（ＧＵＩ）をレンダリングするためのレンダリング・データを生成するように構成されるレンダリング・コンポーネントであって、グラフィカル・ユーザ・インターフェースは、少なくとも１回の現実世界での運転走行の複数の時間ステップのうちのそれぞれについて、時間ステップで発生した認識エラーの視覚的指示を有する認識エラー・タイムラインを備える、レンダリング・コンポーネントと、
少なくとも１つのグラウンド・トゥルース認識出力の時系列（「擬似グラウンド・トゥルース」）を走行時認識出力との比較用に抽出するために、（ｉ）センサ・データの時系列、および（ｉｉ）走行時認識出力の時系列のうちの少なくとも１つに少なくとも１つの非リアルタイムおよび／または非因果的認識アルゴリズムを適用することによって、その少なくとも１つを処理するように構成されるグラウンド・トゥルーシング・パイプラインと、
走行時認識出力の時系列をグラウンド・トゥルース認識出力の時系列と比較することによって、認識エラー・タイムラインを生成するために１つまたは複数の時間区間で発生した認識エラーを識別するように構成される認識オラクルと、
を備える、コンピュータ・システムを対象とする。
センサが装備された車両によって実行される少なくとも１回の現実世界での運転走行（ｄｒｉｖｉｎｇ ｒｕｎ）のデータを受け取るように構成される少なくとも１つの入力であって、データは、（ｉ）センサが装備された車両によってキャプチャされたセンサ・データの時系列と、（ｉｉ）テスト対象のリアルタイム認識システムによってセンサ・データの時系列から抽出された少なくとも１つの関連する走行時認識出力の時系列と、を備える、少なくとも１つの入力と、
グラフィカル・ユーザ・インターフェース（ＧＵＩ）をレンダリングするためのレンダリング・データを生成するように構成されるレンダリング・コンポーネントであって、グラフィカル・ユーザ・インターフェースは、少なくとも１回の現実世界での運転走行の複数の時間ステップのうちのそれぞれについて、時間ステップで発生した認識エラーの視覚的指示を有する認識エラー・タイムラインを備える、レンダリング・コンポーネントと、
少なくとも１つのグラウンド・トゥルース認識出力の時系列（「擬似グラウンド・トゥルース」）を走行時認識出力との比較用に抽出するために、（ｉ）センサ・データの時系列、および（ｉｉ）走行時認識出力の時系列のうちの少なくとも１つに少なくとも１つの非リアルタイムおよび／または非因果的認識アルゴリズムを適用することによって、その少なくとも１つを処理するように構成されるグラウンド・トゥルーシング・パイプラインと、
走行時認識出力の時系列をグラウンド・トゥルース認識出力の時系列と比較することによって、認識エラー・タイムラインを生成するために１つまたは複数の時間区間で発生した認識エラーを識別するように構成される認識オラクルと、
を備える、コンピュータ・システムを対象とする。
【0011】
実施形態では、走行時認識出力の時系列とグラウンド・トゥルース認識出力の時系列との間の数値的エラー値を計算し、数値的エラー値を少なくとも１つの認識エラー閾値と比較することによって、認識エラーが識別されてもよい。
【0012】
たとえば、数値的エラー値がエラー閾値を超えている場合にのみ、数値的エラー値が認識エラーとして識別されてもよい。
【0013】
エラー閾値は固定でも可変でもよい。たとえば、異なる認識エラー閾値が、異なるアクター／エージェント、またはそれらの異なるタイプに適用されてもよい（たとえば、車両対歩行者で異なる閾値など）。
【0014】
エラー閾値は、たとえば、ＧＵＩを介して、または認識オラクルに提供されるルール定義命令（たとえば、ドメイン固有言語（ＤＳＬ：Ｄｏｍａｉｎ－Ｓｐｅｃｉｆｉｃ Ｌａｎｇｕａｇｅ）でコード化されたもの）を介して調整可能であってもよく、または別の方法で設定可能であってもよい。ルール定義命令をＤＳＬで、認識エラー仕様の形態でコード化するために、ルール・エディタが提供されてもよい。後者のアプローチは、本明細書で「認識エラー・フレームワーク」と呼ばれるものを提供する。
【0015】
エラー閾値はまた、運転走行の１つまたは複数のシーン変数（走行変数）、たとえば、エラー閾値が適用されるオブジェクトの変数に応じて変更されてもよい。たとえば、所与のオブジェクト（たとえば、エージェントまたは静的オブジェクト）について、そのオブジェクトの認識エラー閾値は、（近くのオブジェクトにとって、より小さい認識エラーがより重大であることに基づいて）そのオブジェクトと自エージェントとの間の距離と共に増加させられてもよい。同じ効果は、固定閾値を使用しても実現されることができ、ただし、数値的エラー値がシーン変数に応じて重み付けされる（たとえば、距離の逆数によって重み付けされる）。本明細書において、別段の指示がない限り、「可変閾値」への言及は後者の実装を包含する。
【0016】
（重み付けされた）数値的認識エラーは正規化されてもよく、すなわち、任意選択により固定エラー閾値と共に、ある所定のスケールに、たとえば、不合格閾値がゼロに設定された範囲［－１，１］に変換される。正規化された認識エラーは、認識「ロバスト性」スコアと呼ばれる場合がある。
【0017】
重み付け基準／可変閾値は、たとえばＧＵＩまたはＤＳＬを介して設定可能であってもよい。
【0018】
識別された認識エラーに加えて、（正規化された）エラー値がＧＵＩを介してアクセス可能にされてもよい。
【0019】
より複雑なルールを適用して、たとえば、複数の認識エラー値またはそれらの組み合わせをマッピングすることによって、１つまたは複数のエラー閾値に基づいて認識エラーを識別することができる。
【0020】
「認識エラー」は、認識エラーの２値のインジケータ（エラーあり／エラーなし）、または非２値のカテゴリ・インジケータ（たとえば、赤、緑、青の「信号機」スタイルの分類）とすることができる。
【0021】
認識エラーは、たとえば、複数のオブジェクトおよび／またはセンサおよび／またはセンサ・モダリティにわたって集約された認識エラー数とすることができる。
【0022】
たとえば、認識エラー・ルールは階層的に定義されてもよい。たとえば、複数のセンサおよび／またはセンサ・モダリティ（たとえば、ライダー、レーダー、カメラなど）および／または複数のオブジェクトを用いて、複数のモダリティ／オブジェクトにわたって集約された集約認識エラーが抽出されてもよい。この場合、複数の認識エラー・タイムラインが導出されてもよく、たとえば、所定のルールを「下位レベル」のタイムライン（たとえば、特定のオブジェクト、センサ、および／またはセンサ・モダリティに関するもの）に適用することによって、「最上位」の集約タイムラインが入力される。最上位のタイムラインは、下位レベルのタイムラインを閲覧するために展開可能であってもよい。運転走行の「ズーム・アウト」されたビューを提供するために、認識エラーが時間ウィンドウにわたって集約されてもよい。
【0023】
認識オラクルは、走行の少なくとも１つの時間区間をフィルタリングするように構成されてもよく、その時間区間は認識エラー・タイムラインから省略され、フィルタリングは、認識エラー（たとえば、認識エラーが発生しなかった時間区間をフィルタリングするため）、ならびに／あるいは現実世界での運転走行に関連付けられた１つまたは複数のタグ／ラベル（たとえば、交通弱者などの特定のタイプのシーン要素が存在する区間のみを含めるため）に適用される１つまたは複数のフィルタリング基準に基づいて実行されてもよい。たとえば、タグは、動的および／または静的なシーン要素または条件（アクター、天候、照明など）に関連するオントロジー・タグを含んでもよい。そのようなフィルタリングは、タイムラインの「スライシング」と呼ばれる場合もある。
【0024】
タイムラインは複数回の運転走行を集約してもよい。スライシングは、このコンテキストでは、タイムラインに表示される「関心のない」情報の範囲を削減する方法として有用なツールである。
【0025】
タグはＧＵＩを介してアクセス可能であってもよい。
【0026】
運転走行の概略表現がＧＵＩ上に表示されてもよい。静的表現は現在の時間ステップにおける運転走行の静的なスナップショットを表示してもよく、現在の時間ステップはＧＵＩへの命令を介して選択可能である。現在の時間ステップが変化させられると、視覚的インジケータが、認識エラー・タイムライン上で現在の時間ステップをマークするように変化させられてもよい。概略表現と共に、少なくとも１回の現実世界での運転走行の（生）データも表示されてもよい。たとえば、概略的なトップ・ダウン・ビューが、現実世界での運転走行の少なくとも１つの３Ｄ点群（たとえば、ライダー、レーダー、もしくはモノラル／ステレオ深度点群、またはそれらの任意の組み合わせ／集約）が重ねられて表示されてもよい。代替的または追加的には、現在の時間ステップに関する、１回の現実世界での運転走行からの少なくとも１つのキャプチャされた画像が表示されてもよい（現在の時間ステップを変更することは、それに応じて対応する画像でＧＵＩが更新されることを引き起こす）。
【0027】
運転走行の概略表現は、走行時認識出力の時系列を使用してレンダリングされてもよい。たとえば、走行時認識出力の時系列は、複数の検出されたオブジェクトのそれぞれに対するグラウンド・トゥルース・バウンディング・ボックス（位置、姿勢、サイズ）の時系列と、各オブジェクトの識別されたオブジェクト・タイプと、を含んでもよく、これらは運転走行の既知の道路レイアウト（たとえば、地図から導出されたもの）上にそのオブジェクトの視覚的なアイコンをレンダリングするために使用される。
【0028】
走行時認識出力の時系列も、グラウンド・トゥルース認識出力との視覚的な比較のためにＧＵＩを介して表示されてもよい。たとえば、走行時認識出力の時系列は、後者から導出された概略表現上に重ねられてもよい。たとえば、走行時認識出力は、検出されたリアルタイム・バウンディング・ボックスの複数の時系列を含んでもよく、現在の時間ステップに関連付けられた走行時バウンディング・ボックスのサブセットが、現在の時間ステップのスナップショット上に重ねられてもよい。
【0029】
認識グラウンド・トゥルースは、各エージェント（自エージェントおよび／または他のエージェント）の軌跡（ｔｒａｃｅ）の形態であってもよく、軌跡は空間状態および運動状態（たとえば、バウンディング・ボックスおよび検出された速度ベクトルまたは他の動きベクトル）の時間シーケンスである。
【0030】
抽出された軌跡は、ＧＵＩで走行を視覚化するために使用されてもよい。
【0031】
ＧＵＩでシナリオを動的に「リプレイ」するオプションが提供されてもよく、シナリオが進行するにつれて、ビデオ・インジケータが認識エラー・タイムラインに沿って移動する。
【0032】
同じグラウンド・トゥルース認識出力（たとえば、軌跡）に適用された運転パフォーマンス査定の結果を伝える第２の運転パフォーマンス・タイムラインもＧＵＩ上に表示されてもよい。たとえば、この目的でテスト・オラクルが提供されてもよい。
【0033】
走行データは、複数のセンサ・モダリティ、たとえば、ライダー、レーダー、および画像（たとえば、ステレオまたはモノラル・イメージングからの深度データ）のうちの２つ以上を含んでもよい。
【0034】
いくつかの実施形態では、あるセンサ・モダリティ（またはセンサ・モダリティの組み合わせ）が、他のセンサ・モダリティ（またはセンサ・モダリティの組み合わせ）のグラウンド・トゥルースを提供するために使用されてもよい。たとえば、より正確なライダーを使用して、レーダーまたは画像（モノラルまたはステレオ）データから導出される検出結果または他の認識出力のベースラインとして使用される擬似グラウンド・トゥルースを導出してもよい。
【0035】
比較的少量の手動でラベル付けされたグラウンド・トゥルースが、たとえば、擬似グラウンド・トゥルースまたは走行時認識出力の精度を検証または測定するためのベースラインとして、システム内で使用されてもよい。
【0036】
上記は擬似グラウンド・トゥルースから導出される認識エラーを考えたが、本発明の他の態様では、上記のＧＵＩを使用して、他の方法で導出された認識エラー（擬似グラウンド・トゥルースの使用なしで現実世界データから導出されたもの、およびシミュレータで生成されたシミュレートされた運転走行の認識エラー）をレンダリングすることができる。シミュレートされた走行の場合、上記の説明は、（グラウンド・トゥルーシング・パイプラインを必要とせずに）シミュレータによって直接提供されるグラウンド・トゥルース、およびシミュレートされた走行のシーン変数にも同様に当てはまる。
【0037】
本明細書における第２の態様は、自律車両のパフォーマンスを査定するためのコンピュータ・システムであって、
少なくとも１回の自律運転走行のパフォーマンス・データを受け取るように構成される少なくとも１つの入力であって、パフォーマンス・データは、少なくとも１つの認識エラーの時系列と、少なくとも１つの運転パフォーマンス結果の時系列とを含む、少なくとも１つの入力と、
グラフィカル・ユーザ・インターフェースをレンダリングするためのレンダリング・データを生成するように構成されるレンダリング・コンポーネントであって、グラフィカル・ユーザ・インターフェースは、パフォーマンス・データを視覚化するためのものであり、
（ｉ）認識エラー・タイムライン、および
（ｉｉ）運転査定タイムライン、
を備える、レンダリング・コンポーネントと、
を備え、
タイムラインは時間的に位置合わせされ、少なくとも１回の運転走行の複数の時間ステップに分割され、各時間ステップについて、認識エラー・タイムラインは、その時間ステップで認識エラーが発生したか否かの視覚的指示を含み、運転査定タイムラインは、その時間ステップにおける運転パフォーマンスの視覚的指示を含む、
コンピュータ・システムを提供する。
少なくとも１回の自律運転走行のパフォーマンス・データを受け取るように構成される少なくとも１つの入力であって、パフォーマンス・データは、少なくとも１つの認識エラーの時系列と、少なくとも１つの運転パフォーマンス結果の時系列とを含む、少なくとも１つの入力と、
グラフィカル・ユーザ・インターフェースをレンダリングするためのレンダリング・データを生成するように構成されるレンダリング・コンポーネントであって、グラフィカル・ユーザ・インターフェースは、パフォーマンス・データを視覚化するためのものであり、
（ｉ）認識エラー・タイムライン、および
（ｉｉ）運転査定タイムライン、
を備える、レンダリング・コンポーネントと、
を備え、
タイムラインは時間的に位置合わせされ、少なくとも１回の運転走行の複数の時間ステップに分割され、各時間ステップについて、認識エラー・タイムラインは、その時間ステップで認識エラーが発生したか否かの視覚的指示を含み、運転査定タイムラインは、その時間ステップにおける運転パフォーマンスの視覚的指示を含む、
コンピュータ・システムを提供する。
【0038】
運転査定タイムラインおよび認識エラー・タイムラインは相互に平行であってもよい。
【0039】
上記のツールは、運転パフォーマンスを認識エラーに視覚的に結び付けて、ＡＤＳ／ＡＤＡＳパフォーマンスが低い／許容不可能な場合についてエキスパートが判断するのを支援する。たとえば、重大な運転ルールの不合格が発生した運転パフォーマンス・タイムラインの領域に焦点を当てることにより、エキスパートは、同じ瞬間の認識エラー・タイムラインを閲覧して、認識エラーがそのルールの不合格に影響を与えていた可能性があるか否かを確認することができる。
【0040】
実施形態では、運転パフォーマンスは、１つまたは複数の事前定義された運転ルールに関して査定されてもよい。
【0041】
運転パフォーマンス・タイムラインは、複数の個々の運転ルールにわたって運転パフォーマンスを集約してもよく、個々の運転ルールのそれぞれの運転パフォーマンス・タイムラインを閲覧するために展開可能であってもよい。
【0042】
運転パフォーマンス（または各運転パフォーマンス）は、（以下で説明されるように）ルールの計算グラフ表現を閲覧するために展開可能であってもよい。
【0043】
運転走行は現実世界での走行であってもよく、現実世界での軌跡に運転ルールが適用される。
【0044】
場合によっては、グラウンド・トゥルーシング・パイプラインを使用して（擬似）グラウンド・トゥルース軌跡／認識出力を抽出してもよく、これは、認識エラーを決定し、運転ルールに関するパフォーマンスを査定するために使用される（上記の第１の態様と同様）。
【0045】
代替的には、擬似グラウンド・トゥルースの使用なしで認識エラーが識別されてもよい。たとえば、そのようなエラーは、「ちらつく」オブジェクト（これは走行時オブジェクト検出器が失敗すると出現／消失する）、または「ジャンプする」オブジェクト（これは、運動学的に実行不可能な方法でシーン内でジャンプするように見え、たとえば、走行時検出器は、走行内のある時点で２つの近くのオブジェクトを「入れ替える」場合がある）から識別されてもよい。
【0046】
パフォーマンス・データは、関心対象の認識エリアを示す少なくとも１つの数値的認識スコアの時系列を含んでもよく、グラフィカル・ユーザ・インターフェースは、少なくとも対応する数値的認識スコアのタイムラインを備えてもよく、各時間ステップについて、数値的認識スコア・タイムラインは、その時間ステップに関連付けられた数値的認識スコアの視覚的指示を含む。
【0047】
数値的認識スコアの時系列は、各時間ステップにおける認識システムにとっての難易度の尺度を示す困難性（ｈａｒｄｎｅｓｓ）スコアの時系列であってもよい。
【0048】
パフォーマンス・データは、少なくとも１つのユーザ定義スコアの時系列を含んでもよく、グラフィカル・ユーザ・インターフェースは、少なくとも１つの対応するカスタム・タイムラインを備えてもよく、各時間ステップについて、カスタム・タイムラインは、その時間ステップで評価されたユーザ定義スコアの視覚的指示を含む。
【0049】
代替的には、走行はシミュレートされた走行であってもよく、認識エラーはシミュレートされてもよい。
【0050】
たとえば、認識エラーをサンプリングし、またはより一般的には、グラウンド・トゥルース・シミュレータの状態を、シミュレーション中のテスト対象のスタックの上位レベルのコンポーネントに提供されるより現実的な認識エラーに変換するために、１つまたは複数の認識エラー（または認識パフォーマンス）モデルが使用されてもよい。
【0051】
他の例として、合成センサ・データがシミュレーションで生成され、現実のセンサ・データと同じようにスタックの認識システムによって処理されてもよい。この場合、シミュレートされた認識エラーは、現実世界の認識エラーと同じように導出されることができる（ただし、この場合、シミュレータに固有のグラウンド・トゥルースとの比較によって認識エラーが識別されることができるので、パイプラインのグラウンド・トゥルースは必要ない）。
【0052】
フィルタ／スライシングもタイムラインに適用されて、たとえば、特定のルール／ルールの組み合わせに関する不合格付近の期間のみが呈示されてもよい。したがって、運転パフォーマンス・タイムラインに適用されたルールに基づいて、認識エラー・タイムラインがフィルタリング／スライスされることができ、その逆も同様である。
【0053】
グラフィカル・ユーザ・インターフェースは、タイムラインと位置合わせされたプログレス・バーを備えてもよく、プログレス・バーは、一定の時間区間を示す１つまたは複数のマーカーを有し、各区間は運転走行の１つまたは複数の時間ステップを含む。マーカーのサブセットは、数値的な時間インジケータでラベル付けされてもよい。
【0054】
グラフィカル・ユーザ・インターフェースは、タイムラインにまたがり、運転走行の選択された時間ステップを示すスクラバー・バーを備えてもよい。ユーザがタイムラインのうちの１つの点をクリックして、運転走行の新しい時間ステップを選択したことに応答して、スクラバー・バーがタイムラインに沿って移動してもよく、その結果、選択された点でスクラバー・バーがタイムラインにまたがる。
【0055】
グラフィカル・ユーザ・インターフェースは、タイムラインに含まれる運転走行の時間ステップ数を増減させるために使用可能なズーム入力を備えてもよい。ズーム入力を使用してタイムライン内の時間ステップ数を増減させると、タイムラインが一定の長さを維持するように、各時間ステップの視覚的インジケータがそれぞれ縮小または拡大するようタイムラインが構成されてもよい。
【0056】
プログレス・バーは、ズーム入力を使用してタイムライン内の時間ステップ数を閾値未満に減少させると、マーカーがより短い時間区間を示すように調整されるように構成されてもよい。ズーム入力を使用して、閾値を超えてタイムライン内の時間ステップ数を増加させると、マーカーがより長い時間区間を示すように調整されてもよい。
【0057】
ズーム入力を使用して運転走行の時間ステップ数を調整すると、タイムラインが、タイムライン上の基準点から定義された範囲内の時間ステップのみを含むように調整されてもよい。基準点は、運転走行の開始点であってもよい。代替的には、基準点は、運転走行の現在選択されている時間ステップであってもよい。現在選択されている点は、スクラバー・バーによって示されてもよい。
【0058】
ズーム入力はズーム・スライダー・バーを備えてもよく、これは、スライダー・バーに沿ってインジケータを移動させることによってタイムライン内の時間ステップ数を調整するために使用されてもよい。インジケータは、スライダーをクリックしてバーに沿ってドラッグするか、またはインジケータの移動先となるスライダー上の点をクリックすることによって移動されてもよい。ズーム入力は、タッチ・スクリーン上のピンチ・ジェスチャを含んでもよく、これは、スクリーンに接触している２本の指の間の距離の変化に基づいてタイムライン内の時間ステップ数を調整する。代替的には、ズーム入力はマウス・ホイールを含んでもよく、これは、ユーザがホイールを前後に回転させたことに応答してタイムライン内の時間ステップ数を調整する。
【0059】
タイムラインはスクロール可能であってもよく、タイムラインに表示される複数の時間ステップが、ユーザのスクロール・アクションに応答して時間的に前後にシフトするように調整される。
【0060】
運転走行の一部分が、その部分の開始時刻を示すプログレス・バー上の第１の点をクリックし、その部分の終了時刻を定義する第２の点までプログレス・バーに沿ってドラッグすることにより、選択されてもよい。選択された部分に対応する運転データが抽出されてデータベースに記憶されてもよい。
【0061】
上記の第１の態様は、走行時認識出力を導出された（擬似）グラウンド・トゥルース認識出力のセットと比較することにより、リアルタイム認識システムをテストすることに言及している。他の態様では、実施形態の上記の任意の特徴をより一般的に適用して、任意の認識出力のシーケンスを、対応するグラウンド・トゥルース認識出力のシーケンスとの比較によって評価することができる。このコンテキストでは、グラウンド・トゥルースは、ベースラインとの比較により認識出力を評価する目的で正確であるとみなされる任意のベースラインであってもよい。
【0062】
本明細書における第３の態様は、
少なくとも１回の運転走行に関するデータを受け取るように構成される少なくとも１つの入力であって、データは、（ｉ）第１の認識出力の時系列と、（ｉｉ）第２のグラウンド・トゥルース認識出力の時系列と、を含み、グラウンド・トゥルース認識出力の時系列および走行時認識出力の時系列は少なくとも１つの時間区間に関連する、少なくとも１つの入力と、
グラフィカル・ユーザ・インターフェース（ＧＵＩ）をレンダリングするためのレンダリング・データを生成するように構成されるレンダリング・コンポーネントであって、グラフィカル・ユーザ・インターフェースは、少なくとも１回の運転走行の複数の時間ステップのうちのそれぞれについて、その時間ステップで発生した認識エラーの視覚的指示を有する認識エラー・タイムラインを備える、レンダリング・コンポーネントと、
認識出力の時系列をグラウンド・トゥルース認識出力の時系列と比較することによって、認識エラー・タイムラインを生成するために１つまたは複数の時間区間で発生した認識エラーを識別するように構成される認識オラクルと、
を備える、コンピュータ・システムを対象とする。
少なくとも１回の運転走行に関するデータを受け取るように構成される少なくとも１つの入力であって、データは、（ｉ）第１の認識出力の時系列と、（ｉｉ）第２のグラウンド・トゥルース認識出力の時系列と、を含み、グラウンド・トゥルース認識出力の時系列および走行時認識出力の時系列は少なくとも１つの時間区間に関連する、少なくとも１つの入力と、
グラフィカル・ユーザ・インターフェース（ＧＵＩ）をレンダリングするためのレンダリング・データを生成するように構成されるレンダリング・コンポーネントであって、グラフィカル・ユーザ・インターフェースは、少なくとも１回の運転走行の複数の時間ステップのうちのそれぞれについて、その時間ステップで発生した認識エラーの視覚的指示を有する認識エラー・タイムラインを備える、レンダリング・コンポーネントと、
認識出力の時系列をグラウンド・トゥルース認識出力の時系列と比較することによって、認識エラー・タイムラインを生成するために１つまたは複数の時間区間で発生した認識エラーを識別するように構成される認識オラクルと、
を備える、コンピュータ・システムを対象とする。
【0063】
「認識出力」という用語は、このコンテキストでは広く使用されており、人間によるアノテーションならびに車両の認識スタックの出力から得られる認識データを含むことに留意されたい。
【0064】
コンピュータ・システムはさらに、グラウンド・トゥルーシング・パイプラインを備えてもよい。グラウンド・トゥルーシング・パイプラインは、少なくとも１つの非リアルタイムおよび／または非因果的認識アルゴリズムを少なくとも１回の運転走行のデータに適用して、そのデータを処理することによって、第１の認識出力の時系列を生成するように構成されてもよく、データは、運転走行からのセンサ・データの時系列と、認識システムによってセンサ・データの時系列から抽出された関連する走行時認識出力の時系列と、を含む。グラウンド・トゥルース認識出力は、少なくとも１回の運転走行の手動のアノテーションによって生成されてもよい。この実施形態において認識システムによって生成される認識出力は、「擬似」グラウンド・トゥルース認識出力であり、これは、同じ運転走行に関して受け取られた手動でアノテーション付けされたグラウンド・トゥルース認識出力と比較されて、擬似グラウンド・トゥルース認識出力における認識エラーが識別されてもよい。この比較は、評価対象の他の認識出力のセットとの比較のためのグラウンド・トゥルースとして使用される、グラウンド・トゥルーシング・パイプラインから得られた擬似グラウンド・トゥルース認識出力の適切性を評価する方法として使用されてもよい。この比較は、手動でアノテーション付けされた運転データのサブセットのみに基づいてもよく、これは、人間によるアノテーションが利用可能でないより大きなデータ・セットの認識出力を査定するために擬似ＧＴが使用されることを可能にする。
【0065】
代替的には、認識システムは、センサが装備された車両に配備するためのリアルタイム認識システムを備えてもよく、認識出力は、リアルタイム認識システムによって所与の運転走行に関するセンサ・データの時系列から抽出された走行時認識出力の時系列を含んでもよい。グラウンド・トゥルース認識出力は、グラウンド・トゥルーシング・パイプラインにより、少なくとも１つの非リアルタイムおよび／または非因果的認識アルゴリズムをセンサ・データの時系列または走行時認識出力の時系列のうちの少なくとも１つに適用して、その少なくとも１つを処理することによって、生成されてもよい。代替的には、グラウンド・トゥルース認識出力は、運転走行の手動のアノテーションによって生成されてもよい。
【0066】
運転走行は、現実世界での運転走行であってもよい。
【0067】
代替的には、運転走行は、シミュレートされた運転走行であってもよく、センサ・データはシミュレータによって生成され、走行時認識出力は、シミュレートされたセンサ・データにリアルタイム認識システムを適用することによって取得されてもよい。グラウンド・トゥルース認識出力は、走行時認識出力との比較のためにシミュレータから直接取得されてもよい。
【0068】
本明細書におけるさらなる態様は、リアルタイム認識システムをテストするためのコンピュータ実装方法であって、リアルタイム認識システムはセンサが装備された車両に配備するためのものであり、この方法は、
センサが装備された車両によって実行される少なくとも１回の現実世界での運転走行のデータを入力において受け取ることであって、データは、（ｉ）センサが装備された車両によってキャプチャされたセンサ・データの時系列と、（ｉｉ）テスト対象のリアルタイム認識システムによってセンサ・データの時系列から抽出された少なくとも１つの関連する走行時認識出力の時系列と、を備える、受け取ることと、
認識エラー・タイムラインを備えるグラフィカル・ユーザ・インターフェース（ＧＵＩ）をレンダリングするためのレンダリング・データをレンダリング・コンポーネントによって生成することであって、認識エラー・タイムラインは、少なくとも１回の現実世界での運転走行の複数の時間ステップのうちのそれぞれについて、時間ステップで発生した認識エラーの視覚的指示を有する、生成することと、
少なくとも１つのグラウンド・トゥルース認識出力の時系列を走行時認識出力との比較用に抽出するために、（ｉ）センサ・データの時系列、および（ｉｉ）走行時認識出力の時系列のうちの少なくとも１つに少なくとも１つの非リアルタイムおよび／または非因果的認識アルゴリズムを適用することによって、その少なくとも１つをグラウンド・トゥルーシング・パイプラインにおいて処理することと、
走行時認識出力の時系列をグラウンド・トゥルース認識出力の時系列と比較することによって、認識エラー・タイムラインを生成するために１つまたは複数の時間区間で発生した認識エラーを識別することと、
を備える、コンピュータ実装方法を提供する。
センサが装備された車両によって実行される少なくとも１回の現実世界での運転走行のデータを入力において受け取ることであって、データは、（ｉ）センサが装備された車両によってキャプチャされたセンサ・データの時系列と、（ｉｉ）テスト対象のリアルタイム認識システムによってセンサ・データの時系列から抽出された少なくとも１つの関連する走行時認識出力の時系列と、を備える、受け取ることと、
認識エラー・タイムラインを備えるグラフィカル・ユーザ・インターフェース（ＧＵＩ）をレンダリングするためのレンダリング・データをレンダリング・コンポーネントによって生成することであって、認識エラー・タイムラインは、少なくとも１回の現実世界での運転走行の複数の時間ステップのうちのそれぞれについて、時間ステップで発生した認識エラーの視覚的指示を有する、生成することと、
少なくとも１つのグラウンド・トゥルース認識出力の時系列を走行時認識出力との比較用に抽出するために、（ｉ）センサ・データの時系列、および（ｉｉ）走行時認識出力の時系列のうちの少なくとも１つに少なくとも１つの非リアルタイムおよび／または非因果的認識アルゴリズムを適用することによって、その少なくとも１つをグラウンド・トゥルーシング・パイプラインにおいて処理することと、
走行時認識出力の時系列をグラウンド・トゥルース認識出力の時系列と比較することによって、認識エラー・タイムラインを生成するために１つまたは複数の時間区間で発生した認識エラーを識別することと、
を備える、コンピュータ実装方法を提供する。
【0069】
さらなる態様は、本明細書に記載された任意の方法を実装するようにコンピュータ・システムをプログラミングするための実行可能なプログラム命令を提供する。
【0070】
本開示のよりよい理解のために、また、その実施形態がどのように実施されることができるかを示すために、単なる例として以下の図への参照がなされる。
【図面の簡単な説明】
【0071】
【図1】認識エラー仕様のユース・ケースのセットを示す図である。
【図2A】自律車両スタックの概略機能ブロック図である。
【図2B】自律車両のテスト・パラダイムの概略図である。
【図2C】シナリオ抽出パイプラインの概略ブロック図である。
【図3】手動でタグ付けされた運転走行をレビューするためのユーザ・インターフェースを示す図である。
【図4A】グラウンド・トゥルーシング・パイプラインの概要を示す図である。
【図4B】ノイズのあるバウンディング・ボックスのセットと、精製（ｒｅｆｉｎｅ）されたバウンディング・ボックスのセットとを示す図である。
【図5A】グラウンド・トゥルーシング・パイプラインで使用される検出結果精製技術のセットを示す図である。
【図5B】グラウンド・トゥルーシング・パイプラインで使用されるオフライン検出技術のセットを示す図である。
【図6A】テスト・パイプラインの概略ブロック図である。
【図6B】テスト・パイプラインの可能な実装のさらなる詳細を示す図である。
【図7A】テスト・オラクル内で評価されるルール・ツリーの例を示す図である。
【図7B】ルール・ツリーのノードの例示的な出力を示す図である。
【図8A】テスト・オラクル内で評価されるルール・ツリーの例を示す図である。
【図8B】シナリオ・グラウンド・トゥルース・データのセットで評価されたルール・ツリーの第２の例を示す図である。
【図8C】テスト・オラクル内でルールがどのように選択的に適用されることができるかを示す図である。
【図9A】グラフィカル・ユーザ・インターフェースをレンダリングするための視覚化コンポーネントの概略ブロック図である。
【図9B-9D】グラフィカル・ユーザ・インターフェース内で利用可能な様々なビューを示す図である。
【図10A】割り込みシナリオの第１のインスタンスを示す図である。
【図10B】第１のシナリオ・インスタンスの例示的なオラクル出力を示す図である。
【図10C】割り込みシナリオの第２のインスタンスを示す図である。
【図10D】第２のシナリオ・インスタンスの例示的なオラクル出力を示す図である。
【図11】認識エラーを評価するための例示的なアーキテクチャを示す図である。
【図12A】トリアージ・ツールの例示的なグラフィカル・ユーザ・インターフェースを示す図である。
【図12B】グラフィカル・ユーザ・インターフェースに表示されたセンサ・データを含む運転シナリオの概略表現である。
【図12C】ズーム機能およびタイムライン・スクラバーを有する例示的なユーザ・インターフェースを示す図である。
【図12D】ユーザ・インターフェースにおけるシナリオのサブセクションの選択を示す図である。
【図13】認識ルールを示すグラフィカル・ユーザ・インターフェースの焦点を絞ったビューである。
【図14】認識エラー・フレームワーク内の例示的なルール定義を示す図である。
【図15】認識エラーの数値スコアの例示的なグラフを定義されたエラー閾値と共に示す図である。
【図16】単一の認識エラー仕様が現実の運転シナリオおよびシミュレートされた運転シナリオにどのように適用されることができるかを示す図である。
【図17】定義された認識エラー仕様が認識スタックおよび計画スタックをテストする際にどのように使用されることができるかを示す図である。
【図18A-18B】シナリオの関連するエラーを識別するために適用されるフィルタリング・ツールを示す図である。
【図19A】グラフィカル・ユーザ・インターフェースを介してエラー閾値がどのように調整されることができるかを示す図である。
【図19B】運転シナリオの「スライス」の選択および分析を示す図である。
【発明を実施するための形態】
【0072】
図１１は、「認識オラクル」１１０８が複数のソース（現実のソースおよび／またはシミュレートされたソース）から認識エラー・データを受け取り、それらのデータを使用して「認識トリアージ」グラフィカル・ユーザ・インターフェース（ＧＵＩ）５００に入力する例示的なアーキテクチャを示している。
【0073】
テスト・オラクル２５２は運転パフォーマンスを査定し、ＧＵＩ５００の特定の実装は、それぞれのタイムライン上の認識情報と合わせた運転パフォーマンス査定を可能にする。
【0074】
特定の認識エラーは、現実の走行またはシミュレートされた走行のグラウンド・トゥルース軌跡から導出されてもよく、それらの同じグラウンド・トゥルース軌跡が、運転パフォーマンスを査定するためにテスト・オラクルによって使用される。
【0075】
テスト・オラクル２５２および認識オラクル１１０８は、それぞれが設定可能なルール・ベースのロジックを適用してＧＵＩ５００上のタイムラインに入力する限りにおいて、互いを鏡に映す。前者は階層型のルール・ツリーを（擬似）グラウンド・トゥルース軌跡に適用して走行（または複数回の走行）にわたる運転パフォーマンスを査定し、後者は同様のロジックを適用して顕著な認識エラーを識別する。レンダリング・コンポーネント１１２０は、ディスプレイ上にＧＵＩをレンダリングするためのレンダリング・データを生成する。
【0076】
引用により本明細書に組み込まれている我々の同時係属中の国際特許出願ＰＣＴ／ＥＰ２０２２／０５３４０６およびＰＣＴ／ＥＰ２０２２／０５３４１３は、テスト・オラクルにおけるルールをコード化するためのドメイン固有言語（ＤＳＬ）について記載している。認識オラクルにおいて顕著な認識エラーを識別するためのルールをコード化するためのＤＳＬの拡張が以下で説明される。
【0077】
説明される実施形態は、現実のシナリオまたはシミュレートされたシナリオにおける移動ロボット・スタックのルール・ベースのテストを容易にするためのテスト・パイプラインを提供し、これは認識エラーの存在を柔軟な方法で識別および伝達するための追加機能を組み込んでいる。
【0078】
典型的には、「フル」スタックは、下位レベルのセンサ・データの処理および解釈（認識）から、予測および計画などの主要な上位レベルの機能への入力、ならびに（たとえば、ブレーキ、ステアリング、加速などを制御するための）計画レベルの決定を実施するための適切な制御信号を生成するための制御ロジックまで、全てを含む。自律車両の場合、レベル３のスタックは移行要求を実装するためのロジックを含み、レベル４のスタックはミニマム・リスク・マヌーバを実装するためのロジックを追加的に含む。スタックは、たとえば、合図、ヘッドライト、ウィンドスクリーン・ワイパーなどの二次的な制御機能も実装してもよい。
【0079】
「スタック」という用語は、個別にまたは任意の所望の組み合わせでテストされてもよい、認識、予測、計画、または制御スタックなどの、フル・スタックの個々のサブ・システム（サブ・スタック）を指す場合もある。スタックは、純粋にソフトウェア、すなわち、１つまたは複数の汎用コンピュータ・プロセッサ上で実行されることができる１つまたは複数のコンピュータ・プログラムを指す場合がある。
【0080】
以下で説明されるテスト・フレームワークは、現実世界データからシナリオ・グラウンド・トゥルースを生成するためのパイプラインを提供する。このグラウンド・トゥルースは、生成されたグラウンド・トゥルースをテスト中の認識スタックの認識出力と比較すること、ならびに運転挙動を運転ルールに照らして査定することにより、認識テストの基礎として使用されてもよい。
【0081】
現実のシナリオまたはシミュレートされたシナリオにおけるエージェント（アクター）の挙動は、テスト・オラクルによって、定義されたパフォーマンス評価ルールに基づいて評価される。そのようなルールは、安全性の様々な側面を評価してもよい。たとえば、スタックのパフォーマンスを特定の安全基準、規制、または安全性モデル（ＲＳＳなど）に照らして査定するための安全性ルール・セットが定義されてもよく、またはパフォーマンスの任意の側面をテストするためのオーダー・メイドのルール・セットが定義されてもよい。テスト・パイプラインはその用途が安全性に限定されず、快適性または定められたゴールに向けた進捗状況など、パフォーマンスの任意の側面をテストするために使用されることができる。ルール・エディタは、パフォーマンス評価ルールが定義または変更され、テスト・オラクルに渡されることを可能にする。
【0082】
同様に、車両の認識は「認識オラクル」によって、定義された認識ルールに基づいて評価されることができる。これらは、認識のエラーを定義するための標準形式を提供する認識エラー仕様内で定義されてもよい。
【0083】
図１は、認識エラー・フレームワークの考えられるユース・ケースのセットを示している。認識エラー・フレームワークでルールを定義することは、現実世界の運転シナリオにおける関心のあるエリアがユーザに強調表示されること（１６０２）を、たとえば、ユーザ・インターフェースに提示されるシナリオのリプレイでこれらのエリアにフラグを立てることによって可能にする。これは、ユーザが認識スタック内の明らかなエラーをレビューし、エラーの考えられる理由、たとえば、元のセンサ・データにおけるオクルージョンなどを特定することを可能にする。このような認識エラーの評価は、ＡＶスタックの認識コンポーネントと計画コンポーネントとの間で「契約」が定義されることも可能にし（１６０４）、認識パフォーマンスの要件が指定されることができ、これらの認識パフォーマンスの要件を満たすスタックは、安全に計画が立てられることを約束する。現実世界の運転シナリオからの現実の認識エラーを評価するとともに、認識エラー・モデルを使用して直接シミュレートされるか、または、たとえばカメラ画像の写実的なシミュレーションなど、シミュレートされたセンサ・データに認識スタックを適用することによって計算される、シミュレートされたエラーを評価するために、統合されたフレームワークが使用されてもよい（１６０６）。
【0084】
パイプラインによって決定されたグラウンド・トゥルース自体が、定義されたルールに従って、シナリオを手動でレビューしてアノテーション付けすることによって決定された「真の」グラウンド・トゥルースと比較することによって、同じ認識エラー仕様内で評価されることができる（１６０８）。最後に、認識エラー・テスト・フレームワークを適用した結果は、スタックの認識サブシステムと予測サブシステムとの両方をテストするためのテスト戦略をガイドするために使用されることができる（１６１０）。
【0085】
シナリオは、現実のものであろうとシミュレートされたものであろうと、自エージェントが現実のまたはモデル化された物理的コンテキスト内を進んでいくことを必要とする。自エージェントは、テスト対象のスタックの制御下で移動する現実のまたはシミュレートされた移動ロボットである。物理的コンテキストは、テスト対象のスタックが効果的に対応することが求められる静的要素および／または動的要素を含む。たとえば、移動ロボットは、スタックの制御下にある完全または半自律車両（自車両）であってもよい。物理的コンテキストは、静的な道路レイアウトと、シナリオが進行するにつれて維持または変更されることができる所与の環境条件のセット（たとえば、天候、時刻、照明条件、湿度、汚染／粒子レベルなど）とを含んでもよい。相互作用的なシナリオは、１つまたは複数の他のエージェント（「外部」エージェント、たとえば、他の車両、歩行者、自転車に乗っている人、動物など）を追加的に含む。
【0086】
以下の例は、自律車両のテストへの適用を考える。しかしながら、本原理は他の形態の移動ロボットにも同様に当てはまる。
【0087】
シナリオは、様々な抽象化レベルで表現または定義されてもよい。より抽象化されたシナリオは、より大きい度合いの変形に適応する。たとえば、「割り込みシナリオ」または「車線変更シナリオ」は、多くの変形（たとえば、様々なエージェントの開始位置およびスピード、道路レイアウト、環境条件など）に適応する、関心のある操作または挙動によって特徴付けられる、高度に抽象化されたシナリオの例である。「シナリオ走行」は、任意選択により１つまたは複数の他のエージェントの存在下で、エージェントが物理的コンテキスト内を進んでいく具体的な出来事を指す。たとえば、異なるエージェント・パラメータ（たとえば、開始位置、スピードなど）、異なる道路レイアウト、異なる環境条件、および／または異なるスタック構成などでの、割り込みまたは車線変更シナリオの複数回の走行が（現実世界および／またはシミュレータで）行われることができる。「走行」および「インスタンス」という用語は、このコンテキストでは同じ意味で使用される。
【0088】
以下の例では、１回または複数回の走行にわたって、テスト・オラクル内での自エージェントの挙動を所与のパフォーマンス評価ルールのセットに照らして評価することによって、スタックのパフォーマンスが少なくとも部分的に査定される。ルールはシナリオ走行（または各シナリオ走行）の「グラウンド・トゥルース」に適用され、これは一般に、テストの目的で信頼できるものとみなされる、（自エージェントの挙動を含む）シナリオ走行の適切な表現を単に意味する。グラウンド・トゥルースはシミュレーションに固有のものであり、シミュレータはシナリオ状態のシーケンスを計算し、これは定義上、シミュレートされたシナリオ走行の完璧な信頼できる表現である。現実世界でのシナリオ走行では、同じ意味でのシナリオ走行の「完璧な」表現は存在しないが、それにもかかわらず、適切に情報を提供するグラウンド・トゥルースは、たとえば、車載センサ・データの手動のアノテーション、そのようなデータの自動化／半自動化されたアノテーション（たとえば、オフライン／非リアルタイム処理を使用）、および／または外部情報源（たとえば、外部センサ、地図など）の使用などに基づいて、多数の方法で取得されることができる。
【0089】
シナリオ・グラウンド・トゥルースは、典型的には、自エージェントおよび該当する場合は他の任意の（顕著な）エージェントの「軌跡」を含む。軌跡は、シナリオにわたるエージェントの位置および運動の履歴である。軌跡が表現されることができる多くの方法がある。軌跡データは、典型的には、環境内のエージェントの空間および運動データを含む。この用語は、現実のシナリオ（現実世界での軌跡を有する）と、シミュレートされたシナリオ（シミュレートされた軌跡を有する）との両方に関連して使用される。軌跡は、典型的には、シナリオ内でエージェントによって実現された実際の軌道を記録したものである。用語に関して言えば、「軌跡」および「軌道」は、同一または類似のタイプの情報（たとえば、時間経過に伴う空間および運動状態の系列など）を含む場合がある。軌道という用語は、一般に計画のコンテキストでよく用いられ（将来の／予測される軌道を指す場合がある）、軌跡という用語は、一般にテスト／評価のコンテキストで過去の挙動との関連でよく用いられる。
【0090】
シミュレーション・コンテキストでは、「シナリオ記述」がシミュレータに入力として提供される。たとえば、シナリオ記述は、シナリオ記述言語（ＳＤＬ：ｓｃｅｎａｒｉｏ ｄｅｓｃｒｉｐｔｉｏｎ ｌａｎｇｕａｇｅ）を使用して、またはシミュレータによって使用されることができる他の任意の形式で、コード化されてもよい。シナリオ記述は、典型的には、シナリオのより抽象的な表現であり、複数回のシミュレートされた走行を生じさせることができる。実装によっては、シナリオ記述は、可能な変形の度合いを高めるために変更されることができる１つまたは複数の設定可能なパラメータを有してもよい。抽象化およびパラメータ化の度合いは設計上の選択である。たとえば、シナリオ記述は、パラメータ化された環境条件（たとえば、天候、照明など）を使用して、固定レイアウトをコード化してもよい。しかしながら、たとえば、設定可能な道路パラメータ（たとえば、道路の曲率、車線の構成など）を使用して、さらなる抽象化が可能である。シミュレータへの入力は、シナリオ記述を選ばれたパラメータ値のセット（該当する場合）と共に含む。後者は、シナリオのパラメータ化と呼ばれる場合がある。設定可能なパラメータはパラメータ空間（シナリオ空間とも呼ばれる）を定義し、パラメータ化はパラメータ空間内の点に対応する。このコンテキストでは、「シナリオ・インスタンス」は、シナリオ記述および（該当する場合）選ばれたパラメータ化に基づいた、シミュレータにおけるシナリオのインスタンス化を指す場合がある。
【0091】
簡潔にするために、「シナリオ」という用語は、より抽象化された意味でのシナリオだけでなく、シナリオ走行を指すために使用される場合もある。シナリオという用語の意味は、それが使用される文脈から明らかであろう。
【0092】
軌道計画は、本発明のコンテキストにおける重要な機能であり、「軌道プランナ」、「軌道計画システム」、および「軌道計画スタック」という用語は、将来に向けて移動ロボットの軌道を計画することができる１つまたは複数のコンポーネントを指すために、本明細書では同じ意味で使用される場合がある。軌道計画の決定は、自エージェントによって実現される実際の軌道を最終的に決定する（しかしながら、一部のテスト・コンテキストでは、これは、たとえば、制御スタックにおけるそれらの決定の実装、およびその結果得られる制御信号に対する自エージェントの現実のまたはモデル化された動的応答などの他の要因によって影響される場合がある）。
【0093】
軌道プランナは、単独で、あるいは１つまたは複数の他のシステム（たとえば、認識、予測、および／または制御）と組み合わせてテストされてもよい。フル・スタック内では、計画は一般に、上位レベルの自律的な意思決定能力（たとえば、軌道計画）を指すが、制御は一般に、それらの自律的な決定を実施するための制御信号の下位レベルの生成を指す。しかしながら、パフォーマンス・テストのコンテキストでは、制御という用語はより広い意味でも使用される。誤解を避けるために、軌道プランナがシミュレーションにおいて自エージェントを制御すると述べられている場合、それは必ずしも（より狭い意味での）制御システムが軌道プランナと組み合わせてテストされることを示唆するわけではない。
【0094】
例示的なＡＶスタック：
説明される実施形態に関連するコンテキストを提供するために、ＡＶスタックの例示的な形態のさらなる詳細がここで説明される。
説明される実施形態に関連するコンテキストを提供するために、ＡＶスタックの例示的な形態のさらなる詳細がここで説明される。
【0095】
図２Ａは、ＡＶ走行時スタック１００の非常に概略的なブロック図を示している。走行時スタック１００は、認識（サブ）システム１０２、予測（サブ）システム１０４、計画（サブ）システム（プランナ）１０６、および制御（サブ）システム（コントローラ）１０８を備えるように示されている。上記のように、（サブ）スタックという用語が、前述のコンポーネント１０２～１０８を説明するために使用される場合もある。
【0096】
現実世界のコンテキストでは、認識システム１０２は、ＡＶの車載センサ・システム１１０からセンサ出力を受け取り、それらのセンサ出力を使用して外部エージェントを検出し、それらの物理的状態、たとえば、それらの位置、速度、加速度などを測定する。車載センサ・システム１１０は、様々な形態をとることができるが、一般に、画像キャプチャ・デバイス（カメラ／光学センサ）、ライダーおよび／またはレーダー・ユニット、衛星測位センサ（ＧＰＳなど）、モーション／慣性センサ（加速度計、ジャイロスコープなど）などの種々のセンサを備える。したがって、車載センサ・システム１１０は豊富なセンサ・データを提供し、そこから、周囲の環境、ならびにその環境内のＡＶおよび任意の外部アクター（車両、歩行者、自転車に乗っている人など）の状態に関する詳細な情報を抽出することが可能である。典型的には、センサ出力は、１つまたは複数のステレオ光学センサ、ライダー、レーダーなどからのステレオ画像など、複数のセンサ・モダリティのセンサ・データを含む。複数のセンサ・モダリティのセンサ・データは、フィルタ、融合コンポーネントなどを使用して組み合わせられてもよい。
【0097】
認識システム１０２は、典型的には、協働してセンサ出力を解釈することによって認識出力を予測システム１０４に提供する複数の認識コンポーネントを備える。
【0098】
シミュレーション・コンテキストでは、テストの性質に応じて、特に、スタック１００がテストのためにどこで「スライス」されるかに応じて（下記参照）、車載センサ・システム１００をモデル化する必要がある場合とそうでない場合とがある。上位レベルのスライシングでは、シミュレートされたセンサ・データは必要ないので、複雑なセンサ・モデリングは必要ない。
【0099】
認識システム１０２からの認識出力は、予測システム１０４によって、ＡＶの近傍の他の車両などの外部アクター（エージェント）の将来の挙動を予測するために使用される。
【0100】
予測システム１０４によって計算された予測はプランナ１０６に提供され、プランナ１０６は予測を使用して、所与の運転シナリオでＡＶによって実行される自律運転の決定を下す。プランナ１０６によって受け取られる入力は、典型的には走行可能エリアを示し、また、走行可能エリア内の外部エージェント（ＡＶの観点からは障害物）の予測される動きもキャプチャする。走行可能エリアは、認識システム１０２からの認識出力をＨＤ（高解像度）地図などの地図情報と組み合わせて使用して、決定されることができる。
【0101】
プランナ１０６の中核機能は、予測されるエージェントの動きを考慮して、ＡＶの軌道（自己軌道）を計画することである。これは軌道計画と呼ばれる場合がある。軌道は、シナリオ内の所望のゴールを遂行するために計画される。ゴールは、たとえば、環状交差点に入って所望の出口で出ること、前の車両を追い越すこと、または目標スピードで現在の車線に留まること（車線追従）とすることができる。ゴールは、たとえば、自律ルート・プランナ（図示せず）によって決定されてもよい。
【0102】
コントローラ１０８は、ＡＶの車載アクター・システム１１２に適切な制御信号を提供することによって、プランナ１０６によって行われた決定を実行する。具体的には、プランナ１０６はＡＶの軌道を計画し、コントローラ１０８は計画された軌道を実施するための制御信号を生成する。典型的には、プランナ１０６は将来に向けて計画を立てて、計画された軌道が部分的にのみ制御レベルで実施されることができるようにし、その後、プランナ１０６によって新しい軌道が計画される。アクター・システム１１２は、ブレーキ、加速、およびステアリング・システムなどの「主要な」車両システム、ならびに二次的なシステム（たとえば、合図、ワイパー、ヘッドライトなど）を含む。
【0103】
なお、所与の瞬間での計画された軌道と、自エージェントによって辿られる実際の軌道との間には違いがあってもよい。計画システムは、典型的には計画ステップのシーケンスにわたって動作し、各計画ステップで計画された軌道を、前の計画ステップ以降のシナリオの変化（または、より正確には、予測された変化から逸脱した変化）を考慮するように更新する。計画システム１０６は、各計画ステップでの計画された軌道が次の計画ステップを逸脱するように、将来に向けて推論してもよい。したがって、個々の計画された軌道は完全には実現されない場合がある（計画システム１０６がシミュレーションにおいて単独でテストされる場合、自エージェントは次の計画ステップまで計画された軌道を正確に辿るだけである場合があるが、上記のように、他の現実のコンテキストおよびシミュレーション・コンテキストでは、計画された軌道は次の計画ステップまで正確に辿られない場合があり、その理由は、自エージェントの挙動が、制御システム１０８の動作および自車両の現実のまたはモデル化されたダイナミクスなどの他の要因によって影響される場合があるためである）。多くのテスト・コンテキストでは、最終的に重要なのは、自エージェントの実際の軌道であり、具体的には、実際の軌道が安全か否か、ならびに快適性および進捗状況などの他の要因である。しかしながら、本明細書でのルール・ベースのテスト・アプローチは、計画された軌道に適用されることもできる（それらの計画された軌道が自エージェントによって完全にまたは正確に実現されない場合でも）。たとえば、エージェントの実際の軌道が所与の安全性ルールに従って安全であるとみなされたとしても、瞬間的な計画された軌道は安全ではなかった場合があり、プランナ１０６が安全でない行動方針を検討していたという事実が、たとえそれがシナリオ内で安全でないエージェントの挙動につながらなかったとしても、明らかになる場合がある。瞬間的な計画された軌道は、シミュレーションにおける実際のエージェントの挙動に加えて、有用に評価されることができる内部状態の１つの形態を構成する。他の形態の内部スタック状態も同様に評価されることができる。
【0104】
図２Ａの例は、分離可能な認識、予測、計画および制御システム１０２～１０８を有する比較的「モジュール式」のアーキテクチャを考えている。サブ・スタック自体も、たとえば、計画システム１０６内に分離可能な計画モジュールを有するモジュール式であってもよい。たとえば、計画システム１０６は、異なる物理的コンテキスト（たとえば、単純な車線走行対複雑な交差点または環状交差点）に適用されることができる複数の軌道計画モジュールを備えてもよい。これは、コンポーネント（たとえば、計画システム１０６またはその個々の計画モジュールなど）が個別にまたは異なる組み合わせでテストされることを可能にするので、上記の理由によりシミュレーション・テストに関連する。誤解を避けるために、モジュール式のスタック・アーキテクチャでは、スタックという用語はフル・スタックだけでなく、その個々のサブ・システムまたはモジュールを指す場合もある。
【0105】
様々なスタック機能が統合されるまたは分離可能である程度は、異なるスタック実装間で大幅に異なる場合があり、一部のスタックでは、特定の側面が区別できないほど密接に結合されている場合がある。たとえば、他のスタックでは、計画および制御が統合されてもよく（たとえば、そのようなスタックは制御信号の観点で直接計画を行うことができる）、一方、他のスタック（たとえば、図２Ａに示されるもの）は、これら２つの間に明確な区別をつける方法で設計されてもよい（たとえば、軌道の観点で計画を行い、制御信号レベルで計画された軌道を実行する最良の方法を決定するために独立した制御の最適化を行う）。同様に、一部のスタックでは、予測および計画がより密接に結合されてもよい。極端な場合、いわゆる「エンド・ツー・エンド」の運転では、認識、予測、計画、および制御が本質的に分離不可能である場合がある。特に明記されない限り、本明細書で使用される認識、予測、計画、および制御という用語は、これらの側面の特定の結合またはモジュール化を示唆するものではない。
【0106】
「スタック」という用語はソフトウェアを包含するが、ハードウェアも包含できることは理解されよう。シミュレーションでは、スタックのソフトウェアは、最終的に物理的な車両の車載コンピュータ・システムにアップロードされる前に、「汎用の」非車載コンピュータ・システム上でテストされてもよい。しかしながら、「ハードウェア・イン・ザ・ループ」テストでは、テストが車両自体の基盤となるハードウェアにまで及んでもよい。たとえば、スタック・ソフトウェアは、テストの目的でシミュレータに結合された車載コンピュータ・システム（またはそのレプリカ）上で実行されてもよい。このコンテキストでは、テスト対象のスタックは、車両の基盤となるコンピュータ・ハードウェアにまで及ぶ。他の例として、スタック１００の特定の機能（たとえば、認識機能）は、専用のハードウェアで実装されてもよい。シミュレーション・コンテキストでは、ハードウェア・イン・ザ・ループ・テストは、合成センサ・データを専用ハードウェアの認識コンポーネントに供給することを含むことができる。
【0107】
例示的なテスト・パラダイム：
図２Ｂは、自律車両のテスト・パラダイムの非常に概略的な概要を示している。たとえば図２Ａに示される種類のＡＤＳ／ＡＤＡＳスタック１００は、シミュレータ２０２で複数のシナリオ・インスタンスを走行し、テスト・オラクル２５２でスタック１００（および／またはその個々のサブ・スタック）のパフォーマンスを評価することによって、シミュレーションで繰り返しのテストおよび評価を受ける。テスト・オラクル２５２の出力はエキスパート１２２（チームまたは個人）にとって有益であり、エキスパート１２２がスタック１００内の課題を特定し、それらの課題を軽減するようにスタック１００を修正することを可能にする（Ｓ１２４）。この結果はまた、エキスパート１２２がテスト用のさらなるシナリオを選択する際に役立ち（Ｓ１２６）、プロセスは継続して、シミュレーションでスタック１００を繰り返し修正し、テストし、そのパフォーマンスを評価する。改善されたスタック１００は最終的に、センサ・システム１１０およびアクター・システム１１２が装備された現実世界のＡＶ１０１に組み込まれる（Ｓ１２５）。改善されたスタック１００は、典型的には、車両１０１の車載コンピュータ・システム（図示せず）の１つまたは複数のコンピュータ・プロセッサで実行されるプログラム命令（ソフトウェア）を含む。改善されたスタックのソフトウェアは、ステップＳ１２５においてＡＶ１０１にアップロードされる。ステップＳ１２５は、基盤となる車両ハードウェアへの変更も含んでもよい。改善されたスタック１００は、ＡＶ１０１に搭載されると、センサ・システム１１０からセンサ・データを受け取り、アクター・システム１１２に制御信号を出力する。現実世界でのテスト（Ｓ１２８）は、シミュレーション・ベースのテストと組み合わせて使用されることができる。たとえば、シミュレーション・テストおよびスタック改良のプロセスを通じて許容可能なレベルのパフォーマンスに到達すると、適切な現実世界のシナリオが選択されてもよく（Ｓ１３０）、それらの現実のシナリオにおけるＡＶ１０１のパフォーマンスがキャプチャされ、テスト・オラクル２５２で同様に評価されてもよい。
図２Ｂは、自律車両のテスト・パラダイムの非常に概略的な概要を示している。たとえば図２Ａに示される種類のＡＤＳ／ＡＤＡＳスタック１００は、シミュレータ２０２で複数のシナリオ・インスタンスを走行し、テスト・オラクル２５２でスタック１００（および／またはその個々のサブ・スタック）のパフォーマンスを評価することによって、シミュレーションで繰り返しのテストおよび評価を受ける。テスト・オラクル２５２の出力はエキスパート１２２（チームまたは個人）にとって有益であり、エキスパート１２２がスタック１００内の課題を特定し、それらの課題を軽減するようにスタック１００を修正することを可能にする（Ｓ１２４）。この結果はまた、エキスパート１２２がテスト用のさらなるシナリオを選択する際に役立ち（Ｓ１２６）、プロセスは継続して、シミュレーションでスタック１００を繰り返し修正し、テストし、そのパフォーマンスを評価する。改善されたスタック１００は最終的に、センサ・システム１１０およびアクター・システム１１２が装備された現実世界のＡＶ１０１に組み込まれる（Ｓ１２５）。改善されたスタック１００は、典型的には、車両１０１の車載コンピュータ・システム（図示せず）の１つまたは複数のコンピュータ・プロセッサで実行されるプログラム命令（ソフトウェア）を含む。改善されたスタックのソフトウェアは、ステップＳ１２５においてＡＶ１０１にアップロードされる。ステップＳ１２５は、基盤となる車両ハードウェアへの変更も含んでもよい。改善されたスタック１００は、ＡＶ１０１に搭載されると、センサ・システム１１０からセンサ・データを受け取り、アクター・システム１１２に制御信号を出力する。現実世界でのテスト（Ｓ１２８）は、シミュレーション・ベースのテストと組み合わせて使用されることができる。たとえば、シミュレーション・テストおよびスタック改良のプロセスを通じて許容可能なレベルのパフォーマンスに到達すると、適切な現実世界のシナリオが選択されてもよく（Ｓ１３０）、それらの現実のシナリオにおけるＡＶ１０１のパフォーマンスがキャプチャされ、テスト・オラクル２５２で同様に評価されてもよい。
【0108】
シナリオはシミュレーションの目的で、手動のコーディングを含む様々な方法で取得されることができる。このシステムは、シミュレーションの目的で現実世界での走行からシナリオを抽出することも可能であり、現実世界のシチュエーションおよびその変形がシミュレータ２０２内で再作成されることを可能にする。
【0109】
図２Ｃは、シナリオ抽出パイプラインの非常に概略的なブロック図を示している。現実世界での走行のデータ１４０は、シナリオ・グラウンド・トゥルースを生成する目的で「グラウンド・トゥルーシング」パイプライン１４２に渡される。走行データ１４０は、たとえば、１つまたは複数の車両（これは、自律型、人間による運転、またはそれらの組み合わせとすることができる）上でキャプチャ／生成されたセンサ・データおよび／または認識出力、ならびに／あるいは外部センサ（たとえば、ＣＣＴＶ）などの他のソースからキャプチャされたデータを含むことができる。走行データは、現実世界での走行に関する適切なグラウンド・トゥルース１４４（軌跡およびコンテキスト・データ）を生成するために、グラウンド・トゥルーシング・パイプライン１４２内で処理される。論じられたように、グラウンド・トゥルーシング・プロセスは、「生の」走行データ１４０の手動のアノテーションに基づくことができ、またはプロセスは完全に自動化されることができ（たとえば、オフラインの認識方法を使用）、あるいは手動のおよび自動化されたグラウンド・トゥルーシングの組み合わせが使用されることができる。たとえば、走行データ１４０にキャプチャされた車両および／または他のエージェントの周囲に３Ｄバウンディング・ボックスを配置して、それらの軌跡の空間および運動状態を決定してもよい。シナリオ抽出コンポーネント１４６は、シナリオ・グラウンド・トゥルース１４４を受け取り、シナリオ・グラウンド・トゥルース１４４を処理して、シミュレーションの目的で使用されることができるより抽象化されたシナリオ記述１４８を抽出する。シナリオ記述１４８はシミュレータ２０２によって使用され、複数回のシミュレートされた走行が行われることを可能にする。シミュレートされた走行は、元の現実世界での走行の変形であり、可能な変形の度合いは抽象化の程度によって決まる。グラウンド・トゥルース１５０は、シミュレートされた走行ごとに提供される。
【0110】
現実のシナリオ・グラウンド・トゥルース１４４およびシミュレートされたグラウンド・トゥルース１５０は、認識スタックを評価するために認識トリアージ・ツール１５２によって処理されてもよく、ならびに／あるいはグラウンド・トゥルース１４４またはシミュレートされたグラウンド・トゥルース１５０に基づいてスタックを査定するためにテスト・オラクル２５２によって処理されてもよい。
【0111】
現在の非車載のコンテキストでは、軌跡がリアルタイムに抽出される必要はなく（または、より正確には、リアルタイムの計画作成をサポートするように軌跡が抽出される必要はなく）、むしろ、軌跡は「オフライン」で抽出される。オフライン認識アルゴリズムの例は、非リアルタイムおよび非因果的認識アルゴリズムを含む。オフライン技術は、リアルタイムの計画作成／意思決定を容易にするためにＡＶスタック１００内に実行可能に実装されることができる「オンライン」技術とは対照的である。
【0112】
たとえば、ＡＶの車載コンピュータ・システムのハードウェアまたは他の実際的な制約によりオンラインでは実行されることができない非リアルタイム処理を使用することが可能である。軌跡を抽出するために、たとえば、１つまたは複数の非リアルタイム認識アルゴリズムが現実世界走行データ１４０に適用されることができる。非リアルタイム認識アルゴリズムは、必要とする計算リソースまたはメモリ・リソースが原因でリアルタイムに動作することが不可能と思われるアルゴリズムとすることができる。
【0113】
このコンテキストでは、「非因果的」認識アルゴリズムを使用することも可能である。非因果的アルゴリズムは、実行時にリアルタイムに動作することが可能である場合とそうでない場合とがあるが、いずれにせよ、未来の知識を必要とするので、オンライン・コンテキストでは実装されることができない。たとえば、特定の瞬間でのエージェントの状態（たとえば、位置、姿勢、スピードなど）をその後のデータに基づいて検出する認識アルゴリズムは、未来の知識を必要とするので（ただし、短い先読みウィンドウで動作するように制約されている場合を除く）、オンライン・コンテキストではスタック１００内でのリアルタイムの計画作成をサポートすることができない。たとえば、後方パスを用いたフィルタリングは、リアルタイムに動作させることができる場合もあるが、未来の知識を必要とする非因果的なアルゴリズムである。
【0114】
「認識」という用語は一般に、現実世界データ１４０内の構造を認識するための技術、たとえば、２Ｄまたは３Ｄバウンディング・ボックス検出、位置検出、姿勢検出、運動検出などを指す。たとえば、軌跡は、（たとえば、鳥瞰図の基準フレームにおける）３Ｄ空間または２Ｄ空間内のバウンディング・ボックスまたは他の空間状態の時系列として、関連する運動情報（たとえば、スピード、加速度、ジャークなど）と共に抽出されてもよい。
【0115】
グラウンド・トゥルース・パイプライン
自律車両スタックの現実世界でのパフォーマンスをテストするときの問題は、自律車両が膨大な量のデータを生成することである。このデータは、現実世界でのＡＶのパフォーマンスを分析または評価するために後で使用されることができる。しかしながら、潜在的な課題は、この映像内で関連するデータを探し、運転中に発生した関心のあるイベントを特定することである。１つの選択肢は、データを手動で解析し、人間によるアノテーションによって関心のあるイベントを特定することである。しかしながら、これはコストがかかる場合がある。
自律車両スタックの現実世界でのパフォーマンスをテストするときの問題は、自律車両が膨大な量のデータを生成することである。このデータは、現実世界でのＡＶのパフォーマンスを分析または評価するために後で使用されることができる。しかしながら、潜在的な課題は、この映像内で関連するデータを探し、運転中に発生した関心のあるイベントを特定することである。１つの選択肢は、データを手動で解析し、人間によるアノテーションによって関心のあるイベントを特定することである。しかしながら、これはコストがかかる場合がある。
【0116】
図３は、運転中に現実世界運転データに手動でタグ付けする例を示している。ＡＶは、たとえばカメラなどのセンサが装備されている。例示的な画像１２０２に示されるように、カメラにより運転に沿って映像が収集される。人間のドライバーによる高速道路での例示的な運転では、ドライバーが何か関心のあるものに気付いた場合、ドライバーはＡＶにフラグを提供し、センサによって収集されたデータ内のそのフレームにタグ付けすることができる。画像は地図１２００上での運転の視覚化を示しており、バブルはドライバーが何かにタグ付けした、運転に沿った点を示している。この例では、タグ付けされた各点はカメラ画像のフレームに対応しており、これは、タグ付けされたフレームのみが後で検査されるように、運転後に分析されるデータをフィルタリングするために使用される。
【0117】
地図１２００に示されるように、運転経路においてタグ付けされたフレーム間には大きなギャップがあり、これらのギャップにおいて収集されたデータはいずれもタグ付けされていないので、このデータは使用されない。自車両のドライバーによる手動のアノテーションを使用してデータをフィルタリングすることにより、その後の運転データの分析は、人間のドライバーまたはテスト・エンジニアがフラグを立てるほど十分に重要であると感じたイベント、またはフラグを立てるのに十分な時間があったイベントのみに限定される。しかしながら、残りのデータの他の時点に車両のパフォーマンスに関する有用な洞察が存在する場合があり、運転パフォーマンスをより完全に処理および評価するための自動的な方法を決定することは有用であろう。さらに、同じ量のデータに対して手動でタグ付けするよりも多くの課題を特定することは、同じ量の収集データに対してＡＶシステムにより多くの改善を行う機会を提供する。
【0118】
考えられる解決策は、同じメトリックを使用してシナリオ・シミュレーションと現実世界の運転との両方を査定する統合された分析パイプラインを作成することである。最初のステップは、実際に収集されたデータから運転軌跡を抽出することである。たとえば、自車両の概略位置および他のエージェントの概略位置が、車上検出結果に基づいて推定されることができる。しかしながら、車上検出結果は完璧ではなく、その理由は、コンピューティング・リソースが限られていること、および車上検出結果がリアルタイムに機能すること、すなわち、所与の検出結果を知らせるデータが、センサがその時点までに観測したもののみであることである。これは、検出結果がノイズを含み、不正確である場合があることを意味する。
【0119】
図４Ａは、所与の現実世界データのセットに対する擬似グラウンド・トゥルース１４４を決定するために、データ取り込みパイプライン内でデータがどのように処理および精製されるかを示している。「真の」グラウンド・トゥルースは現実世界データから抽出されることができず、本明細書に記載されたグラウンド・トゥルース・パイプラインは、評価に十分なグラウンド・トゥルースの推定値を提供することに留意されたい。この擬似グラウンド・トゥルース１４４は、本明細書では単に「グラウンド・トゥルース」と呼ばれる場合もある。
【0120】
データ取り込みパイプライン（または「取り込み」ツール）は、所与のスタックから、および任意選択により手動のアノテーションなどの他の任意のデータ・ソース１３００から認識データ１４０を取り入れ、データを精製して、データにキャプチャされた現実世界の運転シナリオの擬似グラウンド・トゥルース１４４を抽出する。図に示されるように、車両からのセンサ・データおよび検出結果が取り込まれ、任意選択によりオフライン検出結果または手動のアノテーションなどの追加の入力と共に取り込まれる。これらは、生のセンサ・データにオフライン検出器１３０２を適用するために、および／または車両の車載認識スタックから受け取られた検出結果の精製１３０４を行うために処理される。次いで、精製された検出結果は、シナリオの擬似グラウンド・トゥルース１４４として出力される。次いで、これは、テスト・オラクルによりグラウンド・トゥルースを運転ルールに照らして評価すること（後述）、車両検出結果を擬似グラウンド・トゥルースと比較して認識エラーを決定すること、シミュレーション用のシナリオを抽出することを含む、様々なユース・ケースの基礎として使用されてもよい。入力データに対して他のメトリックが計算されてもよく、これは認識「困難性」スコア１３０６を含み、認識「困難性」スコア１３０６は、たとえば、検出結果またはカメラ画像全体に適用されることができ、認識スタックが所与のデータを正しく扱うことの難しさを示す。
【0121】
図４Ｂは、精製前後のバウンディング・ボックスのセットの例を示している。図４Ｂの例では、上の画像は、各時間ステップでの車両の位置および向きを定義する「未精製」のノイズのある３Ｄバウンディング・ボックスのセットを示しており、これらのバウンディング・ボックスは、ノイズが加えられたグラウンド・トゥルースを表す。図示された例は、ノイズが加えられたバウンディング・ボックスに該当するが、現実世界の運転スタックからの車両検出結果を精製する場合にも同じ効果が得られる。図４Ｂに示されるように、バウンディング・ボックスはノイズを含み、検出されたバウンディング・ボックスの位置および向きは両方とも、認識エラーが原因で時間的に変動する。
【0122】
精製パイプラインは、このノイズを除去するために様々な方法を使用することができる。図４Ｂの下の軌道は、ノイズが除去された車両の擬似グラウンド・トゥルース軌跡１４４を示している。図に示されるように、車両の向きおよびその位置はフレームごとに一貫しており、滑らかな運転軌道を形成している。この平滑化を実行するためにパイプラインによって使用される複数の可能な方法は、詳細には説明されない。しかしながら、パイプラインは、オンライン検出器よりも優れたコンピューティング能力の恩恵を受けて、より正確な検出器が使用されることを可能にするだけでなく、過去および未来の検出結果を使用することから恩恵を受けて、軌道を滑らかにし、車から収集される現実世界の検出結果は、リアルタイムに機能するので、過去のデータのみに基づいている。たとえば、オブジェクトが時間ｔでは部分的に遮られているが、時間ｔ＋ｎでは車のセンサによって完全に見えるようになる場合、オフラインの精製パイプラインでは、時間ｔ＋ｎでの検出結果を使用して、部分的に遮られたデータに基づくより早い検出結果に知らせることによって、全体的により完全な検出結果をもたらすことができる。
【0123】
様々なタイプのオフライン検出器または検出結果精製方法が使用されることができる。図５Ａは可能な検出結果精製技術のテーブルを示しており、図５Ｂは、改善された検出結果を得るためにセンサ・データに適用されることができる可能なオフライン検出器のテーブルを示している。
【0124】
検出結果を精製するために様々な技術が使用される。一例は、カメラ画像に適用されるセマンティック・キーポイント検出である。精製後、結果は、たとえば図４Ｂに示されるように、車を滑らかに追跡する適切なサイズの直方体による安定した検出結果になる。
【0125】
国際特許公開第２０２１／０１３７９２号への参照が行われ、これは引用により本明細書に組み込まれている。上記の引用文献は、関心対象の各エージェントの擬似グラウンド・トゥルース軌跡を抽出するためにグラウンド・トゥルーシング・パイプライン４００内で実装されることができるオフラインのアノテーション方法のクラスを開示している。自動化されたアノテーション技術を適用して、現実世界での走行のデータ１４０に精製された３Ｄバウンディング・ボックスのシーケンスでアノテーション付けすることによって、軌跡が抽出される（この場合、エージェント軌跡は精製された３Ｄボックスで構成される）。
【0126】
この方法は大まかに以下のように機能する。現実世界走行データ１４０はフレームのシーケンスで構成され、各フレームは３Ｄ構造点のセット（たとえば、点群）で構成される。関心対象の各エージェント（自エージェントおよび／または他のエージェント）は、複数のフレームにわたってオブジェクトとして追跡される（このエージェントは、上記の引用文献の用語では「共通構造コンポーネント」である）。
【0127】
このコンテキストにおける「フレーム」とは、任意のキャプチャされた３Ｄ構造表現、すなわち、３Ｄ空間における構造を定義するキャプチャされた点（３Ｄ構造点）を含むものを指し、これは、そのフレームにキャプチャされた３Ｄ構造の基本的に静的な「スナップショット」（すなわち、静的な３Ｄシーン）を提供する。フレームは単一の瞬間に対応していると言われる場合があるが、これは必ずしも、フレームまたはフレームが導出される基礎となるセンサ・データが瞬間的にキャプチャされる必要があることを示唆するわけではなく、たとえば、移動体により短い区間（たとえば、約１００ｍｓ）にわたってライダー・スイープでライダー測定値がキャプチャされ、移動体の動きを考慮して「ほどかれて（ｕｎｔｗｉｓｔｅｄ）」、単一の点群を形成してもよい。その場合でも、単一の点群は単一の瞬間に対応すると言われる場合がある。
【0128】
現実世界走行データは、複数のフレーム・シーケンス、たとえば、ライダー、レーダー、深度フレームのうちの２つ以上の別個のシーケンスで構成されてもよい（このコンテキストでの深度フレームとは、ステレオまたは単眼深度イメージングなどの深度イメージングによって導出される３Ｄ点群を指す）。フレームは、異なるセンサおよび／または異なるセンサ・モダリティからの複数の点群を融合することによって計算される融合された点群で構成されることもできる。
【0129】
この方法は、関心対象の各エージェントの３Ｄバウンディング・ボックス推定値（粗いサイズ／姿勢推定値）の初期セットから開始し、これらの推定値を使用して、フレーム自体からそのエージェントの３Ｄモデルを構築する。ここで、姿勢とは、６Ｄ姿勢（３Ｄ空間内の３Ｄ位置および向き）を指す。以下の例は、特にライダーからの３Ｄモデルの抽出を考えるが、この説明は他のセンサ・モダリティにも同様に当てはまる。センサ・データの複数のモダリティを用いて、たとえば、１つまたは第２のセンサ・モダリティまたは複数のモダリティ（たとえば、レーダーまたは深度イメージング）によって粗い３Ｄボックスが提供されることができる。たとえば、３Ｄバウンディング・ボックス検出器を第２のモダリティ（または複数のモダリティ）の点群に適用することによって、初期の粗い推定値が計算されることができる。粗い推定値は、同じセンサ・モダリティ（この場合はライダー）から決定することもでき、後続の処理技術を使用してこの推定値を精製する。他の例として、テスト対象の認識システム１０２からのリアルタイムの３Ｄボックスが、初期の粗い推定値として使用されることができる（たとえば、現実世界での走行中に車両上で計算される場合）。後者のアプローチの場合、この方法は、検出結果精製の一形態として説明されることができる。
【0130】
各エージェントに対する集約的な３Ｄオブジェクト・モデルを作成するために、各フレームの粗い３Ｄバウンディング・ボックスに含まれる点のサブセットを取得することにより（または、オブジェクト点抽出のための追加の「余地」を設けるために、粗い３Ｄバウンディング・ボックスがわずかに拡大されてもよい）、そのオブジェクトに属する点が複数のフレームにわたって集約される。大まかに言えば、集約は、最初に各フレームからの点のサブセットをエージェントの基準フレームに変換することによって機能する。各フレーム内のエージェントの姿勢は概略的にしかわかっていないので、エージェント基準フレームへの変換はこの時点では正確にはわからない。変換は、粗い３Ｄバウンディング・ボックスから最初に推定される。たとえば、各フレーム内の粗い３Ｄバウンディング・ボックスの軸に合わせて点のサブセットを変換することにより、変換が効率的に実装されることができる。異なるフレームからの点のサブセットは、大部分が同じオブジェクトに属するが、初期姿勢推定値の誤差に起因して、エージェント基準フレーム内で位置がずれている場合がある。位置ずれを補正するために、位置合わせ方法を使用して、点の２つのサブセットを位置合わせする。そのような方法は、何らかの形態のマッチング・アルゴリズム（たとえば、反復最近接点（Ｉｔｅｒａｔｉｖｅ Ｃｌｏｓｅｓｔ Ｐｏｉｎｔ））を使用して、オブジェクト点のサブセットの一方を変換（回転／並進）して他方と位置合わせすることによって、大まかに機能する。マッチングは、点の２つのサブセットの大部分が同じオブジェクトのものであるという知識を使用する。次いで、このプロセスを後続のフレームにわたって繰り返して、オブジェクトの密な３Ｄモデルを構築することができる。このように密な３Ｄモデルを構築すると、ノイズ点（オブジェクトに属さないもの）が、実際のオブジェクト点から隔離されるので、さらにいっそう容易にフィルタリングされることができる。次に、密なフィルタリングされた３Ｄオブジェクト・モデルに３Ｄオブジェクト検出器を適用することで、問題のエージェントに対して、より正確なサイズのぴったりとフィットした３Ｄバウンディング・ボックスが決定されることができる（これは、３Ｄバウンディング・ボックスのサイズおよび形状がフレーム間で変化せず、各フレームの変数がその位置および向きのみであるような、剛体のエージェントを想定している）。最後に、集約的な３Ｄモデルが各フレーム内の対応するオブジェクト点とマッチングされて、各フレームにおけるより正確な３Ｄバウンディング・ボックスの位置が正確に特定されることによって、各フレームの精製された３Ｄバウンディング・ボックス推定値（擬似グラウンド・トゥルースの一部を形成する）が提供される。このプロセスは反復的に繰り返されることができ、それによって初期３Ｄモデルが抽出され、姿勢が精製され、精製された姿勢に基づいて３Ｄオブジェクト・モデルが更新され、以下同様である。
【0131】
精製された３Ｄバウンディング・ボックスは、位置ベースの認識出力（たとえば、走行時のボックス、姿勢推定値など）の認識エラーの程度を決定する際に、擬似グラウンド・トゥルース位置状態としての役割を果たす。
【0132】
運動情報を組み込むために、３Ｄバウンディング・ボックスが３Ｄ運動モデルと合同で最適化されてもよい。運動モデルは、問題のエージェントの運動状態（たとえば、スピード／速度、加速度など）を提供することができ、運動状態は、走行時の運動検出結果（たとえば、テスト対象の認識システム１０２によって計算されるスピード／速度、加速度推定値など）に対する擬似グラウンド・トゥルースとして使用されてもよい。運動モデルは、フレームにわたる現実的な（運動学的に実現可能な）３Ｄボックスを促進することができる。たとえば、合同の最適化は、集約的な３Ｄモデルと各フレームの点との間の不一致にペナルティを課すが、同時に、フレーム間のエージェント姿勢の運動学的に実行不可能な変化にペナルティを課すコスト関数に基づいて定式化されることができる。
【0133】
運動モデルはまた、運動モデルに基づいて隣接するフレーム間の３Ｄエージェントの姿勢を補間することによって、オブジェクト検出漏れ（すなわち、粗い推定値が利用可能でなく、これは、粗い推定値が車両上での検出結果であり、テスト対象の認識システム１０２が所与のフレームで失敗した場合に起こる場合がある）を含むフレームにおいて３Ｄボックスが正確に位置特定されることを可能にする。これは、認識トリアージ・ツール１５２内で、オブジェクト検出漏れが識別されることを可能にする。
【0134】
３Ｄモデルは集合点群の形態にすることができ、または表面モデル（たとえば、距離フィールド）が点にフィッティングされてもよい。引用により本明細書に組み込まれている国際特許公開第２０２１／０１３７９１号は、３Ｄオブジェクト・モデルの３Ｄ表面が、抽出された点にフィッティングされた（符号付き）距離フィールドとしてエンコードされる３Ｄオブジェクト・モデリング技術のさらなる詳細を開示している。
【0135】
これらの精製技術の用途は、これらを使用して、自車両および外部エージェントを含むシーンのエージェントの擬似グラウンド・トゥルース１４４を取得することができ、精製された検出結果が、シーン内でエージェントによって取られた現実の軌跡として扱われることができるということである。これは、車の検出結果を擬似グラウンド・トゥルースと比較することにより、車両の車上認識がどの程度正確であったかを査定するために使用されてもよい。擬似グラウンド・トゥルースは、テスト対象のシステム（すなわち、自車両スタック）がどのようにハイウェイ・ルールに違反して走行したかを確認するために使用されることもできる。
【0136】
擬似グラウンド・トゥルース検出結果１４４はまた、収集されたデータのセマンティックなタグ付けおよびクエリを行うために使用されることもできる。たとえば、ユーザは、「割り込みのある全てのイベントを探す」などのクエリを入力することができ、ここで、割り込みとは、エージェントが自車両の車線の自車両の前に進入したときのことである。擬似グラウンド・トゥルースは、任意の時点における位置および向きを含む、シーン内の全てのエージェントの軌跡を有しているので、エージェントがある車線の他の車両の前に進入した事例をエージェント軌跡内で検索することで、割り込みを識別することが可能である。より複雑なクエリが構築されてもよい。たとえば、ユーザは、「エージェントが少なくともｘの速度を有していた全ての割り込みを探して」というクエリを入力してもよい。データから抽出された擬似グラウンド・トゥルース軌跡によってエージェントの運動が定義されるので、エージェントが所与のスピードを超えていた割り込みの事例を精製された検出結果内で検索することは簡単である。これらのクエリが選択されて実行されると、データを手動で分析するのに必要な時間が短縮される。これは、ドライバーが関心のあるエリアをリアルタイムに識別することに依存する必要がなく、代わりに、収集されたデータ内で関心のあるエリアが自動的に検出されることができ、そこから関心のあるシナリオがさらなる分析のために抽出されることができることを意味する。これは、より多くのデータが使用されることを可能にし、場合によっては、人間のドライバーによって見落とされる可能性があるシナリオが識別されることを可能にする。
【0137】
テスト・パイプライン：
次に、テスト・パイプラインおよびテスト・オラクル２５２のさらなる詳細が説明される。以下の例は、シミュレーション・ベースのテストに焦点を当てている。しかしながら、上記のように、テスト・オラクル２５２は、現実のシナリオでスタック・パフォーマンスを評価するために同様に適用されることができ、以下の関連する説明は現実のシナリオにも同様に当てはまる。具体的には、以下で説明されるテスト・パイプラインは、図１～図５で説明された、現実世界のデータから得られた抽出されたグラウンド・トゥルース１４４と共に使用されてもよい。説明されるテスト・パイプラインを現実世界データ分析ツールにおいて認識評価パイプラインと共に適用することが、後でさらに詳しく説明される。以下の説明は、例として図２Ａのスタック１００に言及する。しかしながら、上記のように、テスト・パイプライン２００は非常に柔軟性が高く、任意の自律性レベルで動作する任意のスタックまたはサブ・スタックに適用されることができる。
次に、テスト・パイプラインおよびテスト・オラクル２５２のさらなる詳細が説明される。以下の例は、シミュレーション・ベースのテストに焦点を当てている。しかしながら、上記のように、テスト・オラクル２５２は、現実のシナリオでスタック・パフォーマンスを評価するために同様に適用されることができ、以下の関連する説明は現実のシナリオにも同様に当てはまる。具体的には、以下で説明されるテスト・パイプラインは、図１～図５で説明された、現実世界のデータから得られた抽出されたグラウンド・トゥルース１４４と共に使用されてもよい。説明されるテスト・パイプラインを現実世界データ分析ツールにおいて認識評価パイプラインと共に適用することが、後でさらに詳しく説明される。以下の説明は、例として図２Ａのスタック１００に言及する。しかしながら、上記のように、テスト・パイプライン２００は非常に柔軟性が高く、任意の自律性レベルで動作する任意のスタックまたはサブ・スタックに適用されることができる。
【0138】
図６Ａは、参照番号２００で表されるテスト・パイプラインの概略ブロック図を示している。テスト・パイプライン２００は、シミュレータ２０２およびテスト・オラクル２５２を含むように示されている。シミュレータ２０２は、ＡＶ走行時スタック１００の全部または一部をテストする目的でシミュレートされたシナリオを走行し、テスト・オラクル２５２は、シミュレートされたシナリオでのスタック（またはサブ・スタック）のパフォーマンスを評価する。論じられたように、走行時スタックのサブ・スタックのみがテストされてもよいが、単純にするために、以下の説明は全体を通して（フル）ＡＶスタック１００について言及する。しかしながら、この説明はフル・スタック１００の代わりにサブ・スタックにも同様に当てはまる。「スライシング」という用語は、本明細書では、テスト用のスタック・コンポーネントのセットまたはサブセットの選択に使用される。
【0139】
前述されたように、シミュレーション・ベースのテストのアイディアは、テスト中のスタック１００の制御下で自エージェントが進んでいかなければならないシミュレートされた運転シナリオを走行することである。典型的には、シナリオは、典型的には１つまたは複数の他の動的エージェント（たとえば、他の車両、自転車、歩行者など）の存在下で、自エージェントが進んでいくことを求められる静的な走行可能エリア（たとえば、特定の静的な道路レイアウト）を含む。この目的で、シミュレートされた入力２０３がシミュレータ２０２からテスト対象のスタック１００に提供される。
【0140】
スタックのスライシングは、シミュレートされた入力２０３の形態を決定付ける。例として、図６Ａは、テスト中のＡＶスタック１００内の予測、計画および制御システム１０４、１０６および１０８を示している。図２ＡのフルＡＶスタックをテストするために、認識システム１０２がテスト中に適用されることもできる。この場合、シミュレートされた入力２０３は、適切なセンサ・モデルを使用して生成され、現実のセンサ・データと同様に認識システム１０２内で処理される合成センサ・データを含む。これは、十分に現実的な合成センサ入力（たとえば、写実的な画像データおよび／または同様に現実的なシミュレートされたライダー／レーダー・データなど）の生成を必要とする。その結果得られる認識システム１０２の出力は次いで、上位レベルの予測および計画システム１０４、１０６に供給される。
【0141】
対照的に、いわゆる「計画レベル」のシミュレーションは、基本的に認識システム１０２をバイパスする。代わりに、シミュレータ２０２は、より単純な上位レベルの入力２０３を予測システム１０４に直接提供する。一部のコンテキストでは、シミュレートされたシナリオから直接得られた予測（すなわち、「完璧な」予測）に基づいてプランナ１０６をテストするために、予測システム１０４もバイパスすることさえ適切な場合がある。
【0142】
これらの両極端の間には、多くの異なるレベルの入力スライシングの余地があり、たとえば、認識システム１０２のサブセットのみ、たとえば、「後期の」（上位レベルの）認識コンポーネント、たとえば、下位レベルの認識コンポーネント（たとえば、オブジェクト検出器、バウンディング・ボックス検出器、動き検出器など）からの出力に作用する、フィルタまたは融合コンポーネントなどのコンポーネントをテストするなどである。
【0143】
どのような形態を取っても、シミュレートされた入力２０３は、プランナ１０８による意思決定の基礎として（直接的または間接的に）使用される。次いで、コントローラ１０８は、制御信号１０９を出力することによって、プランナの決定を実施する。現実世界のコンテキストでは、これらの制御信号はＡＶの物理的なアクター・システム１１２を駆動する。シミュレーションでは、自車両ダイナミクス・モデル２０４を使用して、結果として得られた制御信号１０９をシミュレーション内での自エージェントの現実的な動きに変換することによって、制御信号１０９に対する自律車両の物理的応答をシミュレートする。
【0144】
代替的には、より単純な形態のシミュレーションは、自エージェントが計画ステップ間で計画された各軌道を正確に辿ると仮定する。このアプローチは、制御システム１０８を（計画から分離可能な範囲で）バイパスし、自車両ダイナミクス・モデル２０４の必要性を取り除く。計画の特定の側面をテストするにはこれで十分な場合がある。
【0145】
外部エージェントがシミュレータ２０２内で自律的な挙動／意思決定を示す範囲内で、何らかの形態のエージェント決定ロジック２１０が、それらの決定を行い、シナリオ内でのエージェントの挙動を決定するように実装される。エージェント決定ロジック２１０は、自己スタック１００自体と同等の複雑さであってもよく、またはより限定された意思決定能力を有してもよい。狙いは、自己スタック１００の意思決定能力を有用にテストできるようにするために、シミュレータ２０２内に十分に現実的な外部エージェントの挙動を提供することである。一部のコンテキストでは、これはエージェント意思決定ロジック２１０を全く必要とせず（開ループ・シミュレーション）、他のコンテキストでは、基本的なアダプティブ・クルーズ・コントロール（ＡＣＣ）などの比較的限定されたエージェント・ロジック２１０を使用して有用なテストが提供されることができる。適切な場合、１つまたは複数のエージェント・ダイナミクス・モデル２０６が、より現実的なエージェントの挙動を提供するために使用されてもよい。
【0146】
シナリオは、シナリオのシナリオ記述２０１ａおよび（該当する場合）選ばれたパラメータ化２０１ｂに従って走行される。シナリオは典型的には静的要素および動的要素の両方を有し、これらはシナリオ記述２０１ａ内に「ハード・コード」されてもよく、または設定可能であり、したがってシナリオ記述２０１ａによって、選ばれたパラメータ化２０１ｂと組み合わせて決定されてもよい。運転シナリオでは、静的要素は典型的には静的な道路レイアウトを含む。
【0147】
動的要素は、典型的にはシナリオ内の１つまたは複数の外部エージェント、たとえば、他の車両、歩行者、自転車などを含む。
【0148】
各外部エージェントについてシミュレータ２０２に提供される動的情報の範囲は変化することができる。たとえば、シナリオは、分離可能な静的レイヤおよび動的レイヤによって記述されてもよい。様々なシナリオ・インスタンスを提供するために、所与の静的レイヤ（たとえば、道路レイアウトを定義する）は、様々な動的レイヤと組み合わせて使用されることができる。動的レイヤは、各外部エージェントについて、そのエージェントによって辿られる空間経路を、その経路に関連付けられた運動データおよび挙動データの一方または両方と共に含んでもよい。単純な開ループ・シミュレーションでは、外部アクターは、非反応性の、すなわち、シミュレーション内で自エージェントに反応しない、動的レイヤで定義された空間経路および運動データを単に辿る。そのような開ループ・シミュレーションは、エージェント決定ロジック２１０なしで実装されることができる。しかしながら、閉ループ・シミュレーションでは、動的レイヤは代わりに、静的経路に沿って辿られる少なくとも１つの挙動（たとえば、ＡＣＣの挙動）を定義する。この場合、エージェント決定ロジック２１０はその挙動をシミュレーション内で反応的な方法で、すなわち、自エージェントおよび／または他の外部エージェントに対して反応的に実施する。運動データは、依然として静的経路に関連付けられてもよいが、この場合はあまり規範的ではなく、たとえば、経路に沿った目標としての役割を果たしてもよい。たとえば、ＡＣＣの挙動では、エージェントが一致させようとする経路に沿って目標スピードが設定されることができるが、エージェント決定ロジック２１０は、前方車両との目標車間距離を維持するために経路に沿った任意の点で外部エージェントのスピードを目標よりも下げることが許可されてもよい。
【0149】
理解されるように、シナリオは、シミュレーションの目的で、任意の度合いの設定可能性を有する多くの方法で記述されることができる。たとえば、エージェントの数およびタイプ、ならびにそれらの運動情報は、シナリオ・パラメータ化２０１ｂの一部として設定可能であってもよい。
【0150】
所与のシミュレーションに関するシミュレータ２０２の出力は、自エージェントの自己軌跡２１２ａおよび１つまたは複数の外部エージェントの１つまたは複数のエージェント軌跡２１２ｂ（軌跡２１２）を含む。各軌跡２１２ａ、２１２ｂは、空間成分および運動成分の両方を有するシミュレーション内でのエージェントの挙動の完全な履歴である。たとえば、各軌跡２１２ａ、２１２ｂは、スピード、加速度、ジャーク（加速度の変化率）、スナップ（ジャークの変化率）など、経路に沿った点に関連付けられた運動データを有する空間経路の形態を取ってもよい。
【0151】
軌跡２１２を補足し、これにコンテキストを提供するための追加情報も提供される。そのような追加情報は、「コンテキスト」データ２１４と呼ばれる。コンテキスト・データ２１４は、シナリオの物理的コンテキストに関係し、静的コンポーネント（たとえば、道路レイアウト）と動的コンポーネント（たとえば、シミュレーションにわたって変化する範囲での気象条件）との両方を有することができる。コンテキスト・データ２１４は、シナリオ記述２０１ａまたはパラメータ化２０１ｂの選択によって直接定義されるので、シミュレーションの結果に影響されないという点で、ある程度「パススルー」であってもよい。たとえば、コンテキスト・データ２１４は、シナリオ記述２０１ａまたはパラメータ化２０１ｂによって直接もたらされる静的な道路レイアウトを含んでもよい。しかしながら、典型的には、コンテキスト・データ２１４は、シミュレータ２０２内で導出された少なくともいくつかの要素を含む。これは、たとえば、気象データなどのシミュレートされた環境データを含むことができ、シミュレータ２０２は、シミュレーションの進行と共に、気象条件を自由に変更することができる。その場合、気象データは時間に依存してもよく、その時間依存性はコンテキスト・データ２１４に反映される。
【0152】
テスト・オラクル２５２は、軌跡２１２およびコンテキスト・データ２１４を受け取り、それらの出力をパフォーマンス評価ルール２５４のセットに関してスコアリングする。パフォーマンス評価ルール２５４は、テスト・オラクル２５２への入力として提供されることが示されている。
【0153】
ルール２５４は通常、カテゴリ的なもの（たとえば、合格／不合格タイプのルール）である。特定のパフォーマンス評価ルールは、軌道を「スコアリング」するために使用される数値パフォーマンス・メトリック（たとえば、達成または不合格の度合い、またはカテゴリ結果を説明するのに役立つか、もしくは別の方法でカテゴリ結果に関連する他の数量を示す）にも関連付けられる。ルール２５４の評価は時間ベースであり、所与のルールはシナリオ内の異なる時点で異なる結果を有する場合がある。スコアリングも時間ベースであり、各パフォーマンス評価メトリックについて、テスト・オラクル２５２は、シミュレーションが進行するにつれてそのメトリックの値（スコア）が時間の経過と共にどのように変化するかを追跡する。テスト・オラクル２５２は、後でさらに詳細に説明されるように、各ルールのカテゴリ（たとえば、合格／不合格）結果の時間シーケンス２５６ａと、各パフォーマンス・メトリックのスコア－時間プロット２５６ｂとを含む出力２５６を提供する。結果およびスコア２５６ａ、２５６ｂは、エキスパート１２２にとって有益であり、テストされたスタック１００内のパフォーマンスの課題を特定して軽減するために使用されることができる。テスト・オラクル２５２は、シナリオの全体的な（集約的な）結果（たとえば、全体的な合格／不合格）も提供する。テスト・オラクル２５２の出力２５６は、出力２５６が関係するシナリオに関する情報に関連付けて、テスト・データベース２５８に記憶される。たとえば、出力２５６は、シナリオ記述２１０ａ（またはその識別子）および選ばれたパラメータ化２０１ｂに関連付けて記憶されてもよい。時間依存の結果およびスコアと同様に、全体のスコアもシナリオに割り当てられ、出力２５６の一部として記憶されてもよい。たとえば、各ルールの集約スコア（たとえば、全体の合格／不合格）、および／または全てのルール２５４にわたる集約結果（たとえば、合格／不合格）。
【0154】
図６Ｂは、スライシングの他の選択を示しており、参照番号１００および１００Ｓを使用して、それぞれフル・スタックおよびサブ・スタックを表している。図６Ａのテスト・パイプライン２００内でテストの対象となるのはサブ・スタック１００Ｓである。
【0155】
いくつかの「後期」認識コンポーネント１０２Ｂは、テストされるサブ・スタック１００Ｓの一部を形成し、テスト中に、シミュレートされた認識入力２０３に適用される。後期認識コンポーネント１０２Ｂは、複数の早期認識コンポーネントからの認識入力を融合するフィルタリングまたは他の融合コンポーネントなどを含むことができる。
【0156】
フル・スタック１００では、後期認識コンポーネント１０２Ｂは、早期認識コンポーネント１０２Ａから実際の認識入力２１３を受け取る。たとえば、早期認識コンポーネント１０２Ａは、１つまたは複数の２Ｄまたは３Ｄバウンディング・ボックス検出器を備えてもよく、その場合、後期認識コンポーネントに提供されるシミュレートされた認識入力は、シミュレーションでレイ・トレーシングにより導出された、シミュレートされた２Ｄまたは３Ｄバウンディング・ボックス検出結果を含むことができる。早期認識コンポーネント１０２Ａは、一般に、センサ・データに対して直接作用するコンポーネントを含む。図６Ｂのスライシングでは、シミュレートされた認識入力２０３は、通常は早期認識コンポーネント１０２Ａによって提供される実際の認識入力２１３に形式的に対応する。しかしながら、早期認識コンポーネント１０２Ａは、テストの一部として適用されるのではなく、代わりに１つまたは複数の認識エラー・モデル２０８をトレーニングするために使用され、認識エラー・モデル２０８は、テスト対象のサブ・スタック１００の後期認識コンポーネント１０２Ｂに供給されるシミュレートされた認識入力２０３に現実的なエラーを統計的に厳密な方法で導入するために使用されることができる。
【0157】
そのような認識エラー・モデルは、認識統計パフォーマンス・モデル（ＰＳＰＭ：Ｐｅｒｃｅｐｔｉｏｎ Ｓｔａｔｉｓｔｉｃａｌ Ｐｅｒｆｏｒｍａｎｃｅ Ｍｏｄｅｌ）、または同義的に「ＰＲＩＳＭ」と呼ばれる場合がある。ＰＳＰＭの原理のさらなる詳細、およびＰＳＰＭを構築およびトレーニングするための適切な技術は、国際特許公開第２０２１０３７７６３号、第２０２１０３７７６０号、第２０２１０３７７６５号、第２０２１０３７７６１号、および第２０２１０３７７６６号で見つけられることができ、それぞれの全体が引用により本明細書に組み込まれている。ＰＳＰＭの背後にあるアイディアは、サブ・スタック１００Ｓに提供されるシミュレートされた認識入力に現実的なエラーを効率的に導入することである（すなわち、早期認識コンポーネント１０２Ａが現実世界で適用された場合に予想される種類のエラーを反映する）。シミュレーション・コンテキストでは、シミュレータによって「完璧な」グラウンド・トゥルース認識入力２０３Ｇが提供されるが、これらは、認識エラー・モデル２０８によって導入された現実的なエラーを有するより現実的な認識入力２０３を導出するために使用される。
【0158】
前述の引用文献で説明されているように、ＰＳＰＭは物理的条件を表す１つまたは複数の変数（「交絡因子」）に依存することができ、起こり得る様々な現実世界の条件を反映する様々なレベルのエラーが導入されることを可能にする。したがって、シミュレータ２０２は、単に気象交絡因子の値を変更して、認識エラーの導入のされ方を変化させることによって、異なる物理的条件（たとえば、異なる気象条件）をシミュレートすることができる。
【0159】
サブ・スタック１００Ｓ内の後期認識コンポーネント１０２ｂは、フル・スタック１００内で現実世界の認識入力２１３を処理するのと全く同じ方法でシミュレートされた認識入力２０３を処理し、その出力は予測、計画、および制御を駆動する。
【0160】
代替的には、ＰＲＩＳＭは、後期認識コンポーネント１０２Ｂを含む認識システム１０２全体をモデル化するために使用されることができ、その場合、入力として予測システム１０４に直接渡される現実的な認識出力を生成するためにＰＳＰＭが使用される。
【0161】
実装に応じて、所与のシナリオ・パラメータ化２０１ｂと、スタック１００の所与の構成でのシミュレーションの結果との間に決定的な関係がある場合もあれば、そうでない場合もある（すなわち、同じパラメータ化が、同じスタック１００で常に同じ結果につながる場合もあれば、そうでない場合もある）。非決定性は様々な方法で生じる場合がある。たとえば、シミュレーションがＰＲＩＳＭに基づく場合、ＰＲＩＳＭはシナリオの所与の時間ステップごとに可能な認識出力の分布をモデル化してもよく、そこから現実的な認識出力が確率的にサンプリングされる。これはシミュレータ２０２内で非決定的な挙動につながり、そのため、異なる認識出力がサンプリングされるので、同じスタック１００およびシナリオ・パラメータ化に対して異なる結果が得られる場合がある。代替的または追加的には、シミュレータ２０２は本質的に非決定的であってもよく、たとえば、天候、照明、または他の環境条件がシミュレータ２０２内である程度ランダム化されてもよい／確率的であってもよい。理解されるように、これは設計上の選択であり、他の実装形態では、代わりに、様々な環境条件がシナリオのパラメータ化２０１ｂで完全に指定されることもできる。非決定的なシミュレーションでは、パラメータ化ごとに複数のシナリオ・インスタンスが走行されることができる。特定のパラメータ化２０１ｂの選択に対して、集約的な合格／不合格の結果が、たとえば、合格／不合格の結果のカウントまたはパーセンテージとして、割り当てられることができる。
【0162】
テスト・オーケストレーション・コンポーネント２６０は、シミュレーションの目的でシナリオを選択する役割を担う。たとえば、テスト・オーケストレーション・コンポーネント２６０は、以前のシナリオからのテスト・オラクル出力２５６に基づいて、シナリオ記述２０１ａおよび適切なパラメータ化２０１ｂを自動的に選択してもよい。
【0163】
テスト・オラクル・ルール：
パフォーマンス評価ルール２５４は、テスト・オラクル内で適用される計算グラフ（ルール・ツリー）として構築される。特に明記されない限り、本明細書における「ルール・ツリー」という用語は、所与のルールを実装するように構成される計算グラフを指す。各ルールはルール・ツリーとして構築され、複数のルールのセットは複数のルール・ツリーの「フォレスト」と呼ばれる場合がある。
パフォーマンス評価ルール２５４は、テスト・オラクル内で適用される計算グラフ（ルール・ツリー）として構築される。特に明記されない限り、本明細書における「ルール・ツリー」という用語は、所与のルールを実装するように構成される計算グラフを指す。各ルールはルール・ツリーとして構築され、複数のルールのセットは複数のルール・ツリーの「フォレスト」と呼ばれる場合がある。
【0164】
図７Ａは、エクストラクタ・ノード（リーフ・オブジェクト）３０２とアセッサ・ノード（非リーフ・オブジェクト）３０４との組み合わせから構築されたルール・ツリー３００の例を示している。各エクストラクタ・ノード３０２は、シナリオ・データ３１０のセットから時間変化する数値（たとえば、浮動小数点）信号（スコア）を抽出する。シナリオ・データ３１０は、上記で説明された意味でシナリオ・グラウンド・トゥルースの一形態であり、そのように呼ばれる場合がある。シナリオ・データ３１０は、軌道プランナ（たとえば、図２Ａのプランナ１０６）を現実のシナリオまたはシミュレートされたシナリオに配備することによって取得されており、自己およびエージェント軌跡２１２ならびにコンテキスト・データ２１４を含むように示されている。図６または図６Ａのシミュレーション・コンテキストでは、シナリオ・グラウンド・トゥルース３１０はシミュレータ２０２の出力として提供される。
【0165】
各アセッサ・ノード３０４は、少なくとも１つの子オブジェクト（ノード）を有するように示されており、各子オブジェクトは、エクストラクタ・ノード３０２のうちの１つ、またはアセッサ・ノード３０４のうちの別の１つである。各アセッサ・ノードはその子ノードから出力を受け取り、それらの出力にアセッサ関数を適用する。アセッサ関数の出力は、カテゴリ結果の時系列である。以下の例は、単純な２値の合格／不合格の結果を考えるが、本技術は非２値の結果にも容易に拡張されることができる。各アセッサ関数は、その子ノードの出力を予め定められた原子的（ａｔｏｍｉｃ）ルールに照らして査定する。そのようなルールは、所望の安全性モデルに応じて柔軟に組み合わせられることができる。
【0166】
加えて、各アセッサ・ノード３０４は、その子ノードの出力から時間変化する数値信号を導出し、これは閾値条件（下記参照）によってカテゴリ結果に関連付けられる。
【0167】
最上位のルート・ノード３０４ａは、他のいかなるノードの子ノードでもないアセッサ・ノードである。最上位ノード３０４ａは、最終的な結果のシーケンスを出力し、その子孫（すなわち、最上位ノード３０４ａの直接的または間接的な子であるノード）は、基礎となる信号および中間結果を提供する。
【0168】
図７Ｂは、アセッサ・ノード３０４によって計算された導出された信号３１２および対応する結果３１４の時系列の例を視覚的に示している。結果３１４は、導出された信号が不合格閾値３１６を超えている場合に（その場合にのみ）合格の結果が返されるという点で、導出された信号３１２と相関している。理解されるように、これは、結果の時間シーケンスを対応する信号に関連付ける閾値条件の一例にすぎない。
【0169】
エクストラクタ・ノード３０２によってシナリオ・グラウンド・トゥルース３１０から直接抽出された信号は、アセッサ・ノード３０４によって計算された「導出された」信号と区別するために、「生」信号と呼ばれる場合がある。結果および生信号／導出された信号は時間的に離散化されてもよい。
【0170】
図８Ａは、テスト・プラットフォーム２００内に実装されるルール・ツリーの例を示している。
【0171】
ルール・エディタ４００は、テスト・オラクル２５２で実装されるルールを構築するために提供される。ルール・エディタ４００は、ユーザ（システムのエンド・ユーザであってもなくてもよい）からルール作成入力を受け取る。この例では、ルール作成入力は、ドメイン固有言語（ＤＳＬ）でコード化され、テスト・オラクル２５２内に実装される少なくとも１つのルール・グラフ４０８を定義する。以下の例では、ルールは論理ルールであり、真および偽はそれぞれ合格および不合格を表す（理解されるように、これは純粋に設計上の選択である）。
【0172】
以下の例は、原子論理述語の組み合わせを使用して定式化されるルールを考える。基本的な原子述語の例は、初等的な論理ゲート（ＯＲ、ＡＮＤなど）と、論理関数、たとえば、「ｇｒｅａｔｅｒ ｔｈａｎ」、（Ｇｔ（ａ，ｂ））（これは、ａがｂより大きい場合は真、それ以外の場合は偽を返す）などとを含む。
【0173】
Ｇｔ関数は、自エージェントと、シナリオ内の他のエージェント（エージェント識別子「ｏｔｈｅｒ＿ａｇｅｎｔ＿ｉｄ」を有する）との間の安全横方向距離ルールを実装するためのものである。２つのエクストラクタ・ノード（ｌａｔｄ、ｌａｔｓｄ）は、それぞれＬａｔｅｒａｌＤｉｓｔａｎｃｅおよびＬａｔｅｒａｌＳａｆｅＤｉｓｔａｎｃｅエクストラクタ関数を適用する。これらの関数は、シナリオ・グラウンド・トゥルース３１０に直接作用して、時間変化する横方向距離信号（自エージェントと識別された他のエージェントとの間の横方向距離を測定する）と、自エージェントおよび識別された他のエージェントに関する時間変化する安全横方向距離信号とをそれぞれ抽出する。安全横方向距離信号は、（軌跡２１２にキャプチャされた）自エージェントのスピードおよび他のエージェントのスピード、ならびにコンテキスト・データ２１４にキャプチャされた環境条件（たとえば、天候、照明、道路タイプなど）などの様々な要因に依存することができる。
【0174】
アセッサ・ノード（ｉｓ＿ｌａｔｄ＿ｓａｆｅ）は、ｌａｔｄおよびｌａｔｓｄエクストラクタ・ノードの親であり、Ｇｔ原子述語にマッピングされている。したがって、ルール・ツリー４０８が実施されると、ｉｓ＿ｌａｔｄ＿ｓａｆｅアセッサ・ノードは、ｌａｔｄおよびｌａｔｓｄエクストラクタ・ノードの出力にＧｔ関数を適用して、シナリオの時間ステップごとに真／偽の結果を計算し、ｌａｔｄ信号がｌａｔｓｄ信号を超えている時間ステップごとに真を返し、それ以外の場合は偽を返す。このように、「安全横方向距離」ルールが原子エクストラクタ関数および述語から構築されており、横方向距離が安全横方向距離閾値に達しているか下回っている場合、自エージェントは安全横方向距離ルールに不合格となる。理解されるように、これはルール・ツリーの非常に単純な例である。同じ原理に従って任意の複雑さのルールが構築されることができる。
【0175】
テスト・オラクル２５２は、ルール・ツリー４０８をシナリオ・グラウンド・トゥルース３１０に適用し、ユーザ・インターフェース（ＵＩ）４１８を介して結果を提供する。
【0176】
図８Ｂは、図８Ａに対応する横方向距離ブランチを含むルール・ツリーの例を示している。追加的に、ルール・ツリーは、前後方向距離ブランチと、安全距離メトリックを実装するための最上位のＯＲ述語（安全距離ノード、ｉｓ＿ｄ＿ｓａｆｅ）とを含む。横方向距離ブランチと同様に、前後方向距離ブランチは、シナリオ・データから前後方向距離および前後方向距離閾値信号（それぞれエクストラクタ・ノードｌｏｎｄおよびｌｏｎｓｄ）を抽出し、前後方向距離が安全前後方向距離閾値を上回っている場合、前後方向安全性アセッサ・ノード（ｉｓ＿ｌｏｎｄ＿ｓａｆｅ）は真を返す。最上位のＯＲノードは、横方向距離および前後方向距離の一方または両方が安全である（該当する閾値を下回っている）場合は真を返し、どちらも安全でない場合は偽を返す。このコンテキストでは、距離の一方のみが安全閾値を超えていれば十分である（たとえば、２台の車両が隣接する車線を走行している場合、それらが隣り合っているときに、前後方向間隔はゼロまたはゼロ付近であるが、それらの車両が十分な横方向間隔を有していれば、そのシチュエーションは危険ではない）。
【0177】
最上位ノードの数値出力は、たとえば、時間変化するロバスト性スコアとすることができる。
【0178】
異なるルール・ツリーを構築して、たとえば、所与の安全性モデルの異なるルールを実装する、異なる安全性モデルを実装する、または異なるシナリオに選択的にルールを適用することができる（所与の安全性モデルでは、全てのルールが必ずしも全てのシナリオに該当するわけではなく、このアプローチでは、異なるルールまたはルールの組み合わせが異なるシナリオに適用されることができる）。このフレームワーク内で、快適性（たとえば、軌道に沿った瞬間的な加速度および／またはジャークに基づく）、進捗状況（たとえば、定められたゴールに到達するまでにかかる時間に基づく）などを評価するためのルールが構築されることもできる。
【0179】
上記の例は、たとえば、ＯＲ、ＡＮＤ、Ｇｔなど、単一の時点での結果または信号で評価される単純な論理述語を考えている。しかしながら、実際には、時相論理の観点で特定のルールを定式化することが望ましい場合がある。
【0180】
Ｈｅｋｍａｔｎｅｊａｄら、「Ｅｎｃｏｄｉｎｇ ａｎｄ Ｍｏｎｉｔｏｒｉｎｇ Ｒｅｓｐｏｎｓｉｂｉｌｉｔｙ Ｓｅｎｓｉｔｉｖｅ Ｓａｆｅｔｙ Ｒｕｌｅｓ ｆｏｒ Ａｕｔｏｍａｔｅｄ Ｖｅｈｉｃｌｅｓ ｉｎ Ｓｉｇｎａｌ Ｔｅｍｐｏｒａｌ Ｌｏｇｉｃ」（２０１９）、ＭＥＭＯＣＯＤＥ ’１９：Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １７ｔｈ ＡＣＭ－ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｆｏｒｍａｌ Ｍｅｔｈｏｄｓ ａｎｄ Ｍｏｄｅｌｓ ｆｏｒ Ｓｙｓｔｅｍ Ｄｅｓｉｇｎ（その全体が引用により本明細書に組み込まれている）は、ＲＳＳ安全性ルールの信号時相論理（ＳＴＬ：ｓｉｇｎａｌ ｔｅｍｐｏｒａｌ ｌｏｇｉｃ）コード化を開示している。時相論理は、時間に関する条件付きの述語を構築するための形式的なフレームワークを提供する。これは、所与の瞬間でアセッサによって計算された結果が、他の瞬間の結果および／または信号値に依存することができるということを意味する。
【0181】
たとえば、安全性モデルの要件は、自エージェントが設定された時間枠内で特定のイベントに対応することである場合がある。そのようなルールは、ルール・ツリー内で時相論理述語を使用して、同様の方法でコード化されることができる。
【0182】
上記の例では、スタック１００のパフォーマンスはシナリオの各時間ステップで評価される。ここから全体のテスト結果（たとえば、合格／不合格）が導出されることができ、たとえば、特定のルール（たとえば、安全性が決定的に重要なルール）は、シナリオ内の任意の時間ステップでルールに不合格であった場合に、全体の不合格をもたらしてもよい（すなわち、シナリオの全体の合格を取得するには、全ての時間ステップでルールに合格しなければならない）。他のタイプのルールの場合、全体の合格／不合格基準は「より緩やか」であってもよく（たとえば、特定のルールに関して、ある数の連続した時間ステップにわたってそのルールに不合格であった場合にのみ、不合格が発動されてもよい）、そのような基準はコンテキストに依存してもよい。
【0183】
図８Ｃは、テスト・オラクル２５２内に実装されるルール評価の階層を概略的に示している。ルール２５４のセットは、テスト・オラクル２５２での実装のために受け取られる。
【0184】
特定のルールは自エージェントにのみ適用される（一例は快適性ルールであり、これは任意の所与の瞬間で自己軌道によって最大加速度またはジャーク閾値が超えられているか否かを査定する）。
【0185】
他のルールは、自エージェントと他のエージェントとの相互作用に関係する（たとえば、「衝突なし」ルールまたは上記で検討された安全距離ルール）。そのような各ルールは、自エージェントと他の各エージェントとの間でペア方式で評価される。他の例として、「歩行者緊急ブレーキ」ルールは、歩行者が自車両の前に歩いてきた場合にのみ、かつその歩行者エージェントに関してのみ、アクティブ化されてもよい。
【0186】
全てのルールが必ずしも全てのシナリオに該当するわけではなく、一部のルールはシナリオの一部にしか該当しない場合がある。テスト・オラクル２５２内のルール・アクティブ化ロジック４２２は、ルール２５４のそれぞれが問題のシナリオに該当する否か、いつ該当するかを決定し、該当する場合は、該当するときにルールを選択的にアクティブ化する。したがって、ルールは、シナリオ全体でアクティブなままになる場合があり、所与のシナリオでは一度もアクティブ化されない場合があり、またはシナリオの一部でのみアクティブ化される場合がある。さらに、ルールは、シナリオの異なる時点で異なる数のエージェントに対して評価されてもよい。このようにルールを選択的にアクティブ化することは、テスト・オラクル２５２の効率を大幅に向上させることができる。
【0187】
所与のルールのアクティブ化または非アクティブ化は、１つまたは複数の他のルールのアクティブ化／非アクティブ化に依存してもよい。たとえば、「最適な快適性」ルールは、歩行者緊急ブレーキ・ルールがアクティブ化されている場合には非該当とみなされてもよく（歩行者の安全が一番の関心事であるため）、後者がアクティブな場合は常に、前者が非アクティブ化されてもよい。
【0188】
ルール評価ロジック４２４は、それぞれのアクティブなルールを、それがアクティブなままである期間の間評価する。それぞれの相互作用的なルールは、自エージェントと、それが適用される他のエージェントとの間でペア方式で評価される。
【0189】
また、ルールの適用にはある程度の相互依存関係が存在してもよい。たとえば、快適性ルールと緊急ブレーキ・ルールとの間の関係に対処する他の方法は、緊急ブレーキ・ルールが少なくとも１つの他のエージェントに対してアクティブ化されるときは常に、快適性ルールのジャーク／加速度閾値を増加させることであろう。
【0190】
合格／不合格の結果が考えられているが、ルールは非２値であってもよい。たとえば、不合格の２つのカテゴリ、すなわち、「許容可能」および「許容不可能」が導入されてもよい。再度、快適性ルールと緊急ブレーキ・ルールとの間の関係を考えると、快適性ルールの許容可能な不合格は、そのルールには不合格であったが、緊急ブレーキ・ルールがアクティブであったときに生じてもよい。したがって、ルール間の相互依存関係は、様々な方法で対処されることができる。
【0191】
ルール２５４のアクティブ化基準は、ルール・エディタ４００に提供されるルール作成コードで指定されることができ、ルールの相互依存関係の性質およびそれらの相互依存関係を実装するためのメカニズムも同様である。
【0192】
グラフィカル・ユーザ・インターフェース：
図９Ａは、視覚化コンポーネント５２０の概略ブロック図を示している。視覚化コンポーネントは、テスト・オラクル２５２の出力２５６をグラフィカル・ユーザ・インターフェース（ＧＵＩ）５００上にレンダリングするための、テスト・データベース２５８に接続された入力を有するように示されている。ＧＵＩはディスプレイ・システム５２２上にレンダリングされる。
図９Ａは、視覚化コンポーネント５２０の概略ブロック図を示している。視覚化コンポーネントは、テスト・オラクル２５２の出力２５６をグラフィカル・ユーザ・インターフェース（ＧＵＩ）５００上にレンダリングするための、テスト・データベース２５８に接続された入力を有するように示されている。ＧＵＩはディスプレイ・システム５２２上にレンダリングされる。
【0193】
図９Ｂは、ＧＵＩ５００の例示的なビューを示している。このビューは、複数のエージェントを含む特定のシナリオに関するものである。この例では、テスト・オラクル出力５２６は複数の外部エージェントに関係しており、結果はエージェントごとに編成されている。各エージェントについて、シナリオのある時点でそのエージェントに該当するルールごとに、結果の時系列が利用可能である。図示された例では、「エージェント０１」のサマリ・ビューが選択されており、該当するルールごとに計算された「最上位」の結果が表示されている。各ルール・ツリーのルート・ノードで計算された最上位の結果がある。そのエージェントに対してルールが非アクティブである期間、アクティブかつ合格である期間、およびアクティブかつ不合格である期間を区別するために色分けが使用されている。
【0194】
結果の時系列ごとに第１の選択可能な要素５３４ａが設けられている。これは、ルール・ツリーの下位レベルの結果、すなわち、ルール・ツリーの下方で計算された結果がアクセスされることを可能にする。
【0195】
図９Ｃは「ルール０２」の結果の第１の展開されたビューを示しており、下位レベルのノードの結果も視覚化されている。たとえば、図４Ｂの「安全距離」ルールに関して、「ｉｓ＿ｌａｔｄ＿ｓａｆｅ」ノードおよび「ｉｓ＿ｌｏｎｄ＿ｓａｆｅ」ノードの結果が視覚化されてもよい（図９Ｃでは「Ｃ１」および「Ｃ２」とラベル付けされている）。ルール０２の第１の展開されたビューでは、ルール０２の達成／不合格が結果Ｃ１およびＣ２の間の論理ＯＲ関係によって定義されており、Ｃ１およびＣ２の両方で不合格が得られた場合にのみルール０２が不合格である（上記の「安全距離」ルールの場合と同様）ことがわかる。
【0196】
結果の時系列ごとに第２の選択可能な要素５３４ｂが設けられており、これは関連付けられた数値パフォーマンス・スコアがアクセスされることを可能にする。
【0197】
図９Ｄは第２の展開されたビューを示しており、ルール０２の結果および「Ｃ１」の結果が展開されており、これらのルールがエージェント０１に対してアクティブである期間の関連付けられたスコアが見えるようになっている。スコアは、合格／不合格を表すために同様に色分けされた視覚的なスコア－時間のプロットとして表示される。
【0198】
例示的なシナリオ：
図１０Ａは、自車両６０２と他の車両６０４との間の衝突イベントで終了する、シミュレータ２０２における割り込みシナリオの第１のインスタンスを示している。割り込みシナリオは複数車線の運転シナリオとして特徴付けられ、自車両６０２が第１の車線６１２（自車線）に沿って移動しており、他の車両６０４が最初は第２の隣接車線６０４に沿って移動している。このシナリオのある時点で、他の車両６０４は、隣接車線６１４から自車線６１２に、自車両６０２の前方（割り込み距離）に移動する。このシナリオでは、自車両６０２は他の車両６０４との衝突を回避することができない。第１のシナリオ・インスタンスは、衝突イベントに応じて終了する。
図１０Ａは、自車両６０２と他の車両６０４との間の衝突イベントで終了する、シミュレータ２０２における割り込みシナリオの第１のインスタンスを示している。割り込みシナリオは複数車線の運転シナリオとして特徴付けられ、自車両６０２が第１の車線６１２（自車線）に沿って移動しており、他の車両６０４が最初は第２の隣接車線６０４に沿って移動している。このシナリオのある時点で、他の車両６０４は、隣接車線６１４から自車線６１２に、自車両６０２の前方（割り込み距離）に移動する。このシナリオでは、自車両６０２は他の車両６０４との衝突を回避することができない。第１のシナリオ・インスタンスは、衝突イベントに応じて終了する。
【0199】
図１０Ｂは、第１のシナリオ・インスタンスのグラウンド・トゥルース３１０ａから得られる第１のオラクル出力２５６ａの例を示している。「衝突なし」ルールが、自車両６０２と他の車両６０４との間でシナリオの持続時間にわたって評価される。衝突イベントは、シナリオの終了時のこのルールの不合格をもたらす。加えて、図４Ｂの「安全距離」ルールが評価される。他の車両６０４が自車両６０２に横方向に近づくと、安全横方向距離閾値および安全前後方向距離閾値の両方が違反される時点（ｔ１）になり、これは時刻ｔ２の衝突イベントまで持続する安全距離ルールの不合格をもたらす。
【0200】
図１０Ｃは、割り込みシナリオの第２のインスタンスを示している。第２のインスタンスでは、割り込みイベントは衝突をもたらさず、自車両６０２は割り込みイベントの後に他の車両６０４の後方の安全距離に到達することができる。
【0201】
図１０Ｄは、第２のシナリオ・インスタンスのグラウンド・トゥルース３１０ｂから得られる第２のオラクル出力２５６ｂの例を示している。この場合、全体を通して「衝突なし」ルールに合格する。自車両６０２と他車両６０４との間の横方向距離が安全でなくなる時刻ｔ３で、安全距離ルールが違反される。しかしながら、時刻ｔ４において、自車両６０２は、他の車両６０４の後方の安全距離になんとか到達する。したがって、安全距離ルールは時刻ｔ３および時刻ｔ４の間でのみ不合格になる。
【0202】
認識エラー・フレームワーク
上述されたように、認識エラーおよび運転ルールの両方は、グラウンド・トゥルーシング・パイプライン１４４によって決定された抽出された擬似グラウンド・トゥルース１４４に基づいて査定され、ＧＵＩ５００に提示されることができる。
上述されたように、認識エラーおよび運転ルールの両方は、グラウンド・トゥルーシング・パイプライン１４４によって決定された抽出された擬似グラウンド・トゥルース１４４に基づいて査定され、ＧＵＩ５００に提示されることができる。
【0203】
図１１は、認識エラーを評価するためのアーキテクチャを示している。認識オラクル１１０８を備えるトリアージ・ツール１５２は、現実の運転シナリオおよびシミュレートされた運転シナリオの両方について認識エラーを抽出および評価するために使用され、テスト・オラクル２５２からの結果と並んでＧＵＩ５００にレンダリングされる結果を出力する。トリアージ・ツール１５２は、本明細書では認識トリアージ・ツールと呼ばれるが、自律車両スタックのテストおよび改善に有用な、認識データおよび運転パフォーマンス・データを含む運転データを抽出してユーザに提示するためにより一般的に使用されてもよいことに留意されたい。
【0204】
運転走行からの現実のセンサ・データ１４０について、オンライン認識スタック１０２の出力がトリアージ・ツール１５２に渡され、グラウンド・トゥルーシング・パイプライン４００を介して現実のセンサ・データ１４０とオンライン認識出力との両方を実行することによって得られる抽出されたグラウンド・トゥルース１４４に基づいて、数値的な「現実世界」の認識エラー１１０２が決定される。
【0205】
同様に、センサ・データがゼロからシミュレートされ、シミュレートされたセンサ・データに認識スタックが適用されるシミュレートされた運転走行の場合、トリアージ・ツール１５２によって、認識スタックからの検出結果とシミュレーション・グラウンド・トゥルースとの比較に基づいて、シミュレートされた認識エラー１１０４が計算される。しかしながら、シミュレーションの場合、グラウンド・トゥルースは、シミュレータ２０２から直接取得されることができる。
【0206】
シミュレータ２０２が認識スタックの出力をシミュレートするために認識エラーを直接モデル化する場合、シミュレートされた検出結果とシミュレーション・グラウンド・トゥルースとの差、すなわち、シミュレートされた認識エラー１１１０は既知であり、これが認識オラクル１１０８に直接渡される。
【0207】
認識オラクル１１０８は認識ルール定義１１０６のセットを受け取り、これは、後でより詳細に説明されるように、ユーザ・インターフェースを介して定義されてもよく、またはドメイン固有言語で記述されてもよい。認識ルール定義１１０６は、認識エラーおよびその限界を定義する閾値またはルールを適用してもよい。認識オラクルは、運転シナリオに関して得られた現実の認識エラーまたはシミュレートされた認識エラーに定義されたルールを適用し、認識エラーが定義されたルールを破った箇所を特定する。これらの結果はレンダリング・コンポーネント１１２０に渡され、レンダリング・コンポーネント１１２０は、評価された認識ルールの視覚的インジケータをグラフィカル・ユーザ・インターフェース５００への表示のためにレンダリングする。明瞭にするために、テスト・オラクルへの入力は図１１には示されていないが、テスト・オラクル２５２も、グラウンド・トゥルーシング・パイプライン４００またはシミュレータ２０２のいずれかから取得されたグラウンド・トゥルース・シナリオに依存することに留意されたい。
【0208】
次に、現実世界運転スタックの認識エラーを抽出されたグラウンド・トゥルースに照らして評価するためのフレームワークのさらなる詳細が説明される。上記で述べたように、認識エラーと、テスト・オラクル２５２による運転ルール分析との両方が、現実世界運転分析ツールに組み込まれることができ、これは以下でより詳細に説明される。
【0209】
全てのエラーが同じ重要性を有するわけではない。たとえば、自車から１０メートル離れたエージェントにおける１０ｃｍの並進誤差は、１００メートル離れたエージェントにおける同じ並進誤差よりもはるかに重要である。この課題に対する簡単な解決策は、自車両からの距離に基づいて誤差をスケールすることであろう。しかしながら、異なる認識エラーの相対的な重要性、または異なるエラーに対する自車の運転パフォーマンスの感度は、所与のスタックのユース・ケースに依存する。たとえば、直線道路を走行するためのクルーズ・コントロール・システムを設計する場合、これは並進誤差には敏感であるべきであるが、向き誤差には特に敏感である必要はない。しかしながら、環状交差点の入り口に対処するＡＶは、検出されたエージェントの向きを、エージェントが環状交差点から出ようとしているか否か、ひいては環状交差点に安全に進入できるか否かを示すものとして使用するので、向き誤差に対して非常に敏感であるべきである。したがって、異なる認識エラーに対するシステムの感度を各ユース・ケースに合わせて設定可能にすることが望ましい。
【0210】
認識エラーを定義するために、ドメイン固有言語が使用される。これを使用して、たとえば並進誤差の許容限界を定義することによって、認識ルール１４０２（図１４を参照）を作成することができる。このルールは、自車からの異なる距離に対する安全な誤差レベルの設定可能なセットを実装する。これはテーブル１４００内に定義されている。たとえば、車両が１０メートル未満だけ離れている場合、その位置の誤差（すなわち、車の検出結果と、精製された擬似グラウンド・トゥルース検出結果との間の距離）は、１０ｃｍ以下となるように定義されることができる。エージェントが１００メートル離れている場合、許容可能な誤差は最大５０ｃｍに定義されてもよい。ルックアップ・テーブルを使用して、任意の所与のユース・ケースに合わせてルールが定義されることができる。これらの原理に基づいて、より複雑なルールが構築されることができる。他のエージェントの誤差が、自車両に対するそれらの位置に基づいて完全に無視されるようなルールが定義されてもよく、たとえば、自車道が分離帯によって対向交通から分離されている場合の、対向車線にいるエージェントなどである。定義されたカットオフ距離を超える自車の背後の交通も、ルール定義に基づいて無視されてもよい。
【0211】
そして、適用される全てのルールを含む認識エラー仕様１６００を定義することによって、所与の運転シナリオにルールのセットがまとめて適用されることができる。仕様１６００に含まれることができる典型的な認識ルールは、前後方向および横方向の並進誤差（それぞれ前後方向および横方向におけるグラウンド・トゥルースに対する検出結果の平均誤差を測定する）、向き誤差（対応するグラウンド・トゥルースと一致させるために検出結果を回転させる必要がある最小角度を定義する）、サイズ誤差（検出されたバウンディング・ボックスの各次元の誤差、または体積差分を取得するための位置合わせされたグラウンド・トゥルースおよび検出されたボックスの積集合／和集合の比率（ｉｎｔｅｒｓｅｃｔｉｏｎ ｏｖｅｒ ｕｎｉｏｎ））に関する閾値を定義する。さらなるルールは車両のダイナミクスに基づいてもよく、これは、エージェントの速度および加速度の誤差、および分類のエラー、たとえば、車を歩行者またはトラックとして誤って分類した場合のペナルティ値を定義するものなどを含む。ルールは、誤検出または検出漏れ、ならびに検出遅延も含んでもよい。
【0212】
定義された認識ルールに基づいて、ロバスト性スコアを構築することができる。効果的にこれを使用して、検出結果がルールの指定閾値内にある場合、システムは安全に走行することができるはずであり、そうでない場合（たとえば、ノイズが多すぎる場合）、自車両が対処できない場合がある悪いことが起こる可能性があると言うことができ、これは正式にキャプチャされる必要がある。たとえば、時間経過に伴う検出結果を評価するために、また、複雑な天候依存性を組み込むために、複雑なルールの組み合わせが含まれることができる。
【0213】
これらのルールを使用して、エラーをＵＩでのシナリオの再生に関連付けることができる。図１４に示されるように、異なる認識ルールがそのルールのタイムラインに、ＤＳＬでの所与のルール定義を適用したときの異なる結果に対応して、異なる色で表示される。これはＤＳＬの主なユース・ケース（すなわち、トリアージ・ツール用の視覚化）である。ユーザはＤＳＬでルールを記述し、ルールはＵＩのタイムラインに表示される。
【0214】
ＤＳＬは、定義されたルールに関して計算されたロバスト性スコアに基づいて、システムの認識スタックと計画スタックとの間の契約を定義するために使用されることもできる。図１５は、たとえば並進誤差などの所与の誤差定義に関するロバスト性スコアの例示的なグラフを示している。ロバスト性スコアが定義された閾値１５００を超えている場合、これは、認識エラーが期待されるパフォーマンス内にあり、システム全体が安全な運転を約束するはずであるということを示す。図１５に示されるようにロバスト性スコアが閾値より下がった場合、そのレベルの認識エラーではプランナ１０６が安全に走行することが期待できないので、エラーは「契約外」である。この契約は実質的に認識システムに対する要求仕様となる。これは、認識または計画のいずれかに責任を割り当てるために使用されることができる。車が不正な挙動をしているときにエラーが契約内であると識別された場合、これは認識の問題ではなくプランナの課題を指摘しており、逆に、認識が契約外である場合の悪い挙動については、認識エラーが原因である。
【0215】
認識エラーが契約内とみなされるか契約外とみなされるかのアノテーションを付けることによって、契約情報がＵＩ５００に表示されることができる。これは、ＤＳＬから契約仕様を取得し、フロント・エンドで契約外エラーに自動的にフラグを立てるメカニズムを使用する。
【0216】
図１６は、異なるモダリティ（すなわち、現実世界およびシミュレーション）にわたって認識エラーを統合する第３のユース・ケースを示している。上記の説明は、現実の車が走行してデータを収集する現実世界の運転に関連し、オフラインで精製技術およびトリアージ・ツール１５２が認識エラーを計算し、これらのエラーが契約内か契約外かを計算する。しかしながら、エラーを評価するための認識エラー・ルールを指定する同じ認識エラー仕様１６００が、シミュレートされた運転走行に適用されることができる。シミュレーションは、図１１を参照して前述されたように、認識スタックによって処理されるシミュレートされたセンサ・データを生成するものであるか、または認識エラー・モデルを使用してグラウンド・トゥルースから検出結果を直接シミュレートすることによるものとすることができる。
【0217】
１つ目のケースでは、シミュレートされたセンサ・データ１１１２に基づく検出結果はエラー１１０４を有し、これらのエラーが契約内か契約外かを定義するためにＤＳＬが使用されることができる。これは認識エラー・モデル２０８に基づくシミュレーションによって行われることもでき（すなわち、オブジェクト・リストにノイズを加える）、注入されたエラー１１１０を計算および検証して、モデル化されることが期待されるものをシミュレータ２０２がモデル化しているかをチェックすることが可能である。これを使用して、契約外のエラーを注入するのではなく、契約内のエラーを意図的に注入することによって、純粋に認識エラーが原因でスタックが不合格になることを回避することもできる。１つのユース・ケースでは、契約内ではあるが契約の端に近いエラーがシミュレーションで注入されてもよく、期待される認識パフォーマンスが与えられた場合に、計画システムが正しく動作することが検証されることができる。これは認識および計画の開発を切り離し、その理由は、これらがこの契約に照らして個別にテストされることができるためであり、認識が契約を満たし、プランナが契約の限度内で機能すると、これらのシステムは満足のいく水準まで連携するはずである。
【0218】
認識モデルがどこでスライスされるかに応じて、たとえば融合を行う場合に、シミュレータから何が出てくるかについてほとんど知らない場合があるので、それを契約内エラーおよび契約外エラーに関して評価することは、シミュレートされたシナリオを分析するのに有用である。
【0219】
ＤＳＬの他の用途は、擬似グラウンド・トゥルース１４４自体の精度を査定することである。完璧でない検出結果を精製して完璧なグラウンド・トゥルースを取得することは不可能であるが、精製パイプラインが信頼性高く使用されるために到達する必要がある許容可能な精度はおそらく存在する。ＤＳＬルールを使用して、現時点での擬似グラウンド・トゥルースを査定し、現在「真の」ＧＴにどの程度近いか、および将来的にどの程度近づく必要があるかを決定することができる。これは、擬似グラウンド・トゥルースに照らして計算されるオンラインの認識エラーをチェックするために使用されるのと同じ契約を行ってもよいが、精度に関してより厳しい限度を適用して、オンライン検出結果が査定されるのに十分なほど擬似グラウンド・トゥルースが「正しい」という十分な自信があるようにしてもよい。擬似グラウンド・トゥルースの許容可能な精度は、「真の」グラウンド・トゥルースに照らして測定された場合の契約内のエラーとして定義されることができる。特定の閾値内に限り、精製後でも多少のエラーを生成することが許容される。異なるシステムが異なるユース・ケースを有する場合、各システムは異なるＤＳＬルール・セットを適用する。
【0220】
精製された検出結果が査定される「真の」グラウンド・トゥルースは、現実世界のデータセットを選択し、これに手動でアノテーション付けし、定義されたＤＳＬルールに従って擬似ＧＴをこの手動ＧＴに照らして評価し、許容可能な精度が達成されているか否かを判定することによって取得される。精製パイプラインが更新されるたびに、精製された検出結果の精度査定を再実行して、パイプラインが退行していないかをチェックすることができる。
【0221】
ＤＳＬの他の用途は、認識１０２と計画１０６との間で契約が定義されると、認識レイヤで行われる必要があるテストのタイプを分割することが可能になることである。これは図１７に示されている。たとえば、認識レイヤは、契約内でなければならないエラーを全てが含むセンサ読み取り値のセットが供給されることができ、それが事実であるか否かをチェックするためにＤＳＬルールが適用されることができる。計画レイヤについても同様に、最初にグラウンド・トゥルース・テスト１７０２が適用されることができ、それに合格した場合は契約内テスト１７０４が適用され、そのため、システムは、契約内エラーを有するオブジェクト・リストが供給され、プランナが安全に挙動するか否かを確認する。
【0222】
１つの例示的なテスト・スキームでは、プランナは「所与のもの」とみなされてもよく、シミュレーションを使用して認識エラーを生成し、プランナが意図通りに動作するために許容可能な認識精度の限界を探してもよい。次いで、これらの限界を使用して、認識システムの契約を半自動的に作成することができる。認識システムのセットをこの契約に照らしてテストして、これを満たすものを探してもよく、または契約は認識システムを開発する際のガイドとして使用されてもよい。
【0223】
現実世界運転分析ツール
上述のテスト・フレームワーク、すなわち、テスト・オラクル２５２および認識トリアージ・ツール１５２は、現実世界運転分析ツールにおいて組み合わせられてもよく、このツールでは、図２Ｃに示されるように、グラウンド・トゥルース・パイプライン４００から抽出された認識グラウンド・トゥルースに認識評価および運転評価の両方が適用される。
上述のテスト・フレームワーク、すなわち、テスト・オラクル２５２および認識トリアージ・ツール１５２は、現実世界運転分析ツールにおいて組み合わせられてもよく、このツールでは、図２Ｃに示されるように、グラウンド・トゥルース・パイプライン４００から抽出された認識グラウンド・トゥルースに認識評価および運転評価の両方が適用される。
【0224】
図１２Ａは、現実世界データから抽出された運転シナリオを分析するための例示的なユーザ・インターフェースを示している。図１２Ａの例では、点群データ（たとえば、ライダー、レーダー、またはステレオもしくはモノラル深度イメージングから導出されるもの）に基づいてシーンの俯瞰の概略表現１２０４が示されており、対応するカメラ・フレーム１２２４が差し込み図に示されている。道路レイアウト情報は高精細地図データから取得されてもよい。カメラ・フレーム１２２４は、検出結果のアノテーションが付けられてもよい。ＵＩは、たとえば、ライダー、レーダー、またはカメラ・データなど、運転中に収集されたセンサ・データも示してもよい。これは図１２Ｂに示されている。シーン視覚化１２０４はまた、導出された擬似グラウンド・トゥルースならびに車載認識コンポーネントからの検出結果に基づくアノテーションが重ねられる。図示された例では、３台の車両が存在し、それぞれにボックスでアノテーションが付けられている。実線のボックス１２２０は、シーンのエージェントの擬似グラウンド・トゥルースを示しており、輪郭１２２２は、自車の認識スタック１０２からの未精製の検出結果を示している。視覚化メニュー１２１８が示されており、その中で、ユーザはセンサ・データ、オンラインおよびオフライン検出結果のいずれを表示するかを選択することができる。これらは必要に応じてオンおよびオフが切り替えられてもよい。現実のセンサ・データを車両の検出結果およびグラウンド・トゥルース検出結果の両方と並べて示すことは、ユーザが車両の検出結果における特定のエラーを識別または確認することを可能にする。ＵＩ５００は選択された映像の再生を可能にし、タイムライン・ビューが示され、ユーザは映像内の任意の時点１２１６を選択して、選択された時点に対応する鳥瞰図のスナップショットおよびカメラ・フレームを示すことができる。
【0225】
上述されたように、検出結果を精製された擬似グラウンド・トゥルース１４４と比較することによって、認識スタック１０２が査定されることができる。特定のＡＶスタックのユース・ケースに依存することができる定義された認識ルール１１０６に照らして認識が査定される。これらのルールは、車の検出結果の位置、向き、またはスケールと、擬似グラウンド・トゥルース検出結果のそれらとの間の不一致に対して、異なる値の範囲を指定する。ルールはドメイン固有言語で定義されることができる（図１４を参照して上述）。図１２Ａに示されるように、認識ルールの結果を集約した、運転シナリオの「最上位」の認識タイムライン１２０６に沿って異なる認識ルール結果が示されており、いずれかの認識ルールが破られたときにタイムライン上の期間にフラグが立てられる。これを展開して、定義されたルールごとの個々の認識ルール・タイムライン１２１０のセットを呈示することができる。
【0226】
認識エラー・タイムラインは、運転走行のより長い期間を呈示するために「ズーム・アウト」されてもよい。ズーム・アウトされたビューでは、ズーム・インされたときと同じ粒度で認識エラーを表示することができない場合がある。この場合、タイムラインは、時間ウィンドウにわたる認識エラーの集約を表示して、ズーム・アウトされたビューのためにまとめられた認識エラーのセットを提供してもよい。
【0227】
第２の運転査定タイムライン１２０８は、擬似グラウンド・トゥルース・データが運転ルールに照らしてどのように査定されたかを示す。集約された運転ルールは最上位のタイムライン１２０８に表示され、これは、定義された各運転ルールに照らしたパフォーマンスを表示する個々のタイムライン１２１２のセットに展開されることができる。各ルール・タイムラインは、図示されたようにさらに展開されて、所与のルールに関する時間経過に伴う数値パフォーマンス・スコアのプロット１２２８を表示することができる。これは、図９Ｃを参照して前述された選択可能な要素５３４ｂに対応する。この場合、擬似グラウンド・トゥルース検出結果は、シーンにおけるエージェントの実際の運転挙動とみなされる。車が所与のシナリオに関して安全に挙動したか否かを確認するために、自車の挙動は定義された運転ルールに照らして、たとえばデジタル・ハイウェイ・コードに基づいて、評価されることができる。
【0228】
まとめると、認識ルール評価および運転査定は両方とも、現実世界の運転からの検出結果を精製するために上述のオフライン認識方法を使用することに基づいている。運転査定の場合、精製された擬似グラウンド・トゥルース１４４を使用して、自車の挙動を運転ルールに照らして査定する。図２Ｃに示されるように、これを使用して、テスト用のシミュレートされたシナリオを生成することもできる。認識ルール評価の場合、認識トリアージ・ツール１５２は、記録された車両検出結果とオフラインの精製された検出結果とを比較して、可能性のある認識失敗を迅速に識別してトリアージする。
【0229】
また、ドライブ・ノートがドライブ・ノート・タイムライン・ビュー１２１４に表示されてもよく、その中に、運転中にフラグが立てられた注目すべきイベントが表示されてもよい。たとえば、ドライブ・ノートは、車両がブレーキをかけたもしくは方向転換した時点、または人間のドライバーがＡＶスタックを解除したときを含む。
【0230】
ユーザが潜在的な課題をデバッグおよびトリアージするのに役立つユーザ定義のメトリックが呈示される追加のタイムラインが表示されてもよい。ユーザ定義のメトリックは、エラーまたはスタックの欠陥を識別するとともに、エラーが発生したときにエラーをトリアージするために定義されてもよい。ユーザは、所与のＡＶスタックの目標に応じてカスタム・メトリックを定義してもよい。例示的なユーザ定義メトリックは、メッセージが順序通りに到着しないとき、または認識メッセージのメッセージ遅延にフラグを立ててもよい。これは、プランナの間違いによって計画が行われたのか、メッセージが遅れてまたは順番通りでなく到着したために計画が行われたのかを判定するために使用されてもよいので、トリアージに有用である。
【0231】
図１２Ｂは、センサ・データが表示され、カメラ・フレーム１２２４が差し込み図に表示されたＵＩ視覚化１２０４の例を示している。典型的には、時間的な単一のスナップショットからのセンサ・データが呈示される。しかしながら、高解像度の地図データが利用可能でない場合に、静的なシーン地図を取得するために、複数の時間ステップにわたって集約されたセンサ・データを各フレームが呈示してもよい。左側に示されるように、現実のシナリオ中に収集されたカメラ、レーダーもしくはライダー・データ、または自車両自体の認識からのオンライン検出結果などのデータを表示または非表示にするためのいくつかの視覚化オプション１２１８がある。この例では、車両からのオンライン検出結果は、グラウンド・トゥルースの精製された検出結果を表す実線のボックス１２２０の上に重ねられた輪郭１２２２として示されている。グラウンド・トゥルースと車両の検出結果との間には向き誤差が見られる。
【0232】
グラウンド・トゥルーシング・パイプライン４００によって実施される精製プロセスは、複数のツールの基礎として擬似グラウンド・トゥルース１４４を生成するために使用される。呈示されたＵＩは、認識トリアージ・ツール１５２からの結果を表示し、これは、テスト・オラクル２５２を使用して単一の運転例でのＡＤＡＳの運転能力を査定すること、欠陥を検出すること、課題を再現するシナリオを抽出すること（図２Ｃを参照）、および識別された課題を開発者に送信してスタックを改善することを可能にする。
【0233】
図１２Ｃは、ユーザがシナリオのサブセクションにズーム・インすることを可能にするように構成される例示的なユーザ・インターフェースを示している。図１２Ｃは、図１２Ａに関して上述されたように、概略表現１２０４ならびに差し込み図で呈示されたカメラ・フレーム１２２４を含む、シナリオのスナップショットを示している。上述された、認識エラー・タイムライン１２０６、１２１０のセット、ならびに展開可能な運転査定タイムライン１２０８およびドライブ・ノート・タイムライン１２１４も図１２Ｃに示されている。
【0234】
図１２Ｃに示された例では、運転シナリオの現在のスナップショットが、全てのタイムライン・ビューに同時にまたがるスクラバー・バー１２３０によって示されている。これは、単一の再生バー上のシナリオ内の現在点の指示１２１６の代わりに使用されてもよい。ユーザはスクラバー・バー１２３０をクリックしてバーを選択し、運転シナリオの任意の時点まで移動させることができる。たとえば、ユーザは、赤に着色された、または別の方法により位置誤差タイムライン上で誤差を含むセクションとして指示されたセクション内の点などの特定のエラーに関心がある場合があり、その指示は、指示されたセクションに対応する期間における「グラウンド・トゥルース」および検出結果の間でその時点に観察された位置誤差に基づいて決定される。ユーザはスクラバー・バーをクリックし、位置誤差タイムライン内の関心のある点までバーをドラッグすることができる。代替的には、ユーザは、スクラバーがまたがるいずれかのタイムライン上の点をクリックして、その点にスクラバーを置くことができる。これは概略ビュー１２０４および差し込み図１２２４を更新して、選択された時点に対応するトップ・ダウンの概略ビューおよびカメラ・フレームをそれぞれ呈示する。次いで、ユーザは、概略ビューおよび利用可能なカメラ・データまたは他のセンサ・データを検査して、位置誤差を確認し、認識エラーの考えられる理由を特定することができる。
【0235】
「ルーラー」バー１２３２は、認識タイムライン１２０６の上かつ概略ビューの下に呈示される。これは、運転シナリオの時間間隔を示す一連の「ノッチ」を含む。たとえば、タイムライン・ビューに１０秒の時間区間が表示される場合、１秒の間隔を示すノッチが呈示される。いくつかの時点には、たとえば、「０秒」、「１０秒」などの数値インジケータもラベル付けされる。
【0236】
ズーム・スライダー１２３４が、ユーザ・インターフェースの下部に提供される。ユーザは、インジケータをズーム・スライダーに沿ってドラッグして、タイムラインに呈示される運転シナリオの部分を変更することができる。代替的には、インジケータの移動先となるスライダー・バー上の所望の点をクリックすることにより、インジケータの位置が調整されてもよい。現在選択されているズームのレベルを示すパーセンテージが呈示される。たとえば、運転シナリオ全体の長さが１分の場合、タイムライン１２０６、１２０８、１２１４は、１分間の運転にわたる認識エラー、運転査定、およびドライブ・ノートをそれぞれ呈示し、ズーム・スライダーは１００％を示し、ボタンは一番左の位置にある。ズーム・スライダーが２００％を示すまでユーザがボタンをスライドすると、シナリオの３０秒のスニペットに対応する結果のみを呈示するようにタイムラインが調整される。
【0237】
ズームは、スクラバー・バーの位置に応じてタイムラインの表示部分を調整するように構成されてもよい。たとえば、１分間のシナリオでズームが２００％に設定されている場合、ズーム・インされたタイムラインは、スクラバーが位置する選択された時点が中心となる３０秒のスニペットを呈示し、すなわち、スクラバーによって示された点の前後に１５秒のタイムラインが呈示される。代替的には、シナリオの開始点などの基準点を基準にしてズームが適用されてもよい。この場合、ズーム後にタイムラインに呈示されるズーム・インされたスニペットは、常にシナリオの開始点から始まる。ルーラー・バー１２３２のノッチおよび数値ラベルの粒度は、タイムラインがズーム・インまたはズーム・アウトされる度合いに応じて調整されてもよい。たとえば、シナリオが３０秒からズーム・インされて３秒のスニペットを呈示する場合、ズーム前は数値ラベルが１０秒間隔で表示され、ノッチが１秒間隔で表示されてもよく、ズーム後は数値ラベルが１秒間隔で表示され、ノッチが１００ｍｓ間隔で表示されてもよい。タイムライン１２０６、１２０８、１２１４の時間ステップの視覚化は、ズーム・インされたスニペットに対応するように「引き伸ばされる」。ズーム・インされたビューのタイムラインにより高いレベルの詳細が表示されてもよく、その理由は、時間的により短いスニペットが、ＵＩ内のタイムラインの表示においてより大きなエリアによって表現可能であるためである。したがって、より長いシナリオ内の非常に短い時間にわたるエラーは、ズーム・インされた場合にのみタイムライン・ビューで可視にされてもよい。
【0238】
他のズーム入力を使用して、シナリオのより短いまたは長いスニペットを表示するようにタイムラインを調整してもよい。たとえば、ユーザ・インターフェースがタッチ・スクリーン・デバイス上で実装される場合、ユーザはピンチ・ジェスチャを適用してタイムラインにズームを適用してもよい。他の例では、ユーザはマウスのスクロール・ホイールを前後にスクロールしてズーム・レベルを変更してもよい。
【0239】
運転シナリオのサブセットのみを呈示するためにタイムラインがズーム・インされている場合、タイムラインを時間的にスクロールして表示部分を時間的にシフトすることができるので、ユーザによってタイムライン・ビューでシナリオの様々な部分が検査されることができる。ユーザは、タイムライン・ビューの下部にあるスクロール・バー（図示せず）をクリックしてドラッグするか、またはたとえばＵＩが動作している関連デバイスのタッチ・パッドを使用して、スクロールすることができる。
【0240】
ユーザは、たとえば、さらなる分析のために、またはシミュレーションの基礎としてエクスポートされる、シナリオのスニペットを選択することもできる。図１２Ｄは、運転シナリオのセクションがユーザによってどのように選択されることができるかを示している。ユーザは、ルーラー・バー１２３２上の関連する点をカーソルでクリックすることができる。これは任意のズーム・レベルで行われることができる。これは、ユーザ選択範囲の最初の境界を設定する。ユーザはタイムラインに沿ってカーソルをドラッグして、選ばれた時点まで選択範囲を拡張する。ズーム・インされている場合、シナリオの表示されているスニペットの最後までドラッグし続けることにより、これはタイムラインを前方にスクロールし、選択範囲がさらに拡張されることを可能にする。ユーザは任意の点でドラッグを停止することができ、ユーザが停止した点が、ユーザ選択範囲の終了境界になる。ユーザ・インターフェースの下部にあるバー１２３０は、選択されたスニペットの時間的な長さを表示し、この値は、ユーザがカーソルをドラッグして選択範囲を拡張または縮小すると更新される。選択されたスニペット１２３８は、ルーラー・バー上の影付きセクションとして呈示される。選択範囲に対応するデータを抽出するための「軌跡シナリオを抽出する」などのユーザ・アクションを提供するいくつかのボタン１２３６が呈示されている。これは、抽出されたシナリオのデータベースに記憶されてもよい。これは、さらなる分析のために、または同様のシナリオをシミュレートするための基礎として、使用されてもよい。選択を行った後、ユーザはズーム・インまたはズーム・アウトすることができ、ルーラー・バー１２３２上の選択範囲１２３８も、ルーラーならびに認識、運転査定、およびドライブ・ノートのタイムラインと共に伸縮する。
【0241】
擬似グラウンド・トゥルース・データは、データベース内のデータを検索するためのデータ探索ツールと共に使用されることもできる。このツールは、新しいバージョンのＡＶスタックが配備されるときに使用されることができる。新しいバージョンのソフトウェアの場合、データを収集するために、車が一定期間（たとえば、１週間）運転されることができる。このデータ内で、ユーザは特定の条件で車がどのように挙動するかをテストすることに関心がある場合があるので、たとえば、「夜間の運転を見せて」、または「雨が降っていたときを見せて」などのクエリを提供してもよい。データ探索ツールは関連する映像を引き出し、その後、トリアージ・ツールを使用して調査することができる。このデータ探索ツールは、さらなる分析のための一種のエントリ・ポイントとして機能する。
【0242】
たとえば、新しいソフトウェア・バージョンが実装され、ＡＶがしばらく運転されて一定量のデータを収集すると、データを集約して、車の総合的なパフォーマンスを把握するためのさらなる査定ツールが使用されてもよい。この車は、インジケータの使用および環状交差点への出入りなど、新しく開発された機能のセットを有し、これらの機能に関して車がどれほど適切に挙動するかについての総合的なパフォーマンス評価を求めてもよい。
【0243】
最後に、再シミュレーション・ツールを使用して、センサ・データを新しいスタックで実行して開ループ・シミュレーションを実行することにより、退行の課題をチェックすることができる。
【0244】
図１３は、シナリオ視覚化１２０４および認識エラー・タイムライン１２０６、１２１０に焦点が当てられた、認識トリアージ・ツール１５２の例示的なユーザ・インターフェースを示している。左側に示されるように、現実のシナリオ中に収集されたカメラ、レーダーもしくはライダー・データ、または自車両自体の認識からのオンライン検出結果などのデータを表示または非表示にするためのいくつかの視覚化オプション１２１８がある。この場合、視覚化は精製された検出結果のみ、すなわち、オフラインで検出され、精製結果が実線のボックスで示されたエージェントのみに限定されている。実線の各ボックスは、その時間的なスナップショットにおいて誤差補正／精製の前にエージェントがどのように認識されたかを示す、関連するオンライン検出結果（図示せず）を有する。上述されたように、グラウンド・トゥルース１４４と元の検出結果との間には、特定の量の誤差が存在する。シーン内のエージェントのスケール、位置、および向きの誤差、ならびに誤検出による「ゴースト」検出および検出漏れを含む、様々なエラーが定義されることができる。
【0245】
上述されたように、全てのエラーが同じ重要性を有するわけではない。認識ルールのＤＳＬは、求められるユース・ケースに応じたルールの定義を可能にする。たとえば、直線道路を走行するためのクルーズ・コントロール・システムを設計する場合、これは並進誤差には敏感であるべきであるが、向き誤差には特に敏感である必要はない。しかしながら、環状交差点の入り口に対処するＡＶは、検出されたエージェントの向きを、エージェントが環状交差点から出ようとしているか否か、ひいては環状交差点に安全に進入できるか否かを示すものとして使用するので、向き誤差に対して非常に敏感であるべきである。認識エラー・フレームワークは、そのユース・ケースでの所与の並進誤差または向き誤差の相対的な重要性を示す別個のテーブルおよびルールが定義されることを可能にする。図１３の自車両の周囲に示されたボックスは、例示の目的で、認識ルールがターゲットにするように定義されてもよい関心対象のエリアを示すものである。ルール評価結果は、ユーザ・インターフェースの認識エラー・タイムライン１２１０内に表示されてもよい。たとえば特定のルールが定義されているエリアにフラグを立てることによって、ルールの視覚的インジケータが概略表現１２０４内に表示されてもよく、これは図１３には示されていない。
【0246】
運転走行の単一のスナップショットの結果を表示するだけでなく、クエリおよびフィルタリングを適用して、認識評価結果に従ってデータをフィルタリングし、分析を実行するユーザにさらに多くのコンテキストを提供することもできる。
【0247】
図１８Ａおよび図１８Ｂは、現実の運転走行の認識結果をフィルタリングして表示するためのグラフィカル・ユーザ・インターフェース５００の例を示している。所与の走行について、前述されたように、全ての認識エラーに対して集約されたルール評価を有する認識エラー・タイムライン１２０６が表示される。気象条件、道路の特徴、他の車両、および交通弱者などの運転シーンの特徴を示す第２のタイムラインのセット１２２６が呈示されてもよい。これらは、認識エラー・ルールを定義するために使用されるのと同じフレームワーク内で定義されてもよい。異なる運転条件に応じて異なる閾値が適用されるように認識ルールが定義されてもよいことに留意されたい。図１８Ａは、ユーザが評価に適用されるクエリを選択することができるフィルタリング機能１８００も示している。この例では、ユーザ・クエリは、交通弱者（ＶＲＵ：ｖｕｌｎｅｒａｂｌｅ ｒｏａｄ ｕｓｅｒ）が存在する運転走行の「スライス」を探すことである。
【0248】
このクエリは処理され、運転シナリオ表現のフレームを、交通弱者がタグ付けされたフレームへとフィルタリングするために使用される。図１８Ｂは、フィルタが適用された後の認識タイムラインの更新されたビューを示す。図に示されるように、元のタイムラインのサブセットが呈示されており、「ＶＲＵ」タイムラインに示されているように、このサブセットでは、交通弱者が常に存在する。
【0249】
図１９Ａは、グラフィカル・ユーザ・インターフェース５００内で分析を実行するために使用されてもよい他の機能を示している。ユーザが調整することができるエラー閾値スライダーのセット１９００が示されている。エラーの範囲は、認識ルールのＤＳＬで定義された認識エラー限界によって知らされてもよい。ユーザは所与のエラーの閾値を、そのエラーの所望の新しい閾値までマーカーをスライドさせることによって、調整してもよい。たとえば、ユーザは、３１ｍの並進誤差の不合格閾値を設定してもよい。次いで、この閾値は、前述の認識ルールＤＳＬに記述された認識ルール仕様内で定義された並進誤差にフィードバックされて、新しい閾値を考慮に入れるようにルール定義を調整することができる。新しいルール評価結果はフロント・エンドに渡され、新しい閾値に関して現在発生しているルールの不合格が、所与のエラーの展開されたタイムライン・ビュー１２１０に示される。図１９Ａに示されるように、許容不可能なエラー値の閾値を下げることは、タイムラインでより多くのエラーにフラグが立てられることを引き起こす。
【0250】
図１９Ｂは、運転シナリオの選択されたスライスに集約的な分析を適用して、ユーザが計算された認識エラーに基づいて最も関連性の高いフレームを選択して検査することを可能にする方法を示している。前述されたように、ユーザは、フィルタリング機能１８００を使用して、交通弱者が存在するフレームのみを呈示するようにシナリオをフィルタリングすることができる。一致するフレーム内で、ユーザは選択ツール１９０２を使用して、シナリオを特定のスニペットにさらに「スライス」することができ、選択ツール１９０２は、タイムライン１２０６に沿ってドラッグされ、関心のある期間をカバーするように拡大されることができる。選択されたスニペットについて、集約データが表示１９０４内にユーザに表示されてもよい。選択されたスニペット内でキャプチャされた認識エラーの様々な属性が選択され、互いに対照してグラフ化されてもよい。図示された例では、エラーのタイプおよびエラーの大きさがグラフ化されており、ユーザはシナリオの選択された部分について各タイプの最も重大なエラーを視覚化することが可能になる。ユーザはグラフ上の任意の点を選択して、そのエラーが発生した対応するフレームのカメラ画像１９０６をオクルージョンなどのシーンの他の変数と共に表示してもよく、ユーザはエラーを引き起こした可能性がある要因についてフレームを検査することができる。
【0251】
グラウンド・トゥルーシング・パイプライン４００は、認識トリアージ・ツール１５２およびテスト・オラクル２５２、ならびに、上記のデータ探索および集約査定ツールを含む、車両のパフォーマンスのクエリ、集約、および分析を行うためのさらなるツールと共に使用されてもよい。グラフィカル・ユーザ・インターフェース５００は、上述のスナップショット・ビューに加えて、これらのツールからの結果を表示してもよい。
【0252】
上記の例はＡＶスタックのテストを考えているが、本技術は他の形態の移動ロボットのコンポーネントをテストするために適用されることができる。たとえば、内外の工業地帯で貨物を運ぶための他の移動ロボットが開発されている。そのような移動ロボットは人が乗っておらず、ＵＡＶ（無人自律車両：ｕｎｍａｎｎｅｄ ａｕｔｏｎｏｍｏｕｓ ｖｅｈｉｃｌｅ）と呼ばれる移動ロボットのクラスに属する。自律型の空中移動ロボット（ドローン）も開発されている。
【0253】
本明細書におけるコンポーネント、機能、モジュールなどへの言及は、様々な方法によってハードウェア・レベルで実装されることができるコンピュータ・システムの機能コンポーネントを指す。コンピュータ・システムは、本明細書で開示された方法／アルゴリズム・ステップを実行するように、および／または本技術を使用してトレーニングされたモデルを実装するように構成されてもよい実行ハードウェアを備える。実行ハードウェアという用語は、関連する方法／アルゴリズム・ステップを実行するように構成されるハードウェアのあらゆる形態／組み合わせを包含する。実行ハードウェアは、プログラマブルまたは非プログラマブルであってもよい１つまたは複数のプロセッサの形態を取ってもよく、あるいはプログラマブル・ハードウェアと非プログラマブル・ハードウェアとの組み合わせが使用されてもよい。適切なプログラマブル・プロセッサの例は、ＣＰＵ、ＧＰＵ／アクセラレータ・プロセッサなどの命令セット・アーキテクチャに基づく汎用プロセッサを含む。そのような汎用プロセッサは、典型的には、プロセッサに結合されたまたは内蔵するメモリに保持されたコンピュータ可読命令を実行し、それらの命令に従って関連するステップを実施する。他の形態のプログラマブル・プロセッサは、回路記述コードを通じてプログラム可能な回路構成を有するフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）を含む。非プログラマブル・プロセッサの例は、特定用途向け集積回路（ＡＳＩＣ）を含む。コード、命令などは、必要に応じて一時的媒体または非一時的媒体（後者の例は、ソリッド・ステート、磁気および光学ストレージ・デバイスなどを含む）に記憶されてもよい。図２Ａの走行時スタックのサブシステム１０２～１０８は、プログラマブル・プロセッサもしくは専用プロセッサ、またはその両方の組み合わせで、車両に搭載されて、またはテストなどのコンテキストでは非車載コンピュータ・システムで実装されてもよい。シミュレータ２０２およびテスト・オラクル２５２などの、図１１および図６を含む図の様々なコンポーネントも同様に、プログラマブル・ハードウェアおよび／または専用ハードウェアで実装されてもよい。
【図1】
【図2A】
【図2B】
【図2C】
【図3】
【図4A】
【図4B】
【図5A】
【図5B】
【図6A】
【図6B】
【図7A】
【図7B】
【図8A】
【図8B】
【図8C】
【図9A】
【図9B】
【図9C】
【図9D】
【図10A】
【図10B】
【図10C】
【図10D】
【図11】
【図12A】
【図12B】
【図12C】
【図12D】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18A】
【図18B】
【図19A】
【図19B】
【手続補正書】
【提出日】2024-01-25
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
自律車両のパフォーマンスを査定するためのコンピュータ実装方法であって、少なくとも１回の自律運転走行のパフォーマンス・データを入力において受け取ることであって、前記パフォーマンス・データは、少なくとも１つの認識エラーの時系列と、少なくとも１つの運転パフォーマンス結果の時系列とを備える、前記受け取ることと、
グラフィカル・ユーザ・インターフェースをレンダリングするためのレンダリング・データをレンダリング・コンポーネントにおいて生成することであって、前記グラフィカル・ユーザ・インターフェースは、前記パフォーマンス・データを視覚化するためのものであり、
（ｉ）認識エラー・タイムライン、および
（ｉｉ）運転査定タイムライン、
を備える、前記生成することと、
を備え、
前記タイムラインは時間的に位置合わせされ、前記少なくとも１回の運転走行の複数の時間ステップに分割され、各時間ステップについて、前記認識エラー・タイムラインは、前記時間ステップにおいて認識エラーが発生したか否かの視覚的指示を備え、前記運転査定タイムラインは、前記時間ステップにおける運転パフォーマンスの視覚的指示を備える、
コンピュータ実装方法。
【請求項2】
前記認識エラー・タイムラインおよび前記運転査定タイムラインは相互に平行である、請求項１に記載の方法。
【請求項3】
前記運転パフォーマンスは、１つまたは複数の事前定義された運転ルールに関して査定される、請求項１に記載の方法。
【請求項4】
前記運転査定タイムラインは、複数の個々の運転ルールにわたって運転パフォーマンスを集約し、前記運転査定タイムラインは、前記個々の運転ルールのそれぞれの運転査定タイムラインを閲覧するために展開可能である、請求項３に記載の方法。
【請求項5】
前記運転査定タイムラインまたは各運転査定タイムラインは、前記運転ルールの計算グラフ表現を閲覧するために展開可能である、請求項３に記載の方法。
【請求項6】
前記運転走行は現実世界での走行であり、現実世界での軌跡に運転ルールが適用される、請求項３に記載の方法。
【請求項7】
グラウンド・トゥルーシング・パイプラインが、グラウンド・トゥルース認識出力を抽出するために使用され、前記グラウンド・トゥルース認識出力は、認識エラーを決定し、運転パフォーマンスを査定するために使用される、請求項１に記載の方法。
【請求項8】
前記グラウンド・トゥルーシング・パイプラインは自動化される、請求項７に記載の方法。
【請求項9】
グラウンド・トゥルース認識出力の使用なしで少なくとも一部の認識エラーが識別される、請求項１に記載の方法。
【請求項10】
前記認識エラーは、ちらつく検出結果、または
ジャンプする検出結果
のうちの少なくとも１つを備える、請求項９に記載の方法。
【請求項11】
前記パフォーマンス・データは、関心対象の認識エリアを示す少なくとも１つの数値的認識スコアの時系列を備え、前記グラフィカル・ユーザ・インターフェースは、少なくとも対応する数値的認識スコアのタイムラインを備え、各時間ステップについて、前記数値的認識スコア・タイムラインは、前記時間ステップに関連付けられた前記数値的認識スコアの視覚的指示を備える、請求項１に記載の方法。
【請求項12】
前記数値的認識スコアの時系列は、各時間ステップにおける前記認識システムにとっての難易度の尺度を示す困難性スコアの時系列である、請求項１１に記載の方法。
【請求項13】
前記パフォーマンス・データは、少なくとも１つのユーザ定義スコアの時系列を備え、前記グラフィカル・ユーザ・インターフェースは、少なくとも１つの対応するカスタム・タイムラインを備え、各時間ステップについて、前記カスタム・タイムラインは、前記時間ステップで評価された前記ユーザ定義スコアの視覚的指示を備える、請求項１に記載の方法。
【請求項14】
前記運転走行はシミュレートされた運転走行であり、前記認識エラーはシミュレートされた認識エラーを備える、請求項１に記載の方法。
【請求項15】
前記シミュレートされた認識エラーを提供し、グラウンド・トゥルース・シミュレータの状態を、前記スタックの上位レベルのコンポーネントに提供される現実的な認識出力に変換するために、１つまたは複数の認識エラー・モデルが使用される、請求項１４に記載の方法。
【請求項16】
前記シミュレートされた認識エラーは、合成センサ・データおよびシミュレーション・グラウンド・トゥルースに基づいて導出され、前記合成センサ・データは、シミュレーションで生成され、前記スタックの認識システムによって処理される、請求項１４に記載の方法。
【請求項17】
運転ルール、認識エラー、またはシーン・パラメータのうちの１つまたは複数に基づいて、フィルタも前記２つのタイムラインに適用される、請求項１に記載の方法。
【請求項18】
請求項１～１７のいずれかに記載の方法を実装するように構成される１つまたは複数のコンピュータを備える、コンピュータ・システム。
【請求項19】
請求項１～１７のいずれかに記載の方法を実装するようにコンピュータ・システムをプログラミングするための実行可能なプログラム命令を備える、コンピュータ・プログラム。
【国際調査報告】