JP2014213697A - 混雑状況情報集配信システム - Google Patents

Abstract

【課題】高速で高精度な混雑状況情報の集配信システムを提供する。
【解決手段】混雑状況情報集配信システム１００は、複数の計算機がネットワーク接続する情報集配信システムであって、改札機１０１、制御監視サーバ１０２、改札情報集信サーバ１０３、分析サーバ１０６、管理情報サーバ１０７、配信サーバ１０４、管理者端末１０９、利用者端末１０５から構成する。
【選択図】図１

Description

本発明は、鉄道等の交通機関における人流情報の集配信システム、設備制御システムに関する。

鉄道網が大規模複雑化している。特に、大規模災害時や異常時には、タイムリーで適切な情報提供、設備制御が重要である。さらに、改札情報は乗客の流れを把握しうる情報源であり、プライバシを保護しつつ、これをリアルタイムに集配信する新サービスについて、研究開発が盛んである。

改札情報はいったん蓄積すれば、データマイニングなどの手段を用いてユーザの行動パターンを抽出できる（特許文献１乃至４）。

特開２００１−５５１４５号 特開２０１０−２４７７２８号 特開２００７−１１８７０５号 特開２００７−２２４９７号

しかし、過去データに基づくシミュレーションと、リアルタイムの現況把握は別問題である。特に都市部では、改札情報は大量のトランザクションが飛び交うビッグデータとなるため、人の流れや混雑状況としてリアルタイムに集約する処理がむつかしい。浮動小数点処理専用プロセッサや並列処理ＯＳなどの近年の計算機性能を活用する観点においては、ＩＦ−ＴＨＥＮルールを多数用いる従来のシミュレーション目的の分析ロジックだと処理速度ネックとなりやすく、リアルタイムストリーム処理に適さない。

改札情報を集配信するシステムでは、高速処理と状況推測の精度向上を両立することが課題であった。

上記課題を解決するために、本発明は、一つの観点に従う構成は以下のとおりである。

混雑状況情報集配信システムは、複数の計算機がネットワーク接続する情報集配信システムであって、改札機、制御監視サーバ、改札情報集信サーバ、分析サーバ、管理情報サーバ、配信サーバ、管理者端末、利用者端末から構成する。計算機はメモリ、ＣＰＵ、ディスク、入出力手段を備え、相互にネットワーク接続する。

管理情報サーバは、管理データベースを備え、管理データベースには管理情報を格納管理する。管理情報には、混雑状況情報等の実績情報、分析情報、関連情報を含む。関連情報には、運行情報，車両応過重情報、経路情報などが含まれる。さらに、関連情報には、乗車券、利用者、契約情報、駅、改札機などの属性情報が含まれる。例えば、管理データベースを検索することにより、乗車駅IDから駅名文字列を参照したり、改札情報から管理情報サーバに乗客の性別を照会したりできる。管理者端末の入力手段を用いて関連情報を格納してもよいし、通信によって車両等から受信してもよい。運行情報、経路情報、改札情報、予測情報、現況情報のテーブルを、事前登録および／あるいは逐次登録管理してもよい。

改札機は、開閉戸と乗車券読み取り装置を備え、乗車券を持った乗客が改札機を通過する際に、改札通過時刻、乗車駅ＩＤ、改札ＩＤ，定期券情報を含む改札情報を取得し、制御監視サーバに改札情報を送信する。制御監視サーバは、１つ以上の改札機の制御を行い、改札情報を受信する。改札機の制御には、戸の開閉や通過方向の限定を含む。改札情報集信サーバは、１つ以上の制御監視サーバから改札情報を集信、蓄積し、改札情報を改札情報テーブルに格納する。

分析サーバは、改札情報を分析して、混雑状況情報を計算、混雑状況情報テーブルに格納する。配信サーバは、混雑状況情報を参照して配信する。利用者端末は、混雑状況情報を受信し、混雑状況情報を出力する。

分析サーバは、
予改札情報テーブルを改札機ＩＤをキーとして集計し、改札機ごとの混雑状況を現況情報テーブルに格納するステップと、
あらかじめ用意した時刻のルックアップテーブル、あるいは、時刻の１次関数を用いて、改札通過時刻によって、定期券区間の発駅か着駅か他の駅かを乗客の予定降車駅として定めるステップと、
乗車駅、予定降車駅および／あるいは途中駅における滞留予定時刻および滞留予定時間を計算し、予測情報テーブルに格納するステップと、
予測情報テーブルに格納された滞留予定時間の合計を計算し、駅ごとおよび／あるいは時間帯ごとの混雑状況を現況情報テーブルに格納するステップと、
運行情報によって指定された路線をキーとして、予測情報テーブルに格納した滞留時間に運転再開までの見込み時間を加算してレコードを更新するステップと、
現況情報テーブルの時間帯ごとの混雑状況と、あらかじめ登録した駅ごとの滞留限界人数と比較して、どの時間帯になると滞留限界を超えるかを調べ、注意フラグをセットするステップと、
を備え、注意フラグが立っている場合に利用者端末においてシステム利用者に注意喚起を促すことができる。

