JP2001071908A - 列車保安システム - Google Patents

Abstract

(57)【要約】 【課題】 サブシステム間にデータベースが分散配置さ
れた列車保安システムにおいて、サブシステム間の通信
電文中にデータベースのバージョン番号を含めずに、サ
ブシステム間のデータベースバージョンの不一致を検出
する。 【解決手段】 マスターデータベース４から各サブシス
テム200,330に分散配置するデータベースを生成する際
に、マスターデータベース４のバージョンに１対１に対
応する鍵を生成し、各データベース200,330に付加す
る。各サブシステムは、制御電文を送信する際、データ
ベースに記載された鍵で暗号化する。車上側システム
は、受信電文をデータベース330に記載された鍵で復号
化する。制御側と車上側とでデータベースバージョンが
一致しない場合、車上側では受信電文を復号化できない
から、バージョンの不一致を確実に検出できる。制御電
文にバージョン番号を含める必要がないので、制御電文
のビットを有効活用できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、計算機を用いた列
車保安システムに係り、特に、列車保安システムにおけ
るデータベースのバージョン管理方法に関する。

【０００２】

【従来の技術】分散型の制御システムにおいては、それ
ぞれのサブシステムが必要なデータを保持すると、サブ
システム間の伝送量を低減させ、制御を高度化すること
が可能である。

【０００３】このようなシステムの例として、列車保安
システムを考える。路線は、閉塞と呼ばれる区間に分割
されており、列車保安システムは、１閉塞に１列車のみ
の進入を許容するよう制御し、列車の衝突を防止する。
例えば、閉塞Ａに列車の存在を検出した地上システム
は、後続列車に対して、それよりも手前の閉塞Ｂまでは
進入してよいことを示す情報を伝送する。後続列車に
は、各閉塞の長さを記したデータベースが搭載されてい
るため、停止すべき地点までの距離を算出できるので、
先行列車に衝突しないよう制御できる。

【０００４】ここで重要となるのが、地上側システムと
車上側システムのデータベースの整合性である。例え
ば、路線改修によって閉塞の区分が変わったにもかかわ
らず、その変更内容が地上または車上のいずれか一方の
データベースにしか反映されなかった場合には、停止す
べき地点に対する認識が異なることになり、最悪の場合
には列車衝突に至るおそれがある。

【０００５】このような事態を防止するため、地上から
送信する制御情報にはデータベースのバージョンが付加
されており、車上装置は自身のデータベースのバージョ
ンと照合し、バージョンの不一致を検出していた。不一
致の場合には直ちにブレーキを出力する処理により、危
険側への制御は防止されることになる。

【０００６】

【発明が解決しようとする課題】このような従来のデー
タベースのバーション管理方法では、制御電文中にバー
ジョン番号を含める必要があるため、その分、実際の制
御に使用できるデータの量は減少することになる。制御
情報の伝送回線が貧弱な場合、特に深刻な問題となる。
したがって、伝送情報中のバージョン番号は最小限の長
さにとどめたいところであるが、あまり短くし過ぎる
と、同一番号がサイクリックに使用される頻度が増加
し、不一致を検出できなくなる可能性も増大するという
問題があった。

【０００７】本発明の目的は、サブシステム間にデータ
ベースが分散配置された列車保安システムにおいて、サ
ブシステム間の通信電文中にデータベースのバージョン
番号を含めずに、サブシステム間のデータベースバージ
ョンの不一致を検出する手段を備えた列車保安システム
を提供することである。

【０００８】

【課題を解決するための手段】本発明は、マスターデー
タベースから生成される複数のデータベースがサブシス
テム間に分散配置されるデータベースシステムを有する
列車保安システムにおいて、サブシステム間の通信をマ
スターデータベースのバージョンと一意に対応する鍵に
より暗号化する暗号化手段と、被制御側サブシステムに
おいて受信した電文を正常に復号化できた場合にのみサ
ブシステム間に分散配置されたデータベースのバージョ
ンが一致していると判定する判定手段とを備えた列車保
安システムを提案する。

【０００９】前記制御側サブシステムは、例えば車両が
走行する路線数に合わせて、バージョンが異なるが複数
のデータベースを搭載することができる。

