JP2014211784A - 多重化制御装置および多重化制御方法 - Google Patents

Abstract

【課題】信頼性の低下を抑制することが可能な多重化制御装置を提供する。【解決手段】多重化制御装置は、エラーのイベントをシステムログにログとして登録する。システムログから、所定の時間内に発生しているエラーの発生回数を把握し、エラーの回数が、所定の回数に達したとき、永久エラーが発生したと推定する。多重化制御装置は、推定した永久エラーの明示を行う。これにより、エラーに関する情報が不足している種々の部品を実装しても、永久エラーを推定することが可能となり、多重化制御装置の信頼性の低下を抑制することが可能となる。【選択図】図２

Description

本発明は、多重化制御装置および多重化制御方法に関し、特に故障の発生に応答して自動的に制御の切り替えが行われる多重化サーバに関する。

近年、監視制御システムなどの制御システムにおいては、そのシステムの信頼性を向上させるために、制御システムに含まれるところの制御装置を複数個設け、多重化した多重化制御装置が採用されることがある。例えば、電気、上下水、ガス等の生活インフラを制御する制御システムにおいては、制御システムは終日稼働されることが要求される。更に、生活に密着しているため、当該制御システムには高い信頼性が要求される。そのため、この様な制御システムにおいては、複数の制御装置を用いた多重化制御装置が、制御システムとして用いられる。

多重化制御装置の一例として、いわゆる二重化された制御装置がある。この場合、二重化された制御装置を構成する２個の制御装置のうちの、一方が運用系とされ、他方が待機系とされる。運用系の制御装置が、万が一故障および／あるいは通信不良に陥り、その制御装置が復旧不可能となった場合、待機系の制御装置が、運用系に自動的に切り替わる。これにより、重要な機能が停止せずに、継続してシステムの運用を行うことが可能となる。

一方、多重化制御装置においては、複数個の制御装置を設けることが要求されるため、コストアップに繋がる。コストアップを抑制するために、それぞれの制御装置に用いられる部品としては、種々のメーカから、種々の部品の調達が行われることがある。

特開２０１１―２４８６７８号公報

種々のメーカから、種々の部品を調達して、多重化制御装置を構成する場合、調達した部品に関して、それを販売するメーカから、その部品に対して十分な情報の公開がされていない場合も有りうる。例えば、調達した部品に関して、エラーを発生するときの使用状況等に関する情報が十分に公開されていないことが考えられる。この様な状況においても、多重化制御装置においては、運用系の制御装置に復旧不可能な故障が発生した場合には、自動的に待機系の制御装置へ切り替えが行われ、運用を継続することが要求される。

エラーに関する情報が不足していると、その部品を実装した場合に、運用において発生しているエラーを認識することが困難となることが考えられる。例えば、その部品で発生しているエラーが、復旧不可能なエラー（永久エラー）であるのか、期待エラーであるのかを認識することが困難となる。発生しているエラーが、永久エラーであれば、運用を継続することは困難となり、その部品を故障と判定して、運用系の制御装置における部品の交換あるいは点検が必要とされる。また、この場合には、待機系の制御装置を運用系に切り替えることも要求される。

一方、発生しているエラーが、期待エラーの場合には、予め想定しているエラーであり、制御装置のパフォーマンスは低下することが考えられるが、運用は可能である。ここで、期待エラーとは、制御装置が正常に動作している状態で、そのエラーが発生することが想定されており、且つ制御装置の設計の際にも、そのエラーの発生が織り込み済みのエラーを意味している。すなわち、期待エラーの発生そのものは、制御装置の異常には該当しない。例えば、一時的なイベントの多発が想定される制御装置において、イベントの入力待ちテーブルが一時的にＦＵＬＬとなることを想定して設計された制御装置においては、新たなイベントが、待ちテーブルへの登録に失敗することは、期待エラーに該当する。この場合、待ちテーブルへの登録に失敗したときは、一定時間経過した後で、再登録を行う様に、制御装置は設計される。すなわち、エラーが発生することは予め織り込み済みとされており、部品の交換等が要求される永久エラーには該当しない。しかしながら、この例の様に、時間的なパフォーマンスは低下する。

