運行管理方法及びシステム

【課題】事故、車両トラブル等の有事の際必要となる運転整理についての技術であり、特に、列車自身が自律的に運行管理を行うシステムを提供する。
【解決手段】有事発生時の当事者である列車１０２と、その周囲にいる影響が及ぶと予想される列車１０１がお互いに周囲の状況判断、情報収集をすることにより、本来影響を受けなくてもよい列車１０３に負荷をかけることなく、最小限の処理により、ダイヤ修正のための処理の選択、指示を行う。

【発明の詳細な説明】
【技術分野】
【０００１】
事故、車両トラブル等の有事の際必要となる運転整理についての技術であり、特に、列車自身が自律的に運行管理を行うシステムに関する。
【背景技術】
【０００２】
現在の運行管理システムにおいては、ダイヤを管理する装置が日々のダイヤ管理を行う。もし、走行している列車に事故、車両トラブル等により、ダイヤの乱れが発生した場合には、中央装置からの指令により、運転整理が行われ、ダイヤの乱れを解決している。
【０００３】
これに関係する技術として、特許文献１が挙げられる。特許文献１には、中央管理部に列車運行シミュレーションする機能を持たせることにより、列車運行が乱れた際、列車運行のシミュレーションを繰り返して最適な運転整理案を作成し、通常運転時に極力近づける技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2001-1904号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、特許文献１では、中央管理部に追加されたシミュレータによる予想ダイヤを基に運転整理を行う為、もし、同時に複数個所での事故、システムダウン等については、考慮がされておらず、同時に並行して早急な処理を行う必要のある場合には対処できない。また、中央管理部での指示、制御による為、関係の無い列車にまでも影響を及ぼす可能性が考えられる。
【課題を解決するための手段】
【０００６】
そこで本願発明では、中央管理部による制御、処理のみに頼るのではなく、有事発生時の当事者、またその周囲にいる影響が及ぶと予想される列車各自がお互いに周囲の状況判断、情報収集をすることにより、本来影響を受けなくてもよい列車に負荷をかけることなく、最小限の処理により、最適な処理の選択、指示を行う。
【発明の効果】
【０００７】
本発明によれば、中央管理部からの指示を待つことなく、必要最低限の関係車両間で対策の選択、処理を実現できる。また、もし同時に複数個所での事故、車両トラブル等の有事があった場合でも、中央管理部のようにどこか一箇所への負荷集中を避けられ、より迅速な対応が可能となる。
【図面の簡単な説明】
【０００８】
【図１】実施例における運行管理システムの概要図。
【図２】周辺運行情報の基地局情報のデータテーブル。
【図３】周辺運行情報の駅情報のデータテーブル。
【図４】周辺運行情報の列車運行情報のデータテーブル。
【図５】通常処理部におけるフローチャート。
【図６】事故処理部におけるフローチャート。
【図７】対策処理部におけるフローチャート。
【図８】対策処理部中、可能処理判定処理におけるフローチャート。
【図９】事象DBの事象DB情報のデータータテーブル。
【図１０】事象DBの障害発生列車運行情報のデータータテーブル。
【図１１】事象DBの障害対応列車情報のデータータテーブル。
【発明を実施するための形態】
【実施例１】
【０００９】
＜本実施例の概要＞
通常運行時、列車、駅は列車間通信及び列車列車間通信に必要な情報を電波で送受信する基地局の電波受信可能範囲に入ると、その基地局に対し、その時点での自分自身の運行状況を含んだ列車運行情報や駅情報を発信する。基地局は、それぞれの駅、列車から受信した列車運行情報、駅情報をデータセンタへ発信し、データセンタは基地局から受信した、列車運行情報、駅情報とどこの基地局から受信したかの基地局情報を元にそれぞれの情報をマージし、周辺運行情報を作成する。その後、データセンタはマージした周辺運行情報を全ての基地局に対して返送する。
【００１０】
＜本実施例の詳細＞
以下、図面を用いて本発明に関する実施の形態を説明する。
図１において、基地局001があり、その受信可能範囲内に列車101と102、駅201と202があるとすると、まず、基地局001のデータ受信可能範囲内に入った、列車101と102、駅201と202はそれぞれ列車運行情報501と502、駅情報401と402を基地局001に対して発信する。基地局002についても同様、基地局002のデータ受信範囲内に入った列車103と駅203はそれぞれ列車運行情報503と駅情報403を基地局002に対し発信する。なお、列車、駅からの情報発信は、該当する基地局のデータ受信範囲内に入ったことを契機に送信する場合と、一定の時間間隔で現在の情報を送信する場合と、列車、駅に何らかの異常が発生した場合にそれら異常の情報を添えて送信する場合と、がある。尚、基地局001、002とデータセンタ000はそれぞれ専用ケーブルで接続されており、基地局001、002は各列車、駅から受信したデータをこのケーブルを003、004を経由してデータセンタ000へ受け渡す。基地局001、002からデータを受信したデータセンタ000は受信した列車運行情報501〜503、駅情報401〜403の6つのデータをマージし、周辺運行情報301を作成し、周辺運行情報DBに格納する。データセンタ000は作成した周辺運行情報301を基地局001、002へ返送し、その周辺運行情報301を受信した基地局001はデータ受信範囲内にいる駅201と202、列車101と102に、基地局002はデータ受信範囲内にいる駅203と列車103に周辺運行情報301を送信する。この実施例では、基地局が２つの場合を説明したが、基地局が多数存在してもよい。その場合、データセンタで周辺運行情報をマージする範囲を予め決めておくと良い。例えば、基地局と路線の地理上の配置状態に基づき、基地局001〜基地局003を周辺運行情報をマージする一つ目の範囲とし、基地局004〜基地局008を周辺運行情報をマージする二つ目の範囲とするなどの実施方法がある。
【００１１】
図１において、各列車に搭載されているハード構成について、列車101を用いて説明する。列車101には運行管理サーバ601が搭載されており、このサーバはDB701とCPU801、通信部、から構成されている。また、CPU801は3つの処理部に分かれており、通常処理部901、事故処理部111、対策処理部121から構成されている。通常運行時は、通常処理部901が実行されており、最寄の基地局に対し、自身の運行情報を発信している。もし、列車101自身に車両トラブルや事故等の有事が発生した際には事故処理部111が実行される。逆に、自分自身にトラブルは無くても、周辺を走行する列車に事故があった際には、その障害列車に対し、応援可能かの判断、対策を実行する対策処理部121が実行される。DB701には、過去に周辺の列車に生じた事象とその際の対処結果が格納されている。そして、この運行管理サーバ601は通信部を用いて他の装置（データセンタ、基地局）とデータの送受信を行なう。
【００１２】
次に、データセンタに搭載されているハード構成について説明する。データセンタには、CPU、記憶装置、通信部を備える。このCPUは通信部により受信した列車運行情報と駅情報をマージし、DBに格納する機能を備える。この記憶装置には、列車運行情報を格納する列車運行情報DB、駅情報を格納する駅情報DB、CPUによりマージされた周辺運行情報を格納する周辺運行情報DB、がある。なお、これらDBは一つのハードディスクで構成されてもよいし、別々のハードディスクで構成されてもよい。
【００１３】
ここで、上記で説明した、データセンタ000によりマージされた周辺運行情報を構成する、基地局情報、駅情報、列車運行情報の情報テーブルの詳細をそれぞれ図２、図３、図４にて説明する。周辺運行情報は「基地局情報」、「駅情報」、「列車運行情報」の3つの情報から構成されている。今回の例の場合、データセンタ000は、基地局001と基地局002から駅201〜203の「駅情報」と、列車101〜103の「列車運行情報」を受信している。その為、データセンタ000がマージした周辺運行情報はデータを受信した「基地局情報」と「駅情報」が3つ、「列車運行情報」が3つから構成されている。以下、各情報の詳細を説明する。
【００１４】
図２に、周辺運行情報を構成する1つ目の基地局情報D1を示す。基地局情報D1は基地局名と、その基地局がどこに設置されているかを表す所在地についての情報で構成されている。所在地は、「経度、緯度」で示される。この基地局情報D1から、受信した情報が、どこの基地局から発信された情報なのかを知ることができ、データセンタ000が作成した周辺運行情報を返送する際にこのデータを参照する。
【００１５】
図３に、周辺運行情報を構成する2つ目の駅情報D2を示す。駅情報D2は駅名、異常フラグ、所在地、乗入線区についての情報から構成されている。駅情報の所在地についても同様、「経度、緯度」で示される。
【００１６】
図４に、周辺運行情報を構成する3つ目の列車運行情報D3を示す。列車運行情報D3は列車番号、ステータス、異常フラグ、線区、現在位置（経度、緯度）、次駅、始発駅、終点駅、進行方向から構成されている。ステータスは、その値によって列車の状態を表し、0:障害、1:走行中、2:停車中、3:障害対応中を表している。異常フラグも同様、その値によって障害の種別を表し、もし、事故、車両トラブル等の障害が発生した際、周辺を走行している列車へ注意を促し、場合によっては応援を求める。その値は、通常走行中の異常が無い状態の場合は0がデフォルトで設定されており、障害が発生した場合には、1:事故、2:車両トラブル、3:災害のようにその障害の種別を表す値が設定される。
【００１７】
ここで実施例１として、図１において、列車102に車両トラブルが発生した場合について説明する。列車102はトラブルが発生するまでは通常処理部902を実行している。
【００１８】
図５に、この通常処理部902の処理フローを示す。まず、列車102は、各種センサーまたは通信手段を用いて、異常（車両トラブルなど）を検知すると、自分自身に異常が無いかのチェック処理N1を実行する。N1では、自分自身に車両トラブルを検知すると事故処理N2へ処理が流れる。
【００１９】
図６に、この事故処理N2を実行する事故処理部112についての処理フローを示す。列車102は通常処理部902で異常を検知した後、事故処理部112で、障害の種別を判定する(A1)。障害が事故であれば１(A2)、車両トラブルであれば２(A3)、災害であれば３(A4)を異常フラグに立てる。今回の場合、車両トラブルが発生したとし、事故処理部112では、自身の列車運行情報の異常フラグへ車両トラブルを表す２を立てる(A3)。異常フラグを立てた後、事故処理部112では列車運行情報発信処理A5を実行し、基地局001に対して列車運行情報502を発信する。基地局001では列車102から受信した列車運行情報502がデータセンタ000へ送信され、周辺運行情報301が作成される。データセンタ000で周辺運行情報301が作成されると、データセンタ000から基地局001、002に対し周辺運行情報301が返送され、その周辺運行情報301を受信した周辺を走行する列車から列車102の車両トラブルに対し、当情報を受け取った列車が対策可能か、またどのような対策が実行できるかの回答を列車102が受信する(A6)。列車102は周囲の列車からの回答を受信後、対策可能の回答をくれた列車に対し、対策処理の指示を行う(A7)。
【００２０】
一方で、列車102の異常フラグを含んだ周辺運行情報301を受信した列車101の処理の流れについて図５を再度用いて説明する。列車102も走行中は通常処理部901を実行しており、今回の例の場合、列車101には異常が無いと仮定すると、通常処理部901では自分に異常が無いかの判定処理N1を実行し「無」を選択しN3に進む。そして、基地局001より受信した周辺運行情報301に異常を含んだ情報が無いかの判定を行う(N3)。異常フラグを含んだ列車運行情報が無い場合には、自身の現在状況の列車運行情報501を基地局001へ発信するが(N5)、今回の場合、列車101が受信した周辺運行情報301には、列車102の発信した、異常フラグ2を含んだ列車運行情報502があるので、処理は対策処理部121へ処理が渡され、対策処理N4が実行される。
【００２１】
図７に、対策処理部121の処理フロー（N4）について説明する。対策処理部121では、現状の自分自身が対応可能かを判断する(M1)。この判断には、自身の列車運行情報501のステータスにて判断する。ステータスが０、若しくは３の場合は自身に障害が発生しているか、他の列車の障害対応中の為、対応は不可と判断し、その旨の回答を発信する(M9)。今回は、列車101は通常通り走行中で対応可能だと仮定すると、自身の持つ事象DB701内に似た事象が無いかの検索処理を行う(M2)。この検索の際は、受信した、異常フラグの種類に応じて過去の事象を検索する。事象DB701内には過去に発生した事象とその際の対処結果が格納されている。もし、事象DB701内に列車102に発生した障害と同様の事象のヒットがあれば、その事象DBを参照し(M4)、可能処理の回答を発信する(M10)。事象DB内に同じような事象が無ければ、自分が可能な処理の判定をする(M5)。今回は事象DB701内には類似事象が無く、自分で対応可能な処理の判定を行うとすると、M5にて可能処理の判定を実行する。
【００２２】
可能処理判定処理M5の結果、対策がとれない場合（対策フラグが０）であれば、可能処理無しの回答を発信する(M9)。一方、なんらかの対策が可能な場合（対策フラグ１〜３）、今回の障害内容とその対策を自身の持つ、事象DB701へ追加し(M6)、列車102に対し、回答を発信する(M10)。ここで、列車102は事故処理部122の回答受信A6にて列車101からの可能処理回答を受信し、列車101に対して可能処理の実行を指示する(A7)。列車101は列車102からの指示を受け(M11)、その対策を実行する(M12)。
【００２３】
図８に、可能処理判定処理の詳細(M5)を説明する。まず、障害の発生した列車と自分が同じ線区かを基地局001から受信した周辺運行情報301に含まれる列車102の列車運行情報の線区情報から判断する(J1)。今回の例の場合、同じ線区の為J2にて進行方向の判定を行う。もし、線区は同じでも進行方向が違う場合には対策フラグを３とする(J11)。今回は、線区も、進行方向も同じの為、J3にて障害列車102と自分との位置関係を列車運行情報の現在位置より判定し、どちらが先行列車かを判定する(J3)。今回の例の場合は、列車101が列車102に対して先行している為、J4にて自分が次駅にて回送列車かの判定を行う。もし、列車101がA駅が終点でない場合には車庫に余剰車両があるか確認し(J6)、あれば対策フラグ１(J5)、なければ、複線かどうかにより、追い抜けるかの判断を行う(J7)。複線であれば、追い抜ける為、対策フラグ２とする(J8)。今回の列車101は次駅がA駅となっており、次駅で回送列車となる為、対策フラグ１とする(J5)。
【００２４】
ここで、この事象DB701のデータテーブルとそれを構成する情報を図９、図１０、図１１に示す。
【００２５】
図９に、事象DB701に格納されている事象DB情報P1の詳細を示す。事象DB情報P1は「障害発生日」「障害内容」「障害発生列車番号」「対策方法」「障害対応列車番号」から構成されている。また、「障害発生列車番号」と「障害対応列車番号」は、それぞれ「障害発生列車運行情報」「障害対応列車運行情報」のキーとなっている。
【００２６】
図１０に、「障害発生列車運行情報」の詳細を示す。障害発生列車運行情報P2は「列車番号」「異常フラグ」「線区」「障害発生時位置」「進行方向」から構成されている。
【００２７】
図１１に、「障害対応列車運行情報」の詳細を示す。障害対応列車運行情報P3は「列車番号」「対策フラグ」「線区」「障害対応時位置」「進行方向」から構成されている。
【００２８】
最後に、列車103の処理フローについて説明する。列車103も走行中は通常処理部903を実行しており、自身の異常有無と基地局002から受信する周辺運行情報301の異常有無の判定を行っている。今回の場合、列車103には障害は無く、通常通りの運行と仮定すると、列車103は通常処理部903で、図５において、自身の異常が無いかの判定処理(N1)により異常無しと判定し、基地局002から受信した周辺運行情報301の異常有無の判定を行う(N3)。今回の場合、基地局002から受信した周辺運行情報301には列車102の障害発生情報が含まれている為、対策処理N4を実行する。対策処理部123へ処理が渡されると図７において、自身が対応可能かどうかの判定を行う(M1)。今回の場合、図４において、列車103の列車運行情報のステータスは１なので、対応可能と判定し、事象DB703の類似事象の検索を行う(M2)。列車103も列車102と同様、自身の持つ事象DB703に類似事象が無いと仮定すると、可能処理判定処理M5を実行する。今回の例の場合図８の可能処理判定処理M5において、図４の列車運行情報D3から障害発生列車102の線区と列車103の線区は別線区の為、J9にて同じ駅に乗り入れるかの判定を行う。列車103の線区は列車102の線区とは交わらず、同じ駅に乗り入れることもないので、対策フラグは０となる(J12)。その結果、図７の対策処理部123では、可能処理無の回答を列車102に対し発信する(M9)。
【符号の説明】
【００２９】
000 データセンタ
001〜002 基地局
003〜004 基地局・データセンタ間ケーブル
101〜103 列車
201〜203 駅
301 周辺運行情報
401〜403 駅情報
501〜503 列車運行情報
601〜603 運行管理サーバ
701〜703 DB
801〜803 CPU
901〜903 通常処理部
111〜113 事故処理部
121〜123 対策処理部
D1 基地局情報
D2 駅情報
D3 列車運行情報
P1 事象DB情報
P2 障害発生列車運行情報
P3 障害対応列車運行情報