混雑状況情報集配信システムの利用者は、駅員と一般利用者である。一般利用者には乗客も含む。駅員は管理者端末および利用者端末を使用してすべての構成要素にアクセスでき、一般利用者は利用者端末を利用して配信情報を得る。

本明細書が開示する技術は、処理するソフトウェア，装置，サービス，システム，コンテンツ，媒体およびその応用用途に適用可能である。

一つの観点に従った上記態様によって得られる効果は以下のとおりである。

本発明により、高速で高精度な混雑状況情報の集配信システムを提供できる。さらに、本発明の応用システムでは，混雑状況情報を集配信する設備制御システムを実現でき、混雑状況の緩和や人流の適正化等に寄与する。

混雑状況情報の集配信システムの全体システム構成を示す図である。 改札情報テーブルの構造とデータ例を示す図である。 予測情報テーブルの構造とデータ例を示す図である。 現況情報テーブルＡ（改札機単位集計）の構造とデータ例を示す図である。 現況情報テーブルＢ（駅単位集計）の構造とデータ例を示す図である。 分析サーバの構成を示す図である。 分析サーバの予測処理の処理手順を示す図である。 分析サーバの集計処理の処理手順を示す図である。 分析サーバの異常時補正処理の処理手順を示す図である。 混雑状況情報の配信サーバの構成を示す図である。 分析サーバの予測処理の処理手順において、改札情報と改札時刻から予想目的駅を計算する方法を示す図である。 発見的規則を整理した表を示す図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。

図１は、混雑状況情報集配信システム１００の全体システム構成を示す。

混雑状況情報集配信システム１００は、複数の計算機がネットワーク接続する情報集配信システムであって、改札機１０１、制御監視サーバ１０２、改札情報集信サーバ１０３、分析サーバ１０６、管理情報サーバ１０７、配信サーバ１０４、管理者端末１０９、利用者端末１０５の計算機から構成する。設備制御１１０の計算機を含めてもよい。これらの計算機はそれぞれメモリ、ＣＰＵ、ディスク、入出力手段、タイマを備え、相互にネットワーク接続する。

管理情報サーバ１０７は、管理データベースを備え、管理データベースには管理情報１１２を格納管理する。管理情報１１２には、混雑状況情報等の実績情報、分析情報、関連情報を含む。関連情報には、運行情報，車両応過重情報、経路情報などが含まれる。さらに、関連情報には、乗車券、利用者、契約情報、駅、改札機などの属性情報が含まれる。例えば、管理データベースを検索することにより、乗車駅IDから駅名文字列を参照したり、改札情報１１１を用いて管理情報サーバ１０７に乗客の性別を照会したりできる。管理者端末１０９の入力手段１１６を用いて関連情報を格納してもよいし、通信によって車両１０８等から受信してもよい。車両１０８内に改札機があってもよい。運行情報、経路情報、改札情報１１１、予測情報１１３、現況情報１１４のテーブルを管理データベースで事前登録および／あるいは逐次登録管理してもよい。

改札機１０１は、開閉戸と乗車券読み取り装置を備え、乗車券を持った乗客が改札機を通過する際に、改札通過時刻、乗車駅ＩＤ、改札ＩＤ，定期券情報を含む改札情報を取得し、制御監視サーバ１０３に改札情報を送信する。設備制御１１０に送信してもよい。設備制御１１０および／あるいは制御監視サーバ１０２は、１つ以上の改札機１０１や昇降機、通路門戸等の制御手段、情報を送受信する手段を備える。改札機１０１の制御には、戸の開閉や通過方向の限定を含む。改札情報集信サーバ１０３は、１つ以上の制御監視サーバ１０２から改札情報を集信し、改札情報テーブル１１１に格納する。

分析サーバ１０６は、データベースを備え、分析サーバメモリ内に予測処理、集計処理、配信情報作成処理の機能を持ち、分析サーバＣＰＵの制御によって、改札情報１１１を分析して、混雑状況を予測集計し、予測情報１１３、現況情報１１４としてデータベーステーブルに格納する。配信サーバ１０４は、現況情報１１４等を参照して混雑状況情報１１５を配信する。利用者端末１０５は、混雑状況情報１１５を受信し、出力手段１１７を用いて出力する。

分析サーバ１０６は、分析サーバＣＰＵ、分析サーバメモリ、分析サーバ入出力手段を備える。分析サーバメモリには、予測１１８、集計１１９、配信情報作成１２０を含む多用な処理方法を定めたプログラムを搭載し、分析サーバＣＰＵによってプログラムを実行制御する。