【００１０】前記暗号化手段を、制御電文の送信側にお
いてエラーチェックコードを付与した上で暗号化する手
段とし、前記被制御側サブシステムの判定手段を、復号
化の後にエラーをチェックして誤りの有無により復号化
の成功または失敗を判定する手段としてもよい。

【００１１】前記被制御側サブシステムの判定手段は、
復号化の失敗が所定回数に達した時にデータベースのバ
ージョンが一致していないと判定する判定手段とするこ
とも可能である。

【００１２】いずれの場合も、前記被制御側システムに
おいて受信した電文を正常に復号化できなかった場合に
被制御側システムを強制的に停止させる手段を備えるこ
とが望ましい。

【００１３】従来の問題は、制御電文中にバージョン番
号を含めているために生じていた。本発明においては、
制御電文を暗号化し、暗号化／復号化の鍵をバージョン
番号として用い、制御電文中にバージョン番号を含める
ことなく、制御側，被制御側でデータベースを照合しよ
うとする。すなわち、本発明は、データベースの生成ま
たは変更に際して、制御側および被制御側データベース
のバージョンに１対１に対応して鍵を定め、制御側は制
御電文をバージョンに対応した鍵を用いて暗号化し、被
制御側は受信した制御電文を自身のデータベースバージ
ョンに対応した鍵を用いて復号する。制御側，被制御側
でデータベースバージョンが不一致である場合、被制御
側は受信電文を正しく復号できないため、制御を実行で
きず、データベースにバージョン不一致がある状態での
誤った制御を抑止できる。

【００１４】

【発明の実施の形態】次に、図１〜図１０を参照して、
本発明による列車保安システムの実施例を説明する。

【００１５】図１は、本発明による列車保安システムの
地上側の構成を示すブロック図である。路線は、閉塞と
呼ばれる区間に分割されており、列車保安システムは、
１閉塞に１列車のみの進入を許容するよう制御し、列車
の衝突を防止する。

【００１６】レール２３には、閉塞に分割するという必
要に応じて絶縁材２４が挿入され、電気的に絶縁されて
いる。列車検知装置２１ａ〜２１ｄは、絶縁された区間
毎に設置されている。列車検知装置２１ａ〜２１ｄとレ
ール２３とは、軌道回路といわれる電気回路を構成して
おり、列車の車軸３８が両側のレール２３を短絡するか
否かを検知し、その閉塞に列車が存在するか存在しない
かを判断する。

【００１７】図１では、４つの軌道回路を記載してある
が、軌道回路の数は、必要に応じて増減させる。１閉塞
は、最低１つの軌道回路から構成される。１閉塞が複数
の軌道回路からなっていても何ら問題はないが、本実施
例では、話を単純にするために、１閉塞は１軌道回路か
らなるとする。

【００１８】ＡＴＣ地上装置２０は、軌道回路により検
知した各閉塞の列車在線状態に基づき、各列車３０に対
する進入許容閉塞を判定する。ＡＴＣ地上装置２０は、
制御のための情報を記憶したデータベース２００を内蔵
している。

【００１９】信号送信機２２ａ〜２２ｄは、ＡＴＣ地上
装置２０で作成した制御電文すなわちその閉塞への進入
列車に対する進入許容閉塞を、レール２３経由で、列車
３０に送信する。信号送信機２２ａ〜２２ｂは、１つの
閉塞について１つずつ設置される。

【００２０】ネットワーク２５は、列車検知装置２１ａ
〜２１ｄからの列車検知情報をＡＴＣ地上装置２０に伝
達するとともに、ＡＴＣ地上装置２０からの制御電文を
信号送信機２２ａ〜２２ｄに伝達する。

【００２１】地点信号地上子２６は、列車３０がその上
を通過した際に、列車３０に対して現在位置に関する情
報を送信する。

【００２２】図２は、本発明による列車保安システムの
車上側の構成を示すブロック図である。信号受電器３１
は、レール２３に流れる信号電流をピックアップする。
信号受信部３２は、信号受電器３１がピックアップした
信号電流を復調処理し、ＡＴＣ車上装置３３に伝送す
る。

【００２３】ＡＴＣ車上装置３３は、ＡＴＣ地上装置２
０から送信される制御電文に示された進入許容閉塞終端
までの距離を、内蔵されたデータベース３３０中の情報
を用いて算出する。ＡＴＣ車上装置３３は、速度発電機
３７から入力される現時点の列車速度から停止するまで
の距離を算出する。現時点での列車速度からの停止距離
が、進入許容閉塞終端までの距離を超えている場合に
は、ブレーキ装置３４に対してブレーキ指令を出力し、
列車３０が進入許容閉塞を越えて走行して先行列車３０
に衝突しないように制御する。

