知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-12-04
(45)【発行日】2024-12-12
(54)【発明の名称】車両のナビゲーションのためのシステム、方法及び計算装置
(51)【国際特許分類】
G01C 21/26 20060101AFI20241205BHJP
G08G 1/09 20060101ALI20241205BHJP
【ＦＩ】
G01C21/26 A
G08G1/09 D
G08G1/09 H
【請求項の数】
4
(21)【出願番号】P 2023117218
(22)【出願日】2023-07-19
(65)【公開番号】P2024013227
(43)【公開日】2024-01-31
【審査請求日】2023-07-19
(31)【優先権主張番号】17/867,817
(32)【優先日】2022-07-19
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110001678
【氏名又は名称】藤央弁理士法人
(72)【発明者】
【氏名】クンドゥ スブラタ クマル
【審査官】白石 剛史
(56)【参考文献】
【文献】特開２０２２－０４１９２３（ＪＰ，Ａ）
【文献】特開２０１９－１８４５９０（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０１Ｃ ２１／２６
Ｇ０８Ｇ １／０９
(57)【特許請求の範囲】
【請求項1】
システムであって、１以上のプロセッサと、
前記１以上のプロセッサによって実行可能な命令を格納する、１以上の計算機読み取り可能な記憶媒体と、を含み、
前記１以上のプロセッサが実行する処理は、
車両の出発地位置と目的地位置との間の複数の候補ルートを決定し、
前記複数の候補ルートの各候補ルートを複数の道路セグメントにセグメント化し、
前記車両に搭載された、前記車両の周囲を監視するための車両センサのタイプの情報を含む、車両センサ構成情報を受信し、
前記車両に搭載された車両センサの視野、または前記車両に搭載された計算リソースの少なくとも一方が、前記複数の候補ルートの第１の候補ルートの道路セグメントの自律ナビゲーションに関連する閾値を満たさないと判定し、
前記車両に搭載された車両センサの視野または前記車両に搭載された計算リソースの少なくとも一方が、前記道路セグメントの自律ナビゲーションに関連する閾値を満たさないと判定する処理は、
前記自律ナビゲーションのために前記車両が監視すべき領域である観測ゾーンと、前記車両センサの視野とを比較して、前記観測ゾーンの一部が前記車両センサの視野によって覆われていないと判定することを含み、
前記１以上のプロセッサが実行する処理は、
前記車両の外部の計算装置に、前記観測ゾーンの前記覆われていない部分に関連する情報を送信し、
前記車両が前記第１の候補ルートの道路セグメントを自律的にナビゲートすることに関連する前記閾値を満たすことを可能にするために、前記計算装置が、前記車両のために少なくとも１つの計算タスクを実行することをスケジュールされることの決定に基づいて、前記車両のために、前記第１の候補ルートを選択し、
前記少なくとも１つの計算タスクは、カメラを含む前記道路セグメントにおける少なくとも１つのセンサからのセンサデータにアクセスし、前記車両が前記道路セグメントを通過するときに前記車両に前記観測ゾーンの前記覆われていない部分に関する情報をリアルタイムで与える、システム。
【請求項2】
請求項１に記載のシステムであって、前記道路セグメントにおける少なくとも１つのセンサは、前記道路セグメントに配置されたインフラセンサ、または前記道路セグメントを通過する他の車両に搭載された車両センサの少なくとも１つである、システム。
【請求項3】
請求項１に記載のシステムであって、前記１以上のプロセッサが実行する処理は、
前記第１の候補ルートの通過中に前記車両が利用可能な自律走行の量が、前記複数の候補ルートの他の候補ルートを上回ると判定することに少なくとも基づいて、前記第１の候補ルートを前記車両に提供することをさらに含む、システム。
【請求項4】
請求項１に記載のシステムであって、前記１以上のプロセッサが実行する処理は、
前記計算装置に、前記車両に搭載された計算リソースが前記道路セグメントの自律ナビゲーションに関連する前記閾値を満たさないという指示を送信し、
前記計算装置から、前記計算装置が、前記車両が前記道路セグメントを通過すると予測される予測時間に基づくタイミングで、前記道路セグメントでの自律ナビゲーションを支援するために前記車両に提供する１以上の計算リソースをスケジューリングしたとの指示を受信する、ことをさらに含む、システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、車両のナビゲーションに関する。
【背景技術】
【0002】
先進運転支援システム（ＡＤＡＳ）及び自律走行（ＡＤ）システムは、安全性の向上、ナビゲーションの自動化、利便性の向上、効率性の向上のために、車両制御を自動化またはその他の方法で強化する。従来、部分的にしか自動化されていない車両には、コストを抑え、市場に受け入れられやすいように、限られた数のセンサとプロセッサが搭載されている。自動運転のレベルを半自動運転や完全自動運転まで高めるには、車両に異なるタイプのセンサを搭載し、車両の周囲を継続的に監視することが必要である。さらに、これらの半自動または完全自動車両は通常、障害物の認識やその他のナビゲーション機能の実行など、すべてのセンサデータをリアルタイムで処理することが必要である。しかし、異なるタイプのセンサからの大量のセンサデータをリアルタイムで処理するためには、処理の大きなキャパシティが必要となり、車両のコストが大幅に上昇し得る。
【先行技術文献】
【特許文献】
【0003】
【文献】米国特許出願公開第２０２１／０１４６９４４号
【発明の概要】
【0004】
本発明の一態様のシステムは、１以上のプロセッサと、前記１以上のプロセッサによって実行可能な命令を格納する、１以上の計算機読み取り可能な記憶媒体と、を含み、前記１以上のプロセッサが実行する処理は、車両の出発地位置と目的地位置との間の複数の候補ルートを決定し、前記複数の候補ルートの各候補ルートを複数の道路セグメントにセグメント化し、前記車両に搭載された車両センサの車両センサ構成情報を受信し、前記車両に搭載された車両センサの視野、または前記車両に搭載された計算リソースの少なくとも一方が、前記複数の候補ルートの第１の候補ルートの道路セグメントの自律ナビゲーションに関連する閾値を満たさないと判定し、前記車両が前記第１の候補ルートの道路セグメントを自律的にナビゲートすることに関連する前記閾値を満たすことを可能にするために、前記車両の外部の計算装置が、前記車両のために少なくとも１つの計算タスクを実行することをスケジュールされることの決定に基づいて、前記車両のために、前記第１の候補ルートを選択する。
【0005】
本発明の一態様の方法は、車両に搭載された１以上のプロセッサが、ネットワークを介してサービス計算装置に、前記車両に搭載されたセンサに関連するセンサ情報を含む車両情報と、目的地位置とを送信し、前記１以上のプロセッサが、前記サービス計算装置から、前記目的地位置まで前記車両を自律的に走行させるための複数の道路セグメントを含むルートを示すルーティング情報を受信し、前記１以上のプロセッサが、前記ルートに沿って前記車両をナビゲートし、前記１以上のプロセッサが、前記ルートの前記複数の道路セグメント内の道路セグメントに関連付けられたサービス計算装置から、前記道路セグメントの処理結果を受信し、前記１以上のプロセッサが、前記受信した処理結果を、前記道路セグメントの自律ナビゲーションの間に、前記車両に搭載されたセンサから前記１以上のプロセッサによって決定された認識データと組み合わせて使用する、ことを含む。
【0006】
本発明の一態様の計算装置は、実行可能な命令によって処理を実行するように構成された１以上のプロセッサを含み、前記処理は、サービス計算装置から、前記計算装置が関連付けられている道路セグメントを第１の車両が通過すると予測される第１の時刻を含む、前記第１の車両に関連する第１の車両情報を受信し、前記第１の車両が、前記道路セグメントの自律ナビゲーションに関連付けられた第１の閾値レベルを満たさないセンシングリソースまたは計算リソースの少なくとも一方を有すると判定することに基づいて、前記第１の時刻における前記計算装置の計算負荷が第２の閾値より小さいと判定し、前記サービス計算装置に、前記計算装置が前記第１の車両が前記道路セグメントを自律的にナビゲートすることを支援するための少なくとも１つの計算タスクを実行することをスケジュールされている、という指示を送信し、前記第１の車両が前記道路セグメントに到達したことを検出することに基づいて、前記第１の車両に前記計算タスクの結果を提供する。
【図面の簡単な説明】
【0007】
【図1】実施形態による、車両のリソースを割り当てるためのシステム例を示す図である。
【図2】実施態様による車両センサ構成例を示す図である。
【図3】実施態様による車両センサ構成例を示す図である。
【図4】実施態様による車両センサ構成例を示す図である。
【図5】実施態様による、車両のリソースを割り当てるためのシステムのハードウェア構成例を示す図である。
【図6】実施形態による、候補ルートから最適ルートを決定するための例示的なプロセスを示すフロー図である。
【図8】実施態様による、車両の最適ルートを選択するための例示的なアーキテクチャとプロセスを示す、フロー図とブロック図を組み合わせた図である。
【図9】実施態様による、候補ルートから最適ルートを決定するための例示的なプロセスを示すフロー図である。
【図11】実施形態による、出発地位置と目的地位置との間の候補ルートを決定する例を示す図である。
【図12A】実施態様による交差点の例を示す図である。
【図12B】実施態様による交差点の例を示す図である。
【図13】実施形態による、様々な異なる基準についてＰＯＺを決定するための例示的なプロセスを示すフロー図である。
【図14】実施態様に従って、現在の道路セグメントが交差点機能領域の外側に該当するＰＯＺを決定する例を示す図である。
【図15】実施態様に従ってＰＯＺを決定する例を示す図である。
【図16】実施態様に従って、ＶＥＣが車両にリソースを提供できるかどうかを決定するための例示的なプロセスを示すフロー図である。
【図17】実施態様による自律走行制御アーキテクチャの例示的な概略図である。
【発明を実施するための形態】
【0008】
以下において、図を参照して詳細な説明を行う。図において、参照番号の左端の桁は、参照番号が最初に現れる図を識別する。異なる図において同じ参照番号を使用することは、類似または同一の項目または特徴を示す。
【0009】
本明細書の実施形態は、自律走行（ＡＤ）車両またはＡＤＡＳ車両などの車両のリソースを割り当てるための技術及び配置に向けられている。本明細書のいくつかの実施形態は、車両が通過すると予想されるルートに沿って、車両が利用可能な計算リソースを特定する。利用可能な計算リソースの決定は、車両に搭載されて利用可能と予想される計算リソースを含んでもよく、ルートを通過する間に車両によって利用され得る車両の外部の他の計算リソースも含んでもよい。さらに、本明細書の実施形態は、車両が自律走行を実行できる時間を最大化するために、車両がルートに沿って予想される場所に到達する前に、車両の計算タスクを効果的に割り当てることができる。これは、人間によって操作される、または、センサデータ処理が不十分な状態で自律的に操作されることとは対照的に、車両が安全に自律的に操作される時間を増やすことによって、車両の安全性を高めるのに役立つ。
【0010】
本明細書の実施形態は、車両の最適ルートを決定するために使用され得る予防観測ゾーン（ＰＯＺ：Ｐｒｅｃａｕｔｉｏｎａｒｙ Ｏｂｓｅｒｖａｔｉｏｎ Ｚｏｎｅ）の計算を含み得る。ＰＯＺの決定は、最適ルートを選択する際に車両に採用される車載センサのタイプ及び能力を考慮することができ、さらに、各候補ルート上の道路の特徴、各候補ルートをナビゲートするために必要な視野（ＦＯＶ）、及び後述するような他の事項を考慮することができる。
【0011】
いくつかのケースにおいて、ルートに沿った各場所における予想される計算タスクは、車両が通過すると予想されるルートに沿ったＰＯＺを決定することに少なくとも部分的に基づいて決定され得る。例えば、ルートに沿った特定のゾーンが、より大量のセンサリソース及び／または計算リソース（例えば、車両に搭載されて利用可能なリソースよりも多くのリソース）を必要とする場合、本実施形態におけるシステムは、ルートに沿った任意のタスクオフロード領域を事前に特定してもよく、予想されるセンシングタスク及び／または認識タスクのうちの１以上を、ルートに沿って配置され得る利用可能な計算リソースに効果的に割り当ててもよい。したがって、実施形態は、選択されたルートに沿った計算負荷の高いゾーンを事前に決定し、これらのゾーンを、車両にとってセンシングタスクオフロード、計算タスクオフロード、及び／または計算タスク共有が望ましい場所として指定することができる。
【0012】
実施形態では、システムは、ルートの近くに位置し、１または複数の路側ユニットを介して近くの車両と通信することができる１または複数の車両エッジ計算装置（ＶＥＣ）に、センシング及び計算タスクをオフロードすることができる。例えば、データセンタまたは他のクラウドインフラストラクチャにある計算装置との通信とは対照的に、本明細書におけるＶＥＣは、クラウドベースのサーバの比較的遠隔の位置と比較して、路側により近い位置に処理ユニットがあるため、タイムクリティカルな計算タスクを実行するのに適した位置にある。例えば、ＶＥＣは、車両と車外の計算装置との間のデータ通信のネットワーク待ち時間を回避または実質的に短縮することができる。さらに、ＶＥＣの近くにある利用可能なセンシング及び計算リソースを有する他の車両は、センシング及び／または計算リソースをＶＥＣに提供し、データを処理及び／またはデータを車両に対して提供することもできる。
【0013】
本明細書の実施形態は、ＶＥＣ、過剰な計算キャパシティを有する他の車両、及びより遠隔に位置するクラウドベースのサービス計算装置の組み合わせを提供し、これらの装置は、個別に及び／または一緒に、追加の計算リソースを必要とするそれぞれの車両にセンシング及び計算リソースを提供することができ、一方で、それぞれの車両は、自身の電子制御ユニット（ＥＣＵ）及び自身の搭載センサを使用してオンボード処理も実行する。従って、本明細書の実施形態は、特定のルートに沿ったすべての場所において、所望レベルの自動運転のために不十分なセンシング及び／または計算リソースを有する可能性のある車両の問題を解決することができる。例えば、本明細書の実施形態は、車両によって通過される１または複数の道路セグメントのＰＯＺを完全に感知することができない車両のために、近くのＶＥＣがセンシング及び／または計算タスクのサポートを提供することを要求する場所を事前に決定することができる。例えば、遠隔に位置するサービス計算装置は、ＶＥＣ上の利用可能な計算リソースに従って、計算タスクを近くのＶＥＣに割り当てることができる。本明細書の実施形態は、さらに、自律走行を実現するためにより高いレベルの計算リソースを必要とする可能性がある場所であるＰＯＺとして、ルートに沿った特定の領域を事前に特定してもよい。システムは、ＶＥＣ及び／またはクラウドベースのサービス計算装置の利用可能な計算リソースをスケジューリングすることによって、オフロードされた計算タスクを適宜割り当てて実行するためのスケジューリングを実行してもよい。
【0014】
上述のように、安全運転は個人にとってだけでなく、あらゆる種類の輸送やサービス事業にとっても重要である。安全性は、自動運転システムの幅広い開発と急速な進歩の根本的な理由ある。完全または部分的に自動化された車両には複数のセンサが搭載され、車両周辺を継続的に監視して障害物を認識し、安全性を向上させる。先行研究によれば、交通事故のほとんどは人間の運転ミスによるものである。従って、高度なセンシングとデータ処理装置を備えた最先端の自動運転車両は、改良されたアルゴリズムを使用することで、車両衝突の発生率を大幅に低減できる。
【0015】
本明細書における自動車両のセンサは、最終的に衝突を回避するのに役立つように、車両の周囲の障害物や道路の特徴を検出する上で主要な役割を果たす。本明細書の処理装置は、最先端のアルゴリズムを利用してリアルタイムでセンサデータを処理し、必要な制御信号を様々なシステム及び／またはアクチュエータに送信して車両を制御することができる。車両の周囲に複数の冗長な高分解能センサを配置し、処理キャパシティの高い複数の処理ユニットを併用することで、車両はあらゆる条件下で自律的に動作できる。しかし、このような構成は、車両のコストを大幅に増加させるだけでなく、車両の効率を低下させる可能性がある。したがって、これらの問題に対処するために、本明細書の実施形態では、より限られた数のセンサと、最適化された処理キャパシティを有する処理ユニットとを使用することができる。限られた数のセンサを使用することは、多くの自動運転シナリオには十分であるが、いくつかのケースでは、限られた数のセンサでは、特定の道路セグメント、交差点などを安全にナビゲートするために必要なすべての領域を感知するのに十分でない場合がある。その結果、本明細書の実施形態では、インフラストラクチャ・センサ、他の車両センサ、または近傍で利用可能な車両外部の他のセンサから得られるセンシング情報を使用するなどして、これらの場所における車両のセンシング能力を補強するためにＶＥＣを採用することができる。いくつかのケースにおいて、ＶＥＣは車両に代わって外部のセンサデータを処理し、センシング結果を車両に提供して車両の自律走行を支援する。
【0016】
車両の安全性を確保するために、本明細書の実施形態は、自動運転時間を最大化しようとする場合がある。しかしながら、状況によっては、限られた数のセンサを備えた車両では、いくつかのタイプの道路カテゴリや道路形状を考慮した場合、ルート全体にわたって連続的な自動運転を保証することができない。例えば、フロントカメラとレーダを搭載した車両は、一般的に高速道路での自律走行を確保できるが、このセンサの組み合わせは、市街地での自動運転には不十分である。そのため、本明細書の実施形態は、接続データとしてインフラストラクチャ及び／または他の車両センサの利用を自動運転のために採用する。しかし、これらの追加のデータを処理するためには、追加の計算リソースも必要となる。接続性とクラウド計算の最近の進歩により、ＶＥＣと中央クラウドベースの計算技術は、車両に追加情報を提供するために、利用され得る。しかしながら、遠隔クラウドベースの計算リソース（例えば、本明細書におけるサービス計算装置）は、一般に、車両から地理的に離れたデータセンタに配置されるため、サービス計算装置と車両との間の通信に著しい遅延が生じ、時間的に重要なアプリケーションを、車両の安全を確保するのに十分な短時間で実行し、車両に戻すことができない場合がある。
【0017】
本明細書の例では、移動の開始時に、車両は、その現在位置、目的地、センサの種類及び構成、ならびに処理ユニットの仕様をサービス計算装置と共有することができる。サービス計算装置は、目的地までの候補ルートを特定し、候補ルートのＰＯＺを計算する。ＰＯＺは、車両の安全を確保するために車両が監視すべき領域であってよい。ＰＯＺは、ルート中の全ての道路セグメント／ウェイポイントについて決定されてよい。ＰＯＺは、以下で追加的に説明するように、例えば、道路のタイプ、ウェイポイントの位置などに応じて変化する３Ｄ領域であってもよい。
【0018】
サービス計算装置は、すべての候補道路セグメントに沿って特定された ＰＯＺ と比較して、車両センサ構成及び処理ユニット仕様を分析し、自動運転の時間量を最大化するための最適ルートを選択する。サービス計算装置は、車両センサ構成及び車両処理ユニット仕様に基づいて、自動運転のための道路特徴や障害物の特定など、車両がセンサデータを分析するために追加の計算リソースを必要とするルート上の道路セグメントを特定してよい。サービス計算装置は、特定された場所のＶＥＣと車両情報を共有し、車両がそれぞれのＶＥＣに最も近い道路セグメントに接近すると予想される時間を共有する。サービス計算装置から車両情報を受信すると、それぞれのＶＥＣは、その時間セグメントのスケジュールされた計算タスクを分析し、それぞれのＶＥＣの計算リソースの利用可能性に基づいて、特定の車両を支援する要求を確認または拒否することができる。さらに、それぞれのＶＥＣからのフィードバックに基づいて、サービス計算装置は、ルーティング情報を更新してもよく、ルーティング情報を車両に送信してもよい。例えば、ＶＥＣが特定の車両の要求をサポートできない場合、サービス計算装置は、代替候補ルートが車両のために利用可能であるか否かを決定することができる。車両搭載処理装置、ＶＥＣキャパシティ利用可能性、及びサービス計算装置利用可能性を考慮しながら、事前に実行される計算タスク分配及びオフロードのために説明される技術は、自律または半自律車両の自動運転の時間を最大化し、その安全性を確保するための大きな利点を提供する。
【0019】
例えば、車両は、サービス計算装置によって提供される接続されたデータ分析プラットフォームにアクセスし、車両上で利用可能な車載センサに関する情報をサービス計算装置上のデータ分析プラットフォームに提供するとともに、出発地位置、目的地位置、車両構成情報などを提供することができる。さらに、車両は、データ分析プラットフォームから、目的地位置に到達するためにデータ分析プラットフォームによって選択された1または複数の最適ルートに関する情報を受信してもよい。他の例では、ルート決定は、車両に搭載された計算装置、または車両のルートに沿って車両に近接して配置されたＶＥＣなどによって実行されてもよい。
【0020】
本明細書の実施形態は、各候補ルートについて複数のＰＯＺを決定してもよい。例えば、各候補ルートは複数のセグメントに分割されてもよく、各セグメントについてＰＯＺ及び計算要件が計算されてもよい。計算されたＰＯＺ及び計算要件は、各候補ルートの全体的な実現可能性を決定するために使用されてもよく、計算要件及びそれを満たす能力に少なくとも部分的に基づいて、選択された目的地まで車両が通過するための特定の候補ルートが選択されてもよい。例えば、車両及びその乗員の全体的な安全性を向上させるために、ルートに沿って自律走行に割り当てられる時間を最大化することが望ましい場合がある。例えば、交通事故のほとんどは人為的なミスによって引き起こされるため、安全に行える場合に自律走行時間を増加させることで、車両の全体的な安全性を向上させることができる。さらに、本実施形態のシステムは、道路セグメントごとにＰＯＺを決定することにより、それぞれの道路セグメントを通過する際に車両の安全を確保するために車両が監視すべきゾーンを事前に決定することができる。
【0021】
一例として、道路セグメントのＰＯＺは、カメラを使用した運転手監視システムと、多数の被験者の監視から収集されたデータを使用して決定することができる。しかしながら、本明細書の実施形態には、事前の被験者ベースの運転手監視データなしに、ルートに対して必要な観測ゾーンを特定することによってＰＯＺを決定する技術が含まれる。これらの技法において、完全自動化／半自動化車両は、従来のルーティングエンジンを使用するなどして、複数の目的地への候補ルートを決定することができるサービス計算装置によって提供されるデータ分析プラットフォームと通信できる。データ分析プラットフォームにおいて、候補ルートは複数の道路セグメントに分割され、各道路セグメントは交差点機能領域の一部であるか否かについて分類される。選択された道路セグメントのカテゴリに基づいて、停止見通し距離、知覚反応距離、操作距離、旋回見通し距離などを含む複数のパラメータが計算され、その道路セグメントのＰＯＺを計算するために使用される。
【0022】
いくつかの実施形態が、選択されたルートに対する１または複数のＰＯＺの決定に基づいて、さらに、車両の搭載処理能力、及び候補ルートに沿った１または複数のＶＥＣの処理可用性に基づいて、車両のルート（走行経路（ｔｒａｖｅｌ ｐａｔｈ））を選択する環境で説明される。しかしながら、本明細書の実施形態は、提供された特定の例に限定されず、本明細書の開示に照らして当業者に明らかになるように、他のタイプの車両、他のタイプの通信、他のタイプの計算装置構成、他のタイプの計算プラットフォーム及びアーキテクチャなどに拡張され得る。
【0023】
図１は、実施形態による、車両のリソースを割り当てるための例示的なシステム１００を示す。この例では、少なくとも３つの異なるタイプの計算リソースが採用され。システム１００は、１または複数のＶＥＣ１０５に接続された１または複数の路側ユニット（ＲＳＵ：Ｒｏａｄ Ｓｉｄｅ Ｕｎｉｔ）１０３と無線通信できる１または複数の車両計算装置１０４を有する車両１０２を含む。さらに、車両計算装置１０４及びＶＥＣ１０５は、１または複数のネットワーク１０６を介して、１または複数のサービス計算装置１０８と通信することができる。ＶＥＣ１０５は、複数の他の車両１０９と通信することができ、各車両１０９は、それ自身の車両計算装置１１１を含むことができる。本明細書におけるいくつかの例では、車両１０２、１０９は、ＶＥＣ１０５及び／またはサービス計算装置１０８のような１または複数の車両外計算装置と通信するために接続され、「コネクテッド車両」と呼ばれることがある。
【0024】
いくつかの例として、ＶＥＣ１０５は、ＶＥＣ１０５が認識データまたは車両１０２の外部の（すなわち、搭載されていない）センサからのセンサデータを処理した他の結果を提供する車両１０２、１０９によって通過される１以上の道路セグメントから１マイル、半マイル、１／４マイル、またはそれ以下の範囲内に位置し、道路セグメントの近くにある。例えば、ＶＥＣ１０５は、それらが接続されるＲＳＵ１０３から数百ヤード以内に位置することがあり、ＲＳＵ１０３は、車両１０２、１０９が走行する道路から数十ヤード以内に位置することがある。逆に、サービス計算装置１０８は、ＲＳＵ１０３、車両１０２、１０９、及びＶＥＣ１０５から数十マイル、数百マイル、または数千マイル離れた場所にある場合もある。
【0025】
１または複数のネットワーク１０６は、セルラネットワークなどの無線ネットワーク、インターネットなどの広域ネットワーク、イントラネットなどのローカルエリアネットワーク、Ｗｉ－Ｆｉなどのローカル無線ネットワーク、ＢＬＵＥＴＯＯＴＨ（登録商標）またはＤＳＲＣ（専用近距離通信）などの近距離無線通信、光ファイバ及びイーサネットなどの有線ネットワーク、これらの任意の組み合わせ、または他の任意の適切な通信ネットワークを含む、任意の適切なネットワークを含むことができる。このような通信技術に使用されるコンポーネントは、ネットワークの種類、選択した環境、またはその両方に少なくとも部分的に依存する。このようなネットワーク上で通信するためのプロトコルは周知であり、本実施形態では詳述しない。
【0026】
さらに、ＲＳＵ１０３とＶＥＣ１０５との間の通信リンク１１３は、１つ以上のネットワーク１０６のいずれかを含むことができる。例えば、ＶＥＣ１０５とＲＳＵ１０３は、無線通信または有線通信を介して通信することができる。通信リンク１１３は、光ファイバ接続、イーサネット、または他の有線接続を含むことができる。さらに、ＲＳＵ１０３は、任意のタイプの無線通信などを通じて、車両１０２、１０９と無線通信するように構成されてよい。例としては、４Ｇ、５Ｇ、またはＬＴＥセルラ通信その他の無線周波数、Ｗｉ－Ｆｉ通信その他の短距離無線通信、またはその他の無線通信技術が挙げられる。
【0027】
いくつかの例では、車両計算装置１０４、１１１は、１または複数の電子制御ユニット（ＥＣＵ）または他の様々なタイプの計算装置のいずれかを含むことができる。例えば、計算装置１０４、１１１は、センサデータを処理し、ナビゲーション、ブレーキ、ステアリング、加速、減速などのＡＤＡＳタスク及び／またはＡＤタスクを実行するなど、車両システムの少なくとも一部を制御するための１または複数のＡＤＡＳ／ＡＤＥＣＵまたは他のタイプのＥＣＵを含んでもよい。計算装置１０４、１１１は、それぞれ車両１０２、１０９の多数の他のシステムのいずれかを制御するための１または複数の他のＥＣＵを含むこともできる。
【0028】
図示された例では、交差点１１５は、車両１０２、１０９と通信可能な複数のＲＳＵ１０３を含む。例えば、サービス計算装置１０８によって実装されたデータ分析プラットフォームが、車両１０２がナビゲーションのために追加の計算リソースを必要とする可能性のあるＰＯＺとして交差点１１５を特定したとする。さらに、交差点１１５には、交通カメラなどの１つ以上のインフラストラクチャ・センサ１１７が配置され得る。
【0029】
従って、車両１０２が交差点１１５を自律的にナビゲートすることを可能にする計算タスクの一部は、交差点１１５に近接して位置し、ＲＳＵ１０３とそれぞれ通信可能なＶＥＣ１０５の１つにオフロードされ得る。例えば、インフラセンサデータ、他の車両１０９からのデータ、及び／または車両１０２からのデータは、ＶＥＣ１０５によって受信されてもよい。ＶＥＣ１０５は、車両１０２に代わって１つ以上の計算タスクを実行し、処理結果を、ＲＳＵ１０３を介して車両１０２に送信することができる。車両１０２は、交差点１１５のナビゲーション中に、ＶＥＣ１０５から提供された結果を使用することができる。一例として、ＶＥＣ１０５は、車両１０２のセンシング情報をインフラストラクチャ・センサ及び／または他の車両センサからのセンサ情報で補強することによって、車両１０２の限られたセンサ能力を補ってもよい。
【0030】
例えば、移動の開始時に、車両１０２は、その目的地を１つ以上のサービス計算装置１０８と共有することができる。目的地に基づいて、サービス計算装置１０８は、以下で説明されるように、最適ルートを選択してよく、最適ルートの選択は、最適ルートの個々のルートセグメントを決定することを含んでよい。さらに、少なくともライブ及び過去の交通データを考慮することに基づいて、サービス計算装置１０８は、車両が各ルートセグメントに到達すると予想される時間を決定してもよい。例えば、交差点１１５の場合、サービス計算装置１０８は、車両１０２が交差点に接近すると予想される時刻を決定してもよい。サービス計算装置１０８は、予想される交差点到着時間と共に、車両１０２の車両情報を、交差点１１５に関連する１つ以上のＶＥＣ１０５に送信する。受信した情報に基づいて、ＶＥＣ１０５は、車両１０２が予想される時間にサービスを受けるようにスケジューリングする。
【0031】
本明細書のいくつかの例では、各ＶＥＣ１０５（及びそれに対応するＲＳＵ１０３）は、それぞれ定義された作業ゾーン（例えば、その周辺の直径など）を有し、その範囲はメートルからキロメートルに及ぶことがある。ＶＥＣ１０５は、その作業ゾーン内で車両を支援することができる。したがって、車両１０２が任意のＶＥＣ１０５及び／またはその対応するＲＳＵ１０３の作業ゾーンに入ると、車両１０２は、任意の適切な通信プロトコル、例えば、セルラＶ２Ｘ、ＷｉＦｉ、または任意の他の無線通信技術を使用するなどして、その位置及び他の車両情報を、ＲＳＵ１０３を介してＶＥＣ１０５に送信することができる。したがって、車両１０２とＶＥＣ１０５は、ＲＳＵ１０３を介して通信を確立することができ、ＶＥＣ１０５は、サービス計算装置１０８から以前に受信した車両情報などを通じて、特定の車両１０２を認識することができる。特定の車両１０２を認識することに基づいて、ＶＥＣ１０５は、ＶＥＣ１０５に提供された車両情報を用いて、サービス計算装置１０８によって指定されたセンシング及び／または計算支援を提供することができる。
【0032】
さらに、いくつかの実施形態では、ＶＥＣ１０５は、車両１０２に追加のセンサ情報を提供する等のための計算タスクを実行するために、他の車両１０９上の車両計算装置１１１及び／または他の車両１０９上のセンサからのデータを利用することができる。例えば、車両１０９の中には、計算処理リソースのキャパシティがオーバしているものがあり得る。このような状況では、ＶＥＣ１０５自身が、利用可能な計算キャパシティを有する車両１０９に１つ以上の計算タスクをオフロードし、その結果を受信し、その結果を車両１０２に提供することができる。
【0033】
いくつかの例では、サービス計算装置１０８は、タイムクリティカルでない計算タスクなどのために、車両１０２に計算リソースを提供することもできる。ＶＥＣリソースは、サービス計算装置１０８と比較して、車両１０２、１０９に実質的により近い距離に位置するため、オフロードされたタイムクリティカルな安全及び制御アプリケーションの実行は、物理的に数百または数千マイル離れたデータセンタに位置する可能性のあるサービス計算装置１０８ではなく、通常ＶＥＣ１０５で実行される可能性がある。さらに、図１の例に示されたＲＳＵ１０３は、ＶＥＣ１０５から分離されているように示されているが、他の例では、ＲＳＵ１０３及びＶＥＣ１０５は、車両１０２、１０９との間でデータを送受信し、データを処理することができる単一の計算装置に組み合わされる場合がある。さらに、後述するように、サービス計算装置１０８は、車両１０２、１０９の自律ナビゲーションを支援するための多数の他の機能を提供することができる。
【0034】
図２は、実施形態による車両センサの構成例２００を示す。この例では、車両１０２は、その走行経路に沿って、道路、障害物、標識、ランドマークなどを検出及び認識するとともに、部分的または完全な自律走行中に、あらゆる衝突をナビゲート及び回避するために、広範なセンサを備えることができる。例えば、自動車技術会（ＳＡＥ：Ｓｏｃｉｅｔｙ ｏｆ Ａｕｔｏｍｏｔｉｖｅ Ｅｎｇｉｎｅｅｒｓ）が定義するように、運転自動化にはレベル０からレベル５までの６段階がある。特に「レベル０」（運転自動化なし）では、運転手がステアリング、ブレーキ、加速などのすべての操作タスクを行う。「レベル１」（運転支援）では、車両が一部の機能（クルーズコントロールなど）を支援することができるが、アクセル操作、ブレーキ操作、周辺環境の監視などはすべて運転手が行う。「レベル２」（部分的な運転自動化）では、車両がステアリング操作や加速機能をアシストし、運転手は作業の一部から離れることができる。アダプティブクルーズ・コントロール（ＡＣＣ）は、レベル２の自律操作の一例である。
【0035】
自律走行のコンセプトは主に「レベル３」（条件付き運転自動化）から始まり、そこでは車両自身が周囲の状況を監視し、車両に対して何らかの制御を行うことができる（例：自律駐車）。レベル３では、運転手が運転を引き継がなければならない。「レベル４」（高運転自動化）では、車両はほとんどの時間単独で運転することができるが、すべての条件が満たされない限り運転しない。「レベル５」（完全運転自動化）では、車両はあらゆる条件下でどこでも運転できる。自律走行システムがすべての重要なタスクを制御し、周囲の状況を監視し、渋滞、障害物、通行止めなどの特異な走行条件を識別するため、ペダルやハンドルは必要ない。
【0036】
より高い自動化レベル（すなわち、レベル３からレベル５）の場合、車両１０２は、障害物を回避して安全に航行するために、車両１０２の周囲を継続的に監視することができる。このような状況において車両１０２に使用され得る様々な種類のセンサ及びセンシング技術が存在する。一般的に使用されるセンサには、モノカメラ、ステレオカメラ、赤外線カメラ、レーダ、ライダ、レーザ、超音波センサ、ＧＰＳ受信機などがある。任意の特定の運転支援システム用途または任意の特定の運転自動化レベルに対して、センサは、検出範囲、検出能力のタイプ、電力要件、コスト、生成されるデータ量などを含み得るセンサタイプの長所及び短所に基づいて選択される。各センサの種類には利点と欠点があるため、様々な天候や他の種類の条件における精度を向上させるために、車両１０２での使用において異なる種類のセンサを組み合わせてよい。例えば、ある気象条件下では、単一のセンサタイプでは認識精度や距離の要件を満たせない場合がある。
【0037】
一例として、カメラ（モノ／ステレオ）は、暗い場所や悪天候のときにうまく機能しない可能性があり、検出範囲は、同程度の価格のレーダセンサと比較して比較的低い。しかし、レーダセンサは車道にいる人間を検出できないことがあり、レーンマーカを検出するのが難しいこともある。一方、レーダセンサは、他のセンサタイプに比べ、他の車両の長距離検知に適している。別の例として、赤外線カメラは、夜間の条件下では良好な性能を発揮するが、長距離検出能力が低いという問題がある。さらに、ライダセンサは、昼夜を問わず良好な性能を発揮するが、コストが高く、リアルタイムでデータを処理するために大キャパシティのプロセッサを必要とする膨大な量のデータを生成する。さらに、超音波センサは他のタイプのセンサよりも低コストであるが、超音波センサの検出範囲は１０メートル以下であるため、有用性が制限される。
【0038】
上記の観点から、ＡＤＡＳ／ＡＤ車両には、車両周囲を継続的に監視するために、複数の異なるセンサタイプが一般的に採用されている。一般的に使用されるセンサには、モノカメラ、ステレオカメラ、赤外線カメラ、レーダ、ライダ、レーザ、超音波センサ、ＧＰＳなどがある。特定の運転支援システム・アプリケーションや特定の運転自動化レベルでは、可動範囲、検出能力の種類、電力要件、コスト、データ生成量など、それぞれの長所と短所を考慮してセンサが選択される。各センサにはそれぞれ長所と短所がある。認識精度や可動範囲を考慮すると、全天候型の要件を満たす単一のセンサを決定するのは困難な場合が多い。そのため、自動車メーカは、自律走行システムのレベルやコストに応じて、単一センサまたは複数センサの融合システムを使用している。レベル２のＡＤＡＳアプリケーションの一例として、車線逸脱警告と側面衝突回避に使用されるレーンキープアシスト（ＬＫＡ）システムがある。レベル４、５の自律走行システムにおいて、車両周囲の３６０度監視を実現するセンサの組み合わせ例を図２に示す。さらに、図２に示すような車載センサに加え、車両は、他の車両、インフラ、道路エッジ計算モジュール、クラウドデータ交換及び／または分析プラットフォームなどとデータを共有するための通信デバイスを装備することもできる。従来のセルラネットワーク、ＤＳＲＣ、Ｗｉ－Ｆｉなどは、車両１０２と他のデバイスとの間で接続データを通信するために使用され得る通信プロトコルである。
【0039】
図２において、例示的な車両１０２は、車両周囲の３６０度監視のための複数の異なるセンサを備えている。この例では、車両１０２は、図２に示すように、各々が検知領域２０２（前面、背面、左側面、右側面）を有する４つの周囲モノカメラまたは超音波（ＵＴＺ）センサを備えることができる。例えば、モノカメラは、最大１０ｍの検知範囲を有し、駐車支援、近接障害物の検知、及び／または歩行者の検知に有用である。
【0040】
また、車両１０２は、車両１０２の前方に検出領域２０４を有する前方向きの広角モノまたはステレオカメラを備えていてもよい。さらに、車両１０２は、車両１０２の前方に検出領域２０６を有する前方向ステレオカメラを備えることもできる。ステレオカメラを使用した視覚センシングシステムは、視差マップなどを用いるなどして、異なる障害物、ランドマーク、歩行者、道路標識、道路特徴、信号機などを識別及び追跡するための、短距離／中距離から、長距離の、認識用途に用いることができる。カメラを使用したセンシングは、雪、雨、日光、暗闇などの環境条件に大きく影響される場合がある。
【0041】
さらに、車両１０２は、車両１０２を取り囲むそれぞれの検出領域２０８を有する４つの中距離レーダセンサを備えることができる。さらに、車両１０２は、車両１０２の前方に検出領域２１０を有する長距離レーダセンサを備えることができる。レーダセンサは、ミリ波検出及び測距を採用してもよく、したがって、天候条件に強く、最大２５０ｍの比較的長い範囲を有し得る。しかし、レーダに基づく測定は、障害物の形状及びサイズなどの詳細な幾何学的情報を欠く場合がある。いくつかの例では、中距離レーダセンサは、死角支援や緊急ブレーキＡＤＡＳ機能などの用途に有用である。
【0042】
いくつかのケースおいて、ステレオカメラ、長距離レーダ、または上記のセンサの代わりに、またはこれらに加えて、ライダセンサを使用することができる。さらに、いくつかのセンサ構成例を図２に関して説明したが、他の多数のセンサタイプ、センサ位置、及びセンサ構成は、本明細書の開示の当業者には明らかであろう。従って、本明細書の実施態様は、特定のセンサタイプ、位置、または構成に限定されない。
【0043】
さらに、本明細書の車載センサにより、車両１０２は、他の車両、インフラ、道路端計算モジュール、クラウドデータ交換、データ分析プラットフォームなどとデータを共有するためのコネクテッドデバイスを備えることができる。一般に、他の車両やシステムとデータを共有する完全自律車両や部分自律車両は、「コネクテッド自律車両」と呼ばれることがある。コネクテッド自律車両は、上述のように他のソースからデータを受信し、受信したデータを処理して、自律走行中の安全性、快適性、効率性の向上、移動時間の短縮などを実現することができる。さらに、コネクテッド自律車両は、データを他の車両と共有し、交通密度、道路使用状況などを実現するとともに、他の車両に異なる値を提供することができる。
【0044】
図３は、実施態様によるセンサ構成例３００を示す。例えば、レーン・キープ・アシスト（ＬＫＡ）やアダプティブクルーズ・コントロール（ＡＣＣ）のような横方向及び縦方向の運転支援システムのためのＡＤＡＳアプリケーションは、市販車両で利用可能な比較的成熟した技術である。これらのシステムは、通常、安全で堅牢な性能を確保するために単一または複数のセンサを使用する。車両に採用されるセンサの種類と数は、ＡＤＡＳアプリケーションの種類によって異なる。
【0045】
図３の例では、ＬＫＡシステムは、車線逸脱警告及び横方向衝突回避のために採用される。例えば、ＬＫＡシステムは、車両１０２を自車線内に安全に維持するために運転手を支援する。したがって、この例では、センサの使用構成は、検出領域２０６を提供するステレオカメラと、検出領域２１０を提供する長距離レーダとを含む。例えば、長距離カメラの検出領域２１０は、道路の曲率を測定し、車線３０２内の車両１０２の定位を提供できる視野を提供する。例えば、ＬＫＡシステムは、運転席やステアリングホイールなどに振動を与えることにより、運転手に触覚フィードバックを提供するためのアクチュエータ（図３には図示せず）を含む。このように、ＬＫＡシステムは、車線逸脱の警告を提供することで運転手を支援し、運転手は、車両１０２を制御し、さらなる車線逸脱を回避する責任を負う。
【0046】
さらに、本明細書のいくつかの例では、車線逸脱が発生したときに運転手の反応に頼るのではなく、LKAシステムは長距離カメラと長距離レーダからのセンサ融合を採用して運転手に警告し、ステアリングアクチュエータも作動させることができる。したがって、ステアリングアクチュエータは、車両を適切な車線に戻すために自動的に作動する。センサ融合アルゴリズムは、厳しい性能要件と安全要件を満たす必要がある場合がある。
【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】
事故は交差点で発生することが多いため、交差点での安全性の確保は最優先事項である。交差点では、人間の運転手は、どこで車線変更を行うか、いつ、どのように信号を読むか、停止する場所、曲がる前に見るべき場所、曲がるタイミングと速度などを理解することができる。自動運転車両は、人間のような判断を下すために、連続したステップに従い、適切な領域を観察する能力を持つべきである。従って、自動運転車両は、政府、地方自治体などが指定する交差点の異なる領域を理解し、各領域に対して人間の運転手と同じ動作を行う必要がある。交差点機能領域の計算は、各国の指定当局によって定義される道路制限速度、場所、道路の種類などに依存し得る。米国では、ＡＡＳＨＴＯ（米国道路交通運輸行政官協会）によると、交差点機能長（Ｆ）は、ＥＱ（１）に示すように、停止見通し距離（Ｓ）とストレージ長距離（Ｑ）の和である。交通がない場合、ストレージ長距離（Ｑ）はゼロとなり、交差点機能領域は停止見通し距離となる。停止見通し距離は、車両を停止させるための２つのフェーズで車両が移動する距離の組み合わせであり、すなわち、第１のフェーズは知覚反応時間中に移動する知覚反応距離１２２４であり、第２のフェーズは操縦時間中に移動する操縦距離１２２６である。
Ｆ＝Ｓ＋Ｑ ＥＱ（１）
Ｓ＝（１．４７＊Ｖ＊ｔ）＋１．０７５＊（Ｖ2／ａ） ＥＱ（２）
Ｆ＝Ｓ＋Ｑ ＥＱ（１）
Ｓ＝（１．４７＊Ｖ＊ｔ）＋１．０７５＊（Ｖ2／ａ） ＥＱ（２）
【0160】
Ｆ＝交差点機能長
Ｓ＝停車時見通し距離
Ｑ＝ストレージまたは待ち列長
Ｖ＝設計速度（マイル）
ｔ＝知覚反応時間（２．５秒）
ａ＝減速率（１１～１５フィート／ｓｅｃ2以内、例：１１．２フィート／ｓｅｃ2）
Ｓ＝停車時見通し距離
Ｑ＝ストレージまたは待ち列長
Ｖ＝設計速度（マイル）
ｔ＝知覚反応時間（２．５秒）
ａ＝減速率（１１～１５フィート／ｓｅｃ2以内、例：１１．２フィート／ｓｅｃ2）
【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】
さらに、ＥＱ（３）は、ｔ＝２．５秒、ａ＝１１．２ｆｔ／ｓｅｃ2の典型的な値に基づいて、ＥＱ（４）のように書き直すことができる。
Ｓ＝３．６７５＊Ｖ＋０．０９６＊Ｖ２ ＥＱ（４）
Ｓ＝３．６７５＊Ｖ＋０．０９６＊Ｖ２ ＥＱ（４）
【0192】
加えて、道路が勾配Ｇにある場合、停止見通し距離Ｓは勾配を考慮することができ、ＥＱ（５）のように計算することができる。
Ｓ＝３．６７５＊Ｖ＋Ｖ2／［３０（（ａ／３２．２）±Ｇ／１００）］ ＥＱ（５）
Ｓ＝３．６７５＊Ｖ＋Ｖ2／［３０（（ａ／３２．２）±Ｇ／１００）］ ＥＱ（５）
【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】
本主題は、構造的特徴及び／または方法論的行為に特有の言語で記載されているが、添付の特許請求の範囲に定義される主題は、必ずしも記載された特定の特徴または行為に限定されるものではないことを理解されたい。むしろ、特定の特徴及び行為は、特許請求の範囲を実施する例示的な形態として開示されている。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12A】
【図12B】
【図13】
【図14】
【図15】
【図16】
【図17】