JP4679956B2 - ネットワーク故障判定方法およびネットワーク制御方法 - Google Patents

Description

この発明は、分散して配置された複数の計算機がネットワークによって接続されてなるネットワークシステムにおいて、計算機の故障かネットワークの故障かのいずれかを判断することができるネットワーク故障判定方法およびネットワーク制御方法に関するものである。

従来のネットワークシステムは複数の計算機をネットワーク（ＬＡＮ）で接続したネットワーク分散システムの構成が主流である（例えば、非特許文献１参照）。
従来は、各計算機から送信されるデータの有無により各計算機単位の故障は判定していたが、ネットワーク自体の故障は判定していなかった。各計算機間では通信ネットワークを介したデータ連携（データアクセス・プログラム間通信など）が常時行われており、通信ネットワークの故障は系統制御システム全体の機能喪失に直結する重大な事象である。このため、ネットワークの故障は、その故障様相に関わらず確実に検出し、ネットワークの使用を停止（冗長構成の場合は別ネットワークヘの切り替えを実施）する必要がある。

堀内謙二・塚原研・有本雅昭著、「フリーソフトウェア活用による電力系統監視制御システムのソフトウェア生産環境改善」、電気学会全国大会発行、平成１５年３月１７日

従来のネットワーク故障判定方法は、ネットワークに接続される各計算機単位に測定期間もしくは所定回数通信が途絶えたことをもって故障と判定していた。この方式では各計算機毎の故障は検出できるもののネットワーク全体の故障や通信可・不可を繰り返すような不安定な通信状況（ハンチング現象）を検出することができないという問題点があった。

この発明は上記のような課題を解決するためになされたものであり、各計算機単位の故障とネットワーク全体の故障を区別でき、さらに、ネットワークが通信可・不可を繰り返すような不安定な通信状況（ハンチング現象）を検出してそれに対応するネットワーク故障判定方法およびネットワーク制御方法を得ることを目的とする。

この発明は、分散して配置された複数の計算機がネットワークによって接続され各計算機はヘルスチェック信号を定期的にネットワークに送信するネットワークシステムにおいて、各計算機のヘルスチェック信号をネットワークを介して受信して、任意の期間においてヘルスチェック信号が受信できない各計算機の数が所定数より少ないとヘルスチェック信号が受信できない計算機の故障と判断し、ヘルスチェック信号を受信できない各計算機の数が所定数を超えるとネットワークの故障であると判断し、
上記ヘルスチェック信号を第１の所定期間以上連続して受信できない計算機は、上記第１の所定期間後の第２の所定期間において上記ヘルスチェック信号が受信できないものとして判断を行うものである。

この発明のネットワーク故障判定方法は、分散して配置された複数の計算機がネットワークによって接続され各計算機はヘルスチェック信号を定期的にネットワークに送信するネットワークシステムにおいて、各計算機のヘルスチェック信号をネットワークを介して受信して、任意の期間においてヘルスチェック信号が受信できない各計算機の数が所定数より少ないとヘルスチェック信号が受信できない計算機の故障と判断し、ヘルスチェック信号を受信できない各計算機の数が所定数を超えるとネットワークの故障であると判断し、
上記ヘルスチェック信号を第１の所定期間以上連続して受信できない計算機は、上記第１の所定期間後の第２の所定期間において上記ヘルスチェック信号が受信できないものとして判断を行うので、各計算機の故障かネットワークの故障かを容易に判断することができる。

実施の形態１．
以下、本願発明の実施の形態について説明する。図１はこの発明の実施の形態１のネットワークシステムの構成を示すブロック図、図２および図３は図１に示したネットワークシステムの通信状態を示す通信状態管理テーブルである。図において、本願ネットワークシステムは第１のネットワーク１および第２のネットワーク２にて構成される多重化ネットワーク３であり、分散して配置された複数の計算機４、５、６、７、８、９、１０、１１が第１のネットワーク１および第２のネットワーク２にそれぞれ接続されている。尚、ここで言う各ネットワークとはＨＵＢ機器なども含み、各計算機４、５、６、７、８、９、１０、１１以外の部分を指すものである。

