JPWO2007099578A1 - 故障解析装置 - Google Patents

Abstract

論理回路の実装されるボード番号及びボード上搭載位置に対応付けて、その論理回路から収集するログ情報について、そのログ情報が発生するときに処理すべき情報と、そのログ情報が有効なものとなる条件の情報と、そのログ情報が無効なものとなる条件の情報とについて記述する解析情報を定義して、この解析情報を使って、論理回路を単位として故障解析を行うようにする。そして、この解析情報がさらにログ情報の優先度の情報を記述するようにすることで、この論理回路を単位とする故障解析の実現にあたって、重大な故障を漏れのない形で解析することを実現する。

Description

本発明は、複数の論理回路を搭載する複数のボードを具備する情報処理装置に実装されて、それらの論理回路にどのような故障が発生したのかを解析する故障解析装置に関し、特に、メモリ資源の削減、処理の高速化および開発工数の削減を実現するとともに、重大な故障を漏れなく解析することを実現し、さらに、解析不可能範囲を小さくすることを実現する故障解析装置に関する。

今日、高密度に集積化され複雑化したＡＳＩＣ（Application Specific Integrated Circuit ：特定用途向けＩＣ）などのようなＬＳＩを搭載する情報処理装置においては、停止時間や復旧時間の削減のために、ＬＳＩに故障が発生するときに、その正確な故障箇所を自律的に速やかに判定するとともに、その影響範囲を自律的に速やかに判定する故障解析機能の実現が強く求められている。

ＬＳＩの集積化が進むことで、ＬＳＩの故障解析に必要となる解析情報は増加の一途を辿っており、それらの大量の解析情報の入力作業が必要となっている。しかも、各ＬＳＩの設計者とＬＳＩを搭載するシステムの設計者とＬＳＩの故障解析を行うファームウェアの設計者との間に意思の疎通が避けられないことから、そのような故障解析機能を実現するためには膨大な開発工数が要求されることになる。

これから、そのような故障解析機能を効率的に実現するための新たな技術の構築が叫ばれている。

ＡＳＩＣを搭載する情報処理装置では、通常、複数種類の複数のＡＳＩＣを搭載するシステムボードを複数枚具備することになる。

これから、従来では、ＡＳＩＣに故障が発生する場合に、各システムボード用に用意する１枚又は数枚の解析用テーブルを用いてシステムボードを単位にして故障解析を行い、そのシステムボードを単位にして行った解析結果を集めて、システム全体としての解析結果を導出するようにしていた。

図１５に、従来技術の構成を図示する。

ここで、図１５中、１００は情報処理装置内に実装される解析対象となる複数のシステムボードを示し、１１０はボード解析情報テーブルを示し、１２０はシステム解析情報テーブルを示し、１３０は解析処理部を示す。

このシステムボード１００には、通常、複数種類の複数のＡＳＩＣが搭載されている。ボード解析情報テーブル１１０は、システムボード１００毎に定義されて、そのシステムボード１００に搭載されるＡＳＩＣに発生した故障の解析に必要となる情報を記憶する。システム解析情報テーブル１２０は、システムボード１００間の故障解析に必要となる情報を記憶する。解析処理部１３０は、システムボード１００毎の故障解析を行う解析処理機能と、システム全体の故障解析を行う解析処理機能とで構成される。

ここで、解析処理部１３０については、具体的には、情報処理装置に実装されるファームウェア（以下、監視ファームウェアと称することがある）により実現され、ボード解析情報テーブル１１０およびシステム解析情報テーブル１２０については、そのファームウェアの持つメモリ上に展開されることになる。

このように構成される従来技術では、システムボード１００を単位にしてＡＳＩＣのログ情報（後述するハード故障フラグ）を収集して、システムボード１００毎に定義されるボード解析情報テーブル１１０を使ってシステムボード１００についての故障解析を行うことで、そのシステムボード１００で発生した故障を特定する。

そして、このシステムボード１００についての故障解析を終了すると、続いて、システム解析情報テーブル１２０を使い、例えば、受信側で検出される故障は送信側で発生した故障に伴って発生することを考慮して、受信側で検出される故障については故障解析から除外するというようなシステム全体の故障解析を行うことで、最終的にどのような故障が発生したのかを特定する。

このようにして、従来技術では、ＡＳＩＣに故障が発生する場合に、先ず最初に、システムボード１００を単位にして故障解析を行い、続いて、そのシステムボード１００を単位にして行った解析結果を集めて、システム全体としての解析結果を導出するようにしていた。

この故障解析を行うときに必要となるボード解析情報テーブル１１０については、ＡＳＩＣの設計者やシステムボード１００の設計者が作成し、システム解析情報テーブル１２０については、システムの設計者やシステムボード１００の設計者が作成することになる。

すなわち、従来技術では、図１６に示すように、ボード解析情報テーブル１１０のコンパイル前のデータであるボード解析定義については、ＡＳＩＣの種類毎に、各ＡＳＩＣの設計者が独自に、あるいはシステムボード１００の設計者と協議しながら個別に作成する。そして、システムをとりまとめるシステム設計者が独自に、あるいはシステムボード１００の設計者と協議しながら、それらのボード解析定義を編集することで、システム解析情報テーブル１２０のコンパイル前のデータであるシステム解析定義を作成する。そして、このようにして作成したボード解析定義とシステム解析定義とを監視ファームウェアが取り込める形にコンパイルすることで、ボード解析情報テーブル１１０とシステム解析情報テーブル１２０とを作成するようにしていた。

解析処理部１３０は、このようにして作成されたボード解析情報テーブル１１０を使ってシステムボード１００についての故障解析を行うことになるが、この場合、図１７に示すように、ＡＳＩＣから収集するハード故障フラグ（ハード故障時に故障原因を残すハード内フラグ群）を、故障解析で確保する故障フラグバッファに格納していくことで、どのような故障が発生したのかを特定するという処理を行うことになる。

この処理を行う場合、従来の解析処理部１３０では、先行して検出されたハード故障フラグを故障フラグバッファに格納していって、故障フラグバッファが満杯になる場合には、それ以降に検出されたハード故障フラグについては破棄するようにして、故障フラグバッファにどのようなハード故障フラグが格納されているのかを抽出することにより、どのような故障が発生したのかを特定するようにしていた。

すなわち、従来の解析処理部１３０では、ハード故障フラグが大量に立った場合には、一定の検出個数をもって故障解析を中断して、そこまでの故障解析結果を報告するようにしていたのである。

