JP2004007466A - 被試験システムにおいてデータパケット転送障害を診断する方法 - Google Patents

Abstract

【課題】複雑な商業用途に適用可能で、間欠的障害を診断するための障害シミュレーションを提供すること。
【解決手段】データパケットが転送されるデータ伝送経路を定義する被試験システム（ＳＵＴ）（１１０）においてデータパケット転送障害を診断する方法であって、データパケットの転送においてエラーを起こす可能性のある前記ＳＵＴの前記データ伝送経路のうち、少なくともいくつかの部分を識別するステップと、前記識別されたデータ転送経路部分のうち、少なくともいくつかについてのデータパケット転送関係を定義する制約条件を与えるステップと、前記制約条件に関して前記ＳＵＴを診断するステップとを含む。
【選択図】図６

Description

【０００１】
【発明の属する技術分野】
本発明は、一般に、システム障害診断に関するものである。とりわけ、本発明は、システムの部分間における多重離散的データ転送障害の診断が組み込まれたシステム及び方法に関するものである。
【０００２】
【従来の技術】
被試験システム（ＳＵＴ）が示す障害を診断するために、さまざまなシステム及び方法が用いられてきた。例えば、手動診断、テスト・モデルをベースにしたテクノロジに基づく自動化診断、カスタム・ソフトウェア、及び、障害シミュレーションが利用された。しかし、これらの技法には、その適用性に制限を加えることになりがちな恐れのある、１つ以上の知覚される欠点を示す傾向がある。
【０００３】
手動診断に関して、この技法は、一般に、高レベルのＳＵＴとテスト・スーツの知識を必要とする知識集約型技法である。オペレータがこうした知識を獲得するには、時間がかかり、従って、コストが高くつく可能性がある。さらに、診断中に得られる結果は、オペレータ毎に及び／または場所毎に異なる可能性があるので、一般に、再現性がない。こうした技法は、不適切に適用されると、不正確な障害診断を下すことになる可能性があるので、多少エラーを生じやすい可能性がある。
【０００４】
テスト・モデルに基づく診断の形態の多くは、静的障害の診断にうってつけとみなされるが、間欠的障害の診断に用いるには効果がない。静的障害は、テスト全体に生じ、一般に、テスト中の全てのデータ転送に影響を及ぼす障害であるが、間欠的障害は、一般に、データ転送の一部に影響するだけである。テスト・モデルをベースにした技法は、テスト経路の特定部分及び／またはコンポーネントの告発に比べて、テスト経路に関して、障害を診断する場合は、そのテスト経路全体を告発することになりがちである。さらに、テスト・モデルに基づく診断には、一般に、システムに関するテストの詳細モデルを開発することが必要になる。先行技術の中には、テスト・モデルをベースにしたシステムを取り扱ったものもある（例えば、特許文献１参照）。特許文献１は、本明細書開示の発明と共にＡｇｉｌｅｎｔ　Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．に譲渡されており、その開示は参照により本明細書に含まれる。
【０００５】
システムの診断には、カスタム・ソフトウェアも利用されてきた。あいにく、カスタム・ソフトウェアは、一般に、特定システムの診断のためだけに書かれたものである。このアプローチは、面倒なことになりがちであり、従って、実施コストが高くつく。
【０００６】
やはり既知のように、システム診断には、障害シミュレータの利用が可能である。障害シミュレータは、一般に、障害辞書を作成することによって機能する。しかし、とりわけ、ＳＵＴによって複雑な回路が用いられる場合には、障害シミュレーションは、一般に、大量のモデル化時間と、比較的長い実行時間を必要とする。これは、シミュレーションには、一般に、ＳＵＴの動作をビット単位で分析する必要があるためである。このため、一般に、複雑な商業用途に障害シミュレーションを利用するのが実用的であるとは考えられない。さらに、間欠的障害を診断するための障害シミュレーションは、存在しないか、さもなければ、非実用的とみなされている。
【０００７】
【特許文献１】
米国特許第５，８０８，９１９号明細書
【０００８】
【発明が解決しようとする課題】
上記に鑑みて、本発明の目的は、先行技術に関する前述の及び／または他の知覚される欠点に対処する、改良されたシステム及び方法を提供することにある。
【０００９】
【課題を解決するための手段】
本発明は、被試験システム（ＳＵＴ）のデータ・パケット転送における障害診断に関するものである。一般に、本発明では、ＳＵＴの個々の部分間におけるデータ・パケット転送の関係を規定する制約条件が用いられる。従って、ＳＵＴから得られるテスト結果に関連して、これらの制約条件を評価することが可能である。
【００１０】
実施態様によっては、データフロー・モデルを利用して、データ・パケット転送エラーが起こる可能性のあるＳＵＴの部分を識別するものもある。従って、識別される部分間におけるデータ・パケット転送の関係を規定する制約条件が開発される。これにより、ＳＵＴに対応するテスト結果を受信し、データ・パケット転送エラーが検出されると、データフロー・モデルを用いて、テスト結果に関連して制約条件の評価を行い、データ・パケット転送エラーを生じさせた可能性のあるＳＵＴのコンポーネント及び／またはサブコンポーネントを識別するか、または、その容疑を晴らすか、あるいは、その両方を行うことが潜在的に可能になる。
【００１１】
さまざまな技法を用いて、診断を下すことが可能である。例えば、整数計画法、ルール・ベースの辺分類、及び／または、流れイベントベースの辺分類といった線形計画法を利用することが可能である。
【００１２】
実施態様によっては、例えば、データ・パケットのようなデータをカウントすることが可能な、及び／または、データに関連した操作を実施することが可能なＳＵＴの部分を識別することも可能である。例えば、こうした操作には、データの複製（バッシング）、分割、組み合わせ、削除、及び／または、経路指定（スイッチング）を含むことが可能である。
【００１３】
これに関して、本発明の実施態様は、ＳＵＴにおけるデータ・パケット転送障害を診断するための方法として構成することが可能である。すなわち、こうした方法の１つには、データ・パケット転送においてエラーを起こす可能性のあるＳＵＴのデータ伝送経路のうち少なくともいくつかの部分を識別するステップと、データ伝送経路のそれらの部分の少なくともいくつかについてデータ・パケット転送関係を規定する制約条件を設けるステップと、その制約条件に関連してＳＵＴを診断するステップが含まれている。
【００１４】
本発明の実施態様は、被試験システム（ＳＵＴ）におけるデータ・パケット転送障害を診断するためのシステムとして構成することも可能である。こうしたシステムの１つには、データフロー・モデルと、推論エンジンが含まれている。データフロー・モデルは、ＳＵＴのデータ転送機能を表している。推論エンジンは、データフロー・モデルに関して、ＳＵＴに対応するテスト結果を評価するようになっている。
【００１５】
もう１つの障害診断システムには、ＳＵＴのデータ伝送経路の少なくともいくつかの部分を介して、データ・パケットの転送に対応するテスト結果を受信するための手段と、ＳＵＴのデータ伝送経路の少なくともいくつかの部分についてデータ・パケット転送関係を規定する制約条件に関して、ＳＵＴの診断を行うための手段が組み込まれている。
【００１６】
本発明のさらにもう１つの実施態様は、その少なくとも一部がコンピュータ可読媒体に記憶可能な診断システムとみなすことが可能である。こうした診断システムの１つには、データ・パケット転送においてエラーを起こす可能性のあるＳＵＴのデータ伝送経路のうち少なくともいくつかの部分を識別するように構成された論理と、データ伝送経路のそれらの部分の少なくともいくつかについてデータ・パケット転送関係を規定する制約条件を設けるように構成された論理と、その制約条件に関連してＳＵＴを診断するように構成された論理が含まれている。
【００１７】
本発明の実施態様が、上述のもの以外の、あるいは、その代わりとなる、特徴及び／または利点を示すことができるのは明らかである。さらに、当業者には、付属の図面及び以下の詳細な説明を検討すれば、本発明の他のシステム、方法、特徴、及び／または、利点が多分明らかになるか、または、明らかになるといって差し支えない。こうした追加システム、方法、特徴、及び／または、利点は、全て、本説明内に含まれ、本発明の範囲内であり、付属の請求項によって保護されるものとする。
【００１８】
【発明の実施の形態】
本明細書においてさらに詳述するように、本発明のシステム及び方法によれば、データの転送に関連した被試験システム（ＳＵＴ）の障害診断が潜在的に可能になる。すなわち、ＳＵＴのデータ伝送経路の個々の部分間における関係を表した制約条件を利用して、検出される障害の原因である可能性があるＳＵＴの候補または部分を推測するか、または、その容疑を晴らすか、あるいは、その両方を行うことが可能である。ＳＵＴのデータフロー機能を規定する制約条件を利用して、例えば、ＳＵＴにデータを流すべき方法を記述するルール及び／または方程式を導き出すことが可能である。一般に、ＳＵＴのエラーのないデータ・パケット転送挙動を表したデータフロー・モデルが利用される。こうした実施態様の場合、データフロー・モデル及び関連する推論エンジンを利用して、ＳＵＴの診断を行うことが可能である。実施態様によっては、診断される障害が、ＳＵＴにおいて迅速に生じるか、または、間欠的か、あるいは、その両方の可能性がある。
【００１９】
次に図面を参照すると、いくつかの図に共通して、参照番号は対応する要素を表しており、図１は、本発明のシステム１０の実施態様の１つを表した概略図である。すなわち、システム１０には、ＳＵＴ１１０と通信する診断システム１００が含まれている。診断システム１００には、データフロー・モデル１２０と推論エンジン１３０が組み込まれている。データフロー・モデル１２０は、ＳＵＴに関連したデータの流れを記述し、推論エンジン１３０は、さらに詳細に後述するように、データフロー・モデルに関連したテスト結果の解釈を行う。診断システム１００の出力診断には、その故障が観測テスト結果を生じさせた可能性のある、コンポーネント及び／またはサブコンポーネントの表示が含まれるのが望ましい。
【００２０】
実施態様によっては、診断システムが、ＳＵＴと間接的に通信可能なものもある。例えば、ＳＵＴは、テスト結果のような情報を別のシステムまたはプログラムに提供することが可能であり、その情報が、さらに、診断システムに提供されて、分析が行われることになる。
【００２１】
図２には、本発明のシステム１０の実施態様に関する機能を表したフローチャートが描かれている。図２に示すように、システムまたは方法１０は、ブロック２１０から開始されるものと解釈することが可能であり、このブロックにおいて、ＳＵＴのデータ伝送経路の少なくともいくつかの部分が、識別される。すなわち、ＳＵＴの識別された部分は、データ転送においてエラーを起こしかねない可能性がある。ブロック２２０では、データ伝送経路のそれらの部分のうち少なくともいくつかについて、データ・パケット転送関係を規定する制約条件が設けられる。その後、ブロック２３０に示すように、この制約条件に関連して、ＳＵＴの診断が行われる。
【００２２】
診断システム１００は、ソフトウェア、ファームウェア、ハードウェア、または、それらの組み合わせによって実施可能である。ハードウェアで実施される場合、診断システム１００は、さまざまなテクノロジの任意のものまたは組み合わせによって実施することが可能である。例えば、それぞれ、当該技術において周知のところである、下記のテクノロジを利用することが可能である：データ信号に論理機能を実施するための論理ゲートを備えた個別論理回路、適合する組み合わせ論理ゲートを備えた専用集積回路（ＡＳＩＣ）、プログラマブル・ゲート・アレイ（ＰＧＡ）、及び、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）。
【００２３】
ソフトウェアで実施される場合、診断システム１００は、コンピュータまたはプロセッサ・ベースの装置によって実行可能なプログラムとすることが可能である。次に、図３の概略図を参照して、こうしたコンピュータまたはプロセッサ・ベースの装置について説明を行うことにする。
【００２４】
一般に、ハードウェア・アーキテクチャに関して、図３のコンピュータ３００には、ローカルインターフェイス３０８を介して通信可能に結合されたプロセッサ３０２、メモリ３０４、及び、１つ以上の入力及び／または出力（Ｉ／Ｏ）装置３０６（または周辺装置）が含まれている。ローカルインターフェイス３０８は、例えば、当該技術において既知のように、１つ以上のバス、あるいは、他の有線または無線接続とすることが可能である。ローカルインターフェイス３０８には、説明を容易にするために省略された、別の構成要素を含むことが可能である。これらの別の構成要素は、例えば、コントローラ、バッファ（キャッシュ）、ドライバ、中継器、及び／または、受信器とすることが可能である。さらに、ローカルインターフェイスには、コンピュータ３００のコンポーネント間における適切な通信を可能にするアドレス、制御、及び／または、データ接続を含むことが可能である。
【００２５】
プロセッサ３０２は、メモリ３０４に記憶することが可能なソフトウェアを実行するように構成されたハードウェア装置とすることが可能である。プロセッサ３０２は、任意の特注または市販のプロセッサ、中央演算処理装置（ＣＰＵ）、または、いくつかのプロセッサ間における補助プロセッサとすることが可能である。さらに、プロセッサは、例えば、半導体ベースのマイクロプロセッサ（マイクロチップの形態をとる）とすることが可能である。
【００２６】
メモリ３０４には、揮発性メモリ素子（例えば、ランダム・アクセス・メモリ（ＤＲＡＭ、ＳＲＡＭ等のようなＲＡＭ）、及び／または、不揮発性メモリ素子（例えば、ＲＯＭ、ハード・ドライブ、テープ、ＣＤＲＯＭ等）の任意の組み合わせを含むことが可能である。さらに、メモリ３０４には、電子、磁気、光学、及び／または、他のタイプの記憶媒体を組み込むことが可能である。メモリ３０４は、各種コンポーネントが互いに遠隔配置されるが、プロセッサ３０２によってアクセスすることが可能な、分散型アーキテクチャを備えることが可能であるという点に留意されたい。
【００２７】
メモリ３０４内のソフトウェアには、それぞれ、論理機能を実施するための実行可能命令の順序つきリストが含まれている、１つ以上の独立したプログラムを含むことが可能である。メモリ３０４内のソフトウェアには、診断システム１００と、適合するオペレーティング・システム（Ｏ／Ｓ）３１０が含まれている。診断システムは、後述することになる、テスト１００Ａ、モデル化１００Ｂ、及び、推論１００Ｃといった１つ以上のさまざまな機能を発揮することが可能である。実施態様によっては、これらの機能の１つ以上を独立したプログラムとしてて供することが可能なものもある。オペレーティング・システム３１０は、診断システム１００のような他のコンピュータ・プログラムの実行を制御する。オペレーティング・システム３１０は、スケジューリング、入力・出力制御、、ファイル及びデータ管理、メモリ管理、及び、通信制御及び関連サービスを施すことも可能にする。
【００２８】
Ｉ／Ｏ装置３０６には、例えば、キーパッドのような入力装置を含むことが可能である。Ｉ／Ｏ装置３０６には、例えば、ディスプレイ装置のような出力装置を含むことも可能である。Ｉ／Ｏ装置３０６には、さらに、例えば、通信ポートのような入力及び出力の両方と通信するように構成された装置を含むことも可能である。
【００２９】
コンピュータ３００が動作中、プロセッサ３０２は、メモリ３０４内に記憶されているソフトウェアを実行し、メモリ３０４とデータのやりとりを行い、コンピュータの動作を全般的に制御するように構成されている。診断システム１００及びＯ／Ｓ３１０は、全体が、または、部分的に、プロセッサ３０２によって読み取られ、おそらく、プロセッサ３０２内に緩衝記憶され、さらに、実行される。
【００３０】
診断システム１００がソフトウェアによって実施される場合、留意すべきは、診断システムは、任意のコンピュータ関連システムまたは方法によって、または、それらに関連して利用される、任意のコンピュータ可読媒体に記憶することができるという点である。本明細書に関して、コンピュータ可読媒体は、任意のコンピュータ関連システムまたは方法によって、または、それらに関連して利用されるコンピュータ・プログラムを納める、すなわち、記憶することが可能な電子、磁気、光学、または、他の物理的装置または手段である。診断システム１００は、命令実行システム、装置、または、デバイスから命令を取り出して、その命令を実行することが可能なコンピュータ・ベース・システム、プロセッサを含むシステム、または、他のシステムのように、命令実行システム、装置、または、デバイスによって、または、それらに関連して利用される、任意のコンピュータ可読媒体によって実施することが可能である。
【００３１】
本明細書において用いられる限りにおいて、コンピュータ可読媒体は、命令実行システム、装置、または、デバイスによって、または、それらに関連して利用されるプログラムを記憶し、伝達し、伝搬し、あるいは、転送することが可能な任意の手段とすることが可能である。従って、コンピュータ可読媒体は、制限するわけではないが、電子、磁気、光学、電磁、赤外線、または、半導体システム、装置、または、デバイス、あるいは、伝搬媒体とすることが可能である。コンピュータ可読媒体のより具体的な例（非網羅的リスト）は、次の通りである：１つ以上の配線を備えた電気接続（電子）、携帯用コンピュータ・ディスケット（磁気）、ランダム・アクセス・メモリ（ＲＡＭ）（電子）、読み取り専用メモリ（ＲＯＭ）（電子）、消去可能ＰＲＯＭ（ＥＰＲＯＭ、ＥＥＰＲＯＭ、または、フラッシュ・メモリ）、（電子）、光ファイバ（光学）、及び、携帯用コンパクト・ディスク読み取り専用メモリ（ＣＤＲＯＭ）（光学）。プログラムは、用紙または他の媒体を光学的に走査して、電子的に捕捉し、さらに、コンパイルし、解釈するか、必要があれば、適切なやり方で別様の処理を施し、さらに、コンピュータ・メモリに記憶することができるので、コンピュータ可読媒体は、プログラムが印刷される用紙または別の適合する媒体とすることさえ可能であるという点に留意されたい。
【００３２】
次に、診断システム１００の典型的な実施態様の機能を表した、図４のフローチャートを参照することにする。これに関して、フローチャートの各ブロックは、１つ以上の実行可能な命令を含むコードのモジュール・セグメントまたは部分、または、指定の論理機能を実施するための論理を表している。やはり留意すべきは、代替実施例によっては、図４、または、添付のフローチャートの他の全てにおける個々のブロックが、描かれている順序どおりには行われない可能性もあるという点である。例えば、図４において連続して示された２つのブロックが、実際には、ほぼ同時に実行される可能性がある。他の実施態様には、必要とされる機能に応じて、時々、逆の順序でブロックを実行することが可能なものもある。
【００３３】
図４に示すように、診断システムまたは方法１００は、ブロック４１０から開始されるものと解釈することができ、このブロックにおいて、ＳＵＴを表したデータフロー・モデルが生成される。データフロー・モデルには、ＳＵＴの少なくとも一部に関連したデータ・パケット転送関係に対応する情報を含むのが望ましい。ブロック４２０では、データフロー・モデルに関連して、ＳＵＴの診断が実施される。一般に、これには、例えば、テスト論理（図３のテスト１００Ａ参照）、を利用したテスト結果の入手と、推論エンジン（図３の推論１００Ｃ参照）によるテスト結果の分析が含まれている。前述のように、テスト結果は、診断システムにテスト結果を提供する独立したシステムによって入手可能である。
【００３４】
一般に、データフロー・モデルによって実施されるデータフロー・セマンティックス（記号論）は、本質的に汎用であり、さまざまなシステムに適用することが可能である。一般に、特定のＳＵＴのデータフロー・モデルは、頂点と辺を含む有向グラフである。頂点は、辺の終端部を表す、すなわち、頂点を用いて、辺の終端が規定される。さらに、頂点は、データを処理することが可能な、データ伝送経路の位置または部分に対応することが可能である。例えば、頂点は、間違って伝送されたデータを廃棄するデータ伝送経路の一部に対応することが可能である、すなわち、頂点は、データ・パケットを削除し、データを複数部分に分割し、データを組み合わせ、データの経路指定を施し、及び／または、データを複製する。もう１つの例を挙げると、頂点は、例えば、データのカウントといった測定が行われる位置、及び／または、例えば、巡回冗長検査（ＣＲＣ）を実施することが可能といった、データの優良または不良を判定することが可能な位置に対応することが可能である。データの追跡には、優良及び不良以外に、データのタイプの追跡を含むことが可能である点に留意されたい。従って、本発明の実施態様は、特定の用途に応じて、他のデータ特性を考慮するように改変することが可能である。
【００３５】
辺は、１つの頂点からもう１つの頂点までの、ＳＵＴのデータ伝送経路またはその一部を表している。すなわち、辺は、データ転送エラーを起こす要因とみなされる方向性のある成分である。例えば、辺（Ａ、Ｂ）は、例えば、頂点Ａから頂点Ｂまでのデータ・パケットの転送といった、優良または不良データの条件付き転送を表している。自己ループ（Ａ、Ａ）は、一般に許されない。
【００３６】
ＳＵＴに関して、エラー検出機能は、生成、記憶、送信、及び、受信といった操作中及び／または後におけるデータの完全性を判定するための検査の実施に適したコンポーネントと関連している。こうした検査には、巡回冗長検査（ＣＲＣ）、及び、ＭＤ５のようなメッセージ・ダイジェスト法が含まれている。パケット・ベース・アーキテクチャを組み込んだＳＵＴにこれを適用できるのは明白である。例えば、こうしたＳＵＴの場合、ＳＵＴのある位置でＣＲＣコードを生成し、別の位置でＣＲＣコードを再計算し、さらに、２つのＣＲＣコードを比較することによって、データ伝送の完全性を確保することが可能である。
【００３７】
エラー検出機能を用いて、データを追跡することによって、ＳＵＴの一部またはコンポーネントは、例えば、不良データ・パケットといったエラーを含むデータを受信したか、送信したか、または、送信しようとしているかに関する情報、及び／または、不良データを削除したか、または、下流に伝搬したかに関する情報を得ることが可能である。さらに、実施態様によっては、エラー検出に関連したコンポーネントの状態及び／または時間を確認できるものもある。
【００３８】
実施態様によっては、ＳＵＴのエラー記録機能が、完全であると想定されているものもある。すなわち、ＳＵＴは、一般に、あらゆる条件下において、全ての辺における入力データの正しい状況を記録することが可能であるものと想定される。もちろん、これは、一般的な応用例においては誤っているが、より効率的で、より高度な分析による診断を実施できるようにする可能性がある。実施態様によっては、不完全なエラー記録を考慮するといった、補足的変数を利用することが可能なものもあるのは明らかである。
【００３９】
前述のように、本発明の診断システムは、制約条件を利用して、ＳＵＴの障害候補を診断する。すなわち、診断システムの実施態様は、ＳＵＴを通るデータパケットの流れが、ＳＵＴの機能性によって制約を受けるという原理を利用している。これは、一般に、特定のテスト経路のデータフロー・グラフとして表される。ＳＵＴ及びデータフロー・グラフは、やはり、装置状況、カウンタ状況等を捕捉する。一方、さまざまな推論エンジンの機能性を利用することも可能であるが、後述することにする。
【００４０】
特定の機能性に関係なく、推論エンジンの実施態様では、診断、すなわち、推論エンジンの出力に関する同じ定義が利用される。さらに、推論エンジンは、装置状況、パケット・カウント等を含むテスト結果、及び、テスト経路及び関連装置の機能性を記述したデータフロー・グラフを入力として利用する。推論方法によって、疑わしい辺、及び、各辺に関連した障害タイプ／量を含むことが可能な診断が出力として得られる。例えば、ある辺における障害がテスト結果と呼応する場合、その辺は、疑わしいとみなすことが可能である。対照的に、ある辺における障害がテスト結果と呼応しない場合、その辺は、疑わしいとみなすことはできない、すなわち、優良である。従って、所望に応じて、ＳＵＴの物理的コンポーネントに優良の辺と疑わしい辺を写像することが可能である。
【００４１】
これに関して、本発明の推論エンジンの実施態様では、線形計画法、ルール・ベース、及び、流れイベントベースによる障害シミュレーションといった１つ以上の技法を用いて、制約条件を適用することが可能である。線形計画法を用いて、ＳＵＴを評価する診断システムの実施態様では、一般に、それぞれの例については後述する、制約等式及び／または不等式を用いて、診断を下す。
【００４２】
一例を挙げると、例えば、データ・パケットのようなデータの伝送が試みられる合計回数といったテストに関連するＳＵＴ機能性の制約条件、及び／または、観測された挙動（テスト結果）に関連する制約条件が与えられると、線形計画法を利用して、実現可能な診断を見出すことが可能である。すなわち、実施態様によっては、線形計画法を利用して、各辺毎に不良になるデータ・パケット数を最適化／最大化することが可能なものもある。
【００４３】
例えば、データ・パケットのようなデータの許容可能な流れをモデル化した有向グラフＧ＝（Ｖ，Ｅ）が作成されるものと仮定する。Ｇの頂点ｖ　∈　Ｖは、例えば、測定が行われ、例えば、ＣＲＣコードの検査によって、パケットの優良または不良がテストされ、さらに、不良パケットが削除されるか、または、そのいずれかが行われる可能性のある位置である。
【００４４】
頂点には、頂点の所定の挙動特性に関する情報のタグを付けることが可能である。例えば、「ｐｒｏｐ」頂点は、不良パケットを伝搬する頂点であり、「ｎｏｐｒｏｐ」頂点は、検出された不良パケットを削除する頂点である。さらに、「ｂｕｓ」頂点は、物理的バスを表す、すなわち、受信した全ての優良パケットが、こうした頂点の全ての「出辺」によって送信される。「ｕｎｃｏｎｓｔｒａｉｎｅｄ（制約されない）」頂点が利用されることもある。このタイプの頂点による受信パケット数と送信パケット数との関係に関して、役に立つ知識はない。こうした頂点は、例えば、頂点に流入／から流出する多量の優良及び不良パケットについて説明するのが困難な、ＳＵＴの複雑なデータ依存動作を表すために利用することが可能である。
【００４５】
∧＝｛ｐｒｏｐ，ｎｏｐｒｏｐ，ｂｕｓ，ｕｎｃｏｎｓｔｒａｉｎｅｄ｝を可能性のある頂点タグの集合とする。各頂点ｖ　ｐｒｏｐ　ε　Ｖは、関数Ｔ：Ｖ→２^∧によって得られる関連タグ集合を備えている。指示辺、Ｅ⊆Ｖ×Ｖは頂点間の伝達経路である。一般性を損なうことなく、単一方向のみの辺、すなわち、矢印が１つだけの辺が一般に用いられる。別のやり方では、１つの双方向の辺を２つの単一方向の辺に置き換えることが可能である。辺（ｊ，ｉ）∈Ｅは、ｉの「入辺」と呼ばれ、辺（ｉ，ｊ）∈Ｅは、ｉの「出辺」と呼ばれることを想起されたい。
【００４６】
辺に関して下記のセマンティックスが想定されている。入辺のどれかから頂点ｖに流入するパケットは、出辺のどれかから流出することができる。あるシステムまたはテストで、パケットが特定の１つまたは複数の辺から頂点ｖに入り、他の特定の１つまたは複数の辺から出て行くという流れを制限することが分っている場合、頂点ｖを２つ以上の頂点に分割することが望ましい。さらに、ある頂点に入辺がない場合、その頂点は「ソース」と呼ばれる。ある頂点に出辺がない場合、その頂点は「シンク」と呼ばれる。
【００４７】
グラフＧ以外に、カウンタ集合Ψ及び写像Ｍが存在するものと仮定する：Ｅｘ｛ｔ，ｒ｝ｘ｛ｇｏｏｄ，ｂａｄ｝→Ψ。写像Ｍによって、カウンタのセマンティックスが得られる。写像Ｍは、次のように解釈すべきである。
【００４８】
Ｍ（（ｉ，ｊ），ｔ，ｇｏｏｄ）＝ψと仮定すると、ψは、優良パケットが頂点ｉから辺（ｉ、ｊ）に送り出される毎にインクリメントする。
【００４９】
Ｍ（（ｉ，ｊ），ｔ，ｂａｄ）＝ψと仮定すると、ψは、不良パケットが頂点ｉから辺（ｉ，ｊ）に送り出される毎にインクリメントする。
【００５０】
Ｍ（（ｉ，ｊ），ｒ，ｇｏｏｄ）＝ψと仮定すると、ψは、頂点ｊが辺（ｉ，ｊ）を介して優良パケットを受信する毎にインクリメントする。
【００５１】
Ｍ（（ｉ，ｊ），ｒ，ｂａｄ）＝ψと仮定すると、ψは、頂点ｊから辺（ｉ，ｊ）を介して不良パケットを受信する毎にインクリメントする。
【００５２】
写像Ｍは、１対１が望ましいが、１対１ではない場合もある点に留意されたい。例えば、頂点ｖが３つの入辺（ｘ，ｖ）（ｙ，ｖ）及び（ｚ，ｖ）を備えるものと仮定する。ψにｖに届く全ての優良パケットをカウントさせるのが望ましい。従って、次のように設定される。
【００５３】
Ｍ（（（ｘ，ｖ），ｒ，ｇｏｏｄ））＝Ｍ（（（ｙ，ｖ），ｒ，ｇｏｏｄ））＝Ｍ（（（ｚ，ｖ），ｒ，ｇｏｏｄ））＝ψ
同様に、単一カウンタを用いて、それぞれの辺で生じる多種多様な異なるイベントをカウントすることが可能である。各カウンタの特定測定値の集合は、シンドロームと呼ばれる。
【００５４】
線形計画法を用いたＳＵＴ診断の一般的な前提は、例えば、パケットの制約方法、カウンタ・セマンティックス、及び、測定カウンタ値に関する情報といった、入手可能な情報を、その最適解によって、特定の辺に障害の可能性があるか否かが判定される、最適化問題にコード化することである。
【００５５】
これに関して、線形計画法を用いる診断システムの推論エンジンの実施態様は、一般に、３つのサブセクション、すなわち、（１）制約条件の抽出、（２）シンドローム制約条件の追加、及び、（３）制約条件及びシンドロームが与えられた場合の、可能性のある障害候補の判定を組み込んだものと説明することができる。一般に、第１のサブセクションは、ある特定のＳＵＴに関して再計算することが可能である。さらに、第２と第３のサブセクションは、一般に、各シンドローム毎に再実行する必要がある。
【００５６】
制約条件の抽出に関して、変数集合Ｕ_{（ｉ，ｊ）∈Ｅ}｛ｇ（ｉ，ｊ），ｂ（ｉ，ｊ），ｍｂ（ｉ，ｊ），ｇｄ（ｉ，ｊ），ｂｄ（ｉ，ｊ）｝が生成される。変数ｇ（ｉ，ｊ）は、辺（ｉ、ｊ）に送り出される優良パケット数を表している。変数ｂ（ｉ、ｊ）は、頂点ｉによって辺（ｉ、ｊ）に送り出される不良パケット数を表している。変数ｍｂ（ｉ、ｊ）は、辺（ｉ、ｊ）において不良になるパケット、すなわち、その辺に優良パケットとして送り出されるが、不良として受信されるパケットの数を表している。変数ｇｄ（ｉ、ｊ）は、辺（ｉ、ｊ）に送り出された優良パケットの消失した数を表している。パケットは、受信装置がそのパケットをパケットとして認識できないほどに破損すると、消失する可能性がある点に留意されたい。変数ｂｄ（ｉ、ｊ）は、辺（ｉ、ｊ）に送り出された不良パケットの消失した数を表している。
【００５７】
以下＄という表記を行うが、これは次式を意味する。
【００５８】
【数１】

