JP7428988B2 - 自律自動車の制御ユニットを修正するための方法およびシステム - Google Patents

Description

本発明は、自律自動車の制御ユニットを修正する（特に－さらに－開発する）方法に関し、ここで、当該自律自動車は基本的センサを装備し、ここで当該基本的センサによって記録されたデータによって、当該制御ユニットは自律運転モードで自律自動車を制御することができる。本発明はまた、自律自動車の制御ユニットを修正するためのシステム、ならびに、対応するにコンピュータプログラム製品およびコンピュータ可読媒体に関する。

自律車両開発の安全性試験は、工程の重要部分である。すべてが確実に整備されていない状態で道路に出ると、特に公道では、自律自動車の制御システムが準備できていない状況につながる可能性が有り、安全性ドライバが介入しなくてはならなかったり、さらに悪いことには、事故が発生したりといった結果になることがある。従って、安全性テストのためのいくつかの異なるアプローチが、従来技術から知られている。

上記の理由に基づいて、広範な試験が行われなければならない。そのため、多くのアプローチが、自律自動車の制御ユニットの開発を支援し得るシミュレーション技術で知られている。

特許文献１では、自律車両のテスト事例を生成するための方法およびデバイスが開示されている。テスト事例生成は、中央のデータベースに基づき、そこのデータは往来の任意の種類の実車から得られる。この文書のアプローチの不便な点は、この種のテスト事例生成が基本的な制御ユニットの開発には適していると考えられるが、予期していない事例の扱いには適していないと考えられることである。特許文献２では、上記の文書に対応して、自律車両のためのソフトウェアをテストするための方法と装置が開示されている。

様々な状況をシミュレーションするためのハイブリッドシミュレーション技術が、Ｆｒａｎｃｋ Ｇｅｃｈｔｅｒ ｅｔ ａｌ．： Ｔｏｗａｒｄｓ ａ Ｈｙｂｒｉｄ Ｒｅａｌ／Ｖｉｒｔｕａｌ Ｓｉｍｕｌａｔｉｏｎ ｏｆ Ａｕｔｏｎｏｍｏｕｓ Ｖｅｈｉｃｌｅｓ ｆｏｒ Ｃｒｉｔｉｃａｌ Ｓｃｅｎａｒｉｏｓ； ＳＩＭＵＬ ２０１４， Ｔｈｅ Ｓｉｘｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ａｄｖａｎｃｅｓ ｉｎ Ｓｙｓｔｅｍ Ｓｉｍｕｌａｔｉｏｎで開示されている。

Ｅｌｓｅｖｉｅｒ ２０１１に提出された査読前原稿である、さらなる記事（Ｆｒａｎｃｋ Ｇｅｃｈｔｅｒ ｅｔ ａｌ．： ＶＩＶＵＳ： Ｖｉｒｔｕａｌ Ｉｎｔｅｌｌｉｇｅｎｔ Ｖｅｈｉｃｌｅ Ｕｒｂａｎ Ｓｉｍｕｌａｔｏｒ： Ａｐｐｌｉｃａｔｉｏｎ ｔｏ Ｖｅｈｉｃｌｅ Ｐｌａｔｏｏｎ Ｅｖａｌｕａｔｉｏｎ）は、仮想現実を構築するためのフレームワークを開示する。不便なことに、このシミュレータは、多くの工程で人による相互作用を必要とする。他のシミュレーションのフレームワークの開示は、以下のリンク先で見つけることができる。
●ｈｔｔｐｓ：／／ｕｋ．ｍａｔｈｗｏｒｋｓ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ａｕｔｏｍａｔｅｄ－ｄｒｉｖｉｎｇ／ｆｅａｔｕｒｅｓ．ｈｔｍｌ
●ｈｔｔｐｓ：／／ｕｋ．ｍａｔｈｗｏｒｋｓ．ｃｏｍ／ｈｅｌｐ／ｄｒｉｖｉｎｇ／ｅｘａｍｐｌｅｓ／ｍｏｄｅｌ－ｒａｄａｒ－ｓｅｎｓｏｒ－ｄｅｔｅｃｔｉｏｎｓ．ｈｔｍｌ
●ｈｔｔｐ：／／ｗｗｗ．ｖｃｒａｓｈｕｓａ．ｃｏｍ／

シミュレーションフレームワークは、特許文献３で開示されている。このフレームワークでは、多くの類似のシナリオが生成される元となる、マスターシナリオファイルが作成される。さらなるシミュレーションフレームワークは、特許文献４、特許文献５、特許文献６、特許文献７、および特許文献８に開示されている。

既知のアプローチを考慮して、自律自動車の制御ユニットを、予期していない状況に可能な限り上手く対応できるように、従来技術のアプローチよりも効率的な方法で修正（さらに開発）することができる方法が求められている。

ＵＳ２０１７／０１３２１１７Ａ１ ＵＳ２０１７／０１３２１１８Ａ１ ＤＥ１０２００７０５３５０１Ａ１ ＤＥ１０２００７０５３５００Ａ１ ＤＥ１０２００８０２７５２６Ｂ４ ＤＥ１０２０１１０８８８０５Ａ１ ＵＳ２０１６／０２１０３８３Ａ１ ＵＳ２０１７／０１６１４１４Ａ１

本発明の主な目的は、自律自動車の制御ユニットを修正するための方法を提供することであり、その方法は、可能な限り広範囲にわたって従来技術のアプローチの不便な点から解放されるものである。

本発明の目的は、自律自動車の制御ユニットを、予期していない状況に可能な限り上手く対応できるように、従来技術のアプローチよりも効率的な方法で修正（さらに開発）することができる方法を提供することである。従って、本発明の目的は、通常シミュレータでは構築できず、一般に安全性技師によって（人工的に）生成される事例ではカバーされないシナリオ（予期していない事例）に基づいて、自律自動者の制御ユニットをさらに開発することを可能にすることである。

基本的に、本発明の目的は、自律自動車の制御ユニットにおいて、さらなる開発を行うことである。換言すると、予期していない状況に対してより迅速にかつより良く対応できるようにするのは、基本的な制御フレームワークを、通常の、日常的なシナリオを多数含むデータベースの活用によって開発した後が好ましい。

本発明の目的は、請求項１に記載の方法によって達成することができる。本発明の好ましい実施形態は、従属クレーム中に定義されている。

先行技術アプローチと比較された時の、本発明に係る方法の主な利点は、本発明のフレームワークが、離脱イベントに基づいて、より具体的には離脱イベントに関する離脱レポートに基づいて構築されているという事実に由来する。離脱イベントは、予期していない状況の結果であり、自律自動車の制御ユニットによって対処することになる。離脱は、自律自動車がこれ以上それ自体では制御できないという状況に相当し、離脱イベントは、修正（さらに開発）するべき、自律自動車の制御システムのコンポーネントを、直接指し示す。

上記に引用される従来技術アプローチのいずれも、離脱イベントに関係するテスト事例を使用していない。その結果、従来技術アプローチには、自動運転の中断（つまり離脱）の原因を明らかにする機能性が存在しないが、それを分析することは、修正（改善）するべき制御ユニットの部分の効率的な同定につながる。そのため、制御の修正（改善）するべき場所を明らかにする（同定する）際に、本発明に係る方法は、従来技術アプローチよりも効率的である。本発明は、離脱前の利用可能な情報をすべて使用すること、および、シナリオテストパイプラインの有用性を最大化するために、テストの関連部分のみを再構築することによって、現実世界テストの肝要部分のみに重点を置く。

要約すると、本発明によれば、（新しい）シナリオファイルは、離脱イベントが発生したときに作成されるが、一方で、多くの従来技術アプローチ（特許文献３など）は、既存のシナリオファイルを使用して（または、既存の事例に基づく新しい事例を生成することによって）機能する。いくつかの従来技術アプローチとは異なり、本発明によれば、自動車の内蔵センサは使用されず、しかし、特別に較正されかつ車両に追加されたセンサが使用される（多くの従来技術アプローチでは、情報はブレーキ操作、ステアリング操作などの、自律自動車の内部挙動からのみ収集される）。これらのセンサの役割は、出来事を、発生した通りに再生することである。本発明によれば、走行を数回繰り返すことができるような、そして全く同じ入力を提供すると同じ出力が得られような、視覚的に良い、決定論的シミュレータを使用する。

従って、本発明を活用すると、自律自動車の制御ユニット（制御ユニット－好ましくは制御システムの一部としての－は、好ましくは、（制御）ソフトウェアによって、またはソフトウェア要素およびハードウェア要素の組み合わせによって実装される）の弱点が、非常に効率的な方法で改善することができる事に留意されたい。換言すると、離脱イベントをシミュレーションするべきイベントとして使用することによって、予期していないと考えられるイベントを捕捉し、そして対処することができる。多くの人工的に生成されたテストイベントの代わりに、基本的な状況で訓練された自律自動車の制御ユニット（これは上で、基本的な制御フレームワークと呼ばれる）を使用するシミュレータで、離脱イベントを処理することは、本発明に係るフレームワークを、高度に効率的なものにする、その理由は、単一の離脱イベントの一つ一つが、離脱の原因が何であったのかについて分析される時に、制御ユニットのコンポーネントの修正（開発）につながるからである。従って、本発明では、制御ユニットの修正（開発）は、好ましくは、（既に開発された）基本レベルの制御ユニットから開始され、それを予期していないイベントに対応できるようにする。

本発明に係る方法によれば、離脱関連（ログ）データに基づく仮想世界（およびそこのシナリオ）の構築は、好ましくは自動的に実行される。さらに、記録された（ログされた）離脱関連データに基づいて、（周囲車両を、それらの特性および挙動と共に含む）仮想シナリオも、自動的に生成される。シミュレータにおける決定論的実行に従って、離脱（自律モードの中断）の原因を、仮想的に再現、デバッグ、および修繕することができる。

本発明に係る方法によれば、好ましくは、実生活シナリオを仮想シナリオに変換するのに手作業を必要としないため、ヒューマンエラーに帰着する必要性が存在しない。このことは、また、シナリオの一部詳細は、人間の処理で追従することが非常に困難であり、または不可能でさえあるという観点からも、有利である（例えば、自律自動車以外の往来自動車を追従する場合など）。方法は、実生活シナリオの精確な再現を生成し、その精確さは、入手可能な記録を基に手作業で再現を試みることによって達成できるものでは無い。本発明に係る方法は、好ましくは、コンピュータによる力を必要とするのみであるため、利用可能なマンパワーに関係なく、効率的に規模変更を行うことができる。生成されたログファイルは普遍的であり、つまり、単一の仮想シミュレータ、または単一のシナリオテストフレームワークに左右されないことを意味し、したがって、いずれのシステムにおいても使用することができる。

本発明のさらなる利点も下記に詳述される。本発明によれば、好ましくは、（いくつかの実施形態で検証センサによって生成される）検証データを使用して、自律自動車の基本的センサに基づいて原因を明らかにすることができない事例においても、離脱の原因を見つけることが可能になる。

さらに、本発明のフレームワークでは、異なるレベルの再テストがシミュレーションで利用可能であり、ここでは制御ユニットの妥当性を修正後にチェックできる（下記の工程Ｓ７０、およびさらなる検証工程を参照）。

本発明は、換言すると、記録され、かつ後処理されたセンサデータに基づいて、実生活上の安全性シナリオを、自律車両の開発、テスト、および検証のための仮想環境で再作成する方法である。

本発明の好ましい実施形態は、以下の図面を参照して、例示によって下記に説明される。
様々なセンサを備えた例示的な自律自動車を示す。 本発明に係る方法の実施形態の工程のフロー図である。 本発明に係る方法のさらなる実施形態のいくつかの工程のフロー図である。 本発明に係る方法の別のさらなる実施形態のいくつかの他の工程のフロー図である。

