特許 7593645 自律車両システム

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

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

(11)【特許番号】

(24)【登録日】2024-11-25

(45)【発行日】2024-12-03

(54)【発明の名称】自律車両システム

(51)【国際特許分類】

   G08G 1/00 20060101AFI20241126BHJP

   G08G 1/09 20060101ALI20241126BHJP

   G08G 1/16 20060101ALI20241126BHJP

   B60W 50/02 20120101ALI20241126BHJP

   B60W 50/04 20060101ALI20241126BHJP

   B60W 60/00 20200101ALI20241126BHJP

【ＦＩ】

G08G1/00 X

G08G1/09 V

G08G1/16 A

B60W50/02

B60W50/04

B60W60/00

【請求項の数】 29

(21)【出願番号】P 2021546208

(86)(22)【出願日】2020-03-27

(65)【公表番号】

(43)【公表日】2022-05-18

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

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

(87)【国際公開日】2020-10-08

【審査請求日】2023-03-20

(31)【優先権主張番号】62/826,955

(32)【優先日】2019-03-29

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

(73)【特許権者】

【識別番号】591003943

【氏名又は名称】インテル・コーポレーション

(74)【代理人】

【識別番号】110000877

【氏名又は名称】弁理士法人ＲＹＵＫＡ国際特許事務所

(72)【発明者】

【氏名】モウスタファ、ハスナー

(72)【発明者】

【氏名】ジャバー、スヘル

(72)【発明者】

【氏名】アイヤール、ダーシャン

(72)【発明者】

【氏名】コーダム ハズラティ、メルナズ

(72)【発明者】

【氏名】アグラワル、プラギャ

(72)【発明者】

【氏名】アエッラボツ、ナヴィーン

(72)【発明者】

【氏名】ヴァン ビーク、ペトラス ジェイ．

(72)【発明者】

【氏名】マルティネス－カナレス、モニカ ルシア

(72)【発明者】

【氏名】ロブ、パトリシア アン

(72)【発明者】

【氏名】チャットパドヒャイ、リタ

(72)【発明者】

【氏名】カヴルヤ、ソリア ピー．

(72)【発明者】

【氏名】スリパティ、カーティク レディー

(72)【発明者】

【氏名】タトウリアン、イゴール

(72)【発明者】

【氏名】ウォウヘイビ、リタ エイチ．

(72)【発明者】

【氏名】アルヴァレズ、イグナシオ ジェイ．

(72)【発明者】

【氏名】アデンワラ、ファテマ エス．

(72)【発明者】

【氏名】タンリオヴァー、カグリ シー．

(72)【発明者】

【氏名】エリ、マリア エス．

(72)【発明者】

【氏名】ザゲ、デイヴィッド ジェイ．

(72)【発明者】

【氏名】サンカラン クティー、ジシン サンカー

(72)【発明者】

【氏名】ロペズ－アライザ、クリストファー イー．

(72)【発明者】

【氏名】ガラン－オリヴェラス、マグディエル エフ．

(72)【発明者】

【氏名】チェン、リ

【審査官】佐々木 佳祐

(56)【参考文献】

【文献】米国特許出願公開第２０１８／０１９６４２７（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１７／０３４９１８６（ＵＳ，Ａ１）

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

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

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

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

Ｂ６０Ｗ ５０／０２

Ｂ６０Ｗ ５０／０４

Ｂ６０Ｗ ６０／００

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

センサデータを生成する複数のセンサと、
車両の動きを物理的に制御する制御システムと、
処理回路類であって、
前記制御システムと通信することによって、前記センサデータに基づいた経路計画にしたがって車両の運転を自律的に制御し、
前記車両の自律制御を停止すべきと決定し、
遠隔コンピューティングシステムが前記車両の運転を遠隔で制御するように、前記遠隔コンピューティングシステムにハンドオフ要求を送り、
運転命令データを前記遠隔コンピューティングシステムから受信し、
前記制御システムと通信することによって、前記運転命令データに含まれる命令に基づいて前記車両の運転を制御する、
処理回路類と
を備え、
前記車両の前記自律制御を停止すべきと決定することは、前記経路計画の次の区間の間は前記車両の前記自律制御が困難であるという予測に基づいて、前記車両の前記自律制御を停止すべきと決定することを含む、車両。

【請求項28】

前記処理回路類が退避イベントを検出し、前記車両が前記退避イベントと関連して退避し運転を停止した後で、前記ハンドオフ要求が前記退避イベントに応答して送られる、請求項２７に記載の車両。

【請求項29】

前記処理回路類が、
前記経路計画に沿った条件の、前記車両の前記自律制御を停止すべきと決定した条件からの変化を検出し、
検出した前記変化に応じて、前記車両の前記運転の制御を前記遠隔コンピューティングシステムから前記車両の自律運転論理に戻す、請求項２７または２８に記載の車両。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、「自律車両システム」という名称で２０１９年３月２９日に出願された米国仮特許出願第６２／８２６，９５５号の利益および優先権を主張し、その開示全体を参照により本明細書に組み込む。

【0002】

本開示は、全体として、コンピュータシステムの分野に関し、より詳細には、自律車両を使用可能にするコンピューティングシステムに関する。

【背景技術】

【0003】

一部の車両は、運転者からの入力がほとんどまたは全くない状態で環境を車両が走行する、自律モードで動作するように構成される。かかる車両は、一般的に、環境に関する情報を感知するように構成された１つまたは複数のセンサを含む。車両は、感知した情報を使用して、環境を走行してもよい。例えば、車両が障害物に接近していることをセンサが感知した場合、車両は障害物を避けて走行してもよい。

【図面の簡単な説明】

【0004】

【図1】特定の実施形態による、一例の自律運転環境を示す概略図である。

【0005】

【図2】特定の実施形態による、自律運転の機能性を装備した車両（および対応する車両内コンピューティングシステム）の一例の実現例を示す概略ブロック図である。

【0006】

【図3】特定の実施形態による、ニューラルネットワークの一例の一部分を示す図である。

【0007】

【図4】特定の実施形態による、様々な車両において（例えば、それらに対応する車両内コンピューティングシステムによって）対応していてもよい、自律運転の例示のレベルを示す概略ブロック図である。

【0008】

【図5】特定の実施形態による、一部の自律運転システムにおいて実現されてもよい、一例の自律運転フローを示す概略ブロック図である。

【0009】

【図6】特定の実施形態による、自律車両および様々なセンサを示す概略ブロック図である。

【0010】

【図7】特定の実施形態による、一例の遠隔バレットサービスの送達中におけるシステム間の通信を示す概略ブロック図である。

【0011】

【図8】特定の実施形態による、遠隔バレットサービスを立ち上げるのに活用されてもよい、退避イベントリスクおよび路面条件警報に関する情報の協調的報告を示す概略ブロック図である。

【0012】

【図9】特定の実施形態による、車両センサ、人工知能／機械学習ベースの自律運転スタック、および遠隔バレットサービスを提供することができるシステムに対するハンドオフ要求のトリガおよび生成に対応する論理を含む、例示の自律車両機構を示す概略ブロック図である。

【0013】

【図10】特定の実施形態による、例示の安全モデル運転フェーズを示す図である。

【0014】

【図11】特定の実施形態による、安全モデルに準拠した加速を確保するように運転者入力を修正するシステムを示す図である。

【0015】

【図12】特定の実施形態による、制御・加速変換器（ｃｏｎｔｒｏｌ－ｔｏ－ａｃｃｅｌｅｒａｔｉｏｎ ｃｏｎｖｅｒｔｅｒ）の訓練フェーズを示す図である。

【0016】

【図13】特定の実施形態による、制御・加速変換器の推論フェーズを示す図である。

【0017】

【図14】特定の実施形態による、許容可能な制御信号を車両作動システムに提供するフローを示す図である。

【0018】

【図15】特定の実施形態による、コンテキストモデルを構築する訓練フェーズを示す図である。

【0019】

【図16】特定の実施形態による、信号品質測定基準モデルを構築する訓練フェーズを示す図である。

【0020】

【図17】特定の実施形態による、ハンドオフ準備状態モデルを構築する訓練フェーズを示す図である。

【0021】

【図18】特定の実施形態による、センサデータに基づいてハンドオフ判定を決定する推論フェーズを示す図である。

【0022】

【図19】特定の実施形態による、車両の制御をハンドオフするか否かを決定するフローを示す図である。

【0023】

【図20】特定の実施形態による、運転者状態モデルの訓練フェーズを示す図である。

【0024】

【図21】特定の実施形態による、ハンドオフ判定モデルの訓練フェーズを示す図である。

【0025】

【図22】特定の実施形態による、ハンドオフ判定を決定する推論フェーズを示す図である。

【0026】

【図23】特定の実施形態による、ハンドオフ判定を生成するフローを示す図である。

【0027】

【図24】特定の実施形態による、自律車両の制御に関するフレームワークの上位ブロック図である。

【0028】

【図25】特定の実施形態による、自律車両のテイクオーバを制御する一例のプロセスを示す図である。

【0029】

【図26】特定の実施形態による、自律車両のテイクオーバを制御する更なる一例のプロセスを示す図である。

【0030】

【図27】特定の実施形態による、自律車両に対する一例の知覚、計画、および行動の自律運転パイプライン２８００を示す図である。

【0031】

【図28】特定の実施形態による、自律車両の人間の運転者によるテイクオーバ要求を制御する一例のプロセスを示す図である。

【0032】

【図29】特定の実施形態による、人間の運転者から要求される参加の様々なレベルの自動化量および関連量を示す図である。

【0033】

【図30】特定の実施形態による、包括的認知監督（ｃｏｍｐｒｅｈｅｎｓｉｖｅ ｃｏｇｎｉｔｉｖｅ ｓｕｐｅｒｖｉｓｏｒｙ）システムを示す図である。

【0034】

【図31】特定の実施形態による、例示の自律レベル遷移を示す図である。

【0035】

【図32】特定の実施形態による、Ｌ４自律レベルで動作している自律車両におけるデータの構造的フローの一例を示す図である。

【0036】

【図33】特定の実施形態による、運転者に対する映像信号の一例を示す図である。

【0037】

【図34】特定の実施形態による、一例の自律車両ハンドオフ状況のフローを示す図である。

【0038】

【図35】特定の実施形態による、自律車両の制御を人間の運転者にハンドオフするフローの一例を示す図である。

【0039】

【図36】特定の実施形態による、人間の運転者に対する自律車両のハンドオフに関する一例のシステム３６００を示す図である。

【0040】

【図37】特定の実施形態による、地点Ａから地点Ｂに行くのに車両が取ってもよい一例のルートを示す図である。

【0041】

【図38】特定の実施形態による、ハンドオフ取扱いモジュールによって少なくとも部分的に実施されてもよいフローを示す図である。

【0042】

【図39】本明細書に開示する実施形態にしたがって使用されてもよい、例示のコンピュータアーキテクチャを示すブロック図である。

【図40】本明細書に開示する実施形態にしたがって使用されてもよい、例示のコンピュータアーキテクチャを示すブロック図である。

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

【0043】

図１は、一例の自律運転環境を示す概略図１００である。車両（例えば、１０５、１１０、１１５など）は、それぞれの自律運転スタックを使用可能にする、ハードウェア、ファームウェア、および／またはソフトウェアの形で論理が実現された車両内コンピューティングシステムによって容易にされる、様々なレベルの自律運転能力を備えてもよい。かかる自律運転スタックは、車両の自己制御を許可するか、または運転者支援を提供して、車道を検出し、１つの地点から別の地点に走行し、他の車両および路上の動作主体（例えば、歩行者（例えば、１３５）、自転車運転者など）を検出し、障害物および危険物（例えば、１２０）ならびに路面条件（例えば、交通量、路面条件、気象条件など）を検出し、車両の制御および誘導を適宜調節してもよい。本開示内では、「車両」は、一人または複数人の人間の乗員を運ぶように設計された有人車両（例えば、自動車、トラック、バン、オートバイ、列車、空中輸送車両、救急車など）、人間の乗員を乗せてもしくは乗せずに運転する無人車両（例えば、貨物車両（例えば、トラック、鉄道車両など））、人間以外の乗員を運搬する車両（例えば、家畜運搬車など）、ならびに／あるいはドローン（例えば、運転環境内で移動する陸上もしくは空中ドローンまたはロボット（例えば、運転環境に関する情報を収集する、他の車両の自動化を支援する、道路保守管理業務を実施する、工業的業務を提供する、保安および緊急応答業務を提供するなど））であってもよい。いくつかの実現例では、車両は、他の例の中でも特に、複数の異なるモードで選択的に動作するように構成されたシステム（例えば、乗用車、無人車両、またはドローン車両）であってもよい。車両は、環境内で「走行」して、車両を地面（例えば、舗装もしくは未舗装道路、経路、または地形）に沿って、水中を通って、または空中を通って移動させてもよい。この意味で、「道路」または「車道」は、実現例に応じて、屋外もしくは屋内の地上経路、水路、または既定の空中境界を具体化してもよい。したがって、以下の開示および関連する実施形態は、様々な文脈および車両の実現例に等しく当てはまってもよいことが認識されるべきである。

【0044】

いくつかの実現例では、環境内の車両（例えば、１０５、１１０、１１５）は、車両内コンピューティングシステムが、１つまたは複数の技術（例えば、ＩＥＥＥ ８０２．１１通信（例えば、ＷｉＦｉ（登録商標））、セルラーデータネットワーク（例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ）（登録商標）ネットワーク、汎欧州デジタル移動体通信システム（ＧＳＭ（登録商標））、汎用パケット無線サービス、符号分割多重アクセス（ＣＤＭＡ）など）、４Ｇ、５Ｇ、６Ｇ、ブルートゥース（登録商標）、ミリ波（ｍｍＷａｖｅ）、ＺｉｇＢｅｅ（登録商標）、Ｚ－Ｗａｖｅなど（登録商標））を使用して、車両内コンピューティングシステムが、他の車両の車両内コンピューティングシステム、路側ユニット、クラウドベースのコンピューティングシステム、または他の支援インフラストラクチャなど、他のコンピューティングシステムに接続し、それらと通信することを可能にする、無線通信に対応する通信モジュールを含むという点で、「接続」されてもよい。例えば、いくつかの実現例では、車両（例えば、１０５、１１０、１１５）は、車両自体の自律運転能力を支援して、コンピューティングシステムと通信して、センサ、データ、およびサービスを提供してもよい。例えば、図１の実例に示されるように、他の例の中でも特に、支援ドローン１８０（例えば、地上および／または空中）、路側コンピューティングデバイス（例えば、１４０）、様々な外部（車両に対して、即ち「車外」）センサデバイス（例えば、１６０、１６５、１７０、１７５など）、および他のデバイスが、車両（例えば、１０５、１１０、１１５）に取り付けられたコンピューティングシステム、センサ、および論理とは別個に、自律運転インフラストラクチャとして提供されて、車両を通して提供される自律運転結果を支援し改善してもよい。車両はまた、他の例示の通信の中でも特に、無線通信チャネルを通じて他の接続された車両と通信して、データを共有し、自律運転環境内での移動を連係させてもよい。

【0045】

図１の例に示されるように、自律運転インフラストラクチャは、様々な異なるシステムを組み込んでもよい。かかるシステムは、場所に応じて変動してもよく、例えば、より発達した車道（例えば、特定の地方自治体または通行料徴収機関によって制御される車道、都市部の車道、自律車両にとって問題が多いことが知られている車道の区間など）は、車道の他の区間よりも多数のまたは高度な支援インフラストラクチャデバイスなどを有する。例えば、車道の部分および環境内を移動している車両を観察し、センサの観察を記述または具体化する対応データを生成するセンサを含む、補助センサデバイス（例えば、１６０、１６５、１７０、１７５）が提供されてもよい。例として、センサデバイスは、他の例の中でも特に、車道自体に埋め込まれるか（例えば、センサ１６０）、路側もしくは頭上の看板にあるか（例えば、標識１２５のセンサ１６５）、電子路側機器もしくは設備（例えば、信号機（例えば、１３０）、電子道路標識、電子広告掲示板など）に取り付けられたセンサ（例えば、１７０、１７５）であるか、専用路側ユニット（例えば、１４０）であってもよい。センサデバイスはまた、自身が収集したセンサデータを付近の接続された車両に直接、またはフォグベースもしくはクラウドベースのコンピューティングシステム（例えば、１４０、１５０）に通信する、通信能力を含んでもよい。車両は、外部センサデバイス（例えば、１６０、１６５、１７０、１７５、１８０）によって収集されたセンサデータ、またはこれらのセンサデバイス（例えば、１６０、１６５、１７０、１７５、１８０）からのセンサデータに基づいて、他のシステム（例えば、１４０、１５０）によって生成された観察もしくは推奨を具体化するデータを取得し、このデータを、センサフュージョン、推論、経路計画、および車両内自律運転システムによって実施される他のタスクに使用してもよい。いくつかの事例では、かかる車外センサおよびセンサデータは、実際には、車両に取り付けられるアフターマーケットセンサ、車両の乗員が携帯もしくは着用するパーソナルコンピューティングデバイス（例えば、スマートフォン、ウェアラブルなど）の形態などで、車両内にあってもよい。歩行者、自転車、ドローン、無人空中車両、ロボット、電子スクーターなどを含む、他の路上動作主体も、他の例の中でも特に、自律車両、クラウドベースもしくはフォグベースの支援システム（例えば、１４０、１５０）、他のセンサデバイス（例えば、１６０、１６５、１７０、１７５、１８０）によって使用され消費されてもよい、自律運転環境を記述するセンサデータを生成するセンサを備えるか、または携帯してもよい。

【0046】

自律車両システムは様々なレベルの機能性および精巧性を所持してもよいので、支援インフラストラクチャは、一部の車両の感知能力を補助するだけでなく、一部の車両の自律運転機能性を使用可能にする、コンピュータおよび機械学習の機能性も求められることがある。例えば、機械学習モデル訓練およびかかる機械学習モデルの使用を容易にするのに使用される、計算リソースおよび自律運転論理が、車両内コンピューティングシステムに完全に、または車両内システムおよび一部の外部システム（例えば、１４０、１５０）の両方に部分的に提供されてもよい。例えば、接続された車両は、車道の特定のセグメントに局在する路側ユニット、エッジシステム、またはクラウドベースのデバイス（例えば、１４０）と通信してもよく、かかるデバイス（例えば、１４０）は、データ（例えば、ローカルセンサ（例えば、１６０、１６５、１７０、１７５、１８０）から集約されたセンサデータ、もしくは他の車両のセンサから報告されたデータ）を提供し、車両によって提供されるデータに対して演算処理（サービスとして）を実施して車両本来の能力を補助し、ならびに／あるいは（例えば、デバイス１４０で収集された、もしくは付近のセンサデバイスなどからのセンサデータに基づいて）通過するまたは接近する車両に情報を転送することができる。接続された車両（例えば、１０５、１１０、１１５）は更に、あるいは代わりに、クラウドベースのコンピューティングシステム（例えば、１５０）と通信してもよく、それによって、同様のメモリ、センシング、および演算処理リソースを提供して、車両におけるそれらの利用可能性を強化してもよい。例えば、クラウドベースのシステム（例えば、１５０）は、１つまたは複数の場所の様々なデバイスからセンサデータを収集し、このデータを利用して機械学習モデルを構築および／または訓練してもよく、その機械学習モデルは、他の例示の実現例の中でも特に、クラウドベースのシステム１５０と通信している様々な車両（例えば、１０５、１１０、１１５）に結果を提供するか、または車両内システムが使用するように車両に転送するのに、クラウドベースのシステムで使用されてもよい。携帯電話の中継塔、路側ユニット、様々な車道インフラストラクチャに装備されたネットワークアクセスポイント、近隣の車両もしくは建物によって提供されるアクセスポイント、および他のアクセスポイントなどのアクセスポイント（例えば、１４５）は、環境内に提供され、クラウドベースのシステム（例えば、１５０）と様々な車両（例えば、１０５、１１０、１１５）との間で、１つもしくは複数のローカルエリアネットワークまたは広域ネットワーク（例えば、１５５）を通じて通信するのを容易にするのに使用されてもよい。かかるインフラストラクチャおよびコンピューティングシステムを通して、本明細書で考察する実施例、特徴、および解決策は、全体的に、かかる車両内コンピューティングシステム、フォグベースもしくはエッジコンピューティングデバイス、またはクラウドベースのコンピューティングシステムの１つもしくは複数によって、あるいはシステム間の通信および協働による上述の組み合わせによって、実施されてもよいことが認識されるべきである。

【0047】

概して、本明細書で考察される、「サーバ」、「クライアント」、「コンピューティングデバイス」、「ネットワーク要素」、「ホスト」、「プラットフォーム」、「センサデバイス」、「エッジデバイス」、「自律運転システム」、「自律車両」、「フォグベースのシステム」、「クラウドベースのシステム」、および「システム」などは、一般に、自律運転環境と関連付けられたデータおよび情報を、受信、送信、処理、格納、または管理するように動作可能である、電子コンピューティングデバイスを含むことができる。本明細書で使用するとき、「コンピュータ」、「プロセッサ」、「プロセッサデバイス」、または「処理デバイス」という用語は、他の例の中でも特に、中央処理装置（ＣＰＵ）、グラフィック処理装置（ＧＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、テンソルプロセッサ、および他の行列演算プロセッサを含む、任意の好適な処理装置を包含するものとする。例えば、環境内の単一のデバイスとして示される要素が、複数のサーバコンピュータを含むサーバプールなど、複数のコンピューティングデバイスおよびプロセッサを使用して実現されてもよい。更に、コンピューティングデバイスのいずれか、全て、またはいくつかが、Ｌｉｎｕｘ（登録商標）、ＵＮＩＸ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ（登録商標）ＯＳ、Ａｐｐｌｅ（登録商標）ｉＯＳ（登録商標）、Ｇｏｏｇｌｅ（登録商標）Ａｎｄｒｏｉｄ（登録商標）、Ｗｉｎｄｏｗｓ Ｓｅｒｖｅｒ（登録商標）などの任意のオペレーティングシステム、ならびに、カスタマイズされたおよびプロプライエタリオペレーティングシステムを含む、特定のオペレーティングシステムの実行を仮想化するように適合された仮想マシンを、実行するように適合されてもよい。

【0048】

後述するまたは図面に例証する様々な構成要素のうち任意のもののフロー、方法、プロセス（もしくはその一部分）、または機能性のいずれかが、１つもしくは複数のモジュール、エンジン、ブロック、ユニット、モデル、システム、または他の好適なコンピューティング論理など、任意の好適なコンピューティング論理によって実施されてもよい。本明細書における、「モジュール」、「エンジン」、「ブロック」、「ユニット」、「モデル」、「システム」、または「論理」に対する言及は、１つもしくは複数の機能を実施する、ハードウェア、ファームウェア、ソフトウェア、および／またはそれぞれの組み合わせを指してもよい。一例として、モジュール、エンジン、ブロック、ユニット、モデル、システム、または論理は、マイクロコントローラまたはプロセッサによって実行されるように適合されたコードを格納する、非一時的媒体と関連付けられた、マイクロコントローラまたはプロセッサなどの１つもしくは複数のハードウェア構成要素を含んでもよい。したがって、モジュール、エンジン、ブロック、ユニット、モデル、システム、または論理に対する言及は、一実施形態では、非一時的媒体で保持されるコードを認識および／または実行するように具体的に構成された、ハードウェアを指してもよい。更に、別の実施形態では、モジュール、エンジン、ブロック、ユニット、モデル、システム、または論理の使用は、所定の動作を実施するようにマイクロコントローラまたはプロセッサによって実行されるように具体的に適合された、コードを含む非一時的媒体を指す。また、推論することができるように、更に別の実施形態では、モジュール、エンジン、ブロック、ユニット、モデル、システム、または論理は、ハードウェアおよび非一時的媒体の組み合わせを指してもよい。様々な実施形態では、モジュール、エンジン、ブロック、ユニット、モデル、システム、または論理は、ソフトウェア命令を実行するように動作可能なマイクロプロセッサもしくは他の処理要素、特定用途向け集積回路（ＡＳＩＣ）などの個別論理、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのプログラムされた論理デバイス、命令を包含するメモリデバイス、（例えば、プリント回路基板で見られるような）論理デバイスの組み合わせ、あるいは他の好適なハードウェアおよび／またはソフトウェアを含んでもよい。モジュール、エンジン、ブロック、ユニット、モデル、システム、または論理は、例えば、トランジスタによって実現されてもよい、１つもしくは複数のゲートまたは他の回路構成要素を含んでもよい。いくつかの実施形態では、モジュール、エンジン、ブロック、ユニット、モデル、システム、または論理は、完全にソフトウェアとして具体化されてもよい。ソフトウェアは、非一時的コンピュータ可読記憶媒体に記録されたソフトウェアパッケージ、コード、命令、命令セット、および／またはデータとして具体化されてもよい。ファームウェアは、メモリデバイスにハードコーディングされた（例えば、不揮発性の）コード、命令もしくは命令セット、および／またはデータとして具体化されてもよい。更に、別個であるものとして例証される論理境界は、一般に、変動し場合によっては重複する。例えば、第１および第２のモジュール（または複数のエンジン、ブロック、ユニット、モデル、システム、もしくは論理）は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせを共有してもよいが、場合によってはいくつかの独立したハードウェア、ソフトウェア、またはファームウェアを保持してもよい。

【0049】

後述するとともに添付図面に示すフロー、方法、およびプロセスは、特定の実施形態で実施されてもよい機能の単なる代表例である。他の実施形態では、フロー、方法、およびプロセスにおいて追加の機能が実施されてもよい。本開示の様々な実施形態は、本明細書に記載の機能を遂行する任意の好適な信号発生メカニズムを想到する。本明細書に例証する機能の一部は、適切な場合、フロー、方法、およびプロセスの中で、繰り返されるか、組み合わされるか、修正されるか、または消去されてもよい。それに加えて、機能は、特定の実施形態の範囲から逸脱することなく、フロー、方法、およびプロセスの中で、任意の好適な順序で実施されてもよい。

【0050】

次に図２を参照すると、自律運転の機能性を装備した車両（および対応する車両内コンピューティングシステム）１０５の一例の実現例を示す、概略ブロック図２００が示されている。一例では、車両１０５は、他の例の中でも特に、中央処理装置（ＣＰＵ）、グラフィック処理装置（ＧＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、テンソルプロセッサ、および他の行列演算プロセッサなど、１つまたは複数のプロセッサ２０２を装備してもよい。かかるプロセッサ２０２は、他の例の中でも特に、機械学習推論または訓練（後述する機械学習推論もしくは訓練のいずれかを含む）に関連する機能、特定のセンサデータ（例えば、カメラ画像データ、ＬＩＤＡＲ点群など）の処理、自律運転に関係する特定の演算機能（例えば、行列演算、畳み込み演算など）の実施など、特定の処理およびメモリアクセス機能を加速させるハードウェアを備えてもよい、ハードウェアアクセラレータデバイス（例えば、２０４）に結合されるかあるいはそれを統合していてもよい。１つまたは複数のメモリ素子（例えば、２０６）は、車両において実現される自律運転スタックのモジュールまたはサブモジュールのうちいずれか１つの全てもしくは一部分を実現する、機械実行可能命令を格納するため、ならびに、車両によって実施される（もしくは本明細書で考察する実施例および解決策と関連して使用される）自律運転の機能性と関連して受信され、生成され、または使用される、機械学習モデル（例えば、２５６）、センサデータ（例えば、２５８）、および他のデータを格納するために提供されてもよい。様々な通信モジュール（例えば、２１２）も提供されてもよく、１つもしくは複数のネットワーク通信技術を用いて１つまたは複数のネットワークチャネルを通じて他の車外コンピューティングシステムと通信する、車両のシステムによって使用される通信能力を実現するのに、ハードウェア回路類および／またはソフトウェアにおいて実現される。これらの様々なプロセッサ２０２、アクセラレータ２０４、メモリデバイス２０６、およびネットワーク通信モジュール２１２は、中でも特に、周辺構成要素相互接続エクスプレス（ＰＣＩｅ）、Ｅｔｈｅｒｎｅｔ（登録商標）、ＯｐｅｎＣＡＰＩ（商標）、Ｇｅｎ－Ｚ（商標）、ＵＰＩ、ユニバーサルシリアルバス（ＵＳＢ）、Ｃａｃｈｅ Ｃｏｈｅｒｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ ｆｏｒ Ａｃｃｅｌｅｒａｔｏｒｓ（ＣＣＩＸ（商標））、Ａｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ（商標）（ＡＭＤ（商標））のＩｎｆｉｎｉｔｙ（商標）、共通通信インターフェース（ＣＣＩ）、またはＱｕａｌｃｏｍｍ（商標）のＣｅｎｔｒｉｑ（商標）相互接続などの技術を利用するファブリックなど、１つもしくは複数の相互接続ファブリックまたはリンク（例えば、２０８）を通して、車両システム上で相互接続されてもよい。

【0051】

引き続き図２の例を参照すると、一例の車両（および対応する車両内コンピューティングシステム）１０５は、ハードウェアおよび／またはソフトウェアで自律車両の機能性を実現した他の例示のモジュールの中でも特に、車両内処理システム２１０、運転制御（例えば、２２０）、センサ（例えば、２２５）、およびユーザ／乗員インターフェース（例えば、２３０）を含んでもよい。例えば、車両内処理システム２１０は、いくつかの実現例では、（例えば、図５の実施例で示され考察されるような）自律運転スタックおよびプロセスフローの全てまたは一部分を実現してもよい。自律運転スタックは、ハードウェア、ファームウェア、またはソフトウェアで実現されてもよい。機械学習エンジン２３２は、本明細書の実施例で考察されるものなど、車両でもしくは車両に対して提供され実現される１つまたは複数の自律機能および機構と関連して、車両１０５に提供される様々な機械学習モデル（例えば、２５６）を利用するのに提供されてもよい。かかる機械学習モデル２５６は、人工ニューラルネットワークモデル、畳み込みニューラルネットワーク、判定木ベースのモデル、サポートベクターマシン（ＳＶＭ）、ベイズモデル、深層学習モデル、および他の例示のモデルを含んでもよい。いくつかの実現例では、一例の機械学習エンジン２３２は、機械学習モデル２５６の１つもしくは複数の訓練（例えば、初期訓練、継続訓練など）に参加する、１つまたは複数のモデルトレーナーエンジン２５２を含んでもよい。訓練済み機械学習モデル２５６を利用して、様々な推論、予測、分類、および他の結果を導き出す、１つまたは複数の推論エンジン２５４も提供されてもよい。いくつかの実施形態では、本明細書に記載する機械学習モデルの訓練または推論は、コンピューティングシステム１４０または１５０によってなど、車両外で実施されてもよい。

