JP2022542641A - 動的なイベントの特定および流布のための方法およびシステム - Google Patents

Abstract

好ましくは独立した乗り物(1)、モバイルデバイスなどである少なくとも1つの観測主体(10)からの情報を制御し、調整し、まとめるための道路インフラストラクチャによるリアルタイムの動的なイベントに関連する情報の導出および流布のための方法が、開示される。方法は、道路インフラストラクチャの道路インフラストラクチャサーバによって1つまたは複数の観測主体(10)からイベント情報を受信するステップであって、観測主体(10)の各々が、観測主体(10)のイベント情報を、いくつかの属性を含むイベントデータレコードを、イベントデータレコードを参照する一意識別子と一緒に含むイベント情報フレームとして提供する、ステップと、観測主体(10)から受信されたイベント情報フレームを収集し、分析し、複合的イベント情報、複合的イベント情報を参照する一意識別子、および観測主体(10)との通信を調整するための制御コマンドを含む組み合わされたイベント情報フレームを生成するためにイベント情報フレームを処理するステップと、組み合わされたイベント情報フレームを配信ドメイン内で配信するステップとを含む。さらに、道路を走行する乗り物搭載システムが、説明される。

Description

本出願に至るプロジェクトは、研究助成契約(grant agreement)第825012号の下で欧州連合のHorizon 2020研究およびイノベーションプログラムから資金提供を受けた。

本発明は、交通安全に関し、より詳細には、動的なイベントに関連する情報の流布のための方法および道路を走行する乗り物(road vehicle)搭載システムに関する。本発明は、乗り物に適用されるのみでなく、必要とされるセンシング、コンピューティング、および通信能力を有するモバイルデバイスの形態のオプションのその他の観測主体(observation entity)にも適用可能である。

事故および道路工事(または道路に隣接したエリアにおける土木工事)のようなイベントは、通勤者にとって予期せぬ遅延を引き起こす交通渋滞につながる場合がある。渋滞地点(choke-point)におけるそのような渋滞の継続時間は、イベントの種類により数分から数時間、数日、数週間、または数ヶ月に及ぶ場合がある。たとえば、小さな事故が、数十分続く交通渋滞につながる場合がある一方、重大な事故は、数時間続く可能性がある渋滞につながる場合がある。同様に、定期的な道路補修のようなイベントが、数日続く場合がある一方、大規模な建設プロジェクトは、数週間および数ヶ月続く渋滞を引き起こす場合がある。

既存の自動車システムは、原因や詳細をまったく明示することなく代替経路を選択するように運転者に求めるラジオ告知およびナビゲーションシステムを介した漠然とした交通渋滞の警告の中継を除いて、乗り物に道路上の一時的な渋滞地点から離れるように警告するおよび/またはそのような場所を迂回させるための効率的な対策を持たない。そのような情報は、通常、タイミングが悪く、メッセージが受信されるまでに古くなっている可能性もあり、さらには、原因およびイベントが引き起こした影響を明示する情報を含まない。

最新の分析を参照すると、乗り物の状況認識のためのほとんどすべての方法/システムは、限られた乗り物の対象物(vehicular object)に加えて外部センサおよびソフトな情報システム(soft information system)の可用性にある程度依存する。外部センサの例は、「(固定視点の)沿道のカメラ、流量測定デバイス(flow measuring device)、自動トラフィック検出器など」であり、一方、「ソフトな情報ソース(soft Information Source)」の例は、(運転者が現在の道路/交通状況を知らせるために電話する)コールセンター、FM無線局、測候所(weather station)、公共イベント情報システム、交通管理システム、道路工事情報システムなどである。ほとんどのソフトな情報システムは、正確なイベント識別情報の作成の信頼性および情報の正確性に影響を与え、情報を流布する際に遅延を招く「人的要因」を有する。さらに、コールセンターのソリューションは、運転者が電話によってイベントを報告するので不確かであり、運転者が電話によってイベントを報告することは、違法であり、危険である。

計画された経路上に存在する場合がある道路渋滞地点に関する乗り物への準リアルタイムの事前の警告の効率的で、きめ細かく、効果的な発行が可能にされるようにして動的なイベントに関連する情報の流布のための方法および道路を走行する乗り物搭載システムを改善し、さらに発展させることが、本発明の目的である。

本発明によれば、上述の目的が、好ましくは独立した乗り物、モバイルデバイスなどである少なくとも1つの観測主体からの情報を制御し、調整し、まとめるための道路インフラストラクチャによるリアルタイムの動的なイベントに関連する情報の導出および流布のための方法であって、
道路インフラストラクチャの道路インフラストラクチャサーバによって1つまたは複数の観測主体からイベント情報を受信するステップであって、観測主体の各々が、観測主体のイベント情報を、いくつかの属性を含むイベントデータレコードを、イベントデータレコードを参照する一意識別子と一緒に含むイベント情報フレームとして提供する、ステップと、
観測主体から受信されたイベント情報フレームを収集し、分析し、複合的イベント情報(composite event information)、複合的イベント情報を参照する一意識別子、および観測主体との通信を調整するための制御コマンドを含む組み合わされたイベント情報フレームを生成するためにイベント情報フレームを処理するステップと、
組み合わされたイベント情報フレームを配信ドメイン内で配信するステップとを含む、方法によって達成される。

さらに、上述の目的は、計算能力および通信能力を提供し、
乗り物の搭載センサシステムからおよび/または乗り物の運転者によって持ち運ばれるスマートデバイスからイベントに関連する生センサデータを受信し、
受信された生センサデータを処理し、生センサデータから導出されたコンテキスト的な(contextual)イベント説明情報(event-descriptive information)の形態で属性を含むイベントデータレコードを生成し、
イベントデータレコードの属性に基づいて、イベントシグネチャ(event signature)と呼ばれる一意識別子を生成し、
少なくともイベントシグネチャおよびイベントデータレコードの属性を含むイベント情報フレームを生成し、
イベント情報フレームを道路インフラストラクチャサーバに送信するように構成される車載器(onboard unit)OBUを含む道路を走行する乗り物搭載システムによって達成される。

