7612883 移動ロボットの軌道プランナのパフォーマンス・テスト

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-12-27

(45)【発行日】2025-01-14

(54)【発明の名称】移動ロボットの軌道プランナのパフォーマンス・テスト

(51)【国際特許分類】

   G08G 1/00 20060101AFI20250106BHJP

   B60W 60/00 20200101ALI20250106BHJP

   G06F 11/36 20060101ALI20250106BHJP

【ＦＩ】

G08G1/00 D

B60W60/00

G06F11/36 188

【請求項の数】 15

(21)【出願番号】P 2023548758

(86)(22)【出願日】2022-02-11

(65)【公表番号】

(43)【公表日】2024-02-28

(86)【国際出願番号】 EP2022053413

(87)【国際公開番号】W WO2022171819

(87)【国際公開日】2022-08-18

【審査請求日】2023-10-06

(31)【優先権主張番号】2102006.0

(32)【優先日】2021-02-12

(33)【優先権主張国・地域又は機関】GB

(31)【優先権主張番号】2105838.3

(32)【優先日】2021-04-23

(33)【優先権主張国・地域又は機関】GB

(73)【特許権者】

【識別番号】521163628

【氏名又は名称】ファイブ、エーアイ、リミテッド

【氏名又は名称原語表記】ＦＩＶＥ ＡＩ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】100120031

【弁理士】

【氏名又は名称】宮嶋 学

(74)【代理人】

【識別番号】100107582

【弁理士】

【氏名又は名称】関根 毅

(74)【代理人】

【識別番号】100118843

【弁理士】

【氏名又は名称】赤岡 明

(74)【代理人】

【識別番号】100152205

【弁理士】

【氏名又は名称】吉田 昌司

(72)【発明者】

【氏名】イアン、ホワイトサイド

(72)【発明者】

【氏名】ジョン、レッドフォード

(72)【発明者】

【氏名】デイビッド、ハイマン

(72)【発明者】

【氏名】コンスタンティン、ベレテニコフ

【審査官】▲高▼木 真顕

(56)【参考文献】

【文献】特表２０１９－５１２８２４（ＪＰ，Ａ）

【文献】国際公開第２０１８／１８０１４３（ＷＯ，Ａ１）

【文献】国際公開第２０１９／１６７４５７（ＷＯ，Ａ１）

【文献】特開２０１１－１１８６０１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０８Ｇ １／００ － ９９／００

Ｂ６０Ｗ ３０／００ － ６０／００

Ｇ０６Ｆ １１／２８ － １１／３６

Ｇ０５Ｄ １／００ － １／８７

Ｇ０１Ｃ ２１／００ － ２１／３６

(57)【特許請求の範囲】

【請求項1】

現実のまたはシミュレーションされたシナリオにおける移動ロボットの軌道プランナのパフォーマンスを評価するコンピュータ実装方法であって、
前記シナリオのシナリオ・グラウンド・トゥルースを受け取ることであって、前記シナリオ・グラウンド・トゥルースは、前記シナリオの少なくとも１つのシナリオ要素に応答して前記シナリオの自エージェントを制御するために前記軌道プランナを使用して生成される、受け取ることと、
前記シナリオの１つまたは複数のパフォーマンス評価ルールと、各パフォーマンス評価ルールの少なくとも１つのアクティブ化条件とを受け取ることと、
各パフォーマンス評価ルールの前記アクティブ化条件が前記シナリオの複数の時間ステップにわたって満たされているかどうかを判定するために、テスト・オラクルによって、前記シナリオ・グラウンド・トゥルースを処理することであって、各パフォーマンス評価ルールは、前記アクティブ化条件が満たされている場合にのみ、少なくとも１つのテスト結果を提供するために、前記テスト・オラクルによって評価される、処理することとを備え、
前記シナリオ・グラウンド・トゥルースは、各パフォーマンス評価ルールの前記アクティブ化条件が複数のシナリオ要素のセットの各シナリオ要素について前記シナリオの複数の時間ステップにわたって満たされているかどうかを判定するために処理され、各パフォーマンス評価ルールは、そのアクティブ化条件が前記シナリオ要素のうちの少なくとも１つについて満たされている場合にのみ、および前記自エージェントと前記アクティブ化条件が満たされている前記シナリオ要素との間でのみ評価される、コンピュータ実装方法。

【請求項2】

