JP2014137806A - 故障通知装置、故障通知方法、及び故障通知プログラム - Google Patents

Abstract

【課題】故障の発生箇所を容易に特定することである。
【解決手段】ＯＭＰ１０は、アクセス経路特定部１３と故障被疑テーブル１８と被疑パッケージ判定部１５と表示制御部１６とを有する。アクセス経路特定部１３は、交換単位であるパッケージの故障発生時、複数のパッケージを含む経路の中から、故障が発生したパッケージを含む経路を特定する。被疑パッケージ判定部１５は、上記複数のパッケージの内、故障発生の疑われるパッケージを特定する情報を格納する故障被疑テーブル１８に格納された上記情報により特定されるパッケージと、アクセス経路特定部１３により特定された経路上のパッケージとを比較し、該比較の結果、一致するパッケージを、故障が発生したパッケージと判定する。表示制御部１６は、被疑パッケージ判定部１５により故障が発生したと判定されたパッケージの交換優先度を、他のパッケージの交換優先度よりも高くして通知する。
【選択図】図４

Description

本発明は、故障通知装置、故障通知方法、及び故障通知プログラムに関する。

従来、故障が発生した箇所を保守管理者に自動的に通知する故障通知装置が存在する。故障通知装置は、故障が疑われる箇所のパッケージ（以下、「被疑パッケージ」と記す。）を発生事象と対応付けて予め保持しておき、故障発生時には、発生事象に対応する被疑パッケージを、故障被疑箇所として表示する。ところが、故障通知装置は、通常、複数のパッケージを有するため、発生事象に対応する被疑パッケージが複数存在する場合には、故障箇所の特定が困難である。例えば、故障通知装置が交換機の制御装置である場合、複数のパッケージを経由したアクセスを行うため、保守管理者は、何れのパッケージが故障原因のパッケージであるかを、発生事象から正確に判別することは困難である。そこで、故障発生時に複数の被疑パッケージが存在する場合には、保守管理者は、まず、１つの被疑パッケージを交換して様子を見る。その後、故障が再発した場合には、別の被疑パッケージを交換して更に様子を見る。これにより、最終的に、装置故障の原因となるパッケージの特定、及びその交換を可能とする。

特開平８−１８１６９３号公報 特開２０１２−８９７４号公報 特開２０１０−１６５０９８号公報 特開２０１１−２０７５８号公報 国際公開第２００６／０４６３０９号

しかしながら、上述した従来技術は、発生事象の再現性が高く、被疑パッケージが明確な故障（以下、「固定故障」と記す。）に対しては有効であるが、故障が固定的に発生せず、被疑パッケージが明確でない故障（以下、「間欠故障」と記す。）への対応は困難である。従って、間欠故障が発生した場合には、保守管理者は、過去の故障発生履歴や予防交換の有無を基に、今回の被疑パッケージを自ら推定し、故障の可能性の高いパッケージを自ら判別した上で、交換しなければならなかった。このため、保守管理者は、必要以上に広範囲のパッケージを交換したり、交換して間もないパッケージを再び交換したりすることがあった。また、これとは反対に、保守管理者が、本来は交換すべき未交換の被疑パッケージを放置してしまうこと（交換漏れ）があった。このことが、装置故障の再発を招く要因となっていた。この様な問題は、早期の復旧作業が必要な社会インフラの障害発生時等、保守管理者に迅速な対応が要求される状況において、特に顕著となる。

開示の技術は、上記に鑑みてなされたものであって、故障の発生箇所を容易に特定することのできる故障通知装置、故障通知方法、及び故障通知プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本願の開示する故障通知装置は、特定部と格納部と判定部と通知部とを有する。前記特定部は、交換単位であるパッケージの故障発生時、複数のパッケージを含む経路の中から、故障が発生したパッケージを含む経路を特定する。前記格納部は、故障発生の疑われるパッケージを特定する情報を格納する。前記判定部は、前記複数のパッケージの内、前記格納部に格納された前記情報により特定されるパッケージと、前記特定部により特定された経路上のパッケージとを比較し、該比較の結果、一致するパッケージを、故障が発生したパッケージと判定する。前記通知部は、前記判定部により故障が発生したと判定されたパッケージの交換優先度を、他のパッケージの交換優先度よりも高くして通知する。

本願の開示する故障通知装置の一つの態様によれば、故障の発生箇所を容易に特定することができる。

図１は、交換機の構成を示す図である。 図２は、交換機の制御装置の構成を示す図である。 図３は、故障通知システムの構成を示す図である。 図４は、ＯＭＰの機能構成を示す図である。 図５は、ＰＲＯＣの機能構成を示す図である。 図６は、ＯＭＰのハードウェア構成を示す図である。 図７は、故障発生メッセージの構成例を示す図である。 図８Ａは、故障発生メッセージに設定されるアクセス種別の一例を示す図である。 図８Ｂは、故障発生メッセージに設定される故障種別の一例を示す図である。 図９は、実施例１に係るＯＭＰの故障被疑フラグテーブルの初期状態を示す図である。 図１０は、実施例１に係る故障通知システムにより実行される交換優先度表示処理を説明するためのフローチャートである。 図１１は、アクセス経路テーブルにおけるデータ格納例を示す図である。 図１２は、実施例１に係る故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図１３は、実施例１に係るＯＭＰの故障被疑フラグテーブルにおける故障被疑フラグの設定例を示す図である。 図１４は、実施例１に係る被疑パッケージ比較後の故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図１５は、実施例１に係るＯＭＰの故障被疑フラグテーブル更新後における故障被疑フラグの設定例を示す図である。 図１６は、実施例１に係る故障通知システムにより実行されるパッケージ交換後処理を説明するためのフローチャートである。 図１７は、実施例１に係るＯＭＰの故障被疑フラグテーブルにおけるパッケージ交換後の故障被疑フラグの設定例を示す図である。 図１８は、実施例１に係る被疑パッケージの交換後かつ比較後の故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図１９は、実施例１に係る故障通知システムにより実行される監視タイマ停止処理を説明するためのフローチャートである。 図２０は、実施例１に係るＯＭＰの故障被疑フラグテーブルクリア後の状態を示す図である。 図２１は、実施例１に係るＯＭＰの故障被疑フラグテーブルにおける監視タイマ起動前の故障被疑フラグの設定例を示す図である。 図２２は、実施例１に係る監視タイマ起動後の故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図２３は、実施例１に係るＯＭＰの故障被疑フラグテーブルにおける故障パッケージ交換後の故障被疑フラグの設定例を示す図である。 図２４は、実施例１に係るＯＭＰの故障被疑フラグテーブルの、監視タイムアウトに伴うクリア後の状態を示す図である。 図２５は、実施例２に係るＯＭＰの交換優先度テーブルの初期状態を示す図である。 図２６は、実施例２に係る故障通知システムにより実行される交換優先度表示処理を説明するためのフローチャートである。 図２７は、実施例２に係るＯＭＰの交換優先度テーブルにおける故障被疑フラグ兼交換優先度の設定例を示す図である。 図２８は、実施例２に係る故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図２９は、実施例２に係る更新後の故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図３０は、実施例２に係るＯＭＰの交換優先度テーブル更新後における故障被疑フラグ兼交換優先度の設定例を示す図である。 図３１は、実施例２に係る故障通知システムにより実行されるパッケージ交換後処理を説明するためのフローチャートである。 図３２は、実施例２に係るＯＭＰの交換優先度テーブルにおけるパッケージ交換後の故障被疑フラグ兼交換優先度の設定例を示す図である。 図３３は、実施例２に係るＯＭＰの交換優先度テーブルにおける更新後の故障被疑フラグ兼交換優先度の設定例を示す図である。 図３４は、実施例２に係る被疑パッケージの交換後かつ優先度加算後の故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図３５は、実施例２に係るＯＭＰの交換優先度テーブルにおける２回目のパッケージ交換後の故障被疑フラグ兼交換優先度の設定例を示す図である。 図３６は、実施例２に係る故障通知システムにより実行される監視タイマ停止処理を説明するためのフローチャートである。 図３７は、実施例２に係るＯＭＰの交換優先度テーブルクリア後の状態を示す図である。 図３８は、実施例３に係るＯＭＰの故障被疑フラグテーブルの初期状態を示す図である。 図３９は、実施例３に係る故障通知システムにより実行される交換優先度表示処理を説明するためのフローチャートである。 図４０は、実施例３に係るＯＭＰの１つ目の故障被疑フラグテーブルにおける故障被疑フラグの設定例を示す図である。 図４１は、実施例３に係る１つ目の故障被疑フラグテーブル生成後の故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図４２は、実施例３に係るＯＭＰの２つ目の故障被疑フラグテーブルにおける故障被疑フラグの設定例を示す図である。 図４３は、実施例３に係る２つ目の故障被疑フラグテーブル生成後の故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図４４は、実施例３に係る故障通知システムにより実行されるパッケージ交換後処理を説明するためのフローチャートである。 図４５は、実施例３に係る故障通知システムにより実行される監視タイマ停止処理を説明するためのフローチャートである。 図４６は、実施例４に係るＯＭＰの交換優先度テーブルの初期状態を示す図である。 図４７は、実施例４に係る故障通知システムにより実行される交換優先度表示処理を説明するためのフローチャートである。 図４８は、実施例４に係るＯＭＰの交換優先度テーブルにおける故障被疑フラグ兼交換優先度の設定例を示す図である。 図４９は、実施例４に係る故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図５０は、実施例４に係るＯＭＰの交換優先度テーブル更新後における故障被疑フラグ兼交換優先度の設定例を示す図である。 図５１は、実施例４に係る更新後の故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図５２は、実施例４に係るＯＭＰの交換優先度テーブルにおけるパッケージ交換後の故障被疑フラグ兼交換優先度の設定例を示す図である。 図５３は、実施例４に係るＯＭＰの交換優先度テーブルにおける更新後の故障被疑フラグ兼交換優先度の設定例を示す図である。 図５４は、実施例４に係る予防交換インジケータの付された故障被疑パッケージリストにおける被疑パッケージの表示例を示す図である。 図５５は、故障通知プログラムを実行するコンピュータを示す図である。

以下に、本願の開示する故障通知装置、故障通知方法、及び故障通知プログラムの実施例を、図面を参照しながら詳細に説明する。なお、この実施例により、本願の開示する故障通知装置、故障通知方法、及び故障通知プログラムが限定されるものではない。

まず、本願の開示する一実施例に係る故障通知システムの構成を説明する。図１は、交換機１の構成を示す図である。図１に示す様に、本実施例に係る交換機１は、制御装置２ａ、２ｂと回線装置３ａ、３ｂとを有する。交換機１は、０系の制御装置２ａ及び回線装置３ａと１系の制御装置２ｂ及び回線装置３ｂとの２系統の装置構成を有する。また、回線装置３ａ、３ｂは、それぞれ二重化されることで、他の外部装置と接続される。回線装置３ａ、３ｂは、各々の装置の接続する制御装置２ａ、２ｂからの指示に従い、交換機１と外部装置との間の回線を接続する。

図２は、交換機１の制御装置２ａ、２ｂの構成を示す図である。図２に示す様に、制御装置２ａ、２ｂは、デュプレックス構成により二重化されており、各制御装置２ａ、２ｂ間は、ＢＸＣ（Bus eXchange Controller）６０ａ、６０ｂにより、系間交差バスＢ１を介して接続されている。０系の制御装置２ａは、ＰＲＯＣ（PROCessor）２０、３０と、ＢＸＣ６０ａと、回線ＩＦ（Inter Face）７０ａと、ＨＤＵ（Hard Disk Unit）８１ａ、８２ａ、８３ａ、８４ａとを有する。ＰＲＯＣ２０、３０は、プロセッサパッケージであり、ＢＸＣ６０ａは、プロセッサバス交差制御パッケージである。また、回線ＩＦ７０ａは、交換機１の外部装置と接続するための回線インタフェースであり、ＨＤＵ８１ａ〜８４ａは、ハードディスクを収容するユニットである。これら各構成部分は、一方向又は双方向に、各種信号やデータの入出力が可能な様に接続されている。

１系の制御装置２ｂは、制御装置２ａと同様の構成を有する。ＢＸＣ６０ａ及びＢＸＣ６０ｂと、ＰＲＯＣ２０、３０及びＰＲＯＣ４０、５０とはそれぞれ、システムバスＢ２、Ｂ３を介して、接続されている。また、ＰＲＯＣ２０及びＰＲＯＣ３０と、ＨＤＵ８１ａ、８２ａ及びＨＤＵ８３ａ、８４ａとはそれぞれ、ＳＣＳＩ（Small Computer System Interface）バス等のＩＯ（Input Output）バスＢ４、Ｂ５を介して、接続されている。同様に、ＰＲＯＣ４０及びＰＲＯＣ５０と、ＨＤＵ８１ｂ、８２ｂ及びＨＤＵ８３ｂ、８４ｂとはそれぞれ、ＩＯ（Input Output）バスＢ６、Ｂ７を介して、接続されている。そして、上記各構成部分の内、ＢＸＣ６０ａ、６０ｂと、ＰＲＯＣ２０、３０、４０、５０と、ＨＤＵ８１ａ〜８４ａ、８１ｂ〜８４ｂとが、交換機１における交換単位となる。

