JP2001287649A - 列車運行管理システム - Google Patents

Abstract

(57)【要約】 【課題】制御用コントローラーをメインの処理装置とし
た列車運行管理システムにおいても各関連装置が生成し
た種々の情報を実績データとして時系列的に登録し、こ
れを表示したり運行の再現を可能とする。 【解決手段】運行制御用ネットワークに接続したデータ
蓄積装置１０１は、運行制御の開始、終了を確認し、デ
ータ登録処理部に受信データ登録の開始や終了を指示す
る登録処理管理部１０２と、受信データを実績データと
して記憶装置に時系列的に登録するデータ登録処理部１
０３と、実績データを指示に従い表示装置に表示、もし
くは運行モニタ用ネットワークに送信する実績データ提
示処理部１０４と、実績データを時系列的に順番に表示
装置に表示、もしくは運行モニタ用ネットワークに送信
し運行の再現を行う運行再現処理部１０５より構成され
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、列車の運行管理シ
ステムに係わり、特に関連各装置が生成した運行に関る
種々のデータの蓄積ならびにその提示手段に関するもの
である。

【０００２】

【従来の技術】無停止運転が要求される列車の運行管理
システムにおいては、何らかの異常が発生した場合、迅
速かつ確実な原因究明が要求される。よって、一般に制
御関連データ、例えば、軌道回路や信号機や転てつ器と
いった地上設備の状態情報、列車の追跡情報、制御出力
情報、関連装置の内部データなどを実績データとして時
系列的に記憶装置に蓄積している。異常が発生した場
合、異常発生時間帯のこれら実績データを解析し異常の
原因究明を実施する。従来の運行管理システムでは、中
央システムにあるメインの処理装置が、種々の前記実績
データを自装置内のディスク装置に登録しておいた。デ
ィスク容量の制限や異常の原因究明という目的から、数
分から数十分程度を目処に現時刻から一定時間前までの
データをサイクリックに登録し、異常発生を確認すると
登録をストップし、異常時間帯前後の情報を参照できる
ようになっている。例えば、特開平２−１２８９５７号
公報は、駅分散型システムの例で、中央処理装置のディ
スク装置に各駅制御装置からの前記実績データを登録
し、登録した実績データを中央処理装置に接続している
モニタ端末にて確認する方式が述べられている。

【０００３】一方、ＦＡ（Factory Automation）分野な
どにおいて、制御用コントローラーは、一般的にＰＬＣ
（Programmable Logic Controller）と呼ばれ、ラダー
言語などを用いたシーケンス制御に利用されてきた。し
かし、ＬＳＩ技術の進歩、つまり、ＣＰＵの高速高性能
化、実装メモリの大容量化が急速に進み、制御用コント
ローラーは、いわゆる組込みシステム（Embedded Syste
m）として、汎用のリアルタイムＯＳ(オペレーティング
システム)やＣ言語などの高級言語により制御ロジック
を実行することも可能となっている（参考：例えば、東
芝レビュー Vol.54 No.8 pp.34〜42）。現在では、メモ
リ容量が１０メガバイト以上にも及ぶ制御用コントロー
ラーもあり、中小規模の鉄道システムにおいては、この
制御用コントローラーを制御装置（前記中央処理装置、
駅制御装置を含む）として利用した列車運行管理システ
ムの実現が可能となってきた。

【０００４】

【発明が解決しようとする課題】制御用コントローラー
は、ディスクレスで大容量記憶装置を持たない。このた
め、前記実績データをコントローラー内のメモリに登録
するとしても容量的に限界があり、異常の原因究明に十
分な時間帯分の実績データを登録できるとはいえない。
ましてや、始業開始から終業までのほぼ1日に及ぶ実績
データを蓄積し、１日分の運行再現を実現することなど
できなかった。また、従来システムでは、運行制御を行
なうシステムと実績データのモニタを行なうシステム
が、装置、ネットワークとも同一であったので、オンラ
イン運行中に実績データを提示したり列車の運行を再現
したりするには限界があった。

【０００５】本発明の第１の目的は、制御用コントロー
ラーを前記制御装置として利用した列車運行管理システ
ムにおいも、各制御装置が生成した前記制御関連データ
を含む種々の情報を実績データとして時系列的に登録可
能とする手段を提供することにある。本発明の第２の目
的として、オンライン運行中においても、運行制御に影
響を与えることなく、登録された実績データを提示し、
また、実績データより列車の運行再現を実現する手段を
提供することにある。また、本発明の第３の目的とし
て、制御装置を含む関連各装置に何ら影響を与えないで
前記種々の情報を入手する手段を提供するものである。

