WO2019093255A1 - リソース調停システムおよびリソース調停装置 - Google Patents

Abstract

リソースの利用条件と提供条件との双方を満たしつつ、リソースの需要と供給を制御する。 リソース調停サーバ１は、鉄道車両事故Ｐ３の被害規模に基づいて、鉄道車両事故Ｐ３がない場合の到着時刻、事故復旧後の到着時刻および臨時バスを利用した場合の到着時刻を予測し、乗客に配信するとともに、臨時バスの運行計画をバス会社に配信し、到着時刻の予測情報に基づき、乗客とバス会社に臨時バス利用の条件を提示し、乗客とバス会社の間で臨時バスの台数や料金を調停する。

Description

リソース調停システムおよびリソース調停装置

　本発明は、リソースの需要と供給を制御することが可能なリソース調停システムおよびリソース調停装置に関する。

　近年、大量生産型経済モデルが限界に達し、リソースを再利用する循環型経済の台頭に伴って、サービス化のビジネスがクローズアップされている。その中でも、社会交通インフラのサービス化では、製品として販売していた交通移動手段（自動車等）を共同利用することや、モノを代替化することが行われている。

　特許文献１では、タイムテーブルに従って運行行路を運行するバスが所定の時刻にチェックポイントに到達していないと判定した場合、臨時乗り物を出動させる技術が開示されている。

　特許文献２では、過去の移動経路の記憶情報を参照し、移動計画を立案した後、車両の提供者の端末に相乗りの受け入れ依頼を送信することによって、タクシーの相乗り運行計画を立案する技術が開示されている。

　特許文献３では、車両の仮想オブジェクトを使ったコンピュータシミュレーションによって、交通状況を再現して評価する技術が開示されている。

特開２００６―１６３７３８号公報 特開２０１５―１９１３６４号公報 特開２０１３―０８０２７２号公報

　しかしながら、特許文献１に開示された技術では、予定の時刻にバスが来なかった場合に、臨時バスを代替とすることはできるが、鉄道車両停止事故などの発生時に、移動できなくなる乗客が鉄道車両停止事故発生地点から地理上平面で拡大するような状況には対応できなかった。

　特許文献２に開示された技術では、相乗りによるタクシーと乗客の利用効率を高めることができるが、鉄道車両停止事故などの発生時に数百人から数千人のオーダで発生する代替移動手段を、鉄道車両停止事故復旧時までに確保することは困難であった。

　すなわち、個々のタクシーと乗客が、タクシーの利用と提供を独自かつ個別に行えば、膨大なパターンの調停が発生する。このようなケースでは、鉄道車両停止事故の復旧を待った方が早く、または、安く済むという本末転倒な事態が発生する可能性が高い。さらに、タクシーの利用者には、到着予測時間が分からないため、乗客がタクシーの利用を躊躇する可能性が高い。

　また、特許文献３の発明は、コンピュータシミュレーションによる交通状況の再現を行うことはできるが、鉄道車両停止事故などの発生時に、より多くの人員をより短い時間で目的地に到達させる臨時バスの運行計画を立案することはできなかった。

　本発明は、上記事情に鑑みなされたものであり、その目的は、リソースの利用条件と提供条件との双方を満たしつつ、リソースの需要と供給を制御することが可能なリソース調停システムおよびリソース調停装置を提供することにある。

　上記目的を達成するため、第１の観点に係るリソース調停システムは、第１リソースの需給状態に基づいて第２リソースの提供条件と利用条件を設定し、前記提供条件と前記利用条件に基づいて前記第２リソースの需要と供給の調停を行う第１サーバと、前記第１サーバから送られた前記第２リソースの提供条件を評価する第２サーバと、前記第１サーバから送られた前記第２リソースの利用条件を評価する情報端末とを備える。

　本発明によれば、リソースの提供条件と利用条件との双方を満たしつつ、リソースの需要と供給を制御することができる。

図１は、第一の実施形態に係るリソース調停システムで想定される鉄道路線上での事故発生時の臨時バス運行路線の一例を示す図である。 図２は、第一の実施形態に係るリソース調停システムの構成を示すブロック図である。 図３は、第一の実施形態に係るリソース調停システムに用いられるサーバのハードウェア構成を示すブロック図である。 図４は、図２のリソース調停サーバの構成を示すブロック図である。 図５は、図４のリソース調停サーバの処理の流れを示すブロック図である。 図６は、図４の仮想乗客オブジェクト１３―６の目的地到着時刻を説明する図である。 図７は、図４の鉄道運行サーバ２、バス運行サーバ３および情報端末４の構成を示すブロック図である。 図８は、図２のリソース調停システムのメッセージ通信処理を示すブロック図である。 図９は、図４のリソース調停サーバの動作の流れを示す図である。 図１０は、図４の新交通生成計画ソルバ１３―３の処理の流れを示すブロック図である。 図１１は、第一の実施形態に係るリソース調停システムで用いられる品種の一例を示す図である。 図１２（ａ）から（ｄ）は、図４の仮想乗客オブジェクト１３―６が利用する臨時バスの料金を決めるのに用いられるファジィルールテーブルとメンバーシップ関数の一例を示す図である。 図１３（ａ）および（ｂ）は、図４の調停係数補正部１３－３で用いられる補正係数用テーブルを示す図である。 図１４は、補正係数用テーブルに基づいて変更されたファジィルールテーブルを示す図である。 図１５は、図２のリソース調停システムに適用される鉄道運行時の環境条件を示す図である。 図１６は、鉄道車両停止事故発生中に移動中の鉄道車両の乗客数の変化を示すグラフ図である。 図１７は、図１の駅Ｅおよび駅Ｆに滞留している乗客数を示すグラフ図である。 図１８は、図２のリソース調停システムによって提案された臨時バスの運行計画案を示す図である。 図１９は、図２のリソース調停システムによって提案された現実の臨時バスによって短縮される時間を示す図である。 図２０は、図２のリソース調停システムよって提案された運行計画案の適用の有無による駅Ｆの滞留人員の変化を示す図である。 図２１（ａ）および（ｂ）は、図２のリソース調停システムによる仮想調停によって妥結した料金を示す図である。 図２２は、図４の情報端末４の表示画面の一例を示す図である。 図２３は、図４のバス運行サーバ３の表示画面の一例を示す図である。 図２４は、第二の実施形態に係る鉄道路線上での事故発生時の臨時バス運行路線の一例を示す図である。 図２５は、図２４の駅の駅情報を示す図である。 図２６は、第二の実施形態に係るリソース調停サーバの仮想調停結果作成時の処理の流れを示すブロック図である。 図２７は、図２６のデータベースに格納されている、鉄道車両停止事故を発生させた時に生成したデータの一例を示す図である。 図２８は、第二の実施形態に係るリソース調停サーバの現実調停までの流れを示すブロック図である。 図２９は、第二の実施形態に係る仮想調停における過去の鉄道車両事故の発生地点と、今回の鉄道車両事故を発生地点との関係の一例を示す図である。 図３０は、第二の実施形態に係るリソース調停サーバの現実調停に用いられる仮想調停結果の算出方法の一例を示す図である。 図３１（ａ）は、ラッシュ時における心理的仮想距離の算出方法を示すフローチャート、図３１（ｂ）は、電車遅延時における遅延的仮想距離の算出方法を示すフローチャートである。

　実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また、実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

　以下の第一の実施形態では、第１リソースとして鉄道、第２リソースとしてバスを例にとって説明するが、第１リソースおよび第２リソースは、第２リソースが第１リソースの代替として使用できれば、鉄道およびバスに限定されない。例えば、リソースとして交通インフラ以外にも、電力や通信などの社会インフラであってもよい。

　図１は、第一の実施形態に係るリソース調停システムで想定される鉄道路線上での事故発生時の臨時バス運行路線の一例を示す図である。
　図１において、鉄道路線Ｐ１上には駅Ａ～Ｉが設けられている。なお、図１では、鉄道路線Ｐ１上に９個の駅Ａ～Ｉが設けられている例を示したが、鉄道路線Ｐ１上に２以上の駅があればよい。また、鉄道路線Ｐ１は分岐していてもよい。

　ここで、例えば、駅Ｅ、Ｆ間で鉄道車両事故Ｐ３が発生した場合、鉄道路線Ｐ１の駅Ａ～Ｉ間には臨時バス運行路線Ｐ２を設定することができる。なお、鉄道車両事故Ｐ３は、停電事故、信号機トラブル、ポイント故障、人身事故または踏切事故などであってもよい。あるいは、大雨、積雪または強風などによって鉄道車両が停止する場合であってもよい。

　鉄道車両事故Ｐ３が発生すると、駅Ｅ、Ｆ間を運行している鉄道車両だけでなく、それより前の区間を運行している鉄道車両も止まる。場合によっては、鉄道路線Ｐ１上の全線で鉄道車両が止まることもある。このため、駅Ｅ、Ｆ間を跨ぐように臨時バス運行路線Ｐ２を設定するとともに、駅Ｅ、Ｆ間を跨がないような臨時バス運行路線Ｐ２も設定することができる。

　また、図１では、鉄道車両事故Ｐ３が発生した鉄道路線Ｐ１の駅Ａ～Ｉ間で臨時バス運行路線Ｐ２を設定する方法について示したが、鉄道路線Ｐ１から他の鉄道路線へ乗り換える場合にも鉄道車両事故Ｐ３による遅延の影響が及ぶことがある。このため、鉄道車両事故Ｐ３が発生した鉄道路線Ｐ１以外の鉄道路線の駅が臨時バス運行路線Ｐ２に含まれていてもよい。

　以下、臨時バス運行路線Ｐ２の設定方法の概略を説明する。
　鉄道車両事故Ｐ３が発生すると、その被害規模を予測する。そして、その被害規模に基づいて、鉄道車両事故Ｐ３がない場合の到着時刻ｔ１、鉄道車両事故Ｐ３の復旧後の到着時刻ｔ２および鉄道車両事故Ｐ３の復旧前に臨時バスを利用した場合の到着時刻ｔ３を予測し、乗客に配信するとともに、臨時バスの運行計画をバス会社に配信する。

　次に、到着時刻ｔ１、ｔ２、ｔ３の予測情報に基づき、乗客に臨時バスの利用条件を提示するとともに、バス会社に臨時バスの提供条件を提示し、乗客とバス会社の間で臨時バスの台数や料金を調停する。

　次に、臨時バスの台数や料金の調停が完了したら、実際に臨時バスの運用を開始する。

　リソース調停システムで想定される環境条件の一例を以下に示す。
鉄道路線距離：約３０ｋｍ
利用者総数　：約５万人／日
運行時間　：  約１８時間／日
利用可能な臨時バス台数：各駅に１０台

　このリソース調停システムでは、臨時バスの利用条件と提供条件に基づいて、乗客とバス会社間で調停を行わせることができる。これにより、なるべく多くの人員をなるべく短い時間で目的地に到達させる合理的な臨時バスの運行計画を、鉄道車両事故Ｐ３が復旧するまでの短時間に立案することができる。