図３は、故障通知システム１００の構成を示す図である。図３に示す様に、故障通知システム１００は、ＯＭＰ（Operation & Maintenance Processor）１０と、ＰＲＯＣ２０、３０、４０、５０とを有する。ＯＭＰ１０と各ＰＲＯＣ２０、３０、４０、５０とは、ハブやＬ（Layer）２スイッチを有する保守用ＬＡＮ（Local Area Network）等のネットワークＮを経由して、接続されている。詳細については後述するが、ＯＭＰ１０は、各ＰＲＯＣ２０、３０、４０、５０の障害状況を監視する。各ＰＲＯＣ２０、３０、４０、５０は、保守用ＬＡＮインタフェースを備えており、自パッケージ内に故障を検出すると、ネットワークＮを介して、ＯＭＰ１０にメッセージを送信することにより、故障を通知する。

図４は、ＯＭＰ１０の機能構成を示す図である。図４に示す様に、ＯＭＰ１０は、メッセージ受信部１１とメッセージ送信部１２とアクセス経路特定部１３と診断制御部１４と被疑パッケージ判定部１５と表示制御部１６とアクセス経路テーブル１７と故障被疑テーブル１８と監視タイマ１９とを有する。これら各構成部分は、一方向又は双方向に、各種信号やデータの入出力が可能な様に接続されている。

メッセージ受信部１１は、ネットワークＮから各種メッセージを受信する。メッセージ送信部１２は、ネットワークＮに対し、各種メッセージを送信する。アクセス経路特定部１３は、アクセス経路テーブル１７を参照し、受信された故障発生メッセージの送信元と送信先との情報に基づき、該メッセージの通信経路上にあるパッケージを特定する。診断制御部１４は、アクセス経路特定部１３により特定された経路上にあるパッケージに対する診断の実行を、上記各ＰＲＯＣ２０〜５０に指示する。

被疑パッケージ判定部１５は、アクセス経路特定部１３により特定された経路上のパッケージに対する診断結果に基づき、パッケージに発生した故障が「間欠故障」であるか否かを判定する。また、被疑パッケージ判定部１５は、故障被疑テーブル１８を参照して、上記パッケージの交換優先度を判定すると共に、該判定結果に従い、故障被疑テーブル１８の更新を行う。被疑パッケージ判定部１５は、故障被疑テーブル１８の更新を契機として、監視タイマ１９を起動した後、監視タイマ１９のタイムアウトに伴い、故障被疑テーブル１８をクリアすると共に、監視タイマ１９を停止（リセット）する。更に、被疑パッケージ判定部１５は、故障の発生したパッケージが保守管理者により交換された時、交換されたパッケージの情報のみを故障被疑テーブル１８からクリアする。

表示制御部１６は、上記被疑パッケージ、上記診断結果、及び上記交換優先度をディスプレイに表示させることで、交換等の対応を要するパッケージを保守管理者に通知する。アクセス経路テーブル１７は、メッセージがアクセス元からアクセス先に到達するまでに通過するパッケージの情報を更新可能に記録したテーブルである。故障被疑テーブル１８は、パッケージの実装位置毎に故障被疑フラグが更新可能に設定された後述する故障被疑フラグテーブル１８１と、パッケージの実装位置毎に交換優先度が更新可能に設定された後述する交換優先度テーブル１８２とを有する。監視タイマ１９は、故障被疑テーブル１８が最終更新されてからの経過時間を計測する。

図５は、ＰＲＯＣ２０の機能構成を示す図である。図５に示す様に、ＰＲＯＣ２０は、メッセージ受信制御部２１とメッセージ送信制御部２２とアクセス制御部２３と診断制御部２４と自律診断実行部２５とアンサ監視タイマ２６と回線制御部２７とを有する。これら各構成部分は、一方向又は双方向に、各種信号やデータの入出力が可能な様に接続されている。

メッセージ受信制御部２１は、ネットワークＮからの各種メッセージの受信を制御する。メッセージ送信制御部２２は、ネットワークＮに対する各種メッセージの送信を制御する。アクセス制御部２３は、システムバスＢ２またはＩＯバスＢ４へ、オーダ（例えば、自律診断の指示）を出力すると共に、該オーダに対するアンサ（例えば、診断結果）を入力する。また、アクセス制御部２３は、オーダ出力時にアンサ監視タイマ２６を起動し、アンサ入力時にアンサ監視タイマ２６を停止（リセット）する。更に、アクセス制御部２３は、アンサ監視タイマ２６のタイムアウト発生に伴い、上記故障発生メッセージをＯＭＰ１０宛に送出する。

診断制御部２４は、ＯＭＰ１０から自ＰＲＯＣ２０への診断起動メッセージを入力した場合、自律診断実行部２５に対し、自律診断の実行を指示する。また、診断制御部２４は、自律診断実行部２５から入力された診断結果を、メッセージ送信制御部２２経由でＯＭＰ１０へ返信する。一方、診断制御部２４は、ＯＭＰ１０から他のパッケージ（例えば、ＢＸＣ６０ａ、６０ｂ、ＰＲＯＣ３０、４０、５０、ＨＤＵ８１ａ〜８４ａ、８１ｂ〜８４ｂ）への診断起動メッセージを入力した場合、アクセス制御部２３を介して、上記他のパッケージ宛にオーダを出力する。また、診断制御部２４は、上記他のパッケージからのアンサを入力した場合、該アンサ（例えば、診断結果）をＯＭＰ１０宛に転送する。

自律診断実行部２５は、ＰＲＯＣ２０の自律診断を実行し、自パッケージにおける故障発生の有無を判定する。アンサ監視タイマ２６は、上記オーダの出力時点から、該オーダに対するアンサの入力時点までの経過時間を計測し、所定時間を超えた場合には、アクセス制御部２３に対し、アンサタイムアウトの発生を通知する。回線制御部２７は、アクセス制御部２３を介して、制御装置２ａに接続された回線装置３ａを制御する。

以上、ＰＲＯＣ２０の構成を代表的に説明したが、他のＰＲＯＣ３０、４０、５０の構成は、ＰＲＯＣ２０の構成と同様である。従って、共通する構成要素には、末尾が同一の参照符号を用いると共に、その図示及び詳細な説明は省略する。

続いて、ＯＭＰ１０のハードウェア構成を説明する。図６は、ＯＭＰ１０のハードウェア構成を示す図である。図６に示す様に、ＯＭＰ１０においては、ハードウェア的には、プロセッサ１０ｂとメモリ１０ｃとＨＤＤ（Hard Disk Drive）１０ｄとＮＩＣ（Network Interface Card）１０ｅとディスプレイ１０ｆとが、スイッチ１０ａを介して、各種信号やデータの入出力が可能な様に接続されている。プロセッサ１０ｂは、例えば、ＣＰＵ（Central Processing Unit）やＤＳＰ（Digital Signal Processor）等である。メモリ１０ｃは、例えば、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory)、フラッシュメモリ等である。ディスプレイ１０ｆは、例えば、ＬＣＤ（Liquid Crystal Display）、有機ＥＬ（Electro-Luminescence）ディスプレイ等の表示装置である。

ＯＭＰ１０の機能構成とハードウェア構成との対応関係につき、メッセージ受信部１１とメッセージ送信部１２とは、例えば、ＮＩＣ１０ｅ及びプロセッサ１０ｂにより実現される。また、アクセス経路特定部１３と診断制御部１４と被疑パッケージ判定部１５と監視タイマ１９とは、例えば、プロセッサ１０ｂ及びメモリ１０ｃにより実現される。表示制御部１６は、例えば、プロセッサ１０ｂ及びディスプレイ１０ｆにより実現される。また、アクセス経路テーブル１７と故障被疑テーブル１８とは、例えば、ＨＤＤ１０ｄ及びメモリ１０ｃにより実現される。

図７は、故障発生メッセージＭ１の構成例を示す図である。故障発生メッセージＭ１は、何れかのパッケージの故障発生時に、異なるパッケージ間で送受信されるメッセージであり、例えば、イーサフレームのペイロード部分に含まれる。図７に示す様に、故障発生メッセージＭ１は、故障が発生したアクセスのアクセス元のパッケージの識別子（例えば、ＰＲＯＣ２０）を「アクセス元」として格納する領域と、該アクセスのアクセス先のパッケージの識別子（例えば、ＨＤＵ８１ｂ）を「アクセス先」として格納する領域とを有する。故障発生メッセージＭ１は、他のデータ格納領域として、「アクセス種別」領域と「故障種別」領域とを有する。

図８Ａは、故障発生メッセージＭ１に設定されるアクセス種別Ａ１の一例を示す図である。図８Ａに示す様に、アクセス種別は、故障が発生したアクセスの種別（例えば、“ＨＤＵへのライトアクセス”）であり、該種別を示すコード（例えば、“１Ａ”）と対応付けて設定される。なお、アクセス種別コードは、ＯＭＰ１０及び各ＰＲＯＣ２０、３０、４０、５０において保持されている。

次に、図８Ｂは、故障発生メッセージＭ１に設定される故障種別Ａ２の一例を示す図である。図８Ｂに示す様に、故障種別は、発生した故障の内容（例えば、“エラーアンサ受信”）であり、該内容を示すコード（例えば、“２Ａ”）と対応付けて設定される。なお、故障種別コードは、ＯＭＰ１０及び各ＰＲＯＣ２０、３０、４０、５０において保持されている。

次に、実施例１に係る故障通知システム１００の動作を説明する。動作説明の前提として、ＯＭＰ１０の故障被疑フラグテーブル１８１の初期状態について説明する。図９は、実施例１に係るＯＭＰ１０の故障被疑フラグテーブル１８１の初期状態を示す図である。図９に示す様に、故障被疑フラグテーブル１８１ａには、故障被疑の有無を示す「故障被疑フラグ」が、パッケージ毎に設定されている。故障被疑フラグは、故障被疑が無い場合には“−”に設定され、故障被疑が有る場合には“×”に設定される。通常、初期状態においては、故障通知システム１００には、故障被疑のあるパッケージは存在しないため、図９では、全てのパッケージに対応する「故障被疑フラグ」に、故障被疑無しを表す“−”が設定されている。なお、図９の「パッケージ」は、必ずしもパッケージ自体の識別情報でなくてもよく、例えば、各パッケージの実装される位置（ボード差込み位置）の識別情報であってもよい。

図１０は、実施例１に係る故障通知システム１００により実行される交換優先度表示処理を説明するためのフローチャートである。

Ｓ１では、故障を検出したＰＲＯＣが、故障発生メッセージＭ１をＯＭＰ１０へ送信する。以下、ＰＲＯＣ２０が、ＨＤＵ８１ｂに対してリードアクセスした際に故障を検出した場合を想定し、Ｓ１の処理について具体的に説明する。正常時（故障未発生時）には、まず、ＰＲＯＣ２０は、ＢＸＣ６０ａ、６０ｂ経由で、リードオーダを、ＰＲＯＣ４０へ出力する。該リードオーダが入力されたＰＲＯＣ４０は、ＨＤＵ８１ｂに対し、リードコマンドを出力する。次に、ＨＤＵ８１ｂは、該リードコマンドに対する応答として、リードデータを返信する。そして、リードデータの返信を受けたＰＲＯＣ４０は、ＢＸＣ６０ｂ、６０ａ経由で、リードアンサをＰＲＯＣ２０に出力する。ところが、ＰＲＯＣ２０からＨＤＵ８１ｂへの経路上のパッケージに故障が発生した場合、ＰＲＯＣ２０が、リードオーダを出力しても、リードアンサが返信されないことがある。ＰＲＯＣ２０は、オーダの出力からアンサの入力までの時間を計測しているため、所定時間（例えば、１秒〜１分程度）内に上記アンサが返信されない場合には、アンサタイムアウトとして、故障の発生をＯＭＰ１０に通知する。

Ｓ２では、ＯＭＰ１０のアクセス経路特定部１３は、Ｓ１でＰＲＯＣから送信された故障発生メッセージＭ１を基に、故障の発生したアクセス経路を特定する。すなわち、ＯＭＰ１０は、メッセージ受信部１１により、ＰＲＯＣ２０、３０、４０、５０の何れかから送信された上述の故障発生メッセージＭ１を受信すると、アクセス経路特定部１３により、アクセス経路を特定する。アクセス経路の特定は、アクセス経路特定部１３が、アクセス経路テーブル１７を参照することにより行う。図１１は、アクセス経路テーブル１７におけるデータ格納例を示す図である。図１１に示す様に、アクセス経路テーブル１７には、アクセス経路上のパッケージが、「アクセス経路」として、「アクセス元」のパッケージ及び「アクセス先」のパッケージと対応付けて格納されている。従って、アクセス経路特定部１３は、アクセス経路テーブル１７の参照により、受信された故障発生メッセージＭ１に含まれるアクセス元とアクセス先との情報から、故障の発生が検知されたアクセス経路を特定することができる。

例えば、故障発生メッセージＭ１内に、「アクセス元」として“ＰＲＯＣ２０”が「アクセス先」として“ＨＤＵ８１ｂ”がそれぞれ含まれている場合を想定する。この場合、ＰＲＯＣ２０を始点とし、ＢＸＣ６０ａ、ＢＸＣ６０ｂ、ＰＲＯＣ４０を順次経由した後、ＨＤＵ８１ｂを終点とする経路（図２参照）が特定される。同様に、「アクセス元」“ＰＲＯＣ３０”と「アクセス先」“ＨＤＵ８３ｂ”とが故障発生メッセージＭ１に含まれる場合、ＰＲＯＣ３０を始点とし、ＢＸＣ６０ａ、ＢＸＣ６０ｂ、ＰＲＯＣ５０を順次経由した後、ＨＤＵ８４ｂを終点とする経路が特定される。更に、「アクセス元」として“ＰＲＯＣ４０”、「アクセス先」として“ＨＤＵ８２ｂ”が故障発生メッセージＭ１に含まれる場合、ＰＲＯＣ４０からＨＤＵ８２ｂに直接到達する経路が特定される。