【００５９】
一般に、当初は空の制約条件集合Ｃが生成される。少なくとも１つの入辺及び少なくとも１つの出辺を備えた、各ｕｎｃｏｎｓｔｒａｉｎｅｄの頂点ｉ＄Ｔ（ｉ）毎に、下記に定義の制約条件からＣに追加する。
【００６０】
・ｂｕｓ＄Ｔ（ｉ）の場合、制約条件ＫＧ（ｉ）
・ｂｕｓ∈Ｔ（ｉ）の場合、ｉの各出辺毎に制約条件ＫＧＢ（ｉ、ｊ）
少なくとも１つの出辺を備えた、各ｕｎｃｏｎｓｔｒａｉｎｅｄの頂点ｉ＄Ｔ（ｉ）毎に、Ｃに付加する
・ｐｒｏｐ∈Ｔ（ｉ）及びｂｕｓ＄Ｔ（ｉ）の場合、制約条件ＫＢＰ（ｉ）
・ｐｒｏｐ∈Ｔ（ｉ）及びｂｕｓ∈Ｔ（ｉ）の場合、ｉの各出辺毎に制約条件ＫＢＰＢ（ｉ、ｊ）
・ｐｒｏｐ＄Ｔ（ｉ）の場合、ＫＢＮＰ制約条件
各辺（ｉ、ｊ）∈Ｅ毎に、制約条件ＥＤＧＥＣＯＮＳＥＲＶＥ（ｉ、ｊ）を追加する。
【００６１】
各カウンタψ∈Ψ毎に、制約条件ＣＯＵＮＴＥＲ（Ψ）を追加する。
【００６２】
上述の制約条件は、下記のように定義される。
【００６３】
ＫＧ（ｉ）
（優良パケットに対するキルヒホッフと同様の制約条件、頂点はバスではない）
【数２】

