JP6752435B2 - 交通システム、ダイヤ提案システム及び列車運行システム - Google Patents

Description

本発明は、乗客需要の増減に応じて列車本数を動的に調整する交通システム、ダイヤ提案システム及び列車運行システムに関する。

鉄道輸送サービスに代表される公共交通機関の快適度の大きな要因として車両の混雑度がある。列車の乗車率が増加すると、停車駅における乗客の乗り降りにも時間がかかり、周辺の列車の運行ダイヤにも乱れを発生させ、予定どおりの運行を実施できなくなってしまう。

このような状況に対処することを検討した先行技術として特許文献１がある。特許文献１では、列車運行管理業務を担当する指令員が輸送力増を指示した場合に、線区内の在線列車数や出庫可能本数など車両手配を考慮して、新しくダイヤを作成する技術を開示している。また、特許文献２および特許文献３では、駅内の利用客の増減と流れを検知し、車両の発車時刻を調整する技術を開示している。

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

特許文献１の方法では輸送力増強の指示は指令員が行う。このため、輸送力増強も個人の判断に頼らざるを得ず、輸送力増強に関してきめ細かな判定が難しい。一方、特許文献２および３の方法はあくまで列車の発車時刻を調整であって、列車本数の増減を行うものではない。さらに、これらはいずれも混雑の緩和に着目した文献であるが、一方で公共交通機関が過剰な輸送力を提供している可能性もある。乗客に不便を感じさせない程度に車両本数を間引くことができれば、サービスコストの低減につながり、ひいては乗客の満足度の向上が期待できる。

このため、駅における乗客に関する情報を常時収集し、乗客の移動需要をリアルタイムに予測して、移動需要の増減に対応した列車運行本数の増減できる交通システムを提供する。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、列車を複数の駅を有する路線で運行する交通システムであって、路線のダイヤを決定するダイヤ計画システムと、路線のダイヤの変更を提案するダイヤ提案システムとを有し、ダイヤ提案システムは、複数の駅で収集される、乗客に関する情報を格納するデータサーバと、移動需要予測プログラム、列車待ち乗客数予測プログラム及び列車本数増減判定プログラムを格納する計算サーバとを有し、データサーバは、所定の日付の所定の時間帯に複数の駅に含まれる第１の駅に入場し、複数の駅に含まれ第１の駅とは異なる第２の駅から出場する乗客数の情報を蓄積し、計算サーバは、それぞれあらかじめ定められた時間間隔で移動需要予測プログラム、列車待ち乗客数予測プログラム及び列車本数増減判定プログラムを実行し、移動需要予測プログラムは、データサーバに蓄積された過去の所定の日付の所定の時間帯に第１の駅に入場し、第２の駅から出場する乗客数の情報に基づいて、当日の所定の時間帯において第１の駅に入場し、第２の駅から出場する乗客数を予測し、列車待ち乗客数予測プログラムは、移動需要予測プログラムにより予測された乗客数に基づいて当日の所定の時間帯における複数の駅における列車待ち乗客数を予測し、列車本数増減判定プログラムは、当日の所定の時間帯における複数の駅における列車待ち乗客数に基づいて当日の所定の時間帯における列車本数の増減の要否を判定し、ダイヤ計画システムは、当日の所定の時間帯におけるダイヤをダイヤ提案システムにおける列車本数の増減要否判定に基づき列車本数を増減したダイヤに更新する。

乗客の移動需要に合わせて列車本数増減をきめ細かく実行できる交通システムが実現できる。

本実施例のシステム構成を示す図である。 データサーバ１１１のデータ格納部１５０に格納されるデータを示す図である。 計算サーバ１１２の記憶部１６０に格納されるプログラムを示す図である。 本実施例を適用する鉄道の路線図の例である。 マスタ情報１５６のデータ構造を示す図である。 列車位置情報１５３のデータ構造を示す図である。 列車状態情報１５４のデータ構造を示す図である。 列車待ち乗客数情報１５１のデータ構造を示す図である。 列車乗車人数情報１５２のデータ構造を示す図である。 移動需要情報１５５のデータ構造を示す図である。 移動需要予測プログラム４００のフローチャートである。 列車待ち乗客数の予測結果のデータ構造を示す図である。 混雑基準値幅情報１５７のデータ構造を示す図である。 列車本数増減判定プログラム４４０のフローチャートである。 列車本数増減判定結果１５８のデータ構造を示す図である。 提案ダイヤ作成プログラム４６０のフローチャートである。 更新ダイヤ情報１５９のデータ構造を示す図である。 効果分析プログラム４８０のフローチャートである。 情報配信サーバ１１３が配信する画面の一例を示す図である。 情報配信サーバ１１３が配信する画面の一例を示す図である。 情報配信サーバ１１３が配信する画面の一例を示す図である。 情報配信サーバ１１３が配信する画面の一例を示す図である。

図１から図２１を用いて、本発明の実施例を説明する。なお、本実施例は、鉄道輸送サービスを対象としているが、車両を複数の駅（停留所）を有する所定の路線で運行し、不特定多数人が利用可能な交通システムに好適なものである。例えば、複数の停留所を経由する路線バス等にも適用可能である。

図１に鉄道輸送サービスを例に、本実施例である交通システムの構成を示す。近年、多くの鉄道の駅には自動改札機１０３が設置されており、自動改札機１０３が非接触型ＩＣカード（または、同等の機能を持つモバイル端末）または磁気乗車券を読み取ることによって、利用者１０２は駅へ入場、または出場することができる。自動改札機１０３が読み取った情報は、ネットワーク１０９を介して、鉄道事業者が管理するデータ管理サーバ群１０６へ送信され、改札通過データとして蓄積される。改札通過データには、各乗客が列車を利用するために入場した駅と時刻、降車した駅と時刻等の情報が含まれる。

また、改札付近やプラットホームに監視カメラ１０４が設置されることも多い。一台の監視カメラで撮影できる空間的な範囲は限られているため、一つの駅に改札付近、各プラットホーム、通路、階段など複数台の監視カメラを設置されることが一般的である。監視カメラ１０４が取得した映像データは、鉄道の運行を管理する指令所などで、ネットワーク１０９を介してリアルタイムに映像を確認できる。監視カメラ１０４で撮影した映像から人物を検知し、ある空間に存在している人数を集計する技術も開発されている。

また、駅や列車内で利用可能な公衆無線ＬＡＮの普及に伴い、アクセスポイント１０５が各所に設置されるようになってきている。なお、ここで公衆無線ＬＡＮは鉄道事業者以外の事業者が提供するものであってもよい。公衆無線ＬＡＮとは、無線ＬＡＮによりインターネットへの接続を提供するサービスであり、利用者１０２はノートＰＣ、タブレットＰＣ、スマートフォンなどのモバイル端末からアクセスポイント１０５を介してインターネット接続する。一つのアクセスポイントから電波が到達可能な範囲は、一般的に数十メール程度であるため、駅などの広い空間では複数のアクセスポイントが設置される。モバイル端末が複数のアクセスポイント１０５と交信可能な場合に混信が生じるのを防ぐため、ネットワークを識別するＳＳＩＤによって通信を行う。このため、アクセスポイント１０５側では各モバイル端末の接続開始時刻及び接続終了時刻を取得することができる。

一般的に駅構内に設置されるアクセスポイント１０５は改札付近やプラットホームに複数設置されているので、各アクセスポイント１０５と利用者１０２のモバイル端末との間の電波強度からモバイル端末の位置を大まかに推定できる。あるいは、各モバイル端末が接続しているアクセスポイント１０５を時系列に追跡することで、駅構内における乗客の移動も推定できる。他にも、利用者１０２が、あらかじめモバイル端末の識別子であるＭＡＣアドレス等を登録することによって利用できる公衆無線ＬＡＮサービスを利用している場合には、当該モバイル端末の移動履歴を無線ＬＡＮの接続データから取得できる。これらの駅構内に設置されたアクセスポイント１０５の接続情報はデータ管理サーバ群１０６にリアルタイムに送信される。