本実施例では、上述した様に、ＰＲＯＣ２０からＨＤＵ８１ｂへのリードアクセスにてアンサタイムアウトが発生した場合を想定していることから、ＯＭＰ１０の被疑パッケージ判定部１５は、ＰＲＯＣ２０からＨＤＵ８１ｂへのアクセス経路上に故障発生パッケージが存在すると推定する。そして、被疑パッケージ判定部１５は、上記アクセス経路上のパッケージを、故障の発生した可能性のあるパッケージ（被疑パッケージ）として特定する（Ｓ３）。このとき、ＯＭＰ１０は、表示制御部１６により、上記被疑パッケージのリストをディスプレイ１０ｆに表示させてもよい（Ｄ１）。図１２は、実施例１に係る故障被疑パッケージリストＬ１における被疑パッケージの表示例を示す図である。図１２に示す様に、故障被疑パッケージリストＬ１には、今回のアンサタイムアウトで故障発生が疑われるパッケージとして、“ＰＲＯＣ２０”、“ＢＸＣ６０ａ”、“ＢＸＣ６０ｂ”、“ＰＲＯＣ４０”、“ＨＤＵ８１ｂ”が掲載される。

Ｓ４では、ＯＭＰ１０の診断制御部１４は、故障種別（例えば、固定故障、間欠故障）の判定の前提処理として、Ｓ３で特定された被疑パッケージの診断を行う。診断は、各被疑パッケージにおける固定故障の有無を判定することにより行われる。具体的には、診断制御部１４は、Ｓ２で特定されたアクセス経路上の各被疑パッケージ（ＰＲＯＣ２０、ＢＸＣ６０ａ、ＢＸＣ６０ｂ、ＰＲＯＣ４０、ＨＤＵ８１ｂ）に自律診断を実行させる。このとき、ＯＭＰ１０は、各被疑パッケージから得られた自律診断結果を、表示制御部１６により、ディスプレイ１０ｆに表示させてもよい（Ｄ２）。

自律診断処理について、より具体的に説明する。故障通知システム１００内の各パッケージは、自律診断機能を有する。各ＰＲＯＣ２０、３０、４０、５０は、ＯＭＰ１０からの指示に従い、自ＰＲＯＣの自律診断を実行後、診断結果をＯＭＰ１０に通知する。従って、ＯＭＰ１０は、各ＰＲＯＣ２０、３０、４０、５０に対して自律診断を指示することで、診断結果を得ることができる。また、ＰＲＯＣ以外のパッケージであるＢＸＣ６０ａ、６０ｂ、ＨＤＵ８１ａ〜８４ａ、８１ｂ〜８４ｂは、各ＰＲＯＣ２０、３０、４０、５０からの指示に従い、自パッケージの自律診断を実行後、診断結果を各ＰＲＯＣに通知する。該通知を受けた各ＰＲＯＣ２０、３０、４０、５０は、ＯＭＰ１０に診断結果を転送する。従って、ＯＭＰ１０は、各ＰＲＯＣ２０、３０、４０、５０に対して、他のパッケージの自律診断を指示することで、ＢＸＣ６０ａ、６０ｂ、ＨＤＵ８１ａ〜８４ａ、８１ｂ〜８４ｂの診断結果を、ＰＲＯＣ経由で得ることができる。

上記自律診断の結果、上記アクセス経路上の少なくとも１つの被疑パッケージにおける診断結果がＮＧ（固定故障有り）である場合（Ｓ５；Ｙｅｓ）、被疑パッケージ判定部１５は、故障被疑フラグテーブル１８１内のデータをクリアする（Ｓ６）。なお、Ｓ６の処理が開始される時点で、故障被疑フラグテーブル１８１が初期状態にある場合（図９参照）には、Ｓ６の処理は省略される。

クリア後、被疑パッケージ判定部１５は、監視タイマ１９を停止する（Ｓ７）。

一方、Ｓ４における自律診断の結果、上記アクセス経路上の全ての被疑パッケージにおける診断結果がＯＫ（固定故障無し）である場合（Ｓ５；Ｎｏ）には、被疑パッケージ判定部１５は、発生した故障が「間欠故障」であると判定する。その後、被疑パッケージ判定部１５は、現時点で、故障被疑フラグテーブル１８１に故障被疑フラグの設定が有るか否かを判定する（Ｓ８）。

上記判定の結果、故障被疑フラグテーブル１８１に故障被疑フラグが設定されていない場合（Ｓ８；Ｎｏ）、被疑パッケージ判定部１５は、故障被疑フラグテーブル１８１上の被疑パッケージに対し、故障被疑フラグの設定を行う（Ｓ９）。図１３は、実施例１に係るＯＭＰ１０の故障被疑フラグテーブル１８１ｂにおける故障被疑フラグの設定例を示す図である。図１３に示す様に、間欠故障の発生に伴い、Ｓ３で被疑パッケージと特定されたパッケージ（ＰＲＯＣ２０、ＢＸＣ６０ａ、ＢＸＣ６０ｂ、ＰＲＯＣ４０、ＨＤＵ８１ｂ）に対応する故障被疑フラグは、初期状態の“−”から“×”に更新される。

テーブル更新後、被疑パッケージ判定部１５は、監視タイマ１９を起動する（Ｓ１０）。

故障種別は間欠故障（診断結果ＯＫ）であるため、保守管理者は、現時点では、被疑パッケージの中から、実際に故障が発生したパッケージを特定することができない。従って、保守管理者は、パッケージの交換を行うことなく、経過を監視する。

しかしながら、依然、故障要因のパッケージは交換されていないため、別のリードアクセスにおいてもアンサタイムアウトが発生する。本実施例では、その後、ＰＲＯＣ３０からＨＤＵ８４ｂへのアクセスにてアンサタイムアウトが発生した場合を想定する。このため、ＯＭＰ１０の被疑パッケージ判定部１５は、アクセス経路テーブル１７を参照することで、ＰＲＯＣ３０からＨＤＵ８４ｂへのアクセス経路上に故障発生パッケージが存在すると推定する。続いて、被疑パッケージ判定部１５は、上記アクセス経路上の被疑パッケージ（ＰＲＯＣ３０、ＢＸＣ６０ａ、ＢＸＣ６０ｂ、ＰＲＯＣ５０、ＨＤＵ８４ｂ）と、故障被疑フラグテーブル１８１に現在フラグ“×”が設定されている被疑パッケージ（図１３参照）とを比較する。そして、被疑パッケージ判定部１５は、双方の被疑パッケージに共通する被疑パッケージ、換言すれば、一致する被疑パッケージ（ＢＸＣ６０ａ、ＢＸＣ６０ｂ）を特定する（Ｓ１１）。

Ｄ３では、ＯＭＰ１０は、表示制御部１６により、上記アクセス経路上の被疑パッケージの一覧をディスプレイ１０ｆに表示させる。図１４は、実施例１に係る被疑パッケージ比較後の故障被疑パッケージリストＬ２における被疑パッケージの表示例を示す図である。図１４に示す様に、故障被疑パッケージリストＬ２には、今回のアンサタイムアウトで故障発生が疑われるパッケージとして、“ＰＲＯＣ３０”、“ＢＸＣ６０ａ”、“ＢＸＣ６０ｂ”、“ＰＲＯＣ５０”、“ＨＤＵ８４ｂ”が掲載される。併せて、上記一致する被疑パッケージであるＢＸＣ６０ａ、ＢＸＣ６０ｂが、●により強調表示される。故障被疑パッケージリストＬ２の●は、交換優先度の高いパッケージであることを示す。これにより、保守管理者は、故障の可能性のあるパッケージの中から、特に故障の可能性が高く交換すべきパッケージを、簡易かつ迅速に把握することができる。

Ｓ１２では、被疑パッケージ判定部１５は、Ｓ１１における比較の結果特定された被疑パッケージにのみ、故障被疑フラグを設定することで、故障被疑フラグテーブル１８１を更新する。図１５は、実施例１に係るＯＭＰ１０の故障被疑フラグテーブル１８１更新後における故障被疑フラグの設定例を示す図である。図１５に示す様に、故障被疑フラグテーブル１８１ｃは、上記Ｓ１１の処理結果が反映されたフラグ設定となっている。すなわち、上記Ｓ１１の処理により、被疑パッケージは、２つのパッケージ（ＢＸＣ６０ａ、ＢＸＣ６０ｂ）に絞り込まれたため、故障被疑フラグが従前まで設定されていた被疑パッケージ（図１３参照）の内、該２つのパッケージ以外のパッケージ（ＰＲＯＣ２０、４０、ＨＤＵ８１ｂ）のフラグは解除されている。

テーブル更新後、被疑パッケージ判定部１５は、監視タイマ１９を再び起動する（Ｓ１３）。

その後、保守管理者は、交換優先度の高いＢＸＣ６０ａ、６０ｂの内、実際には間欠故障していないＢＸＣ６０ｂを交換したとする。なお、この時点では、保守管理者は、間欠故障の発生したパッケージが、ＢＸＣ６０ａ、６０ｂの内の何れのパッケージであるかを知らないため、交換すべきパッケージを正確に特定することはできない。従って、本実施例では、説明の便宜上、保守管理者が、間欠故障の発生していないパッケージであるＢＸＣ６０ｂの交換を実施したものとする。

図１６は、実施例１に係る故障通知システム１００により実行されるパッケージ交換後処理を説明するためのフローチャートである。Ｓ２１では、保守管理者は、ＢＸＣ６０ｂの交換後、キーボードやマウス等の入力装置により、交換済パッケージ（本実施例では“ＢＸＣ６０ｂ”）の情報を入力する。ＯＭＰ１０の被疑パッケージ判定部１５は、該入力により、パッケージが交換されたことを検知すると、故障被疑フラグテーブル１８１を再び更新する。具体的には、被疑パッケージ判定部１５は、保守管理者により指定されたＢＸＣ６０ｂの故障被疑フラグをクリアする（Ｓ２２）。

図１７は、実施例１に係るＯＭＰ１０の故障被疑フラグテーブル１８１ｄにおけるパッケージ交換後の故障被疑フラグの設定例を示す図である。図１７に示す様に、故障被疑フラグテーブル１８１ｄは、ＢＸＣ６０ｂの交換処理が反映されたフラグ設定となっている。すなわち、従前まで故障被疑フラグ“×”が設定されていたＢＸＣ６０ｂ（図１５参照）が、保守管理者によって交換されたため、該故障被疑フラグ“×”はクリアされ、“−”に更新されている。

しかしながら、依然として、本来交換すべきであった故障要因のパッケージ（ＢＸＣ６０ａ）が残存するため、交換後も、例えば、ＰＲＯＣ２０からＨＤＵ８１ｂへのリードアクセスにおいてアンサタイムアウトが発生する。この場合、ＯＭＰ１０の被疑パッケージ判定部１５は、アクセス経路テーブル１７を参照することで、ＰＲＯＣ２０からＨＤＵ８１ｂへのアクセス経路上に故障発生パッケージが存在するとの推定が可能である。そこで、被疑パッケージ判定部１５は、上述のＳ１１と同様に、上記アクセス経路上の被疑パッケージ（ＰＲＯＣ２０、ＢＸＣ６０ａ、ＢＸＣ６０ｂ、ＰＲＯＣ４０、ＨＤＵ８１ｂ）と、故障被疑フラグテーブル１８１に現在フラグ“×”が設定されている被疑パッケージ（図１７参照）とを比較する。そして、被疑パッケージ判定部１５は、互いに一致する被疑パッケージ（ＢＸＣ６０ａ）を特定する。

ＯＭＰ１０は、表示制御部１６により、上記アクセス経路上の被疑パッケージの一覧をディスプレイ１０ｆに表示させる。図１８は、実施例１に係る被疑パッケージの交換後かつ比較後の故障被疑パッケージリストＬ３における被疑パッケージの表示例を示す図である。図１８に示す様に、故障被疑パッケージリストＬ３には、今回のアンサタイムアウトで故障発生が疑われるパッケージとして、“ＰＲＯＣ２０”、“ＢＸＣ６０ａ”、“ＢＸＣ６０ｂ”、“ＰＲＯＣ４０”、“ＨＤＵ８１ｂ”が掲載される。併せて、上記互いに一致する被疑パッケージであるＢＸＣ６０ａが、交換優先度の高いパッケージとして、●により強調表示される。これにより、保守管理者は、故障の可能性のあるパッケージの中から、特に故障の可能性が高く交換を要するパッケージを、容易かつ適確に特定することができる。

保守管理者は、１つに特定されたパッケージ（ＢＸＣ６０ａ）を交換する。交換後は、保守管理者は、ＢＸＣ６０ｂの交換後と同様に、入力装置により、交換済パッケージ（本実施例では“ＢＸＣ６０ａ”）の情報を入力する（Ｓ２１）。ＯＭＰ１０の被疑パッケージ判定部１５は、該入力により、パッケージが交換されたことを検知すると、故障被疑フラグテーブル１８１を再び更新する。具体的には、被疑パッケージ判定部１５は、保守管理者により指定されたＢＸＣ６０ａの故障被疑フラグをクリアする（Ｓ２２）。

