JP2022169493A - オンデマンド路側ａｉサービスの方法とシステム - Google Patents

Abstract

【課題】限られた搭載車両センサと搭載計算資源を利用して、その環境内の車両をはじめとする路上動作主体を識別し、運転決定を下すための、オンデマンド路側ＡＩサービスの方法とシステムを提供する。【解決手段】方法には、車両からサービス要求を受信するステップと、１つ又は複数のセンサを用いて環境データを取得するステップと、サービス要求に基づいて車両の車両タイプを判定するステップと、車両の車両タイプ及び環境データに基づいて、サービス要求に応答するサービスデータを判定するステップと、サービスデータを含むサービスメッセージを車両に送信するステップと、が含まれる。【選択図】図１

Description

本明細書は、交通管理システム、さらに具体的には、オンデマンド路側ＡＩサービスのための方法及びシステムに関する。

人工知能（ＡＩ）と深層学習技術の進歩により、自律型車両が増え、先進運転支援システム（ＡＤＡＳ）が向上している。自律型車両とＡＤＡＳシステムが、搭載車両センサと搭載計算資源を利用して、その環境内の車両をはじめとする路上動作主体を識別し、運転決定を下す場合がある。しかし、車両の搭載計算能力は限られており、搭載センサの数も限られており、運転中の視野も限られている。そのため、自律型車両又はＡＤＡＳシステムの能力は、ここに挙げた要因をはじめとする要因によって制限される可能性がある。このため、オンデマンド路側ＡＩサービスの方法とシステムが必要である。

一実施形態では、方法には、車両からサービス要求を受信するステップと、１つ又は複数のセンサを用いて環境データを取得ステップと、サービス要求に基づいて車両の車両タイプを判定するステップと、車両の車両タイプ及び環境データに基づいて、サービス要求に応答するサービスデータを判定するステップと、判定されたサービスデータを含むサービスメッセージを車両に送信するステップと、が含まれる。

別の実施形態では、方法には、１つ又は複数の車両センサを用いて環境データを収集するステップと、車両から路側サーバにサービス要求を送信するステップと、サービス要求に応答するサービスデータを含むサービスメッセージを、路側サーバから受信するステップと、サービスデータを環境データと融合して、融合データを取得するステップと、融合データに基づいて１つ又は複数の運転指示を判定するステップと、が含まれる。

別の実施形態では、路側サーバがコントローラを備える。コントローラは、車両からサービス要求を受信し、１つ又は複数のセンサを用いて環境データを取得し、サービス要求に基づいて車両の車両タイプを判定し、車両の車両タイプ及び環境データに基づいて、サービス要求に応答するサービスデータを判定し、判定されたサービスデータを含むサービスメッセージを車両に送信する、ように構成される。

図面に示す実施形態は、本質的に例示的かつ典型的なものであり、開示を限定することを意図するものではない。例示的な実施形態の以下の詳細な説明は、以下の図面と併せて読むと理解することができる。図面では、類似の構造は、類似の参照番号で示される。
図１は、本明細書に示し、説明する１つ又は複数の実施形態による、路側サーバを備えるシステムを概略的に示す。 図２は、本明細書に示し、説明する１つ又は複数の実施形態による、車両システムの概略図を示す。 図３は、本明細書に示し、説明する１つ又は複数の実施形態による、図１の路側サーバの概略図を示す。 図４は、本明細書に示し、説明する１つ又は複数の実施形態による、図１及び図２の自律型車両を操作する方法のフローチャートを示す。 図５は、本明細書に示し、記載する１つ又は複数の実施形態による、図１及び図２の従来型車両を操作する方法のフローチャートを示す。 図６は、本明細書に示し、記載する１つ又は複数の実施形態による、図１及び図２の路側サーバを操作する方法のフローチャートを示す。

本明細書に開示する実施形態は、オンデマンド路側ＡＩサービスのためのシステム及び方法を含む。現在使用されている多くの車両は、全体的又は部分的に自律型である。自律型車両が、運転者の行動を必要とせずに、特定の運転機能を実行する場合がある。自律型車両が、１つ又は複数の搭載車両センサを利用して、車両の運転環境に関するデータを収集する場合がある。次に、自律型車両は、搭載計算資源を使用して、車両の位置を判定し、他の路上物体を識別し、それに応じて運転決定を下す場合がある。

しかし、搭載資源のみを使用することには、特定の制限がある。潜在的な制限の１つには、搭載センサの検出能力が制限されていることが挙げられる。ほとんどのセンサが視線ベースのものである。このため、車両センサが、視線への障害物によって制限される可能性がある。さらに、車両センサが特定の範囲内のデータしか収集できない場合がある。さらに、旧来の従来型車両にはセンサがまったく搭載されていない可能性がある。

もう１つの潜在的な制限には、測位情報の制限が挙げられる。自律型車両は、多くの場合、測位と定位のためにＧＰＳデータに依存している。しかし、ＧＰＳ信号の信頼性が低いか、ＧＰＳ信号を利用できない場所がある場合がある。さらに、従来型車両にはＧＰＳ能力が制限されているかまったくない場合がある。

もう１つの潜在的な制限には、計算能力の制限が挙げられる。センサデータの処理と複雑な意思決定タスクの実行には、かなりの計算能力が必要になる場合があるが、これは搭載車両では利用することができない場合がある。そのため、自律型車両が利用することができる計算資源は、車両の性能を制限する可能性がある。さらに、従来型車両には、さらに制限された搭載計算資源があるか、利用可能な搭載計算資源がまったくない場合がある。

上記の制限のほか、他の制限により、自律型又は非自律型の車両、従来型車両の性能が制限される場合がある。このため、本明細書の実施形態では、車両性能を改善し得るオンデマンド路側ＡＩサービスについて説明する。路側ＡＩサービスには、カスタマイズされたサービス要求を車両から受信する路側サーバ又は路側計算装置が含まれる場合がある。サービス要求は、知覚サービス、定位サービス又は決定サービスに対するものである場合がある。路側計算装置は、環境データを取り込むための独自のセンサを有する場合があり、路側センサによって取り込まれたデータ又は要求を発している車両から受信したデータを処理するための計算資源を有している場合がある。次に、路側計算装置は、サービス要求に応答して、計算された結果を、要求を発している車両に送信する場合がある。

路側サーバが、搭載車両センサでは取り込むことができないデータを取り込むことができる視野を有している場合があるため、路側ＡＩサービスを利用することで、車両が、その感知能力を向上させる場合がある。さらに、路側装置の計算資源を利用すると、車載計算資源を増やす必要なしに、車両の計算機能を向上させる場合がある。さらに、路側サーバが、カスタマイズされた要求を車両から受信する場合があり、さまざまなタイプのデータをさまざまなタイプの車両に送信する場合がある。例えば、路側装置は、特定のデータを完全自律型車両に送信し、他のデータを従来型車両に送信する場合がある。

ここで図に目を向けると、図１は、オンデマンド路側ＡＩサービスのためのシステムを概略的に示している。システム１００が路側サーバ１０２を備える。路側サーバ１０２は、本明細書に開示するように、１つ又は複数の車両から路側ＡＩサービスに対する要求を受信してもよい。図１の例では、車両１０４、１０６及び１０８が道路１１０に沿って走行する。図１の例では、車両１０４、１０６、１０８のそれぞれは、完全自律型車両、半自律型車両又は従来型車両であってもよい。本明細書で使用する場合、従来型車両とは、いかなる自律運転機能をも有していない車両、例えば、レベル０の車両である。従来型車両ではこのほか、搭載センサ及び／又は計算資源が少ないか、まったくない場合がある。図１の例では３台の車両を示しているが、他の例では、システム１００は任意の数の車両と共に動作し得ることを理解されたい。車両１０４、１０６、１０８のそれぞれは、自動車、あるいは、例えば、バス、スクータ、ドローン又は自転車を含むが、ここに挙げたものに限定されない地上、水上及び／又は空中の車両などの任意の他の搭乗者がいるか、搭乗者のいない車両であってもよい。

