JP2012239375A - 装置の状態の例外に基づく通知のための方法 - Google Patents

Abstract

【課題】装置の状態の選択的通知のための方法およびシステムの提供。
【解決手段】システム３０は、監視装置２８によって監視される装置２６の状態の選択的通知のための分析エンジン３４と通知エンジン３８とを含む。前記システム３０によって実行される方法は、監視装置２８からのデータ要素を受信し、前記装置２６の前記状態を検出するために前記データ要素５８を処理し、前記状態が前記装置２６の正常状態に対する例外を明示すると決定する。前記状態の第１の通知６０は、前記例外の決定の第１の事例で責任関係者５９に伝達し、第２の通知６０の伝達は、その次の、前記例外の決定の第２の事例で防止される。加えて、前記装置２６の前記正常状態の通信は防止される。
【選択図】図１

Description

本発明は、変圧器管理および障害監視システムの分野に関する。より具体的には本発明は、変圧器システムにおける障害状態の選択的通知に関する。

送電は、消費者への電気の配送におけるプロセスである。一般に用語「送電」は、場所から場所への、例えば発電所と人口集中地域付近の変電所との間の電力のバルク転送を指す。関連する大量の電力のために、送電は通常、高い電圧（１１０ｋＶ以上）で行われる。この電圧を、商業ユーザおよび住民ユーザへの配電のためのより低い電圧に下げるために変電所において変圧器が使用される。

主要電力変圧器は典型的には、一般に誘電体媒質、絶縁体、および熱伝導剤として機能する鉱物油系の流体で満たされる。通常使用のときこの流体は典型的には、ゆっくり劣化し、この油に集まるガスを生じる。変圧器内に電気的障害があると、これらのガスは、より急速に生成される。変圧器内で起こり得る多数の障害状態の各々は、ある主要ガスおよびこれらのガスの分布パターンを発生させる。したがってガスを生じさせる障害状態の特徴は、変圧器流体に存在する種々のガスとこれらの量とを決定することによって確認され得る。

溶解ガス分析（ＤＧＡ）は、変圧器の動作を評価するために変圧器流体内のガスの集積と発生速度とを監視するために広く使用されている予測保守技法である。適当な溶解ガス分析スケジュールは、変圧器の場所、変圧器の使用の性質、およびユニットの重要性に依存して設定され得る。さらに、障害状態が検出されると、ユニットが更なる損傷を受ける前に適切な処置が取られ得るように、どれほど急速にガスが生成されつつあるか、またそれによって問題がどれほど重大であり得るかを決定するために、サンプリング（サンプル採取）頻度が増やされ得る。さらに、如何なるガスが前の障害状態からの残留ガスであるか、あるいはこれらが新しく発生した障害状態によるものであるかどうかに関する決定が行われ得るように、各ユニットの履歴を保持することは必須であると考えられる。

オンライン溶解ガス分析ユニットは、多数のガス、例えば水素（Ｈ_２）、酸素（Ｏ_２）、一酸化炭素（ＣＯ）、二酸化炭素（ＣＯ_２）、メタン（ＣＨ_４）、アセチレン（Ｃ_２Ｈ_２）、エチレン（Ｃ_２Ｈ_４）、およびエタン（Ｃ_２Ｈ_６）の分析を与え得る。サンプルは、監視されている各変圧器から定期的に、例えば４時間ごとに採取され得る。このサンプルレートは望ましくは、個別ガスに関して予め決められた閾値が、あるいは個別ガスに関する変化速度が、到達された場合に、例えば１時間ごとに、増加する。多数の変圧器を管理する公益事業体では、このサンプルレートは、それぞれ分析されるべき多量のデータサンプルを発生させる。

人間の本性と仕事量は、しかしながら、責任ある個人に、オンラインＤＧＡ監視ユニットからのサンプルの反復性のために、１つのサンプルグループの分析を先延ばしさせる可能性がある。したがって、オンライン監視システムの有用性は、膨大な量のデータがタイムリーな仕方で検査されないと、なくなる可能性がある。その結果、公益事業体は典型的には、十分にデータを収集してこのデータを管理可能で有用な情報にフィルタリングすることができないという理由で、種々の装置に関してあまりにも少ない情報に直面することになる。これらの状況下では、あるいくつかの状態は大惨事が発生するまで検出されない可能性がある。

公益事業体は、電力供給を中断することなく与え、また公益事業体に投資した株主を保護することによって公益事業体の資産の利用を安全に最大化し、顧客コストを最小化することに関心を持っている。適切に使用されると溶解ガス分析は、変圧器保守プログラムにおける強力な連続監視ツールを提供し得る。しかしながら、溶解ガス分析の有効性は、溶解ガス分析の結果を適切に広める能力によって限定される。したがって必要とされるのは、溶解ガス分析データの有効な普及のための技法である。

したがって、装置の状態の選択的通知のための方法およびシステムが提供されることは、本発明の利点である。

検出された障害状態の第１（１回目）の事例のときにだけ通知を与え、同じ状態の通知を控える方法およびシステムが提供されることは、本発明のもう１つの利点である。

本発明のもう１つの利点は、責任のある側または複数の責任のある側にだけ障害状態の通知を与える方法およびシステムが提供されることである。

本発明の上記および他の利点は、監視装置によって監視される装置の状態の選択的通知のための方法によって１つの形で実施される。本方法は、監視装置からデータ要素を受信することと、装置の状態を検出するためにこれらのデータ要素を処理することと、状態が装置の正常な状態に対する例外を明示していると決定することと、を必要とする。状態の第１の通知は、例外の決定の第１（１回目）の事例の際に責任のある側に伝達される。第１の事例に続いて発生する、前記例外の決定の第２（２回目）の事例における第２の通知の伝達は妨げられる。

本発明の上記および他の利点は、複数の監視装置のそれぞれの状態の選択的通知のためのシステムであって、複数の装置のそれぞれは複数の監視装置の１つによって監視される、もう１つの形で実施される。このシステムは、監視装置の各々に関して、分析器が各監視装置からデータ要素を受信し、これらの装置のうちの関連する１つの装置の状態を検出するためにデータ要素を処理し、この状態が正常状態とこの正常状態に対する例外とのうちの１つを明示していると決定するように、複数の監視装置の各々との通信のために構成された分析器を含む。本システムはさらに、分析器と通信する通知エンジンを含む。この通知エンジンは、前記例外の決定の第１の事例において責任のある側に状態の第１の通知を伝達する。通知エンジンは、第１の事例の後に続いて発生する、前記例外の決定の第２の事例における状態の第２の通知の伝達を防止し、また通知エンジンは正常状態の決定の際に責任のある側との通信を防止する。

本発明のより完全な理解は、図に関連して考察される場合に詳細な説明と請求項とを参照することによって導き出され、同様の参照番号は図を通して同様のアイテムを指す。
図１は、データ要素の分析と例外に基づく障害状態の通知とが本発明の好適な実施形態にしたがって行われる電気公益事業施設の一部分のブロック図である。 図２は、図１の装置の１つを監視する監視装置によって生成されるデータ要素の第１の例示的パケットの図である。 図３は、図１の装置の１つを監視する監視装置によって生成されるデータ要素の第２の例示的パケットの図である。 図４は、図１の装置のうちの１つの正常状態に対する例外について責任のある側に与えられる通知の図である。 図５は、図１の装置の１つに起こり得る複数の例外に関連する責任関係者のコンタクト（連絡）リストデータベースの図である。 図６は、図１の処理システムの通知エンジンによって保持される例外データベースの図である。 図７は、図１の処理システムの分析エンジンによって実行されるデータ分析プロセスの流れ図である。 図８ａは、本発明による通知プロセスの流れ図である。 図８ｂは、本発明による通知プロセスの流れ図である。 図９は、図８ａおよび８ｂの通知プロセスの通知監視サブプロセスの流れ図である。

本発明は、装置における例外を、すなわち障害状態と重症度レベルとを責任関係者に選択的に通知するための例外に基づく通知方法およびシステムを伴う。本通知方法およびシステムは、電気公益事業会社の変電所に配置された超高圧（ＥＨＶ）変圧器における障害状態の監視に関連して説明される。監視は、溶解ガス分析（ＤＧＡ）ユニットによって実行され、１つ以上の溶解ガス分析（ＤＧＡ）ユニットは、各変圧器のオンライン監視を実行する。本発明による通知エンジンは、責任関係者および他の関係者に不必要なおよび／または繰り返しの情報を充満させることなく、適切な責任関係者に例外の通知を通信する。膨大な量のデータが収集されて分析される、また分析されるデータの選択的通知だけが適切な個人に伝達される必要がある種々の環境に、本発明が直ちに適応させられ得ることは以下の論議において直ちに明らかになるはずである。

図１は、データ要素の分析と例外に基づく障害状態の通知とが本発明の好適な実施形態にしたがって行われる電気公益事業施設２０の一部分のブロック図を示す。施設２０は、複数の変電所２２を含んでおり、そのうちの２つだけが示されている。更なる変電所２２は、省略記号２４によって表されている。変電所２２の各々には、変圧器２６の形式の複数の装置が配置されている。図解を簡略化するために、変電所２２の各々には単に３つの変圧器２６が示されている。しかしながら当業者に知られるように、変電所２２の各々が任意数の変圧器２６を含み得ることは理解されるべきである。

変圧器２６の各々は、複数の溶解ガス分析器（ＤＧＡ）ユニット２８のうちの１つ以上によって監視される。ＤＧＡユニット２８は、典型的には鉱物油系の変圧器流体を監視する。ＤＧＡユニット２８は、鉱物油系の変圧器流体の分解の生成物である例えば８種のガスを監視する。これら８種のガスは、水素（Ｈ_２）、酸素（Ｏ_２）、一酸化炭素（ＣＯ）、二酸化炭素（ＣＯ_２）、メタン（ＣＨ_４）、アセチレン（Ｃ_２Ｈ_２）、エチレン（Ｃ_２Ｈ_４）、およびエタン（Ｃ_２Ｈ_６）を含み得る。

施設２０はさらに、通信ネットワーク３２を介してＤＧＡユニット２８と通信する処理システム３０を含む。好適な実施形態では、処理システム３０は、電気公益事業施設２０によって運用されるエネルギーコントロールセンター（図示せず）に配置され得る。しかしながら、処理システム３０は代替として、契約された第３者の監視施設にアウトソーシングされ得る。