【0052】

車両に提供される機械学習エンジン２３２は、自律運転スタックおよび他の自律運転関連機構を実現する、車両内処理システム２１０の他の論理構成要素およびモジュールを支援し、それらによって使用される結果を提供するのに利用されてもよい。例えば、データ収集モジュール２３４は、（例えば、車両によって使用される様々な機械学習モデル２５６の訓練または使用における入力のために）どのソースからデータを収集するべきかを決定する論理を備えてもよい。例えば、特定のソース（例えば、内部センサ（例えば、２２５）または車外ソース（例えば、１１５、１４０、１５０、１８０、２１５など））が選択されてもよく、ならびにデータがサンプリングされてもよい頻度および忠実度が選択される。いくつかの事例では、かかる選択および構成は、（例えば、特定の検出されたシナリオを所与として、適切にデータを収集するため）１つまたは複数の対応する機械学習モデルを使用して、データ収集モジュール２３４によって少なくとも部分的に自律的に行われてもよい。

【0053】

センサフュージョンモジュール２３６も、機械学習エンジン２３２、および車両内処理システムの他のモジュール（例えば、２３８、２４０、２４２、２４４、２４６など）によって利用される、様々なセンサ入力の使用および処理を統制するのに使用されてもよい。複数のセンサデータソース（例えば、車両上もしくは車両外）から出力を導き出してもよい、１つまたは複数のセンサフュージョンモジュール（例えば、２３６）が提供されてもよい。ソースは、同質または異質のタイプのソース（例えば、共通のセンサタイプの複数のインスタンスからの、もしくは複数の異なるセンサタイプのインスタンスからの複数の入力）であってもよい。一例のセンサフュージョンモジュール２３６は、他の例示のセンサフュージョン技術の中でも特に、直接フュージョン、間接的フュージョンを適用してもよい。センサフュージョンの出力は、いくつかの事例では、自律運転の機能性、または本明細書で考察される例示の解決策に記載されるものなど、他の機能性を提供することと関連して、入力として（場合によっては追加入力とともに）、車両内処理システムの別のモジュールおよび／または１つもしくは複数の機械学習モデルに供給されてもよい。

【0054】

知覚エンジン２３８がいくつかの実施例で提供されてもよく、いくつかの例では、車外ソースおよび／またはセンサフュージョンモジュール２３６からのデータを含む、様々なセンサデータ（例えば、２５８）を入力として取って、車両１０５が遭遇する（もしくは遭遇することになる）環境の自律的知覚に対応する他の例示の機能の中でも特に、検出された物体の物体認識および／または追跡を実施してもよい。知覚エンジン２３８は、１つまたは複数の畳み込みニューラルネットワークおよび他の機械学習モデル２５６によるものなど、深層学習を使用して、センサデータ入力から物体認識を実施してもよい。物体追跡はまた、センサデータ入力から、物体が移動しているか否か、また移動している場合はどの軌道に沿っているかを自律的に推定するのに実施されてもよい。例えば、所与の物体が認識された後、知覚エンジン２３８は、所与の物体が車両に対してどのように移動するかを検出してもよい。かかる機能性は、例えば、他の例示の使用の中でも特に、車道上の車両の経路に影響を及ぼすことがある、環境内で移動している他の車両、歩行者、野生動物、自転車運転者などの物体を検出するのに使用されてもよい。

【0055】

位置確認エンジン２４０も、いくつかの実現例では、車両内処理システム２１０に含まれてもよい。いくつかの事例では、位置確認エンジン２４０は、知覚エンジン２３８の下位構成要素として実現されてもよい。位置確認エンジン２４０はまた、１つまたは複数の機械学習モデル２５６および（例えば、ＬＩＤＡＲおよびＧＰＳデータなどの）センサフュージョンを利用して、車両の高信頼度の場所と所与の物理的空間（即ち「環境」）内で車両が占める空間とを決定してもよい。

【0056】

車両１０５は更に、環境内で車両１０５の運転を制御する運転制御（例えば、２２０）によって使用されてもよい、車両の経路計画および／または行動計画を決定するのに、他のもの（例えば、推奨エンジン２４４）の中でも特に、データ収集２３４、センサフュージョン２３６、知覚エンジン２３８、および位置確認エンジン（例えば、２４０）など、他の様々なモジュールの結果を利用してもよい、経路プランナ２４２を含んでもよい。例えば、経路プランナ２４２は、これらの入力および１つまたは複数の機械学習モデルを利用して、運転環境内の様々なイベントの確率を決定して、環境内で作用する有効なリアルタイム計画を決定してもよい。

【0057】

いくつかの実現例では、車両１０５は、車両１０５自体のセンサ（例えば、２２５）によって生成されるセンサデータ、ならびに（例えば、センサデバイス１１５、１８０、２１５などの）車外センサからのセンサデータから様々な推奨を生成する、１つまたは複数の推奨エンジン２４４を含んでもよい。いくつかの推奨は、推奨エンジン２４４によって決定されてもよく、それが車両の自律運転スタックの構成要素に入力として提供されて、それらの構成要素によって行われる決定に影響を及ぼしてもよい。例えば、経路プランナ２４２によって考慮されると、通常は別の形で決定するであろう、ただし推奨のために判定または計画から経路プランナ２４２を逸脱させる、推奨が決定されてもよい。推奨はまた、乗員の快適さおよび体験の考慮に基づいて、推奨エンジン（例えば、２４４）によって生成されてもよい。いくつかの事例では、車両内の内部機構は、車両のセンサおよび／または車外センサなどによって獲得されるセンサデータ（例えば、２５８）から決定されるこれらの推奨に基づいて、予測的および自律的に操作されてもよい。

【0058】

上述したように、いくつかの車両の実現例は、運転操縦を変更するとともに車両の車室環境に対する変更を実行して、センサデータ（例えば、２５８）によって獲得される観察に基づいて車両内の乗員の体験を強化するために、車両の制御ユニットを制御するのに、センサデータおよび車両の自律運転スタック内の他のモジュールの出力を利用してもよい、ユーザ／乗員体験エンジン（例えば、２４６）を含んでもよい。いくつかの例では、ユーザが車両およびその自律運転システムと対話できるようにする、車両に提供されるユーザインターフェース（例えば、２３０）の態様が強化されてもよい。いくつかの事例では、情報表現が、他の例示の使用の中でも特に、車両（例えば、１０５）内の乗員の体験に影響を及ぼし改善する助けとするのに、ユーザディスプレイ（例えば、音声、視覚、および／または触覚表現）によって生成され提供されてもよい。

【0059】

いくつかの事例では、車両の様々なセンサによって収集される情報を監視して、車両の自律運転システムの性能に関する問題点を検出する、システムマネージャ２５０も提供されてもよい。例えば、演算処理エラー、センサの故障および問題点、通信チャネルの利用可能性および品質（例えば、通信モジュール２１２を通して提供される）、車両システムチェック（例えば、モータ、トランスミッション、バッテリ、冷却系統、電気系統、タイヤなどに関する問題点）、または他の操作イベントが、システムマネージャ２５０によって検出されてもよい。かかる問題点は、いくつかの事例では、車両システムの健全性および問題点も、車両１０５の自律運転の機能性におけるセンサデータ２５８で収集される他の情報とともに考慮できるように、機械学習モデル２５６および関連する自律運転モジュール（例えば、２３２、２３４、２３６、２３８、２４０、２４２、２４４、２４６など）に対する入力として利用されてもよい、システムマネージャ２５０によって生成されるシステム報告データにおいて特定されてもよい。

【0060】

いくつかの実現例では、車両１０５の自律運転スタックは、他の例の中でも特に、ステアリング制御（例えば、２６０）、アクセル／スロットル制御（例えば、２６２）、ブレーキ制御（例えば、２６４）、信号発生制御（例えば、２６６）を含む、車両がどのように運転されるかに影響を及ぼす運転制御２２０と結合されてもよい。いくつかの事例では、車両はまた、ユーザ入力に全体的または部分的に基づいて制御されてもよい。例えば、ユーザインターフェース（例えば、２３０）は、（例えば、ハンドオーバまたはそれに続く運転者支援行動において）人間の運転者が制御を自律運転システムから引き継ぐのを許可する、運転制御（例えば、物理的もしくは仮想ハンドル、アクセル、ブレーキ、クラッチなど）を含んでもよい。他のセンサは、発話検出２９２、身振り検出カメラ２９４、および他の例など、ユーザ／乗員入力を受け取るのに利用されてもよい。ユーザインターフェース（例えば、２３０）は乗員ユーザの希望および意図を獲得してもよく、車両１０５の自律運転スタックは、これらを車両の運転の制御（例えば、運転制御２２０）における追加入力とみなしてもよい。いくつかの実現例では、運転制御は、他の例示の実現例の中でも特に、乗員が外部デバイス（例えば、スマートフォンもしくはタブレット）を利用して運転指示または制御を提供する場合、あるいは（例えば、緊急イベントに基づいて）外部運転者またはシステムが車両の制御をテイクオーバする、遠隔バレットサービスの場合など、外部コンピューティングシステムによって統制されてもよい。

【0061】

上述したように、車両の自律運転スタックは、車両またはその外部に提供される様々なセンサによって生成される、様々なセンサデータ（例えば、２５８）を利用してもよい。一例として、車両１０５は、車両の外部および周囲環境に関連する様々な情報、車両システム状態、車両内の条件、および車両の処理システム２１０のモジュールによって使用可能な他の情報を収集する、センサ２２５のアレイを所持してもよい。例えば、かかるセンサ２２５としては、他の例示のセンサの中でも特に、全地球測位（ＧＰＳ）センサ２６８、光検出および測距（ＬＩＤＡＲ）センサ２７０、二次元（２Ｄ）カメラ２７２、三次元（３Ｄ）またはステレオカメラ２７４、音響センサ２７６、慣性測定ユニット（ＩＭＵ）センサ２７８、熱センサ２８０、超音波センサ２８２、バイオセンサ２８４（例えば、顔認識、声認識、心拍センサ、体温センサ、感情検出センサなど）、レーダセンサ２８６、天候センサ（図示なし）を挙げることができる。かかるセンサは、他の例の中でも特に、車両が動作する環境（例えば、天候、障害物、交通量、路面条件など）、車両内の乗員（例えば、乗員もしくは運転者の意識または覚醒、乗員の快適さまたは気分、乗員の健康または生理学的条件など）、車両の他の内容（例えば、小包、家畜、貨物、荷物など）、車両のサブシステムの、様々な属性および条件を決定するのに組み合わせて利用されてもよい。センサデータ２５８はまた（あるいは代わりに）、他の車両のセンサ（例えば、１１５）（車車間通信もしくは他の技術によって車両１０５に通信されてもよい）、地上または空中ドローン１８０のセンサ、車両１０５の内部または外部の人間のユーザが携帯するユーザデバイス２１５（例えば、スマートフォンもしくはウェアラブル）のセンサ、ならびに路側ユニット（例えば、１４０）、道路標識、信号機、街灯などの他の路側要素に装備または提供されたセンサを含む、車両に一体的に結合されていないセンサによって生成されてもよい。かかる車外センサデバイスからのセンサデータは、他の例示の実現例の中でも特に、センサデバイスから車両に直接提供されてもよく、あるいはデータ集約デバイスを通して、または他のコンピューティングシステム（例えば、１４０、１５０）によってこれらのセンサに基づいて生成された結果として、提供されてもよい。

【0062】

いくつかの実現例では、自律車両システム１０５は、他のコンピューティングシステムとインターフェース接続し、それらによって提供される情報およびサービスを活用して、デバイス１０５の自律運転の機能性を強化するか、使用可能にするか、または別の形で支援してもよい。いくつかの例では、一部の自律運転機構（本明細書で考察する例示の解決策のいくつかを含む）は、サービス、コンピューティング論理、機械学習モデル、データ、または車両外部のコンピューティングシステムの他のリソースを通して使用可能にされることがある。かかる外部システムが車両に利用可能でないとき、これらの機構は少なくとも一時的に使用不能であってもよい。例えば、路側ユニットまたはフォグベースのエッジデバイス（例えば、１４０）、他の（例えば、上位）車両（例えば、１１５）、およびクラウドベースのシステム１５０（例えば、様々なネットワークアクセスポイント（例えば、１４５）を通してアクセス可能）でホストされる、外部コンピューティングシステムが提供され活用されてもよい。路側ユニット１４０もしくはクラウドベースのシステム１５０、または車両（例えば、１０５）が対話する他の協働システムは、場合によっては追加の機能性および論理とともに、一例の車両内処理システム（例えば、２１０）に属するものとして例証される論理の全てまたは一部分を含んでもよい。例えば、クラウドベースのコンピューティングシステム、路側ユニット１４０、または他のコンピューティングシステムは、モデル訓練および推論エンジン論理のどちらかまたは両方に対応する機械学習エンジンを含んでもよい。例えば、かかる外部システムは、よりハイエンドのコンピューティングリソースおよびより発展したまたは最新の機械学習モデルを所持して、これらのサービスが、車両の処理システム２１０において本来生成されるであろうものよりも優れた結果を提供することを可能にしてもよい。例えば、車両内処理システム２１０は、特定のタスクに対してクラウドベースのサービスを通して提供され、特定のシナリオを取り扱う、機械学習訓練、機械学習推論、および／または機械学習モデルに依存してもよい。実際に、車両１０５に属するものとして考察され例証されるモジュールの１つまたは複数は、いくつかの実現例では、クラウドベース、フォグベース、または自律運転環境に対応する他のコンピューティングシステム内で、選択的もしくは冗長に提供されてもよいことが認識されるべきである。

【0063】

本明細書の様々な実施形態は、１つまたは複数の機械学習モデルを利用して、自律車両スタックの機能（または本明細書に記載する他の機能）を実施してもよい。機械学習モデルは、特定のタスクの性能を漸増的に改善するように、コンピューティングシステムによって実行されてもよい。いくつかの実施形態では、機械学習モデルのパラメータは、訓練データに基づいて訓練フェーズ中に調節されてもよい。訓練済み機械学習モデルは次に、入力データに基づいて予測または判定を行うのに、推論フェーズ中に使用されてもよい。

【0064】

本明細書に記載する機械学習モデルは、任意の好適な形態を取るか、または任意の好適な技術を利用してもよい。例えば、機械学習モデルのいずれかは、教師あり学習、半教師あり学習、教師なし学習、または強化学習技術を利用してもよい。

【0065】

教師あり学習では、モデルは、入力および対応する所望の出力の両方を包含するデータの訓練セットを使用して構築されてもよい。各訓練インスタンスは、１つまたは複数の入力および所望の出力を含んでもよい。訓練は、訓練インスタンス全体を通して、新しい入力に対する出力を予測するようにモデルに教示する目的関数を使用して、反復することを含んでもよい。半教師あり学習では、訓練セットにおける入力の一部分が所望の出力を有さなくてもよい。

【0066】

教師なし学習では、モデルは、入力のみを包含して所望の出力は有さない、データセットから構築されてもよい。教師なしモデルは、データにおけるパターンを発見することによって、データの構造（例えば、データポイントのグループ化またはクラスタ化）を見出すのに使用されてもよい。教師なし学習モデルで実現されてもよい技術としては、例えば、自己組織化マップ、最近傍マッピング、ｋ平均法、および特異値分解が挙げられる。

【0067】

強化学習モデルは、精度を改善するために正または負のフィードバックが与えられてもよい。強化学習モデルは、１つまたは複数の目的／報酬を最大限にすることを試行してもよい。強化学習モデルで実現されてもよい技術としては、例えば、Ｑ学習、時間差（ＴＤ）、および深層敵対ネットワークを挙げることができる。

【0068】

本明細書に記載する様々な実施形態は、１つまたは複数の分類モデルを利用してもよい。分類モデルでは、出力は値の限定されたセットに制約されてもよい。分類モデルは、１つまたは複数の入力値の入力セットに対してクラスを出力してもよい。本明細書での分類モデルに対する言及は、例えば、線形分類器（例えば、ロジスティック回帰もしく単純ベイズ分類器）、サポートベクターマシン、判定木、ブースティング木、ランダムフォレスト、ニューラルネットワーク、または最近傍といった技術のいずれか１つもしくは複数を実現する、モデルを想到してもよい。

【0069】

本明細書に記載する様々な実施形態は、１つまたは複数の回帰モデルを利用してもよい。回帰モデルは、１つまたは複数の値の入力セットに基づいて、連続範囲から数値を出力してもよい。本明細書での回帰モデルに対する言及は、例えば、線形回帰、判定木、ランダムフォレスト、またはニューラルネットワークといった技術（あるいは他の好適な技術）のいずれか１つもしくは複数を実現する、モデルを想到してもよい。

【0070】

様々な実施形態では、本明細書で考察する機械学習モデルのいずれかは、１つまたは複数のニューラルネットワークを利用してもよい。ニューラルネットワークは、シナプスによって接続されたニューロンの大きいクラスタを含む生体脳の構造に似せて大まかにモデル化した神経単位群を含んでもよい。ニューラルネットワークでは、神経単位は、接続された神経単位の活性化状態に対する影響に関して興奮性または抑制性であってもよいリンクを介して、他の神経単位に接続される。神経単位は、その入力の値を利用して関数を実施して、神経単位の膜電位を更新してもよい。神経単位は、神経単位と関連付けられた閾値を超えると、接続された神経単位にスパイク信号を伝播してもよい。ニューラルネットワークは、コンピュータビジョンタスク、発話認識タスク、または他の好適なコンピューティングタスクなど、様々なデータ処理タスク（自律車両スタックによって実施されるタスクを含む）を実施するように、訓練されるかまたは別の方法で適応されてもよい。

【0071】

図３は、特定の実施形態による、ニューラルネットワーク３００の一例の一部分を示している。ニューラルネットワーク３００は神経単位Ｘ１～Ｘ９を含む。神経単位Ｘ１～Ｘ４は、主入力Ｉ１～Ｉ４（ニューラルネットワーク３００が出力を処理する間、一定に保たれてもよい）をそれぞれ受信する入力神経単位である。任意の好適な主入力が使用されてもよい。一例として、ニューラルネットワーク３００が画像処理を実施するとき、主入力値は、画像からのピクセルの値であってもよい（また、画像が処理されている間、主入力の値は一定のままであってもよい）。別の例として、ニューラルネットワーク３００が発話処理を実施するとき、特定の入力神経単位に適用される主入力値は、入力される発話に対する変化に基づいて、時間に伴って変化してもよい。

【0072】

特定のトポロジーおよび接続性スキームが図３に示されているが、本開示の教示は、任意の好適なトポロジーおよび／または接続性を有するニューラルネットワークで使用されてもよい。例えば、ニューラルネットワークは、順伝播型ニューラルネットワーク、回帰型ネットワーク、または神経単位間の任意の好適な接続性を有する他のニューラルネットワークであってもよい。別の例として、ニューラルネットワークは、入力層、隠れ層、および出力層を有するものとして図示されているが、ニューラルネットワークは、任意の好適な形式で配置された任意の好適な層を有してもよい。図示される実施形態では、２つの神経単位間の各リンクは、２つの神経単位間の関係の強度を示すシナプス荷重を有する。シナプス荷重は、ＷＸＹとして示され、Ｘはシナプス前神経単位を示し、Ｙはシナプス後神経単位を示す。神経単位間のリンクは、接続された神経単位の活性化状態に対する影響に関して興奮性または抑制性であってもよい。例えば、Ｘ１からＸ５まで伝播するスパイクは、Ｗ１５の値に応じて、Ｘ５の膜電位を増加または減少させてもよい。様々な実施形態では、接続は有向性または無向性であってもよい。

【0073】

様々な実施形態では、ニューラルネットワークの各時間ステップの間、神経単位は、それぞれのシナプスを介して神経単位に接続された神経単位のうち１つまたは複数からのバイアス値あるいは１つもしくは複数の入力スパイクなど、任意の好適な入力を受信してもよい（この神経単位セットは、神経単位のファンイン神経単位と呼ばれる）。神経単位に適用されるバイアス値は、入力神経単位に適用される主入力の関数、および／または神経単位に適用される他の何らかの値（例えば、ニューラルネットワークの訓練または他の動作中に調節されてもよい一定値）であってもよい。様々な実施形態では、各神経単位は、それ自体のバイアス値または複数の神経単位に適用され得るバイアス値と関連付けられてもよい。

【0074】

神経単位は、その入力の値およびその現在の膜電位を利用して関数を実施してもよい。例えば、入力が神経単位の現在の膜電位に追加されて、更新された膜電位を生成してもよい。別の例として、シグモイド伝達関数などの非線形関数が、入力および現在の膜電位に適用されてもよい。他の任意の好適な関数が使用されてもよい。神経単位はそれにより、関数の出力に基づいてその膜電位を更新する。

【0075】

図４に移ると、様々な車両が（例えば、それらの対応する車両内コンピューティングシステムによって）対応していてもよい、自律運転の例示のレベルを示す概略ブロック図４００が示されている。例えば、レベルの範囲（例えば、Ｌ０～Ｌ５（４０５～４３５））が規定されてもよく、レベル５（Ｌ５）は最高レベルの自律運転の機能性を有する車両に対応し（例えば、完全自動化）、レベル０（Ｌ０）は最低レベルの自律運転の機能性に対応する（例えば、非自動化）。例えば、Ｌ５車両（例えば、４３５）は、過酷な路面条件および天候における場合を含めて、全ての運転シナリオで、人間の運転者によって提供されるであろう能力以上の自律運転性能を提供することができる、完全自律コンピューティングシステムを所持してもよい。Ｌ４車両（例えば、４３０）も、完全自律とみなされてもよく、出発場所から目的地までの全行程を通して、安全性重視の運転機能を自律的に実施し、車道条件を効率的に監視することができてもよい。Ｌ４車両は、Ｌ４の自律能力が、全ての運転シナリオを含まない場合がある車両の「運転設計領域」の限界内で規定されるという点で、Ｌ５車両とは異なってもよい。Ｌ３車両（例えば、４２０）は、特定の交通および環境条件セットにおいて、安全性重視の機能を車両に完全にシフトする自律運転の機能性を提供するが、他の全てのシナリオにおいて運転を扱う人間の運転者の関与および利用可能性を依然として予期している。したがって、Ｌ３車両は、人間の運転者から自律運転スタックへの、またその逆の制御の移行を組織化する、ハンドオーバプロトコルを提供してもよい。Ｌ２車両（例えば、４１５）は、運転者が車両の物理的操作から時々離れるのを可能にして、運転者の手および足の両方が車両の物理的制御から周期的に離れてもよい、運転者支援の機能性を提供する。Ｌ１車両（例えば、４１０）は、１つまたは複数の特定の機能（例えば、ステアリング、ブレーキなど）の運転者支援を提供するが、車両のほとんどの機能を常に運転者が制御することを依然として要する。Ｌ０車両は、非自律とみなされてもよく、人間の運転者が車両の運転機能性の全てを制御する（ただし、かかる車両は、それでもなお、センサデータを上位車両に提供すること、センサデータを使用して車両内のＧＰＳおよび娯楽情報サービスを強化することなどによって、自律運転環境内で受動的に参加してもよい）。いくつかの実現例では、単一の車両が複数の自律運転レベルでの動作に対応してもよい。例えば、運転者は、所与の走行中にどのレベルの自律支援（例えば、Ｌ４以下のレベル）が使用されるかを制御し選択してもよい。他の事例では、車両は、例えば、車道または車両の自律運転システムに影響を及ぼす条件に基づいて、レベル間で自律的に切り替えてもよい。例えば、他の例の中でも特に、１つまたは複数のセンサが故障していることの検出に応答して、Ｌ５またはＬ４車両はより下位のモード（例えば、Ｌ２以下）にシフトして、センサの問題点に関して人間の乗員を関わらせてもよい。

【0076】

図５は、一部の自律運転システムにおいて実現されてもよい、一例の自律運転フローを示す概略ブロック図５００である。例えば、自律（または半自律）車両で実現される自律運転フローは、感知および知覚段階５０５と、計画および判定段階５１０と、制御および行動フェーズ５１５とを含んでもよい。感知および知覚段階５０５の間、様々なセンサによってデータが生成され、自律運転システムによって使用するために収集される。データ収集は、いくつかの例では、外部ソースからのデータフィルタ処理および受信センサを含んでもよい。この段階はまた、センサフュージョン動作およびオブジェクト認識、ならびに１つまたは複数の機械学習モデルを使用して実施される、位置確認などの他の知覚タスクを含んでもよい。計画および判定段階５１０は、センサデータおよび様々な知覚動作の結果を利用して、前方の車道の確率予測を行い、これらの予測に基づいてリアルタイムの経路計画を決定してもよい。計画および判定段階５１０は更に、障害物および他のイベントの検出に反応して、経路計画に関する判定を行って、これらのイベントを考慮して決定された経路を走行するか否か、また安全に走行するためにどの行動を取るべきかを判定することを含んでもよい。計画および判定段階５１０の経路計画および判定に基づいて、制御および行動段階５１５は、これらの決定を行動に変換して、アクチュエータを通して、ステアリング、加速、およびブレーキを含む運転制御、ならびにウィンカー、センサクリーナー、ワイパー、ヘッドライトなどの補助制御を操作してもよい。

【0077】

車両が自律的に機能するのに必要な機能性は全て、車両内コンピューティングシステムを通して本来提供されてもよい（また、必要な場合、有線もしくは無線の家庭用または車庫用ネットワーク接続を通じて周期的通信によって更新される）が、無線通信技術および速度が進歩するにしたがって、一部の自律車両の実現例は、車外のデータおよび計算リソース（例えば、車両の外部の、もしくは車両に本来統合されていない）からの通信により一層依存することがある。例えば、５Ｇキャリアネットワークの到来および４Ｇ ＬＴＥカバレッジの拡大によって、接続された自律車両および車車間・路車間（Ｖ２Ｘ）システムの実現例は、より即時的に達成可能になる。例えば、安全性を重視することを所与として、車両の自律運転システムを通して本来提供される安全性は、強化されたクラウドソースインテリジェンスを提供し、ならびにリアルタイム高信頼性アプリケーションなどを通して冗長性を提供することの両方のため、自動車外部のシステムを使用して補足され、増補され、強化されてもよい。

【0078】

自律車両は、外部コンピューティングシステムと通信し、またそれによって指示されてもよい。かかる制御は、無線（ＯＴＡ）更新を転送するなどの低レベルの制御を含んでもよく、車両は、（例えば、車両もしくは自律運転システムの相手先商標製品製造会社（ＯＥＭ）またはプロバイダに属する）遠隔制御／保守管理センタから、ソフトウェアおよび／またはファームウェアの更新を受信することができる（例えば、技術者が手作業で行うために車両を保守センタに持っていくのとは対照的）。他のより上位の制御アプリケーションでは、自律車両の完全な制御が、外部コンピューティングシステムまたは遠隔コンピューティング端末の遠隔ユーザ／仮想運転者にハンドオーバされてもよい。例えば、かかる遠隔制御は、例えば、自律車両から車両内の乗員への制御のハンドオーバが実現不能であるかまたは望ましくないとき、自律運転システムがルートの特定部分を正確に、効率的に、または安全に走行するのに苦労している車両を支援するため、あるいは退避イベントまたは別の状態で不動化している自律車両を支援するため、オンデマンド「遠隔バレット」サービスとして提示されてもよい。

【0079】

いくつかの実現例では、自律車両が、どのように信頼性高く安全に扱うべきか自律車両が分からない状況またはイベントに遭遇したとき、車両は、自律運転システムが車道を外れるように（例えば、路肩、駐車スペースなどに）車両に指示する退避イベントを開始するようにプログラムされてもよい。将来的に、自律車両が車道でより多数見られるようになると、一台の自律車両に退避を開始させるイベントが、他の近隣の自律車両に同様に影響を及ぼして、複数の退避によって更なる渋滞および車道の立往生が起こる可能性につながり、場合によっては車道およびそれらの車道上の自律運転が麻痺することがある。いくつかの例は、退避を引き起こす状況を走行するため、自律運転システムから人間の乗員へのハンドオーバイベントを承認してもよいが、他の実現例では、他の例示の状況および実現例の中でも特に、（例えば、車両に乗員がいないとき（例えば、ドローン車両、乗員に対して遠隔招集機構を使用している最中の車両など））遠隔バレットサービスがトリガされてもよい。

【0080】

上記にしたがって、自律車両のいくつかの実現例は、車両の運転を（車両の自律運転システムから）ハンドオフさせ、ネットワークを通じて遠隔コンピューティングシステムによって制御することを可能にする、遠隔バレットモードに対応してもよい。例えば、自律車両の遠隔制御は、自律車両が取り扱うことができない状況（例えば、センサが機能していない、車両が知らない新しい路面状況、車載システムが判定を行うことができないなど）に直面したとき、自律車両によってオンデマンドでトリガされてもよい。かかる遠隔制御はまた、車両が遠隔制御を要求する緊急状況にある車両に提供されてもよい。遠隔バレットサービスは、車両を遠隔で制御するように操作されるユーザエンドポイントシステムを備えた、制御および保守管理センタに遠隔で位置している人間が関わってもよい。かかるシステムは、車両自体またはその環境の使用可能な情報が欠落していて操縦を行うことができないため、自律車両が退避するかまたは不動のままでいることがある、エッジケースを軽減するのに使用されてもよい。遠隔バレットシステムはまた、自律システムからの情報も受信する（例えば、車両が走行する車道の視界を備える、車両のシステム状態、車両の乗員状態に関する情報を提供するなど）機能性を装備していてもよいが、それでもなお、車両の自律運転システムとは独立して機能してもよい。かかる独立性によって、他の例示の使用例、利益、および実現例の中でも特に、自律車両における完全または実質的なセンサ故障の条件であっても、遠隔バレットサービス自体が機能することが可能になってもよい。

【0081】