次に、上記のように構成された実施の形態１のネットワーク故障判定方法について図２および図３を交えながら説明する。まずここでは各計算機４、５、６、７、８、９、１０、１１は第１のネットワーク１を介してデータの送受信を行っているものとする。また、各計算機４、５、６、７、８、９、１０、１１は第１のネットワーク１に定期的にヘルスチェック信号を送信している。尚、このヘルスチェック信号とは通常の運転や制御などに伴う信号と異なり、各計算機の動作チェックを行うための信号である。次に、ここでは計算機Ｈ１１におけるネットワーク故障判定方法について説明する。まず、計算機Ｈ１１は第１のネットワーク１から他の各計算機４、５、６、７、８、９、１０から送信されているヘルスチェック信号を受信して通信状態管理テーブルを作成する。

通信状態管理テーブルとは計算機Ｈ１１が当該計算機Ｈ１１の通信相手となる各計算機４、５、６、７、８、９、１０との通信状態を示すものであり、横軸に期間をとり縦軸に各計算機４、５、６、７、８、９、１０をとりヘルスチェック信号の受信の有無を示したテーブルである。そして、単位期間内（例えば、ヘルスチェック信号は定期的出力されるため、その定期的期間を単位期間としてもよい。また、定期的期間の２倍の期間を単位期間と設定してもよい。）に各計算機４、５、６、７、８、９、１０からヘルスチェック信号を一度でも受信した場合には、状態を「○（通信可）」と判断し、相手計算機の停止やネットワーク障害等でデータを全く受信できなかった場合には、状態を「×（通信不可）」と判断して作成される。尚、この通信状態管理テーブルでは単位期間あたりを１コマとして示している。

そして、例えば図２に示すように通信状態管理テーブルが作成される。状態２は全計算機が通信可能な状態「○」を示しており、状態３は計算機Ｂ５が停止もしくはネットワーク障害が発生し、計算機Ｂ５とのみ通信ができない状態「×」を示している。そしてこの場合から、通信不可能な計算機は計算機Ｂ５の１台のみであり、かつ、任意の期間、例えば状態３からテーブルの３コマに相当する状態３ａの期間までにおいて計算機Ｂ５のみが通信不可能であるため、ネットワークの故障とは判断せず、計算機Ｂ５のみの故障であると判断する。よって、第１のネットワーク１は正常であるため、第１のネットワーク１をそのまま使用してデータの送受信を行う制御を継続すると判断する。尚、計算機の故障の判断は、「×」の信号が任意の期間発生した場合に故障として判定するため、この任意の期間はネットワークシステムに応じて適宜設定する必要がある。また、計算機の故障として判断した場合には、外部にそのことを通知して該当計算機の修理または交換を行うなどの対処を容易に行うことができる。

次に、例えば図３に示すように通信状態管理テーブルが作成される。通常、通信状態が「×」となる理由は相手計算機が停止した、もしくは相手計算機に実装されているＬＡＮカード（もしくはケーブル類）に故障が発生したことが考えられる。本発明はこれらの通信状態が「×」となる確率に着目したものである。複数の計算機で同時期にこれらの故障が発生する確率は極めて低いことから、所定数（例えば、ここでは４台以上と設定する）の計算機との通信状態が「×」となった場合は、その要因が相手計算機の故障ではなく、相手計算機と自計算機とを接続する第１のネットワーク１自体に故障の原因が存在すると判断する。

具体的には図３において、状態４は計算機Ｂ５の１台とのみ通信できない状態を示しており、この状態ではまだ故障要因は相手計算機Ｂ５のみにあるものと判断している。次に、状態５では計算機Ｂ５、計算機Ｄ７、計算機Ｅ８、計算機Ｇ１０の４台と通信できない状態となっており、かつこの期間が、任意の期間である例えば状態５からテーブルの２コマに相当する状態５ａに相当する期間まで連続して発生している。このため、所定数以上の計算機との通信異常が任意の期間発生するということは、故障要因が第１のネットワーク１自体にある可能性が高いと判断する。そしてこのように第１のネットワーク１が故障であると判断されると、計算機Ｈ１１は故障と判断された第１のネットワーク１と別の第２のネットワーク２を介してデータの送受信を行うよう制御する。