【００６４】
制約条件ＫＧは、頂点ｉに送られた優良パケット数引く、ｉの入辺で消失したパケット数引く、ｉの入辺内で不良になったパケット数が、ｉから流出する優良パケット数に等しくなければならないということを説明している。
【００６５】
ＫＧＢ（ｉ、ｊ）
（優良パケットに対するキルヒホッフと同様の制約条件、頂点はバスである）
【数３】

【００６６】
制約条件ＫＧＢに述べられているのは、頂点ｉに送られた優良パケット数引く、ｉの入辺で消失したパケット数引く、ｉの入辺内で不良になったパケット数が、ｉのｊへの出辺から流出する優良パケット数に等しくなければならないということである。
【００６７】
ＫＢＰ（ｉ）
（不良パケットに対するキルヒホッフと同様の制約条件、ｐｒｏｐ頂点、頂点はバスではない）
【数４】

【００６８】
制約条件ＫＢＰに述べられているのは、ｐｒｏｐ頂点ｉにおいて、ｉに送られた不良パケット数足す、ｉの入辺で消失したパケット数足す、ｉの入辺内で不良になったパケット数が、ｉから流出する不良パケット数に等しくなければならないということである。
【００６９】
ＫＢＰＢ（ｉ，ｊ）
（不良パケットに対するキルヒホッフと同様の制約条件、ｐｒｏｐ頂点、頂点はバスである）
【数５】