本実施例では、自動改札機１０３、監視カメラ１０４、アクセスポイント１０５からの情報に基づき、後述するように駅の利用者１０２の数、さらに各利用者１０２が利用する路線等を推定する。推定方法はこれらの機器を利用するものに限定はされず、またこれらの機器のすべてを利用しなければならないものでもないが、既存の駅の設備を活用できる可能性が高く、多額の設備投資の必要なく実施することができるものである。

列車１０１は鉄道事業者の保有する列車運行システム１３０に基づき運用されている。列車運行システム１３０は、サブシステムとしてダイヤ計画システム１３１、運行管理システム１３２、列車情報管理システム１３３を有する。ダイヤ計画システム１３１は列車１０１のダイヤを作成する。運行管理システム１３２は、ダイヤ計画システム１３１で作成されたダイヤ通りに列車１０１が運行されているかを管理する。列車情報管理システム１３３は運行中の列車１０１から様々な情報を取得・収集して乗務員や運行管理センタ１２６に情報を伝送するシステムである。列車情報管理システム１３３を活用すると、列車の位置や列車番号、列車の故障情報などが各列車から送信され、運行管理センタ１２６に集約することができる。列車１０１にはブレーキング強弱の調整のために、列車の重量を測定できるセンサが取り付けられている。列車重量の計測値を収集し、乗客一人当たりの平均体重から列車１０１の乗車人員情報を推定することができる。

動的列車運行ダイヤ提案システム１１０は、鉄道事業者が鉄道管理システムの一部として保有してもよいし、鉄道事業者とは異なるサービス事業者が保有して列車運行ダイヤ提案を鉄道事業者に対して行う事業形態であってもよい。動的列車運行ダイヤ提案システム１１０はデータサーバ１１１、計算サーバ１１２及び情報配信サーバ１１３を有している。各サーバはネットワーク１２０を介してシステム運用者（システム１１０を鉄道事業者が保有している場合には鉄道事業者）１２１が使用する計算機１２２と通信可能に接続されている。また、動的列車運行ダイヤ提案システム１１０はネットワーク１２４を介して運行管理センタ１２６、乗客等１２７が使用する端末１２８と通信できる。

以下、動的列車運行ダイヤ提案システム１１０を構成するサーバについて説明する。なお、本実施例では３つのサーバ群として説明するが、物理的に一つの計算機、または、論理的あるいは物理的に構成された複数の計算機上で構成される計算機システムとして構成でき、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。

各サーバの基本構成は同一であり、ネットワークインタフェース（Ｉ／Ｆ）１７０、プロセッサ（ＣＰＵ）１７１、メモリ１７２及び記憶部１６０を有する計算機である。ネットワークインタフェース１７０は、ネットワーク１０９、１２０に接続するためのインタフェースである。プロセッサ１７１は、メモリ１７２に格納されたプログラムを実行する。メモリ１７２は、不揮発性の記憶素子であるＲＯＭ（Read Only Memory）と揮発性の記憶素子であるＲＡＭ（Random Access Memory）とを含む。ＲＯＭには不変のプログラム、例えば、ＢＩＯＳ（Basic Input Output System）などを格納する。また、ＲＡＭは、ＤＲＡＭ（Dynamic Random Access Memory）のような高速かつ揮発性の記憶素子であり、プロセッサ１７１が実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。記憶部１６０は、例えば、磁気記憶装置（ＨＤＤ（Hard Disc Drive））、フラッシュメモリ（ＳＳＤ（Solid State Drive））、光学ドライブ等の大容量かつ不揮発性の記憶装置によって構成され、プロセッサ１７１が実行するプログラム及びプログラムの実行時に使用されるデータを格納する。なお、記憶部として複数の記録装置を設け、プログラムやデータを複数の記録装置に分割して記録してもよい。

また、各サーバは、キーボードやマウスなどが接続され、オペレータからの入力を受ける入力インタフェース及び、ディスプレイ装置やプリンタなどが接続され、プログラムの実行結果をオペレータが視認可能な形式で出力する出力インタフェースを有してもよい。また、各サーバが実行するプログラムは、ネットワークまたはリムーバブルメディア（光ディスク、フラッシュメモリなど）介して各サーバに提供される。このため、各サーバは、リムーバブルメディアからデータを読み込むインタフェースを有するとよい。

まず、データサーバ１１１について説明する。駅構内の施設（１０３，１０４）やアクセスポイント１０５からの情報、列車情報管理システム１３３からの列車乗車人数情報などは、新たなデータを取得したタイミング、または所定の時間間隔（列車間隔に応じて数分おき、数時間おきなど）で、ネットワーク１０９を介して、データサーバ１１１へ送信される。データサーバ１１１は、受信したデータを記憶部１６０ａのデータ格納部（ＤＢ）１５０に記録する。図２Ａに示すように、データ格納部１５０には、列車待ち乗客数情報１５１、列車乗車人数情報１５２、列車位置情報１５３、列車状態情報１５４、移動需要情報１５５、駅や路線の構造を表すマスタ情報１５６、混雑しきい値幅情報１５７、列車本数増減判定結果１５８、更新ダイヤ情報１５９を格納する。これらのデータの詳細については後述する。

次に、計算サーバ１１２は、データサーバ１１１に蓄積されたデータ群を用いて、列車本数の増減提案を行うための演算処理を実行する。図２Ｂに示すように、記憶部１６０ｂは移動需要予測プログラム４００、列車待ち乗客数予測プログラム４２０、列車本数増減判定プログラム４４０、提案ダイヤ作成プログラム４６０、効果分析プログラム４８０及び計算処理の過程で生成される中間データが格納される。プログラムは記憶部１６０ｂから読み出され、メモリ１７２ｂにロードされて、プロセッサ１７１ｂによって実行される。分析対象のデータはデータサーバ１１１から取得されて、メモリ１７２ｂに一時的に格納され、プロセッサ１７１ｂがプログラムを記憶部１６０ｂから読み出して実行する。これらプログラムは、予め定められた時間間隔（例えば、数秒おき、数分おきなど）に従って自動的に実行してもよいし、システム運用者１２１が指示したタイミングで実行してもよい。また、予め定めた時間間隔は時間帯によって時間間隔を異ならせるものであってもよい。これらのプログラムの詳細については後述する。

次に、情報配信サーバ１１３はその記憶部１６０ｃに情報配信プログラム１４１などのプログラムと、計算処理の過程で生成される中間データを格納する。情報配信サーバ１１３は、システム管理者１２１、運行管理センタ１２６または乗客１２７が使用する端末１２８からネットワーク１２０、１２４を介してアクセスされ、情報を提供する。

動的列車運行ダイヤ提案システム１１０のシステム運用者１２１は、端末１２２からネットワーク１２０を介して、動的列車運行ダイヤ提案システム１１０に蓄積されたデータの構成や状況、計算サーバ１１２の状況や計算結果、利用者からの検索リクエスト状況などを確認することができる。

図３の路線図として示される鉄道を例として、本実施例にかかる運行ダイヤ提案システムについて説明する。

図４はデータサーバ１１１に格納されるマスタ情報１５６のデータ構造を示す図である。マスタ情報１５６には、システムを適用する鉄道の路線情報とダイヤ情報が含まれる。

路線・駅情報２４０は、路線ＩＤ２４１、路線・方面の名称２４２、駅ＩＤ２４３、駅における番線情報２４４、区間情報２４５などの情報を含み、路線の構造を表す。本例では路線ＩＤ「01」は「Ｌ１路線上り９０１」を示し、路線ＩＤ「02」は「Ｌ１路線 下り９０２」を示す。また、駅Ｓ０１は区間Ｌ１−Ａ１に属し、またＬ１路線上りは駅Ｓ０１の１番線であることが読み取れる。路線を構成する駅は、基本的に実際の並び順に従って格納される。