路側サーバ１０２は、車両１０４、１０６、１０８のうちの１つ又は複数に通信可能に結合されてもよい。いくつかの例では、路側サーバ１０２は、道路１１０の近くに位置決めされた路側ユニット（ＲＳＵ）であってもよい。このような例では、システム１００は、各ＲＳＵが異なるサービスエリアを網羅するように、道路１１０に沿って間隔を置いて配置された任意の数のＲＳＵを備えてもよい。即ち、車両１０４、１０６、１０８が道路１１０に沿って走行するとき、車両は、異なるＲＳＵが異なる場所で受信地域を提供するように、異なる時間に異なるＲＳＵの範囲内にあってもよい。このため、車両１０４、１０６、１０８が道路１１０に沿って走行するとき、車両は、異なるＲＳＵの受信サービスエリア間を移動してもよい。

他の例では、路側サーバ１０２は、別のタイプのサーバ又は計算装置であってもよく、道路１１０から離れて位置決めされてもよい。いくつかの例では、路側サーバ１０２はエッジサーバであってもよい。いくつかの例では、路側サーバ１０２は、別の車両などの移動エッジサーバであってもよい。いくつかの例では、路側サーバ１０２は、クラウドベースのサーバであってもよい。

車両１０４、１０６、１０８が道路１１０に沿って走行するとき、車両のうちの１つ又は複数が、カスタム路側ＡＩサービス要求を路側サーバ１０２に送信してもよい。路側ＡＩサービス要求には、本明細書に開示するように、知覚サービスに対する要求、定位サービスに対する要求又は決定サービスに対する要求が含まれてもよい。要求のタイプ及び要求を発する車両のタイプに応じて、路側ＡＩサービス要求には、車両が取り込んだデータが含まれてもよく、要求を発する車両のタイプが含まれてもよい。路側サーバ１０２は、本明細書に開示するように、カスタム要求に基づくサービス要求に応答して異なるタイプのサービスを提供してもよく、要求を発する車両のタイプに基づいて要求に応答して異なるタイプのデータを送信してもよい。

路側サーバ１０２は、要求を発している車両からＡＩサービス要求を受信した後、要求を処理し、要求に基づいて要求データを判定し、要求データをサービスメッセージの形態で、要求を発している車両に送り返してもよい。要求を発している車両は、サービスメッセージを受信してもよく、サービスメッセージに含まれるデータを利用して、車両の運転挙動を更新したり、及び／又は車両の運転者に情報を表示したりしてもよい。接続された車両（例えば、外部装置と通信することができる搭載ハードウェアを有する車両）の場合、車両ハードウェアは、路側サーバ１０２と直接通信してもよい。接続されていない車両の場合、運転者が、スマートフォン又は他のハードウェア装置を利用して、路側サーバ１０２と通信してもよい。

図２は、図１の車両１０４、１０６及び／又は１０８に含まれ得る車両システム２００を示す。車両システム２００は、自律型車両、半自律型車両又は従来型車両に含まれる車両システムを表してもよい。しかし、図２の車両システム２００の特定の構成要素が、本明細書に開示するように、いくつかの例では特定の車両タイプに含まれない場合がある。

図２の例では、車両システム２００は、１つ又は複数のプロセッサ２０２、通信経路２０４、１つ又は複数のメモリモジュール２０６、衛星アンテナ２０８、１つ又は複数の車両センサ２１０、ネットワークインターフェースハードウェア２１２及びデータ記憶部品２１４を備える。この詳細については、次の段落で説明する。

１つ又は複数のプロセッサ２０２のそれぞれは、機械可読で実行可能な命令を実行することができる任意の装置であってもよい。このため、１つ又は複数のプロセッサ２０２のそれぞれは、コントローラ、集積回路、マイクロチップ、コンピュータ又は任意の他の計算装置であってもよい。１つ又は複数のプロセッサ２０２は、システムのさまざまなモジュール間の信号相互接続性を提供する通信経路２０４に結合される。このため、通信経路２０４は、任意の数のプロセッサ２０２を互いに通信可能に結合し、通信経路２０４に結合されたモジュールが分散計算環境で動作することを可能にしてもよい。具体的には、モジュールのそれぞれは、データを送信したり、及び／又は受信したりし得るノードとして動作してもよい。本明細書で使用する場合、「通信可能に結合」という用語は、結合された構成要素が、例えば、導電性媒体を介した電気信号、空気を介した電磁信号、光導波路を介した光信号などのデータ信号を互いに交換することができることを意味する。

このため、通信経路２０４は、例えば、導線、導電性トレース、光導波路など、信号を送信することができる任意の媒体から形成されてもよい。いくつかの実施形態では、通信経路２０４は、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離無線通信（ＮＦＣ）などの無線信号の送信を容易にしてもよい。さらに、通信経路２０４は、信号を送信することができる媒体の組み合わせから形成されてもよい。一実施形態では、通信経路２０４は、プロセッサ、メモリ、センサ、入力装置、出力装置及び通信装置などの構成要素への電気データ信号の送信を可能にするために協調する導電性トレース、導線、コネクタ及びバスの組み合わせを含む。このため、通信経路２０４は、例えば、ＬＩＮバス、ＣＡＮバス、ＶＡＮバスなどの車両バスを含んでもよい。さらに、「信号」という用語は、媒体を通過することができるＤＣ、ＡＣ、正弦波、三角波、方形波、振動などの波形（例えば、電気的、光学的、磁気的、機械的又は電磁的な波形）を意味することに留意されたい。

車両システム２００は、通信経路２０４に結合された１つ又は複数のメモリモジュール２０６を備える。１つ又は複数のメモリモジュール２０６は、ＲＡＭ、ＲＯＭ、フラッシュメモリ、ハードドライブ、あるいは１つ又は複数のプロセッサ２０２が機械可読で実行可能な命令にアクセスすることができるように、機械可読で実行可能な命令を保存することができる任意の装置を含んでもよい。機械可読で実行可能な命令は、例えば、プロセッサによって直接実行され得る機械語など、任意の世代の任意のプログラミング言語（例えば、１ＧＬ、２ＧＬ、３ＧＬ、４ＧＬ又は５ＧＬ）、あるいは機械可読で実行可能な命令にコンパイルされるか組み入れられ、１つ又は複数のメモリモジュール２０６に保存され得るアセンブリ言語、オブジェクト指向プログラミング（ＯＯＰ）、スクリプト言語、マイクロコードなどで記述された論理又はアルゴリズムを含んでもよい。これとは別に、機械可読で実行可能な命令は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）構成又は特定用途向け集積回路（ＡＳＩＣ）のいずれか、あるいはそれに相当するものを介して実装される論理など、ハードウェア記述言語（ＨＤＬ）で記述されてもよい。このため、本明細書に記載の方法は、任意の従来のコンピュータプログラミング言語で、事前にプログラムされたハードウェア要素として、あるいはハードウェアとソフトウェアのコンポーネントの組み合わせとして実装されてもよい。

さらに図２を参照すると、車両システム２００は、通信経路２０４が衛星アンテナ２０８を車両システム２００の他のモジュールに通信可能に結合するように、通信経路２０４に結合された衛星アンテナ２０８を備える。衛星アンテナ２０８は、全地球測位システム衛星からの信号を受信するように構成される。具体的には、一実施形態では、衛星アンテナ２０８は、全地球測位システム衛星によって送信される電磁信号と相互作用する１つ又は複数の導電性要素を備える。受信された信号は、衛星アンテナ２０８の位置、ひいては、車両システム２００を含む車両の位置（例えば、緯度及び経度）を示すデータ信号に変換される。