分析サーバ１０６の動作概要は、以下のようになる。
（１）改札情報１１１のテーブル内容から改札機ＩＤをキーとして集計し、改札機ごとの混雑状況を現況情報１１４のテーブルに格納する。
（２）あらかじめ用意した時刻のルックアップテーブル、あるいは、時刻の１次関数を用いて、改札通過時刻によって、定期券区間の発駅か着駅か他の駅かを乗客の予定降車駅として定める。
（３）乗車駅、予定降車駅および／あるいは途中駅における滞留予定時刻および滞留予定時間を計算し、予測情報１１３のテーブルに格納する。予測情報１１３のテーブルに格納された滞留予定時間の合計を計算し、駅ごとおよび／あるいは時間帯ごとの混雑状況を現況情報１１４のテーブルに格納する。
（４）運行情報によって指定された路線情報をキーとして、予測情報１１３のテーブルに格納した滞留時間に運転再開までの見込み時間を加算して予測情報１１３のレコードを更新する。
（５）現況情報１１４のテーブルで時間帯ごとの混雑状況と、あらかじめ登録した駅ごとの滞留限界人数と比較して、どの時間帯になると滞留限界を超えるかを調べ、注意フラグをセットする。
（６）注意フラグが立っている場合に利用者端末１０５においてシステム利用者に注意喚起を促すことができる。

次に、図２〜図５を用いて、データベースの構造とデータ例を示す。

図２は、改札情報テーブル２０１の構造とデータ例を示す図である。

改札情報テーブル２０１は、改札情報集信サーバ１０３により、改札情報１１１のデータベースに格納される。改札情報テーブル２０１は、ｃＩＤ２０２、乗車駅ＩＤ２０３、改札機ＩＤ２０４、改札時刻２０５、定期券区間２０６、出入２０７、属性２０８のフィールドを備える。ｃＩＤ２０２は、１件の改札情報を一意に特定するＩＤであり、例えば非接触ＩＣカード乗車券のカード番号であってもよいし、ＩＤ連携技術などを用いてカード番号から変換された別体系のＩＤ番号であってもよい。属性２０８フィールドは、非接触ＩＣカード乗車券の乗車履歴情報や、管理情報サーバ１０７を検索することによって得られる管理情報１１２の一部等を格納する。

図３は、予測情報テーブル２０９の構造とデータ例を示す図である。

予測情報テーブル２０９は、予測情報１１３のデータベースに格納する。予測情報テーブル２０９は、ｒＩＤ２１０、駅ＩＤ２１１、入場時刻２１２、滞留予想時間２１３、算出源２１４、運行条件２１５、属性２１６のフィールドを備える。ｒＩＤ２１０フィールドは１件の予測情報を一意に特定するＩＤである。算出源２１４フィールドには、そのレコードの予測情報を生成する元になった改札情報を特定する情報やｃＩＤ２０２を格納する。運行条件２１５には予測の前提となる運行経路情報を格納する。

図２（ｃ）は、現況情報テーブルＡ２１７の構造とデータ例を示す図である。

現況情報テーブルＡ２１７は、現況情報１１４のデータベースに格納する。現況情報テーブルＡ２１７は、主に改札機単位集計に用いるテーブルであり、ｇＩＤ２１８、駅ＩＤ２１９、改札機ＩＤ２２０、入２２１、出２２２、時刻２２３、注意フラグ２２４、属性２２５のフィールドを備える。ｇＩＤ２１８フィールドはレコードを一意に特定するＩＤである。属性２２５フィールドには集計時刻、関係情報等を格納する。

図２（ｄ）は、現況情報テーブルＢ２２６の構造とデータ例を示す図である。

現況情報テーブルＢ２２６は、現況情報１１４のデータベースに格納する。現況情報テーブルＢ２２６は、主に駅単位集計に用いるテーブルであり、ｓＩＤ２２７、駅ＩＤ２２８、滞留限界２２９、注意フラグ２３０、滞留人数２３１、５分後２３２、１０分後２３３、１５分後２３４、属性２３５のフィールドを備える。ｓＩＤ２２７はレコードを一意に特定するＩＤである。属性２３５フィールドには集計時刻、信頼性情報、予測精度、関係情報等を格納する。

図３に分析サーバ１０６の詳細な構成を示す。

分析サーバ１０６は、メモリ３０５上に予測１１８、集計１１９、異常時補正３０６、行動仮説シナリオ処理３０７、蓄積分析３０８、配信情報作成１２０のそれぞれの処理方法を記述したプログラム、および、バッファ等の作業領域を備え、ＣＰＵ３０１の制御によって処理を実行する。分析サーバ１０６は、その入力手段３０３あるいは出力手段３０４を用いて、運行情報３１１、経路情報３１２、実績情報と分析情報を含む実績分析情報３１１等を入出力する。実績情報３１１のデータベースは、分析サーバディスク３０２に備えてもよいし、管理情報サーバ１０７の計算機ディスク上に備えてもよい。分析サーバ１０６は、改札情報集信サーバ１０３の出力する改札情報１１１を受信し、メモリ３０５あるいはディスク３０２上に、予測情報３０９、現況情報３１０、分析情報３１１等を作成する。