【００２４】地点信号車上子３５は、地点信号地上子２
６からの信号をピックアップする。地点信号受信器３６
は、受信した信号を復調処理し、受信した地点情報をＡ
ＴＣ車上装置３３に送信する。ＡＴＣ車上装置３３は、
路線上の任意の箇所に設置された地点信号地上子２６か
らの地点信号を地点信号受信器３６から取り込んで、列
車３０が路線上のどの地点に位置しているかを認識す
る。列車３０の初期位置が確定すれば、速度発電機３７
からの速度信号を積分して得られる走行距離を初期位置
に加算すると、列車３０は自らの位置を認識でき、進入
許容閉塞終端までの距離を求めることも可能となる。そ
のためには、ＡＴＣ車上装置３３の制御用データベース
３３０には、閉塞がどのような順序で並んでいるかを示
したデータを記憶しておく必要がある。

【００２５】さて、本システムにおいて、制御用として
保持する必要のあるデータベースは以下の通りとなる。
まずＡＴＣ地上装置においては、各閉塞がどのような順
番で並んでいるかを記述したデータベースが必要であ
る。この情報により、ＡＴＣ地上装置は、例えば閉塞Ａ
に列車が存在している場合、その後方の閉塞Ｂ，Ｃ，
Ｄ，…には、進入許可閉塞として閉塞Ｂを送信すべきで
あるとの判断が可能となる。 一方、ＡＴＣ車上装置に
おいては、地上装置の場合と同様、各閉塞がどのように
並んでいるかを記述したデータベースが必要となる。さ
らに、車上装置の場合は、各閉塞の長さを記述したデー
タベースも必要である。これらのデータにより、車上装
置は、自らの位置を認識できるとともに、地上装置によ
り指定された進入許容閉塞端までの距離を算出できる。

【００２６】次に、この列車保安システムにおいて使用
するデータベースを生成するシステムを考える。図３
は、本発明による列車保安システム用データベース作成
システムの一実施例の概要を示すブロック図である。デ
ータベース作成システム１は、マスターデータベース４
からデータを取り込んで、更新するデータを作成し、作
成したデータを地上装置用データベース２００および車
上装置用データベース３３０に出力する。

【００２７】図４は、列車保安システム用データベース
作成システムの入力ファイルの構成の一例を示す図であ
る。マスターデータベース４は、各閉塞の名称および始
端・終端キロ程が記載されたファイルである。なお、キ
ロ程とはある路線の始端からの距離のことである。これ
を閉塞ファイルと称する。この閉塞ファイルは、路線改
修があった場合、その都度更新する必要がある。

【００２８】図５は、列車保安システム用データベース
作成システムの出力ファイルである地上装置用データベ
ースのファイル構成の一例を示す図である。ＡＴＣ地上
装置用データベース２００には、図５に示すファイル形
式で、各閉塞名称とその前後に接続される閉塞の名称と
が記載されている。

【００２９】図６は、列車保安システム用データベース
作成システムの出力ファイルである車上装置用データベ
ースのファイル構成の一例を示す図である。ＡＴＣ車上
装置用データベース３３０は、図６に示すファイル形式
で、各閉塞名称とその前後に接続される閉塞の名称とに
加えて、各閉塞の長さが記載されている。

【００３０】図７は、列車保安システム用データベース
作成システムの動作を示すフローチャートである。ステ
ップ１０で、入力データである閉塞ファイルを読み込
む。ステップ１１では、起動カウンタを１だけインクリ
メントする。起動カウンタとは、データベース作成シス
テムが何回起動されたかを示すカウンタであり、システ
ムを稼働させていない状態や電源オフ状態でもその値は
保持されている。言い換えれば、起動カウンタの値はバ
ージョン番号そのものである。

【００３１】ステップ１２では、起動カウンタの値すな
わちバージョン番号に一意に対応する暗号化鍵および復
号化鍵を生成する。本実施例では、話を単純にするた
め、このバージョン番号そのものを暗号化，復号化鍵と
して用いることにする。詳細な暗号化／復号化の方法
は、後述する。