【０００６】

【課題を解決するための手段】ディスクなどの大容量記
憶装置を持つデータ蓄積装置を設け、これを運行制御用
ネットワークに接続し、データ蓄積装置は、関連各装置
から該ネットワークに送信された前記種々の情報を受信
し、これを実績データとして記憶装置に登録する。ま
た、運行制御用ネットワークのほか、運行モニタ用ネッ
トワークを設け、データ蓄積装置は運行モニタ用ネット
ワークにも接続し、前記実績データを運行モニタ用ネッ
トワークに送信し、モニタ用ネットワークに接続されて
いるモニタ端末にても実績データの確認や列車運行の再
現を確認することを可能とする。データ蓄積装置は、受
信データを実績データとして記憶装置に時系列的に登録
するデータ登録処理部と、列車の運行制御の開始、終了
を確認し、データ登録処理部に受信データ登録の開始や
終了を指示する登録処理管理部と、記憶装置に記録され
た実績データを指示に従い表示装置に表示、もしくは運
行モニタ用ネットワークに送信し提示する実績データ提
示処理部と、記憶装置に記録された実績データを時系列
的に順番に表示装置に表示、もしくは運行モニタ用ネッ
トワークに送信し運行の再現を行う運行再現処理部より
構成される。

【０００７】また、関連各装置が送信する送信パケット
に内容を示すコードをヘッダ情報の一部として持たせ、
且つ、関連各装置が送信パケットをマルチキャスト送信
することにより、データ蓄積装置も送信されたデータを
盗み取りの形で受信できることを可能とし、データ蓄積
装置は受信した送信パケットの前記コードから必要な情
報であるか判断し、必要な情報であれば自装置の記憶装
置に登録する。

【０００８】

【発明の実施の形態】以下、本発明における１実施例を
詳細に示す。

【０００９】図１に本発明の１実施例におけるデータ蓄
積装置の構成を、図２に本発明の１実施例における列車
運行管理システムの構成の一例を示す。図２は、駅サブ
システムにて分散制御を行う駅分散制御型システムであ
る。図２において、中央サブシステムは、主に、中央処
理装置２０２、指令端末２０３から構成されている。駅
サブシステムは、主に、駅制御装置２０４、連動装置２
０５、案内放送装置２０６から構成され、駅サブシステ
ムは、主要駅単位で設置される。各駅サブシステムと中
央サブシステムは、駅間ネットワーク２０７により結合
されている。各駅サブシステム内ネットワーク、中央サ
ブシステム内ネットワーク、駅間ネットワークは運行制
御用ネットワークである。中央処理装置、駅制御装置、
連動装置、案内放送装置は、制御関連装置で中少規模の
鉄道システムでは前記制御コントローラーにて実現可能
で、一般に多重系システムである。また、指令端末は、
複数台システムとなる場合がある。モニタサブシステム
は、運行状況などをモニタリングするサブシステムで、
モニタ端末２０８が、各駅、保守区、中央指令室など種
々の場所に設置される。モニタ端末は、運行モニタ用ネ
ットワーク２０９により運行制御側のシステムと接続し
ている。以下、各装置の機能を簡単に説明する。駅サブ
システムでは、連動装置２０５が、信号機、転てつ器、
軌道回路などの地上設備機器と接続しており、連動装置
は、これら設備機器のＯＮ、ＯＦＦの状態情報を取り込
み、設備情報として自駅サブシステム内のネットワーク
に送信する。また、連動装置は、自駅サブシステムの駅
制御装置２０４から制御出力情報を受信し、地上設備機
器を制御する。案内放送装置２０６は、案内表示盤や案
内放送機器と接続しており、駅制御装置２０４から案内
放送情報を受信し、案内表示や案内放送を行う。駅制御
装置２０４は、自駅サブシステム内の連動装置から設備
情報を受信し、列車の追跡処理、進路設定処理、進路設
定情報や案内放送情報の出力処理を行う。中央サブシス
テムでは、指令端末２０４は、指令員への運行状況の表
示や、指令員から指令入力を受けこれを中央処理装置２
０２へ送信する。中央処理装置２０２は、ダイヤ情報の
駅制御装置への配信、指令入力情報のチェック処理と指
令情報の駅制御装置への配信処理などの処理を行う。モ
ニタサブシステムでは、モニタ端末２０８は、後述する
データ蓄積装置１０１より、運行モニタ用ネットワーク
２０９を介して運行状況データなどを受け取りこれをモ
ニタ表示する。