例えば、図６の概略ブロック図６００に示されるように、自律車両１０５は、様々なセンサ（例えば、６２０、６２５、６３０など）と、自律車両が様々な環境で自主走行できるようにする自律運転論理とを含んでもよい。上述したように、いくつかの例では、自律車両によって（または自律車両内の乗員による要求時に）、車両１０５の自律運転システムが、経路計画のルートの一部分を信頼性高く、望ましく、または安全に走行できないと決定されてもよい。自律車両１０５は、１つまたは複数のネットワーク（例えば、１５５）とインターフェース接続し、車両１０５と遠隔バレットサービス６０５を実現する１つまたは複数のコンピューティングシステムとの間でデータを交換できるようにする、通信能力を含んでもよい。遠隔バレットサービス６０５は、複数のユーザ端末デバイスを提供してもよく、それによって、車両のセンサ（例えば、６２０、６２５、６３０など）、または他のデバイス（例えば、路側システム（例えば、１３０）、空中もしくは地上ドローン（例えば、１８０）、および更には他の近隣車両からのセンサ）のセンサ（例えば、１７５）から提供されるセンサデータ（例えば、カメラの視界もしくは他のセンサ情報）に基づいて、仮想運転者ユーザが車両１０５周りの条件を観察することを可能にしてもよい。仮想運転者は次に、遠隔バレット端末で入力を提供して、対応する低レイテンシ高優先データを（ネットワーク１５５を通じて）車両１０５に通信して、車両１０５のステアリング、加速、およびブレーキを制御してもよい。

【0082】

いくつかの例では、車両１０５は、遠隔バレットサービス６０５に介入および制御のハンドオーバを自動的に要求してもよい。いくつかの事例では、この要求は反動的（例えば、退避イベント、センサ故障、または緊急事態に応答）であってもよいが、他の事例では、要求は、（ルート前方の条件を所与として、退避イベントまたは他の困難が起こる可能性が高いという予測に基づいて）遠隔バレットサービス６０５に車両の制御を先制的にテイクオーバさせるように送られてもよい。車両１０５は、自身のセンサ（例えば、６２０、６２５、６３０など）からのセンサデータ、ならびに他のセンサおよびデバイス（例えば、１３０、１８０など）からのデータ、ならびにバックエンド自律運転支援サービス（例えば、クラウドベースのサービス１５０）を活用して、１つまたは複数の機械学習モデルを使用して、制御を遠隔バレットサービス６０５にハンドオーバすべき条件であると決定してもよい。

【0083】

いくつかの事例では、複数の異なる自律車両のいずれか１つによって活用されてもよい、複数の遠隔バレットサービスが存在してもよい。実際に、複数の自律車両が、単一の遠隔バレットサービスに同時に接続し、それによって（例えば、別個の遠隔運転者がそれぞれの車両をガイドして）制御されてもよい。いくつかの事例では、１つの遠隔バレットサービスが別のものよりも高い利用可能性を広告してもよい。いくつかの事例では、遠隔バレットサービス品質の格付けが維持されてもよい。更に他の事例では、複数の異なる遠隔バレットサービスそれぞれのリアルタイムの接続性条件を特定するのに、接続品質および速度情報が維持されてもよい。したがって、遠隔ハンドオーバが必要であるかまたは見込まれることの検出に加えて、自律車両（例えば、１０５）はまた、かかる入力を考慮して、考えられる多くの利用可能な代替遠隔バレットサービスのうちどれが使用され要求されてもよいかを決定してもよい。いくつかの実現例では、（例えば、他の考慮点の中でも特に、特定のプロバイダからの遠隔バレットサービスに対するアクティブな加入、遠隔バレットサービスが自動車またはその自律運転システムのメーカーと関連付けられていることなどによって）車両が遠隔バレットサービスのうち特定の１つと関連付けられている例など、選択は直接的となる。

【0084】

それに加えて、遠隔バレットサービスはまた、（例えば、ハンドオーバの要求に含まれる情報、ハンドオーバまたは遠隔制御に関連して受信されたセンサデータから集められる情報などから）遠隔バレットサービスによって検出される様々な属性に基づいて、個々の自律車両（例えば、１０５）およびその所有者および乗員に合わせてサービスを調整してもよい。例えば、他の例示の考慮点の中でも特に、制御されている車両の型およびモデル、車両の自律運転システムのバージョンおよび実装、車両のどのセンサが動作可能で信頼性が高いままか、ハンドオフを引き起こす特定の条件（例えば、専門の遠隔運転者がトラブルシューティングを支援するように要求され、車両を困難なコーナーケースから抜け出させるように案内する）に基づいて、調整された運転支援ユーザインターフェースおよび制御が提供され、遠隔バレットサービスの仮想運転者に提示されてもよい。

【0085】

いくつかの実現例では、遠隔バレットサービスは、公共サービスとして政府機関を通して提供されてもよい。他の実現例では、遠隔バレットサービスはプライベートセクタの商業的企業として提供されてもよい。したがって、所与の車両（例えば、１０５）の走行と関連して提供される遠隔バレットサービスと関連して、測定基準が自動的に収集され、提供された遠隔バレットサービスを記述する、対応するデータが（例えば、車両（例えば、１０５）および遠隔バレットシステム６０５のどちらかもしくは両方のセンサまたはモニタによって）生成されてもよい。かかる測定基準およびデータは、他の測定基準の中でも特に、遠隔仮想サービスがそのサービスに対して請求する利用料を決定するために考慮され使用されてもよい、遠隔バレットサービスをトリガした条件の過酷度（例えば、より困難な問題はより高い遠隔バレットサービス利用料を求める）、遠隔バレットサービス制御下で走行した距離、遠隔バレットサービス制御下にあった時間、遠隔バレットサービスを容易にするために使用された特定の仮想運転者およびツール、遠隔バレットサービスによって使用された車外データのソースおよび量（例えば、センサ（例えば、６２０、６２５、６３０）外にあるソース（例えば、１７５、１８０）から要求され収集されたデータの量）など、遠隔バレットサービスの特性を記述してもよい。いくつかの事例では、利用料は、車両の所有者、車両メーカー、車両保証提供者、車両の自律運転システムの提供者などによって支払われるか、またはそれらの間で分割されてもよい。いくつかの事例では、遠隔バレットサービス請求の責任は、他の例示の実現例の中でも特に、どの当事者が遠隔バレットサービス利用料のどれだけの金額に責任があるかを決定するように、ハンドオーバ要求に関連して生成されるデータから自動的に決定されてもよい。

【0086】

遠隔バレットサービスに対するハンドオーバ要求と関連して生成されるデータ、ならびに所与の走行において車両に提供される遠隔バレットサービスを記録するのに生成されるデータは、遠隔バレットサービス（例えば、６０５）のシステム（例えば、６１０）に、またはクラウドベースのサービス（例えば、１５０）に収集され維持されてもよく、それによって遠隔バレットサービスの結果を集約しクラウドソーシングして、他の例示の使用の中でも特に、今後の遠隔バレットサービスの提供、ならびに車両が自主走行し遠隔バレットサービスを要求する際に依存する自律運転モデルを改善してもよい。

【0087】

図７に移ると、一例の遠隔バレットサービスの送達中におけるシステム間の通信を示す概略ブロック図７００が示されている。例えば、ハンドオーバ要求７１０は、車両（１０５）（例えば、その自律運転システムの遠隔バレットサポートブロック（例えば、７０５））から、ネットワークを通じて、（１つまたは複数の遠隔バレットサービスシステム（例えば、６０５）を通して提供される）遠隔バレットサービスを提供または仲介するコンピューティングシステムに送られてもよい。他の例では、信頼されている第三者システム（例えば、自律車両１０５の車外）が、（例えば、車両が関わる交通を監視する様々なデバイスからのセンサデータの集合によって）車両１０５が支援を必要としていると決定してもよい。いくつかの事例では、車両内の乗員は、他の例示の実現例の中でも特に、車両１０５の代わりにハンドオーバ要求（例えば、７１０'）を送ってもよい、第三者サービス（例えば、クラウドベースのサービス１５０）を使用して、（例えば、スマートフォンアプリを通して）遠隔バレットサービスをトリガしてもよい。安全な最優先通信チャネル７１５が、車両１０５と遠隔バレットシステム６０５との間に確立されて、遠隔バレットサービスを提供できるようにしてもよい。例えば、車両の位置および状態ならびにその周囲環境のほぼリアルタイムの視野を提供するため、車両１０５のセンサによって収集されたセンサデータ（例えば、カメラデータ、ＬＩＤＡＲデータなど）が送られてもよい。いくつかの事例では、データは、例えば、他の例示の使用の中でも特に、車両の乗員の視野を使用可能にする、ならびに／あるいは乗員と遠隔バレットの仮想運転者との間のライブ通信を容易にする、車両１０５の内部センサからのデータを含んでもよい。遠隔バレットの仮想運転者は、車両１０５のライブ条件を記述する受信した情報に応答し、自身の端末の制御を使用して、車両１０５の運転操作を遠隔制御するためにチャネル７１５を通じて車両に送られる運転命令データを生成してもよい。遠隔バレットサービスはまた、（例えば、車両１０５から受信するものに加えて）路側ユニット、他の車両、ドローン、および他のセンサデバイスなどの車外ソースからの補足データを取得してもよい。かかる情報は、１つまたは複数のバックエンドシステム（例えば、１５０）によって容易にされる、最優先チャネル（例えば、７２０）を通じて提供されてもよい。いくつかの実現例では、遠隔バレットシステム６０５は、車両１０５の場所から、遠隔バレットシステムが別の安全なチャネル（例えば、７２０）を確立し、遠隔バレットシステムによって制御されている車両の周りの現場を記述するライブデータを取得するのに用いてもよい、センサセット（遠隔バレット運転者の制御下で、車両が経路に沿って移動するにつれて動的に変化してもよい）を決定してもよい。したがって、いくつかの実現例では、遠隔バレットサービスは、制御されている車両１０５上または車外のセンサからのセンサデータのどちらかもしくは両方を使用してもよい。

【0088】

上述したように、いくつかの実現例では、自律車両は、支援のために遠隔バレットサービスを呼び出すべきインスタンスを検出してもよい。いくつかの事例では、この決定は１つまたは複数のバックエンドサービス（例えば、１５０）によって支援されてもよい。いくつかの実現例では、車両は、ハンドオーバ要求（例えば、７１０）を引き起こした条件を記述するデータをかかるサービス１５０に（または他のクラウドベースのシステム、レポジトリ、およびサービスに）提供してもよい。車両は更に、遠隔バレットシステムの性能を記述する（例えば、遠隔バレットが取った操作または経路を記述する、サービスの乗員満足度を記述するなど）報告を（サービス後またはサービス中に）提供してもよい。かかる報告データ（例えば、７３０）は、機械学習モデルを訓練するか、または別の方法で、バックエンドもしくはクラウドベースのシステム（例えば、１５０）によって提供されるサービスを強化するのに、後で使用されてもよい。洞察および改善されたモデルは、システム１５０によって導き出され、次に車両の自律運転システム（ならびにその遠隔バレットサポート論理７０５）と共有されてもよい。いくつかの事例では、自律車両は、遠隔バレットの操作および反応を記述する情報を記録し、それ自体の自律運転機械学習モデルで使用されるモデルを更に訓練し改善するのに使用してもよい。同様に、報告データ（例えば、７２０による）は、遠隔バレットシステム６０５からクラウドベースのサービスに、または車両に提供されて、本明細書に記載されるような、他の例示の使用の中でも特に、車両の（および他の車両の）自律運転論理ならびにハンドオーバ要求を強化するのに使用されてもよい。

【0089】

実例として、自律車両（例えば、１０５）は、ルートに沿って走行しながら、車両の自律運転システムが特定の状況を扱うことができないと、自律的に決定（あるいは乗員フィードバック、または公安官によって受信もしくは報告されるフィードバックなどに基づいて決定）してもよい。したがって、遠隔バレットサービスがトリガされてもよい。いくつかの事例では、遠隔バレットサービスは、道路の次の区間に問題があるとの予測に基づいて、道路のその区間に前もって接触してもよい。いくつかの実現例では、ハンドオフ要求は、（図５の例で考察したような）自律運転パイプラインの経路計画フェーズを実現する、自律運転システム論理を補足する論理ブロックによって実施されてもよい。いくつかの例では、遠隔バレットハンドオフ要求が遠隔バレットシステムに対して発行されると、テレマティクス制御ユニット（ＴＣＵ）などの自律車両の通信モジュールが、遠隔バレットサービスに接続するのに使用されてもよい。いくつかの実現例では、ＴＣＵの製造フェーズ中に指定される緊急サービス（緊急電話と同様）との通信として、遠隔バレットサービス通信が確立されてもよい。このハンドオフ要求では、車両の場所が提供されてもよい。いくつかの実現例では、ハンドオフ要求および遠隔バレットサービスは、「遠隔バレット」を扱う人間の仮想運転者が行動を取るＯＥＭ提供のコール／制御センタにおいて実現されてもよい。いくつかの実現例では、車両と遠隔バレットサービスとの間の接続の確立に応答して、遠隔バレットは車両に対して、周囲の視野に対するカメラ全てからの映像をリアルタイムでストリーミング配信するように要求を送ってもよい。同じ場所にある他のセンサ（例えば、路上カメラおよび路側センサ）も、車両から受信される情報を補足するデータ（例えば、追加のストリーミング映像）を提供するものとして特定されてもよい。車両から（また場合によっては、補助ソース（例えば、路上カメラ）からも）ストリーミング配信された映像を通して、ほぼリアルタイムで遠隔バレットに対して表示される、車両の周囲および路面条件の視野に基づいて、遠隔バレットは（プレーヤーが自動車の視野を見て、ホイール、手持ち型コントローラなどによって運転し制御する映像没入型ゲームと同様に）車両を制御して、車両を目的地まで運転する。いくつかの事例では、目的地は、問題が少ないと決定されたルートの次の区間に対応してもよく、その地点で制御が自律運転システムに返されて、標準自律運転モードで車両の運転を制御してもよい。他の事例では、元のハンドオフ要求の状況および検出された特性に基づいて、遠隔バレットサービスは、他の例および使用例の中でも特に、センサもしくは自律運転システムが故障した車両を最寄りのサービスセンタまで運転する、または病気のもしくはケガをした乗員が乗った車両を病院まで運転するなど、車両で検出された問題点に対処する装備があると特定された特定の目的地に車両を向けてもよい。

【0090】

上述したように、いくつかの実現例では、車両の自律運転システムは、他の遠隔センサデバイス（例えば、他の自律車両、ドローン、路側ユニット、気象モニタなど）によって収集されたデータにアクセスして、道路の次の区画において見込まれる条件を先制的に決定してもよい。いくつかの事例では、様々なセンサは、データをクラウドベースのシステムに提供して、このデータ群を集約し処理して、道路の区間およびこれらのルートに影響を及ぼす条件に関連する情報を複数の自律車両に提供してもよい。上述したように、いくつかの事例では、クラウドベースのシステムおよび他のシステムは、以前の退避および遠隔バレットハンドオーバイベントと関連付けられた入力を受信してもよく、これらのイベントに共通の特性を検出してもよい。いくつかの実現例では、機械学習モデルは、この情報から構築または訓練されてもよく、かかる機械学習モデルは、路側ユニット、クラウドベースの支援システム、遠隔バレットコンピューティングシステム、または自律車両自体の車両内システムに配備され、それらによって実行されて、可能性がある遠隔バレットハンドオフを予測的に決定する論理を提供してもよい。例えば、所与の自律車両によってアクセスされるセンサデータを通して、車両は、退避が高頻度で起こっている、および／または遠隔バレットハンドオフが一般的である、各道路に沿ったエリアを前もって決定してもよい。いくつかの例では、自律車両は、道路の次の区間に関して報告された条件が、退避および／または遠隔バレットハンドオーバの可能性（退避およびハンドオーバが道路のその特定の区間で以前に起こっていない場合であっても）を示唆していることを、（例えば、対応する機械学習モデルから）決定してもよい。かかる情報を使用して、自律車両は、車両内運転者または遠隔バレットサービスに対するハンドオーバの準備をする措置を先制的に講じてもよい。いくつかの事例では、自律車両は、（例えば、遠隔バレットに対応することができる通信リソースの非利用可能性の検出、好ましいバレットサービスに関して報告された利用可能性の欠如、遠隔バレットが可能な限り回避されることを要求するユーザの好みなどにも基づいて）この先にある道路の面倒な区間を回避するように経路計画を変更するよう判定してもよい。いくつかの実現例では、自律車両の表示は、次の予測される問題点ならびに退避および／または遠隔バレットハンドオーバの可能性に関する、車両内乗員に対する警報または命令を提示してもよい。いくつかの事例では、この情報はインタラクティブ表示の形で提示されてもよく、それを通して乗員は、乗員へのハンドオーバ、遠隔バレットサービスへのハンドオーバ、代替ルートの選択、または退避イベントのいずれかによる、次の走行セグメントの扱いに関する自身の好みを登録してもよい。更に他の実現例では、他の例示の実現例の中でも特に、道路の面倒なセグメントを反映したクラウドベースの知識が、道路標識または車両内道路マップに通信されて、面倒なセグメントを運転者および他の自律車両に示してもよい。

【0091】

図８に移ると、危険および困難なシナリオを通して自律車両を支援する遠隔バレットサービスを立ち上げるのに更に活用されてもよい、かかる退避イベントリスクおよび路面条件警報に関する情報の協調的報告を示す概略ブロック図８００が示されている。例えば、情報は、関連車両および／または周囲のセンサデバイスによる、退避要求および／または遠隔バレットイベントに関して収集されてもよく、この情報は、自律運転システムを強化するのに共有され活用されてもよい。図８の例では、退避またはハンドオフが起こると、関連車両（例えば、１０５）は、このイベントに関係して生成され収集されたデータをアセンブルしてもよく、この情報を、クラウドベースの支援システム（例えば、１５０）、ならびに／あるいは路側ユニットまたはエッジコンピュータ（もしくはエッジクラウド）サーバ（例えば、１４０）などのエッジデバイスと共有してもよい。

【0092】

図９は、様々な車両センサ（例えば、６２０、６２５）、人工知能／機械学習ベースの自律運転スタック５１５、および遠隔バレットサービスを提供することができるシステムに対するハンドオフ要求のトリガおよび生成に対応する論理（例えば、９０５）を含んでもよい、一例の自律車両１０５を示す概略ブロック図９００を示している。テレマティクス制御ユニット（ＴＣＵ）９１０が提供されてもよく、それを通して、ハンドオフ要求が送られ、車両１０５と仮想運転者端末との間に通信が確立されて、遠隔バレットサービスが提供されてもよい。

【0093】

自律運転エンジン（例えば、５１５）が退避イベントを決定するか、または遠隔バレットサポート論理（例えば、９０５）が、ハンドオフ要求が送られるべきであると決定すると、信号がＴＣＵ９１０に送られて、車両の場所および退避場所を、様々なクラウドベースのエンティティ（またはこの情報を複数のエンティティもしくはサービスに分配する単一のエンティティもしくはゲートウェイ）に送ってもよい。実際に、多くの異なるサービスがかかる情報を利用してもよい。例えば、クラウドベースのアプリケーション８１５（例えば、車両ＯＥＭと関連付けられる）は、一例では、この情報の主要な標的または受信者であってもよく、この情報の部分を他の受信者に分配してもよい。他の例では、車両１０５は、データ自体を複数の異なるクラウドベースのアプリケーション（例えば、受信者ごとに１つのアプリケーション）に提供し分配してもよい。例えば、ＯＥＭ保守管理アプリケーション（例えば、８２０）は、退避またはハンドオフ情報を利用し、車両（およびそのモデル）が自律運転を扱うことができない曲がり角の事例の診断および特定にその情報を活用してもよい。いくつかの例では、退避またはハンドオフ情報の受信者は、専用クラウドアプリを通して車両から直接、または情報を車両から直接受信するＯＥＭを通して、この情報を受信することができる、従来のナビゲーションマップ、３Ｄマップ、高精細度（ＨＤ）マップなどのプロバイダを含む、マップアプリケーションプロバイダ（例えば、８２５、８２６）を含んでもよい。マッププロバイダは、退避およびハンドオフ情報を、退避イベントおよび困難な自律運転条件が起こりやすいエリアに関する情報をマップに投入する助けとなり得る統計に活用して、この情報を継続的に更新できるようにしてもよい。更に、ＨＤマップは、かかる情報を、他の例の中でも特に、ＨＤマップが提供する道路セグメントごとの高精細度情報の一部として組み込んでもよい。地方自治体、政府機関、有料道路提供者、ならびに他のインフラストラクチャ企業および運営機関（例えば、８３０）も、（例えば、他の例の中でも特に、車両１０５から直接、別のアプリケーションもしくはエンティティを通して間接的に、または関連する路側センサおよび路側支援ユニットを通してかかる情報を獲得することによって）、退避およびハンドオフ情報の受信者であってもよい。かかる機関は、この情報を利用して、新しい道路およびインフラストラクチャ計画、治安維持、料金所、標識または警報の配備のトリガ、および他の使用の証拠として、道路保守管理をトリガしてもよい。

【0094】

退避またはハンドオフイベントはまた、車両１０５が、付近の路側ユニット、車両、および他のセンサデバイスと情報を共有するのをトリガしてもよい。一例の路側ユニット（例えば、１４０）はこの情報を活用して、例えば、このデータを、受信する他のデータとともに処理し、この情報またはこの分析の結果を、（例えば、道路セグメントアプリケーション８３５を通して）近傍にある他の車両（例えば、１１０）またはシステムと共有してよい。例えば、路側ユニットは、他の例示の行動の中でも特に、退避イベントのリスクを他の車両に警告し、インフラストラクチャが遠隔バレットサービスとの通信を支援する準備をしてもよい。路側ユニットはまた、関連する地方自治体、保守管理提供者、および機関が、（例えば、信号機タイミングを動的に適応させる、デジタル標識を更新する、追加の車線を開けるなどのために）この情報にアクセスし使用してもよいように、この情報を格納または通信してもよい。

【0095】

上述したように、様々なクラウドおよびエッジベースのコンピューティングシステムは、時間に伴って様々な車両から収集された退避およびハンドオフ情報を利用してモデルを改善してもよく、それらのモデルは、他の例示の使用および利益の中でも特に、（例えば、退避もしくは遠隔バレットハンドオフを推奨するように）推奨システムを改善し、予測的または先制的な遠隔バレットハンドオフを可能にし、自律運転モデルを改善し、遠隔バレットサービスを改善するのに、共有され使用されてもよい。

【0096】

全ての道路エージェントがモデルに準拠した場合に安全性を担保する、または事故の場合に責任を適正に割り当てる、数学モデルが様々な実施形態で使用されてもよい。例えば、安全モデルは、エージェントの挙動を規定の制約セットに限定することによってモデル化された最悪のシナリオにおける衝突を回避するため、数学的に計算された２つの道路エージェント間の縦方向および横方向の最小安全距離に依存してもよい。

【0097】

２つのエージェント間の距離が、安全モデルによって規定された安全距離を下回る状況（例えば、「危険状況）が生じたときは常に、以前に規定された限界内の加速を制定する（例えば、「適切な応答」を制定する）ことによって両方のエージェントが応答した場合、安全モデルは、衝突の防止を数学的に担保してもよい。他方で、エージェントの一方が準拠していない場合、事故が起こった場合にそのエージェントが責任を負うべきである。

【0098】

安全モデルを使用することで、縦方向および横方向の次元に別個に焦点を当てることによって、２つのエージェントが関わる状況の分析が単純化される。例えば、エージェントの速度および加速、それらの速度および加速を使用して計算された最小安全距離、ならびにエージェント間の実際の距離は全て、車線の中心がｙ軸上にあるとみなされる（したがって、縦方向成分がｙで表され、横方向成分がｘで表される）座標系において、それらの縦方向および横方向成分に関して分析される。

【0099】

図１０は、特定の実施形態による様々な運転フェーズを示している。図１０では、エージェント１００２および１００４は、３つのフェーズ１００６、１００８、および１０１０で示される。安全モデルに準拠するため、エージェントは、縦方向および横方向両方の最小安全距離が侵害されたとき、適切な応答を制定することが求められ、適正な応答自体はどの侵害が最も最近起こったかに依存する。第１のフェーズ１００６では、エージェント１００２および１００４は、安全でない横方向距離で、ただし安全な縦方向距離で分離されている。第２のフェーズ１００８は、縦方向距離がまだ安全だった最後の時点（「責任時間（ｂｌａｍｅ ｔｉｍｅ）」と呼ばれる）を示している。責任時間後の次の時点で、縦方向安全距離も侵害される。第３のフェーズ１０１０では、縦方向の適切な応答が制定された後、エージェントは安全な状況に戻っており、衝突が回避されている。

【0100】

安全モデルは、エージェントのポリシーから完全に分離されて設計されてもよい。安全モデルに準拠するために、自律運転スタックは、エージェントのポリシーによって行われる判定の準拠をチェックし、エージェントのポリシーが準拠していない行動を要求したときの、既定の安全モデルに準拠した判定を施行する、追加の構成要素を含んでもよい。

【0101】

安全モデルは自律車両を念頭に置いて設計されてもよいが、本開示の様々な実施形態は、人間の運転者の判定によって事故を回避するメカニズムとして、任意の好適な事故回避数学モデルを使用する、制御システムを備えた車両を含む。かかる実施形態は、場合によっては、人間の運転者にとってより高い全体的な安全性をもたらしてもよく、また、現行法が安全モデルの責任割当てメカニズムに匹敵する手法で責任を割り当てた場合（例えば、責任はモデルの条件を侵害したエージェントに割り当てられる）に、運転者が事故の責任を問われないという証拠または担保を提供してもよい。安全モデルにしたがって、本明細書に記載される様々な実施形態は、例えば、より多くのエージェント（人間もしくはそれ以外）が安全モデルエンフォーサ（または類似のモデルのエンフォーサ）を装備するにしたがって、交通事故の全体量が減少して、全てのエージェントにとって理想的な状況に発展するといった、別の可能なより長期の利点を提示する。

【0102】

本開示の特定の実施形態では、車両は、安全モデルに準拠しない加速をもたらすであろう運転者入力を、安全モデルに準拠した加速の範囲内に含まれる加速を生成することが担保された合成的に生み出された入力と置き換える、制御システムを含む。安全モデルに準拠した運転者入力は、不変のまま作動システムに渡され、それによって、場合によっては危険な状況でのみテイクオーバするシステムが実現される。

【0103】

図１１は、特定の実施形態による、安全モデルに準拠した加速を確保するように運転者入力を修正するシステム１１００の図を示している。様々な実施形態では、システム１１００は、車両、例えば１０５の一部であってもよく、図示されるモジュールはいずれも、車両、例えば１０５のコンピューティングシステムの任意の好適な論理によって実現されてもよい。他の実施形態では、モジュールはいずれも、車両の外部で（例えば、１４０または１５０によって）実現されてもよく、結果は車両に通信されてもよい。システム１１００は、制御１１０２（様々な実施形態では、制御１１０２は運転制御２２０の任意の好適な特性を有してもよい）、センサスイート１１０４（様々な実施形態では、センサスイート１１０４はセンサ２２５の任意の好適な特性を有してもよい）、安全モデル１１０６、安全モデルエンフォーサ１１０８、制御・加速変換器１１１０、および加速・制御変換器１１１２を含む。特定の実施形態では、システム１１００の構成要素は全て車両内に統合されてもよい。他の実施形態では、１つまたは複数の構成要素は、車両とは別個であり、車両に通信可能に結合されてもよい。

【0104】

制御１１０２は、人間の運転者が車両の作動システムに入力を提供できるように提供されてもよい。例えば、制御は、ハンドルまたは他のステアリングメカニズム、アクセルペダルまたは他のスロットル、およびブレーキペダルまたは他のブレーキメカニズムを含んでもよい。一実施形態では、制御は、ギアシフタ、緊急ブレーキ、ジョイスティック、タッチ画面、身振り認識システム、または車両の速度もしくは方向に影響を及ぼしてもよい他の好適な入力制御など、他の構成要素を含んでもよい。

【0105】

センサスイート１１０４は、車両と関連付けられた世界状態に関する情報を収集するのに、車両によって利用される１つまたは複数のセンサの任意の好適な組み合わせを含んでもよい。例えば、センサスイート１１０４は、１つまたは複数のＬＩＤＡＲ、レーダ、カメラ、全地球測位システム（ＧＰＳ）、慣性測定ユニット（ＩＭＵ）、音声センサ、赤外線センサ、または本明細書に記載される他のセンサを含んでもよい。世界状態情報は、本明細書に記載されるコンテキスト、センサによって検出される物体、物体と関連付けられた場所情報、または他の好適な情報のいずれかなど、任意の好適な情報を含んでもよい。

【0106】

世界状態は、安全モデル１１０６、制御・加速変換器１１１０、または加速・制御変換器１１１２など、システム１１００の任意の好適な構成要素に提供されてもよい。例えば、世界状態情報は安全モデル１１０６に提供されてもよい。安全モデル１１０６は、世界状態情報を利用して、車両に対して安全モデルに準拠した加速の範囲を決定してもよい。その際、安全モデル１１０６は、車両と他の車両または他の物体との経度方向および緯度方向距離を追跡してもよい。それに加えて、安全モデル１１０６はまた、車両の経度方向および緯度方向速度を追跡してもよい。安全モデル１１０６は、安全モデルに準拠した加速の範囲を周期的に更新し、加速範囲を安全モデルエンフォーサ１１０８に提供してもよい。安全モデルに準拠した加速は、経度方向の安全モデルに準拠した加速の範囲、ならびに緯度方向の安全モデルに準拠した加速の範囲を指定してもよい。加速は、メートル毎秒毎秒など、任意の好適な単位で表されてもよく、正または負の値を有してもよい（もしくはゼロの値が付けられてもよい）。

【0107】

安全モデルエンフォーサ１１０８は、制御信号を運転者入力から受信し、制御・加速変換器１１１０を呼び出し、それによって、運転者入力が作動システム１１１４に渡された場合、運転者入力を予測車両加速を示す加速値に変換する（いくつかの実施形態では、緯度方向および経度方向両方の加速成分を含む）。安全モデルエンフォーサ１１０８は、加速値が、安全モデル１１０６から受信された安全モデルに準拠した加速の最近の範囲内にあるか否かを決定してもよい。加速値が安全モデルに準拠した加速の範囲内である場合、安全モデルエンフォーサによって、運転者入力を制御１１０２から作動システム１１１４に渡すことが可能になる。加速値が安全モデルに準拠した加速の範囲内にない場合、安全モデルエンフォーサは、運転者入力を阻止し、受信した範囲内の安全モデルに準拠した加速値を選ぶ。安全モデルエンフォーサ１１０８は次に、選択された加速値を用いて加速・制御変換器１１１２を呼び出してもよく、返ってくる１つまたは複数の制御信号を受信してもよい。特定の実施形態では、加速・制御変換器１１１２によって提供される制御信号は、運転者入力に応答して作動システム１１１４に提供される制御信号と同じ形式を有してもよい。例えば、制御信号は、ブレーキの量、加速の量、および／またはステアリングの量と方向、あるいは他の好適な制御信号を指定してもよい。安全モデルエンフォーサ１１０８は、これらの新しい制御信号を作動システム１１１４に提供してもよく、そこで制御信号を使用して、指定されたように車両を加速させてもよい。