【００３２】ステップ１３では、閉塞ファイルの内容を
閉塞始端キロ程でソートし、実際の接続順に並べ替え
る。ステップ１４では、接続順にソートされたファイル
に対して、ヘッダ情報として暗号化鍵すなわちバージョ
ン番号を付加する。次に、ステップ１５で、ＡＴＣ地上
装置の計算機に合わせてフォーマット変換して、ＡＴＣ
地上装置用データベース２００を生成する。

【００３３】一方、ＡＴＣ車上装置用データベース３３
０の生成手順は以下の通りである。ステップ１６では、
ステップ１３で接続順にソートされたファイルについ
て、始端キロ程と終端キロ程の差から閉塞長を算出す
る。次にステップ１７で、ヘッダ情報として復号化鍵を
付加する。なお、付加する復号化鍵は、本実施例では、
起動カウンタの値であり、ステップ１４でＡＴＣ地上装
置用データベース２００に付加されたものと同一であ
る。ステップ１８で、ＡＴＣ車上装置の計算機に合わせ
てフォーマット変換して、ＡＴＣ車上装置用データベー
ス３３０を生成する。

【００３４】本発明では、バージョン番号の代わりに暗
号化の鍵を用いる。このため、地上用／車上用のそれぞ
れのデータベースのヘッダに記載されるバージョンは、
実際には、それぞれが暗号化／復号化のための鍵である
ことはこれまで述べた通りである。暗号化のアルゴリズ
ムには様々な種類があるが、暗号化の方法自体は何であ
ってもよい。

【００３５】ただし、ここで重要な点は、データベース
生成システム内で管理しているバージョン番号に対し
て、１対１に鍵が定まる必要があることである。本実施
例においては、話を単純にするため、バージョン番号そ
のもので暗号化する方法について述べるが、バージョン
番号と鍵を１対１に定めることさえできれば、よりセキ
ュリティの高い暗号化方法を用いてもよいことはいうま
でもない。

【００３６】図８は、ＡＴＣ地上装置２０の動作を示す
フローチャートである。本動作は、ある閉塞に対する送
信情報の決定を示したものであり、実際には、この処理
が閉塞の個数だけ繰り返されることになる。ステップ２
０１では、ネットワーク２５経由で取得した列車検知情
報をもとに、各閉塞の列車在線状況を判定し、その閉塞
の前方で列車在線となっている閉塞のうち直近のものを
探索する。そして、その１つ手前の閉塞が停止閉塞とし
て選択される。これらの処理過程で、データベース２０
０が用いられる。ステップ２０２では、ステップ２０１
で決定された停止閉塞やその閉塞自体の番号などの付加
的情報を追加することにより、送信情報を生成する。

【００３７】ステップ２０３では、ステップ２０２で生
成された送信情報に対して一定のルールでエラーチェッ
クコードを付与し、送信電文を生成する。エラーチェッ
クコードとしては、例えば、ＨＤＬＣ(High Level Data
Link Control)伝送で用いられるＣＲＣ(Cyclic Redund
ancy Check)コード等が考えられる。ＣＲＣは対象とな
るビット列を生成多項式で割った剰余であり、ＣＣＩＴ
Ｔ−１として定められているものは１６ビットの長さを
持つ。

【００３８】エラーチェックコードの付与は必須ではな
いが、伝送過程での誤り検出等のため、高信頼性が要求
される伝送では使用されることが多い。また、本実施例
では、後述の通り、バージョン不一致の検出を容易にす
る役割も果たしている。本実施例では、エラーチェック
コードとしてＣＲＣを用いて説明するが、その他のチェ
ックコードを用いても同様の結果が得られることはいう
までもない。

【００３９】ステップ２０４では、決定された送信電文
を暗号化する。暗号化鍵は、地上装置用データベース２
００のヘッダに記載されたものを用いる。本実施例で
は、バージョン番号は１バイトとし、送信電文をバイト
単位でバージョン番号との排他的論理和ＥＯＲを取るこ
とで暗号化する。このように暗号化した後、ステップ２
０５で、ネットワークに対して暗号化された電文を送信
する。