改札情報１１１は分析サーバ１０６の入力手段３０３ではバッファリングを伴うリアルタイムストリーム情報として扱い、連続的、不規則に、受信する。分析サーバ１０６では、バッファ内の複数の改札情報を１件ずつあるいは複数件取り出して予測１１８、集計１１９等の処理を行う。運行情報３１１に変化があれば異常時補正３０６の処理を行う。配信情報作成１２０によって現況情報３１０等を出力する。

図３では、Ａ駅とＣ駅間の定期券を持つ乗客がＡ駅に入場した場合の改札情報を処理する場合を例示している。行動仮説シナリオ３０７によって、この乗客はＣ駅で下車し、５人分の動きと解釈評価する。ただし、必ずしもすべての乗車券が定期券ではないため、全体の推計を要する。経路情報３１２は、途中駅を含む路線のグラフ構造３１５、時刻表、各駅での標準乗り継ぎ時間、構内徒歩時間を含む情報であり、保持管理する。

経路情報３１２を参照し、予測１１８処理は、各駅の滞在予想時間３１４をまとめる。集計１１９処理に際しては、実際の集計結果人数を５倍に評価して出力する。さらに、異常発生時には、管理者が管理者端末１０９を操作して入力手段１１６によって、ｎ線が０８：３０−０８：４５の時間帯において運転停止する入力を行う。さらに、その入力内容を管理情報１１２内の運行情報としてデータ格納し、さらに、運行情報３１１として分析サーバ１０６にも伝えることによって、異常時においても適切に分析集計できる。

実績分析情報３１１の保存、作成は、分析サーバ１０６の蓄積分析処理３０８による。多数の乗客について、改札情報１１１を元に乗車下車回数実績値を集計する。定期券区間の駅を含めてもよい。その集計において、個人ごと個々の駅での乗下車回数実績値は、それらの総和で除算して発生頻度の数値に変換してから、分析情報として格納する。分析情報は、ｃＩＤ，乗車駅ＩＤ，下車駅ＩＤ，発生頻度（％）という形式のレコード集合であって、改札情報テーブル２０１のそれぞれのＩＤ番号と関係付ける。仮にｃＩＤを含めなければレコード数が駅ＩＤの総数の２乗分となり、ｃＩＤを含めれば乗客数のオーダを更に乗算する件数規模となる。さらに他の属性を含めてもよい。

乗車下車駅の利用回数分布は大きく偏るため、実績情報を参照すればより精度よく予測処理ができる。実績情報は大きな索引規模を持つため検索利用時にも相応の計算時間を要する。しかし、本実施例では、改札情報の中の定期券情報を利用することによって実績情報の参照頻度を限定するので、処理高速化できる。すなわち、改札情報リアルタイムストリーム処理全体を効率的に処理できる。

改札情報の分析、集計処理を円滑化することによって、計算資源に余裕が生じ、集計頻度を高くすることや重点的なケースを詳細分析することなどで計算資源を適正利用できる。さらに、現況を把握する上でより最新の情報が得られる。それは設備機器の適正制御、構内環境の適正化、混雑緩和による乗客サービス向上、システム利用者のシステム使い勝手向上などに寄与する。

図４は、分析サーバ１０６の予測処理１１８の処理手順を詳細に示す図である。

分析サーバ１０６では、ステップ４０１でバッファメモリなどの初期化を行った後、連続的にストリーム入力される改札情報１１１に対して、ステップ４０２において下記の予測処理を繰り返し制御する。

１．ステップ４０３において、改札情報１１１を読み込む。

２．ステップ４０４において、入場時に改札情報テーブル２０１の乗車駅ＩＤ、改札時刻を含む情報を用いて予想目的駅を推定する。推定手段の詳細は後述する。

３．ステップ４０５において、経路情報３１２を参照し、乗車駅と予想目的駅の経路を得る。乗車駅（出発駅）、乗換駅、予想目的駅それぞれについて、到着予定時刻、滞留予想時間、経路となる路線名を取得する。この乗客の到着予定時刻に対して、時刻表情報に含む直近の電車時刻との差分として滞留予想時間を計算してもよいし、あらかじめ経路情報３１２に駅ごとの固定値を登録しておいた値を滞留予想時間として利用してもよいし、両者を組み合わせて計算してもよい。

４．ステップ４０６において、予測情報テーブル２０９に駅ごとの入場時刻２１２（到着予定時刻という予測値と改札情報の実測値を総称する）、滞留予想時間２１３の情報を格納する。

５．ステップ４０７において、改札情報、予測情報、時刻を実績情報３１１として蓄積する。退場時も実績情報として分析蓄積処理する。

６．ステップ４０８において、時刻参照し、一定件数処理するごとに、あるいは定期的に、時刻が古いレコードなどの不要レコードを更新、消去する。ステップ４０８においては、改札情報が退場出札、すなわち改札を出たレコードが入った場合に、改札情報のｃＩＤ２０２の値と一致する算出源２１４フィールドの値を持つ予測情報は消去する。さらに、テーブル間の関係を追跡して、現況情報テーブルＢ（駅単位集計）における関係駅での滞留人数２３１等の集計値を１減算してもよい。古いレコードを適切に無効化することにより、分析精度が高まる上に、分析や集計に寄与しない処理対象データ件数が減るので、分析、集計処理が高速化、高頻度化して、よりリアルタイムな状況把握ができるようになる。

