JP2011143779A - 信号設備保守システム - Google Patents

Abstract

【課題】信号設備保守システムにおいて、様々な原因による軌道回路の不正落下に対し、その原因に応じた的確な保守支援情報を提供する。
【解決手段】軌道回路信号の受信レベル低下時のトレンド（変化率、低レベル状態継続時間など）を周囲環境と共に類型化し、類型毎に保守情報（保守対応の要否、難度、復旧見込み時間など）を対応付け、データベースに蓄積する。受信レベル低下の際、データベースを参照し、合致する類型に対応付けられた保守情報を保守端末へ提供する。
【選択図】図１

Description

本発明は、軌道回路を有した鉄道信号設備の保守システムに関する。

軌道回路は鉄道列車の在線検知に広く用いられている信号設備である。軌道回路を構成する2本のレール上に鉄道車両が在線すると、車軸が鉄輪を介してレールを短絡し、軌道回路の一端からレールへ送信した信号（以下、軌道回路信号）を迂回させるため、他端でその信号の受信レベルが低下することを原理としている。

軌道回路信号の受信レベルの低下は、列車の在線だけではなく、レールの破断、受信器故障、レールの浸水、障害物による短絡などによっても発生する。しかし、受信レベルの大小に基づく在線検知手法は、列車の在線と、これらの不測事象とを区別できない。このため、予期せず受信レベルが低下した場合、保守作業員がその原因を調べた上で適切な復旧措置を取る必要があり、その分の手間と時間がかかる。

復旧作業の迅速化を支援する方法として、軌道回路上の一端から他端への電流・電圧の入出力情報と、軌道回路の回路モデルとから、回路特性の変化を検出し、どのような回路特性に変化したかを予め想定したケースと照合することで、軌道回路上の故障部位を特定する、という軌道回路監視装置が、特許文献１に開示されている。

特開平１１−２７８２６９号公報

本発明は、軌道回路モデルの精度に依らず、様々な異常要因に応じて的確な保守支援情報を提供することを目的とする。

本発明の信号設備保守システムは、二本のレールで成る軌道区間の一端から送信した信号と他端で受信した信号との受信レベルの相対情報に基づいて列車の在線を検出する在線検出部と、ある期間の前記受信レベルの時間推移を予め定めた類型に分類し、その分類を類型情報として出力するクラス化演算部と、前記予め定めた類型に応じた保守支援情報を保持するデータベースと、前記類型情報を用いて前記データベースを参照し、得られた保守支援情報を保守端末へ出力する参照部と、を有することを特徴とする。

本発明によれば、軌道回路の様々な異常要因に応じ、的確な保守支援情報を提供できる。

図１は本発明の実施例１の信号設備保守システムにおけるシステム構成を示す図である。 図２は正常な受信レベルの推移例を示す図である。 図３は軌道回路信号受信部の故障を想定した受信レベルの推移例を示す図である。 図４はレールの浸水を想定した受信レベルの推移例を示す図である。 図５は本発明の実施例１の保守支援情報データベース１０７のデータフォーマットを示す図である。 図６はクラス化演算部の処理フローを示す図である。 図７は参照部の処理フローを示す図である。 図８は本発明の実施例２の信号設備保守システムにおけるシステム構成を示す図である。 図９は本発明の実施例３の信号設備保守システムにおけるシステム構成を示す図である。

以下、本発明の実施の形態について図面を用いて説明する。

図１は、本実施例の信号設備保守システムにおけるシステム構成を示している。軌道回路１０５は鉄道レールで構成され、レールの短絡状態に応じて軌道回路上の列車の在線を検出するために用いられる一般的なものである。

在線検出部１０２は、軌道回路１０５上の列車の有無を検出するためのものである。軌道回路１０５の一端から軌道回路信号を送信する送信部と、これを他端で受信する受信部と、受信信号の大きさと送信信号の大きさとの比（以下、受信レベルと呼ぶ）を計算する演算部とを備える。

列車が軌道回路１０５上に在線している場合、車軸が鉄輪を介してレールを短絡するため、軌道回路信号は車軸を迂回する。このとき送信信号の大きさに対する受信信号の大きさ（以下、この比を受信レベルと呼ぶ）が大きく低下することから、列車の在線を検出できる。この在線検出の原理は、今日一般的に利用されている。

以下では列車在線有無と判断するための受信レベルの閾値をＬ２（落下判定閾値）とし、受信レベルがこれを下回る状態を軌道回路「落下」と呼ぶ。

在線検出部１０２は保守支援部１０１と接続し、列車在線有無の判断のために求めた受信レベルを逐一伝送する。