本線合流時間情報２５０は退避場所情報２５１、合流駅２５２、路線・方面の名称２５３、列車状態２５４と合流までの所要時間２５５などの情報を含む。例えば、第１留置線９０６は駅Ｓ０２においてＬ１路線上り９０１に合流するよう設けられており、スタンバイ状態で留置された列車がＬ１路線上りに合流するまでに１０分を要することが読み取れる。あるいはデポ（車両基地）９０７の１番線にスタンバイ状態で留置された列車が駅Ｓ０６においてＬ１路線下り９０２に合流するまでに８分を要することが読み取れる。これらは列車を増発する場合に必要な情報である。

折返し設備情報２６０は路線ＩＤ２６１、路線・方面の名称２６２、駅ＩＤ２６３などの情報を含む。Ｌ１路線上り９０１では駅Ｓ０１と駅Ｓ０３にそれぞれ折返し設備９０８，９０９が設けられていることが読み取れる。折返し設備は上り線（下り線）の列車を下り線（上り線）に導入するための設備である。後述するように、本実施例では路線をいくつかの区間（路線・駅情報２４０の区間情報２４５を参照）に区切って混雑状況を分析する。区間の設定はシステム運用者に任されるが、折返し設備情報２６０に基づき、折返し区間をそのまま区間として設定することができる。折返し設備のない駅では列車数の増減の起点とすることができないためである。以上は、固定的な情報であるが、路線や駅の設備情報が変更された場合には、システム運用者により更新がなされる。

列車計画時刻表２７０は、駅ＩＤ２７１、列車番号２７２、番線情報２７３、日付２７４、列車到着時刻２７５、列車出発時刻２７６などの情報を含む。例えば、2016年５月１日の列車運行計画では、列車Ａ０１が駅Ｓ０１の１番線に７時に到着し、７時０分30秒に出発し、さらに、駅Ｓ０１の１番線に７時５分30秒に到着し、７時６分に出発することが読み取れる。列車計画時刻表２７０は、列車運行システム１３０のダイヤ計画システム１３１から随時データを受信するたびに更新される。

図５はデータサーバ１１１に格納される列車位置情報１５３のデータ構造を示す図である。列車位置情報１５３は列車番号２２１、路線・方面の名称２２２、日付２２３、時刻２２４、走行中の駅情報２２５、２２６などの情報を含む。列車位置情報は列車が当該時点にどこにいるかを示すものであり、運行管理システム１３２もしくは列車情報管理システム１３３から、各列車の情報を受信して得られる。列車が走行中の場合は、駅１と駅２にはその前後の駅ＩＤが登録されており、列車が停車中の場合は、駅１と駅２には当該駅の駅ＩＤが登録されている。もちろん、各列車がどの位置を走行しているかという情報が含まれていればよいので、レコード構造は図５に示した構造に限定するものではない。

図６はデータサーバ１１１内に格納される列車状態情報１５４のデータ構造を示す図である。列車状態情報１５４は列車番号２３１、在線場所２３２、列車状態２３３などの情報を含む。例えば、列車Ｔ０１が第１留置線９０６にスタンバイ状態で在線していることが読み取れる。列車が在線している場所および列車の状態は、列車運行システム１３０の運行管理システム１３２のもしくは列車情報管理システム１３３の在線監視機能により把握される。

図７はデータサーバ１１１内に格納される列車待ち乗客数情報１５１のデータ構造を示す図である。列車待ち乗客数情報１５１は、駅ＩＤ２０１、番線情報２０２、日付２０３、時刻２０４、待ち乗客数２０５などの情報を含む。待ち乗客数には、１分毎、５分毎、１０分毎などあらかじめ決められた時間単位に従って集計された値が格納される。待ち乗客数は駅構内に設置された設備からの情報を用いて推定する。

例えば、この推定には公衆無線ＬＡＮのアクセスポイント１０５への接続情報を用いることができる。プラットホーム毎にアクセスポイントが設置されていればその接続数を求める。１つのプラットホームに複数のアクセスポイントが存在する場合は、接続数の集計値を求めればよく、また１つのプラットホームに２つの番線が向かい合って配置されている場合は、接続数を番線毎に分解すればよい。分解には、複数のアクセスポイントからの通信強度を用いて、各端末がプラットホーム上のどの位置にいるかを推定してもよいし、監視カメラ１０４の映像を用いて番線毎におおよその滞留人数を検知するなどの方法が考えられる。また、駅を利用する全乗客が公衆無線ＬＡＮ利用者ではないため、あらかじめ「全乗客数/公衆無線ＬＡＮ利用者数」の比率を求めておき、補正を行う。比率の設定には、アンケート調査を実施してもよいし、自動改札機１０３から得られる、所定時間内に自動改札機１０３を通過した乗客数と、各モバイル端末が接続しているアクセスポイントを時系列に追跡することで得られる乗客の移動から推定できる当該自動改札機１０３を通過した乗客数とを比較して定めてもよい。

また、駅構内に設置されている監視カメラ１０４の映像を用いて、画像処理により人物検知を行い、番線毎に列車を待っている乗客の数を集計することで待ち乗客数を求めてもよい。または、自動改札機１０３から得られる改札通過データを用いて、各乗客の入出場駅情報から、その人が利用したであろう路線および列車を推定し、駅ごと・番線ごとに集計する方法で生成してもよい。路線と駅のネットワーク情報や、列車の計画ダイヤデータを用いて経路探索問題を解くことで、任意の出発駅・到着駅の組み合わせに対して、利用する経路や列車、駅で列車を待った時間や、到着までの総所要時間を計算することができる。この計算処理を全乗客の移動に関して実施した結果を駅ごと・番線ごとに集計することで、任意の駅および任意の番線の列車待ち乗客数を求めることができる。さらに、監視カメラ映像が設置されている駅と、設置されていない駅などが混在するような路線においては、これらの手法を組み合わせて利用することが効果的である。なお、上記以外にも赤外線センサなどの計測手段を用いても良い。

図８はデータサーバ１１１内に格納される列車乗車人数情報１５２のデータ構造を示す図である。列車乗車人数情報１５２は列車番号２１１、路線・方面の名称２１２、日付２１３、時刻２１４、列車乗車人員２１５、列車定員２１６などの情報を含む。列車乗車人数２１５は前述したように、列車に取り付けられた重量センサの値を用いて推定することができる。または列車のドア付近にカメラや赤外線センサなどの計測手段を取り付けておき、列車の乗降人数をカウントすることで求めてもよい。または列車内に公衆無線ＬＡＮのアクセスポイントが設けられている場合には、駅のプラットホームでの列車待ち乗客数を推定したのと同様に列車内の乗車人数を求めてもよく、改札通過データを用いて、前述した列車待ち乗客数を推定したのと同様に全乗客の利用経路および利用した列車を推定して集計してもよい。
図９はデータサーバ１１１内に格納される移動需要情報１５５のデータ構造を示す図である。移動需要とは、所定の日付・時間帯において駅βを目的地として駅αに入場する人数と定義される。移動需要情報１５５は日付３０１、時間帯３０２、入場駅ＩＤ３０３、出場駅ＩＤ３０４、人数３０５などの情報を含む。時間帯は5分毎、10分毎、15分毎、30分毎などあらかじめ設定しておいた時間間隔に従って格納される。また、路線に含まれるすべての駅についての入場駅、出場駅の組み合わせを含むことが望ましいが、路線に含まれる主要駅（少なくとも各区間から１駅は含まれるように選択する）についての入場駅、出場駅の組み合わせを含むとしてもよい。移動需要情報１５５は改札通過データを用いて、ある所定時間帯に駅Ａに入場した乗客がどの駅で降車したか利用人数を集計することで算出される。図では、７時から７時15分の間に駅Ｓ０１に入場した乗客のうち、駅Ｓ０２を出場した乗客が20人、駅Ｓ０３を出場した乗客が30人であることが示されている。移動需要情報１５５の更新は、予め定められた時間間隔（例えば、数秒おき、数分おきなど）に従って自動的に実行してもよいし、データサーバ１１１が新しく改札通過データを受信するタイミングで実行してもよい。