本発明は、自律自動車の制御ユニットを修正する（開発し、改善する）ための方法である。本発明に係る方法で適用される自律自動車は、自律自動車の周囲のオブジェクトと環境との融合モデルが生成され得る元になる、センサデータを記録するように適合された、基本的センサを装備し、（融合モデルは、基本的センサから、例えば、基本的センサの一部であり、そして自律自動車から異なる方向に外側へ向けられたカメラから収集されるデータに基づいて、生成、－作成、構築－され）、ここで、基本的センサによって記憶されるセンサデータは、制御ユニットが、自律自動車を自律運転モードで制御すること、つまり車両操作デバイスを制御することを可能にする（自律運転モードでは、ハンドル、ペダル、および他の車両操作デバイスは、制御ユニットによって制御されている）。

従って、基本的センサは、自律自動車を自律運転モードでの走行に適したものにする。この目的のために必要とされる異なる種類のセンサは、現在利用可能な自律自動車から既知である（下記の図１の例も参照）。

図１に関して図示されるように、（外部センサ、または自律自動車の環境を検出するためのセンサ、自動車の外を「見ている」センサとも呼ばれ得る）基本的センサの最小群が存在し、これの活用により、自律走行が実現可能となる（基本センサに関しては、最小のセンサパックで、その活用により、自律自動車の周囲のオブジェクトと環境との融合モデルが生成できる）。しかし、追加的センサを使用することによって、制御はより洗練されたものとなり得る。

方法は、図２に図示される以下の工程を含む（工程の本質のみが、図２で、各工程について示される）。
－制御ユニットが第１の状態にある間に、自律自動車の自律運転モードで実行される自動テストアクション中に、基本的センサによって、センサデータが記録される。
－離脱イベントが引き金となる対応で、離脱イベント前の分析時間枠に基本的センサによって記録されたセンサデータを含む離脱関連データが、ログ（記録、ログとして記録）される。

換言すると、上記工程（図２の工程（Ｓ４０））で：自律自動車の制御ユニットの第１の状態で（つまり、制御ユニットが第１の状態である時に）、離脱イベントが引き金となって、基本的センサによって記録されたセンサデータを含む離脱関連データ（または単に離脱データ）は、自律自動車の自律運転モードで実行される自動テストアクション中に記録され、当該記録は、離脱イベントの前の分析時間枠で遂行される。

従って、第１の工程では、離脱関連データはさらなる使用のために記録される（ログされる）；この工程はオンラインで、つまり自律モードでのテスト走行中に、実行される。

その後、仮想シナリオは、離脱関連データ基づいて、分析時間枠の間に、シミュレータ装置で生成され（つまり、離脱イベント前の分析時間枠の期間に相当するシナリオが作成され）、ここで、仮想シナリオは、基本的センサの仮想対応物（つまり、現実世界の基本的センサと同じ機能性を備える仮想センサ）を有する自律自動車の仮想対応物を含み、そして、自動テストアクションに従って第１の仮想自律走行が実行され、この時、自律自動車の仮想対応物（自律自動車は、シナリオ中でそれ自身の役割を有しており、それは周囲の環境のオブジェクトおよびそれらの挙動と同様に、トラッキングされる）は、シミュレータ装置の制御ユニットの第１の状態を使用し、このことによって、第１の仮想自律走行は、仮想シナリオの離脱イベントを引き起こす（図２の工程（Ｓ５０））。自律自動車の仮想対応物は、現実の自律自動車の現実の基本的センサの相当物である、仮想センサを有する。自律自動車の仮想対応物は、シナリオの既定の開始状態から外部世界の検出を行う基本的センサのシグナルに基づいて制御され、そして、車両操作デバイスは、制御ユニットによって自律モードで制御される。

走行は自律的である、つまり、自律自動車の仮想対応物が、制御ユニットによって制御される。第１の仮想自律走行は、自動テストアクションに従って実行され、（前工程で、この－つまり同じ－自動テストアクションのデータが記録されており）、これは、自律自動車が、現実テスト時と同じ状態で始動し、そしてその後、制御ユニットによって自律的に運転－つまりここでも仮想世界で－されることを意味する。シナリオが許容可能な品質（以下を参照）で生成（構成、作成、構築）されれば、現実シナリオはうまく再現され、そして第１の仮想自律走行もまた離脱を引き起こすだろう（それは必要である、上記を参照）。

シナリオは、仮想スペースにおいても、シナリオも離脱を引き起こす、現実に非常に類似した品質で構築されなければならない。シナリオ構築を許容可能な品質で達成するためには、検証データを使用する必要があるかもしれない。このことは、制御が現実状況に基づいて離脱状態になるので重要であり、そのため、離脱を第１の仮想走行で再現するためには、周囲のアクションを可能な限り現実と類似させて構築する必要がある（このことは、離脱に帰着した、第１の仮想走行におけるシナリオの期間中の制御決定を有するのに、必要である）。

現実の出来事の再構築に関するこの品質は、最近利用可能となった再構築技術に従って達成可能である。この工程で仮想的に離脱に到達することは、さらなる工程にとって重要である、というのは、このことが、離脱関連データに基づいて仮想的に行われる離脱の原因を探るのに必要となるからである。工程（Ｓ５０）とその後に続く工程は、自動車の自律運転中に捕捉された離脱関連データに基づいて、オフラインで実行される。

従って、さらなる工程（図２の工程（Ｓ６０））で、仮想シナリオに基づいて、制御ユニットの、不適当に（不十分に）動作するコンポーネント（つまり、発生した離脱のタイプを回避するために修正されるべき、制御の部分）が同定され、ここで、離脱イベントは、制御ユニットの、不適当に動作するコンポーネントの不適当な動作によって引き起こされている。制御ユニットの制御ユニットのコンポーネントは、制御ユニットの各々の（自己完結型の、スタンドアローンの）パーツであるかもしれず（例は下記を参照）、サブユニットと呼ばれるかもしれない。制御ユニットと同様に、コンポーネントは、制御ソフトウェアの多少なりとも分離されたブロック（モジュール）によって、またはソフトウェアとハードウェアとの組み合わせによって、実装されても良い。

その後、制御ユニットの第１の状態に基づいて、制御ユニットの第２の状態を生成（制御ユニットの第１および第２の状態はまた、それぞれ開始状態およびアップグレード状態とも呼ばれ得る）し、それは、制御ユニットの、不適当に動作するコンポーネントを修正すること（つまり、制御ユニットの第２の状態は、その第１の状態から、制御ユニットの、同定されたコンポーネントの修正によって得ることができる）と、そして、自動テストアクションに従って第２の仮想自律走行が実行され、この時、自律自動車の仮想対応物が、シミュレータ装置の制御ユニットの第２の状態を使用すること（図２の工程（Ｓ７０））と、離脱イベントが、第２の仮想自律走行で回避されるか否かをチェックすることと、そして、離脱イベントが第２の仮想自律走行で回避される場合に、制御ユニットの修正されたコンポーネントを保存することと、によって行われる。離脱が第２の仮想自律走行で回避されなかった場合（つまり仮想自律走行が行われることの第１のチェックの間に）、修正は継続され得る。修正の後の段階で、新しい仮想自律走行が実行され得る。「第２の」仮想走行（さらなる仮想走行と呼んでも良い）が最終的な成功修正後に実行される仮想走行に対応するように、修正手順を考えることができる。

従って、中間の仮想走行を、修正（開発）の一部として考えても良い。従って、制御ユニットの、同定されたコンポーネントの修正（開発）のゴールは、離脱が改善された制御を使用する自律自動車によって回避されるような、制御の改善を行うことである。第２の仮想自律走行も、自動テストアクションに従って実行される（それは自律モードの現実テスト時と同じ状態から始動する）が、自律自動車の仮想対応物は、制御ユニットの第２の状態（つまり修正によって得られた改善バージョン）によって操作される。適切な修正（開発、改善）が実行された、アップデートされた制御ユニットで離脱を回避することが、ゴールである。

基本的に、２つの別々の原因が、自律自動車の安全性ドライバによる、または制御ユニットそれ自身による、中断に相当する離脱という結果になる得ることに注意することが重要である（以下の例を参照）。第１のタイプの原因の場合には、センサによって実行された検出は正確であったが、その正確な融合モデルの認識にもかかわらず、不正な決定が制御ユニットによって行われた。

このタイプの原因の例は、以下の通りである：センサは、速度限界を指定する道路標識（交通標識）に基づいて、最高速度が５０ｋｍ／ｈであって良いと正しく検出したが、その正確な検出にもかかわらず、速度を下げることが制御によって決定されなかった。このタイプの原因の場合には、基本的センサが、シミュレータにシナリオを再現するのに十分である（つまり、随意に適用される検証センサは必要ではない）。そのため、図１に図示される例示的センサパックが、離脱の上記タイプを再現するのに十分であり、これに対しては検証センサは必要無い（第１のタイプの離脱）。第１のタイプの離脱の場合には、基本的センサによって分析時間枠中に生成された融合モデルは、許容可能であるとわかる、つまり、融合モデルは不変のままである。そのため、もし離脱が融合モデルの不正確性によって引き起こされたものでければ、融合モデル（全体）が許容可能であると考えられ、制御ユニットの制御決定が修正されるべきであると判定することができる。従って、制御ユニットの同定されたコンポーネントを修正した後、第２の走行が同じ融合モデルで実行される（第１のタイプの離脱の場合には、修正されたコンポーネントは、融合モデルを構築するための主要因では無く、制御決定を下す際に加味されるものである）。

別の（第２の）タイプの原因の場合には、検出が正確（正しい）ものではなく、そのため、不正確な融合モデルがリアルタイム融合中に生成され（換言すると、分析時間枠中に基本的センサによって生成された融合モデルは、分析時間枠の少なくとも一部の間に許容不可能であることがわかり）、その後、自律自動車は、この不正確な融合モデルに対して反応し、そして、離脱は、不正確な融合モデルに対するこの反応の結果であった（自律自動車の距離推定－融合モデルの一部－が不正確である、下記の例を参照）。この場合、その後の記録の分析に基づいて、正確な融合モデルを生成することはできるが、検出の不正確性は、利用可能な記録とログに基づく方法を活用することでは修正できないので、シミュレータの事例を再現するのには、検証データ（例えばライダーデバイスのデータ、詳細は下記を参照）が必要となる場合があるだろう。

このような離脱は、自律自動車の制御ユニットが、安全性ドライバに制御を戻し始め、不定状態になった時にも、起こり得る。この場合、簡易的な例としては、高速道路用に設計された制御フレームワーク（ソフトウェア）が、自律自動車の前の車線や路面を安定して検出できない場合が挙げられる。

上記詳細によれば、第２のタイプの離脱の場合には、不正確な融合モデルは、融合によって、並びにシナリオの再構成によって、リアルタイムで生成された。制御ユニットの、不適当に動作するコンポーネントの同定が正しく、その修正が成功すれば、融合モデルは、改善された制御モデルに従って正確に再構成され－融合モデルは分析時間枠全体の長さで許容可能になり－（例えば、距離推定が制御ユニットの修正前に不正確であったならば、以前は融合によって誤った推定距離に設置されていたオブジェクトは、修正後には正確に配置されるであろう）、そして、離脱は回避されるだろう（検証データが第１のタイプの離脱のために使用される場合については、下記を参照）。

図２の上に記載された実施形態で、制御ユニットの第２の状態（いわゆる第２の制御ソフトウェア状態）の、シミュレータで第２の仮想自律走行を実行することを伴うテストは、最終工程である。

第１のタイプの離脱の場合には、制御ユニットが、制御ユニットの第１の状態の失敗走行（走行して離脱してしまう）時と同じである、融合によって作成されたモデルスペースで第２の状態を有するように修正された時に、自律自動車はシミュレータ内で走行する。上述したように、第１のタイプの離脱の場合には、離脱は不正確な融合モデルによって引き起こされたものではない。制御ユニットの第２の状態によって、第２の仮想自律走行が実行されると、離脱イベントを回避されることが期待される、つまり、シナリオが重大ポイント後も継続する。