本発明は、動的なイベントの特定、流布、および更新のための効率的な方法およびシステムを提供する。本発明の実施形態は、インフラストラクチャサーバによって集中的に調整される協調的な方法で移動物体(たとえば、乗り物)による道路イベントの状況に基づく特定および評価ならびにそのようなイベントの高速で自律的な流布を可能にする。

従来のソリューションとは対照的に、本発明による方法およびシステムは、いかなる外部センサおよび/またはソフトな情報システムにも頼ることなく(つまり、インフラストラクチャが要らず)、基本的に、目標物(つまり、乗り物)において利用可能な搭載センサクラスタを利用することに依拠し、スマートフォンがセンサの独自のエコシステム(ecosystem)を提供するので運転者/同乗者によって持ち運ばれるスマートフォンも含むことができる。本発明の実施形態は、イベントを正確に特定および決定し、それを準リアルタイムで流布するために、あらゆる所に行き渡っているモバイルネットワークインフラストラクチャにも依拠する。したがって、本発明の範囲は、幹線道路だけでなく、オプションの道路網に当てはまる。主に依存するものは、モバイルネットワークインフラストラクチャの可用性である。さらに、本発明の実施形態は、独立した移動可能物体(つまり、乗り物)によって生成された情報を利用することによって人間の介在を完全に排除し(ゼロタッチ(zero touch))、したがって、より厳密で、一貫性があり、きめ細かいイベントの特定および(その他の乗り物への、または事故の場合は初期対応者(first responder)への)流布を可能にする。したがって、本発明の実施形態は、自律走行(自立運転)車にも適する。

対照的に、従来技術の手法は、道路上の複数の乗り物からの情報の収集を集中的に調整しないようである。乗り物は、乗り物の状況の情報をインフラストラクチャサーバに独立して周期的に送信する。しかし、これは、同じ車によっておよびエリア内の複数の車によって同じイベントを報告する重複した情報を周期的に送信するという問題を引き起こし、これは、(特にアップリンクの)ネットワークリソースを不必要に浪費し、その結果、高い処理負荷およびその他のモバイルデータ通信の長い遅延を招きながらネットワークの輻湊および過負荷をもたらす場合がある。

本発明の実施形態は、イベントおよびその重大性を特定し、分析し、この情報を、準リアルタイムの初期対応者への通知、ならびに/または道路上でイベントが渋滞地点の原因となっているエリアの特定の範囲へのナビゲーションマップおよび経路計画の動的な更新などの様々な方法で流布するために、乗り物の搭載センサおよび計算能力(搭載計算リソース)を利用してイベントの一意識別子(イベントシグネチャ)を導出し、道路インフラストラクチャサーバと協力してV2X通信を探索する。課題は、最小限の処理および無線リソースを消費する費用対効果の良い方法でイベント情報の適時の正確な獲得およびそのイベント情報の乗り物への流布を可能にすることである。

実施形態によれば、本発明は、1つまたは複数の独立した乗り物またはその他の観測主体からの情報を制御し、調整し、まとめるためのインフラストラクチャサーバにおける方法に関する。これは、複数のソース、すなわち、乗り物からのイベント情報の特定およびクラスタリングと、選択された属性のセット、および必要な場合に関連する更新された情報を送信するように乗り物に命令するための制御フラグと一緒に、組み合わされたイベント識別子を生成することとを含んでもよい。さらに、これは、きめ細かく、より完全で、正確な情報の更新を提供するための合同分析のために、複数の独立した乗り物からの収集されたイベント情報をまとめることを含んでもよい。

実施形態によれば、乗り物および/またはその他の観測主体は、イベントのそれらの観測/記録に関する情報をイベント情報フレームの形態で提供する/通知してもよい。道路インフラストラクチャサーバは、乗り物および/またはその他の観測主体から受信されたイベント情報フレームを収集、分析し、それから、特別なフレーム(すなわち、組み合わされたイベント情報フレーム)に符号化される場合がある複合的な情報のスナップショットを生成するためにそれらのイベント情報フレームを処理してもよい。配信ドメイン内の組み合わされたイベント情報フレームの配信は、ブロードキャスト、マルチキャスト、エニーキャスト、またはユニキャスト送信によって実現されてもよい。配信ドメインのサイズは、それぞれのイベントのイベント影響因子(event impact factor)および/または遅延因子(delay factor)から導出されることが可能である影響全体によって決定されてもよい。

実施形態によれば、イベント情報フレームに含まれる一意識別子は、ハッシュアルゴリズムを適用することによるなどしてイベントデータレコードの選択された属性から導出されるイベントシグネチャであってもよい。代替的に、識別子は、たとえば、シーケンス番号および乗り物の識別子などを含む、それぞれの乗り物から導出される曖昧でない番号であってもよい。同様に、組み合わされたイベント情報フレームに含まれる一意識別子は、ハッシュアルゴリズムを適用することによるなどして複合的イベント情報から導出される組み合わされたイベントシグネチャであってもよい。

実施形態によれば、本発明は、カメラ、ライト(light)、アクセル(accelerator)などのようなセンサ、プロセッサ、メモリ、およびネットワークインターフェースを有するOBUなどの車搭載システムに関する。搭載システムは、イベント、道路標識を特定し、さらに、道路標識に書かれる場合があるオプションのテキスト情報を解読するために使用される場合がある画像認識アプリケーションを含んでもよい。インフラストラクチャの計算(infrastructure computation)は、異なる製造元のOBUからのイベント情報を異なる画像/テキスト認識アプリケーションと整合させることを可能にする。

実施形態によれば、画像/動画データを含む感知可能なイベントデータのセット(たとえば、イベントタイプ、impact_factor、推定されたイベントの継続時間、delay_factorなど)を用いてローカルの一意イベント識別子を導出するために、(カメラ、GPS、速度(speed)、通信モジュール、レーダー、LIDARなどのような)搭載センサから収集された生データを特定し、処理する(フィルタリング、分類、および/または分析を含む)方法が、乗り物内で実行されてもよい。乗り物は、この情報--イベント情報フレームに含まれる--をインフラストラクチャサーバに送信するように構成されてもよい。