図１９は、実施例１に係る故障通知システム１００により実行される監視タイマ停止処理を説明するためのフローチャートである。Ｓ３１では、ＯＭＰ１０の被疑パッケージ判定部１５は、故障被疑フラグテーブル１８１をクリアする。図２０は、実施例１に係るＯＭＰ１０の故障被疑フラグテーブルクリア後の状態を示す図である。図２０に示す様に、故障発生パッケージが交換された結果、故障要因が消滅した場合には、故障被疑フラグテーブル１８１ｅは、初期状態（図９参照）に戻る。すなわち、従前まで故障被疑フラグ“×”が設定されていたＢＸＣ６０ａ（図１７参照）が、保守管理者によって交換されたため、該故障被疑フラグ“×”はクリアされ、“−”に更新される。その結果、故障被疑フラグテーブル１８１に設定されていた故障被疑フラグは全てクリアされる。

クリア後、被疑パッケージ判定部１５は、上述したＳ７（図１０参照）と同様に、監視タイマ１９を停止する（Ｓ３２）。

上述した様に、故障通知システム１００によれば、保守管理者は、故障被疑パッケージリストＬ３に表示された優先度に従い、被疑パッケージの交換を行うことで、早期に確実な復旧が可能となる。

ここで、ＯＭＰ１０の監視タイマ１９の用途について説明する。第１に、間欠故障は、所定の期間内に故障を繰り返すものであるが、ＯＭＰ１０が、故障発生パッケージを特定できない場合でも、ある被疑パッケージを交換することにより、所定時間（例えば、１日〜１週間程度）故障が発生しない場合がある。この様な場合、保守管理者は、交換されたパッケージに故障要因があったものと推定することができる。このため、監視タイマ１９が、交換に伴う故障被疑フラグテーブル１８１の更新後の経過時間を計測することで、故障発生パッケージの交換が完了したか否かの判断が可能となる。

第２に、パッケージ故障の中には、装置等のハードウェアの故障に限らず、外部要因によって発生する故障（以下、「ソフトエラー」と記す。）がある。例えば、α線によるメモリのビットエラー等がソフトエラーに該当する。ソフトエラーに起因するパッケージ故障は、ハードウェア故障と異なり、頻発するものではない。このため、パッケージ故障が検出された後、保守管理者が、パッケージ交換を行わなくても、所定時間（例えば、１日〜１週間程度）の間、パッケージ故障が再発しない場合には、ソフトエラーに起因した故障であると推定することができる。このため、監視タイマ１９が、パッケージ故障の検知に伴う故障被疑フラグテーブル１８１の更新後の経過時間を計測することで、故障発生パッケージの交換が必要であるか否かの判断が可能となる。

従って、故障被疑フラグテーブル１８１に設定された故障被疑フラグは、該テーブルの更新後、所定時間、故障発生が検知されない場合には、全てクリアされるものとしてもよい。

以下、図２１〜図２４を参照しながら、上述の監視タイムアウトに伴うテーブルクリア処理について、より詳細に説明する。本説明では、ＰＲＯＣ２０からＨＤＵ８１ｂへのリードアクセスにおいてアンサタイムアウトが発生した場合を想定するが、他の種別のアクセスであっても同様の処理が実行可能である。また、本説明では、ＨＤＵ８１ｂに間欠故障が発生したケースを想定する。

ＰＲＯＣ２０は、ＨＤＵ８１ｂに対するリードアクセスがアンサタイムアウトとなると、ＯＭＰ１０に対し、故障の発生を通知する。該通知を受けたＯＭＰ１０の被疑パッケージ判定部１５は、アクセス経路テーブル１７を参照することで、ＰＲＯＣ２０からＨＤＵ８１ｂへのアクセス経路上に故障発生パッケージが存在すると推定する。ＯＭＰ１０の被疑パッケージ判定部１５は、上記アクセス経路上の各パッケージに自律診断を実行させ、全てのパッケージにおける診断結果がＯＫの場合は、発生した故障を間欠故障と判定すると共に、各パッケージに故障被疑フラグを設定する。なお、診断結果がＮＧの場合は、被疑パッケージ判定部１５は、故障被疑フラグテーブル１８１をクリアする。

図２１は、実施例１に係るＯＭＰ１０の故障被疑フラグテーブル１８１ｆにおける監視タイマ起動前の故障被疑フラグの設定例を示す図である。図２１に示す様に、間欠故障の発生に伴い、被疑パッケージと特定されたパッケージ（ＰＲＯＣ２０、ＢＸＣ６０ａ、ＢＸＣ６０ｂ、ＰＲＯＣ４０、ＨＤＵ８１ｂ）に対応する故障被疑フラグは、初期状態の“−”から“×”に更新されている。

テーブル更新後、被疑パッケージ判定部１５は、監視タイマ１９を起動する。

このとき、ＯＭＰ１０は、表示制御部１６により、上記被疑パッケージのリストをディスプレイ１０ｆに表示させる。図２２は、実施例１に係る監視タイマ起動後の故障被疑パッケージリストＬ４における被疑パッケージの表示例を示す図である。図２２に示す様に、故障被疑パッケージリストＬ４には、上記リードアクセスのアンサタイムアウトで故障発生が疑われるパッケージとして、“ＰＲＯＣ２０”、“ＢＸＣ６０ａ”、“ＢＸＣ６０ｂ”、“ＰＲＯＣ４０”、“ＨＤＵ８１ｂ”が掲載される。

その後、保守管理者は、故障被疑パッケージリストＬ４を参照して、上記各パッケージの内、間欠故障しているＨＤＵ８１ｂを交換したとする。なお、この時点では、保守管理者は、間欠故障の発生したパッケージが何れのパッケージであるかを知らないため、交換すべきパッケージを正確に特定することはできない。しかしながら、説明の便宜上、保守管理者が、間欠故障の発生したパッケージであるＨＤＵ８１ｂの交換を実施したものとする。

保守管理者は、ＨＤＵ８１ｂの交換後、キーボードやマウス等の入力装置により、交換済パッケージ（本実施例では“ＨＤＵ８１ｂ”）の情報を入力する。ＯＭＰ１０の被疑パッケージ判定部１５は、該入力により、パッケージが交換されたことを検知すると、故障被疑フラグテーブル１８１を再び更新する。具体的には、被疑パッケージ判定部１５は、保守管理者により指定されたＨＤＵ８１ｂの故障被疑フラグをクリアする。

図２３は、実施例１に係るＯＭＰ１０の故障被疑フラグテーブル１８１ｇにおける故障パッケージ交換後の故障被疑フラグの設定例を示す図である。図２３に示す様に、故障被疑フラグテーブル１８１ｇは、ＨＤＵ８１ｂの交換処理が反映されたフラグ設定となっている。すなわち、従前まで故障被疑フラグ“×”が設定されていたＨＤＵ８１ｂ（図２１参照）が、保守管理者によって交換されたため、ＨＤＵ８１ｂの故障被疑フラグ“×”はクリアされ、“−”に更新されている。

故障被疑フラグテーブル１８１ｇには、故障被疑フラグ“×”が複数残存するが、これらのフラグに対応するパッケージは、実際には故障していない。すなわち、ＨＤＵ８１ｂの交換により、故障要因が除去されたため、ＰＲＯＣ２０からＨＤＵ８１ｂへのアクセス経路に、再び故障が発生することはない。

以降、故障は検出されないため、ＯＭＰ１０の被疑パッケージ判定部１５は、監視タイマ１９による計測時間が所定時間（例えば、１日〜１週間程度）に達したことを契機として、故障被疑フラグテーブル１８１に現在設定されている４つの故障被疑フラグ“×”を全てクリアする。

図２４は、実施例１に係るＯＭＰ１０の故障被疑フラグテーブルの、監視タイムアウトに伴うクリア後の状態を示す図である。図２４に示す様に、監視タイマ１９がタイムアウトとなった場合には、既に故障要因が消滅しているとの判断が可能であるため、故障被疑フラグテーブル１８１ｈは、初期状態（図９参照）に戻る。すなわち、故障要因の消滅に伴い、従前まで故障被疑フラグ“×”が設定されていたＰＲＯＣ２０、ＢＸＣ６０ａ、ＢＸＣ６０ｂ、ＰＲＯＣ４０（図２３参照）のフラグはクリアされ、“−”に更新される。その結果、故障被疑フラグテーブル１８１に設定されていた故障被疑フラグは全てクリアされる。

テーブルのクリア後、被疑パッケージ判定部１５は、監視タイマ１９を停止すると共に、故障被疑フラグテーブル１８１のクリアが完了したことを、表示制御部１６により保守管理者に通知する。

上述した様に、故障通知システム１００によれば、ＯＭＰ１０は、監視タイマ１９による計時の開始後、所定時間故障が再発しない場合に、故障被疑フラグテーブル１８１に設定されている全ての故障被疑フラグをクリアする。これにより、ＯＭＰ１０は、自動的に監視を解除することができる。従って、保守管理者は、交換が完了し、故障要因が消滅した場合に、故障発生パッケージの監視処理の継続を回避することができる。その結果、故障通知システム１００の効率的な運用が可能となる。

以上説明した様に、故障通知システム１００によれば、ＯＭＰ１０は、アクセス経路特定部１３と故障被疑テーブル１８と被疑パッケージ判定部１５と表示制御部１６とを有する。アクセス経路特定部１３は、保守交換単位であるパッケージ（例えば、部品）の故障発生時、複数のパッケージを含む経路の中から、故障が発生したパッケージを含む経路を特定する。故障被疑テーブル１８は、故障発生の疑われるパッケージを特定する情報を格納する。被疑パッケージ判定部１５は、上記複数のパッケージの内、故障被疑テーブル１８に格納された上記情報により特定されるパッケージ（例えば、前回の被疑パッケージとしてテーブルに事前に記憶されているパッケージ）と、アクセス経路特定部１３により特定された経路上のパッケージ（例えば、今回新たに検出された被疑パッケージ）とを比較する。そして、被疑パッケージ判定部１５は、該比較の結果、一致するパッケージを、故障が発生したパッケージと判定する。表示制御部１６は、被疑パッケージ判定部１５により故障が発生したと判定されたパッケージの交換優先度を、他のパッケージの交換優先度よりも高くして通知する。

本実施例に係る故障通知システム１００は、例えば、以下の効果を奏する。ＯＭＰ１０は、故障発生時に、交換優先度の高い被疑パッケージが識別可能な様に、被疑パッケージを表示する。従って、夜間緊急対応においても、保守管理者が、必要以上に広範囲にパッケージを交換してしまったり、既に交換済の被疑パッケージを再度交換してしまうことが未然に防止される。あるいは、反対に、保守管理者が、交換優先度の高い未交換の被疑パッケージを長時間放置してしまうことが予防される。その結果、システムの早期復旧が可能となる。更に、保守管理者は、交換優先度の表示を参考にして、交換等の保守作業を迅速に行うことができる。これにより、保守管理作業に掛かる時間が短縮される。その結果、故障通知システム１００のＭＴＴＲ（Mean Time To Repair）が低下し、システムの信頼性が向上すると共に、安定稼働が実現される。

次に、実施例２について説明する。実施例２に係る故障通知システムは、図３に示した実施例１に係る故障通知システムと同様の構成を有する。また、実施例２に係るＯＭＰの構成は、図４、図６に示した実施例１に係るＯＭＰの構成と同様である。更に、実施例２に係るＰＲＯＣの構成は、図５に示した実施例１に係るＰＲＯＣの構成と同様である。従って、実施例２では、実施例１と共通する構成要素には、同一の参照符号を用いると共に、その図示及び詳細な説明は省略する。

実施例２が実施例１と異なる点は、交換優先度を決定及び通知する方法である。具体的には、実施例１では、１つのパッケージでの故障発生を想定したことから、ＯＭＰ１０は、交換の必要性を示す●の有無（二値）によって、交換優先度を決定及び通知するものとした。これに対し、実施例２では、故障が複数箇所で発生した場合にも対応可能な様に、ＯＭＰ１０は、交換優先度を数値化することにより、多値の交換優先度を決定及び通知する。以下においては、この様な実施例２に係る故障通知システム１００の動作を、図２５〜図３７を参照しながら、実施例１との相違点を中心として説明する。

次に、実施例２に係る故障通知システム１００の動作を説明する。動作説明の前提として、ＯＭＰ１０の交換優先度テーブル１８２の初期状態について説明する。図２５は、実施例２に係るＯＭＰ１０の交換優先度テーブル１８２の初期状態を示す図である。図２５に示す様に、交換優先度テーブル１８２ａには、故障被疑の有無及び交換優先度を示す「故障被疑フラグ兼交換優先度」が、パッケージ毎に設定されている。故障被疑フラグ兼交換優先度は、故障被疑が無い場合には、初期値である“０”に設定され、故障被疑が有る場合には“１”〜“２５５”の数値に設定される。この数値が大きい程、交換優先度が高い、すなわち、交換の必要性の高いパッケージである。通常、初期状態においては、故障通知システム１００には、故障被疑のあるパッケージは存在しないため、図２５では、全てのパッケージに対応する「故障被疑フラグ兼交換優先度」に、故障被疑無しを表す“０”が設定されている。なお、図２５の「パッケージ」は、必ずしもパッケージ自体の識別情報でなくてもよく、例えば、各パッケージの実装される位置（ボード差込み位置）の識別情報であってもよい。