図１０は移動需要予測プログラム４００のフローチャートである。移動需要予測プログラム４００はデータサーバ１１１に継続的に蓄積されたデータに基づき、当日どの駅に向かう乗客がいつ頃当該駅に入場するかを推定することにより、番線ごとに当日の列車待ち乗客数の時系列変化を推定するものである。もちろん、大雑把な列車待ち乗客数の増減傾向は過去のデータを使わなくても推定可能であろうが、乗客数は実際には天候や周囲の交通状況を受けても変化する。通勤・通学時間帯のような乗客数の増減に影響を与える因果関係のみならず、不規則に生じる事象による乗客数の変動を織り込んで、きめ細かく精度の高い列車待ち乗客数の推定を行うため、本実施例では過去のデータから類似度の高い日の移動需要情報を用いて、列車に乗る乗客数をシミュレーションすることにより、列車待ち乗客数を予測するものである。

移動需要予測プログラム４００は5分、10分、30分などあらかじめ定められた時間間隔で自動的に実行されるか、またはシステム運用者から指示されたタイミングで実行されるものとする。また、移動需要の変動の程度も時間帯に影響を受けると考えられるため、時間帯によって異なる時間間隔として設定してもよい。まず、予測対象とする時間帯を取得する（ステップ４０１）。予測対象とする時間帯は現在時刻を基点として、例えば15分後、30分後、1時間後など、あらかじめ決められた固定値を用いて設定してもよいし、その都度、任意に設定されてもよい。

次に列車待ち乗客数情報１５１から、日付および時刻情報を参照し、当日の（現在時刻−Ｔ）から現在時刻までのデータを取得する（ステップ４０２）。パラメタＴは１５分、３０分、１時間など、あらかじめ決められた値を用いる。次に列車待ち乗客数情報１５１から、日付および時刻情報を参照し、過去の日付期間の（現在時刻−Ｔ）から現在時刻までのデータを取得する（ステップ４０３）。パラメタＴはステップ４０２と同じ値を用いる。過去の期間については（当日−Ｎ日）から前日（＝（当日−１日））までを対象とする。パラメタＮはあらかじめ決められた値である、出来る限り大きな値（長期の期間）であることが望ましい。

列車待ち乗客数情報１５１からステップ４０２により、データ群Ｄ_ｃ（Ｐ（ｓ,ｐｆ），ｔ）が得られる。ここで、Ｄｃは、当日ｃにおいて、時刻ｔで、駅ｓ、番線ｐｆで特定される場所Ｐにおける列車待ち人数である。ここで、ｔは（現在時刻−Ｔ）から現在時刻までの時刻であり、また、駅Ｓ０１の１番線であれば、Ｐ（Ｓ０１，１）と表せる。同様に、ステップ４０３により、データ群Ｄ_ｃ−ｉ（Ｐ（ｓ,ｐｆ），ｔ）（但し、１≦ｉ≦Ｎ）が得られる。

当日のデータ群（Ｄ_ｃ（Ｐ（ｓ,ｐｆ），ｔ））と過去日のデータ群（Ｄ_ｃ−ｉ（Ｐ（ｓ,ｐｆ），ｔ）（但し、１≦ｉ≦Ｎ））との間で類似度を計算する（ステップ４０４）。類似度の計算には例えば、Ｄ_ｃとＤ_ｃ−ｉとの間のユークリッド距離などを用いればよい。最も類似度が高い（ユークリッド距離による計算の場合は距離が短い）と判定された過去日を特定し、移動需要情報１５５から特定された過去日のデータを取得する(ステップ４０５)。なお、類似度の高い過去日の選択は、ある一日だけでもよいし、類似度の高い順に複数日を選出し平均値をとるなどしてもよい。

また、移動需要情報の取得は全時間帯のデータを取得してもよいし、現在時刻から所定時間遡った時刻からその日の終わりまでのデータに限定して取得してもよい。なお、予測対象とする時間帯以前に駅αに入場した乗客であっても予測対象とする時間帯に駅βから出場する、あるいは路線内で乗降することがありうる。現在時刻から所定時間遡らせてデータを取得するのは、このような乗客も含めて分析するためである。

取得した移動需要情報から乗客のトリップ情報を生成する。例えば、図９に示す2016年５月１日の移動需要情報が最も類似度の高い過去日として特定されたとすれば、乗客集合Ｋｊ（入場時刻，入場駅ＩＤ，出場駅ＩＤ）は、例えば、
Ｋ1(07:00，Ｓ０１，Ｓ０２)、Ｋ2(07:01，Ｓ０１，Ｓ０２)、・・・Ｋ20(07:14，Ｓ０１，Ｓ０２)、Ｋ21(07:00，Ｓ０１，Ｓ０３)、Ｋ22(07:00，Ｓ０１，Ｓ０３)、Ｋ23(07:01，Ｓ０１，Ｓ０３)、Ｋ24(07:01，Ｓ０１，Ｓ０３)、・・・
のように生成される。すなわち、所定の入場時刻に、駅β（出場駅）を目的地として駅α（入場駅）に入場する乗客集合Ｋが生成される。格納されている移動需要情報に従い、路線に含まれるすべての駅についての入場駅、出場駅の組み合わせあるいは、主要駅についての入場駅、出場駅の組み合わせについて乗客修道Ｋを生成する。なお、上記の例では、移動需要情報１５５では時間帯ごとに登録されているため、乗客集合Ｋを生成するにあたり、入場時刻は当該時間帯にほぼ均等に乗客が入場したものとして算出している。

一方、列車位置情報１５３と、列車計画時刻表２７０を用いて、当日の列車の遅延補正運行時刻表を作成する（ステップ４０６）。列車位置情報１５３と現在時刻での列車計画時刻表２７０とを照合することで、現在時刻における列車の遅延を計算できる。計算した遅延時分を反映させ、現在時刻から一日の終わりまでの列車の遅延補正運行時刻表を作成する。

その後、ステップ４０５で作成した乗客集合Ｋのトリップ情報と、ステップ４０６で作成した遅延補正運行時刻表を用いて、乗客が乗る列車を推定する（ステップ４０７）。ここで移動需要情報１５５は入場駅ＩＤ３０３と出場駅ＩＤ３０４との間で定義されており、入場駅と出場駅間に複数の路線が含まれている場合には、マスタ情報１５６に含まれる路線・駅情報２４０および列車計画時刻表２７０を用いて経路探索を行うことにより、利用の可能性が高い路線および列車を求めることができる。例えば、移動時間を最短とするような経路探索を行う。この処理により、ステップ４０５で生成した乗客集合Ｋの全レコードに対して、下記のようなトリップ情報を出力することができる。

Ｋｊ（入場時刻，入場駅ＩＤ，出場駅ＩＤ，［Ｔ１，降車駅ＩＤ，Ｔ２］ｍ）
Ｔ１：列車の出発駅への到達時刻、Ｔ２：列車の降車駅への到達時刻
乗り換えがなければ、出発駅＝入場駅、降車駅＝出場駅である。一方、ｍ回乗り換えがあれば、鍵括弧内の情報をｍ回繰り返したトリップ情報が出力される。例えば、駅Ｓ０１に入場し、駅Ｓ０８で出場する乗客Ｋ_１００は、
Ｋ_１００＝（07:00，Ｓ０１，Ｓ０８，［07:05，Ｓ０５，07:30］［07:45，Ｓ０８，07:50］）と表せる。すなわち、７時に入場駅Ｓ０１に入場した乗客Ｋ_１００は、７時５分に入場駅＝出発駅Ｓ０１に到着する列車（Ｌ１路線上り）に乗り、７時30分に駅Ｓ０５に着き、降車する。その後、７時45分に駅Ｓ０５に到着する列車（Ｌ２路線下り）に乗り、降車駅＝出場駅Ｓ０８に７時50分に到着することになる。このトリップ情報により、乗客Ｋ_１００は、入場駅Ｓ０１の１番線ホームにて７時から７時５分までの間列車待ちがあり、乗換駅Ｓ０５の４番線ホームにて７時30分から７時45分までの間列車待ちがあることが分かる。

