JP7092590B2

JP7092590B2 - 保安装置

Info

Publication number: JP7092590B2
Application number: JP2018137054A
Authority: JP
Inventors: 昌也森; 純佐藤
Original assignee: Nippon Signal Co Ltd
Current assignee: Nippon Signal Co Ltd
Priority date: 2018-07-20
Filing date: 2018-07-20
Publication date: 2022-06-28
Anticipated expiration: 2038-07-20
Also published as: JP2020013500A

Description

本発明は、鉄道信号保安装置など安全を担保するための保安装置に関する。

鉄道信号保安装置などの保安装置には高い安全性と信頼性とが求められるため、安全性および信頼線を向上させるための種々の仕組みが提案されている。例えば、特許文献１には、入出力ポートを指定するアドレスデコーダの故障を検出するための制御出力回路が開示されている。

特開２０１７－９１４５３号公報

特許文献１に記載の技術は、保安装置のハードウェアにおける偶発的故障等の検出に有効である。しかしながら、保安装置に搭載されるソフトウェアにおけるコーディングミスや設計不良等の系統的故障を検出するためには別途、対策が必要である。ソフトウェアについての系統的故障を検出する方法として、ソフトウェア・ダイバシティ（以下、ダイバシティ化）と呼ばれる方法がある。ソフトウェア・ダイバシティとは、同じ機能を別論理の複数プログラムで組み、各プログラムの処理結果を照合することでソフトウェアの系統的故障を検出する方法をいう。

ソフトウェア開発は、一般に上位のプログラム（以下、「アプリケーション」或いは「ＡＰ」と略記）と、ＡＰから呼び出される下位のプログラム（例えば、Ｉ／Ｏドライバ(以下、ＤＲ)など）とで、別々に行われる場合が多い。以下、上位側のプログラムを呼出元プログラム、下位側のプログラムを呼出先プログラム、と記す。ダイバシティ化を行う場合もＡＰとＤＲとで個々に実施されることになる。ダイバシティ化したアプリケーションをＡＰ１、ＡＰ２とし、ダイバシティ化したＩ／ＯドライバをＤＲ１、ＤＲ２とすると、アプリケーションの処理はＡＰ１→ＡＰ２→アプリケーション処理結果照合の流れとなり、Ｉ／Ｏドライバの処理はＤＲ１→ＤＲ２→ドライバ処理結果照合の流れになる。

上記仕組みにおいてアプリケーションの実行過程でＩ／Ｏドライバを呼び出すとすると、ＡＰ１からの呼び出しの際にＤＲ１→ＤＲ２→ドライバ処理結果照合が行われ、ＡＰ２からの呼び出しの際にもＤＲ１→ＤＲ２→ドライバ処理結果照合の処理が行われる。つまり、ＤＲ１→ＤＲ２→ドライバ処理結果照合が重複して２回実行されることになり、必要以上にＣＰＵ負荷が上昇するといった問題がある。

また、上記仕組みにおいてＩ／Ｏドライバが出力ドライバである場合、ドライバ処理結果照合によりＤＲ１の処理結果とＤＲ２の処理結果が一致した場合に出力を行うようにしても、出力が２回行われるといった不合理が発生する。

上記重複実行に起因する不具合を回避するために、ＡＰ１についてはＤＲ１を呼出し、ＡＰ２についてはＤＲ２の呼び出しとドライバ処理結果照合とを行うようにする方法が考えられる。しかしこの方法では、ＤＲ１とＤＲ２の動作タイミングが大きくずれる。ＤＲ１とＤＲ２の動作タイミングがずれると、Ｉ／Ｏドライバが入力ドライバである場合、ＤＲ１の実行の際に読み取った入力値とＤＲ２の実行の際に読み取った入力値とが一致しない可能性があり、ＡＰ１およびＡＰ２にコーディングミス等がないにも拘らず、ＡＰ１の処理結果とＡＰ２の処理結果とが不一致となって系統的故障が誤検出される可能性がある、という問題がある。

上記の事情に鑑み、本発明は、呼出先プログラムの重複実行を回避しつつ、呼出元および呼出先のプログラムをダイバシティ化して安全性を向上させることを可能にする手段を提供することを目的とする。