　図２は、第一の実施形態に係るリソース調停システムの構成を示すブロック図である。
　図２において、リソース調停システムには、リソース調停サーバ１、鉄道運行サーバ２、バス運行サーバ３および情報端末４が設けられている。情報端末４は、鉄道またはバスを利用する乗客が使うモバイル端末を用いることができる。リソース調停サーバ１は、鉄道運行サーバ２、バス運行サーバ３および情報端末４とネットワーク５で接続されている。ネットワーク５の接続の態様は、無線有線等、特に限定はない。

　リソース調停サーバ１は、鉄道車両事故Ｐ３の被害規模に基づいて、鉄道車両事故Ｐ３がない場合の到着時刻ｔ１、鉄道車両事故Ｐ３の復旧後の到着時刻ｔ２および鉄道車両事故Ｐ３の復旧前に臨時バスを利用した場合の到着時刻ｔ３を予測し、情報端末４に配信したり、臨時バスの運行計画をバス運行サーバ３に配信したりすることができる。そして、到着時刻ｔ１、ｔ２、ｔ３の予測情報に基づいて、情報端末４に臨時バスの利用条件を提示するとともに、バス運行サーバ３に臨時バスの提供条件を提示し、乗客とバス会社の間で臨時バスの台数や料金を調停することができる。

　鉄道運行サーバ２は、当日の鉄道運行ダイヤを管理したり、鉄道車両停止事故情報や鉄道車両停止事故の復旧予想時間を送信したりすることができる。

　バス運行サーバ３は、臨時バスとして利用可能なバスの台数と場所などの情報を送信することができる。また、バス運行サーバ３は、臨時バスの運行計画を受信したり、その運行計画の受け入れ可否を送信したりすることができる。この運行計画は、臨時バスの提供条件を含むことができる。

　情報端末４は、鉄道またはバスを利用する乗客の現在の位置情報などを送信することができる。また、情報端末４は、臨時バスの利用条件を受信したり、その利用条件の受け入れ可否を送信したりすることができる。

　ここで、リソース調停サーバ１は、乗客とバス会社の間で臨時バスの台数や料金を調停するに際し、仮想的な調停（以下、仮想調停と言う）、現実的な調停（以下、現実調停と言う）を行うことができる。

　「仮想調停」とは、リソース調停サーバ１の中に現実世界のモノに対応するオブジェクトを生成し、そのオブジェクトを仲介して調停を行うことである。オブジェクトとは、オブジェクト指向プログラミングにおけるインスタンス等の、現実世界のモノの情報を格納する一定のメモリ領域のことである。
　このように生成された複数のオブジェクトによってリソース調停サーバ１に作られた仮想的な世界を、以下「仮想空間」という。

　本実施形態における「仮想的な乗客」とは、リソース調停サーバ１の中に生成する、現実世界の乗客の情報を有するオブジェクトである。「仮想的な乗客」は、原則として現実の乗客の情報（位置情報等）を取得し、または仮想空間の環境に合わせて、オブジェクトの情報を更新する。
　例えば、現実世界の乗客が出発駅の自動改札口を通過した時、仮想空間の中に、その現実世界の乗客を模擬する「仮想的な乗客」を生成してもよい。
　その「仮想的な乗客」は、仮想空間内で運行している「仮想的な電車」に乗車した場合、「仮想的な乗客」の位置情報は、「仮想的な電車」と一致することになり、「仮想的な乗客」が「仮想的なバス」を仮想的な停留所で待っている時には、「仮想的な乗客」の位置情報は、「仮想的な停留場」となる。
　あるいは、現実世界の乗客が、スマートホンなどの位置情報デバイスを持っている場合は、現実世界の乗客の位置情報を「仮想的な乗客」の位置情報として更新してもよい。
　現実世界の乗客が到着駅の自動改札口を通過した時、仮想空間内に居た、その現実世界の乗客を模擬する「仮想的な乗客」を消滅させてもよい。

　仮想調停では、仮想的な乗客（以下、仮想乗客と言う）に臨時バスの利用条件を提示するとともに、仮想的なバス会社（以下、仮想バス会社と言う）に臨時バスの提供条件を提示し、仮想乗客と仮想バス会社の間で臨時バスの台数や料金を仮想調停することができる。
　現実調停では、仮想調停で得られた臨時バスの利用条件を現実的な乗客（以下、現実乗客と言う）に提示するとともに、仮想調停で得られた臨時バスの提供条件を現実的なバス会社（以下、現実バス会社と言う）に提示し、現実乗客と現実バス会社の間で臨時バスの台数や料金を現実調停することができる。

　ここで、現実調停の前に仮想調停を行うことにより、コンピュータ内の仮想空間上で仮想乗客と仮想バス会社の間で仮想バスの提供条件と利用条件が折り合うように仮想バスの提供条件と利用条件を早期に収束させることができる。この時、現実調停では、現実乗客と現実バス会社は、仮想調停で得られた臨時バスの提供条件と利用条件を受け入れるかどうかの判断のみで済ませることができる。このため、鉄道車両事故Ｐ３で滞留している多くの人員をなるべく短い時間で目的地に到達させる合理的な臨時バスの運行計画を、鉄道車両事故Ｐ３が復旧するまでの短時間に立案することができる。

　図３は、第一の実施形態に係るリソース調停システムに用いられるサーバのハードウェア構成を示すブロック図である。
　図３のハードウェアは、図２のリソース調停サーバ１、鉄道運行サーバ２およびバス運行サーバ３に用いることができる。ＣＰＵ１―０１、メモリ１―０２、通信ＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃａｒｄ）１―０３、ハードディスクドライブ（以下、ＨＤＤという）１―０４、入出力コントローラ１―０５およびモニタコントローラ１―０６は、バス１―０７等で接続されている。入出力コントローラ１―０５は、キーボード１―１１およびマウス１―１２に接続されている。モニタコントローラ１―０６は、ディスプレイ１―１３に接続されている。

　ＣＰＵ１―０１は、各サーバ全体の動作制御を司るハードウェアである。メモリ１―０２は、例えば、半導体メモリから構成され、各種プログラムや制御データを一時的に保持することができる。ＨＤＤ１―０４は、各種プログラムの実行ファイルなどを保持することができる。ＨＤＤは、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）であってもよい。通信ＮＩＣ１―０３は、コンピュータなどの機器を通信ネットワークに接続することができる。

　リソース調停サーバのＨＤＤ１―０４には、鉄道車両事故Ｐ３がない場合の到着時刻、鉄道車両事故Ｐ３の復旧後の到着時刻および鉄道車両事故Ｐ３の復旧前に臨時バスを利用した場合の到着時刻を予測したり、その予測情報に基づいて乗客とバス会社の間で臨時バスの台数や料金を調停したりするリソース調停プログラムを格納することができる。

　鉄道運行サーバ２のＨＤＤ１―０４には、鉄道運行ダイヤを管理したり、鉄道車両停止事故の復旧予想時間を予測したりする鉄道運行管理プログラムを格納することができる。

　バス運行サーバ３のＨＤＤ１―０４には、臨時バスとして利用可能なバスの台数と場所を管理したり、臨時バスの提供条件を受信したり、その提供条件に応答したりするバス運行管理プログラムを格納することができる。

　図２の情報端末４には、キーボード１―１１、マウス１―１２およびディスプレイ１―１３の代わりにタッチパネルが設けられている。さらに、情報端末４には、ＧＰＳモジュール１―０８が設けられている。それ以外は、前記ハードウェア構成と同じである。

　情報端末４のＨＤＤ１―０４には、鉄道またはバスを利用する乗客の現在の位置情報などを送信したり、臨時バスの利用条件を受信したり、その利用条件に応答したりする乗客情報管理プログラムを格納することができる。

　図４は、図２のリソース調停サーバの構成を示すブロック図である。
　図４において、リソース調停サーバ１には、通信処理部１１、現実調停処理部１２および仮想調停処理部１３が設けられている。

　通信処理部１１は、鉄道運行サーバ２、バス運行サーバ３および情報端末４との間で通信を行う。通信処理部１１には、メッセージ受信部１１―１およびメッセージ送信部１１―２が設けられている。メッセージ受信部１１―１は、鉄道運行サーバ２、バス運行サーバ３および情報端末４から転送されてくるメッセージを受信する。メッセージ送信部１１―２は、バス運行サーバ３および情報端末４にメッセージを送信する。

　現実調停処理部１２は、仮想調停処理部１３による仮想調停結果に基づいて、現実乗客と現実バス会社との間の現実調停を行う。この時、現実調停処理部１２は、仮想調停が不調の場合、現実調停を行わないようにすることができる。
現実調停処理部１２には、鉄道運行リソース情報１２―１、バス運行リソース情報１２―２、乗客リソース情報１２―３、現実調停部１２―４および現実調停メッセージ作成部１２―５が設けられている。

　鉄道運行リソース情報１２―１は、鉄道車両停止事故情報と鉄道車両停止事故の復旧予想時間を保持する。バス運行リソース情報１２―２は、臨時バスとして利用可能なバスの台数と場所を保持する。乗客リソース情報１２―３は、乗客の始発駅情報、到着駅情報あるいは現在の位置情報を保持する。現実調停部１２―４は、現実乗客および現実バス会社からの意思表示に基づいて現実調停を実行する。現実調停メッセージ作成部１２―５は、仮想調停内容に対応した現実調停のメッセージを作成する。

　仮想調停処理部１３は、仮想乗客と仮想バス会社との間の仮想調停を行う。この時、仮想調停処理部１３は、Ｎ（Ｎは２以上の整数）個の異なる臨時バスの提供条件と利用条件をそれぞれ設定し、そのＮ個の異なる臨時バスの提供条件と利用条件に基づいて仮想調停を行うことができる。仮想調停処理部１３には、新交通生成計画ソルバ１３―１、交通運行予測シミュレータ１３―２、調停係数補正部１３―３、仮想鉄道車両オブジェクト１３―４、仮想バスオブジェクト１３―５、仮想乗客オブジェクト１３―６および仮想調停部１３―７が設けられている。

　新交通生成計画ソルバ１３―１は、臨時バス用の仮想バスオブジェクト１３―５の配置および運行計画を立案する。交通運行予測シミュレータ１３―２は、仮想鉄道車両オブジェクト１３―４の運行予測を行う。調停係数補正部１３―３は、仮想調停における調停補正係数を変更する。この時、調停係数補正部１３―３は、仮想乗客による臨時バスの利用条件と仮想バス会社による臨時バスの提供条件の双方を満たすように調停補正係数を変更することができる。仮想鉄道車両オブジェクト１３―４は、移動中の鉄道車両の位置を決定する。仮想バスオブジェクト１３―５は、仮想バス会社の臨時バスの提供、不提供または提供する場合の料金を決定する。仮想乗客オブジェクト１３―６は、仮想乗客の臨時バスの利用、不利用または利用する場合の料金を決定する。仮想調停部１３―７は、仮想乗客オブジェクト１３―６と仮想バスオブジェクト１３―５の間で仮想調停を行う。

　以下、図４のリソース調停システムの動作について詳細に説明する。
　バス運行サーバ３から、臨時バスとして利用可能なバスの台数と場所がメッセージ受信部１１―１を介して転送されると、現実調停処理部１２のバス運行リソース情報１２―２に格納される。