車両システム２００は、１つ又は複数の車両センサ２１０を備える。１つ又は複数の車両センサ２１０のそれぞれは、通信経路２０４に結合され、１つ又は複数のプロセッサ２０２に通信可能に結合される。１つ又は複数のセンサ２１０は、ＬｉＤＡＲセンサ、ＲＡＤＡＲセンサ、光学センサ（例えば、カメラ、レーザセンサ）、近接センサ、位置センサ（例えば、ＧＰＳモジュール）などを含む場合があるが、ここに挙げたものに限定されない。実施形態では、センサ２１０は、車両の周囲を監視してもよく、道路上の他の車両又は路上動作主体を検出してもよい。センサ２１０によって取り込まれたデータは、プロセッサ２０２によって処理されて、路上動作主体の位置を識別し、判定してもよい。実施形態では、完全自律型車両、半自律型車両及び従来型車両が、異なるセットのセンサを備えてもよい。例えば、完全自律型車両には、自律運転のためのＬｉＤＡＲセンサ、ＲＡＤＡＲセンサなどの高性能センサが含まれる場合があり、半自律型車両には、完全自律型車両に含まれる一部のセンサが含まれない場合がある。従来型車両には、センサがほとんど含まれていないか、まったく含まれていない場合がある。

自律型車両の場合、車両システム２００は自律運転モジュールを備えてもよく、センサ２１０によって収集されたデータは、自律運転モジュールによって車両を自律的にナビゲートするために使用されてもよい。

さらに図２を参照すると、車両システム２００は、車両システム２００を路側サーバ１０２に通信可能に結合するためのネットワークインターフェースハードウェア２１２を備える。ネットワークインターフェースハードウェア２１２は、通信経路２０４に通信可能に結合することができ、ネットワークを介してデータを送信したり、及び／又は受信したりすることができる任意の装置であることがある。このため、ネットワークインターフェースハードウェア２１２は、任意の有線通信又は無線通信を送信したり、及び／又は受信したりするための通信トランシーバを含むことができる。例えば、ネットワークインターフェースハードウェア２１２は、他のネットワーク及び／又は装置と通信するためのアンテナ、モデム、ＬＡＮポート、Ｗｉ－Ｆｉカード、ＷｉＭａｘカード、移動通信ハードウェア、近距離通信ハードウェア、衛星通信ハードウェア及び／又は任意の有線又は無線のハードウェアを備えてもよい。一実施形態では、ネットワークインターフェースハードウェア２１２は、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線通信プロトコルに従って動作するように構成されたハードウェアを含む。実施形態では、車両システム２００のネットワークインターフェースハードウェア２１２は、路側ＡＩサービスに対する要求を、センサ２１０によって収集されたセンサデータ又はそのような要求に関連する他のデータと共に、路側サーバ１０２に送信してもよい。

ネットワークインターフェースハードウェア２１２は、本明細書に開示するように、サービス要求を路側サーバ１０２に送信してもよい。ネットワークインターフェースハードウェア２１２はこのほか、本明細書に開示するように、サービス要求に応答して路側サーバ１０２からサービスメッセージを受信してもよい。

さらに図２を参照すると、車両システム２００は、データ記憶部品２１４を備える。
データ記憶部品２１４は、車両システム２００のさまざまな構成要素によって使用されるデータを保存してもよい。さらに、データ記憶部品２１４は、センサ２１０によって収集されたデータ又は路側サーバ１０２から受信されたデータを保存してもよい。

車両システム２００はこのほか、インターフェースを備えてもよい。インターフェースは、データが人間の運転者に提示され、データが運転者から受信されることを可能にしてもよい。例えば、インターフェースは、運転者に情報を表示するための画面、運転者に音声情報を提示するためのスピーカ及び運転者が情報を入力するために使用し得るタッチスクリーンを備えてもよい。他の例では、車両システム２００は、他のタイプのインターフェースを備えてもよい。

いくつかの実施形態では、車両システム２００は、ネットワークによって路側サーバ１０２に通信可能に結合されてもよい。一実施形態では、ネットワークは、１つ又は複数のコンピュータネットワーク（例えば、パーソナルエリアネットワーク、ローカルエリアネットワーク又はワイドエリアネットワーク）、セルラーネットワーク、衛星ネットワーク及び／又は全地球測位システムならびにその組み合わせを含んでもよい。このため、車両システム２００は、ワイドエリアネットワーク、ローカルエリアネットワーク、パーソナルエリアネットワーク、セルラーネットワーク、衛星ネットワークなどを介してネットワークに通信可能に結合することができる。適切なローカルエリアネットワークには、有線イーサネット（登録商標）及び／又は、例えば、ワイヤレスフィデリティ（Ｗｉ－Ｆｉ）などの無線技術が含まれてもよい。適切なパーソナルエリアネットワークには、例えば、ＩｒＤＡ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、無線ＵＳＢ、Ｚ-Ｗａｖｅ、ＺｉｇＢｅｅ（登録商標）及び／又は他の近距離無線通信プロトコルなどの無線技術が含まれてもよい。適切なセルラーネットワークには、ＬＴＥ、ＷｉＭＡＸ、ＵＭＴＳ、ＣＤＭＡ及びＧＳＭ（登録商標）などの技術が含まれるが、ここに挙げたものに限定されない。

ここで図３を参照すると、路側サーバ１０２は、１つ又は複数のプロセッサ３０２、１つ又は複数のメモリモジュール３０４、ネットワークインターフェースハードウェア３０６、１つ又は複数のセンサ３０７及び通信経路３０８を備える。１つ又は複数のプロセッサ３０２は、コントローラ、集積回路、マイクロチップ、コンピュータ又は任意の他の計算装置であってもよい。１つ又は複数のメモリモジュール３０４は、ＲＡＭ、ＲＯＭ、フラッシュメモリ、ハードドライブ、あるいは１つ又は複数のプロセッサ３０２が、機械可読で実行可能な命令にアクセスすることができるように機械可読で実行可能な命令を保存することができる任意の装置を含んでもよい。

ネットワークインターフェースハードウェア３０６は、通信経路３０８に通信可能に結合することができ、ネットワークを介してデータを送信したり、及び／又は受信したりすることができる任意の装置であることがある。このため、ネットワークインターフェースハードウェア３０６は、任意の有線通信又は無線通信を送信したり、及び／又は受信したりするための通信トランシーバを含むことができる。例えば、ネットワークインターフェースハードウェア３０６は、アンテナ、モデム、ＬＡＮポート、Ｗｉ－Ｆｉカード、ＷｉＭａｘカード、移動通信ハードウェア、近距離通信ハードウェア、衛星通信ハードウェア及び／又は他のネットワーク及び／又は装置と通信するための任意の有線又は無線のハードウェアを含んでもよい。一実施形態では、ネットワークインターフェースハードウェア３０６は、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線通信プロトコルに従って動作するように構成されたハードウェアを含む。いくつかの例では、ネットワークインターフェースハードウェア３０６は、以下でさらに詳細に考察するように、専用狭域通信（ＤＳＲＣ）チャネル及びミリ波無線チャネルを含む２つの異なるチャネルを備えてもよい。路側サーバ１０２のネットワークインターフェースハードウェア３０６は、車両（例えば、図１の車両１０４、１０６、１０８）及び／又はスマートフォン又は車両運転者の他の装置との間でデータを送受信してもよい。