上述した課題を解決するために、本発明は、異なる論理で同じ処理の実行を指示する複数の呼出元プログラムのうちの一つの呼出元プログラム呼び出しに応じて、異なる論理で同じ処理の実行を指示する複数の呼出先プログラムの各々の処理結果を記憶し、前記複数の呼出元プログラムのうち前記一つの呼出元プログラム以外の呼出元プログラムの呼び出しに応じて、前記記憶した処理結果を返すコンピュータを備える保安装置を。第１の態様として提供する。

第１の態様の保安装置によれば、上記一つの呼出元プログラムからの呼び出しに応じて複数の呼出先プログラムの各々の処理結果が記憶され、上記複数の呼出元プログラムのうち上記一つの呼出元プログラム以外の呼出元プログラムからの呼び出しの際には、複数の呼出先プログラムの各々は実行されず、上記記憶された処理結果が呼出元プログラムへ返される。第１の態様の保安装置では、上記複数の呼出元プログラムのうち上記一つの呼出元プログラム以外の呼出元プログラムからの呼び出しの際には、複数の呼出先プログラムの各々が実行されることはないので、上記各課題を解決することができる。

上記第１の態様の保安装置において、前記複数の呼出元プログラムの処理結果を照合する、という構成が第２の態様として採用されてもよい。

第２の態様の保安装置によれば、上記複数の呼出元プログラムの処理結果の照合により、呼出元プログラム及び呼出先プログラムの少なくとも一方に含まれる系統的故障が検知される。

上記第１の態様の保安装置において、前記複数の呼出先プログラムの処理結果を照合する、という構成が第３の態様として採用されてもよい。

第３の態様の保安装置によれば、上記複数の呼出先プログラムの処理結果の照合により、呼出先プログラムに含まれる系統的故障が検知される。

上記第３の態様の保安装置において、前記複数の呼出先プログラムの処理結果が一致した場合に限り、一致した処理結果を有効にする、という構成が第４の態様として採用されてもよい。

上記第４の態様の保安装置によれば、複数の呼出先プログラムの処理結果が一致した場合に限り、有効とされた処理結果を用いた呼出元プログラムの処理が行われる。従って、一致しない呼出先プログラムの処理結果を用いて無駄な呼出元プログラムの処理が行われる不都合が回避される。

上記第１乃至第４のいずれか１の態様の保安装置において、前記一つの呼出元プログラムの呼び出しに応じて前記複数の呼出先プログラムの処理結果を返すインタフェースと、当該処理結果を記憶し、前記複数の呼出元プログラムのうち前記一つの呼出元プログラム以外の呼出元プログラムの呼び出しに応じて当該処理結果を返すインタフェースとを備える、という構成が第５の態様として採用されてもよい。

第５の態様の保安装置によれば、前記一つの呼出元プログラムに呼び出されるインタフェースと、前記複数の呼出元プログラムのうち前記一つの呼出元プログラム以外の呼出元プログラムに呼び出されるインタフェースの仕様を一致させることで、複数の呼出元プログラムの各々に含まれる呼出先プログラムを呼び出すためのコードを共通化できる。

第１実施形態にかかる保安装置の構成例を示す図。第１実施形態にかかる保安装置の演算部が実行する処理の流れを示すフローチャート。第１実施形態にかかる保安装置の演算部が実行する処理の流れを示すフローチャート。第１実施形態にかかる保安装置におけるソフトウェア・ダイバシティを説明するための図。従来のソフトウェア・ダイバシティにおける問題点を説明するための図。第１実施形態の効果を説明するための図。第２実施形態にかかる保安装置の演算部が実行する処理の流れを示すフローチャート。第２実施形態にかかる保安装置におけるソフトウェア・ダイバシティを説明するための図。変形例にかかる保安装置におけるソフトウェア・ダイバシティを説明するための図。変形例にかかる保安装置におけるソフトウェア・ダイバシティを説明するための図。変形例にかかる保安装置におけるソフトウェア・ダイバシティを説明するための図。変形例にかかる保安装置におけるソフトウェア・ダイバシティを説明するための図。変形例にかかる保安装置におけるソフトウェア・ダイバシティを説明するための図。