各パフォーマンス評価ルールは、ルール作成コードの一部に第２の論理述語としてコード化され、そのアクティブ化条件は、ルール作成コードの前記一部に第１の論理述語としてコード化され、各時間ステップにおいて、前記テスト・オラクルは、各シナリオ要素について前記第１の論理述語を評価し、前記自エージェントと前記第１の論理述語を満たす任意のシナリオ要素との間でのみ前記第２の論理述語を評価する、請求項１に記載の方法。

【請求項3】

異なるそれぞれのアクティブ化条件を有する複数のパフォーマンス評価ルールが受け取られ、前記テスト・オラクルによってそれらの異なるそれぞれのアクティブ化条件に従って選択的に評価される、請求項１または２に記載の方法。

【請求項4】

各パフォーマンス評価ルールは運転パフォーマンスに関する、請求項１～３のいずれか一項に記載の方法。

【請求項5】

時系列における前記複数の時間ステップのそれぞれの結果をグラフィカル・ユーザ・インターフェース（ＧＵＩ）上にレンダリングすることであって、各時間ステップの前記結果は、
前記アクティブ化条件が満たされていない場合の第１のカテゴリと、
前記アクティブ化条件が満たされており、前記ルールに合格している場合の第２のカテゴリと、
前記アクティブ化条件が満たされており、前記ルールに不合格である場合の第３のカテゴリとを備える少なくとも３つのカテゴリのうちの１つのカテゴリを視覚的に示す、レンダリングすることを備える、請求項１～４のいずれか一項に記載の方法。

【請求項6】

前記結果は、前記少なくとも３つのカテゴリに対応する少なくとも３つの異なる色のうちの１つの色としてレンダリングされる、請求項５に記載の方法。

【請求項7】

前記パフォーマンス評価ルールのうちの第１のパフォーマンス評価ルールの前記アクティブ化条件は、前記パフォーマンス評価ルールのうちの少なくとも第２のパフォーマンス評価ルールの前記アクティブ化条件に依存する、請求項１～６のいずれか一項に記載の方法。

【請求項8】

前記第２のパフォーマンス評価ルールがアクティブである場合、前記第１のパフォーマンス評価ルールは非アクティブ化される、請求項７に記載の方法。

【請求項9】

前記第２のパフォーマンス評価ルールは安全性に関し、前記第１のパフォーマンス評価ルールは快適性に関する、請求項８に記載の方法。

【請求項10】

前記シナリオ要素は１つまたは複数の他のエージェントを備える、請求項１～９のいずれか一項に記載の方法。

【請求項11】

前記シナリオ要素のセットは他のエージェントのセットである、請求項１０に記載の方法。

【請求項12】

前記アクティブ化条件が満たされている任意のシナリオ要素の識別子を含むイテラブルを各時間ステップで計算するために、前記アクティブ化条件は各シナリオ要素について評価され、前記パフォーマンス評価ルールは、各時間ステップで前記イテラブルにわたってループすることによって評価される、請求項２に従属する場合の請求項１０または１１に記載の方法。

【請求項13】

前記パフォーマンス評価ルールは、前記シナリオ・グラウンド・トゥルースから抽出される１つまたは複数の信号に適用される計算グラフとして定義され、前記イテラブルは、前記自エージェントと前記アクティブ化条件を満たす任意のシナリオ要素との間で前記ルールを評価するために前記計算グラフを介して受け渡される、請求項１２に記載の方法。

【請求項14】

請求項１～１３のいずれか一項に記載の方法を実装するように構成される１つまたは複数のコンピュータを備えるコンピュータ・システム。

【請求項15】

請求項１～１３のいずれか一項に記載の方法を実装するようにコンピュータ・システムをプログラムするための実行可能なプログラム命令。

【発明の詳細な説明】

【技術分野】

【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】シナリオ抽出パイプラインの概略ブロック図である。

【図2】テスト・パイプラインの概略ブロック図である。

【図2A】テスト・パイプラインの可能な実装のさらなる詳細を示す図である。

【図3A】テスト・オラクル内で評価されるルール・ツリーの例を示す図である。

【図3B】ルール・ツリーのノードの例示的な出力を示す図である。

【図4A】テスト・オラクル内で評価されるルール・ツリーの例を示す図である。

【図4B】シナリオ・グラウンド・トゥルース・データのセットで評価されたルール・ツリーの第２の例を示す図である。

【図4C】テスト・オラクル内でルールがどのように選択的に適用されることができるかを示す図である。

【図5】グラフィカル・ユーザ・インターフェースをレンダリングするための視覚化コンポーネントの概略ブロック図である。

【図5A-5C】グラフィカル・ユーザ・インターフェース内で利用可能な様々なビューを示す図である。