１つ又は複数のセンサ３０７は、環境データ又は道路データを取り込んでもよく、ＬｉＤＡＲセンサ、ＲＡＤＡＲセンサ、光学センサ（例えば、カメラ、レーザセンサ）、近接センサ、位置センサ（例えば、ＧＰＳモジュール）などを含んでもよいが、ここに挙げたものに限定されない。センサ３０７は、さまざまな気象条件（例えば、雨、霧、雪）での道路データを取り込むことができてもよい。センサ３０７は、車両に搭載された車両センサが取り込むことができない道路データを取り込むことができてもよい。例えば、路側サーバ１０２のセンサ３０７は、車両の搭載センサとは異なる視野又は視線を有してもよい。

１つ又は複数のメモリモジュール３０４は、データベース３１２、サービス要求受信モジュール３１４、標的車両識別モジュール３１６、センサデータ受信モジュール３１８、知覚サービスモジュール３２０、定位サービスモジュール３２２、決定サービスモジュール３２４及びサービスメッセージ送信モジュール３２６を含む。データベース３１２、サービス要求受信モジュール３１４、標的車両識別モジュール３１６、センサデータ受信モジュール３１８、知覚サービスモジュール３２０、定位サービスモジュール３２２、決定サービスモジュール３２４及びサービスメッセージ送信モジュール３２６のそれぞれが、１つ又は複数のメモリモジュール３０４に保存されたオペレーティングシステム、アプリケーションプログラムモジュールをはじめとするプログラムモジュールの形態のプログラムモジュールであってもよい。いくつかの実施形態では、プログラムモジュールは、路側サーバ１０２と通信し得る遠隔記憶装置に保存されてもよい。いくつかの実施形態では、データベース３１２、サービス要求受信モジュール３１４、標的車両識別モジュール３１６、センサデータ受信モジュール３１８、知覚サービスモジュール３２０、定位サービスモジュール３２２、決定サービスモジュール３２４及びサービスメッセージ送信モジュール３２６のうちの１つ又は複数が、車両の車両システム２００の１つ又は複数のメモリモジュール２０６に保存されてもよい。そのようなプログラムモジュールは、以下に説明するように、特定のタスクを実行するか、特定のデータ型を実行するためのルーチン、サブルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含んでもよいが、ここに挙げたものに限定されない。

データベース３１２は、車両から受信したＡＩサービス要求及びセンサデータを一時的に保存してもよい。データベース３１２はこのほか、路側サーバ１０２のセンサ３０７によって取り込まれたデータを保存してもよい。データベース３１２はこのほか、路側サーバ１０２のメモリモジュール３０４及び／又は他の構成要素によって使用され得る他のデータを保存してもよい。

サービス要求受信モジュール３１４は、カスタマイズされたＡＩサービスのために車両からサービス要求を受信してもよい。サービス要求受信モジュール３１４によって受信されたサービス要求が、ＡＩサービスのためのカスタマイズされた要求を指定してもよい。例えば、サービス要求が、知覚サービス、定位サービス又は決定サービスに対する要求であってもよい。以下でさらに詳細に考察するように、要求が、要求の追加の詳細をさらに指定してもよい。いくつかの例では、サービス要求が、要求を発する車両のタイプ（例えば、完全自律型車両、半自律型車両又は従来型車両）を指定してもよい。いくつかの例では、実施されるサービスのタイプは、本明細書に開示するように、要求を発する車両のタイプに依存してもよい。

いくつかの例では、サービス要求を、車両に関連付けられた車両システム２００のネットワークインターフェースハードウェア２１２によって送信してもよい。しかし、従来型車両を伴ういくつかの例では、車両が、図２に関して説明した車両システム２００の構成要素の全部を備えていない場合がある。このような例では、従来型車両の運転者が、アプリケーションを実行しているスマートフォン又は他のハードウェア装置を利用してサービス要求を生成してもよい。このような例では、サービス要求を、運転者のスマートフォンから送信してもよく、サービス要求受信モジュール３１４によって受信してもよい。

実施形態では、サービス要求が、知覚サービスに対する要求、定位サービスに対する要求又は決定サービスに対する要求であってもよい。知覚サービスに対する要求が、道路に沿って１つ又は複数の路上物体を検出するための路側サーバ１０２に対する要求を含んでもよい。路側サーバ１０２は、特定のサービス要求と、サービス要求を発する車両のタイプとに応じて、物体レベルの知覚メッセージ、特徴レベルの知覚メッセージ又は生データ知覚メッセージを送信することによって、知覚サービスに対する要求に応答してもよい。このような知覚メッセージについては、以下でさらに詳しく考察する。

定位サービスに対する要求には、路側サーバ１０２が、要求を発している車両の位置をローカライズするか判定するための要求が含まれてもよい。路側サーバ１０２は、特定のサービス要求と、サービス要求を発する車両のタイプとに応じて、道路レベルの定位メッセージ、車線レベルの定位メッセージ又はグローバルマップ定位メッセージを送信することによって、定位サービスに対する要求に応答してもよい。このような定位メッセージについては、以下でさらに詳細に考察する。

決定サービスに対する要求には、要求を発している車両に対する１つ又は複数の運転決定を判定するための路側サーバ１０２に対する要求が含まれてもよい。例えば、決定サービスには、特定のパラメータに基づくルート判定に対する要求又は知覚データに基づく特定の運転決定に対する要求が含まれてもよい。路側サーバ１０２は、特定のサービス要求に応じて、安全関連の決定及び案内メッセージ、エネルギー効率関連の決定及び案内メッセージ、あるいは移動時間関連の決定及び案内メッセージを送信することによって、決定サービスに対する要求に応答してもよい。このような決定メッセージについては、以下でさらに詳細に考察する。

標的車両識別モジュール３１６は、サービス要求受信モジュール３１４によって受信されたサービス要求を送信する車両のタイプを識別してもよい。例えば、標的車両識別モジュール３１６は、サービス要求を完全自律型車両、半自律型車両又は従来型車両が発しているかどうかを判定してもよい。いくつかの例では、標的車両識別モジュール３１６は、サービス要求を発する車両の自動化のレベル（例えば、Ｌ０～Ｌ５）を判定してもよい。いくつかの例では、サービス要求が、サービス要求を発する車両のタイプを指定してもよい。そのため、標的車両識別モジュール３１６は、サービス要求で指定されたこの情報に基づいて、要求を発する車両のタイプを識別してもよい。他の例では、標的車両識別モジュール３１６は、サービス要求に含まれるデータのタイプ（例えば、センサデータがサービス要求に含まれるかどうか）に基づいて、要求する車両に関連する車両のタイプ又は自動化のレベルを判定してもよい。車両のタイプ及び／又はサービス要求を発する車両の自動化のレベルは、以下でさらに詳細に開示するように、サービス要求に応答して送信されるデータ又はサービスメッセージのタイプを通知してもよい。

センサデータ受信モジュール３１８は、路側サーバ１０２のセンサ３０７によって取り込まれたセンサデータを受信してもよい。上記で考察したように、路側サーバ１０２は、道路データを取り込み得る１つ又は複数のセンサ３０７を有してもよい。この取り込まれたデータは、センサデータ受信モジュール３１８によって受信されてもよい。特定のタイプのサービス要求（例えば、知覚サービス）の場合、路側サーバ１０２は、本明細書に開示するように、路側サーバのセンサ３０７によって取り込まれたデータを利用してもよい。他のタイプのサービス要求の場合、路側サーバ１０２は、センサ３０７によって取り込まれたデータを利用することがなくてもよい。