第１のタイプの離脱を有するある実施形態では、好ましくは、上記の工程後にさらなる任意の実証工程が続く。この工程で、制御ユニットは再度現実の記録上でテストされ、この現実の記録は、離脱レポートにつながるものであり、つまり離脱関連データの一部である。これは、追加的な実証工程であっても良く、これを活用して制御ユニットの安全性を増強することができる。これは、制御ソフトウェアがより詳細にトレーニングされ、より多くのタイプのデータでテストされると、つまり状況がより良く再現されると、結果が良くなるからである。従って、この実施形態では、分析時間枠において基本的センサによって生成（作成、構築）される融合モデルが、分析時間枠において許容可能であることが判明した場合に、第２の仮想自律走行を実行した後に、第３の仮想自律走行が、自動テストアクションに従って実行される。この時、自律自動車の仮想対応物が、シミュレータ装置の制御ユニットの第２の状態を使用する、自律自動車の仮想対応物の基本的センサの対応物に、離脱関連データ（基本的センサのセンサデータと、随意に他のログタイプのデータ）を与える。

これらのさらなる任意の工程で、自律自動車の制御ソフトウェア（ユニット）は、特別な状態でテストされ、ここでは、センサデータの全ては元の記録に由来する（つまり、元のセンサデータが利用される）。しかし、元のコマンド（ハンドル角度、ペダル位置）は実行されない；これらのパラメータは、離脱レポートで、ログの以前のデータと比較されるのみであり、そしてその結果はチェックされ、比較が特定の限界値間にある場合は受け入れられる。車が元の離脱の近くで異なる挙動をとるだけでなく、より長いセクションで異なる走行を行い、したがって、重大な状況は異なる挙動によって回避されるということも起こり得る。このことは、現実の記録が使用された時の現在の工程で行われたコマンドを、シミュレータで制御ユニットの第２の状態がテストされた、以前の工程のログのコマンドと比較することによってテストできる。このことは、自動車がその元の経路から大幅に逸脱すると記録が非同期的になるため、テストする上で簡単な方法では無い。しかし、制御ユニットの第２の状態のシミュレータテスト中に、制御ユニットによって実装された改訂後の制御ソフトウェアが元の記録によってテストできるのか否かを、判定できる。

路上テスト中、自律車両は、安全性ドライバによって手動で、または自律モードでのいずれかで、運転され得る。自動車が自分自身で運転を行う間、いくつかの異なるセンサのデータを使用して、制動、加速、または操舵を行うか否かの決定を下す。自律自動車上で使用されているセンサは、カメラ、レーダー、ライダー、またはＧＰＳであるかもしれない；ＨＤマップデータまたは任意の他の情報源（図１に図示される下記の例を参照）も、決定のために使用しても良い。しかし、主にセンサの待ち時間によって、すべてのセンサが、高速道路上などの高速運転に適しているわけではない（詳細は下記を参照）。

自律自動車（３０）は、例にある以下のセンサを装備する（この外部センサパックは、高速道路上の走行のために最適化されているが、他のタイプの道路にも適用可能である）。センサのパラメータは以下の通りである。位置（ｐｏｓ）値は、「前方（ｘ）、左（ｙ）、上方（ｚ）」の座標系で、メートルで与えられ、原点（［０、０、０］座標の位置）は、自動車の後軸の中央が地面に対して突き出するように、配置される。ヨー、ピッチ、およびロール値は、度を単位として示される。
●Ｆ＿ＲＡＤＡＲ＿Ｃ，ｐｏｓ：［３．６，０，０．７６］，ヨー＿ピッチ＿ロール：［０，－２０，０］（図１のセンサ（１０）で、（自動車のフロントパネル上の）元の場所から３．６ｍの場所に一定の高さで配置される；ピッチ値は－２０で、つまり道路に向かって僅かに傾斜していることを意味する）
●Ｆ＿ＭＩＤＲＡＮＧＥＣＡＭ＿ＣＬ，ｐｏｓ：［１．８８５，０．２，１．２］，ヨー＿ピッチ＿ロール：［０，－２，０］（図１のセンサ（１２））
●Ｆ＿ＭＩＤＲＡＮＧＥＣＡＭ＿ＣＲ，ｐｏｓ：［１．８８５，－０．２，１．２］，ヨー＿ピッチ＿ロール：［０，－２，０］（図１のセンサ（１６）；センサ（１２）と（１６）は、互いから４０ｃｍの距離内の前方対称軸に対して対称的には配置される）
●Ｆ＿ＬＯＮＧＲＡＮＧＥＣＡＭ＿Ｃ，ｐｏｓ：［１．８８５，０，１．２］，ヨー＿ピッチ＿ロール：［０，０，０］（図１のセンサ（１４）で、このカメラセンサ（１４）は、前方対称軸上、つまり、センサ（１２）と（１６）の中間に配置される）
●Ｍ＿ＷＩＤＥ＿Ｌ，ｐｏｓ＿メートル：［０．０３，０．７５，１．２］，ヨー＿ピッチ＿ロール＿度：［－８５，３０，０］（図１のセンサ（２４））
●Ｍ＿ＷＩＤＥ＿Ｒ， ｐｏｓ＿メートル：［０．０３，－０．７５，１．２］，ヨー＿ピッチ＿ロール＿度：［８５，－３０，０］（図１のセンサ（２６）で、センサ（２４）と（２６）は、センサ（１２）、（１４）、および（１６）と同じ高さで、自動車の２つの側面に配置される）
●Ｂ＿ＭＩＤＲＡＮＧＥ＿Ｃ，ｐｏｓ＿メートル：［０．１５，０，１．４５］，ヨー＿ピッチ＿ロール＿度：［１８０，－７，０］（図１のセンサ（２２）で、このセンサは、センサ（１２）、（１４）、（１６）、（２４）、（２６）よりも高い高さで、前方対称軸上に配置される）
●ＩＭＵ＿ＰＲＩＭＡＲＹ（図１のセンサ（１８））
●ＧＰＳ＿ＰＲＩＭＡＲＹ（図１のセンサ（２０）；センサ（１８）と（２０）は、前方対称軸上に配置される）。

センサ（１０）、（１２）、（１４）、（１６）、（２２）、（２４）、および（２６）は、センサの位置から始まり広がって行くアーチ記号によって表示される。

センサ（１０）は、自動車（３０）のフロントパネルに配置されたレーダーである。自律モードで融合にレーダーセンサ（１０）を用いることは、任意である。自動車の前方の距離計測のために、センサ（１２）と（１６）を使用するのが好ましいかもしれない；センサ（１２）と（１６）は、自動車の前のオブジェクトの、自動車からの距離を計測するのに適している、ステレオカメラペアを構成する、中距離カメラである。センサ（１４）は、長距離用－例えばピンホールタイプ－のカメラであり、遠方のオブジェクトがステレオカメラの実際の画像では非常に小さいので、好適に使用される（ビデオ映像が自動車にセンサとして配置されたカメラによって記録され、その映像は画像ごとに分析することができる）。長距離のカメラセンサ（１４）を活用し、融合時により好ましい、より良い画像を得ることができる（自律自動車の前の自動車に関する特定の情報、例えば、自動車の色、自動車照明および方向指示器の使用などを取得するために）。図示される例示センサ（１０）、（１２）、（１４）、および（１６）は、自律自動車の前方の環境を探るために使用することができる。

さらに、自動車（３０）は、自動車の側方のオブジェクトを確認するためのカメラ、好ましくは魚眼（側方確認用）カメラである、センサ（２４）と（２６）を装備する。自動車が自律自動車（３０）を追い越すか、または自律自動車（３０）が別の自動車を追い越す場合、それを、これらのカメラによって記録することができる。図示される例では、センサ（２２）も自動車（３０）上に配置され、そのセンサ（２２）は、自動車（３０）の後方を確認するカメラである。このカメラセンサ（２２）を活用して、自律自動車（３０）後方の出来事は探ることができる（例えば、接近自動車、または、カメラセンサ（２２）の画像上ではどんどん小さくなって行く、自動車（３０）よりも速度の低い自動車）。

自動車（３０）の位置と傾斜を計測するために、ＧＰＳ（全地球測位システム）センサ（２０）と傾斜センサ（１８）（ＩＭＵ－慣性計測装置）が、自動車（３０）上に配置される。これらの位置は、図１に図示される。

例における基本的センサは、レーダーセンサ（１０）、ピンホールカメラセンサ（１４）、傾斜センサ（１８）、およびＧＰＳセンサ（２０）以外、全て自動車（３０）上に図示されるセンサであって良い。しかし、これらのセンサも基本的センサの一部である場合には、融合をより良い精度で行なうことができる可能性が高い。基本的センサとして機能するには、より少ないセンサ、または他のセンサ（例えばセンサ（１２）と（１６）の代わりに単一のカメラセンサ）で十分であるかもしれない。同様に、センサの数を増やして、離脱関連データの一部になるデータを提供しても良い。従って、離脱関連データは、様々なセンサの記録およびログを含み得る。

随意に、自律自動車は、自律自動車の車両操作デバイス、特に、ハンドル、アクセルペダル、およびブレーキペダルの状態を計測するように適合された内部センサを装備する（車両操作デバイスは、車両の操作に必要な他のデバイスであるかもしれず、そして自律自動車を自律モードで運転する時に制御を必要とする）が、これらのセンサを使用することは必須では無く、また、これらのセンサは必ずしも自律自動車に配置されていない。自律自動車では、車両操作デバイス（例えばハンドル、アクセルペダル、およびブレーキペダル）は、制御ユニットによって操作されるが、これらの車両操作デバイスの状態は、必ずしも継続的にチェック（計測）されない。内部センサは、検証センサとしての役割を有し得る。

予期していない何かが起こるか、または車両が本来そうあるべきでない操作を試みる場合に、安全性ドライバが介入し、そして、車両の部分的な、または完全な制御を取り戻すことができる。これらの事象は離脱と呼ばれ、そして、離脱イベントが発生すると、制御の返還までに何が起こったのかに基づいて、車両によってレポートが生成される（このレポートの要素－より一般的には離脱関連データと呼ばれる－は、その後本発明によって使用される）。レポートは、制御が取り戻される時に、好ましくは自動的に、生成される。レポート（離脱関連データ）は、以前の分刻みの時間（つまり、適切に選択された時間域内）からの記録センサデータと車両からのログを全て含み、ここでは、異なるソフトウェア状態と可変値を観察することができる。このレポートを、離脱の理由を分析するために、後に使用することができる。

自律自動車の安全性シナリオテストは、シミュレータの仮想環境を提供することによって、自律自動車の制御の開発工程の迅速な反復を可能にする。シミュレータの仮想環境では、車両制御ソフトウェアを異なる状況で検証することができ、また、開発者の期待に対してのみならず、安全性要件に対しても、テストすることができる（シミュレータを、現実の路上テストだけで無く、制御ソフトウェアを開発するために使用することは、効率的である）。フォトリアリスティックなシミュレータは、リアルタイムでまさにそこにある位置および状況で現実世界を再作成するので、拡張可能的なテストにとって重要である。本発明の異なるフレームワーク（シナリオパイプラインと呼ばれ得る）を使用すると、異なる道路を細かな詳細まで作成することができる。

スタンドアローンのシナリオエディタツールは、そのようなタスクの（つまり、シナリオを仮想的に生成する）ために使用されている。車両、歩行者、および動物は、まず最初にシナリオに配置され、その後、さらに道路上に－それらの動きに応じて－パラメータで表記される。いくつかの異なるオプションが車両に対して使用可能であり、例えばは自動車の型、色、そして付属品がスポーニング（ｓｐａｗｎｉｎｇ）前に定義できる。最初のスピードを設定し、そして後ほど、様々なタイマーまたはイベントに基づいて変更しても良い。