【００４０】なお、バージョン番号を１バイトとしたこ
とにより、本実施例では２５６種類の異なるバージョン
を区別できることになるが、例えばこれを２バイトとす
れば、６５５３６種類の異なるバージョンを区別でき
る。何種類のバージョンを区別するかは、システム運用
期間中に予想されるデータ更新の回数に応じて決定すれ
ばよく、システム上の制約を受けることはない。実際の
路線の工事等による閉塞データの更新は、年間で高々１
０数回である。また、計算機の性能に応じて、より高度
な暗号化手段を用いることも可能である。本発明の効果
は、暗号化のアルゴリズムには依存しない。

【００４１】次に、車上装置の動作について説明する。
信号受電器３１により検出された信号は信号受信器３２
により復調され、ＡＴＣ車上装置３３に送られる。図９
は、搭載データベースが１種類である場合のＡＴＣ車上
装置３３の動作を示すフローチャートである。ステップ
３３１で、受信した地上からの制御電文は、ステップ３
３２で復号化処理する。この時の復号化鍵は、車上装置
用データベース３３０のヘッダに記録されたものを使用
する。本実施例では、復号化鍵は、バージョン番号その
ものであり、受信電文に対して、バイト単位で復号化鍵
との排他的論理和ＥＯＲを取ると、暗号化前の電文を復
号化できる。

【００４２】復号化された電文は、ステップ３３４でエ
ラーをチェックする。地上から車上へのデータ電送にお
いてエラーが発生した場合、このエラーチェックにより
誤りが検出されるが、本実施例では、地上と車上の間で
バージョンの不一致があった場合にも、誤りが検出され
る。地上・車上間でバージョンの不一致がある場合、車
上装置は、鍵が異なるために、受信した電文を正しく復
号できず、あたかも伝送エラーが生じたのと同様な状態
になるからである。なお、復号化された電文の合理性チ
ェックなどにより、電文が正しく復号されていないこと
を検出してもよい。

【００４３】さて、ステップ３３４のエラーチェックで
誤りが検出されなければ、受信電文には伝送誤りがな
く、しかも、地上・車上のバージョンは一致していると
いえるので、その受信電文は制御に使用してよい。一
方、誤りが検出されれば、受信電文に伝送誤りが発生し
たか、または、地上・車上間でバージョンの不一致が発
生しているといえるので、その電文は制御に使用せず、
破棄しなければならない。

【００４４】ステップ３３４のエラーチェックで電文に
誤りが検出された場合は、ステップ３３８で、誤りカウ
ンタの値を１だけインクリメントする。誤りカウンタと
は、電文受信時のＣＲＣエラーの連続回数をカウントす
るためのものである。このときは、ＡＴＣとしての通常
制御は実行しない。

【００４５】ステップ３３４のエラーチェックで電文に
誤りが検出されなかった場合は、ステップ３３６で、Ａ
ＴＣ装置としての通常の制御をしたのち、ステップ３３
７で、誤りカウンタの値を０にリセットする。

【００４６】ステップ３３９では、誤りカウンタの値を
判定し、その値が３以上であれば、すなわち、３回連続
して誤りが検出された場合、地上・車上間バージョン不
一致であると判定し、システムを強制停止させる。本実
施例では、連続する誤りの回数の許容値を２回としてい
るが、この値は任意である。

【００４７】先にも述べた通り、エラーチェックで誤り
が検出されるのは、バージョン不一致の場合と伝送エラ
ー発生時である。誤り検出１回では、バージョン不一致
なのか単なる伝送エラーなのかは判定できない。しか
し、通常の伝送品質を仮定すれば、３回連続エラーの可
能性は低く、この場合バージョン不一致により誤り検出
が連続したものと推定できる。したがって、伝送品質が
良好で、伝送誤りを考慮しなくてもよい状況では、１回
の誤り検出でバージョン不一致と判定しても支障はな
い。

【００４８】以上の実施例では、車上装置に搭載された
データベースは１種類であったが、異なるバージョンの
データベースを複数搭載してもよい。図１０は、搭載デ
ータベースが２種類である場合のＡＴＣ車上装置３３の
動作を示すフローチャートである。ここでは、話を単純
にするため、車上に搭載されるデータベースは２種類で
あるとするが、これは３種類以上であってもよい。また
車上に搭載されるデータベースの数によらず、地上装置
の処理は不変である。