路側サーバ１０２は、道路の側面に沿って位置決めされる場合があるため、路側サーバ１０２のセンサ３０７は、任意の個々の車両の搭載センサよりも広い視野を有してもよい。このため、センサ３０７は、任意の個々の車両よりも多くてさらに良好なデータを取り込むことができる可能性があるため、路側サーバ１０２は、搭載センサのみに依存する自律型車両よりも優れた知覚サービスを実施することができる可能性がある。このため、センサ３０７によって取り込まれたデータを、センサデータ受信モジュール３１８が受信してもよく、受信されたデータは、以下でさらに詳細に開示するように、知覚サービスを実施するために使用されてもよい。

知覚サービスモジュール３２０は、要求を発している車両から知覚サービス要求を受信した後、知覚サービスを実施してもよい。上記で考察したように、知覚サービスモジュール３２０は、物体レベルの知覚、特徴レベルの知覚又は生データの知覚を実施してもよい。物体レベルの知覚には、センサデータに基づいて、道路上の１つ又は複数の物体を検出するために（例えば、物体の境界ボックスを判定するために）、センサ３０７によって取り込まれたセンサデータを処理する知覚サービスモジュール３２０が含まれてもよい。次に、１つ又は複数の検出された物体の境界ボックスの位置及び形状を含む物体レベルの知覚メッセージを、要求を発している車両に送信してもよい。

特徴レベルの知覚には、センサ３０７によって取り込まれたセンサデータから特徴を抽出する知覚サービスモジュール３２０が含まれてもよい。次に、抽出された特徴を含む特徴レベルの知覚メッセージを、要求を発している車両に送信してもよい。要求を発している車両は、抽出された特徴を受信した後、特徴をさらに処理して、物体を検出したり、及び／又は識別したりしてもよい。

生データ知覚には、センサ３０７によって取り込まれたセンサデータを、要求を発している車両に単に中継する知覚サービスモジュール３２０が含まれてもよい。即ち、センサ３０７によって取り込まれた生データを含む生データ知覚メッセージを、要求を発している車両に送信してもよい。要求を発している車両は、生センサデータを受信した後、生データをさらに処理して、物体を検出したり、及び／又は識別したりしてもよい。

いくつかの例では、サービス要求が、要求を発している車両が望む知覚サービスのタイプ（例えば、物体レベルのデータ、特徴レベルのデータ又は生データ）を指定してもよい。他の例では、知覚サービスモジュール３２０は、標的車両識別モジュール３１６によって識別された車両のタイプに基づいて実施する知覚サービスのタイプを判定してもよい。例えば、従来型車両には、生データ又は特徴レベルのデータをさらに処理するための搭載計算資源がない場合がある。そのため、従来型車両は物体レベルのデータのみを受信する可能性がある。半自律型車両には、特徴レベルのデータを処理するのに充分な計算資源があるが、生データを処理するのに充分な計算資源がない場合がある。そのため、半自律型車両は、物体レベルのデータ又は特徴レベルのデータを受信することができる可能性がある。完全自律型車両には、生データを処理するのに充分な計算資源がある場合がある。このため、完全自律型車両は、物体レベルのデータ、特徴レベルのデータ又は生データを受信することができる可能性がある。このため、いくつかの例では、知覚サービスモジュール３２０は、知覚サービス要求が従来型車両から受信されたときに物体レベルの知覚サービスを実施してもよく、知覚サービスモジュール３２０は、知覚サービス要求が半自律型車両から受信されたときに特徴レベルの知覚サービスを実施してもよく、知覚サービスモジュール３２０は、知覚サービス要求が完全自律型車両から受信されたときに生データレベルの知覚サービスを実施してもよい。

定位サービスモジュール３２２は、要求を発している車両から定位サービス要求を受信した後、定位サービスを実施してもよい。上記で考察したように、定位サービスモジュール３２２は、道路レベルの定位、車線レベルの定位又はグローバルマップの定位を実施してもよい。実施する定位サービスのタイプは、サービス要求にて指定されてもよい。

道路レベルの定位には、要求を発している車両が走行している道路区分の識別が含まれる場合がある。しかし、道路レベルの定位は、車線レベルの定位ほど正確ではない。例えば、道路レベルの定位の解像度は約１０メートルである場合がある。道路レベルの定位は、自律型車両、半自律型車両又は従来型車両など、あらゆるタイプの車両に有用である可能性がある。

車線レベルの定位には、要求を発している車両がどの車線に配置されているか、あるいは要求を発している車両が車線内のどこに位置決めされているかの識別が含まれてもよい。車線レベルの定位は、道路レベルの定位よりも正確である。例えば、車線レベルの定位の解像度は約１メートルである場合がある。車線レベルの定位は、自律型車両と半自律型車両にのみ有用である場合があり、従来型車両には特に有用ではない場合がある。人間の運転者が乗車している従来型車両の場合、人間の運転者は、自分の感覚を用いて車線内の位置を概ね評価することができる。そのため、人間の運転者にどの車線にいるかを伝える車線レベルの定位メッセージを受信しても、通常は運転者の助けにはならないことになる。しかし、自律型車両の場合、車線レベルの定位メッセージの受信を使用して、搭載センサデータを補完するか置換して、適切な運転操縦を実施してもよい。

グローバルマップ定位には、マップ上の要求を発している車両のグローバル座標の識別が含まれる場合がある。これは、自律型車両又は従来型車両のいずれかがその地図上の位置を特定するのに有用である場合がある。自律型車両は、ルート案内の一部としてこの情報を使用する場合がある。従来型車両は、運転者を支援するためにこの情報を人間の運転者に表示する場合がある。

実施形態では、定位サービスモジュール３２２は、路側サーバ１０２のセンサ３０７によって取り込まれたセンサデータに基づいて、道路レベルの定位、車線レベルの定位又はグローバルマップの定位を実施してもよい。いくつかの例では、定位サービスモジュール３２２は、要求を発している車両から定位サービス要求の一部として受信したセンサデータに基づいて定位を実施してもよい。即ち、車両が、搭載センサを使用してセンサデータを収集し、車両自体の計算資源ではなく、路側サーバ１０２の計算資源を利用して定位を実施してもよい。いくつかの例では、定位サービスモジュール３２２は、要求を発している車両から受信したセンサデータと、路側サーバ１０２のセンサ３０７によって取り込まれたセンサデータとの組み合わせに基づいて定位を実施してもよい。

決定サービスモジュール３２４は、要求を発している車両から決定サービス要求を受信した後、決定サービスを実施してもよい。上記で考察したように、決定サービスモジュール３２４は、安全関連の決定サービス、エネルギー効率関連の決定サービス及び移動時間関連の決定サービスを実施してもよい。決定サービスモジュール３２４は、要求を発している車両から受信したサービス要求に基づいて、要求を発している車両に対する１つ又は複数の運転決定を判定してもよい。決定サービスに対するサービス要求には、搭載車両センサによって収集されたデータが含まれる場合があり、安全関連の決定サービス、エネルギー効率関連の決定サービス又は移動時間関連の決定サービスが望ましいかどうかを指定してもよい。あらゆるタイプの車両があらゆるタイプの決定サービスを受信する可能性がある。

決定サービスモジュール３２４は、要求を発している車両に対する１つ又は複数の運転決定を判定してもよい。運転決定には、車線操縦、速度変更、ルート案内などが含まれてもよい。実施形態では、決定サービスモジュール３２４は、受信されたサービス要求のタイプに基づいて特定の目的を最大化するために、要求を発している車両に対する１つ又は複数の運転決定を判定してもよい。安全関連の決定サービス要求の場合、決定サービスモジュール３２４は、安全を最大化するために１つ又は複数の運転決定を判定してもよい。エネルギー効率関連の決定サービス要求の場合、決定サービスモジュール３２４は、エネルギー効率を最大化するために１つ又は複数の運転決定を判定してもよい。移動時間関連の決定サービス要求の場合、決定サービスモジュール３２４は、移動時間を最小化するために１つ又は複数の運転決定を判定してもよい。