シナリオ中に多くの動的試験を定義することができるので、非常に複雑な状況ですら作成することができる。仮想シミュレータのシナリオの実行中に、いくつかの条件がチェックされ、自律（自己）車両が想定通りの挙動をとるかが確認される、例えば２－３例を挙げると、車線と目標速度を維持しているか、追い越しを実行するか、そして安全に高速を出ることができるか、などである。

ソフトウェアによって修正（開発）された自律車両制御ユニットは、同一コンピュータ上での動作、またはネットワーク上での接続のいずれかによって、シミュレータに接続することができる。シミュレーション中、シミュレータは、実生活で発生するであろう方法と同じ様に、車両制御ソフトウェアによってリクエストされる、全てのセンサデータを提供し（これらのデータ－例えば、カメラの画像、範囲値－の全ては、シミュレーションされたシナリオに基づいて生成され、元々は、テスト中に自律車両のセンサデータに基づいて生成されたものである）、そして、車両制御ソフトウェアは、返されたデータを路上テスト中と同じ方法で処理する。換言すると、完全なシナリオが、（自律自動車それ自体、ならびに自律自動車の周囲からの他のオブジェクトを含む、参加自動車と共に）シミュレータで生成され、そして、自律自動車のセンサの仮想対応物は、シナリオ、つまり周囲の仮想世界の、計測および記録を行なう。制御ソフトウェアは、シミュレータに制御メッセージを送り返すことができ、シミュレータはメッセージに従って、車両ソフトウェアから受信した、加速、制動、および操舵のリクエストコマンドを実行することができる。

シミュレータでこのテスト方法を使用することによって、路上テストを実施する前に、自律車両ソフトウェアの全ての関連モジュールが信頼性があり、かつ動作可能であることを、確実にすることができる。シミュレータで現実世界の位置をモデル化することができるので、制御ユニットは、後に実生活でテストされるのと同じ道路区間上さえ、仮想的にテストすることができ、通常特定の位置に生じる任意の問題に備えることができる。

人工的な状況を作成することは、開発が、実生活で非常に稀にしか起こらない異なるコーナー事例をカバーするのに役立つ可能性があるが、これらの状況は通常、影響力がとても小さく、隔絶された場所で特定の機能性をテストするのみである。そのような状況は一般に従来技術アプローチに見られ、そこでは、コーナー事例は、テスト事例の膨大な数を根拠として、カバーされるものと意図されている。しかし、現実のコーナー事例は生成するのが非常に難しく、単純にテスト事例の数を多くの数に増加させればカバーできるというものではない。この困難は、離脱が発生した時の事例に基づいて開発を行う本発明を活用することによって、つまり、特別なコーナー事例捕捉を本発明によって行うことによって、解決する。

路上テストを実施している間に、自己（自律）車両のまわりにいくつかの他の車両が存在することがあり、そして、それらが予期していない操作、制動、または操舵などを直ちに実行することがある。（路上テストの）記録、および路上テストからの離脱レポートを全て使用することによって、特定の事例を再作成し、そして実生活でそれらが発生するそのままでテストすることができ、そして、人工テストと比較して、例（制御ユニットの機能性）のより広い範囲をカバーする。このことは、開発者に、同じシナリオを仮想的に繰り返し、可能性のある問題をさらに分析し、そしてそれらを分析に従って修繕するというオプションを与える。コーナー事例は離脱イベントを介して「捕捉」される、その理由は、離脱イベントが常に、さらに開発（修正）されるべきである制御（融合アルゴリズム、制御プロトコル、自律自動車に配置されるセンサからの不十分な情報）の動作によって引き起こされるからである。

本発明に従い、以前失敗した全く同じ状況で、車両制御ソフトウェアの変更を、検証およびテストでき、そして、なされた変更が実際にソフトウェアの品質を改善したのか否かを確認できることは、非常に好ましい。すなわち、換言すると、離脱は、制御ソフトウェアの新規バージョンが同じシナリオ上でテストされた時に、改善された制御ソフトウェアによって、回避されるが、この仮想シナリオは、－ちょうど実生活におけるような－離脱を以前に示し、その後に、制御ソフトウェアの適切なコンポーネントが修正されたシナリオである。このことは、仮想シミュレータで容易に行うことができるため、もはや、特定の場所に運転して行くために時間を費やす必要は無く、また現実世界で同じ状況を再作成しようと試みる必要もない。この可能性は、開発に費やされる時間とコストを低減する（コーナー事例、したがって、制御ソフトウェアの開発が必要とされる弱点を、離脱を通じて大変有効的に捕捉することができる）だけでなく、他の方法では再現できなかっただろういくつかの事例を、テストすることを可能にする。多くの参加者を伴う出来事は、この良い例であるかもしれない。例えば４台の自動車を考える：高速でのカーブにおける、これらの位置を再現することはできない。

環境に対する小さな相違は大きく影響する可能性があるので、仮想環境で特定の状況を再作成することは、（例えば、同じソフトウェア状態をテストし、離脱イベントを取り戻すための）決定論的な結果への鍵となる。この仕事を手仕事で行うことは、非常に時間を消費するだけでなく、不可能ですらあるだろう（例えば、他の自動車の動きを追従する時に）。したがって、この処理は望ましい結果を達成するための唯一の方法である。

以下の部分で、シナリオ生成のための融合を詳細に説明する。当技術分野で使用される種類と一致するように、（融合データ作成の結果である）融合モデルは、融合によって作成された空間のためのモデルに関連して使用されるであろう（それは、異なるソースのデータが融合される時に、その工程自体に対して使用されるかもしれない）。スペースのためのオフラインで作成されたモデルは、単にモデルスペースと呼ばれる（従って、モデルスペースは後処理によって生成される）。両モデルは、周囲に関する（オンラインでは制御のための；オフラインでは再構築のための）必要な情報を全て含む。融合は、様々なカメラ、センサ、ＧＰＳ、ナビゲーション、およびマップデータに基づいて構成されると共に、リアルタイムでアップデートされ、そして、自律車両制御ロジックによって使用されることで何をするかが決定される（制御ロジックは、環境のこの情報に基づいて、どのようにして継続するかに関する決定を下す）。

融合データ作成のプロセスは本文書の範囲内ではないが、いくつかの態様を考慮に入れるべきである。制御ロジックは、少なくとも１０Ｈｚを超えて実行する時には安全であると考えられ、したがって、たとえ高速であっても、比較的迅速に決定を下すことができる。例えば１３０ｋｍ／ｈでの走行は、３．６メートルごとに（１０Ｈｚで）決定を下す機会を得ることになり、そしてそのため、安全であると考えられる。この性能を達成するためには、この時間枠中に信頼できるデータを生み出すことができるセンサのみを使用することができ、これらのセンサは、そのためデータをリクエストするシグナルをトリガとして、センサの捕捉および分析アルゴリズムの処理により融合モデルがアップデートされ、そして制御決定が下されるのに十分な時間を与える必要があり、これら全てが最長１００ミリ秒以下で行われるべきである。自律自動車上で使用できる通常のカメラは、１５－２１ミリ秒の待ち時間を有しており、他方、通常のレーダーは、アルゴリズムによって使用され得るデータを生成するのに、２５～４５ミリ秒かかり得る。従って、上に引用された期間は、トリガからセンサデータの捕捉までの時間をカバーする。センサデータは、固定の時間間隔で区切られた時間ごとの制御によって利用され、そのため、分析および制御決定のために割り当てることが可能な時間は、上述の待ち時間によって異なる。

高速道路のある区間をテストする時、自動車に配置されたセンサ（センサシステム）は、高スピードに起因する問題に対処しなければならない。基本的な態様は、カメラの検出範囲（視認の範囲）、ならびに制御ユニットの反応時間である。重要な問題は、カメラによって記録された画像では、１００メートルの距離にある自動車が非常に小さく見える場合があるため、検出アルゴリズムにおいて不正確性を引き起こすかもしれないということである。他方、市内走行の場合には、交通の速度ははるかに遅いが、環境ははるかに多様的であり（交通標識、交通信号、横断歩道、自転車道など）、そして、交通の参加者の数はより多くなり、多くの様々な方法で行動する。高速道路では、自動車は車線に沿って走行するか、あるは車線変更を行うかであるが、市内では、多数の交差点、出口車線などがある。歩道には、多くの歩行者、自転車搭乗者、ローラースケート搭乗者、あるいは他の交通手段搭乗者がおり、彼等の行動は容易に推定できず、および／または一様ではない。

本発明によれば、もしシナリオを、基本的センサ（センサベースパックとも呼ばれる）に基づいて適切に再現できない場合に、（例えば検証センサによって記録された）検証データを、好ましくはある実施形態で使用することができる。上述される通り、検証データの使用は、第２のタイプの離脱の場合、つまり不正確な融合モデルの生成が明らかになった場合に、必要となるかもしれない。検証データは、シナリオの少なくとも一部（その部分は、基本的センサのデータに基づいて十分に良い品質で再現できない部分であり、分析時間枠全体のためのスペースの一部であるかもしれないが、分析時間枠の一部のための、周囲のスペースの全部または一部であるかもしれない）を検証するために、つまり融合モデルの不正確な詳細を探りそして同定するために、適用される。

検証データは、データおよび／または、必ずしも融合には使用されないが、信頼できる方法で環境の地上検証データを提供することができるデータのソースおよび／またはデータの一種である。

検証データは、制御用にリアルタイムで使用されていない任意の（派生）データであって良い。たとえそのデータが遅く、リアルタイムでは使用できないとしても、検証データは、そのスペースのための、オフラインで生成されるモデルの品質を改善するのに、つまり、周囲の環境とオブジェクトのより精確な描写を作り出すのに、役立ち得る。

検証データを作り出す検証センサ（検証センサ（ｖａｌｉｄａｔｉｏｎ ｓｅｎｓｏｒ））は、例えばレーダーまたはライダーかもしれないが、生のビデオ映像を、オフラインで適切に処理される検証データのためのソースとして利用することもでき（この場合、検証データは、同じセンサ、すなわちカメラ、のデータから得られ、その映像は、自動車が、別の処理をされた自律モードで走行する時のリアルタイム融合中に使用され）、その理由は、最も遅い検出アルゴリズムであっても、シナリオ生成（つまり、シナリオ再現時）の処理部で実行可能であるからであり、そして、これらは、実際のところ、リアルタイムで出力を作り出す必要がないため、速度制限下でリアルタイムで使用されるものよりも、はるかに精確なものになり得る。

従って本発明に係る方法の実施形態において、好ましくは、分析時間枠に基本的センサによって生成された融合モデルが、分析時間枠の少なくとも一部で許容可能でないことが判明した場合には、検証データは、分析時間枠の少なくとも一部の間に、検証シナリオ部の検証モデルを、検証シナリオ部の融合モデルと比較することに基づいて、仮想シナリオの検証シナリオ部を検証するために、仮想シナリオの生成の際に使用（適用）され、そして、制御ユニットの、不適当に動作するコンポーネントは、分析時間枠の少なくとも一部の間の、検証シナリオ部の検証モデルと、検証シナリオ部の融合モデルとの比較によって同定され、（融合モデルは時間依存的であり、分析時間枠の時間的工程ごとに作成しても良い；検証データは、分析時間枠中ずっと使用しても良いが、一部で使用しても良い、その理由は、他の期間では融合モデルが使用可能であるからである）。仮想シナリオの検証シナリオ部は、シナリオのある一部分である。シナリオは周囲のオブジェクトに関する時間依存的なデータによって再現され、つまり、検証シナリオ部は、例えば専用自動車の接近動作に対応するデータであるかもしれない。

シナリオのこの部分は、離脱関連データに由来する融合モデルに加えて、検証モデルを有することになるだろう。