【００７０】
制約条件ＫＢＰに述べられているのは、ｐｒｏｐ頂点ｉにおいて、ｉに送られた不良パケット数引く、ｉの入辺で消失したパケット数足す、ｉの入辺内で不良になったパケット数が、ｉのｊへの各出辺から流出する不良パケット数に等しくなければならないということである。
【００７１】
ＫＢＮＰ（ｉ）
（不良パケットに対するキルヒホッフと同様の制約条件、ｎｏｎｐｒｏｐ頂点）
【数６】

【００７２】
制約条件ＫＢＮＰに述べられているのは、ｎｏｎｐｒｏｐ頂点からは、不良パケットが送り出されないということである。
【００７３】
ＥＤＧＥＣＯＮＳＥＲＶＥ（ｉ，ｊ）
（辺におけるパケットの保存）
【数７】

【００７４】
これらの不等式に述べられているのは、辺で送られる以上には、パケットが辺で消失するあるいは不良になることはないということである。通常ＥＤＧＥＣＯＮＳＥＲＶＥ制約条件は必要である。この制約条件がなければ、送られたパケットより多くのパケットが消失する解が求められる可能性がある。
【００７５】
ＣＯＵＮＴＥＲ（ψ）（ψがカウントするイベントを指定する）
【数８】