保守支援部１０１は、クラス化演算部１０３、参照部１０４、保守支援データベース１０７、環境検出部１０８を有する。

クラス化演算部１０３は、在線検出部１０２から受け取った受信レベルの時間推移データの特徴を予め定めた基準に沿って数値化し、クラス分けする。このための手法には、例えば基準データ列からの距離（距離の定義は予め規定）を導出し、距離によって分類するというよく知られたクラスタリング手法を利用できる。

クラス分けに用いるデータ列は、受信レベルが低下してＬ１（分析開始閾値）を下回ったところから、時間ｔｗが経過するまでの間に取得したデータ列とする。クラス化演算部１０３は、算出したクラスを参照部１０４へ出力する。処理フローは後述する。

環境検出部１０８は、天候（晴天・雨天・降雪など）を検出し、参照部１０４からの要求に応じて、これを参照部１０４へ通知する。天候を検出する手段は様々知られており、どの方法でも良い。尚、環境検出部１０８で検出する情報は天候に限らず、軌道回路の状態や、あるいは保守作業に影響するものであれば何でも良く、例えば気温、湿度などで構成した気象情報や、月日や時刻の情報を含んでも良い。以下では簡単のため、晴天・雨天（少）・雨天（多）の3情報で成る気候情報を検出する場合を前提として説明する。

保守支援情報データベース１０７は、気候情報とクラス情報の組ごとに保守支援情報を蓄積しており、この二つをキーに参照されたとき、保守支援情報を一つ定める。この詳細は後述する。

参照部１０４は、気候情報とクラス情報をキーに保守支援情報データベース１０７を検索して保守支援情報を引き出し、保守端末１０６へと送信する。処理フローは後述する。
保守端末１０６は、保守支援部１０１から受信した保守支援情報を表示する。

図６はクラス化演算部１０３の処理フローである。クラス化演算部１０３は、ＳＴＡＲＴからＥＮＤまでの処理を繰り返す。以下、クラス化演算部１０３の各処理の説明で登場するタイマは、受信レベルの蓄積期間を測るためのものである。

処理６０１は初めの処理で、タイマが動作中かどうかを調べる。動作中であれば処理６０５へ、それ以外は処理６０２へ移る。

処理６０２では、受信レベルが処理開始閾値Ｌ１より小さいかどうかを判定する。小さければ処理６０３へ、それ以外はＥＮＤへ移る。

処理６０３では、タイマを始動させる。その後、処理６０４へ移る。処理６０４では、受信レベルデータをバッファに蓄積する。後述する処理６０７では、このバッファに蓄積した受信レベルデータを対象に、クラス化演算を行う。本処理はそのためのデータ収集処理である。その後、ＥＮＤへ移る。

処理６０５では、タイマのカウントが時間ｔｗより大きいかどうかを判定する。大きければ処理６０６へ、それ以外は処理６０４へ移る。処理６０６では、タイマを停止する。その後、処理６０７へ移る。

処理６０７では、処理６０４でバッファに蓄積した受信レベルデータを対象に、クラス化演算を適用する。この演算の詳細は、よく知られたクラスタリング手法に従う。その後、処理６０８へ移る。処理６０８では、処理６０７で得たクラス情報を参照部１０４へ送信する。その後、ＥＮＤへ移る。

以上の処理フローにより、クラス化演算部１０３は、受信レベルが処理開始閾値Ｌ１を下回った時点から時間ｔｗの間のデータに対し、クラス化処理を適用する。

図７は参照部１０４の処理フローである。参照部１０４は、ＳＴＡＲＴからＥＮＤまでの処理を繰り返す。

処理７０１は初めの処理で、クラス化演算部１０３からのクラス情報の受信が有ったかどうかを調べる。クラス情報の受信があれば処理７０２へ、それ以外はＥＮＤへ移る。
処理７０２では、環境検出部１０８へと気候情報を要求し、気候情報を取得する。その後、処理７０３へ移る。

処理７０３では、処理７０１で取得を確認したクラス情報と、処理７０２で取得した気候情報を用いて、保守支援情報データベース１０７を検索し、保守支援情報を取得する。その後、処理７０４へ移る。

処理７０４では、処理７０３で取得した保守支援情報を、保守端末１０６へ送信する。
以上の処理フローにより、参照部１０４は、クラス情報と気候情報に応じた保守支援情報を、保守端末１０６へ送信できる。