図２６は、実施例２に係る故障通知システム１００により実行される交換優先度表示処理を説明するためのフローチャートである。図２６は、Ｔ１２の処理を除き、実施例１に係る動作の説明において参照した図１０と同様の処理を含む。従って、共通するステップには、末尾が同一の参照符号を付すと共に、その詳細な説明は省略する。具体的には、図２６のステップＴ１〜Ｔ７、Ｔ１３の各処理は、図１０に示したステップＳ１〜Ｓ７、Ｓ１３の各処理にそれぞれ対応する。また、図３１のステップＴ２１、Ｔ２２、及び図３６のステップＴ３１、Ｔ３２の各処理は、図１６に示したステップＳ２１、Ｓ２２、及び図１９に示したＳ３１、Ｓ３２の各処理にそれぞれ対応する。更に、図２６のステップＥ１〜Ｅ３の各処理は、図１０に示したステップＤ１〜Ｄ３の各処理に対応する。

以下、ＢＸＣ６０ｂ及びＰＲＯＣ４０に間欠故障が発生した場合を例にとり、実施例２に係る故障通知システム１００により実行される交換優先度表示処理について、より詳細に説明する。

まず、ＢＸＣ６０ｂの間欠故障に起因して、ＰＲＯＣ２０からＨＤＵ８１ｂへのリードアクセスにアンサタイムアウトが発生すると、間欠故障を検出したＰＲＯＣ２０が、故障発生メッセージＭ１をＯＭＰ１０へ送信する（Ｔ１）。Ｔ２では、ＯＭＰ１０のアクセス経路特定部１３は、Ｔ１でＰＲＯＣ２０から送信された故障発生メッセージＭ１を基に、故障の発生したアクセス経路を特定する。

本実施例では、上述した様に、ＰＲＯＣ２０からＨＤＵ８１ｂへのリードアクセスにてアンサタイムアウトが発生した場合を想定していることから、ＯＭＰ１０の被疑パッケージ判定部１５は、ＰＲＯＣ２０からＨＤＵ８１ｂへのアクセス経路上に故障発生パッケージが存在すると推定する。そして、被疑パッケージ判定部１５は、上記アクセス経路上のパッケージを、故障の発生した可能性のあるパッケージ（被疑パッケージ）として特定する（Ｔ３）。

このとき、ＯＭＰ１０は、表示制御部１６により、上記被疑パッケージのリストをディスプレイ１０ｆに表示させてもよい（Ｅ１）。

Ｔ４では、ＯＭＰ１０の診断制御部１４は、故障種別（例えば、固定故障、間欠故障）の判定の前提処理として、Ｔ３で特定された被疑パッケージの診断を行う。このとき、ＯＭＰ１０は、各被疑パッケージから得られた自律診断結果を、表示制御部１６により、ディスプレイ１０ｆに表示させてもよい（Ｅ２）。

上記自律診断の結果、上記アクセス経路上の少なくとも１つの被疑パッケージにおける診断結果がＮＧ（固定故障有り）である場合（Ｔ５；Ｙｅｓ）、被疑パッケージ判定部１５は、交換優先度テーブル１８２内のデータをクリアする（Ｔ６）。なお、Ｔ６の処理が開始される時点で、交換優先度テーブル１８２が初期状態にある場合（図２５参照）には、Ｔ６の処理は省略される。

クリア後、被疑パッケージ判定部１５は、監視タイマ１９を停止する（Ｔ７）。

一方、Ｔ４における自律診断の結果、上記アクセス経路上の全ての被疑パッケージにおける診断結果がＯＫ（固定故障無し）である場合（Ｔ５；Ｎｏ）には、被疑パッケージ判定部１５は、交換優先度テーブル１８２上の被疑パッケージに対し、交換優先度を１加算する（Ｔ１２）。図２７は、実施例２に係るＯＭＰ１０の交換優先度テーブル１８２ｂにおける故障被疑フラグ兼交換優先度の設定例を示す図である。図２７に示す様に、間欠故障の発生に伴い、Ｔ３で被疑パッケージと特定されたパッケージ（ＰＲＯＣ２０、ＢＸＣ６０ａ、ＢＸＣ６０ｂ、ＰＲＯＣ４０、ＨＤＵ８１ｂ）に対応する故障被疑フラグ兼交換優先度は、初期状態の“０”から“１”に更新される。図２８は、実施例２に係る故障被疑パッケージリストＬ５における被疑パッケージの表示例を示す図である。図２８に示す様に、故障被疑パッケージリストＬ５には、今回のアンサタイムアウトで故障発生が疑われるパッケージが、交換優先度“１”を先頭に付された状態で掲載される。

テーブル更新後、被疑パッケージ判定部１５は、監視タイマ１９を起動する（Ｔ１３）。

本実施例で想定する２つの故障種別は何れも間欠故障（診断結果ＯＫ）であるため、保守管理者は、現時点では、被疑パッケージの中から、実際に故障が発生したパッケージを特定することができない。従って、保守管理者は、パッケージの交換を行うことなく、経過を監視する。

しかしながら、依然、故障要因のパッケージ（ＢＸＣ６０ｂ、ＰＲＯＣ４０）は交換されていないため、別のリードアクセスにおいてもアンサタイムアウトが発生する。本実施例では、その後、ＰＲＯＣ３０からＨＤＵ８４ｂへのアクセスにてアンサタイムアウトが発生したとする。この場合、ＯＭＰ１０の被疑パッケージ判定部１５は、アクセス経路テーブル１７を参照することで、ＰＲＯＣ３０からＨＤＵ８４ｂへのアクセス経路上に故障発生パッケージが存在すると推定する。続いて、被疑パッケージ判定部１５は、上記アクセス経路上のパッケージを被疑パッケージと特定し、該被疑パッケージの交換優先度に更に“１”を加算する。

Ｅ３では、ＯＭＰ１０は、表示制御部１６により、上記アクセス経路上の被疑パッケージの一覧をディスプレイ１０ｆに表示させる。図２９は、実施例２に係る更新後の故障被疑パッケージリストＬ６における被疑パッケージの表示例を示す図である。図２９に示す様に、故障被疑パッケージリストＬ６には、今回のアンサタイムアウトで故障発生が疑われるパッケージとして、“ＰＲＯＣ３０”、“ＢＸＣ６０ａ”、“ＢＸＣ６０ｂ”、“ＰＲＯＣ５０”、“ＨＤＵ８４ｂ”が掲載される。併せて、各被疑パッケージの交換優先度が、対応するパッケージの先頭部分に表示される。ＢＸＣ６０ａ、ＢＸＣ６０ｂに関しては、１回目のアクセスに続き、２回目の（今回の）アクセスにおいても、アンサタイムアウトが発生したアクセス経路上のパッケージである。このため、ＢＸＣ６０ａ、ＢＸＣ６０ｂには、他のパッケージよりも高い“２”の交換優先度が付されている。これにより、保守管理者は、故障の可能性のあるパッケージの中から、特に故障の可能性が高く交換すべきパッケージを、容易かつ正確に認識することができる。

図３０は、実施例２に係るＯＭＰ１０の交換優先度テーブル１８２更新後における故障被疑フラグ兼交換優先度の設定例を示す図である。図３０に示す様に、交換優先度テーブル１８２ｃは、上記Ｔ１２の処理結果が反映された優先度設定となっている。すなわち、上記Ｔ１２の処理により、アンサタイムアウトの発生した２つのアクセス経路に共通するパッケージ（ＢＸＣ６０ａ、ＢＸＣ６０ｂ）の交換優先度は“２”に設定され、１つのアクセス経路上のパッケージ（ＰＲＯＣ２０、３０、４０、５０、ＨＤＵ８１ｂ、８４ｂ）の交換優先度は“１”に設定される。そして、アンサタイムアウトの発生していないアクセス経路上のパッケージ（ＨＤＵ８１ａ〜８４ａ、８２ｂ、８３ｂ）の交換優先度は、初期値である“０”を維持する。

テーブル更新後、被疑パッケージ判定部１５は、監視タイマ１９を再び起動する。

その後、保守管理者は、交換優先度の高いＢＸＣ６０ａ、６０ｂの内、間欠故障の発生しているＢＸＣ６０ｂを交換したとする。なお、本実施例では、ＢＸＣ６０ｂ及びＰＲＯＣ４０に間欠故障が発生した場合を想定しているため、ＢＸＣ６０ｂが除外されてもなお、ＰＲＯＣ４０において間欠故障が継続する。

図３１は、実施例２に係る故障通知システム１００により実行されるパッケージ交換後処理を説明するためのフローチャートである。Ｔ２１では、保守管理者は、ＢＸＣ６０ｂの交換後、キーボードやマウス等の入力装置により、交換済パッケージ（本実施例では“ＢＸＣ６０ｂ”）の情報を入力する。ＯＭＰ１０の被疑パッケージ判定部１５は、該入力により、パッケージが交換されたことを検知すると、交換優先度テーブル１８２を再び更新する。具体的には、被疑パッケージ判定部１５は、保守管理者により指定されたＢＸＣ６０ｂの故障被疑フラグ兼交換優先度をクリアする（Ｔ２２）。

図３２は、実施例２に係るＯＭＰ１０の交換優先度テーブル１８２ｄにおけるパッケージ交換後の故障被疑フラグ兼交換優先度の設定例を示す図である。図３２に示す様に、交換優先度テーブル１８２ｄは、ＢＸＣ６０ｂの交換処理が反映されたフラグ設定となっている。すなわち、従前まで故障被疑フラグ兼交換優先度“２”が設定されていたＢＸＣ６０ｂ（図３０参照）が、保守管理者によって交換されたため、該交換優先度“２”はクリアされ、“０”に更新されている。

しかしながら、依然として、故障要因のパッケージ（ＰＲＯＣ４０）が残存するため、交換後も、例えば、ＰＲＯＣ４０からＨＤＵ８２ｂへのリードアクセスにおいてアンサタイムアウトが発生する。この場合、ＯＭＰ１０の被疑パッケージ判定部１５は、アクセス経路テーブル１７を参照することで、ＰＲＯＣ４０からＨＤＵ８２ｂへのアクセス経路上（ＰＲＯＣ４０、ＨＤＵ８２ｂの何れか）に故障発生パッケージが存在するとの推定が可能である。そこで、被疑パッケージ判定部１５は、上述のＴ１２と同様に、交換優先度テーブル１８２上の被疑パッケージに対し、交換優先度を１加算する。

図３３は、実施例２に係るＯＭＰ１０の交換優先度テーブル１８２ｂにおける更新後の故障被疑フラグ兼交換優先度の設定例を示す図である。図３３に示す様に、間欠故障の発生に伴い、Ｔ３で被疑パッケージと特定されたパッケージ（ＰＲＯＣ４０、ＨＤＵ８２ｂ）に対応する故障被疑フラグ兼交換優先度はそれぞれ、“１”、“０”から、“２”、“１”に更新される。

併せて、ＯＭＰ１０は、表示制御部１６により、上記アクセス経路上の被疑パッケージの一覧をディスプレイ１０ｆに表示させる。図３４は、実施例２に係る被疑パッケージの交換後かつ優先度加算後の故障被疑パッケージリストＬ７における被疑パッケージの表示例を示す図である。図３４に示す様に、故障被疑パッケージリストＬ７には、今回のアンサタイムアウトで故障発生が疑われるパッケージとして、“ＰＲＯＣ４０”、“ＨＤＵ８２ｂ”が掲載される。同時に、各パッケージの交換優先度を示す数値“２”、“１”が、対応するパッケージの先頭部分に並列表示される。これにより、保守管理者は、故障の可能性のあるパッケージの中から、特に故障の可能性が高く交換を要するパッケージを、容易かつ正確に特定することができる。

保守管理者は、故障被疑パッケージリストＬ７に掲載された被疑パッケージの内、交換優先度の高い方のパッケージ（ＰＲＯＣ４０）を交換する。交換後は、保守管理者は、ＢＸＣ６０ｂの交換後と同様に、入力装置により、交換済パッケージ（本実施例では“ＰＲＯＣ４０”）の情報を入力する（Ｔ２１）。ＯＭＰ１０の被疑パッケージ判定部１５は、該入力により、パッケージが交換されたことを検知すると、交換優先度テーブル１８２を再び更新する。具体的には、被疑パッケージ判定部１５は、保守管理者により指定されたＰＲＯＣ４０の故障被疑フラグ兼交換優先度をクリアする（Ｔ２２）。

図３５は、実施例２に係るＯＭＰ１０の交換優先度テーブル１８２ｆにおける２回目のパッケージ交換後の故障被疑フラグ兼交換優先度の設定例を示す図である。図３５に示す様に、交換優先度テーブル１８２ｆは、ＰＲＯＣ４０の交換処理が反映されたフラグ設定となっている。すなわち、従前まで故障被疑フラグ兼交換優先度“２”が設定されていたＰＲＯＣ４０（図３３参照）が、保守管理者によって交換されたため、該交換優先度“２”はクリアされ、“０”に更新されている。

２回目のパッケージ交換により、故障発生パッケージは全て取り除かれ、間欠故障の発生要因は消滅した。このため、ＯＭＰ１０は、監視タイマ１９のタイムアウトを契機として、監視タイマ停止処理を実行する。図３６は、実施例２に係る故障通知システム１００により実行される監視タイマ停止処理を説明するためのフローチャートである。Ｔ３１では、ＯＭＰ１０の被疑パッケージ判定部１５は、交換優先度テーブル１８２をクリアする。図３７は、実施例２に係るＯＭＰ１０の交換優先度テーブルクリア後の状態を示す図である。図３７に示す様に、故障発生パッケージが交換された結果、故障要因が消滅した場合には、交換優先度テーブル１８２ｇは、初期状態（図２５参照）に戻る。すなわち、従前まで故障被疑フラグ兼交換優先度“２”が設定されていたＰＲＯＣ４０（図３３参照）が、保守管理者によって交換されたことに伴い、全ての故障被疑フラグ兼交換優先度がクリアされ、“０”に更新される。