【図6A】割り込みシナリオの第１のインスタンスを示す図である。

【図6B】第１のシナリオ・インスタンスの例示的なオラクル出力を示す図である。

【図6C】割り込みシナリオの第２のインスタンスを示す図である。

【図6D】第２のシナリオ・インスタンスの例示的なオラクル出力を示す図である。

【図7】テスト・オラクルによって適用されるルールを定義するための、ドメイン固有言語でのルール作成コードの例を示す図である。

【図8】カスタム・ルール・ツリーの出力をレンダリングするためのＧＵＩビューのさらなる例を示す図である。

【発明を実施するための形態】

【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】

【数1】

【0146】

上記の例では、ＬｏｎｇｉｔｕｄｉｎａｌＤｉｓｔａｎｃｅ（）およびＶｅｌｏｃｉｔｙＡｌｏｎｇＲｏａｄＬａｔｅｒａｌＡｘｉｓ（）は予め定められたエクストラクタ関数であり、「ａｎｄ」、Ｅｖｅｎｔｕａｌｌｙ（）、Ｎｅｘｔ（）、およびＡｌｗａｙｓ（）などの関数は原子アセッサ関数である。関数ＡｇｅｎｔＩｓＯｎＳａｍｅＬａｎｅ（）は、所与のエージェントが自エージェントと同じ車線にいるかどうかを判定する、シナリオに直接適用されるアセッサ関数である。

【0147】

ここで、ＮｅａｒｂｙＡｇｅｎｔｓ（）は、自エージェントまでの距離閾値を満たす他のエージェントを識別する、時間変化するイテラブルである。これは、自エージェントと他の各エージェントとの間で、自エージェントからの距離に基づいて適用されるルール・アクティブ化条件の一例である。

【0148】

上記の例はＡＶスタックのテストを考えているが、本技術は他の形態の移動ロボットのコンポーネントをテストするために適用されることができる。たとえば、内外の工業地帯で貨物を運ぶための他の移動ロボットが開発されている。そのような移動ロボットは人が乗っておらず、ＵＡＶ（無人自律車両：ｕｎｍａｎｎｅｄ ａｕｔｏｎｏｍｏｕｓ ｖｅｈｉｃｌｅ）と呼ばれる移動ロボットのクラスに属する。自律型の空中移動ロボット（ドローン）も開発されている。

【0149】

コンピュータ・システムは、本明細書で開示された方法／アルゴリズム・ステップを実行するように、および／または本技術を使用してトレーニングされたモデルを実装するように構成されてもよい実行ハードウェアを備える。実行ハードウェアという用語は、関連する方法／アルゴリズム・ステップを実行するように構成されるハードウェアのあらゆる形態／組み合わせを包含する。実行ハードウェアは、プログラマブルまたは非プログラマブルであってもよい１つまたは複数のプロセッサの形態を取ってもよく、あるいはプログラマブル・ハードウェアと非プログラマブル・ハードウェアとの組み合わせが使用されてもよい。適切なプログラマブル・プロセッサの例は、ＣＰＵ、ＧＰＵ／アクセラレータ・プロセッサなどの命令セット・アーキテクチャに基づく汎用プロセッサを含む。そのような汎用プロセッサは、典型的には、プロセッサに結合されたまたは内蔵するメモリに保持されたコンピュータ可読命令を実行し、それらの命令に従って関連するステップを実施する。他の形態のプログラマブル・プロセッサは、回路記述コードを通じてプログラム可能な回路構成を有するフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）を含む。非プログラマブル・プロセッサの例は、特定用途向け集積回路（ＡＳＩＣ）を含む。コード、命令などは、必要に応じて一時的媒体または非一時的媒体（後者の例は、ソリッド・ステート、磁気および光学ストレージ・デバイスなどを含む）に記憶されてもよい。図１の実行時スタックのサブ・システム１０２～１０８は、プログラマブル・プロセッサもしくは専用プロセッサ、またはその両方の組み合わせで、車両に搭載されて、またはテストなどのコンテキストでは非車載コンピュータ・システムで実装されてもよい。シミュレータ２０２およびテスト・オラクル２５２などの図２の様々なコンポーネントも同様に、プログラマブル・ハードウェアおよび／または専用ハードウェアで実装されてもよい。

【図1A】

【図1B】

【図1C】

【図2】

【図2A】

【図3A】

【図3B】

【図4A】

【図4B】

【図4C】

【図5】

【図5A】

【図5B】

【図5C】

【図6A】

【図6B】

【図6C】

【図6D】

【図7】

【図8】