（第１実施形態）
本発明の第１実施形態について説明する。図１は、本発明の第１実施形態にかかる保安装置１０Ａの構成例を示す図である。保安装置１０Ａは鉄道信号保安装置であり、保安装置１０Ａと連携動作する他の保安装置とともに鉄道信号保安システムを構成する。図１には、保安装置１０Ａと連携する装置１０Ｂも図示されている。装置１０Ｂは鉄道信号保安装置であってもよいし、鉄道信号保安装置ではない装置であってもよい。図１に示すように、保安装置１０Ａと装置１０Ｂは、両装置間のデータの授受を仲介する信号線１２１を介して互いに接続されている。図１に示すように保安装置１０Ａは、演算部１１０、Ｉ／Ｏインタフェース１２０、記憶部１３０、およびこれら構成要素間のデータ授受を仲介するバス１４０を含んでいる。

演算部１１０は例えばシングルコアＣＰＵ（Central Processing Unit）などの演算回路である。演算部１１０は、記憶部１３０（より正確には、後述する不揮発性記憶部１３４）に記憶されているプログラムを実行し、保安装置１０Ａの制御中枢として機能する。Ｉ／Ｏインタフェース１２０は、各種外部機器との間でデータ授受を行う装置である。Ｉ／Ｏインタフェース１２０の具体例としては、ＮＩＣ（Network Interface Card）やシリアル通信回路、パラレル通信回路が挙げられる。Ｉ／Ｏインタフェース１２０には、信号線１２１を介して装置１０Ｂが接続される。

記憶部１３０は揮発性記憶部１３２と不揮発性記憶部１３４とを含む。揮発性記憶部１３２は例えばＲＡＭ（Random Access Memory）である。揮発性記憶部１３２は各種プログラムを実行する際のワークエリアとして演算部１１０によって利用される。不揮発性記憶部１３４は例えばハードディスクである。不揮発性記憶部１３４には、各種ソフトウェアが予め格納されている。不揮発性記憶部１３４に格納されているソフトウェアの具体例としては、ＯＳ（Operating System）を実現するためのカーネルソフトウェア、保安装置１０Ａに特有の機能を実現するためのアプリケーション、アプリケーションからの呼び出しに応じてＩ／Ｏインタフェース１２０を制御し装置１０Ｂに対してデータ出力を行うＩ／Ｏドライバが挙げられる。

本実施形態の保安装置１０Ａでは、アプリケーションとＩ／Ｏドライバの各々の系統的故障のリスクを軽減するために、アプリケーションとＩ／Ｏドライバの各々がダイバシティ化されている。すなわち、アプリケーションプロラムについては、保安装置１０Ａに特有の機能を実現するための処理について、異なる論理での実行を演算部１１０に指示するＡＰ１とＡＰ２とが不揮発性記憶部１３４に予め格納されている。また、Ｉ／Ｏドライバについては、装置１０Ｂへ出力するデータを呼出元のアプリケーションから与えられるデータに基づいて生成する処理について、異なる論理での実行を演算部１１０に指示するＤＲ１とＤＲ２とが不揮発性記憶部１３４に予め記憶されている。

また、本実施形態の保安装置１０Ａでは、アプリケーションとＩ／Ｏドライバの各々を個別にダイバシティ化することに起因する不具合の発生を回避するために、ＤＩＦ１およびＤＩＦ２の２種類のインタフェースプログラムが不揮発性記憶部１３４に予め記憶されている。さらに、本実施形態の保安装置１０Ａでは、ＡＰ１の処理結果とＡＰ２の処理結果を照合するためのプログラムであるＡＰ照合ＰＲと、ＤＲ１の処理結果とＤＲ２の処理結果を照合するためのプログラムであるＤＲ照合ＰＲが不揮発性記憶部１３４に予め記憶されている。以下、本実施形態の特徴を顕著に示すインタフェースプログラムであるＤＩＦ１およびＤＩＦ２を中心に説明する。

ＤＩＦ１およびＤＩＦ２は何れもアプリケーションから呼び出されるプログラムである。本実施形態では、ＡＰ１はＤＩＦ１を呼び出すように作成されており、ＡＰ２はＤＩＦ２を呼び出すように作成されている。図２はＤＩＦ１にしたがって演算部１１０が実行する処理の流れを示すフローチャートである。図２に示すにようにＤＩＦ１にしたがって作動している演算部１１０は、まず、ＡＰ１から与えられるデータを引数としてＤＲ１を呼出し（ステップＳＡ１００）、ＤＲ１による処理結果（呼出元プログラムから与えられるデータに基づいて生成した出力データ）を取得する。なお、ＤＲ１による処理結果のＤＩＦ１への返却は、関数戻り値による返却であってもよいし、予め定められた外部テーブルへの書き込みによる返却であってよい。