【0108】

様々な実施形態では、安全モデルエンフォーサ１１０８は、安全モデルに準拠した加速の範囲内の任意の好適な加速値を選んでもよい。特定の実施形態では、安全モデルエンフォーサ１１０８は、範囲から無作為に加速値を選んでもよい。別の実施形態では、安全モデルエンフォーサ１１０８は、範囲から最大または最小の控えめな値を選んでもよい。別の実施形態では、安全モデルエンフォーサ１１０８は、範囲の中央から値を選んでもよい。更に別の実施形態では、安全モデルエンフォーサ１１０８は、（例えば、運転者の好みに基づいた、または安全上の考慮点に基づいた）ポリシー情報を使用して、加速値を決定してもよい。例えば、安全モデルエンフォーサ１１０８は、経度方向の加速を緯度方向の加速よりも好んでもよく、またはその逆であってもよい。別の例として、安全モデルエンフォーサ１１０８は、運転者にとってより快適な加速を好んでもよい（例えば、より遅いブレーキまたはより小さいステアリングの調節が、急ブレーキまたは尻振りよりも好ましいことがある）。様々な実施形態では、判定は、安全性および快適性の両方に基づいてもよく、関連する測定基準は同じ運動パラメータおよび車両特性のセットから計算される。

【0109】

上述したように、制御・加速変換器１１１０は、運転者入力（例えば、ハンドルの回転およびスロットル／ブレーキペダル圧力）を加速に変換する。様々な実施形態では、変換器１１１０は、変換中、世界状態（例えば、車両の速度、天候、路面条件、道路レイアウトなど）、およびホスト車両の物理的性質（例えば、車両の重量、車両の形状、タイヤの性質、ブレーキの性質など）など、任意の好適な情報を考慮に入れてもよい。一実施形態では、変換は（例えば、車両のメーカーによって供給されるような）車両の動力学の高度な数学モデルに基づいてもよい。いくつかの実施形態では、変換器１１１０は、機械学習モデル（例えば、任意の好適な回帰モデルを実現する）を実現して、変換を実施してもよい。制御・加速変換の一例の機械学習モデルについては、図１２および図１３に関連して更に詳細に記載する。

【0110】

加速・制御変換器１１１２は、テイクオーバ中に安全モデルエンフォーサ１１０８によって強化された安全モデルに準拠した加速を、作動システム１１１４に適した入力に変換する論理を含んでもよい。変換器１１１２は、任意の好適な情報を利用してこの変換を実施してもよい。例えば、変換器１１１２は、制御・加速変換器１１１０によって使用される情報のうち１つまたは複数を利用してもよい。同様に、変換器１１１２は、加速の入力を所与として制御信号を出力するように適応された機械学習モデルなど、変換器１１１０と同様の方法を使用してもよい。特定の実施形態では、加速・制御変換器は、加速値に基づいて所望の制御信号を決定する、比例積分微分（ＰＩＤ）コントローラを備えてもよい。ＰＩＤコントローラは、比例、積分、および微分係数を用いる従来のコントローラアルゴリズムを使用して実現されてもよく、または機械学習ベースであることができ、これらの係数は、安全性および快適性を考慮に入れる最適化測定基準を利用する、（例えば、機械学習エンジン２３２によって実現される）ＭＬアルゴリズムを使用して予測される。

【0111】

１１１４は、１つまたは複数の制御信号を受信し、１つまたは複数の制御信号に対して車両に応答させる、任意の好適な作動システムを表してもよい。例えば、作動システムは、車両のエンジンまたはモータに供給されるガソリンもしくは電力（または他の動力源）の量、車両の車輪に適用されるブレーキ圧力の量、車両の１つもしくは複数の車輪に適用される角度量を調節するか、あるいは車両の加速に影響を及ぼしてもよい他の任意の好適な調節を行ってもよい。

【0112】

図１２は、特定の実施形態による、制御・加速変換器１１１０の訓練フェーズを示している。モデルに対する訓練入力１２０２は、制御信号に応答して制定される加速に影響を及ぼしてもよい任意の好適な情報を含んでもよい。例えば、訓練入力は、車両の初速、路面条件、タイヤ条件、気象条件、車輪回転、アクセルペダル圧力レベル、ブレーキペダル圧力レベル、道路レイアウト、車両の物理的性質、または他の好適な情報と、かかる情報の各セット下で結果として得られる加速との、任意の組み合わせを含んでもよい。かかるデータは、機械学習訓練フェーズ１２０４中に、制御信号および他の情報（例えば、世界状態情報、車両の物理的性質）を加速値に変換するのに車両によって使用されてもよい、回帰モデル１２０６を訓練するのに使用されてもよい。様々な実施形態では、回帰モデル１２０６は、多くの異なる天候、道路、および車両状態条件下にある車両のクラスのうち１つまたは複数の車両を使用して収集された、グラウンドトゥルースデータに対して訓練される。様々な実施形態では、訓練は、（車両内コンピューティングシステム、クラウドベースのシステム、または他のデータ処理環境にかかわらず）任意の好適なコンピューティングシステムによって実施されてもよい。

【0113】

図１３は、特定の実施形態による、制御・加速変換器１１１０の推論フェーズを示している。推論フェーズ中、車両と関連付けられた様々な入力１３０２が回帰モデル１２０６に提供されて、入力に基づいて予測加速が出力される。入力は、モデル１２０６を訓練するのに使用される入力タイプを反映してもよいが、かかる入力のリアルタイム値を含んでもよい。回帰モデル１２０６は加速値１３０４を出力する。

【0114】

同様の回帰モデルが加速・制御変換器１１１２に使用されてもよい。同様の入力データが、モデルを訓練するのに使用されてもよいが、推論中、モデルは、所望の加速を入力として（世界状態および／または車両状態のリアルタイム値とともに）受信してもよく、所望の加速をもたらすように予測された制御信号を出力してもよい。

【0115】

図１４は、特定の実施形態による、許容可能な制御信号を車両作動システムに提供するフローを示している。１４０２で、車両に対する人間の入力に応答して、第１の１つまたは複数の制御信号のセットが生成される。１４０４で、第１の制御信号のセットが車両の許容可能な加速をもたらすか否かに関して決定が行われる。制御信号が許容可能な加速をもたらす場合、１４０６で、制御信号は不変のまま車両作動システムに提供される。制御信号が許容不能な加速をもたらす場合、１４０８で、許容可能な加速が特定される。１４１０で、許容可能な加速が第２の１つまたは複数の制御信号のセットに変換される。１４１２で、第１の１つまたは複数の制御信号のセットの代わりに、第２の１つまたは複数の制御信号のセットが車両作動システムに提供される。

【0116】

自律車両から人間へ、またはその逆への運転責任の安全なハンドオーバは、非常に重要なタスクである。上述したように、人間から自律車両へのハンドオーバの１つの方策は、自律車両が許容不能な人間の入力を妨害し、それらをより安全な入力と置き換えてもよい、安全モデルなどに基づいてもよい。

【0117】

本開示の様々な実施形態では、ハンドオフ準備状態は、かかる測定が行われるコンテキストに対する、車両のセンサの信号品質全体の指標に基づいてもよい。コンテキストは、交通状況（例えば、高速道路もしくは混雑した通り）または気象条件（例えば、晴天、雨、水溜りがある、薄氷があるなど）など、本明細書に記載する任意の好適なコンテキストであってもよい。信号品質測定基準は、センサデータおよびコンテキスト情報を入力として受信し、信号品質測定基準を出力する、機械学習（ＭＬ）アルゴリズムを使用して決定されてもよい。この信号品質測定基準は次に、車両衝突事故情報を使用して訓練された別のＭＬアルゴリズムを使用して、ハンドオフ準備状態を決定するのに使用される。信号品質測定基準が、コンテキストに照らして信号品質が低いことを示した場合、人間の運転者から自律車両へのハンドオフは安全ではないことがあるので、かかるハンドオフは許可されなくてもよい。

【0118】

図１５は、特定の実施形態による、コンテキストモデル１５０８を構築する訓練フェーズを示している。様々な実施形態では、コンテキストモデル１５０８は、センサデータ１５０４およびコンテキスト情報グラウンドトゥルース１５０６を使用して構築される分類モデルであってもよい。ＭＬアルゴリズム１５０２は、センサデータ１５０４およびコンテキスト情報グラウンドトゥルース１５０６に基づいて、コンテキストモデル１５０８を訓練するための任意の好適なアルゴリズムを表してもよい。センサデータ１５０４は、１つもしくは複数のＬＩＤＡＲ、レーダ、カメラ、全地球測位システム（ＧＰＳ）、慣性測定ユニット（ＩＭＵ）、音声センサ、赤外線センサ、または他のセンサなど、車両の１つまたは複数のセンサからの任意の好適なセンサデータを含んでもよい。ＭＬアルゴリズム１５０２は、センサデータ１５０４およびコンテキスト情報グラウンドトゥルース１５０６の様々なインスタンスを使用して、コンテキストモデル１５０８を訓練してもよく、各インスタンスは、センサデータのセットならびに関連するコンテキストを含んでもよい。様々な実施形態では、訓練データは、実際のセンサデータおよび関連するコンテキスト、シミュレートされたデータおよび関連するコンテキスト、ならびに／あるいは合成データおよび関連するコンテキスト（例えば、本明細書に記載する方法を使用して生成された合成画像からのもの）を含んでもよい。特定の実施形態では、コンテキストは、「霧」および「濡れた路面」など、コンテキストを記述する１つまたは複数のテキストキーワードを含んでもよいが、コンテキストの任意の好適な表現が本開示によって想到される。

【0119】

図１６は、特定の実施形態による、信号品質測定基準モデル１６０８を構築する訓練フェーズを示している。様々な実施形態では、信号品質測定基準モデル１６０８は、センサデータおよびコンテキスト情報グラウンドトゥルースを使用して構築される回帰モデルであってもよい。様々な実施形態では、センサデータ１６０４は、センサデータ１５０４と同じセンサデータであってもよく、または少なくとも部分的に異なってもよい。いくつかの実施形態では、コンテキスト情報グラウンドトゥルース１６０６は、コンテキスト情報グラウンドトゥルース１５０６と同じコンテキスト情報であってもよく、または少なくとも部分的に異なってもよい。ＭＬアルゴリズム１６０２は、センサデータ１６０４およびコンテキスト情報グラウンドトゥルース１６０６の様々なインスタンスを使用して、信号品質測定基準モデル１６０８を訓練してもよく、各インスタンスは、センサデータのセットならびに関連するコンテキストを含んでもよい。様々な実施形態では、訓練データは、実際のセンサデータおよび関連するコンテキスト、シミュレートされたデータおよび関連するコンテキスト、ならびに／あるいは合成データおよび関連するコンテキストを含んでもよい。特定のコンテキストと関連付けられたセンサデータの複数の異なるインスタンスを分析することによって、ＭＬアルゴリズム１６０２は、特定のコンテキストに対するセンサデータ１６０４の様々なインスタンスの品質同士を区別するように、信号品質測定基準モデル１６０８を訓練することができてもよい。同様の訓練が任意の好適な数の異なるコンテキストに対して行われてもよい。

【0120】

信号品質測定基準モデルが訓練された後、センサデータのインスタンス（センサデータのインスタンスがある期間にわたって収集されたセンサデータを備える場合）および関連するコンテキストを受信し、センサデータ品質の１つまたは複数の指示を出力することができてもよい。例えば、信号品質測定基準は、センサデータのインスタンスの品質に対する合成スコアを含んでもよい。別の例では、信号品質測定基準は、センサデータの複数のタイプそれぞれの品質に対するスコアを含んでもよい。例えば、信号品質測定基準は、カメラデータに対するスコアおよびＬＩＤＡＲデータに対するスコアを含んでもよい。いくつかの実施形態では、スコアは、信号対雑音比の測定値、分解能の測定値、または他の好適なタイプの品質測定基準など、複数のタイプの品質測定基準のいずれかであってもよい。いくつかの実施形態では、信号品質測定基準は、複数のタイプの品質測定基準に対するスコアを含んでもよく、または複数のタイプの品質測定基準に基づいた単一のスコアを含んでもよい。いくつかの実施形態では、信号品質測定基準のスコアは正規化された値（例えば、０～１）であってもよい。

【0121】

図１７は、特定の実施形態による、ハンドオフ準備状態モデル１７０８を構築する訓練フェーズを示している。様々な実施形態では、ハンドオフ準備状態モデル１７０８は、信号品質測定基準情報１７０４および衝突事故情報グラウンドトゥルース１７０６を使用して構築される分類モデルであってもよい。

【0122】

ＭＬアルゴリズム１７０２は、信号品質測定基準１７０４および衝突事故情報グラウンドトゥルース１７０６に基づいて、ハンドオフ準備状態モデル１７０８を訓練するための任意の好適なアルゴリズムを表してもよい。ＭＬアルゴリズム１７０２は、信号品質測定基準１７０４および衝突事故情報グラウンドトゥルース１７０６の様々なインスタンスを使用して、コンテキストモデル１５０８を訓練してもよい。訓練に使用されるインスタンスは、信号品質測定基準ならびに衝突情報のセットを含んでもよい。衝突事故情報のセットは、信号品質測定基準の特定のインスタンスと関連付けられた任意の好適な安全性成果を含んでもよい。例えば、衝突事故情報のインスタンスは、自律車両が信号品質測定基準下で操作されたときに事故が起こったか否かを示してもよい。別の例としては、衝突事故情報のインスタンスは、自律車両が信号品質測定基準下で操作されたときに事故が起こりそうだったか否かを示してもよい。別の例として、衝突事故情報のインスタンスは、自律車両が信号品質測定基準下で操作されたときに、事故が起こったかまたは起こりそうだったか否かを示してもよい（例えば、起こりそうだった事故は実際の事故と同じに扱われてもよい）。様々な実施形態では、訓練データは、実際のデータ信号品質測定基準および衝突事故情報、シミュレートされたデータ信号品質測定基準および衝突事故情報、合成データ信号品質測定基準および衝突事故情報、またはそれらの組み合わせを含んでもよい。

【0123】

図１８は、特定の実施形態による、センサデータ１８０２に基づいてハンドオフ判定１８０８を決定する推論フェーズを示している。例えば、車両内コンピューティングシステムによって運転時間に実現されてもよい推論フェーズでは、センサデータ１８０２が収集され、訓練済みコンテキストモデル１５０８に提供される。コンテキストモデルは、センサデータ１５０４を分析し、センサデータ１８０２からコンテキスト１８０４を決定する。決定されたコンテキスト１８０４は、センサデータ１８０２とともに信号品質測定基準モデル１６０８に提供される。信号品質測定基準モデル１６０８は、センサデータ１８０２およびコンテキスト１８０４を分析し、コンテキスト１８０４に照らしてセンサデータ１８０２の品質に基づいて、信号品質測定基準１８０６を決定する。信号品質測定基準１８０６はハンドオフ準備状態モデル１７０８に提供され、それに基づいてハンドオフ判定１８０８が決定される。特定の実施形態では、ハンドオフ判定１８０８は、ハンドオフが安全であるか否かのバイナリ指示である。他の実施形態では、これは、３つ以上の起こり得る成果を有するマルチクラス判定であってもよい。例えば、ハンドオフ判定は、ハンドオフの安全性の異なる範囲をそれぞれ表す、任意の数の成果を示すことができる。様々な実施形態では、車両は、ハンドオフ判定１８０８の成果を利用して、ハンドオフするか否か、または部分ハンドオフを実施するか否か、例えば、一部の制御はハンドオフして他はハンドオフしないか（例えば、ステアリングのみをハンドオフしてブレーキはハンドオフしない、またはその逆）を決定してもよい。

【0124】

様々な実施形態では、推論フェーズは、周期的にもしくはトリガに応答して（または両方で）実施されてもよい。例えば、自律車両が運転制御を扱っている間、推論フェーズが周期的に実施されて、自律車両が運転制御を依然として信頼性高く扱うことができているか否かを決定してもよい。別の例として、推論フェーズは、制御を車両に移行する要求が人間の運転者から受信されると、トリガされてもよい。更に別の例として、推論フェーズは、コンテキストの変化またはセンサデータの品質の大幅な変化によってトリガされてもよい。

【0125】

特定の実施形態では、ハンドオフの先制的な計画は、車両が走行する道路の高精細度マップの利用可能性など、静的データの既知のレベルに基づく。このタイプのデータは、例えば、特定のエリアのＨＤマップデータがまだ収集されていないため、車両が走行しなければならない特定のエリアで利用不能なことがある。かかる事例では、システムは、ハンドオフを先制的に（例えば、走行の開始前に）計画し、本明細書に記載するハンドオフ技術のいずれかを使用して、運転者に前もって安全なハンドオフの準備をさせることができる。特定の例では、ハンドオフ判定を決定する推論フェーズは、車両がＨＤマップデータを有さない区域に入ると（または入る直前に）トリガされる。いくつかの実施形態では、ＨＤマップデータの利用可能性は、ＨＤマップデータが利用可能な場合は正の、または利用可能でない場合は負の影響を信号品質測定基準に及ぼす、信号品質測定基準モデル１６０８に対する入力として使用されてもよい。いくつかの実施形態では、ＨＤマップは基本的に、追加のセンサ入力として処理される。

【0126】

様々な実施形態では、図１５～図１８を参照して記載したＭＬアルゴリズムまたはモデルは、車両内コンピューティングシステム、クラウドおよび／またはフォグベースのコンピューティングリソースを使用して実現する支援システム、あるいは別のデータ処理環境など、任意の好適なコンピューティングシステムによって訓練または実施されてもよい。

【0127】

図１９は、特定の実施形態による、車両の制御をハンドオフするか否かを決定するフローを示す図である。１９０２で、車両のコンピューティングシステムは、センサデータおよびセンサデータのコンテキストに基づいて、信号品質測定基準を決定する。１９０４で、車両の制御のハンドオフと関連付けられた安全性の可能性が、信号品質測定基準に基づいて決定される。１９０６で、安全性の可能性に基づいて、ハンドオフが防止または開始される。

【0128】

自律車両は、疲労、変動する覚醒レベル、気分の変動、または他の因子など、人間に悪影響を及ぼす因子に対して免疫があることにより、運転イベントに対してより良好でより一貫した応答を有するという点で、人間の運転者を超える可能な利点を提供することが予期される。しかしながら、自律車両は、機器が故障することがあり、または自律車両が適切に動作する準備ができていない状況を経験して（例えば、自律車両は、車両アルゴリズムが訓練されていない新しい特徴を有する区域に入ることがある）、人間の運転者に対する車両のハンドオフまたは車両の退避を必要とすることがある。

【0129】

本開示の様々な実施形態では、車両を人間の運転者にハンドオフする前に、運転者の状態（例えば、疲労レベル、覚醒レベル、感情の状態、または他の状態）が分析されて、ハンドオフプロセスの安全性が改善される。準備ができていない人物に突然制御をハンドオフすることは、最近の試験車両で最近報告されている事故の数によって示されるように、全くハンドオフしないことよりも危険であり得る。

【0130】

一般的に、自律車両は外側に面するセンサを有するが、それは、知覚システムは環境をマッピングすることに集中させ、位置確認システムは、これらのセンサからのデータおよびマップデータに基づいて、自車両の場所を見つけることに集中させているためである。本開示の様々な実施形態は、運転者状態を追跡する、１つもしくは複数の車両内カメラまたは他のセンサを提供する。

【0131】

図２０は、特定の実施形態による、運転者状態モデル２００８の訓練フェーズを示している。訓練フェーズでは、センサデータ２００４および運転者状態グラウンドトゥルースデータ２００６がＭＬアルゴリズム２００２に提供され、そこで、このデータに基づいて運転者状態モデル２００８を訓練する。様々な実施形態では、運転者状態モデル２００８は、運転者の状態を記述するクラスを出力する分類モデルであってもよい。他の実施形態では、運転者状態モデル２００８は、運転者の状態に対するスコアを出力する回帰モデルであってもよい（より高いスコアはより望ましい状態を示す）。

【0132】

様々な実施形態では、センサデータ２００４は、任意の好適なセンサデータ、および／またはセンサデータから導き出される情報を表してもよい。例えば、センサデータ２００４は、車両内部の画像を獲得する１つもしくは複数のカメラから収集された画像データを含むか、またはそれに基づいてもよい。いくつかの実施形態では、１つもしくは複数のカメラ、またはカメラに結合されたコンピューティングシステムは、顔、眉毛、または目の動きを検出し、特徴を抽出して、検出された特徴によって示される疲労および覚醒度のレベルを追跡する、ＡＩアルゴリズムを実現してもよい。

【0133】

様々な実施形態では、センサデータ２００４は、赤外線カメラから収集された１つもしくは複数の温度マップを含むか、またはそれに基づいてもよい。いくつかの実施形態では、赤外線カメラまたは赤外線カメラに結合されたコンピューティングシステムは、これらの温度マップに基づいて、運転者の感情の状態または他の身体的状態を追跡する、ＡＩアルゴリズムを実現してもよい。単なる一例として、（例えば、温度マップにおいて赤色の領域の数が増加することによって示される）人間の運転者の体温の上昇は興奮状態を示してもよい。様々な実施形態では、センサデータ２００４は、ハンドル、アクセル、または運転席の触覚もしくは力覚センサから収集される圧力データを含んでもよく、あるいはそれに基づいてもよい。いくつかの実施形態では、かかる触覚または力覚センサに結合されたコンピューティングシステムは、かかる圧力データを分析して、運転者の覚醒レベルまたは他の身体的状態を追跡する、ＡＩアルゴリズムを実現してもよい。

【0134】

様々な実施形態では、センサデータ２００４は、スマートウォッチもしくはヘルストラッカーバンドなどのウェアラブルからの、心電図（ＥＫＧ）または慣性測定ユニット（ＩＭＵ）データを含むか、あるいはそれに基づいてもよい。かかるウェアラブルに結合されたコンピューティングシステム、またはウェアラブル自体が、ＡＩアルゴリズムを利用してＥＫＧの特徴を抽出して、運転者の健康状態または他の身体的状態を追跡するか、あるいはＩＭＵデータを分析して特徴を抽出して、運転者の覚醒レベルまたは他の身体的状態を追跡してもよい。

【0135】

様々な実施形態では、センサデータ２００４は、車室内マイクロフォンからの音声データを含むか、またはそれに基づいてもよい。かかるデータは、車両の乗員によって発生した音を分離するため、雑音消去技術を用いて前処理されてもよい。例えば、音声が車両内娯楽情報システムによって再生された場合、再生されている音声からの信号は、何らかの更なる処理を行う前に、車室内マイクロフォンによって獲得された音声から除去されてもよい。未加工音声の特徴は、ユーザの応答性レベル又は全体の身体的状態を計測するのに直接使用されてもよい（例えば、不明瞭な発話は酩酊を示すことがある）が、運転者状態を示す更なる特徴として使用することができる、音声イベント（例えば、笑い声、泣き声、あくび、いびき、嘔吐、または他のイベント）を分類するのにも使用されてもよい。分析された音声データは、乗員が互いに、または車両の娯楽情報システムと交わしている会話から検出された発話も含んでもよい（例えば、発話は、自動発話認識エンジンなどによってテキストに変換されてもよい）。一例として、ハンドオフに関して運転者と通信することに加えて、車両の会話システムは、差し迫ったハンドオフに対して運転者の確認を取るように試行することができる。発話はテキストに変換され、続いて高度な自然言語処理パイプライン（など）によって分析されて、発話者の意図（例えば、肯定的もしくは否定的な確認）を分類するか、対話の心情（例えば、汚い言葉などの言語材料の場合は負の心情）を分析するか、または議論されている話題をモデル化してもよい。かかる出力は続いて、運転者状態追跡アルゴリズムに対する追加の特徴として使用されてもよい。

【0136】

車両の状態に関する特徴も、運転者の現在の覚醒レベルに関する洞察を提供してもよい。例として、かかる特徴は、車両内で現在再生されている媒体（例えば、映画、ビデオゲーム、音楽）、車室内の光のレベル、運転者とダッシュボード制御との対話の量、窓の開口レベル、車室内温度制御システム（例えば、空調もしくは暖房）の状態、車両に接続されたデバイス（例えば、ブルートゥース（登録商標）を介して接続された携帯電話）の状態、あるいは他の車両状態入力のうち１つまたは複数を含んでもよい。かかる特徴は、運転者状態モデル２００８を訓練するＭＬアルゴリズム２００２に対する入力として、センサデータ２００４内に含まれてもよい。

【0137】

特定の実施形態では、活動レベルは活動分類モデルによってセンサデータから導き出されてもよい。例えば、モデルは、運転者が眠っているか（例えば、画像データで目が閉じていること、音声データでいびきが聞こえること、および体温が低下していることに基づく）、車室内の別の乗員と喧嘩しているか（例えば、声量が大きくなっている、心拍が速くなっている、侮辱的発言が交わされている）、具合が悪いか（例えば、マイクロフォンによって嘔吐音が獲得されている、および画像データに示される運転者の頭部が下がっている）否か、あるいは他の任意の好適な活動を検出してもよい。

【0138】

様々な実施形態では、未加工センサデータが訓練アルゴリズム２００２に供給されてもよい。それに加えて、または代替例として、未加工センサデータに基づいた分類がＭＬアルゴリズム２００２に供給されて、運転者状態モデル２００８を訓練してもよい。いくつかの実施形態では、上述した活動レベルは、より堅牢な運転者状態追跡結果のため、訓練アルゴリズム２００２に（任意に、より下位の特徴および／または未加工センサデータとともに）供給されてもよい。

【0139】

運転者状態グラウンドトゥルース２００６は、センサデータ２００４のインスタンスに対応する既知の運転者状態を含んでもよい。運転者状態モデル２００８が分類アルゴリズムを実現すると、運転者状態グラウンドトゥルース２００６は様々なクラスの運転者状態を含んでもよい。運転者状態モデル２００８が回帰アルゴリズムを実現すると、運転者状態グラウンドトゥルース２００６の各インスタンスは、運転者状態を示す数値スコアを含んでもよい。

【0140】

様々な実施形態では、運転者状態グラウンドトゥルース２００６およびセンサデータ２００４は、運転者に特異的であってもよく、または複数の異なる運転者に対して集約されたデータを含んでもよい。

【0141】

図２１は、ハンドオフ判定モデル２１１０の訓練フェーズを示している。ＭＬ訓練アルゴリズム２１０２は、運転者履歴データ２１０４、運転者状態２１０６、およびハンドオフ判定グラウンドトゥルース２１０８を使用して、ハンドオフ判定モデル２１１０を訓練する。代替実施形態では、ＭＬアルゴリズム２１０２は単に、運転者状態２１０６およびハンドオフ判定グラウンドトゥルース２１０８を使用して、ハンドオフ判定モデル２１１０を訓練してもよい。ハンドオフ判定グラウンドトゥルース２１０８は、実際の以前のハンドオフ判定およびそれぞれの結果（例えば、衝突事故または他の危険なイベントが起こったか否か）を含んでもよい。特定の実施形態では、ハンドオフ判定グラウンドトゥルース２１０８の全てまたはサブセットをシミュレートして、データセットが強化されてもよい。

【0142】

運転者履歴データ２１０４は、運転者の注意力のレベルを知らせてもよい、任意の好適なバックグラウンド情報を含んでもよい。例えば、履歴データ２１０４は、飲酒運転（ＤＵＩ）のインスタンス、過去の事故、運転者が取った場合によっては危険な行動のインスタンス（例えば、対向交通に逸れる、別の車両に追突するのを回避するために急ブレーキを踏む、スピード防止帯を越える）、運転者の健康状態、または他の好適なバックグラウンド情報を含む、運転者の履歴データを含んでもよい。いくつかの実施形態では、自律車両は、運転者が特別なＩＤを挿入する運転者ＩＤスロットを有してもよく、自律車両接続性システムは、運転者の関連履歴データを引き出す。運転者のバックグラウンド情報は他の任意の好適な手法で得られてもよい。

【0143】

図示される実施形態では、訓練フェーズ中、運転者の履歴データ２１０４は、運転者状態情報２１０６とともにＭＬアルゴリズム２１０２に供給されて、２つ以上のクラスを出力するハンドオフ判定モデル２１１０を構築する。一実施形態では、ハンドオフ判定モデル２１１０は、ハンドオフ、ハンドオフなし、または短期ハンドオフという３つのクラスを出力する。別の実施形態では、ハンドオフ判定モデル２１１０は、ハンドオフまたはハンドオフなしという２つのクラスを出力する。更に別の実施形態では、クラスの１つは部分ハンドオフであってもよい。様々な例として、「ハンドオフ」のクラスは、ハンドオフが高い信頼レベルで実施されてもよいことを示してもよく、「ハンドオフなし」のクラスは、低い信頼レベルを示してもよく、また車両による制御の継続が望ましくない状況では、運転者の準備ができるかまたは自動車が安全に停車されるまで、ハンドオフは自動車の制御をテイクオーバする遠隔監視システムにしたがってもよく、「短期ハンドオフ」のクラスは、運転者の中間の信頼レベルを表してもよく、いくつかの実施形態では、制御が期限付きで運転者にハンドオフされてもよく、その期限内で自動車は停車させられる（例えば、自動車は、自動車を制御するかもしくは自動車の格納場所を提供してもよい、通信システムなどの待機ユニットによって安全に停車されてもよい）。別の実施形態では、「部分ハンドオフ」は、運転者の中間の信頼レベルを表してもよく、制御の一部分のみ（例えば、ブレーキ制御のみ、またはステアリング制御のみ）が運転者に渡されてもよい。一実施形態では、「条件付きハンドオフ」は、運転者の中間の信頼レベルを表してもよく、ハンドオフを運転者に渡し、運転者の行動および／またはユーザの状態を監視して、車両が安全に操作されていることを確保してもよい。上記は可能性があるハンドオフクラスの例を表しているだけであり、ハンドオフ判定モデル２１１０は上述のハンドオフクラスまたは他の好適なハンドオフクラスの任意の組み合わせを出力してもよい。

【0144】

