JP2013073396A - 車両混雑状況予測システム - Google Patents

Abstract

【課題】数日間の混雑状況を平均化するだけでは、特異的な混雑状況も平均化されてしまい、実態と混雑状況が異なるケースが考えられる。
【解決手段】データベースに、電車ＩＤを記録する電車テーブルと、車両ＩＤを記録する車両テーブルと、停車駅を記録する駅テーブルと、位置ＩＤを記録する停車位置テーブルと、曜日ごと時間帯ごとの乗車率を記録する混雑状況テーブルと、を保持し、端末からアクセスを受け付けたとき、検索画面を端末に送信し、端末から、混雑状況取得依頼を受け付けたとき、データベースに基づいた駅ごと車両ごとの混雑情報を端末に送信する混雑状況予測サーバにより、達成できる。
【選択図】図３

Description

本発明は、車両混雑状況予測システムに係り、特に車両毎の混雑状況を予測する車両混雑状況予測システムに関する。

特許文献１は、混雑センサからの出力を集計して、電車の車両毎の混雑推移情報を更新し、所望の電車の現在の車両毎の混雑状況と降車駅までの車両毎の混雑推移情報を提供する技術を開示する。

特開２００７−２４９７０５号公報

しかし、特許文献１のシステムでは、直近数日間の混雑状況の推移や乗車・降車情報に基づいた混雑状況を平均化予測している。車両トラブルによる運行ダイヤの乱れや他線（他社）の運行状況、または駅周辺のイベント開催により混雑状況は異なる。数日間の混雑状況を平均化するだけでは、特異的な混雑状況も平均化されてしまい、実態と混雑状況が異なるケースが考えられる。

本発明は、上記の点に鑑みなされたもので、所望する車両の混雑状況と降車駅までの混雑推移情報を混雑事由毎に考慮した混雑推移情報を通知して、ユーザに対して乗車位置を決定させる為の判断材料を提供する。

本発明を達成する為に、車両混雑状況予測システムは、現在の混雑状況や混雑推移情報を示すデータベースを元にして混雑推移情報を更新する機能を有している。また、特異的な混雑事由毎の混雑率を算出する。車両混雑状況予測システムは、現在の車両毎の混雑状況を検知して混雑状況処理サーバに転送する。車両混雑状況予測システムは、現在の混雑状況や特異的な混雑事由など混雑推移状況を特定するために必要な情報を混雑状況処理サーバに転送する。

車両混雑状況予測システムは、混雑推移情報を保持するデータベースや運行ダイヤを保持しているデータベースを有している。車両混雑状況予測システムは、ユーザからの混雑情報要求を取得する、また、当該要求に対して乗車率情報や各車両の停車位置をユーザの携帯端末に表示する。

上述した課題は、座席位置ごとおよび立ち位置ごとに配置された人感センサと、これらの人感センサの検出結果を無線送信する送信部とを車両ごとに備える電車と、検出結果を混雑状況予測サーバに伝送する閉域通信網と、データベースに、電車ＩＤを記録する電車テーブルと、車両ＩＤを記録する車両テーブルと、停車駅を記録する駅テーブルと、位置ＩＤを記録する停車位置テーブルと、曜日ごと時間帯ごとの乗車率を記録する混雑状況テーブルと、を保持し、端末からアクセスを受け付けたとき、検索画面を端末に送信し、端末から、混雑状況取得依頼を受け付けたとき、データベースに基づいた駅ごと車両ごとの混雑情報を端末に送信する混雑状況予測サーバと、を含む車両混雑状況予測システムにより、達成できる。

本発明によれば、日々の通常運行による統計情報だけでなく、運行ダイヤ乱れなどの特異的な事象に対しても車両の混雑状況を予測する事ができる。ユーザは最適な乗車位置、乗車時間の調整、または最適な路線ルートを決定する事ができる。また、ユーザの混雑によるストレス低減や車両混雑の平均化を期待する事ができる。