このように乗客集合Ｋのトリップ情報により、各乗客がどの駅の、どの番線で列車待ちを行う必要があるのかが把握できる。この結果を集計することにより、予測対象の時間帯における各駅の番線ごとの列車待ち乗客数の予測値を求める（ステップ４０８）。図１１はこのようにして求めた列車待ち乗客数予測結果３３０のデータ構造を示す図であり、計算サーバ１１２内に格納されている。列車待ち乗客数予測結果３３０は日付３３１、時間帯３３２、駅ＩＤ３３３、番線情報３３４、合計列車待ち乗客数３３５などの情報を含む。例えば、７時から７時15分の時間帯において、駅Ｓ０１の１番線ホームに800人の合計列車待ち乗客数が生じることが読み取れる。先述の乗客Ｋ_１００もこのうちの１名として含まれることになる。なお、時間帯情報は、15分毎、30分毎、1時間毎などあらかじめ決められた時間単位で格納される。

このようにして求めた列車待ち乗客数予測結果、列車の乗車人員情報等を用いて、列車本数の増減を判断する。具体的には、ある区間において、列車待ち乗客数の予測値が基準値を大きく超えると判断されたときに列車を増発し、列車待ち乗客数の予測値が基準値を大幅に下回っていると判断されたときに列車を運休する。図３に示す区間Ｌ１−Ａ２について、列車本数増減の判定を行う場合の例を用いて説明する。まず、路線の始発駅（ここでは駅Ｓ０1）から対象区間Ｌ１−Ａ２の終点から一つ前の駅（ここでは駅Ｓ０３）を対象に、列車待ち総乗客数ΣＫを求める。すなわち、駅Ｓ０１の１番線ホーム、駅Ｓ０２の１番線ホーム、駅Ｓ０３の２番線ホームの当該時間帯における列車待ち乗客数予測結果の総和を求める。なお、終点駅（ここでは駅Ｓ０４）の１番ホームで列車を待っている乗客は、次の区間Ｌ１−Ａ３の列車待ち人数にカウントされるべきであるためここでは含めない。列車待ち総乗客数ΣＫは、列車待ち乗客数予測プログラム４２０により、移動需要予測プログラム４００で予測した列車待ち乗客数予測結果（図１１）を用いて集計する。なお、集計対象の路線および区間のリストは、常に全路線および全区間を対象にしてもよいし、システム運用者によって指定された一部の路線または区間に限定した対象としてもよい。

なお、列車待ち乗客数予測プログラム４２０は移動需要予測を用いて予測するものに限られない。例えば、単純に当日の各駅の番線ごとの列車待ち乗客数の推移と過去の同じ時間帯の列車待ち乗客数の推移とを比較して、最も類似した列車待ち乗客数の推移に基づき列車待ち乗客数を予測してもよい。この場合は、比較する過去の時点でのダイヤが当日のダイヤと同一視できることが前提となる。

列車を待ち総乗客数ΣＫと、あらかじめ設定した基準値Ｘ０を用いて、列車本数の増減判断を行う。例えば、基準値Ｘ０は列車を待っている総乗客数ΣＫの通常値であり、例えば過去における列車待ち総乗客数の平均値とする。乗客数の中長期に亘る経時変化により増減の判定が不適切になるのを防止するために基準値との差をもって列車本数の増減判断を行うようにするものである。

具体的には、「（列車待ち総乗客数ΣＫ−基準値Ｘ０）＞混雑しきい値幅上限値」が成り立つ場合、列車本数の増発が必要と判断する。一方、「（基準値Ｘ０−列車待ち総乗客数ΣＫ）＞混雑しきい値幅下限値」が成り立つ場合、列車本数を減らす(運休)判断をする。いずれにも当てはまらない場合は列車の増発も運休も行わない。

図１２はデータサーバ１１１内に格納される混雑しきい値幅情報１５７のデータ構造を示す図である。混雑しきい値幅情報１５７は日付区分３１１、時間帯３１２、路線・方面の名称３１３、区間３１４、基準値３１５、混雑しきい値幅３１６などの情報を含む。時間帯情報は、15分毎、30分毎、1時間毎などあらかじめ決められた時間単位で格納される。混雑しきい値幅情報に上限及び下限の値が含まれていることにより、増発／運休／現状維持の３つの選択肢が可能になる。上限と下限の値はそれぞれ分かれたカラムに格納されていてもよいし、または所定のしきい値と許容範囲の比率（±α）の組み合わせで格納されていてもよい。一般的に乗客需要は、平日・休日の区分や時間帯、路線や区間によって傾向が異なるため、混雑しきい値幅情報も区間毎に細かく設定されている方が望ましい。混雑しきい値幅は、列車待ち乗客数情報１５１に格納されたデータを用いて、区間単位に集計した上で、平均値や分散をとるなどの統計処理により、求めることができる。

加えて、数ヶ月おき、または一年に一回など、定期的に再計算を行い、基準値３１５（Ｘ０）の更新を行うことで、乗客需要の季節変動や経年変化に対応することができる。大規模なイベントの予定など、通常と比べて乗客需要が大きく変わるであろうことが、あらかじめ予想できている場合は、システム運用者がイベント開催日用の基準値Ｘ０を入力してもよい。

図１３は、上述の判断を行う列車本数増減判定プログラム４４０のフローチャートである。まず、列車本数の増減を判定する対象路線および対象区間、対象時間帯の条件を取得する（ステップ４４１）。取得した条件をもとに、列車待ち乗客数予測プログラム４２０により算出される合計列車待ち乗客数ΣＫを取得する（ステップ４４２）。次に混雑しきい幅情報１５７からステップ４４１で取得した条件に一致する基準値３１５、混雑しきい値幅３１６を取得する（ステップ４４３）。

上述のように経時変化の影響を低減するため、合計列車待ち乗客数ΣＫと基準値Ｘ０との差と混雑しきい値幅とを比較する。その結果、「（合計列車待ち乗客数ΣＫ−基準値Ｘ０）＞混雑しきい値幅の上限値」が成り立つ場合（ステップ４４４）は、列車を増発した方がよいという判定を下し、差分Ｓ（合計列車待ち乗客数ΣＫ−基準値Ｘ０−混雑しきい値幅の上限値）を計算し、列車本数増減判定結果とともに格納する（ステップ４４５）。逆に「（基準値Ｘ０−合計列車待ち乗客数ΣＫ）＞混雑しきい値幅の下限値」が成り立つ場合（ステップ４４６）は、列車を運休した方がよいという判定を下し、差分Ｓ（基準値Ｘ０−合計列車待ち乗客数ΣＫ−混雑しきい値幅の下限値）を計算し、列車本数増減判定結果とともに格納する（ステップ４４７）。すなわち、差分Ｓは、合計列車待ち乗客数ΣＫが想定した混雑度（混雑しきい値幅の上限値として与えられる）を超えて生じた待ち乗客数、あるいは想定した閑散度（混雑しきい値幅の下限値として与えられる）を越えて不足した待ち乗客数ということができる。

図１４はデータサーバ１１１内に格納される列車本数増減判定結果１５８のデータ構造を示す図である。列車本数増減判定結果１５８は、日付３２１、時間帯３２２、路線・方面の名称３２３、区間３２４、列車本数増減判定プログラム４４０から得られる判定結果３２５、差分値３２６などの情報を含む。

図１５は提案ダイヤ作成プログラム４６０が、列車本数増減判定結果１５８および、列車状態情報１５４をもとに、実際に増発/運休する列車本数を算出し、鉄道事業者が保有する列車運行システム１３０のダイヤ計画システム１３１に情報を送信し、ダイヤ計画システム１３１が作成した更新ダイヤを受信する処理のフローチャートである。ここでは例として、列車本数増発のケースについて述べる。まず、対象路線および対象区間、対象時間帯の条件を取得する（ステップ４６１）。取得した条件での判定結果を列車本数増減判定結果１５８から取得する（ステップ４６２）。このとき、対象時間帯の前後の時間帯のレコードをも取得する。例えば、ステップ４６１で指定された対象時間帯が07:00-07:15であった場合、ステップ４６２では、06:30-07:45のように、前後30分ずつのマージンをとるような形で、複数のレコードを取得する。このマージンに関しては前後30分ずつ、1時間ずつなどあらかじめ定められているものとする。前後30分ずつのマージンを取る場合、列車本数増減判定結果１５８の時間帯区分が15分単位であれば、ステップ４６２では対象時間帯を含む合計5個のレコードを取得する。取得したレコードの判定結果を参照し、増発と判定された回数が、あらかじめ定めておいたしきい値を超えていれば最終的に増発が必要と判定する（ステップ４６３）。しきい値は、レコードの合計数に対する比率（例えば50%超）で定めてもよい。超えている場合は、ステップ４６４以降を実行し、超えていない場合はステップ４６１に戻り、異なる対象路線、対象区間または対象時間帯の条件を取得する。