実施形態によれば、乗り物は、示されたイベントの乗り物との関連性を特定し、要求されたアクションを実行するために、インフラストラクチャサーバから送信された「組み合わされたイベント情報フレーム」を復号するようにさらに構成されてもよい。それぞれのアクションは、それぞれの制御フラグを設定するまたはアクティブ化することによって「組み合わされたイベント情報フレーム」内でインフラストラクチャサーバによって示されてもよい。たとえば、"SEND_MORE"フラグが、さらなるイベントに関連する情報をインフラストラクチャサーバに送信するように乗り物に要求してもよく、"UPDATE"フラグが、「組み合わされたイベント情報フレーム」が更新された情報を含むことを乗り物に通知してもよい。

実施形態によれば、インフラストラクチャサーバは、1つもしくは複数のMECサーバおよび/またはコアサーバを含んでもよい。特に、インフラストラクチャサーバは、同じイベントの状況を報告する乗り物のクラスタを特定するための重複イベント検出処理のため、および、たとえば、畳み込み関数を適用することによって乗り物のこのクラスタのイベント情報を組み合わせるためのメカニズムを実行するように構成されてもよい。さらに、インフラストラクチャサーバは、イベント情報の正確性を決定するために乗り物のこのクラスタからの入力に基づいて属性および/または画像(適用される場合)を評価するように構成されてもよい。

本発明の実施形態は、インフラストラクチャサーバによる情報の調整および特定によって、外部の静的な情報システムに頼ることなく、乗り物が重複した情報を不必要に送信することを防止することを目標とする。さらに、複数の独立した乗り物によって送信された状況の情報が、きめ細かく、より完全な情報を提供するためにインフラストラクチャサーバにおいて(たとえば、グラフAIもしくはML技術または信号/画像処理を用いて)一緒に分析されることが可能であり、そして、このきめ細かく、より完全な情報が、関連する乗り物および/またはステークホルダ(たとえば、緊急対応者(emergency responder))に流布される。

実施形態によれば、情報調整タスクの一部として、インフラストラクチャサーバは、より正確なイベント情報を作り上げるために、必要とされる場合、さらなる関連する情報を送信するように乗り物に命令するように構成されてもよい。重複する情報を送信することを防止することは、乗り物から上流に送信される情報を処理するバックエンドサーバへの余計な処理負荷を減らすだけでなく、(特にアップリンクの)ネットワークリソースを節約する結果となり、これは、そうでなければ、ネットワークの輻湊および過負荷をもたらし、それによって、イベント情報の流布の遅延を引き起こす場合がある。

本発明の教示を有利に設計し、さらに発展させるいくつかの方法が存在する。この目的で、それは、一方で従属請求項に、他方で例として図によって示される本発明の好ましい実施形態の以下の説明に委ねられることになる。図の助けによる本発明の好ましい実施形態の説明に関連して、教示の概して好ましい実施形態およびさらなる発展が、説明される。

本発明の実施形態によるイベントの特定および流布のためのシステムの配置のための道路シナリオ(road scenario)の概要を示す概略図である。 本発明の実施形態によるイベント記録エンジンEREを含む乗り物の車載器を示す機能の概要の図である。 本発明の実施形態によるEREによる搭載センサデータのサンプリングおよび処理を示す図である。 EREから受信された情報を処理するインフラストラクチャサーバを示す機能の概要の図である。 EREから受信された情報を処理するインフラストラクチャサーバを示すプロセスの概要の図である。

本発明の実施形態は、一方で、カメラ、GPS、モニタ、通信モジュール、レーダー、LIDARなどの乗り物内の搭載センサを利用し、他方で、モバイルネットワークインフラストラクチャを利用する。モバイルネットワークインフラストラクチャは、イベントおよびイベントの場所について警告し、正確性の極めて高いリアルタイムのイベント情報を提供するために、迅速で、低コストで、動的で、正確なイベントの特定と、道路ユーザ、すなわち、乗り物およびその他のステークホルダ(たとえば、緊急対応者)への流布を可能にするために1つまたは複数のインフラストラクチャサーバ(たとえば、マルチアクセスエッジコンピューティングMECサーバ)によって制御され、調整され、管理されてもよい。イベントの場所は、交通の遅延を引き起こす場合があり、渋滞、道路工事、事故などのイベントによって特徴付けられることが可能である経路上の地点である。そして、そのような警告を受信する受信者は、受信された情報を、たとえば、乗り物がイベントの場所(たとえば、渋滞地点)を迂回することを可能にする経路を再計算することによって異なる方法で利用することができる。プロセスは、スケーラブルなままでありながら計算および無線リソースの最小限の消費で可能にされる。

図1は、乗り物1とインフラストラクチャとの両方の処理/計算能力を利用する本発明の実施形態によるイベント特定流布システムと一緒に道路シナリオを概略的に示す。示された実施形態によれば、インフラストラクチャは、多数の路側機(RSU: road-side unit)2、エッジサーバ(ES)3、およびコアサーバ4を含む。

RSU 2は、観測主体10と、つまり、特に乗り物1と、ただし、モバイルデバイスなどとも情報をやりとりするために使用される無線基地局などの通信デバイスである。この目的で、RSU 2は、沿道に配置される。たとえば、RSU 2は、信号またはセルラ無線基地局に設置されることが可能である。

エッジサーバ(ES)3は、エッジクラウドデータセンター5などの中心的な場所に置かれるコンピューティングプラットフォームであるか、またはそれらのエッジサーバ(ES)3は、分散され、たとえば、信号などにRSU 2と一緒に置かれてもよい。実施形態によれば、エッジサーバ3は、エッジクラウドインフラストラクチャのMEC(マルチアクセスエッジコンピューティング)サーバの形態で実装されてもよい。コアサーバ(CS)4は、コアデータセンター6に実装されてもよい。