特許文献１には、データベースを更新した場合に、更新に係わるログを生成するログ生成部を有するデータベース二重化システムが開示されている。しかしながら、特許文献１には、情報開示が十分されていない部品を用いた場合に生じる課題は記載されていないし、その認識もされていない。

本発明の目的は、それを構成する部品として、種々の部品を用いても、その信頼性の低下を抑制することが可能な多重化制御装置を提供することにある。

本発明の前記ならびにそのほかの目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。

すなわち、多重化制御装置は、エラーのイベントをシステムのログに記録（登録）する。所定の時間内にログに登録されたエラーイベントは、エラーの発生回数として把握され、エラーの発生回数が、所定の回数に達したとき、永久エラーが発生したと推定される。多重化制御装置は、推定した永久エラーの明示を行う。これにより、例えばエラーに関する情報が不足している種々の部品を実装しても、永久エラーを推定することが可能となり、多重化制御装置の信頼性の低下を抑制することが可能となる。また、推定した永久エラーの明示に応じて、運用の切り替え要否の判断も可能となる。

本明細書に開示される一実施の形態においては、期待エラーと判定されるべき情報が、多重化制御装置に記憶（格納）される。この格納されている情報とログに記録されているエラーイベントとの比較が行われ、所定の時間内に、所定の回数の一致が判定されたとき、永久エラーと推定される。これにより、期待エラーに対する処理（例えば、運用の継続）と、永久エラーに対する処理（明示あるいは運用の切り替え）とを、自動的に行うことが可能となる。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば、以下のとおりである。

信頼性の低下を抑制することが可能な多重化制御装置を提供することができる。

本発明に係わる多重化制御装置を有するシステムの構成を示すブロック図である。 本発明に係わるイベントログを判定する処理を示すフローチャート図である。 本発明の係わる制御機能処理の一覧（リスト）を示す図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部分には原則として同一の符号を付し、その繰り返しの説明は省略する。

（実施の形態）
図１は、本発明の一実施の形態による多重化制御装置を具備したシステムのブロック図である。特に制限されないが、本実施の形態においては、多重化制御装置として、２個の制御装置を用いた二重化制御装置の例が示されている。以下、二重化制御装置を、多重化制御装置の例として説明する。図１において、２および３のそれぞれは、二重化制御装置を構成する制御装置である。同図において、１は、制御装置２および３により制御されるシステムであり、ネットワーク５、６によって、制御装置２および３に接続され、制御される。二重化制御装置を構成する制御装置２および３の間は、ネットワーク４によって接続されている。特に制限されないが、ネットワーク４は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等で構成され、システム１と制御装置２および３を結ぶネットワーク５、６とは異なり、ネットワーク５、６からは分離されている。

上記した制御装置２および３のそれぞれは、運用系と待機系の２種類の状態を有しており、それぞれは２種類の状態のいずれかで動作する。もちろん、一方が、運用系として動作する時は、他方は待機系として動作し、運用系の制御装置が、主導でシステム１の制御を行う。以下では、制御装置２が運用系の制御装置であり、制御装置３が待機系の制御装置である場合を例として説明する。運用系の制御装置２と待機系の制御装置３は、専用のネットワーク４を介して、互いの生存を監視している。制御装置２および３のそれぞれには、キーボードが設置されている様に図面においては示されているが、これにはもちろん限定されない。また、以下の説明では、制御装置２、３のそれぞれをサーバ装置として説明するが、ＬＡＮ等の通信機能を有するパーソナルコンピュータであってもよい。

図２は、本実施の形態に係わるイベントログを判定する処理のフローチャート図である。以下、図１および図２を用いて、イベントログの判定を実施する処理を説明する。以下の説明においては、制御装置２（図１）が運用系の制御装置として動作し、この制御装置２がプログラムを実行することにより、図２に示したフローチャートの処理が実行される場合を述べる。しかしながら、図１に示した制御装置が、プログラムを実行してもよい。また、図２において、フローチャートで示されている各処理は、ハードウェアにより実現してもよい。ハードウェアにより実現する場合、本明細書においては、処理をユニットと称する。