ステップＳＡ１００に後続するステップＳＡ１１０では、演算部１１０は、ステップＳＡ１００にてＤＲ１の呼び出しに用いたデータと同じデータを引数としてＤＲ２を呼び出し、ＤＲ２による処理結果を取得する。ＤＲ２による処理結果のＤＩＦ１への返却についても、関数戻り値による返却であってもよいし、予め定められた外部テーブルへの書き込みによる返却であってよい。なお、ステップＳＡ１００の処理とステップＳＡ１１０の処理をシーケンシャルに実行するのは、演算部１１０がシングルコアＣＰＵだからである。演算部１１０がマルチコアＣＰＵであれば、ステップＳＡ１００の処理とステップＳＡ１１０の処理を並列に実行してもよい。

ステップＳＡ１１０に後続するステップＳＡ１２０では、演算部１１０はＤＲ照合ＰＲに従い、ステップＳＡ１００にて取得した処理結果（すなわち、ＤＲ１による処理結果）と、ステップＳＡ１１０にて取得した処理結果（すなわち、ＤＲ２に処理結果）とを照合し、その照合結果を示すＤＲ照合結果コードと、ＤＲ１およびＤＲ２の各々による処理結果とを揮発性記憶部１３２内の所定のアドレスから始まる記憶領域（以下、ＤＲ処理結果テーブル）に書き込む。以降、ＤＩＦ１にしたがって作動している演算部１１０は、ＤＲ照合結果コードと上記各処理結果とを上記ＤＲ処理結果テーブルを用いて呼出元プログラムであるＡＰ１へ返却する。また、ＤＲ１による処理結果とＤＲ２に処理結果とが一致している場合には、演算部１１０は、何れか一方の処理結果をＩ／Ｏインタフェース１２０を介して装置１０Ｂへ出力する。

ＤＩＦ１の呼出元プログラム（すなわち、ＡＰ１）については、ＤＩＦ１から返却されたＤＲ照合結果コードを参照することで、ＤＲ１による処理結果とＤＲ２による処理結果の一致／不一致を把握し、後続の処理を切り替えるようにしてもよい。例えば、ＤＲ１による処理結果とＤＲ２による処理結果とが一致している場合には、ＤＩＦ１から返却された処理結果を有効とし、当該処理結果を用いて当該アプリケーションの演算を行う一方、不一致の場合にはＩ／Ｏドライバについての系統的故障が発生したと見做して、アプリケーション演算を停止することが考えられる。

図３はＤＩＦ２にしたがって演算部１１０が実行する処理の流れを示すフローチャートである。図３に示すにようにＤＩＦ２にしたがって作動している演算部１１０は、上記所定のアドレスから始まる記憶領域（ＤＲ処理結果テーブル）から格納内容（すなわち、ＤＲ１およびＤＲ２の各々の処理結果とＤＲ照合結果コード）を読み出し（ステップＳＢ１００）、読み出したデータを呼出元プログラム（すなわち、ＡＰ２）へ返却し（ステップＳＢ１１０）、ＤＩＦ２の処理を終了する。ＤＩＦ２の呼出元プログラムであるＡＰ２も、ＤＩＦ２から返却されたＤＲ照合結果コードを参照することで、ＤＲ１による処理結果とＤＲ２による処理結果の一致／不一致を把握し、後続の処理を切り替えることができる。

保安装置１０Ａの運用過程では、図４に示すように、ＡＰ１の実行、ＡＰ２の実行、といった順にダイバシティ化されたアプリケーションがシーケンシャルに実行され、さらにその後、ＡＰ照合ＰＲに従いＡＰ１の処理結果とＡＰ２の処理結果の照合が実行される。前述したようにＡＰ１、ＡＰ２およびＡＰ照合ＰＲを実行する演算部１１０はシングルコアＣＰＵだからである。図４におけるＡＰ照合ＰＲに従う照合の結果が不一致であれば、演算部１１０は、アプリケーションについての系統的故障が発生したと見做し、エラーメッセージ出力等の異常通知処理を行って動作を停止することが考えられる。