また、解析処理部１３０は、図１６に示すような方法により作成されたボード解析情報テーブル１１０およびシステム解析情報テーブル１２０を使って故障解析を行うことになるが、従来の解析処理部１３０では、図１８に示すように、その故障解析がシステムに異常が発生した場合に実行する一時的な処理であるのにもかかわらず、その故障解析で使用する情報であるボード解析情報テーブル１１０およびシステム解析情報テーブル１２０については、システムの起動直後に監視ファームウェアのメモリに常駐させるようにしていた。

ここで、図１８中に示すメモリ空間は、監視ファームウェアのシステムメモリ空間を示し、図１８中に示す解析情報は、故障解析で使用する情報であるボード解析情報テーブル１１０およびシステム解析情報テーブル１２０を示し、図１８中に示す解析ワークは、監視ファームウェアが故障解析で用いる作業用メモリ域を示している。

以上に説明したように、従来技術では、ＡＳＩＣに故障が発生する場合に、先ず最初に、システムボード１００を単位にして故障解析を行い、続いて、そのシステムボード１００を単位にして行った解析結果を集めて、システム全体としての解析結果を導出するようにしていた。

このように、従来技術では、システムボード１００を単位にして故障解析を行っていることから、図１９に示すように、例えば、システムボード１００に搭載されるある一つのＡＳＩＣ（例えば、図中に示すＡＳＩＣ−Ｄ）からハード故障フラグを収集できないような事態が起こると、そのシステムボード１００についての故障解析全体が不可能となってしまうことになる。

このような従来技術に従っていると、次のような問題がある。

（１）メモリ資源、処理時間についての問題
システムボード１００を単位とする従来の故障解析方法に従っていると、故障解析を行うときに、システムボード１００にかかる全てのハード故障フラグを故障解析に用いる作業用メモリ域（図１８に示す解析ワーク）に書き込まなくてはならないことになる。

しかるに、システムボード１００内には数個から数十個のＡＳＩＣが搭載されるため、システムボード１００全体でのハード故障フラグ数は非常に多い。

これから、システムボード１００を単位とする従来の故障解析方法に従っていると、故障解析に要するメモリが大きくなるという問題がある。

しかも、システムボード１００内には同種のＡＳＩＣが搭載されることがあるが、システムボード１００を単位とする従来の故障解析方法に従っていると、ボード解析情報テーブル１１０はシステムボード１００を単位にして生成されることから、同じＡＳＩＣのボード解析情報テーブル１１０が冗長に含まれることになる。これも大きなメモリ資源を要求される原因となっている。

すなわち、同じＡＳＩＣであっても、その搭載位置に応じてボード解析情報テーブル１１０は異なるものとなるが、システムボード１００を単位とする従来の故障解析方法では、ボード解析情報テーブル１１０にＡＳＩＣの搭載位置に応じた解析定義を記述するという構成を採っていないので、これらのボード解析情報テーブル１１０を共通化することができない。これから、同じＡＳＩＣのボード解析情報テーブル１１０が冗長に含まれることになることで大きなメモリ資源を要求されていたのである。

しかも、システムボード１００を単位とする従来の故障解析方法に従っていると、図１８で説明したように、故障解析がシステムに故障が発生した場合に実行する一時的な処理であるのにもかかわらず、その故障解析で使用する情報であるボード解析情報テーブル１１０およびシステム解析情報テーブル１２０については、システムの起動直後に監視ファームウェアのメモリに常駐させるようにしていた。

このときに常駐させるボード解析情報テーブル１１０およびシステム解析情報テーブル１２０は、情報処理装置に搭載されるＡＳＩＣの種類や版数が予め分かっている場合には、それに応じた数で済むものの、予め分かっていない場合には、情報処理装置に搭載される可能性のあるものの全てを常駐させる必要があることから、その常駐に大きなメモリ量を要求されることになる。

この点からしても、システムボード１００を単位とする従来の故障解析方法に従っていると、大きなメモリ資源を要求されることになるという問題がある。

また、１つのＡＳＩＣ当たり数千から数万のハード故障フラグを搭載するため、システムボード１００全体では数十万個のハード故障フラグの解析となり、しかも、ボード解析情報テーブル１１０もシステムボード１００を単位にして持つことから、その検索に多大な計算量を要することになる。

これから、システムボード１００を単位とする従来の故障解析方法に従っていると、故障解析に膨大な処理時間を要するという問題がある。

（２）開発工数について
システムボード１００を単位とする従来の故障解析方法では、ボード解析情報テーブル１１０とシステム解析情報テーブル１２０という２つのテーブルを使って故障解析を行うことになるが、図１６で説明したように、ボード解析情報テーブル１１０については、ＡＳＩＣの設計者やシステムボード１００の設計者が作成し、システム解析情報テーブル１２０については、システムの設計者やシステムボード１００の設計者が作成することになる。

これから、システムボード１００を単位とする従来の故障解析方法に従っていると、これらのテーブル１１０，１２０の初期設計時や変更設計時に、それぞれに工数が発生して各設計者に負担を強いるという問題がある。

しかも、各設計者の間で解析情報の記述定義の認識に違いがでることが避けられず、これから、システムボード１００を単位とする従来の故障解析方法に従っていると、この認識の違いによる障害を発生するという問題もある。

（３）解析漏れについて
従来の故障解析方法では、図１７で説明したように、ハード故障フラグが大量に立った場合には、故障フラグバッファに格納できなくなることに合わせて、一定の検出個数をもって故障解析を中断するようにしていた。

これから、従来の故障解析方法に従っていると、故障フラグバッファが満杯になった後に検出される、より重大な故障を見逃してしまうという問題がある。

（４）解析不可能範囲について
システムボード１００を単位とする従来の故障解析方法では、図１９で説明したように、何らかの二次的な問題で、システムボード１００に搭載されるある一つのＡＳＩＣからでもハード故障フラグを収集できないような事態が起こると、そのシステムボード１００についての故障解析全体が不可能になってしまうという問題がある。

本発明はかかる事情に鑑みてなされたものであって、情報処理装置に搭載されるＬＳＩのような論理回路に発生する故障を解析するという機能を実現するときに、メモリ資源の削減、処理の高速化および開発工数の削減を実現するとともに、重大な故障を漏れなく解析することを実現し、さらに、解析不可能範囲を小さくすることを実現する新たな故障解析技術の提供を目的とする。

この目的を達成するために、本発明の故障解析装置は、複数の論理回路を搭載する複数のボードを具備する情報処理装置に実装されて、それらの論理回路にどのような故障が発生したのかを解析する処理を行うために、（１）論理回路の搭載されるボード番号及びボード上搭載位置に対応付けて、その論理回路から収集するログ情報について、そのログ情報が発生するときに処理すべき情報と、そのログ情報の優先度の情報と、そのログ情報が有効なものとなる条件の情報と、そのログ情報が無効なものとなる条件の情報とについて記述する解析情報を記憶する記憶手段と、（２）論理回路の故障発生時に、論理回路から故障発生を表示するログ情報を収集する収集手段と、（３）収集手段の収集したログ情報と、記憶手段に記憶される解析情報とに基づいて、論理回路にどのような故障が発生したのかを解析する解析手段とを備えるように構成する。