【００７６】
また通常、全ての変数が負でないよう、すなわち負のパケット・フローが生じないよう制約する必要があるという点に留意されたい。さらに、状況によっては、変数の全てまたは一部が整数であるよう制約するのが望ましい場合もある。
【００７７】
シンドローム制約条件の追加に進むと、シンドロームは通常、それぞれのカウンタに関連した値、または、他の観測されたＳＵＴ装置のステータスを含み、これらはテストの終了後に収集されるものである。こうした各カウンタ毎に、カウンタの値を指定する等式をＣに追加する。例えば、ψ_１１に関連したカウンタの測定値が、値１２７を示し、ψ_１７に関連したカウンタの測定値が、値１００１を示す場合、制約条件ｃｏｕｎｔｅｒ＿ｖａｌｕｅ（ψ_１１）＝１２７及びｃｏｕｎｔｅｒ＿ｖａｌｕｅ（ψ_１７）＝１００１が追加される。これらのシンドロームは、Ｓと呼ばれる。
【００７８】
可能性のある障害候補の判定に関して、このタスクでは、どの障害候補が、検出された不良パケットの要因となったのか、例えば、どの障害候補が、カウンタ値など観測されたテスト結果をきちんと説明するものなのかを判定しなければならない。各障害候補は、例えば、ｍｂ、ｇｄ、ｂｄ等のような障害タイプ、及び、障害タイプの量を含んでおり、関連する辺（ｉ，ｊ）∈Ｅに対応することが望ましい。
【００７９】
例えば、ｎのパケットが、特定の辺で特定のやり方によって間違って送信された可能性があり、２つ以上の障害候補が、各辺に関連している可能性がある。この障害候補集合は、ＦＣ（ｉ，ｊ）と呼ばれる。さらに、ＳＵＴが、２つ以上の障害辺を備えている可能性があり、２つ以上の障害候補が、ある特定の観測されたテスト結果に関連している可能性がある。
【００８０】
この実施態様の場合、関連する障害変数の少なくとも１つ以上が０を超える、制約条件の等式の系に対する解が得られる場合に限って、ある特定の障害候補に障害のある可能性がある。制約条件Ｃ及びＳは、全て、線形である。一般に、変数値は、やはり、全て整数であるので、制約条件の等式は、整数計画法問題（ＩＰ）として解くことが可能である。
【００８１】
ＩＰ問題を解くには、さまざまなルーチンを利用することが可能である。例えば、ＩＰ問題を解くのに利用可能なｌｐ＿ｓｏｌｖｅといった多くのライブラリ・ルーチンが存在する。参考までに、本明細書にはｌｐ＿ｓｏｌｖｅのソース・コードが示されている。ｌｐ＿ｓｏｌｖｅにおいて、変数はデフォルトで負ではないので、変数は、負ではないと明示的に制約する必要はない。さらに、ｌｐ＿ｓｏｌｖｅでは、「分岐限定」法を用いてＩＰ問題を解く。
【００８２】
目的関数を選択し、さまざまな制約条件を利用した複数のＩＰ公式化を繰り返すことによって、可能性のある各障害辺毎に、全ての障害タイプを効率よく列挙することが可能になる。すなわち、目的関数は、一般に次の通りである。
【００８３】
【数９】

すなわち、Ｅの全ての辺で不良になるパケット合計を最大にすることになる。この関数によって、全ての空でないＦＣ（ｉ，ｊ）に少なくとも１つの障害候補が含まれるようになる解が、全ての障害変数に強制される。単一最適化では、全てのＦＣ（ｉ，ｊ）の全ての要素が生成されることはなく、同時に満たされるＦＣ（ｉ，ｊ）のおそらくは大きい集合が生成されるだけであるという点に留意されたい。この目的関数によれば、障害変数に対して、２つ以上の辺に障害のある可能性があるとする解が与えられる。
【００８４】
追加障害候補を生成するため、下記のように、ＩＰをさらに制約し、追加最適化を実行することが可能である。例えば、ＵＦＣ１＝Ｕ_{（ｉ，ｊ）∈Ｅ}ＦＣ（ｉ，ｊ）、かつＵＦＣ＝ＵＦＣ１とする。
【００８５】
全てのｆｃ∈ＵＦＣ１について、
１．その障害変数を０に設定する、すなわち、今後の解からその障害タイプを除去する制約条件をＣに追加する。これによって、事実上、新しい障害タイプが解として浮上せざるを得なくなる。
【００８６】
２．この新しいＩＰを最適化する。
【００８７】
３．実現可能な解が存在する場合、１つ以上の結果生じる固有の障害候補をＵＦＣに追加する。
【００８８】
４．実現可能な解が存在しない場合、ステップ１で追加された制約条件をＣから除去する。
【００８９】
ここでＵＦＣには、全ての可能性のある障害辺に関して全ての実現可能タイプの障害候補が含まれているはずである。ＩＰソルバによっては、ステップ１で、制約条件の全てにおいて、０に設定される変数に対する全ての参照を削除することによって問題からその変数を除去するほうが、その変数がゼロであることを要求する制約条件を追加するよりも効率的である可能性があるという点に留意されたい。
【００９０】
適用例によっては、同時に障害を同時に発生させるのが望ましい場合もあり得る。例えば、演繹的知識または顧客の選好により、いくつかの辺で同時に障害を起こすことが可能である。あるいはまた、オッカムのかみそりの原理に従って、最少数の障害のある辺によって診断に達するのが望ましいものと仮定する。こうした診断は、まず、利用可能なデータを説明する単一の障害のある辺を見つけようと試みることによって下すことが可能である。次に、見つからなければ、さらに、利用可能なデータを説明する１対の有効な辺を見つけようと試みる。このプロセスは、シンドロームを説明する複数欠陥のある仮説が見つかるまで続行可能である。
【００９１】
（事例１）
次に、図５のデータフロー・モデルを参照することにする。例えば、頂点１、頂点２、及び、頂点３といった各頂点は、所定の挙動特性を示す。すなわち、頂点１は、送信される優良パケット数をカウントすることが可能であり、頂点２は、受信する不良パケット数をカウントすることが可能であり、頂点３は、受信する優良パケット数をカウントすることが可能である。さらに、頂点１及び３は、両方とも、受信した不良パケットを伝搬せず、頂点２は、受信した不良パケットを伝搬する。
【００９２】
データフロー・モデル５００に基づき、３つのカウンタを利用することが可能である：Ψ＝｛ψ_１，ψ_２，ψ_３｝。写像Ｍは、次のようになる。
【００９３】
【数１０】

【００９４】
データフロー・モデル５００から生じる制約条件Ｃは、
【数１１】

【００９５】
得られたテスト結果に基づき、頂点１で、２０の優良パケットがカウントされ、頂点２で、１つのＣＲＣエラーがカウントされ、頂点３で、１９の優良パケットがカウントされると仮定する。このシンドロームから生じる制約条件Ｓは、
ｐｓｉ＿１＝２０
ｐｓｉ＿２＝１
ｐｓｉ＿３＝１９
整数プログラムは、ｍａｘ｛ｍｂ＿１＿２＋ｍｂ＿２＿３｜Ｃ，Ｓ｝である。障害変数ｍｂ（１，２）、ｇｄ（１，２）、ｂｄ（１，２）、ｍｂ（２，３）、ｇｄ（２，３）、ｂｄ（２，３）は、対応する辺に障害の可能性がある場合に限って、１以上である。
【００９６】
上述のようなＩＰ問題を解いた後、ｍｂ（１，２）＝１になり、他の全ての障害変数は０になる。従って、辺（１，２）は、障害があり、１つのパケットが不良になった。
【００９７】
（事例２）
次に、典型的なＳＵＴのブロック図を描いた図６を参照することにする。図６に示すように、ＳＵＴ６００には、５つのコンポーネント、すなわち、ＳＴＡＲＴ、Ｎ２ＰＢ、ＰＢＩＦ、ＢＵＦ、及び、ＣＢＯＣが含まれている。各コンポーネントは、所定の挙動特性を示す。すなわち、ＳＵＴ６００の図示コンポーネントは、それぞれ、例えば、データ・パケットのような受信データをカウントし、ＣＲＣ検査を実施することが可能である。さらに、留意すべきは、コンポーネントのうちのいくつかは、不良データの受信時に実施する内容が互いに異なるという点である。すなわち、Ｎ２ＰＢとＢＵＦは、両方とも、受信した不良データを伝搬し、ＳＴＡＲＴとＰＢＩＦは、両方とも、受信した不良データを伝搬しない。また、２つの異なる種類のＢＵＦＦ単位も存在する。「ｓｍａｒｔ　ｂｕｆｆ」は、受信する優良パケットをカウントし、「ｄｕｍｂ　ｂｕｆｆ」はカウントしない。
【００９８】
「ｄｕｍｂ　ｂｕｆｆ」の場合、４つのカウンタを利用することが可能である：Ψ＝｛ψ_１、ψ_２、ψ_３、ψ_４｝。写像Ｍは、次のようになる。
【００９９】
【数１２】