車両混雑状況予測システムの構成を説明するブロック図である。 車両混雑状況モニタを説明する図である。 混雑状況予測サーバの構成を説明するブロック図である。 混雑予測処理データベース（ＤＢ）内の構成を説明する図である。 端末表示画面（検索入力画面）を説明する図である。 混雑状況の検索シーケンスを説明する図である。 混雑率更新のフローチャートである。 端末表示画面（検索結果画面）を説明する図である。 車両混雑状況予測システムの構成を説明するブロック図である。 障害タイプの分類を説明する図である。 障害時混雑処理用データベース（ＤＢ）内の構成を説明する図である。 端末表示画面（検索入力画面）を示す図である。 混雑状況検索シーケンス（トラブル発生時）図（その１）である。 混雑状況検索シーケンス（トラブル発生時）図（その２）である。 端末表示画面（検索結果画面）を説明する図である。

以下、本発明の実施の形態について、実施例を用い図面を参照しながら詳細に説明する。なお、実質同一部位には同じ参照番号を振り、説明は繰り返さない。

まず、図１ないし図８を参照して、通常運転時の車両混雑状況予測システムを説明する。
図１を参照して、車両混雑状況予測システムの構成を説明する。図１において、車両混雑状況予測システム１００は、路線１と、電車２０と、駅１０と、混雑状況予測サーバ５０と、携帯端末６０と、公衆網４０と、閉域通信網３０と、システム管理端末９０とから構成される。

路線１を運行する電車２０には、車両毎に混雑状況を検知するセンサを設置している。センサは、駅１０を出発してから一定期間モニタリングした車両毎の混雑情報を、閉域通信網３０−Ａを介して混雑状況処理サーバ５０に転送する。すなわち、電車２０は、通信システムを設置している。

混雑状況予測サーバ５０は、電車２０の車両毎の混雑情報を、閉域通信網３０−Ａを介して取得する。混雑状況予測サーバ５０は、ユーザからの混雑情報要求を、公衆網４０を介してユーザ携帯端末６０から受信する。また、混雑状況予測サーバ５０は、ユーザからの混雑情報要求に対する検索結果を、公衆網４０を介してユーザ携帯端末６０に送信する。

携帯端末６０は、電車混雑状況要求を、公衆網４０を介して混雑状況予測サーバ５０に送信する。また、電車混雑情報要求に対する検索結果について、携帯端末６０は、公衆網４０を介して混雑状況予測サーバ５０から受信する。

システム管理端末９０は、システム管理者がシステム監視情報を入手したり、また、システムの設定変更の指示要求をするために、閉域通信網３０−Ｂを介して混雑状況予測サーバ５０とデータの送受信をする。

公衆網４０は、インターネット、加入電話網、携帯電話網のいずれかである。閉域通信網３０は、利用者専用の通信網または一般の公衆網の一部を専用利用する閉域通信網である。

図２を参照して、車両混雑状況モニタを説明する。図２（ａ）において、電車２０の車両毎に人感センサ２０１を設置して混雑状況をモニタリングする。モニタリングして取得した車両混雑情報７０を、図示しない無線送信部は、無線通信で混雑状況予測サーバ５０に転送する。

図２（ｂ）において、モニタリングは、車両内のセンサ感知エリア２０２の複数ポイントに分割して、駅を出発してから一定期間モニタリングする。車両内の乗車率は、センサ感知エリア２０２の分割ポイント２０３に対して人感検出ポイント２０４の割合で算出する事ができる。

乗車率
＝人感検出ポイントの合計数／センサ感知エリアの分割ポイントの合計数×２００（％）
である。ここで、乗車率は、０％：乗車無し＜１００％：空席無し＜２００％：乗車率Ｍａｘである。なお、モニタリングの回数や周期を変更する事により、車両内の混雑情報の精度を調整する事ができる。具体的には、混雑状況を検知する人感センサ２０１と混雑状況処理サーバ５０に転送する通信システムを組み合わせて一体型の装置を作製する。電車２０の各車両の天井のセンター部に装置を設置する。装置は、車両内のセンサ感知エリア２０２をモニタリングして、検知した車両混雑情報７０を無線で混雑状況予測サーバ５０に転送する。人感センサ２０１は、車両毎の混雑情報を取得する為のセンサであり、混雑情報を取得するセンサ、設置台数、設置箇所は限定されるものではない。