【００４９】ステップ３３１で、受信された地上からの
制御電文は、ステップ３３２ａで、復号化処理される。
この時の復号化鍵は、図示しない第１の車上装置用デー
タベースのヘッダに記録されたものを使用する。ステッ
プ３３３ａで、第１のデータベースに記載された鍵によ
り復号化された電文のエラーをチェックする。ステップ
３３４ａでは、ステップ３３３ａでのエラーチェック結
果が判定される。エラーが検出されなければ、地上装置
が使用しているデータベースのバージョンは、車上に搭
載された第１のデータベースのバージョンと一致してい
ることになる。したがって、この時は、ステップ３３５
ａで、第１のデータベースが制御用として選択されるこ
とになる。

【００５０】一方、ステップ３３４ａで誤り検出と判定
された場合は、引き続き、ステップ３３２ｂで、復号化
処理を実行する。この時の復号化鍵は、図示しない第２
の車上装置用データベースのヘッダに記録されたものを
使用する。ステップ３３３ｂで、第２のデータベースに
記載された鍵により復号化された電文のエラーをチェッ
クする。ここでエラーが検出されなければ、地上装置が
使用しているデータベースのバージョンは、車上に搭載
された第２のデータベースのバージョンと一致している
ことになる。したがって、この時は、ステップ３３５ｂ
により第２のデータベースが制御用として選択されるこ
とになる。

【００５１】ステップ３３４ａおよびステップ３３４ｂ
のいずれにおいてもエラーありと判定された場合、ステ
ップ３３８において、誤りカウンタの値が１だけインク
リメントされる。

【００５２】ステップ３３４ａまたは３３４ｂのいずれ
かにおいて、エラーなしと判定された場合には、ステッ
プ３３５ａまたは３３５ｂにより制御用のデータベース
が選択されており、この時はステップ３３６で、ＡＴＣ
として通常制御し、ステップ３３７において誤りカウン
タの値は０にリセットされる。ここでの誤りカウンタの
値は、地上装置が使用しているデータベースのバージョ
ンが、車上装置が使用している第１または第２のデータ
ベースのバージョンのいずれとも一致しない状態をカウ
ントしているといえる。

【００５３】続くステップ３３９では、誤りカウンタの
値を判定し、その値が３以上であれば、すなわち、３回
連続して誤りが検出された場合、地上・車上間バージョ
ン不一致であると判定し、システムを強制停止させる。
この時の判定基準についての考え方は、車上に搭載され
たデータベースが１つしかない場合と同様である。

【００５４】車上装置側に複数のデータベースを搭載す
ることは、システムのバージョン切換の効率向上につな
がる。車上装置に１つしかデータベースを搭載できない
場合は、地上側システムのデータベースのバージョンア
ップに合わせて、車上装置のデータベースも同時にバー
ジョンアップする必要があるが、対象車両が多数にわた
る場合、一斉に交換することは多大な労力を要する。

【００５５】車上側に変更前，変更後の２つのデータベ
ースを搭載し、地上からの制御信号に応じてこれらを選
択的に使用できれば、車上装置側のバージョンアップの
手間を大幅に簡略化できる。

【００５６】また、複数の路線を走行する列車について
考えると、データベースを１種類しか搭載できない場合
には、全ての路線のデータを一元的に管理する必要があ
る。例えば、路線Ａ，路線Ｂの２路線を走行する車両が
ある場合、路線Ａ，路線Ｂのデータを１つのデータベー
スとしなければならない。このような系統構成では、路
線Ａのみに改修があった場合であっても、路線Ａ，路線
Ｂをひとまとめとしてバージョンアップしなければなら
ず、関係のない路線Ｂに対して影響が及ぶという点で、
煩雑である。

【００５７】これに対して、車上に複数のデータベース
を持つ場合、路線毎のデータベースを持ち、それぞれ独
立にバージョンを管理することが可能となる。すなわ
ち、路線Ａのみに改修があった場合、車上装置用データ
ベースも、路線Ａに対応するものだけを交換すればよ
い。

【００５８】本発明では、対象となる線区が増えても、
制御電文には影響がないという利点がある。ただし、そ
のためには、異なる線区で、同一のバージョン番号すな
わち暗号化鍵を使用しないように、データベース生成シ
ステム側で管理しなければならない。既に述べたよう
に、バージョン番号は、必要に応じ十分な余裕をもって
大きく取れるので、異なる線区で同一バージョンとなら
ないように管理することは、容易である。

【００５９】