システムを起動すると、すなわち制御装置２、３を起動すると、ステップＳ１０１（起動）からの処理が開始される。一方、制御装置２および３のそれぞれは、それにエラーが発生する度に、システムのログに、ログデータとしてエラーのイベントＩＤを登録する。

制御装置２および／あるいは３は、ステップＳ１０２において、システムのログを開く（システムログオープン）。次に、ステップＳ１０３において、ログの内容が確認される（ログエラーチェック）。ログの内容がエラーの場合、次にログエラーチェック処理が開始される。ログエラーチェック処理は、同図において、右側に示されており、ステップＡ１からステップＡ２の間の工程を有している。このログエラーチェック処理は、ステップＡ１が入り口で、ステップＡ２が出口である。ステップＳ１０３において、ログの内容がエラーの場合、ログエラーチェック処理の入り口であるステップＡ１に処理が移り、ログエラーチェック処理が終了すると、出口であるステップＡ２から、上記したステップＳ１０３へ処理が移る。すなわち、ステップＳ１０３から、ログエラーチェック処理へは、記号Ａを通して、ステップＡ１へ移る。ログエラーチェック処理からステップＳ１０３へは、ステップＡ２から、記号Ａを通して、ステップＳ１０３へ移る。

ログエラーチェック処理においては、先ず、ステップＳ１１６において、エラー状態のイニシャルが行われる。次に、ステップＳ１１７において、システムのログを読み込み、システムのログに登録されているところのログデータからイベントＩＤを確認する（ステップＳ１１８）。ログデータに含まれるイベントＩＤについては、後で図３を用いて説明するが、発生するエラーの種類に対応した例えば番号である。図２に示している一連の処理を実行するところ制御装置（本実施の形態においては、制御装置２）には、予め、把握した複数種類のエラーのそれぞれに対して、対応するイベントＩＤが付与され、イベントＩＤのチェックリストが作成され、格納されている。説明を容易にするために、システムのログに登録されるログデータに含まれるイベントＩＤをログデータイベントＩＤと称し、イベントのチェックリストに登録されているイベントをチェックデータイベントＩＤと称する。ステップＳ１１８においては、ログデータイベントＩＤとチェックデータイベントＩＤとの比較が行われる。

ステップＳ１１８（イベントＩＤ確認）において、読み取ったログデータイベントＩＤと、チェックデータイベントＩＤとが一致した場合、エラーの発生回数を確認するステップが次に実行される。すなわち、一致したチェックデータイベントＩＤ（この場合、ログデータイベントＩＤも同じ）が、所定の回数に到達したか否かの判定がステップＳ１１９（発生回数確認）において行われる。所定の回数に到達した場合、次にステップＳ１２０が実行される。このステップＳ１１９においては、ステップＳ１１８からの一致を受けて、そのチェックデータイベントＩＤの発生（出現）の回数を“１”だけ増やす処理が行われる。特に制限されないが、回数を“１”だけ増加させた後で、上記した所定の回数に到達しているか否かの判定処理が行われる。

また、チェックリストには、後で図３を用いて説明するが、そのエラーの発生回数をチェック（確認）せずに、永久エラーとして処理すべきエラーもチェックデータイベントＩＤとして登録されている。本明細書においては、このチェックをしないエラーをチェック不要エラーと称する。このチェック不要エラーは、後で説明する図３から理解されるが、複数種類存在する。ログデータイベントＩＤとチェックデータイベントＩＤとの比較により、チェック不要エラーであると、ステップＳ１１８において判定された場合、ステップＳ１１９の処理はスキップされ、ステップＳ１２０が、次に実行される。

ステップＳ１２０は、チェックデータイベントＩＤに対応するエラーが所定の回数だけ発生した場合と、チェック不要エラーが発生した場合に、実行される。このステップＳ１２０の実行により、永久エラーが発生した旨の永久エラー情報が作成され、登録される。チェックリストに登録されているイベントＩＤには、期待エラーが発生した場合にシステムのログに登録されるイベントＩＤに対応するチェックデータイベントＩＤが含まれている。従って、その情報が十分に公開されていない部品を実装したときに、所定の回数以上に期待エラーが発生すると、永久エラーの発生を示す永久エラー情報が、ステップＳ１２０において形成される。すなわち、永久エラーの発生と推定される。発生しているエラーが永久エラーでなく、上記した所定の回数以上、実行（リトライ）すれば、エラーの解消が図れる場合もあるが、この実施の形態の様に、永久エラーの発生と同様と見なすことにより、時間的なパフォーマンスの低下を防ぐことが可能となる。