決定サービスモジュール３２４は、決定サービス要求のタイプ（例えば、安全関連、エネルギー効率関連、移動時間関連）と、路側サーバ１０２のセンサ３０７によって取り込まれたサービス要求及び／又はセンサデータと共に車両要求から受信したセンサデータとに基づいて、サービス要求に応答して１つ又は複数の運転決定を判定してもよい。実施形態では、決定サービスモジュール３２４は、人工知能、機械学習及び／又は深層学習アルゴリズムを利用して、受信した決定サービス要求に応答して１つ又は複数の運転決定を判定してもよい。

サービスメッセージ送信モジュール３２６は、サービス要求に応答して、要求を発している車両にサービスメッセージを送信してもよい。特に、サービスメッセージ送信モジュール３２６は、受信されたサービス要求のタイプに基づいて、知覚サービスモジュール３２０、定位サービスモジュール３２２又は決定サービスモジュール３２４によって判定されたサービスメッセージを送信してもよい。上記で考察したように、いくつかの例では、ネットワークインターフェースハードウェア３０６は、ＤＳＲＣチャネル及びミリ波無線チャネルを備えてもよい。ＤＳＲＣの帯域幅はミリ波無線よりも狭くなっている。このため、サービスメッセージ送信モジュール３２６は、決定サービスメッセージ、定位サービスメッセージ、物体レベルの知覚メッセージ及び特徴レベルの知覚メッセージを、ＤＳＲＣチャネルを利用して、送信してもよい。これは、このようなタイプのメッセージが、比較的狭い帯域幅を必要とすることによる。しかし、生データ知覚メッセージには生データが含まれているため、通常、広めの帯域幅が必要である。このため、ＤＳＲＣには、生データ知覚メッセージを送信するための充分な帯域幅がない可能性がある。このため、サービスメッセージ送信モジュール３２６は、ミリ波無線チャネルを利用して、生データ知覚メッセージを送信してもよい。

サービスメッセージ送信モジュール３２６がサービスメッセージを、要求を発している車両に送信した後、サービスメッセージは、要求を発している車両が受信してもよい。従来型車両の場合、従来型車両が受信したサービスメッセージに含まれる情報が車両の運転者に表示されてもよい。いくつかの例では、この情報は、従来型車両のインターフェース（例えば、表示画面）に表示されてもよい。従来型車両の運転者がスマートフォンを利用して路側サーバ１０２にサービス要求を送信する他の例では、スマートフォンはサービスメッセージを受信し、サービスメッセージに含まれる情報をスマートフォンの表示画面に表示してもよい。車両の運転者は、表示された情報を見て、それに応じて運転決定を下してもよい。

物体レベルの知覚サービスを要求する従来型車両の場合、受信した物体レベルの知覚メッセージが、識別された路上物体に関連付けられた境界ボックスの位置と形状を示してもよい。要求を発している従来型車両又はスマートフォンは、物体レベルの知覚メッセージを受信すると、識別された路上物体の境界ボックスの画像及び／又は座標を表示してもよい。定位サービスを要求する従来型車両の場合、受信した定位メッセージが、要求を発している車両の位置を示してもよい。このため、要求を発している従来型車両又はスマートフォンは、車両の位置を示す画像を表示してもよい。決定サービスを要求する従来型車両の場合、受信した決定メッセージが、車両が実施するための推奨される運転決定（例えば、提案されたルート）を示してもよい。要求を発している従来型車両又はスマートフォンは、決定メッセージを受信した後、提案されたルート又は他の提案された運転決定の画像をディスプレイに表示してもよい。

自律型車両又は半自律型車両の場合、そのような車両の計算資源は、路側サーバ１０２からサービスメッセージを受信した後、いくつかの例では、サービスメッセージに含まれるデータをさらに処理するために、利用されてもよい。例えば、知覚サービスメッセージに含まれるデータは、知覚サービスメッセージを受信すると、車両センサ２１０によって収集されたデータと融合されてもよい。これにより、車両システム２００は、搭載車両センサ２１０によって直接収集されたデータと、路側サーバ１０２のセンサ３０７によって直接収集されたデータの両方にアクセスすることができる。このデータ融合は、物体レベルの知覚メッセージで受信された物体レベルのデータ、特徴レベルの知覚メッセージで受信された特徴レベルのデータ及び／又は生データ知覚メッセージで受信された生データを融合することを含んでもよい。

同じように、自律型車両又は半自律型車両が定位サービスメッセージを受信すると、定位サービスメッセージに含まれるデータは、車両に局所的に保存されている定位データと融合されてもよい。このデータ融合は、道路レベルの定位メッセージで受信された道路レベルの定位データ、車線レベルの定位メッセージで受信された車線レベルの定位データ及び／又はグローバルマップ定位メッセージで受信されたグローバルマップデータの融合を含んでもよい。

知覚データ又は定位データを融合した後、自律型車両又は半自律型車両は、融合された知覚データ又は定位データの追加処理を実施して、知覚情報又は定位情報（例えば、車両の定位又は近くの路上動作主体の識別）をそれぞれ判定する。融合された知覚データ又は定位データを利用することにより、車両は、搭載車両センサ２１０を使用して収集されたデータのみを使用するか、路側サーバ１０２のセンサ３０７によって収集されたデータのみを使用するよりも、さらに正確な知覚情報又は定位情報を判定することができる可能性がある。次に、車両は、融合された知覚情報又は定位情報に基づいて運転決定を下してもよい。

これとは別に、自律型車両又は半自律型車両が決定サービスメッセージを受信した後、車両は、受信した決定サービスメッセージに含まれる１つ又は複数の運転決定を実施してもよい。

図４は、図１のシステム１００にて自律型車両（例えば、車両１０４、１０６又は１０８のうちの１つ）を操作するための方法のフローチャートを示す。ステップ４００では、車両システム２００のセンサ２１０は、センサデータを受信する。センサ２１０によって収集されたセンサデータは、環境情報又は車両の近くに位置決めされた他の路上動作主体に関する情報を示してもよい。

ステップ４０２では、ネットワークインターフェースハードウェア２１２は、サービス要求を路側サーバ１０２に送信する。サービス要求は、特定のタイプのサービス用にカスタマイズされた要求を含んでもよい。実施形態では、サービス要求には、知覚サービス、定位サービス又は決定サービスに対する要求が含まれてもよい。さらに、サービス要求には、上記で考察したように、特定のタイプの知覚サービス、定位サービス又は決定サービスに対する要求が含まれてもよい。いくつかの例では、サービス要求を、運転者からの入力に基づいて生成してもよい（例えば、運転者が、サービス要求のパラメータを車両システム２００のインターフェースに入力してもよい）。他の例では、サービス要求を、プロセッサ２０２によって自動的に生成してもよい（例えば、サービス要求が、搭載車両センサ２１０によって収集されたデータに基づいて利用することができない自律運転システムによって必要とされる知覚情報に基づくものであってもよい）。いくつかの例では、サービス要求は、車両センサ２１０によって収集されたデータを含んでもよい。

ステップ４０４では、ネットワークインターフェースハードウェア２１２は、送信されたサービス要求に応答して、路側サーバ１０２からサービスメッセージを受信する。上記のように、サービスメッセージは、カスタムサービス要求に応答する情報を含んでもよい。サービスメッセージは、データ記憶部品２１４に保存されてもよい。