検証データ、すなわち許容可能な品質のシナリオを構築するために使用される検証データはまた、制御ユニットの、不適当に動作するコンポーネントを同定する際に役立つ。

そのため、同定は仮想シナリオに基づいて行われるが、もし検証データが利用可能であれば、この検証データは同定に寄与するであろう。その理由は、より良い品質のシナリオが検証データを使用して既に得られているからである。

検証シナリオ部の検証モデルと融合モデルとの比較に基づいて、相違がモデルに見つかるかもしれず、その相違に基づいて、制御ユニットのどのコンポーネントが、相違の主要因であるか（特に、どのコンポーネントが検証モデルからの逸脱の主要因なのか、多くの事例において、どれが地上検証物であると考えられるのか）を同定できる。

距離推定の例を考えると、融合モデルにおける距離が、検証モデルに観察される距離と異なることが明確にされるだろう。そのため、制御ユニットの適切な（主要因である）距離推定コンポーネントがさらに開発される（つまり修正される）べきであることは、明らかである。

検証データは、別の検証センサによって記録されるか、または基本的センサから入手可能であり、そのデータを別に処理して融合に使用しても良い。基本的センサから入手可能な検証データについては、上記の生データが良い例である。

カメラの生データは、融合に使用されるために、高速アルゴリズムによって処理される。しかし、より精確な検出を得るために、より遅く、より洗練されたアルゴリズムによって処理することで、検証データを生データから入手することができる（つまり、この場合、検証データは、オフラインアルゴリズムを生成する検証データを活用することによって、生データから入手される）。

より遅い処理を使用すると、融合には使用できない。

検証は、例えば、並列自動車の距離が誤って推定された、つまり融合モデルで並列自動車が不正な位置に置かれていたこと、を示す。この推定の主要因である制御ユニットのコンポーネントが修正されると、推定は、修正された、さらに開発された制御ユニットを（その第２の状態で）活用することによって、適切になされるであろう。

距離推定コンポーネントが不適当に動作するコンポーネントであったため、この例では、制御ユニットの第１の状態で生成された融合モデルと比較して、制御ユニットの第２の状態を使用して生成された融合モデルにおける変化が存在するだろう。

さらなる実施形態では、自律自動車は、検証データの記録のために適合された検証センサを装備している。

検証センサは、任意のセンサであって良い；つまり、オンライン融合でデータを使用するセンサであっても良いが、そのデータは－オフラインで処理され－検証に適している。この場合、検証データをあるセンサから入手し、そのデータをリアルタイム融合で使用する（例えば、検証データが生データである時など）。

しかし、ある実施形態では、検証センサは別のセンサであっても良く、そこからは検証データのみが取得される（例えば、このセンサのデータは、融合に使用するのに適していない、この点については、ライダーセンサの説明を参照）。そのため、この検証センサは、基本的センサと異なる。

検証センサは、ある実施形態ではライダーデバイスである。

ライダーセンサの待ち時間は、１００－２５０ミリ秒の間であり、そのため、高速道路上、または高い意思決定頻度において、リアルタイムに使用することはできない。従って、ライダーは、例えば融合用の低速で使用することができるが、主にテスト用のみであり、ライダーデバイスは非常に高価なので、すべての自律自動車に設置できるとは限らない。同様の考察はレーダーにもあてはまる；これらの機能は、他の－例えばカメラに基づく－センサによって提供されるべきである。

しかし、センサによって捕捉されたデータは、その後もオフラインソフトウェア補正にかけることができ（例えば、高速で記録されたライダーデータは、歪みを生じるかもしれないが、その歪みは適切なソフトウェアを活用することで補正することができ）、そして融合データの改善のための、地上検証データとして使用することができる。

従って、ソフトウェアによって改善されたライダーデータも、検証データとして使用することができる。

そのため、検証センサの役割は、シナリオのシミュレーションのために、センサデータに基づいて構築された融合モデルの補正を補助することである。

これについては、距離推定アルゴリズムの不正確性が、良い例であるかもしれない（詳細は下記を参照）：リアルタイムの融合モデルで、他の自動車は１３０メートルの距離にあると推定され、そして、もしこの情報のみが使用されれば、離脱レポートに基づいて構築されるシナリオでは、この自動車は１３０メートルの距離から始動するだろう（つまり、自律自動車は、車線変更操作を実施するのに十分な時間を有していることになる）。

検証センサの役割は、この種の不正確な情報（不正確な距離推定）を補正することである。

ライダーが自律自動車上に設置され、そして、追い越しが開始された時に、（赤い）自動車は自律自動車の後方８０メートルの距離にいることを正確に検出していたと仮定する。

従って、検証センサのデータが、ログに基づいて作られた改善されたシナリオに対して使用されれば、（赤い）自動車は、改善されたシナリオにおいても８０メートルの場所にあり、そして、その後、シミュレーションでは、追い越しのための十分な時間が無いことになるだろう。

同時に、この場合、検証センサは、制御ユニットの、修正（開発）されるべき部分を見つけるのに役立つ：検証データ（８０ｍ）から、制御ユニットの距離推定アルゴリズムが改善されるべきであることは明らかである。

上記の詳細より、検証センサとしてライダーデバイスを使用するある実施形態では、制御ユニットの距離推定コンポーネントは、制御ユニットの、不適当に動作するコンポーネントとして同定され、そして、（自動車のまわりの任意の方角、例えば自動車の前方、自動車の後方、または自動車の側方、で距離を計測する）距離推定コンポーネントは、制御ユニットの第１の状態に基づいて、制御ユニットの第２の状態を生成するために修正される。

距離の推定は、ライダーデバイスを活用することで検証できる。

自律自動車の前方のオブジェクトの距離を推定するためのセンサが、好ましくはステレオカメラのペアなので、この方向の距離は、好ましくは良い精度で推定される。

しかし、自律自動車の後方を「確認している」センサは、図１の例で、自律自動車の後方の出来事からの映像を記録するように指向された単一のカメラであり、したがって、このセンサのデータを使用する距離推定コンポーネント（アルゴリズム）が、様々な状況で良い精度に到達するように開発されるべきであると考えられる。

この後の部分では、融合についてのいくつかの詳細を説明する。

融合データは、任意の所与の時間における、全ての周囲車両についての以下のパラメータを含むべきである。

シナリオの全ての長さを追跡できるような車両に限って、あるいは、なぜ、ある車両が突然ＧＰＳまたはマップデータに現れたまたはそこから消えたかについて、知識経験に基づいた推測が可能である場合に、その車両のモデル化を行うべきである。

ゴールは、検出エラーを除去することであり、検出エラーは、それらの急に現われたり消えたりするような「オブジェクト」であるかもしれない。

そのため、この選別が近傍の自動車を失うことになってはならず、それらの挙動は、自律自動車の制御にとって重要である。

検出エラーは主に融合に現れ、同時に、検証データには存在しない。

しかし、オブジェクトが、検証データの時系列で明らかに追跡でき、同時に、融合データには（明らかに）現れない場合、それは、高い確率で検出の失敗であり、制御ユニットのコンポーネントの不適当な動作の結果であり得る。

従って、この後者の事例はまた、制御ユニットの、不適当に動作するコンポーネントの同定において役立ち得る。

以下のパラメータが、これらの周囲車両に関して必要（これらの自動車を追跡するのに十分）である：
●ｍ／ｓ表示による速度（スピード）
●自己（自律）自動車からの、メートル表示による距離と、度数表示による角度。
●自己自動車に対する、車両の車線識別子（ｉｄ）
●自己自動車に対する、進行方向角度。

任意のパラメータは以下の通りである（これらのパラメータを有することが好ましい）：
●メートル表示による幅と長さ
●メートル表示による車線の中央からの推定距離
●アタッチメント
●色
●モデル
●照明と方向指示器の状態

上記の、必要かつ任意のパラメータのほとんどは、自律自動車のカメラセンサによってなされた記録から取得することができる；センサの例示的な配置は、上に紹介される通りの図１で図示される。

周囲の車両の調査には、主に、自動車の前方のカメラ、ならびにその後方部分のカメラを使用する。

速度と距離は、これらのカメラの記録から取得することができる。自律自動車がある自動車に接近する（追従し、そして近付く）と、その自動車は、記録の中でどんどん大きくなる。

カメラセンサ（１２）と（１６）によって構成されたステレオカメラによって、この自動車の距離は容易に取得でき、ならびに自律自動車に対するその速度を計測することができる（自律自動車の実際の速度がわかっているので、その自動車の絶対速度を計算することもできる）。

これらのパラメータは、後方から自律自動車に接近してくる自動車に関して、後方のカメラセンサ（２２）から－精度は低いが－取得することができる。

より良い精度を得るために、ステレオカメラのペアを、自律自動車の後方部分に取り付けても良い。

車線識別子と進行方向も、主としてカメラセンサ（１２）、（１６）、および（２２）（随意に、センサ（１４））の記録から、それらの記録を解析することによって、取得できる。

周囲の車両の幅などの、他の任意のパラメータは、記録から取得することができる。

しかし、その長さ－および、もしあればアタッチメント－を取得するために、側方カメラセンサ（２４）と（２６）も使用することができる。

周囲車両の車線の中心からの推定距離、ならびにその色とモデルもまた、カメラ記録から取得することができる情報である。

記録（例えばある長さのビデオ記録）を分析することによって、周囲車両の照明および方向指示器についての情報も取得できるかもしれない。

シナリオを準備するために、レポートが処理される対象となる、離脱イベント前の期間を定義することが重要である（離脱イベントは、安全性ドライバが車両から制御を取り戻す必要がある時の時間インスタンス（ｔｉｍｅ ｉｎｓｔａｎｃｅ）に相当する）；この期間の長さは、重要なパラメータである。

離脱がより早い段階の操作によって回避可能かを判定することは重要であり、そしてもし回避可能であれば、発生したことを回避するオプションを探し求めるために、より長いシナリオが作成され（より長い期間では、自律自動車は、選択するべきより多くのオプションを有する）、あるいは、もし離脱が、ある場所、またはアクションの短い連続に特異的であるならば、短いシナリオのみが作成される。

融合データが準備され、それは好ましくはシナリオジェネレータによって処理される前であり、離脱が起こる前の環境がどんなものであったかというアイディアを得るために、ノイズを減じることによって準備される；これは、好ましくは自動化される。

融合データは、ある場合には不正確であるかもしれず、そして、このことがまた、離脱の原因となり得る（上記の第２のタイプの離脱を参照）。

従って、そのような事例では、状態を正確に再作成するために、検証センサ（もし利用可能であれば）を好適に使用して、使用することができる追加的情報を提供する。検証センサに由来するデータは、好ましい実施形態で、以下の工程に従って使用されても良い：

１．レポートの関連区間にある全ての車両を反復し、そして個々に処理する。

各フレーム間の車両の動きをテストし、そして、動きの量が不自然な場合、関連するフレームをマーキングする。これらのマーキングしたフレーム内の車両の位置は、最後の位置と次の安定した位置との間に、内挿する必要があるだろう。

２．検証センサで利用可能なデータは、融合モデルにマッチしている。全ての車両を、検証センサのデータと融合データが重複する程度まで、反復かつテストする。

審査された区間の長さ全体の間で最も重複する、検証センサによって検出されたオブジェクトを見つけることによって、この情報を、融合の精確さを補正し、かつ内挿が必要となる場所を満たすために使用することができる。

車両の進行方向もチェックするべきであり、そして必要であれば、検証センサにおける利用可能な情報によって補正するべきである。

融合によって生成されたモデルスペースの車両の位置は、非連続的であっても良く、一方で同時に、これらの車両は、検証データの活用によって生成されたモデルスペースの中で見つけることもできる。この後者のモデルスペースでは、車両位置は継続的に変化する。

上記の工程のこれらの２つのモデルスペース間で、一致がもたらされるように試みる。この目的のために、重複を、２つのモデルスペースの自動車間で調査する。