この構成を採るときに、さらに、（４）装置起動時に、解析対象となる情報処理装置に搭載される可能性のある論理回路に適用される解析情報の索引に用いられる索引情報を、記憶手段に記憶させる第１の展開手段と、（５）論理回路の故障発生時に、解析対象となる情報処理装置に搭載される論理回路の情報と索引情報とに従って、解析手段の解析に必要となる解析情報を特定して、その特定した解析情報を記憶手段に記憶させる第２の展開手段とを備えることがある。

そして、この構成を採るときに、記憶手段は、ログ情報が有効なものとなる条件の情報として、どのログ情報が故障発生を示す場合という条件の情報について記述することがあり、また、ログ情報が無効なものとなる条件の情報として、どのログ情報が故障発生を示す場合という条件の情報について記述することがある。

このように構成される本発明の故障解析装置では、装置起動時に、解析情報の索引に用いられる索引情報のみを記憶手段に記憶させる。

この後、情報処理装置が処理を開始するので、その処理の実行中に、ある論理回路に故障が発生すると、各論理回路から故障発生を表示するログ情報を収集する。

このとき、そのログ情報の収集に合わせて、情報処理装置でどのような論理回路が用いられているのかという情報を取得して、記憶手段に記憶される索引情報に従って、その取得した情報の指す論理回路に適用される解析情報を特定し、その特定した解析情報を記憶手段に記憶させる。

続いて、記憶手段の記憶する解析情報を参照することで、収集した故障発生を表示するログ情報の内、解析情報に記述される条件情報に基づいて有効となるものを抽出することで、論理回路にどのような故障が発生したのかを解析する。

このとき、解析情報に記述される優先度情報に基づいて、優先度の高いログ情報を抽出することで、重大な故障の解析漏れが起こらないようにする。

この抽出処理は、例えば、収集した故障発生を表示するログ情報の内、解析情報に記述される条件情報に基づいて有効となるログ情報を抽出すると、その抽出したログ情報の優先度が規定のメモリ容量を持つバッファに格納されるログ情報の優先度よりも高い場合には、そのバッファに格納される最も優先度の低いログ情報と入れ替える形でその抽出したログ情報を格納し、その抽出したログ情報の優先度がそのバッファに格納されるログ情報の優先度よりも低い場合には、その抽出したログ情報をバッファに格納しないようにすることで行うことが可能である。

このようにして、本発明の故障解析装置では、論理回路の搭載されるボード番号及びボード上搭載位置に対応付けて、その論理回路から収集するログ情報について、そのログ情報が発生するときに処理すべき情報と、そのログ情報が有効なものとなる条件の情報と、そのログ情報が無効なものとなる条件の情報とについて記述する解析情報を定義して、従来技術ではシステムボードを単位として行っていた故障解析を、この解析情報を使って、論理回路を単位として行うようにするという構成を採るのである。

そして、この解析情報がさらにログ情報の優先度の情報を記述するようにすることで、この論理回路を単位とする故障解析の実現にあたって、重大な故障を漏れのない形で解析するようにするという構成を採るのである。

本発明によれば、次のような効果を実現できるようになる。

（１）メモリ資源、処理時間についての効果
本発明では、論理回路を単位とする故障解析方法を用いるので、故障解析を行うべく故障発生を表示するログ情報を作業用メモリに書き込むときに、システムボードを単位とする従来の故障解析方法に比べて、大幅に少ない量のログ情報を書き込めば足りることになる。

このようにして、本発明によれば、システムボードを単位とする従来の故障解析方法に比べて、故障解析に要するメモリを大幅に削減できるようになる。

しかも、本発明では、論理回路の搭載されるボード番号及びボード上搭載位置に対応付ける形で故障解析に必要となる解析情報を定義して、そのような記載形式をとる解析情報を用いて故障解析を行うので、システムボードに同じ論理回路が搭載される場合に、それらの論理回路についての解析情報を共通化できるようになる。

この点からしても、本発明によれば、システムボードを単位とする従来の故障解析方法に比べて、故障解析に要するメモリを大幅に削減できるようになる。

しかも、本発明では、解析情報を記憶する記憶手段に対して解析情報を常駐させないようにして、故障発生時点に、記憶手段に対して必要な解析情報のみを展開するようにする。

この点からしても、本発明によれば、使用しない解析情報までも含める形で記憶手段に解析情報を常駐させるという従来の故障解析方法に比べて、故障解析に要するメモリを大幅に削減できるようになる。

そして、本発明では、論理回路を単位とする故障解析方法を用いるので、システムボードを単位とする従来の故障解析方法に比べて、大幅に少ない量のログ情報を解析すれば足りることになり、しかも、単一の論理回路に限定した解析情報の検索を行うことで足りることになる。

このようにして、本発明によれば、システムボードを単位とする従来の故障解析方法に比べて、故障解析に要する処理時間を大幅に削減できるようになる。

（２）開発工数について
本発明では、論理回路を単位とする故障解析方法を用いており、さらに、故障解析に用いる解析情報として、規定の内容について記述するものを用いるようにする。

これから、本発明によれば、論理回路の設計者の入力する解析情報の定義フォーマットを共通化できるようになるので、その入力作業を統合化でき、その入力作業をサポートするツールを用いることで、論理回路の設計者による一貫した解析情報の作成を実現できるようになり、開発工数を大幅に削減できるようになる。

しかも、本発明によれば、定義フォーマットによって、各設計者の間における解析情報の記述定義の認識の違いを小さくできるようになるので、この認識の違いによる障害の発生を防止できるようになる。

（３）解析漏れについて
本発明では、解析情報に定義された優先度の順番に従って、故障発生を表示するログ情報をチェックすることで故障解析を行うようにする。

これから、本発明によれば、より重大な故障を見逃してしまうというような不都合の発生を防止できるようになる。

（４）解析不可能範囲について
本発明では、論理回路を単位とする故障解析方法を用いるので、ログ情報の欠落による故障解析の不可能範囲が論理回路単位となる。

これから、本発明によれば、従来技術に比べて、故障解析の不可能範囲を大幅に小さくすることができるようになる。

このようにして、本発明によれば、情報処理装置に搭載されるＬＳＩのような論理回路に発生する故障を解析するという機能を実現するときに、メモリ資源の削減、処理の高速化および開発工数の削減を実現できるようになるとともに、重大な故障を漏れなく解析することを実現できるようになり、さらに、解析不可能範囲を小さくすることを実現できるようになる。