【００１０】データ蓄積装置１０１は、中央サブシステ
ム内にあり運行制御用ネットワークと運行モニタ用ネッ
トワーク２０９に接続している。この装置は、運行制御
に直接関らず、上記関連各装置が運行制御用ネットワー
クに送信した種々のデータのうち、運行の再現、デバッ
グや異常の原因究明などに必要となる情報を受信し、こ
れを実績データとして自装置の記憶装置に登録する。受
信する方法として、例えば図３に示すように、ネットワ
ーク上に送信されたデータを盗み取りする方式にてデー
タの受信を行えば、本来の送受信を行う関連各装置に何
ら影響を与えずに必要なデータを受信し登録することが
可能となる。盗み取りを可能とする通信方式は既に幾つ
か存在するが、最も実現しやすい方法の１つとして、イ
ンターネットプロトコルであるＵＤＰ／ＩＰを利用した
方法がある。この通信方式は宛先ポート番号のみを指定
したマルチキャスト通信方式で、各装置は、送信データ
の宛先となったポート番号をオープンすることにより、
このデータを受信することができる。関連各装置が、こ
の方式で送受信を実行することにより、データ蓄積装置
は、他装置に何ら影響を与えることなく、ネットワーク
に流れるデータを自身の判断で受信し必要なデータを自
装置の記憶装置に登録することが可能となる。

【００１１】続いて、データ蓄積装置１０１の構成につ
いて説明する。図１に示すように該装置は、主に、デー
タ登録処理を管理する登録処理管理部１０２、受信した
データを時系列的に登録するデータ登録処理部１０３、
登録したデータを提示する実績データ提示処理部１０
４、登録したデータを時系列に取り出し運行を再現する
運行再現処理部１０５、データの送受信を行うデータ受
信処理部１０６とデータ送信処理部１０７より構成され
る。なお、データ登録処理部は、受信データパケットの
種別に対応して複数存在する。また、データ蓄積装置は
記憶装置１０８を持ち、現在の運行状態を記録した運行
状態ファイル１０９、受信したデータを登録した実績デ
ータ登録ファイル１１０が存在する。

【００１２】以下、各処理部の説明を順に行う。

【００１３】始めに登録処理管理部１０２について、図
４から図９を使って説明する。図４は、登録処理管理部
とデータ登録処理部１０３のデータのやり取りの概要を
示す。図５は、登録処理管理部の処理手順を示すフロー
チャートである。処理フローの説明の前に、列車の運行
状態と運行状態ファイル１０９について説明する。列車
の運行は、一般に指令端末２０４からの始業命令により
運行開始となり、指令端末からの終業命令により運行を
終了する。よって、データ蓄積装置が運行状態を運行状
態ファイルに記録するには、該装置が、始業となったこ
と、終業となったことを認識する必要がある。図６に始
業、終業情報に関する関連装置のデータのやり取りの例
を示す。まず、指令端末２０３より中央処理装置２０２
へ始業もしくは終業要求が出される。中央処理装置は、
要求を受信しチェックした後、指令端末へ要求の承認情
報を、駅制御装置２０４へ始業もしくは終業情報を送信
する。データ蓄積装置は、中央処理装置から駅制御装置
へのこれら情報を受信し、この情報により始業、終業を
確認することができる。図４において、データ受信部１
０６は、始業もしくは終業情報パケットを受信すると、
該パケット用のバッファ４０１に登録する。このバッフ
ァは、ＦＩＦＯ(First In First Out)型のバッファで、
パケット種別ごとに存在する。登録処理管理部は、始業
終業パケット用のバッファに登録された始業、終業パケ
ットを取り出し、始業、終業を確認し、この状況を運行
状況ファイルに記録する。始業、終業の確認方法である
が、図７に示す送信パケットの構成例により説明する。
送信パケットは、ヘッダ部とデータ部より構成され、ヘ
ッダ部には少なくともパケットの種別を示すコード番号
７０１、該種別を細分化した種別を示すコード番号７０
２、データが送信された時刻７０３を含む。またデータ
部には複数のデータ種別（７０４、７０５)が登録され
ることもある。図４のバッファ４０１は、パケット種別
コード番号７０１ごとに用意され、データ受信処理部１
０６は運行制御用ネットワークからパケットを受信する
と、受信パケットのパケット種別コード番号を参照し、
該当するバッファにパケットを登録する。該当するバッ
ファが用意されていなければ受信パケットは破棄され
る。始業情報と終業情報では、どちらの情報もパケット
種別コード番号は同じで、細分化コードが異なることと
なる。登録処理管理部は、始業終業パケット用のバッフ
ァよりパケットを取りだし、細分化コードより始業情報
か終業情報かを判断し、図５のフローに示す処理を実行
する。