図1のシナリオに関連して示された実施形態によれば、ES 3は、エッジクラウドデータセンター5に置かれると仮定される。RSU 2は、ES 3とN:1で接続され、一方、ES 3は、コアデータセンター6に実装されたCS 4とN:1で接続される。一方、乗り物1は、計算および通信能力を提供する車載器(OBU、図1に示さず)を備えていると期待される。図1は、乗り物1が通信およびデータアクセスを目的としてRSU 2に接続される参照シナリオおよびインフラストラクチャのレイアウトを示す。

特に、図1は、右車線に渋滞地点がある両面通行の幹線道路を示す。示された渋滞地点は、道路建設などの何らかのイベントが原因である。イベントの場所は、イベントについてのテキスト情報と、イベント区域内の制限速度、イベントの予測される継続時間、およびその他の警告または迂回路情報などの必要な情報とを有する警告灯、警告標識、および道路標識の存在によって特徴付けられる。

図2は、図1のシナリオで示された乗り物1の車載器OBUの機能の概要を示す。示された実施形態によれば、OBUは、以後、イベント記録エンジン(ERE)7と表記されることがある処理ユニットを含み、処理ユニットは、以下で詳細に説明されるように、概して、イベントデータレコードを導出するために搭載生センサデータをサンプリングし、処理するように構成され、そして、イベントデータレコードは、一意のイベントシグネチャを導出するために使用される。それから、一意のイベントシグネチャは、図1に示されたエッジサーバ3などのインフラストラクチャサーバに送信されてもよい。

一部の実施形態によれば、乗り物1によるイベントデータの処理は、乗り物1の搭載センサの出力、たとえば、乗り物1が撮影したイベントのカメラ画像の処理に基づいて乗り物1がイベントを検出するときにトリガされてもよい。乗り物1の搭載センサシステムは、図2のステップS201に示されるように、画像を撮影し、それらの画像を処理のために車載器(OBU)に送信するようにトリガされてもよい。たとえば、1つのトリガイベントは、乗り物1の速度が許される制限速度未満に大幅に落ち、混雑した状況を示唆するとき、または乗り物1の目の前の事故を示唆する急なブレーキ操作であってもよい。そのようなトリガが発生すると、OBUは、乗り物1のOBUの一部であってもよいイベント記録エンジン(ERE)7にキャプチャされた生データを提供する/入力するためのサンプリングを開始するように搭載センサに求める。

図2の例示的な機能の概要によれば、ERE 7は、ステップS202に示されるように、搭載カメラからの画像を含む生センサデータをフィルタリングし、処理し、分類するための必要な機能を含む。特に、示された実施形態によれば、ERE 7は、画像/テキスト認識および処理アプリケーション701、データフィルタリングおよび処理ユニット702、ならびに分類機能703を含む。

ERE 7の出力は、ステップS203に与えられるように、ERE 7の処理の一部として生データから導出された処理された状況データを含むEvent-dataレコードである。たとえば、乗り物1の搭載カメラから受信された画像から、ERE 7の一部である画像/テキスト認識および処理アプリケーション701は、たとえば、道路標識に書かれる場合があるオプションのテキスト情報を解読してよりはっきりしたイベントの状況を生成することによってイベントに関連する情報を特定してもよい。評価されたイベントの状況に基づいて、ERE 7は、(event_typeとして記録されてもよい)イベントの種類を明示してもよい。さらに、乗り物1の様々なセンサから受信された関連する時間的情報が、特定されたイベントの潜在的な影響に関する情報を導出するために一緒に処理されることが可能である。たとえば、この情報は、event_impact_factorとして記録されてもよい。

下のTable 1(表1)は、イベントデータの非網羅的なリストをそれぞれの定義とともに有するEvent-dataレコードの例示的な実施形態を提供する。

実施形態によれば、ERE 7は、Event-dataレコードに基づいて、イベントデータレコードを参照する一意識別子として構築される一意のevent_signatureを生成する。event_signatureは、ハッシュアルゴリズムなどのいくつかのよく知られている方法のうちの1つによってEvent-dataレコードから導出されることが可能である。実施形態によれば、たとえば、event_geo_locationおよびspeed_rangeのような上のTable 1(表1)に規定されたEvent-dataの粒度(granularity)は、ERE 7が距離および/または速度のわずかな変化(つまり、粒度の閾値未満)と無関係に同じevent_signatureを生成することを保証するために粗く(つまり、構成可能な粒度の閾値を超える)保たれる。

ERE 7は、event_signatureを生成した後、図2のステップS204に示されるように、"event_Information_frame"を生成する。この"event_Information_frame"は、event_signature、event_signatureが生成されるEvent-dataレコードの属性、ならびに乗り物1の搭載センサシステムのカメラが撮影したイベントの画像および/または動画のセットからなる。そして、event_Information_frameは、そのevent_Information_frameをMECサーバなどの関連するES 3に中継することができるRSU 2(たとえば、モバイルBS)に送信される。

図3は、本発明の実施形態による、搭載センサデータをサンプリングし、処理するERE 7の詳細なプロセスの論理を示す図である。概して、サンプリングのラウンド(round)の数を制限し、複数のラウンドの間の導出されたevent_signatureが一意であり、それらの複数のラウンド後に、乗り物1がevent_Information_frameをRSU 2を介して関連するES 3に送信することを保証するために、判断論理がプロセスに含められてもよい。以降、プロセスが、より詳細に説明される。

プロセスは、S302に示されるように、N:=0と設定することおよびM:=0と設定することにより2つのカウンタNおよびMをまず初期化することによってS301において開始する。S303において、乗り物1のOBUが、乗り物1の搭載センサシステムによって収集された(カメラ画像および/または動画、GPS座標、速度および方向情報などの)生センサデータを受信する。基本的に、このステップは、図2のステップS201に対応する。