尚、以後は第２のネットワーク２においても上記第１のネットワーク１と同様にネットワーク故障判定方法およびネットワーク制御方法を行うことができるのは言うまでもない。また、ここでは計算機Ｈ１１のみにおけるネットワーク故障判定方法およびネットワーク制御方法の例を示したが、他の計算機においても同様の判断がされ同様の結果が生じると考えられるため、他の計算機においても、第１のネットワーク１が故障であると判断され第２のネットワーク２においてデータの送受信を行うように制御される。また、このことは以下の実施の形態においても同様であるためその説明は適宜省略する。

上記のように構成された実施の形態１のネットワーク故障判定方法およびネットワーク制御方法によれば、各計算機のヘルスチェック信号を確認するのみにて各計算機の故障であるか、ネットワークの故障であるかを容易に判断することができる。また、それに応じて、多重化されたネットワークに接続されている場合は、故障と判断されていない別のネットワークを介してデータの送受信を行うことができるためシステムの安定化を図ることが可能となる。

実施の形態２．
図４はこの発明の実施の形態２におけるネットワーク故障判定方法の通信状態管理テーブルを示す図である。上記実施の形態１では通信状態（可・不可）を各計算機からヘルスチェック信号を一度でも受信したか否かのみで判定しているが、本実施の形態２では測定期間内の通信率を加味して故障を判定するものである。この場合、通信率を加味することにより、通信可・不可を繰り返し通信不可の状態が連続しないものの、通信が不安定な状況（いわゆる、ハンチング現象と呼ばれる現象）を、当該計算機の近傍におけるネットワークに障害が発生していると判断することが可能となる。

例えば図４（ａ）に示すように、上記実施の形態１と同様に通信状態管理テーブルが検出される。次に、測定期間（ここでは、テーブルの７コマ分を測定期間とする）における通信率を、○を１００％、×を０％として、各計算機４、５、６、７、８、９、１０においてそれぞれ算出する。次に、算出された各通信率が所定値より低いか否かを判断する。ここでは所定値を例えば７０％として設定する。よって、計算機Ｂ５および計算機Ｄ７が所定値より低いと判断され、これらの計算機Ｂ５および計算機Ｄ７の近傍のネットワークに障害が発生していると判断し、測定期間における計算機Ｂ５および計算機Ｄ７の通信結果をすべて「×」として判断する。

そして、図４（ｂ）に示すように、通信状態管理テーブルを図４（ａ）の状態から変換する。すなわち、計算機Ｂ５および計算機Ｄ７の通信結果が測定期間においてすべて「×」に変換される。そして、上記実施の形態１と同様に、状態６では計算機Ｂ５、計算機Ｄ７、計算機Ｅ８、計算機Ｇ１０の４台と通信できない状態となって、連続したテーブルのコマである状態７においても計算機Ｂ５、計算機Ｄ７、計算機Ｅ８、計算機Ｆ９の４台と通信できない状態となって、所定数（ここでは４台以上と設定されている）以上の計算機との通信故障が、任意の期間である例えば２コマ分連続して発生しているため、故障要因が第１のネットワーク１自体にある可能性が高いと判断する。そしてこのように第１のネットワーク１が故障であると判断される。そして、計算機Ｈ１１は故障と判断された第１のネットワーク１と別の第２のネットワーク２を介してデータの送受信を行うよう制御する。

例えば図４（ａ）のような通信状態管理テーブルの状態のままにて上記実施の形態１と同様の判断を行うと、状態６ａのみにて計算機Ｂ５、計算機Ｄ７、計算機Ｅ８、計算機Ｇ１０の４台と通信できない状態となっており、状態７ａでは計算機Ｄ７、計算機Ｅ８、計算機Ｆ９の３台と通信できない状態となり、所定数以上の計算機との通信故障が任意の期間して発生していないため、第１のネットワーク１自体の故障ではないと判断されてしまう。実際には計算機Ｂ５および計算機Ｄ７近傍でハンチング現象が発生してネットワークが不安定になっており、このことを見逃すこととなる。