様々な実施形態では、車両の外向きのセンサを介して検出されたコンテキストはまた、ハンドオフをうまく取り扱う運転者の能力を評価するのに考慮に入れられてもよい。例えば、気象条件、視認性条件、路面条件、交通条件、または他の条件が、ハンドオフに望ましい覚醒レベルに影響を及ぼすことがある。例えば、条件が厳しい場合、運転者にハンドオフする前に異なる意識レベルが求められることがある。これは、コンテキスト情報を機械学習アルゴリズム２１０２に供給することによって、または他の任意の好適な手法で実現されてもよい。

【0145】

図２２は、特定の実施形態による、ハンドオフ判定２２０８を決定する推論フェーズを示している。上述したようなセンサデータ２２０２は、運転者状態２２０４を出力する運転者状態モデル２００８に提供される。運転者状態２２０４および履歴データ２２０６はハンドオフ判定モデル２１１０に提供され、それが、上述したようなハンドオフ判定２２０８または別の好適なハンドオフ判定を出力する。他の実施形態では、ハンドオフ判定モデルは他の因子（例えば、１つもしくは複数の外側に面するセンサから決定された運転状況のコンテキスト）を考慮するか、または履歴データ２２０６を省略してもよい。

【0146】

推論フェーズは、任意の好適なトリガに応答して実施されてもよい。例えば、推論フェーズは、車両自体が許容可能な安全性レベルで独立して動作することができないという決定に応答して、実施されてもよい。別の例として、推論フェーズは、人間の運転者が車両を操作している間、周期的に実施されてもよく、推論フェーズの成果は、運転者が車両を操作するのに適合しているか否かの決定であってもよい。運転者が適合していない場合、車両は、運転制御の全てもしくは一部の制御をテイクオーバしてもよく、警報を運転者に提供してもよく、あるいは運転者の覚醒度を増大させる行動（例えば、大音量の音楽を流す、窓を開ける、運転席もしくはハンドルを振動させる、または他の好適な行動）を取ってもよい。

【0147】

システムが人間の運転者にハンドオフすると決定すると、運転者には差し迫ったハンドオフが通知される。それを行うため、システムは、いくつかの可能な手法のうち１つまたは複数で運転者に関与してもよい。例えば、システムは言葉によって運転者に関与してもよい。例えば、意味論および構文が適正なテキストが、自然言語生成エンジンによって構築され、次にテキスト音声化エンジンによって合成発話音声に変換されて、ハンドオフを記述する言語メッセージが作成されてもよい。別の例として、システムは物理的に運転者に関与してもよい。例えば、運転席またはハンドルに搭載されたモータは、運転者を驚かせて事故につながらないように運転者の安全性を考慮して、座席またはハンドルを激しく振動させてもよい。他の実施形態では、システムは、任意の好適な手法で運転者に関与して、ハンドオフを通信してもよい。

【0148】

図２３は、特定の実施形態による、ハンドオフ判定を生成するフローを示している。２３０２で、センサデータが、車両内部に位置する少なくとも１つのセンサから収集される。２３０４で、センサデータが分析されて、車両内部の人物の身体的状態が決定される。２３０６で、その人物の身体的状態に少なくとも部分的に基づいて、その人物が車両を安全に操作することができると予期されるか否かを示す、ハンドオフ判定が生成される。

【0149】

本明細書で考察するように、いくつかの自律運転システムは、自律車両から車両内の人間のユーザへの、または遠隔の場所（例えば、遠隔バレットアプリケーション）での制御の移行を支援する機能性を装備してもよい。いくつかの実現例では、自律運転システムは、異なる条件および状況下で、乗員および道路両方の安全性を強化する目的で、乗員（ＥＧＯ）から自律（エージェント）自動車への、または逆の制御の円滑な移行のため、論理ベースのフレームワークを採用してもよい。このフレームワークの少なくともいくつかの態様は、（例えば、ＦＰＧＡ、Ｈａｄｏｏｐクラスタなどを通して）自律運転システムのハードウェア上で実現されるものとして並列化されてもよい。

【0150】

例えば、一例のフレームワークは、自律車両または人間の運転者のどちらかが車両を制御し、両当事者間でこれらの制御要求を実現するメカニズムを提示するのにより安全である、異なる状況を考慮してもよい。一例として、より安全な運転のために自律車両が車両の制御を取り戻すことを望む条件があってもよい。自律車両は、運転者の意識状態を感知（例えば、運転者が通話に気を取られているか、もしくは眠気／気怠さを感じているか否かを決定）し、運転者の意識に基づいて制御をテイクオーバするか否かを決定するのに使用されてもよい、カメラまたは他の内部センサ（例えば、マイクロフォン）を装備してもよい。自律車両は、センサデータを分析し（例えば、自動車内部からのカメラおよびマイクロフォンデータに対して行われる分析）、運転者の意識レベルが低いか、または運転者が別の理由で安全ではないとみなされる場合（例えば、飲酒運転、手放し運転、ハンドルの後ろで眠っている、メールを打ちながらの運転、危険運転など）、あるいは自律車両が自動車内の何らかの異常行動（例えば、喧嘩、もしくは叫び声、または人間の運転者もしくは乗員による他の安全ではない運転挙動）を感知した場合、制御を要求して運転者からテイクオーバする、メカニズムを含んでもよい。このように、自律車両の内部および外部両方における人物の安全性が強化されてもよい。

【0151】

いくつかの実現例では、認証ベースの（例えば、生体認証を使用する）コマンド制御が、自律自動車の無断使用を防止するのに利用されてもよい。一例として、いくつかの実施形態では、自律車両が盗まれるかまたは悪人の手に渡ったとき、自律車両はこのシナリオを検出し、制御されないように自身でロックすることができてもよい。例えば、生体認証（例えば、指紋、声および顔認識、運転免許証など）を使用して、自律車両の制御を要求するユーザを認証する認証メカニズムが、自律車両に含まれてもよい。これらのメカニズムは、自律車両の未認証使用を防止してもよい。いくつかの事例では、自律車両またはその態様の使用は、異なる承認レベルに基づいて提供されてもよい。例えば、あるユーザは、どこでも自動車を手動で完全に制御することができてもよく、別のユーザは、特定の地図上で限定された場所でしか自動車を制御することができなくてもよい。別の例として、いくつかの実施形態では、乗員は、非常に混雑した道路、悪天候、センサ（例えば、カメラ、ＬＩＤＡＲ、レーダなど）の故障など、特定の状況に遭遇したとき、自律車両の制御を要求してもよい。要求に応答して、自律車両は、ユーザの生体認証の１つまたは複数に基づいてユーザを認証してもよく、認証された場合、自律車両の制御をユーザに渡してもよい。別の例として、いくつかの実施形態では、エンティティ／ユーザ（例えば、警察、第１対応者、政府職員など）が自律車両を遠隔で制御したい場合、自律車両は、制御をそのエンティティ／ユーザに移行する前にユーザを有効にしてもよい。

【0152】

いくつかの実施形態では、例えば、自律車両が危険な運転をしているかまたは他の自動車の挙動モデルの許容可能な限界内にないと、周囲の自律車両が考えた場合、自律車両の制御は、複数の周囲の自動車（警察車両を含む）またはインフラストラクチャベースのセンサ／コントローラにクラウドソーシングされてもよい。かかる例では、制御を要求する人間の生体認証を通して、または自律車両／インフラストラクチャセンサのデジタルセキュリティ情報（例えば、デジタル証明）によってなど、制御を要求するエンティティが認証されてもよい。

【0153】

図２４は、少なくとも１つの実施形態による、上述のフレームワークの上位ブロック図を示している。例えば、シナリオ２４０２で、自律車両が（例えば、自律車両内部からのカメラまたはマイクロフォンデータを介して）安全でない運転条件（例えば、図２４に列挙されるものもしくは他の安全でない条件）を検出したとき、自律車両は人間運転／手動動作モードで動作しており、したがって制御を自律車両に戻して自律運転モードを続ける。このシナリオでは、自律車両は、制御を取り戻す前に、車両の制御を取り戻すように運転者に要求を提示してもよい。

【0154】

シナリオ２４０４で、運転者が自律動作モードを続けることを快適に感じない状況（例えば、図２４に列挙されるもの、もしくはその他）を運転者が特定したことなどに応答して、人間の運転者が自律車両の制御を要求する。自律車両は、２４０５で、例えば、それに応答して、生体認証または他の認証方法を使用して、人間の運転者を認証する認証要求を開始してもよく、また有効性が認証されると、制御を自律車両から人間の運転者に渡してもよい（そうでなければ、自律車両が制御を保持する）。

【0155】

シナリオ２４０６で、例えば、自律車両による安全でない運転が観察されたことによって、自律車両が盗まれたと報告されていることによって、混雑／道路制御の目的で自律車両を移動する必要があることによってなど、警察官または近隣の自律車両が自律車両の制御を要求してもよい。自律車両は、２４０７で、それに応答して、要求している人物／エンティティを認証する認証要求を開始してもよく、それに応答して、また有効性が認証されると、制御を自律車両から警察官／近隣の自律車両に渡してもよい（そうでなければ、自律車両が制御を保持する）。

【0156】

図２５は、少なくとも１つの実施形態による、自律車両のテイクオーバを制御する一例のプロセスの図である。例示のプロセスの動作は、自律車両の態様または構成要素によって実施されてもよい。例示のプロセス２５００は、追加のまたは異なる動作を含んでもよく、動作は、図示される順序または別の順序で実施されてもよい。いくつかの事例では、図２５に示される動作の１つまたは複数は、複数の動作を含むプロセス、サブプロセス、または他のタイプのルーチンとして実現される。いくつかの事例では、動作は、組み合わせるか、別の順序で実施するか、並行して実施するか、反復するか、または別の方法で繰り返すかもしくは別の手法で実施することができる。

【0157】

２５０２で、自律車両は自律モードで操作され、それによって自律車両は、自律車両の動作の多くまたは全ての態様を制御している。

【0158】

２５０４で、自律車両は、自律車両の制御をテイクオーバする要求を別のエンティティから受信する。エンティティとしては、自律車両の人間の乗員／運転者、自律車両から遠隔にいる人物（例えば、警察官もしくは政府職員）、あるいは自律車両の付近にいる別の自律車両または複数の自律車両（例えば、クラウドソーシング制御）を挙げることができる。

【0159】

２５０６で、自律車両は、制御を要求するエンティティを認証するのに、エンティティの認証情報をプロンプトする。プロンプトは、指紋、声認識のための声サンプル、顔認識のための顔サンプル、または別のタイプの生体認証など、生体認証のプロンプトを含んでもよい。プロンプトは、ユーザ名、パスワードなど、他のタイプの認証情報のプロンプトを含んでもよい。

【0160】

２５０８で、自律車両は、要求しているエンティティから入力を受信し、２５１０で、受信した入力に基づいて、エンティティが認証されるか否かを決定する。エンティティが認証された場合、自律車両は、２５１２でテイクオーバを許可し、要求しているエンティティに制御を渡す。入力に基づいてエンティティが認証されない場合、自律車両は、２５１４でテイクオーバ要求を拒否し、自律動作モードで動作を続ける。

【0161】

図２６は、少なくとも１つの実施形態による、自律車両のテイクオーバを制御する別の一例のプロセスの図である。例示のプロセスの動作は、自律車両の態様または構成要素によって実施されてもよい。例示のプロセス２６００は、追加のまたは異なる動作を含んでもよく、動作は、図示される順序または別の順序で実施されてもよい。いくつかの事例では、図２６に示される動作の１つまたは複数は、複数の動作を含むプロセス、サブプロセス、または他のタイプのルーチンとして実現される。いくつかの事例では、動作は、組み合わせるか、別の順序で実施するか、並行して実施するか、反復するか、または別の方法で繰り返すかもしくは別の手法で実施することができる。

【0162】

２６０２で、自律車両は手動／人間運転の動作モードで操作され、それによって（自律車両の内部または自律車両から遠隔にいる）人間が自律車両の動作の１つまたは複数の態様を制御している。

【0163】

２６０４で、自律車両は、自律車両の内部に位置する１つまたは複数のセンサからセンサデータを受信し、２６０６で、センサデータを分析して、人間の操作者からの入力が安全か否かを決定する。入力が安全であると決定された場合、自律車両は、手動動作モードで動作し続ける。入力が安全ではないと決定された場合、自律車両は、２６０８で、人間の操作者からの制御テイクオーバを要求し、２６１０で、自律動作モードで自律車両を操作する。

【0164】

レベル２（「Ｌ２」または「Ｌ２＋」）の自律車両から完全自律のレベル５（「Ｌ５」）の自律車両への移行には数年かかる可能性があり、自律車両業界は、あらゆる場所での完全自律状態（運転者なし）に達するまで、人間の運転者の役割から責任を徐々に移行するのを観察することができる。機械制御（自律モード）から人間制御（人間運転モード）への安全なテイクオーバの実現は、この移行フェーズにおいて重要であるが、いくつかの課題がある。例えば、可能性がある課題の１つは、自律システムからの要求なしに起こる、人間の運転者による無作為の介入を制御することである。別の課題は、イベント駆動の介入によって生じる。自律車両で起こり得る３つのタイプのテイクオーバには以下のようなものがある。

【0165】

車両要求によるテイクオーバ：車両が運転者のテイクオーバを要求し、自律モードから人間運転モードに渡す場合。これは、いくつかの事例では、最良の判定に何らかの不確実性があるとき、または車両が地図上で限定された領域から出ていくときなど、自律車両がその知覚システムにとって新しい状況に面したときに起こることがある。人間のテイクオーバを要求する一般的方策は、１つまたは複数の手法（例えば、ダッシュボードに現れるポップアップメッセージ、ビープ音、もしくはハンドルの振動）によって運転者に警告することによる。人間の運転者がテイクオーバを受け入れていても、人間の反応時間が予期されるよりも長くかかること、人間が集中していないこと、または他の理由によって、テイクオーバに何らかの誤りが起こることがある。

【0166】

人間の運転者による無作為のテイクオーバ：テイクオーバの可能性は、人間の運転者によって無作為に（例えば、車両からの要求なしに）、予測できない理由で起こる場合がある。例えば、人間の運転者は気が散っていることがあり、または意図しない眠りから覚めて不適切に反応する（十分に意識せずに急にハンドルを制御する）ことがある。別の例として、人間の運転者は、急いでいて（例えば、飛行機の便もしくは重要なイベントに間に合わせるため）、自律モードの車両速度に満足していないことがあり、そのため制御をテイクオーバして加速することがある。これらのタイプの無作為のテイクオーバは、かかる予測できないテイクオーバに対して運転規則／方針を整備することは実現不可能なので、望ましくないことがあり、無作為なテイクオーバ自体が事故／衝突事故につながることがある。

【0167】

人間によるイベント駆動のテイクオーバ：テイクオーバの別の可能性は、予測できないイベントによって人間によって起こる場合がある。例えば、人間の運転者は急に車を降りる必要を感じることがある（例えば、閉所恐怖症、具合が悪いなど）。別の例として、人間の運転者と同乗している乗員が急に高リスクのシナリオに入り込むことがあり、人間の運転者が自動車を停車するためにテイクオーバすることがある。別の例として、人間の運転者が走行している道路を不快に感じて（例えば、暗い知らない道路）、制御を行って気分をより快適にする必要性がトリガされることがある。これらのタイプのテイクオーバは、自律運転モードを予測できない方法で妨げる可能性があるので望ましくないことがあり、テイクオーバ自体が事故／衝突事故につながることがある。上述の事例と同様に、このタイプのテイクオーバも、かかる予測できないテイクオーバに対して運転規則／方針を整備することは実現不可能なので、望ましくないことがあり、予測できないイベントによって駆動されるテイクオーバは安全ではない可能性が高い。

【0168】

これらのタイプのうち、無作為およびイベント駆動のテイクオーバは、安全ではないとみなされることがあり、したがって、自律運転システムは、これらのタイプのテイクオーバを検出し制御するように具体的に構成されてもよく、それによって自律運転モード中のより安全な運転および予測できない挙動の回避を可能にしてもよい。特定の実施形態では、これらの場合によっては安全ではないテイクオーバ状況を軽減するため、
自律運転知覚フェーズ（例えば、車両内知覚ソフトウェアスタックにおいて実現されるような）は、リアルタイムで安全ではないテイクオーバを検出するためのソフトウェアモジュールを含むように拡張されてもよい。
自律運転行動フェーズ（例えば、車両内システムにおいて実現される車両制御ソフトウェアおよびハードウェア）は、リアルタイムで検出された安全ではないテイクオーバを軽減するためのソフトウェアモジュールを含むように拡張されてもよい。
自律運転計画フェーズ（例えば、ルート計画サブシステム）は、軽減を実行する手段として、乗員または運転者が快適ではない状態を回避するため、可能性があるルート変更または自律運転モードに対する他の調節を考慮することを含むように拡張されてもよい。

【0169】

図２７は、少なくとも１つの実施形態による、自律車両に対する一例の知覚、計画、および行動の自律運転パイプライン２８００の図である。特に、図２７は、場合によっては安全ではないテイクオーバをリアルタイムで検出し軽減する、自律車両の知覚および制御における特定の考慮点の概要を示している。知覚、計画、および行動パイプラインの動作は、自律車両の車両内制御システムによって実施されてもよい。図示されるように、例示の知覚、計画、および行動パイプラインは、感知／知覚フェーズ、計画フェーズ、および行動／制御フェーズを含む。

【0170】

図示される例では、制御システムは、車両知覚センサ（例えば、カメラ、ＬＩＤＡＲなど）および車両制御要素（例えば、ハンドルセンサ、ブレーキ／アクセルペダルセンサ、内部カメラ、内部マイクロフォンなど）を含む、自律車両に結合された複数のセンサからセンサデータを受信する。制御システムは、感知／知覚フェーズでセンサデータを使用して、自律車両の人間の運転者による安全ではないテイクオーバ要求を検出する。安全ではないテイクオーバの検出は、受信したセンサデータの少なくとも一部分に基づいてもよい。例えば、安全ではないテイクオーバは、テイクオーバの行動を感知する、アクセルペダル、ブレーキペダル、および／またはハンドルに結合されたセンサに基づいて検出されてもよい。いくつかの事例では、自動車内部のカメラおよび／またはマイクロフォンが（例えば、人工知能とともに）使用されて、運転者の行動が自律車両の制御をテイクオーバするものであることを検出してもよい。いくつかの実施形態では、ペダル／ハンドルセンサから、および車両内カメラからのデータが相関されて、人間によるテイクオーバ要求の可能性を検出し、行動が実際に要求されたテイクオーバであるか否かを決定してもよい。例えば、急に目が覚めたまたは気が散った運転者が、制御の無作為のテイクオーバを開始する意図がないまま、ブレーキ、アクセル、またはハンドルの１つもしくは複数を作動させることがある。

【0171】

要求されたテイクオーバが安全ではないことが検出された後、制御システムは、安全ではないテイクオーバ要求を軽減する。これは、例えば、人間の運転者が自律車両を制御することが許可されないように、テイクオーバ要求を阻止することを含む場合がある。例えば、ハンドル、ブレーキアクチュエータ／ペダル、およびアクセルアクチュエータ／ペダルは、自律運転モードの間はロックされてもよく、自律車両が人間によるテイクオーバを要求したときのみロック解除されてもよい（後述するように、無作為のテイクオーバ要求が安全であることの検出に応答してもよい）。更に、いくつかの事例では、ドアロック解除は、車両が停車状態にある（移動していない）ときのみ使用可能にされてもよいので、安全ではないテイクオーバ要求に応答してドアはロックされたままであってもよい。

【0172】

いくつかの事例では、安全ではないテイクオーバ要求の軽減は、運転者／乗員の要望に合致するように自律運転モードを修正することを含んでもよい。例えば、制御システムは、運転者／乗員の快適さを担保し、テイクオーバ要求によって導入される乗員／運転者に対するリスクを最小限に抑えるように、自律車両のルート（例えば、方向、速度など）を再計画してもよい。いくつかの事例では、制御システムは、人間の運転者および／または乗員に、テイクオーバ要求に応答して（例えば、声によるプロンプト（声認識対応自律車両の場合）および／またはテキストプロンプトを使用して）入力するようにプロンプトしてもよく、運転者／乗員から受信した入力に基づいて、自律モードの１つまたは複数の態様を修正してもよい。

【0173】

図２８は、少なくとも１つの実施形態による、自律車両の人間の運転者によるテイクオーバ要求を制御する一例のプロセスの図である。特に、図２８は、安全ではないテイクオーバの検出および軽減スキームを示している。例示のプロセスの動作は、自律車両の構成要素（例えば、自律車両の制御システム）によって実施されてもよい。例示のプロセス２８００は、追加のまたは異なる動作を含んでもよく、動作は、図示される順序または別の順序で実施されてもよい。いくつかの事例では、図２８に示される動作の１つまたは複数は、複数の動作を含むプロセス、サブプロセス、または他のタイプのルーチンとして実現される。いくつかの事例では、動作は、組み合わせるか、別の順序で実施するか、並行して実施するか、反復するか、または別の方法で繰り返すかもしくは別の手法で実施することができる。

【0174】

２８０２で、自律車両は自律運転モードで動作している。例えば、自律車両の制御システムは、知覚、計画、および行動パイプラインを通してなど、自律車両の動作の１つまたは複数の態様を制御していてもよい。２８０４で、自律車両は（例えば、制御システムに渡されたセンサデータに基づいて）、非正規または未知の状況に遭遇しているか否かを決定する。遭遇している場合、２８０６で、自律車両は、人間の運転者が自律車両の制御をテイクオーバすることを要求し、２８０８で、自律車両は（人間の運転者が自律車両を制御する）人間運転動作モードに入り、それで動作する。自律車両は次に、人間運転動作モードの間、２８１０で、正規／既知の条件に遭遇しているか否かを決定してもよい。遭遇している場合、自律車両は、２８１２で、自律車両の制御のテイクオーバまたは制御の取戻しを要求してもよく、自律動作モードに再び入ってもよい。２８０４で非正規／未知の状況に遭遇していない場合、自律車両は、自律運転モードで動作し続け、それにより、非正規／未知の状況に遭遇しているか否かを継続して決定してもよい。

【0175】

２８１４で、自律車両は、人間の運転者によるテイクオーバ要求を検出する。テイクオーバ要求は、自律車両の内部に位置するセンサ（例えば、ハンドル、ブレーキアクチュエータ、アクセルアクチュエータ、または内部カメラもしくはマイクロフォンに結合されたセンサ）を含んでもよい、自律車両に結合された１つまたは複数のセンサからのセンサデータに基づいてもよい。

【0176】

２８１６で、自律車両は、テイクオーバ要求が安全ではないか否かを決定する。安全ではない場合、自律車両は、それに応答して安全ではないテイクオーバ要求を軽減してもよい。例えば、２８１８で、自律車両はテイクオーバ要求を阻止してもよい。それに加えて、自律車両は、２８１８で、テイクオーバ要求の原因または非正規の状況に関してより理解するため、運転者に入力するようにプロンプト（例えば、声認識ソフトウェアを使用して、運転者と会話できるようにする）してもよい。

【0177】

２８２０で、運転者から受信した入力に基づいて、自律車両は、運転者がどんな状況にあるか、または運転者がテイクオーバ要求を開始する理由を決定する。例えば、運転者または乗員にとってのリスクである（例えば、叫び声、安全ではない挙動など）状況が特定された場合、ルートに関して再計画を考慮するのが必要なことがあるので、自律車両は、２８２２で、退避して停車するように自律運転モードを修正してもよい。例えば、運転者および／または乗員にとって自律運転モードが不快であるという状況（例えば、未知のルート／道路、非常に暗い環境など）が特定された場合、自律車両は、２８２４で、より多くの視覚情報が運転者／乗員に対して表示されて（例えば、（追加して）ルートの詳細を表示し、自律車両は車内灯も調節して、運転者が追加情報を見ることを可能にしてもよい）、運転者および／または乗員が自律運転モードでより快適になるのを助けるように、自律運転モードを修正してもよい。例えば、速度に関して不満がある（例えば、運転者が自律車両を減速もしくは加速させたい）状況が特定された場合、計画フェーズは別の速度および／またはルートを考慮してもよく、自律車両は、速度（もしくはルート）を変更するように自律運転モードを修正してもよい。受信した運転者入力に応答して、他の軽減策が用いられてもよい。

【0178】

自律車両の利益の可能性の１つは、より安全な運転環境の可能性である。しかしながら、エラーのない自動化システムを作成する最善の努力にかかわらず、車両の摩損によって引き起こされる機械的、物理的、および／または電子的損傷は不可避である。かかる損傷は自律車両の誤作動を引き起こすことがある。

【0179】

不可避的に、自律車両が、特にそのセンサが損傷すると、車両の機能が低下する場合がある。自律車両の自動化レベルは、図２９に示されるように、人間の運転者が求められる参加の量に関連して定義される。自律車両が問題に遭遇したとき、人間の乗員（もしくは遠隔監視エンティティ）が運転制御をテイクオーバすることが求められることがあり、または車両が動作を停止することがある。

【0180】

更に、車両に問題がある場合、その問題が、センサの問題点、プロセッサもしくはメモリの誤作動、または他のいずれかのハードウェア／ソフトウェアの問題点であるか否かにかかわらず、事故が起こる可能性が増加する。これは、特に運転者がテイクオーバの準備ができていない場合に、人間の運転者が車両の制御をテイクオーバさせられる場合にも当てはまる。車両に何が起こっているかを追跡する能力は、多くの当事者にとって非常に重要であると示すことができる。例えば、保険会社、運転者、または車両のメーカーは、様々な責任問題に関して利益を得ることができる。更に、車両の設計者は、重要な状況で何が起こるかを理解することによって利益を得ることができる。

【0181】

包括的認知監督システム３０００が図３０に示されている。システム３０００は、運転条件の継続分析、ならびに自律車両の、特に自律車両の感知、計画、および行動層の精度に基づいて、車両の自律レベルを監督し調節するように、論理によって構成されたコンピューティングシステム（本明細書で考察するコンピューティングシステムのサブシステムまたは実現例）である。システム３０００は、人間の運転者を監視し、警告し、再び関与させることによって、また人間の運転者に対する運転制御の安全なハンドオフを実施することによって、自律車両で生じることがある問題を取り扱う、マルチレベルスマートメカニズムを備えることができる。システム３０００はまた、自律車両の遠隔監督および／または制御を可能にするように構成することができる。システム３０００はまた、自律車両の自律レベルを低減し、それによって、車両のセンサもしくは構成要素が故障した状況、または車両が取り扱えない他の状況において人間の運転者により大きく依存する、システムとみなすことができる。

【0182】

システム３０００は、自律車両の自律レベルを監視することができる。更に、システムは、自律レベルが適正か否かを決定することができ、適正でない場合、車両の自律レベルを変更することができる。それに加えて、変更が必要な場合、システム３０００は運転者に変更を警告することができる。システムはまた、遠隔サーベイランスシステム３０１０に変更を警告することができる。

【0183】

包括的認知監督システム（Ｃ２Ｓ２）３００５は、自律車両の正規自動化システムの上位に位置してもよい（例えば、監督してもよい）。一例では、システム３００５は、車両のセンサ（３０２０）、計画（３０３０）、および実行（３０４０）システムの上位に位置する。いくつかの実現例では、Ｃ２Ｓ２は、自律車両の車両内コンピューティングシステムのより多数の上位に位置するか、またはそれらと共同機能することができることが注目されるべきである。特に、Ｃ２Ｓ２は、車両の自律レベルに影響を及ぼすことがある、いずれかのシステムの上位に位置することができる。システム３００５はまた、自律運転レベルおよびセンサ健全性監視の履歴を記録してもよい。収集されたデータは、何か誤作動または事故が起こった場合に参照することができるように、非常に簡潔でオフラインアクセス可能であってもよい。

【0184】

いくつかの例では、Ｃ２Ｓ２ ３００５は、自動車の自律レベルを監視するように実行可能な論理を含み、機能的保証、品質保証、および安全性保証の３つの主要モジュールを備える。これらの主要モジュールはそれぞれ、車両に対して設定された現在の自律状態を許容または拒絶する、既定の重要業績評価指標（ＫＰＩ）セットを有することができる。Ｃ２Ｓ２が、監視されているモジュールのいずれかにより、自律レベルが許容可能ではないと決定した場合、Ｃ２Ｓ２は、車両の自律レベルを変更する能力を有することができる。更に、システムは人間の運転者に変更を通知する。自律レベルを変更する能力は非常に有益であり得る。例えば、何らかのセンサ故障がある場合に、車両の自律を完全に止める代わりに、Ｃ２Ｓ２は、自律を完全に除去するのとは反対に自律レベルを下げることができると決定することができる。これは、車両が（例えば、図３１に示されるような）Ｌ４からＬ３レベルになることを意味してもよい。かかる変更は、人間の運転者が車両の制御に関与するのを要しないことがあるが、いくつかの実施形態では、自律の変更が運転者に通信されて、運転者が必要とされる場合に運転者がより深く注意を払うことを可能にしてもよい。

【0185】

引き続き図３０の例を参照すると、Ｃ２Ｓ２ ３００５は、３つのシステム（センサ３０２０、計画３０３０、および実行３０４０）の３つの主要ブロック（機能的保証、品質保証、および安全性保証）それぞれのＫＰＩを評価する。Ｃ２Ｓ２ ３００５がシステムに何らかの問題があると検出した場合、自律レベルを変更する必要があるか否かを評価することができる。必ずしも全ての問題が自律レベルの変更を要しないことがある。例えば、車両は、センサの１つに問題を有することがある。しかしながら、このセンサが別のセンサと比べて反復データを作成する場合、車両は現在の自律レベルを維持する能力を失わないことがある。

【0186】

他の例では、しかしながら、センサの問題点が問題を引き起こす場合がある。メーカーはＬ４自律レベルが可能な特定の車両を導入しているが、かかる指定は実際は条件付きであり、車両の自律能力は時間に伴って変動することがある。例えば、センサ／構成要素の故障のようなシナリオで、センサが使用不能になるかまたは乗員の安全性が損なわれると、自律レベルを変更しなければならないことがある。Ｃ２Ｓ２ ３００５は、自律レベルを変更し、運転者および遠隔サーベイランスシステム（３０１０）の両方に通知することができる。

【0187】

自律レベルの監視および変更に加えて、Ｃ２Ｓ２ ３００５はまた、遠隔サーベイランスシステム３０１０に行動を報告し返すことができる。Ｃ２Ｓ２ ３００５は自律レベルの変更を報告することができるだけでなく、Ｃ２Ｓ２ ３００５は、任意の重要なデータを遠隔システム３０１０に報告することができる。例えば、必要な自律レベルの変更がある状況では、または更には自律車両が関わる事故がある状況であっても、レベル変更、および車両の移動、計画、自律レベルなどに関するデータの完全な記録を、サーベイランスシステム３０１０に送り、そこで格納することができる。かかるデータは、事故の過失、改善のためのデータなどを決定するのに有用であり得る。獲得することができるいずれのデータも、所望であれば、遠隔サーベイランスシステム３０１０に送ることができることが想到される。

