JP2021508385A - 車両軌跡データを使用する適応交通制御 - 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. 少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、
    センサによって取得された車両軌跡データ及び交通信号コントローラからの交通制御データを受信することと、
    異常な交通状態を検出することと、
    複数の位相の青色スプリットを調整することにより、前記車両軌跡データに基づいてオンライン交通制御スキームを最適化することと、
    交通制御信号を生成する交通信号コントローラに、前記最適化オンライン交通制御スキームをリアルタイムに提供することとを含む交通制御方法を実行させる命令を記憶する非一時的なコンピュータ可読媒体。