知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-06-21
(54)【発明の名称】テスト視覚化ツール
(51)【国際特許分類】
G08G 1/00 20060101AFI20240614BHJP
【ＦＩ】
G08G1/00 D
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2023575617
(86)(22)【出願日】2022-06-08
(85)【翻訳文提出日】2024-01-30
(86)【国際出願番号】 EP2022065484
(87)【国際公開番号】W WO2022258657
(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
(31)【優先権主張番号】2204797.1
(32)【優先日】2022-04-01
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】521163628
【氏名又は名称】ファイブ、エーアイ、リミテッド
【氏名又は名称原語表記】ＦＩＶＥ ＡＩ ＬＩＭＩＴＥＤ
(74)【代理人】
【識別番号】100120031
【弁理士】
【氏名又は名称】宮嶋 学
(74)【代理人】
【識別番号】100107582
【弁理士】
【氏名又は名称】関根 毅
(74)【代理人】
【識別番号】100118843
【弁理士】
【氏名又は名称】赤岡 明
(74)【代理人】
【識別番号】100152205
【弁理士】
【氏名又は名称】吉田 昌司
(72)【発明者】
【氏名】イアン、ホワイトサイド
(72)【発明者】
【氏名】マルコ、フェーリ
(72)【発明者】
【氏名】ベン、グレーブズ
(72)【発明者】
【氏名】ジェイミー、クルックシャンク
【テーマコード（参考）】
5H181
【Ｆターム（参考）】
5H181AA01
5H181AA27
5H181BB20
5H181CC03
5H181CC04
5H181CC14
5H181FF04
5H181FF05
5H181FF10
5H181MB02
(57)【要約】
自エージェントが道路レイアウトを進行する運転シナリオの走行を視覚化するためのグラフィカル・ユーザ・インターフェースをレンダリングするためのコンピュータ・システムであって、道路レイアウトの地図と、走行データとを受け取るように構成される入力であって、走行データは、タイムスタンプ付きの自エージェント状態のシーケンスと、走行評価ルールのセットの各ルールに関する自エージェントのパフォーマンスを定量化した時間変化する数値スコアと、を備える、入力と、各ルールについて、時間変化する数値スコアのプロットと、プロットの選択された時間インデックスを示すマーカーであって、マーカーは、選択された時間インデックスを変更するために時間軸に沿って移動可能である、マーカーと、選択された時間インデックスにおける走行の視覚化を備えるシナリオ視覚化であって、マーカーを時間軸に沿って移動させることは、時間インデックスが変更されたときに、シナリオ視覚化を更新させる、シナリオ視覚化と、をグラフィカル・ユーザ・インターフェースに表示させるように構成されるレンダリング・コンポーネントと、を備える、コンピュータ・システム。
【特許請求の範囲】
【請求項1】
自エージェントが道路レイアウトを進行する運転シナリオの走行を視覚化するためのグラフィカル・ユーザ・インターフェースをレンダリングするためのコンピュータ・システムであって、前記運転シナリオの前記道路レイアウトの地図と、前記運転シナリオの走行の走行データとを受け取るように構成される少なくとも１つの入力であって、前記走行データは、
タイムスタンプ付きの自エージェント状態のシーケンスと、
走行評価ルールのセットの各ルールに関する、前記走行評価ルールを前記走行に適用することによって計算される、前記自エージェントのパフォーマンスを定量化した時間変化する数値スコアと、
を備える、前記少なくとも１つの入力と、
レンダリング・データを生成するように構成されるレンダリング・コンポーネントであって、前記レンダリング・データは、グラフィカル・ユーザ・インターフェースに、
前記走行評価ルールのうちの各ルールについて、
前記時間変化する数値スコアのプロットと、
前記プロットの時間軸上の選択された時間インデックスを示すマーカーであって、前記マーカーは、前記選択された時間インデックスを変更するために、前記グラフィカル・ユーザ・インターフェースにおいてユーザ入力を介して前記時間軸に沿って移動可能である、前記マーカーと、
前記選択された時間インデックスにおける前記走行のエージェント視覚化が重ねられた前記道路レイアウトの視覚化を備えるシナリオ視覚化であって、前記マーカーを前記時間軸に沿って移動させることは、前記選択された時間インデックスが変更されたときに、前記レンダリング・コンポーネントに前記シナリオ視覚化を更新させる、前記シナリオ視覚化と、
を表示させるためのものである、前記レンダリング・コンポーネントと、
を備える、コンピュータ・システム。
【請求項2】
前記入力は、前記運転シナリオの第２の走行の第２の走行データを受け取るようにさらに構成され、前記第２の走行データは、タイムスタンプ付きの自エージェント状態の第２のシーケンスと、走行評価ルールのセットの各ルールに関する、前記走行評価ルールを前記走行に適用することによって計算される、前記自エージェントのパフォーマンスを定量化した第２の時間変化する数値スコアと、を備え、前記レンダリング・コンポーネントは、レンダリング・データを生成するようにさらに構成され、前記レンダリング・データは、グラフィカル・ユーザ・インターフェースに、前記走行評価ルールのセットの各ルールについて、前記第２の時間変化する数値スコアのプロットであって、前記時間変化する数値スコアおよび前記第２の時間変化する数値スコアは、少なくとも共通の時間軸を備える共通の軸のセットに関してプロットされ、前記マーカーは、前記共通の時間軸上の選択された時間インデックスを示す、前記プロットと、
前記選択された時間インデックスにおける前記第２の走行の第２のエージェント視覚化であって、前記シナリオ視覚化は、前記第２のエージェント視覚化が重ねられる、前記第２のエージェント視覚化と、
を表示させるためのものである、請求項１に記載のコンピュータ・システム。
【請求項3】
前記時間変化する数値スコアは、前記走行データから抽出された時間変化する信号に１つまたは複数のルールを適用することによって計算され、前記信号の変化は前記シナリオ視覚化で見ることができる、請求項１または２に記載のコンピュータ・システム。
【請求項4】
前記レンダリング・コンポーネントは、第１の走行および前記第２の走行のうちの１つを示す前記グラフィカル・ユーザ・インターフェースでの選択解除入力に応答して、各運転ルールについて、前記共通の軸のセットから前記選択解除された走行の前記時間変化する数値スコアの前記プロットを除去し、
前記道路レイアウトの前記単一の視覚化から前記選択解除された走行の前記エージェント視覚化を除去する
ように構成され、
ユーザは、前記第１の走行および前記第２の走行の両方に関する走行比較ビューから、前記第１の走行および前記第２の走行の一方のみに関する単一走行ビューに切り替えることができる、
請求項２または３に記載のコンピュータ・システム。
【請求項5】
前記グラフィカル・ユーザ・インターフェースは、前記走行評価ルールのセットの各ルールについてのエントリを有する比較テーブルをさらに含み、前記エントリは、前記第１の走行における前記ルールに関する集約的なパフォーマンス結果と、前記第２の走行における前記ルールに関する集約的なパフォーマンス結果とを含む、請求項２から４のいずれかに記載のコンピュータ・システム。
【請求項6】
各ルールについての前記エントリは、前記ルールの説明をさらに備える、請求項５に記載のコンピュータ・システム。
【請求項7】
前記レンダリング・コンポーネントは、前記グラフィカル・ユーザ・インターフェースでの展開入力に応答して、各ルールの前記時間変化する数値スコアの前記プロットを非表示にし、時間の経過に伴う前記ルールの合格／不合格結果の指示を備えるタイムライン・ビューを表示するように構成される、請求項１から６のいずれかに記載のコンピュータ・システム。
【請求項8】
前記レンダリング・コンポーネントは、前記走行評価ルールのセットの各ルールについて、前記選択された時間インデックスにおける前記数値スコアを前記グラフィカル・ユーザ・インターフェースに表示させるように構成される、請求項１から７のいずれかに記載のコンピュータ・システム。
【請求項9】
前記走行評価ルールは認識ルールを備え、前記シナリオ視覚化は、自車両の認識コンポーネントによって生成された認識出力のセットを備える、請求項１から８のいずれかに記載のコンピュータ・システム。
【請求項10】
前記シナリオ視覚化は、前記道路レイアウトの前記視覚化に重ねられたセンサ・データを備える、請求項９に記載のコンピュータ・システム。
【請求項11】
前記シナリオ視覚化は、シナリオ時間マーカーを有するシナリオ・タイムラインを備え、前記マーカーを前記シナリオ・タイムラインに沿って移動させることは、前記選択された時間インデックスが変更されたときに、前記レンダリング・コンポーネントに、前記時間変化する数値スコアの各プロットの前記それぞれの時間マーカーを更新させる、請求項１から１０のいずれかに記載のコンピュータ・システム。
【請求項12】
前記シナリオ・タイムラインは、前記選択された時間インデックスに対応するフレーム・インデックスと、前記フレーム・インデックスをそれぞれインクリメントまたはデクリメントさせることによって前方または後方に移動するためのコントロールのセットと、を備える、請求項１０に記載のコンピュータ・システム。
【請求項13】
前記運転シナリオは、シミュレートされた自エージェントがシミュレートされた道路レイアウトを進行するシミュレートされた運転シナリオであり、前記走行データはシミュレータから受け取られる、請求項１から１２のいずれかに記載のコンピュータ・システム。
【請求項14】
前記運転シナリオは、前記自エージェントが現実世界の道路レイアウトを進行する現実世界の運転シナリオであり、前記走行データは、前記走行中に前記自エージェント上で生成されるデータに基づいて計算される、請求項１から１２のいずれかに記載のコンピュータ・システム。
【請求項15】
前記時間変化する数値スコアの前記プロットは、前記時間変化する数値スコアのｘｙプロットを備える、請求項１から１４のいずれかに記載のコンピュータ・システム。
【請求項16】
前記時間変化する数値スコアは、色分けを使用してプロットされる、請求項１から１５のいずれかに記載のコンピュータ・システム。
【請求項17】
自エージェントが道路レイアウトを進行する運転シナリオの走行を視覚化するための方法であって、前記運転シナリオの前記道路レイアウトの地図と、前記運転シナリオの走行の走行データとを受け取ることであって、前記走行データは、
タイムスタンプ付きの自エージェント状態のシーケンスと、
走行評価ルールのセットの各ルールに関する、前記走行評価ルールを前記走行に適用することによって計算される、前記自エージェントのパフォーマンスを定量化した時間変化する数値スコアと、
を備える、前記受け取ることと、
レンダリング・データを生成することであって、前記レンダリング・データは、グラフィカル・ユーザ・インターフェースに、
前記走行評価ルールのうちの各ルールについて、
前記時間変化する数値スコアのプロットと、
前記プロットの時間軸上の選択された時間インデックスを示すマーカーであって、前記マーカーは、前記選択された時間インデックスを変更するために、前記グラフィカル・ユーザ・インターフェースにおいてユーザ入力を介して前記時間軸に沿って移動可能である、前記マーカーと、
前記選択された時間インデックスにおける前記走行のエージェント視覚化が重ねられた前記道路レイアウトの視覚化を備えるシナリオ視覚化であって、前記マーカーを前記時間軸に沿って移動させることは、前記選択された時間インデックスが変更されたときに、前記レンダリング・コンポーネントに前記シナリオ視覚化を更新させる、前記シナリオ視覚化と、
を表示させるためのものである、前記生成することと、
を備える、方法。
【請求項18】
請求項１～１７のいずれかに記載の方法またはシステムの機能を実装するようにコンピュータ・システムをプログラムするための実行可能な命令を備える、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【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】
【図1A】自律車両スタックの概略ブロック図である。
【図1B】自律車両のテスト・パラダイムの概略図である。
【図1C】シナリオ抽出パイプラインの概略ブロック図である。
【図2A】テスト・パイプラインの概略ブロック図である。
【図2B】テスト・パイプラインの可能な実装のさらなる詳細を示す図である。
【図3A】テスト・オラクル内で評価されるルール・グラフの例を示す図である。
【図3B】ルール・グラフのノードの例示的な出力を示す図である。
【図4】走行視覚化ユーザ・インターフェースをレンダリングするためのコンピュータ・システムの概略ブロック図である。
【図5】例示的な走行視覚化ユーザ・インターフェースの単一走行ビューを示す図である。
【図6】例示的な走行視覚化ユーザ・インターフェースの走行比較ビューを示す図である。
【図7】走行視覚化ユーザ・インターフェースの退行レポート・ビューを示す図である。
【図8】認識エラーを評価するためのアーキテクチャを示す図である。
【図9A】トリアージ・ツールの例示的なグラフィカル・ユーザ・インターフェースを示す図である。
【図9B】グラフィカル・ユーザ・インターフェースに表示されたセンサ・データを含む運転シナリオの概略表現を示す図である。
【図9C】ズーム機能およびタイムライン・スクラバーを有する例示的なユーザ・インターフェースを示す図である。
【図9D】ユーザ・インターフェースにおけるシナリオのサブセクションの選択を示す図である。
【図10】認識エラーの数値スコアの例示的なグラフを定義されたエラー閾値と共に示す図である。
【発明を実施するための形態】
【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】
どのような形態を取っても、シミュレートされた入力２０３は、プランナ１０８による意思決定の基礎として（直接的または間接的に）使用される。
【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】
本明細書におけるコンポーネント、機能、モジュールなどへの言及は、様々な方法によってハードウェア・レベルで実装されることができるコンピュータ・システムの機能コンポーネントを指す。コンピュータ・システムは、本明細書で開示された方法／アルゴリズム・ステップを実行するように、および／または本技術を使用してトレーニングされたモデルを実装するように構成されてもよい実行ハードウェアを備える。実行ハードウェアという用語は、関連する方法／アルゴリズム・ステップを実行するように構成されるハードウェアのあらゆる形態／組み合わせを包含する。実行ハードウェアは、プログラマブルまたは非プログラマブルであってもよい１つまたは複数のプロセッサの形態を取ってもよく、あるいはプログラマブル・ハードウェアと非プログラマブル・ハードウェアとの組み合わせが使用されてもよい。適切なプログラマブル・プロセッサの例は、ＣＰＵ、ＧＰＵ／アクセラレータ・プロセッサなどの命令セット・アーキテクチャに基づく汎用プロセッサを含む。そのような汎用プロセッサは、典型的には、プロセッサに結合されたまたは内蔵するメモリに保持されたコンピュータ可読命令を実行し、それらの命令に従って関連するステップを実施する。他の形態のプログラマブル・プロセッサは、回路記述コードを通じてプログラム可能な回路構成を有するフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）を含む。非プログラマブル・プロセッサの例は、特定用途向け集積回路（ＡＳＩＣ）を含む。コード、命令などは、必要に応じて一時的媒体または非一時的媒体（後者の例は、ソリッド・ステート、磁気および光学ストレージ・デバイスなどを含む）に記憶されてもよい。図１Ａの走行時スタックのサブシステム１０２～１０８は、プログラマブル・プロセッサもしくは専用プロセッサ、またはその両方の組み合わせで、車両に搭載されて、またはテストなどのコンテキストでは非車載コンピュータ・システムで実装されてもよい。図２Ａ、図２Ｂ、図３Ｂ、図４および図８のコンポーネントも同様に、プログラマブル・ハードウェアおよび／または専用ハードウェアで実装されてもよい。
【図1A】
【図1B】
【図1C】
【図2A】
【図2B】
【図3A】
【図3B】
【図4】
【図5-1】
【図5-2】
【図6-1】
【図6-2】
【図7】
【図8】
【図9A-1】
【図9A-2】
【図9B】
【図9C】
【図9D】
【図10】
【手続補正書】
【提出日】2024-01-30
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
自エージェントが道路レイアウトを進行する運転シナリオの走行を視覚化するためのグラフィカル・ユーザ・インターフェースをレンダリングするためのコンピュータ・システムであって、前記運転シナリオの前記道路レイアウトの地図と、前記運転シナリオの走行の走行データとを受け取るように構成される少なくとも１つの入力であって、前記走行データは、
タイムスタンプ付きの自エージェント状態のシーケンスと、
走行評価ルールのセットの各ルールに関する、前記走行評価ルールを前記走行に適用することによって計算される、前記自エージェントのパフォーマンスを定量化した時間変化する数値スコアと、
を備える、前記少なくとも１つの入力と、
レンダリング・データを生成するように構成されるレンダリング・コンポーネントであって、前記レンダリング・データは、グラフィカル・ユーザ・インターフェースに、
前記走行評価ルールのうちの各ルールについて、
前記時間変化する数値スコアのプロットと、
前記プロットの時間軸上の選択された時間インデックスを示すマーカーであって、前記マーカーは、前記選択された時間インデックスを変更するために、前記グラフィカル・ユーザ・インターフェースにおいてユーザ入力を介して前記時間軸に沿って移動可能である、前記マーカーと、
前記選択された時間インデックスにおける前記走行のエージェント視覚化が重ねられた前記道路レイアウトの視覚化を備えるシナリオ視覚化であって、前記マーカーを前記時間軸に沿って移動させることは、前記選択された時間インデックスが変更されたときに、前記レンダリング・コンポーネントに前記シナリオ視覚化を更新させる、前記シナリオ視覚化と、
を表示させるためのものである、前記レンダリング・コンポーネントと、
を備える、コンピュータ・システム。
【請求項2】
前記入力は、前記運転シナリオの第２の走行の第２の走行データを受け取るようにさらに構成され、前記第２の走行データは、タイムスタンプ付きの自エージェント状態の第２のシーケンスと、走行評価ルールのセットの各ルールに関する、前記走行評価ルールを前記走行に適用することによって計算される、前記自エージェントのパフォーマンスを定量化した第２の時間変化する数値スコアと、を備え、前記レンダリング・コンポーネントは、レンダリング・データを生成するようにさらに構成され、前記レンダリング・データは、グラフィカル・ユーザ・インターフェースに、前記走行評価ルールのセットの各ルールについて、前記第２の時間変化する数値スコアのプロットであって、前記時間変化する数値スコアおよび前記第２の時間変化する数値スコアは、少なくとも共通の時間軸を備える共通の軸のセットに関してプロットされ、前記マーカーは、前記共通の時間軸上の選択された時間インデックスを示す、前記プロットと、
前記選択された時間インデックスにおける前記第２の走行の第２のエージェント視覚化であって、前記シナリオ視覚化は、前記第２のエージェント視覚化が重ねられる、前記第２のエージェント視覚化と、
を表示させるためのものである、請求項１に記載のコンピュータ・システム。
【請求項3】
前記時間変化する数値スコアは、前記走行データから抽出された時間変化する信号に１つまたは複数のルールを適用することによって計算され、前記信号の変化は前記シナリオ視覚化で見ることができる、請求項１に記載のコンピュータ・システム。
【請求項4】
前記レンダリング・コンポーネントは、第１の走行および前記第２の走行のうちの１つを示す前記グラフィカル・ユーザ・インターフェースでの選択解除入力に応答して、各運転ルールについて、前記共通の軸のセットから前記選択解除された走行の前記時間変化する数値スコアの前記プロットを除去し、
前記道路レイアウトの前記単一の視覚化から前記選択解除された走行の前記エージェント視覚化を除去する
ように構成され、
ユーザは、前記第１の走行および前記第２の走行の両方に関する走行比較ビューから、前記第１の走行および前記第２の走行の一方のみに関する単一走行ビューに切り替えることができる、
請求項２に記載のコンピュータ・システム。
【請求項5】
前記グラフィカル・ユーザ・インターフェースは、前記走行評価ルールのセットの各ルールについてのエントリを有する比較テーブルをさらに含み、前記エントリは、前記第１の走行における前記ルールに関する集約的なパフォーマンス結果と、前記第２の走行における前記ルールに関する集約的なパフォーマンス結果とを含む、請求項２に記載のコンピュータ・システム。
【請求項6】
各ルールについての前記エントリは、前記ルールの説明をさらに備える、請求項５に記載のコンピュータ・システム。
【請求項7】
前記レンダリング・コンポーネントは、前記グラフィカル・ユーザ・インターフェースでの展開入力に応答して、各ルールの前記時間変化する数値スコアの前記プロットを非表示にし、時間の経過に伴う前記ルールの合格／不合格結果の指示を備えるタイムライン・ビューを表示するように構成される、請求項１に記載のコンピュータ・システム。
【請求項8】
前記レンダリング・コンポーネントは、前記走行評価ルールのセットの各ルールについて、前記選択された時間インデックスにおける前記数値スコアを前記グラフィカル・ユーザ・インターフェースに表示させるように構成される、請求項１に記載のコンピュータ・システム。
【請求項9】
前記走行評価ルールは認識ルールを備え、前記シナリオ視覚化は、自車両の認識コンポーネントによって生成された認識出力のセットを備える、請求項１に記載のコンピュータ・システム。
【請求項10】
前記シナリオ視覚化は、前記道路レイアウトの前記視覚化に重ねられたセンサ・データを備える、請求項９に記載のコンピュータ・システム。
【請求項11】
前記シナリオ視覚化は、シナリオ時間マーカーを有するシナリオ・タイムラインを備え、前記マーカーを前記シナリオ・タイムラインに沿って移動させることは、前記選択された時間インデックスが変更されたときに、前記レンダリング・コンポーネントに、前記時間変化する数値スコアの各プロットの前記それぞれの時間マーカーを更新させる、請求項１に記載のコンピュータ・システム。
【請求項12】
前記シナリオ・タイムラインは、前記選択された時間インデックスに対応するフレーム・インデックスと、前記フレーム・インデックスをそれぞれインクリメントまたはデクリメントさせることによって前方または後方に移動するためのコントロールのセットと、を備える、請求項１０に記載のコンピュータ・システム。
【請求項13】
前記運転シナリオは、シミュレートされた自エージェントがシミュレートされた道路レイアウトを進行するシミュレートされた運転シナリオであり、前記走行データはシミュレータから受け取られる、請求項１に記載のコンピュータ・システム。
【請求項14】
前記運転シナリオは、前記自エージェントが現実世界の道路レイアウトを進行する現実世界の運転シナリオであり、前記走行データは、前記走行中に前記自エージェント上で生成されるデータに基づいて計算される、請求項１に記載のコンピュータ・システム。
【請求項15】
前記時間変化する数値スコアの前記プロットは、前記時間変化する数値スコアのｘｙプロットを備える、請求項１に記載のコンピュータ・システム。
【請求項16】
前記時間変化する数値スコアは、色分けを使用してプロットされる、請求項１に記載のコンピュータ・システム。
【請求項17】
自エージェントが道路レイアウトを進行する運転シナリオの走行を視覚化するための方法であって、前記運転シナリオの前記道路レイアウトの地図と、前記運転シナリオの走行の走行データとを受け取ることであって、前記走行データは、
タイムスタンプ付きの自エージェント状態のシーケンスと、
走行評価ルールのセットの各ルールに関する、前記走行評価ルールを前記走行に適用することによって計算される、前記自エージェントのパフォーマンスを定量化した時間変化する数値スコアと、
を備える、前記受け取ることと、
レンダリング・データを生成することであって、前記レンダリング・データは、グラフィカル・ユーザ・インターフェースに、
前記走行評価ルールのうちの各ルールについて、
前記時間変化する数値スコアのプロットと、
前記プロットの時間軸上の選択された時間インデックスを示すマーカーであって、前記マーカーは、前記選択された時間インデックスを変更するために、前記グラフィカル・ユーザ・インターフェースにおいてユーザ入力を介して前記時間軸に沿って移動可能である、前記マーカーと、
前記選択された時間インデックスにおける前記走行のエージェント視覚化が重ねられた前記道路レイアウトの視覚化を備えるシナリオ視覚化であって、前記マーカーを前記時間軸に沿って移動させることは、前記選択された時間インデックスが変更されたときに、前記レンダリング・コンポーネントに前記シナリオ視覚化を更新させる、前記シナリオ視覚化と、
を表示させるためのものである、前記生成することと、
を備える、方法。
【請求項18】
請求項１～１７のいずれかに記載の方法またはシステムの機能を実装するようにコンピュータ・システムをプログラムするための実行可能な命令を備える、コンピュータ・プログラム。
【国際調査報告】