　また、情報端末４から、情報端末４の所有者の始発駅情報、到着駅情報あるいは現在の位置情報がメッセージ受信部１１―１を介して転送されると、現実調停処理部１２の乗客リソース情報１２―３に格納される。

　また、鉄道運行サーバ３から、鉄道車両停止事故情報と鉄道車両停止事故の復旧予想時間がメッセージ受信部１１―１を介して転送されると、現実調停処理部１２の鉄道運行リソース情報１２―１に格納される。

　これらの格納された情報は、仮想調停処理部１３の仮想鉄道車両オブジェクト１３―４、仮想バスオブジェクト１３―５および仮想乗客オブジェクト１３―６にも格納される。仮想鉄道車両オブジェクト１３―４、仮想バスオブジェクト１３―５および仮想乗客オブジェクト１３―６が存在しない場合は、仮想鉄道車両オブジェクト１３―４、仮想バスオブジェクト１３―５および仮想乗客オブジェクト１３―６が仮想調停処理部１３にて新規に作成される。

　仮想調停処理部１３が鉄道車両停止事故情報を鉄道運行サーバ３から受信すると、交通運行予測シミュレータ１３―２が稼働を開始する。

　交通運行予測シミュレータ１３―２は、仮想鉄道車両オブジェクト１３―４、仮想バスオブジェクト１３―５および仮想乗客オブジェクト１３―６を使って、その鉄道車両停止事故の発生時点から鉄道車両停止事故の復旧予想時間後の所定の時間まで、交通運行予測シミュレーションを実施する。

　この交通運行予測シミュレーションは、以下の３つのケースについて、それぞれ鉄道車両停止事故の発生時点まで遡って実施される。
（Ａ）鉄道車両停止事故が発生しなかった場合
（Ｂ）鉄道車両停止事故が発生した場合
（Ｃ）鉄道車両停止事故が発生した上で、仮想調停処理部１３の新交通生成計画ソルバ１３―１の示す臨時バスが運行された場合

　仮想バスオブジェクト１３―５および仮想乗客オブジェクト１３―６のそれぞれには、独自の判断基準をもつ推論エンジンのメソッドが搭載されている。

　上述した３つのケース（Ａ）～（Ｃ）の交通運行予測シミュレーション結果を受けて、仮想バスオブジェクト１３―５は、仮想バス会社の臨時バスの提供、不提供または提供する場合の料金を決定し、仮想乗客オブジェクト１３―６は、仮想乗客の臨時バスの利用、不利用または利用する場合の料金を決定する。臨時バスの料金を決定する場合、臨時バスを利用した時の乗客の利益を参照することができる。この場合の乗客の利益とは、臨時バスを利用した時の到着時間の短縮時間とすることができる。

　仮想調停部１３―７は、仮想バスオブジェクト１３―５および仮想乗客オブジェクト１３―６の判断を受け取ると、仮想バスオブジェクト１３―５および仮想乗客オブジェクト１３―６に対して、その判断に対する仮想調停を行う。そして、仮想調停部１３―７は、仮想バスオブジェクト１３―５の判断と仮想乗客オブジェクト１３―６の判断とが折り合うまで仮想調停を繰り返す。仮想バスオブジェクト１３―５の判断と仮想乗客オブジェクト１３―６の判断は、仮想バス会社が臨時バスを提供する場合の料金と、仮想乗客が臨時バスを利用する場合の料金を基づいて行うことができる。この時、仮想バス会社が臨時バスを提供する場合の料金と、仮想乗客が臨時バスを利用する場合の料金ついて、仮想バスオブジェクト１３―５と仮想乗客オブジェクト１３―６とが合意するまで仮想調停を繰り返すことができる。

　仮想バスオブジェクト１３―５および仮想乗客オブジェクト１３―６との間で仮想調停が収束したら、仮想調停部１３―７は、その調停結果を現実調停メッセージ作成部１２―５に渡す。現実調停メッセージ作成部１２―５は、その調停結果に基づいて、現実乗客と現実バス会社向けの調停メッセージを作成する。この調停メッセージは、メッセージ送信部１１―２を介してバス運行サーバ３および情報端末４に送信される。

　具体的なメッセージの内容としては、現実乗客の有する情報端末４あるいは現実バス会社のバス運行サーバ３のＷｅｂブラウザの画面などで表示できるメッセージとしてもよい。

　現実乗客および現実バス会社は、情報端末４およびバス運行サーバ３の画面を操作して、現実の自分の意思を伝える返信メッセージをリソース調停サーバ１に送信する。その返信メッセージは、メッセージ受信部１１―１で受信され、現実調停部１２に渡される。

　現実調停部１２は、鉄道運行リソース情報１２―１、バス運行リソース情報１２―２および乗客リソース情報１２―３を参照しつつ、現実乗客と現実バス会社との間の現実調停を行う。現実調停メッセージ作成部１２―５は、その現実調停結果に基づいて、現実乗客と現実バス会社向けの調停メッセージを作成する。この調停メッセージは、メッセージ送信部１１―２を介してバス運行サーバ３および情報端末４に送信され、現実乗客と現実バス会社との間の現実調停を繰り返すことができる。

　現実乗客と現実バス会社との間の現実調停が失敗した場合、仮想調停の想定条件が間違っていたものと推認される。そこで、現実調停に失敗した場合には、調停係数補正部１３―３は、仮想乗客オブジェクト１３―６または仮想バスオブジェクト１３―５に対応した調停補正係数を変更する。そして、その調停補正係数を仮想乗客または仮想バスを識別する固有のＩＤとともに、図３のＨＤＤ１―０４の補正係数用テーブルに記録し、次回の仮想調停時において、この調停補正係数を用いた仮想調停を試みる。この調停補正係数には、仮想バス会社が臨時バスを提供する場合の料金の値引き率および仮想乗客が臨時バス利用する場合の料金の値引き率を設定することができる。

　図５は、図４のリソース調停サーバの処理の流れを示すブロック図である。

　図５の現実世界の時間軸４―１上において、鉄道車両停止事故Ｐ３の発生前は、図４のリソース調停サーバ１は、移動中の鉄道車両の位置、移動中の乗客の位置および臨時バスとして利用可能なバスの位置または台数をリアルタイムで把握している。仮想鉄道車両オブジェクト１３―４、仮想乗客オブジェクト１３－６および仮想バスオブジェクト１３―５はリソース調停サーバ１の中のメモリ空間にそれぞれ作成される。

　仮想鉄道車両オブジェクト１３―４は、移動中の鉄道車両の位置を常に記録し、仮想乗客オブジェクト１３－６は、移動中の乗客の位置を常に記録し、仮想バスオブジェクト１３―５は、臨時バスとして利用可能なバスの位置または台数を常に記録しているものとする。

　そして、現実世界の時間軸４―１上の時刻４－２において、鉄道車両停止事故Ｐ３が発生すると、リソース調停サーバ１における仮想運行フェーズ４―３に移行する。仮想運行フェーズ４―３では、交通運行予測シミュレータ１３―２が起動され、仮想鉄道車両オブジェクト１３―４の運行予測を行う。交通運行予測シミュレータ１３―２は、仮想鉄道車両オブジェクト１３―４の運行予測に基づき、仮想乗客オブジェクト１３―６の到着時刻予測も行う。さらに、新交通生成計画ソルバ１３―３は、仮想鉄道車両オブジェクト１３―４の運行予測に基づき、臨時バス用の仮想バスオブジェクト１３―５の配置および運行計画を立案する。そして、交通運行予測シミュレータ１３―２は、仮想バスオブジェクト１３―５の運行計画を利用した場合の仮想乗客オブジェクト１３―６の到着時刻予測も行う。

　図６は、図４の仮想乗客オブジェクト１３―６の目的地到着時刻を説明する図である。
　図６において、交通運行予測シミュレータ１３―２は、上述した３つのケース（Ａ）～（Ｃ）について、各仮想乗客オブジェクト１３―６の到着時刻ｔ１、ｔ２、ｔ３を予測する。図６の例では、鉄道車両停止事故４－２が発生した時に、新交通生成計画ソルバ１３―１の示す臨時バスを利用した場合は利用しない場合に比べて目的地への到着時刻が早くなっている。

　図５の仮想乗客オブジェクト１３―６は、到着時刻ｔ１、ｔ２、ｔ３の予測に基づき、仮想の臨時バスに該当する仮想バスオブジェクト１３―５の利用、不利用または利用する場合の料金を提示する。仮想バス会社の仮想バスオブジェクト１３―５は、新交通生成計画ソルバ１３―３が立案した臨時バスの仮想バスオブジェクト１３―５の利用計画に対して、臨時バスの提供、不提供、または提供する場合の料金を提示する。

　仮想調停部１３―７は、仮想乗客オブジェクト１３―６が提示した料金と、仮想バスオブジェクト１３―５が提示した料金に基づいて、仮想乗客オブジェクト１３―６と仮想バスオブジェクト１３―５の間で仮想調停を行う。この仮想調停は、仮想乗客オブジェクト１３―６と仮想バスオブジェクト１３―５が合意できる状態になるまで続けられる。仮想運行フェーズ４―３は、リソース調停サーバ１の中のメモリ空間に作られている仮想鉄道車両オブジェクト１３―４、仮想バスオブジェクト１３―５および仮想乗客オブジェクト１３―６にて仮想的に実施される。

　これらの仮想空間内での仮想調停が完了した後、リソース調停サーバ１は、現実運行フェーズ４―４での現実調停に入る。現実運行フェーズ４―４では、現実調停メッセージ作成部１２―５は仮想調停内容に対応した現実調停のメッセージを作成し、現実乗客および現実バス会社に調停案を転送する。その調停案に対して、現実乗客は、臨時バスの利用、不利用または利用する場合の料金を逆提案する。また、現実バス会社は、臨時バスの提供、不提供または提供する場合の料金を逆提案する。

　現実調停部１２は、現実乗客および現実バス会社からの逆提案に基づいて現実調停を実行する。現実運行フェーズ４―４での現実調停の完了後、調停内容に従った臨時バスの運行と、乗客の利用と、料金の徴収と回収が実施され、元の時間軸４―１に復帰する。

　図７は、図４の鉄道運行サーバ２、バス運行サーバ３および情報端末４の構成を示すブロック図である。
　図７において、鉄道運行サーバ２、バス運行サーバ３および情報端末４には、リソース情報提供部２０―１、メッセージ送信部２０―２、メッセージ受信部２０―３、自動調停部２１および手動調停部２２がそれぞれ設けられている。

　自動調停部２１には、調停メッセージ作成部２１―１、調停メッセージ解析部２１―２およびリソース調停部２１―３が設けられている。手動調停部２２には、調停メッセージ入力部２２―１および調停メッセージ表示部２２―２が設けられている。

　鉄道運行サーバ２のリソース情報提供部２０―１は、運行鉄道車両情報および当日ダイヤを初期時にリソース調停サーバ１に提供し、運行鉄道車両の位置情報を定期的にリソース調停サーバ１に提供する。

　バス運行サーバ３のリソース情報提供部２０―１は、利用可能なバスの台数および位置情報を初期時および定期的にリソース調停サーバ１に提供する。