図３を参照して、混雑状況予測サーバの構成と、入出力データを説明する。図３において、混雑状況予測サーバ５０は、制御部３０１と、演算部３０２と、表示部３０３と、入出力部３０４と、認証部３０５と、課金部３０６と、混雑予測処理ＤＢ８０と、障害時混雑予測処理ＢＤ８１と、（自社）運行ダイヤＤＢ８２と、（他社）運行ダイヤＤＢ８３とから構成される。なお、制御部３０１と、演算部３０２と、認証部３０５と、課金部３０６とは、図示しないＣＰＵが図示しないメモリ上のプログラムを実行することにより、実現する。

混雑状況予測サーバ５０は、閉域通信網３０−Ａと接続され、イベント情報７３、運行ダイヤ情報７２、トラブル・災害情報７１、車両混雑情報７０を受信する。混雑状況予測サーバ５０は、公衆通信網４０と接続され、端末アクセス情報７４を送受信する。

制御部３０１は、演算部３０２、表示部３０３、入出力部３０４、認証部３０５、課金部３０６の各機能を管理する。また、制御部３０１は、各機能間の連携を指示する。

演算部３０２は、制御部３０１からの指示によりユーザからの混雑情報要求７４に対する混雑率の算出や電車の運行状況（車両混雑情報７０〜イベント情報７３）に応じた混雑率の更新を実行する。また、演算部３０２は、混雑予測処理ＤＢ８０、障害時混雑予測処理ＤＢ８１、（自社）運行ダイヤＤＢ８２、（他社）運行ダイヤＤＢ８３と連携する。
表示部３０３は、ユーザからの混雑情報要求７４に対して検索入力画面や検索結果画面をユーザの携帯端末６０に表示する。

入出力部３０４は、ネットワーク３０を介して車両の運行状況に関連するトラブル・災害情報７１、車両混雑情報７０、運行ダイヤ情報２２３、イベント情報７３の入力を受け付ける。また、入出力部３０４は、ネットワーク４０を介してユーザからの混雑情報要求７４に対するデータの受け付け、および出力する。

認証部３０５は、ユーザの認証可否を行なう。ユーザ認証の方法としては、ユーザを識別する識別子とパスワードを利用する方法や携帯電話の個体の識別子とパスワードを利用する方法が考えられる。

課金部３０６は、ユーザに提供したサービスに対しての課金を行なう。なお、課金内容は、通信を行なった際の転送データ量に基づく従量課金、月極めの一定課金などが考えられる。

図４を参照して、混雑予測処理データベース（ＤＢ）を説明する。図４において、混雑予測処理データベース８０は、電車テーブル４０１と、車両テーブル４０２と、駅テーブル４０３と、停車位置テーブル４０４と、曜日テーブル４０５と、混雑状況テーブル４０６とから構成されている。

電車テーブル４０１は、電車ＩＤから構成されている。車両テーブル４０２は、電車ＩＤごとの車両ＩＤから構成されている。駅テーブル４０３は、電車ＩＤごとの停車駅ＩＤから構成されている。停車位置テーブル４０４は、車両ＩＤごとの位置ＩＤから構成されている。曜日テーブル４０５は、車両ＩＤごとの曜日から構成されている。混雑状況テーブル４０６は、車両ＩＤごと・曜日ごと・時間ごとの乗車率から構成されている。

混雑予測処理データベース８０は、各要素を階層的に関連付けられている。混雑予測処理データベース８０により、車両毎の各時間帯の乗車率を取得することができる。具体的には、電車ＩＤ（Ａ）→車両ＩＤ（１）→停車駅ＩＤ（Ａ駅）→停車位置ＩＤ（”１”）→月曜日→時刻６：３０の乗車率は、５０％である。

図５を参照して、端末表示画面（検索入力画面）を説明する。図５は、ユーザ携帯端末６０にユーザの混雑情報要求を入力する為の検索入力画面５０１である。ユーザ端末６０は、乗車日時と、乗車時間と、乗車駅と、降車駅と、Ｏｐｔｉｏｎの空席検索モードへのチェックとを、”検索ボタン”の押下により受け付け、混雑状況予測サーバ５０に送信する。なお、端末画面には現状の運行状況アナウンスを表示させて情報サービスを提供することができる。また、Ｏｐｔｉｏｎの空席検索モードへのチェックがある場合、混雑状況予測サーバ５０は、ＯｐｔｉｏｎモードＦｌａｇに”１”を設定する。