【0188】

図３０に記載されるシステムは、特定の実施形態でもたらされることがあるモジュールの単なる代表例である。他の実施形態は、本明細書では具体的に言及しない追加のモジュールを備えてもよい。それに加えて、必ずしも全てのモジュールが必要ではなく、または他の実施形態では、モジュールが組み合わされてもよい。

【0189】

自律車両によって完全に人間がいらない運転体験を提供することが理想的であり得るが、自律車両の自律レベルに応じて、車両が動作中の間、人間の運転者による何らかの対話を有するのが必要なことがある。これは特に、人間の運転者が制御をテイクオーバするのが必要なことがある、緊急時に当てはまる。かかる状況では、人間の運転者への一般的なハンドオフは、成功した場合、平均で約３秒間かかることがある。しかしながら、人間は、注意散漫な場合が多く、簡単に気が散り、特定の状況に応答するのが遅い場合が多い。そのため、迅速で安全なハンドオフを達成するためには、車両が自律モードで動作している間、運転者を関与させ続けるのは困難な場合がある。

【0190】

したがって、少なくともいくつかの状況では、ある人物が自律車両のハンドオフに関するバックアップとして信頼できないことがある。ある人物が十分迅速に反応できない場合、可能性がある危険な状況が、適時に反応できない注意散漫な運転者によって更に悪化する場合がある。上述のシステムの様々な実現例は、自律運転者と人間の運転者との間のハンドオフを行う、より安全な手法を提供してもよい。

【0191】

図３２は、Ｌ４自律レベルで動作している自律車両におけるデータの構造的フローの一例を示している。図３２の例示のフローは、感知モジュール３２１０と、計画モジュール３２２０と、行動モジュール３２３０と、ドライブバイワイヤ（「ＤＢＷ」）モジュール３２４０とを含む。一例として、感知モジュール３２１０は、様々な知覚センサ（例えば、カメラ、レーダ、ＬＩＤＡＲ、ＧＰＳなど）からのデータの処理に関与することができる。感知モジュール３２１０はセンサ２２５の任意の好適な特性を有してもよい。感知モジュールによって出力されるデータは、車両の運動パラメータ（例えば、速度、位置、向きなど）を表すことができ、車両の周りの物体を表すデータとともに、計画モジュール３２２０（本明細書のいずれかの箇所で考察されるものなど、経路プランナモジュール（例えば、２４２）の任意の好適な特性を有してもよい）に渡すことができる。計画モジュール３２２０は、現在の状況に基づいて、運転中に路上で取られる行動についての関連する判定を行うことができる。計画モジュールによる判定は、コントローラを備えることができる行動モジュール３２３０に通信されて、ＤＢＷモジュール３２４０に与えられる特定の車両コマンドを生成することができる。かかるコマンドは、例えば、特定のステアリング角、および／または加速に対するコマンドを含むことができる。これらのコマンドは次に、ＤＢＷモジュールによって実行される。上述のフローは単なる例示であり、他のフローが存在してもよいことが注目されるべきである。それに加えて、異なる車両には異なるレベルの知能が存在することが可能である。例えば、Ｌ２定格車両は、Ｌ４定格車両とは異なるレベルの知能を有するであろう。

【0192】

現在、図３２の例におけるモジュールレベルの１つに故障がある状況では、または車両の計画アルゴリズムが特定の運転シナリオの行動を取ることができない場合、車両は自動的に、運転者がテイクオーバする必要があることを示す信号を運転者に送る。この信号は、視覚、音声、またはそれらの組み合わせであることができる。図３３は、運転者に対する映像信号の一例を示している。

【0193】

図３４は、一例の自律車両ハンドオフ状況のフローを示している。図から分かるように、フローの開始時、３４１０で、車両は自律モードであってもよい。問題が認識され、自律レベルを変更する必要があると、３４２０で、テイクオーバ信号が送られる。最後に、３４３０で、自律モードが不活性化される。

【0194】

急激でも突然でもないハンドオフプロセスは、運転者が必要に応じて車両に関与する助けとなる。それに加えて、センサが機能停止した場合に、車両が完全に非自律になる必要はないことがある。単に自律レベルを下げるのが安全なことがある。例えば、Ｌ４モードで動作している自律車両の場合、車両が人間の運転者に直接ハンドオフし、その自律を停止する必要はないことがある。計画アルゴリズム（例えば、計画モジュール３２２０によって実施される）は複数のセンサ入力に依存している。自律システムの信頼性は、これらのセンサ入力に基づいて計画アルゴリズムが判定を行うことができる正確性によって定義される。全てのシステムが、計画モジュールによって行われる判定の信頼度レベルを定義する、重要なセンサ入力および重要でないセンサ入力の独自のセットを有する。Ｌ４レベル車両は、そのセンサのサブセット（主に冗長センサ）が動作を停止した場合、同じ信頼度レベルで動作することはできなくなる。一例の状況では、車両は、単純に信頼度レベルをＬ４から、運転者によるより高い注意レベルを要するＬ３に降格させてもよい。しかしながら、運転者が完全にテイクオーバし、車両が自律システムを遮断する必要はないことがある。

【0195】

図３５は、自律車両の制御を人間の運転者にハンドオフするフローの一例を示している。それに加えて、図３５は、人間の反応と自律車両の行動との間の連係を示している。この連係は点線によって示される。図３５の例示のフローは、自律車両の計画モジュール３２２０で行うことができる。しかしながら、図３５のフローは、本明細書で言及しないものも含む、コンピューティングシステムの任意のモジュールまたは組み合わせによって実施されてもよいことが注目されるべきである。

【0196】

図３５の例は、最初（３５１０）に、自律車両が通常はその自律モードで、この例ではＬ４レベルで動作していることを示している。結果として、人間の運転者は非アクティブである（３５１５）。これは特に、自律車両の高い自律レベルに当てはまってもよい。

【0197】

問題が起こると、車両はシステム誤作動警告を送出してもよい（３５２０）。したがって、人間の運転者は警告を受信する（３５２５）。この警告は、視覚、音声、触覚、または他の任意のタイプの警告であることができる。

【0198】

誤作動が即時に運転者の対話を必要とするほど深刻なものではないと決定されると、車両はより下位の自律モードに切り替えることができる（３５３０）。この例では、車両はＬ４からＬ３に切り替えられる。したがって、人間の運転者は（例えば、３５２５で受信した警告に基づいて）この遷移に気づき、運転条件に注意を払ってもよく、必要な場合、特定の時間量で車両の制御を得ることができる（３５３５）。いくつかの例では、車両は、特定のセンサおよび監視を使用することによって、運転者の関与を確認することができる。例えば、車両は、視線監視、力覚フィードバック、音声フィードバックなどを使用することができる。

【0199】

別のエラーがある場合、車両はもう一度システム誤作動警告を送出することができる（３５４０）。警告が送られた後にもう一度、運転者は警告を受信する（３５４５）。

【0200】

次に、自律レベルを再び（この例では、Ｌ３からＬ２に）低減することができるともう一度決定された場合、車両はその自律レベルを再び下げる（３５５０）。ここで、対応する動きで、運転者はより一層注意を払い始める（３５５５）。この例では、自動車はＬ２モードなので、人間の運転者は注意を払い続ける。

【0201】

自動車がもう一度その自律レベルを、今度はＬ１に下げる必要がある場合、運転者がテイクオーバすることが必要になる。したがって、車両はテイクオーバ信号を送出してもよい（３５６０）。対応する動きで、運転者はテイクオーバ信号を受信してもよい（３５７０）。

【0202】

次に、車両は、運転者が車両の制御を引き継ぐことができるか否かを確認してもよい。したがって、車両は運転者が制御を引き継ぐのを待つ（３５６２）。上述したように、車両は、運転者が実際に制御を引き継いでいるか否かを監視することに加えて、監視およびセンサを使用して、運転者の準備状態を決定することができる。

【0203】

ある期間の後、運転者が制御を引き継いでいない（または安全に制御を引き継ぐことができない）と車両が決定した場合、緊急システムが活性化される（３５６４）。これは、状況に応じて異なる行動を実施することを含むことができる。例えば、車両が退避するのが必要なことがある。いくつかの状況では、退避および停車するのが安全ではないことがあるので、車両はある期間の間は進み続けてもよい。したがって、車両は、停車するのが安全になるまで、減速し、および／または道路の片側に退避してもよい。緊急システムが活性化されると、それに対応して緊急行動の状態が完了する（３５７４）。

【0204】

しかしながら、運転者がテイクオーバすることができ、ハンドオフが成功した場合、自律モードを不活性化することができる（３５６６）。対応する行動で、運転者は完全に関与し、車両を運転する（３５７６）。図から分かるように、早期の警告（ハンドオフが必要になる前に複数回）によって、システムが故障し、運転者がテイクオーバすることが強制的になる前に、運転者がハンドオフの準備をすることが可能になる。

【0205】

自律車両の自律レベルに応じて、車両が動作中の間に人間の運転者が何らかの対話をするのが必要なことがある。車両が通常、完全自律方式で動作することができるときであっても、人間の運転者が制御をテイクオーバするのが必要なことがある、いくつかの状況（例えば、緊急事態）があり得る。他の状況では、例えば、人間の運転者が運転したいとき、またはある人物が車両を制御する有益な理由があるとき、運転者が自律車両の制御をテイクオーバするのが望ましいことがある。しかしながら、人間は、注意散漫な場合が多く、簡単に気が散り、特定の状況に応答するのが遅い。したがって、少なくともいくつかの状況では、ある人物が、自律車両のハンドオフに関するバックアップとして信頼できないことがある。更に、人間の応答時間および反応は、状況のコンテキストに応じて変動する可能性がある。例えば、一部の人間は他の人間よりも反応時間が遅い。別の例として、一部の人間は緊急状況に冷静に反応し、他の人間はパニックになる。

【0206】

自律車両のハンドオフシステムおよび手順が、車両の制御をある人物にハンドオフする個人化された方策を実現するのが有益なことがある。かかるシステムおよび手順は、ハンドオフの安全性および有効性を強化することができる。これは、特に、人間の運転者が一般に不要である、レベル５の自律車両に当てはまり得る。いくつかの状況では、人間の運転者は眠っているかまたは気が散っていることがあり、したがってハンドオフと関連付けられる危険が増加する。個人化され連係されたハンドオフの方策は、かかる状況における人間の運転者の注意レベルおよび／または反応特性を、ハンドオフを計画するときに考慮に入れることができる。

【0207】

様々な実施形態では、個人化され連係されたハンドオフの方策は、自律車両における計画されたおよび計画されていないハンドオフ両方に適用することができる。完全自律が望ましい場合があるが、実世界のシナリオ（例えば、重大なセンサ故障、予期されない突然の路面条件変化（例えば、鉄砲水）など）は、自律車両の能力を超える状況を作り出すことがある。

【0208】

本明細書の実施形態によれば、ハンドオフの問題の解決策は、運転者の活性、個人の能力、およびハンドオフを計画するときの標的のルートのうち１つまたは複数を考慮に入れる、多面的な方策を備えることができる。この方策によって、システム（例えば、車両内処理システム２１０）が、車両の制御を人間の運転者にハンドオフするかどうか、またいつハンドオフするかに関してより良好な判断を行うことが可能になる。それに加えて、様々な実施形態はまた、時間に伴って運転者の個人化を提供することができ、コンテキスト情報参照を常に維持して、ハンドオフプロセスを漸進的に改善することができる。

【0209】

図３６は、人間の運転者に対する自律車両のハンドオフに関する一例のシステム３６００を示している。システムは、安全な適時の、かつ適応性の、人間の運転者に対する自律車両のハンドオフのシステムとみなすこともできる。いくつかの実施形態では、様々なモジュールが車両内処理システム（例えば、２１０）によって実現されてもよい。他の実施形態では、モジュールのうち１つまたは複数は、クラウドベースのコンピューティングシステム（例えば、１４０または１５０）によって実現されてもよい。システム３６００は、車両乗員活動監視モジュール３６１０と、個人化車両乗員能力データベース３６１５と、一般車両乗員能力データベース３６２０と、ハンドオフ予報モジュール３６２５と、ハンドオフ取扱いモジュール３６３０と、実行査定および最適化モジュール３６３５とを含む。システム３６００は単なる例示であり、本明細書に具体的に提示する実施形態に限定されない。

【0210】

車両乗員活動監視（「ＯＡＭ」）モジュール３６１０は、自律車両の人間の運転者に関連する情報を抽出する。特定の実施形態では、ＯＡＭモジュール３６１０は、規則ベースの機械学習ならびに深層学習方法の組み合わせを実現する。ＯＡＭは、人間の運転者と関連付けられた状態特性、例えば、運転者が向いている方向（例えば、その人物が道路または車両の後方のどちらを向いて座っているか）、運転席の位置付け（例えば、運転席からハンドルまでの距離、座席の背もたれの傾斜角度、またはハンドルに対する運転席の他の特性）、運転者が起きているか眠っているか、運転者が別の活動に関与しているか（例えば、読書している、映像を観ている、ゲームで遊んでいるなど）、あるいは他の状態特性を決定してもよい。ここで列挙するＯＡＭモジュール３６１０によって行われる決定は単なる例示であり、ＯＡＭは、運転者が車両の制御を完全にまたは部分的に引き継ぐ能力に関連するとみなされる、運転者の任意の特性を決定するのに使用することができる。

【0211】

ＯＡＭモジュール３６１０は、いくつかの異なるセンサからのデータを入力として使用してもよい。例えば、情報をＯＡＭモジュール３６１０に提供してもよい車両内センサとしては、例えば、カメラ、慣性測定ユニット、座席および背もたれセンサ、超音波センサ、または生体認証センサ（例えば、心拍モニタ、体温モニタなど）が挙げられる。センサからのデータは、未加工の形式または前処理済みであることができる。本明細書で列挙されるセンサは単なる例示であり、本明細書に列挙されているか否かにかかわらず、任意のタイプのセンサを、ＯＡＭモジュール３６１０に対するデータ入力として使用することができる。

【0212】

一般車両乗員能力（「ＧＯＣ」）データベース３６２０は、自律車両の実際の運転者と同様の一般運転者の特性の統計情報に関連するデータを含むことができる。例えば、ＧＯＣデータベース３６２０は、実際の運転者と同様の特性（例えば、性別、年齢、体力レベル）を有する運転者に関する特性応答の情報を包含することができる。更に、データベース３６２０に格納される情報は、世界的であるか、または１つもしくは複数の特定の地理的エリアに特異的であることができる。いくつかの実施形態では、ＧＯＣデータベース３６２０は、車両の外部にあり、クラウドを通じて自律車両が利用可能にすることができる。ＧＯＣデータベース３６２０は、自律車両のハンドオフ動作を時間に伴って改善することができるように、任意の好適な時間または間隔で更新することができる。ＧＯＣデータベース３６２０は、１つを超えるデータベースを備えることができることが注目されるべきである。

【0213】

ＧＯＣデータベースにおけるデータのタイプの例としては、プロンプトに応答するか、座席を１８０度回転させるか、座席を特定の距離長手方向に移動させるか、自分の手を膝の上に乗せた状態からハンドルに置くか、起きているときに道路に関与するか（これは、関与するように警告される前の運転者の活動に依存する場合がある）、またはハンドオフと関連付けられた他の好適な活動を行うのに、特徴的な運転者（例えば、運転者と類似の特性（例えば、年齢、性別など）を有する人物）が要する時間量を挙げることができる。それに加えて、運転者の特性（例えば、運転者の健康状態）を使用して、運転者の状況のコンテキストに対応する統計データを作成することができる。例えば、データベースは、自律車両の運転者と同じ腰の問題がある平均的運転者が、座席を直立位置にするかまたは座席をハンドルに向かって前方に移動するのに、平均して特定の時間量がかかることがあることを示す情報を獲得してもよい。

【0214】

利用可能な統計データを利用すること以外に、例えば、車両内処理システム２１０によって実現される機械学習モデルはまた、自律車両上で未加工データを処理するのに使用することができる。他の実施形態では、かかる機械学習モデルは、（自律車両上でローカルにではなく）クラウド上で実行されてもよく、推論出力が車両上で利用されてもよい。

【0215】

個人化車両乗員能力（「ＰＯＣ」）データベース３６１５は、本質的にＧＯＣデータベース３６２０と同様のデータを包含してもよい。しかしながら、ＰＯＣデータベースは、ＧＯＣデータベースのように複数の運転者から集約された情報ではなく、運転者および車両に特異的な情報を含む。各人物はＧＯＣデータベース３６２０によって確立されるベースラインからばらつくので、ＰＯＣデータベース３６１５内のデータは、システム３６００の機能を改善する助けとすることができる。ＰＯＣデータベース３６１５内のデータは、時間に伴って観察し測定することができる。システム３６００のＰＯＣモジュール３６１５は、運転者と仮想運転者との間の違いを追跡し続ける中心位置とみなすことができる。

【0216】

運転者に特異的な情報に加えて、ＰＯＣデータベース３６１５は車両に特異的な情報も包含することができる。例えば、運転者が座席を１８０度旋回させる時間は、車両の技術的能力に依存することがあり、運転者はこのプロセスを加速または減速することができない。

【0217】

例として、運転者が音声プロンプトに応答するのに平均的運転者よりもＸ１秒長くかかること、運転者が座席を回転させるのにかかる時間が平均よりもＸ２秒短いこと（例えば、これは、車両が高速転回動作を有すること、および／または運転者が比較的迅速に応答することによることがある）、運転者が座席を長手方向に移動させるのが平均的運転者よりもＸ３秒遅いこと、運転者が手をハンドルに置くのが平均的運転者よりもＸ４秒早いこと、ならびに運転者が起きているときに道路に関与するのが平均的運転者よりもＸ５秒早いこと、といったタイプのデータが、ＰＯＣデータベースに格納されてもよい。これらの例は、平均的運転者に関する測定値を考察しているが、いくつかの実施形態では、ＰＯＣデータベースによって格納される情報は、絶対測定値（例えば、運転者が音声プロンプトに応答するのに平均でＹ１秒かかること、運転者が座席を回転させるのに平均でＹ２秒かかることなど）を含んでもよい。それに加えて、ＧＯＣデータベースと同様に、ＰＯＣデータベースは、更なるコンテキストを運転者の状況に提供してもよい統計データを生成するのに使用することができる、運転者の他の特性を包含することができる。例として、ＰＯＣデータベースは、運転者が背中の損傷のため、座席を直立位置にするかまたは座席を前方に移動するのに、どのくらい迅速に動くかを示す情報を含んでもよい。

【0218】

ハンドオフ予報（ＨＯＦ）モジュール３６２５は、ハンドオフがいつ必要になり得るかを決定する。ＨＯＦモジュールは、自律運転者から人間の運転者へのハンドオフがどこでいつ必要になり得るかを決定するのに、例えば、事故、過密な道路、公共イベント、歩行者、工事などの路面条件を考慮することができる。ＨＯＦモジュールは、例えば、リアルタイムの交通量、事故、危険物、および道路保守管理の更新情報とともに、ローカルマップおよびルート情報を受信することができる。この情報の部分または全ては、自律車両内にローカルで、またはクラウドに格納されてもよい（また、車両は、クラウドを通してかかる情報に対する更新を受信してもよい）。

【0219】

図３７は、車両３７０５が地点Ａから地点Ｂに行くのに取っている一例のルート３７００を示している。ルート３７００は、自動車３７０５のナビゲーションシステム（例えば、経路プランナモジュール２４２）によって選択されている。ＨＯＦモジュール３６２５は、どこで人間の運転者にハンドオフすることが必要になり得るかを決定するのに、事故、過密な道路セグメント、および道路工事箇所などの路面条件を考慮してもよい。図３７の例では、かかるハンドオフが求められ得る３つのエリア（３７１０、３７２０、および３７３０）が決定されている。見込まれるハンドオフ場所を特定した後、ＨＯＦモジュール３６２５は、異なる基準に基づいて場所を格付けしてもよい。かかる基準の例としては、以下のようなものを挙げることができる。

【0220】

１－優先順位は低いかも知れないが、特定された場所で人間の運転者にハンドオフする必要がない、代替ルートがあるか？一例として、場所３７２０は代替ルート３７１５と関連付けられてもよい。

【0221】

２－自律車両が、速度を低減させることによって、ならびに／あるいは必要であれば間欠的に停車することによって、特定されたハンドオフ場所に対処することができるか？一例として、場所３７３０は、制御された安全な形で交通を減速させる可能性が高い、進行中の道路工事を有している。

【0222】

３－自律車両が人間の介入なしに扱うことができなくなる、何らかのセグメントがルート上にあるか？一例として、場所３７１０は、事故が交通の深刻な混乱を引き起こしていることがあるので、そのような場所であり得る。自律車両は、この特定の場所に接近するときに人間の運転者が前もって準備していることを確認する必要がある。

【0223】

様々な実施形態では、ＨＯＦモジュール３６２５は、ルート上のハンドオフ場所を決定するとともに、それらの相対的重要度（例えば、どのハンドオフ場所がハンドオフを要する可能性がより高いか）を格付けしてもよい。

【0224】

図３６に戻ると、ハンドオフ取扱い（「ＨＯＨ」）モジュール３６３０は、ハンドオフ判定を行うのに、ハンドオフ関連情報を考慮してもよい。ＨＯＨモジュール３６３０は、ＯＡＭモジュール３６１０、ＰＯＣデータベース３６１５、ＧＯＣデータベース３６２０、およびＨＯＦモジュール３６２５の出力を受け取り、それらの１つまたは複数に基づいてハンドオフ判定を行う。

【0225】

最後に、実行査定および最適化（「ＥＡＯ」）モジュール３６３５は、ハンドオフの予期される成果を運転者の行動と比較する。比較の結果は、今後のハンドオフを改善するため、ＰＯＣデータベース３６１５およびＨＯＨモジュール３６３０にフィードバックされる。情報を収集するため、ＥＡＯモジュール３６３５は、ルート上の各ハンドオフイベントにおいて、運転者がハンドオフ要求に応答するのにどのぐらいかかったか、運転者がハンドオフ後の予期されるステアリング範囲内にいたか否か、運転者の加速／減速がハンドオフ後の予期される加速／減速範囲内であったか否か、ならびに運転者がハンドオフの直後に道路に関与するのにどのぐらいかかったかといった、例示の基準を使用することができる。上記に列挙した基準は単なる例示であり、様々な実施形態では、全ての基準が使用されるわけではなく、または列挙されていない基準が使用されることがある。

【0226】

ＰＯＣデータベース３６１５内の更新によって、ハンドオフプロセスが、運転者によるより多くの個人化された情報、および自律車両の技術的能力を考慮することが可能になる。そのため、時間に伴って、自律車両の乗車回数が増加するにしたがって、ＰＯＣデータベース３６１５がＧＯＣデータベース３６２０からより一層差別化され始める。

【0227】

ＨＯＨモジュール３６３０は、ＥＡＯモジュール３６３５からのフィードバック情報を使用して、運転者が一般的な挙動と違う異常をいつどこで示したかを計算する。これは、ＰＯＣデータベース３６１５が、運転者の予期される挙動からの逸脱に関連するものとして運転者に関して格納することとは異なってもよく、今後のハンドオフにおいて考慮されてもよい。ＨＯＨモジュール３６３０が、かかる異常を今後のハンドオフにおいて考慮に入れた場合、運転者および自律車両のより代表的なデータに基づいて、自律車両がハンドオフ判定およびハンドオフ実行査定を行い、それは実世界の観察に基づくものなので、道路の安全性を改善することができる。

【0228】

図３８は、ＨＯＨモジュール３６３０の高度動作フロー３８００の一例を示している。この動作フローは、自律車両を人間の運転者にハンドオフする方法とみなすこともできる。最初に、方法は、決定されたハンドオフ場所をＨＯＦモジュール３６２５から取得することで開始される。これらの場所はルートの計算された優先順位から決定することができる。

【0229】

次に、方法３８００は続いて、一般運転データをＧＯＣデータベース３６２０から得る。何らかの一般運転データを取得するのは必須ではない場合もあることが注目されるべきである。例えば、適切な量のデータがＰＯＣデータベース３６１５に格納されていれば、ＧＯＣデータベース３６２０からのデータは、特定の決定から省略されてもよい。また、個人化されたデータを１つの場所から別の場所に伝達するのが可能であってもよく、例えば、運転者が新しい車両を購入したとき、情報が古い車両またはクラウドから新しい車両に伝達されてもよいことが、注目されるべきである。

【0230】

一般データ（利用される場合）を取得した後、ＨＯＨモジュールは続いて、個人化されたデータをＰＯＣデータベース３６１５から取得する。例えば、車両が新品であり、データがまだ取得されていないときなど、個人化されたデータがない状況があり得ることが注目されるべきである。

【0231】

次に、方法３８００は続いて、データをＯＡＭモジュール３６１０から取得する。このデータは、運転者の注意レベル、活動などに関連するものとして、運転者に関する情報を備えることができる。

【0232】

ＨＯＨモジュールは次に、ＨＯＦモジュール３６２５によって決定されたような可能なハンドオフ場所それぞれに対して、予期される運転者の取扱い挙動を決定することができる。ＨＯＨモジュール３６３０がハンドオフのタイミングであると決定した場合、運転者にプロンプトされる。そうではない場合、ＨＯＨモジュール３６３０は、他のモジュールのいずれかからリアルタイムの更新があるか否かを決定することができる。更新がある場合、１つまたは複数の更新を使用して、予期される運転者の取扱い挙動を再決定することができる。

【0233】

引き続き図３８の例を参照すると、運転者にプロンプトされた後、ＨＯＨモジュール３６３０は、運転者がテイクオーバすることができるか否かを決定する。テイクオーバできる場合、ＨＯＨモジュールは、予期される運転者挙動をＥＡＯモジュール３６３５に提供することができ、次に車両の制御を運転者に渡すことができる。更に、ハンドオフの間に運転者がどのぐらい良好に実施したかに関するデータを、ＥＡＯモジュール３６３５から取得することができ、それに応答して、予期される運転者挙動を更新することができる。運転者は、例えば、運転者が制御を放棄する準備ができるか、またはＡＶが制御を安全に再開できると決定されるまで、運転し続けることができる。

【0234】

プロンプトされたときに運転者がテイクオーバの準備ができていない場合、ＨＯＨモジュール３６３０は、ハンドオフの代案があるか否かを査定することができる。これは、例えば、代替ルートを取ること、減速することなどを含むことができる。代案がある場合、１つの代案を選択することができる。車両が移動し続けることを可能にする代案がない場合、ＨＯＨモジュールは車両を停車させることができる。これは、車両が安全な場所および方式で停車できることを確保するため、所望のルートの変更を伴う可能性があることが注目されるべきである。車両が停車位置に来た場合、車両は、運転者がテイクオーバの準備ができるまで、静止したままであることができる。次に、運転者は、自律車両に再びテイクオーバする準備ができ、またそれが安全になるまで、運転することができる。他の実施形態では、車両が再び移動するのを可能にする代案ができるまで、車両が停車位置に留まることも可能であってもよい。これは、例えば、車両を停車させた原因の路面条件の変化、または更には新しいルートが開通したことを含むことができる。

【0235】

以下の例は、図３８の例示の動作フローを図３７のルートの例と組み合わせて利用することによる、ＨＯＨモジュール３６３０の動作を例証する。

【0236】

行程前：

【0237】

１．ＡとＢとの間の最適ルート（３７００）が計算され、ＨＯＦモジュールに提供されている。

【0238】

２．ＨＯＦモジュール３６２５は、リアルタイム更新を使用して、３つのハンドオフエリア（３７１０、３７２０、および３７３０）を特定する。

【0239】

３．ＨＯＦモジュールは、場所３７１０が、運転者支援が必要とされる可能性が最も高い場所であると判定する（その地点の事故に関する情報がほとんどないため）。

【0240】

４．場所３７３０は、進行中の道路工事によって別のハンドオフが必要とされるかも知れない、次に確率が高い場所として選択される。

【0241】

５．場所３７２０は、道路における歩行者の交通量の増加が観察されている、ハンドオフの可能性がある別のエリアとして特定される。自律車両は、運転者による支援を必要とすることなく、代替ルート３７１５を取ることによって、乗車のこの区間を簡単に取り扱うことができる。

【0242】

６．ＧＯＣデータベース３６２０は、運転者に関する一般情報をＨＯＨモジュール３６３０に提供する。

【0243】

７．ＰＯＣデータベースは空である（運転者が自動車を購入したばかりで、運転者に基づく個人化された情報が限定されているため）。

【0244】

８．ＯＡＭモジュール３６１０は、運転者がハンドルの後ろに着席しており、その息子が後部座席に座っていることを確認する。

【0245】

９．運転者が運転している車両のモデルは、運転者が走行中に自由に後部座席の乗員と対話することを可能にする、全回転式の運転席を有する。そのため、運転者は道路に背を向け、息子に話しかけ始める。

【0246】

１０．車室内カメラは自動車内で起こっていることを完全にカバーしているので、ＯＡＭモジュール３６１０には、この会話活動ならびに運転者の着席位置がリアルタイムで通知される。ＯＡＭモジュール３６１０はまた、運転者が話している間に座席を息子にわずかに近づけており、身を乗り出していることを把握する。

【0247】

行程中：

【0248】

１１．自律車両は、第１のハンドオフ場所３７１０に向かって移動し始める。この第１のハンドオフ場所は最も重要であり、車両が運転者の介入を必要とするようになる場所なので、ＨＯＨモジュール３６３０は次のハンドオフについて運転者に早めに通知し始める。

【0249】

１２．ＨＯＨモジュール３６３０は、運転者が向き直ってハンドルに手を置くのにどのぐらいの時間がかかる可能性が高いかが分かっている。

【0250】

１３．ＨＯＨモジュール３６３０はまた、ＧＯＣデータベース３６２０から、一般に、高齢の運転者の方が若い運転者よりも完全に気づくのに長い時間がかかることが分かっている。したがって、一例として、運転者が５０歳の男性である場合、運転者が手をハンドルに置くとすぐに運転コンテキストに完全に気づくのに１５～２０秒かかる可能性がある。したがって、場所３７１０でのハンドオフが近づくにつれて、ＨＯＨモジュール３６３０によってこの追加の時間も考慮される。