　情報端末４のリソース情報提供部２０―１は、情報端末４の所有者の出発地および到着地の位置情報または名称を初期時にリソース調停サーバ１に提供し、情報端末４の位置情報を定期的にリソース調停サーバ１に提供する。

　バス運行サーバ３および情報端末４は、リソース調停サーバ１の現実調停のフェーズにおいて、それぞれのメッセージ受信部２０－３を介して調停メッセージを受信する。この場合、バス運行サーバ３および情報端末４は自動調停を行うか、手動調停を行うかを選択することができる。

　手動調停が選択された場合、手動調停部２２にて手動調停が行われる。この時、バス運行サーバ３および情報端末４のオペレータは、調停メッセージ表示部２２―２の表示内容に応じて、調停メッセージ入力部２２―１より応答を作成し、メッセージ送信部２０－２を介して返送する。これらの操作は、例えば、現実乗客の有する情報端末４あるいは現実バス会社のバス運行サーバ３のＷｅｂブラウザの画面上で行うことができる。

　一方、自動調停が選択された場合、自動調停部２１にて自動調停が行われる。この時、オペレータは操作を行わず、調停メッセージ解析部２１―２がリソース調停部２１―３の調停内容を参照して、調停メッセージを解析する。そして、調停メッセージ作成部２１―１は、その解析結果に基づいて調停メッセージの応答を作成し、メッセージ送信部２０－２を介して返送する。なお、リソース調停部２１―３の実現の態様としては、図１２（ａ）～（ｄ）のファジィルールテーブルとメンバーシップ関数に基づいて動作する推論エンジンを用いることができる。

　図８は、図２のリソース調停システムのメッセージ通信処理を示すブロック図である。
　図８において、リソース調停システムへの参入時または鉄道車両停止事故Ｐ３が発生していない間には、リソース調停サーバ１は、鉄道運行サーバ２、バス運行サーバ３および情報端末４との間でメッセージ通信を行う。

　鉄道運行サーバ２は、リソース調停システムへの参入時において、当日の運行ダイヤをリソース調停サーバ１に転送する（２７―１）。リソース調停サーバ１は、このタイミングで、複数の仮想鉄道車両オブジェクト１３―４を作成する（２７―３）。また、鉄道運行サーバ２は、運行中の全ての鉄道車両の位置情報をリソース調停サーバ１に定期的に転送する（２７―２）。リソース調停サーバ１は、鉄道車両の位置情報に基づいて、仮想鉄道車両オブジェクト１３―４の内容を更新する（２７―４）。

　バス運行サーバ３は、リソース調停システムへの参入時に、稼動可能なバスの台数および位置情報をリソース調停サーバ１に転送する（３７―１）。リソース調停サーバ１は、このタイミングで、複数の仮想バスオブジェクト１３―５を作成する（３７―２）。また、バス運行サーバ３は、稼動可能なバスの台数および位置情報をリソース調停サーバ１に定期的に転送する（３７―１）。この時、リソース調停サーバ１は、必要に応じて仮想バスオブジェクト１３―５の追加および削除を行う（３７―２）。

　情報端末４は、リソース調停システムへの参入時において、情報端末４の所有者の出発地および到着地の位置情報あるいは名称を入力する（４７―１）。リソース調停サーバ１は、このタイミングで、仮想乗客オブジェクト１３―６を生成する（４７―４）。その後、情報端末４は、情報端末４の所有者の位置情報を定期的に転送し続け（４７―２）、その位置情報に基づいて仮想乗客オブジェクト１３―６が更新され続ける（４７―５）。情報端末４が終着地の到着をリソース調停サーバ１に通知すると（４７―３）、リソース調停サーバ１は、仮想乗客オブジェクト１３―６を消滅させる（４７―６）。

　図９は、図４のリソース調停サーバの動作の流れを示す図である。
　図９において、リソース調停サーバ１は、時刻４－２での鉄道車両停止事故Ｐ３の発生直後から稼動し始める。この時、交通運行予測シミュレータ１３―２は、鉄道車両停止事故Ｐ３の発生通知を受信すると、仮想鉄道車両オブジェクト１３―４、仮想乗客オブジェクト１３―６および仮想バスオブジェクト１３―５の最新状態を取得する（８―１）。そして、交通運行予測シミュレータ１３―２は、「（Ａ）鉄道車両停止事故が発生しなかった場合」の交通運行予測シミュレーションを開始する（８―１２）。

　この交通運行予測シミュレーションは、鉄道車両停止事故Ｐ３の発生時から鉄道車両停止事故Ｐ３の復旧後を越えた所定の時刻（最大は終電まで）まで実施する。

　また、鉄道車両停止事故Ｐ３の発生後の状況を再現するために、ダミーの仮想乗客オブジェクトを一定の時間単位で生成する。このダミーの仮想乗客オブジェクトの発生／消滅スケジュールとして、過去の同じ曜日の時間帯の乗客データなどを使ってもよい。

　この交通運行予測シミュレーションによって、仮想乗客オブジェクト１３―６のそれぞれは、「（Ａ）「鉄道車両事故」が発生しなかった場合」の到着位置（到着駅）の到着時刻ｔ１を取得することができる（８―４）。この到着時刻ｔ１は、仮想調停部１３―７に転送された後、各仮想乗客オブジェクト１３―６に記録される。

　次に、交通運行予測シミュレータ１３―２は、鉄道車両停止事故発生時刻４―２に遡って、今度は「（Ｂ）鉄道車両停止事故が発生した場合」の交通運行予測シミュレーションを開始する（８―２）。

　この交通運行予測シミュレーションによって、仮想乗客オブジェクト１３―６のそれぞれは、「（Ｂ）鉄道車両停止事故が発生した場合」の到着位置（到着駅）の到着時刻ｔ２を取得することができる（８―５）。この到着時刻ｔ２も、仮想調停部１３―７に転送された後、各仮想乗客オブジェクト１３―６に記録される。

　ここで、新交通生成計画ソルバ１３―３は、この「（Ｂ）鉄道車両停止事故が発生した場合」における乗客の移動量と、鉄道車両停止事故発生時点における臨時バスとして利用可能なバスの位置および台数から、臨時バスの臨時運行計画（以下、新交通計画と言う。）を立案する（８―１１）。

　再び、交通運行予測シミュレータ１３―２は、鉄道車両停止事故発生時刻４―２に遡って、今度は「（Ｃ）鉄道車両停止事故が発生した上で、さらに、新交通計画による臨時バスが運行された場合」の交通運行予測シミュレーションを開始する（８―３）。

　この交通運行予測シミュレーションによって、仮想乗客オブジェクト１３―６のそれぞれは、「（Ｃ）鉄道車両停止事故が発生した上で、さらに、新交通計画による臨時バスが運行された場合」の到着位置（到着駅）の到着時刻ｔ３を取得することができる（８―６）。この到着時刻ｔ３も、仮想調停部１３―７に転送された後、各仮想乗客オブジェクト１３―６に記録される。

　このようにして、上記の３つのケース（Ａ）～（Ｃ）における各仮想乗客オブジェクト１３―６の目的地の到着時刻ｔ１、ｔ２、ｔ３が算出される。また、各仮想バスオブジェクト１３―５の運行スケジュールおよび運行経路が算出される（８―７）。

　次に、各仮想乗客オブジェクト１３―６は、上記の３つのケース（Ａ）～（Ｃ）における到着時刻ｔ１、ｔ２、ｔ３から、臨時バスの利用または不利用の決定、および利用する場合の料金を提示する（８―１０）。また、各仮想バスオブジェクト１３―５は、臨時バスの提供または不提供の決定、および提供する場合のバスの必要経費を提示する（８―８）。

　仮想調停部１３―７は、各仮想乗客オブジェクト１３―６と各仮想バスオブジェクト１３―５に仲立ち、料金の折り合いをつけるように、仮想空間内での仮想調停を行う（８―９）。

　図１０は、図４の新交通生成計画ソルバ１３―３の処理の流れを示すブロック図である。
　図１０において、新交通生成計画ソルバ１３―３は、駅情報９―２と仮想乗客オブジェクト１３―６の移動情報９―１を収集し、その移動情報９―１をベクトル情報として集約する（９―３）。駅情報９―２は、例えば、各駅Ａ～Ｉの時間帯ごとの乗降客の人数を含むことができる。そして、新交通生成計画ソルバ１３―３は、このベクトル情報を品種ごとの移動要求の数に変換する（９―７）。なお、品種は、任意の駅の２駅間の組合せである。

　図１１は、第一の実施形態に係るリソース調停システムで用いられる品種の一例を示す図である。
　図１１において、鉄道路線Ｐ１の駅Ａ～Ｉから選択された２駅を組み合わせることにより、品種Ｓ１～Ｓ１９を得ることができる。図１１の例では、隣接する２駅間の組み合わせと、１駅を跨いだ場合の２駅間の組み合わせと、２駅を跨いだ場合の２駅間の組み合わせを示した。なお、３駅以上を跨いだ場合の２駅間の組み合わせであってもよい。

　また、図１０において、新交通生成計画ソルバ１３―３は、駅情報９―２と、仮想鉄道車両オブジェクト１３―４の移動情報９―４と、鉄道車両停止事故復旧時刻情報９―６を収集し、グラフを構築する（９―５）。このグラフから各品種の最大流量経路探索を行い（９―９）、各品種の最適経路と流量の算出を行う（９―１０）。そして、新交通生成計画ソルバ１３―３は、各品種の最適経路と流量と移動要求の数に基づいて、各品種の輸送量の統合および調整を行い（９―８）、各品種の調整済み流量を算出する（９―１１）。

　この時、各品種の調整済み流量は、鉄道車両事故Ｐ３が発生した時間帯に応じて変化させることができる。例えば、鉄道車両事故Ｐ３が通勤時間帯に発生した場合には、各品種の調整済み流量を増大させ、鉄道車両事故Ｐ３が昼間に発生した場合には、各品種の調整済み流量を減少させることができる。

　また、各品種の調整済み流量は、各駅の乗降客の人数に応じて変化させることができる。例えば、乗降客の人数の多い駅を含む品種については、その調整済み流量を増大させ、乗降客の人数の少ない駅しか含まない品種については、その調整済み流量を減少させることができる。

　また、新交通生成計画ソルバ１３―３は、仮想バスオブジェクト１３―５から待機臨時バス台数情報９―１２を抽出し、各品種の調整済み流量９―１１に基づいて、バスの選出を行い（９―１３）、この情報に基づいて新輸送経路情報９―１３を作成する。

　以下、仮想調停部１３―７の調停処理について具体例を示しながら詳細に説明する。
　図１２（ａ）から（ｄ）は、図４の仮想乗客オブジェクト１３―６が利用する臨時バスの料金を決めるのに用いられるファジィルールテーブルとメンバーシップ関数の一例を示す図である。
　図１２（ａ）において、ケース（Ｃ）とケース（Ｂ）の到着時間の差Ｄｅｌａｙ（分）と、ケース（Ｃ）とケース（Ａ）の到着時間の差とケース（Ｃ）とケース（Ｂ）の到着時間の差の比率ｅｆｆｅｃｔから、仮想乗客オブジェクト１３―６が臨時バスの利用に支払える料金のファジィルールテーブルと、ファジィ推論の前件部と後件部のメンバーシップ関数を設定することができる。