テーブルのクリア後、被疑パッケージ判定部１５は、上述したＴ７（図２６参照）と同様に、監視タイマ１９を停止する（Ｔ３２）と共に、交換優先度テーブル１８２のクリアが完了したことを、表示制御部１６により保守管理者に通知する。

上述した様に、故障通知システム１００によれば、ＯＭＰ１０の表示制御部１６は、被疑パッケージ判定部１５により故障が発生したと判定されたパッケージの交換優先度を、上記比較の結果が一致した回数に応じた数値を用いて通知する。これにより、ＯＭＰ１０は、間欠故障が複数のパッケージで発生した場合にも、交換を要するパッケージを精度良く特定し、その優先度と併せて保守管理者に提示することができる。また、保守管理者は、提示された交換優先度を参照し、より優先度の高い被疑パッケージの交換を行うことで、早い段階で確実にシステムを復旧させることが可能となる。

なお、実施例２に係る故障通知システム１００では、被疑パッケージの交換優先度の値は、１ずつ加算されるものとした。しかしながら、これに限らず、ＯＭＰ１０の被疑パッケージ判定部１５は、システム構成やアクセス頻度に応じて、加算される交換優先度の値に重み付けを行ってもよい。例えば、ＢＸＣ６０ａ、６０ｂは、系間（０系−１系）を接続するパッケージであることから、アクセス種別に拘らず、アクセス経路となる可能性が高い。このため、被疑パッケージ判定部１５は、ＢＸＣ６０ａ、６０ｂの交換優先度を、他のパッケージ（ＰＲＯＣやＨＤＵ）の交換優先度と同様にカウントしてしまうと、アクセスが多い分、ＢＸＣ６０ａ、６０ｂの交換優先度が突出して高くなってしまうことが懸念される。そこで、被疑パッケージ判定部１５は、かかる優先度の突出を抑制するため、ＢＸＣ６０ａ、６０ｂの交換優先度の増加分として、“１”ではなく“０．５”を加算するものとしてもよい。

また、例えば、ＨＤＵの多いシステム構成の場合には、被疑パッケージ判定部１５は、ＨＤＵの交換優先度の増加分を、通常の“１”から“２”に増加させるものとしてもよい。更に、例えば、被疑パッケージ判定部１５は、ＭＴＴＦ（Mean Time To Failure）の数値が所定の閾値よりも高いパッケージに対し、他のパッケージよりも高い重み付けを与えるものとしてもよい。なお、被疑パッケージ判定部１５は、重み付けの度合いを決定する際、アクセス回数や頻度等を考慮して正規化された値を用いてもよい。

次に、実施例３について説明する。実施例３に係る故障通知システムは、図３に示した実施例１に係る故障通知システムと同様の構成を有する。また、実施例３に係るＯＭＰの構成は、図４、図６に示した実施例１に係るＯＭＰの構成と同様である。更に、実施例３に係るＰＲＯＣの構成は、図５に示した実施例１に係るＰＲＯＣの構成と同様である。従って、実施例３では、実施例１と共通する構成要素には、同一の参照符号を用いると共に、その図示及び詳細な説明は省略する。

実施例３が実施例１と異なる点は、故障被疑フラグテーブルの構成である。具体的には、実施例１では、ＯＭＰ１０は、アクセス経路を問わず共通化された１つの故障被疑フラグテーブル１８１を用いるものとした。これに対し、実施例３では、相互に関連性の無い複数の故障が同時期に発生した場合にも対応可能な様に、ＯＭＰ１０は、複数の故障被疑フラグテーブル１８１−ｎ（ｎは自然数であり、例えば、１〜３２）を有する。また、これに合わせて、ＯＭＰ１０は、監視タイマ１９−ｎ（ｎは自然数であり、例えば、１〜３２）を有する。以下においては、この様な実施例３に係る故障通知システム１００の動作を、図３８〜図４５を参照しながら、実施例１との相違点を中心として説明する。

次に、実施例３に係る故障通知システム１００の動作を説明する。動作説明の前提として、ＯＭＰ１０の故障被疑フラグテーブル１８１の初期状態について説明する。図３８は、実施例３に係るＯＭＰ１０の故障被疑フラグテーブル１８１の初期状態を示す図である。図３８に示す様に、故障被疑フラグテーブル１８１−ｎには、故障被疑の有無を示す「故障被疑フラグ」が、パッケージ毎に設定されている。故障被疑フラグは、故障被疑が無い場合には“−”に設定され、故障被疑が有る場合には“×”に設定される。通常、初期状態においては、故障通知システム１００には、故障被疑のあるパッケージは存在しないため、図３８では、全てのパッケージに対応する「故障被疑フラグ」に、故障被疑無しを表す“−”が設定されている。なお、図３８の「パッケージ」は、必ずしもパッケージ自体の識別情報でなくてもよく、例えば、各パッケージの実装される位置（ボード差込み位置）の識別情報であってもよい。

図３９は、実施例３に係る故障通知システム１００により実行される交換優先度表示処理を説明するためのフローチャートである。図３９は、Ｕ９、Ｕ１０の処理を除き、実施例１に係る動作の説明において参照した図１０と同様である。従って、共通するステップには、末尾が同一の参照符号を付すと共に、その詳細な説明は省略する。具体的には、図３９のステップＵ１〜Ｕ１３の各処理は、図１０に示したステップＳ１〜Ｓ１３の各処理にそれぞれ対応する。また、図３９のステップＦ１〜Ｆ３の各処理は、図１０に示したステップＤ１〜Ｄ３の各処理に対応する。更に、図４４のステップＵ２１、Ｕ２２、及び図４５のステップＵ３１、Ｕ３２の各処理は、図１６に示したステップＳ２１、Ｓ２２、及び図１９に示したＳ３１、Ｓ３２の各処理にそれぞれ対応する。

以下、ＨＤＵ８１ｂ及びＨＤＵ８３ｂにおいて、関連しない間欠故障が同時期に発生した場合を例にとり、実施例３に係る故障通知システム１００により実行される交換優先度表示処理について、実施例１との相違点（Ｕ９、Ｕ１０）を中心に説明する。

最初に、ＨＤＵ８１ｂの間欠故障に起因して、ＰＲＯＣ４０からＨＤＵ８１ｂへのリードアクセスにアンサタイムアウトが発生する。ＯＭＰ１０のアクセス経路特定部１３は、ＰＲＯＣ４０からの故障発生メッセージＭ１により、ＰＲＯＣ４０、ＨＤＵ８１ｂ間における故障の発生を検知する。

Ｕ５における自律診断の結果、ＰＲＯＣ４０、ＨＤＵ８１ｂ間の経路上の全ての被疑パッケージ（ＰＲＯＣ４０、ＨＤＵ８１ｂ）における診断結果がＯＫ（固定故障無し）である場合（Ｕ５；Ｎｏ）には、被疑パッケージ判定部１５は、発生した故障が「間欠故障」であると判定する。その後、被疑パッケージ判定部１５は、現時点で、故障被疑フラグテーブル１８１−ｎに故障被疑フラグの設定が有るか否かを判定する（Ｕ８）。

上記判定の結果、故障被疑フラグテーブル１８１−ｎに故障被疑フラグが設定されていない場合（Ｕ８；Ｎｏ）、被疑パッケージ判定部１５は、故障被疑フラグテーブル１８１−ｎを、新規の故障被疑フラグテーブル１８１−１とする。被疑パッケージ判定部１５は、該新規の故障被疑フラグテーブル１８１−１上の被疑パッケージに対し、故障被疑フラグの設定を行う（Ｕ９）。図４０は、実施例３に係るＯＭＰ１０の１つ目の故障被疑フラグテーブル１８１−１における故障被疑フラグの設定例を示す図である。図４０に示す様に、間欠故障の発生に伴い、Ｕ３で被疑パッケージと特定されたパッケージ（ＰＲＯＣ４０、ＨＤＵ８１ｂ）に対応する故障被疑フラグは、初期状態の“−”から“×”に更新される。

テーブル更新後、被疑パッケージ判定部１５は、該新規の故障被疑フラグテーブル１８１−１用の監視タイマ１９−１を起動する（Ｕ１０）。併せて、ＯＭＰ１０は、表示制御部１６により、ＰＲＯＣ４０、ＨＤＵ８１ｂ間のアクセス経路上の被疑パッケージの一覧をディスプレイ１０ｆに表示させる。図４１は、実施例３に係る１つ目の故障被疑フラグテーブル１８１−１生成後の故障被疑パッケージリストＬ８における被疑パッケージの表示例を示す図である。図４１に示す様に、故障被疑パッケージリストＬ８には、今回のアンサタイムアウトで故障発生が疑われるパッケージとして、“ＰＲＯＣ４０”、“ＨＤＵ８１ｂ”が掲載される。

その後、ＨＤＵ８１ｂの間欠故障とは別に、ＨＤＵ８３ｂの間欠故障に起因して、ＰＲＯＣ５０からＨＤＵ８３ｂへのリードアクセスに新たなアンサタイムアウトが発生したとする。ＯＭＰ１０のアクセス経路特定部１３は、ＰＲＯＣ５０からの故障発生メッセージＭ１により、ＰＲＯＣ５０、ＨＤＵ８３ｂ間における故障の発生を検知する。この場合、ＯＭＰ１０は、別のアクセス経路（ＰＲＯＣ５０−ＨＤＵ８３ｂ）に関し、上記アクセス経路（ＰＲＯＣ４０−ＨＤＵ８１ｂ）に関する処理と同様の処理を実行する。

具体的には、まず、被疑パッケージ判定部１５は、今回間欠故障が発生したアクセス経路上のパッケージと、現時点で故障被疑フラグテーブル１８１−１に故障被疑フラグが設定されているパッケージとを比較し、双方の被疑パッケージの一致を確認する。本実施例では、前者のパッケージは、上述の様に、ＰＲＯＣ５０、ＨＤＵ８３ｂであるのに対し、後者のパッケージは、ＰＲＯＣ４０、ＨＤＵ８１ｂ（図４０参照）である。すなわち、双方の被疑パッケージが一致しない場合に該当する。

従って、被疑パッケージ判定部１５は、前回とは異なるパッケージで間欠故障が発生したものと推測し、故障被疑フラグテーブル１８１−１とは別に、新規の故障被疑フラグテーブル１８１−２を生成する。生成後、被疑パッケージ判定部１５は、該新規の故障被疑フラグテーブル１８１−２上の被疑パッケージに対し、故障被疑フラグの設定を行う（Ｕ９）。図４２は、実施例３に係るＯＭＰ１０の２つ目の故障被疑フラグテーブル１８１−２における故障被疑フラグの設定例を示す図である。図４２に示す様に、間欠故障の発生に伴い、被疑パッケージと特定されたパッケージ（ＰＲＯＣ５０、ＨＤＵ８３ｂ）に対応する故障被疑フラグは、初期状態の“−”から“×”に更新される。

テーブル更新後、被疑パッケージ判定部１５は、該新規の故障被疑フラグテーブル１８１−２用の監視タイマ１９−２を起動する（Ｕ１０）。併せて、ＯＭＰ１０は、表示制御部１６により、ＰＲＯＣ５０、ＨＤＵ８３ｂ間のアクセス経路上の被疑パッケージの一覧をディスプレイ１０ｆに表示させる。図４３は、実施例３に係る２つ目の故障被疑フラグテーブル１８１−２生成後の故障被疑パッケージリストＬ９における被疑パッケージの表示例を示す図である。図４３に示す様に、故障被疑パッケージリストＬ９には、今回のアンサタイムアウトで故障発生が疑われるパッケージとして、“ＰＲＯＣ５０”、“ＨＤＵ８３ｂ”が、掲載されることとなる。

図４４は、実施例３に係る故障通知システム１００により実行されるパッケージ交換後処理を説明するためのフローチャートである。実施例３に係るパッケージ交換後処理は、交換済パッケージの故障被疑フラグの解除対象となる故障被疑フラグテーブル１８１−ｎが複数存在する点を除き、実施例１に係るパッケージ交換後処理と同様である。従って、その詳細な説明は省略する。同様に、図４５は、実施例３に係る故障通知システム１００により実行される監視タイマ停止処理を説明するためのフローチャートである。実施例３に係る監視タイマ停止処理は、クリア対象となる故障被疑フラグテーブル１８１−ｎが複数存在する点を除き、実施例１に係る監視タイマ停止処理と同様である。従って、その詳細な説明は省略する。

ここで、故障被疑フラグテーブルは、共通部分を含まないアクセス経路毎に分けて生成される。例えば、ＰＲＯＣ５０、ＨＤＵ８３ｂ間のアクセス経路は、ＰＲＯＣ４０、ＨＤＵ８１ｂ間のアクセス経路との間に共通部分を含まない（アクセス経路が被らない）ため、それぞれのアクセス経路に対し、個別の故障被疑フラグテーブル１８１−１、１８１−２が生成される。一方、例えば、ＰＲＯＣ２０、ＨＤＵ８３ｂ間のアクセス経路と、ＰＲＯＣ３０、ＨＤＵ８１ｂ間のアクセス経路との双方の経路において、間欠故障が検出されたとする。この場合、ＰＲＯＣ２０、ＨＤＵ８３ｂ間の経路は、ＰＲＯＣ３０、ＨＤＵ８１ｂ間の経路との間に共通部分（ＢＸＣ６０ａ、ＢＸＣ６０ｂ）を含むため、各経路毎に個別の故障被疑フラグテーブルは生成されず、共通の故障被疑フラグテーブルが用いられることとなる。