従って、車両に関する情報は、好ましくは、両モデルスペースから考慮することができる。

上述される通り、検証データは、可能性のある検出エラーの点において優位し、関連車両が省略されることはない。

３．車両の補正された経路を同定した後、現われたり消えたりする車両をテストするべきである。車両が急に消えて、別の車両がその位置に現われる場合、融合モデルが正確ではないという仮定が成り立ち得る。

もし、色またはモデルのような、車両の外観について入手可能な情報があり、そしてそれらが一致していれば、これらの２台の車両を、安全に統合して融合させることができる。その他では、検証センサのデータが継続的に移動しているオブジェクトを示す場合に、外観情報無しであっても、統合を実行することができる。

検証データを活用することによって、車両の継続的な追跡を、上記の工程１でマーキングしたフレームにおいても達成することができる。

以下の部分では、シナリオを生成する工程の例示的な順序を説明する：

１．初期状態を作成する：
ａ）ＧＰＳの位置に基づくマップデータが利用可能であれば、所与の道路区間をロードするか、または作成する。
ｂ）マップデータが利用可能でない場合、融合データを処理し、そして車線と車線接続を、融合で利用可能な検出ロードモデルに基づいて作成する（マップ作成、ロード、および生成は、本文書の範囲では無く、ポイントａ）またはポイントｂ）に従って、既知のアプローチによって行われても良い）。
ｃ）すべての車両の全ての利用可能データと共に、始動位置およびスピード（速度）を設定する。
ｄ）安全性要件（例えば、スピード変化、車線維持、安全な車間など）、および離脱の理由に基づくテスト条件を、自律自動車用に設定する。離脱の理由は、好ましくは、何故制御を自律自動車から取り戻したのかについて、安全性ドライバによって与えられる。この情報は、制御ユニットの、不適当に動作するコンポーネントを探す時に役に立ち得る。しかし、これは、仮想シミュレータのシナリオをテストする時にのみ必要であり、ログが処理されている時には省略しても良い。

このポイントｄ）については、以下に注意すること。

安全部（この部は、様々な自動車安全基準を適用する責任がある）によって決定されたパラメータ値は、ある状況の自動車に観察される必要がある（例えば、限界値を超過してはならない、または距離が限界値を下回ってはならないなど、下記を参照）。上述のパラメータの、スピード変化とは、自律車両の（維持されるべき）目標速度が、もし十分な理由が無い場合に、例えば５％を超えて変化してはならないという意味である（十分な理由とは、つまり例外であり、道路上の障害物を検出する、自律車両の前により遅い自動車がいる、あるいは、ある道路区間では速度を落として走行する必要がある、などである）。

「車線維持」パラメータは、車線マーキングに接近すること（どれ程の量近付いても良いか）に対応する。理想的な事例では、車線維持機能をテストする際、自律自動車は、急カーブにおいてであっても、１０ｃｍを超えて車線マーキングに近付かない。

「安全車間」パラメータは、自律自動車の前の自動車からの距離に対応する（それは、時間パラメータで特徴付けることもできる）。一般に、自動車は、その自動車の速度に関係無く、（少なくとも）１．５秒の追従時間で追従することが期待される、というのは、自動車はいつでも制動され得、また事故が起こる可能性もあるからである。

２．融合データを、「ｔ」秒ごとに処理する（つまり、適切な時間工程に従う）：

この工程で、タイムスタンプ記録のログ（下記でシナリオログと呼ばれる）を作成し、それをその後にシナリオジェネレータに供給することができる。

ログは、各車両にどのようなアクションが発生したかについて、および経路に沿った移動を変更した可能性がある、車両の挙動における他の変更についての、キーワードを含むことになっている。

次のイベントがログに記録されるべきである（周囲車両から必要となるパラメータは上で参照）：
●現われる：車両ｉｄ、位置、進行方向、初期速度
●消える：車両ｉｄ、最終の既知の位置、進行方向、速度
●スピード：車両ｉｄ、目標スピード
●車線変更：車両ｉｄ、元の車線ｉｄ、目標車線ｉｄ（これは、車両が以前に居た車線と異なる車線に割り当てられた、まさにその瞬間を示す）
●車線中央距離：車両ｉｄ、車線の想像上のセンターラインからの、メートル表示による符号付き距離
●自動車照明状態：車両ｉｄ、照明名（ブレーキランプ、方向指示器左または右など）、照明の状態（オン、オフ）

上のイベントのリストは、車両の直線移動が想定される場合に、任意の所与の時点でのシナリオにおける車両の位置が、リアルタイム融合データで利用可能な位置と一致するような方法で、生成しなければならない。

換言すると、シナリオは、自律自動車の走行中に作成されたものと等価な状況が取得されるような方法で、構築しなければならない。要するに、シナリオは、自律自動車に起こった実際の状況と同じ方法で、離脱イベントも引き起こさなければならない。

一旦ログが完了すれば、それをシナリオジェネレータへ転送することができ、それによって、実際のフレームワークに基づくシナリオファイルを作成することができる。

シナリオ生成および実行時間の実装は、本文書の範囲外であるが、任意の種類のシナリオテストフレームワークを準備して、ログファイルを処理し、そしてそれを有効なシナリオに変換することができるという意味において、生成されたログファイルは普遍的であろうと言うことができ、つまり、既知のシステムの利用を制限することはなく、そして、当業者の誰もが、そのようなフレームワークへの変換を準備する（例えば、ファイルフォーマットｏｐｅｎＳｃｅｎａｒｉｏを開くなど）ことができなければならないことを意味する。

随意に、加速、制動、車線変更など、シナリオ中に同じ方法で実行されることが期待される自律（自己）車両の動きのさまざまなアクションを、マーキングする。

これらは、安全性によって定義される条件の下で追加的にテストすることができるが、異なる評価を行うことができる。

例えば、車両制御ソフトウェアが早めに車線を切り替えることによって離脱を回避するか否か、または、またはその逆で、自動車は以前に車線を切り替えていたが、何らかの理由でテストではそうしなかった；元の車線変更が合理的な動きであったならば、意図されていなかった部分が、制御ソフトウェアにおいて変更されたことを示すかもしれず（主目的は、制御ユニットのコンポーネントを変更した後に離脱を回避することである）、そしてこの場合、ここに到達する：つまり、ある開始状態から開始したシナリオが、制御ユニットの第１の状態で離脱してしまい、そしてその離脱は、その第２の改善状態で回避される。

上記の説明は周囲の環境からの車両にのみ焦点を当てているが、新しい参加者用の新しいイベントを追加するだけで、任意の他の参加者（例えば歩行者、動物など）を、同じ方法を使用してシナリオで観察および再作成することができる。

図３では、シナリオ生成（作成）および評価のワークフローが示される。

工程（Ｓ１００）では、シナリオは、安全性技師によって以下のように定義される。

どの道路区間でシナリオを実行するべきか（始動時の車線、出口または合流時の車線、交差点、カーブなどの数）、最初に道路区間上で車両をどのように配置するべきか、ならびに開始速度およびメタ情報（車両タイプ、色、アタッチメントなど）と共に定義する。

次に、発生する異なるアクションを、シナリオの各工程で定義する（速度変更、車線変更など）。

車両制御ソフトウェアをテストするための異なる条件も定義し、そして、許容可能な制限と共に期待値を設定する。

さらなる工程（Ｓ１１０）では、定義されたシナリオを、スタンドアローンのシナリオエディタにおいて作成することによって、シナリオテストフレームワークに変換する。

そこでは、開始位置、タイマー、イベント、および異なるアクションをすべて特定し、安全性技師によって与えられるシナリオの記載と一致させることができる。

その後、次の工程（Ｓ１２０）で、作成されたシナリオを仮想シミュレータで実行することができる。

定義された車両をスポーニングし、車両制御ソフトウェアがシミュレータに接続するのを待つ（そのため、離脱イベントが発生した時に現実に使われた、同じ制御ソフトウェアバージョンでテストすることになる）。

一旦すべてが準備できれば、シナリオは実行を開始し、イベントとタイマーなどが実行される。

シナリオ中に、自律車両ソフトウェアによって運転される自動車は、定義された条件をテストすることができるように緊密にモニタリングされる（上のポイント１ｄ）を参照）。

一旦条件の１つがアクティブ状態に到達すると（つまり、そのような条件の限界値違反が発生すると）、または、車両がそのゴールに到達すると、シミュレーションは停止し、そして詳細のログファイルが生成され、そのファイルはその後さらに分析、レプレイとして再度再生することができ、あるいは、そこから任意の有用な情報を取得することができる。

テストは好ましくは夜通し行って良い。

各走行の結果は、制御ソフトウェアの性能が様々な状況で上がったか下がったかを確認するために比較される。

図４では、本発明の実施形態で適用される自動的シナリオ生成のワークフローが記載される。

準備段階（Ｓ２００）（「自律車両にセンサを取り付ける」と表示される）では、自律車両に、通常の路上テストに必要なカメラおよびすべての必要なセンサを搭載する。

通常融合には使用されない追加的－検証－センサ（例えば、レーダーまたはライダー）が必要な場合、これらのデバイスも車両に搭載する。

この工程は各テストごとには行わず、自律自動車をテスト用に準備する時に、一度だけ行わなければならない。

次の工程（Ｓ２１０）では、自律自動車は、自動テストが実行されることが意図されているエリアに進み、そこでは手動で運転しても良い（そこで自動で運転しても良いが、この場合、テストエリアへの道路もテストの一部になる）。

工程（Ｓ２２０）では、指定されるテストエリアに到達し、安全性ドライバが車両に制御を行い、車両を自律モードに切り替える。

そのテストは計画通りに行われるが、予期していないイベントによって中断されることもあり、その時は、離脱イベントが発生し、そして制御が、自律自動車から安全性ドライバに戻る。

しかし、いくつかのテストは、そのような予期していないイベントの発生無く行うことが可能ではあるが、予期していないイベントが発生した場合には、それは離脱レポート（ログ）と共に捕捉される。

本発明によれば、それを捕捉することは有利である、というのは、本文書全体にわたって説明されているように、離脱イベントが発生する時に取得できる情報が、自律自動車の制御を開発するのに使用されるからである。

従って、工程（Ｓ２３０）では、予期していない何かが起こると、安全性ドライバが介入して制御を取り戻すか、あるいは車両制御ソフトウェアがドライバにシグナルを送って自動的に制御を戻すかのいずれかが行われる（離脱は両方の方法で発生し得る）。

離脱レポートが生成される時に、その時点までの全てのログとセンサ情報が収集され、そして容易にアクセスできるようにレポート中にリンクされる。

さらなる工程（Ｓ２４０）では、一旦路上テストが終了し、車両が事務所に戻って来ると、離脱レポートを事務所サーバーにコピーし、そして処理ソフトウェアチェーン（ｐｒｏｃｅｓｓｉｎｇ ｓｏｆｔｗａｒｅ ｃｈａｉｎ）に転送することができる、つまり、離脱レポートがダウンロードされる。

工程（Ｓ２５０）では、まず、レポートをフレームワークによって解析し、そして融合モデルをオフラインで再構築して、シナリオ用のモデルスペースを持たせる（離脱レポートを後処理する際に、センサのデータを使用して、テスト中にオンラインで作成された融合モデルをオフラインで再作成する）。

融合データは単に、離脱関連データの一部（つまり、離脱レポートの一部）である。いくつかの異なるデータは、（好ましくは検証データを含む）このデータパックから利用される；この工程では、これらを収集し、そして同期させてシナリオ用のモデルスペースを作成する。

その後、次の工程（Ｓ２６０）では、検証センサデータを異なるソフトウェアで分析して、任意の関連メタ情報と共に、オブジェクトのタイムスタンプ記録のリストを作成する。

従って、この種の検証センサ（例えばライダー）は、周囲のオブジェクトのリスト化のために適合される。一般に、検証データは、オフラインで取得できる、任意の種類の補助情報であっても良い。

