知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-02-26
(54)【発明の名称】軌道プランナのパフォーマンス・テスト
(51)【国際特許分類】
G08G 1/00 20060101AFI20240216BHJP
【ＦＩ】
G08G1/00 A
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023548761
(86)(22)【出願日】2022-02-11
(85)【翻訳文提出日】2023-10-06
(86)【国際出願番号】 EP2022053406
(87)【国際公開番号】W WO2022171812
(87)【国際公開日】2022-08-18
(31)【優先権主張番号】2102006.0
(32)【優先日】2021-02-12
(33)【優先権主張国・地域又は機関】GB
(31)【優先権主張番号】2105838.3
(32)【優先日】2021-04-23
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】521163628
【氏名又は名称】ファイブ、エーアイ、リミテッド
【氏名又は名称原語表記】ＦＩＶＥ ＡＩ ＬＩＭＩＴＥＤ
(74)【代理人】
【識別番号】100120031
【弁理士】
【氏名又は名称】宮嶋 学
(74)【代理人】
【識別番号】100107582
【弁理士】
【氏名又は名称】関根 毅
(74)【代理人】
【識別番号】100118843
【弁理士】
【氏名又は名称】赤岡 明
(74)【代理人】
【識別番号】100152205
【弁理士】
【氏名又は名称】吉田 昌司
(72)【発明者】
【氏名】イアン、ホワイトサイド
(72)【発明者】
【氏名】デイビッド、ハイマン
(72)【発明者】
【氏名】コンスタンティン、ベレテニコフ
【テーマコード（参考）】
5H181
【Ｆターム（参考）】
5H181AA01
5H181CC03
5H181CC04
5H181CC12
5H181CC14
5H181EE02
5H181FF04
5H181FF05
5H181FF10
(57)【要約】
コンピュータ・システムは、現実のまたはシミュレーションされたシナリオにおける少なくとも１つの他のエージェントに応答して自エージェントを制御するために軌道プランナを使用して生成されるシナリオ・データを受け取る。テスト・オラクルは、シナリオ・データから時間変化する数値信号を抽出するための予め定められたエクストラクタ関数と、抽出された時間変化する信号を査定するための予め定められたアセッサ関数とを提供する。テスト・オラクルは、エクストラクタ・ノードおよびアセッサ・ノードを備えるルール・グラフをシナリオ・データに適用する。各エクストラクタ・ノードは、予め定められたエクストラクタ関数のうちの１つをシナリオ・データに適用して、時間変化する数値信号の形式で出力を抽出する。各アセッサ・ノードは１つまたは複数の子ノードを有し、各子ノードはエクストラクタ・ノードのうちの１つまたはアセッサ・ノードのうちの別の１つであり、アセッサ・ノードは、予め定められたアセッサ関数のうちの１つをその子ノードの出力に適用する。テスト・オラクルは、アセッサ・ノードのうちの少なくとも１つの出力と、その子ノードのうちの少なくとも１つの出力とを備える出力グラフを提供する。
【特許請求の範囲】
【請求項1】
現実のまたはシミュレーションされたシナリオにおける軌道プランナのパフォーマンスを評価するためのコンピュータ・システムであって、シナリオ・データを受け取るように構成される少なくとも１つの入力であって、前記シナリオ・データは、前記現実のまたはシミュレーションされたシナリオにおける少なくとも１つの他のエージェントに応答して自エージェントを制御するために前記軌道プランナを使用して生成される、少なくとも１つの入力と、
前記シナリオ・データから時間変化する数値信号を抽出するための予め定められたエクストラクタ関数と、前記抽出された時間変化する信号を査定するための予め定められたアセッサ関数とを提供するように構成されるテスト・オラクルと
を備え、
前記テスト・オラクルは、エクストラクタ・ノードおよびアセッサ・ノードを備えるルール・グラフを前記シナリオ・データに適用するように構成され、
各エクストラクタ・ノードは、前記予め定められたエクストラクタ関数のうちの１つを前記シナリオ・データに適用して、時間変化する数値信号の形式で出力を抽出するように構成され、
各アセッサ・ノードは１つまたは複数の子ノードを有し、各子ノードは前記エクストラクタ・ノードのうちの１つまたは前記アセッサ・ノードのうちの別の１つであり、前記アセッサ・ノードは、前記予め定められたアセッサ関数のうちの１つをその子ノードの出力に適用して、前記出力から出力を計算するように構成され、
前記テスト・オラクルは、前記アセッサ・ノードのうちの少なくとも１つの出力と、その子ノードのうちの少なくとも１つの出力とを備える出力グラフを提供するように構成される、
コンピュータ・システム。
【請求項2】
各エクストラクタ・ノードの前記予め定められたエクストラクタ関数と、各アセッサ・ノードの前記予め定められたアセッサ関数と、前記エクストラクタ・ノードと前記アセッサ・ノードとの間の親子関係とを指定するルール作成入力に応答して前記ルール・グラフを作成するように構成されるルール・エディタを備える、請求項１に記載のコンピュータ・システム。
【請求項3】
前記ルール・グラフを作成するように構成されるルール・エディタを備え、各エクストラクタ・ノードは、前記予め定められたエクストラクタ関数の識別子を備えるノード作成入力に応答して作成され、
各アセッサ・ノードは、前記アセッサ関数の識別子と、前記１つまたは複数の子ノードの識別子とを備えるノード作成入力に応答して作成される、
請求項１に記載のコンピュータ・システム。
【請求項4】
前記出力グラフは、前記アセッサ・ノードのうちの一部または全ての前記出力を備える、請求項１、２または３に記載のコンピュータ・システム。
【請求項5】
前記出力グラフは、前記エクストラクタ・ノードのうちの１つ、一部、または全ての前記出力を備える、請求項４に記載のコンピュータ・システム。
【請求項6】
前記コンピュータ・システムは、前記出力グラフにアクセスするためのグラフィカル・ユーザ・インターフェース（ＧＵＩ）を提供するように構成され、前記ＧＵＩを介して、前記出力グラフの各出力の視覚化にアクセス可能である、請求項１～５のいずれか一項に記載のコンピュータ・システム。
【請求項7】
前記ＧＵＩは前記少なくとも１つのアセッサ・ノードの前記出力の視覚的表現を最初に表示するように構成され、グラフ展開入力に応答して、前記ＧＵＩはその子ノードの前記出力の視覚的表現を表示するように構成される、請求項６に記載のコンピュータ・システム。
【請求項8】
前記ＧＵＩは、前記ノード作成入力の変更に応答して更新される前記ルール・グラフの初期の視覚化を表示するように構成される、請求項２または３に従属する場合の請求項６または７に記載のコンピュータ・システム。
【請求項9】
各アセッサ・ノードの前記出力は、カテゴリ結果の時系列および導出された時間変化する数値信号のうちの少なくとも１つを備える、請求項１～８のいずれか一項に記載のコンピュータ・システム。
【請求項10】
前記アセッサ・ノードの前記出力は、カテゴリ結果の時系列および導出された時間変化する数値信号を備え、前記導出された時間変化する信号は、第１のタイプのカテゴリ結果が計算される場合に限り、閾値条件を満たす、請求項９に記載のコンピュータ・システム。
【請求項11】
前記ＧＵＩは前記カテゴリ結果の時系列の視覚的表現を最初に表示するように構成され、ノード展開入力に応答して、前記ＧＵＩは前記導出された時間変化する信号の視覚的表現を表示するように構成される、請求項６に従属する場合の請求項１０に記載のコンピュータ・システム。
【請求項12】
前記導出された時間変化する信号は、前記閾値条件を満たす任意の部分の視覚的指示と共に表示される、請求項１１に記載のコンピュータ・システム。
【請求項13】
前記アセッサ関数および／または前記エクストラクタ関数のうちの少なくとも１つは、１つまたは複数の設定可能なパラメータを有し、前記ルール・エディタは、前記パラメータを設定するための１つまたは複数のパラメータ設定入力を受け取るように構成される、請求項２または３あるいは請求項２または３に従属する請求項のいずれか一項に記載のコンピュータ・システム。
【請求項14】
前記テスト・オラクルは、前記パラメータの現在の設定のために必要に応じて前記出力を部分的にのみ計算し、前記部分的に計算された出力をキャッシュに記憶するように構成され、前記パラメータの前記設定の変更に応答して、前記テスト・オラクルは、前記キャッシュされた出力が前記変更の影響を受けない範囲を決定し、前記出力の再計算および／またはさらなる計算が必要な範囲を決定し、必要に応じて前記出力を（再）計算し、前記（再）計算された出力を、前記影響を受けていないキャッシュされた出力と結合するように構成される、
請求項１３に記載のコンピュータ・システム。
【請求項15】
前記テスト・オラクルは、前記ルール・グラフを前記シナリオ・データに適用することを、複数の子ノードを有する前記アセッサ・ノードのうちの少なくとも１つについて、前記複数の子ノードのうちの１つまたは複数の第１のサブセットの出力を計算し、前記出力から、残りの子ノードの前記出力を計算しないかまたは部分的にしか計算せずに前記アセッサ・ノードの前記出力が計算可能であることを決定し、前記残りの子ノードの前記出力を計算しないかまたは部分的にしか計算せずに前記アセッサ・ノードの前記出力を計算する
ことによって行うように構成される、請求項１～１４のいずれか一項に記載のコンピュータ・システム。
【請求項16】
前記ルール・エディタは、前記ルール・グラフの少なくとも１つのシナリオ条件を表す入力を受け取るように構成され、前記テスト・オラクルは、複数の時間ステップまたは時間間隔において前記シナリオ・データを査定して、前記時間ステップまたは時間間隔において前記シナリオ条件が満たされているか否かを判定し、
前記シナリオ条件が満たされている任意の時間ステップまたは時間間隔に関して、前記アセッサ・ノードのうちの少なくとも１つの前記出力を部分的に計算し、その子ノードの前記出力が、前記アセッサ・ノードの前記出力を部分的に計算するために必要に応じて部分的にのみ計算される
ように構成される、請求項２または３あるいは請求項２または３に従属する請求項のいずれか一項に記載のコンピュータ・システム。
【請求項17】
前記テスト・オラクルは、前記子ノードの前記部分的に計算された出力をキャッシュに記憶し、前記キャッシュされた出力の少なくとも一部を再利用することを、前記シナリオ・データで他のルール・グラフを評価する、および／または
前記ルール・グラフの少なくとも１つの設定可能なパラメータの変更に応答して、前記シナリオ・データで前記ルール・グラフを再評価する
場合に行うように構成され、
前記キャッシュされた出力は、少なくとも１つのさらなる時間間隔または時間期間の間に前記ノードの部分的に計算された出力と結合される、
請求項１６に記載のコンピュータ・システム。
【請求項18】
前記ノード作成入力はルール作成コードに具現化され、前記ルール・エディタは前記ルール作成コードを受け取って解釈するように構成される、請求項２または３あるいは請求項２または３に従属する請求項のいずれか一項に記載のコンピュータ・システム。
【請求項19】
前記ルール作成コードはドメイン固有言語に従って解釈される、請求項１８に記載のコンピュータ・システム。
【請求項20】
前記アセッサ関数のうちの少なくとも１つは時相または非時相論理演算子を備える、請求項１～１９のいずれか一項に記載のコンピュータ・システム。
【請求項21】
現実のまたはシミュレーションされたシナリオにおける少なくとも１つの他のエージェントに応答して自エージェントを制御するために軌道プランナを使用して生成されるシナリオ・データを評価するためのルールを作成するためのルール・エディタであって、前記ルール・エディタは一時的または非一時的媒体にプログラム命令として具現化され、前記プログラム命令は１つまたは複数のコンピュータ・プロセッサ上で実行された場合に、前記１つまたは複数のプロセッサに、エクストラクタ・ノードおよびアセッサ・ノードを備えるカスタム・ルール・グラフを作成させ、
各エクストラクタ・ノードは、テスト・オラクルによって提供される予め定められたエクストラクタ関数のうちの１つの識別子を備えるノード作成入力に応答して作成され、前記エクストラクタ・ノードは、前記識別されたエクストラクタ関数をシナリオ・データに適用して、時間変化する数値信号の形式で出力を抽出するように構成され、
各アセッサ・ノードは、前記テスト・オラクルによって提供される予め定められたアセッサ関数のうちの１つの識別子と、１つまたは複数の子ノードの識別子とを備えるノード作成入力に応答して作成され、各子ノードは前記エクストラクタ・ノードのうちの１つまたは前記アセッサ・ノードのうちの別の１つであり、前記アセッサ・ノードは、前記識別されたアセッサ関数をその子ノードの出力に適用して、前記出力から出力を計算するように構成される、
ルール・エディタ。
【請求項22】
少なくとも１つの運転ルールに基づいて現実のまたはシミュレーションされたシナリオにおける自律車両の軌道プランナのパフォーマンスを評価するためのコンピュータ・システムであって、シナリオ・データを受け取るように構成される少なくとも１つの入力であって、前記シナリオ・データは、前記現実のまたはシミュレーションされたシナリオにおける少なくとも１つの他のエージェントに応答して前記自律車両を制御するために前記軌道プランナを使用して生成される、少なくとも１つの入力と、
前記シナリオ・データに適用される運転ルールを入力として受け取るように構成されるルール・エディタであって、前記運転ルールは、１つまたは複数のエクストラクタ関数で評価される時相または非時相論理述語の形式で定義される、ルール・エディタと、
前記１つまたは複数のエクストラクタ関数を前記シナリオ・データに適用して、前記シナリオ・データから１つまたは複数の抽出された信号を計算し、前記シナリオの複数の時間ステップにおいて前記１つまたは複数の抽出された信号で前記論理述語を評価することによって、カテゴリ結果の時系列の形式で最上位の出力を計算することにより、前記運転ルールを前記シナリオに適用するように構成されるテスト・オラクルと、
出力グラフを表示するように構成されるグラフィカル・ユーザ・インターフェースであって、前記出力グラフは、
前記最上位の出力と、
複数の中間出力であって、それぞれが前記最上位の出力を導出するために使用されるカテゴリ結果の時系列であり、それぞれが前記運転ルールの構成要素の述語を評価することによって計算される、複数の中間出力と、
前記最上位の出力と前記複数の中間出力との間の階層関係のセットと
を視覚化する、グラフィカル・ユーザ・インターフェースと
を備える、コンピュータ・システム。
【請求項23】
前記出力グラフは、前記最上位の出力または前記複数の中間出力のうちの１つと相関する導出された信号の視覚的表現を備える、請求項２２に記載のコンピュータ・システム。
【請求項24】
前記出力グラフは、前記１つまたは複数の抽出された信号のうちの少なくとも１つの抽出された信号と、前記少なくとも１つの抽出された信号と前記複数の中間出力との間の階層関係との視覚的表現を備える、請求項２２または２３に記載のコンピュータ・システム。
【請求項25】
請求項１～２４のいずれか一項に記載の機能を実装するようにコンピュータ・システムをプログラムするための実行可能なプログラム命令。
【発明の詳細な説明】
【技術分野】
【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】
【図1A】自律車両スタックの概略機能ブロック図である。
【図1B】自律車両のテスト・パラダイムの概略図である。
【図1C】シナリオ抽出パイプラインの概略ブロック図である。
【図2】テスト・パイプラインの概略ブロック図である。
【図2A】テスト・パイプラインの可能な実装のさらなる詳細を示す図である。
【図3A】テスト・オラクル内で評価されるルール・グラフの例を示す図である。
【図3B】ルール・グラフのノードの例示的な出力を示す図である。
【図4A】テスト・オラクル内で評価されるカスタム・ルール・グラフを作成するためのルール・エディタを示す図である。
【図4B】シナリオ・グラウンド・トゥルース・データのセットで評価された例示的なカスタム・ルール・グラフを示す図である。
【図5】折り畳み可能な出力グラフが表示される例示的なグラフィカル・ユーザ・インターフェース（ＧＵＩ）を示す図である。
【図6】折り畳み可能な出力グラフが表示されるＧＵＩのさらなる例を示す図である。
【発明を実施するための形態】
【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】
【数1】
【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】
【数2】
【図1A】
【図1B】
【図1C】
【図2】
【図2A】
【図3A】
【図3B】
【図4A】
【図4B】
【図5】
【図6】
【国際調査報告】