　なお、図１２（ｂ）はＤｅｌａｙ（分）についてのメンバーシップ関数、図１２（ｃ）は比率ｅｆｆｅｃｔについてのメンバーシップ関数、図１２（ｄ）は乗客が臨時バス利用する場合の料金についてのメンバーシップ関数を示している。

　図１２（ａ）のファジィルールテーブルでは、例えば、乗客が臨時バスを利用することで逆に到着時刻が遅れてしまうような場合は、支払いが０円となることが規定されている。このため、仮想乗客オブジェクト１３―６は臨時バスの利用をしないという決定をすることができる。

　また、鉄道車両停止事故の影響で６０分の遅延が発生した場合、臨時バスを利用することで３０分の遅延に止めることができるのであれば、料金を支払うモチベーションが発生するということをファジィルールテーブルで規定することができる。さらに、鉄道車両停止事故による９０分の遅延に対して、臨時バスを利用することで８０分の遅延に止めることになるだけなら、臨時バスに料金を払うモチベーションは発生しないということをファジィルールテーブルで規定することができる。

　一方、仮想バスオブジェクト１３―５の場合は、例えば、２００００円（固定費）にバスの運転時間（時）に１００００円を乗算したものを加算して、それに対して１．２（利益率２０％）倍した額を越える金額を徴収できるのであれば、臨時バスを運行させ、それを下回る場合は臨時バスを運行しないという単純なルールを設定することができる。

　このような、仮想乗客オブジェクト１３―６および仮想バスオブジェクト１３―５の判断に対して、仮想調停部１３―７は以下のような計算および調停を行うことができる。

（ケースＫ１）ある仮想バスオブジェクト１３―５に乗車を希望する仮想乗客オブジェクト１３―６の提示金額の合計金額が、仮想バスオブジェクト１３―５の期待する金額を越えているものとする。この場合は、仮想調停部１３―７は、仮想バスオブジェクト１３―５の期待する金額を、仮想オブジェクトの人数で割り算した金額を、それぞれ仮想乗客オブジェクト１３―６に提案し、仮想バスオブジェクト１３―５には、提示通りの金額を提案する。

　ケースＫ１の場合、基本的には仮想乗客オブジェクト１３―６にとっては値下げ方向に働く。このため、仮想バスオブジェクト１３―５だけでなく仮想乗客オブジェクト１３―６にとっても、この提案を受理しやすくなると考えられる。

　（ケースＫ２）ある仮想バスオブジェクト１３―５に乗車を希望する仮想乗客オブジェクト１３―６の提示金額の合計金額が、仮想バスオブジェクト１３―５の期待する金額を下回っているものとする。この場合は、例えば、仮想調停部１３―７は、仮想バスオブジェクト１３―５の期待する金額を、仮想オブジェクトの人数で割り算した金額から１５％を上限とした値上げを行い、それぞれ仮想乗客オブジェクト１３―６に提案し、仮想バスオブジェクト１３―５にも、提示通りの金額から１５％を上限とした値引きを提案することができる。

　ケースＫ２の場合、仮想乗客オブジェクト１３―６にとっては値上げの方向に働き、仮想バスにとっては値下げの方向に働く。このため、この提案によって臨時バスの利用を断念する仮想乗客オブジェクト１３―６が発生する可能性があり、それによって臨時バスの収入も減るので、臨時バスの運行を仮想バス会社が取りやめる可能性がある。

　仮想調停部１３―７は、上記のケースＫ１、Ｋ２の調停ポリシーに基づいて、仮想乗客オブジェクト１３―６と仮想バスオブジェクト１３―５間での調停を繰り返すことで、調停に応じた仮想乗客オブジェクト１３―６と仮想バスオブジェクト１３―５が最終的に残存して、図５の仮想調停フェ―ズ４―３が完了する。

　次に、図５の現実調停フェーズ４―４では、現実乗客および現実バス会社に対して、仮想調停によって決定した金額を提示して現実調停を行う。基本的には、その金額に対して、現実乗客および現実バス会社が受理するか否かだけを問うものとすることで、現実調停時間の増大を防止することができる。ただし、上記の仮想調停と同じようなルールを、現実調停でも運用してもよい。

　また、現実調停を行う際に、現実乗客および現実バス会社に仮想調停の経緯を提示してもよい。これにより、現実乗客および現実バス会社は、仮想調停の背景を知ることができ、仮想調停結果を受け入れるか否かの判断材料とすることができる。

　現実調停に失敗した場合には、仮想乗客オブジェクト１３―６または仮想バスオブジェクト１３―５に対応した調停補正係数を変更することができる。これにより、現実乗客および現実バス会社の双方にとって仮想調停結果を受け入れ可能な条件を再設定することができる。

　図１３（ａ）および（ｂ）は、図４の調停係数補正部１３－３で用いられる補正係数用テーブルを示す図である。
　図１３（ａ）の補正係数用テーブルでは、バスを識別する固有のバスＩＤとともに、バス会社が臨時バスを提供する場合の料金の値引き率が設定される。この時、バスＩＤごとに値引き率が異なっていてもよい。
　図１３（ｂ）の補正係数用テーブルでは、乗客を識別する固有の乗客ＩＤとともに、乗客が臨時バス利用する場合の料金の値引き率が設定される。この時、乗客ＩＤごとに値引き率が異なっていてもよい。

　図１４は、補正係数用テーブルに基づいて変更されたファジィルールテーブルを示す図である。
　図１４では、図１２のファジィルールテーブルの記載金額が全て１０％引きになっている例を示した。

　図１２のファジィルールテーブルを用いた時に調停に失敗した場合においても、図１４のファジィルールテーブルを用いることにより、乗客にとっては料金の値下げの方向に働かせることができる。このため、乗客にとっては調停案を受け入れやすくすることができる。

　また、乗客にとって料金を値下げの方向に働かせることにより、臨時バスの利用を受け入れる乗客の人数を増大させることができる。このため、臨時バスを利用する乗客から徴収可能な合計料金の減少を抑制することが可能となる。また、乗客にとって料金を値下げの方向に働かせることにより、、臨時バスの利用を受け入れる乗客の人数が大幅に増大した場合には、臨時バスを利用する乗客から徴収可能な合計料金を増大させることも可能となる。

　図１５は、図２のリソース調停システムに適用される鉄道運行時の環境条件の具体例を示す図である。
　図１５において、鉄道運行時の環境条件には項目が設定される。項目には、対象時刻、車両数、利用乗客数、事故規模および事故の発生時間場所を設けることができる。この項目ごとに数値および内容を設定することができる。新交通生成計画ソルバ１３―３は、新交通生成計画の立案時において、この環境条件を参照することができる。

　図１６は、鉄道車両停止事故発生中に移動中の鉄道車両の乗客数の変化を示すグラフ図である。
　図１６において、鉄道車両事故発生中に、鉄道車両が停止し、乗車人員が増加していることが分かる。図１６の例では、図１５の環境条件に従って１１：００に鉄道車両事故が発生し、９０分間運行が停止した場合を示した。

　図１７は、図１の駅Ｅおよび駅Ｆに滞留している乗客数を示すグラフ図である。
　図１７において、鉄道車両事故発生中に、鉄道車両の定員を越えて乗車できない乗客が発生したり、目的地に到着する鉄道車両が存在しなくなることによって、乗客が駅Ｅ、Ｆに留まることを余儀なくされている。駅Ｅ、Ｆ間で事故が発生しているため、駅Ｅ、Ｆを経由しなければならない乗客は、駅Ｅ、Ｆで下車せざるを得ない状況になっていることが分かる。

　図１８は、図２のリソース調停システムによって提案された臨時バスの運行計画案を示す図である。
　図１８において、鉄道車両停止事故区間への臨時バス（簡易ソルバ）の運行計画案と、図１０に基づくアルゴリズムによって提案された臨時バスの運行計画案（新ソルバ）を比較した。

　簡易ソルバによる簡易方式では、鉄道車両事故発生時に使用可能なバスが駅Ｅ、Ｆ間に全て投入される。他の駅から駅Ｅ、Ｆにバスを移動させても、その移動に時間を費やし、事故復旧までの間の輸送力と成り得ない場合がある。

　一方、新ソルバによる運行計画案では、各駅Ａ～Ｉで利用可能なバスをその駅Ａ～Ｉに即時投入することができる。このため、鉄道車両停止事時に使用可能なバスを鉄道路線Ｐ１の全線に渡って鉄道輸送の補完として機動させることができる。調停前のシミュレーション結果では、輸送総人員に短縮時間を乗算した値において、１２．７％程度の改善を図ることができた。

　図１９は、図２のリソース調停システムによって提案された現実の臨時バスによって短縮される時間を示す図である。
　図１９において、図１５の環境条件で与えられた利用乗客数（６万人）のうち仮想調停の対象となった仮想乗客オブジェクト１３―６の数および仮想バスによる遅着時間の短縮時間と、現実調停の対象となった現実の乗客の数および現実の臨時バスによる遅着時間の短縮時間を示した。

　図１８の新ソルバによって、現実世界において遅着が予想される乗客を算出し、その乗客を仮想乗客オブジェクト１３―６として、仮想バスオブジェクト１３―５と調停を行わせた。その結果、現実の調停に応じると予想される人員は６００人程度となり、遅着予想乗客数の１／１０、利用乗客数の１／１００程度の乗客と調停を行えば足りることが分かった。また、現実調停候補者は遅着予想乗客に対して１５分程度の遅着時間の短縮が見込めることが分かった。

　図２０は、図２のリソース調停システムよって提案された運行計画案の適用の有無による駅Ｆの滞留人員の変化を示す図である。
　図２０において、運行計画案を適用した場合は適用しない場合に比べて駅Ｆの滞留人員が減少していることが分かる。リソース調停システムの仮想調停を経た後の現実調停によって、乗客の輸送効率を向上させることができる。

　図２１（ａ）および（ｂ）、図２のリソース調停システムによる仮想調停によって妥結した料金を示す図である。
　図２１（ａ）において、仮想バスオブジェクト１３―５は、臨時バスを提供する場合の料金をバスＩＤごとに提示することができる。
　図２１（ｂ）において、仮想乗客オブジェクト１３―６は、乗客が臨時バス利用する場合の料金を乗客ＩＤごとに提示することができる。

　仮想調停によって現実調停前におおよその料金が明かになり、現実調停の際に無益な調停を繰り返すことを防止することができる。さらに、仮想調停の経緯を現実乗客と現実バス会社に示すことで、現実乗客と現実バス会社の双方に納得感を与えることができ、現実調停にスムーズに推移させることができる。

　図２２は、図４の情報端末４の表示画面の一例を示す図である。
　図２２において、図４の現実調停メッセージ作成部１２―５は、仮想調停部１３―７からの調停結果に基づいて、現実乗客向けの調停メッセージを作成し、メッセージ送信部１１―２を介して情報端末４に送信する。

　情報端末４が調停メッセージを受信すると、情報端末４の表示画面Ｍ１に調停メッセージが表示される。調停メッセージは、鉄道車両の復旧予想時刻、臨時バスの出発駅と終着駅、発車時刻、到着予定時刻および乗車料金を含むことができる。また、表示画面Ｍ１には、算出理由を提示させるボタンＭＢ２、乗車の受諾を表明するボタンＭＢ３、乗車の拒否を表明するボタンＭＢ４を表示させることができる。