次に、S304において、ERE 7の専用アプリケーションが、画像認識およびセンサデータの処理ならびにデータのフィルタリングおよび分類を実行する。基本的に、このステップは、図2のステップS202に対応する。

S305において、ERE 7は、前のステップにおいて実行されたデータ分析の結果に基づいてイベントデータを生成する(図2のステップS203に対応する)。このイベントデータに基づいて、S306において、乗り物1のOBUが、イベントデータからの選択された属性のセットに基づいて(event_signatureと表記される)一意のイベントシグネチャを導出し、生成する(図2のステップS204に対応する)。

示された実施形態によれば、プロセスは、2つの閾値、すなわち、T>T'であるようなTおよびT'を定義する。閾値T'は、搭載センサからデータを収集し、サンプリングするサンプリングのラウンドの数を管理するように意図される。一方、この閾値Tは、導出されたevent_signatureの一意性を保証するためにプロセスが繰り返される回数を管理するように意図される。

より詳細には、S307に示されるように、ERE 7は、event_signatureを導出するために生データをT'回サンプリングし、処理し、そのevent_signatureが一意であることを保証する。(S308において実行される)event_signatureの一意性のテストが失敗する場合、同じプロセスが、T回繰り返される(S309)。一意のevent_signatureがEvent-dataレコードから導出された後、イベント情報フレームが、図2を参照して上で説明されたように生成され、(S310に示されるように)RSU 2を介してES 3に送信される。T回の繰り返しの後、一意のevent_signatureが導出されなかった場合、ERE 7は、処理を停止し、最後のEvent-dataレコードおよびそのEvent-dataから導出されたevent_signatureをRSU 2を介してES 3にイベント情報フレーム内で送信すると規定されてもよい。

搭載センサデータのサンプリングレートは、後で説明されるように、ES 3がイベントのきめ細かい見方(perspective)を生成するためにイベントデータのさらなるサンプルを送信するように乗り物1に要求する場合、インフラストラクチャによって制御されてもよいことに留意されたい。

図4および図5は、インフラストラクチャの観点から見た、つまり、RSU 2、ES 3、およびCS 4の観点から見た上述の方法の実施形態を示す。特に、図4が、ERE 7からの情報を処理するインフラストラクチャサーバの機能の概要を示す一方、図5は、インフラストラクチャサーバにおけるERE 7から受信された情報の処理のプロセスの概要を示す。図4は、合計4つの観測主体10、すなわち、"A"、"B"、"C"、および"D"とラベル付けされた乗り物1を示す。

図4を参照すると、ステップS401において、"A"および"B"とラベル付けされた2つの乗り物1の各々が、(図2および図3に関連して上で説明されたように)イベント情報フレームを生成し、このフレームをRSU 2に送信する。そのようなイベント情報フレームを受信するRSU 2は、そのようなイベント情報フレームを、RSU 2自体か、またはエッジ(すなわち、ES 3)および/もしくはコア(すなわち、CS 4)の何らかの専用インフラストラクチャサーバかのどちらかに実装された処理論理に送信する。処理論理がMECサーバなどのES 3内に実装されると仮定すると、このサーバは、イベント情報フレーム内のevent_geo_locationパラメータを使用して特定されることが可能である同じ場所/エリア内の乗り物1から受信されたイベント情報フレームをグループ分けしてもよい。

ステップS402に示されるように、インフラストラクチャサーバは、それから、"A"および"B"とラベル付けされた乗り物1からのイベント情報フレーム内で受信された情報を一緒に処理して、高品質な/きめの細かいイベントの見方を生成してもよい。このプロセスの一部として、インフラストラクチャサーバは、複数のイベント情報フレームからのevent_signatureを組み合わせて、(combined_event_signatureと表記される)組み合わされたイベントシグネチャを導出してもよい。組合せは、何らかの符号化技術を使用することによって、または複数のイベントシグネチャの畳み込みによって実行されてもよい。たとえば、図4を参照すると、combined_event_signature (S)は、"A"および"B"とラベル付けされた乗り物1からのevent_signature S1およびS2を組み合わせることによって形成されてもよい。combined_event_signatureを生成する理由は、ERE 7の画像/テキスト認識アプリケーション701の出力が、上のTable 1(表1)に含まれるvehicle_typeによって示されてもよい異なる乗り物の製造元によって変わる場合があるからである。したがって、複数の乗り物1がそれらのイベントデータレコードおよびそれらの導出されたevent_signatureをインフラストラクチャサーバに報告するならば、包括的で正確なイベントの説明を生成することができる。

実施形態によれば、combined_event_signature (S)は、SEND_MOREフラグおよび/またはUPDATEフラグなどのcontrol_flagならびに構成要素のイベント情報フレームからの属性と一緒にCombined-Event-Information-Frameに埋め込まれてもよい。オプションで、画像/動画情報、警告メッセージ、および/またはマップ更新情報も、Combined-Event-Information-Frameに埋め込まれることが可能である。本発明の実施形態によるCombined-Event-Information-Frameの包括的なフォーマットが、図4に示される。

ステップS403に示されるように、上述のように複数のソースからのイベント情報を処理した後、インフラストラクチャサーバは、更新された情報を有する生成されたCombined-Event-Information-Frameをブロードキャストする。乗り物1のOBU内のデコーダは、組み合わされたイベントシグネチャ(S)を復号して、構成要素のevent_signature(すなわち、説明されたシナリオにおいてはS1およびS2)を抽出し、combined_event_signatureにマッピングされる内部のイベントデータベース(EDB)に、更新された情報要素を個々のevent_signatureと一緒に記憶する。それから、このデータベースは、後で説明されるように、インフラストラクチャに情報を送信すべきか否かを判断するために、イベントの場所に接近するその後の乗り物1によって使用されてもよい。Combined_Event_Information-Frameによって更新された後のEDBの例示的な実施形態が、下のTable 2(表2)に示される。この実施形態はブロードキャストされた情報に基づくので、Combined_Event_Information_Frameを受信するすべての乗り物1が、同じエントリを持つ。