処理システム３０は、分析プロセス３６を実行する分析エンジン３４の形式の第１の処理ユニットを含む。処理システム３０はさらに、通知プロセス４０を実行する通知エンジン３８の形式の第２の処理ユニットと任意選択的なポーリングエンジン４２とを含む。当業者は、分析エンジン３４と通知エンジン３８とポーリングエンジン４２が、別個の物理ユニットである必要はなく、その代わりに単一の処理媒体上に実現され得ることを認めるであろう。処理システム３０の特定の構成は、少なくともある程度、施設２０の複雑さと処理システム３０にデータを供給するＤＧＡユニット２８の数と処理されるデータの量とに依存する。

通知エンジン３８は、コンタクトリストデータベース４４と例外データベース４６とを記憶しているメモリ要素と通信する。データベース構成の技術に精通する人々は、コンタクトリストデータベース４４と例外データベース４６とが幅広い種々の形式を取り得ることを認めるであろう。肯定応答（ＡＣＫ）タイマー５０と処置（ＤＩＳＰ）タイマー５２もまた通知エンジン３８と通信する。処理システム３０の種々の要素間の通信はバス構造体５４を介して達成される。

施設２０はさらに、通知装置５６を含む。通知装置５６は、ページャ、携帯電話、パーソナルディジタルアシスタント（ＰＤＡ）またはこれらの組み合わせといった通常のハンドヘルド通信装置であり得る。代替として、通知装置５６は、デスクトップコンピュータ、または通知装置５６のユーザへの電子メッセージを作成するための他の任意の手段であり得る。通知装置５６は、好適には通信ネットワーク３２を介して処理システム３０と通信する。通信ネットワーク３２は、当業者には周知である通常の無線および／または有線技法を介して通信できる。

通知装置５６の各々は、特定の責任関係者５９に割り当てられるか、あるいは関連付けられる。この説明図では、責任関係者５９は、保守チーム、中間管理チームおよび運転チームを含む。ここで使用される用語「責任関係者」は、特定の変電所において変圧器２６に関して責任を有し、特定の障害状態のために必要とされる矯正措置に最も精通しており、および／または変圧器２６に関する決定を行う適切なレベルの権限を有する１人以上の個人を指す。責任関係者５９は、図５に関連してさらに詳細に論じられるであろう。

一般に、ＤＧＡ分析器２８は、変圧器２６内の流体をサンプリングしてサンプリングされた流体内の溶解ガスに関して監視する。サンプルは、名目上４時間ごとに採取され得る。しかしながら、サンプリングレートは、個別ガスに関して予め決められた閾値が達せられた場合、または個別ガスの変化速度が達せられた場合には、１時間ごとの頻度に増加し得る。ＤＧＡユニット２８における溶解ガス監視は、変圧器流体内の多種のガスの各々に関する量の測定を伴う。これらの測定値は引き続いて、通信ネットワーク３２を介して分析エンジン３４にデータ要素５８として通信される。ＤＧＡユニット２８からのデータ要素５８の通信は、自動的に、および／またはポーリングエンジン４２から通信されるポーリング信号に応じて、行われ得る。代替として、データ要素５８は手動で採取され得る。これらの手動による測定値は、通常のデータ入力方法によって処理システム３０に手動で入力され得る。データ要素５８は、分析エンジン３４によって分析され、この分析結果は通知エンジン３８から１人以上の責任関係者５９に割り当てられた１つ以上の通知装置５６に通知６０の形式で供給される。いったん受信されると、主要な責任関係者（以下に論じられる）は通知６０の受信の肯定応答（ＡＣＫ）６１を送る。本発明による通知と肯定応答の詳細は、図８ａ、８ｂおよび９に関連して提供される。

図２及び３を参照すると、図２は変圧器２６（図１）の１つを監視するＤＧＡユニット２８（図１）の１つによって生成されるデータ要素５８の第１の例示的パケット６２の図を示し、また図３は変圧器２６を監視するＤＧＡユニット２８によって生成されるデータ要素５８の第２の例示的パケット６３の図を示す。パケット６２，６３の各々は望ましくは、ここでは変圧器２８の１つを識別する「ＴＡ０１」と示される変圧器識別子６４を含む。パケット６２、６３の各々はさらに、ＤＧＡユニット２８によって監視されている多種のガス６８の各々に関する値６６としてのデータ要素５８を含む。収集日時、各ガスの変化速度、ここにはリストアップされてない他のガス６８などといった、ここには図示されていない更なる情報も含まれ得る。

第１及び第２のパケット６２，６３はここでは、本発明による分析およびこれに続く選択的通知のためにＤＧＡユニット２８（図１）から処理システム３０（図１）に供給され得る情報を表現するように図示されている。データ要素５８と伝送のための第１及び第２のパケット６２，６３の特定の構成は、それぞれ伝送のために、種々の形を取ることができ、また伝送は当業者に公知の種々の技法によって遂行され得る。

図２は、一般に、「ＴＡ０１」によって識別される変圧器２８が正常に機能している正常状態７０を表す第１のパケット６２を示す。正常状態７０は、ガス６８の各々に関する値６６が、「状態１」レベルなどのような、正常状態７０を定義する予め確立された限界値内に入るときに決定され得る。これらの予め確立された限界値は、ＩＥＥＥ規格Ｃ５７．１０４−１９９１「オイル浸漬変圧器において生成されるガスの解釈のためのＩＥＥＥガイド（IEEE Guide for Interpretation of Gases Generated in Oil-Immersed Transformers）」といった業界で認められた規格において与えられ得る。

これとは対照的に、図３は、一般に、「ＴＡ０１」によって識別される変圧器２８が異常に機能している異常状態７２を表す第２のパケット６３を示す。異常状態７２は、ガス６８に関する一部または全部の値６６がより危機的状態レベルに達したときに決定され得る。この例では、一酸化炭素（ＣＯ）レベルが正常な所望レベルより高い値に達している。その結果、ガス６８に関する値６６が正常限界値内にないというような、ＤＧＡユニット２８（図１）によって監視された状態を指すために、ここで用語「異常状態７２」が利用されている。

図４は、変圧器２６（図１）のうちの１つの正常状態７０（図２）に対する例外７４の１人以上の責任関係者５９（図１）に与えられる通知６０の図を示す。上記に簡潔に言及されたように、ここでのデータ要素５８はＤＧＡユニット２８（図１）においてサンプリングされたガス６８に関する値６６である。ガス６８に関するこれらの値６６は、変圧器２６のうちの１つにおいて現在経験されている例外７４すなわち特定の異常状態７２を明らかにするために分析エンジン３４によって分析される。通知６０はここでは、例外７４を伝達するために利用されている。

通知６０は、ここでは、本発明にしたがって通知エンジン３８（図１）から責任関係者５９の１人以上に供給され得る例外７４に関する情報を表現するように図示されている。通知６０の特定の構成は、当業者に公知の種々の形を取り得る。

通知６０は、変圧器識別子６４を含む。通知６０はさらに、例外７４を伝達し、また任意選択的にガス６８に関する値６６を含み得る。例外７４は、変圧器２６の１つにおける障害状態７６と重症度レベル７８とを定義する。障害状態７６は、障害のタイプ８０と障害の場所８２とを識別する。このようにして、その全体において、例外７４は、変圧器２６の１つにおける異常性に関する高いレベルの詳細を、すなわち障害のタイプ８０と障害の場所８２と特定の障害場所８２における特定の障害タイプ８０の重症度レベル７８とを、責任関係者５９に与える。

図５は、変圧器２６（図１）において可能性のある複数の例外７４（障害状態７６と重症度レベル７８との組み合わせ）に関連する責任関係者５９のコンタクトリストデータベース４４の図を示す。コンタクトリストデータベース４４は、ここでは、本発明による例外７４と責任関係者５９との間の関連性を表現するように図示されている。データベース構成および管理の技術に精通する人々は、コンタクトリストデータベース４４が種々の形式を取り得ることを認めるであろう。

コンタクトリストデータベース４４は、障害タイプ８０と障害場所８２と重症度レベル７８との各組み合わせに関連する責任関係者５９の１人以上を含む。コンタクトリストデータベース４４は、責任関係者５９の適切な１人以上に通知６０（図１）を伝達するために必要とされる情報を通知エンジン３８（図１）に与える。ここでは簡潔にするために、コンタクトリストデータベース４４内に保持される更なる情報を省略記号で表して、コンタクトリストデータベース４４の一部だけが示されている。

この例示的シナリオでは、ガス６８（図２）の値６６（図２）の分析を通して５つの障害タイプ８０が認められ得る。５つの障害タイプ８０は、過熱、過熱オイル、低エネルギー放出、アーク発生、およびセルロース分解を含む。さらにガス６８の値６６の分析を通して５つの障害場所８２が認められ得る。５つの障害場所８２は、負荷タップ切替え器、タンク（コアラミネーションおよびアセンブリボルトを含む）、リード（コイル、巻線およびブッシュなどの間の）、巻線、またはその他のもの（静電シールド、冷却システム等）を含む。この例示的シナリオでは、６つの重症度レベル７８が認められ得る。６つの重症度レベル７８は、１（高い）から６（正常）までの範囲にある。障害タイプ８０と障害場所８２のいずれに関しても「６」という重症度レベル７８は、エントリ８３によって表されているように正常状態７０を示す。その結果、ここでは例示された１２５の可能な例外がある。

責任関係者５９は、例外７４および／または正常状態７０に気付かされる必要のある個人である。この例では、特定の例外７４に、責任関係者５９の３つの通知レベルが関連している。責任関係者５９のこれら３つの通知レベルは、保守チーム８４、中間管理チーム８６および運転チーム８８を含む。種々の他のチームすなわち責任関係者５９は、電気公益事業施設２０（図１）のサイズおよび複雑さ、保守・運転組織の全体的サイズ、特定の障害状態７６などに依存する特定の例外７４に関連付けられ得る。例えば、異なる障害タイプ８０、障害場所８２および／またはこれらの異なる障害タイプ８０および障害場所８２に関する重症度レベル７８のための保守チーム、中間管理チームおよび運転チームを形成する異なる個人が存在し得る。

しかしながら、通知は、責任関係者５９が正式に通知されたという責任関係者５９の各々による応答を必ずしも必要としない。むしろ例外７４の応答と処置は、例外７４に単に気付いている他の責任関係者５９に対する施設２０（図１）の方針と手順とにしたがう責任関係者５９の特定の１人の直接的責任であり得る。