【0251】

１４．ＨＯＨモジュール３６３０はまた、運転者による予期される応答時間をＥＡＯモジュール３６３５に提供して、ハンドオフがどのように実行されるかを査定させる。運転者は、車両によるハンドオフ要求に応答し、自動車をうまく誘導して道路上の事故を切り抜ける。

【0252】

１５．運転者は、事故場所を通り越した後、スマートフォンへの着信を受信すると、自律車両にハンドオフする。

【0253】

１６．ＥＡＯモジュール３６３５は、場所３７１０におけるハンドオフの査定を始める。運転者は、ＨＯＨモジュール３６３０によって予期された時間の１０秒後に応答したものと思われる。ＯＡＭモジュール３６１０のタイムスタンプは、運転者が自動車の制御を受け取るはずであったとき、この予期されない遅延が起こった時点で、息子におもちゃを手渡すのに忙しかったことを示している。

【0254】

１７．この異常は、計画されたハンドオフに対して追加の時間を残すために、今後の参照用にＨＯＨモジュール３６３０に折り返し報告されている。

【0255】

１８．ハンドオフ中の運転者の能力も、内部更新のためにＰＯＣモジュール３６１５に折り返し報告される。

【0256】

１９．車両がハンドオフ３７２０に接近するにつれて、ＯＡＭモジュール３６１０は、運転者がまだ電話中であり、苦痛が増しているという信号を出しているように思われることを確認する。

【0257】

２０．ＨＯＨモジュール３６３０は、代替ルート３７１５を辿ることによってハンドオフ場所３７２０を回避できることが分かっている。このルートは、行程に余剰の２分間を加えるが、運転者が通話を中断せずに続けることを可能にする。

【0258】

２１．ＨＯＨモジュール３６３０は、場所３７２０でのハンドオフを要求しないと判定し、車両の自律を継続する。

【0259】

２２．ＨＯＨモジュール３６３０は、ハンドオフ場所３７３０における道路工事に気づいており、この場所でのハンドオフは場所３７１０ほど重要ではないので、人間の介入によって、行程時間は少し短いものであってもよい。

【0260】

２３．ＯＡＭモジュール３６１０は、運転者がもう通話しておらず、前を向いて自動車前方の交通を何気なく見ていることを示す。

【0261】

２４．ＨＯＨモジュール３６３０は、運転者が非常に簡単にテイクオーバできてもよいと判定し、行程時間を節約する任意のハンドオーバを通知する。

【0262】

２５．テイクオーバによって更に数分間節約するのが良い考えであると判定すると、運転者はテイクオーバに同意し、場所３７３０でのハンドオフの実行が成功する。

【0263】

２６．ＰＯＣモジュール３６１５は、ハンドオフ後にＥＡＯモジュール３６３５によって更新され、異常が検出されていないので、ＨＯＨモジュール３６３０は今度は通知を受信しない。

【0264】

２７．行程の残りに関して、運転者は、ハンドオフしないと判定し、目的地まで手動モードで運転する。

【0265】

上述の例は単なる例示であり、より多数または少数の、更には異なる行動が取られてもよい。同様に、図３８の例の方法も例示であり、その方法のより多数または少数の段階が行われてもよい。

【0266】

また、自律車両が、（ルート、ＥＴＡなどに関して行程の元々の目的を満たすために）人間の運転者にハンドオフする以外の選択肢を有さないが、人間の運転者がテイクオーバする位置にいない状況があり得ることが注目されるべきである。かかるシナリオでは、自律車両は、人間の運転者がテイクオーバできる時まで、退避し安全な停車位置に行くか、低速車線に向かい、走行時間が増加する代わりに交通および路面条件にしたがって走行速度を低減させるか、ハンドオーバなしで車両が走り続けることを可能にする代替ルートを計算するか（かかるルートはより長距離および／または低速であることがある）、あるいは最終目的地までずっとハンドオフなしで車両が走り続けることはできないが、人間の運転者がテイクオーバの準備ができるまで、車両を安全な停車位置に行かせることはできる代替ルートを計算するといった、より安全な選択肢を選択してもよい。これらの解決策は単なる例示であり、車両の義務的なハンドオフに対する他の解決策があってもよい。

【0267】

図３９～図４０は、本明細書に開示する実施形態にしたがって使用されてもよい、例示のコンピュータアーキテクチャのブロック図である。プロセッサおよびコンピューティングシステムに関する分野で知られている、他のコンピュータアーキテクチャ設計も使用されてもよい。一般に、本明細書に開示する実施形態に適したコンピュータアーキテクチャとしては、図３９～図４０に示される構成を挙げることができるが、それらに限定されない。

【0268】

図３９は、一実施形態によるプロセッサの一例の図である。プロセッサ３９００は、上述の実現例と関連して使用することができるタイプのハードウェアデバイスの一例である。プロセッサ３９００は、マイクロプロセッサ、埋込型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ、マルチコアプロセッサ、シングルコアプロセッサ、またはコードを実行する他のデバイスなど、任意のタイプのプロセッサであってもよい。１つのプロセッサ３９００のみが図３９に示されているが、あるいは、処理要素は、図３９に示される１つを超えるプロセッサ３９００を含んでもよい。プロセッサ３９００はシングルスレッドコアであってもよく、または少なくとも１つの実施形態に関しては、プロセッサ３９００は、コアごとに１つを超えるハードウェアスレッドのコンテキスト（即ち、「論理プロセッサ」）を含んでもよいという点で、マルチスレッドであってもよい。

【0269】

図３９はまた、一実施形態によるプロセッサ３９００に結合されたメモリ３９０２を示している。メモリ３９０２は、当業者に知られているかまたは別の形で利用可能である、多種多様なメモリのいずれか（メモリ階層の様々なレイヤを含む）であってもよい。かかるメモリ素子としては、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）の論理ブロック、消去可能プログラマブル読出し専用メモリ（ＥＰＲＯＭ）、および電気消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）を挙げることができるが、それらに限定されない。

【0270】

プロセッサ３９００は、本明細書で詳述するアルゴリズム、プロセス、または動作と関連付けられた任意のタイプの命令を実行することができる。一般に、プロセッサ３９００は、要素または項目（例えば、データ）を１つの状態または物から別の状態または物へと変換することができる。

【0271】

コード３９０４は、プロセッサ３９００によって実行される１つもしくは複数の命令であってもよく、メモリ３９０２に格納されてもよく、あるいはソフトウェア、ハードウェア、ファームウェア、もしくはそれらの任意の好適な組み合わせに、または適切な場合、特定の必要性に基づいて、他の任意の内部もしくは外部構成要素、デバイス、要素、またはオブジェクトに格納されてもよい。一例では、プロセッサ３９００は、コード３９０４によって示される命令のプログラムシーケンスにしたがうことができる。各命令は、フロントエンド論理３９０６を入力し、１つまたは複数のデコーダ３９０８によって処理される。デコーダは、その出力として、既定のフォーマットの固定幅のマイクロ動作など、マイクロ動作を生成してもよく、あるいは他の命令、マイクロ命令、または元のコード命令を反映した制御信号を生成してもよい。フロントエンド論理３９０６はまた、一般に、リソースを割り付け、命令に対応する動作を待ち行列に入れて実行させる、レジスタリネーミング論理３９１０およびスケジューリング論理３９１２を含む。

【0272】

プロセッサ３９００はまた、実行ユニット３９１６ａ、３９１６ｂ、３９１６ｎなどのセットを有する、実行論理３９１４を含むことができる。いくつかの実施形態は、特定の機能または機能のセット専用の多数の実行ユニットを含んでもよい。他の実施形態は、１つの実行ユニットのみ、または特定の機能を実行することができる１つの実行ユニットを含んでもよい。実行論理３９１４は、コード命令によって指定される動作を実施する。

【0273】

コード命令によって指定された動作の実行を完了した後、バックエンド論理３９１８はコード３９０４の命令をリタイヤすることができる。一実施形態では、プロセッサ３９００は、アウトオブオーダ実行は許可するが、命令のインオーダリタイヤメントを要する。リタイヤメント論理３９２０は、様々な既知の形態（例えば、リオーダバッファなど）を取ってもよい。このように、プロセッサ３９００は、コード３９０４の実行中、少なくともデコーダによって生成される出力、レジスタリネーミング論理３９１０によって利用されるハードウェアレジスタおよびテーブル、ならびに実行論理３９１４によって修正される任意のレジスタ（図示なし）に関して変換される。

【0274】

図３９には図示されないが、処理要素は、プロセッサ３９００を有するチップ上にある他の要素を含んでもよい。例えば、処理要素は、プロセッサ３９００とともにメモリ制御論理を含んでもよい。処理要素は、Ｉ／Ｏ制御論理を含んでもよく、ならびに／あるいはメモリ制御論理と統合されたＩ／Ｏ制御論理を含んでもよい。処理要素はまた、１つまたは複数のキャッシュを含んでもよい。いくつかの実施形態では、不揮発性メモリ（フラッシュメモリまたはヒューズなど）も、プロセッサ３９００を有するチップ上に含まれてもよい。

【0275】

図４０は、一実施形態による、ポイントツーポイント（ＰｔＰ）構成で配置されたコンピューティングシステム４０００を示している。特に、図４０は、プロセッサ、メモリ、および入力／出力デバイスが多数のポイントツーポイントインターフェースによって相互接続されたシステムを示している。一般に、本明細書に記載するコンピューティングシステムの１つまたは複数は、コンピューティングシステム３９００と同じまたは類似の方式で構成されてもよい。

【0276】

プロセッサ４０７０および４０８０はまた、メモリ素子４０３２および４０３４と通信するのに、統合されたメモリコントローラ論理（ＭＣ）４０７２および４０８２をそれぞれ含んでもよい。代替実施形態では、メモリコントローラ論理４０７２および４０８２は、プロセッサ４０７０および４０８０とは別個である個別の論理であってもよい。メモリ素子４０３２および／または４０３４は、本明細書に概説する動作および機能性を達成するのにプロセッサ４０７０および４０８０によって使用される、様々なデータを格納してもよい。

【0277】

プロセッサ４０７０および４０８０は、本明細書の他の図面に関連して考察されるものなど、任意のタイプのプロセッサであってもよい。プロセッサ４０７０および４０８０はそれぞれ、ポイントツーポイントインターフェース回路４０７８および４０８８を使用して、ポイントツーポイント（ＰｔＰ）インターフェース４０５０を介してデータを交換してもよい。プロセッサ４０７０および４０８０はそれぞれ、ポイントツーポイントインターフェース回路４０７６、４０８６、４０９４、および４０９８を使用して、個々のポイントツーポイントインターフェース４０５２および４０５４を介してチップセット４０９０とデータを交換してもよい。チップセット４０９０はまた、ＰｔＰインターフェース回路であり得るインターフェース４０３９を介して、高性能グラフィックス回路、機械学習アクセラレータ、または他のコプロセッサ４０３８などのコプロセッサ４０３８とデータを交換してもよい。代替実施形態では、図４０に示されるＰｔＰリンクのいずれかまたは全てを、ＰｔＰリンクではなくマルチドロップバスとして実現することができる。

【0278】

チップセット４０９０は、インターフェース回路４０９６を介してバス４０２０と通信してもよい。バス４０２０は、バスブリッジ４０１８およびＩ／Ｏデバイス４０１６など、バスを通じて通信する１つまたは複数のデバイスを有してもよい。バス４０１０を介して、バスブリッジ４０１８は、ユーザインターフェース４０１２（キーボード、マウス、タッチスクリーン、もしくは他の入力デバイスなど）、通信デバイス４０２６（モデム、ネットワークインターフェースデバイス、もしくはコンピュータネットワーク４０６０を通して通信してもよい他のタイプの通信デバイスなど）、音声Ｉ／Ｏデバイス４０１４、ならびに／あるいはデータ記憶デバイス４０２８など、他のデバイスと通信してもよい。データ記憶デバイス４０２８は、プロセッサ４０７０および／または４０８０によって実行されてもよい、コード４０３０を格納してもよい。代替実施形態では、バスアーキテクチャの任意の部分を１つまたは複数のＰｔＰリンクで実現することができる。

【0279】

図４０に示されるコンピュータシステムは、本明細書で考察する様々な実施形態を実現するのに利用されてもよい、コンピューティングシステムの一実施形態の概略図である。図４０に示されるシステムの様々な構成要素は、システムオンチップ（ＳｏＣ）アーキテクチャで、または本明細書に提供する実施例ならびに実現例の機能性および特徴を達成することができる他の任意の好適な構成で組み合わされてもよいことが、認識されるであろう。

【0280】

本明細書に記載し例証するシステムおよび解決策のいくつかは、複数の要素を包含するか複数の要素と関連付けられるものとして記載しているが、本開示の代替の実現例それぞれにおいて、明示的に例証または記載される全ての要素が利用されなくてもよい。それに加えて、本明細書に記載する要素の１つまたは複数は、システムの外部に位置してもよいが、他の例では、特定の要素が、他の記載される要素ならびに例証される実現例には記載されない他の要素の１つもしくは複数の中に、またはそれらの一部分として含まれてもよい。更に、特定の要素は、他の構成要素と組み合わされてもよく、ならびに本明細書に記載する目的に加えて、代替のまたは追加の目的に使用されてもよい。

【0281】

更に、上記に提示した例は、単に特定の原理および特徴を例証する目的で提供される非限定例であり、本明細書に記載する概念の考え得る実施形態を必ずしも限定または制約するものではないことが認識されるべきである。例えば、様々な異なる実施形態は、本明細書に記載する構成要素の様々な実現例を通して現実化される組み合わせを含む、本明細書に記載する特徴および構成要素の様々な組み合わせを利用して現実化することができる。他の実現例、特徴、および詳細が、本明細書の内容から認識されるべきである。

【0282】

本開示は、特定の実現例および一般に関連する方法に関して記載してきたが、これらの実現例および方法の変更および置換が当業者には明白となるであろう。例えば、本明細書に記載する行動は、記載するのとは異なる順序で実施することができ、依然として望ましい結果を達成することができる。一例として、添付図面に示されるプロセスは、所望の結果を達成するのに、図示される特定の順序または連続順序を必ずしも要するものではない。特定の実現例では、マルチタスキングおよび並列処理が有利であってもよい。それに加えて、他のユーザインターフェースのレイアウトおよび機能性に対応することができる。他の変形例が、後述する特許請求の範囲内にある。

【0283】

本明細書は多くの特定の実現の詳細を包含するが、これらは、発明の範囲または請求することができる範囲に対する限定としてではなく、特定の発明の特定の実施形態に特異的な特徴の説明として解釈されるべきである。別個の実施形態の文脈において本明細書に記載される特定の特徴は、単一の実施形態において組み合わせで実現することもできる。逆に、単一の実施形態の文脈において記載される様々な特徴を、複数の実施形態において別個に、または任意の好適な下位の組み合わせで実現することもできる。更に、特徴は、特定の組み合わせで作用するものとして上記に記載され、更にはそのように最初に請求されることがあるが、請求される組み合わせからの１つまたは複数の特徴は、場合によっては、その組み合わせから削除することができ、請求される組み合わせは下位の組み合わせまたは下位の組み合わせの変形例を対象としてもよい。

【0284】

同様に、動作は特定の順序で図面に示されるが、これはかかる動作が、所望の結果を達成するのに、図示される特定の順序または連続順序で実施されること、あるいは図示される全ての動作が実施されることを要するものと理解されるべきではない。特定の状況では、マルチタスキングおよび並列処理が有利であってもよい。更に、上述した実施形態における様々なシステム構成要素の分離は、全ての実施形態でかかる分離を要するものと理解されるべきではなく、記載するプログラム構成要素およびシステムを、一般に、単一のソフトウェア製品で互いに統合するか、または複数のソフトウェア製品にパッケージングすることができるものと理解されるべきである。

【0285】

車両内コンピューティングシステム（例えば、自動化運転スタックの少なくとも一部分を実現し、車両の自動化運転が機能できるようにするのに使用される）、路側コンピューティングシステム（例えば、車両とは別個に、専用の路側キャビネット内、交通標識上、信号機もしくは照明柱上で実現される）、自律運転環境に対応するクラウドベースまたはフォグベースのシステムを実現する１つまたは複数のコンピューティングシステム、あるいは自律運転環境から遠隔にあるコンピューティングシステムを含む、１つまたは複数のコンピューティングシステムが提供されてもよい。これらのコンピューティングシステムは、以下の実施例（もしくはそれらの部分）の１つまたは組み合わせを実施あるいは実現する、１つもしくは複数のデータ処理装置（例えば、中央処理装置、グラフィックス処理装置、テンソル処理装置、ＡＳＩＣ、ＦＰＧＡなど）、アクセラレータハードウェア、他のハードウェア回路類、ファームウェア、ならびに／あるいはソフトウェアのうち１つまたは組み合わせを使用して実現される、論理を含んでもよい。例えば、様々な実施形態では、以下の例示の方法の動作は、車両（例えば、１０５）のコンピューティングシステムまたはその構成要素（例えば、プロセッサ２０２、アクセラレータ２０４、通信モジュール２１２、ユーザディスプレイ２８８、メモリ２０６、ＩＸファブリック２０８、運転制御２２０、センサ２２５、ユーザインターフェース２３０、車両内処理システム２１０、機械学習モデル２５６、他の構成要素、もしくはそれらのいずれかの下位構成要素）、路側コンピューティングデバイス１４０、フォグベースまたはクラウドベースのコンピューティングシステム１５０、ドローン１８０、およびアクセスポイント１４５、センサ（例えば、１６５）、メモリ３６０２、プロセッサコア３６００、システム３７００、他の好適なコンピューティングシステムまたはデバイス、これらのいずれかの下位構成要素、あるいは他の好適な論理など、任意の好適な論理を使用して実施されてもよい。様々な実施形態では、以下の一実施例の方法の１つまたは複数の特定の動作は、特定の構成要素またはシステムによって実施されてもよいが、実施の方法の１つまたは複数の動作は、別の構成要素またはシステムによって実施されてもよい。他の実施形態では、一実施例の方法の動作はそれぞれ、同じ構成要素またはシステムによって実施されてもよい。

【0286】

実施例１は、車両の複数のセンサからセンサデータを受信する少なくとも１つのインターフェースと、センサデータに基づいた経路計画にしたがって車両の運転を自律的に制御し、車両の自律制御を停止すべきと決定し、遠隔コンピューティングシステムが車両の運転を遠隔で制御するように、遠隔コンピューティングシステムにハンドオフ要求を送り、運転命令データを遠隔コンピューティングシステムから受信し、運転命令データに含まれる命令に基づいて車両の運転を制御する、１つまたは複数のプロセッサと、を備える、装置を含む。

【0287】

実施例２は、運転命令データが、遠隔コンピューティングシステムにおける人間のユーザの入力から生成される、実施例１の装置を含む。

【0288】

実施例３は、１つまたは複数のプロセッサが退避イベントを検出し、車両が退避イベントと関連して退避し運転を停止し、ハンドオフ要求が退避イベントに応答して送られる、実施例１～２のいずれか１つの装置を含む。

【0289】

実施例４は、車両の自律制御を停止すべきと決定することが、特定の機械学習モデルを使用して、経路計画の次の区間における条件が、次の区間の間は自律運転が困難であることを提示すると予測することを有する、実施例１～２のいずれか１つの装置を含む。

【0290】

実施例５は、１つまたは複数のプロセッサが、車両の１つまたは複数の故障したセンサの検出に基づいて、車両の自律制御を停止すべきと決定する、実施例１～４のいずれか１つの装置を含む。

【0291】

実施例６は、１つまたは複数のプロセッサが、適格な乗員が車両内に存在しないと決定し、適格な乗員が存在しないとの決定に少なくとも部分的に基づいて、ハンドオフ要求が送られる、実施例１～５のいずれか１つの装置を含む。

【0292】

実施例７は、１つまたは複数のプロセッサが、センサデータを遠隔コンピューティングシステムに送って、車両の周囲の動的表現を遠隔コンピューティングシステムの人間のユーザに対して提示する、実施例１～６のいずれか１つの装置を含む。

【0293】

実施例８は、センサデータが映像データを有する、実施例７の装置を含む。

【0294】

実施例９は、１つまたは複数のプロセッサが、車両の制御が遠隔バレットサービスにハンドオーバされることを特定する、警告を車両の乗員に通信する、実施例１～８のいずれか１つの装置を含む。

【0295】

実施例１０は、１つまたは複数のプロセッサが、経路計画に沿った条件の変化を検出し、車両の運転の制御を遠隔コンピューティングシステムから車両の自律運転論理に戻す、実施例１～９のいずれか１つの装置を含む。

【0296】

実施例１１は、命令が機械によって実行されると、機械に、車両のセンサのセットから生成されたセンサデータに基づいた経路計画にしたがって車両の運転を自律的に制御させ、車両の自律制御を停止すべきと決定させ、遠隔コンピューティングシステムが車両の運転を遠隔で制御するように、遠隔コンピューティングシステムにハンドオフ要求を送らせ、運転命令データを遠隔コンピューティングシステムから受信させ、運転命令データに含まれる命令に基づいて車両の運転を制御させる、命令を格納するコンピュータ可読媒体を含む。

【0297】

実施例１２は、運転命令データが、遠隔コンピューティングシステムにおける人間のユーザの入力から生成される、実施例１１の媒体を含む。

【0298】

実施例１３は、命令が機械によって実行されると、機械に退避イベントを検出させ、車両が退避イベントと関連して退避し運転を停止し、ハンドオフ要求が退避イベントに応答して送られる、実施例１１～１２のいずれか１つの媒体を含む。

【0299】

実施例１４は、車両の自律制御を停止すべきと決定することが、特定の機械学習モデルを使用して、経路計画の次の区間における条件が、次の区間の間は自律運転が困難であることを提示すると予測することを有する、実施例１１～１２のいずれか１つの媒体を含む。

【0300】

実施例１５は、車両における１つまたは複数の故障したセンサの検出に基づいて、車両の自律制御を停止すべきと決定される、実施例１１～１４のいずれか１つの媒体を含む。

【0301】

実施例１６は、命令が機械によって実行されると、機械に、適格な乗員が車両内に存在しないと決定させ、適格な乗員が存在しないとの決定に少なくとも部分的に基づいて、ハンドオフ要求が送られる、実施例１１～１５のいずれか１つの媒体を含む。

【0302】

実施例１７は、命令が機械によって実行されると、機械に、センサデータを遠隔コンピューティングシステムに送らせて、車両の周囲の動的表現を遠隔コンピューティングシステムの人間のユーザに対して提示する、実施例１１～１６のいずれか１つの媒体を含む。

【0303】

実施例１８は、センサデータが映像データを有する、実施例１７の媒体を含む。

【0304】

実施例１９は、命令が機械によって実行されると、機械に、車両の制御が遠隔バレットサービスにハンドオーバされることを特定する、警告を車両の乗員に提示させる、実施例１１～１８のいずれか１つの媒体を含む。

【0305】

実施例２０は、命令が機械によって実行されると、機械に、経路計画に沿った条件の変化を検出させ、車両の運転の制御を遠隔コンピューティングシステムから車両の自律運転論理に戻させる、実施例１１～１９のいずれか１つの媒体を含む。

【0306】

実施例２１は、車両のセンサのセットから生成されたセンサデータに基づいた経路計画にしたがって車両の運転を自律的に制御する手段と、車両の自律制御を停止すべきと決定する手段と、遠隔コンピューティングシステムが車両の運転を遠隔で制御するように、遠隔コンピューティングシステムにハンドオフ要求を送る手段と、運転命令データを遠隔コンピューティングシステムから受信する手段と、運転命令データに含まれる命令に基づいて車両の運転を制御する手段と、を備える、システムを含む。

【0307】

実施例２２は、運転命令データが、遠隔コンピューティングシステムにおける人間のユーザの入力から生成される、実施例２１のシステムを含む。

【0308】

実施例２３は、退避イベントを検出する手段を更に備え、車両が退避イベントと関連して退避し運転を停止し、ハンドオフ要求が退避イベントに応答して送られる、実施例２１～２２のいずれかのシステムを含む。

【0309】

実施例２４は、車両の自律制御を停止すべきと決定することが、特定の機械学習モデルを使用して、経路計画の次の区間における条件が、次の区間の間は自律運転が困難であることを提示すると予測することを有する、実施例２１のシステムを含む。

【0310】

実施例２５は、センサデータを生成する複数のセンサと、車両の動きを物理的に制御する制御システムと、制御システムと通信することによって、センサデータに基づいた経路計画にしたがって車両の運転を自律的に制御し、車両の自律制御を停止すべきと決定し、遠隔コンピューティングシステムが車両の運転を遠隔で制御するように、遠隔コンピューティングシステムにハンドオフ要求を送り、運転命令データを遠隔コンピューティングシステムから受信し、制御システムと通信することによって、運転命令データに含まれる命令に基づいて車両の運転を制御する、処理回路類と、を備える、車両を含む。

【0311】

実施例２６は、コンピューティング端末デバイスにおいて人間のユーザに対してユーザインターフェースを提供することと、自律的に運転するように構成された車両からハンドオフ要求を受信することと、車両の周囲の環境を記述するセンサデータを遠隔センサデバイスから受信することと、センサデータに基づいて環境の表現をユーザインターフェースにおいて提示することと、表現に応答して、環境内における車両の運転を指示する入力を有するユーザ入力を、コンピューティング端末デバイスで受信することと、ユーザ入力に対応する命令データを車両に送って、ユーザ入力にしたがって車両を遠隔で運転することと、を備える、方法を含む。

【0312】

実施例２７は、ハンドオフ要求が車両の場所を特定する、実施例２６の方法を含む。

【0313】

実施例２８は、場所に対応する、車両の外部のセンサデバイスを決定することと、センサデバイスからの補足センサデータにアクセスすることと、を更に備え、補足センサデータに少なくとも部分的に基づいて表現が提示される、実施例２７の方法を含む。

【0314】

実施例２９は、センサデバイスが車両上のセンサデバイスを有する、実施例２６～２８のいずれか１つの方法を含む。

【0315】

実施例３０は、センサデバイスが車両とは別個のセンサデバイスを有する、実施例２６～２９のいずれか１つの方法を含む。

【0316】

実施例３１は、車両の運転の制御を車両に返還する要求を車両から受信することと、制御の返還の確認を車両に送ることと、車両への命令データの送信を停止することと、を更に備える、実施例２６～３０のいずれか１つの方法を含む。

【0317】

実施例３２は、遠隔バレットサービスによる車両の制御中、ユーザ入力に基づいて、車両の環境および性能を記述する報告データを生成することと、報告データをクラウドベースのシステムに送ることと、を更に備える、実施例２６～３０のいずれか１つの方法を含む。

【0318】

実施例３３は、実施例２６～３２のいずれか１つの方法を実施する手段を備える、システムを含む。

【0319】

実施例３４は、手段が、命令を格納するコンピュータ可読媒体を有し、命令が機械によって実行されると、機械に、実施例２６～３２のいずれか１つの方法の少なくとも一部分を実施させる、実施例３３のシステムを含む。

【0320】

実施例３５は、車両におけるセンサのセットからセンサデータを生成することと、車両の経路計画を決定することと、１つまたは複数の機械学習モデルおよびセンサデータに基づいた経路計画にしたがって、車両の運転を自律的に制御することと、経路計画の次の部分における条件を特定することと、条件に基づいて車両の運転の制御を遠隔バレットサービスにハンドオフする機会を決定することと、機会に基づいて、遠隔バレットサービスを提供する遠隔コンピューティングシステムに、ハンドオフ要求を送ることと、運転命令データを遠隔コンピューティングシステムから受信することと、命令データに含まれる命令に応答して、車両の運転を自動化することと、を備える、方法を含む。

【0321】

実施例３６は、ハンドオフおよびハンドオフに対応する条件を特定する報告データを、別のコンピューティングシステムに送ることを更に備える、実施例３５の方法を含む。

【0322】

実施例３７は、報告データがクラウドベースのアプリケーションに送られる、実施例３６の方法を含む。

【0323】

実施例３８は、報告データが路側ユニットに送られる、実施例３６～３７のいずれか１つの方法を含む。

【0324】

実施例３９は、条件が別のコンピューティングシステムから受信されたデータから特定される、実施例３５～３８のいずれか１つの方法を含む。

【0325】

実施例４０は、条件が機械学習モデルを適用することによって特定され、他のシステムからのデータが機械学習モデルに対する入力として提供される、実施例３９の方法を含む。

【0326】

実施例４１は、機械学習モデルが、遠隔バレットサービスへのハンドオフまたは退避イベントのどちらかを他のインスタンスに報告するデータに基づいて訓練される、実施例４０の方法を含む。

【0327】

実施例４２は、ハンドオフ要求が退避イベントを回避するために送られる、実施例３５～４１のいずれか１つの方法を含む。

【0328】

実施例４３は、機会が、条件に照らして車両の自律運転機能性が十分に機能しないという予測に対応する、実施例３５～４２のいずれか１つの方法を含む。

【0329】

実施例４４は、機会が、センサデータに含まれる情報に少なくとも部分的に基づいて決定される、実施例３５～４３のいずれか１つの方法を含む。

【0330】

実施例４５は、追加のデータにアクセスすることと、追加のデータに基づいて、次の経路に続く経路計画の別の部分における条件の改善を予測することと、条件の予測された改善に基づいて、制御が車両に返還されることを要求する要求データを遠隔コンピューティングシステムに送ることと、車両の運転の自律制御を再開することと、を更に備える、実施例３５～４４のいずれか１つの方法を含む。

【0331】

実施例４６は、制御をハンドオフする機会を決定することが退避イベントを検出することを有する、実施例３５～４５のいずれか１つの方法を含む。

【0332】

実施例４７は、退避イベントと関連付けられたセンサデータから条件を決定することと、条件を記述するデータを遠隔コンピューティングシステムにアップロードすることと、を更に備える、実施例４６の方法を含む。

【0333】

実施例４８は、実施例３５～４７のいずれか１つの方法を実施する手段を備える、システムを含む。

【0334】

実施例４９は、手段が、命令を格納するコンピュータ可読媒体を有し、命令が機械によって実行されると、機械に実施例３５～４７のいずれか１つの方法の少なくとも一部分を実施させる、実施例４８のシステムを含む。

【0335】

実施例５０は、車両に対する人間の入力に応答して、第１の１つまたは複数の制御信号のセットを生成することと、第１の１つまたは複数の制御信号のセットが許容不能な加速を引き起こすであろうという決定に応答して、許容可能な加速を特定し、許容可能な加速を第２の１つまたは複数の制御信号のセットに変換し、第２の１つまたは複数の制御信号のセットを、第１の１つまたは複数の制御信号のセットの代わりに車両作動システムに提供することと、を備える、方法を含む。