ステップＳ１１８において、システムのログに登録されているイベントＩＤが、チェックリストに登録されているイベントＩＤと一致しない場合、あるいはステップＳ１１９において、発生回数が、所定の回数に到達していないと判断された場合には、次にステップＳ１２１が実行される。また、上記したステップＳ１２０において、永久エラー情報を登録した後も、ステップＳ１２１が次に実行される。このステップＳ１２１においては、特に制限されないが、ログのチェックが行われたかの確認が行われる。もし、ログのチェックが済んでいなければ、再度ステップＳ１１８に戻り、ログのイベントＩＤをチェックする。ログのチェックが済んでいれば、次にステップＳ１２２が実行される。

ステップＳ１２２においては、システムのログとして登録されているログの件数分、ログのチェックが行われたかの判定を行う。もし、システムのログに登録されている件数分のログのチェックが済んでいなければ、上記したステップＳ１１７に戻り、ログの取り込みを行い、ステップＳ１１８以降のチェック処理を繰り返す。一方、件数分のログについて、チェックが済んでいると判断した場合には、ログエラーチエック処理の出口（Ａ２）へ移る。このとき、ログエラーチェック処理において、永久エラーと見なせるエラーが検出されて、永久エラー情報が登録されていた場合には、その永久エラー情報が、以降のステップに伝わる様にして、ログエラーチェック処理は完了する。

ログエラーチェック処理が完了すると、次にステップＳ１０４が実行される。ステップＳ１０４においては、二重化状態の取得処理が行われる。この二重化状態の取得処理においては、ログエラーチェック処理を行ったところの自機が、運用系の制御装置なのか待機系の制御装置なのかの判定が行われる。

ステップＳ１０４の次に、ステップＳ１１１が実行される。ステップＳ１１１においては、上記したログエラーチェック処理において、永久エラー情報が登録されているか否かの判定が行われる（図においては、エラー判定と記載）。もし、永久エラー情報が登録されている場合、エラーとして次のステップＳ１１２が実行される。ステップＳ１１２では、既にエラーの表示がされているか否かの判定が行われる（表示判定）。もし、ステップＳ１１２において、エラーの表示がされていないと判定（未表示）された場合には、エラーが発生している旨のメッセージ表示を、ステップＳ１１３において行う。エラーのメッセージを表示した後、ステップＳ１１４において、開いていたシステムのログを閉じる（システムログクローズ）。

一方、ステップＳ１１１において、永久エラー情報を基にした判定の結果として、エラーは発生していないとなった場合には、ステップＳ１１１の後に、ステップＳ１１４を実施して、システムのログを閉じる。また、ステップＳ１１２において、エラーが発生している旨のメッセージを、既に表示していると判定した場合においても、ステップＳ１１２の後に、ステップＳ１１４を実行して、システムのログを閉じる。ステップＳ１１４を実行した後、所定の期間（本実施の形態においては、５秒間）の待機時間をステップＳ１１５で確保し、再び、上記したステップＳ１０２からの処理を実行する。

上記した処理（ステップＳ１０２〜Ｓ１０４、ステップＳ１１１〜Ｓ１２２）を、所定の時間だけ繰り返す。これにより、この所定の時間におけるシステムのログに表れるエラーの発生回数が、求められる。求められたエラーの発生回数が、ステップＳ１１９で比較される所定の回数に達していれば、当該エラーは、永久エラーと見なされ、表示される。