【００１４】続いて、運行状態ファイル１０９の説明を
行う。運行状態ファイルに登録されるデータの一例とし
て、始業フラグと終業フラグがある。それぞれＯＮ,Ｏ
ＦＦの値をとり、これらの値と運行状態の関係を図８に
示す。始業フラグ、終業フラグともＯＦＦの場合は、イ
ニシャル状態である。イニシャル状態とは、データ蓄積
装置が初めて稼動した段階で、まだ一度も始業もしくは
終業情報を受信していない状態である。始業フラグＯ
Ｎ、終業フラグＯＦＦの場合、運行状態とし、始業フラ
グ、終業フラグともＯＮの場合は、運行終了状態とす
る。図９に示すように、データ蓄積装置は、まず、イニ
シャル状態からスタートし、始業情報を受信することに
より、始業フラグＯＮ、終業フラグＯＦＦに設定し運行
状態へ、次に終業情報を受信することにより、始業フラ
グＯＮ、終業フラグＯＮに設定し運行終了状態となる。
翌運転日となり、新たに始業情報を受信すると、始業フ
ラグＯＮ、終業フラグＯＦＦに設定し運行状態となり、
以後、運行状態、運行終了状態を繰り返すことになる。

【００１５】さて、図５のフローの説明を行う。まず、
登録処理管理部は、イニシャル処理として運行状態ファ
イル１０９のデータを読込み、処理開始時の運行状態を
確認する（５０１）。既に運行中であれば（５０２）、
データ登録処理部１０３に始業であることを伝える（５
０３）。後述するが、これによりデータ登録処理部は受
信データを記憶装置１０８に登録することを開始する。
イニシャル処理としてこのような処理を実行する理由
は、万一、データ蓄積装置が運行中にダウンし再立上げ
となった場合でも、直ちにデータ登録を再開できるよう
にするためである。ステップ５０２にて、運行中でない
場合、ステップ５０４にスキップする。イニシャル処理
の後、登録処理管理部は、始業、終業情報パケットを受
信するループ処理に入る。登録処理管理部は、始業もし
くは終業パケットの受信待ちとなり、これを受信すると
（５０４）、受信パケットが始業情報であるか終業情報
であるかを判定する（５０５）。判定方法は、図７の説
明にて既に述べた。始業情報の場合、運行状態ファイル
に記録されている運行状態を確認し（５０６）、既に運
行中であれば（５０７）、既にデータ登録は開始されて
いるので何もせずステップ５０４にスキップし、運行中
でなければ、新たに運行状態を運行中（始業フラグＯ
Ｎ、終業フラグＯＦＦ）として運行状態ファイルに記録
し（５０８）、データ登録処理部１０３に始業となった
ことを伝える（５０９）。そして、ステップ５０４にス
キップし、再び始業、終業情報受信待ちとなる。ステッ
プ５０５にて、受信パケットが始業データでない、つま
り終業データである場合、始業の場合と同様、運行状態
ファイルの運行状態を確認し（５１０）、既に運行終了
状態であれば（５１１）、何もせずステップ５０４にス
キップする。運行終了状態でなく、且つ運行中でない、
つまりイニシャル状態であっても同様に何もせずステッ
プ５０４にスキップする（５１２）。ステップ５１２に
て運行中である場合、新たに運行状態を運行終了（始業
フラグＯＮ、終業フラグＯＮ）とし運行状態ファイルに
記録し（５１３）、データ登録処理部に運行終了を伝え
る（５１４）。そして、ステップ５０４にスキップし、
再び始業、終業情報受信待ちとなる。以上で登録処理管
理部の説明を終了する。

