(57)【要約】      （修正有）【課題】現場の監督者が保守工事の着手要求を行ってから着手承認まで待つ時間である着手承認待ち時間が短縮される保守工事支援システムを提供する。【解決手段】保守工事支援システムは、サーバ２と、指令端末３と、携帯端末４とを備える。サーバ２は、各項の保守工事について線路閉鎖区間を含む情報が登録される。サーバ２は、列車の位置情報を取得し、各項の保守工事について、その項の線路閉鎖区間を着手列車が通過すると、その項の保守工事の着手要求を指令端末３に表示する。着手要求に対して指令端末３で線閉てこが反位操作されると、その線閉てこの反位状態がサーバ２で把握される。サーバ２は、携帯端末４から保守工事の着手要求を受信したとき、その保守工事の項ごとに、関係する線閉てこが反位状態であれば、その携帯端末４に着手承認を送信する。これにより、指令端末３に表示される着手要求が時間的に分散される。【選択図】図２
2015168316.tif 000002
【特許請求の範囲】
【請求項１】
線路の保守工事を支援するための保守工事支援システムであって、
保守工事は、線路閉鎖区間ごとに項に分けられており、
各項の保守工事について線路閉鎖区間を含む情報が登録されるサーバと、
指令に設けられ、前記サーバに接続される指令端末と、
前記サーバと無線回線を介して接続される携帯端末とを備え、
前記サーバは、列車の位置情報を取得し、前記各項の保守工事について、その項の線路閉鎖区間を着手列車が通過すると、その項の保守工事の着手要求を前記指令端末に表示し、
前記着手要求に対して前記指令端末で線閉てこが反位操作されると、その線閉てこの反位状態が前記サーバで把握され、
前記サーバは、前記携帯端末から保守工事の着手要求を受信したとき、その保守工事の項ごとに、関係する線閉てこが反位状態であれば、その携帯端末に着手承認を送信し、
前記携帯端末は、前記サーバから送信された前記着手承認を表示することを特徴とする保守工事支援システム。
【請求項２】
線路閉鎖区間が同じである保守工事が複数項ある場合、それら複数項の保守工事がグループ化されて前記サーバに登録され、
前記サーバは、各々の前記グループについて、そのグループの線路閉鎖区間を着手列車が通過すると、当該グループの着手要求を前記指令端末に表示し、
そのグループの前記着手要求に対して前記指令端末で線閉てこが反位操作されると、その線閉てこの反位状態が前記サーバで把握され、
前記サーバは、前記携帯端末から保守工事の着手要求を受信したとき、その保守工事の項ごとに、関係する線閉てこが反位状態であれば、その携帯端末に着手承認を送信することを特徴とする請求項１に記載の保守工事支援システム。
【請求項３】
線路の保守工事を支援するための保守工事支援システムであって、
保守工事は、線路閉鎖区間ごとに項に分けられており、
各項の保守工事について線路閉鎖区間を含む情報が登録されるサーバと、
指令に設けられ、前記サーバに接続される指令端末と、
前記サーバと無線回線を介して接続される携帯端末とを備え、
前記サーバは、列車の位置情報を取得し、前記各項の保守工事について、その項の線路閉鎖区間を着手列車が通過すると、その項の保守工事の着手要求を前記指令端末に表示し、
前記指令端末は、前記着手要求に対して着手承認の操作が行われると、その項の保守工事の着手承認情報を前記サーバに登録し、
前記サーバは、前記携帯端末から保守工事の着手要求を受信したとき、その保守工事の項ごとに、着手承認情報が登録されていれば、その携帯端末に着手承認を送信し、
前記携帯端末は、前記サーバから送信された前記着手承認を表示することを特徴とする保守工事支援システム。
【請求項４】
線路閉鎖区間が同じである保守工事が複数項ある場合、それら複数項の保守工事がグループ化されて前記サーバに登録され、
前記サーバは、各々の前記グループについて、そのグループの線路閉鎖区間を着手列車が通過すると、当該グループの着手要求を前記指令端末に表示し、
前記指令端末は、そのグループの前記着手要求に対して着手承認の操作が行われると、そのグループの着手承認情報を前記サーバに登録し、
前記サーバは、前記携帯端末から保守工事の着手要求を受信したとき、その保守工事の項ごとに、その項が属するグループの着手承認情報が登録されていれば、その携帯端末に着手承認を送信することを特徴とする請求項３に記載の保守工事支援システム。
【請求項５】
前記サーバは、各項の保守工事について着手要求可能時刻が登録されており、前記着手要求可能時刻が到来した項の保守工事について、その線路閉鎖区間を着手列車が通過したか否かを判断することを特徴とする請求項１又は請求項３に記載の保守工事支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、線路の保守工事における指令員及び現場の監督者の業務を支援するための保守工事支援システムに関する。
【背景技術】
【０００２】
従来から、線路の保守作業（保守工事）における指令員及び現場の監督者（工事監督者）の業務を支援するためのシステムが知られている（例えば、特許文献１参照）。このようなシステムを用いて作業着手の手続を行う場合、監督者がモバイル端末（携帯端末）を用いて作業着手の申込み（着手要求）を送信すると、指令員が当該作業区間の線閉てこの取扱等必要な列車抑止手配（線路閉鎖）を行った後に、作業の着手承認を行う。この着手承認の内容がモバイル端末の画面上に表示され、作業着手の手続が完結する（特許文献１の明細書段落００２１参照）。このようなシステムを用いることにより、指令員と監督者が電話でのやりとりによって手続を行うよりも効率化される。
【０００３】
しかしながら、上述したような従来のシステムは、保守工事の件数が多くなると、着手承認待ち時間が顕著に長くなるという問題がある。着手承認待ち時間とは、監督者が保守工事の着手要求を行ってから着手承認まで待つ時間である。
【０００４】
本発明の発明者は、着手承認待ち時間が長くなっている実態を調査した。図８は、ある夜間における東海道本線吹田駅〜新大阪駅間の線路の保守工事について調査した事例を示す。同図において、横軸は、時刻であり、各横棒は、各々の保守工事における監督者が着手要求を行った時刻、輸送指令の指令員がその着手要求に対して所定の確認を開始した時刻及び指令員が着手承認を行った時刻を示す。同図に示されるように、０時５０分過ぎから着手要求が集中している。着手要求が集中するほど、着手要求から指令員による確認開始までの時間が長くなる傾向があり、着手要求から着手承認までの時間（着手承認待ち時間）が長くなる。
【０００５】
１つの保守工事に複数の施工箇所がある場合、それら複数の施工箇所を含むエリアで一括して線路閉鎖を行うことができず、図９に示されるように、駅間・線別単位の線路閉鎖を行う必要のある線区がある。例えば、上述した東海道本線吹田駅〜新大阪駅間は、このような線区にある。各保守工事は、線路閉鎖区間ごとに項分けされる。各保守工事には、１人の監督者が配置される。線路閉鎖手続における指令員の対応は、保守工事の各項ごとに行われる。駅間・線別単位の線路閉鎖が行われる線区では、保守工事の項数が多くなり、指令員の対応が多くなる。
【０００６】
着手要求の集中によって着手承認待ち時間が長くなる理由を説明する。例えば、図１０に示されるように、保守工事が５件あり、監督者Ｓ１〜Ｓ５が監督する保守工事の項数がそれぞれ４項、３項、５項、４項、４項であるとする。全ての監督者Ｓ１〜Ｓ５が一斉に着手要求を行ったとする。指令員Ｃによる確認開始から着手承認が行われるまでの時間を１項につき１分とする。指令員Ｃは、監督者Ｓ１〜Ｓ５からの着手要求に対して、順次所定の確認を行い、着手承認を行う。監督者Ｓ１からの４項の着手要求に対して、指令員Ｃは、直ぐに確認を開始し、着手承認まで４分かかる。監督者Ｓ２からの３項の着手要求に対して、指令員Ｃは、４分後に確認を開始し、確認開始から着手承認まで３分かかり、着手承認待ち時間は７分となる。監督者Ｓ３からの５項の着手要求に対して、指令員Ｃは、７分後に確認を開始し、確認開始から着手承認まで５分かかり、着手承認待ち時間は１２分となる。監督者Ｓ４からの４項の着手要求に対して、指令員Ｃは、１２分後に確認を開始し、確認開始から着手承認まで４分かかり、着手承認待ち時間は１６分となる。監督者Ｓ５からの４項の着手要求に対して、指令員Ｃは、１６分後に確認を開始し、確認開始から着手承認まで４分かかり、着手承認待ち時間は２０分となる。このように、複数の監督者からの着手要求が集中すると、着手要求から確認開始までの時間が長くなり、着手承認待ち時間が長くなる。
【０００７】
線路の保守工事は、限られた保守間合いの時間内に完了する必要がある。着手承認待ち時間が長くなると、保守間合いの時間内に保守工事を完了することが難しくなり、保守係員に焦りが生じ、ヒューマンエラーを誘発するおそれがある。また、着手承認待ち時間が長くなると、計画通りに保守工事を行うことができなくなり、保守間合いの時間内に行う保守工事の施工数量が計画よりも減ったり、計画した保守工事が中止される等、保守工事の効率が低下する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００２−１３２８８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明は、上記問題を解決するものであり、現場の監督者が保守工事の着手要求を行ってから着手承認まで待つ時間である着手承認待ち時間が短縮される保守工事支援システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の保守工事支援システムは、線路の保守工事を支援するためのものであって、保守工事は、線路閉鎖区間ごとに項に分けられており、各項の保守工事について線路閉鎖区間を含む情報が登録されるサーバと、指令に設けられ、前記サーバに接続される指令端末と、前記サーバと無線回線を介して接続される携帯端末とを備え、前記サーバは、列車の位置情報を取得し、前記各項の保守工事について、その項の線路閉鎖区間を着手列車が通過すると、その項の保守工事の着手要求を前記指令端末に表示し、前記着手要求に対して前記指令端末で線閉てこが反位操作されると、その線閉てこの反位状態が前記サーバで把握され、前記サーバは、前記携帯端末から保守工事の着手要求を受信したとき、その保守工事の項ごとに、関係する線閉てこが反位状態であれば、その携帯端末に着手承認を送信し、前記携帯端末は、前記サーバから送信された前記着手承認を表示することを特徴とする。
【００１１】
この保守工事支援システムにおいて、線路閉鎖区間が同じである保守工事が複数項ある場合、それら複数項の保守工事がグループ化されて前記サーバに登録され、前記サーバは、各々の前記グループについて、そのグループの線路閉鎖区間を着手列車が通過すると、当該グループの着手要求を前記指令端末に表示し、そのグループの前記着手要求に対して前記指令端末で線閉てこが反位操作されると、その線閉てこの反位状態が前記サーバで把握され、前記サーバは、前記携帯端末から保守工事の着手要求を受信したとき、その保守工事の項ごとに、関係する線閉てこが反位状態であれば、その携帯端末に着手承認を送信することが好ましい。
【００１２】
本発明の保守工事支援システムは、線路の保守工事を支援するためのものであって、保守工事は、線路閉鎖区間ごとに項に分けられており、各項の保守工事について線路閉鎖区間を含む情報が登録されるサーバと、指令に設けられ、前記サーバに接続される指令端末と、前記サーバと無線回線を介して接続される携帯端末とを備え、前記サーバは、列車の位置情報を取得し、前記各項の保守工事について、その項の線路閉鎖区間を着手列車が通過すると、その項の保守工事の着手要求を前記指令端末に表示し、前記指令端末は、前記着手要求に対して着手承認の操作が行われると、その項の保守工事の着手承認情報を前記サーバに登録し、前記サーバは、前記携帯端末から保守工事の着手要求を受信したとき、その保守工事の項ごとに、着手承認情報が登録されていれば、その携帯端末に着手承認を送信し、前記携帯端末は、前記サーバから送信された前記着手承認を表示してもよい。
【００１３】
この保守工事支援システムにおいて、線路閉鎖区間が同じである保守工事が複数項ある場合、それら複数項の保守工事がグループ化されて前記サーバに登録され、前記サーバは、各々の前記グループについて、そのグループの線路閉鎖区間を着手列車が通過すると、当該グループの着手要求を前記指令端末に表示し、前記指令端末は、そのグループの前記着手要求に対して着手承認の操作が行われると、そのグループの着手承認情報を前記サーバに登録し、前記サーバは、前記携帯端末から保守工事の着手要求を受信したとき、その保守工事の項ごとに、その項が属するグループの着手承認情報が登録されていれば、その携帯端末に着手承認を送信することが好ましい。
【００１４】
この保守工事支援システムにおいて、前記サーバは、各項の保守工事について着手要求可能時刻が登録されており、前記着手要求可能時刻が到来した項の保守工事について、その線路閉鎖区間を着手列車が通過したか否かを判断することが好ましい。
【発明の効果】
【００１５】
本発明の保守工事支援システムによれば、サーバは、列車の位置情報を取得し、各項の保守工事について、その項の線路閉鎖区間を着手列車が通過すると、その項の保守工事の着手要求を指令端末に表示するので、指令端末に表示される着手要求が時間的に分散され、着手承認待ち時間が短縮される。また、サーバは、携帯端末から保守工事の着手要求を受信したとき、指令員の介在を必要とせずに、その携帯端末に着手承認を送信するので、携帯端末から保守工事の着手要求を受信してから携帯端末に着手承認を送信するまでの時間が短縮される。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施形態に係る保守工事支援システムを含む指令に関するシステム全体の構成図。
【図２】本発明の第１の実施形態に係る保守工事支援システムを用いた線路閉鎖手続の業務フロー図。
【図３】同保守工事支援システムを用いた線路閉鎖手続のタイムチャート。
【図４】同保守工事支援システムを用いた線路閉鎖手続における線路閉鎖区間が同じである保守工事が複数項ある場合の業務フロー図。
【図５】本発明の第２の実施形態に係る保守工事支援システムを用いた線路閉鎖手続の業務フロー図。
【図６】同保守工事支援システムを用いた線路閉鎖手続における線路閉鎖区間が同じである保守工事が複数項ある場合の業務フロー図。
【図７】従来及び本発明の保守工事支援システムを用いた線路閉鎖手続における着手要求から着手承認までの時間を比較した図。
【図８】従来の保守工事支援システムを用いた線路閉鎖手続における着手要求から着手承認までの時間を例示した図。
【図９】保守工事における線路閉鎖区間を例示した線路略図。
【図１０】従来の保守工事支援システムを用いた線路閉鎖手続を説明する図。
【図１１】従来の保守工事支援システムを用いた線路閉鎖手続の業務フロー図。
【図１２】同保守工事支援システムを用いた線路閉鎖手続のタイムチャート。
【発明を実施するための形態】
【００１７】
（第１の実施形態）
本発明の第１の実施形態に係る保守工事支援システムを図１乃至図４を参照して説明する。図１に示されるように、鉄道における指令に関するシステムは、計画業務のための計画系システムと、当日の指令業務のための当日系システムとで構成される。保守工事支援システム１は、線路の保守工事を支援するためのものであり、当日系システムに含まれる。保守工事は、線路閉鎖区間ごとに項に分けられている。この保守工事支援システム１は、サーバ２と、指令端末３と、携帯端末４とを備える。サーバ２は、各項の保守工事について線路閉鎖区間を含む情報が登録される。指令端末３は、指令に設けられ、サーバ２に接続される。携帯端末４は、サーバ２と無線回線５を介して接続される。
【００１８】
サーバ２は、指令管理中央装置２１の一部の機能部分と、保守作業支援装置２２とで実現される。指令管理中央装置２１は、主に列車の運転の指令に用いられる装置であり、指令端末３が接続される。保守作業支援装置２２は、専ら保守作業の支援に用いられる装置であり、携帯端末４が接続される。
【００１９】
指令端末３は、表示装置及び入力装置等を有し、指令に設けられ、指令員によって操作される。指令端末３が設けられる指令は、輸送指令である。
【００２０】
携帯端末４は、モバイル端末であり、保守工事の監督者によって現場に携行される。携帯端末４には、保守工事の着手要求を行うためのアプリケーションプログラムがインストールされている。無線回線５は、例えば、携帯電話回線である。
【００２１】
指令管理中央装置２１は、駅伝送ネットワークを介して、駅制御装置に接続されている。駅制御装置は、連動装置に接続されている。連動装置は、信号機及び転てつ器を制御する保安装置である。
【００２２】
当日系システムの指令管理中央装置２１は、計画系システムと接続されている。計画系システムは、列車ダイヤの計画のためのダイヤ管理装置と、保守作業の計画のための保守作業管理装置を有する。ダイヤ管理装置には、ＥＤＰ（Electronic data processing）端末が接続されている。保守作業管理装置は、保守区に設置された計画端末に接続されている。各項の保守工事についての線路閉鎖区間を含む情報は、計画系システムを用いて作成され、サーバ２に登録される。
【００２３】
保守工事における線路閉鎖手続の業務フローを事例に基づいて説明する。先ず、従来事例について説明する。表１は、着手要求可能時刻と、実際の着手要求時刻との従来事例を示す。
【００２４】
【表１】
2015168316.tif 000003
【００２５】
表１に例示されるように、１１月８日の夜間に施工された１件の保守工事（工事番号：線５０１４）は、３つの線路閉鎖区間で施工され、Ａ項、Ｂ項、Ｃ項の３項を有する。Ａ項の線路閉鎖区間は、Ｙ駅構内８番線である。Ｂ項の線路閉鎖区間は、Ｘ駅〜Ｙ駅間下り外側線である。なお、Ｘ駅〜Ｙ駅間は、複々線であり、上り内側線、上り外側線、下り内側線、及び下り外側線がある。Ｃ項の線路閉鎖区間は、Ｙ駅構内下り外側線である。各項の保守工事における線路閉鎖区間を着手列車が通過すると、保守間合いとなり、その項の着手要求が可能になる。すなわち、着手列車は、線路閉鎖区間を保守間合い前に最後に通過する列車である。Ａ項は、０時００分に着手要求が可能である。Ｂ項は、０時１０分に着手要求が可能である。Ｃ項は、０時２０分に着手要求が可能である。図１１に示されるように、監督者は、それぞれの項の着手要求可能時刻になっても、直ぐには着手要求を行わず、現場で待機し、０時２５分にＡ項、Ｂ項及びＣ項について、まとめて着手要求を行っている。図１２に示されるように、指令員Ｃは、０時２５分にＡ項について所定の確認を開始して着手承認を行い、０時２６分にＢ項について所定の確認を開始して着手承認を行い、０時２７分にＣ項について所定の確認を開始して着手承認を行い、０時２８分にこれら３項の着手承認を完了する。なお、図１２において、確認開始から着手承認までの時間を斜線を付して示している。確認開始から着手承認までの時間は、１項当たり約１分である。指令員Ｃは、確認開始から着手承認までの間に、各項の着手要求に対して、作業区間に見合った列車間合いとなっているかを確認し、着手列車が通過しているかどうかを確認し、操作すべき線閉てこを確認し、指令端末３で線閉てこを反位操作し、関係する全ての線閉てこが反位であることを指令端末３の表示で確認し、指令端末３で着手承認の操作を行う。指令端末３で着手承認の操作が行われると、サーバ２は、その項の保守工事の着手承認を携帯端末４に送信する（図１１参照）。携帯端末４は、サーバ２から送信された着手承認を表示する。
【００２６】
本発明の発明者が保守係員１５０名に聞き取り調査をした結果によれば、保守工事が複数項ある場合、まとめて着手要求を行うと着手承認待ち時間が長くなるとわかっているが、各項ごとに着手要求を行うと、要求失念のおそれや手間がかかる等の理由により、まとめて着手要求を行いたいという意見が３分の１を占めた。また、約３００項の保守工事を対象に、着手要求可能時刻（着手列車通過時刻）と実際の着手要求時刻との関係を調査した結果、約半数以上の項において、着手要求可能時刻の直後には着手要求を行っていないことが判明した。
【００２７】
着手承認待ち時間を短縮するためには、着手要求可能時刻後速やかに着手要求を行い、着手要求を時間的に分散させる必要がある。しかし、多くの監督者は、着手要求をまとめて行うことを希望している。監督者が着手要求をまとめて行うことと、着手承認待ち時間を短縮することとには矛盾があったが、本発明の発明者は、この矛盾を解消することを考え、本発明に到った。
【００２８】
本実施形態の保守工事支援システム１を用いた場合の線路閉鎖手続の業務フローを事例に基づいて説明する。図２に示されるように、本事例では、前述した従来事例と同様に、１件の保守工事がＡ項、Ｂ項、Ｃ項の３項を有し、各項は、それぞれ、０時００分、０時１０分、０時２０分に着手要求が可能になるとする。
【００２９】
サーバ２は、列車の位置情報を取得する。本実施形態では、サーバ２の指令管理中央装置２１は、列車の位置情報を軌道回路単位で取得する。サーバ２は、各項の保守工事について、その項の線路閉鎖区間を着手列車が通過すると、その項の保守工事の着手要求を指令端末３に表示する。このように、サーバ２による着手要求は、監督者Ｓからの着手要求をトリガーとせず、自動的に行われる。
【００３０】
本実施形態では、サーバ２は、各項の保守工事について着手要求可能時刻が登録されており、着手要求可能時刻が到来した項の保守工事について、その線路閉鎖区間を着手列車が通過したか否かを判断する。
【００３１】
本事例では、サーバ２は、Ａ項の着手要求可能時刻である０時００分が到来すると、Ａ項の線路閉鎖区間を着手列車が通過したか否かを判断する。列車が定時運行されていれば、０時００分にはＡ項の線路閉鎖区間を着手列車が通過している。Ａ項の線路閉鎖区間を着手列車が通過している場合、サーバ２は、Ａ項の保守工事の着手要求を指令端末３に表示する。なお、Ａ項の着手要求可能時刻である０時００分が到来してもＡ項の線路閉鎖区間を着手列車が通過していない場合、サーバ２は、一定時間後にＡ項の線路閉鎖区間を着手列車が通過したか否かを再び判断する。
【００３２】
Ａ項の保守工事の着手要求が指令端末３に表示されると、指令員Ｃは、Ａ項の着手要求に対して、所定の確認を行い、指令端末３で関係する線閉てこを反位操作する。着手要求から線閉てこの反位操作までの時間は、約１分である。線閉てこが反位操作されると、線路閉鎖区間への列車の進入を抑止するための停止信号が現示されるとともに、その線閉てこの反位状態がサーバ２で把握される。
【００３３】
同様に、サーバ２は、０時１０分にＢ項の線路閉鎖区間を着手列車が通過すると、Ｂ項の保守工事の着手要求を指令端末３に表示する。Ｂ項の着手要求に対して指令端末３で線閉てこが反位操作されると、その線閉てこの反位状態がサーバ２で把握される。
【００３４】
同様に、サーバ２は、０時２０分にＣ項の線路閉鎖区間を着手列車が通過すると、Ｃ項の保守工事の着手要求を指令端末３に表示する。Ｃ項の着手要求に対して指令端末３で線閉てこが反位操作されると、その線閉てこの反位状態がサーバ２で把握される。
【００３５】
図３に示されるように、指令員は、０時００分にＡ項について所定の確認を開始して、０時０１分にＡ項に関係する線閉てこの反位操作を行う。指令員は、０時１０分にＢ項について所定の確認を開始して、０時１１分にＢ項に関係する線閉てこの反位操作を行う。指令員は、０時２０分にＣ項について所定の確認を開始して、０時２１分にＣ項に関係する線閉てこの反位操作を行う。
【００３６】
サーバ２は、携帯端末４から保守工事の着手要求を受信したとき、その保守工事の項ごとに、関係する線閉てこが反位状態であれば、その携帯端末４に着手承認を送信する。
【００３７】
本事例でも、監督者Ｓは、携帯端末４でＡ項、Ｂ項、Ｃ項の着手要求をまとめて行う。サーバ２は、０時２５分に携帯端末４からＡ項、Ｂ項、Ｃ項の着手要求を受信する。Ａ項、Ｂ項、Ｃ項に関係する線閉てこが反位状態であるので、携帯端末４にＡ項、Ｂ項、Ｃ項の着手承認を送信する。この送信は、サーバ２による自動送信であるので、短時間に行われ、０時２５分１０秒に着手承認の送信が完了する。携帯端末４は、サーバ２から送信された着手承認を表示する（図２参照）。
【００３８】
以上、本実施形態に係る保守工事支援システム１によれば、サーバ２は、列車の位置情報を取得し、各項の保守工事について、その項の線路閉鎖区間を着手列車が通過すると、その項の保守工事の着手要求を指令端末３に表示するので、指令端末３に表示される着手要求が時間的に分散され、着手承認待ち時間が短縮される。また、サーバ２は、携帯端末４から保守工事の着手要求を受信したとき、関係する線閉てこが反位状態であれば、指令員Ｃの介在を必要とせずに、その携帯端末４に着手承認を送信するので、携帯端末４から保守工事の着手要求を受信してから携帯端末４に着手承認を送信するまでの時間が短縮される。このように、サーバ２による指令端末３への自動的な着手要求の表示及び携帯端末４への自動的な着手承認の送信によって、携帯端末４からサーバ２への着手承認が集中するか否かに関わらず、指令端末３に表示される着手要求が時間的に分散され、着手承認待ち時間が短縮される。
【００３９】
本発明の発明者は、着手承認待ち時間が長くなる要因として、上述した着手要求の集中以外の要因をさらに見つけた。線路閉鎖区間が同じである複数の保守工事がある場合、指令員は、最初に着手要求が行われた保守工事に対して、着手列車の通過等の確認を行って着手承認が行い、その後、残る各々の保守工事の着手要求に対しても、同じ確認を行って着手承認を行っていることが調査により判明した。このような指令員による重複した確認によって、着手要求から着手承認までの時間が長くなり、着手承認待ち時間が長くなる。
【００４０】
線路閉鎖区間が同じである複数の保守工事がある場合の従来事例について説明する。表２は、同一線路閉鎖区間での別々の保守工事における着手要求と着手承認の従来事例を示す。
【００４１】
【表２】
2015168316.tif 000004
【００４２】
表２に例示されるように、１１月８日の夜間に施工された４件の保守工事（工事番号：線５０１３、線５０１０、線５６２８、線５０１２）において、線５０１３のＣ項、線５０１０のＤ項、線５６２８のＣ項、及び線５０１２のＥ項は、同じ線路閉鎖区間、Ｘ駅〜Ｙ駅間下り内側線で施工されている。これらの項において、線路閉鎖区間が同じであるので、着手要求可能時刻は、全て０時５１分であり、関係する線路閉鎖てこは、全て８５０Ｒである。各項において、確認開始から着手承認まで、１分前後かかっている。これは、指令員による確認の内容が全く同じであっても、別の保守工事であれば、一から同じように確認を行っているためである。
【００４３】
本発明の発明者は、安全性を低下させずに、同一線路閉鎖区間で施工される項の着手承認にかかる指令員による重複した確認を省略することを考え、本発明に到った。
【００４４】
図４に示されるように、本実施形態の保守工事支援システム１において、線路閉鎖区間が同じである保守工事が複数項ある場合、それら複数項の保守工事がグループ化されてサーバ２に登録される。サーバ２は、各々のグループについて、そのグループの線路閉鎖区間を着手列車が通過すると、当該グループの着手要求を指令端末３に表示する。そのグループの着手要求に対して指令端末３で線閉てこが反位操作されると、その線閉てこの反位状態がサーバ２で把握される。サーバ２は、携帯端末４から保守工事の着手要求を受信したとき、その保守工事の項ごとに、関係する線閉てこが反位状態であれば、その携帯端末４に着手承認を送信する。
【００４５】
保守工事は、計画系システムを用いてサーバ２に登録される（図１参照）。線路閉鎖区間が同じである複数項の保守工事のグループ化は、計画系システムを用いた計画段階で行ってもよいし、サーバ２が自動的に行ってもよい。複数項の保守工事のグループ化は、計画段階で行うとともに、サーバ２がグループ化について再度チェックすることが望ましい。
【００４６】
このように、線路閉鎖区間が同じである保守工事が複数項ある場合、サーバ２は、それら複数項がグループ化されたグループの着手要求が指令端末３に表示し、そのグループの着手要求に対して指令端末３で線閉てこが反位操作されるので、指令員Ｃは、１グループにつき１回の確認をし、線閉てこの反位操作をすればよく、着手承認待ち時間が短縮される（図４参照）。また、サーバ２は、携帯端末４から保守工事の着手要求を受信したとき、関係する線閉てこが反位状態であれば、指令員Ｃの介在を必要とせず、その携帯端末４に着手承認を送信するので、携帯端末４から保守工事の着手要求を受信してから携帯端末４に着手承認を送信するまでの時間が短縮され、着手承認待ち時間が短縮される。
【００４７】
（第２の実施形態）
本発明の第２の実施形態に係る保守工事支援システム１を図１、図５及び図６を参照して説明する。本実施形態の保守工事支援システム１は、第１の実施形態と同様のハードウェア構成を有し（図１参照）、図５に示されるように、サーバ２が保守工事の着手要求を指令端末３に表示した後の指令端末３が受ける操作及びサーバ２が携帯端末４に着手承認を送信する条件が異なる。以下の説明において、第１の実施形態と同等の箇所の詳細な説明は省略する。
【００４８】
保守工事支援システム１において、サーバ２は、列車の位置情報を取得し、各項の保守工事について、その項の線路閉鎖区間を着手列車が通過すると、その項の保守工事の着手要求を指令端末３に表示する。指令端末３は、着手要求に対して着手承認の操作が行われると、その項の保守工事の着手承認情報をサーバ２に登録する。サーバ２は、携帯端末４から保守工事の着手要求を受信したとき、その保守工事の項ごとに、着手承認情報が登録されていれば、その携帯端末４に着手承認を送信する。携帯端末４は、サーバ２から送信された着手承認を表示する。
【００４９】
本実施形態の保守工事支援システム１を用いた場合の線路閉鎖手続の業務フローを事例に基づいて説明する。本事例では、第１の実施形態の事例と同様に、１件の保守工事がＡ項、Ｂ項、Ｃ項の３項を有し、各項は、それぞれ、０時００分、０時１０分、０時２０分に着手要求が可能になるとする。
【００５０】
サーバ２は、列車の位置情報を取得する。サーバ２は、Ａ項の着手要求可能時刻である０時００分が到来すると、Ａ項の線路閉鎖区間を着手列車が通過したか否かを判断する。Ａ項の線路閉鎖区間を着手列車が通過すると、サーバ２は、Ａ項の保守工事の着手要求を指令端末３に表示する。
【００５１】
Ａ項の保守工事の着手要求が指令端末３に表示されると、指令員Ｃは、Ａ項の着手要求に対して、所定の確認を行い、指令端末３で関係する線閉てこを反位操作し、着手承認の操作を行う。このような、指令員Ｃによる確認及び指令端末３の操作は、従来の操作と全く同じである（図１１参照）。線閉てこが反位操作されると、線路閉鎖区間への列車の進入を抑止するための停止信号が現示される。指令端末３は、Ａ項の着手要求に対して、Ａ項の着手承認の操作が行われると、Ａ項の保守工事の着手承認情報をサーバ２に登録する（図５参照）。
【００５２】
同様に、サーバ２は、０時１０分にＢ項の線路閉鎖区間を着手列車が通過すると、Ｂ項の保守工事の着手要求を指令端末３に表示する。指令端末３は、Ｂ項の着手要求に対して、Ｂ項の着手承認の操作が行われると、Ｂ項の保守工事の着手承認情報をサーバ２に登録する。
【００５３】
同様に、サーバ２は、０時２０分にＣ項の線路閉鎖区間を着手列車が通過すると、Ｃ項の保守工事の着手要求を指令端末３に表示する。指令端末３は、Ｃ項の着手要求に対して、Ｃ項の着手承認の操作が行われると、Ｃ項の保守工事の着手承認情報をサーバ２に登録する。
【００５４】
本事例でも、監督者Ｓは、携帯端末４でＡ項、Ｂ項、Ｃ項の着手要求をまとめて行う。サーバ２は、０時２５分に携帯端末４からＡ項、Ｂ項、Ｃ項の着手要求を受信する。Ａ項、Ｂ項、Ｃ項の保守工事の着手承認情報が登録されているので、サーバ２は、携帯端末４にＡ項、Ｂ項、Ｃ項の着手承認を送信する。この送信は、サーバ２による自動送信であるので、短時間に行われ、０時２５分１０秒に着手承認の送信が完了する。携帯端末４は、サーバ２から送信されたＡ項、Ｂ項、Ｃ項の着手承認を表示する。
【００５５】
以上、本実施形態に係る保守工事支援システム１によれば、サーバ２は、列車の位置情報を取得し、各項の保守工事について、その項の線路閉鎖区間を着手列車が通過すると、その項の保守工事の着手要求を指令端末３に表示するので、指令端末３に表示される着手要求が時間的に分散され、着手承認待ち時間が短縮される。また、サーバ２は、携帯端末４から保守工事の着手要求を受信したとき、着手承認情報が登録されていれば、指令員Ｃの介在を必要とせずに、その携帯端末４に着手承認を送信するので、携帯端末４から保守工事の着手要求を受信してから携帯端末４に着手承認を送信するまでの時間が短縮される。このように、第２の実施形態は、指令員Ｃによる指令端末３の操作及び監督者Ｓによる携帯端末４の用い方が従来と同じであり、サーバ２による指令端末３への自動的な着手要求の表示及び携帯端末４への自動的な着手承認の送信によって、第１の実施形態と同様の効果が得られる。
【００５６】
図６に示されるように、本実施形態の保守工事支援システム１においても、線路閉鎖区間が同じである保守工事が複数項ある場合、それら複数項の保守工事がグループ化されてサーバ２に登録される。サーバ２は、各々のグループについて、そのグループの線路閉鎖区間を着手列車が通過すると、当該グループの着手要求を指令端末３に表示する。指令端末３は、そのグループの着手要求に対して着手承認の操作が行われると、そのグループの着手承認情報をサーバ２に登録する。サーバ２は、携帯端末４から保守工事の着手要求を受信したとき、その保守工事の項ごとに、その項が属するグループの着手承認情報が登録されていれば、その携帯端末４に着手承認を送信する。
【００５７】
このように、線路閉鎖区間が同じである保守工事が複数項ある場合、サーバ２は、それら複数項がグループ化されたグループの着手要求が指令端末３に表示し、そのグループの着手要求に対して指令端末３で着手承認の操作が行われるので、指令員Ｃは、１グループにつき１回の確認をし、着手承認の操作をすればよく、着手承認待ち時間が短縮される。また、また、サーバ２は、携帯端末４から保守工事の着手要求を受信したとき、その項が属するグループの着手承認情報が登録されていれば、指令員Ｃの介在を必要とせずに、その携帯端末４に着手承認を送信するので、携帯端末４から保守工事の着手要求を受信してから携帯端末４に着手承認を送信するまでの時間が短縮され、着手承認待ち時間が短縮される。
【００５８】
本発明の保守工事支援システム１による着手承認待ち時間の短縮効果は、第１の実施形態も第２の実施形態もほとんど同じである。本発明の保守工事支援システム１による着手承認待ち時間の短縮効果をシミュレーションによって確認した。
【００５９】
図７の上段は、従来のシステムを用いた場合の着手承認待ち時間の実績を示す。この実績は、平成２５年７月３日の夜間における東海道本線大阪駅〜山陽本線須磨駅間の線路の保守工事について得られたものである。同図において、横軸は、時刻であり、各横棒は、各項の保守工事における現場の監督者が着手要求を行った時刻、輸送指令の指令員がその着手要求に対して所定の確認を開始した時刻及び指令員が着手承認を行った時刻を示す。保守工事が４６項あり、そのうち線路閉鎖によって行う保守工事が３１項あった。その３１項における着手承認待ち時間の実績は、平均１１分３２秒、最長１８分３５秒、合計５時間５７分３８秒であった。
【００６０】
図７の下段は、上記と同じ保守工事について本発明の保守工事支援システム１を用いた場合の着手承認待ち時間をシミュレーションした結果を示す。本発明の保守工事支援システム１を用いると、指令端末３に表示される着手要求が時間的に分散され、他の項の保守工事についての確認を待つ時間が短縮されるとともに、複数項の保守工事がグループ化され、指令員による確認件数が削減される。線路閉鎖によって行う保守工事３１項における着手承認待ち時間のシミュレーション結果は、平均１８秒、最長２分５７秒、合計９分２秒であった。本発明の保守工事支援システム１を用いることにより、着手承認待ち時間が大幅に短縮されることが分かった。
【００６１】
なお、本発明は、上記の実施形態の構成に限られず、発明の要旨を変更しない範囲で種々の変形が可能である。例えば、サーバ２を一体構成しても構わない。
【符号の説明】
【００６２】
１  保守工事支援システム
２  サーバ
３  指令端末
４  携帯端末
５  通信回線
【図１】
2015168316.tif 000005
【図２】
2015168316.tif 000006
【図３】
2015168316.tif 000007
【図４】
2015168316.tif 000008
【図５】
2015168316.tif 000009
【図６】
2015168316.tif 000010
【図７】
2015168316.tif 000011
【図８】
2015168316.tif 000012
【図９】
2015168316.tif 000013
【図１０】
2015168316.tif 000014
【図１１】
2015168316.tif 000015
【図１２】
2015168316.tif 000016