上記したステップＳ１０４において、自機が待機系の制御装置であると判定された場合にも、上述したのと同様に、ステップＳ１１１からステップＳ１１５が実施される。この様にして、システムの制御を主として実施していない、待機系の制御装置においても、永久エラーが発生しているときには、その旨のメッセージが表示される。一方、ステップＳ１０４において、自機は運用系の制御装置であると判定された場合には、ステップＳ１１１において永久エラー情報が登録されているか否かにより、例えば、ステップＳ１１５における待機時間が変更される。すなわち、自機が運用系であり、永久エラー情報が登録されているときには、待機時間を、例示の５秒よりも短くし、上記したログエラーチェックがより短い時間間隔で実施される様にしてもよい。この様にすることにより、より短い時間間隔で、エラーチェックが行われる様になり、エラー判定の信頼性を向上させることが可能となる。一方、自機が運用系で、永久エラー情報が登録されていない場合には、待機時間を例示の値（５秒）あるいはそれ以上に長い待機時間として、ログエラーチェック処理が行われる間隔を、永久エラー情報が登録されている場合に比べて長くなる様にしてもよい。

また、ステップＳ１０４において、自機が運用系であると判定され、ステップＳ１１１において、永久エラー情報が登録されていると判定した場合には、待機系の制御装置として待機している制御装置に、システムを管理するための処理を切り替える様にしてもよい。この場合においても、ステップＳ１１３において、エラーが発生した旨のメッセージは表示することが、信頼性の観点から望ましい。

なお、ステップＳ１１３におけるエラーのメッセージは、制御装置２あるいは３に設けられた表示装置で行うことが可能である。

エラーが発生しているか否かを判定するための時間（所定の時間）は、上記した処理のループを繰り返す回数として設定してもよい。この場合、例えば、ステップＳ１１５からステップＳ１０２に戻る回数をカウンタ等で、計測し、カウンタのカウント数が所定の値に到達するまでの回数が、エラーが発生しているか否かを判定する時間（所定の時間）に相当する。また、ステップＳ１１９で比較される発生回数は、起動を行うステップＳ１０１において、所望の値に設定する。

なお、ステップＳ１１８で一致と判定された値（回数）は、上記したエラーが発生しているか否かを判定するための時間の間（期間）、ステップＳ１１９において、保持され、更新される。また、このエラーが発生しているか否かを判定するための期間を経過したときに、ステップＳ１１８で一致と判定された値（回数）は、リセットされる。すなわち、ステップＳ１１９に保持されていた回数がリセットされる。もちろん、このリセット後に、再度エラーチェックをする際には、上記した判定するための期間、一致と判定された値（回数）は、ステップＳ１１９において、保持され、更新される。

次に、イベントＩＤについて、二重化制御装置の制御機能処理（切り替え処理）の一覧を用いて説明する。図３には、二重化制御装置において、運用系の制御装置と待機系の制御装置とを切り替える場合の状態が示されている。なお、運用系と待機系との間の切り替えは、図３に示されているもの以外にも存在する。そのため、図３は、一例であると理解されたい。

図３は、運用系と待機系とを切り替える場合の状態を示す一覧（リスト）の図である。同図のリストは、４個の列（３００〜３０３）を有しており、列３００にはイベントＩＤが記載されている。列３００には、この実施の形態においては、イベントＩＤの種類が、１〜８として記載されている。それぞれのイベントＩＤに対応する、障害種別、故障部位及び要因、自動切替が、列３０１、３０２、３０３に記載されている。すなわち、リストには、イベントＩＤと、それに対応するエラーと、運用系／待機系の自動的な切替（自動切替）が、列記されている。また、後で説明するが、イベントＩＤ「１」から「８」には、期待エラーに対応したイベントＩＤも含まれている。言い換えるならば、このリストには、期待エラーに対応した情報（自動切替等）が含まれている。以下、例示したイベントＩＤについて述べる。

イベントＩＤが「１」は、故障部位及び要因３０２が、「ＣＰＵ（プロセッサ）故障」であり、障害種別３０１は、「ハードウェア」である。このイベントＩＤ「１」が発生した場合には、自動切替３０３は、「有」であり、自動的に運用系と待機系を切り替えることを意味している。このイベントＩＤ「１」が発生した場合、制御装置内のプロセッサが故障していることが、故障の要因であるため、無条件に運用系と待機系の切替を行う。

イベントＩＤが「４」は、故障部位及び要因３０２が、「Ｉ／Ｏ（入出力）装置無応答」であり、障害種別３０１は、「ハードウェア」であり、自動切替３０３は、「一部有」である。このイベントＩＤ「４」は、期待エラーの一例である。すなわち、時間が経過すれば、入出力装置から応答があることが考えられる。そのため、自動的に切り替えるか否かが決められない。