図５は、分析サーバ１０６の集計処理１１９の処理手順を詳細に示す図である。

ステップ５０１でバッファメモリなどの初期化を行った後、ステップ５０２において、改札情報および予測情報に対して定期的に下記の集計処理を繰り返し制御することによって、混雑状況の現況をまとめる。

ステップ５０３において、運行情報取得する。

ステップ５０４において、もし、運行情報に更新があれば、ステップ５０５において、異常時処理を行う。

ステップ５０６において、個々の改札機（改札機ＩＤ、駅ＩＤ）に対して次の繰り返し処理を行う。

ステップ５０７において、特定の改札機ＩＤ、駅ＩＤに対するレコードを改札情報テーブルから検索して、所定の集計時間範囲（例えば１分など）での入出の人数を集計する。集計時間範囲の情報は、あらかじめ平時の値を調べた数値をメモリ等に格納しておき、異常時状況に応じて変更する。集計時間範囲は、運行情報３１１に含まれる時間を加算してもよいし、管理者端末１０９の入力手段１１６で指定する時間範囲に応じて変化させてもよい。さらに、特定の改札機ＩＤ、駅ＩＤに対応するレコードとして、集計結果を現況情報テーブルＡ（改札機単位集計）に格納する。

ステップ５０８において、個々の駅（駅ＩＤ）に対して次の繰り返し処理を行う。

ステップ５１５において、予測情報テーブル２０９を検索し、滞留人数を集計する。現況情報テーブルＡ（駅単位集計）に集計結果を格納する。

ステップ５０９において、現況情報テーブルを全件検索し、改札機の入出人数の差分値、滞留人数を現況情報として取得する。

ステップ５１０において、現況情報テーブルＡ２１７、現況情報テーブルＢ２１８の特定のレコードで、現況情報と比較情報を比べて必要な対応を行う。比較情報は改札機の入出差分値などの適正値として、駅ごとや改札機ごとにあらかじめ定めた固定値でもよい。比較情報は滞留限界２２９でもよい。あるいは、滞留人数の値について、それらの時間的推移を示す微分値あるいは２階微分値として現況情報評価値として計算し、その現況情報評価値が比較情報より大きいかを比較してもよい。現況情報評価値を用いると、時間的推移が加速度的に状況悪化する場合などを敏感に検知できるため、適切な対応ができる。

さらに、ステップ５１０において、もし、滞留人数情報が比較情報と比べて大きければ、ステップ５１１において、注意フラグ２２４および／あるいは注意フラグ２３４をセットする。比較情報は、実績情報から取得する過去の値でもよいし、実績情報の平均値や分析予測値を用いてもよい。定期券を持つ乗客は全体の一部なので、現況情報の示す人数に対して適当な可変数値あるいは固定数値を掛けた数値を計算し、その計算結果と比較してもよい。

ステップ５１２において、現況情報を元に配信情報を作成して、配信サーバ１０４に送信する。配信情報がそのまま利用者端末１０５に届く混雑状況情報１１５であってもよい。

ステップ５１３において、現況情報、集計時刻などを実績情報として蓄積する。

ステップ５１４において、タイマで現在時刻を参照して、定期的にレコード登録時刻が古いレコードを検索、消去する。レコード登録時刻は、属性フィールド２０８などに格納しておいてもよい。これはステップ４０８での処理と同様であって、不要なレコードを適切に無効化することにより、集計結果の有効性が高まる。さらに、分析や集計に寄与しない処理対象データ件数が減るので、集計処理が高速化、高頻度化して、よりリアルタイムな状況把握ができるようになる。

集計を定期的に行うサイクルは１分おきであってもよいし、リアルタイム処理ならなおよい。鉄道を利用中、駅構内、あるいは、これから利用しようとする人は、鉄道網全体として広域に分散して多数存在する。全体としてみると、情報伝達が数秒の差であっても行動選択が左右されうる人数は多い。リアルタイムに状況把握できれば、より適切な混雑状況等の情報配信を行い、乗客に対して少し待つことを促したり、迂回路の推奨などを行うことができるので、駅構内の混雑状況の緩和、適正化に寄与する。情報配信では、利用者端末の出力手段に応じて、放送、メール、ツィッター、音などが利用できる。

図６は、分析サーバ１０６の異常時補正処理３０６の処理手順を示す図である。

分析サーバ１０６にて、運行情報３１１の入力や変化を受けて、下記の異常時処理を行う。

ステップ６０１において、運行情報３１１を読み込む。運行情報３１１には、運転停止路線情報、運転再開見込み時間情報、遅れ時間情報、原因情報などがある。

ステップ６０２において、予測情報テーブル２０９の運行条件２１５に対して、運転停止路線情報をキーとして、運転停止で影響があるレコードを全件抽出する。