本発明の構成図である。 故障解析用ファームウェアの構成の一例を示す図である。 ＲＡＳ−ＤＢファイルのデータ構造の説明図である。 共通定義ブロックで定義される情報の一例を示す図である。 データ定義ブロックで定義される解析情報の一例を示す図である。 ＡＳＩＣを搭載するシステムボードの一例を示す図である。 解析情報の一例を示す図である。 解析情報の一例を示す図である。 解析情報の作成方法の説明図である。 本体ログ解析プロセスの実行する処理フローである。 本体ログ解析プロセスの実行する処理フローである。 本体ログ解析プロセスの実行する処理の説明図である。 本体ログ解析プロセスの実行する処理の説明図である。 本発明による故障解析不可能範囲の説明図である。 従来技術の説明図である。 従来技術の説明図である。 従来技術の説明図である。 従来技術の説明図である。 従来技術の説明図である。

符号の説明

１０ ＡＳＩＣ
１１ ＲＡＳ−ＤＢファイル
１２ 解析処理部
２０ 故障解析用ファームウェア
３０ 割込ハンドラ
３１ 本体ログプロセス
３２ 解析用ログファイル
３３ 詳細ログファイル
３４ 本体ログ解析プロセス
４０ バッファ
４１ 作業用メモリ
５０ ＲＡＳ−ＤＢ定義ファイル
５１ ＲＡＳ−ＤＢジェネレータ
６０ 宣言部
６１ 定義部
６２ データ定義ブロック
６３ 共通定義ブロック

以下、実施の形態に従って本発明を詳細に説明する。

本発明では、ＡＳＩＣを搭載する情報処理装置において、ＡＳＩＣに故障が発生する場合に、ＡＳＩＣを単位にして故障解析を行うことで、システム全体としての解析結果を導出するという処理を行い、これにより、従来のシステムボードを単位にして行っていた故障解析で必要とされていたシステム全体の故障解析を不要にすることを実現する。

図１に、この処理を行う本発明の構成を図示する。

ここで、図１中、１０は情報処理装置内に搭載される解析対象となるＮ個のＡＳＩＣを示し、１１はＲＡＳ−ＤＢファイルを示し、１２は解析処理部を示す。

ＲＡＳ(Reliability Availability Serviceability）−ＤＢファイル１１は、ＡＳＩＣ１０毎に定義されて、そのＡＳＩＣ１０に発生した故障の解析に必要となる解析情報を記憶するとともに、この解析情報に含める形で、システム全体の故障の解析に必要となる解析情報を記憶する。

解析処理部１２は、ＲＡＳ−ＤＢファイル１１に格納される解析情報を使って、ＡＳＩＣ１０に発生した故障を解析するとともに、その故障解析を行うことで、システム全体の故障解析を同時に実現する。

このように構成される本発明では、故障発生時に、Ｎ個のＡＳＩＣ１０からログ情報を収集し、解析処理部１２は、その収集したログ情報のそれぞれについて故障解析を行うように処理する。

このとき行う故障解析は、ＲＡＳ−ＤＢファイル１１に格納される解析情報に従って、ＡＳＩＣ１０内の故障解析にとどまらずに、システム全体の故障解析までも含めたものとなる。

このようにして、本発明では、ＲＡＳ−ＤＢファイル１１に格納される解析情報を使って、ＡＳＩＣ１０に発生した故障を解析するとともに、その故障解析を行うことで、システム全体の故障解析を同時に実現するのである。

この本発明に特徴的な故障解析を行う解析処理部１２は、具体的には、情報処理装置に実装されるファームウェアにより実現され、ＲＡＳ−ＤＢファイル１１については、そのファームウェアの備えるＲＯＭ上に記憶されることになる。

図２に、この故障解析処理を司る故障解析用ファームウェア２０の構成の一例を図示する。

ここで、図２中、図１で示したものと同じものについては同一の記号で示してある。ま、図２中に示す実線は処理の流れを示し、図２中に示す破線はデータの流れを示している。

図２に示すように、本発明の故障解析処理を司る故障解析用ファームウェア２０は、図１で説明したＲＡＳ−ＤＢファイル１１に加えて、割込ハンドラ３０と、本体ログプロセス３１と、解析用ログファイル３２と、詳細ログファイル３３と、本体ログ解析プロセス３４とを備える。

割込ハンドラ３０は、ＡＳＩＣ１０から故障が発生したことを示す割り込みを受信する。本体ログプロセス３１は、割込ハンドラ３０からの割込受信通知を受けて、ＡＳＩＣ１０からログ情報を読み出す。解析用ログファイル３２は、故障解析用ファームウェア２０の備えるＲＯＭ上に構成されて、本体ログプロセス３１の読み出したログ情報の内の故障解析に必要となるものを格納する。詳細ログファイル３３は、故障解析用ファームウェア２０の備えるＲＯＭ上に構成されて、本体ログプロセス３１の読み出したログ情報の内の故障解析に必要とならないものを格納する。本体ログ解析プロセス３４は、ＲＡＳ−ＤＢファイル１１に格納される解析情報を参照して、解析用ログファイル３２に格納されるログ情報について故障解析を行う。

ここで、本体ログ解析プロセス３４には、故障解析の結果となるログ情報を格納する規定の容量の大きさを持つバッファ４０と、故障解析の作業用に用意される作業用メモリ４１とが備えられることになる。

また、ＲＡＳ−ＤＢファイル１１に格納される解析情報については、ＲＡＳ−ＤＢ定義ファイル５０とＲＡＳ−ＤＢジェネレータ５１とが用意されて、ＡＳＩＣ１０の設計者の作成した解析定義がＲＡＳ−ＤＢ定義ファイル５０に格納されると、ＲＡＳ−ＤＢジェネレータ５１がその解析定義をコンパイルしてＲＡＳ−ＤＢファイル１１に格納することで、ＲＡＳ−ＤＢファイル１１に格納されることになる。

このように構成される故障解析用ファームウェア２０では、割込ハンドラ３０がＡＳＩＣ１０から故障発生の割り込みを受信すると、本体ログプロセス３１は、割込ハンドラ３０からの割込受信通知を受けて、ＡＳＩＣ１０からログ情報を読み出す。

続いて、本体ログプロセス３１は、ＡＳＩＣ１０から読み出したログ情報の内の故障解析に必要となるものを解析用ログファイル３２に格納し、故障解析に必要とならないものを詳細ログファイル３３に格納してから、本体ログ解析プロセス３４に対して故障解析を行うことを指示する。

この指示を受けて、本体ログ解析プロセス３４は、ＲＡＳ−ＤＢファイル１１に格納される解析情報を参照して、解析用ログファイル３２に格納されるログ情報について故障解析を行い、その解析結果を報告先に報告する。

次に、ＲＡＳ−ＤＢファイル１１に格納される解析情報について説明する。

図３に、ＲＡＳ−ＤＢファイル１１のデータ構造を図示する。

ＲＡＳ−ＤＢファイル１１は、図３に示すように、ファイル名などについて宣言する宣言部６０と、解析情報の具体的な内容について定義する定義部６１とで構成され、さらに、定義部６１は、解析情報の本体について定義するデータ定義ブロック６２と、データ定義ブロック６２の各項目で用いる共通の値について定義する共通定義ブロック６３とで構成される。

共通定義ブロック６３で定義した値については、データ定義ブロック６２の項目を省略した場合のデフォルト値として使用されることになる。これから、共通定義ブロック６３が用意されることで、解析情報を作成するＡＳＩＣ１０の設計者は、作成する解析情報で共通的に使用する情報については、その記載を省略することが可能になる。

図４に、共通定義ブロック６３で定義される情報の一例を図示する。

図４に示す共通定義ブロック６３では、ＡＳＩＣ１０の種別・版数（ASIC）、ＡＳＩＣ１０を搭載する情報処理装置のモデル種別（MODEL)、ＡＳＩＣ１０を搭載するシステムボードの番号（BORAD)、ＡＳＩＣ１０のシステムボード上の搭載位置（PLACE)、どのハード機能が有効かを示す機能モード（FUNCTION TYPE)、ＡＳＩＣスキャンループのＩＲコード（IR：ログの種類を示すもの）、ＡＳＩＣ間インタフェースの方向（DIRECTION)、ＱＵＩＥＴコード（QUIET)、エラー事象のレベル（LEVEL)、変換ルールの番号（CONVERT)、交換部品を示す故障マーク（MARK）のそれぞれについて定義可能であることを示している。

