案内情報配信システム
【課題】駅員の所在地に応じて情報に優先順位をつけて配信する案内情報配信システムを提供する。
【解決手段】複数の駅員がそれぞれ携帯する携帯端末５０ａ〜５０ｘと、携帯端末の識別情報が書き込まれた無線ＩＣタグ（携帯端末（ＲＦタグ））５０ｑと、駅構内の管理区域境界に設置され当該管理区域を出入りする駅員が所持する無線ＩＣタグから携帯端末の識別情報を読み込む複数のタグリーダ４０ａ〜４０ｓと、列車の運転情報を管理する運行状況管理サーバ２０と、タグリーダからの情報を収集して携帯端末の所在地を把握すると共に、運転情報を得て、この運転情報を携帯端末の所在地に基づく所定の優先順位に基づいて重み付けをして管理区域毎の表示データに編集し、これを携帯端末に配信する所在地管理サーバ３０とを備える。
【解決手段】複数の駅員がそれぞれ携帯する携帯端末５０ａ〜５０ｘと、携帯端末の識別情報が書き込まれた無線ＩＣタグ（携帯端末（ＲＦタグ））５０ｑと、駅構内の管理区域境界に設置され当該管理区域を出入りする駅員が所持する無線ＩＣタグから携帯端末の識別情報を読み込む複数のタグリーダ４０ａ〜４０ｓと、列車の運転情報を管理する運行状況管理サーバ２０と、タグリーダからの情報を収集して携帯端末の所在地を把握すると共に、運転情報を得て、この運転情報を携帯端末の所在地に基づく所定の優先順位に基づいて重み付けをして管理区域毎の表示データに編集し、これを携帯端末に配信する所在地管理サーバ３０とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータのデータベース管理技術、無線ＩＣタグ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｔｕｇ、以下“ＲＦＩＤタグ”と称す）と無線ＬＡＮ制御通信技術を鉄道分野に適用し、鉄道の駅に散在する複数の駅員に対し旅客案内に必要な種々な情報を各駅員の所在位置に応じて重み付けしたものを配信する案内情報配信システムに関する。
【背景技術】
【０００２】
鉄道の運行に乱れがある場合などに、駅員が旅客から列車の運転状況について質問を受けることがある。この場合、実際の運行状況に合致した案内を適切に行うために駅員に対しリアルタイムな運行状況を与える必要がある。従来、駅員に携帯端末を持たせ、案内サーバからその携帯端末に運行状況などの情報を送信し、当該携帯端末画面に表示させることにより旅客に対する案内情報の提供をスムーズに行い、サービス向上を図る案内情報配信システムが提案されている。このシステムにおいては、駅特定手段により輸送手配に関する伝達情報の配信先とする駅社員携帯端末が決定され配信されることにより、駅員は自分に必要な情報のみを知ることができる（例えば、特許文献１参照）。
【０００３】
【特許文献１】特開２００６−１２３７８０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の案内情報配信システムは、駅特定手段により配信先を決定し各駅毎に使用価値の高い情報を配信している。そのため、同一の駅においても駅員の位置する場所（以下、“所在地”と称す）により必要となる情報の優先度が異なるにもかかわらず、全ての駅員に対して均一な情報しか提供できないという問題があった。
【０００５】
この発明は、上述の課題を解決するためになされたもので、駅員の所在地により提供する情報の優先順位を決定し、適切な情報を優先的に表示することができる案内情報配信システムを得るものである。
【課題を解決するための手段】
【０００６】
上述した課題を解決し、目的を達成するために、本発明の案内情報配信システムは、駅構内にて駅員の携帯端末に表示データを配信する案内情報配信システムであり、複数の駅員がそれぞれ携帯する携帯端末と、携帯端末と共に移動し携帯端末の識別情報が書き込まれた無線ＩＣタグと、駅構内の管理区域境界に設置され当該管理区域を出入りする駅員が所持する無線ＩＣタグから携帯端末の識別情報を読み込む複数のタグリーダと、列車の運転情報を管理する運行状況管理サーバと、タグリーダからの情報を収集して携帯端末の所在地を把握すると共に、運転情報を得て、この運転情報を、携帯端末の所在地に基づく所定の優先順位に基づいて重み付けをして管理区域毎の表示データに編集して携帯端末に配信する所在地管理サーバとを備えたことを特徴とする。
【発明の効果】
【０００７】
この発明によれば、所在地管理サーバは、タグリーダからの情報を収集して携帯端末の所在地（すなわち、駅員の所在地）を把握しており、また、運行状況管理サーバから運転情報を得て、この運転情報を、携帯端末の所在地に基づく所定の優先順位に基づいて重み付けをして管理区域毎の表示データに編集して携帯端末に配信するので、駅員の所在地により提供する情報の優先順位が決定され、適切な情報を優先的に表示することができる。
【発明を実施するための最良の形態】
【０００８】
以下に、本発明にかかる案内情報配信システムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【０００９】
実施の形態１．
図１は本発明の実施の形態１における案内情報配信システムのシステム構成図である。図１において、運行管理システム１０（Ａ線用システムを１０ａ、Ｂ線用を１０ｂ、以下同様にＮ線用システムを１０ｎとする。以下、総称して用いる場合、単に“１０”、どれか一つ、特に特定せず運行管理システムとして用いる場合“１０ｉ”とする。）は、列車の運行を管理する制御用コンピュータを中心に構成されている。この運行管理システム１０は、列車の在線位置を追跡し、信号機等を制御する計算機システムである。
【００１０】
運行状況管理サーバ２０は、鉄道事業者が有する各路線の運行管理システム１０ｉから得られる管理対象列車の運転情報を全路線分受信し管理する計算機である。同時に、運行状況管理サーバ２０は、各線区の運行管理システム１０ｉが保持しているダイヤ情報を入手して管理し、そのダイヤ情報をもとに列車の遅延状況を管理する機能を有する。
【００１１】
駅構内には、所在地管理サーバ３０、タグリーダ４０及び携帯端末５０が配置されている。所在地管理サーバ３０は本発明の中心的な計算機システムであり、サーバ機またはパーソナルコンピュータで構成される。タグリーダ４０は、予め論理的に決められた駅構造における閉区間の境界上に設けられた出入り口に複数設置され、所在地管理サーバ３０に駅構内ネットワーク６０を介して接続される。携帯端末５０は、無線ＬＡＮ通信モジュールとＲＦＩＤタグを内蔵して駅員に運転に関する情報を表示する。
【００１２】
図２は運行状況管理サーバ２０の論理構造略図である。図２において、運行状況管理サーバ２０は、受信処理部２０ａ、データ整形処理部２０ｂ、統合予測ダイヤ生成処理部２０ｃ、駅（所在地管理サーバ３０）への運転情報配信処理部２０ｄ、駅（所在地管理サーバ３０）からの要求受信処理部２０ｅ、及び運行管理システムに対する情報要求処理部２０ｆの各処理部を有している。
【００１３】
また、運行状況管理サーバ２０は更に各種データベースを管理しており、ＤＢ１ａ〜ＤＢ１ｎは図１で示される１０ａ〜１０ｎの各路線列車運行管理システムから得られる路線ごとのダイヤデータベース、ＤＢ２ａ〜ＤＢ２ｎは同様にして得られる路線毎の列車運転状況データベース、ＤＢ１はデータ整形処理部２０ｂでデータ整形され統合された全路線ダイヤデータベース（全路線データベース）、ＤＢ２はデータ整形処理部２０ｂでデータ整形され統合化された全路線運転状況データベース（全路線データベース）、ＤＢ３は統合された全路線予測ダイヤのデータベース、ＤＢ４は全路線分の緊急情報データベース、さらにＤＢ５は運行状況管理サーバに接続される機器の情報を管理する接続相手先管理データベースである。
【００１４】
図３は所在地管理サーバ３０の論理構造略図である。図３において、所在地管理サーバ３０は、所在地データ受信処理部３０ａ、運行状況管理サーバ２０からの運転情報受信処理部３０ｂ、携帯端末５０用の表示データ編集処理部３０ｃ、携帯端末５０への表示情報送信処理部３０ｄ、携帯端末５０からの要求データ受信処理部３０ｅ、及び携帯端末５０からの要求の内、中央の運行状況管理サーバ２０に入手に行く情報に対する要求発信処理部３０ｆの各処理部を有している。
【００１５】
また、所在地管理サーバ３０は各種データベースを管理しており、ＤＢ６は駅員の所在地を管理する所在地管理データベース、ＤＢ７は運行状況管理サーバ２０から得られる全路線全列車の運転情報データベース、ＤＢ８は同様に運行状況管理サーバ２０から得られる全路線に対する緊急情報のデータベース、ＤＢ９は各携帯端末で表示させる情報を保存する携帯端末表示情報データベース、及びＤＢ１０は携帯端末からの問合せを管理するデータベースである。
【００１６】
次に動作について説明する。図４は運行管理システム１０と運行状況管理サーバ２０の情報授受と概略処理内容を示すフローチャートである。図２を参照しながら図４に沿っての処理の流れについて説明する。図４において、運行管理システムは代表線区Ｉのシステム１０ｉでのみ示されているが、同一処理が他の運行管理システム１０ａ〜１０ｎにおいても同様に行われる。まず、各線区の運行管理システム１０ｉがダイヤ情報を生成したとき、あるいは列車運行途中でダイヤが乱れダイヤが変更したときに、ダイヤ情報またはダイヤ変更情報が運行状況管理サーバ２０に対し送信される（ステップＳ１０１）。
【００１７】
これに対して、運行状況管理サーバ２０では受信処理部２０ａ（図２）でこれを入手し、補助記憶装置上に配置されたダイヤデータベースＤＢ１ｉに保存する（ステップＳ２０１）。ここでダイヤデータベースはＤＢ１ａ、ＤＢ１ｂ、・・・・ＤＢ１ｎと路線数分だけ設けられており、例としている“ｉ路線”のデータベースはＤＢ１ｉである。運行状況管理サーバ２０は同様な方法で他の運行管理システム１０ａ〜１０ｎからもダイヤ情報を入手し、それぞれのダイヤデータベースＤＢ１ａ、ＤＢ１ｂ、・・・・ＤＢ１ｎに同じように格納し管理する。ここで、ダイヤ情報が線区により異なる形式を持つことがあるので必要に応じてデータ整形処理部２０ｂ（図２）の処理により全線分統一した情報項目と様式に変換し、各運行管理システムの分を合わせた全路線分の全路線ダイヤデータベースＤＢ１を生成し、統合して管理する（ステップＳ２０２）。
【００１８】
列車が対象線区上に在線すると運行管理システム１０ｉはその情報を、連動装置等鉄道信号を直接制御する機器（本発明の構成には直接関与しないため図１上での図示を省略）より入手する（ステップＳ１０２）。入手した在線情報は単にどの軌道に列車がいるかというだけの情報であるが、それを元に運行管理システム１０ｉは、ダイヤデータと照らし合わせどの軌道にどの列車いるのか特定し、その列車の動きを追跡（「列車追跡」という。）し、列車が進む進路を制御（「進路制御」という）する（ステップＳ１０３）。なお、この列車追跡によって得られた情報を本明細書では運転状況情報と呼ぶ。運行管理システム１０ｉは列車追跡・進路制御を行った後、運転状況情報を運行状況管理サーバ２０に送信する（ステップＳ１０４）。
【００１９】
運行状況管理サーバ２０は、受信処理部２０ａ（図２）で“路線ｉ”の運行管理システム１０ｉから送られて来る情報を受信し列車運転状況データベースＤＢ２ｉにてこれを保存する（ステップＳ２０３）。運行状況管理サーバ２０は同様に全線の列車運転状況データベースＤＢ２ａ〜ＤＢ２ｎを随時更新し保存する。このようにして随時更新される列車運転状況データベースＤＢ２ａ〜ＤＢ２ｎは路線によってコード体系、情報項目、情報項目の並びが異なっていることもあり得るため、データ整形処理部２０ｂ（図２）でデータ整形を行って他線区の運行状況情報と合わせて全路線運転状況データベースＤＢ２で統合し管理する（ステップＳ２０４）。
【００２０】
運行状況管理サーバ２０の統合予測ダイヤ生成処理部２０ｃ（図２）は統一形式で管理されている全路線ダイヤデータベースＤＢ１のダイヤ情報と全路線運転状況データベースＤＢ２の運行状況情報より全線区の遅延予測を行い、予測遅延時分を含んだ予測ダイヤを算出し、全線予測ダイヤデータベースＤＢ３を更新し管理する（ステップＳ２０５）。これにより、列車の運行に対する乱れの有無やその程度、またその乱れが対象線区内の他線区に及ぼす影響の範囲や度合いを一元管理することが可能になる。
【００２１】
次に本発明の中核をなす個別の駅における案内情報配信方法について２つのステップに分けて説明する。図５は所在地登録の動作を示すフローチャートである。図５に沿って、駅における所在地管理サーバ３０、ＲＦＩＤのタグリーダ４０、駅員が持つ携帯端末５０の間のデータ授受と処理の概略について説明する。
【００２２】
図５において、携帯端末５０に内蔵されるＲＦＩＤタグには、その携帯端末固有の識別番号（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ、以下、単に“ＩＤ”と略す。）を初めとする携帯端末を特定することが可能な識別情報が予め設定されていて常時電波を発信している（ステップＳ５０１）。なお、本実施の形態においては、「所在地管理サーバ３０は駅員の所在地を把握する」と表現しているが、ＲＦＩＤタグには上記にように携帯端末５０の識別情報が記録されており、所在地管理サーバ３０はタグリーダ４０からの情報を収集することにより、正確には「携帯端末５０の所在地を把握する」ものである。なお、ＲＦＩＤタグには、多くの場合、駅員の識別情報も載せることが可能であり、このように駅員の識別情報も同時にタグリーダ４０にて読み込むようにすれば、文字通り駅員の所在地を把握することもできる。ＲＦＩＤタグは、必ずしも携帯端末５０に内蔵されるものでなくともよく、常に駅員が所持して携帯端末５０と共に移動するものであればよい。
【００２３】
ここで、動作説明のために鉄道における駅の構造の一例として図６を用い説明する。各駅は通常、駅員がいる事務室、コンコース、エレベータ、エスカレータ及びプラットフォーム等の物理的あるいは建築的構造を有するが、ここでは駅員が乗客に対応する単位をコンコースとプラットフォームの単位で考える。以下、「論理的に分割された管理区域」と言う。論理的に分割された管理区域境界の要所４０ａ〜４０ｊにＲＦＩＤのタグリーダが設置される。
【００２４】
ＲＦＩＤタグの情報は、携帯端末（ここでは５０ｑ）を持った駅員が、この論理的に分割された管理区域に入るとき、または出るときにタグリーダ（ここでは４０ｑ）にかざされることによってタグリーダ４０ｑに読み取られる（ステップＳ４０１）。例えば、駅員事務所がコンコース側４０ａにあって、駅員が事務所に入る際には所有するＲＦＩＤタグをタグリーダ４０ａに読み取らせる。また、その駅員が事務所を出てＡ線プラットフォームに移動する場合には、Ａ線プラットフォームに入ったときにタグリーダ４０ｃで再び読み込ませる。こうして読み込まれる情報は、読み込まれる都度タグリーダ４０から駅構内ネットワーク６０を経由して所在地管理サーバ３０に送られる（ステップＳ４０２）。
【００２５】
所在地管理サーバ３０においては、所在地データ受信処理部３０ａ（図３）は、タグリーダ４０ｑから送られてくるＩＤ情報を受信して（ステップＳ３０１）、その都度、ＲＦＩＤタグのＩＤ情報と所在地コードを所在地管理データベースＤＢ６に登録し管理する（ステップＳ３０２）。
【００２６】
図７は運行状況管理サーバ２０から得られる情報を所在地管理サーバ３０で携帯端末情報に編集し携帯端末５０に表示させるまでの手順を示すフローチャートである。統合予測ダイヤ生成処理部２０ｃ（図２）が働いた結果得られる、列車の各駅における着発の実績と予測時刻、及び各駅における着発に関する実績と予測遅延を併せて運転情報とすると、運転情報が所在地管理サーバで編集され駅員の持つ携帯端末に配信される動作を、図７に沿って説明する。
【００２７】
運行状況管理サーバ２０は、駅への運転情報配信処理部２０ｄ（図２）を働かせて統合された全線予測ダイヤデータベースＤＢ３で管理している運転情報を定期的に接続相手先管理データベースＤＢ５を参照しながら各駅の所在地管理サーバを含む関連装置に配信している（ステップＳ２１１）。
【００２８】
駅に設置される所在地管理サーバ３０では、運転情報受信処理部３０ｂ（図３）がこれを受信し運転情報データベースＤＢ７を更新する（ステップＳ３２０ａ）。表示データ編集処理部３０ｃ（図３）では当該駅のコンコース、ホームという管理区域の単位に運転情報を編集処理する。この処理においてはコンコース、ホームの単位で案内する情報の重み付けがなされ優先度順に配列される。こうして得られる運転情報（表示データ）に対し、さらに緊急情報データベースＤＢ８の内容を検索して必要に応じて重畳し、携帯端末表示情報データベースＤＢ９が更新される（ステップＳ３２１）。
【００２９】
携帯端末表示情報編集処理を終えると携帯端末への表示情報送信処理部３０ｄ（図３）が働き、所在地管理データベースＤＢ６を参照して携帯端末表示情報データベースＤＢ９の情報が携帯端末に送り出される（ステップＳ３２２）。この場合の情報転送は常時一定周期で行われ、登録されている全携帯端末に対して送り出される。
【００３０】
以上の情報を受け取った携帯端末５０は、情報受信をブザー等で報知し、携帯端末の画面にその内容を表示する（ステップＳ５１１）。
【００３１】
ここで、携帯端末５０では得られた情報に基づき、例えば図８及び図９に示す画面を表示する。図８で、当該駅はＡ路線とＢ路線という複数の鉄道路線が出入りしている。携帯端末５０は表示部と操作部が画面上に設けられている。その内、操作部には「他線区」、「他社線」、「全線」等の情報入手用押しボタンが設けられている。「他線区」とは、仮に駅員がＡ線ホームにいればＢ線のことであり、Ａ線ホームにいればＢ線のことである。「他社線」とは当該鉄道路線がその運転先において別の鉄道路線と軌道が連結されており、双方の車両が相互に乗り入れ運転を行っているような場合の当該路線から見た他社線のことである。「全線」とは当該鉄道会社が所有する全路線のことである。
【００３２】
駅員は自ら存在する位置により必要な情報が異なっている。例えば、Ａ線区のホームにいる場合には、Ａ線区の運行状況や先着列車情報などがもっとも重要な情報となり、次に重要な情報は、同じ駅に出入りするＢ線の情報である。当該駅に出入りしていない他線区に関する情報の優先度は相対的に低くなる。同様にＢ線区のホームにいる場合には、Ｂ線区の運行状況や先着列車情報などがもっとも重要な情報となり、次に重要な情報は、同じ駅に出入りするＡ線の情報である。また各線区にいる駅員とコンコースなど共通の設備にいる駅員の間でも必要な情報が異なることが考えられる。このように駅員の所在位置に対応して重み付けされた案内情報が駅員の持つ携帯端末に送られて携帯端末画面に表示される。
【００３３】
図９はＢ路線のホームにいる駅員に対する表示例であり、メッセージ表示部分のみを示している。列車位置のグラフィック表示部分はこの例の場合、一画面で両路線分表現でき同一としている。緊急情報がＡ線用と共通な情報が表示され、Ｂ線運転情報が表示されている。
【００３４】
以上のように、本実施の形態の案内情報配信システムによれば、この発明によれば、所在地管理サーバは、タグリーダからの情報を収集して携帯端末の所在地（すなわち、駅員の所在地）を把握しており、また、運行状況管理サーバから運転情報を得て、この運転情報を、携帯端末の所在地に基づく所定の優先順位に基づいて重み付けをして管理区域毎の表示データに編集して携帯端末に配信するので、駅員の所在地により提供する情報の優先順位が決定され、適切な情報を優先的に表示することができ、これを見た駅員はコンコースやプラットフォームにおいて、旅客に対する案内情報の提供をスムーズに行い、サービス向上を図ることができる。
【００３５】
実施の形態２．
以上の実施の形態では駅員の持つ携帯端末に定期的に情報配信し携帯端末で表示するが、本実施の形態は、駅員からの照会応答も可能とする。携帯端末からの要求に応じて他の線区の情報を提供したい場合には、他線区に対しても送信することができる。このとき、複数の線区の運転情報を含め様々な情報を配信する場合には、各携帯端末の所在地に応じて優先度を付加した上で情報配信する。従って駅員の持つ携帯端末の位置を全て把握している所在地管理サーバが図１０に示すフローチャートの処理を行って、各携帯端末の位置に応じた情報を編集し、さらに緊急情報表示部に示すように限られた情報スペースを用いて全線区における情報を重畳し表示する。この場合の動作を図１０を用いて説明する。
【００３６】
駅員が図８の携帯端末画面に示される「他線区」、「他社線」あるいは「全線」等いずれかのボタンを押すと携帯端末が表示情報受信要求処理を行ない、無線ＬＡＮと駅構内ネットワーク６０を介して所在地管理サーバ３０に表示情報の受信要求をする（ステップＳ５１０）。
【００３７】
所在地管理サーバ３０は、携帯端末からの要求データ受信処理部３０ｅ（図３）で要求内容を分析し、登録すると共に携帯端末からの受信要求情報にある携帯端末ＩＤを見て所在地管理データベースＤＢ６を検索し、どこの場所にいる駅員から要求があったものか判断し、これを携帯端末からの問合せを管理する問合せ管理データベースＤＢ１０に登録する（ステップＳ３１０）。
【００３８】
所在地管理サーバ３０は、既に入手している情報で要求に対応できれば（ステップＳ３２１）の処理フローで示されるように要求携帯端末に最適な情報に編集し与えれば良いが、例えば他社線の情報を求められたときのように、対応できなければ要求発信処理部３０ｆ（図３）が働き最新の運行状況情報を得ようと運行状況管理サーバ２０に要求する（ステップＳ３１１）。
【００３９】
運行状況管理サーバ２０はこの要求に対応した運行状況情報を自ら有する全路線予測ダイヤデータベースＤＢ３を検索し（ステップＳ２１０）、要求元の所在地管理サーバ３０に送信する（ステップＳ２１１）。
【００４０】
所在地管理サーバ３０は最新の運行状況情報を受け取った後、一旦これを運転情報データベースＤＢ７に登録し（ステップＳ３２０ａ）、実施の形態１と同じように運転情報データベースＤＢ７の情報に緊急情報データベースＤＢ８を重畳して要求元の駅員の所在地に対して最適な情報に編集し、携帯端末表示情報データベースＤＢ９を更新する（ステップＳ３２１）。こうして編集された情報は、携帯端末からの問合せを管理する問合せ管理データベースＤＢ１０を見て要求元の携帯端末に送られ（ステップＳ３２２）、携帯端末の画面に内容が表示される（ステップＳ５１１）。
【００４１】
以上のように本実施の形態では、駅員は通常時常時一定間隔で自己の所在地において優先度の高い情報を受け取っている傍ら、列車乗客等の鉄道利用者からの担当範囲外の運行状況に係る問合せにも対応でき、最新の的確な案内を行うことが可能になるという効果が
得られる。
【００４２】
実施の形態３．
本発明の別の実施の形態、強制的に特定の携帯端末に対して情報を送りつけて表示をさせることも可能である。この代表例として列車運行に乱れが生じている場合などがあり、ここではこのようにして送られる情報を緊急情報と称する。以下、緊急情報が個々の駅員の携帯端末にまで伝わる処理の流れを図１１を用いて説明する。
【００４３】
“路線ｉ”で列車の運行が乱れたものとする。その際にＩ線運行管理システムで列車の運行に関する指令に携わる輸送指令員は運行管理システム１０ｉの携帯端末を用いて各種の情報入力を行うがその一つに緊急情報があり、情報入力があると運行状況管理サーバがこれを得るものとする。この場合、当然、運行管理システム１０ｉと運行状況管理サーバ２０の間で情報授受が行われるが図１１では図示を省略している。
【００４４】
緊急情報の与え方の一例として“路線ｉ”において、列車がＡ駅、Ｂ駅、Ｃ駅、・・・Ｚ駅と進んでいくものとして途中のＳ駅から先で列車が不通になった場合、Ｓ駅の行路手前のＬ駅で乗客を“路線ｊ”に迂回誘導する場合がある。この場合、“路線ｉ”の輸送指令携帯端末から緊急情報として「Ｚ駅方向路線でＳ駅―Ｚ駅が不通、Ｌ駅で“路線ｊ”に迂回」と与えると、この情報は少なくとも“路線ｉ”のＡ駅からＬ駅までのコンコースにいる駅員とＺ駅方向路線のプラットフォームにいる駅員に知らしめておく必要がある。
【００４５】
運行状況管理サーバ２０は緊急情報を得ると各駅の所在地管理サーバにこれを送る（ステップＳ１１０）。所在地管理サーバ３０では運行状況管理サーバ２０から緊急情報が送られてきたとき通常処理に対し割り込み優先的に、運転情報受信処理部３０ｂ（図３）が内容分析を行って緊急情報と判別し緊急情報データベースＤＢ８に登録する（ステップＳ３２０ｂ）。
【００４６】
その後、緊急情報データベースＤＢ８に登録された情報と所在地管理データベースＤＢ６に登録されている携帯端末の所在地情報を元に携帯端末所在地検索を行って携帯端末毎に表示させる情報編集を行って携帯端末表示情報を作成（ステップＳ３２１）し、複数の携帯端末５０ａ，５０ｂ，・・・，５０ｌの内、コンコースや該当するプラットフォームにいる駅員の持つ携帯端末に対し、駅内のネットワーク６０と無線ＬＡＮを経由し一斉送信する（ステップＳ３２２）。
【００４７】
以上のように本実施の形態では輸送指令員が運行管理システム１０ｉの指令員携帯端末を用いて伝達したい情報を入力すれば、所在地管理サーバ３０が該当情報を受けて優先的に処理を行ない配信が必要な携帯端末を選びだし、当該携帯端末に対してリアルタイム情報の配信を行うので、これを受けた駅員はコンコースや該当するプラットフォームにいる鉄道利用客に対し、より適切な案内を行えるという効果が得られる。
【産業上の利用可能性】
【００４８】
以上のように、本発明にかかる案内情報配信システムは、鉄道の駅に散在する複数の駅員に対し旅客案内に必要な各種情報を各駅員の所在位置に応じて重み付けしたものを配信するシステムに有用であり、特に、複数の鉄道会社の車両が相互に乗り入れ運転を行っているような駅において各駅員に必要な各種情報を配信するシステムに適している。
【図面の簡単な説明】
【００４９】
【図１】本発明の実施の形態１における案内情報配信システムのシステム構成図である。
【図２】図１に示す運行状況サーバの論理構造略図である。
【図３】図１に示す所在地管理サーバの論理構造略図である。
【図４】運行管理システムと運行状況サーバの情報授受と概略処理内容を示すフローチャートである。
【図５】所在地登録の動作を示すフローチャートである。
【図６】タグリーダの分布の例を示す模式図である。
【図７】運行状況管理サーバ２０から得られる情報を所在地管理サーバで携帯端末情報に編集し携帯端末に表示させるまでの手順を示すフローチャートである。
【図８】Ａ路線携帯端末の場合の画面構成例を示す図である。
【図９】Ｂ路線携帯端末の場合の画面構成例を示す図である。
【図１０】実施の形態２における携帯端末から情報要求した場合の携帯端末が情報を入手する手順を示すフローチャートである。
【図１１】実施の形態３における緊急情報送信の手順を示すフローチャートである。
【符号の説明】
【００５０】
１０ 運行管理システム
２０ 運行状況管理サーバ
２０ａ 受信処理部
２０ｂ データ整形処理部
２０ｃ 統合予測ダイヤ生成処理部
２０ｄ 運転情報配信処理部
２０ｅ 要求受信処理部
２０ｆ 情報要求処理部
３０ 所在地管理サーバ
３０ａ 所在地データ受信処理部
３０ｂ 運転情報受信処理部
３０ｃ 表示データ編集処理部
３０ｄ 表示情報送信処理部
３０ｅ 要求データ受信処理部
３０ｆ 要求発信処理部
４０ タグリーダ
５０ 携帯端末
６０ 駅構内ネットワーク
ＤＢ１ 全路線ダイヤデータベース（全路線データベース）
ＤＢ１ｉ ダイヤデータベース
ＤＢ２ 全路線運転状況データベース（全路線データベース）
ＤＢ２ｉ 列車運転状況データベース
ＤＢ３ 全線予測ダイヤデータベース
ＤＢ５ 接続相手先管理データベース
ＤＢ６ 所在地管理データベース
ＤＢ７ 運転情報データベース
ＤＢ８ 緊急情報サーバ
ＤＢ８ 緊急情報データベース
ＤＢ９ 携帯端末表示情報データベース
ＤＢ１０ 問合せ管理データベース
【技術分野】
【０００１】
本発明は、コンピュータのデータベース管理技術、無線ＩＣタグ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｔｕｇ、以下“ＲＦＩＤタグ”と称す）と無線ＬＡＮ制御通信技術を鉄道分野に適用し、鉄道の駅に散在する複数の駅員に対し旅客案内に必要な種々な情報を各駅員の所在位置に応じて重み付けしたものを配信する案内情報配信システムに関する。
【背景技術】
【０００２】
鉄道の運行に乱れがある場合などに、駅員が旅客から列車の運転状況について質問を受けることがある。この場合、実際の運行状況に合致した案内を適切に行うために駅員に対しリアルタイムな運行状況を与える必要がある。従来、駅員に携帯端末を持たせ、案内サーバからその携帯端末に運行状況などの情報を送信し、当該携帯端末画面に表示させることにより旅客に対する案内情報の提供をスムーズに行い、サービス向上を図る案内情報配信システムが提案されている。このシステムにおいては、駅特定手段により輸送手配に関する伝達情報の配信先とする駅社員携帯端末が決定され配信されることにより、駅員は自分に必要な情報のみを知ることができる（例えば、特許文献１参照）。
【０００３】
【特許文献１】特開２００６−１２３７８０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の案内情報配信システムは、駅特定手段により配信先を決定し各駅毎に使用価値の高い情報を配信している。そのため、同一の駅においても駅員の位置する場所（以下、“所在地”と称す）により必要となる情報の優先度が異なるにもかかわらず、全ての駅員に対して均一な情報しか提供できないという問題があった。
【０００５】
この発明は、上述の課題を解決するためになされたもので、駅員の所在地により提供する情報の優先順位を決定し、適切な情報を優先的に表示することができる案内情報配信システムを得るものである。
【課題を解決するための手段】
【０００６】
上述した課題を解決し、目的を達成するために、本発明の案内情報配信システムは、駅構内にて駅員の携帯端末に表示データを配信する案内情報配信システムであり、複数の駅員がそれぞれ携帯する携帯端末と、携帯端末と共に移動し携帯端末の識別情報が書き込まれた無線ＩＣタグと、駅構内の管理区域境界に設置され当該管理区域を出入りする駅員が所持する無線ＩＣタグから携帯端末の識別情報を読み込む複数のタグリーダと、列車の運転情報を管理する運行状況管理サーバと、タグリーダからの情報を収集して携帯端末の所在地を把握すると共に、運転情報を得て、この運転情報を、携帯端末の所在地に基づく所定の優先順位に基づいて重み付けをして管理区域毎の表示データに編集して携帯端末に配信する所在地管理サーバとを備えたことを特徴とする。
【発明の効果】
【０００７】
この発明によれば、所在地管理サーバは、タグリーダからの情報を収集して携帯端末の所在地（すなわち、駅員の所在地）を把握しており、また、運行状況管理サーバから運転情報を得て、この運転情報を、携帯端末の所在地に基づく所定の優先順位に基づいて重み付けをして管理区域毎の表示データに編集して携帯端末に配信するので、駅員の所在地により提供する情報の優先順位が決定され、適切な情報を優先的に表示することができる。
【発明を実施するための最良の形態】
【０００８】
以下に、本発明にかかる案内情報配信システムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【０００９】
実施の形態１．
図１は本発明の実施の形態１における案内情報配信システムのシステム構成図である。図１において、運行管理システム１０（Ａ線用システムを１０ａ、Ｂ線用を１０ｂ、以下同様にＮ線用システムを１０ｎとする。以下、総称して用いる場合、単に“１０”、どれか一つ、特に特定せず運行管理システムとして用いる場合“１０ｉ”とする。）は、列車の運行を管理する制御用コンピュータを中心に構成されている。この運行管理システム１０は、列車の在線位置を追跡し、信号機等を制御する計算機システムである。
【００１０】
運行状況管理サーバ２０は、鉄道事業者が有する各路線の運行管理システム１０ｉから得られる管理対象列車の運転情報を全路線分受信し管理する計算機である。同時に、運行状況管理サーバ２０は、各線区の運行管理システム１０ｉが保持しているダイヤ情報を入手して管理し、そのダイヤ情報をもとに列車の遅延状況を管理する機能を有する。
【００１１】
駅構内には、所在地管理サーバ３０、タグリーダ４０及び携帯端末５０が配置されている。所在地管理サーバ３０は本発明の中心的な計算機システムであり、サーバ機またはパーソナルコンピュータで構成される。タグリーダ４０は、予め論理的に決められた駅構造における閉区間の境界上に設けられた出入り口に複数設置され、所在地管理サーバ３０に駅構内ネットワーク６０を介して接続される。携帯端末５０は、無線ＬＡＮ通信モジュールとＲＦＩＤタグを内蔵して駅員に運転に関する情報を表示する。
【００１２】
図２は運行状況管理サーバ２０の論理構造略図である。図２において、運行状況管理サーバ２０は、受信処理部２０ａ、データ整形処理部２０ｂ、統合予測ダイヤ生成処理部２０ｃ、駅（所在地管理サーバ３０）への運転情報配信処理部２０ｄ、駅（所在地管理サーバ３０）からの要求受信処理部２０ｅ、及び運行管理システムに対する情報要求処理部２０ｆの各処理部を有している。
【００１３】
また、運行状況管理サーバ２０は更に各種データベースを管理しており、ＤＢ１ａ〜ＤＢ１ｎは図１で示される１０ａ〜１０ｎの各路線列車運行管理システムから得られる路線ごとのダイヤデータベース、ＤＢ２ａ〜ＤＢ２ｎは同様にして得られる路線毎の列車運転状況データベース、ＤＢ１はデータ整形処理部２０ｂでデータ整形され統合された全路線ダイヤデータベース（全路線データベース）、ＤＢ２はデータ整形処理部２０ｂでデータ整形され統合化された全路線運転状況データベース（全路線データベース）、ＤＢ３は統合された全路線予測ダイヤのデータベース、ＤＢ４は全路線分の緊急情報データベース、さらにＤＢ５は運行状況管理サーバに接続される機器の情報を管理する接続相手先管理データベースである。
【００１４】
図３は所在地管理サーバ３０の論理構造略図である。図３において、所在地管理サーバ３０は、所在地データ受信処理部３０ａ、運行状況管理サーバ２０からの運転情報受信処理部３０ｂ、携帯端末５０用の表示データ編集処理部３０ｃ、携帯端末５０への表示情報送信処理部３０ｄ、携帯端末５０からの要求データ受信処理部３０ｅ、及び携帯端末５０からの要求の内、中央の運行状況管理サーバ２０に入手に行く情報に対する要求発信処理部３０ｆの各処理部を有している。
【００１５】
また、所在地管理サーバ３０は各種データベースを管理しており、ＤＢ６は駅員の所在地を管理する所在地管理データベース、ＤＢ７は運行状況管理サーバ２０から得られる全路線全列車の運転情報データベース、ＤＢ８は同様に運行状況管理サーバ２０から得られる全路線に対する緊急情報のデータベース、ＤＢ９は各携帯端末で表示させる情報を保存する携帯端末表示情報データベース、及びＤＢ１０は携帯端末からの問合せを管理するデータベースである。
【００１６】
次に動作について説明する。図４は運行管理システム１０と運行状況管理サーバ２０の情報授受と概略処理内容を示すフローチャートである。図２を参照しながら図４に沿っての処理の流れについて説明する。図４において、運行管理システムは代表線区Ｉのシステム１０ｉでのみ示されているが、同一処理が他の運行管理システム１０ａ〜１０ｎにおいても同様に行われる。まず、各線区の運行管理システム１０ｉがダイヤ情報を生成したとき、あるいは列車運行途中でダイヤが乱れダイヤが変更したときに、ダイヤ情報またはダイヤ変更情報が運行状況管理サーバ２０に対し送信される（ステップＳ１０１）。
【００１７】
これに対して、運行状況管理サーバ２０では受信処理部２０ａ（図２）でこれを入手し、補助記憶装置上に配置されたダイヤデータベースＤＢ１ｉに保存する（ステップＳ２０１）。ここでダイヤデータベースはＤＢ１ａ、ＤＢ１ｂ、・・・・ＤＢ１ｎと路線数分だけ設けられており、例としている“ｉ路線”のデータベースはＤＢ１ｉである。運行状況管理サーバ２０は同様な方法で他の運行管理システム１０ａ〜１０ｎからもダイヤ情報を入手し、それぞれのダイヤデータベースＤＢ１ａ、ＤＢ１ｂ、・・・・ＤＢ１ｎに同じように格納し管理する。ここで、ダイヤ情報が線区により異なる形式を持つことがあるので必要に応じてデータ整形処理部２０ｂ（図２）の処理により全線分統一した情報項目と様式に変換し、各運行管理システムの分を合わせた全路線分の全路線ダイヤデータベースＤＢ１を生成し、統合して管理する（ステップＳ２０２）。
【００１８】
列車が対象線区上に在線すると運行管理システム１０ｉはその情報を、連動装置等鉄道信号を直接制御する機器（本発明の構成には直接関与しないため図１上での図示を省略）より入手する（ステップＳ１０２）。入手した在線情報は単にどの軌道に列車がいるかというだけの情報であるが、それを元に運行管理システム１０ｉは、ダイヤデータと照らし合わせどの軌道にどの列車いるのか特定し、その列車の動きを追跡（「列車追跡」という。）し、列車が進む進路を制御（「進路制御」という）する（ステップＳ１０３）。なお、この列車追跡によって得られた情報を本明細書では運転状況情報と呼ぶ。運行管理システム１０ｉは列車追跡・進路制御を行った後、運転状況情報を運行状況管理サーバ２０に送信する（ステップＳ１０４）。
【００１９】
運行状況管理サーバ２０は、受信処理部２０ａ（図２）で“路線ｉ”の運行管理システム１０ｉから送られて来る情報を受信し列車運転状況データベースＤＢ２ｉにてこれを保存する（ステップＳ２０３）。運行状況管理サーバ２０は同様に全線の列車運転状況データベースＤＢ２ａ〜ＤＢ２ｎを随時更新し保存する。このようにして随時更新される列車運転状況データベースＤＢ２ａ〜ＤＢ２ｎは路線によってコード体系、情報項目、情報項目の並びが異なっていることもあり得るため、データ整形処理部２０ｂ（図２）でデータ整形を行って他線区の運行状況情報と合わせて全路線運転状況データベースＤＢ２で統合し管理する（ステップＳ２０４）。
【００２０】
運行状況管理サーバ２０の統合予測ダイヤ生成処理部２０ｃ（図２）は統一形式で管理されている全路線ダイヤデータベースＤＢ１のダイヤ情報と全路線運転状況データベースＤＢ２の運行状況情報より全線区の遅延予測を行い、予測遅延時分を含んだ予測ダイヤを算出し、全線予測ダイヤデータベースＤＢ３を更新し管理する（ステップＳ２０５）。これにより、列車の運行に対する乱れの有無やその程度、またその乱れが対象線区内の他線区に及ぼす影響の範囲や度合いを一元管理することが可能になる。
【００２１】
次に本発明の中核をなす個別の駅における案内情報配信方法について２つのステップに分けて説明する。図５は所在地登録の動作を示すフローチャートである。図５に沿って、駅における所在地管理サーバ３０、ＲＦＩＤのタグリーダ４０、駅員が持つ携帯端末５０の間のデータ授受と処理の概略について説明する。
【００２２】
図５において、携帯端末５０に内蔵されるＲＦＩＤタグには、その携帯端末固有の識別番号（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ、以下、単に“ＩＤ”と略す。）を初めとする携帯端末を特定することが可能な識別情報が予め設定されていて常時電波を発信している（ステップＳ５０１）。なお、本実施の形態においては、「所在地管理サーバ３０は駅員の所在地を把握する」と表現しているが、ＲＦＩＤタグには上記にように携帯端末５０の識別情報が記録されており、所在地管理サーバ３０はタグリーダ４０からの情報を収集することにより、正確には「携帯端末５０の所在地を把握する」ものである。なお、ＲＦＩＤタグには、多くの場合、駅員の識別情報も載せることが可能であり、このように駅員の識別情報も同時にタグリーダ４０にて読み込むようにすれば、文字通り駅員の所在地を把握することもできる。ＲＦＩＤタグは、必ずしも携帯端末５０に内蔵されるものでなくともよく、常に駅員が所持して携帯端末５０と共に移動するものであればよい。
【００２３】
ここで、動作説明のために鉄道における駅の構造の一例として図６を用い説明する。各駅は通常、駅員がいる事務室、コンコース、エレベータ、エスカレータ及びプラットフォーム等の物理的あるいは建築的構造を有するが、ここでは駅員が乗客に対応する単位をコンコースとプラットフォームの単位で考える。以下、「論理的に分割された管理区域」と言う。論理的に分割された管理区域境界の要所４０ａ〜４０ｊにＲＦＩＤのタグリーダが設置される。
【００２４】
ＲＦＩＤタグの情報は、携帯端末（ここでは５０ｑ）を持った駅員が、この論理的に分割された管理区域に入るとき、または出るときにタグリーダ（ここでは４０ｑ）にかざされることによってタグリーダ４０ｑに読み取られる（ステップＳ４０１）。例えば、駅員事務所がコンコース側４０ａにあって、駅員が事務所に入る際には所有するＲＦＩＤタグをタグリーダ４０ａに読み取らせる。また、その駅員が事務所を出てＡ線プラットフォームに移動する場合には、Ａ線プラットフォームに入ったときにタグリーダ４０ｃで再び読み込ませる。こうして読み込まれる情報は、読み込まれる都度タグリーダ４０から駅構内ネットワーク６０を経由して所在地管理サーバ３０に送られる（ステップＳ４０２）。
【００２５】
所在地管理サーバ３０においては、所在地データ受信処理部３０ａ（図３）は、タグリーダ４０ｑから送られてくるＩＤ情報を受信して（ステップＳ３０１）、その都度、ＲＦＩＤタグのＩＤ情報と所在地コードを所在地管理データベースＤＢ６に登録し管理する（ステップＳ３０２）。
【００２６】
図７は運行状況管理サーバ２０から得られる情報を所在地管理サーバ３０で携帯端末情報に編集し携帯端末５０に表示させるまでの手順を示すフローチャートである。統合予測ダイヤ生成処理部２０ｃ（図２）が働いた結果得られる、列車の各駅における着発の実績と予測時刻、及び各駅における着発に関する実績と予測遅延を併せて運転情報とすると、運転情報が所在地管理サーバで編集され駅員の持つ携帯端末に配信される動作を、図７に沿って説明する。
【００２７】
運行状況管理サーバ２０は、駅への運転情報配信処理部２０ｄ（図２）を働かせて統合された全線予測ダイヤデータベースＤＢ３で管理している運転情報を定期的に接続相手先管理データベースＤＢ５を参照しながら各駅の所在地管理サーバを含む関連装置に配信している（ステップＳ２１１）。
【００２８】
駅に設置される所在地管理サーバ３０では、運転情報受信処理部３０ｂ（図３）がこれを受信し運転情報データベースＤＢ７を更新する（ステップＳ３２０ａ）。表示データ編集処理部３０ｃ（図３）では当該駅のコンコース、ホームという管理区域の単位に運転情報を編集処理する。この処理においてはコンコース、ホームの単位で案内する情報の重み付けがなされ優先度順に配列される。こうして得られる運転情報（表示データ）に対し、さらに緊急情報データベースＤＢ８の内容を検索して必要に応じて重畳し、携帯端末表示情報データベースＤＢ９が更新される（ステップＳ３２１）。
【００２９】
携帯端末表示情報編集処理を終えると携帯端末への表示情報送信処理部３０ｄ（図３）が働き、所在地管理データベースＤＢ６を参照して携帯端末表示情報データベースＤＢ９の情報が携帯端末に送り出される（ステップＳ３２２）。この場合の情報転送は常時一定周期で行われ、登録されている全携帯端末に対して送り出される。
【００３０】
以上の情報を受け取った携帯端末５０は、情報受信をブザー等で報知し、携帯端末の画面にその内容を表示する（ステップＳ５１１）。
【００３１】
ここで、携帯端末５０では得られた情報に基づき、例えば図８及び図９に示す画面を表示する。図８で、当該駅はＡ路線とＢ路線という複数の鉄道路線が出入りしている。携帯端末５０は表示部と操作部が画面上に設けられている。その内、操作部には「他線区」、「他社線」、「全線」等の情報入手用押しボタンが設けられている。「他線区」とは、仮に駅員がＡ線ホームにいればＢ線のことであり、Ａ線ホームにいればＢ線のことである。「他社線」とは当該鉄道路線がその運転先において別の鉄道路線と軌道が連結されており、双方の車両が相互に乗り入れ運転を行っているような場合の当該路線から見た他社線のことである。「全線」とは当該鉄道会社が所有する全路線のことである。
【００３２】
駅員は自ら存在する位置により必要な情報が異なっている。例えば、Ａ線区のホームにいる場合には、Ａ線区の運行状況や先着列車情報などがもっとも重要な情報となり、次に重要な情報は、同じ駅に出入りするＢ線の情報である。当該駅に出入りしていない他線区に関する情報の優先度は相対的に低くなる。同様にＢ線区のホームにいる場合には、Ｂ線区の運行状況や先着列車情報などがもっとも重要な情報となり、次に重要な情報は、同じ駅に出入りするＡ線の情報である。また各線区にいる駅員とコンコースなど共通の設備にいる駅員の間でも必要な情報が異なることが考えられる。このように駅員の所在位置に対応して重み付けされた案内情報が駅員の持つ携帯端末に送られて携帯端末画面に表示される。
【００３３】
図９はＢ路線のホームにいる駅員に対する表示例であり、メッセージ表示部分のみを示している。列車位置のグラフィック表示部分はこの例の場合、一画面で両路線分表現でき同一としている。緊急情報がＡ線用と共通な情報が表示され、Ｂ線運転情報が表示されている。
【００３４】
以上のように、本実施の形態の案内情報配信システムによれば、この発明によれば、所在地管理サーバは、タグリーダからの情報を収集して携帯端末の所在地（すなわち、駅員の所在地）を把握しており、また、運行状況管理サーバから運転情報を得て、この運転情報を、携帯端末の所在地に基づく所定の優先順位に基づいて重み付けをして管理区域毎の表示データに編集して携帯端末に配信するので、駅員の所在地により提供する情報の優先順位が決定され、適切な情報を優先的に表示することができ、これを見た駅員はコンコースやプラットフォームにおいて、旅客に対する案内情報の提供をスムーズに行い、サービス向上を図ることができる。
【００３５】
実施の形態２．
以上の実施の形態では駅員の持つ携帯端末に定期的に情報配信し携帯端末で表示するが、本実施の形態は、駅員からの照会応答も可能とする。携帯端末からの要求に応じて他の線区の情報を提供したい場合には、他線区に対しても送信することができる。このとき、複数の線区の運転情報を含め様々な情報を配信する場合には、各携帯端末の所在地に応じて優先度を付加した上で情報配信する。従って駅員の持つ携帯端末の位置を全て把握している所在地管理サーバが図１０に示すフローチャートの処理を行って、各携帯端末の位置に応じた情報を編集し、さらに緊急情報表示部に示すように限られた情報スペースを用いて全線区における情報を重畳し表示する。この場合の動作を図１０を用いて説明する。
【００３６】
駅員が図８の携帯端末画面に示される「他線区」、「他社線」あるいは「全線」等いずれかのボタンを押すと携帯端末が表示情報受信要求処理を行ない、無線ＬＡＮと駅構内ネットワーク６０を介して所在地管理サーバ３０に表示情報の受信要求をする（ステップＳ５１０）。
【００３７】
所在地管理サーバ３０は、携帯端末からの要求データ受信処理部３０ｅ（図３）で要求内容を分析し、登録すると共に携帯端末からの受信要求情報にある携帯端末ＩＤを見て所在地管理データベースＤＢ６を検索し、どこの場所にいる駅員から要求があったものか判断し、これを携帯端末からの問合せを管理する問合せ管理データベースＤＢ１０に登録する（ステップＳ３１０）。
【００３８】
所在地管理サーバ３０は、既に入手している情報で要求に対応できれば（ステップＳ３２１）の処理フローで示されるように要求携帯端末に最適な情報に編集し与えれば良いが、例えば他社線の情報を求められたときのように、対応できなければ要求発信処理部３０ｆ（図３）が働き最新の運行状況情報を得ようと運行状況管理サーバ２０に要求する（ステップＳ３１１）。
【００３９】
運行状況管理サーバ２０はこの要求に対応した運行状況情報を自ら有する全路線予測ダイヤデータベースＤＢ３を検索し（ステップＳ２１０）、要求元の所在地管理サーバ３０に送信する（ステップＳ２１１）。
【００４０】
所在地管理サーバ３０は最新の運行状況情報を受け取った後、一旦これを運転情報データベースＤＢ７に登録し（ステップＳ３２０ａ）、実施の形態１と同じように運転情報データベースＤＢ７の情報に緊急情報データベースＤＢ８を重畳して要求元の駅員の所在地に対して最適な情報に編集し、携帯端末表示情報データベースＤＢ９を更新する（ステップＳ３２１）。こうして編集された情報は、携帯端末からの問合せを管理する問合せ管理データベースＤＢ１０を見て要求元の携帯端末に送られ（ステップＳ３２２）、携帯端末の画面に内容が表示される（ステップＳ５１１）。
【００４１】
以上のように本実施の形態では、駅員は通常時常時一定間隔で自己の所在地において優先度の高い情報を受け取っている傍ら、列車乗客等の鉄道利用者からの担当範囲外の運行状況に係る問合せにも対応でき、最新の的確な案内を行うことが可能になるという効果が
得られる。
【００４２】
実施の形態３．
本発明の別の実施の形態、強制的に特定の携帯端末に対して情報を送りつけて表示をさせることも可能である。この代表例として列車運行に乱れが生じている場合などがあり、ここではこのようにして送られる情報を緊急情報と称する。以下、緊急情報が個々の駅員の携帯端末にまで伝わる処理の流れを図１１を用いて説明する。
【００４３】
“路線ｉ”で列車の運行が乱れたものとする。その際にＩ線運行管理システムで列車の運行に関する指令に携わる輸送指令員は運行管理システム１０ｉの携帯端末を用いて各種の情報入力を行うがその一つに緊急情報があり、情報入力があると運行状況管理サーバがこれを得るものとする。この場合、当然、運行管理システム１０ｉと運行状況管理サーバ２０の間で情報授受が行われるが図１１では図示を省略している。
【００４４】
緊急情報の与え方の一例として“路線ｉ”において、列車がＡ駅、Ｂ駅、Ｃ駅、・・・Ｚ駅と進んでいくものとして途中のＳ駅から先で列車が不通になった場合、Ｓ駅の行路手前のＬ駅で乗客を“路線ｊ”に迂回誘導する場合がある。この場合、“路線ｉ”の輸送指令携帯端末から緊急情報として「Ｚ駅方向路線でＳ駅―Ｚ駅が不通、Ｌ駅で“路線ｊ”に迂回」と与えると、この情報は少なくとも“路線ｉ”のＡ駅からＬ駅までのコンコースにいる駅員とＺ駅方向路線のプラットフォームにいる駅員に知らしめておく必要がある。
【００４５】
運行状況管理サーバ２０は緊急情報を得ると各駅の所在地管理サーバにこれを送る（ステップＳ１１０）。所在地管理サーバ３０では運行状況管理サーバ２０から緊急情報が送られてきたとき通常処理に対し割り込み優先的に、運転情報受信処理部３０ｂ（図３）が内容分析を行って緊急情報と判別し緊急情報データベースＤＢ８に登録する（ステップＳ３２０ｂ）。
【００４６】
その後、緊急情報データベースＤＢ８に登録された情報と所在地管理データベースＤＢ６に登録されている携帯端末の所在地情報を元に携帯端末所在地検索を行って携帯端末毎に表示させる情報編集を行って携帯端末表示情報を作成（ステップＳ３２１）し、複数の携帯端末５０ａ，５０ｂ，・・・，５０ｌの内、コンコースや該当するプラットフォームにいる駅員の持つ携帯端末に対し、駅内のネットワーク６０と無線ＬＡＮを経由し一斉送信する（ステップＳ３２２）。
【００４７】
以上のように本実施の形態では輸送指令員が運行管理システム１０ｉの指令員携帯端末を用いて伝達したい情報を入力すれば、所在地管理サーバ３０が該当情報を受けて優先的に処理を行ない配信が必要な携帯端末を選びだし、当該携帯端末に対してリアルタイム情報の配信を行うので、これを受けた駅員はコンコースや該当するプラットフォームにいる鉄道利用客に対し、より適切な案内を行えるという効果が得られる。
【産業上の利用可能性】
【００４８】
以上のように、本発明にかかる案内情報配信システムは、鉄道の駅に散在する複数の駅員に対し旅客案内に必要な各種情報を各駅員の所在位置に応じて重み付けしたものを配信するシステムに有用であり、特に、複数の鉄道会社の車両が相互に乗り入れ運転を行っているような駅において各駅員に必要な各種情報を配信するシステムに適している。
【図面の簡単な説明】
【００４９】
【図１】本発明の実施の形態１における案内情報配信システムのシステム構成図である。
【図２】図１に示す運行状況サーバの論理構造略図である。
【図３】図１に示す所在地管理サーバの論理構造略図である。
【図４】運行管理システムと運行状況サーバの情報授受と概略処理内容を示すフローチャートである。
【図５】所在地登録の動作を示すフローチャートである。
【図６】タグリーダの分布の例を示す模式図である。
【図７】運行状況管理サーバ２０から得られる情報を所在地管理サーバで携帯端末情報に編集し携帯端末に表示させるまでの手順を示すフローチャートである。
【図８】Ａ路線携帯端末の場合の画面構成例を示す図である。
【図９】Ｂ路線携帯端末の場合の画面構成例を示す図である。
【図１０】実施の形態２における携帯端末から情報要求した場合の携帯端末が情報を入手する手順を示すフローチャートである。
【図１１】実施の形態３における緊急情報送信の手順を示すフローチャートである。
【符号の説明】
【００５０】
１０ 運行管理システム
２０ 運行状況管理サーバ
２０ａ 受信処理部
２０ｂ データ整形処理部
２０ｃ 統合予測ダイヤ生成処理部
２０ｄ 運転情報配信処理部
２０ｅ 要求受信処理部
２０ｆ 情報要求処理部
３０ 所在地管理サーバ
３０ａ 所在地データ受信処理部
３０ｂ 運転情報受信処理部
３０ｃ 表示データ編集処理部
３０ｄ 表示情報送信処理部
３０ｅ 要求データ受信処理部
３０ｆ 要求発信処理部
４０ タグリーダ
５０ 携帯端末
６０ 駅構内ネットワーク
ＤＢ１ 全路線ダイヤデータベース（全路線データベース）
ＤＢ１ｉ ダイヤデータベース
ＤＢ２ 全路線運転状況データベース（全路線データベース）
ＤＢ２ｉ 列車運転状況データベース
ＤＢ３ 全線予測ダイヤデータベース
ＤＢ５ 接続相手先管理データベース
ＤＢ６ 所在地管理データベース
ＤＢ７ 運転情報データベース
ＤＢ８ 緊急情報サーバ
ＤＢ８ 緊急情報データベース
ＤＢ９ 携帯端末表示情報データベース
ＤＢ１０ 問合せ管理データベース
【特許請求の範囲】
【請求項１】
駅構内にて駅員の携帯端末に表示データを配信する案内情報配信システムであり、
複数の駅員がそれぞれ携帯する携帯端末と、
前記携帯端末と共に移動し前記携帯端末の識別情報が書き込まれた無線ＩＣタグと、
駅構内の管理区域境界に設置され当該管理区域を出入りする駅員が所持する前記無線ＩＣタグから前記携帯端末の識別情報を読み込む複数のタグリーダと、
列車の運転情報を管理する運行状況管理サーバと、
前記タグリーダからの情報を収集して前記携帯端末の所在地を把握すると共に、前記運転情報を得て、当該運転情報を、前記携帯端末の所在地に基づく所定の優先順位に基づいて重み付けをして前記管理区域毎の前記表示データに編集し、該表示データを前記携帯端末に配信する所在地管理サーバと
を備えたことを特徴とする案内情報配信システム。
【請求項２】
前記運行状況管理サーバは、乗り入れを行っている複数の路線の運行管理システムからダイヤ情報を入手してこれを統合し、統合された前記ダイヤ情報から運行状況情報に基づいてダイヤの遅延予測をして、当該遅延予測を含む前記ダイヤ情報から前記運転情報に基づいて前記表示データを生成して前記所在地管理サーバに送信する
ことを特徴とする請求項１記載の案内情報配信システム。
【請求項３】
前記運行状況管理サーバは、運行管理の指令員が適宜与える緊急情報を入手すると、即座に当該緊急情報を前記所在地管理サーバに送信し、
前記所在地管理サーバは、前記緊急情報を受信すると当該緊急情報に優先順位の高い重み付けをして前記表示データに重畳して関連する前記携帯端末に一斉に配信する
ことを特徴とする請求項１または２に記載の案内情報配信システム。
【請求項４】
前記運行状況管理サーバは、
前記複数の運行管理システムから前記運転情報としてダイヤ情報及び運行状況情報を受信してダイヤデータベース及び運行状況情報データベースに記憶する受信処理部と、
異なる形式の複数の前記ダイヤ情報及び前記運行状況情報を統一的に整形して全路線データベースに記憶するデータ整形処理部と、
整形された前記ダイヤ情報及び前記運行状況情報をもとに運転中の各列車の遅延予測を含む統合された予測ダイヤを生成して予測ダイヤデータベースに記憶する統合予測ダイヤ生成処理部と、
前記統合予測ダイヤを含む前記ダイヤ情報及び前記運行状況情報を前記運転情報として前記所在地管理サーバに配信する運転情報配信処理部と
を備えたことを特徴とする請求項２に記載の案内情報配信システム。
【請求項５】
前記運行状況管理サーバは、前記所在地管理サーバからの情報要求を受信する要求受信処理部と、当該情報要求を前記運行管理システムに送信する情報要求処理部とを
さらに備えたことを特徴とする請求項２または４に記載の案内情報配信システム。
【請求項６】
前記管理区域は、駅構内の各コンコース及び各ホームという単位で区分され、前記所在地管理サーバは、各管理区域毎に駅員にとって最も有用な情報となるように前記運転情報に重み付けをして前記携帯端末に送信する
ことを特徴とする請求項１から５のいずれか１項に記載の案内情報配信システム。
【請求項７】
前記所在地管理サーバは、
前記タグリーダからの情報を収集して前記携帯端末の所在地を所在地管理データベースに記憶する所在地受信処理部と、
前記運行状況管理サーバからの統合予測ダイヤを含むダイヤ情報及び運行状況情報を前記運転情報として受信して運転情報データベースに記憶する運転情報受信処理部と、
前記携帯端末の所在地に基づいて前記運転情報に重み付けをして前記携帯端末に対する表示データに編集して携帯端末表示情報データベースに記憶する表示データ編集処理部と、
前記編集された表示データを前記携帯端末毎に配信する表示データ配信処理部と
を備えたことを特徴とする請求項１から６のいずれか１項に記載の案内情報配信システム。
【請求項８】
前記所在地管理サーバは、前記携帯端末からの問い合せ要求を受信して問い合せ管理データベースに記憶する要求データ受信処理部と、前記問い合せ要求を前記運行状況管理サーバに送信する要求発信処理部とをさらに備え、前記表示データ配信処理部は、前記問い合せ管理データベースを参照して前記問い合せ要求に対応する情報を前記携帯端末に配信する
ことを特徴とする請求項６または７に記載の案内情報配信システム。
【請求項９】
前記携帯端末は、表示する情報を切り替える選択ボタンを備え、該選択ボタンによる表示切り替えの動作により必要となる情報は、前記携帯端末から発せられた情報要求により、前記所在地管理サーバから前記携帯端末に配信され、該所在地管理サーバに要求する情報がないとき、前記所在地管理サーバを介して前記運行状況管理サーバから前記携帯端末に配信される
ことを特徴とする請求項１から８のいずれか１項に記載の案内情報配信システム。
【請求項１】
駅構内にて駅員の携帯端末に表示データを配信する案内情報配信システムであり、
複数の駅員がそれぞれ携帯する携帯端末と、
前記携帯端末と共に移動し前記携帯端末の識別情報が書き込まれた無線ＩＣタグと、
駅構内の管理区域境界に設置され当該管理区域を出入りする駅員が所持する前記無線ＩＣタグから前記携帯端末の識別情報を読み込む複数のタグリーダと、
列車の運転情報を管理する運行状況管理サーバと、
前記タグリーダからの情報を収集して前記携帯端末の所在地を把握すると共に、前記運転情報を得て、当該運転情報を、前記携帯端末の所在地に基づく所定の優先順位に基づいて重み付けをして前記管理区域毎の前記表示データに編集し、該表示データを前記携帯端末に配信する所在地管理サーバと
を備えたことを特徴とする案内情報配信システム。
【請求項２】
前記運行状況管理サーバは、乗り入れを行っている複数の路線の運行管理システムからダイヤ情報を入手してこれを統合し、統合された前記ダイヤ情報から運行状況情報に基づいてダイヤの遅延予測をして、当該遅延予測を含む前記ダイヤ情報から前記運転情報に基づいて前記表示データを生成して前記所在地管理サーバに送信する
ことを特徴とする請求項１記載の案内情報配信システム。
【請求項３】
前記運行状況管理サーバは、運行管理の指令員が適宜与える緊急情報を入手すると、即座に当該緊急情報を前記所在地管理サーバに送信し、
前記所在地管理サーバは、前記緊急情報を受信すると当該緊急情報に優先順位の高い重み付けをして前記表示データに重畳して関連する前記携帯端末に一斉に配信する
ことを特徴とする請求項１または２に記載の案内情報配信システム。
【請求項４】
前記運行状況管理サーバは、
前記複数の運行管理システムから前記運転情報としてダイヤ情報及び運行状況情報を受信してダイヤデータベース及び運行状況情報データベースに記憶する受信処理部と、
異なる形式の複数の前記ダイヤ情報及び前記運行状況情報を統一的に整形して全路線データベースに記憶するデータ整形処理部と、
整形された前記ダイヤ情報及び前記運行状況情報をもとに運転中の各列車の遅延予測を含む統合された予測ダイヤを生成して予測ダイヤデータベースに記憶する統合予測ダイヤ生成処理部と、
前記統合予測ダイヤを含む前記ダイヤ情報及び前記運行状況情報を前記運転情報として前記所在地管理サーバに配信する運転情報配信処理部と
を備えたことを特徴とする請求項２に記載の案内情報配信システム。
【請求項５】
前記運行状況管理サーバは、前記所在地管理サーバからの情報要求を受信する要求受信処理部と、当該情報要求を前記運行管理システムに送信する情報要求処理部とを
さらに備えたことを特徴とする請求項２または４に記載の案内情報配信システム。
【請求項６】
前記管理区域は、駅構内の各コンコース及び各ホームという単位で区分され、前記所在地管理サーバは、各管理区域毎に駅員にとって最も有用な情報となるように前記運転情報に重み付けをして前記携帯端末に送信する
ことを特徴とする請求項１から５のいずれか１項に記載の案内情報配信システム。
【請求項７】
前記所在地管理サーバは、
前記タグリーダからの情報を収集して前記携帯端末の所在地を所在地管理データベースに記憶する所在地受信処理部と、
前記運行状況管理サーバからの統合予測ダイヤを含むダイヤ情報及び運行状況情報を前記運転情報として受信して運転情報データベースに記憶する運転情報受信処理部と、
前記携帯端末の所在地に基づいて前記運転情報に重み付けをして前記携帯端末に対する表示データに編集して携帯端末表示情報データベースに記憶する表示データ編集処理部と、
前記編集された表示データを前記携帯端末毎に配信する表示データ配信処理部と
を備えたことを特徴とする請求項１から６のいずれか１項に記載の案内情報配信システム。
【請求項８】
前記所在地管理サーバは、前記携帯端末からの問い合せ要求を受信して問い合せ管理データベースに記憶する要求データ受信処理部と、前記問い合せ要求を前記運行状況管理サーバに送信する要求発信処理部とをさらに備え、前記表示データ配信処理部は、前記問い合せ管理データベースを参照して前記問い合せ要求に対応する情報を前記携帯端末に配信する
ことを特徴とする請求項６または７に記載の案内情報配信システム。
【請求項９】
前記携帯端末は、表示する情報を切り替える選択ボタンを備え、該選択ボタンによる表示切り替えの動作により必要となる情報は、前記携帯端末から発せられた情報要求により、前記所在地管理サーバから前記携帯端末に配信され、該所在地管理サーバに要求する情報がないとき、前記所在地管理サーバを介して前記運行状況管理サーバから前記携帯端末に配信される
ことを特徴とする請求項１から８のいずれか１項に記載の案内情報配信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００９−１１３６０１（Ｐ２００９−１１３６０１Ａ）
【公開日】平成２１年５月２８日（２００９．５．２８）
【国際特許分類】
【出願番号】特願２００７−２８７６５４（Ｐ２００７−２８７６５４）
【出願日】平成１９年１１月５日（２００７．１１．５）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
【公開日】平成２１年５月２８日（２００９．５．２８）
【国際特許分類】
【出願日】平成１９年１１月５日（２００７．１１．５）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
[ Back to top ]