前述したように、ＡＰ１はＤＩＦ１を呼び出すように作成されており、ＡＰ２はＤＩＦ２を呼び出すように作成されている。このため、ＡＰ１の実行過程ではＤＩＦ１の呼び出しが行われ、ＤＲ１、ＤＲ２、ＤＲ照合ＰＲ（図２におけるステップＳＡ１２０の処理）がシーケンシャルに実行される。これに対して、ＡＰ２の実行過程ではＤＩＦ２の呼び出しが行われ、ＤＲ１、ＤＲ２及びＤＲ照合ＰＲが実行されることはない。従来のダイバシティ化であれば、図５Ａに示すように、ＡＰ２の実行の際にもＤＲ１、ＤＲ２及びＤＲ照合ＰＲが実行され、必要以上に演算部１１０の負荷（ＣＰＵ負荷）が上昇するといった問題があった。これに対して、本実施形態の保安装置１０Ａによれば、図５Ｂに示すように、ＤＲ１、ＤＲ２及びＤＲ照合ＰＲが重複して実行されることはなく、必要以上に演算部１１０の負荷が上昇することはない。また、本実施形態の保安装置１０Ａによれば、装置１０Ｂへの出力が重複して行われるといった不具合の発生も回避される。

（第２実施形態）
次いで本発明の第２実施形態について説明する。本発明の第２実施形態にかかる保安装置１０Ａの構成例は、図１に示した第１実施形態にかかる保安装置１０Ａの構成例と同じである。ただし、第２実施形態においては、ＤＲ１およびＤＲ２が、呼出元プログラムからの呼び出しに応じて、Ｉ／Ｏインタフェース１２０を介して外部の装置からデータを受け取り、受け取ったデータを用いた処理を行い、処理結果を呼出元プログラムに返却する入力ドライバである点が、第１実施形態と異なっている。そのため、第２実施形態においては、ＤＲ１およびＤＲ２の呼び出しに用いられるＤＩＦ１に従う演算部１１０の処理が、第１実施形態と異なっている。従って、以下に第２実施形態におけるＤＩＦ１に従った演算部１１０の処理を中心に説明する。

図６は、第２実施形態においてＤＩＦ１に従い演算部１１０が実行する処理の流れを示すフローチャートである。図６に示すように、ＤＩＦ１に従って作動している演算部１１０は、まず、呼出元プログラムであるＡＰ１に従いＤＲ１を呼び出す（ステップＳＣ１００）。続いて、演算部１１０は、呼び出したＤＲ１に従い、Ｉ／Ｏインタフェース１２０を介して装置１０Ｂから入力されたデータの値（入力値Ａ）を取得する（ステップＳＣ１１０）。演算部１１０は、ＤＩＦ１に従い、取得した入力値Ａを記憶する（ステップＳＣ１２０）。

続いて、演算部１１０は、ＤＲ１に従い、取得した入力値Ａを用いた処理を行い（ステップＳＣ１３０）、処理結果をＤＲ処理結果テーブルに書き込む（ステップＳＣ１４０）とともに、その処理結果を呼出元プログラム（すなわち、ＡＰ１）へ返却する。

続いて、演算部１１０は、ＤＩＦ１に従い、ＤＲ２を呼び出す（ステップＳＣ１５０）。また、演算部１１０は、ＤＩＦ１に従い、ステップＳＣ１２０において記憶しておいた入力値Ａを読み出す（ステップＳＣ１６０）。続いて、演算部１１０は、ＤＲ２に従い、入力値Ａを用いた処理を行い（ステップＳＣ１７０）、処理結果をＤＲ処理結果テーブルに書き込む（ステップＳＣ１８０）とともに、その処理結果を呼出元プログラム（すなわち、ＡＰ１）へ返却する。続いて、演算部１１０は、ＤＩＦ１に従い、ＤＲ処理結果テーブルに記憶されているＤＲ１の処理結果とＤＲ２の処理結果を照合する（ステップＳＣ１９０）。ＤＲ１の処理結果とＤＲ２の処理結果とが不一致の場合は、演算部１１０はＩ／Ｏドライバについての系統的故障が発生したと見做して、アプリケーション演算を停止することが考えられる。