【0336】

実施例５１は、許容可能な加速値の範囲を受信することと、許容可能な加速値の範囲から許容可能な加速を特定することと、更に備える、実施例５０の方法を含む。

【0337】

実施例５２は、許容可能な加速値の範囲が事故回避数学モデルにしたがって決定される、実施例５１の方法を含む。

【0338】

実施例５３は、許容可能な加速値の範囲が責任感知型安全論モデルにしたがって決定される、実施例５１～５２のいずれかの方法を含む。

【0339】

実施例５４は、１つまたは複数の制御信号が許容不能な加速を引き起こすであろうと決定することが、機械学習モデルを使用して、１つまたは複数の制御信号を予期される加速に変換することを有する、実施例５０～５３のいずれかの方法を含む。

【0340】

実施例５５は、許容可能な加速を第２の１つまたは複数の制御信号のセットに変換することが、車両と関連付けられたコンテキストに基づいて、許容可能な加速を変換することを有し、コンテキストが、車両の１つまたは複数のセンサを介して受信される入力に基づいて決定される、実施例５０～５４のいずれかの方法を含む。

【0341】

実施例５６は、車両の１つまたは複数のセンサを介して受信される入力が、路面条件、気象条件、タイヤ条件、または道路レイアウトのうち１つもしくは複数を示す、実施例５５の方法を含む。

【0342】

実施例５７は、許容可能な加速を第２の１つまたは複数の制御信号のセットに変換することが、車両の重量に基づいて許容可能な加速を変換することを有する、実施例５０～５６のいずれかの方法を含む。

【0343】

実施例５８は、許容可能な加速を特定することが、車両の運転者によって提供されるポリシー情報に基づいて、許容可能な加速の範囲から許容可能な加速を選択することを有する、実施例５０～５７のいずれかの方法を含む。

【0344】

実施例５９は、車両に対する人間の入力に応答して、第３の１つまたは複数の制御信号のセットを生成することと、第３の１つまたは複数の制御信号のセットが許容可能な加速を引き起こすであろうという決定に応答して、第３の１つまたは複数の制御信号のセットを車両作動システムに不変のまま提供することと、を更に備える、実施例５０～５８のいずれかの方法を含む。

【0345】

実施例６０は、実施例５０～５９の方法の１つまたは複数を実施する、メモリとメモリに結合された処理回路類とを備える、装置を含む。

【0346】

実施例６１は、実施例５０～５９の方法の１つまたは複数を実施する手段を備える、システムを含む。

【0347】

実施例６２は、命令が実行されると、装置を現実化するか、または実施例５０～５９のいずれか１つのような方法を実現する、命令を備える少なくとも１つの機械可読媒体を含む。

【0348】

実施例６３は、車両のコンピューティングシステムによって、センサデータおよびセンサデータのコンテキストに基づいて、信号品質測定基準を決定することと、信号品質測定基準に基づいて、車両の制御のハンドオフと関連付けられる安全性の可能性を決定することと、安全性の可能性に基づいて、車両の制御のハンドオフを防止するかまたはハンドオフを開始することと、を備える、方法を含む。

【0349】

実施例６４は、機械学習モデルを使用して、センサデータに基づいてセンサデータのコンテキストを決定することを更に備える、実施例６３の方法を含む。

【0350】

実施例６５は、機械学習モデルを使用して、信号品質測定基準に基づいて安全性の可能性を決定することを更に備える、実施例６３～６４のいずれかの方法を含む。

【0351】

実施例６６は、機械学習モデルを使用して、センサデータおよびセンサデータのコンテキストに基づいて信号品質測定基準を決定することを更に備える、実施例６３～６５のいずれかの方法を含む。

【0352】

実施例６７は、車両が自律的に制御されている間、車両の制御のハンドオフと関連付けられた安全性の可能性を周期的に決定することを更に備える、実施例６３～６６のいずれかの方法を含む。

【0353】

実施例６８は、車両の制御をハンドオフする人間の運転者からの要求に応答して、車両の制御のハンドオフと関連付けられた安全性の可能性を決定することを更に備える、実施例６３～６７のいずれかの方法を含む。

【0354】

実施例６９は、エリアの高精細度マップを車両が利用不能であるエリアに車両が入ることに応答して、車両の制御のハンドオフと関連付けられた安全性の可能性を決定することを更に備える、実施例６３～６８のいずれかの方法を含む。

【0355】

実施例７０は、信号品質測定基準がセンサデータの信号対雑音比を少なくとも部分的に示す、実施例６３～６９のいずれかの方法を含む。

【0356】

実施例７１は、信号品質測定基準がセンサデータの分解能を少なくとも部分的に示す、実施例６３～７０のいずれかの方法を含む。

【0357】

実施例７２は、実施例６３～７１の方法の１つまたは複数を実施する、メモリとメモリに結合された処理回路類とを備える、装置を含む。

【0358】

実施例７３は、実施例６３～７１の方法の１つまたは複数を実施する手段を備える、システムを含む。

【0359】

実施例７４は、命令が実行されると、装置を現実化するか、または実施例６３～７１のいずれか１つのような方法を実現する、命令を備える少なくとも１つの機械可読媒体を含む。

【0360】

実施例７５は、車両の内部に位置する少なくとも１つのセンサからセンサデータを収集することと、センサデータを分析して、車両内部の人物の身体的状態を決定することと、その人物の身体的状態に少なくとも部分的に基づいて、その人物が車両を安全に操作できることが予期されるか否かを示す、ハンドオフ判定を生成することと、を備える、方法を含む。

【0361】

実施例７６は、車両内部の人物の履歴運転データを特定することと、その人物の履歴運転データに更に基づいて、ハンドオフ判定を生成することとを更に備える、実施例７５の方法を含む。

【0362】

実施例７７は、センサデータを分析して、車両外部の条件を示すコンテキストを決定することと、コンテキストに更に基づいてハンドオフ判定を生成することとを更に備える、実施例７５～７６のいずれかの方法を含む。

【0363】

実施例７８は、車両内部の人物の身体的状態が、車両内部の人物の画像データを備えるセンサデータに少なくとも部分的に基づく、実施例７５～７７のいずれかの方法を含む。

【0364】

実施例７９は、車両内部の人物の身体的状態が、車両内部の人物の音声データを備えるセンサデータに少なくとも部分的に基づく、実施例７５～７８のいずれかの方法を含む。

【0365】

実施例８０は、車両内部の人物の身体的状態が、車両内部の人物の温度データを備えるセンサデータに少なくとも部分的に基づく、実施例７５～７９のいずれかの方法を含む。

【0366】

実施例８１は、車両内部の人物の身体的状態が、触覚センサからの圧力データを備えるセンサデータに少なくとも部分的に基づく、実施例７５～８０のいずれかの方法を含む。

【0367】

実施例８２は、車両内部の人物の身体的状態が、その人物によって着用される健康追跡デバイスから受信されるデータに少なくとも部分的に基づく、実施例７５～８１のいずれかの方法を含む。

【0368】

実施例８３は、センサデータに基づいて、車両内部の人物によって実施される特定の活動を決定することを更に備え、車両内部の人物の身体的状態が、決定された活動に少なくとも部分的に基づく、実施例７５～８２のいずれかの方法を含む。

【0369】

実施例８４は、車両内部の人物または１人もしくは複数の乗員によって生じる音を分離するため、センサデータの音声データを前処理することを更に備え、車両内部の人物の身体的状態が、前処理された音声データに少なくとも部分的に基づく、実施例７５～８３のいずれかの方法を含む。

【0370】

実施例８５は、センサデータが、車両内で再生される媒体、車両内部の光のレベル、人物と１つもしくは複数のダッシュボード制御との間の対話の量、窓の開口レベル、車室内温度制御システムの状態、または人物の電話の状態のうち１つまたは複数を有する、実施例７５～８４のいずれかの方法を含む。

【0371】

実施例８６は、人物の身体的状態が、センサデータを入力として使用して機械学習アルゴリズムを使用して実施される、実施例７５～８５のいずれかの方法を含む。

【0372】

実施例８７は、機械学習アルゴリズムを使用して、ハンドオフ判定を生成することを更に備える、実施例７５～８６のいずれかの方法を含む。

【0373】

実施例８８は、実施例７５～８７の方法の１つまたは複数を実施する、メモリとメモリに結合された処理回路類とを備える、装置を含む。

【0374】

実施例８９は、実施例７５～８７の方法の１つまたは複数を実施する手段を備える、システムを含む。

【0375】

実施例９０は、命令が実行されると、装置を現実化するか、または実施例１～１３のいずれか１つのような方法を実現する、命令を備える少なくとも１つの機械可読媒体を含む。

【0376】

実施例９１は、自律車両のコントローラによって、自律車両を自律運転モードで操作することと、自律車両の制御をコントローラ以外のエンティティによってテイクオーバする要求を受信することと、自律車両の制御をテイクオーバする要求の受信に応答して、要求しているエンティティの認証情報をプロンプトすることと、プロンプトに応答して入力を受信することと、受信された入力に基づいた、要求しているエンティティの認証に応答して、自律車両の制御をテイクオーバする要求を許可することと、を備える、方法を含む。

【0377】

実施例９２は、要求しているエンティティの認証情報をプロンプトすることが、要求しているエンティティに認証のために生体認証を提供するようにプロンプトすることを有する、実施例９１の方法を含む。

【0378】

実施例９３は、生体認証が、指紋、声認識のための声サンプル、および顔認識のための顔サンプルのうち１つまたは複数を含む、実施例９２の方法を含む。

【0379】

実施例９４は、要求しているエンティティが自律車両内部の人物を含む、実施例９１～９３のいずれか１つの方法を含む。

【0380】

実施例９５は、要求しているエンティティが自律車両から遠隔にいる人物を含む、実施例９１～９３のいずれか１つの方法を含む。

【0381】

実施例９６は、要求しているエンティティが自律車両に近接する１つまたは複数の他の自律車両を含む、実施例９１～９３のいずれか１つの方法を含む。

【0382】

実施例９７は、実施例９１～９６の方法の１つまたは複数を実施する、メモリとメモリに結合された処理回路類とを備える、装置を含む。

【0383】

実施例９８は、実施例９１～９６の方法の１つまたは複数を実施する手段を備える、システムを含む。

【0384】

実施例９９は、少なくとも１つのコンピュータプロセッサによって実行されると、少なくとも１つのコンピュータプロセッサが実施例９１～９６の方法の動作を実現できるように動作可能な、コンピュータ実行可能命令を有する、１つまたは複数の有形コンピュータ可読非一時的記憶媒体を備える、製品を含む。

【0385】

実施例１００は、人間の入力に基づいて制御される自律車両を手動動作モードで操作することと、自律車両内部の複数のセンサからセンサデータを受信することと、センサデータの分析に基づいて、人間の入力が安全ではないと検出することと、安全ではない人間の入力の検出に応答して、自律動作モードで自律車両を操作することと、を備える、方法を含む。

【0386】

実施例１０１は、人間の入力が安全ではないと検出することが、入力を提供する人間が気が散っていると決定すること、入力を提供する人間に障害があると決定すること、および入力を提供する人間に意識がないと決定することのうち１つまたは複数を有する、実施例１００の方法を含む。

【0387】

実施例１０２は、実施例１００～１０１の方法の１つまたは複数を実施する、メモリとメモリに結合された処理回路類とを備える、装置を含む。

【0388】

実施例１０３は、実施例１００～１０１の方法の１つまたは複数を実施する手段を備える、システムを含む。

【0389】

実施例１０４は、少なくとも１つのコンピュータプロセッサによって実行されると、少なくとも１つのコンピュータプロセッサが実施例１００～１０１の方法の動作を実現できるように動作可能な、コンピュータ実行可能命令を有する、１つまたは複数の有形コンピュータ可読非一時的記憶媒体を備える、製品を含む。

【0390】

実施例１０５は、自律車両の制御システムによって、自律車両に結合された複数のセンサから取得されたセンサデータに基づいて、自律車両を自律動作モードで操作することと、自律車両の制御システムによって、自律車両の乗員によるテイクオーバ要求を検出することと、自律車両の制御システムによって、センサデータに基づいて、要求されたテイクオーバが安全か否かを決定することと、要求されたテイクオーバが安全ではないという決定に応答して、要求されたテイクオーバを阻止することと、を備える、方法を含む。

【0391】

実施例１０６は、要求されたテイクオーバが安全ではないという決定に応答して、自律動作モードを修正することを更に備える、実施例１０５の方法を含む。

【0392】

実施例１０７は、決定に応答して乗員に入力をプロンプトすることと、プロンプトに応答した乗員からの入力を受信することと、を更に備え、自律動作モードを修正することが受信された入力に基づく、実施例１０６の方法を含む。

【0393】

実施例１０８は、自律車両に結合された複数のセンサが、自律車両内部の内部センサを含み、要求されたテイクオーバが安全か否かを決定することが、内部センサから受信されるセンサデータに基づく、実施例１０５の方法を含む。

【0394】

実施例１０９は、内部センサがカメラおよびマイクロフォンのうち１つまたは複数を含む、実施例１０８の方法を含む。

【0395】

実施例１１０は、要求されたテイクオーバが正規のものであるという決定に応答して、テイクオーバ要求を許可することを更に備える、実施例１０５～１０９のいずれか１つの方法を含む。

【0396】

実施例１１１は、要求されたテイクオーバが安全ではないという決定に応答して、テイクオーバ要求を阻止することを更に備える、実施例１０５～１０９のいずれか１つの方法を含む。

【0397】

実施例１１２は、要求されたテイクオーバが安全ではないか否かの決定が、自律運転パイプラインの感知／知覚フェーズの間に実施される、実施例１０５～１１１のいずれか１つの方法を含む。

【0398】

実施例１１３は、要求されたテイクオーバを阻止することが、自律運転パイプラインの行動／制御フェーズの間に実施される、実施例１０５～１１２のいずれか１つの方法を含む。

【0399】

実施例１１４は、自律動作モードの修正が、自律運転パイプラインの計画フェーズの間に実施される、実施例１０７の方法を含む。

【0400】

実施例１１５は、実施例１０５～１１４の方法の１つまたは複数を実施する、メモリとメモリに結合された処理回路類とを備える、装置を含む。

【0401】

実施例１１６は、実施例１０５～１１４の方法の１つまたは複数を実施する手段を備える、システムを含む。

【0402】

実施例１１７は、少なくとも１つのコンピュータプロセッサによって実行されると、少なくとも１つのコンピュータプロセッサが実施例１０５～１１４の方法の動作を実現できるように動作可能な、コンピュータ実行可能命令を有する、１つまたは複数の有形コンピュータ可読非一時的記憶媒体を備える、製品を含む。

【0403】

実施例１１８は、監督システムによって、自律車両の少なくとも１つのサブシステムを監視することと、監督システムによって、少なくとも１つのサブシステムの監視に基づいて、第１の自律レベルから第２の自律レベルへの自律車両の自律レベルの変更を開始することと、を備える、方法を含む。

【0404】

実施例１１９は、自律車両の自律レベルの変更を遠隔サーベイランスシステムに通信することを更に備える、実施例１１８の方法を含む。

【0405】

実施例１２０は、時間に伴う自律レベルおよびセンサ状態の履歴を記録することを更に備える、実施例１１８～１１９のいずれかの方法を含む。

【0406】

実施例１２１は、少なくとも１つのサブシステムがセンササブシステムを有し、自律レベルの変更が、センササブシステムに対する変更に少なくとも部分的に基づく、実施例１１８～１２０のいずれかの方法を含む。

【0407】

実施例１２２は、少なくとも１つのサブシステムが計画サブシステムを有し、自律レベルの変更が、計画サブシステムに対する変更に少なくとも部分的に基づく、実施例１１８～１２１のいずれか１つまたは複数の方法を含む。

【0408】

実施例１２３は、少なくとも１つのサブシステムが実行サブシステムを有し、自律レベルの変更が、実行サブシステムに対する変更に少なくとも部分的に基づく、実施例１１８～１２２のいずれか１つまたは複数の方法を含む。

【0409】

実施例１２４は、監督システムが少なくとも１つのサブシステムの機能的保証を監視する、実施例１１８～１２３のいずれか１つまたは複数の方法を含む。

【0410】

実施例１２５は、包括的認知監督システムが少なくとも１つのサブシステムの品質保証を監視する、実施例１１８～１２４のいずれか１つまたは複数の方法を含む。

【0411】

実施例１２６は、実施例１１８～１２５の方法の１つまたは複数を実施する、メモリとメモリに結合された処理回路類とを備える、装置を含む。

【0412】

実施例１２７は、実施例１１８～１２５の方法の１つまたは複数を実施する手段を備える、システムを含む。

【0413】

実施例１２８は、命令が実行されると、装置を現実化するか、または実施例１１８～１２５のいずれか１つのような方法を実現する、命令を備える少なくとも１つの機械可読媒体を含む。

【0414】

実施例１２９は、自律車両のシステム故障を決定することと、自律車両の自律レベルを、運転者のテイクオーバを要しない第１のレベルに低減することができると決定することと、自律レベルが第１のレベルに低減されると運転者に警告することと、自律レベルを第１のレベルに低減することと、を備える、方法を含む。

【0415】

実施例１３０は、自律車両の追加のシステム故障があると決定することと、自律レベルを第２のレベルに低減することができると決定することと、自律レベルが第２のレベルに低減されると運転者に警告することと、自律レベルを第２のレベルに低減することと、を更に備える、実施例１２９の方法を含む。

【0416】

実施例１３１は、運転者の関与を確認することを更に備える、実施例１２９～１３０のいずれか１つまたは複数の方法を含む。

【0417】

実施例１３２は、運転者の関与が運転者を監視することを有する、実施例１３１の方法を含む。

【0418】

実施例１３３は、自律車両の追加のシステム故障があると決定することと、車両の自律が不活性化されなければならないと決定することと、車両の自律が不活性化されなければならないとの決定に応答して、運転者へのハンドオフを試行することと、を更に備える、実施例１２９～１３２のいずれか１つまたは複数の方法を含む。

【0419】

実施例１３４は、ハンドオフが成功したかを決定することを更に備える、実施例１３３の方法を含む。

【0420】

実施例１３５は、ハンドオフが成功した場合、車両の自律を不活性化することを更に備える、実施例１３４の方法を含む。

【0421】

実施例１３６は、ハンドオフが成功しなかった場合、緊急システムを活性化することを更に備える、実施例１３４の方法を含む。

【0422】

実施例１３７は、緊急システムが自律車両を安全に停車させる、実施例１３６の方法を含む。

【0423】

実施例１３８は、実施例１２９～１３７のいずれか１つまたは複数を実施する手段を備える、システムを含む。

【0424】

実施例１３９は、手段が、命令を備える少なくとも１つの機械可読媒体を有し、命令が、実行されると、実施例１２９～１３７のいずれか１つまたは複数の方法を実現する、実施例１３８のシステムを含む。

【0425】

実施例１４０は、ルート上における運転者への自律車両の少なくとも１つのハンドオフ場所を決定することと、運転者の特性に関係する情報を受信することと、運転者の現在の注意状態に関係する情報を受信することと、少なくとも１つのハンドオフ場所それぞれにいる間の予期される運転者挙動を決定することと、を備える、方法を含む。

【0426】

実施例１４１は、運転者の特性に関係する情報が一般情報を有する、実施例１４０の方法を含む。

【0427】

実施例１４２は、運転者の特性に関係する情報が運転者に特異的な情報を有する、実施例１４０～１４１のいずれか１つまたは複数の方法を含む。

【0428】

実施例１４３は、運転者がハンドオフの準備ができているか否かを決定することを更に備える、実施例１４０～１４２のいずれか１つまたは複数の方法を含む。

【0429】

実施例１４４は、運転者がハンドオフの準備ができているという決定に応答して、車両の制御を運転者にハンドオーバすることを更に備える、実施例１４３の方法を含む。

【0430】

実施例１４５は、運転者がハンドオフの準備ができていない場合、ハンドオフの代案を計算することを更に備える、実施例１４３の方法を含む。

【0431】

実施例１４６は、代案が代替ルートを見つけることを有する、実施例１４５の方法を含む。

【0432】

実施例１４７は、代案が車両を停車させることを有する、実施例１４５の方法を含む。

【0433】

実施例１４８は、運転者の特性に関係する情報を更新することを更に備える、実施例１４０～１４７のいずれか１つまたは複数の方法を含む。

【0434】

実施例１４９は、実施例１４０～１４８のいずれか１つまたは複数を実施する手段を備える、システムを含む。

【0435】

実施例１５０は、手段が、命令を備える少なくとも１つの機械可読媒体を有し、命令が、実行されると、実施例１４０～１４８のいずれか１つまたは複数の方法を実現する、実施例１４９のシステムを含む。

【0436】

実施例１５１は、車両乗員活動監視モジュールと、個人化車両乗員能力データベースと、一般車両乗員能力データベースと、ハンドオフ予報モジュールと、実行査定および最適化モジュールと、ハンドオフ取扱いモジュールとを備える、システムを含む。

【0437】

このように、主題の特定の実施形態を記載してきた。他の実施形態が、以下の特許請求の範囲内にある。いくつかの事例では、特許請求の範囲で列挙される行動を、異なる順序で実施し、かつ依然として望ましい結果を達成することができる。それに加えて、添付図面に示されるプロセスは、望ましい結果を達成するのに、図示される特定の順序または連続順序を必ずしも要するものではない。
他の可能な請求項
（項目１）
車両の複数のセンサからセンサデータを受信する、少なくとも１つのインターフェースと、
１つまたは複数のプロセッサであって、
上記センサデータに基づいた経路計画にしたがって上記車両の運転を自律的に制御し、
上記車両の自律制御を停止すべきと決定し、
遠隔コンピューティングシステムが上記車両の運転を遠隔で制御するように、上記遠隔コンピューティングシステムにハンドオフ要求を送り、
運転命令データを上記遠隔コンピューティングシステムから受信し、
上記運転命令データに含まれる命令に基づいて上記車両の運転を制御する、１つまたは複数のプロセッサと
を備える、装置。
（項目２）
上記運転命令データが、上記遠隔コンピューティングシステムにおける人間のユーザの入力から生成される、項目１に記載の装置。
（項目３）
上記１つまたは複数のプロセッサが退避イベントを検出し、上記車両が上記退避イベントと関連して退避し運転を停止し、上記ハンドオフ要求が上記退避イベントに応答して送られる、項目１に記載の装置。
（項目４）
上記車両の上記自律制御を停止すべきと決定することが、特定の機械学習モデルを使用して、経路計画の次の区間における条件が、次の区間の間は自律運転が困難であることを提示すると予測することを有する、項目１に記載の装置。
（項目５）
上記１つまたは複数のプロセッサが、上記車両の１つまたは複数の故障したセンサの検出に基づいて、上記車両の自律制御を停止すべきと決定する、項目１に記載の装置。
（項目６）
上記１つまたは複数のプロセッサが、適格な乗員が上記車両内に存在しないと決定し、適格な乗員が存在しないとの決定に少なくとも部分的に基づいて、上記ハンドオフ要求が送られる、項目１に記載の装置。
（項目７）
上記１つまたは複数のプロセッサが、上記センサデータを上記遠隔コンピューティングシステムに送って、上記車両の周囲の動的表現を上記遠隔コンピューティングシステムの人間のユーザに対して提示する、項目１に記載の装置。
（項目８）
上記センサデータが映像データを有する、項目７に記載の装置。
（項目９）
上記１つまたは複数のプロセッサが、上記車両の制御が遠隔バレットサービスにハンドオーバされることを特定する、警告を上記車両の乗員に通信する、項目１に記載の装置。
（項目１０）
上記１つまたは複数のプロセッサが、
上記経路計画に沿った条件の変化を検出し、
上記車両の上記運転の制御を上記遠隔コンピューティングシステムから上記車両の自律運転論理に戻す、
項目１に記載の装置。
（項目１１）
命令を格納し、上記命令が機械によって実行されると、上記機械に、
車両のセンサのセットから生成されたセンサデータに基づいた経路計画にしたがって車両の運転を自律的に制御させ、
上記車両の自律制御を停止すべきと決定させ、遠隔コンピューティングシステムが上記車両の運転を遠隔で制御するように、上記遠隔コンピューティングシステムにハンドオフ要求を送らせ、
運転命令データを上記遠隔コンピューティングシステムから受信させ、
上記運転命令データに含まれる命令に基づいて上記車両の運転を制御させる、
コンピュータ可読媒体。
（項目１２）
上記運転命令データが、上記遠隔コンピューティングシステムにおける人間のユーザの入力から生成される、項目１１に記載の媒体。
（項目１３）
上記命令が機械によって実行されると、上記機械に退避イベントを検出させ、上記車両が上記退避イベントと関連して退避し運転を停止し、上記ハンドオフ要求が上記退避イベントに応答して送られる、項目１１に記載の媒体。
（項目１４）
上記車両の自律制御を停止すべきと決定することが、特定の機械学習モデルを使用して、上記経路計画の次の区間における条件が、上記次の区間の間は自律運転が困難であることを提示すると予測することを有する、項目１１に記載の媒体。
（項目１５）
上記車両における１つまたは複数の故障したセンサの検出に基づいて、上記車両の自律制御を停止すべきと決定される、項目１１に記載の媒体。
（項目１６）
上記命令が機械によって実行されると、上記機械に、適格な乗員が上記車両内に存在しないと決定させ、適格な乗員が存在しないとの決定に少なくとも部分的に基づいて、上記ハンドオフ要求が送られる、項目１１に記載の媒体。
（項目１７）
上記命令が機械によって実行されると、上記機械に、上記センサデータを上記遠隔コンピューティングシステムに送らせて、上記車両の周囲の動的表現を上記遠隔コンピューティングシステムの人間のユーザに対して提示する、項目１１に記載の媒体。
（項目１８）
上記センサデータが映像データを有する、項目１７に記載の媒体。
（項目１９）
上記命令が機械によって実行されると、上記機械に、上記車両の制御が遠隔バレットサービスにハンドオーバされることを特定する、警告を上記車両の乗員に提示させる、項目１１に記載の媒体。
（項目２０）
上記命令が機械によって実行されると、上記機械に、
上記経路計画に沿った条件の変化を検出させ、
上記車両の上記運転の制御を上記遠隔コンピューティングシステムから上記車両の自律運転論理に戻させる、
項目１１に記載の媒体。
（項目２１）
車両のセンサのセットから生成されたセンサデータに基づいた経路計画にしたがって車両の運転を自律的に制御する手段と、
上記車両の自律制御を停止すべきと決定する手段と、
遠隔コンピューティングシステムが上記車両の運転を遠隔で制御するように、上記遠隔コンピューティングシステムにハンドオフ要求を送る手段と、
運転命令データを上記遠隔コンピューティングシステムから受信する手段と、
上記運転命令データに含まれる命令に基づいて上記車両の運転を制御する手段と、
を備える、システム。
（項目２２）
上記運転命令データが、上記遠隔コンピューティングシステムにおける人間のユーザの入力から生成される、項目２１に記載のシステム。
（項目２３）
退避イベントを検出する手段を更に備え、上記車両が上記退避イベントと関連して退避し運転を停止し、上記ハンドオフ要求が上記退避イベントに応答して送られる、項目２１に記載のシステム。
（項目２４）
上記車両の自律制御を停止すべきと決定することが、特定の機械学習モデルを使用して、上記経路計画の次の区間における条件が、上記次の区間の間は自律運転が困難であることを提示すると予測することを有する、項目２１に記載のシステム。
（項目２５）
センサデータを生成する複数のセンサと、
車両の動きを物理的に制御する制御システムと、
処理回路類であって、
上記制御システムと通信することによって、上記センサデータに基づいた経路計画にしたがって車両の運転を自律的に制御し、
上記車両の自律制御を停止すべきと決定し、
遠隔コンピューティングシステムが上記車両の運転を遠隔で制御するように、上記遠隔コンピューティングシステムにハンドオフ要求を送り、
運転命令データを上記遠隔コンピューティングシステムから受信し、
上記制御システムと通信することによって、上記運転命令データに含まれる命令に基づいて上記車両の運転を制御する、処理回路類と、
を備える、車両。
（項目２６）
ルート上における運転者への自律車両の少なくとも１つのハンドオフ場所を決定することと、
運転者の特性に関係する情報を受信することと、
上記運転者の現在の注意状態に関係する情報を受信することと、
上記少なくとも１つのハンドオフ場所それぞれにいる間の予期される運転者挙動を決定することと、
を備える、方法。
（項目２７）
車両に対する人間の入力に応答して、第１の１つまたは複数の制御信号のセットを生成することと、
上記第１の１つまたは複数の制御信号のセットが許容不能な加速を引き起こすであろうという決定に応答して、
許容可能な加速を特定し、
上記許容可能な加速を第２の１つまたは複数の制御信号のセットに変換し、
上記第２の１つまたは複数の制御信号のセットを、上記第１の１つまたは複数の制御信号のセットの代わりに車両作動システムに提供することと、
を備える、方法。
（項目２８）
自律車両のコントローラによって、上記自律車両を自律運転モードで操作することと、
上記自律車両の制御を上記コントローラ以外のエンティティによってテイクオーバする要求を受信することと、
上記自律車両の制御をテイクオーバする上記要求の受信に応答して、要求している上記エンティティに認証情報をプロンプトすることと、
上記プロンプトに応答して入力を受信することと、
受信された上記入力に基づいた、要求している上記エンティティの認証に応答して、上記自律車両の制御をテイクオーバする上記要求を許可することと、
を備える、方法。
（項目２９）
自律車両の制御システムによって、上記自律車両に結合された複数のセンサから取得されたセンサデータに基づいて、上記自律車両を自律動作モードで操作することと、
上記自律車両の上記制御システムによって、上記自律車両の乗員によるテイクオーバ要求を検出することと、
上記自律車両の上記制御システムによって、上記センサデータに基づいて、要求された上記テイクオーバが安全か否かを決定することと、
要求された上記テイクオーバが安全ではないという決定に応答して、要求された上記テイクオーバを阻止することと、
を備える、方法。
（項目３０）
自律車両のシステム故障を決定することと、
上記自律車両の自律レベルを、運転者のテイクオーバを要しない第１のレベルに低減することができると決定することと、
上記自律レベルが上記第１のレベルに低減されると上記運転者に警告することと、
上記自律レベルを上記第１のレベルに低減することと、
を備える、方法。

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

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】