図６を参照して、通常時の混雑状況検索シーケンスを説明する。図６において、電車２０−Ａは、ｎ駅出発後の車両ごとの乗車率をセンサで検出する（Ｓ６０１）。電車２０−Ａは、混雑予測処理サーバ５０に乗車率を送信する（Ｓ６０２）。混雑予測処理サーバ５０は、混雑予測処理ＤＢを更新する（Ｓ６０３）。

ここで、携帯端末６０−Ａは、混雑予測処理サーバ５０にアクセスする（Ｓ６０４）。混雑予測処理サーバ５０は、携帯端末６０−Ａに応答を返す（Ｓ６０６）。なお、この応答には、図５の応答画面が含まれている。携帯端末６０−Ａは、検索内容を受け付ける（Ｓ６０７）。携帯端末６０−Ａは、混雑予測処理サーバ５０に混雑状況取得依頼を送信する（Ｓ６０８）。混雑予測処理サーバ５０は、運行ダイヤを検索する（Ｓ６０９）。混雑予測処理サーバ５０は、乗車駅での混雑状況検索処理を実行する（Ｓ６１０）。混雑予測処理サーバ５０は、降車駅での混雑状況検索処理を実行する（Ｓ６１１）。混雑予測処理サーバ５０は、応答内容を作成する（Ｓ６１２）。混雑予測処理サーバ５０は、携帯端末６０−Ａに混雑状況結果を送信する（Ｓ６１３）。携帯端末６０−Ａは、画面に表示して（Ｓ６１４）、終了する。

なお、ステップ６０８でＯｐｔｉｏｎ（空席検索モード）が指定されていとき、混雑予測処理サーバ５０は、ＯｐｔｉｏｎモードＦｌａｇ＝１に設定する。混雑予測処理サーバ５０は、ユーザが指示した電車の運行ダイヤを検索して、乗車駅での混雑状況を検索処理して、乗車率＞１００％の車両である場合には、後続の電車を選択して再検索を実施する。

図７を参照して、混雑予測処理サーバ５０の混雑率更新フローを説明する。混雑予測処理サーバ５０は、混雑率を更新する際、次の変数情報（ａ、ｂ、ｘ）を取得する（Ｓ７０１）。なお、混雑基準テーブルは、表１に示すようにランク”１”〜”８”の各段階に対して乗車率１０％〜２００％を定義する。

表１ 混雑基準テーブル
−−−−−−−−−−−−
Ｘ 乗車率
−−−−−−−−−−−−
１ １０％
２ ３０％
３ ５０％
４ ８０％
５ １００％
６ １２０％
７ １５０％
８ ２００％
−−−−−−−−−−−−

ここで、ａ＝混雑情報テーブルの乗車率（混雑予測処理ＤＢ８０）、ｂ＝最新の混雑情報（車両混雑情報７０）、ｘ＝混雑基準テーブルにおける”ａ”のランクである。

混雑予測処理サーバ５０は、データベース上の乗車率ａと最新の乗車率ｂの平均値ｃを演算する（Ｓ７０２）。混雑予測処理サーバ５０は、（ｃ＜ａかつｘ＝１）または（ｃ＞ａかつｘ＝８）か判定する（Ｓ７０３）。ＮＯかつｃ≦ａのとき、混雑予測処理サーバ５０は、ｃ＜混雑基準テーブル［ｘ−１］か判定する（Ｓ７０４）。ＹＥＳのとき、混雑予測処理サーバ５０は、混雑情報テーブルの乗車率に混雑基準テーブル［ｘ−１］を設定する（Ｓ７０５）。

ステップ７０３でＹＥＳのとき、ステップ７０４でＮＯのとき、または後述するステップ７０７でＮＯのとき、混雑予測処理サーバ５０は、混雑情報テーブルの乗車率に混雑基準テーブル［ｘ］を設定する（Ｓ７０６）。すなわち、混雑率の更新は発生させない。