図７は、第２実施形態にかかる保安装置１０Ａにおけるソフトウェア・ダイバシティを説明するための図である。第２実施形態においては、第１実施形態と同様に、ＡＰ１の実行、ＡＰ２の実行、ＡＰ照合ＰＲに従うＡＰ１の処理結果とＡＰ２の処理結果の照合、という手順でダイバシティ化されたアプリケーションが実行される。ＡＰ照合ＰＲに従う照合の結果が不一致であれば、演算部１１０は、アプリケーションについての系統的故障が発生したと見做し、エラーメッセージ出力等の異常通知処理を行って動作を停止することが考えられる。

また、第２実施形態においては、第１実施形態と異なり、ＤＲ１に従う演算部１１０は外部の装置から入力値Ａを取得する。演算部１１０は、取得した入力値ＡをＤＲ１に従う処理において用いるとともに、ＤＩＦ１に従い記憶する。その後、演算部１１０は、ＤＲ２に従う処理において、先に記憶しておいた入力値Ａを読み出して用いる。なお、演算部１１０が、ＤＲ照合ＰＲに従い、ＤＲ１の処理結果とＤＲ２の処理結果の照合を行い、その照合結果を示すＤＲ照合結果コードをＤＲ処理結果テーブルに書き込む点は第１実施形態と同様である。

従来のダイバシティ化であれば、ＤＲ１とＤＲ２の実行のタイミングがずれると、ＤＲ１の実行の際に取得した入力値とＤＲ２の実行の際に取得した入力値が一致せず、ＡＰ１およびＡＰ２にコーディングミス等がないにも拘らず、ＡＰ１の処理結果とＡＰ２の処理結果とが不一致となって系統的故障が誤検出される可能性があった。本実施形態では、図７に示すように、ＤＲ１の呼び出しの際に取得され、ＤＲ１の処理に用いられた入力値ＡがＤＲ２の処理に用いられるので、ＤＲ１とＤＲ２の実行のタイミングがずれても、上記のような誤検知が発生することはない。

このように本実施形態によっても、アプリケーションから呼び出される呼出先プログラムであるＩ／Ｏドライバの重複実行を回避しつつ、呼出元および呼出先のプログラムをダイバシティ化して安全性を向上させることが可能になる。

（変形例）
以上本発明の第１および第２実施形態について説明したが、これら実施形態には様々な変形が行われてよい。以下にそれらの変形の例を示す。なお、以下に示す変形例の２以上が適宜、組み合わされてもよい。

（１）上述した第１実施形態では、アプリケーションが呼出元プログラムであり、Ｉ／Ｏドライバが呼出先プログラムであった。しかし、図８に示すように、呼出元プログラムであるアプリケーション（図８におけるＡＰ１およびＡＰ２）から呼び出される呼出先プログラムは、ＯＳのサービスコール（図８におけるＳＣ１およびＳＣ２）であっても良い。なお、図８におけるＳＣＩＦ１は上記の第１実施形態におけるＤＩＦ１に対応するインタフェースプログラムであり、図８におけるＳＣＩＦ２は上記の第１実施形態におけるＤＩＦ２に対応するインタフェースプログラムである。第２実施形態についても同様であり、呼出先プログラムはサービスコールであってもよい。また、呼出元プログラムはアプリケーションには限定されず、Ｉ／Ｏドライバ或いはサービスコールであってもよい。例えば、呼出元プログラムがＩ／Ｏドライバである場合、当該Ｉ／Ｏドライバからインタフェースプログラムを介して呼び出される他のＩ／Ｏドライバまたはサービスコールが呼出先プログラムとなる。

（２）上述した第１実施形態および第２実施形態では、ダイバシティ化された呼出元プログラムの個数とダイバシティ化された呼出先プログラムの個数とが同じ（何れも２個）であったが、ダイバシティ化された呼出元プログラムの個数とダイバシティ化された呼出先プログラムの個数が同じである必要はない。また、上述した第１実施形態および第２実施形態では、呼出元プログラムが２つであったが３つ以上であってもよく、同様に、呼出先プログラムが３つ以上であってもよい。呼出先プログラムが３つ以上の場合、ダイバシティ化された呼出先プログラムの処理結果が一致しない場合であっても、所定数以上（例えば過半数）の処理結果が一致する場合には、当該一致する当該処理結果を用いて呼出元プログラムの処理を継続するようにしてもよい。同様に、呼出元プログラムが３つ以上の場合、ダイバシティ化された呼出先プログラムの処理結果が一致しない場合であっても、所定数以上（例えば過半数）の処理結果が一致する場合には、当該一致する処理結果を有効として呼出元プログラムの処理を継続してもよい。