　乗客がボタンＭＢ２を選択すると、表示画面Ｍ２に移行し、料金の算出理由が表示される。算出理由には、料金の交渉経過を含むことができる。乗客がボタンＭＢ３を選択すると、表示画面Ｍ３に移行し、乗車手続きなどを表示させることができる。乗客がボタンＭＢ４を選択すると、表示画面Ｍ４に移行し、終了メッセージなどを表示させることができる。

　図２３は、図４のバス運行サーバ３の表示画面の一例を示す図である。
　図２３において、図４の現実調停メッセージ作成部１２―５は、仮想調停部１３―７からの調停結果に基づいて、現実バス会社向けの調停メッセージを作成し、メッセージ送信部１１―２を介してバス運行サーバ３に送信する。

　バス運行サーバ３が調停メッセージを受信すると、バス運行サーバ３の表示画面Ｍ１１に調停メッセージが表示される。調停メッセージは、鉄道車両の復旧予想時刻、臨時バスの出発駅と終着駅、発車時刻、到着予定時刻および支払予定金額を含むことができる。また、表示画面Ｍ１１には、算出理由を提示させるボタンＭＢ１２、臨時バスの運行の受諾を表明するボタンＭＢ１３、臨時バスの運行の拒否を表明するボタンＭＢ１４を表示させることができる。

　バス会社がボタンＭＢ１２を選択すると、表示画面Ｍ１２に移行し、料金の算出理由が表示される。算出理由には、料金の交渉経過を含むことができる。バス会社がボタンＭＢ１３を選択すると、臨時バスの配車手続きなどを表示させることができる。バス会社がボタンＭＢ１４を選択すると、終了メッセージなどを表示させることができる。

　第二の実施形態では、第一の実施形態を援用して、さらに規模の大きいリソース調停対象向けのリソース調停方法について述べる。
　第一の実施形態においては、リソースの仮想調停から現実調停までを連続的に行い現実時間内で完了させている。リソースの仮想調停から現実調停までを連続的に行う場合、調停対象の種類や数が増えると、仮想調停から現実調停までを現実時間内に完了させるのが困難になる可能性がある。ここで言う現実時間とは、鉄道車両停止事故発生時から復旧時までの時間である。鉄道車両停止事故の復旧時までに現実調停が完了しないと、乗客が臨時バスを利用する利益がない。
　そこで、第二の実施形態においては、事故とリソース生成のパターンを予め作成し、データベースに格納しておく。そして、実際の事故発生後、その実際の事故に類似するパターンをデータベースから抽出して、現実調停を実施する。これにより、実際の事故発生後に、その実際の事故に応じた仮想調停を行うことなく、現実調停を実施するこができる。このため、調停対象の種類や数が増えた場合においても、実際の事故発生から現実調停までを現実時間内に完了させることが可能となる。

　第二の実施形態におけるリソース調停システムで想定する環境条件の一例を以下に示す。
鉄道路線数：約７路線
停車駅数：約１００駅
鉄道路線距離：約３００ｋｍ
利用者総数：約１００万人／日
運行時間：約１８時間／日
利用可能な臨時バス台数：バスターミナルを有する主要駅に５台程度

　図２４は、第二の実施形態に係る鉄道路線上での事故発生時の臨時バス運行路線の一例を示す図である。
　図２４では、駅０～９９が設けられている時の鉄道路線Ｐ１１および鉄道車両事故Ｐ１３の発生時の臨時バス運行路線Ｐ１２を例示した。ただし、図２４では、バスターミナルを有する駅のみをノードとして表示している。

　鉄道車両事故Ｐ１３の発生時に、図２４のような大規模な鉄道網の振り替え輸送を調停対象とする場合、仮想調停処理に数時間を要することがあり、仮想調停から現実調停までを現実時間内に完了させるのが困難になる可能性がある。このため、第二の実施形態におけるリソース調停システムでは、図２４の鉄道網上で過去に発生した鉄道車両事故に基づいて、現実の鉄道車両事故が発生する前に仮想空間上で仮想調停を行う。この仮想調停は、鉄道車両事故の発生地点、発生時刻および発生規模などの鉄道車両事故の発生条件を変化させて行う。鉄道網上で過去に発生した鉄道車両事故は、過去に発生した実際の鉄道車両事故であってもよいし、シミュレーション上で模擬的に発生させた仮想的な鉄道車両事故であってもよい。

　この仮想調停を行うと、その時の事故情報、新交通作成情報および仮想調停後情報を、鉄道車両事故の事故情報と対応させて記憶しておく。新交通作成情報は、鉄道車両事故の発生条件に応じて決定される臨時バスを提供するバス会社の名称、臨時バスの経路および台数などである。仮想調停後情報は、鉄道車両事故の発生条件に応じて決定される臨時バスを利用する乗客の人数および臨時バスの経路などである。そして、この仮想調停後に、図２４の鉄道網上で実際の鉄道車両事故が発生した場合、その実際の鉄道車両事故に類似する発生条件に対応する新交通作成情報および仮想調停後情報を選択する。そして、その選択された新交通作成情報および仮想調停後情報に基づいて現実調停を実施する。

　これにより、図２４の鉄道網上で実際の鉄道車両事故が発生した後に、図４の仮想調停処理部１３による仮想調停処理を実施することなく現実調停を実施することが可能となる。このため、実際の鉄道車両事故の発生時から現実調停までを現実時間内に完了させることが可能となり、現実乗客および現実バス会社の双方にとって利益のある調停を実現することが可能となる。

　図２５は、図２４の駅の駅情報を示す図である。駅情報は、各駅０～９９にユニークな駅番号２４Ａ－０、駅の名称の略称２４Ａ―１、駅の経度情報２４Ａ―２、駅の緯度情報２４Ａ－３、駅に接続している路線数２４Ａ－４、路線番号と路線上の駅番号（ユニークな駅番号２４Ａ－０ではない）の組２４Ａ－５を含む。

　駅番号２４Ａ－０はプログラムによって後発的に付与される。経度情報２４Ａ―２および緯度情報２４Ａ－３は最短距離のルートの計算に用いることができる。路線数２４Ａ－４および路線番号と路線上の駅番号の組２４Ａ－５は、図２４の鉄道網をトポロジーで表現するのに用いることができる。

　図２６は、第二の実施形態に係るリソース調停サーバの仮想調停結果作成時の処理の流れを示すブロック図である。
　図２６のリソース調停サーバでは、図４の構成に加え、データ書き込み部２５―３およびデータベースＤ１が設けられている。
　そして、このリソース調停サーバは、鉄道車両停止事故２５－２が発生すると、仮想運行フェーズ４―３に移行する。鉄道車両停止事故２５－２は、実際の鉄道車両事故であってもよいし、シミュレーション上で模擬的に発生させた仮想的な鉄道車両事故であってもよい。鉄道車両停止事故２５－２は、事故の発生時刻、事故の発生場所、事故の規模および復旧までの時間などを変更して、複数の事故パターンを人為的に作成させることができる。この場合、二以上の鉄道車両停止事故２５－２を同時に発生させてもよい。

　図２６の仮想運行フェーズ４―３では、図５の仮想運行フェーズ４―３と同様の処理を行う。そして、仮想鉄道車両オブジェクト１３―４、仮想バスオブジェクト１３―５、仮想乗客オブジェクト１３―６および仮想調停部１３―７からデータ書き込み部２５―３に新交通作成情報および仮想調停後情報が出力される。さらに、鉄道車両停止事故２５－２に関する事故情報がデータ書き込み部２５―３に入力される。データ書き込み部２５―３は、新交通作成情報および仮想調停後情報を、発生条件を変更した事故の事故情報ごとにデータベースＤ１に格納する。

　図２６の仮想運行フェーズ４―３のｔ１、ｔ２、ｔ３については、図６の３つのケース（Ａ）～（Ｃ）に対応している。ただし、図２４の鉄道路線上においては、図１の鉄道路線とは異なり、鉄道車両停止事故２５－２が発生したとしても、回避ルートが作れる場合がある。
　この回避ルートについては、例えば、ダイクストラ法（最短経路問題）を用いて最短距離のルートを決定した後に、そのルートを使って到着時刻ｔ１、ｔ２、ｔ３の計算をしてもよい。鉄道車両停止事故２５－２が発生した場合、その発生した駅間の距離を、十分の大きな値としても良い（例えば９９９９．９ｋｍ）。このような対応をすることで、仮想乗客オブジェクト１３―６には、その区間を回避するルートが設定される。

　上記の駅間の距離の大きな値の影響を受けて、ダイクストラ法による経路計算結果が十分大きな値となる（例えば、１００００ｋｍを超える）場合は、目的駅に到着する手段は事実上存在しないものとして、仮想乗客を出発駅で待機させ続けてもよい。

　図２７は、図２６のデータベースに格納されている、発生条件を変化させて鉄道車両停止事故を発生させた時に生成したデータの一例を示す図である。
　図２７において、データベースＤ１には、事故情報として、事故の発生時刻２６－１、事故の発生場所２６－２および事故規模２６－３が格納されている。事故規模２６－３は、事故発生から事故が復旧するまでの時間を示している。例えば、事故の発生時刻２６－１が月曜日の１０：３５である時の事故の発生場所２６－２が“６６，２３”、事故規模２６－３が０．８５と記載される。“６６，２３”は、図２６の駅６６、２３間で事故が発生したことを示す。０．８５は、事故発生から５１分（＝６０分×０．８５）後に復旧したことを示す。

　さらに、データベースＤ１には、新交通作成情報２６－４および仮想調停後情報２６―５が格納されている。新交通作成情報２６－４は、臨時バスが提供される駅間ごとに作成することができる。仮想調停後情報２６―５は、臨時バスが提供される駅間ごとに往路と復路に分けて作成することができる。新交通作成情報２６－４および仮想調停後情報２６―５は、発生条件を変化させた時の事故情報ごとに作成することができる。新交通作成情報２６－４は新交通作成ソルバ１３－１が作成し、仮想調停後情報は仮想調停部１３－７が作成する。

　例えば、新交通作成情報２６－４の＃１において、発生時刻２６－１が火曜日の２２：１０である事故では、“８５－７、４台、Ｂ会社”と記載されている。これは、仮想調停において、Ｂ会社が駅８５、７間でバスを４台運行することに合意したという内容を示す。また、仮想調停後情報２６－５の＃１において、発生時刻２６－１が火曜日の２２：１０である事故では、“８５→７、１１人”と記載されている。これは、仮想調停において、駅８５から駅７に移動するバスに乗ることに合意した乗客の人数が１１人であることを示す。

　図２８は、第二の実施形態に係るリソース調停サーバの現実調停までの流れを示すブロック図である。
　図２８において、図２６のリソース調停サーバに類似判断部２７－５が追加されている。類似判断部２７－５は、今回の鉄道車両停止事故Ｐ１３の発生条件に類似する過去の事故情報に関連付けられた新交通作成情報および仮想調停後情報をデータベースＤ１から取得し、これらの新交通作成情報および仮想調停後情報を現実調停処理部１２に出力する。鉄道車両停止事故Ｐ１３が発生した時の現実調停は、鉄道車両停止事故Ｐ３が発生した時の現実調停と同様に実施することができる。