ステップ７０３でＮＯかつｃ＞ａのとき、混雑予測処理サーバ５０は、ｃ＞混雑基準テーブル［ｘ＋１］か判定する（Ｓ７０７）。ＹＥＳのとき、混雑予測処理サーバ５０は、混雑情報テーブルの乗車率に混雑基準テーブル［ｘ＋１］を設定する（Ｓ７０８）。上述したフローにより、混雑率については、混雑基準テーブルを細分化することにより、日々の乗車率の変動を敏感に反映することができる。

図８を参照して、携帯端末の検索結果画面を説明する。図８において、携帯電話６０−Ａの検索結果画面８０１には、当該電車の車両それぞれに対する各駅出発後の乗車率を表示する。検索結果画面８０１には、駅での停車位置番号が記載されている為、ユーザはどこの乗車位置で電車を待てば、座席を確保できるのかを判断する材料が得られる。具体的には、電車Ａ２０の車両番号５にＡ駅で乗車した場合、Ａ駅では空席がなく座席を確保できなかったとしても、次駅のＢ駅では乗車率が８０％と予測される為、Ｂ駅で座席を確保できる可能性があることが分かる。

ユーザが駅１０−Ａで電車２０−Ａを待っている際、電車２０−Ａの各車両の混雑情報を入手するために、携帯端末６０−Ａから混雑状況処理サーバ５０に問い合わせる。ユーザがネットワーク（公衆網）４０を介して混雑状況予測サーバ５０にアクセスした場合、まずは車両混雑状況予測システムのサービスを提供できるユーザであるのか混雑状況処理サーバ５０の認証部３０５で確認される。ユーザ認証が可と判断された場合には、課金部３０６でユーザに対してのサービス提供の課金情報の管理が開始される。ユーザ認証する際のＩＤ＆パスワード入力やユーザが電車の混雑情報を問い合わせる際の乗車時間＆乗車駅などの入力を促す為、入出力部３０４は表示部３０３と連携して、ユーザに対して適切な入力画面を提供する。ユーザは、携帯端末６０−Ａの検索入力画面５０１を利用して、乗車日時＆乗車時間＆乗車駅＆降車駅の入力、またＯｐｔｉｏｎ（空席検索モード）をＯＮにして”検索ボタン”を押すことにより、当該条件での混雑情報を要求する。

なお、ＪＲや私鉄で現在運行中の電車２０−Ａでは、車両毎に設置されている人感センサ２０１で検出した車両混雑情報７０を、随時、混雑状況処理サーバ５０に転送している。混雑状況予測サーバ５０で受け付けられた車両混雑情報７０を元にして、制御部３０１からの指示により図４で示す混雑予測処理ＤＢ８０の情報は、図７で示す混雑率更新フローチャートに沿って更新される。現時点での電車２０−Ａの混雑情報が管理される他、今後の混雑状況についても予測処理されるデータが作成されている。

混雑状況予測サーバ５０は、ユーザからの電車の混雑情報の問い合わせに対して、混雑予測処理ＤＢ８０の情報を演算部３０２で適切な処理を実施した後に、表示部３０３で問い合わせ内容の応答例を作成する事ができる。混雑状況処理サーバ５０は、ユーザからの問い合わせに対して、ユーザが乗車する駅１０−Ａでの電車２０−Ａの最新の混雑状況、および降車するまでの途中の駅１０−Ｂ、駅１０−Ｃでの予測混雑情報を、携帯端末６０−Ａに検索結果画面８０１で示すことができる。ユーザは、この車両混雑状況予測システムのサービスを受ける事により、電車２０−Ａまたは電車２０−Ｂなどの次発以降の電車に乗車すべきかを判断する事ができる。ユーザが車両混雑状況予測システムのサービスの終了を判断した場合には、課金部３０６での管理も終了させる。

図９ないし図１４を参照して、車両混雑状況予測システムのトラブル対処を説明する。まず、図９を参照して、車両混雑状況予測システムのトラブル対処を説明する。図９は、基本的に図１と同様である。図９において、システム管理者がシステム管理端末９０を用いて、他路線で運行ダイヤ乱れが発生した場合、人身事故が発生した場合など、トラブル＿Ｆｌａｇ＝１を混雑処理サーバ５０に通知することでトラブル対処システムが適用される。