図５に、データ定義ブロック６２で定義される解析情報の一例を図示する。

データ定義ブロック６２では、ＡＳＩＣ種別、ＡＳＩＣ版数、モデル種別、機能モード、搭載ボード（bd）、搭載位置（pl）、ＩＲコード（ir）、スキャンアドレス（adrs）、ＲＣ／ＲＴ表示（rcrt）、優先度（pr）、エントリ抑止条件（dis)、エントリ許可条件（enb)、事象レベル（lvl)、メッセージ番号（msg)、アクション種別（action) 、変換ルール番号（conv）、故障マーク（mark）などの各項目について値を定義することで、ＡＳＩＣ１０の故障解析に用いる解析情報を定義するという構成を採る。

ここで、図５に示すデータ定義ブロック６２の例では、ＡＳＩＣ版数（ver)、ＡＳＩＣ１０を搭載する情報処理装置のモデル種別（mdl)、どのハード機能が有効かを示す機能モード（func）については共通定義ブロック６３で定義されていることで、データ定義ブロック６２ではその定義が省略されていることを想定している。

図５に示す第７番目の解析情報を具体例にして説明するならば、この第７番目の解析情報は、ＡＳＩＣ１０の種別が“ＳＣ”で、そのＡＳＩＣ１０を搭載する情報処理装置のモデル種別が“ＤＣ２”で、そのＡＳＩＣ１０を搭載するシステムボードの番号が“０００１”で、そのＡＳＩＣ１０のシステムボード上の搭載位置が“Ｆ”であるというＡＳＩＣ１０に適用されて、ＩＲ番号“５９”に従ってそのＡＳＩＣ１０から収集されたログの中の“０３７３”のアドレスビット位置に故障フラグが立っている場合に適用される解析情報であるということを示している。

そして、この第７番目の解析情報は、このログのビットがＲＣ（Region Code)ビットであることで故障解析の対象となるものであることを示し、このログの優先度が“１０”で、“／ＸＣ／ＲＣ＿ＣＯＰＹ＿ＬＯＣＫ＿ＣＥ”というビットが立っていた場合にはこの解析情報が無効となり、“／ＸＣ／ＲＣ＿ＲＥＴＲＹ＿ＬＯＣＫ＿ＣＥ”というビットが立っていた場合にはこの解析情報が有効となるもので、この解析情報が有効である場合には、“アラーム”という事象で、２Ａというメッセージ番号のメッセージを報告先に報告し、“ＳＣ＿ＦＴＬ１＿ＩＮＴＦ”というアクションを行って、そのときに用いる交換部品は“／ＣＭＵ＃０”になるということについて記述する解析情報であるということを示している。

このように、本発明で用いられる解析情報では、ＡＳＩＣ１０の搭載されるシステムボード番号及びそのボード上搭載位置に対応付けて、そのＡＳＩＣ１０から収集するログ情報について、こういう別のあるログ情報が故障発生を表示しているときにはそのログ情報についての解析情報が無効となり、こういう別のあるログ情報が故障発生を表示しているときにはそのログ情報についての解析情報が有効となるという条件について記述しつつ、そのログ情報が発生するときに処理すべき情報と、そのログ情報の優先度の情報とについて定義するという構成を採る。

このときに、他のシステムボードに搭載されるＡＳＩＣ１０から収集されるログ情報についても含める形で、こういう別のあるログ情報が故障発生を表示しているときには解析情報が無効となり、こういう別のあるログ情報が故障発生を表示しているときには解析情報が有効となるということについて記述している。

この記述形式に従って、解析処理部１２がＲＡＳ−ＤＢファイル１１に格納される解析情報を使ってＡＳＩＣ１０に発生した故障を解析すると、自ずとシステム全体の故障解析についても同時に実現できるようになる。

次に、図６に示すＣＭＵ＃０というシステムボードを具体例にして、このことが実現できるようになるということについて説明する。

図６に示すＣＭＵ＃０というシステムボードでは、ＣＰＵ＃０というＡＳＩＣ１０と、ＣＰＵ＃１というＡＳＩＣ１０と、ＣＰＵ＃２というＡＳＩＣ１０と、ＣＰＵ＃３というＡＳＩＣ１０と、ＳＣ＃０という５つのＡＳＩＣ１０が搭載されていることを想定している。

ここで、ＣＰＵ＃０，１，２，３は、それぞれ“／Ａ０／ＢＵＳ＿ＳＮＤ”というバスの送信口を持ち、その送信口をチェックするチェッカが、その送信口に故障が発生した場合には、信号名“／Ａ０／ＲＣ＿ＯＵＴ”、ＩＲ番号“５８”およびアドレスビット位置“１０”の指すフラグ域にフラグを書き込むものとする。

また、ＳＣ＃０は、ＣＰＵ＃０の持つバスの送信口に合わせて“／Ｘ０／ＢＵＳ＿ＲＳＶ”というバスの受信口を持ち、その受信口をチェックするチェッカが、その受信口に故障が発生した場合には、信号名“／Ｘ０／ＲＣ＿ＲＳＶ”、ＩＲ番号“１０”およびアドレスビット位置“１２３”の指すフラグ域にフラグを書き込むものとする。