コンタクトリストデータベース４４内の責任関係者５９の通知レベルは、重症度レベル７８が増大するにつれて変化する。好適な実施形態では、この変化は、電気公益事業施設２０（図１）内の組織的な権限の連鎖に関係する。例えば障害状態７６のいずれも「５」または「６」という重症度レベル７８にあるとき、保守チーム８４だけが例外７４の通知と正常状態７０の選択的通知とを必要とする（以下に論じられる）。しかしながら、障害状態７６のいずれも「４」または「３」という重症度レベル７８にあるとき（すなわち障害状態７６が中程度の重大さであることを示しているとき）、保守チーム８４と中間管理チーム８６の両者が通知を必要とする。障害状態７６のいずれも「２」または「１」という重症度レベル７８にあるとき（すなわち障害状態７６が極めて重症になっていることを示すとき）、保守チーム８４、中間管理チーム８６および運転チーム８８のすべてが通知を必要とする。このようにして障害状態７６の重大さが増すにつれて、組織的認識度は増加する。

コンタクトリストデータベース４４はさらに、バックアップ（予備的）責任関係者９０を含み得る。一般に通知エンジン３８（図１）は、通知６０が責任関係者９０によって肯定応答６１（図１）を介して応答されない場合に、バックアップ責任関係者９０に通知６０を送ることができる。障害状態が未通知で未解決のままにならないように、バックアップ責任関係者９０の利用を介して冗長性が与えられ得る。

コンタクトリストデータベース４４に関連して５つの障害タイプ８０と５つの障害場所８２とが論じられているが、当業者は、５つより多い、または少ない障害タイプ８０および同様に５つより多い、または少ない障害場所が識別され得ることを認めるであろう。さらに、ここでは単に６つの重症度レベルが描写されているが、当分野に精通する人は６つよい多い、または少ない重症度レベルが識別され得ることを認めるであろう。

図６は、処理システム３０（図１）の通知エンジン３８（図１）によって保持される例外データベース４６の図を示す。例外データベース４６は、図解目的のために単純化されたフォーマットで示されている。データベースの構成および管理の技術に精通する人々は、例外データベース４６が種々の構成を想定し得ることを認めるであろう。

例外データベース４６は、肯定応答セクション９２と処置セクション９４とを含む。一般に、通知６０が責任関係者５９（図１）の１人以上に送られると、通知エンジン３８は、責任関係者５９の１人からの肯定応答６１（図１）を待ち、肯定応答６１は、施設２０の方針と手順を通して、通知６０に指定された例外７４（図４）の処置に応答し影響を与えるために必要とされる。この特定の例では、１より大きい通知レベルにある責任関係者５９はコンタクトリストデータベース４４（図５）にしたがって通知６０を受信し得るが、保守チーム８４（図５）は肯定応答６１を発送するように要求される。

したがって、肯定応答６１は、保守チーム８４からの１人以上の個人が通知６０を受信したことを示す。肯定応答６１は、Ｅメールプロトコルにしたがって送られた通知６０に対する通常の返信受信の形式、または責任関係者５９が通知６０の受信を肯定応答しているという通知エンジン３８への他の同様な返信メッセージの形式を取り得る。代替として、肯定応答６１は、例外データベース４６への保守チーム８４のメンバーによるデータ入力の形式を取り得る。この肯定応答または肯定応答の欠如は、肯定応答セクション９２に保存される。保守チーム８４からの通知６０の受信の肯定応答に続いて、通知エンジン３８（図１）は、保守チーム８４による例外７４（図４）の処置を待つ。すなわち保守チーム８４は、例外７４を決定的に処理することに責任を持っており、この決定または処置は処置セクション９４に保持される。

例外データベース４６は、一般に、特定の通知６０に関連する識別子９８の記憶のための通知識別子フィールド９６と例外７４の特定の１つに関連する情報の記憶のための例外識別フィールド１００とを含む。例外７４の特定の１つに関連する情報は、変圧器識別子１０１（例えばＴＡ０１）、障害タイプ８０（例えば過熱）、障害場所８２（例えばリード）、および重症度レベル７８（例えば５）を含み得る。

肯定応答セクション９２は、通知６０が送られた日時１０４の記憶のための日時フィールド１０２と、通知６０（図１）の受信の肯定応答６１（図１）が通知エンジン３８で受信されたかどうかを示すための肯定応答フィールド１０６と、責任関係者５９のうちの肯定応答する関係者の特定の識別情報の記憶のための肯定応答受信者フィールド１０８とを含む。この場合、保守チーム８４（ＭＡＩＮＴ）からの個人（例えばＵＳＥＲ００１）が通知６０（例えばＮＯＴＩＣＥ１）の受信を肯定応答する。

処置セクション９４は、例外７４が処置された日時１１２の記憶のため、および例外７４を処置した責任関係者５９（例えばＵＳＥＲ００１）の記憶のための日時フィールド１１０と、処置１１４の保持のための処置フィールド１１３と、を含む。例外データベース４６に保持され得る他の情報は、例えば、試験および／または修理のためのスケジュール、予測保守スケジュールなどを含む。あるいくつかの処置１１４の例は、「正常な監視を続行する」、「電気試験のための送電停止をスケジュールする」、「スケジュールどおりに監視を続行して保守を実行する」、「修理のために運転停止する」などを含む。

例外データベース４６において与えられる情報は、例外７４が前の例外７４からの重症度の増加またな減少であるかどうか、例外７４が障害状態７６（図３）の点から見て変化しつつあるかどうかなど、例外７４に対する要員の応答性に関する決定が行われ得るように、変圧器２６の各々の履歴を維持するために利用され得る。例外データベース４６に備えられている情報はまた、重症度レベル７８が例外７４のより大きな重大さを示すにつれて、より頻繁に通知方法（以下に論じられる）が責任関係者５９および／またはバックアップ責任関係者９０（図５）に通知６０を再送できるように、例外７４の持続性または連続性を調査するためにも利用され得る。例外データベース４６の個体数とその使用法は、図９に関連して論じられるであろう。

図７は、分析エンジン３４（図１）によって実行される分析プロセス３６の流れ図を示す。分析プロセス３６は、変圧器２６が正常に、すなわち正常状態７０（図２）で、あるいは異常に、すなわち異常状態７２（図３）で動作しているかどうか、また例外７４（図４）の特定の１つが異常状態７２を引き起こしているかどうかを決定するために使用され得る結果を取得するために分析エンジン３４によって実行される。分析プロセス３６は、データ要素５８の第１及び第２のパケット６２、６３それぞれ（図２、３）のうちの１つのパケットの受信と分析とに関連して説明されるであろう。しかしながら、データ要素５８がＤＧＡユニット２８（図１）から受信されるにつれて、分析プロセス３６の実行を通して分析エンジン３４がほぼ連続して多数の変圧器２６（図１）からのデータ要素５８を処理できることは理解されるべきである。

分析プロセス３６は、タスク１１６から始まる。タスク１１６で、分析エンジン３４は、ＤＧＡユニット２８の１つからデータ要素５８の第１及び第２のパケット６２、６３の１つを受信する。

タスク１１６におけるデータ要素５８の受信に応じてタスク１１８が実行される。タスク１１８で、分析エンジン３４は、ある状態を、すなわち正常状態７０（図２）とＤＧＡユニット２８によって監視されている変圧器２６の特定の１つに関する例外７４（図４）の１つによって引き起こされる異常状態７２（図３）とのうちの１つを、検出するためにデータ要素５８を処理する。

多数の工業規格の、および発展中の分析技法のいずれも、タスク１１８で分析エンジン３４によって利用され得る。工業規格の溶解ガス分析方法は、ルールに基づく主要ガス分析、Ｒｏｇｅｒｓ比、Ｄｏｅｒｎｅｎｂｕｒｇ比、ＣＩＧＲＥ比、Ｄｕｖａｌ方法およびガスノモグラフを含む。これらの方法は、独立に、あるいは各診断結果の確実性に関する情報を保持するためにファジー理論とニューラルネットワークとによって実現され得る。もう１つの適当な発展中の分析技法は、ルールに基づくエキスパートシステムと並行して動作する人工ニューラルネットワークを含む分析エンジンである。

使用される特定の分析方法とは関係なく、このような方法の目的は、「例外に基づく」通知方法のための可能性を作り出すために、問題のデータ要素５８を不変のまたは正常なデータ要素５８から効果的に区別する、高度に正確なアルゴリズムを提供することである。さらに、このアルゴリズムは、障害状態７６を、すなわち障害タイプ８０（図４）と障害場所８２（図４）とを、正確に認識できるべきであり、また障害状態の各々の重大さ、すなわち重症度レベル７８（図４）を特徴付けることが可能であるべきである。

理想的には、タスク１１８の実行は、変圧器２６のうちの１つの状態を、すなわち正常状態７０（図２）と、例外７４（図５）の１つを表す異常状態７２（図３）とのうちの１つを検出する。タスク１１８が異常状態７２を決定すると、分析エンジン３４はさらに、例外７４の１つから障害タイプ８０と障害場所８２と重症度レベル７８とを識別する。

タスク１１８に応じてタスク１２０が実行される。タスク１２０で、分析エンジン３４は、状態を通知エンジン３８に伝達する。タスク１２０に続いてデータ分析プロセス３６は終了する。

図８ａおよび８ｂは、本発明による通知プロセス４０の流れ図を示す。通知プロセス４０は、典型的には例外７４（図５）のうちの１つの第１の（最初の）事例についてのみ、通知される必要のある責任関係者５９（図１）に通知するために通知エンジン３８（図１）によって実行される。ＤＧＡユニット２８（図１）は例えば４時間またはそれ以下の時間内にデータ要素５８（図１）の他のサンプルを採取しようとしているので、サンプルが同じ例外７４を示そうとする見込みは高い。したがって、通知エンジン３８は、以下に論じられる通知の肯定応答に関連しておよび／または例外７４の処置に関連して、問題が起こらなければ、例外７４の所定の１つに関して１回だけ通知する。通知プロセス４０は、データ要素５８のサンプリングがオンラインで行われるか、手動サンプリングと処理システム３０（図１）へのデータの手動入力とによって行われるかにかかわらず、実行される。

手動入力されたデータ要素５８に対する通知プロセス４０の実行に応じて、予測保守スケジュール（図示せず）は調整されることが可能であり、保守情報および推奨が生成され得る。このような保守情報は、油の品質と変圧器の状態（正常状態または障害状態）と障害の場所およびタイプと次のサンプルが採取されるべき時とを含み得るであろう。サンプリング間隔を含む予測保守スケジュールは、責任関係者５９（図１）、コンピュータ化された保守管理システムなどに伝達され得るであろう。それからこのようにして、ワークプランナーおよびスケジューラは、次の推奨された間隔で変圧器２６（図１）のうちの特定の１つの状態をサンプリングするために作業命令を発行し得る。