増発要と判定した場合、必要な増発本数を求めるため、ステップ４６２で取得した全レコードについて、列車本数増減判定結果１５８の差分Ｓの合計値ΣＳを求め（ステップ４６４）、（ΣＳ／列車の平均定員情報）により、必要な増発本数を求める（ステップ４６５）。列車の平均定員情報はマスタ情報１５６に含まれる列車計画時刻表２７０から計算できる。必要な増発本数を求める方法としては、他にも列車待ち乗客数の合計値に応じて一本、二本、三本とレベル分けをしておくなどの方法がある。

次にステップ４６５で求めた増発本数が実際に手配可能かを確認するために、列車状態情報１５４、マスタ情報１５６の本線合流時間情報２５０を参照する（ステップ４６６）。具体的には列車状態情報１５４の在線場所情報をもとにマスタ情報１５６に含まれる本線合流時間情報２５０を参照し、該当路線に配車可能な列車を抽出する。配車可能な列車本数が、ステップ４６５で求めた増発本数を超えていれば、ステップ４６５で求めた増発本数に加えて、本線合流時間情報２５０から合流に必要な時間を取得し、列車運行システム１３０のダイヤ計画システム１３１に情報を送信する（ステップ４６７）。なお、配車可能な列車本数が、ステップ４６５で求めた増発本数より下回っている場合は、配車可能な列車本数をダイヤ計画システム１３１に情報を送信する。最後にダイヤ計画システム１３１で作成された更新ダイヤを受信し、データサーバ１１１内の更新ダイヤ情報１５９に格納する（ステップ４６８）。更新ダイヤは対象時間帯を含む、前後数十分〜数時間の範囲の時刻表情報である。
図１６はデータサーバ１１１内に格納される更新ダイヤ情報１５９のデータ構造を示す図である。更新ダイヤ情報１５９は、ＩＤ３５１、日付３５２、時間帯３５３、路線・方面の名称３５４、ダイヤデータファイルの格納場所情報３５５などの情報を含む。更新ダイヤ情報１５９には、提案ダイヤ作成プログラム４６０が実行され、ダイヤ計画システム１３１から新しく更新ダイヤを受信したタイミングで格納される。
なお、図１に示した動的列車運行ダイヤ提案システム１１０では、提案ダイヤ作成プログラム４６０により現実に増発可能な列車本数まで求めたうえで、ダイヤ計画システム１３１に提案しているが、例えば、列車本数増減判定プログラム４４０による列車本数の増減判定までを実施し、この判定結果をダイヤ変更提案として、ダイヤ計画システム１３１に提案するというものであってもよい。どこまでを動的列車運行ダイヤ提案システム１１０で実行し、どこからを列車運行システム１３０で実行するか、役割分担の問題であり、この場合は、提案ダイヤ作成プログラム４６０で実行する処理をダイヤ計画システム１３１にて実行することになる。

図１７は効果分析プログラム４８０が、本実施例の運行ダイヤ提案システムの提案にしたがって変更された更新ダイヤの効果の分析を実行するフローチャートである。まず、更新ダイヤ情報１５９より、列車本数増減調整後のダイヤを取得する（ステップ４８１）。移動需要予測プログラム４００の処理と同様の手順で、更新ダイヤの該当時間帯に対する移動需要情報を生成し、ステップ４８１で取得したダイヤ情報をもとに、各乗客が乗る列車を推定する（ステップ４８２）。推定結果を用いて、駅毎および番線毎に列車待ち乗客数を集計する（ステップ４８３）。さらに列車本数増減調整前のダイヤ（元々の列車運行状況）における列車待ち乗客数情報１５１や混雑しきい値幅情報１５７と比較し、更新ダイヤ実施後の列車待ち乗客数が、混雑しきい値幅の設定範囲内に収まっているか、元々の状況より混雑しきい値幅に近い結果に改善されているかなどの判定を行う（ステップ４８４）。更新ダイヤ実施後にも関わらず、列車待ち乗客数が混雑しきい値幅の設定範囲から外れているような状況が確認できた場合には、列車本数増減判定プログラム４４０や提案ダイヤ作成プログラム４６０のパラメタを調整することで、改善の対策を行う。

図１８は、情報配信サーバ１１３が配信する画面の一例を示す図である。画面１０００は、システム運用者１２１の端末１２２や運行管理センタ１２６に配信される画面であり、現在の列車待ち乗客数の状況、列車の計画時刻表などを表示する。画面１０００は、ダイヤスジを表示する画面１００１や、ある駅の列車待ち乗客数情報を時系列で表示するグラフ表示領域１００２を有する。ダイヤスジ表示領域１００３は、駅の一覧１００４と、時間軸からなる二次元の領域で、例えば、現在時刻から数十分後までのダイヤスジを表示する。グラフ表示領域１００２では、当日始発運行もしくは現在時刻の数時間前から現在時刻の数時間後先までの列車待ち乗客数を時系列グラフで表示する。ダイヤスジ表示領域１００３やグラフ表示領域１００２は、縦および横方向にそれぞれ、スクロール機能を有していてもよい。また画面１０００は、路線および方面を選択する機能１００５や、区間を選択する機能１００６や、駅を選択する機能１００７を備えていてもよい。路線および方面を選択する機能１００５の選択内容によって、画面１００１に表示される路線が変更される。また、路線および方面を選択する機能１００５の選択内容によって区間を選択する機能１００６や駅を選択する機能１００７の一覧が変更される。また、区間を選択する機能１００６の選択内容によって画面１００１に表示される範囲（駅の範囲）が変更される。多数の駅から構成される路線について状況を把握したい場合に、このような選択機能は有効である。駅を選択する機能１００７の選択内容に従って、画面１００２のグラフ表示領域の対象駅が変更される。他に駅の中の番線を選択できる機能が含まれていてもよい。

画面１００２のグラフ表示領域においては、列車待ち乗客数の推移に加えて、基準値Ｘ０を表示してもよい。このとき、例えば、列車待ち乗客数は実線で、基準値は点線で表示するなどの工夫が考えられる。また、列車待ち人数がしきい値幅を超えた場合、対象駅を枠で囲む、色や大きさを変更する、ポップアップを出すなどの方法で、利用者に想定以上の混雑が発生していることを伝える警告を表示してもよい。また駅の列車待ち人数の情報はテキストで表示してもよい。現在の状況を俯瞰できる画面をシステム運用者や鉄道事業者に提示することによって、列車本数増減調整の必要性が理解しやすくなるなど、状況を把握するための情報を得ることができる。これらの画面はマウスやキーボードなどの入力インタフェースを用いて操作が可能で、例えば、ホイールボタンなどでダイヤスジ画面のズームイン／ズームアウトを操作したり、マウスクリックで駅を選択し、番線毎の混雑情報など詳細な情報を表示したりできる。

情報配信サーバ１１３は、条件設定機能１００５、１００６、１００７に入力されたリクエストを受信すると、当該条件にしたがって列車待ち乗客数情報１５１や、列車位置情報１５３および列車計画時刻表２７０から、該当路線および方面、該当区間、該当駅のレコードを抽出する。その後、抽出したレコードを時系列グラフやダイヤスジ画面へのマッピングなどの形式に加工し、リクエストを送信した装置に配信する。

情報配信サーバ１１３は、配信先の装置の特性や配信する情報の内容に合わせて複数のプログラムを組み合わせて、配信する画面を作成するとよい。例えば、画面の配信にｗｅｂサーバの技術を用いることができ、配信先の装置で実行されるｗｅｂブラウザによって、配信される情報を見ることができる。なお、配信先の装置で実行される専用のアプリケーションが、情報配信サーバ１１３から送信されたデータを用いて表示すべき画面を作成してもよい。