（３）上述した第１実施形態および第２実施形態では、呼出先プログラムの処理結果の照合結果（ＤＲ照合結果コード）を呼出元プログラムへ返却したが、照合結果の返却は必須ではない。例えば、複数の呼出先プログラムの処理結果が全て一致している場合には、当該処理結果を示すデータを一つだけ呼出元プログラムへ返却する一方、不一致の場合には各呼出先プログラムの処理結果を全て呼出元プログラムへ返却する構成が採用されてもよい。もしくは、複数の呼出先プログラムの処理結果が全て一致している場合には、当該処理結果を示すデータを一つだけ呼出元プログラムへ返却する一方、不一致の場合には呼出先プログラムの処理結果を１つも呼出元プログラムへ返却しない構成が採用されてもよい。いずれの構成が採用されても、呼出元プログラム側では、ダイバシティ化された呼出先プログラムの処理結果の一致／不一致を返却される処理結果の個数に基づいて特定し、一致の場合に限り処理結果を有効とし、例えば処理結果を用いた処理を継続することができる。

（４）上述した第１実施形態および第２実施形態において演算部１１０が実行するものとしたＤＩＦ１およびＤＩＦ２は必須ではない。すなわち、ＡＰ１が図２に示す処理を演算部１１０に指示し、ＡＰ２が図３に示す処理を演算部１１０に指示する構成を採用し、ＤＩＦ１とＤＩＦ２を不要としてもよい。また、上述した第１実施形態および第２実施形態において演算部１１０が実行するものとしたＡＰ照合ＰＲおよびＤＲ照合ＰＲの少なくとも一方を、演算部１１０が実行しない構成が採用されてもよい。

図９は、演算部１１０がＤＩＦ１、ＤＩＦ２、ＡＰ照合ＰＲ、ＤＲ照合ＰＲのいずれも実行しない変形例にかかる保安装置１０Ａにおけるソフトウェア・ダイバシティを説明するための図である。この変形例において、保安装置１０Ａは保安システム２００の一部として構成される。保安システム２００は、保安装置１０Ａと、保安装置１０Ａから出力されるデータの照合を行う照合装置２０を備える。

演算部１１０はＡＰ１に従い、ＤＲ１とＤＲ２の呼び出しを行い、それらの処理結果をＤＲ処理結果テーブルに書き込む。また、演算部１１０はＡＰ２に従い、ＤＲ１とＤＲ２の呼出しに代えて、ＤＲ処理結果テーブルからＤＲ１の処理結果とＤＲ２の処理結果を読み出す。また、演算部１１０は、ＡＰ１に従いＤＲ１の処理結果を用いて行った処理の結果と、ＡＰ１に従いＤＲ２の処理結果を用いて行った処理の結果を照合装置２０に出力する。また、演算部１１０は、ＡＰ２に従いＤＲ１の処理結果を用いて行った処理の結果と、ＡＰ２に従いＤＲ２の処理結果を用いて行った処理の結果を照合装置２０に出力する。

照合装置２０は、保安装置１０Ａの演算部１１０から入力されたＡＰ１の処理結果とＡＰ２の処理結果の照合を行う。照合装置２０は、照合の結果が不一致であれば、保安装置１０Ａのアプリケーション又はＩ／Ｏドライバについての系統的故障が発生したと見做し、例えば、エラーメッセージ出力等の異常通知処理を行って保安装置１０Ａの動作を停止させる。

図１０は、演算部１１０がＤＩＦ１、ＤＩＦ２、ＤＲ照合ＰＲは実行しないが、ＡＰ照合ＰＲは実行する変形例にかかる保安装置１０Ａにおけるソフトウェア・ダイバシティを説明するための図である。図１０に示す変形例においては、演算部１１０がＡＰ照合ＰＲに従い、ＡＰ１の処理結果とＡＰ２の処理結果を照合する点が、図９に示した変形例と異なっている。この変形例においては、保安装置１０Ａにおいて、アプリケーションとＩ／Ｏドライバの少なくとも一方に含まれる系統的故障の検知が行われる。