通知プロセス４０はタスク１２２から始まる。タスク１２２で、通知エンジン３８は、変圧器２６のうちの特定の１つの状態を受信する。すなわち、通知プロセス４０は、分析プロセス３６（図７）の結果を受信する。

タスク１２２に応じて、問合せタスク１２６が実行される。問合せタスク１２６で、通知エンジン３８は、受信された状態が例外７４（図４）のうちの１つの第１の事例を明示しているかどうかを決定する。この例では、通知エンジン３８は、如何なる可能な障害状態７６（図５）も「６」未満の重症度レベル７８（図５）を示しているかどうかを決定するために、タスク１２２で受信された結果を精査する。６という重症度レベル７８が、可能な障害状態７６のいずれに関しても正常状態７０（図２）を示すことは想起されるべきである。これに対して６未満の重症度レベル７８、すなわち１から５までの重症度レベルは、例外７４（図５）の１つに関して異常状態７２（図３）を示す。その結果、問合せタスク１２６は重症度７８の数値が１、２、３、４または５であるいかなる障害状態７６（図５）に関しても探索する。

問合せタスク１２６におけるプロセス４０の実行は、責任関係者（単数または複数）５９（図５）への通知が望まれていない可能性のある多数の状況を、フィルタリング（濾過）する。これらの状況は、変圧器２８の公称運転、例外７４のうちの１つの受信の後続の事例、およびデッドバンド（不動帯）間隔の満了に先立つ重症度レベル７８のうちの１つの減少を含み得る。したがって、問合せタスク１２６の実行は、例外７４のうちの同じ例外の繰り返しの通知または正常状態７０の不必要な通知の伝達を防止する。

受信された状態が例外７４（図４）のうちの１つの第１の事例を明示していないと問合せタスク１２６が決定すると、通知プロセス４０は問合せタスク１２８（以下に論じられる）に進む。しかしながら、例外７４のうちの１つの第１の事例が問合せタスク１２６で決定されると、すなわち重症度レベル７８が６でないと、プロセス４０は問合せタスク１３０に進む。

問合せタスク１３０で、通知エンジン３８（図１）は、問合せタスク１２６で識別された例外７４のうちの１つの重症度が通知プロセス４０の前の繰り返しで確認された前の対応する例外７４に関して増大しているかどうかを決定する。問合せタスク１３０における含意は、障害状態７６（図５）は、すなわち障害タイプ８０と障害場所８２との組み合わせは、変わっていないかもしれないが、重症度レベル７８の観点からのそれの重大さは増加していることである。

障害状態７６のうちの１つの重大さが増加している、すなわち重症度レベル７８の数値が減少していると問合せタスク１３０が決定すると、通知プロセス４０はタスク１３２（図８ｂに示されている）に進む。タスク１３２で、例外７４（すなわち障害タイプ８０、障害場所８２および重症度レベル７８の組み合わせ）の１つを指定する通知６０（図４）が生成される。しかしながら、例外７４のうちの１つの第１の事例が前の例外７４に関して、重大さの増加を表さない、すなわち重症度レベル７８の数値の対応する減少を表さないという決定が行われると、通知プロセス４０は問合せタスク１３４に進む。

問合せタスク１３４で、通知エンジン３８は、例外７４が障害タイプ８０（図５）の新しいタイプを含むかどうかを決定する。この決定は、例外７４の１つを指定する前の通知６０が同じ障害タイプ８０を持って伝達されたかどうかを決定するために、例外データベース４６（図６）にアクセスすることによって行われ得る。例外７４の１つが異なる障害タイプ８０を、すなわち新しい問題の第１の事例を示すことを、通知エンジン３８が問合せタスク１３８で決定すると、通知プロセス４０は再びタスク１３２に進んで、例外７４（障害タイプ８０、障害場所８２および重症度レベル７８の組み合わせ）の１つを指定する通知６０を生成する。しかしながら、例外７４のうちの１つの第１の事例が障害タイプ８０の新しいものを明示していないという決定が行われると、通知プロセス４０は問合せタスク１３６に進む。

問合せタスク１３６で、通知エンジン３８は、例外７４が障害場所８２（図５）の新しいものを含むかどうかを決定する。この決定は、例外７４の１つを指定している前の通知６０が同じ障害場所８２を持って伝達されたかどうかを決定するために例外データベース４６（図６）にアクセスすることによって行われ得る。例外７４の１つが異なる障害場所８２を、すなわち新しい問題の第１の事例を示すことを通知エンジン３８が問合せタスク１３６で決定すると、通知プロセス４０は再びタスク１３２に進んで、例外７４（障害タイプ８０、障害場所８２および重症度レベル７８の組み合わせ）の１つを指定する通知６０を生成する。しかしながら、例外７４のうちの１つの第１の事例が障害場所８２の新しいものを明示していないという決定が行われると、通知プロセス４０は問合せタスク１３８に進む。

タスク１３８では、例外７４の１つが重大さの減少を示す（すなわち、通知プロセス４０の前の繰り返しで確認された例外７４の前の対応する１つより重症度レベル７８に関する高い数値を示す）という決定が達せられる。タスク１２６、１３０、１３４、１３６の実行を通して、完全に新しい例外７４（障害タイプ８０および／または障害場所８２）の第１の事例が識別されたかどうか、あるいは障害状態７６（図５）の１つが前のサンプルから変化しないままに留まっているが、前に発見された例外７４の重大さは増加しているかどうか（すなわち重症度レベル７８の数値はより小さくなっているかどうか）を決定するために、消去法が実行される。もし例外７４の１つがこれらのインジケータを示すことができなければ、タスク１３８は例外７４の１つが重大さの減少を示す（これが１から５までの数値のいずれかの重症度レベル７８の１つにまだ留まってはいるが）と決定する。

タスク１３８で、処理システム３０（図１）のデッドバンド（不動帯）タイマー要素（図示せず）が起動される。デッドバンドは、例外７４の特定の１つに関して処置（通知）が行われるべきでない間隔である。ＤＧＡユニット２８（図１）からのデータ要素５８（図１）は典型的には、変圧器２６（図１）のうちのこのＤＧＡユニットに関連する１つの負荷レベルにしたがう。その結果、ガス２８（図２）の値６６（図２）は、日ごと季節ごとに上昇および下降する可能性がある。このデータは重症度レベル７８の新しいものをトリガーして後続のデータサンプル５８に応じてリセットできる。変圧器２６が本質的に静止状態にあるときに重症度レベル７８の変化ごとの通知を抑制するために、デッドバンドが利用される。デッドバンドは、減少する重症度レベル７８に対して通知エンジン３８が行動する前に、指定された期間中、特定の閾値より下に留まるように重症度レベル７８に要求する。

デッドバンドタイマーの起動に続いて、通知プロセス４０はタスク１４０（図８ｂに示されている）に進む。タスク１４０で、通知エンジン３８は、変圧器２６（図１）のうちの１つの現在状態に関して責任関係者５９（図４）のいずれか１人への通信を抑制する。タスク１４０に続いて、通知プロセス４０の繰り返しは完了してプロセス４０は終了する。もちろん、処理システム３０（図１）の分析エンジン３４（図１）におけるデータ要素５８（図１）の引き続いての受信と分析は、通知プロセス４０の更なる繰り返しという結果をもたらすであろう。

問合せタスク１２６に戻ると、例外７４のうちの１つの第１の事例を明示していない状況が発生する可能性がある。これらの状況は、変圧器２８の正常状態７２（図２）（すべての重症度レベル７８が６という数値を有する）；例外７４のうちの１つの受信の後続の事例（重症度レベル７８が１から５までの数値のいずれかであって、責任関係者（単数または複数）５９が前に通知されている）；または１から５までの数値を示す重症度レベル７８の１つから６という重症度レベルへの復帰；を含み得る。この結果、問合せタスク１２６への否定応答は、問合せタスク１２８への進行という結果をもたらした。

問合せタスク１２８では、重症度レベル７８が例外７４の前の対応する１つに関して正常に戻っているか（すなわち重症度レベル７８が６であるか）どうかに関する決定が行われる。すなわち、問合せタスク１２８は、前に識別された例外７４の１つに関して１から５までの重症度レベル７８の１つから６という重症度レベル（正常）への復帰が存在する状況に関して監視する。重症度レベル７８が正常に復帰したという決定がタスク１２８で行われると、通知プロセス４０は問合せタスク１４１に進む。

問合せタスク１４１では、例外７４のこの特定の１つに関するデッドバンドタイマーが前に起動されたかどうかに関する決定が行われる。デッドバンドタイマーが前に起動されていなかったとき、プロセス４０はタスク１３８に進んで、デッドバンドタイマーを起動し、これに続いてプロセス４０のこの現在の繰り返しを完了させる。再びこのデッドバンドは、変圧器状態が２つの異なる重症度レベル７８間を移行中であるとき、また１日のうちの負荷変動がガスレベルを上昇・降下させそうであるとき、責任関係者５９が迷惑通知６０（図１）を受信するのを防止するように課される。

しかしながら、例外７４のうち前の１つに対応するこの状況に関してデッドバンドタイマーが前に起動されたという決定が問合せタスク１４１で行われると、通知プロセス４０は問合せタスク１４２に進む（図８ｂに示されている）。

問合せタスク１４２で、通知エンジン３８は、デッドバンドすなわち前に設定された時間間隔が満了したかどうかを決定する。デッドバンドが満了しなかったことを通知エンジン３８が問合せタスク１４２で決定すると、プログラム制御はタスク１４０に進んで、責任関係者５９の如何なる人への通信も抑制し、これに続いて通知プロセス４０の現在の繰り返しを終了させる。

しかしながら、デッドバンドが満了したことを通知エンジン３８が問合せタスク１４２で決定すると、プロセス制御はタスク１３２に進み、そこで責任関係者（単数または複数）５９に重症度の減少を通知するために通知６０（図４）が生成される。

問合せタスク１２８に戻り、重症度レベル７８が例外７４の前の対応する１つに関して正常（すなわち６）に戻らなかったことを問合せタスク１２８が確認すると、変圧器２６が予定通りに運転しているか、受信された例外７４の１つが例外７４のうちの同じ例外の受信の後続の事例であるかどちらかである。どちらの場合にも、繰り返しの通知および／または不必要な通知を回避するために、責任関係者（単数または複数）への通知は選択的に抑制されるべきである。この結果、プログラム制御は問合せタスク１４３（図８ｂに示されている）に進む。