そして、ＳＣ＃０は、ＣＰＵ＃１の持つバスの送信口に合わせて“／Ｘ１／ＢＵＳ＿ＲＳＶ”というバスの受信口を持ち、その受信口をチェックするチェッカが、その受信口に故障が発生した場合には、信号名“／Ｘ１／ＲＣ＿ＲＳＶ”、ＩＲ番号“１１”およびアドレスビット位置“１２３”の指すフラグ域にフラグを書き込むものとする。

そして、ＳＣ＃０は、ＣＰＵ＃２の持つバスの送信口に合わせて“／Ｘ２／ＢＵＳ＿ＲＳＶ”というバスの受信口を持ち、その受信口をチェックするチェッカが、その受信口に故障が発生した場合には、信号名“／Ｘ２／ＲＣ＿ＲＳＶ”、ＩＲ番号“１２”およびアドレスビット位置“１２３”の指すフラグ域にフラグを書き込むものとする。

そして、ＳＣ＃０は、ＣＰＵ＃３の持つバスの送信口に合わせて“／Ｘ３／ＢＵＳ＿ＲＳＶ”というバスの受信口を持ち、その受信口をチェックするチェッカが、その受信口に故障が発生した場合には、信号名“／Ｘ３／ＲＣ＿ＲＳＶ”、ＩＲ番号“１３”およびアドレスビット位置“１２３”の指すフラグ域にフラグを書き込むものとする。

さらに、ＳＣ＃０は、内部における故障の発生を示すフラグを書き込むためのフラグ域として、（１）信号名“／Ａ／ＲＣ＿ＸＸ”、ＩＲ番号“２０”およびアドレスビット位置“２００”の指すフラグ域と、（２）信号名“／Ａ／ＲＣ＿ＹＹ”、ＩＲ番号“５０”およびアドレスビット位置“０４４”の指すフラグ域と、（３）信号名“／Ｂ／ＲＣ＿ＸＸ”、ＩＲ番号“２０”およびアドレスビット位置“３００”の指すフラグ域と、（４）信号名“／Ｂ／ＲＣ＿ＹＹ”、ＩＲ番号“５０”およびアドレスビット位置“１４４”の指すフラグ域という４つのフラグ域を持つことを想定している。

この場合、ＲＡＳ−ＤＢファイル１１には、ＣＰＵ＃０，１，２，３の解析情報として、図７に示すものが格納される。ここで、図７では、ＤＣモデル用の解析情報と、ＦＦモデル用の解析情報とを定義しているが、この２つの違いは表示メッセージが異なる点だけである。

一方、ＲＡＳ−ＤＢファイル１１には、ＳＣ＃０の解析情報として、図８に示すものが格納される。

図８に示すＳＣ＃０の解析情報では、エントリ抑止条件として、ＣＰＵ＃０，１，２，３の送信口側に故障が発生した場合には、受信口側であるＳＣ＃０で発生した故障については無効にするということが定義されている。

この定義に従って、ＣＰＵ＃０，１，２，３の送信口側に故障が発生した場合には、受信口側であるＳＣ＃０でも故障が発生することになるが、それについては付随的に発生したものであって本質的なものではないことから無視して、送信口側で発生した本質的な故障のみを解析することが可能になるのである。

この具体例では、エントリ抑止条件が同一のシステムボード内で定義されることを示したが、エントリ抑止条件やエントリ許可条件については、同一のシステムボード内に限られるものではなく、異なるシステムボード間で定義されてもよい。

このことにより、本発明によれば、システムボードを単位とする従来の故障解析方法で必要とされていたシステム全体の故障解析を行うことを省略することができるようになるのである。

次に、図９に従って、図３ないし５に示したデータ構造を持つ解析情報の作成方法について説明する。

図２で説明したように、ＲＡＳ−ＤＢファイル１１に格納される解析情報については、ＡＳＩＣ１０の設計者がＲＡＳ−ＤＢ定義ファイル５０に格納する解析定義を作成すると、ＲＡＳ−ＤＢジェネレータ５１がその解析定義をコンパイルしてＲＡＳ−ＤＢファイル１１に格納することで、ＲＡＳ−ＤＢファイル１１に格納されることになる。

この解析情報の作成にあたって、ＡＳＩＣ１０の搭載される情報処理装置のモデルによって、システムボートの枚数やそこに搭載されるＡＳＩＣ１０の搭載位置が変わることで、解析情報に記述されるエントリ抑止（dis)やエントリ許可条件（enb)や故障マーク（mark）などの項目値が変更されることになる。

しかし、そのような変更に合わせて、ＡＳＩＣ１０の設計者に対して、情報処理装置のモデル毎に、別々の解析情報を作成させるように要求していたのでは多大な負荷を強いることになる。

そこで、本発明では、ＡＳＩＣ１０の設計者に対して、エントリ抑止（dis)やエントリ許可条件（enb)や故障マーク（mark）などの項目値について、情報処理装置のモデルに合わせた読み替えの変換ルールを作成させるとともに、解析情報については情報処理装置のモデルに依らない一般的な形で作成させて、この変換ルールを利用することで、情報処理装置のモデルに合った解析情報の作成を実現するという方法を用いるようにしている。

すなわち、本発明では、図９に示すように、ＡＳＩＣ１０の設計者に対して、ＡＳＩＣ１０に固有のＲＡＳ−ＤＢ定義（情報処理装置のモデルに依らない一般的な形のＲＡＳ−ＤＢ定義）を作成させて、それをフォーマットチェックすることでＡＳＩＣ１０に固有のＲＡＳ−ＤＢ定義を作成する。

そして、ＡＳＩＣ１０の設計者（システムの設計者でもよい）に対して、エントリ抑止（dis)やエントリ許可条件（enb)や故障マーク（mark）などの項目値について、情報処理装置のモデルに合わせた読み替えの変換ルール定義を作成させて、それをフォーマットチェックすることで情報処理装置のモデルに合わせた読み替えの変換ルール定義を作成する。

そして、作成したＲＡＳ−ＤＢ定義と作成した変換ルール定義とを組み合わせて、それをコンパイルすることで、解析対象となる情報処理装置のモデルに合った解析情報を作成して、それをＲＡＳ−ＤＢファイル１１に格納するようにしている。

この構成に従って、本発明によれば、ＡＳＩＣ１０の設計者は情報処理装置のモデル毎に別々の解析情報を作成しなくても済むようになる。

次に、図１０及び図１１の処理フローに従って、図２に示す本体ログ解析プロセス３４の実行する処理について詳細に説明する。