図4に示されるように、イベントの場所にまだ到着していない"D"とラベル付けされた乗り物1も、このブロードキャストされた情報を受信し、その乗り物1のEDBが、上のTable 2(表2)に示されたように更新される。"D"とラベル付けされた乗り物1がイベントの場所に到着するとき、イベント特定プロセスが、上述のようにトリガされる。しかし、乗り物"D"は、その乗り物"D"が観測している同じイベントが先行する乗り物1によって前に報告されたか否かを判定するためにその乗り物"D"の内部のEDBを調べる。

イベントが前に報告されたかどうかまたはそのイベントが新しいイベントであるかどうかを判定するために乗り物"D"が使用することができる多くのインジケーションが、EDB内に存在する。たとえば、実施形態によれば、その乗り物"D"は、イベントに関して内部で導出された独自のevent_signatureをその乗り物"D"のEDBに既に記憶されているevent_signatureと比較することができる。乗り物"D"がevent_signatureとしてS1を導出する場合、乗り物"D"は、Sによって示されるように、イベントが既に報告され、処理されたこと、その乗り物"D"が更新されたEvent Data Recordを有することを知る。その場合、乗り物"D"は、プロセスを停止し、そのイベントをインフラストラクチャサーバに報告しない。代替的にまたは追加的に、Updated Event Data Record内のgeo_location情報は、イベント特定プロセスをトリガすべきか否かを乗り物"D"が判断することを可能にする。

実施形態によれば、同じプロセスが、イベントがいつ解決されたかを報告するために使用されることが可能であり、そして、これは、乗り物1のそれぞれのEDBから特定のEvent Data Recordを消去するために乗り物1にブロードキャストされることが可能である。したがって、この方法は、イベントの報告の重複および無線トラフィックの負荷を減らし、したがって、コンピューティング、ネットワーク、および無線リソースを含むインフラストラクチャの消費を減らす。

さらに、インフラストラクチャサーバによって導出される(上のTable 1(表1)に規定された)impact_factorおよびdelay_factorが、ブロードキャストドメインのサイズをインフラストラクチャサーバが決定することを可能にすることも可能である。たとえば、高いimpact_factorおよび高いdelay_factor(つまり、構成可能な閾値を超える)を有するイベントの場合、インフラストラクチャサーバは、より広い地理的エリアにそのようなイベント情報をブロードキャストするように構成されてもよい。

上述のプロセスの概要に関連して、図5は、本発明の実施形態によるインフラストラクチャのサーバの観点から見たプロセスの論理を示す。S500において開始した後、S501に示されるように、RSU 2が、event_signature、event_data、およびevent_signatureがそれらに基づいて導出されたカメラ画像を運ぶEvent_Information-FrameをRSU 2のカバーエリア内の乗り物1から受信する。

次に、S502に示されるように、RSU 2は、報告する乗り物1によって導出されたevent_dataに基づいてevent_signatureを(再)分析するために、このデータをローカルで処理するか、またはこのデータを遠隔の処理サーバ、たとえば、ES 3に送信する。より詳細には、RSU 2またはES 3は、同じイベントのエリア内の複数の乗り物1から受信されたデータおよび/または画像を確認し、分析するように構成されてもよい。たとえば、交差点において、異なる角度から交差点の画像を撮影するいくつかの車が存在する場合がある。一部の実施形態によれば、グラフAI技術が、(1)イベント情報が重複しているまたはまだ最新であるかどうかを特定し、(2)複数の画像を一緒に処理してイベントのより正確な情報を提供するために画像を分析するために適用されてもよい。乗り物1からのさらなる情報が必要とされるかどうかの判断が、S503においてなされる。

ES 3(またはCS 4)が、たとえば、イベントのより正確な識別情報を生成するために乗り物1からのさらなる情報を必要とする場合、ES 3(またはCS 4)は、S504に示されるように、制御フラグSEND_MOREフラグがTRUEに設定されるようにしてCombined-Event-Information-Frameをブロードキャストする。メッセージを認識する乗り物1は、図2および図3を参照して上で説明されたプロセスに従ってさらなる情報を送信する。これは、ES 3(またはCS 4)がさらなる情報が必要とされず、イベントが正確に特定され、処理されたと判定するまで継続する。この場合、プロセスは、ステップS505に進む。

S505において、処理インフラストラクチャサーバ、すなわち、ES 3またはCS 4が、更新された情報とともにRSU 2を介して最終的なCombined-Event-Information-Frameをブロードキャストする。Combined-Event-Information-FrameがEvent-Information-Frame内で受信された更新された情報からの更新された情報を含む場合、UPDATEフラグと呼ばれるCombined-Event-Information-Frame内の制御フラグが、TRUEに設定されてもよい。

実施形態によれば、Combined-Event-Information-Frameは、オプションで、イベントの更新された画像、たとえば、異なる報告する乗り物1からの画像を組み合わせた後に形成されたイベントの3D画像を運んでもよい。Combined-Event-Information-Frameは、オプションで、イベントの種類に適した好適な警告信号および/またはマップの更新を運んでもよい。たとえば、好適な警告は、(上のTable 1(表1)に定義された)event_impact_factor、delay_factor、estimated_event_duration、estimated_delay、およびtraffic_stateに応じてインフラストラクチャサーバによって導出されてもよい。受信された情報に基づいて、乗り物1のローカルのナビゲーションシステムが、経路を再計算してもよい。実施形態によれば、それぞれの処理サーバが、イベントを迂回する/回避するための新たな経路計画を提案してもよい。結果として、これらの実施形態は、アップリンクのトラフィックが削減されたマップおよび/または経路計画の動的な更新を可能にし、それによって、インフラストラクチャサーバにおいて無線リソースおよび計算リソースを節約する。