【発明の効果】本発明によれば、マスターデータベース
４から各サブシステムに分散配置するデータベースを生
成する際、マスターデータベースのバージョンに１対１
に対応する鍵を生成し、各データベースに付加する。各
サブシステムは、制御電文を送信する際、データベース
に記載された鍵で暗号化する。車上側システムは、受信
電文をデータベースに記載された鍵で復号化する。制御
側と車上側とでデータベースバージョンが一致しない場
合、車上側では受信電文を復号化できないから、バージ
ョンの不一致を確実に検出できる。制御電文にバージョ
ン番号を含める必要がないので、制御電文のビットを有
効活用できる。

【図面の簡単な説明】

【図１】本発明による列車保安システムの地上側の構成
を示すブロック図である。

【図２】本発明による列車保安システムの車上側の構成
を示すブロック図である。

【図３】本発明による列車保安システム用データベース
作成システムの一実施例の概要を示すブロック図であ
る。

【図４】列車保安システム用データベース作成システム
の入力ファイルの構成の一例を示す図である。

【図５】列車保安システム用データベース作成システム
の出力ファイルである地上装置用データベースのファイ
ル構成の一例を示す図である。

【図６】列車保安システム用データベース作成システム
の出力ファイルである車上装置用データベースのファイ
ル構成の一例を示す図である。

【図７】列車保安システム用データベース作成システム
の動作を示すフローチャートである。

【図８】ＡＴＣ地上装置の動作を示すフローチャートで
ある。

【図９】搭載データベースが１種類である場合のＡＴＣ
車上装置の動作を示すフローチャートである。

【図１０】搭載データベースが２種類である場合のＡＴ
Ｃ車上装置の動作を示すフローチャートである。

【符号の説明】

１ データベース作成システム ４ マスターデータベース ２０ ＡＴＣ地上装置 ２００ 地上装置用データベース ２１ａ〜２１ｄ 列車検知装置 ２２ａ〜２２ｄ 信号送信機 ２３ レール ２４ 絶縁材 ２５ ネットワーク ２６ 地点信号地上子 ３０ 列車 ３１ 信号受電器 ３２ 信号受信器 ３３ ＡＴＣ車上装置 ３３０ 車上装置用データベース ３４ ブレーキ装置 ３５ 地点信号車上子 ３６ 地点信号受信器 ３７ 速度発電機 ３８ 車輪および車軸

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5H161 AA01 BB03 BB04 BB06 CC13 CC20 DD02 EE01 5J104 AA01 AA16 EA04 NA02 NA27 PA00 PA14

Claims (5)

【特許請求の範囲】
1. 【請求項１】 マスターデータベースから生成される複
   数のデータベースがサブシステム間に分散配置されるデ
   ータベースシステムを有する列車保安システムにおい
   て、 サブシステム間の通信をマスターデータベースのバージ
   ョンと一意に対応する鍵により暗号化する暗号化手段
   と、被制御側サブシステムにおいて受信した電文を正常
   に復号化できた場合にのみサブシステム間に分散配置さ
   れたデータベースのバージョンが一致していると判定す
   る判定手段とを備えたことを特徴とする列車保安システ
   ム。
2. 【請求項２】 請求項１に記載の列車保安システムにお
   いて、 前記制御側サブシステムが、バージョンが異なる複数の
   データベースを搭載していることを特徴とする列車保安
   システム。
3. 【請求項３】 請求項１または２に記載の列車保安シス
   テムにおいて、 前記暗号化手段が、制御電文の送信側においてエラーチ
   ェックコードを付与した上で暗号化する手段であり、 前記被制御側サブシステムの判定手段が、復号化の後に
   エラーをチェックして誤りの有無により復号化の成功ま
   たは失敗を判定する手段であることを特徴とする列車保
   安システム。
4. 【請求項４】 請求項１ないし３のいずれか一項に記載
   の列車保安システムにおいて、 前記被制御側サブシステムの判定手段が、復号化の失敗
   が所定回数に達した時にデータベースのバージョンが一
   致していないと判定する判定手段であることを特徴とす
   る列車保安システム。
5. 【請求項５】 請求項１ないし４のいずれか一項に記載
   の列車保安システムにおいて、 前記被制御側システムにおいて受信した電文を正常に復
   号化できなかった場合に被制御側システムを強制的に停
   止させる手段を備えたことを特徴とする列車保安システ
   ム。