図２は、在線検出部１０２が列車の在線を検出した時の受信レベルの推移例である。これは列車が軌道回路１０５に進入／退出して正常に「落下」したケースを想定している。縦軸は受信レベル、横軸は時刻である。縦軸には、前述の分析開始閾値Ｌ１と、落下判定閾値Ｌ２を記している。

列車が軌道回路１０５に進入すると受信レベルが低下し始め、時刻ｔ１で分析開始閾値Ｌ１を下回る。その後も受信レベルは低下を続け、時刻ｔ２に落下判定閾値Ｌ２を下回る。その後、在線している列車の車軸のインピーダンスで決まる値に、受信レベルが一定する。

しばらく経って列車が軌道回路１０５から退出すると受信レベルが回復し始め、時刻ｔ５には落下判定閾値Ｌ２を上回り、やがてもとの受信レベルに戻る。このケースでは、在線検出部１０２は時刻ｔ２からｔ５の間、列車が在線していると判定する。

これは実際の在線状況と、受信レベルが閾値まで変化する分の誤差はあるものの、おおよそ一致する。クラス化演算部１０３は、時刻ｔ１を起点に、時間ｔｗ間のデータについて、クラス分けのための処理を適用する。

図２で説明したようにして、在線検出部１０２は列車の在線を検出できるが、しかし、受信レベルの上下は列車が在線した場合に限らず、何らかの異常事象によっても起こり得る。その時、在線検出部１０２は列車の有無を誤る場合がある。その一例を図３、図４を用いて説明する。

図３は異常なシーンの受信レベルの推移で、軌道回路信号の受信器が故障して信号受信できなくなった瞬間の前後を想定している。この場合、受信レベルは急峻に低下し、時間が経っても回復しない。時刻ｔ１０で受信レベルはＬ２を下回り、落下を判定したままとなる。

クラス化演算部１０３は、時刻ｔ９を起点に、時間ｔｗ間のデータについて、クラス分けのための処理を適用する。この時の処理対象のデータは、正常時のデータに比べて落ち込みが急峻で、時間ｔｗが経っても回復を始めないという特徴がある。この特徴の差が、クラスの違いとなって抽出される。

図４もまた異常なシーンの受信レベルの推移で、降雨や積雪に起因する浸水が軌道回路信号の迂回路を形成したシーンを想定している。浸水の度合いに伴い、列車在線時の正常な推移に比べてゆっくりと、受信レベルが低下している。

クラス化演算部１０３は、受信レベルが処理開始閾値Ｌ１を下回る時刻ｔ７を起点に、時間ｔｗ間のデータについて、クラス分けのための処理を適用する。この時の処理対象のデータは、正常時のデータに比べて落ち込みが緩慢で、時間ｔｗが経ってもなお落ち込み続けるという特徴がある。正常時（図２）とも受信器故障時（図３）とも異なるこの特徴の差が、クラスの違いとなって抽出される。

図５は保守支援情報データベース１０７のデータフォーマット例である。気候とクラスの二つをキーにして保守支援情報が一つ定まる。縦欄に気候を、横欄にクラスを列挙して行列形式で表しており、それぞれの値が交差する点で、保守支援情報を定めている。保守支援情報の内容は、保守緊急度、軌道回路落下の推定原因、回復見込み時間などである。

この表の内容は、事前に蓄積した十分数の経験情報から、予め定めることができる。
クラスと保守支援情報を一対一に対応させるのではなく、気候も考慮した場合分けをしたのは、先述した浸水による異常落下も想定されるためである。

一例として、ここではクラスＡに列車在線による正常ケース（図２に相当）を、クラスＢに受信器故障による異常ケース（図３に相当）を、クラスＣに浸水による異常ケース（図４に相当）を割り当てている。

例えば、ある観測された受信レベルデータの推移がクラスＡに相当する場合、正常（緊急度なし）であると判断する。クラスＢに相当する場合は、原因は受信器故障と考えられ、直ちに修理を行わねば回復見込みが無いため、緊急度大である。クラスＣに相当する場合は、多量の降雨があれば、原因は浸水であると考えられ、時間と共に回復する見込みがあり、緊急度中である。

ところが晴天や少量の降雨の場合は、原因は浸水とは考え難いため、別の原因が想定される（図中では原因不明と記述）。このようにして得られた保守支援情報は、オペレータが異常に応じた復旧保守作業を的確化するために役立てられる。

以上の説明において、クラス化演算部１０３では、よく知られたクラスタリング手法を用いて受信レベルの時間推移のトレンドを分類すると説明したが、この方法は、例えば受信レベルの下降の傾きや落下継続時間などを特徴量として直接計算し、それに応じて分類する方法でも良い。