イベントの関連性および/または重大性に応じて、高いimpact_factorおよびdelay_factor、つまり、構成可能な閾値を超えるimpact_factorおよびdelay_factorを有するイベントの場合、処理サーバが中央サーバ、たとえば、CS 4にマップの更新を中継すると規定されてもよい。これは、中央サーバがマップの更新を行い、それらのマップの更新をすべてのRSU 2にプッシュすることを可能にする。マップの更新は、ブロードキャストされるとき、受信する乗り物1のEDBに記憶されるevent_signatureも含む場合がある。これは、上述のように、以前の乗り物1によって既に報告されたイベントの不必要な報告から守るために行われる。

最後に、ステップS506に示されるように、乗り物1によってCombined-Event-Information-Frameが受信されると、OBUが、上述のように、"Combined-Event-Signature"を復号してローカルのイベントデータにマッピングし、乗り物1のEDB内の関連する情報を更新する。

インフラストラクチャ内の乗り物の情報の処理は、RSU 2が処理能力を有するという条件でRSU 2において行われるか、またはエッジデータセンター5内のES 3に中継されることに留意されたい。それから、ES 3は、処理された情報(すなわち、event_signature)を乗り物1にそれに関連付けられるRSU 2を介して中継する。この情報をコアデータセンター6内のCS 4にさらに中継する判断が、パラメータevent_impact_factor、delay_factor、estimated_event_durationの値から決定された永続性のレベルに応じて行われてもよい。たとえば、継続時間の長い影響の大きいイベントは、マップの更新が将来の経路計算のためにずっと広い領域内の乗り物1にブロードキャストされることが可能であるようにCS 4に中継されてもよい。言い換えると、イベント影響因子の導出が、マップの更新の流布の範囲に関する判断を可能にする。

渋滞地点がマップ上にピンを立てられるようにしてマップが更新された後、次に乗り物1が渋滞地点のいずれかに接近するとき、センサに情報を請求するために乗り物1のOBUにトリガが送信される。イベントが解決され、交通の流れが正常である場合、以前報告されたイベントの解決のインジケーションを有する、以前のイベントシグネチャとは異なるイベントシグネチャ(たとえば、異なるハッシュ)が、計算される。そして、これは、図2および図4に示されたのと同様にしてES/CS 3、4に送信され、ES/CS 3、4によって処理されてもよい。結果として、マップが、再更新されてもよく、それぞれの渋滞地点のピンが、削除されることが可能である。したがって、イベントが終わり、渋滞地点が解消した場合に更新を通知するために同じプロセスが使用されることが可能であることが、本発明の実施形態の利点である。

実施形態によれば、event_signatureと、関連するevent_dataレコード毎のイベント説明情報を含む属性/値とのダウンストリームの通知(つまり、インフラストラクチャから乗り物1へ)と一緒に、インフラストラクチャノード(すなわち、ES 3、CS 4)は、乗り物1に追加的な制御情報を提供するように構成されてもよい。この制御情報は、一方で、乗り物1が既知のイベントに関連する継続的にまたは追加的にキャプチャされた情報をどのように扱うべきか(つまり、そのような情報をインフラストラクチャにアップストリームで送信すべきか否か)、およびインフラストラクチャから乗り物1にダウンストリームで送信された配信された情報をどのように扱うべきかを決定する場合がある。

乗り物1におけるキャプチャされた情報の扱いに関連する制御情報に関して、インフラストラクチャサーバは、既知のイベント(つまり、乗り物1はそのevent_signatureデータベースにevent_signatureのエントリを既に持っている)に関連する追加的なデータをインフラストラクチャにアップストリームで送信し続けるように乗り物1に要求することができると規定されてもよい。このメカニズムは、インフラストラクチャがイベントおよび状況のより正確な説明を構築することを可能にする。たとえば、異なる角度から撮影された異なる乗り物1からの追加的なカメラ写真は、インフラストラクチャが状況の3Dまたは回転画像(rotating image)を生成することを可能にする。これに関連して、特定の乗り物1がイベントに関連する場所に接近するその方向に従ってその特定の乗り物1の観点からイベントが視覚化されると規定されてもよい。また、複数の乗り物1からの遅延因子の複数のサンプルは、インフラストラクチャがより正確な平均のもしくは更新された値を構築すること、または乗り物1がイベントに関連する場所に接近する方向の依存性の遅延因子を構築することを可能にする。そのような制御情報の要求は、インフラストラクチャノード(ES 3、CS 4)から乗り物1に送信されるメッセージCombined-Event-Information-Frame内の制御タグ"SEND_MORE"によって示されてもよい。

インフラストラクチャからの受信されたダウンストリームの情報の処理に関連する制御情報に関して、インフラストラクチャは、event_signatureを探し出し、その乗り物1のローカルのevent_signature_database内のエントリとマッチングするだけでなく、添付された属性/値を処理することを乗り物1に示すと規定されてもよい。これの理由は、たとえば、更新された情報、たとえば、より正確なイベントの状況の説明、説明された状況の変化などが含められることである場合がある。そのような制御情報は、インフラストラクチャノード(ES 3、CS 4)から乗り物1に送信されるメッセージCombined-Event-Information-Frame内の制御タグ"UPDATE"によって示されてもよい。

本明細書に記載の本発明の多くの修正およびその他の実施形態は、上述の説明および関連する図面に示された教示を利用することができる、本発明が関連する技術の熟練者の頭に浮かぶであろう。したがって、本発明は開示された特定の実施形態に限定されるべきでなく、修正およびその他の実施形態は添付の請求項の範囲に含まれるように意図されることを理解されたい。本明細書において特有の用語が使用されているが、それらの用語は包括的および説明的な意味でのみ使用されており、限定の目的で使用されていない。

1 乗り物
2 路側機(RSU)
3 エッジサーバ(ES)
4 コアサーバ
5 エッジクラウドデータセンター
6 コアデータセンター
7 イベント記録エンジン(ERE)
10 観測主体
701 画像/テキスト認識および処理アプリケーション
702 データフィルタリングおよび処理ユニット
703 分類機能
S combined_event_signature
S1 event_signature
S2 event_signature

Claims (15)