これは、オンライン、つまり自律自動車の自律モードでの利用が不可能な情報である。

従って、検証センサの場合、周囲の物体の全てを認識できる必要は無い。

これに対して、ゴールは、検証データソース全体を活用することによって関連オブジェクトの全てをカバーできることである。

この後、融合を（その中のどの部分が曖昧かを判定して）整頓し、ノイズを減らし、そして検証センサからのデータを利用可能な融合スペースに統合すること、を含む工程が発生する。要するに、これらの工程は、「融合モデルをアップデートし、微調整する」と表示された工程（Ｓ２７０）へと続く。

融合データは、その前の工程で改善されていた。

ここで道路区間を分析することができ、そして、必要な部分を、選択された道路記述子フォーマット、例えば、オープンソースの、ｏｐｅｎＤｒｉｖｅやｏｐｅｎＣＲＧで作成できる（工程（Ｓ２８０））。

また、この時に、シナリオログ（これに基づいてシナリオが実行可能となる）をさらなる使用のために生成することができる。

次の工程（Ｓ２９０）では、生成ログをシナリオエディタに供給することができ、これによってログに記述されている出来事を自動的に作成してそのシナリオファイルを保存することができ、このシナリオファイルを直ちにシミュレータに転送して、テストで実行することができる。

以下に、任意の（例示的な）選択されたパラメータ値（異なる具体的なパラメータ値が図示を目的として使用され、パラメータ値は例ごとに任意に選択される）を有する異なる例が説明され、本発明のいくつかの態様を図示している。

最初に、上記の例に関係して、不正確な距離推定が検証センサの活用によって同定される、単純な例を説明する。

以下では、この例の新しい態様を詳述する。

自律自動車は、高速道路上の外側車線を１００ｋｍ／ｈの速度で、緑の自動車の後を走行し、そして、緑の自動車の速度は、自律自動車の速度よりも１０ｋｍ／ｈ低い。

自律自動車が、緑の自動車からわずか１００ｍ離れた場所に来た時に、自律自動車は、現在の速度を保つことを可能にするには、追い越しが必要であることを認識する。

自律自動車はハンドルを切り、車線変更を開始するが、内側車線には現在８０ｍの距離に１３０ｋｍ／ｈの速度で赤の自動車が存在する。

接近車があまりにも近いため、この状況は離脱を引き起こす。

離脱の原因は、内側車線の自動車が正確に検出できなかったことである（その自動車が観察されなかった、または観察されたが、より遠い距離またはより遅い速度であると推定されたなど）。

上の例のカメラ記録とログから作成されたシナリオを実行する場合、もしリアルテスト時と同じ制御ソフトウェアバージョン（制御ユニットは同じ状態）が適用されるのであれば、仮想シナリオにおいても追い越しを実行するべきであることがシミュレーションされた自律自動車によって理解され、そしてその後に、自律自動車が追い越しを開始することが、シナリオシミュレーションから期待される。

換言すると、シナリオは、もし制御ソフトウェアが離脱イベントを引き起こしたテスト以来変更されていなければ、再度離脱を引き起こす、良い品質で構築しなければならない。

これがシミュレータで実現されると仮定すると、自動車は、テスト中に同じような挙動をとる。

この後、制御ユニットの失敗の根源を探すことができる（この失敗の結果、離脱が生じた）。

上の例では、距離推定アルゴリズムが接近車は１３０ｍの距離にいると推定したために、追い越しが自律車両の制御ユニットで許可されたが、実際は８０ｍであった。

失敗の根源を発見した後、距離推定アルゴリズムを修正（開発）し、そして、失敗限界内の推定を提供するようになっている（例えば、接近車は、８３ｍの距離にいると推定する）。

そのため、追い越しを実行するべきであると制御ユニットで認識されても、修正後の推定アルゴリズムを使用する制御ユニットバージョンでは、追い越しを開始することは許可されない。

そのため、離脱は回避されるだろう。

もし同時に追い越しロジックに対応するモジュールも修正（開発）されているなら、制御ソフトウェアが、自律自動車の前方１００ｍの距離にいて、かつ速度が１０ｋｍ／ｈ低い車両は追い越さないと決定するということも起こり得る。

そのため、車線変更での距離推定の失敗は発生しない。結果として、自律自動車の速度は低下するが、それ以外は何も行われない。これは失敗につながる挙動として解釈される。そのため、これも、離脱イベントに基づいて作られたシナリオからの貴重な結果である、その理由は、－もし自律自動車が、１０ｋｍ／ｈ低い速度の自動車に１００ｍを超えて接近するべきではないということが、安全性に関わる期待であるならば－、このことを仮想環境でも修繕して、追い越しは行われないが、自律自動車は単にスピードを下げて別の自動車を追従するだけとなる状況を、どうにか回避することができる。

これは、追い越しが単純な車線変更によってなされ得る高速道路の例である。

アスファルトの品質は、車線維持問題によって引き起こされる離脱の場合に、重要な要因となり得る。

例示的なテストルートでは、道路が新しいアスファルトで再構築された、短い、わずか数メートルの長さの部分がさらされ、そのため、（塗装された）車線分離マーキングが簡単に検出できず（多くの場合、新しいアスファルトは、平均的な道路区間より暗めであり；そのため、検出は、その色を路面としてではなく影として観察してしまう）、そしてそのため、自律自動車が度々他の車線に蛇行する。

これは、開発者にとっては、問題を引き起こすとは予期していないイベントであるが、テストおよびテスト中に発生した離脱に基づいて（この例では、望まれない車線変更が離脱を引き起こす）、制御ソフトウェアがそのような事例に対して準備されなくてはならないことは明らかである。この場合、環境がシミュレータ用に手動でモデル化されるとなると、上述の道路区間の正確なモデルは、専門のグラフィックデザイナーによって準備されるであろうし、そして、道路の各詳細の再構築が十分に正確ではないと考えられる（たとえば、グラフィックデザイナーは、ほとんど確実に、アスファルトの品質が重要であるとは想定しておらず、これに対応する詳細に重きを置いていないであろう）、そしてそのため、失敗はシミュレータでは発生しないであろう。

そのため、自動車がテスト中と同じような挙動をとり、適用される制御ソフトウェアバージョンが同じである場合に、シナリオを実行することによって現実世界のテスト時と同じ様に失敗する、というのが、離脱に基づいて生成されたシナリオからの期待である。もしこれが起こらないなら、シナリオの再現は、そのような精度まで開発される必要があることになる。

シナリオの精度が許容限度に達しない時、それは、様々な原因（ある自動車の動きが十分に精確でない、様々な光の状況、様々な天候、車線マーキングの異なる品質など）の結果であり得る。

具体的な原因を考慮し、シナリオの精度を改善するための適切なツールまたは方法。

さらに、離脱を引き起こし得る例示的な状況を以下に説明する。

別の方向の車線内の自動車が、センサ融合によって、自律自動車の車線の中に取り込まれることが起こり得る。

自動車に対して車線を整えることを担当するアルゴリズム内で、問題を探し、そしてそれを修繕するべきである。

履歴において、誤って配置された自動車が常に車線を変更するのであれば、あるいは、より時間はかかるがより精確な車線の規則配置を提供するアルゴリズムも利用可能であるのであれば、離脱の原因を基本的センサによって再現することができるが、もしそうでなければ、検証センサを使用する必要がある。

次の例では、小型車はトラックを追従しており、そして突然その追い越しを開始する。

これらの２台の車両は、同じ方角の自律自動車の前方を走行する。初めに、トラック、小型車、および自律自動車は同じ（外側）車線にいる。

小型者は、トラックを追い越す為に、この車線から内側車線に変わり、そしてそのため、自律自動車はトラックの直後を走行することになる。

トラックは、自律自動車のセンサによって精確に認識されるが、突然、（追い越しが開始されると）小型車の場所にはるかに大きなオブジェクトを検出することになり、それによって自律自動車は、小型車が早いペースで接近していると推測する。

この問題は、検出車両の適切な追跡（いわゆるインスタンス追跡（ｉｎｓｔａｎｃｅ ｔｒａｃｋｉｎｇ））によって解決できるかもしれない。小型車がトラックの隣の隣接車線で正確に検出されれば、その状況を基本的センサによって再現することができる。

インスタンス追跡は、融合によってなされる。つまり、インスタンス追跡中に、全ての車両が数字を持ち、そしてそれらの車両はこれらの数値を活用することによって追跡され、そして自律自動車にとって「可視的」（検出可能）になる。

しかし、小型車がトラックの追い越しを開始する時に小型車の検出が失敗し、そしてそれを認識する検出アルゴリズムが（オフラインの実行においてですら）存在しなければ、この問題は検証センサを活用することでしか解決できない。

さらに次の例で、（自律自動車の制御のために自律自動車によって検出されることになる）自動車は、晴天下で高速道路上を走行しており、高架交差路の下に入る。突然の暗い環境のために、検出はこの瞬間に失われる。

このように、自動車は暗がりから出て来ると突然検出されることになり（その自動車は「どこからともなく」やって来るが、このことは制御によって高速での接近として解釈され）、そして自律自動車は同時に制動を開始し、このことが離脱を引き起こし得る。

この状況はほぼ確実に、基本的センサを活用することによって再現可能となるであろう。

長い、連結トラック（トラックトレーラー）を追い越す過程で、極端に長いオブジェクトが、適切なアルゴリズムによって別の複数の自動車（トラック）として検出されることが、時々起こり得る。

基本的センサのデータを使用してこの状況を再現すれば、それでも十分である、その理由は、その問題がオブジェクト（トラック）がセンサによってあまりにも長い間「確認」され得るという事実によって引き起こされているからである。

強い日の光の中で、太陽が地平線に近付くと、道路の表面の高い輝度のために、車線が検出できないということが起こることもある。これは特別な状況であり、カメラの記録は車線マーキングに関する現実の情報を含んでいないため、検証センサが欠如した状態では、ほぼ確実に解決することはできない。

しかし、もしライダーを検証センサとして使用すれば、太陽の位置は重要ではなくなり、そして、（車線マーキングが路面からわずかに突き出しているため）車線マーキングを好適に検出することができる。

そのため、カメラ記録は車線マーキングに関する有益な情報を提供しないが、検証センサとしてのライダーが車線マーキングを再構築するのに役立つので、シナリオの仮想テストは可能になる。

ある例では、自律自動車は強い横風の中を走行している。

大きなトラックを追い越した後に、自律自動車は突然横風にあおられるかもしれず、そして自動車は少し大きめに傾斜する。

適用されている検出アルゴリズムが高感度な場合、このことは、例えばアルゴリズムの結果の質を低下させるかもしれず、そして、車線マーキングが道路モデル中で適切に示されないといった事が起こり得る（道路モデルが傾斜するので、カメラの検出に適さなくなり、軌道の計画に乱れを引き起こすかもしれず、従って離脱を引き起こし得る）。

この事例は基本的センサによって再現することができる；もし、例えば、ＩＭＵ（慣性計測ユニット）センサが自動車の基本的センサとして適用されれば、自動車の路面保持が（通常状態下のように）適切ではなかったものの、自動車は僅かに傾斜して走行していたことが検出できる。

この情報は、自動のソフトウェアベースの補正のために、実行時間中に利用されるかもしれないが、この効果を補正するのに主要な役割を果たすアルゴリズム（制御ユニットのコンポーネント）が適切に動作しないという事例も起こり得る。

事例がＩＭＵセンサによって測定されたデータを利用しても再現できないということが起こると、（例えば、そのデータを基に傾斜が検出可能となるライダーなど）検証センサを利用しなければ、適切な再現を期待することはできない。

上述される通り、必ずしも基本的センサの１つとしてＩＭＵセンサを適用する必要は無い。