【特許請求の範囲】
【請求項１】
列車に搭載された処理装置による運行管理方法であって、
列車運行の異常を検知するステップと、
前記検知した異常が自列車の異常か否かを判断するステップと、
前記判断した結果が自列車の異常であった場合に、その異常の種類を判別するステップと、
当該異常の種類に関する情報を当該列車と通信可能な基地局に対し送信するステップと、
前記送信した異常の種類に応じて他の列車が送信してきた対処情報を受信するステップと、
前記対処情報に従い、当該対処情報を送信してきた列車に対して対処指示を送信するステップと、
を備えることを特徴とする運行管理方法。
【請求項２】
請求項１に記載の運行管理方法において、
前記他の列車は、前記列車から送信された異常の種類に関する情報をキーに、当該異常の種類に関する過去の対処情報を纏めたデータベースから当該異常の種類に応じた対処情報を抽出し、前記基地局を介して前記列車に送信することを特徴とする運行管理方法。
【請求項３】
請求項２に記載の運行管理方法において、
前記他の列車は、前記異常の種類に関する情報と共に前記列車の線区情報、進行方向情報、を受信し、
前記対処情報を抽出する際に、前記データベースに前記異常の種類に関する過去の対処情報が無い場合は、前記受信した前記列車の線区情報、進行方向情報に基づき対処情報を抽出することを特徴とする運行管理方法。
【請求項４】
列車に搭載された第１のサーバと、前記第１のサーバと前記第２のサーバとの情報伝達を行う基地局と、を備える運行管理システムであって、
前記第一のサーバは、
列車又は運行の異常を検知する異常検知部と、
前記検知した異常が自列車の異常か否かを判断する通常処理部と、
前記判断した結果が自列車の異常であった場合に、その異常の種類を判別する事故処理部と、
前記異常の種類に関する情報を前記基地局に送信し、当該送信した異常の種類に応じて他の列車が送信してきた対処情報を受信する通信部と、
前記対処情報に従い、当該対処情報を送信してきた列車に対して対処指示を送信する対策処理部と、
を備えることを特徴とする運行管理システム。
【請求項５】
請求項４に記載の運行管理システムにおいて、
前記他の列車に搭載される第２のサーバを更に備え、
当該第２のサーバは、
前記異常の種類に関する情報を受信し、前記対処情報を送信する通信部と、
過去に発生した異常の種類と当該異常に対して行なった対処に関する対処情報とを格納した履歴情報記憶部と、
前記受信した異常の種類に関する情報をキーに、前記履歴情報記憶部を検索し、当該履歴情報記憶部から当該異常の種類に応じた対処情報を抽出する対策処理部と、
を備えることを特徴とする運行管理システム。
【請求項６】
請求項５に記載の運行管理システムにおいて、
前記第２のサーバの通信部は、前記異常の種類に関する情報と共に前記列車の線区情報、進行方向情報、を受信し、
前記対策処理部は、前記対処情報を抽出する際に、前記履歴情報記憶部に前記異常の種類に対する対処情報が無い場合は、前記受信した前記列車の線区情報、進行方向情報に基づき対処情報を抽出することを特徴とする運行管理システム。

【図１】