1. 好ましくは独立した乗り物(1)、モバイルデバイスなどである少なくとも1つの観測主体(10)からの情報を制御し、調整し、まとめるための道路インフラストラクチャによるリアルタイムの動的なイベントに関連する情報の導出および流布のための方法であって、
   前記道路インフラストラクチャの道路インフラストラクチャサーバによって1つまたは複数の観測主体(10)からイベント情報を受信するステップであって、前記観測主体(10)の各々が、前記観測主体(10)のイベント情報を、いくつかの属性を含むイベントデータレコードを前記イベントデータレコードを参照する一意識別子と一緒に含むイベント情報フレームとして提供する、ステップと、
   前記観測主体(10)から受信された前記イベント情報フレームを収集し、分析し、複合的イベント情報、前記複合的イベント情報を参照する一意識別子、および前記観測主体(10)との通信を調整するための制御コマンドを含む組み合わされたイベント情報フレームを生成するために前記イベント情報フレームを処理するステップと、
   前記組み合わされたイベント情報フレームを配信ドメイン内で配信するステップと
   を含む、方法。
2. 前記イベント情報フレームに含まれる前記一意識別子が、ハッシュアルゴリズムを適用することによるなどして前記イベントデータレコードの選択された属性から導出されたイベントシグネチャであり、および/または前記組み合わされたイベント情報フレームに含まれる前記一意識別子が、ハッシュアルゴリズムを適用することによるなどして前記複合的イベント情報から導出された組み合わされたイベントシグネチャである、請求項1に記載の方法。
3. 前記インフラストラクチャサーバから前記観測主体(10)に送信される前記組み合わされたイベント情報フレームが1つまたは複数の制御フラグを含み、前記制御フラグのうちの1つが、設定されるかまたはアクティブ化されているとき、イベントに関連する追加的なデータを送信するように受信する観測主体(10)に命令する、請求項1または2に記載の方法。
4. 前記インフラストラクチャサーバから前記観測主体(10)に送信される前記組み合わされたイベント情報フレームが1つまたは複数の制御フラグを含み、前記制御フラグのうちの1つが設定されるかまたはアクティブ化されているとき、前記観測主体(10)によってローカルで処理され、更新されることが可能であるイベントに関連する更新された情報を前記組み合わされたイベント情報フレームが含むことを受信する観測主体(10)に知らせる、請求項1から3のいずれか一項に記載の方法。
5. 前記インフラストラクチャサーバが、前記組み合わされたイベント情報フレームに含まれる1つまたは複数の属性に基づいて、適合された警告信号および/またはマップの更新を前記組み合わされたイベント情報フレームに組み込む、請求項1から4のいずれか一項に記載の方法。
6. 前記インフラストラクチャサーバが、前記イベントに関連する影響および/または遅延を示す属性に基づいてブロードキャストドメインのサイズを決定する、請求項1から5のいずれか一項に記載の方法。
7. 前記インフラストラクチャサーバが、路側機RSU(2)に、またはエッジサーバ(3)、特にマルチアクセスエッジコンピューティングMECサーバに、またはコアデータセンターに実装される請求項1から6のいずれか一項に記載の方法。
8. 車載器(OBU)を含む道路を走行する乗り物搭載システムであって、前記OBUが、
   計算能力および通信能力を提供し、
   乗り物(1)の搭載センサシステムからおよび/または前記乗り物(1)の運転者によって持ち運ばれるスマートデバイスからイベントに関連する生センサデータを受信し、
   受信された生センサデータを処理し、前記生センサデータから導出されたコンテキスト的なイベント説明情報の形態で属性を含むイベントデータレコードを生成し、
   前記イベントデータレコードの前記属性に基づいて、イベントシグネチャと呼ばれる一意識別子を生成し、
   少なくとも前記イベントシグネチャおよび前記イベントデータレコードの前記属性を含むイベント情報フレームを生成し、
   前記イベント情報フレームを道路インフラストラクチャサーバに送信する
   ように構成される、システム。
9. 前記OBUが、
   前記乗り物(1)の搭載センサシステムのカメラによって撮影された画像を処理し、
   前記カメラ画像内で特定された道路標識に書かれているオプションのテキスト情報を解読することによってコンテキスト的なイベントデータを生成する
   ように構成される画像/テキスト認識アプリケーション(701)を含むイベント記録エンジン(7)を含む、請求項8に記載のシステム。
10. 前記OBUが、トリガイベントを検出すると、データを取得し、前記データを処理のために前記OBUに提供するように前記乗り物(1)の搭載センサシステムに要求するように構成され、トリガイベントが、前記乗り物(1)の急なブレーキ操作、および/または前記乗り物(1)の速度が許される制限速度よりも下に構成可能な程度まで低下する状況を含む、請求項8または9に記載のシステム。
11. 前記OBUが、前記イベントデータレコードの前記属性から導出された前記イベントシグネチャが一意であることを保証するために生センサデータをT'回サンプリングし、処理するように構成されるイベント記録エンジン(7)を含み、T'が、構成可能な閾値である、請求項8から10のいずれか一項に記載のシステム。
12. 前記イベントデータレコードが、前記イベントの特定された種類を示すイベントタイプ属性、および/または前記イベントの特定された場所を示すイベントジオロケーション属性を含む、請求項8から11のいずれか一項に記載のシステム。
13. 前記乗り物(1)のOBUが、インフラストラクチャサーバから組み合わされたイベント情報フレームを受信し、前記組み合わされたイベントシグネチャを復号するように構成される、請求項8から12のいずれか一項に記載のシステム。
14. 前記乗り物(1)のOBUが、イベント特定プロセスをトリガすべきかどうかを判断するために復号された組み合わされたイベントシグネチャを使用するように構成される、請求項13に記載のシステム。
15. 前記乗り物(1)の搭載センサシステムが、1つもしくは複数のカメラ、GPSモジュール、モニタ、通信モジュール、レーダーモジュール、および/またはLIDARモジュールを含む、請求項8から14のいずれか一項に記載のシステム。

Images