ステップ６０３において、運転停止で影響があるレコードに対して、経路情報３１２を参照して、代替ルートに進む乗客を選定し、当該乗客に関わる予測内容を変更する。目的地が同じままで別の鉄道経路に進むケースでは、途中駅のレコードの駅ＩＤと滞留時間を経路情報内容を使って更新する。選定は統計的、ランダム的であってもよいし、「代替ルートに乗り換えて迂回して目的地に向かう時間が運転再開を単純に待つ時間よりも短かい人は迂回する」などのルールを設けて選定してもよい。鉄道から出て代替輸送手段を選ぶ乗客のレコードは、改札を出る時点での改札情報内容が予測情報テーブルに反映されて削除される。経路情報３１２には、発駅と着駅に対応して、バス代替輸送ケースを含めた経由路線、途中駅、経由時間、駅滞留時間、優先順位の情報が複数件得られるよう、あらかじめ作成、登録しておく。経路情報３１２から、運行情報で指定された運転停止路線を含まずに優先順位最大となる経路を検索し、当該乗客の予測処理をやり直す、あるいは、絞込み対象から除外する。統計的に一定割合でレコードを絞り込んでもよい。

ステップ６０４において、滞留予想時間に運転再開見込み時間を加算して、予測情報テーブルを更新する。集計時間範囲の情報に対して、所定の値に復旧見込み時間を加算した値に更新する。運行情報の指定によって平時に戻れば、所定の値を用いる。

ステップ６０５において、現況情報テーブルを再度集計する。

ステップ６０６において、滞留限界を確認する。具体的には、現況情報テーブルの５分後等の予測を示すフィールド値と、滞留限界フィールドのあらかじめ定めた値を比較確認する。

ステップ６０７において、現況情報テーブルを検索し、滞留限界２２９と現状値や予測値の比較を行う。予測値は滞留人数２３１、５分後２３２などのフィールドの値を用いる。近々、滞留限界を超える駅があれば、ステップ６０７において、現況情報テーブルの注意フラグを設定する。

ステップ６０８において、更新前後の情報を実績情報として蓄積する。

ステップ６０９において、配信情報を再作成する。注意フラグを監視する利用者端末や利用者情報、配信方法等をあらかじめ配信サーバに登録しておく。注意フラグが立っていれば、利用者端末に対して警告をＰＵＳＨ送信するよう、分析サーバから配信サーバに信号を送信し、配信サーバによって即時配信処理がなされる。

図７は、混雑状況情報の配信サーバ１０４の構成を示す図である。

配信サーバ１０４は計算機であり、配信サーバメモリ内に搭載した機器管理７０１、限定受信（ＰＵＳＨ）７０２、状況照会（ＰＵＬＬ）７０３、注意フラグ確認７０４、利用者画面構成７０５の処理手順を定義した機能モジュールを備える。それぞれの機能モジュールは、配信サーバＣＰＵの制御により実行する。配信サーバ入力手段を用いて現況情報３１０および管理情報１１２を取得し、配信サーバ出力手段を用いて利用者端末１０５に対して情報配信する。管理情報１１２には、車両応荷重、過去状況、分析情報、地図、添付情報、誘導情報等が含まれる。

利用者端末１０５は入力手段７０６、モニタ７０７などの出力手段を備える。利用者は駅員、乗客、あるいは、一般人である。利用者は入力手段７０６を用いて、配信サーバ１０４に送信要求を送る。配信サーバ１０４では、状況照会（ＰＵＬＬ）７０３の処理によって、要求された情報を利用者端末１０５に返信し、モニタ７０７に出力する。

限定受信（ＰＵＳＨ）７０２では、現況情報を利用者端末１０５にリアルタイムに逐次送信あるいは放送する。

注意フラグ確認７０４処理によって、分析サーバ１０６の注意喚起要求６０９からの受信があるかを監視し、注意フラグが立てば利用者端末に対して情報を配信し、画面の配色を反転させたり、警告音を鳴らせたりして、利用者の注意喚起を促す。画面の配色反転は利用者画面構成７０５の中で行う。

配信情報は、利用者端末入力手段を用いて受信され、モニタ等の利用者端末出力手段を用いて利用者端末に出力される。配信される管理情報には、車両応荷重、過去状況、分析情報、地図、店舗情報、誘導情報、その他の情報がある。

機器管理機能は、利用者端末や設備機器の登録、ユーザ管理、全体制御などを行う。

情報配信を行う機能として、限定受信（ＰＵＳＨ）機能、状況照会（ＰＵＬＬ）機能があり、連続的あるいは不定期に配信サーバ側から利用者端末クライアントに配信情報を配信する。放送でもよい。利用者の利用者端末操作によって、注意フラグ確認機能を利用すると、注意フラグが立った場合に配信サーバから警告情報をＰＵＳＨ送信させる制御を行う。警告情報は文字や画像としてモニタに出力してもよいし、利用者端末出力手段として備えるスピーカから警告音等を発して、利用者の注意を促してもよい。