図１０を参照して、障害タイプ分類表を説明する。図１０において、障害タイプ分類表１００１は、種別記号と、タイプとから構成されている。種別記号は、ａ〜ｚのアルファベット小文字である。タイプは、障害のタイプである。具体的には、種別記号ａは、自社路線トラブルａである。

電車２０−Ａ〜２０−Ｃまたは路線１−Ａ〜１−Ｃでトラブルが発生した時、該当の障害タイプによって混雑区間や混雑時間など車両内の混雑状況はさまざまである。障害タイプを詳細に分類する事でユーザに正確な混雑情報を提供することができる。トラブル＿Ｔｙｐｅ＝”種別記号”にすることで、トラブル対処システムに当該の障害タイプでの処理方法が適用される。障害タイプとしては以下が考えられる。
・自社路線で人身事故を事由とした運行トラブルが発生した場合
・自社路線で車両トラブルを事由として運行トラブルが発生した場合
・スポーツ試合を事由として車両内混雑が発生した場合
・降雪を事由として運行ダイヤに影響が発生した場合
トラブルが発生した時の車両内混雑の予測値は、通常運行時の乗車率に対して該当の障害タイプの”掛け値”を掛け合わせることにより算出する。”掛け値”は、式１で算出する。

α＝β／θ …（式１）
ここで、α：最新の掛け値、β：過去”Ｘ”回の平均乗車率、θ：混雑状況テーブルの乗車率である。また、
β＝（β１＋β２＋…＋βｘ）／Ｘ …（式２）
である。掛け値は、当該の障害タイプの過去”Ｘ”回の平均乗車率を通常運行時の乗車率で割ることにより算出する。過去”Ｘ”回の平均乗車率は、過去の参照データが多いほど精度を上げることができる。

図１１を参照して、障害時混雑予測処理データベース（ＤＢ）を説明する。図１１において、障害時混雑予測処理データベース８１は、電車テーブル１１０１と、車両テーブル１１０２と、駅テーブル１１０３と、停車位置テーブル１１０４と、曜日テーブル１１０５と、混雑状況テーブル１１０６とから構成されている。

電車テーブル１１０１は、電車ＩＤから構成されている。車両テーブル１１０２は、電車ＩＤごとの車両ＩＤから構成されている。駅テーブル１１０３は、電車ＩＤごとの停車駅ＩＤから構成されている。停車位置テーブル１１０４は、車両ＩＤごとの位置ＩＤから構成されている。曜日テーブル１１０５は、車両ＩＤごとの月〜日曜日から構成されている。混雑状況テーブル１１０６は、曜日ごと・時間ごと・障害タイプごとの掛け値から構成されている。

障害時混雑予測処理データベース８１は、各要素を階層的に関連付けする事により、各車両の各時間帯の障害タイプの”掛け値”を取得することができる。具体的には、電車ＩＤ（Ａ）→車両ＩＤ（１）→停車駅（Ａ）→停車位置（”１”）→月曜日→時刻２３時台の自社路線トラブルａ”ａ”を事由とした”掛け値”は”１.２”である。

図１２を参照して、端末表示画面（検索入力画面）を説明する。図１２は、車両混雑状況予測システムが提供するユーザ携帯端末６０にユーザの混雑情報要求を入力する検索入力画面である。図１２において、ユーザ端末６０は、乗車日時と、乗車時間と、乗車駅と、降車駅と、Ｏｐｔｉｏｎの空席検索モードへのチェックとを、”検索ボタン”の押下により受け付け、混雑状況予測サーバ５０に送信する。なお、端末画面にはＡ駅でＡＭ６：５０に人身事故が発生していることをアナウンスして現状の運行状況を提示する。また、Ｏｐｔｉｏｎの空席検索モードへのチェックがある場合、混雑状況予測サーバ５０は、ＯｐｔｉｏｎモードＦｌａｇに”１”を設定する。