【０１００】
Ｍに対する２つの異なる引数がψ_３に写像される点に留意されたい。従って、ψ_３は、所望に応じて、その入辺のいずれかでｐｂｉｆが優良パケットを受信するたびに、インクリメントされる。ｓｍａｒｔ　ｂｕｆｆの場合、一般に、追加カウンタψ_５が必要とされ、Ｍ（ｐｂｉｆ，ｂｕｆｆ），ｒ，ｇｏｏｄ）＝ψ_５になる。
【０１０１】
図７のデータフロー・モデル７００は、図６のＳＵＴ６００に関して提供される情報に基づいて構成することが可能である。図６のブロック図及び図７のデータフロー・モデル７００が、データフローの曖昧さを示す点に留意されたい。すなわち、ブロック図及びデータフロー・モデル７００のそれぞれは、データが実際にはＰＢＩＦからＣＢＯＣにいかに流れるかについて明らかにしていない。特に、ＰＢＩＦに届くデータが、最初にＢＵＦに流れて、ＣＢＯＣに転送される前に戻されるのか、すなわちＢＵＦが何らかの方法で迂回されるのかどうかが曖昧である。この曖昧さのため、図６のブロック図の５つのコンポーネントのために直接的類似物を与えるデータフロー・モデル７００は、こうした曖昧さを取り入れていない他のデータフロー・モデルに比べると役に立たない。例えば、ＰＢＩＦからＣＢＯＣへの実際のデータの流れに関する情報が得られると、ＳＵＴによるデータ転送を表した明白なデータフロー・モデルを構成することが可能になる。次に、図８に関連して、こうしたデータフロー・モデルの実施態様について述べることにする。
【０１０２】
もう一度図７のデータフロー・モデルを参照すると、５つのシンドロームが生成されたが、各シンドロームは、データフロー・モデルにおける５つの辺の１つにおける間欠的障害から生じる可能性のあるシンドロームである。表１には、これらのシンドロームが示されている。
【０１０３】
【表１】

【０１０４】
表２及び表３には、線形計画法の問題を解いた結果が示されている。非ゼロの項目は、対応する障害仮説が可能性のある障害の原因であることを意味している。その値は、その障害原因によるものと考えられる不良パケット数である。
【０１０５】
【表２】

【０１０６】
【表３】

【０１０７】
（事例３）
この例において、事例２に関連して前述の仮定に、もう１つの仮定が追加される。すなわち、追加制約条件が既知のものである、言い換えると、パケットは、ｎ２ｐｂからｐｂｉｆ、ｂｕｆｆ、ｐｂｉｆ、ｃｂｏｃへと流れて行かなければならないものと仮定する。従って、ＳＵＴに関するより正確なデータフロー・モデルを構成することが可能になる。図８には、こうしたデータ・フロー・モデルが描かれている。
【０１０８】
図８に示すように、データフロー・モデル８００には、頂点ＳＴＡＲＴ、Ｎ２ＰＢ、ＰＢＩＦ１、ＢＵＦ、ＰＢＩＦ２、及び、ＣＢＯＣが含まれている。辺ＳＴＡＲＴ→Ｎ２ＰＢ、Ｎ２ＰＢ→ＰＢＩＦ１、ＰＢＩＦ１→ＢＵＦ、ＢＵＦ→ＰＢＩＦ２、及び、ＰＢＩＦ２→ＣＢＯＣは、頂点によって規定される。従って、図６のコンポーネントＩＦは、データフロー・モデル８００の目的のために、２つの別個の頂点、すなわち、ＰＢＩＦ１及びＰＢＩＦ２として再規定されており、その結果、データフローの曖昧さが払拭されている。
【０１０９】
事例２と同様、４つのカウンタを利用することが可能である：Ψ＝｛ψ_１，ψ_２，ψ_３，ψ_４｝。写像Ｍは次のようになる。
【０１１０】
【数１３】

【０１１１】
ｓｍａｒｔ　ｂｕｆｆの場合、追加カウンタψ_５が必要とされ、Ｍ（（ｐｂｉｆ１，ｂｕｆｆ）ｒ，ｇｏｏｄ）＝ψ_５になる。ψ３は、ｐｂｉｆ１またはｐｂｉｆ２が優良パケットを受信するとインクリメントされるという点に留意されたい。これは、図７のもとのデータフロー・モデルにおいて、ｐｂｉｆが、いずれかの辺で届けられる全ての到着優良パケットをカウントするためである。
【０１１２】
制約条件Ｃは、
【数１４】

【０１１３】
表４及び５には、ＩＰ問題を解いた結果が示されている。この場合、変数は、さらに整数であるという制約が加えられる。
【０１１４】
【表４】

【０１１５】
【表５】

【０１１６】
前述のように、診断システムの実施態様には、障害を診断するためのさまざまな技法を利用する推論エンジンを含むことが可能である。例えば、アルゴリズムまたはルール・ベースの辺分類及びイベントベースの障害シミュレーションによる辺分類を利用することが可能である。
【０１１７】
ルール・ベースの辺分類に関して、最適化のため、グラフ及びテスト制約条件、及び、データフロー・モデルを処理して、等式集合にする（前述のように）代わりに、同じ情報をルールを用いて評価することが可能である。これらのルールは、データフロー・モデルの辺を優良辺と疑わしい辺として分類するように適応させることが可能である。すなわち、ルール・ベースの辺分類は、ＣまたはＰｒｏｌｏｇのようなプログラミング言語によるアルゴリズムとして実施可能である。もう１つの例として、ルール・ベースの辺分類は、ＣＬＰのような制約条件ベースのテクノロジによって実施することも可能である。
【０１１８】
一般に、制約条件は、グラフＧ（Ｖ，Ｅ）及び集合Ｍに従って関連している。例えば、ｂｕｓ頂点は、上述のような所定の流れ制約条件に従い、ｎｏｎｐｒｏｐ頂点は、所定の制約条件に従い、全ての辺は、ＥＤＧＥＣＯＮＳＥＲＶＥ制約条件に従い、等々。制約条件は、データフロー・グラフの意味の正確な定義として役立ち、診断の生成に用いられる実施態様に左右されない。
【０１１９】
頂点、辺、及び、カウンタに関連した制約条件は、診断を下すために試験される。一般に、各頂点は、ラムダによって決まる流れ制約条件の関連集合を備えている。さらに、各辺には、一般に、例えば、ＥＤＧＥＣＯＮＳＥＲＶＥといった、その辺におけるデータ・パケットの保存を記述する制約条件の関連集合が含まれている。さらに、各カウンタには、一般に、Ｇ、写像Ｍ、及び、ＳＵＴからの測定テスト結果によって規定される制約条件の集合が含まれている。
【０１２０】
ルール・ベースの実施態様の場合、一般制約条件からの線形計画は、一般には用いられず、代わりに、グラフ独立アルゴリズムを利用して、Ｇが詳細に検討され、ＳＵＴ及びテスト結果と整合性のとれる診断を下すため、必要とされる制約条件が適用される。
【０１２１】
一般制約条件は、Ｇ及び写像Ｍと共に、ルール処理エンジンに対する入力として、ルールとして表現することも可能である。こうしたルール処理エンジンは、従って、Ｇを詳細に検討し、制約条件を適用し、Ｇ、Ｍ、及び、テスト結果と整合性のとれる診断を下す。
【０１２２】
もう一度、図８のデータフロー・モデル８００及び表５のシンドローム１の結果を参照し、典型的なルール・ベースの辺分類技法を用いて、データフロー・モデル８００及びシンドローム１に関連した情報を分析することにする。
【０１２３】
ｓｍａｒｔ　ｂｕｆｆｅｒの場合には、５つのカウンタを利用できる点を想起されたい：Ψ＝｛ψ_１，ψ_２、ψ_３、ψ_４、ψ_５｝。写像Ｍは、次のようになる。
【０１２４】
【数１５】