上述した様に、故障通知システム１００によれば、ＯＭＰ１０は、共通部分を含まないアクセス経路毎に異なる故障被疑フラグテーブル１８１−１、１８１−２を生成し、保持する。換言すれば、ＯＭＰ１０は、被疑範囲毎にテーブルを分けて保持する。より具体的には、ＯＭＰ１０は、故障被疑テーブル１８を更に有する。ＯＭＰ１０の故障被疑テーブル１８は、上記故障発生の疑われる部品を特定する情報（例えば、図４０の“×”、図４２の“×”）を、上記経路毎に異なる領域に格納する。また、ＯＭＰ１０の被疑パッケージ判定部１５は、故障被疑テーブル１８に格納された上記情報により特定されるパッケージ（例えば、前回の被疑パッケージ）と、アクセス経路特定部１３により特定された経路上のパッケージ（例えば、今回の被疑パッケージ）とを上記経路毎に比較する。そして、被疑パッケージ判定部１５は、該比較の結果、一致するパッケージを、故障が発生したパッケージと判定する。更に、ＯＭＰ１０の表示制御部１６は、被疑パッケージ判定部１５により故障が発生したと判定されたパッケージの交換優先度を、他のパッケージの交換優先度よりも高くして上記経路毎に通知する。

これにより、ＯＭＰ１０は、関連性の無い複数の間欠故障が同時期に発生した場合でも、対応する複数の故障被疑フラグテーブルを選択し、並列的に参照することができる。従って、ＯＭＰ１０は、被疑範囲毎に交換優先度が異なる場合であっても、正確な交換優先度を、精度良く保守管理者に伝えることができる。また、ＯＭＰ１０は、複数箇所で同時発生した複数の間欠故障にも、容易かつ迅速に対応することができる。その結果、故障通知システム１００の汎用性が向上する。

（変形例１）
以上、実施例１に係るＯＭＰ１０が、独立したアクセス経路毎に複数の故障被疑フラグテーブルを有する態様について説明したが、かかる態様と同様に、実施例２に係るＯＭＰ１０が、アクセス経路毎に複数の交換優先度テーブルを有するものとしてもよい。変形例１に係る故障通知システム１００によれば、ＯＭＰ１０は、共通部分を含まないアクセス経路毎に異なる交換優先度テーブル１８２−１、１８２−２を生成し、保持する。換言すれば、ＯＭＰ１０は、被疑範囲毎にテーブルを分けて保持する。これにより、ＯＭＰ１０は、関連性の無い複数の間欠故障が同時期に発生した場合でも、対応する複数の交換優先度テーブルを選択し、並列的に参照することができる。従って、ＯＭＰ１０は、被疑範囲毎に交換優先度が異なる場合であっても、正確な優先度を保守管理者に伝えることができる。その結果、保守管理者は、該優先度を参照することで、故障の発生したパッケージを高精度に特定し、必要に応じて、交換することができる。また、ＯＭＰ１０は、複数箇所で同時発生した複数の間欠故障にも、容易かつ迅速に対応することができる。その結果、故障通知システム１００の汎用性が向上する。

次に、実施例４について説明する。実施例４に係る故障通知システムは、図３に示した実施例１に係る故障通知システムと同様の構成を有する。また、実施例４に係るＯＭＰの構成は、図４、図６に示した実施例１に係るＯＭＰの構成と同様である。更に、実施例４に係るＰＲＯＣの構成は、図５に示した実施例１に係るＰＲＯＣの構成と同様である。従って、実施例４では、実施例１と共通する構成要素には、同一の参照符号を用いると共に、その図示及び詳細な説明は省略する。

実施例４は、実施例２と類似する。実施例４が実施例２と異なる点は、交換優先度を通知する方法である。具体的には、実施例２では、ＯＭＰ１０は、各被疑パッケージの交換優先度を、数値により保守管理者に通知するものとした。これに対し、実施例４では、ＯＭＰ１０は、保守管理者に予防交換を促すことができる様に、上記数値に併せて、該数値が所定値以上の被疑パッケージにインジケータを付与する。以下においては、この様な実施例４に係る故障通知システム１００の動作を、図４６〜図５４を参照しながら、実施例２との相違点を中心として説明する。

次に、実施例４に係る故障通知システム１００の動作を説明する。動作説明の前提として、ＯＭＰ１０の交換優先度テーブル１８２の初期状態について説明する。図４６は、実施例４に係るＯＭＰ１０の交換優先度テーブル１８２の初期状態を示す図である。図４６に示す様に、交換優先度テーブル１８２ｈには、故障被疑の有無及び交換優先度を示す「故障被疑フラグ兼交換優先度」が、パッケージ毎に設定されている。故障被疑フラグ兼交換優先度は、故障被疑が無い場合には、初期値である“０”に設定され、故障被疑が有る場合には“１”〜“２５５”の数値に設定される。この数値が大きい程、交換優先度が高いパッケージであり、数値が所定の閾値（例えば、３）以上の場合は、予防交換が推奨される。通常、初期状態においては、故障通知システム１００には、故障被疑のあるパッケージは存在しないため、図４６では、全てのパッケージに対応する「故障被疑フラグ兼交換優先度」に、故障被疑無しを表す“０”が設定されている。なお、図４６の「パッケージ」は、必ずしもパッケージ自体の識別情報でなくてもよく、例えば、各パッケージの実装される位置（ボード差込み位置）の識別情報であってもよい。

図４７は、実施例４に係る故障通知システム１００により実行される交換優先度表示処理を説明するためのフローチャートである。図４７は、後述するＶ１４〜Ｖ１６及びＧ４の各処理を除き、実施例２に係る動作の説明において参照した図２６と同様の処理を含む。従って、共通するステップには、末尾が同一の参照符号を付すと共に、その詳細な説明は省略する。具体的には、図４７のステップＶ１２、Ｖ１３、Ｇ３の各処理は、図２６に示したステップＴ１２、Ｔ１３、Ｅ３の各処理にそれぞれ対応する。

以下、ＰＲＯＣ４０に間欠故障が発生した場合を例にとり、実施例４に係る故障通知システム１００により実行される交換優先度表示処理について、より詳細に説明する。

まず、ＰＲＯＣ４０の間欠故障に起因して、ＰＲＯＣ４０からＨＤＵ８１ｂへのリードアクセスに１回目のアンサタイムアウトが発生すると、故障を検出したＰＲＯＣ４０は、故障発生メッセージＭ１の送信により、故障の発生をＯＭＰ１０に通知する。ＯＭＰ１０の被疑パッケージ判定部１５は、故障発生メッセージＭ１を参照し、ＰＲＯＣ４０からＨＤＵ８１ｂへのアクセス経路上（ＰＲＯＣ４０、ＨＤＵ８１ｂの何れか）に故障発生パッケージが存在すると推定する。

Ｖ１２では、被疑パッケージ判定部１５は、交換優先度テーブル１８２上の被疑パッケージに対し、交換優先度を１加算する。図４８は、実施例４に係るＯＭＰ１０の交換優先度テーブル１８２ｉにおける故障被疑フラグ兼交換優先度の設定例を示す図である。図４８に示す様に、間欠故障の発生に伴い、被疑パッケージと特定されたパッケージ（ＰＲＯＣ４０、ＨＤＵ８１ｂ）に対応する故障被疑フラグ兼交換優先度は、初期状態の“０”から“１”に更新される。

テーブル更新後、被疑パッケージ判定部１５は、監視タイマ１９を起動する（Ｖ１３）。

図４９は、実施例４に係る故障被疑パッケージリストＬ１０における被疑パッケージの表示例を示す図である。図４９に示す様に、故障被疑パッケージリストＬ１０には、今回のアンサタイムアウトで故障発生が疑われるパッケージ（ＰＲＯＣ４０、ＨＤＵ８１ｂ）が、交換優先度“１”を先頭に付された状態で掲載される。

本実施例で想定する２つの故障種別は何れも間欠故障（診断結果ＯＫ）である。このため、保守管理者は、現時点では、２つの被疑パッケージの中から、実際に故障が発生したパッケージを特定することができない。従って、保守管理者は、パッケージの交換を行うことなく、故障経過を監視する。

依然、故障要因のパッケージ（ＰＲＯＣ４０）は交換されていないため、別のリードアクセスにおいてもアンサタイムアウトが発生する。本実施例では、その後、前回と同一のアクセスであるＰＲＯＣ４０からＨＤＵ８１ｂへのアクセスにて、アンサタイムアウトが再度発生したとする。この場合、ＯＭＰ１０の被疑パッケージ判定部１５は、アクセス経路テーブル１７を参照することで、ＰＲＯＣ４０からＨＤＵ８１ｂへのアクセス経路上に故障発生パッケージが存在すると推定する。続いて、被疑パッケージ判定部１５は、上記アクセス経路上のパッケージ（ＰＲＯＣ４０、ＨＤＵ８１ｂ）を被疑パッケージと特定し、該被疑パッケージの交換優先度に更に“１”を加算する。

図５０は、実施例４に係るＯＭＰ１０の交換優先度テーブル１８２更新後における故障被疑フラグ兼交換優先度の設定例を示す図である。図５０に示す様に、交換優先度テーブル１８２ｊは、上記Ｖ１２の処理結果が反映された優先度設定となっている。すなわち、上記Ｖ１２の処理により、アンサタイムアウトの発生した２つのアクセス経路に共通するパッケージ（ＰＲＯＣ４０、ＨＤＵ８１ｂ）の交換優先度は何れも“２”に設定される。一方、他のパッケージは何れも、アンサタイムアウトの発生していないアクセス経路上にあるため、ＰＲＯＣ４０、ＨＤＵ８１ｂ以外のパッケージの交換優先度は、更新されず、初期値である“０”のままである。

Ｖ１４では、被疑パッケージ判定部１５は、現時点で、交換優先度が“３”以上のパッケージが交換優先度テーブル１８２に存在するか否かを判定する。該判定の結果、交換優先度が“３”以上のパッケージが無い場合（Ｖ１４；Ｎｏ）、表示制御部１６は、交換優先度テーブル１８２に設定されている数値（例えば、“１”以上）を、対応するパッケージの識別子と共に、ディスプレイ１０ｆに表示させる（Ｖ１５、Ｇ３）。

図５１は、実施例４に係る更新後の故障被疑パッケージリストＬ１１における被疑パッケージの表示例を示す図である。図５１に示す様に、故障被疑パッケージリストＬ１１には、今回のアンサタイムアウトで故障発生が疑われるパッケージ（故障発生パッケージの候補）として、“ＰＲＯＣ４０”、“ＨＤＵ８１ｂ”が掲載される。併せて、各被疑パッケージの交換優先度が、対応するパッケージの先頭部分に表示される。本実施例では、ＰＲＯＣ４０、ＨＤＵ８１ｂの何れのパッケージも、１回目のアクセスに続き、２回目の（今回の）アクセスにおいてもアンサタイムアウトが発生したアクセス経路上のパッケージである。このため、ＰＲＯＣ４０、ＨＤＵ８１ｂには、“２”の交換優先度が付されている。

テーブル更新後、被疑パッケージ判定部１５は、監視タイマ１９を再び起動する（Ｖ１３）。

その後、保守管理者は、交換優先度の高いＰＲＯＣ４０、ＨＤＵ８１ｂの内、間欠故障の発生していないＨＤＵ８１ｂを交換したとする。本実施例では、上述した様に、ＰＲＯＣ４０に間欠故障が発生した場合を想定しているため、ＨＤＵ８１ｂが除外されてもなお、ＰＲＯＣ４０において、間欠故障が繰り返し発生する。

図５２は、実施例４に係るＯＭＰ１０の交換優先度テーブル１８２ｋにおけるパッケージ交換後の故障被疑フラグ兼交換優先度の設定例を示す図である。図５２に示す様に、交換優先度テーブル１８２ｋは、ＨＤＵ８１ｂの交換処理が反映されたフラグ設定となっている。すなわち、従前まで故障被疑フラグ兼交換優先度として“２”が設定されていたＨＤＵ８１ｂ（図５０参照）が、保守管理者によって交換されたため、該交換優先度“２”はクリアされ、更新後の数値である“０”が設定されている。

しかしながら、依然として、故障通知システム１００内には、故障要因のパッケージ（ＰＲＯＣ４０）が残存するため、交換後も、例えば、前回と同一のアクセスであるＰＲＯＣ４０からＨＤＵ８１ｂへのリードアクセスにおいてアンサタイムアウトが再発する。この場合、ＯＭＰ１０の被疑パッケージ判定部１５は、アクセス経路テーブル１７を参照することで、ＰＲＯＣ４０からＨＤＵ８１ｂへのアクセス経路上（ＰＲＯＣ４０、ＨＤＵ８１ｂの何れか）に故障発生パッケージが存在するとの推定が可能である。そこで、被疑パッケージ判定部１５は、上述のＶ１２と同様に、交換優先度テーブル１８２上の被疑パッケージに対し、交換優先度を更に１加算する。

図５３は、実施例４に係るＯＭＰ１０の交換優先度テーブル１８２ｌにおける更新後の故障被疑フラグ兼交換優先度の設定例を示す図である。図５３に示す様に、間欠故障の発生に伴い、被疑パッケージと特定されたパッケージ（ＰＲＯＣ４０、ＨＤＵ８１ｂ）に対応する故障被疑フラグ兼交換優先度はそれぞれ、“２”、“０”から、“３”、“１”に更新される。