【００１６】次に、図４におけるデータ登録処理部１０
３の処理を、図４のほか、図１０から図１４を使って説
明する。データ登録処理部は、受信バッファ４０１に対
応しており、データ登録したいパケット種別数分存在す
ることとなる。データ登録処理部はループ処理を実行す
る。まず、関連パケットの受信待ちとなって関連パケッ
トを対応する受信バッファ４０１から取り出す（１００
１）。既に登録処理管理部１０２より始業の連絡を受け
ており運行状態が運行中であれば（１００２）、登録用
データを作成し（１００３）、これを該当する実績デー
タ登録ファイル１１０に追加登録し（１００４）、再び
ステップ１００１にスキップする。ステップ１００２に
て、イニシャル状態もしくは既に登録処理管理部より終
業の連絡を受けており、運行状態が運行中でなければ、
データ登録は実行せず取得パケットを破棄しステップ１
００１にスキップする。続いて、ステップ１００３，１
００４をより詳細に説明する。ステップ１００３におけ
る登録用データは、図１１に示すように、受信パケット
内に登録されているデータと、ヘッダ情報のうち少なく
とも時刻情報を含む情報より作成する。受信パケット内
のデータ部には、複数のデータ(例えばアラーム情報と
設備情報など)が含まれる場合がある。このような場合
には、そのまま同一データとすることもできるが、後で
述べるデバッグ等にてデータ種別毎の表示を考慮して、
図１１に示すように、データ種別ごとに作成することも
ある。これら登録データは、当然、時系列的に順番に登
録され、後に登録されたデータほど後の時刻の情報とな
る。図１２に実績データ登録ファイルのディレクトリ構
成の一例を示す。図では、ルートディレクトリ、実績デ
ータディレクトリの下位に登録日ごとにディレクトリが
構成されている。例えば、ディレクトリ２００００１０
１は、西暦２０００年１月１日を示す。よって、このデ
ィレクトリ下の各ファイルは該当日における実績データ
登録ファイルである。データ登録処理部は、データ登録
の際、登録日を把握し、該当ディレクトリ下の該当ファ
イルに生成した登録用データを追加登録する。登録日デ
ィレクトリの作成は、例えば登録処理管理部１０２がデ
ータ登録処理部に始業を伝える処理（ステップ５０９）
の前の段階で作成すればよい。

【００１７】さて、運行モニタ用ネットワーク２０９へ
の運行データの送信機能であるが、これは、データ登録
処理部が実績データの登録処理に併せて実行すればよ
い。図１３に該処理におけるデータのフロー図を、図１
４に運行モニタデータ送信を含めたデータ登録処理部の
処理フローチャートの例を示す。図１４にて、データ登
録処理部は、関連パケットを取得しファイル登録した
後、関連パケットがモニタ用データに該当するのであれ
ば（１４０１）、これをモニタデータとして、該当パケ
ット種別に対応する送信バッファ１３０１に登録する。
送信バッファは受信バッファ同様、ＦＩＦＯ型バッファ
である。データ送信処理部１０７が送信バッファからパ
ケットを取り出し、運行モニタ用ネットワークへ送信す
る。以上でデータ登録処理部の説明を終了する。

【００１８】次に、実績データ提示処理部１０４につい
て、図１５から図１９を使い説明する。実績データ提示
処理部は、記憶装置１０８に登録された実績データ登録
ファイル１１０のデータを読込み、これを例えば自装置
の表示装置に表示する処理を実行する。表示装置がない
場合、表示データを運行モニタ用ネットワーク２０９に
送信しモニタ端末２０８に表示する。図１５は、データ
蓄積装置１０１が表示装置１５０１を持つ場合の例であ
る。ここでは、まず、マウス１５０２やキーボード１５
０３を使って、表示すべき実績データ登録ファイル１１
０に関する定義情報を事前に登録しておく。図１６は、
表示装置１５０１に表示された該定義情報の入力画面の
例である。入力項目として、例えば、データの名称（１
６０１）、登録ファイル名称（１６０２）、ファイル内
の1ブロック当たりのデータのバイト数、つまり図１０
のステップ１００３にて述べた登録データのバイト数
（１６０３）、データの属性として、該当データがイベ
ント的に発生する情報なのか周期的に発生する情報なの
かにより、イベントデータ(１６０４)、周期データ（１
６０５）のいずれかを指定する。また、周期を指定した
場合、そのデータが何秒周期に発生するデータであるか
登録しておく（１６０６）。これら定義情報は、登録デ
ータの提示時に利用される。