ステップ４０６では、プロセッサ２０２は、サービスメッセージに含まれるデータを、車両システム２００のセンサ２１０によって収集されたデータと融合させる。知覚サービスメッセージの場合、プロセッサ２０２は、知覚サービスメッセージに含まれる知覚データを、センサ２１０によって収集された知覚データと融合させてもよい。定位サービスメッセージの場合、プロセッサ２０２は、定位サービスメッセージに含まれる定位データを、センサ２１０によって収集された定位データと融合させてもよい。決定サービスメッセージの場合、一般に、センサ２１０によって収集されたデータと融合するデータはない。さらに、いくつかの例では、知覚サービスメッセージ又は定位サービスメッセージで受信されたデータは、センサ２１０によって収集されたデータと融合されない場合がある。例えば、センサ２１０は、サービスメッセージで受信されたデータと融合することができる任意のデータを収集していない場合がある。これとは別に、サービスメッセージで受信されたデータのみを使用することが望ましい場合がある（例えば、このデータは、車両センサ２１０によって収集されたデータよりも信頼性が高い場合がある）。決定サービスメッセージが受信される例又は路側サーバ１０２から受信されたデータを車両システム２００によって取り込まれたデータと融合することが望ましくない例では、図４のステップ４０６は省略されてもよい。

ステップ４０８では、車両システム２００は、融合データを分析する。いくつかの例では、車両システム２００の自律運転モジュールは、融合データを分析して、知覚情報又は定位情報を判定してもよい。例えば、自律運転モジュールが、知覚サービスメッセージで受信した生データ又は特徴レベルデータを分析して、路上動作主体を識別してもよい。データが融合されないいくつかの例では、上記の例で考察したように、車両システム２００の自律運転モジュールは、路側サーバ１０２からのサービスメッセージで受信されたデータのみを分析して、知覚情報及び／又は定位情報を判定してもよい。これとは別に、受信されたサービスメッセージが決定サービスメッセージを含み、サービスメッセージに分析するデータがない例では、ステップ４０８は、図４から省略されてもよい。

ステップ４１０では、車両システム２００の自律運転モジュールは、路側サーバ１０２から受信したデータ及び／又は上記で考察したデータ又は融合データの分析に基づいて運転指示を判定する。知覚サービスメッセージが受信される例では、自律運転モジュールは、（例えば、路上動作主体からの特定の距離を維持するために）識別された路上動作主体に基づいて運転指示を判定してもよい。定位サービスメッセージが受信される例では、自律運転モジュールは、（例えば、道路の特定の車線内に位置決めされるように）判定された車両の定位に基づいて運転指示を判定してもよい。決定サービスメッセージが受信される例では、決定サービスメッセージに含まれる運転指示は、車両によって直接実施されてもよい。ステップ４１２では、自律運転モジュールは、ステップ４１０で判定された運転指示を実施してもよい。

図５は、図１のシステム１００の従来型車両（例えば、車両１０４、１０６又は１０８のうちの１つ）を操作するための方法のフローチャートを示す。ステップ５００では、サービス要求を路側サーバ１０２に送信してもよい。いくつかの例では、サービス要求は、車両システムのネットワークインターフェースハードウェア２１２によって送信されてもよい。他の例では、サービス要求は、車両の運転者によって操作されるスマートフォン又は他の装置によって送信されてもよい。送信されたサービス要求は、運転者によって入力されたパラメータに基づいてカスタマイズされたサービス要求であってもよい。いくつかの例では、サービス要求に対するパラメータは、運転者によって車両システム２００のインターフェースに入力されてもよい。他の例では、サービス要求に対するパラメータは、専用のアプリケーションを使用してスマートフォン又は他の装置に入力されてもよい。サービス要求は、上記で考察したように、知覚サービス要求、定位サービス要求又は決定サービス要求を含んでもよい。

ステップ５０２では、サービス要求を送信した車両システム又はスマートフォンは、路側サーバ１０２からサービスメッセージを受信する。上記のように、サービスメッセージは、サービス要求に応答する情報を含んでもよい。

ステップ５０４では、車両システム２００のインターフェース又はスマートフォンのディスプレイが、受信されたサービスメッセージに含まれる情報を表示する。知覚サービス要求の場合、１つ又は複数の識別された路上動作主体に関連付けられた境界ボックスの画像を表示してもよい。定位サービス要求の場合、要求を発している車両の判定された位置の画像を表示してもよい。決定サービス要求の場合、受信した決定サービスメッセージに含まれる運転指示に関する情報（例えば、ルートの方向又は特定の運転指示）を表示してもよい。いくつかの例では、決定サービスメッセージがルート案内又は提案されたルートを含む場合、ルート案内又は提案されたルートは、車両システム２００又は運転者のスマートフォンのルート案内又はどこで曲がるかの指示と自動的に統合されてもよい。

図６は、図１及び図３の路側サーバ１０２を操作するための方法のフローチャートを示す。 ステップ６００では、サービス要求受信モジュール３１４は、要求を発している車両からサービス要求を受信する。いくつかの例では、サービス要求受信モジュール３１４は、上記で考察したように、車両ではなくスマートフォン又は他の装置からサービス要求を受信してもよい。受信したサービス要求は、カスタマイズされたサービス要求を含んでもよい。実施形態では、サービス要求は、知覚サービスに対する要求、定位サービスに対する要求又は決定サービスに対する要求を含んでもよい。いくつかの例では、受信されたサービス要求が、要求を発している車両によって収集されたセンサデータを含んでもよい。

ステップ６０２では、標的車両識別モジュール３１６は、要求を発している車両の車両タイプを識別する。いくつかの例では、標的車両識別モジュール３１６は、要求を発している車両が自律型車両であるか、半自律型車両であるか、従来型車両であるかを判定してもよい。いくつかの例では、標的車両識別モジュール３１６は、要求を発している車両の自動化のレベルを判定してもよい（例えば、Ｌ０～Ｌ５）。標的車両識別モジュール３１６は、受信されたサービス要求の内容に基づいて、要求を発している車両の車両タイプを識別してもよい。

ステップ６０４では、路側サーバ１０２のセンサ３０７は、センサデータを収集する。特に、センサ３０７は、要求を発している車両を取り巻く道路環境に関するデータを収集してもよい。路側サーバ１０２によって収集されたセンサデータが、サービス要求を完了するために必要とされないいくつかの例では、図６のステップ６０４が省略されてもよい。

ステップ６０６では、路側サーバ１０２は、受信されたサービス要求に応答するサービスデータを判定する。知覚サービス要求の場合、知覚サービスモジュール３２０は、知覚サービスデータを判定してもよい。定位サービス要求の場合、定位サービスモジュール３２２は、定位サービスデータを判定してもよい。決定サービス要求の場合、決定サービスモジュール３２４は、決定サービスデータを判定してもよい。サービスデータは、受信したサービス要求に含まれる車両センサデータ及び／又は路側サーバ１０２のセンサ３０７によって収集されたデータに基づいて判定されてもよい。いくつかの例では、知覚サービスモジュール３２０、定位サービスモジュール３２２又は決定サービスモジュール３２４は、人工知能アルゴリズム、機械学習アルゴリズム及び／又は深層学習アルゴリズムを利用することによって、サービス要求に応答するサービスデータを判定してもよい。いくつかの例では、判定されたサービスデータは、標的車両識別モジュール３１６によって判定された、要求を発している車両の車両タイプに基づくものであってもよい。

ステップ６０８では、サービスメッセージ送信モジュール３２６は、判定されたサービスデータを含むサービスメッセージを、要求を発している車両に送信する。生データサービスメッセージの場合、サービスメッセージ送信モジュール３２６は、ミリ波無線を使用してサービスメッセージを送信してもよい。他のタイプのサービスメッセージの場合、サービスメッセージ送信モジュール３２６は、ＤＳＲＣを使用してサービスメッセージを送信してもよい。