【０１２５】
カウンタ値は：ψ_１＝１０、ψ_２＝９、ψ_３＝１８、ψ_４＝９、ψ_５＝９。
【０１２６】
辺ｓｔａｒｔ→ｎ２ｐｂの分析から始めると、カウンタ１及び２には、この辺に対応する情報が含まれていると判断することができる。すなわち、カウンタ１には、この辺に送り出された優良パケット数に関する情報が含まれており、カウンタ２には、この辺から受信した優良パケット数に関する情報が含まれている。どの辺についても、そのエッジに送り出された優良パケット数が、その辺から受信した優良パケット数に等しい場合、その辺は疑わしくはないという点に留意されたい。しかし、辺ｓｔａｒｔ→ｎ２ｐｂについては、その辺から受信した優良パケット数が、その辺に送り出された優良パケット数と等しくはない、すなわち、カウンタ１−カウンタ２＝１。ある辺から受信する優良パケット数は、その辺に送り出された優良パケット数引く、消失した、その辺で送られた優良パケット数引く、その辺で不良になった優良パケット数に等しいことを想起されたい。従って、２−ｇｄ−ｍｂ＝１、または、整数だけしか用いられないので、ｍｂ（ｓｔａｒｔ，ｎ２ｐｂ）またはｇｄ（ｓｔａｒｔ、ｎ２ｐｂ）は１に等しくなる。
【０１２７】
辺ｎ２ｐｂ−ｐｂｉｆ１に関して、カウンタ２及び３は関連している。カウンタ３は、障害のない動作中、ｐｂｉｆ１及びｐｂｉｆ２において受信した全ての優良パケットをカウントするという点を想起すると、カウンタ３には、カウンタ２のカウンタ値の２倍の値が含まれているはずである。このルールを適用すると、カウンタ３の値は、カウンタ２の値の２倍であり、従って、辺ｎ２ｐｂ−ｐｂｉｆ１は疑わしくないはずであるということが明らかになる。これは、ある辺から受信する優良パケット数は、その辺に送り出された優良パケット数引く、その辺で消失する優良パケット数引く、その辺で不良になる優良パケット数に等しいということを表したカウンタ・ルールのもう１つの適用例である。すなわち、カウンタ３において１８のパケットを受信したことが分っており、カウンタ３は、カウンタ２の値の２倍にしかなり得ないので、辺ｎ２ｐｂ−ｐｂｉｆ１の働きにはエラーがなかったはずである。当業者には明らかなように、残りの辺も同様に分類することが可能であるという点に留意されたい。
【０１２８】
前述のように、流れイベントベースの障害シミュレーションによる辺の分類を利用して、診断を下すことも可能である。すなわち、データフロー・グラフ、関連する制約条件、及び、障害モデルを利用して、挙動モデルを構成することが可能である。この挙動モデルの流れイベントベースの障害シミュレーションは、間欠的障害モデルに関して実施することが可能であり、その結果は、障害辞書に記憶される。この障害辞書によって、パケット装置における間欠的障害に関するテスト結果と関連診断との間における写像が可能になる。
【０１２９】
いくつかのアナログ及びディジタル回路のために、挙動モデル及び関連シミュレータ及び障害シミュレータが存在するが、これらを実際に利用して、ルータのような複雑なパケット・アーキテクチャ装置の間欠的障害の診断を下すことはできない。これは、こうした挙動モデル及びシミュレータでは、数百万のパケットを操作する複雑なＳＵＴに対して、ビット単位の記述によるテスト刺激が用いられており、従って、商業的に実用的ではないためである。
【０１３０】
流れイベントベースの障害シミュレーションを利用する推論エンジンの実施態様では、例えば、辺及び頂点といった、データフロー・グラフの構成要素を操作的に表した挙動モデルが用いられる。結果として得られる部品、基板、または、システム・レベルのモデルを実用的に開発して、障害シミュレーションを実施することにより、パケット装置における間欠的障害に関する障害辞書を作成し、従って、診断を下すことが可能になる。
【０１３１】
一般に、障害シミュレーションの論理プロセスは、挿入される障害をシミュレートし、テスト刺激の記述を装置に供給し、挿入された障害条件下における装置の応答を観測することである。次に、障害辞書によって、挿入された障害と観測できる結果との対応が記録される。このプロセスは、障害モデルの各障害タイプごとに繰り返される。
【０１３２】
従来の障害シミュレーションとは対照的に、推論エンジンの実施態様によって加えられるテスト刺激は、１及び０の形をとる、装置に対する実際の入力を表すものではない。すなわち、用いられるテスト刺激は、例えば、パケット数及びそのタイプといった、入力のモデルまたは抽象化したものである。さらに、ＳＵＴの働きに対応するイベントがシミュレートされる。もう１つの相違点として、推論エンジンの実施態様では、間欠的障害に関する障害モデルを利用することが可能である。
【０１３３】
関心があるのは、例えば、パケット数、パケット・タイプ、内部カウンタの内容、または、他の状態といった、流れの有意結果であるので、システムのビット・レベルのアクティビティを追跡するのに資源を割り当てなくても済むようにすれば、効率を高めることが可能になる。与えられた流れの有意テスト結果は、シミュレートされたテスト結果と比較することができる。結果が一致すれば、障害辞書を調べることによって、シミュレートされたテスト結果に対応するシミュレートされた障害を確認することが可能である。
【０１３４】
以下は、イベントベースの障害シミュレーションを利用した推論エンジンの実施態様に関する概要説明である。まず、挙動モデルの実施態様について述べることにする。例えば、ｂｕｓ頂点の対応する挙動モデルは、その入辺の任意の１つにおいて全てのパケット受信イベントを実行し、全ての出辺にパケット送信イベントを生じさせる。この反復には、各出辺にパケットが送り出されたことを示すイベントの再生が含まれる。ｂｕｓ頂点が不良パケット（ｎｏｎｐｒｏｐ要素Ｔ（ｉ））の削除を必要とする場合、任意の入力不良パケットの到着イベントが廃棄されることになる。
【０１３５】
複数の出辺を備えた、バスではないｐｒｏｐ頂点に関して、全てのパケット到着イベントが、ある辺で再生されるが、必ずしも全ての辺である必要はない。関連挙動モデルが、ただ１つだけの出辺でパケット送信イベントを非決定論的に生じさせることによってこれを実施する。同様に、頂点及びその特性に関連した制約条件に従って機能する関連挙動モデルに対して、全ての頂点タイプとＴ（ｉ）間で写像が行われる。
【０１３６】
さらに、各テスト毎に、各ｓｏｕｒｃｅ頂点は、所定の数の所定のタイプのパケットを生成することが可能である。これは、その出辺に対する対応する数のパケット送信イベントを生じさせる挙動モデルとして実現される。ｓｉｎｋに関しては、どのｓｉｎｋ頂点も、出辺がないので、新しいイベントが生じない。
【０１３７】
辺制約条件は、挙動モデルにも写像される。辺モデルでは、パケット送信イベントが宛先頂点または関連カウンタ・モデルのためのパケット到着イベントに変換される。障害シミュレーション条件下において、辺モデルでは、障害モデルに応じて、パケット送信イベントを不良パケット到着イベントまたは優良パケット消失イベント等に変換することが可能である。
【０１３８】
カウンタ制約条件は、挙動モデルとしても表される。写像Ｍによって、カウンタとパケット・タイプ（優良／不良）が関連づけられ、イベント（パケットｔｘ、パケットｒｘ）と辺が関連づけられるという点を想起されたい。パケットｔｘは、送信パケットと同じであり、パケットｒｘは、受信パケットと同じである。ある特定のカウンタが、関連イベントについてその関連する辺をモニタする。関連イベントが生じると、カウンタはインクリメントされる。
【０１３９】
イベントベースの障害シミュレーション−例１（単一の優良パケット・シミュレーション）
このテスト設計によれば、ｓｔａｒｔ頂点は、テストの間に、１０の優良パケット送信イベントを辺（ｓｔａｒｔ、ｎ２ｐｂ）に送り出すことになる。１つのパケットのシミュレーション全体にわたる連鎖イベントは、次の通りである。
【０１４０】
１．ｓｔａｒｔ信号パケット１を（ｓｔａｒｔ，ｎ２ｐｂ）に送り出す。
【０１４１】
２．カウンタψ_１がその関連イベント（（ｓｔａｒｔ，ｎ２ｐｂ）への優良パケットの送り出し）を確認し、それ自体をインクリメントする。
【０１４２】
３．辺（ｓｔａｒｔ，ｎ２ｐｂ）は、パケット送信イベントを確認し、辺（ｓｔａｒｔ，ｎ２ｐｂ）に関するパケット受信イベントに変換する。
【０１４３】
４．カウンタψ_２が、その関連イベント（（ｓｔａｒｔ，ｎ２ｐｂ）からの優良パケット受信）を確認し、それ自体をインクリメントする。
【０１４４】
５．頂点ｎ２ｐｂは、（ｓｔａｒｔ，ｎ２ｐｂ）からの優良パケットの受信を確認し、（ｎ２ｐｂ，ｐｂｉｆ）に優良パケットを送り出す。
【０１４５】
６．辺（（ｎ２ｐｂ，ｐｂｉｆ）は、優良パケット送り出しイベントを確認し、優良パケット受信イベントに変換する。
【０１４６】
７．カウンタψ_３が、関連イベントを確認し、自身をインクリメントする。
【０１４７】
８．ノードｐｂｉｆが、優良パケット受信イベントを確認し、（ｐｂｉｆ，ｃｂｏｃ）への優良パケット送り出しイベントを生じさせる。後続パケットに関して、ｐｂｉｆは、代わりに、（ｐｂｉｆ、ｂｕｆｆ）で信号を送る選択をすることが可能であるが、定義により、両方の辺にイベントを送り出すことはできない。
【０１４８】
９．次に、辺（ｐｂｉｆ，ｃｂｏｃ）が、優良パケット送信イベントを確認し、優良パケット受信イベントに変換する。
【０１４９】
１０．次に、カウンタψ_４が、優良パケット受信イベントを確認し、それ自体をインクリメントする。
【０１５０】
１１．この結果、このパケットの寿命が尽きるので、シンク・ノードｃｂｏｃによってそれ以上のイベントが生じることはない。
【０１５１】
送り出された１０のパケット全ての優良ＳＵＴシミュレーションが終了すると、ψ_１＝１０、ψ_２＝１０、ψ_３＝２０、ψ_４＝１０になる。
【０１５２】
イベントベースの障害シミュレーション−例２（単一不良パケット障害シミュレーション）
前述の例と同様、１０のパケットが送り出される。しかし、１０のパケットのうちの１つが（ｎ２ｐｂ、ｐｂｉｆ）において破損する。流れイベントベースの障害シミュレーションの繰り返しは、次の通りである。障害シミュレータによって、優良パケットの１つが辺（ｎ２ｐｂ、ｐｂｉｆ）で不良になるという、障害イベントの挿入が決定される。
【０１５３】
１．ｓｔａｒｔ信号パケット１を（ｓｔａｒｔ，ｎ２ｐｂ）に送り出す。
【０１５４】
２．カウンタψ_１がその関連イベント（（ｓｔａｒｔ，ｎ２ｐｂ）への優良パケットの送り出し）を確認し、それ自体をインクリメントする。
【０１５５】
３．辺（ｎ２ｐｂ，ｐｂｉｆ）は、「優良パケットの１つが不良になる」その関連障害イベントを認識し、パケット送り出しイベントを、（ｎ２ｐｂ、ｐｂｉｆ）に関する不良パケット受信イベントに変換する。
【０１５６】
４．カウンタψ_２は、関連イベント（（ｓｔａｒｔ，ｎ２ｐｂ）からの優良パケットの受信）を確認しないので、従って、自身をインクリメントしない。
【０１５７】
５．次に、頂点ｎ２ｐｂが、（ｎ２ｐｂ、ｐｂｉｆ）からの不良パケットの受信を確認し、モデルの定義により、ｐｂｉｆは不良パケットを伝搬しないので、そのイベントを廃棄する。
【０１５８】
６．障害シミュレーションは、別の障害イベントを含んでいない、残り９つの優良パケットの伝送をシミュレートする。
【０１５９】
結果生じるカウントは、ψ_１＝１０、ψ_２＝１０、ψ_３＝１８、ψ_４＝９になる。関連する障害辞書項目には、この情報と、それに生じた障害イベントが含まれている。ＳＵＴからのテスト結果が、障害辞書のこの項目と一致すると、診断は、（ｎ２ｐｂ、ｐｂｉｆ）において良好なパケットが不良になったということになる。（ｂｕｆｆ、ｐｂｉｆ）における「パケットの１つが不良になる」イベントの後続シミュレーションによって、同じシミュレーション結果が得られるのは、注目に値することである。この場合、診断には、両方の障害イベントが含まれることになる。というのも、両方とも、その結果の合理的な説明と思われるためである。
【０１６０】
上記プロセスは、辺のそれぞれにおける障害タイプのそれぞれについて繰り返すことが可能である。適用例の必要に応じて、辺当りの障害イベントの量は、変動する可能性があり、同時辺障害の数が変動する可能性もある。障害シミュレータの繰り返し数は、頂点の定義によって示される、パケット・フローにおける非決定論を補償するため、調整することが可能である。この結果、ＳＵＴが実施する可能性のあるさまざまな方法に関する障害辞書項目が得られることになる。
【０１６１】
以上の説明は、例証及び解説を目的として提示されたものである。本発明を余すところなく説明しようとか、あるいは、開示の形態にそっくりそのまま制限しようと意図したものではない。以上の教示に鑑みて、修正及び／または変更を加えることが可能である。一方、上述の実施態様は、本発明の原理及びその応用例を例示することによって、通常の当業者が、企図する特定の用途に適合する、さまざまな実施態様において、さまざまな修正を加えて、本発明を利用できるようにするために選択され、解説されている。こうした修正及び変更は、全て、付属の請求項によって定められた本発明の範囲内に含まれる。この発明は例として、次の実施形態を含む。
【０１６２】
（１）データパケットが転送されるデータ伝送経路を定義する被試験システム（ＳＵＴ）（１１０）においてデータパケット転送障害を診断する方法であって、データパケットの転送においてエラーを起こす可能性のある前記ＳＵＴの前記データ伝送経路のうち、少なくともいくつかの部分を識別するステップと、
前記識別されたデータ転送経路部分のうち、少なくともいくつかについてのデータパケット転送関係を定義する制約条件を与えるステップと、
前記制約条件に関して前記ＳＵＴを診断するステップと、を含む方法。
【０１６３】
（２）前記識別ステップは、前記ＳＵＴに対応するデータフローモデル（１２０）を用意するステップを含み、前記データフローモデルは、辺と頂点を含み、前記辺のそれぞれは、データ転送においてエラーを起こす可能性のある前記ＳＵＴの前記データ転送経路の１つの一部に対応し、前記辺のそれぞれは、前記頂点のうちの２頂点間に形成され、前記頂点のそれぞれは、１つの辺の終端の少なくとも１つであってデータパケットに関する処理が発生する場所を表す、（１）に記載の方法。
【０１６４】
（３）１つの頂点に対応する処理は、データの削除、データの分割、データの経路指定、データの複製、データの組み合わせ、データのカウント、及び、データタイプの識別の少なくとも１つを含む、（２）に記載の方法。
【０１６５】
（４）前記ＳＵＴに対応するテスト結果を受信するステップをさらに含み、前記診断ステップは、前記データフローモデルに関する前記テスト結果を分析するステップを含む、（２）に記載の方法。
【０１６６】
（５）前記テスト結果の分析ステップは、不合格のデータ転送に関連した障害タイプを識別するステップを含む、（４）に記載の方法。
【０１６７】
（６）前記テスト結果の分析ステップは、
不合格のデータ転送に対応する情報を受信するステップと、
前記不合格のデータ転送に潜在的に関連する可能性のある前記ＳＵＴの部分を識別するステップを含む、（４）に記載の方法。
【０１６８】
（７）識別ステップは、グラフ独立アルゴリズムを利用して、制約条件を慎重に検討し、前記制約条件の少なくともいくつかを適用して、診断を下すルールベースの辺分類技法を用いて、前記不合格のデータ転送を識別するステップを含む、（６）に記載の方法。
【０１６９】
（８）前記識別ステップは、前記ＳＵＴの部分を表す挙動モデルを利用した流れイベントベースの障害シミュレーション技法を用いて、障害辞書を作成するように前記不合格のデータ転送を識別するステップを含む、請求項６に記載の方法。
【０１７０】
（９）被試験システム（ＳＵＴ）（１１０）におけるデータ・パケット転送障害を診断するためのシステム（１００）であって、
前記ＳＵＴのデータ伝送経路の少なくともいくつかの部分を表したデータフローモデル（１２０）と、
前記データフローモデルに関連しており、前記データフローモデルに関して、前記ＳＵＴに対応するテスト結果を評価するようになっている推論エンジン（１３０）と、を含むシステム。
【０１７１】
（１０）前記データフローモデルが、辺と頂点を含む有向グラフ（５００、７００、８００）であり、前記辺のそれぞれが、エラーが起こる可能性のある前記ＳＵＴのデータ伝送経路の少なくとも一部に対応し、前記辺のそれぞれが、前記頂点のうちの２頂点によって形成される、（９）に記載のシステム。
【図面の簡単な説明】
【図１】被試験システムのテストに用いられる診断システムの実施態様を含む、本発明のシステムの実施態様を表した概略図である。
【図２】本発明の診断システムの実施態様に関する機能を表したフローチャートである。
【図３】本発明の診断システムの実施態様を実施するために利用可能なコンピュータまたはプロセッサ・ベースのシステムを示す図である。
【図４】図３の診断システムの実施態様に関する機能を表したフローチャートである。
【図５】本発明の診断システムによる利用が可能なデータフロー・モデルの実施態様を表した有向グラフである。
【図６】典型的な被試験システム（ＳＵＴ）を表したブロック図である。
【図７】図６のＳＵＴを診断するため、本発明の診断システムによって利用可能なデータフロー・モデルの実施態様を表した有向グラフである。
【図８】図６のＳＵＴを診断するため、本発明の診断システムによって利用可能なデータフロー・モデルの実施態様を表したもう１つの有向グラフである。
【符号の説明】
１００　診断システム
１１０　被試験システム
１２０　データフローモデル
１３０　推論エンジン
５００，７００，８００　有向グラフ

Claims (1)

1. データパケットが転送されるデータ伝送経路を定義する被試験システム（ＳＵＴ）においてデータパケット転送障害を診断する方法であって、
   データパケットの転送においてエラーを起こす可能性のある前記ＳＵＴの前記データ伝送経路のうち、少なくともいくつかの部分を識別するステップと、
   前記識別されたデータ転送経路部分のうち、少なくともいくつかについてのデータパケット転送関係を定義する制約条件を与えるステップと、
   前記制約条件に関して前記ＳＵＴを診断するステップと、を含む方法。

Images