【００１９】続いて図１７は、実績データ提示処理部の
フローチャート、図１８、図１９は表示装置１５０１に
表示された表示画面例を示す。まず表示画面にて、登録
年月日（１８０１）を指定する（１７０１）。登録年月
日の指定に関しては、図１２に示したディレクトリを検
索することにより、データが登録されている年月日が明
らかになり、これをプルダウンメニュー表示し、その中
から選択することにより指定可能である。続いて、デー
タ名称（１８０２）を指定する（１７０２）。データ名
称の指定に関しては、指定された年月日ディレクトリ下
の関連ファイルをプルダウンメニュー表示し、その中か
ら選択することにより指定可能である。これらを指定す
ることにより、該当の実績データ登録ファイルが特定で
き、図１６にて定義した関連情報であるデータ属性（１
８０３）や１ブロックあたりのバイト数（１８０４）が
表示される（１７０３）。そして、指定されたファイル
の登録データを1ブロック読込みこれを表示する（１７
０４）。エリア１８０５には、登録データの時刻情報
(図１１参照)を、エリア１８０６には登録データそのも
のが表示される。データ容量が大きく表示画面の表示エ
リアで全てを表示できない場合は、スクロールバー１８
０７にてスクロールすることにより全て参照できる。図
１８の例は、登録データのダンプ表示の例である。制御
出力情報や走行列車の詳細情報においてビット単位のデ
ータを利用している場合、このようなダンプ表示にてデ
バックを行うことがよくある。他のブロックのデータを
参照したい場合は、そのブロックを指定し（１７０
５）、これを表示することになる（１７０４）。以下、
他のブロックの指定方法について述べる。最も簡単な例
として、現表示ブロックから1ブロック後もしくは先、
或いは、一定ブロック数後もしくは先へスキップする方
法がある。これは、１８０８内の記号をマウス１５０２
で指定することにより可能である。もし、戻りすぎや行
きすぎで該当ブロックが存在しない場合は、エラー表示
エリア１８０９にその旨表示する。特定時刻付近のブロ
ックのデータを参照したい場合は、エリア１８１０にて
指定時刻を入力し、マウス１５０２にて実行を指定する
ことにより実行される。イベントデータの場合は、現表
示データの時刻と比較して後のデータか先のデータかを
判断し、時刻の比較をしながら順番にブロックを検索
し、入力時刻に最も近い時刻のブロックの情報を表示す
る。周期データの場合は、例えば式（１）のような簡単
な方法でおおよそのスキップ数を割り出し、求めた数量
分スキップしたブロックを表示すればよい。もちろん該
当ブロックがなければエラー表示する。

【００２０】 ( 入力指定時刻 − 現ブロック時刻 ) ／ 該データの周期時間 （１） また、直接スキップするブロック数を指定し（１８１
１）、先にスキップするなら、＋実行、後にスキップす
るなら、−実行を指定し、しかるべきブロックを表示す
る方法もある。データの表示方法として、ダンプ表示の
ほか、設備情報などでは、図１９に示すように軌道回
路、信号機のＯＮ、ＯＦＦの状態をグラフィック表示す
ることにより、信号機や閉塞区間のＯＮ、ＯＦＦ情報を
視覚的に確認することが可能となり、これと制御出力情
報とを対比させて表示することにより、異常の確認や、
デバック作業がやりやすくなる。

【００２１】次に、運行再現処理部１０５について、図
２０、図２１、図２２を利用し説明する。図２０は、実
績データを運行モニタ用ネットワークに送信する例であ
る。

【００２２】図２０に示すように、運行再現処理部は、
記憶装置１０８に登録された実績データ登録ファイル１
１０より登録データをブロック単位で読込み、送信バッ
ファ１３０１に登録する。データ送信部１０７は、各送
信バッファに登録されたパケットを取り出し、運行モニ
タ用ネットワーク２０９に送信する。但し運行の再現
は、モニタ機能の一部といえるので、運行制御のデータ
を全てそのまま再現する必要はなく、必要なデータのみ
を、また、運行制御側にて送信されるパケットのデータ
の構成と異なるフォーマットにて送信してもよい。ただ
し、基本フォーマットは図７とし、送信バッファは、受
信バッファ４０１と同様、パケット種別コード番号７０
１に対応して用意される。運行モニタ用ネットワークに
は、前記運行モニタデータと運行再現データが送信され
ることになるが、モニタ端末２０８それぞれは、どちら
のデータを取り込む決めておき、受信したパケットの前
記コードを参照して取り込むべきデータか判断すればよ
い。この運行再現処理部のより詳細な処理を、図２１、
図２２のフローチャートに従い説明すると、その処理
は、運行再現に必要な実績データ登録ファイル１１０内
のデータを最初のブロックから順番に検索し、運行再現
開始時刻付近のブロックを特定する処理である。ループ
処理は、特定したブロックから順に時間どおりにデータ
送信してゆく処理である。