本体ログ解析プロセス３４は、本体ログプロセス３１から解析用ログファイル３２に格納されるログ情報（故障発生を表示するログ情報）の解析指示が発行されると、先ず最初に、ステップＳ１０で、バッファ４０をクリアする。

続いて、ステップＳ１１で、解析用ログファイル３２に格納される全てのログ情報を処理したのか否かを判断する。

このステップＳ１１の判断処理に従って、解析用ログファイル３２に格納される全てのログ情報を処理していないことを判断するときには、ステップＳ１２に進んで、解析用ログファイル３２から、未処理のログ情報を１つ読み出す。

続いて、ステップＳ１３で、ＲＡＳ−ＤＢファイル１１から、ステップＳ１２で読み出したログ情報に対応付けられる解析情報を取得する。

続いて、ステップＳ１４で、ステップＳ１３で取得した解析情報にエントリ抑止条件が記述されているのか否かを判断する。

このステップＳ１４の判断処理に従って、ステップＳ１３で取得した解析情報にエントリ抑止条件が記述されていることを判断するときには、ステップＳ１５に進んで、解析用ログファイル３２に格納されるログ情報を参照することで、そのエントリ抑止条件が成立するのか否かを判断する。

続いて、ステップＳ１６で、ステップＳ１５の判断処理に従って、ステップＳ１３で取得した解析情報に記述されるエントリ抑止条件が成立することを判断するときには、次のログ情報について処理すべく、ステップＳ１１の処理に戻る。

すなわち、ステップＳ１３で取得した解析情報に記述されるエントリ抑止条件が成立する場合には、その解析情報が無効となることで、ステップＳ１２で読み出したログ情報を解析する必要がないので、次のログ情報について処理すべく、ステップＳ１１の処理に戻るのである。

一方、ステップＳ１４の判断処理に従って、ステップＳ１３で取得した解析情報にエントリ抑止条件が記述されていないことを判断し、あるいは、ステップＳ１６の判断処理に従って、ステップＳ１３で取得した解析情報に記述されるエントリ抑止条件が成立しないことを判断するときには、ステップＳ１７に進んで、ステップＳ１３で取得した解析情報にエントリ許可条件が記述されているのか否かを判断する。

このステップＳ１７の判断処理に従って、ステップＳ１３で取得した解析情報にエントリ許可条件が記述されていることを判断するときには、ステップＳ１８に進んで、解析用ログファイル３２に格納されるログ情報を参照することで、そのエントリ許可条件が成立するのか否かを判断する。

続いて、ステップＳ１９で、ステップＳ１８の判断処理に従って、ステップＳ１３で取得した解析情報に記述されるエントリ許可条件が成立しないことを判断するときには、次のログ情報について処理すべく、ステップＳ１１の処理に戻る。

すなわち、ステップＳ１３で取得した解析情報に記述されるエントリ許可条件が成立しない場合には、その解析情報が無効となることで、ステップＳ１２で読み出したログ情報を解析する必要がないので、次のログ情報について処理すべく、ステップＳ１１の処理に戻るのである。

一方、ステップＳ１７の判断処理に従って、ステップＳ１３で取得した解析情報にエントリ許可条件が記述されていないことを判断し、あるいは、ステップＳ１９の判断処理に従って、ステップＳ１３で取得した解析情報に記述されるエントリ許可条件が成立することを判断するときには、ステップＳ２０に進んで、バッファ４０が満杯であるのか否かを判断する。

すなわち、ステップＳ１３で取得した解析情報が最終的に有効なものであると判断する場合には、ステップＳ２０に進んで、バッファ４０が満杯であるのか否かを判断するのである。

このステップＳ２０の判断処理に従って、バッファ４０が満杯でないことを判断するときには、ステップＳ２１に進んで、ステップＳ１３で取得した解析情報をバッファ４０に格納することで、ステップＳ１２で読み出したログ情報の解析を行ってから、次のログ情報について処理すべく、ステップＳ１１の処理に戻る。

すなわち、ステップＳ１２で読み出したログ情報に対応付けられる解析情報には、そのログ情報が発生するときには、このような故障が発生したので、このような処理を行えということが記述されているので、それを解析結果としてバッファ４０に格納してから、次のログ情報について処理すべく、ステップＳ１１の処理に戻るのである。

一方、ステップＳ２０の判断処理に従って、バッファ４０が満杯であるということを判断するときには、ステップＳ２２に進んで、ステップＳ１３で取得した解析情報に記述される優先度情報に従って、ステップＳ１２で読み出したログ情報の持つ優先度を特定する。

続いて、ステップＳ２３で、バッファ４０の最後尾にソートされる解析情報（最も低い優先度のものがソートされている）に従って、バッファ４０に解析結果が格納されているログ情報の持つ最も低い優先度を特定する。

続いて、ステップＳ２４で、ステップＳ２２で特定した優先度がステップＳ２３で特定した優先度よりも低いのか否かを判断する。

このステップＳ２４の判断処理に従って、ステップＳ２２で特定した優先度がステップＳ２３で特定した優先度よりも低いことを判断するときには、次のログ情報について処理すべく、ステップＳ１１の処理に戻る。

すなわち、ステップＳ２２で特定した優先度がステップＳ２３で特定した優先度よりも低いことを判断する場合には、ステップＳ１２で読み出したログ情報がバッファ４０に解析結果が格納されているログ情報よりも重要でないことを判断して、何の処理も行うことなく、直ちに、ステップＳ１１の処理に戻るのである。

一方、ステップＳ２４の判断処理に従って、ステップＳ２２で特定した優先度がステップＳ２３で特定した優先度よりも高いことを判断するときには、ステップＳ２５に進んで、バッファ４０の最後尾にソートされる解析情報（最も低い優先度のものがソートされている）と入れ替える形で、ステップＳ１３で取得した解析情報をバッファ４０に格納することで、ステップＳ１２で読み出したログ情報の解析を行う。

すなわち、ステップＳ２２で特定した優先度がステップＳ２３で特定した優先度よりも高いことを判断する場合には、ステップＳ１２で読み出したログ情報がバッファ４０に解析結果が格納されている最も低い優先度を持つログ情報よりも重要であることを判断して、そのログ情報と入れ替える形で、解析結果をバッファ４０に格納するのである。

続いて、ステップＳ２６で、バッファ４０に格納される解析情報を優先度に従ってソートしてから、次のログ情報について処理すべく、ステップＳ１１の処理に戻る。

そして、ステップＳ１１〜ステップＳ２６の処理を繰り返していくときに、ステップＳ１１で、解析用ログファイル３２に格納される全てのログ情報を処理したことを判断するときには、ステップＳ２７に進んで、バッファ４０に格納される解析情報を故障解析の解析結果として報告先に報告して、処理を終了する。