ここで、本明細書で説明する実施形態が、オンデマンド路側ＡＩサービスのための方法及びシステムを対象とするものであることを理解されたい。車両が、サービス要求を路側サーバに送信してもよい。サービス要求は、知覚サービス、定位サービス又は決定サービスに対するカスタマイズされた要求を含んでもよい。サービス要求は、車両センサによって収集されたデータを含んでもよい。要求を発している車両は、自律型車両、半自律型車両又は従来型車両であってもよい。

路側サーバはサービス要求を受信してもよい。路側サーバは、サービス要求に基づいて、要求を発している車両の車両タイプを判定してもよい。いくつかの例では、路側サーバは、路側サーバセンサから追加のデータを収集してもよい。次に、路側サーバは、サービス要求、サービス要求に含まれるデータ及び路側サーバセンサによって収集されたデータに基づいて、サービス要求に応答するサービスメッセージを判定してもよい。いくつかの例では、路側サーバによって判定されたサービスメッセージのタイプは、要求を発している車両の車両タイプ（例えば、車両の自動化のレベル）に依存してもよい。次に、路側サーバは、判定されたサービスメッセージを、要求を発している車両に送信してもよい。車両は、サービスメッセージを受信してもよく、受信したサービスメッセージに基づいて運転者にデータを表示したり、及び／又は受信したサービスメッセージに基づいて１つ又は複数の運転機能を実行したりしてもよい。

「実質的に」及び「約」という用語は、本明細書では、任意の定量的比較、値、測定又は他の表現に起因し得る固有の不確実性の程度を表すために使用され得ることに留意されたい。このような用語はこのほか、問題となっている主題の基本的な機能に変化をもたらすことなく、定量的表現が記載した基準から変化し得る程度を表すために本明細書で使用される。

本明細書では特定の実施形態を例示し、説明しているが、特許請求される主題の精神及び範囲から逸脱することなく、他のさまざまな変更及び修正を施し得ることを理解されたい。さらに、特許請求される主題のさまざまな態様を本明細書に記載しているが、そのような態様を組み合わせて利用する必要はない。このため、添付の特許請求の範囲は、特許請求される主題の範囲内にあるそのようなあらゆる変更及び修正を網羅することが意図されている。

Claims (20)

1. 車両からサービス要求を受信するステップと、
   １つ又は複数のセンサを用いて環境データを取得するステップと、
   前記サービス要求に基づいて前記車両の車両タイプを判定するステップと、
   前記車両の前記車両タイプ及び前記環境データに基づいて、前記サービス要求に応答するサービスデータを判定するステップと、
   前記判定されたサービスデータを含むサービスメッセージを前記車両に送信するステップと、を含む方法。
2. 前記サービス要求の一部として前記車両によって収集されたセンサデータを受信するステップと、
   前記車両によって収集された前記センサデータに少なくとも部分的に基づいて、前記サービス要求に応答するサービスデータを判定するステップと、をさらに含む、請求項１に記載の方法。
3. 前記車両タイプは、前記車両の自動化レベルを含む、請求項１に記載の方法。
4. 前記サービス要求は、知覚サービスに対する要求を含み、
   前記サービスデータは、前記車両の近傍にある１つ又は複数の路上動作主体に関連付けられたデータを含む、請求項１に記載の方法。
5. 前記車両タイプが自律型車両であると判定したときに、
   前記１つ又は複数のセンサによって取り込まれた前記環境データを含む前記サービスデータを判定するステップと、
   ミリ波無線を介して前記サービスメッセージを送信するステップと、をさらに含む、請求項４に記載の方法。
6. 前記車両タイプが半自律型車両であると判定したときに、
   前記環境データに基づいて特徴を抽出するステップと、
   前記抽出された特徴を含む前記サービスメッセージを、専用狭域通信（ＤＳＲＣ）を介して送信するステップと、をさらに含む、請求項４に記載の方法。
7. 前記車両タイプが従来型車両であると判定したときに、
   前記環境データに基づいて１つ又は複数の路上動作主体の位置を判定するステップと、
   ＤＳＲＣを介して前記１つ又は複数の路上動作主体の前記判定された位置を含む前記サービスメッセージを送信するステップと、をさらに含む、請求項４に記載の方法。
8. 前記サービス要求は、定位サービスに対する要求を含み、
   前記サービスデータは、前記車両の位置を含む、請求項１に記載の方法。
9. 前記サービス要求は、決定サービスに対する要求を含み、
   前記サービスデータは、１つ又は複数の運転指示を含む、請求項１に記載の方法。
10. １つ又は複数の車両センサを用いて環境データを収集するステップと、
    車両から路側サーバにサービス要求を送信するステップと、
    前記サービス要求に応答するサービスデータを含むサービスメッセージを、前記路側サーバから受信するステップと、
    前記サービスデータを前記環境データと融合して、融合データを取得ステップと、
    前記融合データに基づいて１つ又は複数の運転指示を判定するステップと、を含む方法。
11. 前記環境データを前記サービス要求と共に前記路側サーバに送信するステップをさらに含む、請求項１０に記載の方法。
12. 前記環境データに基づいて運転条件を判定するステップと、
    前記運転条件に基づいて前記車両の運転性能を改善するデータの第１のセットを判定するステップと、
    前記判定されたデータの第１のセットに基づいて前記サービス要求を生成ステップと、をさらに含む、請求項１０に記載の方法。
13. 前記融合データに基づいて１つ又は複数の路上動作主体の位置を判定するステップをさらに含む、請求項１０に記載の方法。
14. 前記融合データに基づいて前記車両の位置を判定するステップをさらに含む、請求項１０に記載の方法。
15. コントローラを具備する路側サーバであって、前記コントローラは、
    車両からサービス要求を受信し、
    １つ又は複数のセンサを用いて環境データを取得し、
    前記サービス要求に基づいて前記車両の車両タイプを判定し、
    前記車両の前記車両タイプ及び前記環境データに基づいて、前記サービス要求に応答するサービスデータを判定し、
    前記判定されたサービスデータを含むサービスメッセージを前記車両に送信する、ように構成される、路側サーバ。
16. 前記コントローラは、
    前記車両によって収集されたセンサデータを、前記サービス要求の一部として受信し、
    前記車両によって収集された前記センサデータに少なくとも部分的に基づいて、前記サービス要求に応答する前記サービスデータを判定する、ようにさらに構成される、請求項１５に記載の路側サーバ。
17. 前記サービス要求は、知覚サービスに対する要求を含み、
    前記サービスデータは、前記車両の近傍にある１つ又は複数の路上動作主体に関連付けられたデータを含む、請求項１５に記載の路側サーバ。
18. 前記コントローラは、前記車両タイプが自律型車両であると判定するとき、
    前記１つ又は複数のセンサによって取り込まれた前記環境データを含むサービスデータを判定し、
    ミリ波無線を介して前記サービスメッセージを送信する、ようにさらに構成される、請求項１７に記載の路側サーバ。
19. 前記コントローラは、前記車両タイプが半自律型車両であると判定するとき、
    前記環境データに基づいて特徴を抽出し、
    前記抽出された特徴を含む前記サービスメッセージをＤＳＲＣを介して送信する、ようにさらに構成される、請求項１７に記載の路側サーバ。
20. 前記コントローラは、前記車両タイプが従来型車両であると判定したとき、
    前記環境データに基づいて、前記１つ又は複数の路上動作主体の位置を判定し、
    ＤＳＲＣを介して前記１つ又は複数の路上動作主体の前記判定された位置を含む前記サービスメッセージを送信する、ようにさらに構成される、請求項１７に記載の路側サーバ。

Images