配信情報を設備制御装置に配信し、改札機戸開閉やエレベータ停止などの設備制御を行うと、滞留する乗客を適切に誘導できる。例えば、分析サーバ１０６は、注意フラグ２２４あるいは注意フラグ２３０を常時監視しておくステップ、および、注意フラグが立っている場合７０４に、改札機ＩＤを含む混雑状況情報を配信サーバに送信するステップを分析サーバメモリに格納して、分析サーバＣＰＵが制御する。同様に、配信サーバ１０４は、混雑状況情報を受信した場合に、改札機ＩＤに対応する改札機の開閉制御信号を制御監視サーバに送信する。改札機は、開閉制御信号を受信した場合に開閉戸を動作する手段を備えておく。このような構成と作用によって、混雑が予想される改札機では、前記開閉制御信号を受信した場合に、特定方向の開閉戸を適切に制御できる。すなわち、単位時間あたりに改札通過可能な人数を抑制、誘導できる。

図８は、分析サーバ１０６の予測処理１１８の処理手順において、ある乗客の改札情報から、その乗客の予想目的駅を計算する方法を示す図である。加えて、ステップ４０４の処理内容の詳細を説明するものである。

発駅８０１から着駅８０２に向かう定期券を持つ乗客について、駅の属性を発駅８０１、着駅８０２、他駅８０３の３種類として構成し、それぞれを１，２，３の値で符号化する鉄道移動モデルを用いる。乗客が実際に乗り降りする乗車駅と下車駅の組み合わせは、乗車駅で下車する入場券のケースを除けば、乗客の行動パターンとして６種類である。乗客がこれから向かおうとする駅は、改札通過直後の時点で本来乗客のみが知る情報なので、それを情報システムが推定するという意味で予想目的駅と呼ぶ。

この鉄道移動モデルでは、下記のような複数の発見的規則が成り立つ。

・ＩＦ（時間帯が昼ごろで、乗車駅が定期券区間の着駅）
ＴＨＥＮ 予想目的駅は他駅（３） ＢＥＣＡＵＳＥ 出張等
・ＩＦ（時間帯が平日朝で、乗車駅が定期券区間の発駅）
ＴＨＥＮ 予想目的駅は着駅（２） ＢＥＣＡＵＳＥ 出勤等
・ＩＦ（時間帯が夜で、乗車駅が定期券区間外の駅）
ＴＨＥＮ 予想目的駅は発駅（１） ＢＥＣＡＵＳＥ 出張直帰等
これらの発見的規則を整理すると、図１２の表８０４としてまとめることができる。改札通過時刻の含まれる時間帯８０９を前半８１０と後半８１１に分けて、それぞれ、１、２と符号化する。表８０４によると、乗車駅の属性（３種類）と改札通過時刻（２種類）によって、予想目的駅は発駅（１）、着駅（２）、他駅（３）のいずれかに特定できる。

ｓ： 乗車駅の駅ＩＤ
ａ，，ｂ： 定期券区間（発駅の駅ＩＤ＝ａ、着駅の駅ＩＤ＝ｂ）
ｘ： 乗車駅の属性，ｘ＝ｆ（ｓ，ａ，ｂ）
ｔ： 改札通過時刻
ｙ： 予想目的駅ＩＤ ｙ＝ｇ（ｘ，ｔ）
時刻情報は一般に基準時刻からの差分値として表現された連続値なので、割り算による整数化などの適当な符号化手段によって、改札通過時刻は時間帯情報ｔに高速に変換できる。ｘも同様である。そこで、図９の表８０４と同内容で高速なロジックを、時間帯tの一次式として次のように、組むことができる。

すなわち、改札情報テーブル２０１において、乗車駅ＩＤ２０３と改札時刻２０５のフィールド値を用いて予想目的駅を推定できる。予想目的駅の推定には、別の多次元の表を用いてもよいし別の関数を用いてもよい。

もし、予想目的駅が他駅（３）と算出された場合、改札情報に含まれる利用駅の履歴から下車駅を推定する。あるいは、乗車駅と下車駅の改札情報を組み合わせた実績情報に基づいてあらかじめ作成した分析情報から、下車駅を推定する。まず、改札情報の乗車駅ＩＤをキーとして履歴や分析情報を検索し、下車駅ＩＤと発生頻度の組み合わせが複数件となる形で検索結果を得る。次に、この発生頻度に応じた確率で、特定の改札情報に対応づける下車駅ＩＤを選定する。例えば、検索結果の発生頻度百分率を高い順に加算していき、擬似乱数値を超える最後の発生頻度に対応する下車駅ＩＤを指定する。

特定の改札情報１件に対応する予想目的駅が他駅と判定された場合、分析情報から算出した下車駅ＩＤを予想目的駅と設定する上記の方法は、１件の改札情報に対応する一人の乗客の実際の行き先との整合性は担保されにくいものの、複数の改札情報に対応する複数の乗客の行き先分布と整合する。このため全体的な混雑状況の把握にとって有用である。