上記Ｖ１４における判定の結果、交換優先度が“３”以上のパッケージが有る場合（Ｖ１４；Ｙｅｓ）、表示制御部１６は、交換優先度テーブル１８２に設定されている数値（例えば、“１”以上）を、対応するパッケージの識別子と共に、ディスプレイ１０ｆに表示させる（Ｖ１６、Ｇ４）。このとき、表示制御部１６は、交換優先度が“３”以上のパッケージに対し、予防交換を推奨するためのインジケータとして、例えば、“＃”等の記号を付与する。該記号を付与する位置は、保守管理者が、対応するパッケージを容易に視認可能な範囲内で任意であるが、例えば、パッケージの前の交換優先度の更に前である。

図５４は、実施例４に係る予防交換インジケータの付された故障被疑パッケージリストＬ１２における被疑パッケージの表示例を示す図である。図５４に示す様に、故障被疑パッケージリストＬ１２には、今回のアンサタイムアウトで故障発生が疑われるパッケージとして、“ＰＲＯＣ４０”、“ＨＤＵ８１ｂ”が掲載される。同時に、各パッケージの交換優先度を示す数値“３”、“１”が、対応するパッケージの前に並列表示される。更に、交換優先度が閾値“３”以上のパッケージ“ＰＲＯＣ４０”には、先頭部分に、交換を促すインジケータである“＃”が付されている。これにより、保守管理者は、故障の可能性のあるパッケージの中から、特に故障の可能性が高く予防交換の必要なパッケージを、一目で判別することができる。また、保守管理者は、上記インジケータに従い、運用中のシステムから、故障発生の要因となるパッケージを適確に排除することができる。

実施例４に係る故障通知システム１００によれば、ＯＭＰ１０の表示制御部１６は、上記数値に応じて異なる形態（例えば、図５４の“＃”）で、上記交換優先度を通知する。本実施例に係る故障通知システム１００は、発生頻度は低いが、特定のアクセス経路に間欠故障が繰り返し発生する場合に特に有効である。発生頻度の低い間欠故障の場合、保守管理者は、故障が発生しても直ぐにはパッケージの予防交換を行わずに再発の有無を監視し、故障が頻発した場合に初めて交換を行うという方法がある。かかる方法を採る場合、保守管理者は、過去の間欠故障の発生回数を記憶しておき、予防交換の要否を判断することとなる。しかしながら、例えば、夜間緊急時の対応等、時間的な余裕の無い場合には、保守管理者は、間欠故障の発生を漏れなく記憶し、発生回数に応じて、予防交換の要否を正確に判断することは困難である。そこで、実施例４に係る故障通知システム１００の様に、ＯＭＰ１０は、所定回数以上の間欠故障が発生した被疑パッケージについて、予防交換を促すアラームを上げることが好適である。

（故障通知プログラム）
上記各実施例で説明したＯＭＰ１０の各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーション等のコンピュータシステムで実行することによって実現することもできる。そこで、以下では、図５５を用いて、上記の各実施例で説明したＯＭＰ１０と同様の機能を有する故障通知プログラムを実行するコンピュータの一例について説明する。図５５は、故障通知プログラムを実行するコンピュータを示す図である。

図５５に示す様に、上記各実施例におけるコンピュータ２００は、ＣＰＵ（Central Processing Unit）２１０と、ＲＯＭ（Read Only Memory）２２０と、ＨＤＤ（Hard Disk Drive）２３０と、ＲＡＭ（Random Access Memory）２４０とを有する。これら２００〜２４０の各部は、バス２５０を介して接続される。

ＲＯＭ２２０には、上記各実施例で示したメッセージ受信部１１とメッセージ送信部１２とアクセス経路特定部１３と診断制御部１４と被疑パッケージ判定部１５と表示制御部１６とアクセス経路テーブル１７と故障被疑テーブル１８と監視タイマ１９と同様の機能を発揮する故障通知プログラムが予め記憶される。すなわち、ＲＯＭ２２０には、図５５に示す様に、故障通知プログラム２２０ａが記憶される。なお、故障通知プログラム２２０ａについては、適宜分離してもよい。そして、ＣＰＵ２１０が、故障通知プログラム２２０ａをＲＯＭ２２０から読み出して実行する。

ＨＤＤ２３０には、上述のアクセス経路テーブル２３０ａと故障被疑テーブル２３０ｂとが格納される。ＣＰＵ２１０は、アクセス経路テーブル２３０ａ及び故障被疑テーブル２３０ｂを読み出す。ＣＰＵ２１０は、これらをＲＡＭ２４０に記憶させる。ＣＰＵ２１０は、ＲＡＭ２４０に記憶されたアクセス経路テーブル２４０ａ及び故障被疑テーブル２４０ｂを用いて、故障通知プログラム２２０ａを実行する。また、ＣＰＵ２１０は、ＲＡＭ２４０に記憶されたアクセス経路テーブル２４０ａ及び故障被疑テーブル２４０ｂを用いて、故障通知プログラム２２０ａを実行する。なお、ＲＡＭ２４０に記憶される各データは、常に全てのデータがＲＡＭ２４０に記憶される必要はなく、処理に必要なデータのみがＲＡＭ２４０に一時記憶されればよい。

なお、故障通知プログラム２２０ａは、必ずしも最初からＨＤＤ２３０に記憶させておく必要はない。例えば、コンピュータ２００は、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の「可搬用の物理媒体」にプログラムを記憶させておく。そして、コンピュータ２００が、これらの媒体からプログラムを読み出して実行する様にしてもよい。更には、公衆回線、インターネット、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等を介して、コンピュータ２００に接続される「他のコンピュータ（またはサーバ）」等にプログラムを記憶させておくものとしてもよい。

なお、上記各実施例では、診断（故障検出）及び交換の対象となるパッケージとして、ＢＸＣ、ＰＲＯＣ、ＨＤＵを想定したが、パッケージはこれらの装置に限らない。上記パッケージは、例えば、メモリ、通信制御装置、表示装置、各種センサ、スピーカ等の構成部分であってもよい。

また、上記各実施例では、故障通知システム１００の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的態様は、図示のものに限らず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することもできる。例えば、ＯＭＰ１０に関し、アクセス経路特定部１３と被疑パッケージ判定部１５、あるいは、アクセス経路テーブル１７と故障被疑テーブル１８とをそれぞれ１つの構成要素として統合してもよい。また、ＰＲＯＣ２０に関し、アクセス制御部２３と回線制御部２７、あるいは、診断制御部２４と自律診断実行部２５とをそれぞれ１つの構成要素として統合してもよい。

反対に、ＯＭＰ１０の被疑パッケージ判定部１５に関し、故障種別及び交換優先度を判定する部分と、故障被疑テーブル１８を更新（クリアを含む）する部分と、監視タイマ１９を停止する部分とに分散してもよい。また、ＰＲＯＣ２０のアクセス制御部２３に関し、アンサ監視タイマ２６を停止する部分と、故障発生メッセージＭ１をＯＭＰ１０に送出する部分とに分散してもよい。更に、メモリ１０ｃ、ＨＤＤ１０ｄを、ＯＭＰ１０の外部装置として、ネットワークやケーブル経由で接続する様にしてもよい。

更に、上記説明では、個々の実施例毎に個別の構成、及び動作を説明した。しかしながら、各実施例に係る故障通知システムは、他の実施例や変形例に特有の構成要素を併せて有するものとしてもよい。また、実施例、変形例毎の組合せについても、２つに限らず、３つ以上の組合せ等、任意の形態を採ることが可能である。例えば、実施例４のアラーム機能を、実施例２に限らず、実施例３の変形例１や実施例１、３に適用してもよい。更に、１つの故障通知システムが、実施例１〜４及び変形例１において説明した全ての構成要素を併有するものとしてもよい。

１ 交換機
２ａ ０系の制御装置
２ｂ １系の制御装置
３ａ ０系の回線装置
３ｂ １系の回線装置
１０ ＯＭＰ
１０ａ スイッチ
１０ｂ プロセッサ
１０ｃ メモリ
１０ｄ ＨＤＤ（Hard Disk Drive）
１０ｅ ＮＩＣ（Network Interface Card）
１０ｆ ディスプレイ
１１ メッセージ受信部
１２ メッセージ送信部
１３ アクセス経路特定部
１４ 診断制御部
１５ 被疑パッケージ判定部
１６ 表示制御部
１７ アクセス経路テーブル
１８ 故障被疑テーブル
１９ 監視タイマ
２０、３０、４０、５０ ＰＲＯＣ（PROCessor）
２１、３１、４１、５１ メッセージ受信制御部
２２、３２、４２、５２ メッセージ送信制御部
２３、３３、４３、５３ アクセス制御部
２４、３４、４４、５４ 診断制御部
２５、３５、４５、５５ 自律診断実行部
２６、３６、４６、５６ アンサ監視タイマ
２７、３７、４７、５７ 回線制御部
６０ａ、６０ｂ ＢＸＣ（Bus eXchange Controller）
７０ａ、７０ｂ 回線ＩＦ（Inter Face）
８１ａ、８１ｂ、８２ａ、８２ｂ、８３ａ、８３ｂ、８４ａ、８４ｂ ＨＤＵ（Hard Disk Unit）
１００ 故障通知システム
１８１、１８１ａ、１８１ｂ、１８１ｃ、１８１ｄ、１８１ｅ、１８１ｆ、１８１ｇ、１８１ｈ、１８１−ｎ 故障被疑フラグテーブル
１８１−１、１８１−２ 新規の故障被疑フラグテーブル
１８２、１８２ａ、１８２ｂ、１８２ｃ、１８２ｄ、１８２ｅ、１８２ｆ、１８２ｇ、１８２ｈ、１８２ｉ、１８２ｊ、１８２ｋ、１８２ｌ 交換優先度テーブル
２００ コンピュータ
２１０ ＣＰＵ（Central Processing Unit）
２２０ ＲＯＭ（Read Only Memory）
２２０ａ 故障通知プログラム
２３０ ＨＤＤ（Hard Disk Drive）
２３０ａ アクセス経路テーブル
２３０ｂ 故障被疑テーブル
２４０ ＲＡＭ（Random Access Memory）
２４０ａ アクセス経路テーブル
２４０ｂ 故障被疑テーブル
２５０ バス
Ａ１ アクセス種別
Ａ２ 故障種別
Ｂ１ 系間交差バス
Ｂ２、Ｂ３ システムバス
Ｂ４、Ｂ５、Ｂ６、Ｂ７ ＩＯ（Input Output）バス
Ｌ１、Ｌ２、Ｌ３、Ｌ４、Ｌ５、Ｌ６、Ｌ７、Ｌ８、Ｌ９、Ｌ１０、Ｌ１１、Ｌ１２ 故障被疑パッケージリスト
Ｍ１ 故障発生メッセージ
Ｎ ネットワーク

Claims (6)

1. 交換単位であるパッケージの故障発生時、複数のパッケージを含む経路の中から、故障が発生したパッケージを含む経路を特定する特定部と、
   故障発生の疑われるパッケージを特定する情報を格納する格納部と、
   前記複数のパッケージの内、前記格納部に格納された前記情報により特定されるパッケージと、前記特定部により特定された経路上のパッケージとを比較し、該比較の結果、一致するパッケージを、故障が発生したパッケージと判定する判定部と、
   前記判定部により故障が発生したと判定されたパッケージの交換優先度を、他のパッケージの交換優先度よりも高くして通知する通知部と
   を有することを特徴とする故障通知装置。
2. 前記通知部は、前記判定部により故障が発生したと判定されたパッケージの交換優先度を、前記比較の結果が一致した回数に応じた数値を用いて通知することを特徴とする請求項１記載の故障通知装置。
3. 前記格納部は、前記故障発生の疑われるパッケージを特定する情報を、前記経路毎に異なる領域に格納し、
   前記判定部は、前記格納部に格納された前記情報により特定されるパッケージと、前記特定部により特定された経路上のパッケージとを前記経路毎に比較し、該比較の結果、一致するパッケージを、故障が発生したパッケージと判定し、
   前記通知部は、前記判定部により故障が発生したと判定されたパッケージの交換優先度を、他のパッケージの交換優先度よりも高くして前記経路毎に通知することを特徴とする請求項１記載の故障通知装置。
4. 前記通知部は、前記数値に応じて異なる形態で、前記交換優先度を通知することを特徴とする請求項２記載の故障通知装置。
5. 故障通知装置が、
   交換単位であるパッケージの故障発生時、複数のパッケージを含む経路の中から、故障が発生したパッケージを含む経路を特定し、
   前記複数のパッケージの内、故障発生の疑われるパッケージを特定する情報を格納する格納部に格納された前記情報により特定されるパッケージと、特定された経路上のパッケージとを比較し、該比較の結果、一致するパッケージを、故障が発生したパッケージと判定し、
   前記判定の結果、故障が発生したと判定されたパッケージの交換優先度を、他のパッケージの交換優先度よりも高くして通知する
   ことを特徴とする故障通知方法。
6. コンピュータに、
   交換単位であるパッケージの故障発生時、複数のパッケージを含む経路の中から、故障が発生したパッケージを含む経路を特定し、
   前記複数のパッケージの内、故障発生の疑われるパッケージを特定する情報を格納する格納部に格納された前記情報により特定されるパッケージと、特定された経路上のパッケージとを比較し、該比較の結果、一致するパッケージを、故障が発生したパッケージと判定し、
   前記判定の結果、故障が発生したと判定されたパッケージの交換優先度を、他のパッケージの交換優先度よりも高くして通知する
   処理を実行させることを特徴とする故障通知プログラム。

Images