上記のように構成された実施の形態２のネットワーク故障判定方法およびネットワーク制御方法によれば、上記実施の形態１と同様の効果を奏するのはもちろんのこと、さらに通信率を加味してネットワークの故障であるかを判断しているため、ネットワークの故障の判断をより一層強化することができる。さらにそれに応じて、多重化されたネットワークに接続されている場合は、故障と判断されていない別のネットワークを介してデータの送受信を行うことができるためシステムの安定化をさらに図ることが可能となる。

実施の形態３．
図５はこの発明の実施の形態３におけるネットワーク故障判定方法の通信状態管理テーブルを示す図である。上記各実施の形態では通信状態不可の計算機の数のみにてネットワークの故障を判定しているが、本実施の形態３では計算機全体の平均通信率を考慮に入れてネットワークの故障を判定する。

例えば図５に示すように、上記各実施の形態と同様に通信状態管理テーブルが検出される。次に、各計算機４、５、６、７、８、９、１０の測定期間（ここでは、テーブルの７コマ分を測定期間とする）における通信率をそれぞれ算出する。次に、算出された各計算機４、５、６、７、８、９、１０の通信率の平均通信率を算出する。次に、算出された平均通信率が平均所定値より低いか否かを判断する。ここでは平均所定値を７８％として設定する。よって、この場合平均通信率は７７．２％であるため平均所定値より低いと判断され、第１のネットワーク１に障害が発生していると判断する。そしてこのように第１のネットワーク１が故障であると判断されると、計算機Ｈ１１は故障と判断された第１のネットワーク１と別の第２のネットワーク２を介してデータの送受信を行うよう制御する。尚、ここでは便宜上平均通信率のみにて判定を行っているが、上記実施の形態１の判断も合わせて実施することは言うまでもない。

例えば、図５に示すように通信状態管理テーブルが検出され上記実施の形態１と同様の判断のみを実施していた場合には、状態８のみにて計算機Ｂ５、計算機Ｄ７、計算機Ｅ８、計算機Ｇ１０の４台と通信できない状態となって、他は４台より少ない計算機と通信できない状態となっているため、所定数以上の計算機との通信故障が任意の期間である例えば２コマ分連続して発生していないため、第１のネットワーク１自体の故障ではないと判断されてしまう。しかし、実際には全体的にハンチング現象が発生して、ネットワークが不安定になっており、このことを見逃すこととなる。

上記のように構成された実施の形態３のネットワーク故障判定方法およびネットワーク制御方法によれば、上記各実施の形態と同様の効果を奏するのはもちろんのこと、さらに平均通信率によってもネットワークの故障を判断しているため、ネットワークの故障の判断をより一層強化することができる。さらにそれに応じて、多重化されたネットワークに接続されている場合は、故障と判断されていない別のネットワークを介してデータの送受信を行うことができるためシステムの安定化をさらに図ることが可能となる。

実施の形態４．
図６はこの発明の実施の形態４におけるネットワーク故障判定方法の通信状態管理テーブルを示す図である。上記各実施の形態では通信状態をそのまま通信状態管理テーブルに表示する例を示したが、本実施の形態４においては、通信不可の計算機の「×」が所定数連続して検出された場合には一定期間通信不可能期間として復帰「○」とはしないようしてテーブルを作成する。

例えば図６（ａ）に示すように、上記各実施の形態と同様に通信状態管理テーブルが検出される。次に、通信不可「×」の状態が第１の所定期間以上連続すると第２の所定期間分は通信可「○」として判断されても通信不可「×」の状態として判断を行う。そして、ここでは例えば第１の所定期間を３コマ連続として、第２の所定期間を２コマ連続とする。よって、図６（ａ）の状態から変換され、図６（ｂ）に示すような通信状態管理テーブルが得られる。すなわち、図６（ａ）において、計算機Ｂ５および計算機Ｃ６および計算機Ｄ７および計算機Ｇ１０の通信結果は「×」が第１の所定期間以上に相当する３コマ連続したして受信した後の、その後の第２の所定期間に相当する２コマ分を「○」に復帰せず「×」とする。

