ホーム > 特許ランキング > フォレテリックス リミテッド
特開2023-123562自律車両の適切な挙動を監視するためのシステム及びその方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023123562
(43)【公開日】2023-09-05
(54)【発明の名称】自律車両の適切な挙動を監視するためのシステム及びその方法
(51)【国際特許分類】
G06F 11/36 20060101AFI20230829BHJP
G01M 17/007 20060101ALI20230829BHJP
【ＦＩ】
G06F11/36 184
G01M17/007 J
【審査請求】未請求
【請求項の数】27
【出願形態】ＯＬ
(21)【出願番号】P 2023095965
(22)【出願日】2023-06-12
(62)【分割の表示】P 2021547807の分割
【原出願日】2020-12-15
(31)【優先権主張番号】62/949,098
(32)【優先日】2019-12-17
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＰＹＴＨＯＮ
(71)【出願人】
【識別番号】521359601
【氏名又は名称】フォレテリックス リミテッド
(74)【代理人】
【識別番号】110000855
【氏名又は名称】弁理士法人浅村特許事務所
(72)【発明者】
【氏名】ホランダー、ヨアブ
(72)【発明者】
【氏名】ハーシュフェルド、オデッド、ドロン
(72)【発明者】
【氏名】カシャイ、ヤロン
(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】
前記複数のシナリオのうちの少なくとも２つを、並行して、又は順次に実行するようにさらに構成されている、請求項１５に記載のシステム。
【請求項26】
前記複数のシナリオのうちの各シナリオ及び前記複数のエージェントのうちの各エージェントが、測定可能シナリオ記述言語（ＭＳＤＬ）で記述されている、請求項１５に記載のシステム。
【請求項27】
前記ＭＳＤＬが前記自律車両及び物理オブジェクトの前記挙動を記述するための宣言型プログラム言語である、請求項２６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
この出願は、２０１９年１２月１７日に出願された米国仮出願第６２／９４９，０９８号の利益を主張するものであり、その内容は参照によって本明細書に組み込まれる。
【0002】
著作権宣言文
この特許文書における資料のすべてが、米国及び他の国々の著作権法の下で著作権保護の対象である。著作権所有者は、公的な政府の記録に掲載される特許文書又は特許情報開示の複製には異存はないが、そうでなければ他のすべての著作権が留保される。
この特許文書における資料のすべてが、米国及び他の国々の著作権法の下で著作権保護の対象である。著作権所有者は、公的な政府の記録に掲載される特許文書又は特許情報開示の複製には異存はないが、そうでなければ他のすべての著作権が留保される。
【0003】
本発明は、一般に自律車両に関し、より具体的にはそのような車両の適切な性能を監視することに関するものである。
【背景技術】
【0004】
自律車両の分野における進歩は急速である。次の十年間ではますます多くのそのような車両が道路に出てくるはずであり、また世界中の多くの都市の道路を実験車両が走り回っている。自律車両は、人によって設計されたすべての高度なデバイスと同様に、人間の創意の利益を享受するばかりでなくその短所も経験する。短所は、それ自体が、自律車両の望ましくない、予測されない、又は誤った挙動として現れ、車両の乗員並びに他の人、動物、及び車両のまわりの資産を危険に陥れる。
【0005】
そのようなエラーが生じるのを防止するために、車両は道路に出る前に最初に試験され、次いで道路に出るときには、事故を確実に防ぐために追加の予防策が導入される。加えて、それぞれのそのような車両に対して、操作又は応答のエラーが生じたときに、車両の運転をオーバーライドする能力を有する運転者が割り当てられる。これによって、もちろん、そのようなシーケンスを捕捉して車両の制御システムを更新することが可能になり、その結果、将来はそのような危険な状況の事例は防止されるであろう。しかしながら、これらの解決策は、オペレータによる介入の結果としてのそのようなエラーの捕捉又はある種の被害が生じた事例に多くを頼るのでエラーが発生しやすい。望ましくない結果に通じるエラーは、望ましくない結果が生じ得ないときには、効率的に監視されることも捕捉されることもない。
【0006】
したがって、劇的なエラーが生じるのを待つのではなく、適正動作の所定の期待値に基づいて自律車両の動作を監視することを可能にする解決策を提供するのが望ましい。したがって、自律車両をシミュレーション又は試験路などの制御された環境において多数のシナリオに晒すことによって試験しながら、自律車両の性能を系統的に監視するのが有利であろう。
【発明の概要】
【0007】
以下は本開示のいくつかの例示的実施例の概要である。この概要は、読者の便宜のために、そのような実施例の基本的了解事項を提供するように与えられるものであって、本開示の広がりを全体として定義するわけではない。この概要は、すべての企図された実施例の広汎な概要ではなく、すべての実施例の重要な要素又は重大な要素を識別することや、いくらか又はすべての態様の範囲の輪郭を付けることを意図するものでもない。この概要の唯一の目的は、１つ又は複数の実施例のいくつかの概念を、後に提示されるより詳細な説明の前ぶれとして、簡単な形式で提示することである。便宜上、「いくつかの実施例」又は「ある特定の実施例」という用語は、本明細書では本開示の単一の実施例又は複数の実施例を指すように使用され得る。
【0008】
本明細書で開示されるある特定の実施例は、被験デバイス（ＤＵＴ：ｄｅｖｉｃｅ ｕｎｄｅｒ ｔｅｓｔ）の適切な挙動を監視するための方法を含む。この方法は、複数のエージェントを生成するステップであって、複数のエージェントの各々が物理オブジェクトを記述し、複数のエージェントのうちの少なくとも１つはＤＵＴに関するエージェントである、複数のエージェントを生成するステップと、複数のシナリオを生成するステップであって、各シナリオが複数のエージェントのうちの少なくとも１つの挙動をモデル化する、複数のシナリオを生成するステップと、それぞれのエージェントをモデル化するシナリオについて、複数のエージェントとＤＵＴのエージェントとの間の相互作用を監視するステップと、を含む。
【0009】
本明細書で開示されるある特定の実施例は、被験デバイス（ＤＵＴ）の適切な挙動を監視するプロセスを処理回路に実行させるための命令を記憶した非一時的コンピュータ可読媒体も含み、このプロセスは、各々が物理オブジェクトを記述する複数のエージェントを生成するステップであって、複数のエージェントのうちの少なくとも１つがＤＵＴのエージェントである、複数のエージェントを生成するステップと、複数のシナリオを生成するステップであって、各シナリオが複数のエージェントのうちの少なくとも１つの挙動をモデル化する、複数のシナリオを生成するステップと、それぞれのエージェントをモデル化するシナリオについて、複数のエージェントとＤＵＴのエージェントとの間の相互作用を監視するステップと、を含む。
【0010】
加えて、本明細書で開示されるある特定の実施例は、被験デバイス（ＤＵＴ）の適切な挙動を監視するためのシステムを含む。このシステムは、処理回路及びメモリを備え、メモリが含む命令が、処理回路によって実行されたとき、各々が物理オブジェクトを記述する複数のエージェントを生成するステップであって、複数のエージェントのうちの少なくとも１つがＤＵＴのエージェントである、複数のエージェントを生成するステップと、複数のシナリオを生成するステップであって、各シナリオが複数のエージェントのうちの少なくとも１つの挙動をモデル化する、複数のシナリオを生成するステップと、それぞれのエージェントをモデル化するシナリオについて、複数のエージェントとＤＵＴのエージェントとの間の相互作用を監視するステップと、を実行するように構成される。
【0011】
本明細書で開示される主題は、本明細書の結びにおける特許請求の範囲において詳細に指摘され、且つ明確に特許請求される。開示された実施例の上記の目的、特徴、及び利点並びに他の目的、特徴、及び利点が、添付図面とともに以下の発明を実施するための形態を理解することによって明らかになるであろう。
【図面の簡単な説明】
【0012】
【図1】一実施例による、エージェント及びシナリオを活性化して自律車両の挙動を監視するための監視システムの概略図である。
【図2】一実施例による、自律車両用の監視システムを配備するための方法を説明する流れ図である。
【図3】一実施例による、監視システムの少なくとも１つのエージェントを生成するための方法を説明する流れ図である。
【図4A】一実施例による、割り込んで減速するシナリオの開始から終了までの概略説明図である。
【図4B】一実施例による、割り込んで減速するシナリオの追越し過程の概略説明図である。
【図4C】一実施例による、割り込んで減速するシナリオの割込み過程の概略説明図である。
【図4D】一実施例による、割り込んで減速するシナリオの減速過程の概略説明図である。
【図5】一実施例による、割り込んで減速するシナリオのカバレッジ・メトリックの概略説明図である。
【発明を実施するための形態】
【0013】
本明細書で開示される実施例は、本明細書の革新的な教示の多くの有利な用途の実例でしかないことに留意するのは重要なことである。一般に、本出願の明細書における声明は、様々な特許請求の範囲のうちいずれかを必ずしも限定するわけではない。その上に、いくつかの声明はいくつかの独創的な特徴に当てはまっても、他の特徴に当てはまるわけではない。一般に、特に別の指示がなければ、単数の要素は一般性を失うことなく複数であり得、逆の場合も同じである。
【0014】
自律車両の分野では、人間を上回る完成レベルで車両が動作することが要求される。しかしながら、人間によって設計され且つプログラムされて車両にインストールされた設計及びプログラムにおけるエラー及び障害は、望ましくない予測不能な結果をもたらす恐れがある。それゆえに、データ・ストリームを監視する監視デバイスを動作させるエージェントを生成するために測定可能シナリオ記述言語（ＭＳＤＬ：ｍｅａｓｕｒａｂｌｅ ｓｃｅｎａｒｉｏ ｄｅｓｃｒｉｐｔｉｏｎ ｌａｎｇｕａｇｅ）が使用され、そのようなデータ・ストリームは、ＭＳＤＬシナリオによって表された挙動と比較したときの監視されている車両の挙動に関する情報をもたらす。エージェントはＭＳＤＬを使用して生成され、受信ストリームを監視し、異常、重要な性能指標、及びシナリオ・カバレッジを検知して報告するように実行される。すなわち、監視されている車両の挙動が期待値と異なる場合には、その異常が報告される。ＭＳＤＬは、監視されている車両の環境内の監視されない要素を記述することも可能である。
【0015】
図１は、一実施例による、エージェント及びシナリオを活性化して自律車両の挙動を監視するための監視システム１００の例示の概略図を表すものである。監視システム１００は、メモリ１２０に対して通信可能に接続された処理ユニット１１０を備える。メモリ１２０は、ランダムアクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ－ａｃｃｅｓｓ ｍｅｍｏｒｙ）などの揮発性メモリと、読取り専用メモリ（ＲＯＭ：ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）及びフラッシュ・メモリなどの不揮発性メモリとの両方を備え得る。本明細書でさらに説明されるように、メモリ１２０は、処理ユニット１１０によって実行され得る命令を含むように割り当てられたメモリ１２０の一部を有し得る。
【0016】
データベース（ＤＢ：ｄａｔａｂａｓｅ）１３０は、処理ユニット１１０に対してさらに接続されており、本明細書でさらに論じられるように様々なタイプのデータを含み得る。データベース（ＤＢ）１３０は、処理ユニット１１０によって実行される命令又は処理ユニット１１０によって処理されるデータを含み得る。データベース（ＤＢ）１３０は、処理ユニット１１０によって準備されるか又は処理されるデータをさらに受け入れ得る。データベース（ＤＢ）１３０に含まれるデータは、エージェントなどの前もって準備された構成体を含み得、これらは本明細書でより詳細に論じられる。その上、データベース（ＤＢ）１３０は、たとえばビデオ・クリップといったデータ・ストリームを含み得、これらは開示された実施例によって自律車両の挙動を監視するために使用され得るものである。
【0017】
処理回路１１０にはネットワーク・インターフェース１４０がさらに接続されている。ネットワーク・インターフェース１４０は、監視システム１００がネットワークを通じてデータを送受信することを可能にするものであり、ネットワークは有線でも無線でもよい。関連するタイプのネットワークは、それだけではないが、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、広域ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、メトロ・エリア・ネットワーク（ＭＡＮ：ｍｅｔｒｏ ａｒｅａ ｎｅｔｗｏｒｋ）、セルラー・ネットワーク、Ｗｉ－Ｆｉ（登録商標）ネットワーク、及び類似のもの、並びにこれらの任意の組合せを含む。本明細書で説明されるデータ・ストリームは、一実施例では、ネットワーク・インターフェース１４０を使用する監視システム１００に設けられ得る。さらに、入出力（Ｉ／Ｏ）インターフェース１５０が処理ユニット１１０に接続され得る。そのようなインターフェースは、それだけではないが、コンピュータ・スクリーン、タッチスクリーン、キーボード、マウス、及び他の類似の入力デバイス、出力デバイス又は入出力デバイスを含む各種デバイスに接続性をもたらし得る。監視システム１００の様々な構成要素の用途は、本明細書でより詳細に説明される。
【0018】
処理回路１１０は、１つ又は複数のハードウェア論理素子及び回路として実現され得る。たとえば、制限なく、使用され得る例証となるタイプのハードウェア論理素子は、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、特定用途専用標準品（ＡＳＳＰ：ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｓｔａｎｄａｒｄ ｐｒｏｄｕｃｔ）、システムオンチップ・システム（ＳＯＣ：ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ ｓｙｓｔｅｍ）、グラフィック処理ユニット（ＧＰＵ：ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、テンソル処理ユニット（ＴＰＵ：ｔｅｎｓｏｒ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、汎用マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、及び類似のもの、又は計算若しくは他の情報操作を実施することができるその他のハードウェア論理素子を含む。
【0019】
メモリ１２０は（たとえばＲＡＭなどの）揮発性でよく、（たとえばＲＯＭ、フラッシュ・メモリなどの）不揮発性でよく、又はその組合せでもよい。
【0020】
１つの構成では、本明細書で開示される１つ又は複数の実施例を実施するためのソフトウェアはデータベース１３０に記憶され得る。別の構成では、メモリ１２０はソフトウェア・コード１２５などのソフトウェア・コードを記憶するように構成される。ソフトウェア・コード１２５は、ＭＳＤＬを使用して開発された任意の命令を含む。ソフトウェア・コード１２５は、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と称されようと、別様に称されようと、任意のタイプの命令を意味するように広く解釈されるものとする。命令はコード（たとえばソース・コード・フォーマット、２進コード・フォーマット、実行可能コード・フォーマット、又はその他の適切なフォーマットのコード）を含み得る。処理ユニット１１０は、命令を実行することにより、本明細書で説明される様々なプロセスを実施する。
【0021】
データベース（ＤＢ）１３０は、磁気記憶装置、光学記憶装置、及び類似のものなどの任意のタイプの記憶装置でよく、たとえばフラッシュ・メモリ若しくは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ：Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、又は所望の情報を記憶するように使用され得るその他の媒体として実現されてよい。
【0022】
本明細書で説明される実施例は、図１に示された特定の構造に限定されるわけではなく、開示された実施例の範囲から逸脱することなく他の構造が同様に使用され得ることを理解されたい。
【0023】
監視システム１００の動作を示すために実例のシナリオが説明される。他の類似のシナリオが、監視デバイスとして動作する監視システム１００で実行するために容易に開発され且つ配備され得ることが理解されよう。即座の実例のために、「割り込んで減速する」シナリオとして既知のシナリオが使用される。これは、１つの自動車が別の自動車（たとえば自律車両）の前に割り込んで減速するという、交通で頻繁に遭遇するシナリオである。
【0024】
以下は、定義及びシナリオのセットアップから、シナリオの論理的な記述、及びシナリオの最終実現まで、開示された実施例による、「割り込んで減速する」シナリオが取り込まれる様子の、ＭＳＤＬを使用した段階的な説明である。ＭＳＤＬは、シミュレーションにおいて又は自律車両が路上にあるときに取り込まれた実際のデータ・ストリームから、自律車両の応答を試験するとき若しくは監視するときに期待される通りに自律車両が動作していることを確実にするために使用される。検証の責任は、本明細書で説明されるように監視システム１００を使用してこれらの要素からシナリオを定義するためにＭＳＤＬを使用するプログラマ側にある。
【0025】
所望の挙動の検証又は監視のためのシナリオの定義が、即座の例示的事例において説明される。本発明の範囲から逸脱することなく他のシナリオが可能であることが理解されよう。この事例では、自律車両は、可能な限り車線を維持したまま基本的に一定速度で進んでよい。別の車両が、異なる車線において自律車両の背後から近づいて、自律車両を追い越すことがある。次いで、この車両が、自律車両の車線において自律車両の前へ割り込むことがある。
【0026】
次いで、この車両が自律車両の車線において自律車両の前で減速すると、自律車両は、この車両から安全距離を保つために必要な対策をとることを強いられる場合がある。所与の実例には、自律車両の挙動と他方の車両の挙動の２つの挙動が含まれることが理解されよう。シナリオの定義は、カバレッジ・メトリック及び検証目標が達成されたことを証明する等級付けメカニズムも定義する。メトリックは、限定ではなく、車間距離及び速度などの操作パラメータを目標とするものである。
【0027】
実施例によれば、すべてのシナリオが、本明細書で説明されるようにＭＳＤＬを使用して定義され、シナリオの実行はたとえばシステム１００を使用して監視される。メトリックは、当技術では重要な性能指標（ＫＰＩ：ｋｅｙ ｐｅｒｆｏｒｍａｎｃｅ ｉｎｄｉｃａｔｏｒ）とも称される。ＫＰＩは、それだけではないが、一般的には速度、距離、加速度、及び類似のものなどの物理的パラメータである。カバレッジ・メトリックは、限定ではなく、一般的には、たとえば「引継ぎが生じたか？」、「割込みが生じたか？」、「左側又は右側からの割込みが生じたか？」などの論理的記述、ブール代数記述、又は離散的記述、クエリ、及び類似のものである。
【0028】
【0029】
Ｓ２１０において、少なくとも被験デバイス（ＤＵＴ）のエージェントを含む複数のエージェントが生成される。一般的な実施例では、ＤＵＴのエージェントは自律車両（ＡＶ：ａｕｔｏｎｏｍｏｕｓ ｖｅｈｉｃｌｅ）用である。各エージェントはＭＳＤＬを使用して記述され、使用法の実例が提供され、ＭＳＤＬの、限定ではない、より詳細な説明が以下に与えられる。
【0030】
エージェントは、新規に生成されるエージェントを記述するために以前に生成されたエージェントを使用し得る。したがって、エージェントの階層構造が確立される。一実施例では、ルート・エージェントは、直接、又はその階層構造のレベルを通じて、すべてのエージェントを呼び出すエージェントである。エージェントは、ＤＵＴ、車両、道路、歩道、人、動物、交通信号、コーン、防護壁、自転車、列車、気象要素、危険な要素、及び類似の物理オブジェクトを記述し得る。提供されたリストは網羅的なものではなく、ＭＳＤＬ、エージェントの階層構造又は両方を使用して他のエージェントが記述され得ることを理解されたい。そのようなエージェントは、処理ユニット１１０によって実行されるユーザ・インターフェース（図示せず）を介して手作業で生成され得、又は自動的に生成され得ることがさらに理解されよう。
【0031】
自動抽出は、限定ではなく、たとえばビデオ・ストリームといったデータ・ストリームを使用することによって達成され得、エージェントは所望の物理オブジェクト用に生成される。データ・ストリームは、ネットワーク・インターフェース１４０を通じてリアルタイムで供給されてよく、又はデータベース（ＤＢ）１３０に記憶されてオフラインで使用されてもよい。エージェントは、既に前もって定義されたエージェントは再現しないことを許容する下位階層エージェントへの参照を含み得る。たとえば、限定ではなく、環境照明の変化の結果として車両が照明を動作させるが、ヘッドライトをオンにする物理オブジェクトがエージェントとして既に存在する場合には、車両のエージェントを生成するとき、以前に生成されたエージェントを使用するのが有効であり得る。
【0032】
Ｓ２２０において複数のシナリオが生成され、シナリオはＭＳＤＬを使用して記述されてもよく、エージェントの挙動をモデル化し得る。たとえば、限定ではなく、自動車は運転シナリオを有し得、歩行者は歩行シナリオを有し得、交通信号は信号灯変更シナリオを有し得る、等である。交通シナリオには、実例として、制限なく、ＤＵＴの前に自動車が割り込む割込みシナリオ、たとえば２つの別々の車線からＤＵＴの前に２台の自動車が割り込む両側からの割込みシナリオ、自動車がＤＵＴの前に割り込んでから減速する、割り込んで減速するシナリオ、及び類似のものなどの、複数の自動車が相互作用する、より複雑なシナリオがあり得ることを認められたい。
【0033】
これらの複雑なシナリオは、関与するシナリオにおいて、下位レベルのシナリオを適切に実施するように活性化し得る。すなわち、「割込み」は、自動車の各々について運転シナリオを呼び出してよく、それによって「割込み」シナリオを複数回呼び出す。このリストは網羅的なものではなく、ＭＳＤＬ、シナリオの階層構造又は両方を使用して他のシナリオが記述され得ることが理解されよう。そのようなシナリオは、処理ユニット１１０によって実行されるユーザ・インターフェース（図示せず）を介して手作業で生成され得、又は自動的に生成され得ることがさらに理解されよう。自動抽出は、たとえば、限定ではなく、そこからシナリオが生成されるビデオ・ストリームなどのデータ・ストリームを使用することによって達成され得る。データ・ストリームは、ネットワーク・インターフェース１４０を通じてリアルタイムで供給されてよく、又はデータベース（ＤＢ）１３０に記憶されてオフラインで使用されてもよい。本明細書でさらに説明されるように、シナリオは、既に前もって定義されたエージェントは再現しないことを許容する下位階層シナリオへの参照を含み得る。
【0034】
Ｓ２３０において、生成されたエージェント及びシナリオが、ＤＵＴのエージェントの挙動を監視するために監視システム１００によって実行される。
【0035】
Ｓ２４０において、エラー指示が供給されたかどうか検査される。一実施例では、この検査は、いつシナリオが成功裡に生じたか検知してよい。検査するステップは、重要な性能指標（パラメータ）及びそのカバレッジ・データを記憶するステップをさらに含み得る。たとえば、制限なく、ＤＵＴのエージェントが低照度の領域に入ったがＤＵＴのヘッドライトが活性化されていないときにはエラーが生成され得る。たとえば割り込んで減速するシナリオといった別の事例では、ＤＵＴのエージェントによって実行されることとして、このエージェントが、割り込んでくる車両から安全距離においてＤＵＴを減速させることが予期される。車両間の最小距離は、割り込んで減速するシナリオが一旦検知されると記憶され得る重要な性能指標（ＫＰＩ）の非限定的な実例であることが理解されよう。Ｓ２４０においてエラーが検知された場合にはＳ２５０で実行が継続する。そうでなければＳ２６０で実行が継続する。
【0036】
Ｓ２５０において、エラーが検知されたことを指示する通知が生成される。一実施例では、エラー通知をもたらしたシナリオがさらに与えられ、特定の事例におけるＤＵＴのエージェントに応えてエラーをもたらしたシーケンスの再形成を可能にする他の通知、並びに任意のその組合せが与えられ得る。
【0037】
Ｓ２６０において、たとえば追加のエージェント及び／又はシナリオを生成することによって、監視を継続するべきかどうかが検査され、継続するべきであればＳ２３０で実行を継続する。そうでなければ実行は終結する。
【0038】
【0039】
Ｓ３１０において、監視システム１００によってデータ・ストリームが受け取られる。データ・ストリームは、たとえばリアルタイム・ビデオを求めてネットワーク・インターフェース１４０を通じて、又はたとえばオフライン・ビデオ処理するためにデータベース（ＤＢ）１３０から、受け取られ得る。
【0040】
Ｓ３２０において、たとえばＤＵＴ、車両、歩道、人、又は類似のものの物理オブジェクトが選択される。選択は、たとえばＩ／Ｏネットワーク・インターフェース１４０に接続されたポインティング・デバイス（図示せず）を、データ・ストリームによって供給された物理オブジェクトを指示して選択するように使用することを可能にするユーザ・インターフェース（図示せず）によって実施され得る。Ｓ３２０における選択は、開示された実施例の範囲から逸脱することなく、物理オブジェクトの各々のエージェントをそれぞれ生成するために、複数の物理オブジェクトを選択するように拡張され得ることが理解されよう。
【0041】
Ｓ３３０において物理オブジェクトのエージェントが生成され、この物理オブジェクトは以前に定義されたエージェントをさらに使用し得、それによってエージェントの階層構造を生成する。Ｓ３３０において生成されるエージェントは、物理オブジェクトの特性に対応する特定のタイプであり得、オブジェクト・タイプはＭＳＤＬを使用して定義される。一実施例では、手動のユーザ介入が、必要なときと場所に応じてエージェントの生成の指示を与えてよい。その上、２つ以上のエージェントが並行して生成され得る。
【0042】
Ｓ３４０において、生成されたエージェントが、たとえば一実施例におけるメモリ１２０又は別の実施例におけるデータベース（ＤＢ）１３０などのメモリに記憶される。エージェントは、本明細書で論じられたようにＭＳＤＬを使用して生成される。
【0043】
Ｓ３５０において、たとえば監視システム１００によって受け取られたデータ・ストリームを基に、より多くのエージェントが生成されるかどうかが検査され、生成される場合にはＳ３２０で実行が継続する。そうでなければ実行は終結する。
【0044】
図４Ａは、一実施例による、割り込んで減速するシナリオの例示の概略説明図４００Ａである。自律車両（ＡＶ）４１０は図においてＥＧＯと参照され、他の車両４２０は図においてＣＡＲと参照される。したがって、自律車両４２０は開始ポイント４１０Ｓにおいてシナリオを開始し、他の車両４２０は位置４１０Ｓよりも後ろの位置４２０Ｓにおいてシナリオを開始する。他の車両４２０はＡＶ ４１０に対して０よりも高い相対速度を有し、走行経路４４０上でＡＶ ４１０を追い越し、ＡＶ ４１０の車線に割り込んでから減速して、位置４２０Ｅに達する。これによって、経路４５０上を移動しているＡＶ ４１０は、安全上の必要条件を維持するために他の車両４２０の速度変化に適応するように減速を強いられることにより、位置４２０Ｅでシナリオを終結する。
【0045】
【0046】
図４Ｂは、一実施例による、割り込んで減速するシナリオの追越し過程の概略説明図４００Ｂである。図４Ｂで説明された第１の過程は、開始位置と、車両４２０がＡＶ ４１０よりも先に出る位置の間で定義される。この過程では、車両４２０は、同一車線にとどまるＡＶ ４１０Ａを追い越すために、４２０Ｓから４２０Ａまで加速して距離４４０Ａを進む。この期間中に、ＡＶ ４１０は４１０Ｓにおいて開始して４２０Ａまで継続し、速度及び軌跡を維持して距離４５０Ａを走る。
【0047】
図４Ｃは、一実施例による、割り込んで減速するシナリオの割込み過程の概略説明図４００Ｃである。図４Ｃに表された第２の過程では、４２０Ａにおいて開始した車両が車線を変更し、位置４２０ＣにおいてＡＶ ４１０Ａの前に入り、距離４４０Ｃを走る。ＡＶ ４１０Ａから距離４５０Ｃを走ってＡＶ ４１０Ｃに到達したこのとき、割込みが攻撃的（すなわち鋭い角度での車線変更及び／又はＡＶ ４１０Ａと車両４２０Ａとの間の短い車間距離）でなければ、引き続きその速度及び軌跡が維持される。第２の過程の最後における車両４２０Ａの速度は、第２の過程の開始における速度以上であり得る。このときＡＶ ４１０の新規の位置（車両４２０Ａによる割込み後のＡＶ ４１０）が４１０Ｃとして示され、車両４２０Ａは、このとき４２０Ｃ（ＡＶ ４１０Ａの前に割り込んだ後の車両４２０（このときＡＶ ４１０Ａは、別の位置にあるので、ＡＶ ４１０Ｃと称される））として示されることが理解されよう。
【0048】
図４Ｄは、一実施例による、割り込んで減速するシナリオの減速過程の概略説明図４００Ｄである。図４Ｄに示される第３の過程では、車両４２０Ｃがブレーキをかけ、ＡＶ ４１０Ｃからの距離が４５０Ｅのときに、ＡＶ ４１０Ｃは同様に反応しなければならない。この第３の過程に入るとき、ＡＶ ４１０Ｃの最終速度はどちらの車両の開始速度よりも低いものである。このシナリオが終わったとき、ＡＶ ４１０はＡＶ ４１０Ｅの位置にあり、ＡＶ ４２０はＡＶ ４２０Ｅの位置にある。一実施例によれば、ＭＳＤＬは、シナリオのより小さいサブシナリオ又はサブ過程へのセグメント化を可能にし、たとえば本明細書でさらに説明されるようにｄｏ＿ｓｅｒｉａｌ命令による組込み連鎖メカニズムをもたらし得る。
【0049】
図５は、一実施例による、割り込んで減速するシナリオのカバレッジ・メトリックの概略説明図である。図５に記述されている表記法は、ｒｅｌ＿ｄ＿ｃｌｓは車線変更開始ポイントにおける相対距離を（［０．．１５００］ｃｍにおいて５０ｃｍ間隔で）記述するものであり、ｅｇｏ＿ｖ＿ｃｌｓは車線変更開始ポイントにおけるＡＶ ４１０の絶対速度を（［１０．．１３０］ｋｍ／ｈにおいて１０ｋｍ／ｈ間隔で）記述するものであり、ｒｅｌ＿ｖ＿ｃｌｓは、車線変更開始ポイントにおける車両４２０のＡＶ ４１０に対する相対速度を（［－３３．．３３］ｍ／ｓにおいて１ｍ／ｓ間隔で）記述するものであり、ｒｅｌ＿ｄ＿ｃｌｅは車線変更終了ポイントにおけるＡＶ ４１０と車両４２０との間の相対距離を（［０．．３０００］ｃｍにおいて５０ｃｍ間隔で）記述するものであり、ｅｇｏ＿ｖ＿ｃｌｅは車線変更終了ポイントにおけるＡＶ ４１０の絶対速度を（［１０．．１３０］ｋｍ／ｈにおいて１０ｋｍ／ｈ間隔で）記述するものであり、ｒｅｌ＿ｖ＿ｃｌｅは車線変更終了ポイントにおける車両４２０のＡＶ ４１０に対する相対速度を（［－３３．．３３］ｍ／ｓにおいて１ｍ／ｓ間隔で）記述するものである。
【0050】
上記で説明されたものなどのカバレッジ・メトリック及び類似のもの、並びにそれらの任意の組合せは、開示された実施例によって、シナリオを手作業で実施するか又は自動的に実施するために使用され得る。
【0051】
割り込んで減速するシナリオの実例は、ＭＳＤＬを使用して以下のように定義され得る。
【数1】
【0052】
上記の例では、自動車エージェントのタイプのフィールドｃａｒ１、自動車がｅｇｏに対して開始する初期の側、及び道路の範囲が定義される。次いで、経路長は［１００．．２５０］メートルであり、経路には少なくとも２つの車線が必要である、と制約を加える。
【0053】
ＭＳＤＬでは、すべてのフィールドは、特に指定がない限りデフォルトでランダム化することができる。これは、各フィールドが、それらの正規値空間の内部での実行時にランダム値を与えられることを意味する。すべてのフィールドが、そのタイプの値の範囲によって定義された物理量空間、並びに物理量空間とそれに対して適用される何らかの制約との間の共通部分である正規値空間を有する。たとえば、側方フィールドは、適用される制約がないことを所与として、［ｌｅｆｔ，ｒｉｇｈｔ］の物理量空間及び同じ正規値空間を有する。他方では、経路フィールドが有する物理量空間は、マップが提供することができるすべての道路範囲のセットであり、一方、正規値空間は［１００．．２５０］メートル以内の長さ及び少なくとも２つの車線を有する道路範囲のみに縮小される。「＋ｐａｔｈ＿＊」は、選択される道路範囲の特性に対して適用される制約である。一実施例では、ＭＳＤＬは、シナリオ又はエージェントを定義するのを支援する多数のエージェントを提供し得る。エージェント及びシナリオは、必要に応じて、本明細書で説明されたように自動的に定義され得、又は手作業で定義され得る。いかなるシナリオも、エージェントのコンテキストにおいて定義され且つ実行されなければならない。
【0054】
したがって、シナリオの挙動は以下のように定義され得る。
【数2】
【0055】
上記の例では、「ｄｏ ｓｅｒｉａｌ」は、定義された順序で連鎖する順次のアクティビティを記述する組込みオペレータである。例示的実施例では、「ｇｅｔ＿ａｈｅａｄ＿ｏｆ＿ｅｇｏ」が最初に実行され、「ｃｕｔ＿ｉｎ」が続き、「ｓｌｏｗ＿ｄｏｗｎ」がそれに続く。「ｐｈａｓｅ」は並行アクティビティを記述する別の組込みオペレータである。たとえば「ｅｇｏ＿ｃａｒ．ｄｒｉｖｅ（）」と「ｃａｒ１．ｄｒｉｖｅ（）」は並行して実行される。それぞれの過程は、開始時点及び終了時点を有する。同様に、「ｄｏ ｓｅｒｉａｌ」は最初の過程の開始において始まり、最後の過程の終端において終了する。
【0056】
過程の終了条件の完全なリストはＳＤＬ言語マニュアルに見いだされ得る。一実施例によれば、ＭＳＤＬ監視システム１００は、ｃｕｔ＿ｉｎ過程の開始においてｃａｒ１がｅｇｏの側にあるようにｃａｒ１の軌跡を計画する。言い換えれば、ＭＳＤＬベースの監視システム１００は、ｃｕｔ＿ｉｎの開始において所望位置を得るためにすべての必要な動きを推測するように適合され、それによって、結果として試験技術者の業務が容易になり、より多様で具体的なシナリオが生成されることにより、先行技術の解決策に対する大幅な技術的改善をもたらす。
【0057】
与えられる記述は、システムがシナリオを引き起こすようにｃａｒ１を積極的に制御する状況を記述することが理解されよう。一実施例では、ｃａｒ１はデータ・ストリーム（たとえばビデオ・クリップ）から選択され、「割り込んで減速する」シナリオに記述された相互作用が起こったかどうかを確かめるために監視される。例示的実施例では、システム１００（図１）は、ｃａｒ１の制御に関して受動的である。
【0058】
一実施例では、シナリオの範囲内で、シナリオの定義の中又はシナリオの拡張（「アスペクト」とも称される）の中で、カバレッジをさらに定義することが可能である。以下は、割込みカバー・シナリオの拡張の非限定的な実例である。
【数3-1】
【数3-2】
【0059】
一実施例によれば、カバレッジを定義する試験技術者は、どのパラメータ値をサンプリングするか、それをいつサンプリングするか、といった２つの面を考慮に入れる。ＭＳＤＬ監視システム１００を使用して、試験技術者は、サンプリングするべきパラメータを指定するとともにサンプリングする必要のある値のセット（たとえば単位、値範囲）を改良するための構成を与えられる。カバレッジ定義は、パラメータをサンプリングするべき時間における瞬間を規定するイベントを使用する。上記の例では、「ｃｈａｎｇｅ＿ｌａｎｅ．ｓｔａｒｔ」及び「ｃｈａｎｇｅ＿ｌａｎｅ．ｅｎｄ」は、パラメータのサンプリングを活性化するサンプリング・イベントである。試験技術者は所定のイベントを使用することができ、又はそのような所定のイベントを再利用する特化されたイベントを定義して起動することができる。
【0060】
一実施例によれば、試験フローの第１のステージは、監視システム１００にＭＳＤＬソースをロードすることである。次のステップでは、シナリオが使用するマップをロードして解釈する。この時点において、ＭＳＤＬ監視システム１００はアクションのリストを計画する準備ができている。この過程は、シナリオに記述されていた挙動を、より高い細分性の運転シナリオへと拡張する。また、この過程は、シナリオにおける様々な過程を連鎖させる。
【0061】
計画過程がうまくいくと、試験はシミュレーションに移る。この過程では、ＭＳＤＬ監視システム１００はシミュレータとの相互作用を開始し、計画の目標を達成するために、必要に応じて、シミュレーションを進め、エージェントの動的情報（位置、速度、加速度）を取得して、計画を調節する。特に、いかなるＡＶシミュレーションでも、状況に対処するために予測不能の判定を採用することができるＡＶは、交通状況によって微量の予測不可能性を強いられる。これは、計画が必ずしも現実と一致するとは限らないことを意味し、ＭＳＤＬ監視システム１００は、それぞれのシミュレーション・ステップの最後に計画を調節することによって、ＡＶ挙動の副作用を緩和する。
【0062】
別の実施例では、ＭＳＤＬソースファイルはシステム（たとえば監視システム１００）にロードされてよい。その後データ・ストリームが供給される。物理オブジェクトの選択に基づき、本明細書で説明されて開示された実施例に従ってエージェントが生成される。次いで、生成されたエージェントのアクティビティが、たとえば「割り込んで減速する」シナリオに関連して監視される。監視システムは、シナリオにおけるステップの出現を検知したときイベントを生成する。カバレッジ情報はシステムによって保存され、それに応じてそれぞれのメッセージが発行される。
【0063】
以下は、エージェント及びシナリオを定義するために様々な実施例によって利用されるＭＳＤＬの説明である。自律車両（ＡＶ）又は最新運転者支援システム（ＡＤＡＳ：ａｄｖａｎｃｅｄ ｄｒｉｖｅｒ ａｓｓｉｓｔａｎｃｅ ｓｙｓｔｅｍ）の安全性を検証するために、様々な状況又はシナリオにおいて車両の挙動又はシステムを観測するべきである。測定可能シナリオ記述言語（ＭＳＤＬ）を使用すると、環境におけるＡＶの挙動並びに他のアクタを記述するシナリオを定義して生成することができる。アクタは車両、歩行者、天候、道路条件などを含む。
【0064】
ＭＳＤＬシナリオは高レベルの記述であるため、速度、車両タイプ、気象条件などのシナリオ・パラメータを変化させることによってシナリオの多くの具体的な変形形態が生成され得る。一実施例では、ＭＳＤＬツールは、規定された制約のセットの範囲内で、これらの変形形態を自動的に生成し得る。そのような制約はユーザによって与えられ得る。一実施例では、ＭＳＤＬツールは、成功した試験からパラメータ・データを収集して集約し、それによってＡＶの安全性を測定することが可能になる。
【0065】
ＭＳＤＬは概ね宣言型のプログラム言語である。自動的に実行する唯一のシナリオはトップレベルのシナリオである。プログラムの実行フローは、トップレベルのシナリオにシナリオを追加することによって制御され得る。ＭＳＤＬはアスペクト指向のプログラム言語であり、オブジェクトのいくつか又はすべてのインスタンスの挙動又はアスペクトに対する変更は、オブジェクトの元の記述を乱すことなく、特定の検証試験の目的に適合され得る。
【0066】
ＭＳＤＬはシナリオを記述するように設計された小規模の領域特化型言語であり、自動車及び歩行者などのアクタ（エージェントと称されることもある）は環境を通って進む。これらのシナリオはパラメータを有し、それによって、アクタ、動き、及び環境の制御及び制約が可能になる。ＭＳＤＬはシナリオ及び試験の構成を助長するように設計されており、ユーザ独自の技法を用いて複雑な挙動を定義することを可能にするものである。最小限の拡張可能なアクタ及びシナリオのセットは、基本的なビルディング・ブロックを含む。いくつかの組込みシナリオは、並列実行の実施など、すべてのシナリオに共通のタスクを実施する。他の組込みシナリオは、「ｃａｒ．ｄｒｉｖｅ」シナリオなどの比較的複雑な挙動を記述する。
【0067】
これらのシナリオを呼び出すことにより、車両が道を譲れの標識に近づいていることなどの、より複雑な挙動が記述され得る。さらなる複雑さのために複数のシナリオが混合され得る。たとえば、天候シナリオが自動車シナリオと混合され得る。新規のアクタ及び新規のシナリオは、必要に応じて、ゼロから、又は既に定義されているシナリオを使用して、簡単に生成される。たとえば、以下で提示されるシナリオ「ｃｕｔ＿ｉｎ」は、シナリオ「ｃａｒ．ｄｒｉｖｅ」を使用して定義される。一実施例では、すべてのシナリオを支持するために標準的なシナリオ・ライブラリが提供される。新規のシナリオ又はカスタマイズされたシナリオが、必要に応じてライブラリに追加される。
【0068】
ＭＳＤＬのビルディング・ブロック
ＭＳＤＬのビルディング・ブロックは、少なくとも以下のものを含むデータ構造である。
・簡単なストラクト － 属性、制約などを含む基本的エンティティ。
・アクタ － ストラクトに類似であるが関連するシナリオも有する。
・シナリオ － アクタの挙動を記述する。
ＭＳＤＬのビルディング・ブロックは、少なくとも以下のものを含むデータ構造である。
・簡単なストラクト － 属性、制約などを含む基本的エンティティ。
・アクタ － ストラクトに類似であるが関連するシナリオも有する。
・シナリオ － アクタの挙動を記述する。
【0069】
これらのデータ構造は、スカラ値、リスト、及び他の構造を保持する属性を有する。属性値は表現として記述されるか又は外部の方法の定義によって計算される。属性値はｋｅｅｐ（）制約を用いて制御可能であり、たとえばｋｅｅｐ（ｓｐｅｅｄ ＜ ５０ｋｐｈ）とする。
【0070】
シナリオにおける属性値も、ｋｅｅｐ（）制約又はｓｐｅｅｄ（）などのシナリオ・モディファイアを用いて制御可能である。たとえば、ｓｐｅｅｄ（２０ｋｐｈ， ｆａｓｔｅｒ＿ｔｈａｎ： ｃａｒ１）とする。
【0071】
データ構造はイベントも定義し、たとえばイベントｔｏｏ＿ｃｌｏｓｅは（ｄｉｓｔａｎｃｅ＿ｂｅｔｗｅｅｎ（ｃａｒ１， ｃａｒ２） ＜ １０ｍ）である。シナリオの挙動は、組込みシナリオを呼び出すことによって記述され得る。シナリオを、直列実行モード若しくは並列実行モードで実施するか又は別のシナリオと混合するために、直列、並列、又は混合といったオペレータ・シナリオが、活性化され得、又は呼び出され得る。他の組込みシナリオは、発する、待つ、又はエラー報告などの、時間に関連したアクションを実施する。
【0072】
例示のシナリオ
実例１は、ＭＳＤＬを使用して、アクタを定義して拡張するための方法を示すものである。最初に、アクタｃａｒ＿ｇｒｏｕｐが２つの属性を用いて定義される。次いで、このアクタは、別の属性を追加するために、異なるファイルにおいて拡張される。
実例１は、ＭＳＤＬを使用して、アクタを定義して拡張するための方法を示すものである。最初に、アクタｃａｒ＿ｇｒｏｕｐが２つの属性を用いて定義される。次いで、このアクタは、別の属性を追加するために、異なるファイルにおいて拡張される。
【数4】
【0073】
実例２は、ＭＳＤＬを使用する、ｔｗｏ＿ｐｈａｓｅｓという名の、新規のシナリオを定義するための方法を示すものである。このシナリオは、緑色のトラックである単一の属性ｃａｒ１を定義し、直列オペレータ及び並列オペレータを使用してｃａｒ１．ｄｒｉｖｅのシナリオを活性化し、次いでｓｐｅｅｄ（）モディファイアを適用する。Ｔｗｏ＿ｐｈａｓｅｓシナリオは以下のように動作する。
・第１の過程中にｃａｒ１は０ｋｐｈから１０ｋｐｈまで加速する。
・第２の過程中にｃａｒ１は１０～１５ｋｐｈの速度を維持する。
・第１の過程中にｃａｒ１は０ｋｐｈから１０ｋｐｈまで加速する。
・第２の過程中にｃａｒ１は１０～１５ｋｐｈの速度を維持する。
【数5】
【0074】
実例３は、実行される試験を以下のように定義する方法を示すものである。
１．たとえばＳＵＭＯシミュレータといったシミュレータを使用して試験を実行するために、適切な構成をインポートする。
２．定義されたｔｗｏ＿ｐｈａｓｅｓシナリオをインポートする。
３．事前に定義された最初は空のｔｏｐ．ｍａｉｎシナリオを拡張して、インポートされたｔｗｏ＿ｐｈａｓｅｓシナリオを起動する。
実例４は、割込みシナリオを定義するための方法を示すものである。このシナリオでは、ｃａｒ１が、左側又は右側からｄｕｔ．ｃａｒの前に割り込む。ｅｇｏ ｃａｒとも称されるｄｕｔ．ｃａｒは事前に定義されている。このシナリオはｔｗｏ＿ｐｈａｓｅｓよりも抽象的であることに留意されたい。「割込み」シナリオは以下の３つのパラメータを含む。
・ｃｕｔ＿ｉｎを行う自動車（ｃａｒ１）。
・ｃｕｔ＿ｉｎの側（左側又は右側）。
・少なくとも２つの車線を有するものと制約された、２台の自動車によって使用される経路（道路）。
次いで、以下のように挙動が定義される。
・第１の過程においてｃａｒ１がｅｇｏを追い越す。
・第２の過程においてｃａｒ１がｅｇｏの前に割り込む。
ｓｐｅｅｄ（）、ｐｏｓｉｔｉｏｎ（）及びｌａｎｅ（）といったシナリオ・モディファイアはここで使用される。それぞれが、絶対項又は同一の過程における別の自動車との関係のいずれかで規定され得る。それぞれが、全過程について、又は単に過程の開始ポイント若しくは終了ポイントについて、規定され得る。
１．たとえばＳＵＭＯシミュレータといったシミュレータを使用して試験を実行するために、適切な構成をインポートする。
２．定義されたｔｗｏ＿ｐｈａｓｅｓシナリオをインポートする。
３．事前に定義された最初は空のｔｏｐ．ｍａｉｎシナリオを拡張して、インポートされたｔｗｏ＿ｐｈａｓｅｓシナリオを起動する。
【数6】
実例４は、割込みシナリオを定義するための方法を示すものである。このシナリオでは、ｃａｒ１が、左側又は右側からｄｕｔ．ｃａｒの前に割り込む。ｅｇｏ ｃａｒとも称されるｄｕｔ．ｃａｒは事前に定義されている。このシナリオはｔｗｏ＿ｐｈａｓｅｓよりも抽象的であることに留意されたい。「割込み」シナリオは以下の３つのパラメータを含む。
・ｃｕｔ＿ｉｎを行う自動車（ｃａｒ１）。
・ｃｕｔ＿ｉｎの側（左側又は右側）。
・少なくとも２つの車線を有するものと制約された、２台の自動車によって使用される経路（道路）。
次いで、以下のように挙動が定義される。
・第１の過程においてｃａｒ１がｅｇｏを追い越す。
・第２の過程においてｃａｒ１がｅｇｏの前に割り込む。
ｓｐｅｅｄ（）、ｐｏｓｉｔｉｏｎ（）及びｌａｎｅ（）といったシナリオ・モディファイアはここで使用される。それぞれが、絶対項又は同一の過程における別の自動車との関係のいずれかで規定され得る。それぞれが、全過程について、又は単に過程の開始ポイント若しくは終了ポイントについて、規定され得る。
【数7】
【0075】
実例５は、ｃｕｔ＿ｉｎシナリオを使用してｔｗｏ＿ｃｕｔ＿ｉｎシナリオを定義するための方法を示すものである。ｔｗｏ＿ｃｕｔ＿ｉｎシナリオは、左側からのｃｕｔ＿ｉｎシナリオに続けて右側からのｃｕｔ＿ｉｎを実行するものである。その上、包含される２台の自動車の色は異なるものと制約される。
【数8】
【0076】
実例６は、具体的な値を用いてｃｕｔ＿ｉｎを実行するための方法を示すものである。元のｃｕｔ＿ｉｎは範囲を指定しており、そのため、それぞれの実行は、デフォルトで、その範囲内でランダム値を選択することになる。試験は、制約を使用して具体的なものとして定義され得る。
【数9】
【0077】
実例７は、ｃｕｔ＿ｉｎシナリオ、ｉｎｔｅｒｃｅｐｔｏｒ＿ａｔ＿ｙｉｅｌｄと称される別のシナリオ、及びｓｅｔ＿ｗｅａｔｈｅｒシナリオといった複数のシナリオを混合するための方法を示すものである。危険な状況が望まれるため、ｍｉｘ＿ｄａｎｇｅｒｓシナリオは、よくないように（すなわち！ｎｉｃｅ）制約されたｗｅａｔｈｅｒ＿ｋｉｎｄタイプの単一の属性を有する。この属性はｓｅｔ＿ｗｅａｔｈｅｒに渡される。
【数10】
【0078】
実例８はｍｉｘ＿ｄａｎｇｅｒｓを実行するものである。この場合、非特異性の用語（たとえばよくない天候）ではなく具体的な天候（雨）が規定される。
【数11】
【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】
ｍａｐ、ｅｎｖ、ｔｒａｆｆｉｃ及びｄｕｔはｔｏｐにおけるフィールドとしてインスタンスを作成されるため、これらのフィールドは、階層構造におけるそれらの場所に関係なく、全体的なアクタとして、たとえば以下のように直接アクセスされ得ることに留意されたい。
あらゆるアクタが、この階層構造においてアクタを追加するように拡張され得る。ＭＳＤＬは、実行の前に、又は実行中にアクタを生成することができる。生成に際して、アクタのフィールドは規定された制約に従ってランダム化され、その組込みのｓｔａｒｔシナリオがアクティブ・モードで動作し始める。ｓｔａｒｔシナリオによって実行され得る他のシナリオもアクティブ・モードで動作する。シナリオｔｏｐ．ｍａｉｎ（）は、ｔｏｐ．ｓｔａｒｔ（）から間接的に呼び出される。このシナリオは当初は空であり、試験が何を行うか定義する。したがって、試運転を実行するために、ｔｏｐ．ｍａｉｎを拡張することができるｃｕｔ＿ｉｎ＿ａｎｄ＿ｓｌｏｗシナリオが次のように拡張され得る。
【数12】
あらゆるアクタが、この階層構造においてアクタを追加するように拡張され得る。ＭＳＤＬは、実行の前に、又は実行中にアクタを生成することができる。生成に際して、アクタのフィールドは規定された制約に従ってランダム化され、その組込みのｓｔａｒｔシナリオがアクティブ・モードで動作し始める。ｓｔａｒｔシナリオによって実行され得る他のシナリオもアクティブ・モードで動作する。シナリオｔｏｐ．ｍａｉｎ（）は、ｔｏｐ．ｓｔａｒｔ（）から間接的に呼び出される。このシナリオは当初は空であり、試験が何を行うか定義する。したがって、試運転を実行するために、ｔｏｐ．ｍａｉｎを拡張することができるｃｕｔ＿ｉｎ＿ａｎｄ＿ｓｌｏｗシナリオが次のように拡張され得る。
【数13】
【0104】
所定のｅｎｖアクタ
ｅｎｖアクタはグローバル・アクタであり、すべての環境関連のアクティビティを含む。たとえば、ｅｎｖアクタは、ｗｅａｔｈｅｒ及びｔｉｍｅ＿ｏｆ＿ｄａｙのような環境を変更するシナリオを有し、たとえば次のようにする。
タイプ部分はｍｏｒｎｉｎｇ、ｎｏｏｎ、ｅｖｅｎｉｎｇ、又はｎｉｇｈｔであり、種類はｒａｉｎ、ｓｎｏｗ、ｓｕｎｓｈｉｎｅである。たとえば次のようにする。
ｅｎｖアクタはグローバル・アクタであり、すべての環境関連のアクティビティを含む。たとえば、ｅｎｖアクタは、ｗｅａｔｈｅｒ及びｔｉｍｅ＿ｏｆ＿ｄａｙのような環境を変更するシナリオを有し、たとえば次のようにする。
【数14】
タイプ部分はｍｏｒｎｉｎｇ、ｎｏｏｎ、ｅｖｅｎｉｎｇ、又はｎｉｇｈｔであり、種類はｒａｉｎ、ｓｎｏｗ、ｓｕｎｓｈｉｎｅである。たとえば次のようにする。
【数15】
【0105】
所定のｃａｒアクタ・フィールド
ｃａｒアクタの続くフィールドは、許容されたタイプのシミュレータと一致するように、拡張され得、又は制約され得る。これらのフィールドはサンプリングされ、カバレッジ定義に使用され得る。
ｃａｒアクタはまた、ｄｒｉｖｅと称されるシナリオを有する。ｄｒｉｖｅは運転シナリオであり、運転する経路を表す経路パラメータを有する。シナリオ・モディファイアは自動車のｄｒｉｖｅシナリオの内部で規定され得る。
ｃａｒアクタの続くフィールドは、許容されたタイプのシミュレータと一致するように、拡張され得、又は制約され得る。これらのフィールドはサンプリングされ、カバレッジ定義に使用され得る。
【表1】
ｃａｒアクタはまた、ｄｒｉｖｅと称されるシナリオを有する。ｄｒｉｖｅは運転シナリオであり、運転する経路を表す経路パラメータを有する。シナリオ・モディファイアは自動車のｄｒｉｖｅシナリオの内部で規定され得る。
【0106】
所定の列挙型
以下の表には様々な列挙型が列挙されている。
以下の表には様々な列挙型が列挙されている。
【表2】
【0107】
ユーザ・タスクの流れ
ＭＳＤＬがサポートする検証タスクの流れは以下の通りである。
１．検証プロジェクトを計画する。
・都会の運転、ハイウェイ運転、天候、センサ誤動作などのリスク範囲を表すトップレベルのシナリオのカテゴリを識別する。
・シナリオのサブカテゴリを識別する。たとえば、車線変更はハイウェイ運転のサブカテゴリであり得る。
・各シナリオ・サブカテゴリにおける挙動を識別する。たとえば、割り込んで減速することは、車線変更のサブカテゴリにおける挙動であり得る。
・各シナリオがどのくらいくまなくカバーされたか（首尾よく訓練されたか）を判定するためにカバレッジ収集ポイントを識別する。たとえば、割り込んで減速する挙動は、道路条件、距離、及び速度を含むカバレッジ・ポイントを有し得る。
・ＤＵＴが様々なシナリオにおいていかに良く動作したかを判断するために使用される検査基準（等級付け）を識別する。
・それらの挙動及びシナリオのカバレッジ目標を識別する。
２．検証環境を生成する。
・下位レベルの組込みシナリオ及びライブラリの中の利用可能なものに基づき、ＭＳＤＬにおけるシナリオ、挙動及びカバレッジ・ポイントを記述する。
・ＤＵＴ及び実行プラットフォームを識別する。
・使用され得るその他の追加のツールを識別する。
３．試運転を自動化する。
・場合により相争う車線変更を伴って割り込んで減速することなど、異なるサブカテゴリからのシナリオを混合して、試験を書く。
・道路条件、速度及び可視性などのシナリオの変数に対して異なる値を用いて複数の実行を開始する。
４．障害を分析する。
・衝突又は衝突危険などのあらゆる検査エラーの原因を識別する。
・試験を継続することができるように、ＤＵＴを調整するか又は一時的パッチを適用する。
・失敗したすべての実行を自動的に再実行する。
５．進展を見つける。
・検証計画において規定された各目標に関係するカバレッジ・データを分析して、どのシナリオが適切に試験されていないか、を判定する。
・それらの一般的でない事例に及ぶように新規の試験を書く。
ＭＳＤＬがサポートする検証タスクの流れは以下の通りである。
１．検証プロジェクトを計画する。
・都会の運転、ハイウェイ運転、天候、センサ誤動作などのリスク範囲を表すトップレベルのシナリオのカテゴリを識別する。
・シナリオのサブカテゴリを識別する。たとえば、車線変更はハイウェイ運転のサブカテゴリであり得る。
・各シナリオ・サブカテゴリにおける挙動を識別する。たとえば、割り込んで減速することは、車線変更のサブカテゴリにおける挙動であり得る。
・各シナリオがどのくらいくまなくカバーされたか（首尾よく訓練されたか）を判定するためにカバレッジ収集ポイントを識別する。たとえば、割り込んで減速する挙動は、道路条件、距離、及び速度を含むカバレッジ・ポイントを有し得る。
・ＤＵＴが様々なシナリオにおいていかに良く動作したかを判断するために使用される検査基準（等級付け）を識別する。
・それらの挙動及びシナリオのカバレッジ目標を識別する。
２．検証環境を生成する。
・下位レベルの組込みシナリオ及びライブラリの中の利用可能なものに基づき、ＭＳＤＬにおけるシナリオ、挙動及びカバレッジ・ポイントを記述する。
・ＤＵＴ及び実行プラットフォームを識別する。
・使用され得るその他の追加のツールを識別する。
３．試運転を自動化する。
・場合により相争う車線変更を伴って割り込んで減速することなど、異なるサブカテゴリからのシナリオを混合して、試験を書く。
・道路条件、速度及び可視性などのシナリオの変数に対して異なる値を用いて複数の実行を開始する。
４．障害を分析する。
・衝突又は衝突危険などのあらゆる検査エラーの原因を識別する。
・試験を継続することができるように、ＤＵＴを調整するか又は一時的パッチを適用する。
・失敗したすべての実行を自動的に再実行する。
５．進展を見つける。
・検証計画において規定された各目標に関係するカバレッジ・データを分析して、どのシナリオが適切に試験されていないか、を判定する。
・それらの一般的でない事例に及ぶように新規の試験を書く。
【0108】
本明細書で開示された様々な実施例は、ハードウェア、ファームウェア、ソフトウェア又はそれらの任意の組合せとして実施され得るものである。その上に、ソフトウェアは、望ましくは、特定のデバイスの一部、若しくはある特定のデバイス及び／又はデバイスの組合せから成るプログラム記憶ユニット又はコンピュータ可読媒体上に実体的に具現されたアプリケーション・プログラムとして実施される。アプリケーション・プログラムは、任意の適切なアーキテクチャを備えるマシンにアップロードされて実行され得る。望ましくは、マシンは、１つ又は複数の中央処理装置（「ＣＰＵ」）、メモリ、及び入出力インターフェースなどのハードウェアを有するコンピュータ・プラットフォーム上で実施される。コンピュータ・プラットフォームは、オペレーティング・システム及びマイクロ命令コードも含み得る。本明細書で説明された様々なプロセス及び機能は、マイクロ命令コードの一部、又はアプリケーション・プログラムの一部、又はそれらの任意の組合せのいずれかでよく、そのようなコンピュータ又はプロセッサが明示的に示されているか否かにかかわらず、ＣＰＵによって実行される得るものである。加えて、追加のデータ記憶ユニット及び印刷ユニットなどのコンピュータ・プラットフォームに、様々な他の周辺ユニットが接続され得る。その上、非一時的コンピュータ可読媒体は、一時的な伝搬信号を除いたあらゆるコンピュータ可読媒体である。
【0109】
本明細書で説明されたすべての実例及び条件付き言語は、発明者によって当技術を促進するように寄与されて開示された実施例及び概念の原理を読者が理解するのを支援するようにとの教育的な目的が意図されており、そのような特に詳述された実例及び条件を制限することのないように解釈されるべきである。その上に、開示された実施例の原理、態様、及び実施例、並びにその具体例を詳述する本明細書のすべての声明は、その構造的等価物及び機能的等価物を包含するように意図されている。加えて、そのような等価物は、現在知られている等価物ばかりでなく、将来開発される等価物、すなわち、構造には関係なく、同一の機能を実施するあらゆる開発される要素の両方を含むように意図されている。
【0110】
本明細書で使用されるように、品目のリストを伴う「少なくとも１つの」という慣用句は、列挙された品目のうちの任意のものが個々に利用され得るか、又は列挙された品目のうちの２つ以上の任意の組合せが利用され得ることを意味する。たとえば、「Ａ、Ｂ、及びＣのうちの少なくとも１つ」を含むと記述されたシステムは、Ａのみ、Ｂのみ、Ｃのみ、ＡとＢの組合せ、ＢとＣの組合せ、ＡとＣの組合せ、又はＡとＢとＣの組合せを含み得る。
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図4C】
【図4D】
【図5】