イベントＩＤが「５」は、故障種別３０１が、「ハードウェア」ではなく、「ソフトウェア」の例である。このイベントＩＤ「５」の故障部位及び要因３０２は、「ＯＳ（オペーレションシステム）異常」であり、自動切替３０３は、「有」である。このイベントＩＤは、例えば、オペレーションシステムが強制停止しているときに、発生する。もちろん、オペレーションシステムが強制停止しているので、運用系と待機系の切替は、自動的に行われる。

イベントＩＤが「７」も、期待エラーである。このイベントＩＤ「７」は、障害種別３０１が「ソフトウェア」であり、故障部位及び要因３０２が、「アプリケーション異常」
である。このイベントＩＤにおいては、制御装置で実行されているプロセスの状況に応じて、運用系と待機系との間の切替が行われる様にする。そのため、自動的に切り替えるか否かの判定は、「一部有」とされる。言い換えるならば、実行されているプロセスの状況によっては、異常では無くなる可能性がある。

イベントＩＤが「８」は、障害種別３０１が、「ソフトウェア」であり、故障部位及び要因３０２が、「リソース監視」である。この場合には、自動の切替を実施する必要が無いため、自動切替３０３は、「無」である。

制御装置２、３のそれぞれには、図３に示したリストが、チェックリストとして格納（記憶）されている。一方、制御装置２および３のそれぞれは、エラーが発生すると、システムのログにエラーログを登録する。このときのエラーログとして、図３に示したイベントＩＤの番号が登録される。

図２において、ステップＳ１１８は、チェックリストとして設けられた図３のリストにおけるイベントＩＤの番号と、システムのログとして登録されているエラーログ（イベントＩＤの番号）とを比較する。この比較により、一致した場合、一致したイベントＩＤに対応するところの自動切替３０３における項目が、参照される。この参照において、自動切替３０３が、「有」となっていれば、ステップＳ１１８は、そのエラーは、チェック不要エラーと判定し、次にステップＳ１２０を実行させる。ステップＳ１２０は、これを受けて、永久エラーと見なして、永久エラー情報を登録する。

また、一致したイベントＩＤに対応する自動切替３０３における項目が「無」となっていれば、ステップＳ１１８は、例えば、一致したことを無効にする。あるいは、ステップＳ１１９において、発生回数を計測する対象から外す。

一致したイベントＩＤに対応する自動切替３０３における項目が「一部有」を示す情報になっていた場合、ステップＳ１１８からは、一致したことがステップＳ１１９に知らされる。ステップＳ１１９においては、このイベントＩＤに関して、今まで積算されていた回数に、加算を行い、所定の回数に達したか否かの判定を行う。到達していれば、その旨がステップＳ１２０に知らされ、ステップＳ１２０において、永久エラー情報が登録される。

自動切替３０３において、「一部有」は、故障要因により、システムの運用に支障をきたすと思われる故障が発生している場合と、リトライ処理による復帰する事象、あるいはシステムの運用に影響を与えない装置などに故障が発生している場合に、登録する。この場合、リトライ処理による復帰する事象あるいはシステムの運用に影響を与えない装置などに故障が発生している場合には、システムを継続して運用することが可能と判断して、自動での切替は実施しない。

例えば、十分に情報の公開がされていない部品として、種々の情報あるいはデータを記憶するために用いられるディスクがある。ディスクは、その故障モードによっては、リトライ処理を行うことによって正常にアクセスでき、ディスクエラーに至らない場合がある。そのため、自動での切替は適切ではない。しかしながら、この様なリトライ処理が一過性でなく、継続して発生すると、ディスクアクセスエラーの性能劣化によりシステム全体のパフォーマンス低下を招く。

本実施の形態によれば、上記したディスクのエラーは、イベントＩＤ「４」として登録される。これにより、所定の時間の間に、所定の回数に達するイベントＩＤ「４」が発生したとき、永久エラーと推定して、永久エラー情報が登録される。永久エラー情報に基づいたメッセージ表示を確認して、運用系から待機系への切替あるいは、部品の交換を行うことにより、二重化制御装置の信頼性の向上を図ることが可能となる。また、システム全体のパフォーマンス低下を抑制することも可能となる。

