(57)【要約】      （修正有）【課題】一群のユニットについて推奨保守間隔を一群内の各ユニットの運転のプロファイルの関数として決定する方法を提供する。【解決手段】モデルは、関心のコンポーネントごとに故障モードレベルで生成される。個々の故障モードの全てについてのモデルが組み合わされて、結果として一群のユニットを所有するビジネスが一群内のユニットごとに一定を保つことが好ましいものであり得る関心の運転の量となる。設計評価ツールが、境界を評価するために利用することができる。システムは、推奨保守間隔を決定する。【選択図】図１
2017151980.tif 000002
【特許請求の範囲】
【請求項１】
一群の発電ユニット内の複数のユニットごとに推奨保守間隔を決定する方法であって、一群の発電ユニット内の複数のユニット（２０８、２１１）についての運転データおよび予期しない保守データを表す実験的データを収集するステップ（１０１）と、
前記運転データおよび予期しない保守データの前記実験的データを評価するステップ（１０１）と、
前記実験的データに基づいて複数の故障モードモデルを生成するステップ（１０１）と、
前記複数の故障モードモデルを合成するステップ（１０２）と、
前記複数の故障モードモデルの前記合成のために目標の運転の量を確立するステップ（１０３、１０４）と、
前記目標の運転の量に基づいて前記一群の発電ユニットについて一群の推奨保守間隔を生成するステップ（２０２、３０２）と、
前記一群の発電ユニット内の前記複数のユニットごとに運転のプロファイルを計算するステップ（２０８）と、
各ユニットの前記運転のプロファイルに基づいて前記一群の発電ユニット内の前記複数のユニットごとに前記推奨保守間隔を計算するステップ（１０８、１０９、２１０）と
を含む方法。
【請求項２】
前記一群の発電ユニットは、新しい前記推奨保守間隔内で再評価される（１０９）、請求項１記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項３】
選ばれた前記運転の量は、予期しない保守の可能性、予期しない保守のコスト、信頼性、利用度、または合計ライフサイクルコストのうちの１つである、請求項１記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項４】
選ばれた前記運転の量は、ユニットごとに関心の１つまたは複数のサブシステムについて故障モードレベルで信頼性モデルおよびデータに直接関連付けられている、請求項１記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項５】
評価は、設計評価ツールを用いて行われる、請求項２記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項６】
前記複数の故障モードモデルは、運転パラメータの関数として予期しない保守イベントの確率を出力するように設計されている、請求項１記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項７】
前記複数の故障モードモデルは、故障モードが生じた場合に故障モードの結果について結果データを含む、請求項１記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項８】
前記結果データは、イベント継続時間、イベントコスト、および／または修理コストを含む、請求項７記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項９】
故障モードモデルの組み合わせは、前記推奨保守間隔を決定するビジネスが前記一群内のユニットごとに一定を維持するように選ぶ関心の運転の量になる、請求項１記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項１０】
各運転のプロファイルが選ばれた前記運転の量の同じ値になるように前記推奨保守間隔を調整するステップ（１０７）をさらに含む、請求項１記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項１１】
前記運転のプロファイルは、ファクタを考慮した開始とファクタを考慮した時間領域との内に曲線（２０２）を含む、請求項１記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項１２】
前記ファクタを考慮した開始とファクタを考慮した着火時間領域は、任意の所与の時間／開始の比について前記保守間隔を定める、請求項１１記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項１３】
前記設計評価ツールは、何らかのさらなる故障モードモデルが前記組み合わせた複数の故障モードモデル内に含まれるべきか決定するための故障モード／効果分析（ＦＭＥＡ）を含む、請求項５記載の推奨保守間隔を決定する方法（１０８、１０９）。
【請求項１４】
コンポーネントレベルで故障モードモデルを決定するステップをさらに含む、請求項１記載の推奨保守間隔を決定する方法（１０８、１０９）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、推奨保守間隔を決定することに関し、詳細には、各ユニットの運転のプロファイルに基づいて一群のユニットのための保守間隔を決定することに関する。
【背景技術】
【０００２】
公益事業会社のために電力を作り出すことを担っているユニットなどの発電ユニットは、長期間にわたって高いレベルで連続的に運転する責務を通常負う。このユニットは、高いレベルの信頼性を有するとみなされる必要がある。これらの要求の下で信頼性を維持することは、発電ユニットのコンポーネントが摩耗、疲労、亀裂、酸化、および他の損傷を含み得る使用による劣化の傾向があり、定期的な保守を必要とするので、難しいものであり得る。ユニットの故障をもたらし得る劣化は、故障モードと呼ばれ得る。
【０００３】
発電ユニットは、一般に、大型コンポーネントを備え、その多くは使用時に回転し、極限条件の下で動作し、大きな機械的荷重および電気的負荷も受ける。適切に保守しないと、これらのユニットは、摩耗により劣化し、適切に保守を受けない場合、最終的に作動しなくなり得る。故障を防ぐため、発電ユニットは、定期的なスケジュールの下で定期的な修理および保守のためにオフラインにされる。
【０００４】
発電ユニットの保守および修理のスケジューリングは、ユニットが連続的に動作する運転期間を設定することをしばしば含み、この運転期間は、修理および／または保守のためにユニットをオフラインにする第１のイベントから修理および／または保守のためにユニットを再びオフラインにする第２のイベントまで続く。運転期間の長さを決定することは、ユニットの信頼できる動作のための要求と連続的な延長運転の必要性とのバランスをとることを通常伴う。
【０００５】
発電ユニットに対して修理および／または保守の作業を行うために、ユニットは、オフラインにされなければならない。オフラインの間、ユニットは、送電網のために電力を発生していない。運転期間がとても長く許可される場合、電源装置は、運転中に思いもよらずに故障する可能性があり得る。そのような思いもよらない故障は、予期しない発電停止という結果になり、これは、ユニットに頼るプラントの発電出力を減少させ、修理の必要に関する突然性および即時性により財政上の資本と人的資本において高いコストがかかり得る。一方、運転期間を短くすることは、修理イベントと保守イベントの間のユニットが発電を行っている時間の量を減少させ、したがってより頻繁なオフラインセッションにより、発電ユニットの寿命のような長期間にわたってユニットが発生する総電力量を減少させる。ユニットをオフラインにすることについて説明する別のやり方は、「利用度」を減少させることであり、これは、数学的に説明することができる。数学的には、「１」は、３６５日である丸１年のスケジュールの利用度を表す。「０」は、丸１年にわたってオフラインであるユニットを表し、したがって１年で０日の利用度である。特定のユニットが利用可能であるときを数学的に表すために、（１−（全ダウンタイムを全暦時間で割ったもの））の形態で計算を行うことができ、ここで全ダウンタイムは、計画されたダウンタイムと予期しないダウンタイムとの合計である。従来、故障の計算された可能性は、計画されたオフラインの保守イベントと修理イベントとの間に延びる産業用発電ユニットのための適切な運転期間を決定するために使用される。次いで、故障の計算された可能性は、信頼できる電源装置を維持する要求と電力を発生させる必要性との間のバランスに使用される。
【０００６】
故障の計算された可能性は、予期しない停止を受ける発電ユニットの可能性として特徴付けることができる。電源装置は、スケジュールされたオフラインの期間とは異なる時間にユニットがオフラインにされるとき、予期しない停止を受ける。典型的には、予期しない停止は、発電プラントのような現場で動作する発電ユニットの故障による。
【０００７】
従来から、予期しない停止の可能性は、発電ユニットの実際の現場故障の履歴データに基づいて決定される。実際の現場故障は、故障の可能性を評価するのに役立つが、発電ユニットの全ての潜在的な故障モードを正確に説明しない。一部の故障モードは、履歴に基づくユニット故障に反映されない。
【０００８】
これらの他の故障モードをモデル化するために、「非活動モデル（ｌｕｒｋｉｎｇ  モデル）」が従来から使用されてきた。例えば、前もって分からない故障モードの可能性は、非活動モデルを用いて評価することができる。非活動モデルの手法は、おおまかであり、思いがけず事前に分からない故障モードの仮説的分析に基づいている。非活動モデルは、システムまたはコンポーネントが現在動作している経験を越えて動作することが許可される場合に将来起こり得るこれらの知られていないシステムまたはシステムコンポーネントの故障モードに関連した可能性を考慮に入れる。通常、それは、故障点がないワイブルモデルの一種であり形状パラメータ（「ベータ」とも知られる）が仮定されるＷｅｉｂａｙｅｓモデルを用いて評価される。ベータの値は、比較的高いものであり得、３から４の範囲内であり得る。一般に、ベータは、１から４の範囲内であり得る。非活動モデル内に使用される仮説的分析は、発電ユニットの実際の思いがけない故障モードを予期することはできない。
【０００９】
従来、最大運転間隔は、運転時間の最大量または特定のユニットの開始の最大数のいずれかにやはり基づくものであり得る。時間についての最大間隔または開始についての最大間隔を使用すると、運転の量が一群内の特定のユニットの運転のプロファイルの関数として変化することになる。特定のユニットが最大時間限度または最大開始限度から離れているほど、そのユニットの点検はあまり適切でないものになる。言い換えると、そのユニットは、現在の推奨によって割り当てられるものよりも多くの時間またはサイクルにわたって動作し得たことになる。
【００１０】
したがって、一群のレベルで、ユニットは、従来から推奨保守間隔により、時期尚早で点検を受けている。一定である従来の保守間隔は、ユニット運転の関数として所望の運転の量の挙動を考慮に入れていない。一部の従来の解決策では、楕円関係がシステムの開始数とシステムが実行している時間との間で仮定される。これらの楕円の解決策では、しばしば、ユニットは、運転のプロファイルスペクトルの一部について時期尚早に点検を受けることが推奨されるとともに、逆に、適切な間隔よりも後に点検を受けることが推奨される。
【００１１】
一群のユニット内の個々のユニットごとに正しい運転期間を正確に推定し、それらの値を最大化するとともに思いもよらずそれらがオフラインとすることによる損失を最小化するようになっているシステムおよび方法を向上させるという要求が、長年にわたって解決されていない。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】米国特許第８４０１７２６号明細書
【発明の概要】
【００１３】
一群のユニットのための推奨保守間隔を決定する方法は、各ユニットの運転のプロファイルに基づいている。一群内の各ユニットは、運転のプロファイルにかかわらず運転の量の一定値へ実行される。例えば、運転の量は、少なくとも一定の予期しない保守の可能性、予期しない保守のコスト、信頼性、利用度、またはさらに合計ライフサイクルコスト（予期しない停止コスト、修理コスト、および付随的結果のコスト等など）を含み得る。故障モード／効果分析（ＦＭＥＡ：ｆａｉｌｕｒｅ  ｍｏｄｅ  ａｎｄ  ｅｆｆｅｃｔｓ  ａｎａｌｙｓｅｓ）は、全ての知られている故障モードおよび仮説的故障モードが適切に説明されることを確実にするために活用することができる。
【００１４】
一群のユニットのための推奨保守間隔を決定する方法は、同じ値の運転の量に実行される一群内の各ユニットに基づいている。上述したように、運転の量は、予期しない保守の可能性、予期しない保守のコスト、個々のユニットの信頼性、交換部品もしくは交換ユニットの利用度、および個々のユニットもしくは一群のユニットについての合計ライフサイクルコストを含み得る。
【００１５】
運転の量は、関心のコンポーネントまたはサブシステムごとに故障モードレベルで信頼性モデルおよび／またはデータに直接関連付けることができる。
【００１６】
適切な運転期間を決定する部分として、モデルは、関心のコンポーネントごとに故障モードレベルで生成される。典型的には、これらのモデルは、運転パラメータの関数として所与の故障モードについての予期しない保守イベントの確率になる。これらのモデルは、故障モードが生じた場合には故障モードの結果についての、例えばイベント継続時間、または修理コストなどについてのデータを含むこともできる。
【００１７】
個々の故障モードの全てについてのモデルが組み合わされて、結果として関心の運転の量となる。「関心の」運転の量は、ビジネスが一群内のユニットごとに一定を維持することを望む量（ｍｅｔｒｉｃ）である。関心の運転の量の例には、予期しない保守の可能性、予期しない保守のコスト、ユニットの信頼性、ユニットの利用度、および合計ライフサイクルコストが含まれるが、これらに限定されない。
【００１８】
上記モデルに基づいて、保守間隔、すなわち運転期間は、各運転のプロファイルが同じ値の運転の量になるように調整することができる。例えば、曲線を生成することができ、これによって特定のユニットまたは一群のユニットについて開始数と運転の時間とを比較する。そのような曲線は、任意の所与の時間と開始の比について保守間隔を示すことができる。
【００１９】
そのようなシステムは、上述の曲線において具体化された境界内で再評価することができる。再評価は、故障モード／効果分析（ＦＭＥＡ）などの設計評価ツールを用いて達成することができる。そのような再評価は、（従来の方法に対して）保守間隔について新しい拡張された境界がある場合、何らかの新しい仮説的故障モードモデルが追加されるべきか決定することができる。何らかの新しい故障モードが特定される場合、それらの対応するモデルが追加され、新しいモデルが上述した個々の故障モードの全てについて再生成される。
【００２０】
結果として、一群のユニット内のユニットごとの推奨運転間隔は、その個々の運転プロファイルに基づいて生成され、この個々の運転プロファイルは、一群内の全ユニットにわたって同じ値の運転量を維持する。
【００２１】
信頼性については、機械内で生じる実際の摩耗、劣化、および損傷の実験的データは、機械故障モードのモデル化を強化するために使用することができる。モデルは、機械の信頼性を計算し、オフラインの保守および修理セッション間の最適な期間を決定するために使用することができる。このモデルは、エンジン内部目視検査などによる機械の監視に基づいて、履歴的な現場故障と思いがけない故障とも呼ばれる潜在的な現場故障とからのデータを組み合わせる。
【００２２】
信頼性データは、様々な形式をとることができ、その各々は、測定、取り込み、および／または収集のために様々なツールを必要とし得る。信頼性データは、少なくとも、Ａ）各ユニットから自動的に収集できるおよび／または中央監視システムへ送信できる運転データ、Ｂ）予期しないダウンタイムに関連し得るとともに財務会計システムに取り込むことができるコストデータ、ならびにＣ）過去に起こったものを含み故障モードを説明できる現場エンジニアリング報告を含むことができる。これらの例は、例示的であり、限定するものではない。
【００２３】
信頼性データは、様々な記憶装置に記録することができ、これは、データが最終的な記憶装置に集約される前に中間記憶装置として機能することができる。この中間データおよび／または集約データは、故障モードレベルで信頼性モデルを生成するために使用することができる。記憶装置は、少なくとも、Ａ）各ユニットから自動的に収集されるおよび／または中央監視システムへ送信する運転データを記憶するために使用することができる第１のデータベースシステム、Ｂ）財務会計データを記憶するためにしようすることができる第２のデータベースシステム、Ｃ）言語処理プログラムなどの従来のオフィースソフトウェアプログラムを用いて生成することができていた現場報告を記憶するために使用することができるサーバ（この報告は個々のファイルとして生成および／または記憶することができる）、ならびにＤ）複数のデータベースおよび／または記憶装置から集めてまとめた信頼性データを記憶することができる第３のデータベースシステムを含むことができる。各データベースは、中間データベースであり得る。これらの例は、例示的であり、限定するものではない。
【００２４】
分析装置は、一群内および／または群全体のユニットに関して収集されたデータのモデルを生成するために使用することができる。分析装置は、信頼性データから関心のコンポーネントごとに故障モードレベルでモデルを生成するために使用することができる。モデルが生成された後、１つまたは複数の分析装置は、将来の信頼性、利用度、予期しないコスト、および他の運転考慮事項を予測するために生成されたモデルを適用するために使用することができる。１つまたは複数の分析装置は、推奨群保守間隔を計算する目的でそれらのモデルを評価するために使用することができる。例えば、分析装置には、少なくともＡ）関心のコンポーネントごとに故障モードレベルでモデルを繰り返し生成するために信頼性エンジニアによって使用される統計解析ソフトウェア、Ｂ）用計算ソフトウェアツール、Ｃ）確率的シミュレーションソフトウェア、ならびにＤ）パーソナルコンピュータ、サーバ、またはクラウドベースのシミュレーションソフトウェアを含み得る。これらの例は、例示的であり、限定するものではない。
【００２５】
発電ユニットには、ガスタービン、蒸気タービン、または別の発電装置が含まれ得る。
【図面の簡単な説明】
【００２６】
【図１】推奨保守間隔を決定するステップを描いたプロセスの流れ図である。
【図２】従来の保守間隔と本出願による推奨保守間隔とを比べた比較を表すグラフである。
【図３】従来の保守間隔と本出願による推奨保守間隔とを比べた比較を表す代替のグラフである。
【図４（ａ）】従来の手段による運転のプロファイルの関数としての運転量を表すグラフである。
【図４（ｂ）】図２に示したグラフに関連した運転のプロファイルの関数として運転量を表す代替のグラフである。
【図４（ｃ）】図３に示したグラフに関連した運転のプロファイルの関数として運転量を表すさらに別の代替のグラフである。
【図５】図４（ｂ）の曲線とともに図４（ｃ）の曲線を示す組み合わせたグラフである。
【発明を実施するための形態】
【００２７】
図１は、推奨保守間隔を決定するステップを描いたプロセスの流れ図を示す。第１のステップ１０１として、故障モードモデルが生成される。ステップ１０１では、モデルは、関心のコンポーネントごとに生成される。次いで、ステップ１０２において、様々な故障モードモデルは組み合わされて、関心の特定の運転の量について適宜グラフとして示される数学的モデルを生成する。ステップ１０２において生成した様々な故障モードモデルを組み合わせた後、ステップ１０３において、目標の運転の量が、目標の運転のプロファイルでの運転の量を計算することによって得られる。
【００２８】
ステップ１０３において得られた目標の運転の量を用いて、次いで、ステップ１０４において、運転のプロファイルをインクリメントすることができる。ステップ１０４のインクリメントでは、保守間隔は、運転のプロファイルが同じ値の運転の量になるように調整することができる。ステップ１０４のインクリメントの後、ステップ１０５において、運転の量は、新しい運転のプロファイルで計算することができる。ステップ１０５において新しい運転の量が計算された後、ステップ１０６において、運転の量は、目標の運転の量と比較される。ステップ１０５において計算された運転の量が目標の運転の量に等しくない場合、システムは、最適化ループに入ることができ、それによってステップ１０７において、保守間隔は調整され、続いてステップ１０５における最新の運転のプロファイルでの運転の量の新たな計算がある。
【００２９】
一方、ステップ１０６において、所望の公差（例えば、±０．１％）内で運転の量と目標の運転の量とが等しいと分かった場合、次いで、システムは、他の運転のプロファイルがステップ１０８における保守間隔を決定するプロセスの一部として評価されることを必要とするか検討することができる。システムまたはこのシステムの操作者が他運転のプロファイルが評価されることを必要とすると決定する場合、ステップ１０４におけるように、運転のプロファイルは、再びインクリメントすることができる。ステップ１０４において、運転のプロファイルが再びインクリメントされる場合、ステップ１０５において、新しい運転の量が、最新の運転のプロファイルで再び計算され、続いてステップ１０６における比較がある。
【００３０】
他方、ステップ１０８において他の運転のプロファイルが評価されることが必要とされないことが決定される場合、次いで、システムは、ステップ１０９において、例えば、ＦＭＥＡの手続きを用いて、新しい推奨保守間隔内で評価することができる。
【００３１】
ステップ１０９においてシステムを評価した後、システムまたはこのシステムの操作者が、ステップ１１０による延長運転により任意の他の故障モードがモデル化されることを必要とするか決定する。ステップ１１０がはいと決定する場合、さらなる故障モードがモデル化されることが必要となり、新しいさらなるモデルは、ステップ１０２においてすでに検討された他の全てのモデルと組み合わされる。次いで、システムは、ステップ１０２において組み合わされた新しいさらなるモデルを用いて上述のステップを通じて進行する。しかしながら、ステップ１１０が他の故障モードがモデル化または検討される必要がないと決定する場合、システムは完成され、保守間隔はステップ１１１において決定される。
【００３２】
図２は、本出願の運転の量に基づく曲線２０１と曲線２０２との間の従来の保守期間の間のグラフ的比較を示す図である。この図において、垂直軸は、発電ユニットについてのファクタを考慮した着火開始２０３の尺度を有する。水平軸は、発電ユニットについてのファクタを考慮した着火時間２０４の尺度を有する。曲線２０２は、運転の量について同値の曲線として示される。この特定の例では、運転の量は、点２０５に示されるように従来技術（従来）の時間および開始の保守間隔運転の量の値に等しく設定される。
【００３３】
線２０８は、スケジュールされた保守のためにユニットＡをオフラインにするときに考えられる「ユニットＡ」の一例を示す。点２０９は、ユニットＡがオフラインにされる従来の点を示し、一方、点２１０は、ユニットＡがオフラインにされるときの本技術による点を示す。従来の方法によれば、どのくらい多くの時間ユニットが実際に運転しているのかにかかわらず、ニットＡが１２００回開始されるとすぐに、ユニットはオフラインにされなければならない。
【００３４】
線２１１は、スケジュールされた保守のためにユニットＢをオフラインにするときに考えられる「ユニットＢ」の別の一例を表す。従来の方法によれば、ユニットＢは点検時が３２０００時間に到達するとすぐに、着火開始の回数にかかわらず、ユニットＢがオフラインにされる。同様に、点２１２は、従来の方法によるユニットＢが保守のためのオフラインにされる点を示し、一方、点２１３は、ユニットＢがオフラインにされるときの本技術による点を示す。
【００３５】
図２に示されるように、曲線２０１と曲線２０２との間の領域２０６、２０７は、本明細書中に記載されたシステムを用いて可能になるさらなるユニット運転を表す。線２０８の破線部分は、本技術の結果としてユニットＡの追加運転時間を示す。線２１１の破線部分は、本技術の結果としてユニットＢのさらなる運転時間を示す。
【００３６】
図３は、図２に示した曲線と同様に、本出願の運転の量に基づく曲線３０１の従来の保守期間と曲線３０２の従来の保守期間との間のグラフによる比較を示す。図３では、垂直軸は、発電ユニットについてのファクタを考慮した着火開始３０３の尺度を有する。水平軸は、発電ユニットについてのファクタを考慮した着火時間３０４の尺度を有する。図３は、第３の曲線３０８も示しており、この第３の曲線３０８は、曲線３０２に結果としてなる運転の量未満の値に設定された運転の量とやはり運転の量について同値の曲線である。矢印３０９に示されるように、運転の量を低い値に設定すると、本出願によってここに決定された改善された保守間隔を表す曲線をずらす。例えば、曲線３０２は、予期しない停止または故障の可能性を約３０％に設定された運転の量を表すことができ、一方、曲線３０８は、予期しない停止または故障の可能性を約２５％に表すことができ、これは一群のユニット内のユニットが故障にあう可能性が下がったことを表す。
【００３７】
図２と同様に、領域３０６、３０７は、従来の保守間隔の決定に関して可能性のあるさらなるユニット運転を表す。曲線３０８のずれにより、領域３０６、３０７は、図２に示した領域２０６、２０７よりも小さい。曲線３０８は、一群についての推奨保守間隔を表し、故障の可能性は曲線３０２に比べて減少している。
【００３８】
図４（ａ）は、従来技術による運転のプロファイルの関数として運転量のグラフを示す。ここで、例示的な運転量として、「予期しない停止の可能性」が使用される。例示的な運転プロファイルは、ファクタを考慮した着火時間／開始として定義した「Ｎ比」を有する。他の運転量または運転プロファイルが使用されてもよい。図４（ａ）は、運転量Ｙを含む垂直軸４０３を有する。図４（ａ）では、運転量は、パーセンテージの確率として表される予期しない停止の可能性として示される。図４（ａ）は、運転のプロファイルＸを含む水平軸４０４も有する。運転のプロファイルは、ファクタを考慮した着火時間／開始として上述のように定義されたＮ比として示されている。曲線４１２は、発電ユニットが運転中であった時間数に応じて故障モードによる予期しない停止の可能性の一例を示す。曲線４１３は、発電ユニットについてのファクタを考慮した開始数に応じた故障モードによる予期しない停止の可能性の一例を示す。曲線４１１は、予期しない停止の総確率を運転のプロファイルの関数として示す合成した曲線である。
【００３９】
図４（ｂ）は、図２に示した運転プロファイルに従って運転のプロファイルの関数として運転量のグラフを示す。ここで、図４（ａ）に示されるように、例示的な運転量として、「予期しない停止の可能性」が使用される。例示的な運転プロファイルは、ファクタを考慮した着火時間／開始として定義した「Ｎ比」を有する。他の運転量または運転プロファイルが使用されてもよい。図４（ｂ）は、運転量Ｙを含む垂直軸４０３を有する。図４（ｂ）では、運転量は、パーセンテージの確率として表される予期しない停止の可能性として示される。図４（ｂ）運転のプロファイルＸを含む水平軸４０４を有する。運転のプロファイルは、ファクタを考慮した着火時間／開始として上述のように定義されたＮ比として示されている。曲線４２２は、発電ユニットが運転中であったファクタを考慮した着火時間数に応じて故障モードによる予期しない停止の可能性の一例を示す。曲線４２３は、発電ユニットについてのファクタを考慮した開始数に応じた故障モードによる予期しない停止の可能性の一例を示す。曲線４２１は、予期しない停止の合計可能性を運転のプロファイルの関数として示す合成した曲線である。
【００４０】
図４（ｃ）は、図３に示した運転プロファイルに従って運転のプロファイルの関数として運転量のグラフを示す。ここで、図４（ａ）のように、例示的な運転量として、「予期しない停止の可能性」が使用される。例示的な運転プロファイルは、ファクタを考慮した着火時間／開始として定義した「Ｎ比」を有する。他の運転量または運転プロファイルが使用されてもよい。図４（ｃ）は、運転量Ｙを含む垂直軸４０３を有する。図４（ｃ）では、運転量は、パーセンテージの確率として表される予期しない停止の可能性として示される。図４（ｃ）は、運転のプロファイルＸを含む水平軸４０４を有する。運転のプロファイルは、ファクタを考慮した着火時間／開始として上述のように定義されたＮ比として示されている。曲線４３２は、発電ユニットが運転中であったファクタを考慮した着火時間数に応じて故障モードによる予期しない停止の可能性の一例を示す。曲線４３３は、発電ユニットについてのファクタを考慮した開始数に応じた予期しない停止の可能性の一例を示す。曲線４３１は、予期しない停止の合計可能性を運転のプロファイルの関数として示す合成した曲線である。
【００４１】
図５は、図２〜図３に示した運転プロファイルに従って運転のプロファイルの関数として運転量のグラフを示す。ここで、図４（ａ）にあるように、例示的な運転量として、「予期しない停止の可能性」が使用される。例示的な運転プロファイルは、ファクタを考慮した着火時間／開始として定義した「Ｎ比」を有する。他の運転量または運転プロファイルが使用されてもよい。図５は、運転量Ｙを含む垂直軸５０３を有する。図５では、運転量は、パーセンテージの確率として表される予期しない停止の可能性として示される。図５は、運転のプロファイルＸを含む水平軸５０４をやはり有する。運転のプロファイルは、ファクタを考慮した着火時間／開始として上述のように定義されたＮ比として示されている。
【００４２】
図５は、曲線５１１において従来技術に従って、図５の曲線５２１において図２中の線２０２として示される保守間隔に従って、および図５の曲線５３１において、図３中の線３０８として示される保守間隔に従って、予期しない停止の合計可能性を近接させる。
【００４３】
現在最も実際的で好ましい実施形態であるとみなされるものとともに本発明を説明してきたが、本発明は開示した実施形態に限定されず、逆に添付の特許請求の範囲の精神および範囲内に含まれる様々な修正形態および均等な構成を含むものであることを理解されたい。
【００４４】
最後に、代表的な実施態様を以下に示す。
［実施態様１］
一群の発電ユニット内の複数のユニット（２０８、２１１）ごとに推奨保守間隔を決定する方法であって、
一群の発電ユニット内の複数のユニットについての運転データおよび予期しない保守データを収集するステップ（１０１）と、
前記運転データおよび予期しない保守データを評価するステップ（１０１）と、
前記実験的データに基づいて複数の故障モードモデルを生成するステップ（１０１）と、
前記複数の故障モードモデルを合成するステップ（１０２）と、
前記複数の故障モードモデルの前記合成のために目標の運転の量を確立するステップ（１０３、１０４）と、
前記目標の運転の量に基づいて前記一群の発電ユニットについて一群の推奨保守間隔を生成するステップ（２０２、３０２）と、
前記一群の発電ユニット内の前記複数のユニットごとに運転のプロファイルを計算するステップ（２０８）と、
各ユニットの前記運転のプロファイルに基づいて前記一群の発電ユニット内の前記複数のユニットごとに前記推奨保守間隔を計算するステップ（１０８、１０９、２１０）と
を含む方法。
［実施態様２］
前記一群の発電ユニットは、新しい前記推奨保守間隔内で再評価される（１０９）、実施態様１記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様３］
選ばれた前記運転の量は、予期しない保守の可能性、予期しない保守のコスト、信頼性、利用度、または合計ライフサイクルコストのうちの１つである、実施態様１記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様４］
選ばれた前記運転の量は、ユニットごとに関心の１つまたは複数のサブシステムについて故障モードレベルで信頼性モデルおよびデータに直接関連付けられている、実施態様１記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様５］
評価は、設計評価ツールを用いて行われる、実施態様２記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様６］
前記複数の故障モードモデルは、運転パラメータの関数として予期しない保守イベントの確率を出力するように設計されている、実施態様１記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様７］
前記複数の故障モードモデルは、故障モードが生じた場合に故障モードの結果について結果データを含む、実施態様１記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様８］
前記結果データは、イベント継続時間、イベントコスト、および／または修理コストを含む、実施態様７記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様９］
故障モードモデルの組み合わせは、前記推奨保守間隔を決定するビジネスが前記一群内のユニットごとに一定を維持するように選ぶ関心の運転の量になる、実施態様１記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様１０］
各運転のプロファイルが選ばれた前記運転の量の同じ値になるように前記推奨保守間隔を調整するステップ（１０７）をさらに含む、実施態様１記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様１１］
前記運転のプロファイルは、ファクタを考慮した開始対ファクタを考慮した時間領域の内に曲線（２０２）を含む、実施態様１記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様１２］
前記ファクタを考慮した開始とファクタを考慮した着火時間領域は、任意の所与の時間／開始の比について前記保守間隔を定める、実施態様１１記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様１３］
前記設計評価ツールは、何らかのさらなる故障モードモデルが前記組み合わせた複数の故障モードモデル内に含まれるべきか決定するための故障モード／効果分析（ＦＭＥＡ）を含む、実施態様５記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様１４］
コンポーネントレベルで故障モードモデルを決定するステップをさらに含む、実施態様１記載の推奨保守間隔を決定する方法（１０８、１０９）。
［実施態様１５］
一群のユニット内のユニットのための推奨保守間隔を決定するシステムであって、
前記一群のユニットと、
前記一群のユニットの信頼性データを測定し、収集し、および／または取り込むように構成された少なくとも第１のツールと、
前記一群のユニットの前記信頼性データを記録するように構成された少なくとも第１の記憶装置と、
前記一群のユニットの前記信頼性データを評価するように構成された少なくとも第１の分析装置と
を備え、
前記分析装置は、入力を有するように配置され、それによって使用者が運転量を選択できるとともに、前記分析装置が少なくとも前記信頼性モデルおよび前記目標運転量に基づいて推奨点検間隔を生成するように構成されているシステム。
【符号の説明】
【００４５】
１０１〜１１１  ステップ
２０１  曲線
２０２  曲線
２０３  ファクタを考慮した着火開始
２０４  ファクタを考慮した着火時間
２０５  点
２０６  領域
２０７  領域
２０８  線
２０９  点
２１０  点
２１１  線
２１２  点
２１３  点
３０１  曲線
３０２  曲線
３０３  ファクタを考慮した着火開始
３０４  ファクタを考慮した着火時間
３０６  領域
３０７  領域
３０８  第３の曲線、曲線
３０９  矢印
４０３  垂直軸
４０４  水平軸
４１１  曲線
４１２  曲線
４１３  曲線
４２１  曲線
４２２  曲線
４２３  曲線
４３１  曲線
４３２  曲線
４３３  曲線
５０３  垂直軸
５０４  水平軸
５１１  曲線
５１２  曲線
５１３  曲線
【図１】
2017151980.tif 000003
【図２】
2017151980.tif 000004
【図３】
2017151980.tif 000005
【図４（ａ）】
2017151980.tif 000006
【図４（ｂ）】
2017151980.tif 000007
【図４（ｃ）】
2017151980.tif 000008
【図５】
2017151980.tif 000009
【外国語明細書】
2017151980000001.pdf