図１９は、情報配信サーバ１１３が配信する画面の別の例を示す図である。画面１０１０は列車本数増減調整前後のダイヤなどを表示する。画面１０１０は、例えば列車本数増減調整前のダイヤスジを表示する画面１０１１や、列車本数増減調整後の更新ダイヤスジを表示する画面１０１２から構成される。また画面１０１０は、路線および方面を選択する機能１０１３や、日付を選択する機能１０１４などを備えていてもよい。路線および方面を選択する機能１０１３の選択内容、日付を選択する機能１０１４の選択内容によって、画面１０１１、１０１２に表示される路線が変更される。画面１０１１、１０１２は画面縦方向に分割して並べてもよいし、横方向に分割して並べてもよい。または、別々のウインドウで表示し、利用者が自在に動かせるようにしてもよい。画面１０１１および１０１２は、それぞれダイヤスジ表示領域を備えており、区間や駅の一覧と、時間軸からなる二次元の領域で、現在時刻から数十分後までのダイヤスジを表示する。画面１０１１および１０１２は、縦および横方向にそれぞれ、スクロール機能を有しているとよい。スクロール機能は、画面１０１１、１０１２それぞれ単独に操作できてもよいし、一つの画面領域でスクロールを行った操作が、もう一つの画面領域でも連動して動作してもよい。連動することで、列車本数増減調整前後のダイヤを、常に同じ表示領域で比較することができる。また、提案ダイヤスジ表示画面１０１２においては、増減調整された列車を特定しやすくするために、増発した列車を太線で、運休された列車を点線で表示するなど線の色や太さ、形状などを変更して表示してもよい。図１９は区間Ｌ１−Ａ１において、列車が二往復、増発され、全区間において列車が一本、運休された例を示している。増減調整された区間や時間帯を分かりやすく示すために、ダイヤスジの線を変更するだけでなく、該当区間や該当時間帯の領域の背景色を変更するなどしてもよい。

図２０は、情報配信サーバ１１３が配信する画面の別の例を示す図である。画面１０２０は列車本数増減調整前後の列車待ち乗客数の比較画面を表示する。画面１０２０は列車本数増減調整前の列車待ち乗客数予測値を表示する画面１０２１や、列車本数増減調整後の列車待ち乗客数予測値を表示する画面１０２２から構成される。画面１０２１、１０２２は画面縦方向に分割して並べてもよいし、横方向に分割して並べてもよい。または、別々のウインドウで表示し、利用者が自在に動かせるようにしてもよい。画面１０１１および１０１２は、それぞれグラフ表示領域１０２３を備えており、当日始発運行もしくは現在時刻の数時間前から、現在時刻の数時間後先までの列車待ち乗客数を時系列グラフで表示する。グラフ表示領域は横方向にスクロール機能やズーム機能を有していてもよい。また画面１０２０は、路線および方面を選択する機能１０２４や、区間を選択する機能１０２５や、指標を選択する機能１０２６を備えていてもよい。路線および方面を選択する機能１０２４の選択内容によって、画面１０２０に表示される路線が変更される。また、路線および方面を選択する機能１０２４の選択内容によって区間を選択する機能１０２５の選択候補一覧が変更される。画面１０２０は区間を選択する機能１０２５に加えて、駅や番線毎などさらに細かい情報を選択できる機能を有していてもよい。グラフ表示領域１０２３には、路線および方面を選択する機能１０２４、区間を選択する機能１０２５、指標を選択する機能１０２６の選択内容に従って、時系列グラフなどで、指標の変化を表示する。指標の選択は、単一の候補を選択できるインタフェースでもよいし、複数の指標を同時に選択できるインタフェースでもよい。複数の指標を同時に選択できるインタフェースの場合は、グラフ表示領域１０２３に表示されるグラフは、指標別に線の形状や色を変更するなど、指標ごとに区別しやすいような表示形態にして配信する。選択できる指標の種類は、データサーバ１１１に格納される、列車待ち乗客数情報１５１、列車乗車人数情報１５２などのデータから集計可能な、列車待ち乗客数（実測値または予測値）、列車の乗車率などが考えられる。

図２１は情報配信サーバ１１３が配信する画面の別の例を示す図である。画面１０３０は乗客１２７の端末１２８に配信される画面で、指定した路線および方面の列車の到着予定時間や、駅および列車の混雑状況を表示する。乗客１２７のモバイル端末１２８は、画面のサイズが小さく、解像度が低い特性を考慮して画面を構成する必要がある。例えば、画面１０３０は、路線、方面及び駅を選択するインタフェース１０３１及びスクロール機能を有する情報表示領域１０３２を含む。このため、利用者が情報を見たい駅や列車を簡単に選択できる。

また、端末１２８のＧＰＳ機能と連動して、利用者の現在位置に近い駅の情報を選択して表示してもよい。画面１０３０は、利用者が滞在している駅に、これから到着する列車の到着までの時間や、駅の混雑の状況を表示する。また列車の乗車人員情報を用いて、列車の混雑度を表示することもできる。これによって、利用者は、次の列車に乗るべきか、さらに次の列車に乗るべきかを判断できる。また、列車が増発された場合に、線の太さや色を変更するなどして、追加された列車の情報を提供することで、利用者は乗客需要に応じて列車の運行が調整されていることを知ることができ、輸送サービスに対する満足度向上につながると考えられる。

また駅の混雑度の予測値を乗客に配信することで、乗客は、複数の駅が利用可能な場合、空いている駅を選択して利用できるため、混雑の分散につながる。輸送事業者は、駅などの混雑度に応じて人員を配置したり、規制したりすることによって、駅などの安全を確保できる。さらに、混んでいる乗り場に多くの輸送手段（バス、タクシーなど）を配車して、短時間で混雑を緩和できる。

なお、本実施例について詳細に説明をしたが、本発明は上述した実施例に限定されるものではなく、様々な変形例及び同等の構成が含むものである。例えば、上述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備える必要はない。また、ある実施例の構成の一部を他の構成に置き換えてもよい。また、ある実施例の構成に他の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。

１０１：列車、１１０：動的列車運行ダイヤ提案システム、１１１：データサーバ、１１２：計算サーバ、１１３：情報配信サーバ、１２６：運行管理センタ、１３０：列車運行システム、１３１：ダイヤ計画システム、１３２：運行管理システム、１３３：列車情報管理システム、４００：移動需要予測プログラム、４２０：列車待ち乗客数予測プログラム、４４０：列車本数増減判定プログラム、４６０：提案ダイヤ作成プログラム、４８０：効果分析プログラム。

Claims (14)

1. 列車を複数の駅を有する路線で運行する交通システムであって、
   上記路線のダイヤを決定するダイヤ計画システムと、
   上記路線のダイヤの変更を提案するダイヤ提案システムとを有し、
   上記ダイヤ提案システムは、
   上記複数の駅で収集される、乗客に関する情報を格納するデータサーバと、
   移動需要予測プログラム、列車待ち乗客数予測プログラム及び列車本数増減判定プログラムを格納する計算サーバとを有し、
   上記データサーバは、所定の日付の所定の時間帯に上記複数の駅に含まれる第１の駅に入場し、上記複数の駅に含まれ上記第１の駅とは異なる第２の駅から出場する乗客数の情報を蓄積し、
   上記計算サーバは、それぞれあらかじめ定められた時間間隔で上記移動需要予測プログラム、上記列車待ち乗客数予測プログラム及び上記列車本数増減判定プログラムを実行し、
   上記移動需要予測プログラムは、上記データサーバに蓄積された過去の所定の日付の所定の時間帯に上記第１の駅に入場し、上記第２の駅から出場する乗客数の情報に基づいて、当日の所定の時間帯において上記第１の駅に入場し、上記第２の駅から出場する乗客数を予測し、
   上記列車待ち乗客数予測プログラムは、上記移動需要予測プログラムにより予測された乗客数に基づいて上記当日の所定の時間帯における上記複数の駅における列車待ち乗客数を予測し、
   上記列車本数増減判定プログラムは、上記当日の所定の時間帯における上記複数の駅における列車待ち乗客数に基づいて上記当日の所定の時間帯における列車本数の増減の要否を判定し、
   上記ダイヤ計画システムは、上記当日の所定の時間帯におけるダイヤを上記ダイヤ提案システムにおける列車本数の増減要否判定に基づき列車本数を増減したダイヤに更新する交通システム。