【００２３】始めに、運行再現の日程を指定する（２１
０１）。これは、表示装置１５０１や入力装置（１５０
２，１５０３）にて入力するか、モニタ端末２０８から
入力すればよい。この入力された情報より、運行再現処
理部は、図１２に示したどのディレクトリ下のファイル
を読み込むか特定できる。どのファイルのデータを読込
むかは事前に定義されているものとしてさしつかえな
い。次に、該当ファイル内のどのブロックからデータを
順に読込んで行くかの特定処理を行う。まず、運行再現
開始時刻を指定する（２１０２）。これを受け、運行再
現処理部は、運行再現に関係する前記事前定義された複
数あるファイルのうちの１つのファイルをオープンする
（２１０３）。続いて該ファイルの最初のブロックを読
込む（２１０４）。データが存在して読込み成功の場合
（２１０５）、読込んだブロックの時刻情報（図１１参
照）をチェックし、該ブロックの時刻情報と指定された
開始時刻とを比較する（２１０６）。ブロックの時刻情
報が開始指定時刻より以前の場合、このデータを送信で
きないのは自明であるため、次のブロックの読込へと進
み（２１０７）、ステップ２１０５の判定処理に再度進
む。ステップ２１０６にて、ブロックの時刻情報が開始
指定時刻と一致、もしくは以後の場合、該ブロックの情
報を該当ファイルの送信データとする（２１０７）。ス
テップ２１０５にて、ファイルの最後に到達したなどの
理由で読込み失敗の場合、該当ファイルを閉じる（２１
０８）。以上、ステップ２１０７もしくはステップ２１
０８にて、該当ファイルに関するイニシャル処理は終了
する。処理対象となった該当ファイルが最後の関連ファ
イルでない場合（２１０９）、次の関連ファイルをオー
プンし（２１１０）、ブロック２１０４より処理を繰り
返す。ステップ２１０９にて、最後の関連ファイルの場
合、各関連ファイルの送信用データの準備は終了し、開
始時刻を送信時刻として処理は終了する。

【００２４】ループ処理では、送信用データが準備され
た各関連ファイル(以下、単に関連ファイルとする)の送
信データが送信時刻になったかチェックし、順番に送信
してゆく処理を繰り返す。まず、チェック対象となるフ
ァイルを関連ファイルより１つ選択する（２１１２）。
チェック対象ファイルの送信データの時刻情報と送信時
刻は一致するかチェックする（２１１３）。一致しない
場合、まだ送信時刻になっていないので何もせず、ステ
ップ２１１８へスキップする。一致する場合、送信デー
タを図２０に示した該当する送信用バッファ１３０１に
登録し送信する（２１１４）。そして、チェック対象と
なっている該当ファイルより次のブロックを読込み（２
１１５）、読込み成功の場合（２１１６）、読込んだデ
ータを新たに該当ファイルの送信用データとする（２１
１７）。チェックファイルは、関連ファイルの最後のフ
ァイルでなければ（２１１８）、チェック対象となるフ
ァイルを次の関連ファイルとし（２１１９）、ステップ
２１１３にスキップし処理を繰り返す。ステップ２１１
８にて最後のファイルであれば、次の時刻の情報を送信
する処理に移る。即ち、カウント最小時分待ち（２１２
０）、送信時刻をカウント最小時分つけ加えた時刻とす
る（２１１１）。ちなみに、カウント最小時分は、列車
の運行管理システムにおける運行実績の場合、通常、秒
である。そして、ステップ２１１２に戻り新たにチェッ
ク処理を行う。さて、ステップ２１１６にて、読込みに
失敗した場合、つまり、ファイルの最後となりもう登録
されているデータがない場合、該当ファイルを閉じる
（２１２２）。そして、全てのファイルが閉じられたか
チェックし（２１２３）、全て閉じられた場合は、もう
送信するデータがないので処理を終了する。まだオープ
ンしているファイルがある場合、ステップ２１１８にス
キップし処理を継続する。以上、運行再現処理部の説明
を終了する。

【００２５】

【発明の効果】以上、本発明によれば、 １．制御用コントローラーを前記制御装置として利用し
た列車運行管理システムにおいても実績データを時系列
に登録することが可能となり、よって、これら実績デー
タよりデバックや運行異常の原因を究明することが可能
となり、また、１日の運行再現が可能となりこれを複数
のモニタ端末にてモニタすることにより運用者の訓練な
どにも利用できるようになった。

【００２６】２．データ蓄積装置は、列車の運行制御に
直接関る装置ではなく、運行モニタ用ネットワークも同
様に列車の運行制御に直接関るネットワークではない。
よって、オンライン運行中においても、列車の運行制御
に影響を与えることなく実績データの確認や列車運行の
再現モニタリングが可能となった。