問合せタスク１４３では、例外７４のうちの同じ例外の後続の事例が受信されたかどうかに関する決定が行われる。例外７４のうちの同じ例外の後続の事例が受信されなかったという決定が行われると、すなわち変圧器２６が予定通りに動作していると、通知プロセス４０はタスク１４０に進み、そこで正常状態７０の通知は抑制され、続いてプロセス４０は終了する。しかしながら、例外７４のうちの同じ例外の後続の事例が受信されたという決定が問合せタスク１４３で行われると、通知プロセス４０は問合せタスク１４４に進む。

問合せタスク１４４では、デッドバンドタイマーが前に起動されたかどうかに関する決定が行われる。すなわち、問合せタスク１４４は、例外７４のうちの１つの第１の事例がタスク１３８でデッドバンドタイマーを起動したかどうかを決定する。デッドバンドタイマーが前にセットされなかったという決定が行われると、プロセス４０は再びタスク１４０に進み、責任関係者（単数または複数）５９（図１）への通知を抑制してプロセス４０は終了する。しかしながらデッドバンドタイマーが前にセットされたという決定が行われると、プロセス４０は問合せタスク１４２に進み、デッドバンドが満了したかどうかを決定し、満了であればタスク１３２で通知６０の生成を可能にし、満了でなければタスク１４０で通知を抑制する。この結果、処理タスク１４４、１４２は、ａ）増加している重症度（問合せタスク１３０）、新しい障害タイプ（問合せタスク１３４）および／または新しい障害場所（問合せタスク１３６）を示した例外７４のうちの前に識別された例外の後続の事例；またはｂ）重症度が減少した例外７４のうちの前に識別された例外の後続の事例およびデッドバンド間隔が終了したかどうか、を明らかにする。

上記の動作は、例外７４のうちの１つの第１の事例の際に、あるいは適当なデッドバンド間隔に続く例外７４のうちの１つの重大さの減少の際に、タスク１３２で通知６０を生成する。タスク１３２に応じて、タスク１４５が実行される。

タスク１４５で、通知エンジン３８は、検出された例外７４の特定の１つに関連する１人以上の責任関係者５９を選択するためにコンタクトリストデータベース（図５）にアクセスする。タスク１４５における１人以上の責任関係者５９の選択に続いてプログラム制御はタスク１４６に進む。

タスク１４６で通知エンジン３８は、タスク１３２で生成された通知６０（図１）の１つを責任関係者５９の選択された１人以上に伝達する。

タスク１４６に応じて、タスク１４７が実行される。タスク１４７で、通知エンジン３８は、通知６０の受信の、責任関係者５９の選択された１人からの肯定応答６１（図１）に関して監視するため、また例外７４の処置１１４（図６）に関して監視するために通知監視サブプロセスを実行する。タスク１４７に続いて、通知プロセス４０の繰り返しは完了し、プロセスは終了する。他の変圧器２６（図１）に関する例外７４を特徴付ける他の異常状態７２が通知プロセス４０の更なる繰り返しという結果を引き起こすであろうことは無論である。

通知プロセス４０は、説明の明瞭さのために、例外７４のうちの１つの例外の第１の、および／または後続の事例の明示と識別とに関連して説明されている。しかしながら、変圧器２６の１つがデータ分析プロセス３８（図７）の１回の繰り返しの際に多数の例外７４を示している可能性があることは理解されるべきである。代替として、例外７４のうちの前に識別されたもう１つの例外に関して重症度の減少が存在するもう１つの状況があり得る。その結果、データ分析プロセス３６（図７）の結果から得られ、タスク１２２で受信された変圧器２６（図１）の状態に存在し得る多数の例外７４の各々に関して、通知プロセス４０の種々の処理ステップが実行され得る。上記の処理ステップの繰り返された反復は、障害状態の各々がそれ自身の関連重症度レベル７８、重症度レベル７８の合併、または重症度レベル７８の最も重大なものの単一のリストアップによって、多数の障害状態７６（図４）を反映するためにタスク１３２で更新される通知６０という結果をもたらし得るであろう。

さらに通知プロセス４０は、本発明の理解を伝えるために、段階的で明確な仕方で説明された。当業者は、上記の動作に共通な結果を与える通知プロセス４０の動作に大きな変化が存在し得ることを認めるであろう。これらの共通の結果は、適切な責任関係者（単数または複数）への例外７４（障害タイプ／障害場所／重症度レベル）の第１の事例の通知、適当なデッドバンド間隔に続く例外７４のうちの１つの例外の減少した重症度の通知、同じ例外７４の後続の事例の通知の抑制、および変圧器２６が予定通りに動作しているときの責任関係者への通知の抑制である。このような選択的通知は、人間によって精査されなくてはならないデータの量を非常に最小限にする。

図９は、通知プロセス４０（図８ａ、８ｂ）の通知監視サブプロセス１４８の流れ図を示す。通知監視サブプロセス１４８は、責任関係者５９（図１）の１人への通知６０（図１）の伝達に応じて実行される。通知監視サブプロセス１４８の活動をよりよく理解するために、サブプロセス１４８に関連する例外データベース４６（図６）に注意が向けられるべきである。

サブプロセス１４８は、タスク１５０から始まる。タスク１５０で、通知エンジン３８は、肯定応答タイマー５０（図１）を起動する。肯定応答タイマー５０は、特定の予め決められた責任関係者５９が通知６０の受信を肯定応答することになっているウィンドウまたは期間を測定する。肯定応答タイマー５０は、通知６０が通知プロセス４０のタスク１４６において責任関係者５９に伝達されたときに起動される。

タスク１５０に続いてタスク１５２が実行される。タスク１５２で、通知エンジン３８は、施設２０（図１）の方針と手順とにしたがって通知６０に肯定応答することを要求される責任関係者５９の１人からの肯定応答６１（図１）に関して監視する。

タスク１５２に関連して問合せタスク１５４が実行される。問合せタスク１５４で通知エンジン３８は、肯定応答６１が受信されたかどうかを決定する。肯定応答６１がタスク１５４で受信されると、タスク１５６が実行される。しかしながら、通知エンジン３８が問合せタスク１５４で肯定応答６１が受信されなかったことを確認すると、サブプロセス１４８は問合せタスク１６０に進む。

タスク１５６で、肯定応答６１は、例外データベース４６の肯定応答セクション９２に記録される。データベース４６（図６）に示されているように第１のエントリ１８８（図６）の第１の通知６０（ＮＯＴＩＣＥ１）は、肯定応答６１が受信されたことを明らかにし、肯定応答フィールド１０６に配置された文字「Ｙ」によって例示される。タスク１５６に続いて、通知監視サブプロセス１４８は、以下に論じられる一連の処置活動の最初であるタスク１５８に進む。

肯定応答６１を受信できなかったことに続く問合せタスク１６０で、通知エンジン３８は、肯定応答タイマー５０が満了したかどうかを決定する。言い換えれば、問合せタスク１６０は、通知６０の受信の肯定応答のために必要とされる間隔が満了したかどうかを確認する。肯定応答タイマー５０が満了しないと、プログラム制御はタスク１６２に進む。

タスク１６２で、通知エンジン３８は、責任関係者５９の選択された１人に通知６０を再伝達する。それからサブプロセス１４８は、タスク１５２にループバックして肯定応答６１に関する監視を続行する。タスク１６２は、通知６０を再伝達するために肯定応答タイマー５０によって測定された時間間隔以内で定期的に実行され得る。

タスク１６０、１６２に関連してデータベース４６（図６）を参照すると、第３のエントリ１６４で識別される通知６０（ＮＯＴＩＣＥ３）は、肯定応答６１が受信されなかったことを明らかにし、肯定応答フィールド１０６に配置された文字「Ｎ」によって例示される。この結果、タスク１６２の実行を介して通知６０（ＮＯＴＩＣＥ３）は、責任関係者５９の選択された１人に、すなわち例外データベース４６の第４のエントリ１６６によって表される保守チーム８８に、再伝達される。

肯定応答タイマー５０が問合せタスク１６０で満了になると、プログラム制御は問合せタスク１６８に進む。問合せタスク１６８で、通知エンジン３８は、通知６０が責任関係者５９の次の１人に転送されるべきかどうかを決定する。通知６０が問合せタスク１６８で転送されるべきでないとき、タスク１７０が実行され得る。タスク１７０で通知誤り警告が通知され得る。この通知誤り警告は、例外データベース４６に記録され得る、および／またはコントロールセンター管理者に送られ得る、あるいは即座の訂正に繋がり得る。タスク１７０に続いて通知監視サブプロセス１４８は終了する。しかしながら、通知６０が転送されるべきであるという決定が問合せタスク１６８で行われると、サブプロセス１４８はタスク１７２に進む。

タスク１７２で、通知エンジン３８は、コンタクトリストデータベース４４（図５）から次の責任関係者を選択できる。このシナリオでは、次の責任関係者は、予め決められたバックアップ責任関係者９０（図５）である。

タスク１７２に関連して実行されるタスク１７４は、タスク１７２で、選択された責任関係者５９の次の１人、すなわちバックアップ責任関係者９０に、通知６０を転送することを通知エンジン３８にさせる。タスク１７４に続いて、プログラム制御は、タスク１５０にループバックして肯定応答タイマー５０（図１）を起動し、肯定応答６１（図１）に関して監視する。

上記の通知活動の意図は、意図された受信者すなわち責任関係者５９の１人が例外７４（図５）の１つについての通知６０を実際に受信したことを保証することである。いったん肯定応答６１が受信されてタスク１５６で例外データベース４６（図６）に記録されると、この責任関係者５９は、今度は特定の例外７４の処置に責任を有する。したがって、通知監視サブプロセス１４８の通知活動は、今度は電気公益事業施設２０（図１）によって開発された手順にしたがって適切な処置を取らなくてはならない責任関係者５９への特定の例外７４に関する責任を示す。

上記に簡潔に言及されたように、例外７４（図５）の特定の１つに関する処置活動は、タスク１５６における例外データベース４６（図６）の肯定応答セクション９２（図６）への肯定応答６１（図１）の記録に続いて実行される。したがって、タスク１５６に続いて通知監視サブプロセス１４８は一連の処置活動における最初であるタスク１５８に進む。