2. 請求項１に記載の交通システムにおいて、
   上記路線で運行されている列車に関する情報を収集する列車情報管理システムを有し、
   上記計算サーバは、さらに提案ダイヤ作成プログラムを格納しており、あらかじめ定められた時間間隔で上記提案ダイヤ作成プログラムを実行し、
   上記提案ダイヤ作成プログラムは、上記列車本数増減判定プログラムの判定結果及び上記列車情報管理システムで収集された列車の情報に基づいて、上記当日の所定の時間帯において列車本数を増減したダイヤ提案を作成し、
   上記ダイヤ計画システムは、上記ダイヤ提案に基づくダイヤに更新する交通システム。
3. 請求項２に記載の交通システムにおいて、
   上記データサーバは、所定の状態の列車が所定の退避場所から本線へ合流するまでの所要時間を示す本線合流時間情報を格納し、
   上記列車情報管理システムで収集する列車に関する情報に、上記路線上の各列車の在線場所及び状態を示す列車状態情報が含まれ、
   上記提案ダイヤ作成プログラムは、上記本線合流時間情報及び上記列車状態情報に基づいて上記路線に配車可能な列車を抽出して上記ダイヤ提案を作成する交通システム。
4. 請求項２または３に記載の交通システムにおいて、
   上記計算サーバは、さらに上記ダイヤ計画システムにより更新されたダイヤの効果を分析する効果分析プログラムを格納しており、
   上記効果分析プログラムは上記ダイヤ計画システムにより更新されたダイヤによる効果を算出し、
   上記効果に基づき、上記列車本数増減判定プログラムまたは上記提案ダイヤ作成プログラムのパラメータを調整する交通システム。
5. 請求項１〜４のいずれか１項に記載の交通システムにおいて、
   上記複数の駅で収集される乗客に関する情報として、自動改札機から収集される情報、駅に設置される監視カメラの情報、駅に設置される無線ＬＡＮの接続情報の少なくともいずれか一つを含む交通システム。
6. 列車を複数の駅を有する路線で運行する交通システムにおける上記路線のダイヤの変更を提案するダイヤ提案システムであって、
   上記複数の駅で収集される、乗客に関する情報を格納するデータサーバと、
   移動需要予測プログラム、列車待ち乗客数予測プログラム及び列車本数増減判定プログラムを格納する計算サーバとを有し、
   上記データサーバは、所定の日付の所定の時間帯に上記複数の駅に含まれる第１の駅に入場し、上記複数の駅に含まれ上記第１の駅とは異なる第２の駅から出場する乗客数の情報を蓄積し、
   上記計算サーバは、それぞれあらかじめ定められた時間間隔で上記移動需要予測プログラム、上記列車待ち乗客数予測プログラム及び上記列車本数増減判定プログラムを実行し、
   上記移動需要予測プログラムは、上記データサーバに蓄積された過去の所定の日付の所定の時間帯に上記第１の駅に入場し、上記第２の駅から出場する乗客数の情報に基づいて、当日の所定の時間帯において上記第１の駅に入場し、上記第２の駅から出場する乗客数を予測し、
   上記列車待ち乗客数予測プログラムは、上記移動需要予測プログラムにより予測された乗客数に基づいて上記当日の所定の時間帯における上記複数の駅における列車待ち乗客数を予測し、
   上記列車本数増減判定プログラムは、上記当日の所定の時間帯における上記複数の駅における列車待ち乗客数に基づいて上記当日の所定の時間帯における列車本数の増減の要否を判定するダイヤ提案システム。
7. 請求項６に記載のダイヤ提案システムにおいて、
   上記移動需要予測プログラムは、
   予測対象とする路線における当日の列車待ち乗客数の推移と過去の列車待ち乗客数の推移とを比較し、類似度の高い列車待ち乗客数の推移を示した過去の移動需要に基づき、上記当日の所定の時間帯において上記第１の駅に入場し、上記第２の駅から出場する乗客数を予測するダイヤ提案システム。
8. 請求項６または７に記載のダイヤ提案システムにおいて、
   上記データサーバは上記路線で運行されている列車に関する情報を格納し、
   上記計算サーバは、さらに提案ダイヤ作成プログラムを格納しており、あらかじめ定められた時間間隔で上記提案ダイヤ作成プログラムを実行し、
   上記提案ダイヤ作成プログラムは、上記列車本数増減判定プログラムの判定結果及び上記データサーバに格納された列車の情報に基づいて、上記当日の所定の時間帯において列車本数を増減したダイヤ提案を作成するダイヤ提案システム。
9. 請求項８に記載のダイヤ提案システムにおいて、
   上記データサーバは、上記路線上の各列車の在線場所及び状態を示す列車状態情報、及び所定の状態の列車が所定の退避場所から本線へ合流するまでの所要時間を示す本線合流時間情報を格納し、
   上記提案ダイヤ作成プログラムは、上記列車状態情報及び上記本線合流時間情報に基づいて上記路線に配車可能な列車を抽出して上記ダイヤ提案を作成するダイヤ提案システム。
10. 請求項８または９に記載のダイヤ提案システムにおいて、
    上記計算サーバは、さらに上記ダイヤ提案に基づき更新されたダイヤの効果を分析する効果分析プログラムを格納しており、
    上記効果分析プログラムは上記ダイヤ提案に基づき更新されたダイヤによる効果を算出し、
    上記効果に基づき、上記列車本数増減判定プログラムまたは上記提案ダイヤ作成プログラムのパラメータを調整するダイヤ提案システム。
11. 請求項８〜１０のいずれか１項に記載のダイヤ提案システムにおいて、
    さらに、情報配信プログラムを格納する情報配信サーバを有し、
    上記情報配信プログラムは、上記提案ダイヤ作成プログラムによるダイヤ提案に基づき更新されたダイヤの情報を配信するダイヤ提案システム。
12. 請求項６〜１１のいずれか１項に記載のダイヤ提案システムにおいて、
    上記複数の駅で収集される乗客に関する情報として、自動改札機から収集される情報、駅に設置される監視カメラの情報、駅に設置される無線ＬＡＮの接続情報の少なくともいずれか一つを含むダイヤ提案システム。
13. 列車を複数の駅を有する路線で運行する交通システムの列車運行システムであって、
    上記路線で運行されている列車に関する情報を収集する列車情報管理システムと、
    上記路線のダイヤを決定するダイヤ計画システムとを有し、
    上記ダイヤ計画システムは、所定の時間帯におけるダイヤを、ダイヤ提案システムからの提案を受けて、上記ダイヤ提案システムによる列車本数の増減要否判定に基づき、列車本数を増減したダイヤに更新し、
    上記ダイヤ提案システムによる列車本数の増減要否判定は、あらかじめ定められた時間間隔で、上記複数の駅で収集される乗客に関する情報及び上記列車情報管理システムが収集した列車に関する情報に基づいて予測された当日の所定の時間帯における上記複数の駅における列車待ち乗客数に基づいてなされ、上記当日の所定の時間帯における上記複数の駅における列車待ち乗客数は、過去の所定の日付の所定の時間帯に上記複数の駅に含まれる第１の駅に入場し、上記複数の駅に含まれ上記第１の駅とは異なる第２の駅から出場する乗客数の情報に基づいて予測される上記当日の所定の時間帯における上記第１の駅に入場し、上記第２の駅から出場する乗客数に基づいて予測される列車運行システム。
14. 請求項１３に記載の列車運行システムにおいて、
    上記列車に関する情報として、列車の乗客数及び列車の位置情報を含む列車運行システム。

Images