　現実世界の時間軸４―１上の時刻２７－２において、鉄道車両停止事故Ｐ１３が発生すると、図２８のリソース調停サーバでは、図５の仮想運行フェーズ４―３をスキップし、類似判断フェーズ４―５に移行する。類似判断フェーズ４―５では、鉄道車両停止事故Ｐ１３に関する事故情報が類似判断部２７－５に入力される。ここで、鉄道車両停止事故Ｐ１３の発生時点においては、事故の発生時刻と事故の発生場所が分かるが、事故が復旧するまでの時間は不明である。このため、類似判断部２７－５は、過去の事故情報から復旧までの時間を推測するか、あるいは、本システム外部の状況を判断できる人間２７－３または他システム２７―４等からの推測時間を類似判断部２７－５に入力してもよい。

　鉄道車両停止事故Ｐ１３に関する事故情報が類似判断部２７－５に入力されると、類似判断部２７－５は、データベースＤ１に格納されている事故情報と照合する。類似判断部２７－５は、今回の鉄道車両停止事故Ｐ１３と同程度の事故に関する情報がデータベースＤ１に格納されている場合、その事故に関する情報をデータベースＤ１から取得する。今回の鉄道車両停止事故Ｐ１３と同程度の事故の情報がデータベースＤ１に格納されていないと判断した場合、類似判断部２７－５は、今回の鉄道車両停止事故Ｐ１３に最も類似する事故に関する情報をデータベースＤ１から取得することができる。

　あるいは、類似判断部２７－５は、今回の鉄道車両停止事故Ｐ１３と同程度の事故の情報がデータベースＤ１に格納されていないと判断した場合、データベースＤ１に格納されている２以上の事故に関する情報に基づいて、今回の鉄道車両停止事故Ｐ１３に類似する事故に関する情報を生成してもよい。例えば、今回の鉄道車両停止事故Ｐ１３の発生場所の位置座標に近似している場所をデータベースＤ１から抽出し、その場所に対応した事故に関する情報から今回の鉄道車両停止事故Ｐ１３に類似した類似情報を生成してもよい。この類似情報は、データベースＤ１から抽出した新交通作成情報および仮想調停後情報に重回帰計算を行い、その係数を乗算した値の和であってもよい。

　図２９は、第二の実施形態に係る仮想調停における過去の鉄道車両事故の発生地点と、今回の鉄道車両事故を発生地点との関係の一例を示す図である。
　図２９において、過去の鉄道車両停止事故２７２－１、２７２－２、２７２－３について仮想調停が行われると、図２７に示すように、事故情報、新交通作成情報および仮想調停後情報がデータ書き込み部２５―３を介してデータベースＤ１に格納される。今回の鉄道車両停止事故２７２－０が発生すると、類似判断部２７－５は、今回の鉄道車両停止事故２７２－０と同程度の事故の情報がデータベースＤ１に格納されているかどうか判断する。今回の鉄道車両停止事故２７２－０と同程度の事故の情報がデータベースＤ１に格納されている場合、その事故の情報をデータベースＤ１から取得する。今回の鉄道車両停止事故２７２－０と同程度の事故の情報がデータベースＤ１に格納されていない場合、今回の鉄道車両停止事故２７２－０に最も類似する事故の情報をデータベースＤ１から取得することができる。

　例えば、今回の鉄道車両停止事故２７２－０の発生場所に最も近い過去の鉄道車両停止事故２７２－１の発生条件が今回の鉄道車両停止事故２７２－０の発生条件に最も類似しているものとすると、類似判断部２７－５は、鉄道車両停止事故２７２－１の新交通作成情報および仮想調停後情報をデータベースＤ１から取得する。そして、類似判断部２７－５は、鉄道車両停止事故２７２－１の新交通作成情報および仮想調停後情報を現実調停処理部１２に出力する。現実調停処理部１２は、鉄道車両停止事故２７２－１の新交通作成情報および仮想調停後情報に基づいて鉄道車両停止事故２７２－０の現実調停を実施する。

　図３０は、第二の実施形態に係るリソース調停サーバの現実調停に用いられる仮想調停結果の算出方法の一例を示す図である。なお、図３０では、図２９の今回の鉄道車両停止事故２７２－０が発生した時に、今回の鉄道車両停止事故２７２－０の周辺の過去の鉄道車両停止事故２７２－１、２７２－２、２７２－３に基づいて、鉄道車両停止事故２７２－０の新交通作成情報および仮想調停後情報を作成する場合を例にとる。
　図３０において、各鉄道車両停止事故２７２－１、２７２－２、２７２－３には、Ｋ１～Ｋ３というインデックス２７３－０が付されている。各インデックスＫ１～Ｋ３に対し、事故発生時刻２７３－２、事故継続時間２７３－３および今回の鉄道車両停止事故２７２－０の発生位置から各鉄道車両停止事故２７２－１、２７２－２、２７２－３までの事故間距離２７３－４が記入されている。事故間距離２７３－４は、バスターミナルを有する駅数に置き換えた値である。

　類似判断部２７－５は、過去の鉄道車両停止事故２７２－１、２７２－２、２７２－３の事故発生時刻２７３－２、事故継続時間２７３－３および事故間距離２７３－４と、今回の鉄道車両停止事故２７２－０の事故発生時刻、事故継続時間および事故間距離（この場合は、０となる）に基づいて、インデックスＫ１～Ｋ３ごとに重み２７３－１を算出する。重み２７３－１は、過去の鉄道車両停止事故２７２－１、２７２－２、２７２－３の発生条件と今回の鉄道車両停止事故２７２－０の発生条件が近いほど大きくする。
　類似判断部２７－５は、各インデックスＫ１～Ｋ３の重み２７３－１を新交通作成情報および仮想調停後情報に乗算し、その総計をとることで新交通作成合成情報２７３－６および仮想調停後合成情報２７３－７を算出する。図２８の現実運行フェーズ４―４では、新交通作成合成情報２７３－６および仮想調停後合成情報２７３－７に基づいて現実調停を実施する。

　以上説明したように、上述した第二の実施形態によれば、今回の事故発生前に事前に生成された仮想調停パターンの選択結果から、現実調停を行うことが可能となる。このため、調停対象の種類や数が増えた場合にも、今回の鉄道車両事故の発生から現実調停までを現実時間内に完了させることが可能となり、現実乗客および現実バス会社の双方にとって利益のある調停を実現することが可能となる。

　なお、今回の鉄道車両停止事故２７２－０が発生する前に、鉄道車両停止事故２７２－１、２７２－２、２７２－３以外の鉄道車両停止事故を模擬的に発生させ、その模擬的に発生させた鉄道車両停止事故について仮想調停を行うようにしてもよい。そして、その仮想調停における事故情報、新交通作成情報および仮想調停後情報をデータベースＤ１に格納するようにしてもよい。鉄道車両停止事故を模擬的に発生させることで、実際の鉄道車両停止事故が駅２３、６６間で発生していない場合においても、駅２３、６６間で模擬的に発生させた鉄道車両停止事故についての事故情報、新交通作成情報および仮想調停後情報をデータベースＤ１に格納することができる。このため、今回の鉄道車両停止事故２７２－０が駅２３、６６間で発生した時に、駅２３、６６間で模擬的に発生させた鉄道車両停止事故についての事故情報、新交通作成情報および仮想調停後情報に基づいて現実調停を実施することができる。

　ここで、模擬的に発生させた鉄道車両停止事故に対する仮想調停を事前に実施し、その事故に関する情報をデータベースＤ１に格納することにより、実際の鉄道車両停止事故のあらゆる事態に対応しつつ、実際の鉄道車両停止事故と同程度の事故の情報をデータベースＤ１から取得することができる。

　第三の実施形態は、第一および第二の実施形態での人身事故等による鉄道車両の不通という状況に至らないまでも、電車のダイヤ通りのサービスが十分に発揮できない状況（ラッシュ、遅延／遅着）への対応方法である。この第三の実施形態は、第一および第二の実施形態の両方で利用可能である。
　乗客は、乗車時間を短縮すべく乗車を計画する。乗車時間が乗客に負のコストとなるためである。電車の移動速度を均一であるとみなせる場合、乗車時間は電車の移動距離と等価になる。

　ラッシュ時の電車の乗車は、乗客にストレスを与えるものであるので、これも負のコストとして算出することができる。乗客のストレスを負のコストとして算出することができるならば、乗客のストレスは、乗客が利用中の電車の移動距離を増加させたものとみなすことができる。このような乗客の主観を含めた電車の移動距離のことを、以下、「心理的仮想距離」と称呼する。

　図３１（ａ）は、ラッシュ時における心理的仮想距離の算出方法を示すフローチャートである。図３１（ａ）の処理では、図６における到着時刻ｔ２、ｔ３の算出時に、人間の心理を反映させて、仮想乗客オブジェクト１３―６の移動経路の変更を施す。
　図３１（ａ）において、ステップ２８－１では、仮想鉄道車両オブジェクト１３―４を使って、各駅間における鉄道車両の乗車率を算出する。この乗車率は、その時点における各駅間の複数の運行中の仮想鉄道車両オブジェクト１３―４の平均値を用いてもよい。

　次に、ステップ２８－２では、各駅間の混雑率に対する心理的仮想距離の係数を算出する。この係数ＫＡの算出には、例えば、ＫＡ＝ｍａｘ（１，２（ｘ－１））（ｘ：混雑率）という式を用いることができる。この式では、乗車率１５０％以下ではＫＡ＝１となり、混雑率２５０％の時にはＫＡ＝３となる。
　次に、ステップ２８－３では、駅間の現実の距離に、ステップ２８－２で算出した係数ＫＡを乗算することで心理的仮想距離を算出する。次に、ステップ２８－４では、例えば、ダイクストラ法を用いることにより、心理的仮想距離が反映されたルートの再計算を実施する。交通運行予測シミュレータ１３―２は、この再計算されたルートに基づいて、各仮想乗客オブジェクト１３―６の到着時刻ｔ２、ｔ３を予測する。仮想乗客オブジェクト１３―６は、この到着時刻ｔ２、ｔ３の予測に基づき、仮想の臨時バスに該当する仮想バスオブジェクト１３―５の利用、不利用または利用する場合の料金を提示する。

　また、ラッシュ、車両内での乗客どうしのトラブル、嘔吐等による駅停車時間の増大は、乗客の到着時間に影響を与える。これも乗客の負のコストとして算出することができる。到着時間の遅延を負のコストとして算出することができるならば、到着時間の遅延は、乗客が利用中の電車の移動距離を増加させたものとみなすことができる。このような到着時間の遅延がなかった時に電車が本来移動できる移動距離のことを、以下、「遅延的仮想距離」と称呼する。