タスク１５８で、通知エンジン３８は、処置タイマー５２（図１）を起動する。処置タイマー５２は、通知エンジン３８が責任関係者５９から特定の例外７４の処置１１４（図６）を受信することになっている間、ウィンドウまたは期間を測定する。処置タイマー５２は、肯定応答６１（図１）がタスク１５６で通知エンジン３８によって受信されたときに起動される。

タスク１５８に続いて、タスク１７８が実行される。タスク１７８で、通知エンジン３８は、通知６０が伝達された、そして肯定応答６１が受信された責任関係者５９の１人からの処置１１４（図６）の受信に関して監視する。

タスク１７８に関連して問合せタスク１８０が実行される。問合せタスク１８０において、通知エンジン３８は、処置１１４が受信されたかどうかを決定する。処置１１４が問合せタスク１８０で受信されると、タスク１８２が実行される。しかしながら、処置１１４が受信されなかったことを問合せタスク１８０で通知エンジン３８が確認すると、サブプロセス１４８は、問合せタスク１８４に進む。

タスク１８２で、処置１１４は、例外データベース４６の処置セクション９４に記録される。データベース４６（図６）に示されるように、第１のエントリ１８８は、処置１１４が記録されたことを明らかにし、処置フィールド１１３に配置されたフレーズ「正常な監視を続行する」によって例示される。同様に、第５のエントリ１９０は、処置１１４が記録されたことを明らかにし、フレーズ「監視を続行し、予定通り保守を実行する」によって例示される。タスク１８２に続いて、通知監視サブプロセス１４８は、この特定の通知６０に関して終了する。

問合せタスク１８４では、問合せタスク１８０で処置１１４を受信しそこなった後に、通知エンジン３８は、処置タイマー５２（図１）が満了したかどうかを決定する。言い換えれば、問合せタスク１８４は、例外データベース４６（図６）に記録された例外７４の１つを処置するために必要とされる間隔が満了したかどうかを確認する。処置タイマー５２が満了しないとき、プログラム制御はタスク１７８にループバックして処置１１４に対する監視を続行する。しかしながら、処置タイマー５２が満了すると、通知監視サブプロセス１４８はタスク１８６に進む。

処置タイマー５２（図１）の満了に続くタスク１８６で、通知エンジン３８は、選択された１人以上の責任関係者５９に通知６０を気づかせる。タスク１８６は、責任関係者（単数または複数）５９に通知６０を再伝達することによって、あるいは通知６０を識別する他の何らかのメッセージを伝達することによって遂行され得る。処置誤り警告が通知され得る。この処理誤り警告は例外データベース４６に記録され得る、および／またはコントロールセンター管理者に送られ得る、あるいは即座の訂正に繋がり得る。タスク１８６に続いて、プログラム制御は、タスク１５８にループバックして処置タイマー５２を再起動し、処置１１４（図６）に対して監視する。

したがって、通知プロセス４０（図８ａ、８ｂ）と通知監視サブプロセス１４８（図９）との実行は、電気公益事業施設２０（図１）内で保守される監視された変圧器２６（図１）に発生する異常状態７２（図３）の場合に適切な処置を取ることに関する責任を保証する。

要約すれば本発明は、装置の状態の選択的通知のための方法およびシステムについて教示する。選択的通知は、装置の正常状態に対する例外の第１の事例の際に適切な責任関係者に通知することに基づいている。本発明は、多数の障害状態とこれらの障害状態の多数の重症度レベルとに関して適切な責任関係者に通知を提供する。しかしながら、障害状態（障害タイプと障害場所）または重症度レベルが変化しなければ、冗長な通知が回避され得るように、通知エンジンは通知を送らない。すなわち通知エンジンは警告状態に在るが、認識している責任関係者はこの警告状態に今までどおりに気付いているので、通知は抑制され得る。さらに本発明は、要員の責任と問題の解決とを保証するための通知肯定応答および障害状態処置の機構を使用する。変圧器における障害状態の正確な診断と効果的な通知は、交換ユニットの追加投資の繰り延べ、意図されない供給停止により回避されるコスト（代替エネルギー、環境浄化、顧客・付随的損傷、および増加した保険料といった）の点から見てかなりの節約をもたらすことができる。

本発明の好適な実施形態は詳細に図示され説明されてきたが、本発明の精神から、あるいは添付の請求項の範囲から逸脱せずにこれらの実施形態に種々の修正が行われ得ることは、当業者に直ちに明らかになるであろう。例えばここで論じられたプロセスステップは、極めて多くの変更を行うことが可能であり、また提示された順序とは異なる順序で実行されることも可能である。さらに責任関係者の数とレベル、肯定応答ウィンドウ、処置ウィンドウおよびデッドバンドの持続時間は、システムの複雑さ、例外の重症度、ユーザの好みなどにしたがって変えられ得る。