制御ソフトウェアが上述される不定状態になる時には、制御ソフトウェアによって開始された離脱が生じる。

これは、任意のハードウェアの故障（例えば重大なカメラ停止）によって引き起こされ得るが、環境の結果でもあり得る（例えば、自律自動車の前方で車線マーキングまたは路面が検出できず、そのため、軌道を計算できない）。

当然、ハードウェアの故障はそのハードウェアの修繕を必要とするが、他の原因（カメラ記録、ＧＰＳシグナル、またはカメラシグナルの妨害）は、制御ユニットのコンポーネントの修正（開発）を活用することによって修繕できる。

いくつかの異なる故障を、自律自動車の制御によって好適に対処することができる。

自律自動車が安全に走行できている限り、例えばカメラが停止状態であっても、そのまま走行するだろう。

しかし、これ以上は安全に走行できないとなった時、自律自動車はドライバにシグナルを送り、制御を戻す。

多くの場合、離脱を引き起こすのは、交通の他の参加者（例えば、それらのうちのいくつかの位置が誤って検出されるなど）であるが、他の場合に、問題となる状況が、交通の他の参加者とは無関係に、環境から発生することがある。

そのため、本発明に係る方法のために使用されるフレームワークは、かなりの詳細を全て記録することができるだろう方法で生成（構築）し、そしてこれを仮想的に再現しなければならない。

環境に関するこれらの相当な詳細は、複数の群に分類することができる。動的なオブジェクトは、車両、歩行者、または動物であるかもしれない。

（場所に固定された）静的なオブジェクトは、例えば交通信号、交通標識であるかもしれない。

これらの後者の場所と位置は、ほぼ確実に変化しないであろう、そのため、我々はマップデータに頼ることもでき、このマップデータは記録中に見つけることができるオブジェクトと結合させる必要があり、そうすればこれらはより対処しやすくなる。

天候、太陽の位置、または影を、動的な環境関連パラメータ（要因）として考えても良く、一方で、建物や橋の位置、または路面のばらつきや車線マーキングの欠如を、静的な環境関連パラメータとして考えても良い。

これらの４つのより大きな群（動的および静的オブジェクト、動的および静的環境関連パラメータ）の各々のために、記録中の所与の特徴的または特異的詳細を検出する別のアルゴリズムが必要となり、そしてそれは、離脱に関係して生成されるログを介してシミュレータ内に表示される。

本発明はまた、自律自動車の制御ユニットを修正するためのシステムに関連し、ここで、当該制御ユニットの修正は、本発明にかかる方法の実施形態によって実行される。

システムを自律自動車の制御ユニットに電気的に接続して、自律自動車上で修正を実行しても良い。

指示を含むコンピュータプログラム製品で、その指示がコンピューによって実行される時に、コンピュータに本発明に係る方法の実施形態を遂行させる、コンピュータプログラム製品も考えられる。

コンピュータプログラム製品は、１以上のコンピュータによって実行可能であっても良い。

本発明はまた、指示を含むコンピュータ可読媒体に関連し、その指示がコンピュータによって実行される時に、コンピュータに本発明に係る方法の実施形態を遂行させる。

コンピュータ可読媒体は、単一の可読媒体であっても良く、または複数の別々の要素を含んでいても良い。

本発明はもちろん、上に詳しく説明された好ましい実施形態に限定されず、むしろ、特許請求の範囲によって決定される保護の範囲内で、さらなる変形、修正、および改善が可能である。

さらに、いずれの任意の従属請求項の組み合わせによって定義され得る全ての実施形態が、本発明に属する。

Claims (9)

1. 自律自動車（３０）の制御ユニットを修正するための方法であって、前記自律自動車（３０）は、オブジェクトと前記自律自動車（３０）の周囲の環境との融合モデルが生成され得る元になる、センサデータを記録するように適合された、基本的センサを装備し、ここで、前記基本的センサによって記録された前記センサデータは、前記制御ユニットが、前記自律自動車を自律運転モードで制御することを可能にし、前記方法は、
   前記制御ユニットが第１の状態にある間に、前記自律自動車（３０）の前記自律運転モードで実行される自動テストアクション中に、前記基本的センサによって、前記センサデータを記録する工程と、
   離脱イベントが引き金となる対応で、前記離脱イベント前の分析時間枠に前記基本的センサによって記録された前記センサデータを含む離脱関連データを、ログする工程（Ｓ４０）と、
   前記離脱関連データに基づいて、シミュレータ装置で、前記分析時間枠の間、仮想シナリオを生成する工程であって、ここで、前記仮想シナリオは、前記基本的センサの仮想対応物を有する前記自律自動車の仮想対応物を含む、工程と、前記自動テストアクションに従って、前記シミュレータ装置の前記制御ユニットの前記第１の状態を使用して、前記自律自動車の前記仮想対応物で、第１の仮想自律走行を実行する工程であって、前記第１の仮想自律走行が、前記仮想シナリオの前記離脱イベントを引き起こす、工程（Ｓ５０）と、
   前記仮想シナリオに基づいて、前記制御ユニットの、不適当に動作するコンポーネントを同定する工程であって、ここで、前記離脱イベントは、前記制御ユニットの、前記不適当に動作するコンポーネントの不適切な動作によって引き起こされている、工程（Ｓ６０）と、および、
   前記制御ユニットの、不適当に動作するコンポーネントを修正することによって、前記制御ユニットの前記第１の状態に基づいて、前記制御ユニットの第２の状態を生成する工程と、前記自動テストアクションに従って、前記シミュレータ装置の前記制御ユニットの前記第２の状態を使用して、前記自律自動車の前記仮想対応物で、第２の仮想自律走行を実行する工程（Ｓ７０）と、前記離脱イベントが、前記第２の仮想自律走行で回避されるか否かをチェックする工程と、そして、前記離脱イベントが前記第２の仮想自律走行で回避される場合に、前記制御ユニットの修正されたコンポーネントを保存する工程、
   を含む、方法。
2. 前記分析時間枠の少なくとも一部の間に、検証シナリオ部の検証モデルを、前記検証シナリオ部の前記融合モデルと比較することに基づいて、前記仮想シナリオの前記検証シナリオ部を検証するために、前記仮想シナリオの生成の際に検証データを適用する工程をさらに含み、そして、前記制御ユニットの、前記不適当に動作するコンポーネントは、前記分析時間枠の少なくとも前記一部の間の、前記検証シナリオ部の前記検証モデルと、前記検証シナリオ部の前記融合モデルとの比較によって同定されることを特徴とする、請求項１に記載の方法。
3. 前記自律自動車が、前記検証データを記録するために適合された検証センサを装備していることを特徴とする、請求項２に記載の方法。
4. 前記検証センサが、前記基本的センサと異なることを特徴とする、請求項３に記載の方法。
5. 前記検証センサが、ライダーデバイスであることを特徴とする、請求項４に記載の方法。
6. 前記制御ユニットの距離推定コンポーネントが、前記制御ユニットの、前記不適当に動作するコンポーネントであると同定され、そして、前記制御ユニットの前記距離推定コンポーネントが、前記制御ユニットの前記第１の状態に基づいて、前記制御ユニットの前記第２の状態を生成するために修正されることを特徴とする、請求項５に記載の方法。
7. 前記分析時間枠において前記基本的センサによって生成される前記融合モデルが、前記分析時間枠において許容可能であることが判明した場合に、前記第２の仮想自律走行を実行した後に、第３の仮想自律走行が、前記自律自動車の前記仮想対応物で、前記シミュレータ装置の前記制御ユニットの前記第２の状態を使用して、前記自律自動車の前記仮想対応物の前記基本的センサの仮想対応物に、前記離脱関連データを与えながら、前記自動テストアクションに従って実行されることを特徴とする、請求項１に記載の方法。
8. 自律自動車（３０）の制御ユニットを修正するためのシステムであって、前記システムは、前記制御ユニットに接続されたコンピュータを含み、かつ指示を含み、前記指示は、前記コンピュータによって実行される時に、前記コンピュータに、
   前記制御ユニットが第１の状態にある間に、前記自律自動車（３０）の自律運転モードで実行される自動テストアクション中に、前記自律自動車（３０）の基本的センサから、センサデータを記録させ、
   離脱イベントが引き金となる対応で、前記離脱イベント前の分析時間枠に記録された前記センサデータを含む離脱関連データを、ログさせ（Ｓ４０）、
   前記離脱関連データに基づいて、シミュレータ装置で、前記分析時間枠の間、仮想シナリオを生成させ、ここで、前記仮想シナリオは、前記基本的センサの仮想対応物を有する前記自律自動車（３０）の仮想対応物を含み、そして、前記自動テストアクションに従って、前記シミュレータ装置の前記制御ユニットの前記第１の状態を使用して、前記自律自動車（３０）の前記仮想対応物で、第１の仮想自律走行を実行させ、前記第１の仮想自律走行が、前記仮想シナリオの前記離脱イベントを引き起こし（Ｓ５０）、
   前記仮想シナリオに基づいて、前記制御ユニットの、不適当に動作するコンポーネントを同定させ、ここで、前記離脱イベントは、前記制御ユニットの、前記不適当に動作するコンポーネントの不適切な動作によって引き起こされ（Ｓ６０）、および、
   前記制御ユニットの、前記不適当に動作するコンポーネントを修正することによって、前記制御ユニットの前記第１の状態に基づいて、前記制御ユニットの第２の状態を生成させ、前記自動テストアクションに従って、前記シミュレータ装置の前記制御ユニットの前記第２の状態を使用して、前記自律自動車（３０）の前記仮想対応物で、第２の仮想自律走行を実行させ（Ｓ７０）、前記離脱イベントが、前記第２の仮想自律走行で回避されるか否かをチェックさせ、そして、前記離脱イベントが前記第２の仮想自律走行で回避される場合に、前記制御ユニットの修正されたコンポーネントを保存させる、
   システム。
9. 指示を含むコンピュータ可読媒体であって、前記指示は、コンピュータによって実行される時に、前記コンピュータに、
   制御ユニットが第１の状態にある間に、自律自動車（３０）の自律運転モードで実行される自動テストアクション中に、前記自律自動車（３０）の基本的センサから、センサデータを記録させ、
   離脱イベントが引き金となる対応で、前記離脱イベント前の分析時間枠に記録された前記センサデータを含む離脱関連データを、ログさせ（Ｓ４０）、
   前記離脱関連データに基づいて、シミュレータ装置で、前記分析時間枠の間、仮想シナリオを生成させ、ここで、前記仮想シナリオは、前記基本的センサの仮想対応物を有する前記自律自動車（３０）の仮想対応物を含み、そして、前記自動テストアクションに従って、前記シミュレータ装置の前記制御ユニットの前記第１の状態を使用して、前記自律自動車（３０）の前記仮想対応物で、第１の仮想自律走行を実行させ、前記第１の仮想自律走行が、前記仮想シナリオの前記離脱イベントを引き起こし（Ｓ５０）、
   前記仮想シナリオに基づいて、前記制御ユニットの、不適当に動作するコンポーネントを同定させ、ここで、前記離脱イベントは、前記制御ユニットの、前記不適当に動作するコンポーネントの不適切な動作によって引き起こされ（Ｓ６０）、および、
   前記制御ユニットの、前記不適当に動作するコンポーネントを修正することによって、前記制御ユニットの前記第１の状態に基づいて、前記制御ユニットの第２の状態を生成させ、前記自動テストアクションに従って、前記シミュレータ装置の前記制御ユニットの前記第２の状態を使用して、前記自律自動車（３０）の前記仮想対応物で、第２の仮想自律走行を実行させ（Ｓ７０）、前記離脱イベントが、前記第２の仮想自律走行で回避されるか否かをチェックさせ、そして、前記離脱イベントが前記第２の仮想自律走行で回避される場合に、前記制御ユニットの修正されたコンポーネントを保存させる、
   コンピュータ可読媒体。

Images