【００２７】３．コード指定マルチキャスト送信によ
り、関連各装置はデータ蓄積装置を直接意識することは
なく、データ蓄積装置は関連各装置に何ら影響を与える
ことなく必要なデータを入手することができる。よっ
て、関連各装置はデータ蓄積装置対応に新たな機能追加
する必要はない。また、万一、データ蓄積装置が異常で
ダウンすることがあっても、データの蓄積は一時的にス
トップすることはあるが関連各装置に影響はなく列車運
行管理システムの無停止運転を保つことが可能である。

【図面の簡単な説明】

【図１】本発明の１実施例におけるデータ蓄積装置の構
成を示した図である。

【図２】本発明の１実施例における駅分散制御型列車運
行管理システムの構成の１例を示した図である。

【図３】本発明の１実施例における列車運行管理システ
ムの関連装置間のデータの流れの１例を示した図であ
る。

【図４】本発明の１実施例における登録処理管理部とデ
ータ登録処理部の機能に関連したデータや処理の流れを
示した図である。

【図５】本発明の１実施例における登録処理管理部の処
理フローを示した図である。

【図６】本発明の１実施例における始業処理、終業処理
における関連装置間のデータの流れの１例を示す図であ
る。

【図７】本発明の１実施例における送信パケットのパケ
ット構成の１例を示した図である。

【図８】本発明の１実施例における運行状態と始業フラ
グ、終業フラグとの関係を示した図である。

【図９】始業、終業により運行状態の遷移を示した図で
ある。

【図１０】本発明の１実施例におけるデータ登録処理部
のデータ登録処理フローを示した図である。

【図１１】本発明の１実施例における受信データ登録フ
ァイルの登録データの構成を示した図である。

【図１２】本発明の１実施例における受信データ登録フ
ァイルのディレクトリ構成の１例を示した図である。

【図１３】本発明の１実施例におけるデータ登録処理部
の運行モニタ情報送信でのデータの流れを示した図であ
る。

【図１４】本発明の１実施例におけるデータ登録処理部
のデータ登録処理のほかモニタデータ送信の処理フロー
を示した図である。

【図１５】本発明の１実施例における実績データ提示処
理での機器構成とデータの流れを示した図である。

【図１６】本発明の１実施例における実績データ提示処
理での定数データ登録用の画面例を示した図である。

【図１７】本発明の１実施例における実績データ提示処
理部の処理フローを示した図である。

【図１８】本発明の１実施例における実績データ提示処
理での実績データ提示画面の１例で、データのダンプ表
示を示した図である。

【図１９】本発明の１実施例における実績データ提示処
理での実績データ提示画面の１例で、軌道回路の閉塞状
態、進路設定状態を示した図である。

【図２０】本発明の１実施例における運行再現処理のデ
ータの流れを示した図である。

【図２１】本発明の１実施例における運行再現処理部の
処理フローを示した図である。

【図２２】本発明の１実施例における運行再現処理部の
処理フローを示した図である。

【符号の説明】

１０１…データ蓄積装置、１０２…登録処理管理部、１
０３…データ登録処理部、１０４…実績データ提示部、
１０５…運行再現部、１０６，１０７…データ送受信
部、１０８…記憶装置、１０９…運行状態ファイル、１
１０…実績データ登録ファイル、２０２…中央処理装
置、２０３…指令端末、２０４…駅制御装置、２０５…
連動装置、２０６…案内放送装置、２０７…駅間ネット
ワーク、２０８…モニタ端末、２０９…運行モニタ用ネ
ットワーク。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 斎藤 儀忠 茨城県ひたちなか市市毛1070番地 株式会 社日立製作所水戸事業所内 (72)発明者 早乙女 弘 茨城県ひたちなか市市毛1070番地 株式会 社日立製作所水戸事業所内 (72)発明者 佐々木 敏郎 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 Ｆターム(参考） 5H161 AA01 BB02 FF01 GG02 GG03 GG13 GG22 JJ21 JJ29

Claims (1)

【特許請求の範囲】
1. 【請求項１】 軌道回路情報より列車の追跡処理を行
   い、これに基づき列車の進むべき進路を決定し、信号機
   や転てつ器などの地上設備機器を制御する列車の運行管
   理システムにおいて、軌道回路情報、地上設備機器の状
   態情報、進路出力情報など、システム内の運行制御用ネ
   ットワークに送信された種々の情報を受信して、時系列
   的に記憶装置に蓄積し、蓄積したデータの提示および該
   データより列車の運行の再現のうち少なくとも一方を実
   現することを特徴とする列車運行管理システム。