そして、上記実施の形態１と同様に、状態９では計算機Ｂ５、計算機Ｃ６、計算機Ｄ７、計算機Ｇ１０の４台と通信できない状態となって、連続した次のコマの状態１０においても計算機Ｂ５、計算機Ｃ６、計算機Ｄ７、計算機Ｇ１０の４台と通信できない状態となって、所定数（ここでは４台以上と設定されている）以上の計算機との通信故障が任意の期間である例えば２コマ分連続して発生しているため、故障要因が第１のネットワーク１自体にある可能性が高いと判断する。そしてこのように第１のネットワーク１が故障であると判断される。そして、計算機Ｈ１１は故障と判断された第１のネットワーク１と別の第２のネットワーク２を介してデータの送受信を行うよう制御する。

例えば図６（ａ）のような通信状態管理テーブルの状態のままにて上記実施の形態１と同様の判断を行うと、状態９ａのみにて計算機Ｂ５、計算機Ｃ６、計算機Ｄ７、計算機Ｇ１０の４台と通信できない状態となっており、状態１０ａでは計算機Ｃ６、計算機Ｄ７、計算機Ｇ１０の３台と通信できない状態となり、所定数以上の計算機との通信故障が任意の期間である例えば２コマ分連続して所定数の計算機の故障が発生していないため、第１のネットワーク１自体の故障ではないと判断されてしまう。実際には計算機Ｂ５近傍でハンチング現象が発生してネットワークが不安定になっており、このことを見逃すこととなる。

上記のように構成された実施の形態４のネットワーク故障判定方法およびネットワーク制御方法によれば、上記各実施の形態と同様の効果を奏するのはもちろんのこと、さらに通信状態が不安定となっている通信結果に対して強制的に通信不可として例えばハンチング現象に対応してネットワークの故障を判断しているため、ネットワークの故障の判断をより一層強化することができる。さらにそれに応じて、多重化されたネットワークに接続されている場合は、故障と判断されていない別のネットワークを介してデータの送受信を行うことができるためシステムの安定化をさらに図ることが可能となる。

実施の形態５．
図７はこの発明の実施の形態５におけるネットワーク故障判定方法の通信状態管理テーブルを示す図である。上記各実施の形態では各計算機の運行スケジュールを考慮に入れずネットワークの故障を判定する例を示したが、本実施の形態５では各計算機の運行スケジュールを考慮に入れてネットワークの故障を判定する例について説明する。

例えば図７に示すように、上記各実施の形態と同様に通信状態管理テーブルが検出される。次に、各計算機４、５、６、７、８、９、１０の内運行スケジュールが停止期間となると計算機、ここでは計算機Ｅ８が状態１２から、計算機Ｇ１０が状態１１からそれぞれ停止期間となる。よって、この停止期間においてはこれら各計算機Ｅ８および計算機Ｇ１０は故障判定に加味せずに行う。よって、上記実施の形態１と同様の判断を行うと、状態１３のみにて計算機Ａ４、計算機Ｂ５、計算機Ｄ７、計算機Ｆ９の４台と通信できない状態となっており、状態１２では計算機Ｂ５、計算機Ｄ７の２台と通信できない状態となり、所定数（ここでは４台以上と設定されている）以上の計算機との通信故障が任意の期間である例えば２コマ分連続して発生していないため、第１のネットワーク１自体の故障ではないと判断する。但し、停止期間中の計算機が存在する場合には、停止期間中の計算機の数に応じて所定数の数を適宜変更する場合も考えられる。

例えば図７のような通信状態管理テーブルの状態のままにて上記実施の形態１と同様の判断を行うと、状態１３にて計算機Ａ４、計算機Ｂ５、計算機Ｄ７、計算機Ｆ９、計算機Ｇ１０の５台と通信できない状態となっており、状態１２では計算機Ｂ５、計算機Ｄ７、計算機Ｅ８、計算機Ｇ１０の４台と通信できない状態となり、所定数以上の計算機との通信故障が任意の期間である例えば２コマ分連続して発生するため、第１のネットワーク１自体の故障ではないと判断されてしまう。実際には、計算機Ｅ８および計算機Ｇ１０は停止期間中でネットワークの故障の判断に入れるべきではなく、計算機Ｂ５および計算機Ｄ７のみの不都合によることであり、過剰にネットワークの故障を判断してしまうこととなる。