　図３１（ｂ）は、電車遅延時における遅延的仮想距離の算出方法を示すフローチャートである。図３１（ｂ）の処理では、図６における到着時刻ｔ２、ｔ３の算出時に、駅のある鉄道車両の長時間の停車と、他の鉄道車両の閉塞区間の制限によって、電車の停車の連鎖を反映させて、仮想乗客オブジェクト１３―６の移動経路の変更を施す。
　図３１（ｂ）において、ステップ２８―１１では、電車と駅を指定して停車時間を入力する。次に、ステップ２８－１２では、閉塞区間による他の電車運行ダイヤへの影響を計算する。
　次に、ステップ２８―１３は、これらの電車の遅延による駅間の心理的仮想距離の係数を算出する。この係数は、これらの電車の遅延による駅間の通過時間の遅延の比率とすることができる。この係数ＫＢの算出には、例えば、ＫＢ＝（遅延発生中の駅間の平均移動時間）／（遅延が発生してない時の駅間の平均移動時間）という式を用いることができる。（遅延発生中の駅間の平均移動時間）および（遅延が発生してない時の駅間の平均移動時間）は仮想鉄道車両オブジェクト１３―４を用いて算出することができる。
　次に、２８－１４では、駅間の現実の距離に、ステップ２８－１３で算出した係数ＫＢを乗算することで遅延的仮想距離を算出する。次に、ステップ２８－１５で、例えば、ダイクストラ法を用いることにより、遅延的仮想距離が反映されたルートの再計算を実施する。交通運行予測シミュレータ１３―２は、この再計算されたルートに基づいて、各仮想乗客オブジェクト１３―６の到着時刻ｔ２、ｔ３を予測する。仮想乗客オブジェクト１３―６は、この到着時刻ｔ２、ｔ３の予測に基づき、仮想の臨時バスに該当する仮想バスオブジェクト１３―５の利用、不利用または利用する場合の料金を提示する。

１…リソース調停サーバ、２…鉄道運行サーバ、３…バス運行サーバ、１―０１…ＣＰＵ、１―０２…メモリ、１―０３…通信ＮＩＣ、１―０４…ハードディスクドライブ、１―０５…入出力コントローラ、１―０６…モニタコントローラ、１―０７…バス、１―０８…ＧＰＳモジュール、１―１１…キーボード、１―１２…マウス、１―１３…ディスプレイ、１３―１…新交通生成計画ソルバ、１３―２…交通運行予測シミュレータ、１３―３…調停係数補正部、１３―４…仮想鉄道車両オブジェクト、１３―５…仮想バスオブジェクト、１３―６…仮想乗客オブジェクト、１３―７…仮想調停部、１２―１…鉄道運行リソース情報、１２―２…バス運行リソース情報、１２―３…乗客リソース情報、１２―４…現実調停部、１２―５…現実調停メッセージ作成部、１１―１…メッセージ受信部、１１―２…メッセージ送信部、２０―１…リソース情報提供部、２０―２…メッセージ送信部、２０―３…メッセージ受信部、２１―１…調停メッセージ作成部、２１―２…調停メッセージ解析部、２１―３…リソース調停部、２２―１…調停メッセージ入力部、２２―２…調停メッセージ表示部

Claims (19)

1. 　第１リソースの需給状態に基づいて第２リソースの提供条件と利用条件を設定し、前記提供条件と前記利用条件に基づいて前記第２リソースの需要と供給の調停を行う第１サーバと、
   　前記第１サーバから送られた前記第２リソースの提供条件を評価する第２サーバと、
   　前記第１サーバから送られた前記第２リソースの利用条件を評価する情報端末とを備えるリソース調停システム。
2. 　前記第２リソースの提供条件の評価は、前記第２リソースの提供の可否と料金の評価であり、
   　前記第２リソースの利用条件の評価は、前記第２リソースの利用の可否と料金の評価である請求項１に記載のリソース調停システム。
3. 　前記第１サーバは、
   　前記第１リソースの需給状態に基づいて前記第２リソースの利用条件と提供条件を仮想的に設定し、前記第２リソースの利用条件と提供条件に基づいて前記第２リソースの需要と供給の仮想的な調停を行う仮想調停処理部と、
   　前記仮想的な調停結果に基づいて、前記第２リソースの需要と供給の現実的な調停を行う現実調停処理部とを備える請求項１に記載のリソース調停システム。
4. 　前記現実調停処理部は、前記仮想的な調停が不調の場合、前記現実的な調停を行わない請求項３に記載のリソース調停システム。
5. 　前記仮想調停処理部は、前記現実的な調停に失敗した場合、前記提供条件と前記利用条件を変更する請求項３に記載のリソース調停システム。
6. 　前記仮想調停処理部は、Ｎ（Ｎは２以上の整数）個の異なる提供条件と利用条件をそれぞれ設定し、前記Ｎ個の異なる提供条件と利用条件に基づいて仮想的な調停を行う請求項３に記載のリソース調停システム。
7. 　前記仮想調停処理部は、前記第２リソースを利用した時の利益を算出し、前記利益に基づいて前記提供条件と前記利用条件を仮想的に設定する請求項３に記載のリソース調停システム。
8. 　前記仮想調停処理部は、
   　前記第１リソースの運用予測と前記第２リソースの運用予測を行う予測シミュレータと、
   　前記第１リソースの運用予測結果と前記第２リソースの運用予測結果に基づいて、前記第２リソースの利用条件を評価する第１仮想オブジェクトと、
   　前記第２リソースの運用予測結果に基づいて、前記第２リソースの提供条件を評価する第２仮想オブジェクトと、
   　前記第１仮想オブジェクトと前記第２仮想オブジェクトとの間で仮想的な調停を行う仮想調停部とを備える請求項３に記載のリソース調停システム。
9. 　前記第１リソースは鉄道、前記第２リソースはバスであり、
   　前記第１サーバは、
   　鉄道車両事故の被害規模に基づいて、前記鉄道車両事故がない場合の第１到着時刻、前記鉄道車両事故の復旧後の第２到着時刻および前記鉄道車両事故の復旧前に前記バスを利用した場合の第３到着時刻を予測し、
   　前記第１到着時刻、前記第２到着時刻および前記第３到着時刻の予測情報に基づいて、乗客に前記バスの利用条件を提示するとともに、バス会社に前記バスの提供条件を提示し、前記乗客と前記バス会社の間で臨時バスの台数および料金を調停する請求項１に記載のリソース調停システム。
10. 　前記第１リソースは鉄道、前記第２リソースはバスであり、
    　前記仮想調停処理部は、
    　移動中の鉄道車両の位置を決定する仮想鉄道車両オブジェクトと、
    　前記仮想鉄道車両オブジェクトの運行予測を行う交通運行予測シミュレータと、
    　バス会社の臨時バスの提供、不提供または提供する場合の料金を決定する仮想バスオブジェクトと、
    　乗客の臨時バスの利用、不利用または利用する場合の料金を決定する仮想乗客オブジェクトと、
    　前記仮想バスオブジェクトの配置および運行計画を立案する新交通生成計画ソルバと、
    　前記仮想乗客オブジェクトと前記仮想バスオブジェクトの間で仮想調停を行う仮想調停部とを備える請求項３に記載のリソース調停システム。
11. 　第１リソースの需給状態に基づいて第２リソースの利用条件と提供条件を仮想的に設定し、前記第２リソースの利用条件と提供条件に基づいて前記第２リソースの需要と供給の仮想的な調停を行う仮想調停処理部と、
    　前記仮想的な調停結果に基づいて、前記第２リソースの需要と供給の現実的な調停を行う現実調停処理部とを備えるリソース調停装置。
12. 　前記仮想調停処理部は、
    　前記第１リソースの運用予測と前記第２リソースの運用予測を行う予測シミュレータと、
    　前記第１リソースの運用予測結果と前記第２リソースの運用予測結果に基づいて、前記第２リソースの利用条件を評価する第１仮想オブジェクトと、
    　前記第２リソースの運用予測結果に基づいて、前記第２リソースの提供条件を評価する第２仮想オブジェクトと、
    　前記第１仮想オブジェクトの評価結果と前記第２仮想オブジェクトの評価結果に基づいて、前記第１仮想オブジェクトと前記第２仮想オブジェクトとの間で仮想的な調停を行う仮想調停部とを備える請求項１１に記載のリソース調停装置。
13. 　前記仮想調停処理部は、前記第２リソースの利用条件と提供条件が折り合うように前記仮想的な調停を繰り返し、
    　前記現実調停処理部は、前記仮想調停で得られた前記第２リソースの利用条件と提供条件を受け入れるかどうかの判断のみに基づいて現実的な調停を行う請求項１１に記載のリソース調停装置。
14. 　前記第１リソースは鉄道、前記第２リソースはバスであり、
    　前記仮想調停処理部は、
    　鉄道車両事故の被害規模に基づいて、前記鉄道車両事故がない場合の第１到着時刻、前記鉄道車両事故の復旧後の第２到着時刻および前記鉄道車両事故の復旧前に前記バスを利用した場合の第３到着時刻を予測し、
    　前記第１到着時刻、前記第２到着時刻および前記第３到着時刻の予測情報に基づいて、乗客に前記バスの利用条件を提示するとともに、バス会社に前記バスの提供条件を提示し、前記乗客と前記バス会社の間で臨時バスの台数および料金を調停する請求項１１に記載のリソース調停装置。
15. 　前記第１リソースは鉄道、前記第２リソースはバスであり、
    　前記仮想調停処理部は、
    　移動中の鉄道車両の位置を決定する仮想鉄道車両オブジェクトと、
    　前記仮想鉄道車両オブジェクトの運行予測を行う交通運行予測シミュレータと、
    　バス会社の臨時バスの提供、不提供または提供する場合の料金を決定する仮想バスオブジェクトと、
    　乗客の臨時バスの利用、不利用または利用する場合の料金を決定する仮想乗客オブジェクトと、
    　前記仮想バスオブジェクトの配置および運行計画を立案する新交通生成計画ソルバと、
    　前記仮想乗客オブジェクトと前記仮想バスオブジェクトの間で仮想調停を行う仮想調停部とを備える請求項１１に記載のリソース調停装置。
16. 　前記仮想調停処理部による過去の仮想的な調停結果を記憶する記憶部をさらに備え、
    　前記記憶部から検索された過去の仮想的な調停結果を、前記現実調停処理部による前記現実的な調停に用いる請求項１１に記載のリソース調停装置。
17. 　前記仮想調停処理部による過去の仮想的な調停結果を前記鉄道車両事故の事故情報と対応付けて記憶する記憶部と、
    　今回の鉄道車両事故の事故情報と類似する事故情報に対応付けられた過去の仮想的な調停結果を前記記憶部から取得し、前記現実調停処理部に出力する類似判断部をさらに備え、
    　前記現実調停処理部は、前記類似判断部から出力された過去の仮想的な調停結果に基づいて、前記第２リソースの需要と供給の現実的な調停を行う請求項１４に記載のリソース調停装置。
18. 　駅間の混雑率が前記駅間の現実の距離に反映された仮想距離を算出し、
    　前記仮想距離に基づいて前記第２到着時刻および前記第３到着時刻を予測する請求項１４に記載のリソース調停装置。
19. 　電車の遅延時間が前記駅間の現実の距離に反映された仮想距離を算出し、
    　前記仮想距離に基づいて前記第２到着時刻および前記第３到着時刻を予測する請求項１４に記載のリソース調停装置。

Images