本発明の好適な実施形態は詳細に図示され説明されてきたが、本発明の精神から、あるいは添付の請求項の範囲から逸脱せずにこれらの実施形態に種々の修正が行われ得ることは、当業者に直ちに明らかになるであろう。例えばここで論じられたプロセスステップは、極めて多くの変更を行うことが可能であり、また提示された順序とは異なる順序で実行されることも可能である。さらに責任関係者の数とレベル、肯定応答ウィンドウ、処置ウィンドウおよびデッドバンドの持続時間は、システムの複雑さ、例外の重症度、ユーザの好みなどにしたがって変えられ得る。
［１］
監視装置（２８）によって監視される装置（２６）の状態の選択的通知のための方法（４０）であって、
前記監視装置（２８）からデータ要素（５８）を受信すること（１１６）と、
前記装置（２６）の前記状態を検出するために前記データ要素（５８）を処理すること（４０）と、
前記状態が前記装置（２６）の正常状態（７０）に対する例外（７４）を明示すると決定すること（１２６）と、
前記例外（７４）の決定の第１の事例において前記状態の第１の通知（６０）を責任関係者（５９）に伝達すること（１４６）と、
前記第１の事例に続いて発生する第２の事例であって前記例外（７４）の決定の第２の事例において第２の通知（６０）の伝達を防止すること（１４０）と、
を備える、方法（４０）。
［２］
前記状態が前記装置（２６）の前記正常状態（７０）であることを確認すること（１４３）と、
前記責任関係者（５９）への前記正常状態（７０）の伝達を防止すること（１４０）と、
をさらに備える、［１］に記載の方法（４０）。
［３］
個別の責任関係者（５９）を前記装置（２６）において可能性のある複数の障害状態（７６）に関連付けること（４４）と、
前記伝達動作（１４６）が前記ある障害状態（７６）に関連する前記責任関係者（５９）を前記個別の責任関係者（５９）から選択するように、前記障害状態（７６）の１つを前記例外（７４）から決定すること（１４５）と、
をさらに備える、［１］に記載の方法（４０）。
［４］
前記例外動作から前記決定すること（１２６）は、前記伝達動作（１４６）が障害タイプ（８０）に関連する前記責任関係者（５９）を選択するように、前記ある障害状態（７６）の前記障害タイプ（８０）を識別すること（１３４）を含む、［３］に記載の方法（４０）。
［５］
前記例外動作から前記決定すること（１２６）は、前記伝達動作（１４６）が障害場所（８２）に関連する前記責任関係者（５９）を選択するように、前記ある障害状態（７６）の前記障害場所（８２）を識別すること（１３６）を含む、［３］に記載の方法（４０）。
［６］
個別の責任関係者（５９）を前記装置（２６）において可能性のある障害状態（７６）に関する重症度レベル（７８）に関連付けること（４４）と、
前記伝達動作（１４６）が前記ある重症度レベル（７８）に関連する前記責任関係者（５９）を前記個別の責任関係者（５９）から選択するように、前記重症度レベル（７８）の１つを前記例外（７４）から決定すること（１３０）と、
をさらに備える、［１］に記載の方法（４０）。
［７］
前記データ要素（５８）は第１のデータ要素（６２）であり、前記例外（７４）は第１の例外であって、前記方法（４０）は
前記監視装置（２８）から第２のデータ要素（６３）を受信すること（１１６）と、
前記装置（２６）の第２の状態を検出するために前記第２のデータ要素（６３）を処理すること（１１８）と、
前記第２の状態が前記第１の例外（７４）とは異なる第２の例外であると決定すること（１２６）と、
前記第２の例外の決定の際に前記第２の状態の第３の通知（６０）を転送すること（１４６）と、
をさらに備える、［１］に記載の方法（４０）。
［８］
前記転送動作（１４６）は、前記装置（２６）において可能性のある障害状態（７６）に関連する第２の責任関係者（５９）に前記第３の通知を転送し、前記障害状態（７６）は前記第２の例外によって明示される、［７］に記載の方法（４０）。
［９］
前記第１の例外（７４）は前記装置（２６）において可能性のある障害状態（７６）の第１の重症度レベル（７８）を明示し、前記第２の例外（７４）は前記障害状態（７６）の第２の重症度レベル（７８）を明示し、前記転送（１４６）動作は前記第２の重症度レベル（７８）に関連する第２の責任関係者（５９）に前記第３の通知を転送する、［７］に記載の方法（４０）。
［１０］
前記第２の重症度レベル（７８）が前記第１の重症度レベル（７８）より大きな前記障害状態（７６）の重大さを示すと決定すること（１３０）と、
前記第２の責任関係者を、予め決められた権限の連鎖（８４、８６、８８）における前記責任関係者より大きな権限を有するものと識別すること（１４５）と、
をさらに備える、［９］に記載の方法（４０）。
［１１］
前記第１の例外（７４）は前記装置（２６）において可能性のある障害状態（７６）の第１の重症度レベル（７８）を明示し、前記第２の例外（７４）は前記障害状態（７６）の第２の重症度レベル（７８）を明示する［７］に記載の方法であって、前記方法は、
前記第２の重症度レベル（７８）が前記第１の重症度レベル（７８）より小さな前記障害状態（７６）の重大さを示すと決定すること（１３０）と、
前記障害状態（７６）が予め決められた継続時間の間で前記第２の重症度レベルにおいて検出されるまで前記転送動作を遅らせること（１３８）と、
をさらに備える、［７］に記載の方法（４０）。
［１２］
前記責任関係者（５９）から前記第１の通知（６０）の受信の肯定応答（６１）を受信すること（１５４）と、
前記肯定応答（６１）を肯定応答データベース（９２）に記録すること（１５６）と、
をさらに備える、［１］に記載の方法（４０）。
［１３］
前記責任関係者（５９）からの前記第１の通知（６０）の受信の肯定応答の欠如を確認すること（１５４）と、
前記確認動作（１５４）に応じて前記第１の通知（６０）を定期的に再伝達すること（１６２）と、
をさらに備える、［１］に記載の方法（４０）。
［１４］
前記責任関係者（５９）からの前記第１の通知（６０）の受信の肯定応答の欠如を確認すること（１５４）と、
前記確認動作（１５４）に応じて前記第１の通知（６０）を第２の責任関係者（５９）に転送すること（１７４）と、
をさらに備える、［１］に記載の方法（４０）。
［１５］
肯定応答ウィンドウ（１６０）の満了に続いて前記転送動作（１７４）を実行することをさらに備え、前記肯定応答ウィンドウは前記責任関係者（５９）が前記第１の通知に肯定応答することになっている間隔を与える、［１４］に記載の方法（４０）。
［１６］
前記責任関係者（５９）から前記例外（７４）の処置（１１４）を受信すること（１８０）と、
前記処置（１１４）を処置データベース（１１３）に保存すること（１８２）と、
をさらに備える、［１］に記載の方法（４０）。
［１７］
前記責任関係者（５９）から前記例外（７４）の処置（１１４）を受信しそこなうこと（１８０）と、
前記責任関係者（５９）に前記第１の通知（６０）を気づかせること（１８６）と、
をさらに備える、［１］に記載の方法（４０）。
［１８］
前記装置（２６）は複数の装置（２６）の１つであり、前記監視装置（２８）は複数の監視装置（２８）の１つであり、前記方法（４０）は共通の処理システム（３０）において前記複数の装置（２８）の各々に関して前記受信、処理、決定、伝達および防止の動作を実行することをさらに備える、［１］に記載の方法（４０）。
［１９］
前記装置（２６）は公益事業会社（２０）によって保守される変圧器であり、前記監視装置（２８）は溶解ガス監視ユニットであり、前記データ要素（５８）は変圧器油内の溶解ガスの現在値であり、前記方法（４０）は前記公益事業会社（２０）の処理システム（３０）において前記受信、処理、決定、伝達および防止の動作を実行することをさらに備える、［１］に記載の方法（４０）。
［２０］
複数の装置（２６）のうちのそれぞれの状態の選択的通知のためのシステム（３０）であって、前記複数の装置のそれぞれが複数の監視装置（２８）のうちの１つによって監視され、
前記監視装置（２８）のそれぞれに関して、分析器（３４）が前記各監視装置（２８）からデータ要素（５８）を受信し（１１６）、前記複数の装置（２６）のうちの一つと関連付けられた前記状態を検出するために前記データ要素（５８）を処理し（１１８）、前記状態が正常状態（７０）と前記正常状態（７０）に対する例外（７４）とのうちの１つを明示することを決定するように、前記複数の監視装置のそれぞれとの通信のために構成された分析器（３４）と、
通知エンジン（３８）は、前記例外（７４）の決定（１２６）の第１の事例において前記状態の第１の通知（６０）を責任関係者（５９）に伝達し、前記通知エンジン（３８）は、前記例外（７４）の決定（１２６）の、前記第１の事例に続いて発生する第２の事例において、前記状態の第２の通知（６０）の伝達を防止し（１４０）、前記通知エンジン（３８）は、前記正常状態（７０）の決定の際に前記責任関係者（５９）との通信を防止する（１４０）、前記分析器（３４）と通信する前記通知エンジン（３８）と、
を備えるシステム（３０）。
［２１］
前記複数の装置（２６）において可能性のある障害状態（７６）との個別責任関係者（５９）の関連付けのための、前記通知エンジン（３８）と通信するコンタクトリストデータベース（４４）をさらに備えており、前記例外（７４）は前記障害状態（７６）の１つを明示し、前記通知エンジン（３８）は前記ある障害状態（７６）に関連する前記責任関係者（５９）を前記個別責任関係者（５９）から選択する（１４５）、［２０］に記載のシステム（３０）。
［２２］
前記コンタクトリストデータベース（４４）は前記ある障害状態（７６）の複数の重症度レベル（７８）に関して前記個別責任関係者（５９）の権限の連鎖を確立しており、前記例外（７４）は前記重症度レベル（７８）の１つを明示し、前記通知エンジン（３８）は前記重症度レベル（７８）の前記１つに関連する前記責任関係者（５９）を選択する（１４５）、［２１］に記載のシステム（３０）。
［２３］
前記第１の通知（６０）の受信の、前記責任関係者（５９）からの肯定応答（６１）を記録するために前記通知エンジン（３８）と通信する肯定応答データベース（９２）をさらに備える、［２０］に記載のシステム（３０）。
［２４］
前記責任関係者（５９）からの前記例外（７４）の処置（１１４）を保持するための、前記通知エンジン（３８）と通信する処置データベース（１１３）をさらに備える、［２０］に記載のシステム（３０）。
［２５］
監視装置（２８）によって監視される装置（２６）の状態の選択的通知のための方法（４０）であって、
前記監視装置（２８）からデータ要素（５８）を受信すること（１１６）と、
前記装置（２６）の前記状態を検出するために前記データ要素（５８）を処理すること（１１８）と、
前記状態が前記装置（２６）の正常状態（７０）に対する例外（７４）を明示することを決定すること（１２６）と、
前記例外（７４）の決定の第１の事例において前記状態の第１の通知（６０）を責任関係者（５９）に伝達すること（１４６）と、
前記第１の事例に続いて発生する第２の事例であって前記例外（７４）の決定の第２の事例において第２の通知（６０）の伝達を防止すること（１４０）と、
前記第１の通知（６０）の受信の、前記責任関係者（５９）からの肯定応答（６１）と前記肯定応答（６１）の欠如とのうちの１つを発見すること（１５４）と、
前記肯定応答（６１）の発見の際に前記肯定応答（６１）を通知データベース（４６）に記録すること（１５６）と、
前記肯定応答（６１）の前記欠如の際に前記第１の通知（６０）を前記責任関係者（５９）に定期的に再伝達すること（１６２）と、
を備える方法（４０）。
［２６］
前記状態が前記装置（２６）の前記正常状態（７０）であることを確認すること（１４３）と、
前記責任関係者（５９）への前記正常状態（７０）の伝達を防止すること（１４０）と、
をさらに備える、［２５］に記載の方法（４０）。
［２７］
前記データ要素（５８）は第１のデータ要素（６２）であり、前記例外（７４）は第１の例外であって、
前記方法（４０）は、
前記監視装置（２８）から第２のデータ要素（６３）を受信すること（１１６）と、
前記装置（２６）の第２の状態を検出するために前記第２のデータ要素（６３）を処理すること（１１８）と、
前記第２の状態が前記第１の例外とは異なる第２の例外（７４）であると決定すること（１２６）と、
前記第２の例外（７４）の決定の際に前記第２の状態の第３の通知（６０）を転送すること（１４６）と、
をさらに備える、［２５］に記載の方法（４０）。
［２８］
前記肯定応答（６１）の前記欠如の際に、肯定応答ウィンドウ（５０）の満了に続いて第２の責任関係者（５９）に前記第１の通知（６０）を転送すること（１７４）をさらに備え、前記肯定応答ウィンドウは前記責任関係者（５９）が前記第１の通知（６０）に肯定応答することになっている間隔を与える、［２５］に記載の方法（４０）。
［２９］
前記責任関係者（５９）からの前記例外（７４）の処置（１１４）の受信と前記処置（１１４）の受信の不成功とのうちの１つを認識すること（１８０）と、
前記処置（１１４）の受信の際に前記処置（１１４）を通知データベース（４６）に保存すること（１８２）と、
前記処置（１１４）の前記受信不成功の際に前記責任関係者（５９）に前記第１の通知（６０）を気づかせること（１８６）と、
をさらに備える、［２５］に記載の方法（４０）。

Claims (29)

1. 監視装置（２８）によって監視される装置（２６）の状態の選択的通知のための方法（４０）であって、
   前記監視装置（２８）からデータ要素（５８）を受信すること（１１６）と、
   前記装置（２６）の前記状態を検出するために前記データ要素（５８）を処理すること（４０）と、
   前記状態が前記装置（２６）の正常状態（７０）に対する例外（７４）を明示すると決定すること（１２６）と、
   前記例外（７４）の決定の第１の事例において前記状態の第１の通知（６０）を責任関係者（５９）に伝達すること（１４６）と、
   前記第１の事例に続いて発生する第２の事例であって前記例外（７４）の決定の第２の事例において第２の通知（６０）の伝達を防止すること（１４０）と、
   を備える、方法（４０）。
2. 前記状態が前記装置（２６）の前記正常状態（７０）であることを確認すること（１４３）と、
   前記責任関係者（５９）への前記正常状態（７０）の伝達を防止すること（１４０）と、
   をさらに備える、請求項１に記載の方法（４０）。
3. 個別の責任関係者（５９）を前記装置（２６）において可能性のある複数の障害状態（７６）に関連付けること（４４）と、
   前記伝達動作（１４６）が前記ある障害状態（７６）に関連する前記責任関係者（５９）を前記個別の責任関係者（５９）から選択するように、前記障害状態（７６）の１つを前記例外（７４）から決定すること（１４５）と、
   をさらに備える、請求項１に記載の方法（４０）。
4. 前記例外動作から前記決定すること（１２６）は、前記伝達動作（１４６）が障害タイプ（８０）に関連する前記責任関係者（５９）を選択するように、前記ある障害状態（７６）の前記障害タイプ（８０）を識別すること（１３４）を含む、請求項３に記載の方法（４０）。
5. 前記例外動作から前記決定すること（１２６）は、前記伝達動作（１４６）が障害場所（８２に関連する前記責任関係者（５９）を選択するように、前記ある障害状態（７６）の前記障害場所（８２）を識別すること（１３６）を含む、請求項３に記載の方法（４０）。
6. 個別の責任関係者（５９）を前記装置（２６）において可能性のある障害状態（７６）に関する重症度レベル（７８）に関連付けること（４４）と、
   前記伝達動作（１４６）が前記ある重症度レベル（７８）に関連する前記責任関係者（５９）を前記個別の責任関係者（５９）から選択するように、前記重症度レベル（７８）の１つを前記例外（７４）から決定すること（１３０）と、
   をさらに備える、請求項１に記載の方法（４０）。