上記のように構成された実施の形態５のネットワーク故障判定方法およびネットワーク制御方法によれば、上記各実施の形態と同様の効果を奏するのはもちろんのこと、さらに計算機の点検（メンテナンス）や計画停止など予め故障が発生することが判明（予定）している計算機を故障判定対象から除外してネットワークの故障を判断しているため、ネットワークの故障の判断をより一層強化することができる。さらにそれに応じて、多重化されたネットワークに接続されている場合は、故障と判断されていない別のネットワークを介してデータの送受信を行うことができるためシステムの安定化をさらに図ることが可能となる。

尚、上記実施の形態２ないし上記実施の形態５においてはそれぞれのネットワーク故障判定方法およびネットワーク制御方法について説明したが、上記実施の形態２ないし上記実施の形態５を組み合わせて、ネットワークシステムのネットワーク故障判断方法およびネットワーク制御方法を行うようにしてもよいことは言うまでもなく同様の効果を得ることができる。

この発明の実施の形態１のネットワークシステムの構成を示すブロック図である。 図１に示したネットワークシステムの通信状態管理テーブルを示す図ある。 図１に示したネットワークシステムの通信状態管理テーブルを示す図ある。 この発明の実施の形態２におけるを示すネットワーク故障判定方法の通信状態管理テーブルを示す図ある。 この発明の実施の形態３におけるを示すネットワーク故障判定方法の通信状態管理テーブルを示す図ある。 この発明の実施の形態４におけるを示すネットワーク故障判定方法の通信状態管理テーブルを示す図ある。 この発明の実施の形態５におけるを示すネットワーク故障判定方法の通信状態管理テーブルを示す図ある。

符号の説明

１ 第１のネットワーク、２ 第２のネットワーク、３ 多重化ネットワーク、
４，５，６，７，８，９，１０，１１ 計算機。

Claims (5)

1. 分散して配置された複数の計算機がネットワークによって接続され上記各計算機はヘルスチェック信号を定期的に上記ネットワークに送信するネットワークシステムにおいて、上記各計算機の上記ヘルスチェック信号を上記ネットワークを介して受信して、任意の期間に上記ヘルスチェック信号が受信できない上記各計算機の数が所定数より少ないと上記ヘルスチェック信号が受信できない計算機の故障と判断し、上記ヘルスチェック信号を受信できない上記各計算機の数が上記所定数を超えると上記ネットワークの故障であると判断し、
   上記ヘルスチェック信号を第１の所定期間以上連続して受信できない計算機は、上記第１の所定期間後の第２の所定期間において上記ヘルスチェック信号が受信できないものとして判断を行うことを特徴とするネットワーク故障判定方法。
2. 上記各計算機の測定期間内の上記ヘルスチェック信号の通信率をそれぞれ算出し、上記通信率が所定値より低い上記計算機は上記測定期間内における上記ヘルスチェック信号を受信できない計算機として判断を行うことを特徴とする請求項１に記載のネットワーク故障判定方法。
3. 上記各計算機の測定期間内の上記ヘルスチェック信号の通信率をそれぞれ算出し、上記各通信率の平均通信率を算出し、上記平均通信率が平均所定値より低いと上記ネットワークの故障であると判断することを特徴とする請求項１または請求項２に記載のネットワーク故障判定方法。
4. 上記各計算機の運転スケジュールが停止期間となる計算機に対しては故障判定の対象から外すことを特徴とする請求項１ないし請求項３のいずれかに１項に記載のネットワーク故障判定方法。
5. 上記分散して配置された複数の計算機が多重化されたネットワークによって接続されているネットワークシステムにおいて、請求項１ないし請求項４のいずれか１項に記載のネットワーク故障判定方法において上記多重化されたネットワークの内いずれかのネットワークが故障である判断されると、上記各計算機が上記故障と判断されたネットワークと別のネットワークを介してデータの送受信を行うようにすることを特徴とするネットワーク制御方法。

Images