図１３を参照して、トラブル発生時の混雑状況検索シーケンスを説明する。図１３Ａにおいて、システム管理端末９０−Ａは、トラブル情報を受け付ける（Ｓ６２１）。システム管理端末９０−Ａは、混雑予測処理サーバ５０にトラブル＿Ｆｌａｇ＝１、トラブル＿Ｔｙｐｅ＝”ｘ”のトラブル発生通知を送信する（Ｓ６２２）。電車２０−Ａは、［ｎ］駅出発後の各車両の乗車率を検出する（Ｓ６２３）。電車２０−Ａは、混雑予測処理サーバ５０に乗車率を無線伝達する（Ｓ６２４）。混雑予測処理サーバ５０は、混雑処理用ＤＢ８０を更新する（Ｓ６２６）。混雑予測処理サーバ５０は、障害時混雑処理用ＤＢ８１を更新する（Ｓ６２７）。

ここで、携帯端末６０−Ａは、混雑予測処理サーバ５０にアクセスする（Ｓ６２８）。混雑予測処理サーバ５０は、携帯端末６０−Ａにトラブル情報を含む応答を送信する（Ｓ６２９）。携帯端末６０−Ａは、検索内容を受け付ける（Ｓ６３１）。携帯端末６０−Ａは、混雑予測処理サーバ５０に混雑状況取得依頼を送信する（Ｓ６３２）。なお、混雑状況取得依頼には、乗車時刻、乗車駅混雑、Ｏｐｔｉｏｎ等を含む。予測処理サーバ５０は、運行ダイヤを検索する（Ｓ６３３）。

図１３Ｂにおいて、混雑予測処理サーバ５０は、トラブル時の乗車駅での混雑状況を検索する（Ｓ６３４）。混雑予測処理サーバ５０は、降車駅までの混雑状況を検索する（Ｓ６３６）。混雑予測処理サーバ５０は、応答内容を作成する（Ｓ６３７）。混雑予測処理サーバ５０は、携帯端末６０−Ａに混雑状況応答結果を送信する（Ｓ６３８）。携帯端末６０−Ａは、受信した混雑状況応答を表示する（Ｓ６３９）。

ここで、電車２０−Ａは、［ｎ＋１］駅出発後の各車両の乗車率を検出する（Ｓ６４１）。電車２０−Ａは、混雑予測処理サーバ５０に乗車率を無線伝達する（Ｓ６４２）。混雑予測処理サーバ５０は、混雑処理用ＤＢ８０を更新する（Ｓ６４３）。混雑予測処理サーバ５０は、障害時混雑処理用ＤＢ８１を更新する（Ｓ６４４）。

ここで、システム管理端末９０−Ａは、トラブル解消情報を受け付ける（Ｓ６４６）。システム管理端末９０−Ａは、混雑予測処理サーバ５０にトラブル＿Ｆｌａｇ＝０のトラブル解消通知を送信する（Ｓ６４７）。

図１４を参照して、携帯端末の検索結果画面を説明する。図１４において、携帯電話６０−Ａの検索結果画面１４０１には、当該電車の車両それぞれに対する各駅出発後の乗車率を表示する。検索結果の表示では、ユーザはＡ駅１０−Ａに８：００の乗車時間を予定して空席検索モードを指定したが、Ａ駅１０−Ａでの人身事故の影響で車両内が混雑しており、９：１０まで電車を待たなければ空席を確保できない可能性があることが判明している。

ユーザがＡ駅１０−Ａで電車２０を待っている際、電車２０の各車両の混雑情報を入手するために、携帯端末６０から混雑状況処理サーバ５０に問い合わせる。ユーザがネットワーク（公衆網）４０を介して混雑状況予測サーバ５０にアクセスした場合、まずは車両混雑状況予測システムのサービスを提供できるユーザであるのか混雑状況処理サーバ５０の認証部３０５で確認される。ユーザ認証が可と判断された場合には、課金部３０６でユーザに対してのサービス提供の課金情報の管理が開始される。ユーザ認証する際のＩＤ＆パスワード入力やユーザが電車の混雑情報を問い合わせる際の乗車時間＆乗車駅などの入力を促す為、入出力部３０４は表示部３０３と連携して、ユーザに対して適切な入出力画面を提供する。ユーザは、携帯端末６０の検索入力画面１２０１を利用して、乗車日時＆乗車時間＆乗車駅＆降車駅の入力、またＯｐｔｉｏｎ（空席検索モード）をＯＮにして”検索ボタン”を押すことにより、当該条件での混雑情報を要求する。現在の運行状況にトラブルが発生している事を混雑処理サーバ５０に通知する事で、混雑処理サーバ５０が受信した内容を検索入力画面１２０１にアナウンスする事ができる。