乗車券ＩＤをキーとして、その乗客がどの駅で下車する可能性が高いかを個人レベルで検索設定、あるいはシミュレーションしてもよい。その場合、単純に乗車券ＩＤをキーとする検索処理は、乗車券発行数相当の膨大なテーブル検索を伴うなど、処理時間が遅くなる場合がある。一方、上述した分析情報の形で集約した検索方法を用いると、定期券情報に基づいて、特殊設備を要することなく、高速簡便に精度よく処理結果が得られる点で効果的である。

実績情報を分析し、特定の乗客について実際の下車回数実績値順に駅を並べると、定期券の発駅、着駅での下車回数は突出し、いくつかの主要駅で中間的な値を示し、下車実績がほとんどない駅が多数並ぶというＺｉｐｆ法則に従う。本実施例では、改札時刻と定期券情報を活用することによって、突出した実績頻度を持つ発駅、着駅を予想目的駅として高速高精度に推定できる。このため、全体の処理時間が高速化される。さらに、改札情報をベースとした混雑状況をリアルタイムあるいは高速かつ精度よく集計できる。情報をまとめて提示することによって、不可視情報の可視化となり、駅員の業務効率向上、利用者、乗客の安心安全が得られる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１０１：改札機、１０３：改札情報集信サーバ、１０４：配信サーバ、分析サーバ１０６、１０７：管理情報サーバ、１０９：管理者端末、１１０：設備制御、１１１：改札情報

Claims (5)

1. 混雑状況情報集配信システムにおいて、
   開閉戸と乗車券読み取り装置を備え、乗車券から改札通過時刻、乗車駅ＩＤ、改札機ＩＤ，定期券情報を含む改札情報を取得する改札機と、
   前記改札機と接続される制御監視サーバと、
   前記制御監視サーバと接続され、前記制御監視サーバから前記改札機の情報を収集する改札情報集信サーバと、
   前記改札情報集信サーバと接続され、改札情報を分析して、混雑状況情報を計算、混雑状況情報テーブルに格納する分析サーバと、
   前記分析サーバと接続される管理情報サーバと、
   前記分析サーバと接続され、前記混雑状況情報を参照して配信する配信サーバと、を有し、
   前記分析サーバは、
   改札情報から改札機ＩＤをキーとして人数を集計し、改札機ごとの混雑状況を分析し、 前記改札情報から予定降車駅を定め、
   乗車駅、前記予定降車駅における滞留予定時間を計算し、
   前記滞留予定時間の合計を計算し、駅ごとおよび時間帯ごとの混雑状況を分析し、
   前記混雑状況と、あらかじめ登録した駅ごとの滞留限界人数と比較することによって滞留限界を超える時間帯を分析する混雑状況情報集配信システム。
2. 請求項１に記載の混雑状況情報集配信システムにおいて、
   前記管理情報サーバは、１つ以上のデータベースを備え、運行情報、経路情報、改札情報、予測情報、現況情報、実績情報、分析情報のテーブルを、事前登録および／あるいは逐次登録管理し、
   前記制御監視サーバは、１つ以上の前記改札機の制御を行い、前記改札情報を受信し、前記改札情報集信サーバは、１つ以上の前記制御監視サーバから前記改札情報を集信、蓄積し、前記改札情報を改札情報テーブルに格納する混雑状況情報配信システム。
3. 請求項２に記載の混雑状況情報集配信システムにおいて、
   運行情報は、駅ＩＤ、路線名情報、運転再開見込み時間情報を含み、
   管理情報サーバは、前記運行情報が管理情報サーバに登録されたときに前記運行情報を送信する通信を行うステップを備え、
   分析サーバは、
   前記運行情報を受信したときに、前記駅ＩＤおよび／あるいは前記路線名情報をキーとして予測情報テーブルに格納した到着時間および滞留予定時間それぞれに運転再開見込み時間を加算してレコードを更新し、
   混雑状況情報を再集計する混雑状況情報集配信システム。
4. 請求項３に記載の混雑状況情報集配信システムにおいて、
   前記改札情報は乗客の入退場情報を属性として備え、
   前期分析サーバは時間範囲情報をメモリに備え、
   前記時間範囲情報の示す範囲内で改札を出る人と入る人の差分人数を集計し、
   改札機ＩＤをキーとして混雑状況情報から滞留人数を集計する混雑状況情報集配信システム。
5. 請求項３に記載の混雑状況情報集配信システムにおいて、
   前記分析サーバは、注意フラグが立っている場合に、改札機ＩＤを含む混雑状況情報を配信サーバに送信するステップを備え、
   前記配信サーバは、混雑状況情報を受信した場合に、対応する改札機の開閉制御信号を制御監視サーバに送信するステップを備え、
   前記改札機は、前記開閉制御信号を受信した場合に開閉戸を動作させるステップ
   を備えることを特徴とした混雑状況情報集配信システム。

Images