図２の例であれば、受信レベル下降の傾きは例えば（Ｌ２−Ｌ１）／（ｔ２−ｔ１）で求められる。また、落下継続時間は、（ｔ５−ｔ２）で求められる。（図３の例では落下継続時間を同様には求められないが、実用上は適当な打ち切り時間ｔｘを設ければ良い。図４の例では受信レベルの下降の傾きを、適当な打ち切り時間ｔｙを設けて（Ｌ２−Ｌ１）／ｔｙとして導出すれば良い。）

また、クラス化処理を適用する受信レベルデータの取得期間を受信レベルがＬ１を下回った時点からｔｗ間としたが、この期間の取り方は、受信レベルの正常な推移と異常な推移とを区別できるデータ列を取得できる期間であれば、この限りではない。例えば受信レベルがＬ１を下回る時点から、回復して再びＬ１を上回る時点まででも良い（回復が遅いケースへの対応のため適当な打ち切り時間を設けることが前提）。

本実施例によれば、軌道回路信号の受信レベルのトレンドを正常ケースおよび様々な異常ケースに対応付けられ、周囲環境も考慮し、状況に応じた的確な保守支援情報を提供できる。

図８は、実施例２の信号設備保守システムにおけるシステム構成を示している。実施例１の信号設備保守システムと比較して、車両情報検出部８０１を新たに追加した。これに合わせ、保守支援情報データベース１０７の記憶フォーマットを、検索キーに車両情報を加えた形に変更したことを前提とする。

車両情報検出部８０１は、列車型式や列車速度を検出し、参照部１０４へ通知する。車両情報検出部８０１の一例としては速度検出手段を有した車両自身が考えられる。このとき、保守支援部１０１との間に無線通信手段を持つことで、列車型式や列車速度を通知できる。あるいは、車両情報検出部８０１として、ダイヤを把握し、時刻・位置情報から列車を特定できる運行管理装置が考えられる。

本実施例によれば、保守支援情報を車両特性（例えば車両型式の違いに応じた車軸のインピーダンスの違い）を考慮して詳細に類型化することで、提供する保守支援情報をより的確化できる。

図９は、実施例３の信号設備保守システムにおけるシステム構成を示している。実施例２の信号設備保守システムと比較して、入力端末９０１を新たに追加した。

入力端末９０１を介し、保守支援情報データベース９０１の内容を書き換えることができる。これを介して実際に経験した保守緊急度や軌道回路落下原因、復旧時間情報などをデータベースヘフィードバックすることで、提供する保守支援情報をより的確化できる。

１０１ 保守支援部
１０２ 在線検出部
１０３ クラス化演算部
１０４ 参照部
１０５ 軌道回路
１０６ 保守端末
１０７ 保守支援情報データベース
１０８ 環境検出部
６０１〜６０８ クラス化演算部の処理
７０１〜７０４ 参照部の処理
８０１ 車両情報検出部
９０１ 入力端末

Claims (4)

1. 二本のレールで成る軌道区間の一端から送信した信号と他端で受信した信号との受信レベルの相対情報に基づいて列車の在線を検出する在線検出部と、
   列車不在時に比べて受信レベルが低下した期間を含むある期間において、受信レベルの時間推移を予め定めた類型に分類し、その分類を類型情報として出力するクラス化演算部と、
   前記予め定めた類型に応じた保守支援情報を保持するデータベースと、
   前記類型情報を用いて前記データベースを参照し、得られた保守支援情報を保守端末へ出力する参照部と、
   を有することを特徴とする信号設備保守システム。
2. 請求項１に記載の信号設備保守システムにおいて、
   天候を含む予め定めた環境情報を検出する環境検出部を有し、
   前記データベースが前記予め定めた環境情報に応じた保守支援情報を保持し、
   前記参照部が前記環境検出部から取得した環境情報を用いて前記データベース参照することを特徴とする信号設備保守システム。
3. 請求項１または請求項２に記載の信号設備保守システムにおいて、
   軌道区間を走行する車両の型式や速度を含む予め定めた車両情報を検出する車両情報検出部を有し、
   前記データベースが前記予め定めた車両情報に応じた保守支援情報を保持し、
   前記参照部が前記車両情報検出手段から取得した車両情報を用いて前記データベースを参照することを特徴とする信号設備保守システム。
4. 請求項１乃至請求項３のいずれか一つの請求項に記載の信号設備保守システムにおいて、
   前記データベースを更新するための入力端末を有することを特徴とする信号設備保守システム。

Images