また、イベントＩＤ「７」が発生した場合も、時間の経過により、システムを継続して運用することが可能な場合が有り、自動で切替を行うのは適さない。本実施の形態によれば、所定の時間の間、所定の回数に達するイベントＩＤ「７」が発生した場合、永久エラーと見なして、表示が行われる。この様にすることにより、システム全体のパフォーマンス低下を抑制することが可能となる。

本実施の形態においては、メッセージを表示する様にしているが、メッセージの代わりに、運用系から待機系への切替を行う様にしてもよい。また、図３に示したリストは、それぞれの制御装置に格納しなくてもよく、図２に示した処理を行う制御装置に格納されていればよい。また、上記した所定の時間および所定の回数は、ステップＳ１０１において、システムを起動する際に、設定すればよい。

以上本発明者によってなされた発明を、前記実施形態に基づき具体的に説明したが、本発明は、前記実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。

２、３ 制御装置
Ｓ１１３ メッセージ表示ステップ
Ｓ１１８ イベントＩＤ確認ステップ
Ｓ１１９ 発生回数確認ステップ

Claims (9)

1. 複数の制御装置を具備し、前記複数の制御装置のうちの第１の制御装置の故障に応答して、前記複数の制御装置のうちの第２の制御装置が、前記第１の制御装置の代わりに処理を行う多重化制御装置であって、
   前記複数の制御装置のうちの一の制御装置において発生するエラーをログとして登録するログ登録ユニットと、
   前記ログ登録ユニットにより登録されたログにおいて、所定の期間におけるログから、前記一の制御装置において発生したエラーの回数を求め、求めたエラー回数が所定の回数に達したとき、故障情報を出力する検出ユニットと、
   を具備し、
   前記検出ユニットからの前記故障情報に応じた処理を行う、多重化制御装置。
2. 請求項１に記載の多重化制御装置において、
   前記検出ユニットは、前記ログ登録ユニットにより登録されているログから、期待エラーを検出し、期待エラーの検出回数が、前記所定の回数に達したとき、前記故障情報を出力する、多重化制御装置。
3. 請求項２に記載の多重化制御装置において、
   前記検出ユニットは、前記期待エラーを特定する情報を有し、前記ログ登録ユニットにより登録されたログと前記情報とを比較することにより、ログから期待エラーを検出する、多重化制御装置。
4. 請求項３に記載の多重化制御装置において、
   前記多重化制御装置は、前記故障情報に応答して、故障情報を表示する処理を行う、多重化制御装置。
5. 請求項３に記載の多重化制御装置において、
   前記一の制御装置は、前記第１の制御装置であり、
   前記多重化制御装置は、前記故障情報に応じて、前記第１の制御装置の代わりに前記第２の制御装置に処理を行わせる、多重化制御装置。
6. 請求項２に記載の多重化制御装置において、
   前記期待エラーの検出回数が、前記所定の回数を超えないとき、前記一の制御装置が処理を継続する、多重化制御装置。
7. 請求項１に記載の多重化制御装置において、
   前記一の制御装置は、プログラムに従って動作し、
   前記ログ登録ユニットおよび前記検出ユニットのそれぞれは、前記一の制御装置が前記プログラムを実行することにより、構成される、多重化制御装置。
8. 複数の制御装置のうちの第１の制御装置の故障に応答して、前記複数の制御装置のうちの第２の制御装置が、前記第１の制御装置の代わりに処理を行う多重化制御方法であって、
   前記複数の制御装置のうちの一の制御装置におけるエラーをログとして登録する工程と、
   前記登録されたログにおいて、所定の期間におけるログから、前記一の制御装置において発生しているエラーの回数を求める工程と、
   求めたエラーの回数が所定の回数に達したとき、故障に応じた処理を行う工程と、
   を具備する、多重化制御方法。
9. 請求項８に記載の多重化制御方法において、
   前記エラーの回数を求める工程により求められるエラーの回数は、期待エラーの回数である、多重化制御方法。

Images