図１１は、演算部１１０がＤＩＦ１、ＤＩＦ２、ＡＰ照合ＰＲは実行しないが、ＤＲ照合ＰＲは実行する変形例にかかる保安装置１０Ａにおけるソフトウェア・ダイバシティを説明するための図である。図１１に示す変形例においては、演算部１１０がＤＲ照合ＰＲに従い、ＤＲ１の処理結果とＤＲ２の処理結果を照合する点が、図９に示した変形例と異なっている。この変形例においては、保安装置１０ＡにおいてＩ／Ｏドライバに含まれる系統的故障の検知が行われ、照合装置２０において保安装置１０Ａのアプリケーションに含まれる系統的故障の検知が行われる。

図１２は、演算部１１０がＡＰ照合ＰＲ、ＤＲ照合ＰＲは実行しないが、ＤＩＦ１、ＤＩＦ２は実行する変形例にかかる保安装置１０Ａにおけるソフトウェア・ダイバシティを説明するための図である。図１２に示す変形例においては、演算部１１０がＡＰ１に従いＤＩＦ１を呼び出し、ＤＩＦ１に従いＤＲ１およびＤＲ２を呼び出す点と、演算部１１０がＡＰ２に従いＤＩＦ２を呼び出し、ＤＩＦ２に従いＤＲ処理結果テーブルからＤＲ１の処理結果とＤＲ２の処理結果を読み出す点が、図９に示した変形例と異なっている。

この変形例においては、ＡＰ１がＤＩＦ１を呼び出すことによりＤＲ１の処理結果とＤＲ２の処理結果を取得し、ＡＰ２がＤＩＦ２（ＤＩＦ１と仕様が共通）を呼び出すことによりＤＲ１の処理結果とＤＲ２の処理結果を取得するため、ＡＰ１とＡＰ２が呼出先プログラムを呼び出すためのコードに変更を加える必要がない。

なお、図１２の変形例においては、図９の変形例と同様に、照合装置２０において、保安装置１０ＡのアプリケーションとＩ／Ｏドライバの少なくとも一方に含まれる系統的故障の検知が行われる。

（５）上述した実施形態では、鉄道信号保安装置への本発明の適用例を説明したが、本発明の適用対象は鉄道信号保安装置に限定される訳ではなく、戸閉保安装置であってもよい。また、本発明の適用対象は鉄道用の保安装置には限定されず、エレベータ或いはエスカレータ用の保安装置であってもよい。要は、高い安全性と信頼性を要求される保安装置であって、安全性および信頼性の担保のために搭載ソフトウェアのダイバシティ化が行われる保安装置であれば、本発明を適用可能である。

１０Ａ・１０Ｂ…保安装置、１１０…演算部、１２０…Ｉ／Ｏインタフェース、１３０…記憶部、１３２…揮発性記憶部、１３４…不揮発性記憶部、１４０…バス、２０…照合装置、２００…保安システム。

Claims

異なる論理で同じ処理の実行を指示する複数の呼出元プログラムのうちの一つの呼出元プログラム呼び出しに応じて、異なる論理で同じ処理の実行を指示する複数の呼出先プログラムの各々の処理結果を記憶し、前記複数の呼出元プログラムのうち前記一つの呼出元プログラム以外の呼出元プログラムの呼び出しに応じて、前記記憶した処理結果を返すコンピュータを備える保安装置。
前記複数の呼出元プログラムの処理結果を照合する
請求項１に記載の保安装置。
前記複数の呼出先プログラムの処理結果を照合する
請求項１又は２に記載の保安装置。
前記複数の呼出先プログラムの処理結果が一致した場合に限り、一致した処理結果を有効にする請求項３に記載の保安装置。
前記一つの呼出元プログラムの呼び出しに応じて前記複数の呼出先プログラムの処理結果を返すインタフェースと、当該処理結果を記憶し、前記複数の呼出元プログラムのうち前記一つの呼出元プログラム以外の呼出元プログラムの呼び出しに応じて当該処理結果を返すインタフェースと
を備える請求項１乃至４のいずれか１項に記載の保安装置。