なお、ＪＲや私鉄で現在運行中の電車２０では、車両毎に設置されている人感センサ２０１センサで検出した車両混雑情報７０を、随時、混雑状況処理サーバ５０に転送している。混雑状況予測サーバ５０で受け付けられた車両混雑情報７０を元にして、制御部３０１からの指示により図４で示す混雑予測処理ＤＢ８０の情報は、図７で示す混雑率更新フローチャートに沿って更新される。また、図１１で示す障害時混雑処理用ＤＢ８１の情報は、式１で示す”掛け値”の計算式で更新される。現時点での電車２０の混雑情報が管理される他、今後の混雑状況についても予測処理されるデータが作成されている。

混雑状況予測サーバ５０は、ユーザからの電車の混雑情報の問い合わせに対して、混雑予測処理ＤＢ８０、障害時混雑予測処理ＤＢ８１の情報を演算部３０２で適切な処理を実施した後に、表示部３０３で問い合わせ内容の応答を作成する。混雑状況処理サーバ５０は、ユーザからの問い合わせに対して、ユーザが乗車するＡ駅１０−Ａでの電車２０の最新の混雑状況、および降車するまでの途中のＢ駅１０−Ｂ、Ｃ駅１０−Ｃでの予測混雑情報を、携帯端末６０に検索結果画面１４０１で示す。ユーザは、この車両混雑状況予測システムのサービスを受ける事により、電車２０−Ａまたは電車２０−Ｂなどの次発以降の電車に乗車すべきかを判断する。ユーザが車両混雑状況予測システムのサービスの終了を判断した場合には、課金部３０６での管理も終了させる。

１…路線、１０…駅、２０…電車、３０…閉域通信網、４０…公衆網、５０…混雑状況予測サーバ、６０…携帯端末、８０…混雑予測処理ＤＢ、８１…障害時混雑予測処理ＢＤ、８２…（自社）運行ダイヤＤＢ、８３…（他社）運行ダイヤＤＢ、９０…システム管理端末、１００…車両混雑状況予測システム、３０１…制御部、３０２…演算部、３０３…表示部、３０４…入出力部、３０５…認証部、３０６…課金部。

Claims (4)

1. 座席位置ごとおよび立ち位置ごとに配置された人感センサと、これらの人感センサの検出結果を無線送信する送信部とを車両ごとに備える電車と、
   前記検出結果を混雑状況予測サーバに伝送する閉域通信網と、
   データベースに、電車ＩＤを記録する電車テーブルと、車両ＩＤを記録する車両テーブルと、停車駅を記録する駅テーブルと、位置ＩＤを記録する停車位置テーブルと、曜日ごと時間帯ごとの乗車率を記録する混雑状況テーブルと、を保持し、端末からアクセスを受け付けたとき、検索画面を前記端末に送信し、前記端末から、混雑状況取得依頼を受け付けたとき、前記データベースに基づいた駅ごと車両ごとの混雑情報を前記端末に送信する前記混雑状況予測サーバと、を含む車両混雑状況予測システム。
2. 請求項１に記載の車両混雑状況予測システムであって、
   前記混雑状況取得依頼に空席検索指示が含まれているとき、前記前記混雑状況予測サーバは、乗車駅から座れると判定した電車について、駅ごと車両ごとの混雑情報を前記端末に送信することを特徴とする車両混雑状況予測システム。
3. 請求項１に記載の車両混雑状況予測システムであって、
   さらに、前記混雑状況予測サーバにトラブル情報を送信する管理端末を含み、
   前記混雑状況予測サーバは、前記管理端末からトラブル情報を受信したとき、かつ前記端末からアクセスを受け付けたとき、トラブルを通知する検索画面を前記端末に送信することを特徴とする車両混雑状況予測システム。
4. 請求項３に記載の車両混雑状況予測システムであって、
   前記混雑状況予測サーバは、前記端末から、混雑状況取得依頼を受け付けたとき、前記トラブル情報を加味した駅ごと車両ごとの混雑情報を前記端末に送信することを特徴とする車両混雑状況予測システム。

Images