このようにして、本体ログ解析プロセス３４は、本体ログプロセス３１から解析用ログファイル３２に格納されるログ情報（故障発生を表示するログ情報）の解析指示が発行されると、図１２に示すように、ＲＡＳ−ＤＢファイル１１から、優先度の順番に従ってログ情報に対応付けられる解析情報を取得して、それをバッファ４０に格納することで故障解析を行うように処理するのである。

この処理に従って、本発明によれば、優先度の高いログ情報の解析が漏れなく行われることを保証できるようになる。

以上に説明した処理の実行にあたって、本体ログ解析プロセス３４は、作業用メモリ４１の容量を削減するために、図１３に示すように、システムの起動時には、ＲＡＳ−ＤＢファイル１１に格納される解析情報については作業用メモリ４１に読み出さないようにして、解析情報の索引に用いられる索引テーブルのみを作業用メモリ４１に書き込むようにする。

そして、故障が発生すると、自プロセスを実装する情報処理装置にどのようなＡＳＩＣ１０が搭載されているのかという情報を取得して、作業用メモリ４１に読み出してある索引テーブルに従って、その取得した情報の指すＡＳＩＣ１０に適用される解析情報を特定して、それをＲＡＳ−ＤＢファイル１１から読み出して作業用メモリ４１に書き込むようにする。

この構成に従って、本発明によれば、使用しない解析情報までも含める形で作業用メモリ４１に解析情報を常駐させるという従来の故障解析方法に比べて、故障解析に要する作業用メモリ４１の容量を大幅に削減できるようになる。

本発明は、従来技術のように、システムボードを単位とする故障解析を行うのではなくて、システムボードに搭載するＡＳＩＣ１０のようなハードウェア回路を単位とする故障解析を行うことを特徴とする。

これから、本発明では、ログ情報の欠落による故障解析の不可能範囲がハードウェア回路単位となる。

したがって、本発明では、図１４に示すように、例えば、システムボード１００に搭載されるある一つのＡＳＩＣ１０（例えば、図中に示すＡＳＩＣ−Ｄ）からハード故障フラグを収集できないような事態が起こるときには、そのＡＳＩＣ１０のみが解析不可能になるだけであって、従来技術のように、システムボード全体について解析不可能になるようなことはない。

このように、本発明によれば、従来技術に比べて、故障解析の不可能範囲を大幅に小さくすることができるようになる。

本発明によれば、情報処理装置に搭載されるＬＳＩのような論理回路に発生する故障を解析するという機能を実現するときに、メモリ資源の削減、処理の高速化および開発工数の削減を実現できるようになるとともに、重大な故障を漏れなく解析することを実現できるようになり、さらに、解析不可能範囲を小さくすることを実現できるようになる。

Claims (8)

1. 複数の論理回路を搭載する複数のボードを具備する情報処理装置に実装されて、それらの論理回路にどのような故障が発生したのかを解析する故障解析装置であって、
   論理回路の搭載されるボード番号及びボード上搭載位置に対応付けて、その論理回路から収集するログ情報について、そのログ情報が発生するときに処理すべき情報と、そのログ情報が有効なものとなる条件の情報と、そのログ情報が無効なものとなる条件の情報とについて記述する解析情報を記憶する記憶手段と、
   論理回路の故障発生時に、論理回路から故障発生を表示するログ情報を収集する収集手段と、
   上記収集手段の収集したログ情報と、上記記憶手段に記憶される解析情報とに基づいて、論理回路にどのような故障が発生したのかを解析する解析手段とを備えることを、
   特徴とする故障解析装置。
2. 複数の論理回路を搭載する複数のボードを具備する情報処理装置に実装されて、それらの論理回路にどのような故障が発生したのかを解析する故障解析装置であって、
   論理回路の搭載されるボード番号及びボード上搭載位置に対応付けて、その論理回路から収集するログ情報について、そのログ情報が発生するときに処理すべき情報と、そのログ情報の優先度の情報と、そのログ情報が有効なものとなる条件の情報と、そのログ情報が無効なものとなる条件の情報とについて記述する解析情報を記憶する記憶手段と、
   論理回路の故障発生時に、論理回路から故障発生を表示するログ情報を収集する収集手段と、
   上記収集手段の収集したログ情報と、上記記憶手段に記憶される解析情報とに基づいて、論理回路にどのような故障が発生したのかを解析する解析手段とを備えることを、
   特徴とする故障解析装置。
3. 請求項２に記載の故障解析装置において、
   上記記憶手段は、上記ログ情報が有効なものとなる条件の情報として、どのログ情報が故障発生を示す場合という条件の情報について記述することを、
   特徴とする故障解析装置。
4. 請求項２に記載の故障解析装置において、
   上記記憶手段は、上記ログ情報が無効なものとなる条件の情報として、どのログ情報が故障発生を示す場合という条件の情報について記述することを、
   特徴とする故障解析装置。
5. 請求項２ないし４のいずれか１項に記載の故障解析装置において、
   上記解析手段は、上記収集手段の収集したログ情報の内、上記解析情報に記述される条件情報に基づいて有効となるものを抽出することで、論理回路にどのような故障が発生したのかを解析することを、
   特徴とする故障解析装置。
6. 請求項５に記載の故障解析装置において、
   上記解析手段は、上記抽出したログ情報の内、上記解析情報に記述される優先度情報に基づいて優先度の高いものを抽出することを、
   特徴とする故障解析装置。
7. 請求項６に記載の故障解析装置において、
   上記解析手段は、上記収集手段の収集したログ情報の内、上記解析情報に記述される条件情報に基づいて有効となるログ情報を抽出すると、その抽出したログ情報の優先度が規定のメモリ容量を持つバッファに格納されるログ情報の優先度よりも高い場合には、そのバッファに格納される最も優先度の低いログ情報と入れ替える形でその抽出したログ情報を格納し、その抽出したログ情報の優先度がそのバッファに格納されるログ情報の優先度よりも低い場合には、その抽出したログ情報をバッファに格納しないようにすることで、優先度の高いログ情報を抽出することを、
   特徴とする故障解析装置。
8. 請求項２ないし７のいずれか１項に記載の故障解析装置において、
   装置起動時に、解析対象となる情報処理装置に搭載される可能性のある論理回路に適用される上記解析情報の索引に用いられる索引情報を、上記記憶手段に記憶させる第１の展開手段と、
   論理回路の故障発生時に、解析対象となる情報処理装置に搭載される論理回路の情報と上記索引情報とに従って、上記解析手段の解析に必要となる上記解析情報を特定して、その特定した解析情報を上記記憶手段に記憶させる第２の展開手段とを備えることを、
   特徴とする故障解析装置。
   

Images