(57)【特許請求の範囲】
【請求項１】
複数の処理装置を備える端末装置であって、各処理装置が、
データベースと、
前記データベースに格納されているデータを管理する状態管理部と、
前記状態管理部における前記データの管理状態、他の処理装置の状態管理部におけるデータの管理状態、およびデータが必要となる規定されたイベントが発生した場合の前記イベントの種別に基づいて、外部システムに要求するデータ、および前記外部システムにデータを要求する順番を決定し、前記順番に基づいて前記外部システムにデータを要求することが可能なリクエスト管理部と、
前記外部システムからのデータの取得状態を管理する取得管理部と、
を備え、
前記リクエスト管理部は、前記状態管理部での前記データの管理状態、および前記イベントの種別に基づいて、前記外部システムに要求するデータ、およびデータを要求する順番を示す第１のリクエストキューを生成し、他の処理装置から、前記他の処理装置でのデータの管理状態、およびデータが必要となる規定されたイベントが発生した場合の前記イベントの種別に基づいて生成された第１のリクエストキューを取得し、生成した第１のリクエストキュー、および取得した第１のリクエストキューを併合して、前記端末装置として前記外部システムに要求するデータ、およびデータを要求する順番を示す第２のリクエストキューを生成し、
規定された処理装置のリクエスト管理部が、前記第２のリクエストキューを用いて前記外部システムにデータを要求することを特徴とする端末装置。
【請求項２】
前記状態管理部は、前記外部システムから取得した、前記データベースに格納されているデータの最新バージョンを示すデータバージョン情報と、前記データベースに格納されているデータのバージョンとに基づいて、バージョンが一致しているか否かをデータ単位で管理し、
前記リクエスト管理部は、前記状態管理部および前記他の処理装置の状態管理部で管理されているデータのうち、バージョンが不一致のデータを前記外部システムに要求するデータとする、
ことを特徴とする請求項１に記載の端末装置。
【請求項３】
前記リクエスト管理部は、データを要求する要求事由の優先度に基づいて前記外部システムにデータを要求する順番を決定し、要求する順番に各データの情報が記載されたレコードを並び替えて前記第１のリクエストキューを生成し、さらに、前記要求事由の優先度、および各処理装置の優先度に基づいて前記外部システムにデータを要求する順番を決定し、要求する順番に各データの情報が記載されたレコードを並び替えて前記第２のリクエストキューを生成する、
ことを特徴とする請求項１または２に記載の端末装置。
【請求項４】
前記端末装置において制御を行う処理装置が変更された場合、前記各処理装置の優先度は変更され、
前記リクエスト管理部は、前記各処理装置の優先度が変更された場合、前記要求事由の優先度、および変更後の各処理装置の優先度に基づいて前記外部システムにデータを要求する順番を決定し、要求する順番に各データの情報が記載されたレコードを並び替えて前記第２のリクエストキューを生成する、
ことを特徴とする請求項３に記載の端末装置。
【請求項５】
前記取得管理部は、前記第２のリクエストキューで示されるデータについて、前記外部システムへのデータの要求の有無、および前記外部システムからのデータの取得の有無を管理する、
ことを特徴とする請求項１から４のいずれか１つに記載の端末装置。
【請求項６】
複数の処理装置を備える端末装置におけるデータ管理方法であって、各処理装置において、
状態管理部が、データベースに格納されているデータを管理する第１のステップと、
リクエスト管理部が、前記状態管理部における前記データの管理状態、他の処理装置の状態管理部におけるデータの管理状態、およびデータが必要となる規定されたイベントが発生した場合の前記イベントの種別に基づいて、外部システムに要求するデータ、および前記外部システムにデータを要求する順番を決定する第２のステップと、
取得管理部が、前記外部システムからのデータの取得状態を管理する第３のステップと、
を含み、
前記第２のステップにおいて、前記リクエスト管理部は、前記状態管理部での前記データの管理状態、および前記イベントの種別に基づいて、前記外部システムに要求するデータ、およびデータを要求する順番を示す第１のリクエストキューを生成し、他の処理装置から、前記他の処理装置でのデータの管理状態、およびデータが必要となる規定されたイベントが発生した場合の前記イベントの種別に基づいて生成された第１のリクエストキューを取得し、生成した第１のリクエストキュー、および取得した第１のリクエストキューを併合して、前記端末装置として前記外部システムに要求するデータ、およびデータを要求する順番を示す第２のリクエストキューを生成し、
規定された処理装置のリクエスト管理部が、前記第２のリクエストキューを用いて前記外部システムにデータを要求することを特徴とするデータ管理方法。
【請求項７】
前記第１のステップにおいて、前記状態管理部は、前記外部システムから取得した、前記データベースに格納されているデータの最新バージョンを示すデータバージョン情報と、前記データベースに格納されているデータのバージョンとに基づいて、バージョンが一致しているか否かをデータ単位で管理し、
前記第２のステップにおいて、前記リクエスト管理部は、前記状態管理部および前記他の処理装置の状態管理部で管理されているデータのうち、バージョンが不一致のデータを前記外部システムに要求するデータとする、
ことを特徴とする請求項６に記載のデータ管理方法。
【請求項８】
前記第２のステップにおいて、前記リクエスト管理部は、データを要求する要求事由の優先度に基づいて前記外部システムにデータを要求する順番を決定し、要求する順番に各データの情報が記載されたレコードを並び替えて前記第１のリクエストキューを生成し、さらに、前記要求事由の優先度、および各処理装置の優先度に基づいて前記外部システムにデータを要求する順番を決定し、要求する順番に各データの情報が記載されたレコードを並び替えて前記第２のリクエストキューを生成する、
ことを特徴とする請求項６または７に記載のデータ管理方法。
【請求項９】
前記端末装置において制御を行う処理装置が変更された場合、前記各処理装置の優先度は変更され、
前記第２のステップにおいて、前記リクエスト管理部は、前記各処理装置の優先度が変更された場合、前記要求事由の優先度、および変更後の各処理装置の優先度に基づいて前記外部システムにデータを要求する順番を決定し、要求する順番に各データの情報が記載されたレコードを並び替えて前記第２のリクエストキューを生成する、
ことを特徴とする請求項８に記載のデータ管理方法。
【請求項１０】
前記第３のステップにおいて、前記取得管理部は、前記第２のリクエストキューで示されるデータについて、前記外部システムへのデータの要求の有無、および前記外部システムからのデータの取得の有無を管理する、
ことを特徴とする請求項６から９のいずれか１つに記載のデータ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の処理装置を備える端末装置およびデータ管理方法に関する。
【背景技術】
【０００２】
従来、鉄道システムでは、中央制御装置が、各列車の車上制御装置および地上制御装置にデータを送信し、データを共有して列車の運行を制御することが行われている。特許文献１には、列車の車上制御装置が電源オンされると起動報知信号を送信し、起動報知信号を受信した中央制御装置が、車上データベースに格納されるべき最新のデータを車上制御装置にダウンロードし、地上データベースに格納されるべき最新のデータを地上制御装置にダウンロードして、各装置間で最新のデータを共有する技術が開示されている。また、特許文献１に記載の車上制御装置は、信頼性向上のため、現用車上データベースおよび予備用車上データベースの２つの車上データベースを備えることも可能である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−３２１２６４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記従来の技術によれば、２つの車上データベースが同一のデータを格納することを前提としている。各車上データベースがデータを格納する際に一方の車上データベースでデータが受領できない事態が発生した場合、２つの車上データベース間でデータの内容が異なってしまう。このような状況で、現用車上データベースから予備用車上データベースに運用が切り替えられた場合、格納されているデータが一致しないことから事故を引き起こす原因になる可能性がある、という問題があった。【０００５】
本発明は、上記に鑑みてなされたものであって、複数の処理装置を備える場合に、各処理装置のデータベースに格納されるデータの差異を抑制可能な端末装置を得ることを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題を解決し、目的を達成するために、本発明は、複数の処理装置を備える端末装置である。各処理装置は、データベースと、データベースに格納されているデータを管理する状態管理部と、状態管理部におけるデータの管理状態、他の処理装置の状態管理部におけるデータの管理状態、およびデータが必要となる規定されたイベントが発生した場合のイベントの種別に基づいて、外部システムに要求するデータ、および外部システムにデータを要求する順番を決定し、順番に基づいて外部システムにデータを要求することが可能なリクエスト管理部と、外部システムからのデータの取得状態を管理する取得管理部と、を備える。リクエスト管理部は、状態管理部でのデータの管理状態、およびイベントの種別に基づいて、外部システムに要求するデータ、およびデータを要求する順番を示す第１のリクエストキューを生成し、他の処理装置から、他の処理装置でのデータの管理状態、およびデータが必要となる規定されたイベントが発生した場合のイベントの種別に基づいて生成された第１のリクエストキューを取得し、生成した第１のリクエストキュー、および取得した第１のリクエストキューを併合して、端末装置として外部システムに要求するデータ、およびデータを要求する順番を示す第２のリクエストキューを生成する。端末装置では、規定された処理装置のリクエスト管理部が、第２のリクエストキューを用いて外部システムにデータを要求することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、端末装置は、複数の処理装置を備える場合に、各処理装置のデータベースに格納されるデータの差異を抑制できる、という効果を奏する。
【図面の簡単な説明】
【０００８】
【図１】列車制御システムの構成例を示す図
【図２】列車が備える保安装置の構成例を示す図
【図３】保安装置において処理装置が運行管理システムからデータを受領するタイミングの例を示す図
【図４】保安装置が備える処理装置の構成例を示すブロック図
【図５】処理装置の状態管理部が保持するバージョン管理情報の例を示す図
【図６】処理装置のリクエスト管理部で生成される第２のリクエストキューの例を示す図
【図７】処理装置の取得管理部が保持するデータ取得管理情報の例を示す図
【図８】保安装置において処理装置が運行管理システムにデータを要求する処理を示す第１のフローチャート
【図９】保安装置において処理装置が運行管理システムにデータを要求する処理を示す第２のフローチャート
【図１０】保安装置において処理装置が運行管理システムにデータを要求する処理を示す第３のフローチャート
【図１１】保安装置が備える処理回路をプロセッサおよびメモリで構成する場合の例を示す図
【図１２】保安装置が備える処理回路を専用のハードウェアで構成する場合の例を示す図
【発明を実施するための形態】
【０００９】
以下に、本発明の実施の形態に係る端末装置およびデータ管理方法を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【００１０】
実施の形態．
図１は、本発明の実施の形態に係る列車制御システム６０の構成例を示す図である。列車制御システム６０は、運行管理システム５０と、列車１１，１２，１３，２１，３１，３２と、を備える。列車制御システム６０は、運行管理システム５０が、通信ネットワーク４０を介して、列車１１，１２，１３，２１，３１，３２の運行を制御するシステムである。
【００１１】
通信ネットワーク４０は、運行管理システム５０と列車１１，１２，１３，２１，３１，３２とを接続するネットワークである。通信ネットワーク４０は、専用のネットワークでもよいし、インターネットなど汎用のネットワークであってもよい。
【００１２】
運行管理システム５０は、データベース５１を備える。データベース５１には、列車１１，１２，１３，２１，３１，３２の運行を制御するために必要なデータであって、最新のデータが格納されている。運行管理システム５０は、データベース５１に格納されているデータを各列車に送信し、運行管理システム５０と各列車との間でデータを共有して、各列車の運行を制御する外部システムである。また、運行管理システム５０は、列車１１，１２，１３，２１，３１，３２に対して、各列車のデータベースに格納されているデータの最新バージョンを示すデータバージョン情報を送信する。
【００１３】
列車制御システム６０では、異なる種類の列車が運行されることがある。図１では、一例として、列車１１，１２，１３がＡ社製の列車、列車２１がＢ社製の列車、列車３１，３２がＣ社製の列車とする。列車の種類が異なると、各列車で運行に必要なデータが異なることがある。すなわち、Ａ社製グループ１０の列車１１，１２，１３と、Ｂ社製グループ２０の列車２１と、Ｃ社製グループ３０の列車３１，３２とでは、運行に必要なデータが異なる場合がある。このような場合、列車制御システム６０では、運行管理システム５０が、各列車からデータの要求があった場合に、各列車に対して要求されたデータを送信する。これにより、各列車は運行に必要なデータを取得することができ、運行管理システム５０と各列車との間でデータを共有することができる。
【００１４】
一例として、列車１１が運行に必要なデータを運行管理システム５０から取得する動作について説明する。図２は、本実施の形態に係る列車１１が備える保安装置１００の構成例を示す図である。列車１１は、保安装置１００と、外部インタフェース（以下、Ｉ／Ｆ（InterFace）とする。）装置７１，７２と、を備える。なお、図２では、列車１１が運行管理システム５０からデータを取得するために必要な構成のみを示し、一般的な構成については記載を省略している。
【００１５】
保安装置１００は、主系処理装置２００と、従系処理装置３００と、を備える端末装置である。主系処理装置２００は、正常動作時に列車１１の運行を制御する。主系処理装置２００は、処理装置２０１，２０２を備える。主系処理装置２００は、処理装置２０１，２０２で同じ演算処理を行い、演算結果が一致した場合、演算結果に基づいて列車１１の運行を制御する。従系処理装置３００は、主系処理装置２００が故障などで正常に動作していない場合、主系処理装置２００に代わって、列車１１の運行を制御する。従系処理装置３００は、処理装置３０１，３０２を備える。従系処理装置３００は、処理装置３０１，３０２で同じ演算処理を行い、演算結果が一致した場合、演算結果に基づいて列車１１の運行を制御する。
【００１６】
このように、保安装置１００は、複数の処理装置２０１，２０２，３０１，３０２を備える。処理装置２０１，２０２，３０１，３０２の構成は同様の構成とする。処理装置２０１，２０２，３０１，３０２は、例えば、ＣＰＵ（Central  Processing  Unit）である。処理装置２０１，２０２，３０１，３０２は、同一の演算処理を行うために必要なデータを格納するデータベース１を備える。
【００１７】
保安装置１００では、処理装置２０１，２０２，３０１，３０２が、非同期で独立して演算処理を行う。図２に示すように、処理装置２０１，２０２は、通信ネットワーク４０および外部Ｉ／Ｆ装置７１を介して、運行管理システム５０から列車１１の運行に必要なデータを取得する。同様に、処理装置３０１，３０２は、通信ネットワーク４０および外部Ｉ／Ｆ装置７２を介して、運行管理システム５０から列車１１の運行に必要なデータを取得する。保安装置１００では、処理装置２０１，２０２，３０１，３０２が独立して演算処理を行うこと、また、外部Ｉ／Ｆ装置７１，７２の通信状態の違いなどを理由として、処理装置２０１，２０２，３０１，３０２が運行管理システム５０からデータを受領するタイミングが異なることがある。
【００１８】
図３は、本実施の形態に係る保安装置１００において処理装置２０１，２０２，３０１，３０２が運行管理システム５０からデータを受領するタイミングの例を示す図である。図３において、縦長の四角はデータを示す。図３に示すように、処理装置２０１，２０２，３０１，３０２でデータを受領するタイミングが異なると、ある処理装置ではデータを受領できたが、別の処理装置ではデータを受領できなかったというケースが起こりうる。すなわち、同じ演算処理を行う処理装置２０１，２０２，３０１，３０２において、保持するデータに差異が発生する可能性がある。
【００１９】
例えば、処理装置２０１と処理装置２０２との間で保持するデータが異なると、主系処理装置２００は、処理装置２０１，２０２の演算結果が一致せず、列車１１の運行を制御できない可能性がある。また、処理装置３０１と処理装置３０２との間で保持するデータが異なると、主系処理装置２００が故障した場合、従系処理装置３００は、処理装置３０１，３０２の演算結果が一致せず、列車１１の運行を制御できない可能性がある。また、処理装置２０１，２０２と処理装置３０１，３０２との間で保持するデータが異なると、列車１１を制御する処理装置が主系処理装置２００から従系処理装置３００に切り替わった場合、従系処理装置３００は、主系処理装置２００と保持するデータが異なることから主系処理装置２００と演算結果が異なり、事故を引き起こす原因になる可能性がある。
【００２０】
そのため、本実施の形態では、保安装置１００において、各処理装置が、処理装置２０１，２０２，３０１，３０２が保持するデータの状態を管理し、規定された処理装置が、運行管理システム５０にデータを要求する。これにより、保安装置１００は、処理装置２０１，２０２，３０１，３０２が保持するデータで差異が発生する事態を抑制することができる。
【００２１】
前述のように、処理装置２０１，２０２，３０１，３０２は同様の構成のため、処理装置２０１を例にして構成および動作について説明する。図４は、本実施の形態に係る保安装置１００が備える処理装置２０１の構成例を示すブロック図である。図４では、処理装置２０２，３０１，３０２の記載を簡潔にしている。処理装置２０１は、データベース１と、通信部２と、状態管理部３と、リクエスト管理部４と、取得管理部７と、演算部８と、を備える。リクエスト管理部４は、プライオリティ計算部５と、リクエストソート部６と、を備える。
【００２２】
データベース１は、演算部８の演算処理に必要なデータが格納された記憶部である。データベース１には、運行管理システム５０から取得されたデータが追加される。また、データベース１に格納されているデータは、運行管理システム５０から取得されたデータによって更新される。
【００２３】
通信部２は、通信ネットワーク４０および外部Ｉ／Ｆ装置７１を介して、運行管理システム５０からデータを取得する。通信部２は、取得したデータを取得管理部７に出力する。通信部２は、通信ネットワーク４０および外部Ｉ／Ｆ装置７１を介して、運行管理システム５０から、データベース１に格納されているデータの最新バージョンを示すデータバージョン情報を取得する。通信部２は、取得したデータバージョン情報を状態管理部３に出力する。通信部２は、外部Ｉ／Ｆ装置７１および通信ネットワーク４０を介して、リクエスト管理部４の制御によって運行管理システム５０にデータを要求する。
【００２４】
また、通信部２は、リクエスト管理部４から、リクエスト管理部４で生成された第１のリクエストキューを取得し、他の処理装置に第１のリクエストキューを送信する。リクエスト管理部４で生成される第１のリクエストキューについては後述する。通信部２は、他の処理装置から、他の処理装置で生成された第１のリクエストキューを取得する。通信部２は、取得した第１のリクエストキューをリクエスト管理部４に出力する。なお、通信部２については、送信処理を行う送信部、および受信処理を行う受信部のように、機能を分けた構成にしてもよい。
【００２５】
状態管理部３は、データベース１に格納されているデータを管理する。具体的には、状態管理部３は、外部システムである運行管理システム５０から取得した、データベース１に格納されているデータの最新バージョンを示すデータバージョン情報と、データベース１に格納されているデータのバージョンとに基づいて、バージョンが一致しているか否かをデータ単位で管理する。図５は、本実施の形態に係る処理装置２０１の状態管理部３が保持するバージョン管理情報の例を示す図である。図５で示されるバージョン管理情報は、データベース１に格納されているデータのうち、データ単位１の名称で識別されるデータは最新のバージョンであり、データ単位２の名称で識別されるデータは最新のバージョンではなく、データ単位３の名称で識別されるデータは最新のバージョンであり、データ単位４の名称で識別されるデータは最新のバージョンか否か不明であることを示している。状態管理部３は、図５に示すバージョン管理情報をリクエスト管理部４に出力する。
【００２６】
リクエスト管理部４は、状態管理部３でのデータの管理状態、およびデータが必要となる規定されたイベントが発生した場合のイベントの種別に基づいて、運行管理システム５０に要求するデータ、およびデータを要求する順番を示す第１のリクエストキューを生成する。リクエスト管理部４は、状態管理部３で管理されているデータのうち、バージョンが不一致のデータを、運行管理システム５０に要求するデータとする。データが必要となる規定されたイベントが発生した場合とは、例えば、保安装置１００を搭載した列車１１がある走行区間を走行中に、次の走行区間に切り替わる地点よりも規定された距離だけ手前の地点に到達した場合である。規定されたイベントが発生した場合に必要となるデータとは、例えば、次の走行区間を走行するために必要な、次の走行区間内の各地点に設定されている制限速度などのデータである。リクエスト管理部４は、通信部２を介して、生成した第１のリクエストキューを他の処理装置に出力する。
【００２７】
また、リクエスト管理部４は、他の処理装置から、他の処理装置で生成された第１のリクエストキューを取得する。他の処理装置で生成された第１のリクエストキューは、他の処理装置の状態管理部３でのデータの管理状態、およびデータが必要となる規定されたイベントが発生した場合のイベントの種別に基づいて、他の処理装置のリクエスト管理部４で生成された第１のリクエストキューである。リクエスト管理部４は、生成した第１のリクエストキュー、および取得した第１のリクエストキューを併合して、保安装置１００として運行管理システム５０に要求するデータ、およびデータを要求する順番を示す第２のリクエストキューを生成する。リクエスト管理部４は、第２のリクエストキューを用いて、通信部２、外部Ｉ／Ｆ装置７１、および通信ネットワーク４０を介して、運行管理システム５０にデータを要求することが可能である。
【００２８】
保安装置１００では、例えば、現在、列車１１の運行を制御している処理装置のうち、チャネル１用の処理装置のリクエスト管理部４が、第２のリクエストキューを用いて、通信部２、外部Ｉ／Ｆ装置、および通信ネットワーク４０を介して、運行管理システム５０にデータを要求する。具体的には、通常動作時は、主系処理装置２００のチャネル１用の処理装置２０１のリクエスト管理部４が、第２のリクエストキューを用いて、通信部２、外部Ｉ／Ｆ装置７１、および通信ネットワーク４０を介して、運行管理システム５０にデータを要求する。また、主系処理装置２００が故障などで正常に動作していない場合は、従系処理装置３００のチャネル１用の処理装置３０１のリクエスト管理部４が、第２のリクエストキューを用いて、通信部２、外部Ｉ／Ｆ装置７２、および通信ネットワーク４０を介して、運行管理システム５０にデータを要求する。
【００２９】
保安装置１００では、規定された処理装置のリクエスト管理部４が、第２のリクエストキューを用いて運行管理システム５０にデータを要求する。このように、保安装置１００は、１つの処理装置のみが運行管理システム５０にデータを要求する。これにより、保安装置１００は、複数の処理装置が運行管理システム５０にデータを要求する場合と比較して、保安装置１００と運行管理システム５０との間の通信トラヒックの増加を抑えることができる。
【００３０】
プライオリティ計算部５は、リクエスト管理部４において第１のリクエストキューを生成する際、運行管理システム５０にデータを要求することになった理由である要求事由に基づいて、運行管理システム５０に要求するデータの順番を決定する。プライオリティ計算部５は、例えば、各要求事由のプライオリティすなわち優先度が予め設定された要求事由プライオリティテーブルを保持する。プライオリティ計算部５は、要求事由プライオリティテーブルに基づいて、運行管理システム５０に要求するデータの順番を決定する。
【００３１】
また、プライオリティ計算部５は、リクエスト管理部４において第２のリクエストキューを生成する際、運行管理システム５０にデータを要求することになった理由である要求事由、および各処理装置の優先度に基づいて、運行管理システム５０に要求するデータの順番を決定する。なお、保安装置１００において列車１１の制御を行う処理装置が変更された場合、各処理装置の優先度は変更される。例えば、列車１１を制御する処理装置が、主系処理装置２００から従系処理装置３００に切り替わった場合である。この場合、プライオリティ計算部５は、リクエスト管理部４において第２のリクエストキューを生成する際、運行管理システム５０にデータを要求することになった理由である要求事由、および変更後の各処理装置の優先度に基づいて、運行管理システム５０に要求するデータの順番を決定する。各処理装置の優先度の変更については、リクエスト管理部４が行ってもよいし、実際に列車１１の運行を制御する演算部８が行ってもよい。
【００３２】
プライオリティ計算部５は、例えば、前述の要求事由プライオリティテーブル、および各処理装置のプライオリティすなわち優先度が予め設定された処理装置プライオリティテーブルを保持する。プライオリティ計算部５は、要求事由プライオリティテーブル、および処理装置プライオリティテーブルに基づいて、運行管理システム５０に要求するデータの順番を決定する。処理装置プライオリティテーブルは、例えば、主系処理装置２００が運行制御を行っている場合、主系処理装置２００のチャネル１用の処理装置２０１、主系処理装置２００のチャネル２用の処理装置２０２、従系処理装置３００のチャネル１用の処理装置３０１、従系処理装置３００のチャネル２用の処理装置３０２の順に優先度が高く設定されている。処理装置プライオリティテーブルは、保安装置１００の動作状態によって動的に変更されてもよい。処理装置プライオリティテーブルは、例えば、従系処理装置３００が運行制御を行っている場合、従系処理装置３００のチャネル１用の処理装置３０１、従系処理装置３００のチャネル２用の処理装置３０２、主系処理装置２００のチャネル１用の処理装置２０１、主系処理装置２００のチャネル２用の処理装置２０２の順に優先度が高く設定される。
【００３３】
リクエストソート部６は、プライオリティ計算部５で決定された、運行管理システム５０に要求するデータの順番に基づいて、リクエストキュー内で、要求する順番に各データの情報が記載されたレコードを並び替えて、前述の第１のリクエストキューを生成する。また、リクエストソート部６は、プライオリティ計算部５で決定された、運行管理システム５０に要求するデータの順番に基づいて、リクエストキュー内で、要求する順番に各データの情報が記載されたレコードを並び替えて、前述の第２のリクエストキューを生成する。なお、第１または第２が付かないリクエストキューは、レコードの並び替えが行われていない状態にあるものとする。
【００３４】
図６は、本実施の形態に係る処理装置２０１のリクエスト管理部４で生成される第２のリクエストキューの例を示す図である。図６で示される第２のリクエストキューは、リクエストソート部６がレコードの並び替えを行った後の状態を示している。図６で示される１つの行が、要求するデータの情報が記載されたレコードに相当する。図６において、要求ＩＤは、各データを識別する識別情報を示す。図６において、要求事由は、運行管理システム５０にデータを要求することになった理由を示す。図６において、要求元処理装置は、運行管理システム５０に対して要求ＩＤで識別されるデータを要求することを決定した処理装置を示す。図６では、主系処理装置２００をＳｙｓｔｅｍ−Ａ、従系処理装置３００をＳｙｓｔｅｍ−Ｂと記載している。図６において、状態は、運行管理システム５０に対してデータを要求しているのか否かを示す。なお、リクエスト管理部４で生成される第１のリクエストキューも、図６で示される第２のリクエストキューと同様の構成である。第１のリクエストキューでは、要求元処理装置の項目は、第１のリクエストキューを生成する処理装置が示されることになる。
【００３５】
取得管理部７は、通信ネットワーク４０、外部Ｉ／Ｆ装置７１、および通信部２を介して、運行管理システム５０からデータを取得する。取得管理部７は、取得したデータがデータベース１にない場合、取得したデータをデータベース１に格納する。取得管理部７は、取得したデータと同種であるが異なるバージョンのデータがデータベース１に格納されている場合、取得したデータでデータベース１に格納されているデータを更新する。また、取得管理部７は、運行管理システム５０からのデータの取得状態を管理する。具体的には、取得管理部７は、第２のリクエストキューで示されるデータについて、運行管理システム５０へのデータの要求の有無、および運行管理システム５０からのデータの取得の有無を管理する。
【００３６】
図７は、本実施の形態に係る処理装置２０１の取得管理部７が保持するデータ取得管理情報の例を示す図である。図７において、要求ＩＤは、運行管理システム５０に要求するデータを識別する識別情報を示す。なお、図７に示すように、データのサイズが大きい場合はデータを複数のデータに分割し、分割されたデータを運行管理システム５０に要求するデータの単位とし、データ単位毎に識別情報が付与されているものとする。図７において、Ｒｅｑｕｅｓｔは、運行管理システム５０にデータを要求したか否かを示す。図７において、Ｒｅｃｅｉｖｅは、運行管理システム５０からデータを取得したか否かを示す。
【００３７】
演算部８は、データベース１に格納されているデータを用いて演算処理を行い、演算結果を用いて列車１１の運行を制御する。
【００３８】
つづいて、保安装置１００において、処理装置２０１が運行管理システム５０にデータを要求する処理について説明する。図８は、本実施の形態に係る保安装置１００において処理装置２０１が運行管理システム５０にデータを要求する処理を示す第１のフローチャートである。図９は、本実施の形態に係る保安装置１００において処理装置２０１が運行管理システム５０にデータを要求する処理を示す第２のフローチャートである。図１０は、本実施の形態に係る保安装置１００において処理装置２０１が運行管理システム５０にデータを要求する処理を示す第３のフローチャートである。
【００３９】
処理装置２０１において、状態管理部３は、通信ネットワーク４０、外部Ｉ／Ｆ装置７１、および通信部２を介して、運行管理システム５０から、データベース１に格納されているデータの最新バージョンを示すデータバージョン情報を取得したか否かを確認する（ステップＳ１）。状態管理部３は、データバージョン情報を取得した場合（ステップＳ１：Ｙｅｓ）、データバージョン情報で示される各データのバージョンと、データベース１に格納されているデータのバージョンとを比較する。状態管理部３は、バージョンが一致しないデータ、すなわちバージョンが不一致のデータがある場合（ステップＳ２：Ｙｅｓ）、バージョンが不一致であったデータの識別情報、データ要求の要求事由であるバージョン不一致の情報、および処理装置２０１の識別情報をリクエスト管理部４に出力する。リクエスト管理部４は、要求ＩＤをバージョンが不一致であったデータの識別情報、要求事由をバージョン不一致、要求元処理装置を処理装置２０１の識別情報、および状態を要求待ちを示すＷａｉｔｉｎｇとするレコードを、リクエストキューに登録する（ステップＳ３）。処理装置２０１は、状態管理部３がデータバージョン情報を取得していない場合（ステップＳ１：Ｎｏ）、ステップＳ２およびステップＳ３の処理を省略し、状態管理部３においてバージョンが不一致のデータがない場合（ステップＳ２：Ｎｏ）、ステップＳ３の処理を省略する。
【００４０】
状態管理部３は、列車１１において規定されたイベントが発生したか否かを確認する（ステップＳ４）。状態管理部３は、規定されたイベントが発生した場合（ステップＳ４：Ｙｅｓ）、規定されたイベントが発生した場合に必要なデータの識別情報、データ要求の要求事由である発生したイベントすなわち規定されたイベントの識別情報、および処理装置２０１の識別情報をリクエスト管理部４に出力する。リクエスト管理部４は、要求ＩＤを規定されたイベントが発生した場合に必要なデータの識別情報、要求事由を規定されたイベントの識別情報、要求元処理装置を処理装置２０１の識別情報、および状態を要求待ちを示すＷａｉｔｉｎｇとするレコードを、リクエストキューに登録する（ステップＳ５）。処理装置２０１は、規定されたイベントが発生していない場合（ステップＳ４：Ｎｏ）、ステップＳ５の処理を省略する。
【００４１】
リクエスト管理部４は、要求するデータに重複があるか否か、すなわちリクエストキューにおいて要求ＩＤが重複するレコードがあるか否かを確認する（ステップＳ６）。リクエスト管理部４は、リクエストキューにおいて要求ＩＤが重複するレコードがある場合（ステップＳ６：Ｙｅｓ）、要求事由プライオリティテーブルに基づいて、要求ＩＤが重複しているレコードのうち、最上位のプライオリティのレコードのみを残し、最上位のプライオリティのレコード以外のレコードを削除する（ステップＳ７）。リクエスト管理部４は、リクエストキューにおいて要求ＩＤが重複するレコードがない場合（ステップＳ６：Ｎｏ）、ステップＳ７の処理を省略する。リクエスト管理部４は、要求事由プライオリティテーブルに基づいて、リクエストキューに登録されているレコードをプライオリティの降順に並び替える（ステップＳ８）。プライオリティの降順にレコードが並び替えられたリクエストキューが、前述の第１のリクエストキューとなる。リクエスト管理部４は、通信部２を介して、生成した第１のリクエストキューを他の処理装置に送信する（ステップＳ９）。
【００４２】
リクエスト管理部４は、通信部２を介して、他の処理装置から、他の処理装置で生成された第１のリクエストキューを取得したか否かを確認する（ステップＳ１０）。リクエスト管理部４は、他の処理装置から、他の処理装置で生成された第１のリクエストキューを取得した場合（ステップＳ１０：Ｙｅｓ）、他の処理装置から取得した第１のリクエストキューについて、生成した第１のリクエストキューにはないレコードがあるか否かを確認する（ステップＳ１１）。リクエスト管理部４は、他の処理装置から取得した第１のリクエストキューについて、生成した第１のリクエストキューにはないレコードがある場合（ステップＳ１１：Ｙｅｓ）、生成した第１のリクエストキューに、該当するレコードを追加する（ステップＳ１２）。すなわち、リクエスト管理部４は、生成した第１のリクエストキューと、他の処理装置から取得した第１のリクエストキューとを併合する。リクエスト管理部４は、他の処理装置から、他の処理装置で生成された第１のリクエストキューを取得していない場合（ステップＳ１０：Ｎｏ）、ステップＳ１１およびステップＳ１２の処理を省略し、他の処理装置から取得した第１のリクエストキューについて、生成した第１のリクエストキューにはないレコードがない場合（ステップＳ１１：Ｎｏ）、ステップＳ１２の処理を省略する。
【００４３】
リクエスト管理部４は、要求事由プライオリティテーブルおよび処理装置プライオリティテーブルに基づいて、ステップＳ１２の処理後のリクエストキューに登録されているレコードをプライオリティの降順に並び替える（ステップＳ１３）。プライオリティの降順にレコードが並び替えられたリクエストキューが、前述の第２のリクエストキューとなる。リクエスト管理部４は、生成した第２のリクエストキューを取得管理部７に出力する。取得管理部７は、第２のリクエストキューに基づいて、データ取得管理情報を生成する。なお、リクエスト管理部４は、第２のリクエストキューを生成する際、生成した第１のリクエストキューを使用するが、第２のリクエストキューを生成後も、生成した第１のリクエストキューについてはコピーなどをして保持しおくこととする。
【００４４】
取得管理部７は、通信ネットワーク４０、外部Ｉ／Ｆ装置７１、および通信部２を介して、運行管理システム５０からデータを取得したか否かを確認する（ステップＳ１４）。取得管理部７は、運行管理システム５０からデータを取得した場合（ステップＳ１４：Ｙｅｓ）、データ取得管理情報に該当するデータがある場合、該当するデータのＲｅｃｅｉｖｅの欄を済にする。また、取得管理部７は、取得したデータの識別情報をリクエスト管理部４に出力する。リクエスト管理部４は、取得管理部７から、取得したデータの識別情報を取得すると、第１のリクエストキューにおいて、取得したデータの識別情報に該当する要求ＩＤのデータのレコードがあるか否かを確認する（ステップＳ１５）。リクエスト管理部４は、第１のリクエストキューにおいて、取得したデータの識別情報に該当する要求ＩＤのデータのレコードがある場合（ステップＳ１５：Ｙｅｓ）、当該データの取得が完了した後、第１のリクエストキューおよび第２のリクエストキューで該当する要求ＩＤのデータのレコードのうち、要求元処理装置が自装置のレコードについて、状態をＣｏｍｐｌｅｔｅに変更する（ステップＳ１６）。処理装置２０１は、運行管理システム５０からデータを取得していない場合（ステップＳ１４：Ｎｏ）、ステップＳ１５およびステップＳ１６の処理を省略し、取得したデータの識別情報に該当する要求ＩＤのデータのレコードがない場合（ステップＳ１５：Ｎｏ）、ステップＳ１６の処理を省略する。
【００４５】
リクエスト管理部４は、通信部２を介して、他の処理装置から、他の処理装置で生成された第１のリクエストキューを取得し、取得した第１のリクエストキューにおいて状態がＣｏｍｐｌｅｔｅのレコードがあるか否かを確認する（ステップＳ１７）。リクエスト管理部４は、取得した第１のリクエストキューにおいて状態がＣｏｍｐｌｅｔｅのレコードがある場合（ステップＳ１７：Ｙｅｓ）、第２のリクエストキューで該当するレコードの状態をＣｏｍｐｌｅｔｅに更新する（ステップＳ１８）。リクエスト管理部４は、取得した第１のリクエストキューにおいて状態がＣｏｍｐｌｅｔｅのレコードがない場合（ステップＳ１７：Ｎｏ）、ステップＳ１８の処理を省略する。
【００４６】
リクエスト管理部４は、第２のリクエストキューにおいて、要求ＩＤが同一のレコードが複数あって状態がＲｅｑｕｅｓｔｉｎｇのものがあり、変化がないまま規定された時間が経過したか否かを確認する（ステップＳ１９）。リクエスト管理部４は、規定された時間が経過した場合（ステップＳ１９：Ｙｅｓ）、運行管理システム５０に対してデータを再要求する（ステップＳ２０）。なお、ステップＳ２０では、実際には規定された処理装置のリクエスト管理部４のみが、運行管理システム５０に対してデータを再要求する。他の処理装置のリクエスト管理部４は、運行管理システム５０に対してデータを再要求しない。
【００４７】
リクエスト管理部４は、規定された時間が経過していない場合（ステップＳ１９：Ｎｏ）、第２のリクエストキューにおいて、要求ＩＤが同一のレコードの全てで状態がＣｏｍｐｌｅｔｅのものがあれば該当するレコードを削除する（ステップＳ２１）。リクエスト管理部４は、第２のリクエストキューにおいて、状態がＲｅｑｕｅｓｔｉｎｇのレコードが無い、すなわち全てのレコードの状態がＷａｉｔｉｎｇの場合、第２のリクエストキューの最上位にあるレコードの要求ＩＤのデータを運行管理システム５０に要求し、該当するレコードの状態をＲｅｑｕｅｓｔｉｎｇに変更する（ステップＳ２２）。ステップＳ２０の場合と同様、ステップＳ２２では、実際には規定された処理装置のリクエスト管理部４のみが、運行管理システム５０に対してデータを要求する。他の処理装置のリクエスト管理部４は、運行管理システム５０に対してデータを要求しない。
【００４８】
保安装置１００では、各処理装置が、図８から図１０に示すフローチャートの処理を繰り返し実施する。これにより、各処理装置は、第２のリクエストキューを最新の状態に更新することができる。
【００４９】
なお、リクエスト管理部４は、自装置で第１のリクエストキューを生成し、他の処理装置から、他の処理装置で生成された第１のリクエストキューを取得し、生成した第１のリクエストキュー、および取得した第１のリクエストキューを併合して、第２のリクエストキューを生成しているが、第２のリクエストキューを生成する方法はこれに限定されない。各処理装置のリクエスト管理部４は、第１のリクエストキューを生成しても、第１のリクエストキューを用いて運行管理システム５０にデータを要求することはない。すなわち、第１のリクエストキューは、要求事由のプライオリティによって並び替えされていなくてもよい。
【００５０】
リクエスト管理部４は、自装置の状態管理部３におけるデータの管理状態、および自装置でデータが必要となる規定されたイベントが発生した場合のイベントの種別と、他の処理装置の状態管理部３におけるデータの管理状態、および他の処理装置でデータが必要となる規定されたイベントが発生した場合のイベントの種別とに基づいて、運行管理システム５０に要求するデータ、および運行管理システム５０にデータを要求する順番を決定することができる。リクエスト管理部４は、運行管理システム５０に要求するデータ、および運行管理システム５０にデータを要求する順番を決定することで、第２のリクエストキューを生成することができる。
【００５１】
すなわち、リクエスト管理部４は、状態管理部３におけるデータの管理状態、他の処理装置の状態管理部３におけるデータの管理状態、およびデータが必要となる規定されたイベントが発生した場合のイベントの種別に基づいて、運行管理システム５０に要求するデータ、および運行管理システム５０にデータを要求する順番を決定することができる。この場合、リクエスト管理部４は、自装置の状態管理部３および他の処理装置の状態管理部３で管理されているデータのうち、バージョンが不一致のデータを運行管理システム５０に要求するデータとする。このように、リクエスト管理部４は、第１のリクエストキューの状態ではなく、第１のリクエストキューを生成するために必要な情報があれば、第２のリクエストキューを生成することができる。この場合、保安装置１００は、各処理装置が第１のリクエストキューを生成する際にレコードを並び替える処理の負荷を低減することができる。実施の形態では、リクエスト管理部４は、生成した第１のリクエストキュー、および取得した第１のリクエストキューを併合して、第２のリクエストキューを生成しているが、扱っている情報を考えれば、状態管理部３におけるデータの管理状態、他の処理装置の状態管理部３におけるデータの管理状態、およびデータが必要となる規定されたイベントが発生した場合のイベントの種別に基づいて、運行管理システム５０に要求するデータ、および運行管理システム５０にデータを要求する順番を決定する場合と処理内容は同様である。
【００５２】
つづいて、保安装置１００のハードウェア構成について説明する。保安装置１００において、処理装置２０１，２０２，３０１，３０２は、前述のようにＣＰＵであるが、処理回路により実現されてもよい。処理回路は、メモリに格納されるプログラムを実行するプロセッサおよびメモリであってもよいし、専用のハードウェアであってもよい。
【００５３】
図１１は、本実施の形態に係る保安装置１００が備える処理回路をプロセッサおよびメモリで構成する場合の例を示す図である。処理回路がプロセッサ９１およびメモリ９２で構成される場合、保安装置１００の処理回路の各機能は、ソフトウェア、ファームウェア、またはソフトウェアとファームウェアとの組み合わせにより実現される。ソフトウェアまたはファームウェアはプログラムとして記述され、メモリ９２に格納される。処理回路では、メモリ９２に記憶されたプログラムをプロセッサ９１が読み出して実行することにより、各機能を実現する。すなわち、処理回路は、保安装置１００の処理が結果的に実行されることになるプログラムを格納するためのメモリ９２を備える。また、これらのプログラムは、保安装置１００の手順および方法をコンピュータに実行させるものであるともいえる。
【００５４】
ここで、プロセッサ９１は、ＣＰＵ、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、またはＤＳＰ（Digital  Signal  Processor）などであってもよい。また、メモリ９２には、例えば、ＲＡＭ（Random  Access  Memory）、ＲＯＭ（Read  Only  Memory）、フラッシュメモリ、ＥＰＲＯＭ（Erasable  Programmable  ＲＯＭ）、ＥＥＰＲＯＭ（登録商標）（Electrically  ＥＰＲＯＭ）などの、不揮発性または揮発性の半導体メモリ、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、またはＤＶＤ（Digital  Versatile  Disc）などが該当する。
【００５５】
図１２は、本実施の形態に係る保安装置１００が備える処理回路を専用のハードウェアで構成する場合の例を示す図である。処理回路が専用のハードウェアで構成される場合、図１２に示す処理回路９３は、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ＡＳＩＣ（Application  Specific  Integrated  Circuit）、ＦＰＧＡ（Field  Programmable  Gate  Array）、またはこれらを組み合わせたものが該当する。保安装置１００の各機能を機能別に処理回路９３で実現してもよいし、各機能をまとめて処理回路９３で実現してもよい。
【００５６】
なお、保安装置１００の各機能について、一部を専用のハードウェアで実現し、一部をソフトウェアまたはファームウェアで実現するようにしてもよい。このように、処理回路は、専用のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせによって、上述の各機能を実現することができる。
【００５７】
以上説明したように、本実施の形態によれば、列車制御システム６０において、保安装置１００は複数の処理装置を備え、各処理装置が、運行管理システム５０に要求するデータおよびデータを要求する順番を決定し、複数の処理装置のうち１つの処理装置が、運行管理システム５０に対してデータの要求を行うこととした。これにより、保安装置１００は、複数の処理装置を備える場合において、各処理装置のデータベースに格納されるデータの差異を抑制することができる。
【００５８】
また、保安装置１００は、優先度の高い順にデータを要求する。これにより、保安装置１００は、列車１１の運行制御への影響を抑制しつつ、必要なデータを更新し、および必要なデータを取得することができる。また、保安装置１００は、第２のリクエストキューを生成する処理を繰り返し実施する。これにより、保安装置１００は、第２のリクエストキューを最新の状態に更新することができる。
【００５９】
なお、本実施の形態では、列車制御システム６０において、複数の処理装置を備える保安装置１００が、運行管理システム５０にデータを要求して取得する場合について説明したが、一例であり、運行管理システム５０の代わりにデータ管理システムでもよい。また、他の用途においても適用可能である。例えば、自動運転を行う自動車である自動運転車と、自動運転車にデータを送信する制御装置とを備えるシステムにおいて、各自動運転車が、制御装置に対して必要なデータを要求して取得する場合にも適用可能である。この場合、各自動運転車においてデータを要求する装置が端末装置となり、制御装置が各自動運転車にデータを送信する外部システムとなる。
【００６０】
以上の実施の形態に示した構成は、本発明の内容の一例を示すものであり、別の公知の技術と組み合わせることも可能であるし、本発明の要旨を逸脱しない範囲で、構成の一部を省略、変更することも可能である。
【符号の説明】
【００６１】
１，５１  データベース、２  通信部、３  状態管理部、４  リクエスト管理部、５  プライオリティ計算部、６  リクエストソート部、７  取得管理部、８  演算部、１０  Ａ社製グループ、１１，１２，１３，２１，３１，３２  列車、２０  Ｂ社製グループ、３０  Ｃ社製グループ、４０  通信ネットワーク、５０  運行管理システム、６０  列車制御システム、７１，７２  外部Ｉ／Ｆ装置、１００  保安装置、２００  主系処理装置、２０１，２０２，３０１，３０２  処理装置、３００  従系処理装置。
【図１】
0006906716.tif 000002
【図２】
0006906716.tif 000003
【図３】
0006906716.tif 000004
【図４】
0006906716.tif 000005
【図５】
0006906716.tif 000006
【図６】
0006906716.tif 000007
【図７】
0006906716.tif 000008
【図８】
0006906716.tif 000009
【図９】
0006906716.tif 000010
【図１０】
0006906716.tif 000011
【図１１】
0006906716.tif 000012
【図１２】
0006906716.tif 000013