以下、添付図面及び実施例を用いて本発明をさらに説明する。 好ましい方案は図１に示すように、水力発電ユニットの故障総合診断方法であり、 ステップ１、故障スキャン診断前の準備作業を行い、発電所配置データと、ユニット配置データと、設備配置データと、ＦＭＥＡ故障モード配置データと、診断ワークフロー配置データを取得し、 故障モードと影響解析（ＦＭＥＡ）は全ユニットレベル及び設備レベルの故障モード、故障兆候、故障タイプ、故障原因、特徴パラメータ、重大度、発生度、検出度の故障関連情報特徴に対して標準的な記述を行い、設備システム又は部品間の構造と機能結合関係に従って、ユニットシステムの故障モードと影響解析を確立する診断解析であり、 ステップ１．１、発電所コード、発電所配置データ関連ユニット情報テーブル、発電所配置データｉｄが含まれる発電所配置データを取得し、 発電所配置データ関連ユニット情報テーブルは、ある発電所に含まれるすべてのユニット配置データである。 ステップ１．２、ユニットコード、ユニット配置データ関連設備リスト、ユニット配置データｉｄが含まれるユニット配置データを取得し、 ユニット配置データ関連設備リストは、あるユニットに含まれるすべての設備配置データである。 ステップ１．３、設備名、設備コード、設備配置データに関連されて導入されたシステム設備情報テーブルが含まれる設備配置データを取得し、 設備配置データに関連されて導入されたシステム設備情報テーブルは、ある設備に含まれるすべてのサブ設備である。 ステップ１．４、すべての故障モード情報、設備ロジック情報を取得する。 ステップ２、故障診断を実行し、多種の診断方法を利用して発電所配置データと、ユニット配置データと、設備配置データを診断し、前記診断方法はビッグデータモデルアルゴリズム、ルール推論、故障事例マッチング法とフォルトツリー解析法を含み、本発明が採用する診断方法は従来の診断方法であり、機能紹介は以下の通りである。 診断方法１は、前記フォルトツリー解析法（ＦＴＡ）は、定量解析方法であり、エンジニアが設備の信頼性と安全性の指標を決定し、適切な予防措置を決定するのに役立つことができる。フォルトツリー解析法は通常、ＦＭＥＡ（故障モードと影響解析）などの他の解析法と組み合わせて使用され、解析の正確性と信頼性を高める。フォルトツリー解析法のプロセスは、故障を故障トップイベント、中間イベントと基本イベントの三つのレベルに分け、故障トップイベントは複数の中間イベントを含み、中間イベントは複数の基本イベントを含み、各レベルの故障イベントの間はロジックゲートによって接続されることで、故障解析のツリー構造を形成し、各レベルの故障イベントは、相応な故障兆候に対応する。具体的な解析プロセスは、 システムで発生可能な事故または発生した事故によって提供された情報、またはＦＭＥＡに基づいて、ＦＴＡロジックモデルツリーを作成するＳ１と、 作成したロジックモデルツリーをＦＴＡインスタンス化されたモデルツリーを生成するＳ２と、 ＦＴＡインスタンス化されたモデルツリーは、自身の故障診断アルゴリズムを用いて、アルゴリズムモデル、診断ルール、スクリプト及び測定点データを結合してフォルトツリー全体の解析、演繹を完成し、それによって故障発生確率を得るＳ３とを含む。 ステップＳ１は、具体的には、次のサブステップを含み、 システムで発生可能な事故または発生した事故に基づいて、最も影響の大きいシステム故障をトップイベントとして選定する。そして、フォルトツリーのトップイベントのためにロジック設備と故障診断ツール（アルゴリズムモデル、診断ルール、スクリプト及び測定点）をバインドするＳ１１と、 次に、システム故障の原因を段階的に中間イベントに分解し、そしてフォルトツリーのトップイベントのためにロジック設備と故障診断ツール（アルゴリズムモデル、診断ルール、スクリプト及び測定点）をバインドするＳ１２と、 分解が不可能または不要なイベントを基礎イベント即ち下位イベントとする。そして、下位イベントのために故障診断ツールとデフォルトの発生確率を設定するＳ１３と、 各フォルトツリーのノード間は論理関係計算法を用いて接続され（例えば、論理積、論理和）、これにより完全なロジックフォルトツリーの描画が完成するＳ１４と、 フォルトツリーの描画が完了した後、完全性検査に合格すれば、ロジック故障の作成が完了するＳ１５。 ステップＳ２は、具体的には、次のサブステップを含み、 インスタンス化されたステーション、設備を選択することにより、ロジックモデルをインスタンス化されたモデルに変換するＳ２１と、 インスタンス化過程で、ノードにバインドされたロジック設備、測定点などをバインドされた物理設備、物理測定点に変換するＳ２２と、 ロジックアルゴリズムモデルを物理アルゴリズムモデルに変換するＳ２２と、 フォルトツリーのノードにサブツリーが引用される場合、サブツリーもインスタンス化されたツリーに変換する必要があるＳ２３と、 そして、ロジックフォルトツリーのモデル名をインスタンス化されたモデル名に変換し、ここで、フォルトツリーのインスタンスの作成が完了するＳ２４。 ステップＳ３は、具体的には、次のサブステップを含み、 インスタンス化されたフォルトツリーは正式に使用することができ、ｒｅｓｕｌｔインタフェースを通じて呼び出すこともできるし、周期タスクを通じて自動的に実行することもできるＳ３１と、 フォルトツリーノードにバインドされた診断アルゴリズムを取得し、異なるタイプの診断アルゴリズムに基づいて相応の診断インタフェースを呼び出し、診断結果を取得し、ノードアラーム結果及び確率に設定するＳ３２と、 故障ノードにフォルトツリーがバインドされている場合、Ｓ３２を繰り返し実行するＳ３３と、 ステップＳ３２で取得した故障確率をフォルトツリーに代入し、該ノードに故障診断アルゴリズムがバインドされていない場合、デフォルト設定の故障発生確率を取得する。ＦＴＡ故障診断アルゴリズム、例えば最小カットセット、最小パスセットなどに基づいて、フォルトツリーのトップイベントが故障したかどうか、故障が発生する確率を分析、演繹するＳ３４。 診断方法２、前記ルール推論のプロセスは、 Ｓ１、既知の故障モードと故障兆候の関係の経験データに基づいて、ルール配置ツールにルールを確立し、入力された故障兆候データに基づいて、故障モードの発生確率を判断する。ルールがリリースされた後、ＲＥＳＴインタフェースサービスを提供する。 ルール配置プロストは、データ設計とロジック設計の２つの部分から構成される。 データ設計では、故障診断ルールの入力データ、出力データ、中間計算結果データを定義する必要があり、データ変数の名前とタイプを含む。必要に応じて、複数の関連データを複雑な変数タイプにカプセル化することができる。定義されたデータ変数のみを、ルールロジックで使用することができる。ルールロジック内のビジネスパラメータを定数として定義し、可読性と保守性を向上させる。 ロジック設計では、入力データに対する処理フローに従って、条件判断、データの割り当て、データ処理関数、基礎四則計算などを含む各種ルール要素をドラッグすることにより、データ処理プロセスと判断ロジックが含まれる一連のルールブロックを構築する。 ルールはリリースされたときには、データ設計におけるデータ変数から、ルールの入力データと、ルール実行完了後に出力する必要があるデータを指定し、リリースされたＲＥＳＴインタフェースは、ＪＳＯＮフォーマットの入力データを受信し、ＪＳＯＮフォーマットの結果に戻す。 Ｓ２、設備の時系列データに対して解析モデルを構築し、関連する故障兆候が発生しているか否かを解析する。 Ｓ３、ルールリリース時に指定された入力要求に従って、Ｓ２で解析された設備兆候データを該ルールインタフェースに入力されたＪＳＯＮ構造にカプセル化し、Ｓ１で確立されたルールＲＥＳＴインタフェースを要求する。 Ｓ４、ルール配置バックエンドとなるルールの実行エンジンによってＲＥＳＴインタフェース要求を処理し、該ルールにデータを入力し、設計されたロジックによって、故障モードの発生確率を判定して出力する。 ルールの実行エンジンによって、各ルールブロックをルールツリーにコンパイルし、ルール内の各ルールブロックの順序に従ってこれらのルールツリーを順次実行し、関連するデータ変数を更新する。そして最終的に指定された出力データを出力し、故障モードとその発生確率を含む。 ある故障や問題に対して、関連情報を整理、まとめ、分類することによって可視化された知識構造図を形成する。この構造図に通常、特定の故障や問題の把握と解決を支援するために、故障の原因、パフォーマンス、排除方法、ソリューションなどが含まれている。 診断方法３、故障事例マッチング法であり、故障事例ライブラリを通じて故障事例の情報を格納し、組織し、新しい故障が発生した場合、システムは自動的に故障事例ライブラリのデータと比較し、最も似た故障事例を見つけ、そこから役立つ情報を抽出して診断する。診断が必要な時間帯、設備、ユニットなどの情報に基づいて、対応する測定点の時系列データを検索する。診断プロセスは以下の通りである。 Ｓ１、測定点の時系列データに基づいて兆候計算を行い、各兆候は異なる計算ロジックに対応する。該期間にどのような兆候が発生したか、その兆候の信頼性を判断する。 Ｓ２、算出された兆候に基づいて対応する故障モードに従ってグループ化を行った後、算出された兆候の信頼度を固定重みに従って正規化処理を行い、各故障モードの信頼度を得る。 Ｓ３、複数の類似度を測る方法によって、で発生した兆候と故障事例ライブラリにおける各故障事例に対応する兆候の類似度を計算する。 Ｓ４、最後に故障モードの信頼性と類似度を結合し、各故障モードの信頼性、すなわち故障発生の可能性を得る。 診断方法４、ビッグデータモデルアルゴリズムのプロセスは以下の通りである。 Ｓ１、診断が必要な時間帯とユニット設備によって、ＫＫＳインスタンス化された設備ツリーに基づいて、対応する測定点の時系列データを検索する。 Ｓ２、時系列データに対してテーブル転換処理を行う（ピボットテーブル、ｐｉｖｏｔ、ｉｄと、ｔｉｍｅと、ｖフォーマットデータとをｉｄ１、ｉｄ２、ｉｄ３…フォーマットに変換する）。 Ｓ３、テーブル転換処理を行った後、時間が合わない場合（同時刻に一部の測定点にデータがあり、一部の測定点にデータがない）があるため、有効電力測定点とユニット水頭測定点に対して前値補正を行う。 Ｓ４、有効電力測定点に基づいて、データに対して安定性スクリーニングを行い、具体的なロジックは、 Ｓ４．１、ウィンドウｔと波動閾値Ｍを設定し、時間ｔとなるウィンドウ内のユニットが安定的に運転しているか、すなわち有効電力の波動振幅（当該ウィンドウ内最大値－最小値）がＭより小さいかどうかを判断し、 Ｓ４．２、ウィンドウを後ろにスライドさせ、判定ロジック１を繰り返す。 Ｓ５、すべての空データに対して前値補正を行い、２ステップに分けて前値補正を行う理由はデータの真実性を保証する必要があるためである。 Ｓ６、センサレンジを超えた測定点データを選別する。 Ｓ７、目標測定点に対して閾値フィルタを行い、目標測定点が、ユーザーが設定した閾値を超えると、マーキングを行う。 Ｓ８、マーキングされたデータをデータテーブルに格納し、該テーブルは、モデル開発部と故障診断モジュールのデータ交換に用いられる。 また、診断方法１－４は定量診断であり、定量診断では診断できない場合、知識グラフ診断方法を用いて診断を行い、診断プロセスは以下の通りである。 Ｓ１、水力発電ユニット及び故障に関する知識に基づいて、診断に用いられる知識及び関係モデルを設計し、知識ノードはシステム、サブシステム、ユニット、故障事例ライブラリ、ＦＭＥＡ（故障モードと影響解析）ライブラリ、ＦＴＡ（フォルトツリー解析法）ライブラリ、早期アラーム情報、測定点などを含み、そして知識間の関連関係を整理して水力発電故障診断知識グラフの概念モデルを構築し、具体的には、 第１は、知識グラフは、実際の世界に存在する様々なエンティティまたはコンセプト及びその関係を記述するために使用され、最終的に巨大な意味ネットワーク図を配置する。ここで、ノードはエンティティまたはコンセプトを表し、エッジは属性または関係で配置される。 第２は、ノード（または本体）。コンセプトｃｏｎｃｅｐｔｓ、エンティティ（ｅｎｔｉｔｙ）、プロパティ（ａｔｔｒｉｂｕｔｅ）、またはイベント（ｅｖｅｎｔ）を表す。本体は、例えば１台の主変圧器、１人の業務員など、あるいは抽象的なコンセプト、例えばビッグデータプラットフォーム、知識グラフ、発電ユニットなど。 第３は、エッジ（または円弧）。セクションは「関係」に対応し、ノード間に存在する何らかのつながりを表す。エッジのラベルは、関係のタイプ、またはエンティティ間の関係（クラス関係、構成関係など）を表す。 水力発電ユニットの故障診断知識グラフにおいて、ノードはシステム、部品、設備、故障事例ライブラリ、ＦＭＥＡ（故障モードと影響解析）ライブラリ、ＦＴＡ（フォルトツリー解析法）ライブラリ、早期アラーム情報、測定点などを含み、そしてノード間のクラス関係、順序関係、因果関係、構成関係などの関係は、共に故障診断知識グラフの概念モデル（ＦａｕｌｔＤｉａｇｎｏｓｉｓＫＧ Ｃｏｎｃｅｐｔｉｏｎ Ｍｏｄｅｌ）を構成した。 Ｓ２、知識を分類する。この一環はとても重要で、後期の知識サービス、知識計算、知識推論と知識可視化などのために準備をして、ノードはシステム類、設備類、故障類、方法類、データ類、ユーザー類などに分けられ、関係類は、クラス関係、構成関係、集約関係、インスタンス関係、順序関係、関連関係、依存関係、因果関係、関係者などに分類される。 Ｓ３、知識ノードのデータ構造を細分化し、すなわち知識ノードを対象とした故障解析に役立つ関連属性を整理し、例えばユニット（設備ＫＫＳコード、設備仕様、作動時間、設備タイプ、メーカーなど）、故障事例（故障事例コード、故障事例名、故障事例簡単な説明、故障事例ソースタイプ、故障事例関連画像など）、故障（故障エンコード、故障モード、故障現象記述、故障レベル、故障影響など）、故障処理（処理措置、処理ステップ、処理効果）、故障特徴（特徴データ、図形特徴、故障データサンプル、故障回復後のデータサンプル）など。 Ｓ４、知識グラフを用いてツールを構築し、コンセプト知識モデルをグラフデータベースＮｅｏ４ｊに構築し、コンセプトレベルの知識テンプレートを三つ組（主語、述語、目的語）、例えば（ユニット、関連関係、故障）、（水力タービン、クラス関係、ユニット）、（故障原因、因果関係、故障）、（故障特徴、関連関係、故障兆候）、（故障、関係者、欠陥記録者）、（アラート、関連関係、ユニット）などに転換する。 Ｓ５、知識抽出準備を行う。構造化タイプの知識ノードのためのマッピング設定を行い、半構造化および非構造データのための知識ソース配置と知識注釈などの作業を配置し、および知識抽出タスクの作成およびタスク実行パラメータ（タスク実行頻度、実行カバレッジ範囲、知識カバレッジ方式など）を配置する。 Ｓ６、知識の抽出と更新を行う。知識抽出タスクをタイミングまたは定期的に実行し、事前に作成された水力発電故障診断知識グラフの概念モデルに基づいてグラフデータベースにインスタンス化されたデータを保存し、エンティティ定義の不一致などが発生した場合に人工手段を補助して知識統合を行い、最終的に水力発電故障診断の知識グラフを形成する。 Ｓ７、知識の計算と推論を行う。故障診断推論ルールと関連モデルに基づいて、形成された水力発電故障診断知識グラフに対して知識計算或いは知識推論を行い、故障診断結果及び故障解析プロセス記録を得る。 Ｓ８、知識の可視化を行う。故障診断結果と解析プロセスを適切な形式でユーザーに表示する。 各診断方法は１つの診断ノードを構成し、診断ノードはビッグデータモデルアルゴリズムノード、ルールノード、故障事例ライブラリノードとフォルトツリー解析法ノードを含み、診断時、同時にビッグデータモデルアルゴリズムノード、ルールノード、故障事例ライブラリノードとフォルトツリー解析法ノードに入って診断を行い、発電所配置データ、ユニット配置データ、設備配置データを順次診断する。 具体的な診断プロセスは表２により示される。 TIFF 0007442001000003.tif 133 170 ステップ３、各診断方法の結果を取得し、結果テーブルは、ビッグデータモデルアルゴリズム結果テーブル、ルール結果テーブル、故障事例ライブラリ結果テーブル、およびフォルトツリー解析法結果テーブルを含む。 ステップ４、複数の診断方法の診断結果に対して故障診断融合決定を行い、 ステップ４．１、各診断方法の診断結果に対してフィルタ処理を行い、各診断方法の異なる故障モードの確率が最大の結果を取得し、 ステップ４．２、各診断方法がフィルタ処理された結果に対して融合計算処理を行い、最終的な故障モードとその確率を取得する。 ステップ４．２の融合計算は、ツールの結果に一つの故障モードしかない第１種と、ツールの結果に複数の故障モードがある第２種という２種類に分けられ、 ツールの結果に一つの故障モードしかない第１種について、表３のように行われる。 JPEG 0007442001000004.jpg 75 170 ステップ４．２．１、ツールの結果に複数の故障モードがある第２種に対して、Ｄ－Ｓ証拠理論に基づく融合決定モデルを用いて計算する必要がある。Ｄ－Ｓ証拠理論に関する文献は、中国特許文献ＣＮ１１０１６６４３７Ｂが開示したＤ－Ｓ証拠理論に基づく移動目標防御最適戦略の選択方法である。 ステップ５、最終的な診断結果を得る。 最終的な診断結果には、ルール診断結果、故障事例マッチング結果、フォルトツリー解析法マッチング結果、モデルマッチング結果、知識推論結果が含まれ、最終的に最終的な診断結果を集約して統合する。 具体的には、各種診断結果の詳細結果情報を故障診断詳細画面で表示する。ルール診断結果、故障事例マッチング結果、フォルトツリー解析法マッチング結果、モデルマッチング結果、知識推論結果を含み、最終的に各種診断結果を集約して統合し、各種モデルの診断確率と歴史的信頼性を総合し、融合決定を通じて故障診断意思決定結果を与える。 第１は、ルール結果の表示： 詳細な値取り説明、故障モードに基づいて、各故障モードごとに算出された最大確率を結果として、複数の故障モードがあれば複数のモードを取る［１］と、 診断根拠説明、どの故障モードに命中したか、兆候名と発生状況を羅列する［２］と、 兆候に基づく場合、質量不均衡が１１０条におけるある兆候の組合せに命中したと仮定し、各兆候の信頼性とその組合せの信頼性を羅列し、 特徴パラメータに基づく場合、故障モードが一連の特徴パラメータの計算を連結したと仮定し、該グループの特徴パラメータの計算結果及び計算方法を展示する。 第２は、故障事例結果の表示： 詳細な値取り説明、故障モードに基づいて、各故障モードごとに算出された最大確率を結果として、複数の故障モードがあれば複数のモードを取る［１］と、 診断根拠説明、メカニズム兆候と特徴パラメータの２種類に分けられる［２］と、 兆候に基づく場合、今回計算に関与した兆候範囲は、何が発生したか、何が発生していないかを羅列し、兆候の組み合わせに基づいて故障モードの発生を推定し、 特徴パラメータに基づく場合、今回計算に関与した特徴パラメータを羅列する。 第３は、フォルトツリー解析法結果の表示： 詳細な値取り説明、フォルトツリー解析法に基づいて、各フォルトツリー解析法のツリーが命中した故障モードを取るとともに、故障影響によってその故障モードで命中した全パスを見ることができる［１］と、 診断根拠説明、フォルトツリー解析法のツリーに、バインドされたアルゴリズム／ルールの故障モードノード、および発生の有無を羅列する［２］。 第４は、知識グラフ結果の表示： 詳細な値取り説明、兆候または故障モードに基づいて、今回の推論の完全な関連グラフを形成する［１］と、 診断根拠説明、メカニズム兆候と特徴パラメータの２種類に分けられる［２］と、具体的は、 兆候に基づく場合、今回の計算に兆候が関与した場合は、兆候結果テーブルから関連兆候を取得し、兆候に基づいて該当する故障モード、故障原因及び処理措置を推論し、 特徴パラメータに基づく場合、今回の計算で兆候が見つからない場合は、特徴パラメータ計算のルールＩＤを起動することにより、相応の故障モードを見つけ、故障モードを通じて関連の故障原因処理措置などを推論する必要がある。 第５は、アルゴリズム計算結果の表示： 詳細な値取り説明、故障モードに基づいて、各故障モードごとに算出された最大確率を結果として、複数の故障モードがあれば複数のモードを取る［１］と、 診断根拠説明、各計算サブステップに基づいて、クリックして相応な根拠を表示する［２］。 第６は、融合計算結果の表示： 故障事例、フォルトツリー解析法、ビッグデータモデルアルゴリズム、ルール、知識グラフの計算結果に基づいて、故障モードに基づいて合併し、ツールごとに確率が最大の３つの故障モードのデータを取って総合的に表示するとともに（表示戦略は調整可能）、故障兆候、故障タイプ、故障原因、特徴パラメータ、重大度、発生度、検出度などの情報融合出力を関連付け、設備状態に対する業務者の判断に科学的根拠を提供する。 （実施形態１） 図２に示すように、変圧器故障検出を例に故障診断の全プロセスを詳述する。 ステップ１、配置データを取得すること １、ＦＭＥＡ配置の実現方式は以下の通りである。 １．１、ＦＭＥＡ標準テンプレートを構築し、該標準にＦＭＥＡデータを追加し、配置が必要な設備を選択することと、 １．２、システム、サブシステム、設備、部品などの異なるレベルに従って、（多層レベル）設備に対応する故障モード、優先度などの情報を配置し、設備と故障モードの間の関連関係を実現することと、 １．３、配置されたすべての故障モードに対して特徴パラメータ及び故障兆候を自動的に取得し、又は故障モードに対応する特徴パラメータを手動で配置することと、 １．４、すべての故障モードに対応するリスク評価情報を配置し、重要度（Ｓ）、発生度（Ｏ）、検出度（Ｄ）などの情報を含み、最終的にＦＭＥＡの要約情報を形成すること。 ステップ２、複数の診断方法（または複数の診断ツールを利用）を用いて診断を行うこと ２、変圧器故障事例マッチングの実現方法は以下の通りである。 ２．１、変圧器の故障事例を手動で作成し、ロジック設備、インスタンス化された設備、故障モードと故障時間帯を選択する。 ２．２、故障モードにより、ＦＭＥＡを通じて変圧器故障モードに関わるすべての特徴パラメータを検索し、兆候属性欄、データ特徴に表示され、インスタンス化された設備及び故障時間帯を通じて、この特徴パラメータの数値を全部持ち出すことができる。 ２．３、故障モードにより、ＦＭＥＡを通じて当該故障モードの故障原因、処理措置、検出方法などの内容を検索し、自動的に持ち出すことができる。 ２．４、インスタンス化された設備および故障時間帯を通じて、故障データサンプルを生成し、関連付けることができる。アラームなどの情報内容を関連付けることもできる。 ２．５、事例の保存とリリースを行う。 ２．６、事例マッチングの場合、特徴パラメータの数値に基づいて類似度計算してマッチングを行い、マッチングアルゴリズムは灰色関連分析というマッチングアルゴリズムを使用する。 ２．７、事例マッチングのプロセスは、まずロジック設備における故障モードをすべて抽出し、時間帯に基づいて故障モードに関連する特徴パラメータを計算し、それから事例内の特徴パラメータの数値とマッチングアルゴリズムによってマッチングし、すべての事例の類似度順序を求める。 ２．８、事例マッチング結果はデータ特徴パラメータと事例特徴パラメータ、及びすべての事例の類似度順序を表示する。 ３、変圧器ルール（ルール推論）の判断の実現方式は以下の通りである。 ３．１、ルールの構築 ［１］、ルールデータの設計 ａ）、入力データオブジェクトを作成し、３つ比率法に関連する６つの測定点を選択する。 ｂ）、中間データセット出力のデータオブジェクトを作成し、最後に出力する変数と、データ処理中の中間データの保存変数を含む。 ｃ）、必要に応じて、いくつかの業務パラメータを定数に設定する。定数を設定する目的は、データを読み取り可能にし、データの保守性を強化する。 ［２］、ルールロジックの設計 ａ）、３つ比率法のロジック設計を完成し、順序に従って３つ比率法の実行プロセスをルール的に編成する。 ｂ）、一般的なルールの設計プロセスは以下の通りである。 データの処理、データの加工を完成し、例えばオブジェクト構造から属性値を抽出するなど、データの加工を完了し、関数を用いて変数を処理して目標変数を得る。 条件ロジック判断、ｉｆ…ｔｈｅｎ…ｅｌｓｅの構造に従ってビジネスロジックを実行する。 ３つ比率法ルールのプロセスは大体以下の通り、測定点値を取ることと、３つ比率法の運用条件に合致するかどうかを判断することと、３つ比率を計算することと、比率項目ごとに、異なる比に基づいてエンコードすることと、３つ比率のエンコードの組み合わせに基づいて、故障原因などのデータを提供すること。 ［３］、ルールクイックテスト、入力データを提供してテストを行い、物理測定点に対して実行することもでき、入力結果が予想通りであるかどうかを確認する。 ３．２、ルールのスケジュール ［１］、ルールのインスタンス化、インスタンスを作成し、ルールが適用される設備を指定する。 ［２］、ルールのタスク、周期的に実行する必要があるルールについて、タイミングタスクを作成し、タスクに複数のルールのインスタンスを含むことができる。 ４．変圧器知識グラフ判断の実現方法は以下の通り、 知識体系の枠組みを構築し、ニーズに基づいて知識を分類し、各分類のタイプとプロパティ情報を明確にするとともに、知識間の関係を事前定義し、各種類の関係を明確にし、維持管理を行う。 ４．１、知識の表示 知識の表示は、グラフが構築された出力対象、すなわち知識グラフの意味記述フレームワーク、Ｓｃｈｅｍａ、エンティティ命名及びＩＤ体系を決定し、 知識表現標準語には、ＲＤＦＳとＯＷＬが含まれており、ここで、ＲＤＦＳはクラスと属性に対する簡単な説明を提供し、ＲＤＦデータに語彙モデリングするための言語を提供する。より豊富な定義には、杉からＯＷＬ本体までの記述言語が必要である。 基本的なデータモデルとしてＲＤＦ（三つ組）があり、その基本的なロジック構造には主語（個人、クラスのインスタンス）、述語（属性）、目的語（個人またはデータタイプのインスタンス）の３つの部分が含まれる。 知識の取得、現在、故障モードの情報はＦＭＥＡライブラリを主なソースとし、構造化データの知識抽出に向けて、通常はロジックテーブルが三つ組マッピングを通じてＲＤＦデータにマッピングされ、三つ組マッピングはロジックテーブルの各行をいくつかのＲＤＦ三つ組にマッピングすることができるルールである。三つ組ルールには、主語マッピングと複数の述語－目的語マッピングの２つのセクションが含まれる。２つ目は述語－目的語マッピングには述語マッピングと目的語マッピングが含まれる。 ４．２、グラフの構築 ［１］、Ｓｃｈｅｍａの定義 Ｓｃｈｅｍａはすなわち知識グラフ中のエンティティ、プロパティ及び関係を明確に定義し、その実行可能な範囲を明確にし、すなわち知識グラフを定義するＳｃｈｅｍａは知識グラフを構築する本体と等価である。 故障診断の応用ニーズに基づいて、ユーザーのニーズを出発点として、データ統計を証拠として、異なるテーマを構築してユーザーのニーズを満たす。 ［２］、本体グラフの構築 故障診断応用シーンの下で、Ｓｃｈｅｍａ定義を基礎として、故障モード、兆候現象、設備に対して本体スペクトル構築を行い、スペクトルはエンティティ、プロパティ及びエンティティとエンティティ又はエンティティとプロパティの関係を含む。定義された本体をグラフ構築する。 ４．３、知識の融合 知識融合の目標は本体間の連絡を確立することで、本体と本体間の知識グラフが相互にコミュニケーションでき、それらの相互操作を実現することである。 グラフアルゴリズム及びルールにより、本体と本体との関係を計算判断し、自動的に新しい関係グラフを生成する。 ５、変圧器故障検出アルゴリズムモデルの構築 最初にタグ付きの故障サンプルを入力した後、フォーマット変換、時間整列、空データの除去などのデータの前処理を行う。次に、分類モデル（例えば、単純ベイズ、サポートベクターマシンなど）によってトレーニングを行う。 予測を行う場合、データに対して同じ前処理作業を行い、分類モデルを通じて結果を出力する。 トレーニングデータはユニットの運転期間中に蓄積されたサンプルに由来し、大量の故障と正常なデータが含まれ、まとめることにより、サンプルライブラリを構築する。 ５．２、故障データに対してラベル処理を行い、すなわち各データの後ろに故障種別標識、例えば「高温放電」、「低温放電」、「部分放電」などを加える。モデルの実行時に、プログラムが認識できる故障コード（「３０」、「４６」など）に置き換える。計算出力が完了したら、故障の説明に戻す。 ６、変圧器ＦＴＡの実現方式は以下の通り、 ６．１、変圧器ロジックＦＴＡを作成し、ＦＴＡノードにロジック設備と故障モードを配置し、高温過熱（７００ｏＣより高い）ノードに３つ比率法ルールを配置するなど、配置可能なノードに故障診断方法を関連付ける。 ６．２、ロジックＦＴＡの配置が完了したら、完全性検査を行い、検査が完了し、保存し、リリースする。 ６．３、ロジックＦＴＡのインスタンス化を行い、例えば中国葛洲ダム変電所２Ｂ変圧器へのインスタンス化するような具体的な変電所とユニットへのインスタンス化を行う。 ６．４、ロジックＦＴＡのインスタンス化を行い、ＦＴＡインスタンスを生成し、ＦＴＡインスタンスは異なる工場とユニットに基づいて再編集、保存し、リリースすることができる。 ６．５、ＦＴＡの診断、高度なアプリケーション-故障診断が要求パラメータＫＫＳコード、故障時間帯を送信する。ＦＴＡはＫＫＳに基づいて対応するＦＴＡインスタンスをマッチングし、且つＦＴＡインスタンス上のすべてのノードに関連された診断方法を起動し、診断方法が実行されると診断結果に戻り、該診断結果はＦＴＡノードに反映され、且つ赤、緑の色に表示される。そして各ノードからフィードバックされた故障に基づいて、トップイベントの発生確率を推定する。 ステップ３は、ワークフローにおいて、故障モード、関連する診断プロセス及び診断ツールを配置する。 １、作成プロセス 作成プロセスは、モデル名、モデルｋｅｙ、モデル説明を入力し、ここでのモデルｋｅｙは純粋な数字ではなく、後のインタフェースで呼び出すときに使用する必要があり、ｋｅｙとして使用する。ＯＫに入ったら、保存に成功すれば、空白のプロセスが作成される。 ２、プロセス設計 ［１］プロセス設計の開始 事例、ルール、ＦＴＡ、知識マッブ、アルゴリズムモデルのプロセスノードイベントを設計パネルにドラッグし、異なる要素を矢印（シーケンスフロー）で接続する必要がある。 ＨＴＴＰタスクの場合、まず実行サウンドモニターについて、ｒｅｓｔサービスの成功または失敗は通常、単にＨＴＴＰのＳｔａｔｕｓ Ｃｏｄｅのみに頼ることではなく、バックエンドコードに書き込まれたことによって判断する。したがって、ここで実行サウンドモニターは、このＨＴＴＰサービス呼び出しが本当に成功したかどうかをワークフローに認識させるために、いくつかの変数を配置するためのものである。呼び出しが成功したかどうかを関係しない場合は、ここでは配置は必要ない。 ［２］イベントの＋記号を入力して、新しいイベントを追加する イベントは、ｅｎｄを選択 クラスは、固定値ｃｏｍ．ｄｈｃｃ．ｆｌｏｗａｂｌｅ．ｃｏｍｍｏｎ．ｌｉｓｔｅｎｅｒ．ＨｔｔｐＴａｓｋＥｘｅｃｕｔｅＬｉｓｔｅｎｅｒ、 Ｎａｍｅの＋番号を入力して、一つのフィールドを追加し、 名称は、固定値ｓｕｃｃｅｓｓ 表現式は、ｒｅｓｐｏｎｓｅＲｅｓは固定されており、残りは実際のインタフェースのフィールドが何に等しいかに基づいて配置されている。例えば、実際のインタフェースの戻り値は｛ｓｔａｔｕｓＣｏｄｅ：０，ｄａｔａ：［ＸＸＸＸＸ］｝であり、ｓｔａｔｕｓＣｏｄｅが０で表されている場合、ここでは＄｛ｒｅｓｐｏｎｓｅＲｅｓ．ｓｔａｔｕｓＣｏｄｅ＝＝０｝に設定される。 Ｎａｍｅの＋番号を入力し、一つのフィールドを追加し、 名称は、固定値ｅｒｒＭｓｇ、 表現式は、ｒｅｓｐｏｎｓｅＲｅｓは固定されており、残りは実際のインタフェースのエラー情報フィールドに基づいて配置されている。たとえば、実際のインタフェースの戻り値が｛ｓｔａｔｕｓＣｏｄｅ：－７７７７，ｅｒｒｏｒＭｅｓｓａｇｅ：‘エラー’｝であれば、ここでは＄｛ｒｅｓｐｏｎｓｅＲｅｓ．ｅｒｒｏｒＭｅｓｓａｇｅ｝に設定し、 実行サウンドモニターの配置が完了したら、ＨＴＴＰサービスタスクのその他のプロパティを配置する必要があり、 ［３］、要求方法は、ＧＥＴまたはＰＯＳＴを選択する ＵＲＬ：＄｛ｒｅｑｕｅｓｔＨｏｓｔ｝を固定値として要求し、後のアドレスは実際の状況に基づいて記入し、 要求ヘッダーは、ａｕｔｈｏｒｉｚａｔｉｏｎ：＄｛ａｕｔｈｏｒｉｚａｔｉｏｎ｝は固定値であり、インタフェースがｂｏｄｙを着信する必要がある場合は、２行目にＣｏｎｔｅｎｔ－Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎを配置し、着信する必要がない場合はＣｏｎｔｅｎｔ－Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｘ－ｗｗｗ－ｆｏｒｍ－ｕｒｌｅｎｃｏｄｅｄを配置し、 ［４］、要求ボディは、固定値＄｛ｒｅｑｕｅｓｔＢｏｄｙ｝、インタフェースパラメータには変数ｒｅｑｕｅｓｔＢｏｄｙ及び対応する値を着信する必要があることを注意してください。該値はＨＴＴＰサービスを呼び出す際にパラメータとして着信される。 要求タイムアウト時間は、固定値１０００００（または実際の状況に応じて変更）であり、 応答変数名は、固定値ｒｅｓｐｏｎｓｅＲｅｓであり、 レスポンスをＪＳＯＮとして保存し、固定値ｔｒｕｅ。 ステップ４、融合決定をし、結果の表示を行う。故障診断の高度なアプリケーションにおいて、情報スキャンの開始と終了時間を選択し、必要に応じて全ステーションのすべてのユニットを選択するか、あるいは指定された単一ユニットの設備を選択して故障スキャン診断を行う。プロセス管理ツールは、バックグラウンドでさまざまな診断ツールを同時に起動し、診断結果をそれぞれ故障診断の高度なアプリケーションのフロントエンドインタフェースに戻って表示する。各種診断結果の詳細な結果情報を故障診断インタフェースで表示できる。 の実施例は本発明の好ましい態様のみであり、本発明に対する制限とみなすべきではなく、本発明の保護範囲は請求項に記載の態様、請求項に記載の態様における技術的特徴を含む均等な置換態様を保護範囲とするべきである。すなわち、この範囲内での同等の置換改良は、本発明の保護範囲内である。