7. 前記データ要素（５８）は第１のデータ要素（６２）であり、前記例外（７４）は第１の例外であって、前記方法（４０）は
   前記監視装置（２８）から第２のデータ要素（６３）を受信すること（１１６）と、
   前記装置（２６）の第２の状態を検出するために前記第２のデータ要素（６３）を処理すること（１１８）と、
   前記第２の状態が前記第１の例外（７４）とは異なる第２の例外であると決定すること（１２６）と、
   前記第２の例外の決定の際に前記第２の状態の第３の通知（６０）を転送すること（１４６）と、
   をさらに備える、請求項１に記載の方法（４０）。
8. 前記転送動作（１４６）は、前記装置（２６）において可能性のある障害状態（７６）に関連する第２の責任関係者（５９）に前記第３の通知を転送し、前記障害状態（７６）は前記第２の例外によって明示される、請求項７に記載の方法（４０）。
9. 前記第１の例外（７４）は前記装置（２６）において可能性のある障害状態（７６）の第１の重症度レベル（７８）を明示し、前記第２の例外（７４）は前記障害状態（７６）の第２の重症度レベル（７８）を明示し、前記転送（１４６）動作は前記第２の重症度レベル（７８）に関連する第２の責任関係者（５９）に前記第３の通知を転送する、請求項７に記載の方法（４０）。
10. 前記第２の重症度レベル（７８）が前記第１の重症度レベル（７８）より大きな前記障害状態（７６）の重大さを示すと決定すること（１３０）と、
    前記第２の責任関係者を、予め決められた権限の連鎖（８４、８６、８８）における前記責任関係者より大きな権限を有するものと識別すること（１４５）と、
    をさらに備える、請求項９に記載の方法（４０）。
11. 前記第１の例外（７４）は前記装置（２６）において可能性のある障害状態（７６）の第１の重症度レベル（７８）を明示し、前記第２の例外（７４）は前記障害状態（７６）の第２の重症度レベル（７８）を明示する請求項７に記載の方法であって、前記方法は、
    前記第２の重症度レベル（７８）が前記第１の重症度レベル（７８）より小さな前記障害状態（７６）の重大さを示すと決定すること（１３０）と、
    前記障害状態（７６）が予め決められた継続時間の間で前記第２の重症度レベルにおいて検出されるまで前記転送動作を遅らせること（１３８）と、
    をさらに備える、請求項７に記載の方法（４０）。
12. 前記責任関係者（５９）から前記第１の通知（６０）の受信の肯定応答（６１）を受信すること（１５４）と、
    前記肯定応答（６１）を肯定応答データベース（９２）に記録すること（１５６）と、
    をさらに備える、請求項１に記載の方法（４０）。
13. 前記責任関係者（５９）からの前記第１の通知（６０）の受信の肯定応答の欠如を確認すること（１５４）と、
    前記確認動作（１５４）に応じて前記第１の通知（６０）を定期的に再伝達すること（１６２）と、
    をさらに備える、請求項１に記載の方法（４０）。
14. 前記責任関係者（５９）からの前記第１の通知（６０）の受信の肯定応答の欠如を確認すること（１５４）と、
    前記確認動作（１５４）に応じて前記第１の通知（６０）を第２の責任関係者（５９）に転送すること（１７４）と、
    をさらに備える、請求項１に記載の方法（４０）。
15. 肯定応答ウィンドウ（１６０）の満了に続いて前記転送動作（１７４）を実行することをさらに備え、前記肯定応答ウィンドウは前記責任関係者（５９）が前記第１の通知に肯定応答することになっている間隔を与える、請求項１４に記載の方法（４０）。
16. 前記責任関係者（５９）から前記例外（７４）の処置（１１４）を受信すること（１８０）と、
    前記処置（１１４）を処置データベース（１１３）に保存すること（１８２）と、
    をさらに備える、請求項１に記載の方法（４０）。
17. 前記責任関係者（５９）から前記例外（７４）の処置（１１４）を受信しそこなうこと（１８０）と、
    前記責任関係者（５９）に前記第１の通知（６０）を気づかせること（１８６）と、
    をさらに備える、請求項１に記載の方法（４０）。
18. 前記装置（２６）は複数の装置（２６）の１つであり、前記監視装置（２８）は複数の監視装置（２８）の１つであり、前記方法（４０）は共通の処理システム（３０）において前記複数の装置（２８）の各々に関して前記受信、処理、決定、伝達および防止の動作を実行することをさらに備える、請求項１に記載の方法（４０）。
19. 前記装置（２６）は公益事業会社（２０）によって保守される変圧器であり、前記監視装置（２８）は溶解ガス監視ユニットであり、前記データ要素（５８）は変圧器油内の溶解ガスの現在値であり、前記方法（４０）は前記公益事業会社（２０）の処理システム（３０）において前記受信、処理、決定、伝達および防止の動作を実行することをさらに備える、請求項１に記載の方法（４０）。
20. 複数の装置（２６）のうちのそれぞれの状態の選択的通知のためのシステム（３０）であって、前記複数の装置のそれぞれが複数の監視装置（２８）のうちの１つによって監視され、
    前記監視装置（２８）のそれぞれに関して、分析器（３４）が前記各監視装置（２８）からデータ要素（５８）を受信し（１１６）、前記複数の装置（２６）のうちの一つと関連付けられた前記状態を検出するために前記データ要素（５８）を処理し（１１８）、前記状態が正常状態（７０）と前記正常状態（７０）に対する例外（７４）とのうちの１つを明示することを決定するように、前記複数の監視装置のそれぞれとの通信のために構成された分析器（３４）と、
    通知エンジン（３８）は、前記例外（７４）の決定（１２６）の第１の事例において前記状態の第１の通知（６０）を責任関係者（５９）に伝達し、前記通知エンジン（３８）は、前記例外（７４）の決定（１２６）の、前記第１の事例に続いて発生する第２の事例において、前記状態の第２の通知（６０）の伝達を防止し（１４０）、前記通知エンジン（３８）は、前記正常状態（７０）の決定の際に前記責任関係者（５９）との通信を防止する（１４０）、前記分析器（３４）と通信する前記通知エンジン（３８）と、
    を備えるシステム（３０）。
21. 前記複数の装置（２６）において可能性のある障害状態（７６）との個別責任関係者（５９）の関連付けのための、前記通知エンジン（３８）と通信するコンタクトリストデータベース（４４）をさらに備えており、前記例外（７４）は前記障害状態（７６）の１つを明示し、前記通知エンジン（３８）は前記ある障害状態（７６）に関連する前記責任関係者（５９）を前記個別責任関係者（５９）から選択する（１４５、請求項２０に記載のシステム（３０）。
22. 前記コンタクトリストデータベース（４４）は前記ある障害状態（７６）の複数の重症度レベル（７８）に関して前記個別責任関係者（５９）の権限の連鎖を確立しており、前記例外（７４）は前記重症度レベル（７８）の１つを明示し、前記通知エンジン（３８）は前記重症度レベル（７８）の前記１つに関連する前記責任関係者（５９）を選択する（１４５）、請求項２１に記載のシステム（３０）。
23. 前記第１の通知（６０）の受信の、前記責任関係者（５９）からの肯定応答（６１）を記録するために前記通知エンジン（３８）と通信する肯定応答データベース（９２）をさらに備える、請求項２０に記載のシステム（３０）。
24. 前記責任関係者（５９）からの前記例外（７４）の処置（１１４）を保持するための、前記通知エンジン（３８）と通信する処置データベース（１１３をさらに備える、請求項２０に記載のシステム（３０）。
25. 監視装置（２８）によって監視される装置（２６）の状態の選択的通知のための方法（４０）であって、
    前記監視装置（２８）からデータ要素（５８）を受信すること（１１６）と、
    前記装置（２６）の前記状態を検出するために前記データ要素（５８）を処理すること（１１８）と、
    前記状態が前記装置（２６）の正常状態（７０）に対する例外（７４）を明示することを決定すること（１２６）と、
    前記例外（７４）の決定の第１の事例において前記状態の第１の通知（６０）を責任関係者（５９）に伝達すること（１４６）と、
    前記第１の事例に続いて発生する第２の事例であって前記例外（７４）の決定の第２の事例において第２の通知（６０）の伝達を防止すること（１４０）と、
    前記第１の通知（６０）の受信の、前記責任関係者（５９）からの肯定応答（６１）と前記肯定応答（６１）の欠如とのうちの１つを発見すること（１５４）と、
    前記肯定応答（６１）の発見の際に前記肯定応答（６１）を通知データベース（４６）に記録すること（１５６）と、
    前記肯定応答（６１）の前記欠如の際に前記第１の通知（６０）を前記責任関係者（５９）に定期的に再伝達すること（１６２）と、
    を備える方法（４０）。
26. 前記状態が前記装置（２６）の前記正常状態（７０）であることを確認すること（１４３）と、
    前記責任関係者（５９）への前記正常状態（７０）の伝達を防止すること（１４０）と、
    をさらに備える、請求項２５に記載の方法（４０）。
27. 前記データ要素（５８）は第１のデータ要素（６２）であり、前記例外（７４）は第１の例外であって、
    前記方法（４０）は、
    前記監視装置（２８）から第２のデータ要素（６３）を受信すること（１１６）と、
    前記装置（２６）の第２の状態を検出するために前記第２のデータ要素（６３）を処理すること（１１８）と、
    前記第２の状態が前記第１の例外とは異なる第２の例外（７４）であると決定すること（１２６）と、
    前記第２の例外（７４）の決定の際に前記第２の状態の第３の通知（６０）を転送すること（１４６）と、
    をさらに備える、請求項２５に記載の方法（４０）。
28. 前記肯定応答（６１）の前記欠如の際に、肯定応答ウィンドウ（５０）の満了に続いて第２の責任関係者（５９）に前記第１の通知（６０）を転送すること（１７４）をさらに備え、前記肯定応答ウィンドウは前記責任関係者（５９）が前記第１の通知（６０）に肯定応答することになっている間隔を与える、請求項２５に記載の方法（４０）。
29. 前記責任関係者（５９）からの前記例外（７４）の処置（１１４）の受信と前記処置（１１４）の受信の不成功とのうちの１つを認識すること（１８０）と、
    前記処置（１１４）の受信の際に前記処置（１１４）を通知データベース（４６）に保存すること（１８２）と、
    前記処置（１１４）の前記受信不成功の際に前記責任関係者（５９）に前記第１の通知（６０）を気づかせること（１８６）と、
    をさらに備える、請求項２５に記載の方法（４０）。

Images