JP5789268B2 - 経路選択システム、方法及びプログラム - Google Patents

Description

この発明は、交通路などの経路を選択するためのシステム、方法及びプログラムに関する。

従来より、カーナビは、道路上の経路を探索して表示する機能をもつ。その処理のアルゴリズムは例えば、交差点をノード、道路をエッジとみなし、道路の長さを重みとする重み付きグラフに最短経路探索を行うものである。

その際、カーナビを使って同時に経路探索する自動車は多数あり、各々の自動車が独立に最短経路を求めるので、複数の自動車の通行路の重なりを考えたとき、経路の特定のエッジの使用頻度が増加し、その部分で混雑が生じる。このとき、図１に示すように、各エッジにかかる時間は、交通量・通行量の増加に伴って急速に増加すると考えられる。

自動車の場合、ＶＩＣＳ（登録商標）(Vehicle Information and Communication System = 道路交通情報通信システム）等によって提供される渋滞情報を参照して、カーナビが迂回路を計算することができるが、多くの車両が同じ渋滞情報を参照すれば、結局、同様の迂回路を選ぶことになるので、図２に示すように、そちらでやはり渋滞が発生する。

そこで、中央のサーバで、車両の集中による混雑の発生にまで配慮して、図３に示すように、多対多のルーティングをし、混雑の緩和を達成したいという要望がある。すなわち、混雑を相互に回避できれば、所要時間を短くできる可能性がある。しかし、多対多のルーティングを行う計算処理は一般的に、ＮＰ困難であり、合理的な時間の範囲内で解を得ることが困難である。

特開２００１−３３１５６４号公報は、輸送計画中の各輸送手段のルート決定を、それぞれの計画に必要な精度や計算時間によって最も適した計算方法で行うことで効率的な計画作成を実現するために、少なくとも入出力装置と処理装置と記憶装置を有し配送計画作成を行うシステムにおいて、工場、中継拠点、サプライヤなどの拠点の位置情報を入力する拠点情報登録ステップと、各輸送便が立ち寄る拠点や扱う荷物量を含む輸送便情報を入力する輸送便情報登録ステップと、輸送計画の要求精度や制限時間を含む目的情報を入力する条件登録ステップと、ルート作成に用いるアルゴリズムを選択するアルゴリズム選択ステップと、これらの情報から輸送便が回るべきルートを作成するルート作成ステップと、作成結果を出力する出力ステップからなる方法を開示する。

特開２００４−１２３１２号公報は、再探索に要する時間を最初の探索よりも短くすることにより、全体の探索時間を短縮することを目的とするものであって、出発地から目的地までの経路のうち前記経路に付随するパラメータが最小となる第１の最少コスト経路を探索する第１の探索手段と、第１の最短経路を構成する各道路区間のパラメータに重み付けを行う重み付け手段と、第１の探索手段の計算データに基づいて特定の地図領域を制限領域として求める領域制限手段と、重み付けがなされた状態で出発地から目的地までの経路のうち前記経路に付随するパラメータが最小となる第２の最少コスト経路を、領域制限手段で求めた制限領域のみを経路探索の対象として探索する第２の探索手段とを備え、再探索時に前回探索の情報を利用して探索範囲を制限することにより、再探索に要する時間を低減する経路探索装置を開示する。

特開２００９−１９９３２号公報は、経路探索空間が広い場合であっても、高速で最適な経路を探索可能な経路探索システムを提供するために、移動領域を複数の領域に分割する領域分割部と、領域分割部により分割された複数の領域に対応し、それぞれの領域の評価値を算出する複数の評価値算出部と、評価値算出部によって算出された評価値に基づいて経路を決定する経路決定部とを備え、評価値算出部が、近傍に存在する領域の評価値と、当該近傍領域から自領域までの移動コストに基づいて評価値を算出することを開示する。また、その段落００７３には、「移動始点及び移動終点として指定する領域数が、多対一、一対多、多対多である場合においても本発明を応用することができる」と記載されている。

しかし、上記どの従来技術も、素朴に解くと計算量が膨大になってしまう多対多の経路探索処理を合理的な計算量で求める技法については開示するものではない。

特開２００１−３３１５６４号公報 特開２００４−１２３１２号公報 特開２００９−１９９３２号公報

従って、この発明の目的は、多対多の経路探索処理を合理的な計算量で求める技法を提供することにある。

この発明の他の目的は、複数の車両などの通行による混雑度を考慮した経路探索処理を合理的な計算量で求める技法を提供することにある。

この発明においては、交通路をグラフで記述し、各エッジの所要時間を、単調増加する区分線形の関数で近似することで、交通量・通行量の増加に伴う混雑の発生がモデル化される。このモデルは、図１に示す混雑度と所要時間の関係の曲線の近似になっている。

そこで、出発点と目的点を指示するカーナビなどからの情報をリクエストとすると、目的関数を、「全リクエストに亘る実際の所要時間を最短所要時間で割った値の最大値の最小化」とすることで、全ての車両を公平に扱うことができ、全体としても合理的にルーティングになる、というのが本発明の知見である。これは、整数値を取る変数と実数値を取る変数の両方を用いる混合整数計画問題（ＭＩＰ）として記述することができ、所定のソルバで解くことができる。

但し、ＭＩＰでの記述は、あらゆる経路を陽に列挙する必要があり、候補となる経路は、グラフのサイズに関して、一般に指数個存在するので、ＮＰ困難問題となって、現実的に解くことが困難である。

本発明の１つの特徴によれば、候補経路は指数個存在するが、初期状態から、見込みのある経路を徐々に追加して反復してＭＩＰを解くことで、候補経路数の爆発が抑えられる。

本発明の別の特徴によれば、ある反復終了時点での実際の経路を使って新たな経路を探索することで、迂回路として利用価値の高い経路を優先して探索することができる。このとき、本発明の１つの側面によれば、最小コストがその時点で最良解以上の経路と、前反復で追加されたが使われなかった経路が、見込みのない経路として取り除かれる。

本発明のさらに別の特徴によれば、ＭＩＰの計算の結果、出発地から目的地への複数の経路とその利用割合が得られ、その結果を用いて、混雑を緩和するような最適なルーティングが可能となる。

本発明の更に別の特徴によれば、経路候補の更新の際には、前反復で使用された経路は必ず残すようにすることで、ＭＩＰにおいて前反復の解を初期値として利用することが可能となり、計算時間を大幅に短縮することが可能となる。

この発明によれば、混合整数計画問題を用いつつ、見込みのない経路は取り除き、前反復で使用された経路は必ず残すようにして有望な値から反復計算を開始することで、合理的な計算量で多対多の経路を計算することができる。

さらに、この発明によれば、各エッジの所要時間を、単調増加する区分線形の関数で近似することで、妥当な計算量で、混雑を緩和する望ましいルーティングが得られる。

交通量と所要時間の関係を示す図である。 渋滞情報に従い、車両が回避する経路をとる様子を示す図である。 車両が、適切に案内された経路をとる様子を示す図である。 本発明を実施するためのハードウェア構成の一例のブロック図である。 本発明を実施するための機能構成の一例のブロック図である。 単調増加する区分線形の関数で近似する様子を示す図である。 本発明に従い経路選択する処理のフローチャートを示す図である。 本発明に従い経路選択する処理のフローチャートを示す図である。 本発明の処理の出力の例を示す図である。

以下、図面に基づき、この発明の実施例を説明する。特に断わらない限り、同一の参照番号は、図面を通して、同一の対象を指すものとする。尚、以下で説明するのは、本発明の一実施形態であり、この発明を、この実施例で説明する内容に限定する意図はないことを理解されたい。

図４を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータ・ハードウェアのブロック図が示されている。図１において、システム・パス４０２には、ＣＰＵ４０４と、主記憶（ＲＡＭ）４０６と、ハードディスク・ドライブ（ＨＤＤ）４０８と、キーボード４１０と、マウス４１２と、ディスプレイ４１４が接続されている。ＣＰＵ４０４は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＰｅｎｔｉｕｍ（商標） ４、Ｃｏｒｅ（商標）２ Ｄｕｏ、Ｘｅｏｎ（商標）、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。主記憶４０６は、好適には、４ＧＢ以上の容量をもつものである。ハードディスク・ドライブ４０８は、大量の交通路グラフ・データを格納できるように、例えば、５００ＧＢ以上の容量をもつものであることが望ましい。

このようなハードウェア構成の好適な例の１つとして、ＩＢＭ(R) Ｓｙｓｔｅｍ Ｘシリーズがあるが、これには限定されず、通常のパーソナル・コンピュータでも、本発明を実施可能である。

ハードディスク・ドライブ４０８には、個々に図示しないが、オペレーティング・システムが、予め格納されている。オペレーティング・システムは、Ｌｉｎｕｘ（商標）、マイクロソフト社のＷｉｎｄｏｗｓ ＸＰ（商標）、Ｗｉｎｄｏｗｓ（商標）２０００、Ｗｉｎｄｏｗｓ（商標）２００８サーバ、アップルコンピュータのＭａｃ ＯＳ（商標）などの、ＣＰＵ４０４に適合する任意のものでよい。

ハードディスク・ドライブ４０８にはさらに、後述する、処理のメイン・ルーチン５０２、交通路グラフ・データ５０４、リクエスト・データ５０６、ソルバ５０８、経路探索モジュール５１０、及び経路更新モジュール５１２が格納されている。

メイン・ルーチン５０２、ソルバ５０８、経路探索モジュール５１０、及び経路更新モジュール５１２は、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（商標）などの既存のプログラミング言語処理系で作成され、システムの起動時、あるいは、必要に応じてオペレーティング・システムの働きで、メモリ４０６にロードされて実行される。

ディスプレイ４１４は、好適には、液晶ディスプレイであり、例えば、ＸＧＡ（４０２４×７６８の解像度）、またはＵＸＧＡ（１６００×１２００の解像度）などの任意の解像度のものを使用することができる。ディスプレイ４１４は、図示しないが、本発明の処理プログラムを起動したり、停止したりするための操作画面を表示したり、交通路データや、交通路上の経路を表示したりするために使用される。

次に、図５の機能ブロック図を参照して、本発明を実施するための論理的機能構成について説明する。図５において、メイン・ルーチン５０２は、全体の処理を統括するプログラムであり、操作画面（図示しない）をディスプレイ４１４に表示し、ユーザのキーボード４１０やマウス４１２の操作に応じて、処理を開始したり、停止したりする機能を有する。

交通路グラフ・データ５０４は、交差点をノード、道路をエッジとするように交通路をグラフで記述し、各エッジの所要時間を、単調増加する区分線形の関数で近似することで、交通量・通行量の増加に伴う混雑の発生をモデル化した重み付きグラフ・データである。グラフをコンピュータ可読且つ、ハードディスクなどの媒体に保存可能な形式に表現するには、典型的には行列表現と、リスト表現があるが、この発明の目的のためには、どちらの形式でもよい。

図６に、エッジの所要時間の区分線形性を示す。ここでxは、１時間あたりの車の通過台数のような交通量である。これは、図１に示すグラフの区分線形近似になっている。図示されているように、0<=x<x₁の場合は所要時間t=a₁x+b₁、x₁<=x<x₂の場合は所要時間t=a₂x+b₂、x₂<=xの場合は所要時間t=a₃x+b₃ような区分線形の関数が使用される。但し、a_i > 0 (i = 1,2,3)である。ここでは３つだけの区間が図示されているが、これは一実施例に過ぎず、必要に応じて、任意の数と幅の区間をとることができる。このような区分線形の関数は、これには限定されないが、例えば、各エッジから指し示される、メモリ上のテーブルを参照する線形関数として実装することができる。すなわち、<=x₁という交通量の値に対応して、{a₁,b₁}を返し、x₁<=x<x₂という交通量の値に対応して、{a₂,b₂}を返す等のように、テーブルが用意される。

エッジ毎の区分線形近似を行うための{a₁,b₁}、{a₂,b₂}・・・のような係数群は、実際の道路の状態に従い決定する。すなわち、好適にはエッジの実際の長さに比例して、{a_i,b_i} (i = 1,2,3,...)という係数は決定されるが、上り坂の坂道では{a_i,b_i}はより大きく設定され、下り坂の坂道では{a_i,b_i}はより小さく設定される。カーブの曲率の大きい道路では{a_i,b_i}はより大きく設定される。車線の多い道路では{a_i,b_i}はより小さく設定され、幅が狭い道路では、{a_i,b_i}はより大きく設定される。舗装状態がよい道路では{a_i,b_i}はより小さく設定され、舗装状態がよくない道路では、{a_i,b_i}はより大きく設定される。

好適な実施例では、各エッジにおいて、所要時間t = max_i{a_ix + b_i} ここで、a_i > 0と計算される。

リクエスト・データ５０６は、{出発地、目的地、需要量}の集合として与えられる。このようなリクエスト・データは例えば、プローブカーデータを利用することにより、収集することができる。プローブカーデータを利用した交通データ収集技法は公知であり、例えば、特開２００４−１１０４５８号公報、特開２００４−１５６９８２号公報、特開２００７−１９３７０５号公報、特開２００４−２４１９８７号公報などを参照されたい。これらの技法によれば、所定の期間に、{出発地、目的地}の対毎に、その間を走った車両の台数が分かるので、その台数を需要量とし、{出発地、目的地、需要量}を需要量で降順ソートし、上位から所定の数の組をハードディスク・ドライブ４０８に保存するなどして、リクエスト・データ５０６を用意することができる。

ソルバ５０８は、全リクエストに亘る、実際の所要時間／最短所要時間の最大値の最小化を目的関数とする、混合整数計画問題（ＭＩＰ）として定式化された式を解くことにより、各リクエストに対して、複数のルートとその使用割合（実数）を出力として与える。好適なソルバは、これには限定されないが、ＩＢＭ(R) ＩＬＯＧ ＣＰＬＥＸである。このＭＩＰの定式化については、後でより詳細に説明する。

経路探索モジュール５１０は、ダイクストラ法、Ａ^＊法など従来周知のアルゴリズムにより、重み付きグラフの経路探索を行う。あるいは、Ａ^＊法の改良版である、本出願に係る特開２００８−１５７６９８号公報に記述されているアルゴリズムを使ってもよい。

経路更新モジュール５１２は、計算量を減らすために適宜経路を除去し、あるいは有利な経路を追加する処理を行う。経路更新モジュール５１２が実行する処理については、図８のフローチャートを参照して、後で詳細に説明する。

次に、図７及び図８のフローチャートを参照して、本発明の経路選択処理について説明する。

図７では、メイン・ルーチン５０２は、ステップ７０２で、経路探索モジュール５１０を呼び出して、最小コスト経路、すなわち、各エッジで、所要時間t = max_i{a_ix + b_i} の式でx = 0と置いた場合の、リクエスト・データ５０６における{出発地、目的地}の対における、出発地から目的地までの最短経路を探索する。

ステップ７０４では、メイン・ルーチン５０２は、ソルバ５０８を呼び出して、その時点での候補経路の下で、混合整数計画問題（ＭＩＰ）を解く。なお、ステップ７０４、ステップ７０６及びステップ７０８からなるループで、２回目以降は、前回の解を初期値とすることで、計算時間の短縮が可能である。

次に、ＭＩＰの定式化について説明する。この定式化は、全リクエストに亘る、実際の所要時間／最短所要時間の最大値の最小化を目的関数とすることを意図している。交通路グラフ・データ５０４のノードの集合をＶ、エッジの集合をＥとすると、グラフＧ = (Ｖ,Ｅ)であらわされる。そこで、図６の区分線形近似を参照すると、エッジe ∈ Ｅの移動にかかる所要時間は、交通量をxであらわしたとき、次の式であらわされる。
t_e(x) = max_i(a_eix + b_ei) ただし、a_ei > 0

一方、リクエストi (i = 1,...,k)は、以下の属性をもつ。
出発地点のノード: s_i ∈ Ｖ
目的地点のノード: g_i ∈ Ｖ
需要量: d_i ∈ Ｒ, d_i > 0

また、ノードs_iからノードg_iへのサイクルを含まない全ての経路の集合をＰ_i ^*とする。すると、p ∈ Ｐ_i ^*は、以下のように、連結する辺の順列として表される。
p = (e₁.e₂....,e_|p|)
ここで、|p|は、pをつなぐ辺の数である。

そこで、交通量xが0の場合の、ノードs_iからノードg_iへの最小所要時間をＴ_i ^*とする。すなわちＴ_i ^*は、次式であらわされる。

このとき、Ｔ_i ^*は、Ｐ_i ^*の全要素を陽に列挙しないでも、各辺e ∈ Ｅのコストをt_e(0)とし、例えば、経路探索モジュール５１０を呼び出して、最短経路探索アルゴリズムなどを実行することで求めることができる。

また、リクエストiの候補経路集合Ｐ_i ^*の要素に適当に順番を付け、Ｐ_i ^*のj番目(j = 1,...,|Ｐ_i ^*|)の経路をp_ijであらわすことにする。また、Lを十分大きな正の定数とし、y_ijを、リクエストiの候補経路jを使用するかどうかをあらわす、0-1の整数変数である。以上の定義を用いて、混合整数計画問題は、以下のように定式化される。

ここで、s.t. (such that)以下が、制約式をあらわしている。

この混合整数計画問題を解いた結果得られるx_ijは、リクエストiにおけるj番目の経路の交通量をあらわす。すなわち、x_ij/d_iが、リクエストiにおけるj番目の経路の使用割合となる。この使用割合は、例えば、図９で、出発地１から、目的地１への複数の経路それぞれに関連付けられたパーセンテージとして示すものである。

次にステップ７０６では、メイン・ルーチン５０２は、終了条件を満足したかどうかを判断する。ここで終了条件とは例えば、計算時間が事前に設定した時間を超えた、あるいは、反復回数が、所定回数を超えた、などである。

メイン・ルーチン５０２は、終了条件を満足したと判断すると、処理を終了する。その時点で、リクエスト毎の出発地から目的地への複数の経路と、その経路毎の使用割合が得られる。

メイン・ルーチン５０２が、ステップ７０６で、終了条件を満足していないと判断すると、処理は、ステップ７０８に進み、そこで、メイン・ルーチン５０２は、経路更新モジュール５１２を呼び出して、候補経路の更新処理を行う。候補経路の更新処理とは、使われなかった経路や有望でない経路を削除し、有望とみなされる経路を追加する処理であり、図８のフローチャートを参照して、後で詳細に説明する。

ステップ７０８で候補経路が更新された後、ステップ７０４では、その更新された候補経路に基づき、ソルバ５０８によって、再びＭＩＰが解かれることになる。

次に、図８のフローチャートを参照して、経路更新モジュール５１２の処理を説明する。すなわち、ステップ８０２で、経路更新モジュール５１２は、各リクエストについて、以下のような経路を、見込みがない経路として取り除く。
・最小コストが、その時点で、最良解以上の経路。ここで最小コストとは、交通量x = 0とした場合のコストである。
・前反復で追加されたが、使われなかった経路。ここで、使われなかった経路というのは、ステップ７０４におけるソルバ５０８での計算結果における、変数y_ijの値が0であることによって判別される。
このように経路を取り除く処理によって、候補経路数の爆発を抑えることができる。

ステップ８０４では、経路更新モジュール５１２は、“実際の所要時間/最短所要時間”が最大で、かつ全ての候補経路の実際の所要時間が同じリクエストをbottleneckRequestとし、それらの候補経路集合に含まれるエッジをbottleneckEdgeとする。すなわち、経路更新モジュール５１２は、各反復の結果から、ボトルネックとなっているリクエスト、及びbottleneckEdgeの集合を特定する。すなわち、目的関数値を決定しているリクエストをbottleneckRequestと定義し、そのリクエストの候補経路に含まれるエッジをbottleneckEdgeと定義している。

ステップ８０６では、経路更新モジュール５１２は、各bottleneckRequestについて、以下の条件を満たす、コストが現状の最良解未満の経路を探索する。
・現状のコストを使い、bottleneckEdgeを使わない経路を探索する。
・見つからなければ、現状のコストを使い、bottleneckEdgeを使う経路も含めて探索する。
こうして見つかった経路は、新たに追加される。すなわち、追加すると目的関数値が下がる経路、あるいは、下がる可能性が高い経路を効率的に追加することが可能となる。

ステップ８０８では、経路更新モジュール５１２は、ステップ８０６で、候補経路が見つかったかどうかを判断する。もし見つかったのなら、図８で示すサブルーチンを抜けて、図７のステップ７０４に戻る。

ステップ８０８で、経路更新モジュール５１２が、候補経路が見つからなかったと判断すると、ステップ８１０で、経路更新モジュール５１２は、各非bottleneckRequestについて、その時点の解を悪くせずにフロー、すなわち交通量を増加させることができる経路がない場合、以下の条件の経路を探索する。
・現状のコストを使い、bottleneckEdgeを使わない経路を探索する。
・見つからなければ、bottleneckEdgeを使う経路も含めて探索する。
こうして見つかった経路は、新たに追加される。その後、図８で示すサブルーチンを抜けて、図７のステップ７０４に戻る。

ステップ８１０のような処理を行うのは、ボトルネックとなっていないリクエストについても、候補経路を追加することで目的関数値が向上することもあるからである。このとき、以下の条件を満たす候補経路を持つリクエストについては、いかなる経路を追加しても目的関数値の向上は図れないことが分かる。
・その候補経路のいかなるエッジもbottleneckEdgeではなく、かつ、その経路自体が現在の目的関数値を決定している経路ではない。

なお、この条件は、エッジのコスト関数として狭義に単調増加するコスト関数を使うことが前提となっている。すなわち、所要時間の関数の"ax + b"に関して、"a >= 0" ではなく "a > 0" としてある。

図７のフローチャートに戻って、ステップ７０４でのＭＩＰの計算の後、ステップ７０６で終了条件を満足したと判定されると、各リクエスト毎の複数の経路と、その個々の経路の使用割合が返される。

こうして得られた多対多の出発地と目的地の間の望ましい経路と、望ましい経路の使用割合が得られると、車両の交通路においては、通勤時間帯などの恒常的・定常的な渋滞の緩和、恒常的に渋滞が発生する施設周辺のルーティング、などの応用が考えられる。

また、群集の誘導として、イベント会場などでの効率のよい群衆の誘導経路の立案、ビル火災時などにおける効率的な避難経路の立案などの応用もありえる。

なお、特定の実施例に従い本発明を説明してきたが、例示されているハードウェア構成は一例であって、マルチプロセッサ環境、ネットワーク接続のクラウドコンピューティング環境など、任意のハードウェア環境で使用可能である。

４０２ システム・パス
４０４ ＣＰＵ
４０６ メモリ
４０６ 主記憶
４０８ ハードディスク・ドライブ
４１０ キーボード
４１２ マウス
４１４ ディスプレイ
５０２ メイン・ルーチン
５０４ 交通路グラフ・データ
５０６ リクエスト・データ
５０８ ソルバ
５１０ 経路探索モジュール
５１２ 経路更新モジュール

Claims (11)

1. コンピュータの処理により、経路を選択する方法であって、
   記憶手段に、経路をエッジであらわし、経路の交点をノードであらわすグラフを用意するステップであって、各経路は、該経路を通過する所要時間を、交通量に応じて単調増加する区分線形の関数で近似されているステップと、
   経路探索手段が、出発点と目的点の組である複数のリクエストに対して、前記記憶手段から前記グラフを読み出し、前記グラフ上で最短経路を探索して、得られた経路を、処理対象の経路の集合とするステップと、
   ソルバ手段が、前記複数の出発点と目的点の組に対して、各々の出発点から目的点までの所要時間を最短所要時間で割った値の最大値の最小化という目的関数を解くステップと、
   交通量を０として得られる経路の最小の所要時間を第１所要時間とし、前記目的関数を解いて得られた交通量を用いて算出される経路の所要時間を第２所要時間とした場合に、経路更新手段が、終了条件を満足していないことを条件に前記目的関数を解くステップを繰り返すステップ間に、各リクエストについて、前記第１所要時間が前記第２所要時間以上の経路と、現在より前の繰り返すステップで追加され前記目的関数を解く際に検討されたが前記最大値を最小化する経路として使われなかった経路とを、見込みのない経路として前記処理対象の経路の集合から取り除くとともに、新たな経路を前記処理対象の経路の集合に追加するステップを有する、
   経路選択方法。
2. 「実際の所要時間/最短所要時間」が最大で、かつそのリクエストについての全ての候補経路の実際の所要時間が同じ前記リクエストをbottleneckRequestとし、それらの候補経路集合に含まれるエッジをbottleneckEdgeとし、ここで前記実際の所要時間とは、その時点での前記目的関数を解いて得られた交通量を用いて算出される所要時間であり、前記経路更新手段が、前記目的関数を解くステップを繰り返す間に、前記実際の所要時間を使い、前記bottleneckEdgeを使わない経路を探索して、前記処理対象の経路の集合に追加するステップを有する、請求項１に記載の経路選択方法。
3. 前記実際の所要時間を使い、前記bottleneckEdgeを使わない経路を探索するステップが経路をみつけられないことに応答して、前記ソルバ手段が、前記bottleneckEdgeを使う経路も含めて探索するステップを更に有する、請求項２に記載の経路選択方法。
4. 前記bottleneckEdgeを使う経路も含めて探索するステップが経路をみつけられないことに応答して、各非bottleneckRequestについて、その時点の解を悪くせずに交通量を増加させることができる経路がない場合、前記ソルバ手段が、前記実際の所要時間を使い、前記bottleneckEdgeを使わない経路を探索するステップをさらに有する、請求項３に記載の経路選択方法。
5. 前記実際の所要時間を使い、前記bottleneckEdgeを使わない経路を探索するステップが経路をみつけられないことに応答して、前記ソルバ手段が、前記bottleneckEdgeを使う経路も含めて探索するステップを有する、請求項４に記載の経路選択方法。
6. 前記リクエストが、出発点と目的点と需要量の組であり、前記ソルバ手段が、該出発点から該目的点に至る複数の経路の、該需要量における使用割合を出力する、請求項１乃至５いずれか１項に記載の経路選択方法。
7. 請求項１乃至３、及び６のいずれか1項に記載の経路選択方法の全ステップをコンピュータに実行させるための経路を選択するプログラム。
8. コンピュータの処理により、経路を選択するシステムであって、
   記憶手段と、
   前記記憶手段に記憶され、経路をエッジであらわし、経路の交点をノードであらわすグラフであって、各経路は、該経路を通過する所要時間を、交通量に応じて単調増加する区分線形の関数で近似されているグラフと、
   出発点と目的点の組である複数のリクエストに対して、前記グラフ上で最短経路を探索して、得られた経路を、処理対象の経路の集合とする手段と、
   前記複数の出発点と目的点の組に対して、各々の出発点から目的点までの所要時間を最短所要時間で割った値の最大値の最小化という目的関数を解くソルバと、
   交通量を０として得られる経路の最小の所要時間を第１所要時間とし、前記目的関数を解いて得られた交通量を用いて算出される経路の所要時間を第２所要時間とした場合に、前記ソルバが、終了条件を満足していないことを条件に前記目的関数を解く処理を繰り返す間に、各リクエストについて、前記第１所要時間が前記第２所要時間以上の経路と、現在より前の繰り返すステップで追加され前記目的関数を解く際に検討されたが前記最大値を最小化する経路として使われなかった経路とを、見込みのない経路として前記処理対象の経路の集合から取り除くとともに、新たな経路を前記処理対象の経路の集合に追加する手段とを有する、
   経路選択システム。
9. 「実際の所要時間/最短所要時間」が最大で、かつそのリクエストについての全ての候補経路の実際の所要時間が同じ前記リクエストをbottleneckRequestとし、それらの候補経路集合に含まれるエッジをbottleneckEdgeとし、ここで前記実際の所要時間とは、その時点での前記目的関数を解いて得られた交通量を用いて算出される所要時間であり、前記目的関数を解くステップを繰り返す間に、前記実際の所要時間を使い、前記bottleneckEdgeを使わない経路を探索し、前記処理対象の経路の集合に追加する手段を更に有する、請求項８に記載の経路選択システム。
10. 前記実際の所要時間を使い、前記bottleneckEdgeを使わない経路を探索する手段が、経路をみつけられないことに応答して、前記bottleneckEdgeを使う経路も含めて探索する、請求項９に記載の経路選択システム。
11. 前記リクエストが、出発点と目的点と需要量の組であり、前記ソルバが、該出発点から該目的点に至る複数の経路の、該需要量における使用割合を出力する、請求項１０記載の経路選択システム。

Images