JP2023536677A - 車両の改善されたメンテナンスのための車両レベル故障予測 - Google Patents

車両の改善されたメンテナンスのための車両レベル故障予測 Download PDF

Info

Publication number
JP2023536677A
JP2023536677A JP2022573618A JP2022573618A JP2023536677A JP 2023536677 A JP2023536677 A JP 2023536677A JP 2022573618 A JP2022573618 A JP 2022573618A JP 2022573618 A JP2022573618 A JP 2022573618A JP 2023536677 A JP2023536677 A JP 2023536677A
Authority
JP
Japan
Prior art keywords
data
component
sensor
model
components
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2022573618A
Other languages
English (en)
Inventor
ディクシット、スニール
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Northrop Grumman Systems Corp
Original Assignee
Northrop Grumman Systems Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US16/945,263 external-priority patent/US10964130B1/en
Application filed by Northrop Grumman Systems Corp filed Critical Northrop Grumman Systems Corp
Publication of JP2023536677A publication Critical patent/JP2023536677A/ja
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0221—Preprocessing measurements, e.g. data collection rate adjustment; Standardization of measurements; Time series or signal analysis, e.g. frequency analysis or wavelets; Trustworthiness of measurements; Indexes therefor; Measurements using easily measured parameters to estimate parameters difficult to measure; Virtual sensor creation; De-noising; Sensor fusion; Unconventional preprocessing inherently present in specific fault detection methods like PCA-based methods

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

地上ベースのコンピューティングシステムは、同様の航空機に配置された同様の構成要素の性能パラメータのデータを受信し、それぞれの同様の構成要素の対応する劣化レベルおよび劣化の変化率を判定する。同様の構成要素のグループの車両レベルの劣化は、それぞれのグループの同様の構成要素の合成劣化の解析に基づいて生成される。それぞれの同様の構成要素の各々の残存耐用年数（ＲＵＬ）および健全状態（ＳＯＨ）の少なくとも一方は、同様の構成要素の各々の劣化レベルと同様の構成要素のグループの車両レベルの劣化との比較に基づいて判定される。同様の構成要素の各々の予測メンテナンス時間は、同様の構成要素のＲＵＬおよびＳＯＨのうちの対応する少なくとも１つに基づいて判定され、これにより、車両レベル情報に基づいて構成要素の費用効果の高いメンテナンスの判定が可能になる。

Description

関連出願の相互参照
本特許出願は、２０２０年２月２６日「に出願された「ＰＲＯＧＮＯＳＴＩＣＳ ＦＯＲ ＩＭＰＲＯＶＥＤ ＭＡＩＮＴＥＮＡＮＣＥ ＯＦ ＶＥＨＩＣＬＥＳ」と題する米国特許出願第１６／８０１，５９６号の一部継続出願であり、これは２０１９年９月２６日に出願された「ＨＩＧＨ ＦＲＥＱＵＥＮＣＹ ＳＥＮＳＯＲ ＤＡＴＡ ＡＮＡＬＹＳＩＳ ＡＮＤ ＩＮＴＥＧＲＡＴＩＯＮ ＷＩＴＨ ＬＯＷ ＦＲＥＱＵＥＮＣＹ ＳＥＮＳＯＲ ＤＡＴＡ ＵＳＥＤ ＦＯＲ ＰＡＲＡＭＥＴＲＩＣ ＤＡＴＡ ＭＯＤＥＬＩＮＧ ＦＯＲ ＭＯＤＥＬ ＢＡＳＥＤ ＲＥＡＳＯＮＥＲＳ」と題する米国特許出願第１６／５８３，６７８号の一部継続出願であり、これは２０１８年１０月１８日に出願された「ＰＡＲＡＭＥＴＲＩＣ ＤＡＴＡ ＭＯＤＥＬＩＮＧ ＦＯＲ ＭＯＤＥＬ ＢＡＳＥＤ ＲＥＡＳＯＮＥＲＳ」と題する米国特許出願第１６／１６３，７２６号の一部継続出願であり、これら全内容は参照により本明細書に組み込まれる。
本発明の実施形態は、一般に、複雑な車両、例えば航空機の構成要素のメンテナンスがいつ必要であるかを判定することに関する。さらに、実施形態は、すべての同様の航空機の同様の構成要素のメンテナンスが必要であるか否かを、そのような構成要素に関連付けられた車両レベルデータの解析に基づいて識別し、費用がかかり、かつ労働集約的である従来の固定時間間隔に基づいた「スケジュールされたメンテナンス」に対して、認定メンテナンス技術者のために構成要素の状態に基づいて、実施可能な動的かつ費用効果の高い「予測メンテナンス」スケジュールを生成する。
車両、航空機、宇宙船および他のシステムなどの複雑なシステムのメンテナンスは、運用費用が大きい。そのようなシステムのメンテナンスは、典型的には、システムの様々な構成要素のための所定のスケジュールで（周期的な時間に基づいて）行われる。スケジュールは、例えば３ヶ月ごとなど、単に時間ベースであってもよく、または例えば、平均故障間隔（ＭＴＢＦ）構成要素信頼性計算によって判定される運用の３ヶ月ごとまたは１０００時間ごとなど、時間、使用状況、および信頼性メトリックの組み合わせに基づいてもよい。時間および使用状況は、典型的には、同様の動作環境で利用されるのと同じまたは同様の構成要素の性能履歴に基づく。そのような信頼性メトリックに完全に基づくスケジュールされたメンテナンスは、多くの商用システムおよび国防総省のシステムにおいて最適とは言えないことが示されている。国防長官府（ＯＳＤ）は、２０３２年までにすべてのシステムが状態基準保全プラス（ＣＢＭ＋）プロセスに従うことを指示する指令４１５１．２２（マンデート）を発行した。ＣＢＭ＋プロセスは、構成要素の状態に基づいてスケジュールされるメンテナンスを提供し、もはや所定の時間ベースおよび使用状況ベースのメンテナンスを提供しない。しかしながら、ＣＢＭ＋要件の遵守は重大な課題を提示している。
構成要素のそのような所定のスケジュールされたメンテナンスは、いくつかの環境では満足のいくものであったが、このタイプのメンテナンスは、他の環境のいくつかの機器／車両ではうまくいかないものもあった。所定のスケジュールされたメンテナンスは、費用がかかり、テストのために部品を取り出してそれらを交換することによって偶発的な事故をもたらす可能性がある不必要なメンテナンスに起因して、車両の可用性が遅延する原因であることが判明している。例えば、ジェット機を考える。同じタイプのジェット機は、様々な非常に異なる環境条件、例えば、広範囲に変化する温度および吹き付ける砂を有する砂漠と、それに対し、わずかな浮遊ダストしかない温帯地域で利用することができる。さらに、同じ航空機が同じ外部環境条件下で運用する場合、異なるパイロット、特に軍用パイロットは、航空機構造に異なる負荷変動を引き起こす実質的に異なる方法で同じ航空機を飛行させることを選択してもよい。また、異なるミッションは、航空機の構成要素に異なるレベルの応力をもたらす。したがって、構成要素の所定のスケジュールされたメンテナンスは、期待された応力よりも大きいために必要なメンテナンスを実行しない結果となり得るか、または期待された応力よりも著しくレベルが低いレベルのために不要なメンテナンスを実行する結果となり得る。車両の構成要素のメンテナンスのタイミングを改善するための信頼性の高い故障予測は、より費用効果の高いソリューションを提供すると共に、不要なメンテナンスを回避し、航空機／システムの運用上の稼働率を高め、メンテナンス要員をより良く活用する。実際に必要とされるときにのみメンテナンスを実行することは、同様の航空機の何機もメンテナンスしなければならない場合にはさらに重要である。したがって、同じ構成要素についての複数の同様の航空機にわたる構成要素性能のメトリックを利用して、構成要素のオンボードテスト基準を改善し、同様の構成要素についての車両全体の同時メンテナンス判定を行うことができるように、同様のタイプの航空機の車両内の構成要素のメンテナンスのより正確な予測が必要である。
本発明の実施形態の１つの目的は、複数の同様の航空機にわたる対応する構成要素性能の車両全体のメトリックの組み込みに基づいて信頼性の高い故障予測をもたらすために、より高い精度でオンボード構成要素モデルを更新する必要性を満たすことである。
本発明の一実施形態の別の目的は、すべての同様の航空機に配置された同じ構成要素のメンテナンスが必要であるか否かを、そのような構成要素に関連付けられた車両レベルデータの解析に基づいて識別することである。
地上ベースのコンピューティングシステムは、同様の航空機に配置された同様の構成要素の性能パラメータのデータを受信し、それぞれの同様の構成要素の対応する劣化レベルおよび劣化の変化率を判定する。同様の構成要素のグループの車両レベルの劣化は、それぞれのグループの同様の構成要素の合成劣化の解析に基づいて生成される。それぞれの同様の構成要素の各々の残存耐用年数（ＲＵＬ）および健全状態（ＳＯＨ）の少なくとも一方は、同様の構成要素の各々の劣化レベルと同様の構成要素のグループの車両レベルの劣化との比較に基づいて判定される。同様の構成要素の各々の予測メンテナンス時間は、同様の構成要素のＲＵＬおよびＳＯＨのうちの対応する少なくとも１つに基づいて判定され、これにより、車両レベル情報に基づいて構成要素の費用効果の高いメンテナンスの判定が可能になる。
本発明のいくつかの例示的な実施形態は、本発明の実施形態の動作がより理解されるために、添付の図面を参照して以下に説明されるＩＶＨＭシステムおよびデータ融合モジュールからの入力を組み込む。
航空機における機器故障の診断解析のためのオンボード動作ＩＶＨＭシステムおよびそのインターフェースのブロック図を示す。 ＩＶＨＭシステムのデザイン、動作、およびメンテナンスプロセスおよびインターフェースのブロック図を示す。 ＩＶＨＭシステムと共に使用するためのサブシステムのモデルを示す。 図３のモデルにおける構成要素を表す図を示す。 図３のモデルにおける機能ノードを表す図を示す。 図３のモデルにおけるセンサノードを表す図を示す。 図３のモデルにおける較正された境界センサノードを表す図を示す。 センサノードへのデータマッピングを表す図を示す。 ＩＶＨＭシステムで使用するためのモデルをテストするための機構を表す図を示す。 障害障解析レポートの一例を示す。 誤警報レポートの一例を示す。 高周波センサデータおよび低周波センサデータが処理され統合されるデータメッセージインターフェースの一実施形態のブロック図である。 図１１の異常検出器かつ劣化検出器の一実施形態のブロック図である。 図１１に示すデータ融合モジュールの一実施形態のブロック図である。 遠心ポンプにおけるモータ軸受の振動センサからの例示的な高周波センサデータを示し、正常なポンプ軸受および欠陥のあるポンプ軸受に対応する代表的なセンサデータを示す。 遠心ポンプにおけるモータ軸受の振動センサからの例示的な高周波センサデータを示し、正常なポンプ軸受および欠陥のあるポンプ軸受に対応する代表的なセンサデータを示す。 良好な軸受および不良な軸受にそれぞれ関連付けられた電力に対応する遠心ポンプへの電力を監視するセンサからの例示的な高周波センサデータを示す。 良好な軸受および不良な軸受にそれぞれ関連付けられた電力に対応する遠心ポンプへの電力を監視するセンサからの例示的な高周波センサデータを示す。 動的異常認識に利用される高周波センサ信号および導出されたセンサ信号平均を示す例示的なグラフである。 動的異常認識に利用される高周波センサ信号および導出されたセンサ信号平均を示す例示的なグラフである。 動的異常認識に利用される高周波センサ信号および導出されたセンサ信号平均を示す例示的なグラフである。 動的異常認識に利用される高周波センサ信号および導出されたセンサ信号平均を示す例示的なグラフである。 動的異常認識にも利用される導出された数学関数を有する高周波センサ信号の例示的なグラフである。 図１２の異常／劣化検出器を実施するために利用することができる例示的な工程のフロー図である。 図１３のデータ融合を実施するために利用することができる例示的な工程のフロー図である。 高周波センサ解析および低周波センサデータとの統合を実施するための例示的なコンピューティングシステムのブロック図である。 構成要素の状態に基づいて構成要素レベルのメンテナンスの必要性を判定するための例示的な故障予測システムのブロック図である。 各構成要素の挙動およびパラメータを特徴付ける異なるモデルの例示的なハイブリッドシステムのブロック図である。 構成要素レベルでのサービス品質メトリックを示す。 ブラインポンプの軸受性能および電力分配性能の例示的な劣化を示す。 残存耐用年数の判定に利用されるブラインポンプ性能の傾斜の例示的な変化を示すグラフである。 ブラインポンプの例示的な物理システムモデルで監視されるブラインポンプの構成要素を示す図である。 粒子フィルタ判定および寿命末期予測の例示的なフローチャートを示す。 粒子フィルタ判定および寿命末期予測の例示的なフローチャートを示す。 図２７の２段カルマンフィルタの例示的な実施形態をより詳細に示すブロック図である。 ２段カルマンフィルタの機能を示す例示的な工程の方法のフロー図である。 収集された車両レベルデータを使用して、車両レベルデータに基づいて改善された構成要素メンテナンスメトリックを提供するための例示的な車両レベル故障予測システムのブロック図を示す。 収集された車両レベルデータを使用して、車両レベルデータに基づいて改善された構成要素メンテナンスメトリックを提供するための例示的な車両レベル故障予測システムのブロック図を示す。 図３７の解析融合モジュールのブロック図である。 オンボード構成要素の性能評価と車両レベル構成要素の性能評価との両方に使用されるモデルおよびアルゴリズムの精度を高める工程を示すフロー図である。 オンボード構成要素の性能評価と車両レベル構成要素の性能評価との両方に使用されるモデルおよびアルゴリズムの精度を高める工程を示すフロー図である。 航空機の車両におけるすべての同様の構成要素が、車両レベルの性能メトリックおよび生成された予測メンテナンススケジュールに基づいて同時メンテナンスを必要とするときを判定する工程を示すフロー図である。 オンボードおよび車両レベルの故障予測システムのデザイン、訓練、および改良を示すブロック図である。 単一の航空機、車両内の航空機のサブセット、または車両全体の車両レベル故障予測システムによって生成されるレポートおよびメトリックを選択するためのグラフィカルユーザインターフェース（ＧＵＩ）を示す。 時間間隔ベースでスケジュールされたメンテナンスと比較した、例示的な構成要素の予測メンテナンススケジュールのチャートである。 地上ベースの車両故障予測システムを制御するためのＧＵＩを示す。 例示的な構造構成要素の健全状態（ＳＯＨ）インジケータを判定するためのフローチャートである。 構成要素のメンテナンス特性対時間のグラフである。 構成要素のメンテナンス特性対時間のグラフである。 構造材の繰り返し負荷、応力、および亀裂進展の関係を示すチャートである。 障害管理、様々なメンテナンス方法、および行動の相互関係を示すチャートである。
車両レベルの故障予測の実施形態は、図１～図３５との関係で説明したような他の発明に関連付けられた実施形態および特徴の説明から利益を得る。車両レベルの故障予測の実施形態は、図３６～図４８に関連付けられて説明される。
一実施形態では、故障予測システムは、データ融合モジュール１１７５およびＭＢＲ診断エンジン１０６からの入力を利用する。ＩＶＨＭシステムは、図１１のすべてのモジュール、ＭＢＲ診断システム、および現在の対象故障予測システムを含み、その説明は、ＭＢＲ診断エンジンおよびデータ融合モジュールの説明に続く図２６に関連付けられた本文を参照することから始まる。
モデル駆動アーキテクチャ（ＭＤＡ）およびモデルベースのエンジニアリング（ＭＢＥ）を使用するＩＶＨＭは、システムが変更またはアップグレードされるたびにソフトウェアおよびハードウェア要素をフライト認定するのではなく、一度に認定するソリューションである。これは、システムの診断ドメイン知識を有するモデルを含むＸＭＬフォーマット構成ファイルを使用することによって、大幅な費用削減をもたらす。モデルは精度を検証する必要があるが、高価で時間がかかるソフトウェアフライト認定を必要としない。これにより、軍事活動費用および支援費用が２５％から－３５％削減される。
図１は、航空機１２のＩＶＨＭ（統合型車両健全性管理）システム１０の機能的挙動およびインターフェースを示し、ＭＢＲ（モデルベース推論）エンジン１４は、航空機１２のアビオニクスベイ内の計算デバイス（不図示）上で動作する。航空機は図１を参照して示され説明されているが、実施形態はこのタイプの車両に限定されない。観測された挙動１６は、様々な航空機アビオニクスデータバスから得られたＢＩＴ（ビルトインテスト）、パラメトリック、アナログ、および離散のセンサデータを指す。期待された挙動１８は、様々なサブシステム、ライン交換可能ユニット（ＬＲＵ）、およびシステム全体の構成要素のモデル化されたドメイン知識２０から予想されるものを指す（このモデルはＸＭＬフォーマットで表される）。構成要素とは、サブシステム、ＬＲＵ、および部品を指す。観測された挙動１６が期待された挙動と異なる場合１８、異常な挙動（不一致／残差）が登録され、ＭＢＲエンジン１４は診断モードに入る（因果解析）。様々な推論アルゴリズムおよびＢＩＴ、パラメトリック、およびセンサデータの解析により、ＭＢＲエンジン１４は、故障した構成要素の検出、単一の故障した構成要素または同様の構成要素の多義性グループへの分離、誤警報識別、故障した構成要素の機能的評価（すなわち、ポンプ内の漏れ、パイプ内の漏れ、空気流の閉塞、軸受の損傷、および構成要素の物理に依存する他の評価）、および未知の異常を含む結果２２を生成する。未知の異常の場合、モデル２０は、構成要素、およびその故障モードに関連する他の構成要素とのその相互作用に関する追加情報を用いて改良される。この情報は、これらの構成要素の製造業者から得られ、追加の故障モードが既存のモデルに追加される。チェーン（直列または並列）内の同様の要素の多義性グループを低減するために、典型的には、多義性グループ内の特定の構成要素に分離するために追加のセンサが必要とされる。サイズ、重量、および電力の制限に起因し、追加のセンサを適用することができない場合、メンテナンス管理者は、局所的な多義性グループ内でオフボード診断解析を実行しなければならない。
図２は、ＩＶＨＭシステム１００のブロック図を示す。図２の様々な構成要素は、相互接続された機能、故障モード、故障確率、およびモデル化されたシステムにおける機能的評価を論理的に組み合わせるために互いにリンクされ、デザインソース（１１４，１１６，１１８，１２０）、パイロットのディスプレイに配信されるリアルタイムまたは後処理の入力データ（運用フライトプログラム１０２から得られ）、地上システム（ＯＦＰ １０２から得られ）、および維持管理者の地上メンテナンス行動１２２のためのディスク上のストレージ（１２６）にもリンクされる。説明の目的のために、ＩＶＨＭシステム１００はブロック図として表されているが、説明されている機能および方法は、様々な方法でハードウェア構成要素において論理的に組み合わされてもよい。
運用フライトプログラム（ＯＦＰ）１０２は、車両の全体的な運用を管理するためのハードウェアおよびソフトウェアを包含する。ＯＦＰ １０２は、ランタイム診断エンジンＩＶＨＭＥｘｅｃ １０４を含む。ＯＦＰ １０２はまた、アビオニクスデータバスに受動的に取り付けられ、ミッション計画システムと能動的にインターフェースされ、地上システムおよびメンテナンスシステム１２２と能動的にインターフェースされたスタンドアロンのアビオニクスＩＶＨＭコンピュータとして実装されてもよい。ＩＶＨＭＥｘｅｃ １０４は、診断モデルベース推論（ＭＢＲ）エンジン１０６を含む。ＭＢＲエンジン１０６は、車両システムまたはサブシステムの物理モデルをシステム状態を記述する入力データと組み合わせ、その後、システムが正常に動作しているか否か、システム異常が存在するか否かを判定するために決定論的推論を実行し、システム異常が存在する場合には、存在する障害および誤警報の位置およびタイプを分離し、識別する。ＩＶＨＭＥｘｅｃ １０４は、ポータブルメンテナンスデバイスビューア１２２によってもアクセスされ得るディスク１２６にメンテナンス記録を書き込む。
ＭＢＲエンジン１０６は、ＭＢＲエンジン１０６による意思決定を容易にするために高周波センサデータおよび低周波センサデータが共に解析および統合されるデータメッセージインターフェース１０８を介してリアルタイムセンサデータを受信する。ＭＢＲエンジン１０６はまた、リアルタイム動作インターフェース１１２を介して車両のランタイム動作モデル１１０を受信する。車両のモデル１１０は、モデル開発グラフィカルユーザインターフェース（ＧＵＩ）１１４を使用してモデリングエンジニアによって作成される。モデル１１０は、オフライン（非リアルタイム）でＭＢＲエンジン１０６を用いて作成および検証され、その後ＩＶＨＭＥｘｅｃ １０４のリアルタイム埋め込みビルドによって使用されるＸＭＬファイルにエクスポートされる。モデル１１０の作成に加えて、ＧＵＩ １１４はモデルを検証するためにも使用される。検証および妥当性確認は、特定の入力データを使用しない、モデルの内部論理および要素のテストである。このプロセスは、モデルが適切に動作しない、あるいは全く動作しないようなエラーがなく、モデルが論理的に一貫していることを保証するために必要である。
モデル開発プロセスのさらなる工程として、テストマネージャ１１６は、シミュレートされたフライトデータ１１８または実際のフライトデータ１１８に対してモデルをテストすることによってモデルを評価する。開発インターフェース１２０は、ＩＶＨＭＥｘｅｃ １０４ランタイム実行可能ファイルに静的または動的に（スタンドアロンＩＶＨＭＥｘｅｃの場合は静的に、グラフィカルユーザインターフェース（ＧＵＩ）との統合の場合は動的に）リンクされた別個のクラスであるＭＢＲエンジン１０６アルゴリズムの修正および追加を可能にする。検証がモデルを論理的にテストする一方で、テストマネージャ１１６は、モデル性能および出力が所望通りであることを保証する。モデルが検証およびテストされると、ＸＭＬモデル構成ファイル１１０が生成される。
ＩＶＨＭＥｘｅｃ １０４は、モデルのＸＭＬ表現をロードし、車両内の様々なバスから受信される入力センサデータメッセージおよび／または地上で再生するための様々なフォーマットの記憶された履歴データにモデルを適用することによって、ＭＢＲエンジン１０６をリアルタイムで実行する実行部である。ＩＶＨＭＥｘｅｃ １０４はまた、開発インターフェース１２０を介してテストマネージャ１１６によって使用されてもよい。ストレージインターフェース１２４は、ＭＢＲエンジン１０６を記録データストレージ１２６に接続する。記録データ１２６は、ログファイル、機器の完全なタイムスタンプされた状態、例えばスナップショット、タイムスタンプされた障害／故障異常、検出、分離、および分離に対する任意の機能的評価を含む。ログファイルはまた、ＭＢＲエンジンソフトウェア状態（バージョン番号、故障および再起動）、他の航空機ソフトウェアの識別、それらのバージョン番号、故障の場合は故障時の状態、ソフトウェアの再起動、および故障につながる機能的評価も含む。このデータの収集は、航空機で発生した実際の事象の診断視覚化の再生を可能にし、メンテナンス管理者が故障した構成要素につながるハードウェアとソフトウェアの両方の相互作用をよりよく理解することを可能にする。記録データストレージ１２６は、ＭＢＲエンジン１０６によって使用される生データおよびその処理の結果を記憶する。
一実施形態では、ＭＢＲエンジン１０６は、動的に較正されたデータ入力能力と、パラメータ化された直接アナログセンサデータと対応するビルトインテスト（ＢＩＴ）入力とのＩＶＨＭデータ融合のためにセンサロジック内で組み合わされた論理ゲート（積集合ＡＮＤ、和集合ＯＲ、排他的論理和ＸＯＲなど）、ルール、事例（履歴）、および決定木のセットとを含む。パラメトリックデータ、直接アナログセンサデータ、およびＢＩＴ結果の比較は、故障および誤警報予測における信頼性尺度をもたらす。
ここで、ＭＢＲエンジン１０６が使用するモデルの作成例について説明する。一実施形態では、モデルは、モデル化車両内の多くのソースからのデータ融合を提供する。特に、モデルは、ＭＢＲエンジン１０６がアナログデータ入力および定量化されたデジタルデータ入力を含むことを可能にするパラメータ化されたデータ入力能力を含んでもよく、異常の存在を判定するために測定された物理量に対して固定された境界または動的に較正された境界を有する。パラメータ化されたデータ異常判定は、単純な固定された境界、物理センサ動作に基づいて動的に変化する較正値、または信号ノイズ低減、ウィンドウ処理、待ち時間および同様のパラメータ化されたデータ調整を含む、より複雑な判定プロパティに基づくことができる。これらのデータ較正パラメータおよび閾値は、システムのリアルタイム動作中の評価のためのセンサノードプロパティとなる。関数は論理セットおよびオペランドとして表すことができ、ルールは論理セット、自然言語セマンティクス、履歴挙動（事例ベース）、または決定木（障害木解析）として表してもよい。例えば、圧力関数の場合、モデルは、フロー圧力が提供されるか否かを評価し、所望の関数論理に従って他の入力を組み合わせる。一実施形態では、各入力は、関数が真として評価されるための正の結果を示さなければならないが、他の論理関数も使用されてもよい。この関数の様々なユーザ定義パラメータは、関数のノードプロパティとして表すことができる。車両の１つまたはＸＭＬ ＭＢＲモデル１１０およびアビオニクス計算デバイスで実行されるバイナリＩＶＨＭＥｘｅｃ １０４リアルタイムエンジンは、車両全体のＩＶＨＭ能力／機能を提供する。
パラメトリックおよびＢＩＴ ＭＢＲモデルは、それらの機能によって関連する構成要素およびセンサを含んでもよい。一実施形態では、車両システムまたはサブシステムのモデルは、図３に示すように、グラフ内のノードとして表してもよい。特に、図３は、図２のモデル開発ＧＵＩ １１４を使用して表されるように、診断ノードまたは非診断ノードの両方を含む環境制御サブシステム（ＥＣＳ）の一例を示す。説明の目的のために、特定の例が説明されるが、本明細書で説明される原理は、車両の任意のサブシステムまたはシステムに適用されてもよい。モデリングエンジニアは、図２のＧＵＩ １１４を介して図３のモデルと対話する。
診断ノードは、障害または誤警報を引き起こすシステム構成要素を判定するためにＭＢＲモデル推論エンジンで直接使用され、非診断ノードは、センサ出力およびＢＩＴテスト比較などのタスクに使用される。非診断ノードは、パラメトリックセンサデータとＢＩＴデータ結果とのリアルタイム比較に使用される。パラメトリックセンサは、（センサが故障していないときの）真のシステム挙動を表し、ＢＩＴデータが対応する構成要素の故障を示すときに名目上動作している場合、この結果は誤警報として示される。故障したセンサは、センサの偽陽性テストおよび偽陰性テストから識別される。フロー圧力構成要素などの構成要素は、構成要素をモデルの他の要素に接続することによって、その状態（例えば、オン、オフ、高圧または低圧など）およびステータス（動作可能、故障、漏れなど）がＭＢＲエンジン１０６によって示される特定のシステム要素を指す。センサノードは、例えば、直接センサアナログ入力、パラメトリックデータ入力、およびバイナリＢＩＴデータ入力などの多くの形態をとることができる入力データを用いてモデル化される。図３を参照すると、代表的な構成要素ノードがＥＣＳフロー圧力センサノード２０２として示されている。他の構成要素ノードには、ＥＣＳフロー２０４、ＥＣＳ冷却２０６、およびＥＣＳ準備完了２０８が含まれる。
図３Ａは、機能ノードアイコンをダブルクリックすることによってモデリングエンジニアが見ることができるノード２０２の様々なユーザ定義パラメータを示し、ノード２０２（円形）の図３Ａに示すウィンドウが表示される。ノードプロパティで定義されるパラメータは、ノードクラス３０１、デフォルトパラメータ値３０３、ならびにノード２０２の能力、出力、およびステータスデータ型を定義するデータ項目３０５を含む。特定のラベルおよび特徴が図３Ａに示されているが、これらは、モデル化されている機能およびモデル化された車両のデザインに応じて変えてもよい。
デフォルトパラメータ値３０３，３１１は、利用可能なサプライヤデータがないことを示す「０」を有する構成要素サプライヤから入力された故障確率（故障モード）を示す。あるいは、故障確率は、履歴性能データから入力することができる。これは、劣化事象によって再計算することができ、すなわち、故障確率は、劣化事象と共に増加する。間欠性閾値３１３は、例示的なデフォルト値が５秒である間欠的またはランダムな挙動の時間期間を指す。状態３１５は、例えばオン、オフ、高圧など、構成要素の様々な状態を定義する。利用可能なおよび使用中のパラメータ３１７は、両方とも「真」に設定されているものとして示されている、すなわち、構成要素は利用可能であると共に使用中である。パラメータ３１７のいずれかにおける「偽」状態は、故障および／または電力の損失などの他の理由に起因する可能性があり、リンク仕様３１９は、機能ノードによって他の構成要素へのリンクを指定する。
図３のモデルにおける別のタイプのノードは、機能ノードである。代表的な機能ノードは、提供フロー圧力ノード２１０として示されている。他の機能ノードには、提供フロー２１２、提供冷却２１４、および提供ＥＣＳ準備完了２１６が含まれる。図３の各機能ノードは、基本的なＡＮＤ関数を表している。提供フロー圧力２１０は、例えば、フロー圧力が提供されるか否かを判定するために使用され（論理セットおよび論理オペランド）、所望の機能ロジックに従って他の入力を組み合わせる。この例では、各入力は、結果として生じる関数の状態が真であるためには、正の結果を示さなければならない。機能ノード２１０の様々なユーザ定義パラメータは、モデリングエンジニアが機能ノードアイコンをダブルクリックすることによって見ることができ、機能ノード２１０（楕円形）の図４に示すウィンドウが表示される。ノードプロパティで定義されるパラメータは、ノードクラス３０２、デフォルトパラメータ値３０４、ならびにノード２１０の能力、出力、およびステータスデータ型を定義するデータ項目３０６を含む。特定のラベルおよび特徴が図４に示されているが、これらは、モデル化されている機能およびモデル化された車両のデザインに応じて変えることができる。
図３のモデルにおける別のタイプのノードは、物理センサノードである。代表的な物理センサノードは、図３においてＥＣＳ＿フロー圧力ノード２１８（台形）として示されている。別の物理センサノードがＥＣＳ＿温度ノード２３８として示されている。物理ノードおよび仮想ノードは、多くの形態をとることができる入力データを示すためにモデル内で使用される。上述したように、モデリングエンジニアは、ＧＵＩ １１４を介して図３のモデルと対話する。物理センサノード２１８の様々なユーザ定義パラメータは、ノードアイコンをダブルクリックすることによってモデリングエンジニアが見ることができ、物理センサノード２１８の図５に示すウィンドウが表示される。センサノード２１８の場合、パラメータ化された入力データは、図５に示すノードプロパティのウィンドウにおいてデフォルトとして定義された固定された上限および下限（許容閾値）と共に使用される。パラメータ化されたデータの使用は、図５に見られるような生値４０２としてセンサノードプロパティにリスト化された定量化されたセンサ値の直接解析を可能にする。この場合、センサ生値４０２は、ＥＣＳサブシステムの測定されたフロー圧力を含む。生値４０２が下限４０４を下回るか、または上限４０６を超える場合、センサは異常を示し、その後、ＭＢＲエンジン１０６（図２）によってモデルの残りの部分と共に使用されて、異常の性質および原因を判定する（因果解析図２）。
物理センサノードの別の例は、ＢＩＴ ＥＣＳ＿フロー圧力障害２２０である。このセンサは、モデル化されたシステムからのビルトインテスト（ＢＩＴ）データを使用し、これはデータ出力における異常動作または正常動作のいずれかを示す。このＢＩＴテストは、対応するパラメータ化されたセンサと同じ上限および下限を使用するようにデザインされているが、異常動作の場合には異なる結果を生成する可能性がある。したがって、排他的論理和、すなわち（ＸＯＲ）センサノードであるＸＯＲ＿ＥＣＳ＿フロー圧力ノード２２２への別個のパラメータ化データ入力と共に、ＢＩＴテストを入力として使用する。場合によっては、ＢＩＴテストセンサのみがメンテナンス管理者に利用可能であってもよい。この場合、ＢＩＴテストは、ここでＥＣＳフロー圧力２１８に使用されるパラメトリックセンサノードと同様の診断センサとして使用される。図３のモデルにおける他の物理センサノードは、ＢＩＴ＿ＥＣＳ＿準備未完了ノード２４０およびＢＩＴ＿ＥＣＳ＿一時的障害ノード２４２を含む。
ＸＯＲ＿ＥＣＳ＿フロー圧力ノード２２２は、物理センサノードＢＩＴ＿ＥＣＳ＿フロー圧力障害２２０およびパラメータ化された入力センサノードであるＥＣＳ＿フロー圧力＿ＮＤ ２２８（非診断）からの入力を受信する。別個のパラメータ化入力センサがＸＯＲ入力に使用される理由は、この入力が非診断用である（診断サイクルが実行されない）ためである。センサは、システム障害および誤警報を判定するためにＭＢＲエンジンで使用されることを意味する診断用、またはＭＢＲエンジン評価からそれらを除去するための非診断用のいずれかであり得る。ＸＯＲセンサ入力の場合、ＸＯＲ論理および出力は相補的であり、ＭＢＲエンジン処理から分離されているので、ＭＢＲエンジンとの干渉を防止するために、非診断パラメトリックセンサ入力２２８が望ましい。ここで使用される例では、ＢＩＴテストセンサ２２０も同じ理由で非診断用である。さらに、ＸＯＲセンサの場合、ブランク機能２２６は、各センサがそれに取り付けられた下流機能を有するというデザイン要件を満たすために使用される。別のブランク機能が２３６に示されている。同様に、ノード２２２に対して、ＸＯＲ＿ＥＣＳ＿一時ノード２４４は、物理センサノードＢＩＴ＿ＥＣＳ＿一時的障害２４２およびパラメータ化されたセンサノードＥＣＳ＿温度＿ＮＤ ２２４から入力を受信する。
ＸＯＲ＿ＥＣＳ＿フロー圧力ノード２２２は別個の出力ストリームを生成し、接続されたセンサ（パラメータ化されたセンサノード２２８および対応するＢＩＴテストノード２２０）が異なる評価を提供する場合にのみ正のブール結果を示す。正常の動作条件下では、これは起こるべきではないため、ＸＯＲセンサノードは、システムのＢＩＴまたはパラメータ化された入力のうちの１つが異常な結果を提供しているときを判定するのに有用である。これは、システムの健全性を診断するための別のツールをモデラに提供し、そうでなければ解析が困難な場合がある。
ＢＩＴテストデータフィールドのみが利用可能である場合の一例が、提供フローノード２１２にセンサ入力を提供するＢＩＴ＿ＥＣＳ＿フローステータスフラグ障害ノード２３０として図３に示されている。この場合、ＢＩＴテストノード２３０は診断用であり、ＭＢＲエンジンで直接使用される。図３に見られる他のモデル要素タイプは、例えば２３２として示される、モデルの機能を説明するコメントと、図３に示されるサブモデルに示されるモデル要素の外側（すなわち、Ｏｕｔｓｉｄｅサブモデル：「ＬＴＡに出力」）のモデル要素がサブモデル、具体的には提供冷却機能ノード２１４と通信することを可能にする出力アイコン２３４とを含む。
場合によっては、パラメトリックノードは、固定された上限および下限を有さない。この場合、例えば図６に示すように、別個のノードクラスを使用することができる。このノードは、図３のサブシステムモデルの一部ではない。ここでは、経時的に変化し得る較正値（例えば、較正電圧）を提供する第２の入力が使用される。その後、測定値は、較正値の周りの較正＿マイナス＿パーセント５０２および較正＿プラス＿パーセント５０４（一般にサブシステムサプライヤ情報から判定される）によって定義されるパーセンテージ範囲内に収まらなければならない。このタイプのセンサノードは、パラメータ化されたセンサの限界に対する既知の較正値が存在する場合、図３および図５のＥＣＳ フロー圧力ノード２１８などの境界＿センサ＿ｃｆｇクラスノードの代わりに使用することができる。
一実施形態では、図３に示すようなモデルは、モデルの各要素に対応するデータフィールドのリストを含む。例えば、図７に示すように、ＥＣＳ＿温度（Ｃ）６０２の値は、ＥＣＳサブモジュール内の診断用ＥＣＳ＿温度センサノード６０４および非診断用ＥＣＳ＿温度センサノード６０６にマッピングされる。これらは、このモデルのデータ入力として使用されるファイルフォーマットのデータ列のラベルであり、各サブシステム内の様々なセンサのすべてのデータフィールドを１つのファイルに体系的に定義することを可能にする。ＢＩＴテストデータノードには別個のデータ項目がマッピングされ、較正されたセンサノードには較正データ項目がマッピングされる。ドロップダウンメニュー６０８の生値データ項目選択は、この例示的なデータ項目がＥＣＳ温度センサからの生の測定値であることを示す。モデル（パラメトリックまたはＢＩＴ）内の各センサは、較正されたパラメトリックセンサ用の任意の較正値データセットと共に、データ項目にマッピングされる。
図２に戻って参照すると、モデル開発ＧＵＩ １１４（各サブシステムの動作をエミュレートするために、すべてのセンサ、構成要素、および機能を所定の位置に配置して）を使用してＩＶＨＭ ＭＢＲモデルが構築された後、実際のまたはシミュレートされたシステムデータを使用してモデルを実行する２つの方法がある。上述したように、ＧＵＩ １１４は、テストマネージャ１１６を用いて記録されたフライトデータ１１８を使用してＭＢＲモデルを実行する直接方法を含む。図８は、新規テストポップアップウィンドウ７０２を有する代表的なテストマネージャウィンドウを示す。フライト再生テスト７０４が選択されると、適切なテストシミュレートされたデータまたは実際のフライトデータファイルをオプション７０６から選択し、図２のテストマネージャ１１６にロードすることができる。データファイルを使用してモデルのテストが実行された後、出力ファイルが生成され、メンテナンス記録（すなわち、図２のメンテナンス記録ストレージ１２６）として書き込まれた後に記憶された解析された診断結果と共に見ることができる。既存のフライトデータを有する他のテスト事例は、７０８に示されるものから既に選択されてもよい。図９に示す特定のテストは代表例にすぎず、他の多くのテストを使用してもよい。
代替の実施形態では、ＧＵＩ １１４（図２）を使用するモデリングエンジニアは、ＩＶＨＭＥｘｅｃ １０４（図２）のコマンドラインスタンドアロンバージョンを使用してモデルをテストしてもよい。この手順のために、モデルおよびデータマッピングに関する情報を含むＸＭＬ（拡張可能マークアップ言語）ファイルが生成される（すなわち、図示されていない異なるＧＵＩ画面からの図８の完全な＜＜ＡＰＳ＞＞（ＡＰＳ．ｖｍｄｌ）モデル７０６）。このファイルは、ＩＶＨＭＥｘｅｃ １０４のコマンドラインスタンドアロンバージョンで実行して、ＰＭＤデータビューア１２２（図２）にロードすることができる所定のストレージ位置に出力ファイルを生成することができる。この結果は、同じフライトデータに対してテストマネージャ１１６（図２）で生成されたものと同一であるべきであるが、コマンドライン手順は、大量のデータセットおよび様々な数のシステムＭＢＲモデルのバッチファイル処理を可能にする。
モデルテストの出力データの一例を図１０に示す（ＰＭＤビューア１２２図２）。ＭＢＲエンジン１０６（図２）は、ＥＣＳ＿温度ノード２３８として表されるパラメータ化されたＥＣＳ温度センサにおける障害と、他の温度センサ（これらの場合のいくつか、例えば、ＬＴＡレーザアンプリファイアドライバ温度（不図示）では、利用可能なデータはＢＩＴテストのみであり、したがって、この場合の裏付けをするためにＢＩＴテストノードが使用される）を含む他のサブシステム構成要素における裏付けとの両方を使用して、ＥＣＳ冷却構成要素の障害を分離している。図２および図１０に同様に示すような相互接続されたサブシステムのサブモデルの論理は、ＥＣＳ温度を測定するパラメータ化されたセンサＥＣＳ＿温度ノード２３８が、（サブシステム内部の他のセンサまたは他のサブシステムモデルからの外部センサからの）適切な裏付けのある異常であると判定された場合に、この結果を指示する。さらに、ＥＣＳ温度異常を測定するＢＩＴテストＢＩＴ．ＥＣＳ＿一時的障害ノード２４２は、故障を別々に示している。このセンサノードは非診断用であり、したがってシステム障害を判定するために使用されないが、非診断用ＥＣＳ＿温度＿ＮＤパラメトリックセンサノード２２４の比較器として使用される。ＢＩＴノードとパラメトリックノードとの間の変動は、障害ＢＩＴテストまたはセンサを示すことができ、パラメータ化されたセンサを実装することによって追加される能力の１つである。
図１０は、誤警報を生成するＭＢＲエンジン１０６の出力の一例を示す。この場合、システムのＰＤＵサブモデル内の電圧を測定するパラメトリックセンサである配電ユニット（ＰＤＵ）Ｐ５Ｖセンサ８０２は、このサブシステムのデータ入力が定義されたパラメトリック範囲外であるため、異常を生成している。パラメトリックセンサノード実装は、潜在的に煩わしいハードウェアＢＩＴテスト結果を回避して、このセンサデータの直接使用を可能にする。パラメータ化されたノードはまた、信頼性尺度の計算のための定量的データの直接解析、偽データポイントのデータのウィンドウ処理、および同様の解析を可能にする。このサブモデルでは、パラメトリックノードＰＤＵ＿Ｐ５＿ＮＤ ８０６とＢＩＴ＿ＰＤＵ＿Ｐ５＿電圧障害８０８からのＢＩＴテストデータとの間のＸＯＲ＿ＰＤＵ＿Ｐ５ノード８０４を使用した比較器解析が行われ、これらの２つの結果の間にセンサまたはＢＩＴテストの失敗を示す何らかの不一致があるか否かが判定される。以下の例では、他のサブシステムがシステムハードウェアの実際の障害の場合に同様の異常を予想するため、異常は誤警報であると判定される。そのような他の異常は存在しないので、ＭＢＲエンジン１０６は、この異常が誤警報（図１０の右上のボックスにリスト化された結果）であると判定することができる。このボックスの下およびグラフィックの上に示されている他の線は、図１０の結果における裏付けとなるタイムスタンプがされている。
本発明の中心的な目的は、車両および他のシステム用の高忠実度リアルタイム診断能力（誤警報（ＦＡ）拒否、障害検出（ＦＤ）、障害分離（ＦＩ）、および機器故障のパラメータ傾向）を生成することであるが、特に航空機に適している（ただし、これに限定されない）。本発明は、多数のハードウェアデバイスおよびオペレーティングシステム上の組み込みソフトウェア診断能力、ならびにフライト中のリアルタイムシステム動作中にシステムの健全性を判定するためのシステムアビオニクス統合を提供する。高周波センサおよび低周波センサからのパラメトリックデータ入力およびＸＯＲパラメータ－ＢＩＴ比較器融合を実装することにより、システムは、有効なシステム健全性管理および診断能力を維持しながら、定量的センサ入力を解析し、高度な障害信頼性尺度および誤警報信頼性尺度を開発し、ＢＩＴ故障を識別および解析する能力を有する。
図１１は、高周波センサデータおよび低周波センサデータの両方が共に処理および統合されるデータメッセージインターフェース１０８（図２）の実施形態１１００のブロック図である。破線１１０５は、線１１０５の上に示されている高周波センサデータ処理構成要素を、線の下に示されている低周波センサデータ処理構成要素から分離する。低周波センサデータ処理は、従来の手法を表す。低周波数センサ１１１０は、比較的低いデータレート出力を提供し、圧力、温度、体積、フロー、電圧、電流などのセンサに関連付けられ得る。そのようなセンサ出力は、典型的には、アナログ－デジタル変換器（Ａ／Ｄ）１１１５によってデジタル信号に変換されるアナログ電圧に関連付けられる。当然ながら、センサによって直接デジタル出力が提供される場合、デジタル出力はＡ／Ｄ変換器１１１５によって処理される必要はない。
センサ出力のデジタル信号表現は、警報状態が存在するか否かの判定を行うように機能する警報検出器１１２０への入力として供給される。そのような判定は、センサ出力のデジタル値が、各それぞれのセンサに関連付けられた静的、記憶された上限および下限の閾値によって定義される値の固定ウィンドウ内にあるか否かの比較に基づく。そのような比較は、センサ値を対応する閾値と比較するマイクロプロセッサによって行うことができ、または専用回路、例えば集積回路比較器によって行うことができる。センサ出力の値がそれぞれのウィンドウ内にある場合、感知されている構成要素のパラメータの機能は、許容範囲内にある、すなわち警報状態でないと判定される。センサ出力の値がそれぞれのウィンドウの外側にある場合、パラメータの機能は許容範囲内にない、すなわち警報が必要であると判定される。センサウィンドウが比較的広い（低い閾値と高い閾値が遠く離れている）場合、極端または非正常であるが異常な動作状態により、感知されているパラメータがそのようなウィンドウを超え、それによって警報が発生する可能性がある。これは偽陽性に相当する。広いウィンドウは、システムが適切に機能している間に、ほとんどの信号、特にノイズの多い信号を警報として登録することを可能にする。これは、一般に、構成要素およびセンサが正常の定常状態を達成しているフライト前テストの場合である。定常状態の内部時間は、レーダーなどの特定のシステムでは３０分までであり得る。定常状態が達成されると、誤警報が大幅に低減される。現在の方法は、残りの誤警報ならびに各センサの許容可能な静的下限閾値および静的上限閾値の理解を達成するために長いスケジュールおよび予算を必要とする。ＭＢＲエンジンの実装により、この労力と予算は２回のテストフライトで９０％低減される。真の誤警報は容易に識別される。その後、メンテナンス（修理または交換）のために真の障害に対処することができる。持続的な偽陽性（上限閾値を超える）は、対応するセンサが故障したという指示である。ゼロセンサ生値は、センサ内の電気的短絡を表す。誤警報を最小限に抑えるために、極端なまたは非正常な動作状態に対応するセンサ出力に対応するために、センサウィンドウが比較的狭い（互いに近い低い閾値および高い閾値）に設定されている場合、感知されているパラメータは、センサ出力が狭いウィンドウの外側にあるため、異常／警報状態であると判定されない許容できない特性で動作している危険性がある。これは偽陰性に相当する。偽陰性は、起こり得る実際の異常が、そうでなければ因果解析のために検出サイクルで処理されるであろう警報登録およびタグ付けを逃したことを示す。したがって、固定された上限閾値および下限閾値を有するウィンドウを確立することに課題がある。
警報検出器１１２０からの出力は、警報ありまたは警報なしを示すそれぞれのデジタルタグを有する入力デジタルセンサ値からなる。これは、データのフォーマットおよび位置合わせを提供するデータ調整１１２５への入力を提供する。異なるセンサからのデジタル出力は、異なる桁数を有してもよく、または異なる符号化方法の値を有してもよいので、データフォーマットは、これらの値を標準化されたデータ表現およびフォーマット（すなわち、浮動小数点、整数、バイナリビットなど）、ならびに必要に応じてデータの桁のパディングに変換する。また、センサデータレート（周波数）は典型的には、異なるセンサの各々について異なるため、各センサデータストリームを共通のデータレート、例えば５０Ｈｚを有するデータストリームに変換することにより、そのような様々なセンサおよびデータブランチからの情報を統合および処理することがより容易になる。データ調整１１２５は、センサ値の表現の適合性を提供するためにフォーマット変更を行うことができるマイクロプロセッサ上に実装することができ、また、例えば５０Ｈｚなどの目標共通データレートに変換するために各センサデータストリームのアップサンプリングまたはダウンサンプリングのいずれかを必要とし得るそれぞれのデジタルセンサ出力の単一の共通データレートに時間同期信号を確立するために共通クロックを利用することができる。
他のデータ１１３０は、ハードウェアおよびソフトウェアＢＩＴ、システム障害コード、警告、注意、勧告、気象、および生物学的（車両操作者、例えばパイロットの心拍数など）データなどのセンサまたは監視から得られた他の情報を表す。この情報に関連付けられた信号は、Ａ／Ｄ変換器１１３５、警報検出器１１４０、およびデータ調整１１４５によってさらに処理され、これらはそれぞれ、対応するＡ／Ｄ変換器１１１５、警報検出器１１２０、およびデータ調整１１２５について上述したものと同様の機能を実行する。
高周波センサ１１５０は、高データレートのアナログ情報を提供し、例えば、応力ゲージ、歪みゲージ、加速度計、振動センサ、トランスデューサ、トルクゲージ、音響センサ、光学センサなどのセンサを含むことができる。そのようなセンサ出力は、Ａ／Ｄ変換器１１５５によってデジタル信号表現に変換され、異常／劣化検出器１１６０に入力され（より詳細な説明については図１２およびテキストを参照されたい）、異常／劣化検出器１１６０では、各センサデータストリームが異常および／または劣化状態を表すか否かの判定を行う機能が行われる。センサ値に対してそのような条件の一方または両方が存在すると判定された場合、対応するデジタルセンサデータは、ダウンサンプリングされたセンサ日付レートでリアルタイムのセンサ情報を含む埋め込みフラグ表示と共に出力１１６２に出力される。出力１１６３は、すべてのセンサについてのデジタルセンサデータの生の出力であるが、各センサに関連付けられたデータ量を低減するためにダウンサンプリングされた後である。この出力１１６３は、ダウンサンプリングされた（実質的に低い）データレート以外のすべてのセンサのデータを含み、診断健全性判定を提供するために追加のリアルタイムプロセッサ（不図示）によって利用されることを意図している。ダウンサンプリングされたデータは、リアルタイムのセンサデータのすべてを処理することと比較して、より管理しやすく（記憶に必要なメモリが少なくて済むサイズが小さく）、処理が容易であり、リアルタイムの診断健全性判定を実行するプロセッサに必要な時間および処理能力を低減する。データ調整１１６５は、高周波センサが典型的には、同じ時間間隔で低周波センサよりも桁違いに多くのデータを生成するため、単位時間当たり実質的により多くのセンサデータを処理しなければならないことを除いて、データ調整１１２５と同様に動作する。すべてのデータコンディショナによって使用されるフォーマットは、異常もしくは劣化状態、または警報ステータスのフラグの組み込みに対応する。
データ融合モジュール１１７０（より詳細な説明については図１３を参照されたい）は、移動時間ウィンドウ内の到来するセンサデータストリームを、相関するセンサデータのグループにマッピングし、すなわち、あるグループ内の各センサのセンサデータは、グループ内のあるセンサからのデータによって感知された構成要素異常または故障が、グループ内の他のセンサからのデータによって示されるように異常または故障によっても反映されるべきである相互関係を有する。例えば、第１のグループが、ポンプの振動、ポンプによって利用される電力、およびポンプによって生成されるフローレートを感知するセンサに関連付けられたセンサデータからなると仮定する。また、ポンプが軸受の摩耗によって劣化していると仮定する。軸受が十分に摩耗している場合、ポンプは標準外の振動を生成する。ポンプによって利用される電力は、摩耗した軸受の摩擦の増加に起因して、始動時の電力需要を増加させるか、または急増させる可能性がある。ポンプによって生成されたフローレートに関連付けられたセンサデータは、ポンプモータが必要なフローを維持しながらポンプシャフトの回転を増加させる負荷（電力）の増加を補償しようとするとき、劣化の重大度に応じて標準外の減少したフローを示しても示さなくてもよい。最終的に、これを継続させると、軸受の裂け、シャフトの位置ずれ、および場合によってはモータワイヤ巻線の焼けが発生して、ポンプ構成要素が故障する。
センサグループ内の２つ以上のセンサからの標準外の状態を示すセンサデータの一貫性は、実際の劣化または故障の存在を識別する工程である。実際の故障分離は、ＭＢＲモデル２０（図１）と比較した場合に、ＭＢＲエンジンアルゴリズム１０６（図２）によって判定される。逆に、グループ内の別のセンサからのセンサデータによっても検証されない標準外状態を示す１つのセンサからのデータは、一時的な異常（ランダムまたは間欠的）に起因する可能性がある誤警報、または標準外状態の持続的なセンサがそれ自体が適切に機能していないことを示す誤警報である可能性がある。
他の上流構成要素または下流構成要素に関連付けられたセンサデータもグループ内に含めることができる。上記のポンプの例では、構成要素、例えば冷却を必要とするエンジンを通って導かれる液体のフローを生成するようにポンプが制御されると仮定する。このさらなる例では、ポンプの故障はまた、所望の動作範囲を超える可能性があるエンジン加熱の増加をもたらす可能性があるため、エンジンに関連付けられた熱センサをグループ内に含めることができる。したがって、相関するセンサデータのグループ化は、２つ以上の構成要素の感知された属性と関連付けることができることが理解されよう。センサデータのグループは、高周波センサ１１５０、低周波センサ１１１０、および／または他のデータセンサ１１３０からのセンサ情報を含んでもよい。当然ながら、いくつかのセンサからのデータは、いずれのグループにも含まれていなくてもよく、したがって、個別に解析され、考慮される。
データ融合モジュール１１７０は、相関するセンサの所定のグループ内に含まれるセンサデータについてのグループベースで、またはセンサデータがいずれのグループの一部でもない個々の単位で、経時的に増加する時間ウィンドウ内でマッピングされたセンサデータを解析する。データ融合モジュール１１７０は、タグがグループ／個々のセンサデータに関連付けられるべきか否かのセンサデータの各グループ／個々について記憶された使用状況および動作標準範情報に基づいて判定を行い、タグは所定の条件コードのセットのうちの１つからなる。各条件コードは、構成要素によって生成された同様の障害コードにマッピングされ、比較される。その後、条件コードは、ＭＢＲエンジン１０６におけるさらなる処理のために送信され（図２）、一方、障害コードおよび条件コードは、不揮発性メモリに記憶される。例えば、「０」」の条件コードは、構成要素の感知された属性が正常動作範囲内にあることを示し、「１」の条件コードは、構成要素の異常／故障を表し、「２」の条件コードは、センサの動作ウィンドウの正常範囲が望ましくない動作状態を含むほど広いことによって引き起こされ得る検出された偽陽性を表し、「３」の条件コードは、センサの故障、または実際の異常の裏付けがＭＢＲエンジン１０６の検出サイクルを逃してしまうようなセンサの正常範囲較正のウィンドウを狭すぎることによって引き起こされ得る、検出された偽陰性を表す。
センサデータは、条件コードと共に、さらなる解析のためにデータ融合モジュール１１７０から診断モデルベース推論エンジン１０６に送信される。データ融合モジュール１１７０は、センサデータストリームを相関グループにマッピングし、それぞれのセンサ値を上限および下限閾値を有する動的正常動作ウィンドウと比較し、グループ内のあるセンサに関連付けられた異常／障害がグループ内の別のセンサによる異常／故障の相関によって支援されているか否かを判定し、判定された誤動作／障害を表すエラーコードタグを用いてそれぞれのセンサデータを符号化することができるマイクロプロセッサ／コンピュータ上で実行されるソフトウェアで実装される。
図１２は、図１１の異常および劣化検出器１１６０の一実施形態のブロック図である。この検出器は、好ましくは、処理に利用可能な数千ではないにしても数百のＧＰＵプロセッサコアを有するシステムオンチップなどのグラフィック処理ユニット（ＧＰＵ）上で実行されるソフトウェアによって実装される。これは、多数のセンサからの出力の同時処理を支援する。Ａ／Ｄ変換器は、専用のハードウェア回路を利用してもよいが、Ａ／Ｄ変換器は、ＧＰＵコアを利用するソフトウェアに実装されてもよい。同様に、データ調整モジュール１１６５は、ＧＰＵコア上で実行されるソフトウェアによって実装されてもよい。Ａ／Ｄ変換器１１５５からのデジタルセンサ入力１２０５は、有効値および閾値の動的／移動ウィンドウにおいてセンサからパラメトリック値を受信する信号スケール識別モジュール１２１０によって入力として受信される。有効値の動的ウィンドウは、センサが関連付けられている車両の動作のための履歴記憶された正常データに基づいて確立される。信号スケール識別ブロック１２１０によって受信された生センサデータは、ダウンサンプルモジュール１２１５に渡され、ダウンサンプルモジュールは、実質的に正常なデータを排除する（このデータサンプルによって表される多数の削除された重複データを有する少量のタイムスタンプされた正常データを保持する）ことによってセンサデータストリームのサイズを縮小する。標準外パラメータデータの代表は、タイムスタンプおよびこのデータサンプルによって表される削除された重複データの数でタグ付けされる。出力１２２０上で送信されるこのダウンサンプリングされたデータストリームは、非リアルタイムオフライン解析のための初期データストリームの再作成を可能にする。動作モードブロック１２２５の識別は、センサデータを解析し、それを車両の対応する異なる動作モード、例えば、いくつかのモードを挙げると、フライト前、タクシー、離陸、加速および減速、徘徊、武器配送、着陸、フライト後の動作モードに関連付けられた異なる記憶された履歴値範囲と比較する。選択検出モードブロック１２３０は、車両の動作モードを識別する動作モードブロック１２２５の識別からの出力を受信する。選択検出モードブロック１２３０は、モードパラメータ１２３５に、その動作モードに固有の期待される値の正常のウィンドウを定義する各センサの対応する記憶されたパラメータセット（上限および下限閾値、ならびに他のモード依存要因）を識別させる。
これらのパラメータは、異常／劣化検出モジュール１２４０に送信され、異常／劣化検出モジュール１２４０は、各センサデータストリームの対応するパラメータを利用して、これらのパラメータによって定義された期待される動作標準の外側にある値を識別する。したがって、各センサの正規化された動作の動的ウィンドウは、動作モードに応じて変化する。これは、動作モードに基づいて各センサの正常パラメータの動的な変化を提供し、したがって、対応する「正常値ウィンドウ」を変更して特定の動作モード中に期待される値を可能にすることができるため、異常／劣化が感知されているか否かのより正確な判定を可能にする。センサ値は動作モードに応じてかなり変化する可能性があるため、それぞれの動作モードのウィンドウ閾値およびパラメータを調整することにより、すべての動作モードをカバーするために単一の大きな許容範囲を利用する必要なく、誤警報を排除する能力を大幅に高める。様々な動作モードについて収集され記憶された以前のセンサデータに基づくオフライン訓練は、これらのウィンドウ閾値の精緻化を可能にする。
非正常測定モジュール１２４５は、異常／劣化検出モジュール１２４０からそれぞれのセンサデータを受信する。モジュール１２４５は、判定された動作モードの正常パラメータ値に対して、各センサ出力に関連付けられた値のパラメータ距離測定を行う。これらのパラメータ距離測定値に基づいて、非正常測定モジュール１２４５は、各センサ出力について、センサによって感知されている機能が正常モード内で動作しているか否か、または異常が存在するか否かの判定を行う。センサ出力値が対応する正常値ウィンドウ内にある場合、正常動作が判定され、すなわち、機能は期待される動作範囲内で動作している。センサ出力が対応する正常値ウィンドウ外にある場合、動作の異常が判定され、すなわち、機能が劣化した性能または故障状態で動作しているか、またはセンサもしくはその較正に問題がある。上述したタグ条件コードを参照されたい。そのようなタグは、各センサ出力に適用され、設定された異常および劣化フラグモジュール１２５０に送信される。モジュール１２５０は、そのようなタグを、出力１１６２としてデータ調整モジュール１１６５に送信されるセンサ出力値の各々に組み込む。
図１３は、図１１に示すデータ融合モジュール１１７０の一実施形態のブロック図である。融合モジュール１１７０は、マイクロプロセッサベースのコンピュータ上で実行されるソフトウェアによって実装されてもよい。データマッパモジュール１３１０は、データ調整モジュール１１２５、１１４５および１１６５からセンサデータ１３０５の到来ストリームを受信する。このモジュールは、上述したように、相関された異なるセンサからのデータが移動時間ウィンドウ内でそれぞれのグループに統合されるように、到来するセンサストリームからのデータをマッピングまたは相関させる。すなわち、時間ウィンドウが移動するにつれて、その時間ウィンドウ内で発生するセンサ出力は、相関グループにマッピングされるべきものである。到来するセンサデータは共通のデータレートに標準化されているため、各時間ウィンドウ内の時間を選択して、各センサについて１つのデータ出力を捕捉することができる。データを供給するセンサは事前に知られており、相関するセンサのグループを手動で予め決定することができるため、相関情報（相関するセンサのセット）をメモリに記憶し、データマッパによるセンサ出力の関係をそれぞれの相関するグループにルーティングするために利用することができる。これらの相関するセンサ出力のグループは、対応する相関するセンサのグループの初期性能パラメータの記憶されたセットに対して、劣化／異常と判定されたグループ内のセンサ出力を含む、相関するセンサ出力のグループのデータを解析する、融合データモジュール１３１５に入力される。融合データモジュール１３１５は、診断モデルベースの推論エンジン１０６によって提供されるさらなる解析を支援するために、条件付き障害コードまたは異常コードでタグ付けされた単一のデータセットに、センサ出力の相関グループのデータを融合または統合する。融合データモジュール１３１５からの融合出力データは、各相関されたセンサ出力グループに関連付けられたデータを、それぞれの相関されたセンサグループの一部である単一のセンサからの出力と比較するパラメータ特徴付けモジュール１３２０への入力である。この比較は、好ましくは、過去または最後の状態からの単一のセンサからの対応する出力を利用する。過去の出力センサ状態とのそのような比較は、非正常な挙動または少なくとも非正常な挙動に向かう傾向を示し得る将来の状態を示し、予測するのに有用である。そのような比較の結果は、キューに記憶され、その後、さらなる解析のために出力１１７５として編成されたセットとしてＭＢＲエンジン１０６に出力される。キューは、（必要に応じてより多くのプロセッサＲＡＭをキューに動的に割り振り、必要でないときに割り当てられたＲＡＭを解放することによって）データ損失なしに入力データレート１１７５を管理しながら、ＭＢＲエンジン１０６で必要とされる任意の処理待ちに対応するための可変データレート出力を可能にする。
図１４および図１５は、それぞれ、対応する正常および欠陥のあるポンプ軸受の遠心ポンプ内のモータ軸受の振動センサからの例示的な高周波センサデータ１４０５および１５０５を示す。センサ出力データ１４０５は、ポンプ内の正常に動作している軸受からの振動を表し、ポンプの状態に対応するより大きな振幅を有する反復振幅変動１４１０を示し、これは正常では、より少ない振動を生成するポンプの状態に対応するより小さな振幅変動１４１５をわずかに大きくする。より大きな振幅変動１４１０は、典型的には、インペラハウジング内の流体逆流の補償または負荷の変化によるより大きな負荷が発生しているポンプ状態に対応し、より小さな振幅変動１４１５は流体の逆流がなく、振動が少ないことに対応する。１４１０および１４１５の両方は、遠心ポンプの定常状態動作を表す。ロータ（ポンプシャフト）速度は、示されている時間間隔全体にわたって一定のままであることに留意されたい。
センサ出力データ１５０５は、ポンプ内の軸受の誤動作／欠陥からの振動を表す。図１４の変形例と幾分類似して、より小さい振幅出力１５１５が散在する反復的なより大きい振幅出力１５１０が存在する。しかしながら、より小さい振幅出力の平均と平均より大きい振幅出力との差は、図１５において、図１４における同じ対応する差よりも大幅に大きいことに留意されたい。また、より大きな振幅の出力部分１５１０の開始時の振幅スパイク１５２０は、より大きな振幅の出力部分１５１０の残りの部分のいずれよりも著しく高い振幅を有する。時間が経過するにつれて、スパイク１５２０ Ａは、対応するより大きな振幅部分１５１０の残りの部分に対してその振幅差がさらに誇張されることに留意されたい。ポンプサイクルの開始時のこのような振動差は、軸受の摩耗による摩擦の増加に対応し得る。経時的なより高い周波数に対するシステムのベースライン傾向（例えば、開始からの平均傾斜の増加）にも留意されたい。これは、ポンプシャフトの劣化および位置ずれの発生、ならびに修理しない限りポンプの起こり得る最終的な故障を示している。
良好な作業指示でのポンプの動作中の正常の期待される軸受振動に対応してセンサデータが収集および記憶されると、このデータは、対象ポンプが正常に動作しているか、またはメンテナンスもしくは交換を必要としているか否かの判定を行うために、就航中のサービス中（航空機のフライト中）のセンサデータと比較／対比されることができる。図１６および図１７に関して以下で説明されるように、そのような判定は、好ましくは、２つ以上の感知パラメータから得られる情報に基づいて行われる。
図１６および図１７は、それぞれ良好な軸受および不良な軸受を有する遠心ポンプへの電力を監視するセンサからの例示的な高周波センサデータ１６０５および１７０５を示す。良好な軸受を有するポンプによって消費される電力に対応するセンサ出力データ１６０５は、比較的低い消費電力で、より低い大きさの部分１６１５において比較的高い消費電力のより大きい大きさの部分１６１０を含む。図１６および図１７のタイムスケールは同じであるが、図１４および図１５に関連付けられたタイムスケールとは異なることに留意されたい。例えば、より大きい振幅部分１６１０は、ポンプが動作可能であり、負荷を受けている時間に対応してもよく、より小さい振幅部分１６１５は、より軽い負荷またはおそらくほとんど負荷のない時間間隔に対応する。センサ出力データ１７０５は、軸受が不良なポンプによって消費される電力に対応し、時間間隔１７１５によって示されるように、より低い消費電力に対してより高い消費電力を表すより大きい大きさの部分１７１０を含む。しかしながら、消費されている電力のセンサからのスパイク１７２０は、対応する時間間隔１６１０の間に示される最大消費電力よりも一桁以上大きいことを表す。このような電力消費の極端に大きい必要性は、ポンプの回転部を動かすために特に高い初期抵抗を引き起こす不良軸受を有するポンプ（またはポンプサイクル）の初期始動と一致する。
ポンプ振動センサからのデータとポンプ動力センサとの融合は、ポンプの軸受が誤動作／劣化しているか否かの高い信頼性の判定につながる。欠陥軸受信号１５０５と電力センサデータ１７０５の両方による正の相関は、関連付けられたポンプが最低でもメンテナンスまたは場合によっては交換を必要とするという信頼性の高い判定をもたらす。逆に、２つ以上のセンサ信号から正の相関がなければ、欠陥を示す１つのセンサ信号のみが偽陽性である可能性がある。そのような偽陽性は、車両の動作の一過性の変化または一時的な電気的干渉などの一時的な状態の結果であり得る。あるいは、正の相関の欠如は、誤動作の検出に関連付けられたセンサ自体が欠陥であるか、またはおそらく較正が狂っていることを示すこともできる。
図１８、図１９、図２０、および図２１は、動的異常認識に利用される高周波センサ信号および導出されたセンサ信号平均を示す例示的なグラフである。この技術は、動作ベースの処理モードとは独立しており、それに加えて実行されるが、両方とも異常／劣化検出１１６０で並行して行われる。以下に説明する他の情報を有するパラメータ異常タグのみがデータ融合１１７０に転送される。これらのグラフのタイムスケール（横軸）は、動的異常認識に異なる移動平均がどのように利用されるかを説明するのを助けるためにこれらのグラフが提示されるのと同じではないことに留意されたい。図１８において、高周波センサからの出力１８０５は、それぞれの短期、中期、および長期タイムスケール期間を有する一連の３つの異なる移動平均の基礎を形成する。この例では、より短期タイムスケール平均１８１０は、より長期のタイムスケール平均１８２０よりも短い中期タイムスケール平均１８１５よりも実質的に短い。タイムスケール持続時間は、対応する短期移動平均、中期移動平均、および長期移動平均を計算するために利用されるセンサデータ値の数を指す。値の数は、センサデータレートおよびセンサ値の典型的な変化率に応じて変化し得る。初期データ取得時に、これらの移動平均は、到来するパラメータ値および振幅の変化率に従って動的に設定される。中期平均タイムスケール期間は、一般に、短期移動平均タイムスケール期間の１．５から２．５倍であることが観測される。長期移動平均時間スケール持続時間は、一般に、中期移動平均時間スケール持続時間の２倍（またはそれ以上）であることが観測される。中期移動平均および長期移動平均のより大きいタイムスケール持続時間サイズは、これらの平均の結果として得られる曲線における大きさ（振幅）を減少させる効果を有することに留意されたい。これらの移動平均サンプリングウィンドウは、以前のセンサデータに対するオフライン訓練によって精緻化されてもよい。これらは、それらの適用性について十分な信頼が得られると静的に設定することができ、したがって、他のプロセスに利用することができる計算処理能力を低減する。図１８に示すように、センサ出力の実質的に一貫した平均の大きさは、対応する実質的に直線の短期移動平均１８１０、中期移動平均１８１５および長期移動平均１８２０によってそれぞれ反映される。
図１９は、関連する短期、中期、および長期移動平均１９１０、１９１５、および１９２０をそれぞれ有する高周波センサの出力１９０５を示す。この例では、間隔１９２５の期間に実質的な振幅、短時間過渡があった。短期移動平均１９１０は、この過渡間隔の間にセンサ信号１９０５を密接に追跡する。しかしながら、図示のように、中程度の長さの移動平均１９１５およびより長期の移動平均１９２０は、過渡間隔の間にこれらの平均の変動をほとんど生じさせないタイムスケールを有する。そのような過渡現象は、中程度の長さの移動平均１９１５にさえ関連付けられた移動平均時間間隔に対して短い一時的な（間欠的または過渡的な）異常を反映する可能性がある。これらは、ノイズの多いデータバス、環境効果、または何らかの他の近傍機構的効果によるデータ内のランダムノイズによって発生する可能性がある。この挙動は、移動平均の持続的でないシフトとしても知られており、したがって信号のランダムな統計的変動を示している。
図２０は、関連付けられた短期、中期、および長期移動平均２０１０、２０１５、および２０２０をそれぞれ有する高周波センサの出力２００５を示す。この例は、間隔２０２５で始まるセンサ出力値の実質的な初期の大きさの変化を示す。センサ出力の初期の大きさの変化は、間隔２０２５の終わりまでに減少するが、それは依然として、その進行する間隔２０２５よりも大幅に高いレベルに維持される（すなわち、ベースライン曲線の傾斜の増加）。理解されるように、短期移動平均２０１０は、間隔２０２５の前、間、および後のセンサ出力値を密接に追跡する。しかしながら、間隔２０２５の持続時間は、中期移動平均２０１５が短期移動平均２０１０に向かって追跡し始め、これらの２つの移動平均が間隔２０２５の終わりで実質的に一致するように、中期移動平均２０１５に使用される値の数よりも実質的に長い。間隔２０２５の間、長期移動平均２０２０は中期移動平均２０１５に向かってゆっくりと上方に移動しているが、間隔２０２５の終わりまでに、長期移動平均２０２０はまだ中期移動平均２０１５の値に達していないことに留意されたい。長期移動平均２０２０は最終的に中期移動平均２０１５に収束するが（センサ出力値が間隔２０２５の終わりで相対的に一定のままであると仮定すると）、これが発生するには、中で利用されるセンサ値の数と長期移動平均との間の差に応じて、かなりの数の移動平均ロールオーバー計算が必要になる。パラメータ値の大きなサンプリング（多数の連続移動平均計算）中にベースライン傾斜がゆっくりと増加しているという事実は、公称から外れた挙動、すなわち移動平均の持続的なシフトを示す（すべての曲線に留意）。これは、対応するパラメータデータに異常および劣化事象として登録（タグ付け）される。これらの移動平均に対応する構成要素は、故障しておらず、依然として使用可能であるが、劣化した状態である（すなわち、動作条件は、定常状態を達成するために、より低い値に調整されなければならない）。しかしながら、近い将来のある時点で、この構成要素は、構成要素の完全な正常の性能のために修理または交換されてもよい。
図２１は、関連付けられた短期、中期、および長期移動平均２１１０、２１１５、および２１２０の高周波センサの出力２１０５をそれぞれ示す。この例では、間隔２１２５で始まるセンサ出力値２１０５は、間隔２１２５の終わりに実質的に公称から外れた値に達するまで、値の定常的な増加率を受ける。予想通り、短期移動平均２１１０は、基礎となるセンサ値２１０５の値を密接に追跡する。中程度の長さの移動平均２１１５（中程度のサンプリングウィンドウ）は、短期移動平均２１１０に向かって上昇し始めるが、間隔２１２５の終了後まで短期移動平均２１１０の値に達しない。予想通り、長期移動平均２１２０は、ゆっくりと中期移動平均２１１５に向かって上方に移動し始めるが、図示のグラフの終わりまでに、中期移動平均２１１５と同じ値に達していない。この例は、間隔２１２５の前に示された値から、間隔２１２５の終わりに新たな比較的公称から外れた移動平均に移動するセンサ出力値の持続的な変化（移動平均の持続的なシフト）を示す。この例は、故障が近い構成要素を示している。それは、非常に早く、すなわち、好ましくは関連する車両が保管所に戻ると、修理または交換されなければならない。ベースライン傾斜は、下降することなく連続的に急激に増加している。これが重要な構成要素である場合、車両の動作がそのまま継続する場合、車両の安全性が含まれる。車両の操作者は、ベースに戻るべきである。パラメータデータは、ＭＢＲエンジン１０６によって直ちに処理される警報と、即時の行動のために（車両が航空機であると仮定して）パイロットに表示されるまたは地上ベースのパイロットに送信される情報とを伴う（重要な構成要素についての）重要な異常としてタグ付けされる。
図２２は、動的異常認識を支援するために利用される基準が導出される高周波センサ値の例示的なグラフである。この例示的なグラフは、基礎となるセンサ値２２０５に基づいて移動データウィンドウ２２１０上で決定された基準を示す視覚的表現を提供する。これらの基準は、関連付けられたセンサ値によって感知された対応する機能について警報が実施されるべきか否かを判定するための基準を提供する。線２２１５は、ウィンドウ２２１０内に含まれるデータ値の傾斜を表す。線２２２０は、ウィンドウ２２１０内に含まれるデータ値の算術平均（ｕ）を表す。鉛直線２２２５は、ウィンドウ２２１０内に含まれるデータ値の標準偏差（ＳＤ）の視覚的表現である。一般に、警報は、
｜ｓ｜＜０．０１６７
および
ＳＤ／ｕ＜１／６
と設定される。
この技術は、センサ出力値の持続的なシフトの検証、ならびに警報係数の決定、すなわち警報がいつ決定されるべきかに対応する。この技術は、平均によって正規化されるように、６つの標準偏差を超える一貫性値を決定するガウス分布統計を有する低確率に基づいている。標準偏差は、異なるセンサ出力値に対応するために平均によって正規化されることに留意されたい。図１８～図２１と比較すると、移動平均を有する正規化された信号（図２２）は、移動平均の持続的なシフトに対してより小さい傾斜「ｓ」を生成し、ＳＤ／ｕの値がより小さいことに留意されたい。これにより、警報を生成するために（上述のような）必要な条件が生成される。
図２３は図１１の異常／劣化検出を実施するために利用することができる例示的な独立した並列工程のフロー図を示す。センサからのデジタル出力のストリーム１２０５は、各センサに関連付けられたデータの適切な移動ウィンドウを判定する工程２３０５への入力として受信される。各センサは固定データレートでデータを出力するが、様々なセンサの出力データレートは異なっていてもよい。各センサの出力データはそのセンサに対して一意に識別されるため、各センサの既知のデータレートをメモリに記憶し、次に取得して、適切な移動データウィンドウ、すなわち解析のために一緒にグループ化されるセンサ出力値の数の決定を支援することができる。工程２３０５に続いて、デジタルセンサデータストリームは、出力１２２０上で送信されるデータの量を最小限に抑えるために、工程２３１０においてダウンサンプリングされる。多くの場合、異常がフラグ付けされると、一連の移動するデータウィンドウにわたって同じ異常が存在する。ダウンサンプリングは、所与のセンサ出力に対してそれぞれ同じ異常を有する連続した移動データウィンドウの数をカウントすることと、その後、カウントされたデータフレーム／ウィンドウの数を、同じ異常を有する連続した移動データウィンドウの最後に関連付けられたデータで符号化することとからなることができ、その結果、カウントされた回数の関連データを単に複製することによって、必要に応じて元のデータを再構成することができる。この手順は、その出力サイズを低減するために公称データにも利用される。この情報は、構成要素の将来の状態／値の予測のためのリアルタイムと、メンテナンス位置で実行されるメンテナンス解析などの非リアルタイム環境の両方で使用されることが期待される。出力１２２０は、地上制御ステーションおよび／またはメンテナンス場所に無線などで送信されてもよく、または不揮発性ストレージにローカルに記憶され、後にストレージからメンテナンス場所に転送されてもよく、またはＰＭＤビューアを実行する接続されたハンドヘルドデバイスによって車両から取得されてもよい。
工程２３１５において、現在の動作モードの判定が行われ、動作モードの対応する記憶されたパラメータが選択される。航空機の場合、現在の動作モードは、離陸、標準の加速、戦闘加速、定常状態速度での巡航、着陸などが可能である。この情報は、メモリに記憶されたフライト計画から、または動作モード、例えば車輪の重量、加速度計、速度、高度の変化率などを反映するセンサデータの解析などから判定することができる。そのようなセンサデータの記憶された所定の基準／閾値は、現在のセンサタグと比較した場合に動作モードを決定するために利用することができる。特定の動作モードに関連付けられた検出パラメータ、例えば上限閾値および下限閾値、または決定された動作モードの記憶された正常値が選択される。複数の異常検出器１１６０の各々は、構成要素内の同一の既存の高周波センサ（１～ｎ個のセンサ）のセットに接続され、ＧＰＵの１つのコアに実装される。あるいは、同様のまたは異なる構成要素からの異なるセンサに対して、同じＧＰＵコアで複数の異常検出器１１６０を実行することができる。センサ閾値および較正情報は、サプライヤデータから入手可能であり、リアルタイム入力車両データに対する処理のために車両に記憶される。車両内の各高周波センサに使用することができる十分なＧＰＵコアがある。
工程２３２０において、現在のセンサ値が、現在の移動ウィンドウについて選択された検出パラメータと比較される。実際の測定（リアルタイム入力信号）では、これらの選択された検出パラメータは、センサが取り付けられた構成要素の公称動作に一致する。逆伝播を伴う入力層、隠れ層、および出力層を有する人工ニューラルネットワーク（ＡＮＮ）を異常検出機構として利用することができる。記憶された訓練データは、クラスのグループに編成され、監視能力（オフライン教師付き学習）で利用される。各クラスのモデル化には、ｎ次元ガウス関数を利用することができる。これらは、ラジアル基底関数（ＲＢＦ）とも呼ばれる。それらは、入力層と出力層との間の統計的プロパティおよび次元相互関係を捕捉する。ＲＢＦ ＡＮＮのアルゴリズム目標は、公称構成要素挙動については出力パラメータ「０」であり、公称構成要素挙動以外については出力パラメータ「１」である。
工程２３２５において、正常なセンサ値、例えば異常の出力について、センサ値と対応する正常な検出パラメータとの間の差が計算され、記憶される。この情報は、センサデータのオフライン訓練およびＲＢＦ機能モデルの改良に有用である。工程２３３０において、必要に応じて、対応するセンサデータに対してデータフラグ／タグが設定される。
工程２３３５において、各移動ウィンドウについての各センサの出力についての短期移動平均、中期移動平均、および長期移動平均が判定される。移動平均の計算は、当業者にはよく理解されており、そのような計算およびソフトウェアを実装するのに支障はない。工程２３４０において、これらの移動平均間の差、および移動平均の傾向の判定が行われる。工程２３４５において、決定された傾向は、記憶された履歴傾向データと比較されて、非正常な状態が存在するか否かを判定する。工程２３４７ごとに（上記の説明によって決定された）永続的なシフトが存在する場合、プロセスは、警報フラグの必要性の検証および妥当性確認を継続し、対応するセンサデータを２３５０に送信する。
工程２３５０において、各移動ウィンドウにおける各センサ出力の傾斜、平均および標準偏差が計算される。当業者は、標準的なマイクロプロセッシングユニットを使用して、または算術処理ユニットを使用して、ソフトウェアでそのような計算を実施する方法を知るであろう。これらの計算は、グラフィック処理ユニット上で実施することもできる。工程２３５５において、「テスト１」が行われ、傾斜が記憶された所定の傾斜閾値と比較されて、非正常状態が存在するか否かが判定される。工程２３６０において、「テスト２」が行われ、正規化標準偏差が記憶された所定の標準偏差閾値と比較されて、非正常状態が存在するか否かが判定される。工程２３６５において、「テスト１およびテスト２」の両方が正常値から外れている場合、非正常な挙動が存在すると判定される。必要に応じて、工程２３６５に続く工程２３３０において、異常／劣化フラグが設定される。また、工程２３３０において、高周波センサデータは、低周波センサおよび他のデータセンサから受信したデータレートと実質的に同じデータレートを有するためにダウンサンプリングされる。これにより、データ融合ブロック１１７０によるすべてのソースからのセンサデータのより容易な処理および統合が容易になる。
図２４は、図１３のデータ融合を実施するために利用することができる例示的な工程のフロー図を示す。工程２４０５において、到来するセンサデータストリーム１３０５は、グループ内の各データストリームが相関される所定のグループにルーティング（マッピング）される。センサデータの相関について上述した。各センサデータストリームは一意に識別され、相関するグループ内のセンサは予め決定され、相関する各グループ内のセンサを識別するモデリングエンジニア（図２）による手動入力などによってメモリに記憶される。この情報は、メモリに記憶され、その後、到来するデータストリームを相関グループに分離するために取得される。これらの相関グループは、個々のセンサ出力によって示される任意の障害に対する相関解析だけでなく、個々の解析のためにメモリに一時的に記憶されてもよい。
工程２４１０において、相関するグループの各々について、センサ値が、現在の動作モードに関連付けられた値の対応する正常範囲と比較される。この解析に基づいて、非正常と識別されたグループに関連付けられたセンサデータは、条件コードでタグ付けされる。工程２４１５において、融合されたグループセンサデータは、複数のデータウィンドウにわたる相関または相関の欠如について個々の（単一の）センサ値と比較されて、非正常な挙動または非正常な挙動への傾向を検出する。例えば、相関する高周波センサ１１５０のグループと相関するセンサ１１１０または１１３０のうちの一方から来る個々のセンサデータは、異常を確認するか、または個々のセンサデータがグループ内の他の人によって他の非正常なセンサ出力によって妥当性確認がされない潜在的な誤警報を防止するのに有用であり得る。あるいは、そのような個々のセンサデータは、正常動作を反映することができ、一方、高周波センサからの相関センサの対応するグループは、非正常挙動に向かう傾向を示すことができる。これは、単一のセンサデータが、対象構成要素が何らかの形態のメンテナンスを必要とする可能性があるという警告を提供するのに十分に応答しない個々のセンサの「偽陰性」を表す。
図２５は、高周波センサ解析および低周波センサデータとの統合を実施するための例示的なコンピューティングシステム２５００のブロック図である。コンピューティングシステムオンチップ（ＳＯＣ）の中心はマイクロプロセッサ２５０５であり、これはまた、算術処理ユニットおよび／またはグラフィック処理ユニット（ＧＰＵ）を含んでもよい。あるいは、ＧＰＵは、図２３および図２４の計算／決定の一部、すなわち「グラフィック」情報以外を処理するために単独で使用されてもよい。読み出し専用メモリ（ＲＯＭ）２５１０は、マイクロプロセッサ２５０５によって使用される記憶されたプログラム命令およびデータを含む。ランダムアクセスメモリ（ＲＡＭ）２５１５はまた、データが記憶され、後に読み出され得る場所としてマイクロプロセッサ２５０５によって使用される（ＧＰＵはまた、それ自体のＲＡＭを有する）。不揮発性メモリデバイス２５２０は、コンピューティングシステムの電力損失時に失われない命令および／またはデータを記憶するために利用される。入力／出力（Ｉ／Ｏ）バッファ２５２５は、マイクロプロセッサ２５０５に結合され、外部データの受信およびマイクロプロセッサから外部デバイスへのデータ伝送を容易にする。入力デバイス２５３０は、ユーザがコンピューティングシステム、例えばキーボード、マウスなどに情報を入力するための従来の方法を表す。出力デバイス置２５３５は、コンピュータシステムからユーザ、例えばビデオモニタ、プリンタなどに情報を伝達するための従来の方法である。マイクロプロセッサ２５０５（またはＧＰＵ）の並列コアの数に応じて、すべてのコアは、上記で説明した工程に従ってすべてのセンサからのデータを処理するのに必要な十分な計算能力を提供する。例えば、１つのコアを使用して、センサの１つの相関グループのすべてのデータを処理することができる。これは、そのグループ内のすべてのセンサが、そのグループ内の他のセンサの出力と記憶および比較する必要がある出力を有するためである。
当業者によって理解されるように、ＲＯＭ ２５１０および／または不揮発性ストレージデバイス２５２０は、マイクロプロセッサ２５０５が図示のように周辺機器との間で情報を通信することを可能にするオペレーティングシステムを記憶する。より具体的には、センサデータは、Ｉ／Ｏ ２５２５を介して受信され、メモリに記憶され、次いで、記憶されたプログラム命令に従って処理されて、それぞれのセンサに関連付けられた構成要素の異常および劣化の検出を達成する。上記で説明したようなセンサデータの解析に基づいて、当業者は、連続する移動データウィンドウにわたって図１８～図２１に関して説明したような異なる長さの移動平均を判定し、異なる長さの移動平均のそれぞれの値を特定の動作モードの記憶された閾値と比較するためにコンピュータシステムソフトウェアに実装する方法を知る。同様に、図２２に関して、当業者は、連続する移動データウィンドウ内のセンサデータの傾斜、平均、および標準偏差をソフトウェアで計算し、結果を記憶された基準と比較する方法を知る。それぞれの車両の異なる動作モードに対応する異なる閾値および値がメモリに記憶される。動作モードを決定すると、対応する記憶された閾値および値は、それぞれの動作モード中にセンサから導出された情報との比較のために利用される。すべてのタイプの動作条件について所与のセンサの正常動作範囲を決定するために固定された上限および下限閾値のみを利用するのとは対照的に、本明細書に記載の技術は、所与のセンサの動的な、すなわち変化する基準を提供して、センサデータおよび／または車両の動作モードの変化に依存する異常／劣化を決定する。
使用される場合、特に明記しない限り、用語「上部」、「下側」、「前方、」、「背面」、「上」、「下、」および同様のそのような用語は、実施形態を特定の向きに限定するものとして解釈されるべきではない。代わりに、これらの用語は相対的にのみ使用される。
図２６は、構成要素レベルで性能／劣化の過去、現在、および将来の状態を判定し、航空機／システム機器の劣化／故障状況認識を提供しながら、構成要素レベルでのメンテナンスが航空機／システムに必要か否かを判定するための例示的な故障予測システム２６００のブロック図を示す。システム２６００は、構成要素レベルで動作し、すなわち、処理されているデータおよび情報は、データ融合モジュール１１７５からの構成要素データおよびＭＢＲ診断エンジン１０６からの出力の検出およびタグ付けされた異常な挙動に応じて、単一の構成要素または複数の構成要素に同時に関連することができ、複数の相互に関連する構成要素間の相互接続された劣化／故障モードを可能にする。複雑な車両システム内の複数の構成要素からのデータおよび情報のすべてを処理するために、故障予測システム２６００は、それぞれが異なる単一の構成要素に関連付けられた情報およびデータを処理することに専念する複数の処理システムからなることができる。
データインターフェースモジュール２６０５は、データ融合モジュールから入力１１７５を受け取り、タグ付けされたデータおよび警報を識別し、この分離されたデータをＬＲＵ／システム選択およびデータ転送モジュール２６１０へ渡す。警報は、モジュール２６１０によって損傷推定モジュール２６２５に直ちに渡される。１０６（ＭＢＲ診断エンジン）からの出力は、それぞれの構成要素の障害／故障および誤警報分離に対応する複数の構成要素障害コード、ならびに障害／故障の原因（例えば、漏れパイプ、摩耗した軸受、モータシャフトの位置ずれなど）の公称データおよび機能解析からなる。障害データおよび公称データの両方は、損傷推定モジュール２６２５に渡されるＢＩＴおよびパラメトリックデータに対応する。複数のソースからの警報および対応する分解融合データ（すなわち、構成要素の各々について、ＬＲＵ／システム選択およびデータ転送モジュール２６１０において劣化構成要素について分離され、警報を有する構成要素データに与えられる優先度が最も高い様々なモジュールに同時に転送される複数のストリームに組み込まれるデータ）も、データインターフェース２６０５およびＬＲＵ／システム選択およびデータ転送モジュール２６１０を介してデータ融合モジュール１１７５から損傷推定モジュール２６２５に渡される。
ＬＲＵ／システム選択およびデータ転送モジュール２６１０は、解析される構成要素に関連付けられた関連するタグ付きデータ（警報の優先度が最も高くなるタグ付きデータ）、ならびに対応するＢＩＴ、パラメトリック、アナログ（アナログ－デジタル（Ａ／Ｄ）変換なしの直接センサ信号）、離散（ソフトウェアビットを介して渡されるハードウェアＯＮ／ＯＦＦ制御信号）、環境（湿度、圧力、温度、塵埃などの内部環境条件）、および外部計測データ（例えば、砂、埃、熱、風、雨など）などの航空機データを識別および分離する。このデータは、モデルインターフェースモジュール２６２０に送信される。モデルインターフェースモジュール２６２０は、各構成要素に１つのデータの複数のストリームを作成する。タグ付けされたデータは、異常検出器（高周波センサ）、低周波センサ、およびタグ付けされた警報および確証された証拠データと融合されたデータを有する他のデータストリームから得られたメタデータである。確証された証拠データは、１）障害なし、２）障害、３）偽陰性または偽陽性のいずれかの誤警報、および４）２）および３）の原因の機能解析を表すデータからなる。現在の構成要素の障害／故障モードについての様々な対話／相互接続された構成要素センサからの確証された証拠データは、異常／劣化検出器モジュール１１６０から受信され、データ融合モジュール１１７５において融合され、データインターフェースモジュール２６０５に提供される。このデータは、現在の構成要素の障害／故障モードに対してＬＲＵ／システム選択およびデータ転送モジュール２６１０で分解される。独立して確証された証拠データが、ＭＢＲ診断エンジン１０６から受信され、ＭＢＲ診断エンジン１０６は、現在の構成要素の障害／故障モードについての様々な相互作用／相互接続された構成要素センサのパラメトリックおよびＢＩＴデータからの障害／故障／誤警報分離を実行する。ＬＲＵ／システム選択およびデータ転送モジュール２６１０はまた、メンテナンス履歴データベースインターフェース２６１５を介して、関連する構成要素メンテナンスデータ（フライト後のパイロット鳴きおよびメンテナンス管理者ノートを含む）に関連付けられたメンテナンス履歴データベース２６１８からの事例ベースの履歴を要求し、それは次に、現在の異常な構成要素の挙動および警報データとリアルタイムで比較される。これらの履歴は、事例ベースの記録および関連する構成要素の記憶されたパラメータ値である。メンテナンス履歴ＤＢインターフェースモジュール２６１５は、例えば、ＡＮＳＩ ＳＱＬ文を利用して、メンテナンス管理者によって書き込まれたこれらのメンテナンス記録に含まれる、以前に記憶された修理および交換情報ならびに実行されたテストを抽出することができる。メンテナンス管理者は、メンテナンス管理者がメンテナンス認証を得た航空機／システム構成要素のメンテナンスを実行するように割り当てられた技術者である。これらのメンテナンス記録はまた、故障予測エンジンによって以前に記憶されたフライト中リアルタイム評価を含み、好ましくはリレーショナルデータベースであるメンテナンス履歴データベース２６１８に記憶される。メンテナンス管理者は、構成要素を固定または修理または交換するときにグラフィカルユーザインターフェース（ＧＵＩ）を介してメンテナンスノートを入力し、構成要素の劣化ステータスをさらに視覚的に観測する。関連する記録はまた、劣化が判定される元のＢＩＴおよびセンサパラメトリック記録データを含む。記録されたノートはまた、警報の性質に関する手動入力の説明、および構成要素警報が発行された理由、および警報／問題を修正するためにどのような修復工程が行われたかの機能解析を含むことができる。
モデルインターフェースモジュール２６２０は、特定の構成要素についてＬＲＵ／システム選択およびデータ転送モジュール２６１０から受信した分解されたタグ付きデータに基づいて、関連する構成要素を識別する要求を故障予測モデルデータベース２６３５に送信し、故障予測モデルデータベース２６３５が関連する物理ベースモデル、例えばＸＭＬファイル、経験的モデル、例えばＸＭＬファイル、および物理システム論理／機能モデル、例えばＸＭＬファイルをハイブリッドＰＳモデルモジュール２６３０に送信することを要求する。これらのモデル／ファイルは、それぞれの構成要素属性、機能、挙動、およびセマンティクスに関する構成要素の診断および故障予測の定義および構成要素の知識を含む「ブループリント」である。図２７に関してより詳細に説明するように、関連する構成要素の物理学ベースのモデルは、現在の対応するデータ値と比較した構成要素に関連付けられた値を利用して、結果として生じる残差も生成する関連する構成要素の経験的モデルと共に残差を生成する。これらの残差を組み合わせて、組み合わせたモデルと比較して現在のデータの完全な観測を形成する。ゼロ残差付近は、異常な構成要素の挙動がないことを意味する（小さな残基は、収集されたデータからオフラインでシステムを訓練することによって後に排除され得る構成要素のノイズによって引き起こされ得る）。
損傷推定モジュール２６２５は、物理モデル（すなわち、物理ベースシステム損傷方程式）および経験的モデルからの残差を物理システム論理／機能モデルと共に利用して、各構成要素の劣化挙動の表現を生成する。残差は、期待される構成要素属性、機能、挙動、およびセマンティクスと、評価されている構成要素の現在のデータストリームによって生成された対応する属性との間の差である。残差は、構成要素の評価中に３つのモデルのそれぞれについて生成され、良好な性能を有する航空機構成要素については通常ゼロに近い。劣化レベルは、パイロット／ミッション操作者に表示される警報の重大度レベルを表す。警報レベルは、例えば、損傷推定モジュール２６２５によって判定される構成要素の残存耐用年数（ＲＵＬ）に相関させることができる。７０％～５１％の間のＲＵＬは、（最近のＲＵＬ値からの急激な低下ではなく漸進的な低下を仮定して）穏やかな劣化挙動を示し、５０％～１１％は中程度の劣化挙動を示し、１１％未満は構成要素の修理または交換を必要とする。当然ながら、様々なパーセンテージは、期待される将来の摩耗／劣化および将来の環境の重大度に応じて生じ得る。損傷推定モジュール２６２５、ＲＵＬ、およびＥＯＬ（寿命末期）の判定については、以下でより詳細に説明する。
警報生成器モジュール２６４５は、損傷推定器モジュール２６２５によって判定されたＲＵＬのレベルに基づいて警報を生成する。それは、現在および以前に記憶されたＲＵＬデータからＲＵＬの傾斜を計算し、この傾斜およびＲＵＬの現在値に基づいて警報のレベルを生成する。例えば、所定の量を超える傾斜の変化は、ＲＵＬの値のみでは警報を生成することが保証されない場合であっても、劣化が速すぎることを通知し、警報を引き起こす可能性がある。これは、図３０についてさらに説明される。計算されたＲＵＬ曲線３００５は、履歴および現在のデータから決定される。劣化した構成要素について、傾斜３０１０は、ＲＵＬ計算の摺動ウィンドウにわたって動的に計算される。最終的なＲＵＬ曲線傾斜は、いくつかの連続した摺動ウィンドウ、例えば３つのウィンドウにわたって計算される。これは、ｙ軸とｘ軸との間の１対１の測定単位関係（すなわち、単位のない傾斜を生成する時間軸）を生成するために、ｙ軸（ＲＵＬ軸）と同じ単位に対して計算され、重み付けされ、正規化されるＲＵＬ曲線傾斜の平均である。この単位のない傾斜は、所定の閾値、例えば０．５と比較される。この傾斜が所定の閾値より大きい場合、警報が発せられる。時間単位（ｘ軸値）は、動作の開始と（各摺動ウィンドウ内の）現在時刻との差であり、開始ＲＵＬは、動作の開始時の過去のＲＵＬである（すなわち、第１のスライドウィンドウで使用される、後続の摺動ウィンドウは、前の摺動ウィンドウにおける最後のＲＵＬ計算を使用し、以下同様である）。警報は、パイロット行動のための関連するＬＲＵ／構成要素を伴う警報のレベルを示す視覚的表示を提示するパイロットディスプレイ２６５０に渡される。劣化量、特定の構成要素、ならびに構成要素のフライトおよびミッション臨界性に応じて、判定は、既知の劣化した構成要素であってもフライトミッションを継続することであり得る。
アルゴリズム選択モジュール２６６０は、損傷推定器モジュール２６２５および状態予測器モジュール２６７０によって利用されるアルゴリズムを決定する。現在解析されている構成要素に関連付けられたアルゴリズム２６６８が識別され、処理のためにアルゴリズム選択モジュール２６６０から損傷推定モジュール２６２５および状態予測モジュール２６７０のメモリにロードされる。状態予測器モジュール２６７０は、過去の履歴状態を使用し、（粒子フィルタアルゴリズムを使用して）解析されている構成要素の現在および予測される将来の状態を計算する。これらの状態は、対象構成要素に関連する新しいＢＩＴ、パラメトリックセンサ、アナログ、離散、環境などのデータが受信されると更新される。解析データデータベース２６５５は、損傷推定器モジュール２６２５によってすべての解析データを、ハイブリッドモデルモジュール２６３０および状態予測器モジュール２６７０からのハイブリッドモデルパラメータと共に受信して記憶する。
サービス品質（ＱｏＳ）計算機２６７５は、ＩＶＨＭ診断および故障予測システムレベルのサービス品質メトリック、ならびに構成要素レベルのサービス品質メトリックを計算する。これらのメトリックのいくつかを図２８に示す。図２８では、すべてのメトリックが現在の航空機／システムおよびその構成要素に関連することに留意されたい。ＲＵＬは損傷推定モジュール２６２５で計算され、一方、将来の予測である寿命末期（ＥＯＬ）は状態予測モジュール２６７０で計算される。構成要素ＱｏＳメトリックは、対象車両／航空機のＱｏＳ計算機モジュール２６７５で計算され、解析データＤＢ ２６５５内のすべての現在の航空機について記憶される。オフライン地上ベースの車両レベルの故障予測システムは、すべての航空機／システムからのデータ（マイニングデータ）を蓄積し、これらの記憶されたメトリックから単一、複数、または車両全体のレポートを生成する。これらのＱｏＳメトリックは、状態予測モジュール２６７０に渡され、状態予測モジュールは、この情報を解析データＤＢ ２６５５に記憶する。様々なレポート生成およびデータ再生のために地上のオフラインで後で取得される。ミッション計画２６６５は、損傷推定器モジュール２６２５にミッションプロファイルを提供し、状態予測器モジュール２６７０にミッション計画情報を提供する。ミッション計画モジュール２６６５は、劣化したミッション計画、すなわち構成要素の劣化の程度に応じて（可能であれば）代替の修正されたミッション計画を構築するために、損傷推定モジュール２６２５から機器損傷情報を受信する。状態予測器モジュール２６７０は、ミッション計画モジュール２６６５から更新されたミッション計画を周期的に受信し、それと引き換えに、現在の設備および将来の設備の劣化状態を、設備の状態に基づいて反応的かつ事前行動的なミッション計画を構築するミッション計画モジュール２６６５に提供する。損傷推定器モジュール２６２５および状態予測器モジュール２６７０の結果によるすべての解析データは、解析データ２６５５に記憶される。
図２７は、各構成要素の挙動および劣化の傾向が確実に特徴付けられる各構成要素の、１）物理ベースのモデルモジュール２７１０、２）経験的モデルモジュール２７１５、および３）データ駆動型機能物理システムモデルモジュール２７２０からなる例示的なハイブリッドモデルシステム２６３０のブロック図を示す。物理学ベースのモデルにおける（構成要素、構造体などの製造における不完全性、および／または、翼構造体の微細構造的裂け目、トランジスタの回路不良、抵抗器、コンデンサなどの標準以下の品質の材料などの他の原因に起因する）潜在的な不正確さおよび欠陥は、経験的モデルの使用によって効果的に克服される。経験的モデル残差は、一般に、物理学ベースのモデルでは考慮されていない様々な原因による不完全性を解決する付加的なものである。これらの残差は減法的であってもよく、その場合、物理学ベースのモデルは過剰に指定される（それは航空機／システム上の利用可能な構成要素データよりも詳細にモデル化される）。そのような事象の場合、構成要素のサプライヤは、構成要素出力において追加の必要なデータを提供するように求められる。ゼロの経験的モデル残差は、構成要素の状態および状態が正常に機能していること、または以前に見られた不一致が経験的モデルから十分に改良されて現在の動作モード、使用状況、ミッション、および環境のゼロ残差を生成していることを意味する。図２７から、残差ｒ’（ｐ）およびｒ（ｐ）は数学的に表すことができる。

ここで、
ｐ＝パラメトリックセンサデータ
Ｍｐｂ＝物理ベースモデル
ｙｐｂｍ＝モデルのパラメトリック出力
ｕ＝パラメトリックデータの入力ストリーム

；類似の定義

；類似の定義
残差ｒ’（ｐ）およびｒ（ｐ）は、以下のように定義される。
ｒ’（ｐ）＝ｙｐｂｍ（ｐ）＋ｙｅｍ（ｐ）＝ｙｐｂｍ（ｐ）＋Ｍｅｍ（ｐ）ｕ（ｐ）＝｛Ｍｐｂｍ（ｐ）＋Ｍｅｍ（ｐ）｝ｕ（ｐ）
ｒ（ｐ）＝ｙｐｓ（ｐ）－ｒ’（ｐ）
残差ゼロまたはほぼゼロは、構成要素のプロセスおよびモデルを一致させるために理想的である。当然ながら、付加的なノイズは残差を変化させ、システムから排除されない場合はモデルで考慮されなければならない。
３層モデルは、構成要素の故障予測モデル全体を含み、好ましくはＸＭＬファイルとして記憶される。各モデルの入力２７０５は、それぞれの構成要素の各々に感知されたパラメトリックデータ、すなわち、データ融合モジュール１１７５およびＭＢＲ診断エンジン１０６の出力である。物理ベースモデルモジュール２７１０および経験的モデルモジュール２７１５からのそれぞれの残差出力２７２５および２７３０は、加算ノード２７３５によって合計され、その出力は、加算ノード２７４０への入力を形成する。物理システムモデルモジュール２７２０からの残差出力２７４５は、他方の入力から減算される加算ノード２７４０への他方の入力、すなわち、物理ベースのモデルモジュール２７１０および経験的モデルモジュール２７１５からの残差の加算の組み合わせを形成する（すなわち、残基のこの組み合わせは、図１に示すような期待された挙動と観測された挙動との間の差を表す）。
加算ノード２７４０の出力２７５１は、性能推定モジュール２７５５への入力であり、出力２７５０は、損傷推定モジュール２６２５に転送され、解析データ２６５５に記憶され、モデルパラメータの精緻化は、故障予測モデルＤＢ ２６３５に記憶される。状態予測器モジュール２６７０は、解析データ２６５５から（モデルパラメータおよび残差からなる）更新された解析を受信する。性能推定モジュール２７５５において、初期入力は、すべての航空機／システム構成要素に関する履歴性能データを記憶する初期性能パラメータデータベース２７６０から受信される。パラメータ残差２７５１とデータベース２７６０から得られた対応するパラメータとの比較は、入力をフィルタリングする拡張カルマンフィルタオブザーバモジュール２７６５に入力を提供し、性能のデルタ差分を含む性能推定モジュール２７５５に出力を提供する。性能推定モジュール２７５５の出力は、物理ベースモデル２７１０にルーティングされるフィードバックループであり、予測される性能測定値および過去の性能測定値との所定の性能差が根本原因解析をトリガする。連続的な低下性能は、対応する構成要素の劣化の増加によって引き起こされる。
一例として、劣化したブラインポンプを選択し、数十分の動作にわたってその様々な成分信号について監視した。このポンプの軸受性能およびポンプの動力分配性能の劣化を図２９に示す。数分の動作にわたって、軸受振動振幅２９０５は、正常動作から劣化の発生２９１０まで、可能性のある顕著な故障のポイント２９１５まで急速に上昇する。同様に、図２９では、ポンプの動力分配２９２０は、軸受劣化の発生２９２５から急激に上昇する。必要とされる大きな電力２９３０は、このレベルの動作で継続することが可能である場合、追加のポンプ構成要素の劣化を引き起こす可能性がある。多くのフライトにわたって、より正確な初期性能パラメータは、収集されたデータおよびモデルおよびアルゴリズムの改良／精緻化を介して実行されるモデルおよびアルゴリズムに関するオフライン地上訓練から連続プロセスとして得られる。
物理学ベースのモデル２７１０は、構成要素の物理学、例えば、電気的、機械的、流体力学などに基づいて対象構成要素の動作を特徴付ける複数の式を含む。これは、公称挙動と、（入力パラメトリックおよびＢＩＴデータストリームから）構成要素損傷指示が存在する場合、この損傷が品質と量の両方でどのように増大すると予想されるかを記述する。損傷表示は、本質的に単調ではない場合がある。損傷は、構成要素の固有のプロパティ（例えば、電池の回復、または電力システムの半導体に起因する影響）または不完全／部分的なメンテナンス動作などの外因性の影響によって引き起こされる可能性がある。各障害モードは、一般に、異なる損傷伝播モデルを有し得る。経験的モデル２７１５は、構成要素物理ベースモデル２７１０の異なる構成要素障害モード損傷変動および場合によっては構成要素修復（ハードウェアがこの能力を有する場合）におけるこれらの違いを捕捉するのに非常に役立つ。これらの方程式は、当然ながら、特性評価される特定の構成要素に応じて変化する。例えば、例示的なブラインポンプは、以下の表１に示すような個々の構成要素の動作で特徴付けることができる。


上記のパラメータの定義を表２に示す。

典型的なブラインポンプの公称パラメータ値を表３に示す。
経験的モデル２７１５は、構成要素の動作データの統計的に有意なサンプルに基づいて通常のシステム動作をモデル化する対象構成要素データ値のモデルを提供する。構成要素の履歴性能データに基づくそのような経験的モデルは、同じ構成要素が異なる応力レベルおよび／または異なる環境で動作した可能性があるため、物理ベースのモデルよりも性能期待値のより広い変動を可能にする。一例として、ブラインポンプインペラハウジングおよびパイプを通る時間依存性（１日の異なる時間に、数日、数週間、数ヶ月などにわたって）の流体のフローを監視することは、局所的なブラインポンプの動作および使用を特徴付ける。対応するデータ値は、局所的な航空機／システムの動作および使用において利用されるようにブラインポンプを経験的に定義する統計的に有意な経験的モデルを提供する。経験的モデルを利用することにより、同じ航空機／システム上の異なる位置にある同一のブラインポンプまたは他の航空機／システム内の同一のブラインポンプの異なるＲＵＬおよびＥＯＬ予測は、監視されているブラインポンプのＲＵＬおよびＥＯＬを判断することができる現実世界の変動を提供する。このような結果は、ＲＵＬおよびＥＯＬの予測の精度を高める。
物理システムモデル２７２０は、データ駆動型の機能モデルである。物理システムモデル２７２０内の故障予測ノードは、航空機／システムのミッションプロファイルおよびその動作モード（すなわち、フライト前、タクシー、離陸、徘徊など）に関連する構成要素の予想される使用パラメータを含む。観測／測定された挙動、すなわちデータ値は、対応する機能モデル、すなわち対応する測定データ値の値の許容範囲（閾値）と比較され、これは許容可能な挙動の「ブループリント」であり、この比較の残差２７４５が出力である。
例えば、例示的な物理システムモデル２７２０のブラインポンプ構成要素のサブセットが図３１に示されている。それは、ブラインポンプをモデル化する異なるパラメータ／特性を使用する「障害モデル」および「モデル化プロセス」からなり、この例ではブラインポンプ構成要素のサブセットが示されている。部分的なブラインバンプ表現３１００は、塩水「供給ライン」、インペラ（黒い三角形）を介した塩水「加圧出力」、およびブラインポンプ冷却システム内で塩水を循環させるためにモータによって供給されるトルクを提供するモータ回転シャフトを示す。「障害モデル」は、影響を受ける入力３１０５、影響を受ける症状３１１０、影響を受ける出力３１１５、入力３１２０、故障モード３１２５、出力３１３０、およびチェックボックス３１３５からなる。チェックボックス３１３５は、影響を受ける入力３１０５と入力３１２０との間、影響を受ける症状３１１０と故障モード３１２５との間、ならびに影響を受ける出力３１１５と出力３１３０との間の相関を表す。一例として、故障モード３１２５におけるポンプ制限の相関は、影響を受ける症状３１１０における過剰な熱、過剰なノイズ、および過剰な振動の症状に対応することに留意されたい。これは、上述した他の相関についても同様である。これらの相関は、ブラインポンプの高忠実度モデルの生成に大きな貢献をもたらす。モデルは、精査中の構成要素の劣化を理解するために必要なデータタイプを含まなければならない。モデリングプロセス３１４０は、必要とされる典型的なデータ仕様を記述する。典型的な仕様は、「記録仕様」、「アルゴリズム仕様」、「傾向仕様」（劣化の品質および量）、および「予測仕様」である。モデル化される構成要素に応じて、他の仕様が必要とされる場合がある（例えば、電気部品の配線図仕様など）。
性能推定モジュール２７５５および拡張カルマンフィルタ２７６５は共に、時間依存摺動センサデータウィンドウにおける構成要素性能差を測定する。拡張カルマンフィルタ２７６５は、経時的な構成要素センサパラメータのオブザーバとして使用される。すなわち、センサパラメータ履歴を使用して、可変時間依存摺動センサパラメトリックデータウィンドウにわたる構成要素のパラメータの変化を監視および計算する。強化カルマンフィルタは、構成要素性能における非線形力学を提供する。最初に、（オフラインで訓練された）既存の記憶された訓練データから構成要素の性能を計算し、現在のデータとの差を計算し、過去の構成要素の性能と比較する。性能の変化は、性能推定モジュール２７５５に転送される。強化されたカルマンフィルタオブザーバ２７６５および性能推定モジュール２７５５は、性能状態および劣化バイアス（構成要素に見られる場合、センサ信号の一例として図２９を参照）の両方を同時に推定する（「オブザーバ」として使用される第１モジュール２７６５内の）２段階カルマンフィルタのロバストなバンクに基づいている。入力２７０５は、（物理システムモデル２７２０からの）パラメータ残差２７５１および初期性能パラメータ２７６０と共に、性能推定２７５５カルマンフィルタ段階１に進む。拡張カルマンフィルタオブザーバ２７６５の第二段階に渡されたこの段階の出力は、新しい構成要素パラメータ、すなわち、入力２７０５からの直接に対する小さいサンプリングウィンドウにわたる残差の平均によって調整された構成要素パラメータである。段階２の２７６５では、段階１の２７５５からの推定結果が「測定値」とみなされる。段階２の２７６５の出力は、性能測定値における動的デルタ差分、および性能推定２７５５における性能推定を改善するための改善された構成要素パラメータを提供する。この２段階カルマンフィルタ手法は、異常に挙動する構成要素の高速劣化検出および分離を提供する高速共分散行列計算による高速収束のためにデザインされている。２段階カルマンフィルタは、一般的に知られており、例えば、Ｖ．Ｒ．Ｎ．Ｐａｕｗｅｌｓ，２０１３，Ｓｉｍｕｌｔａｎｅｏｕｓ Ｅｓｔｉｍａｔｉｏｎ ｏｆ Ｍｏｄｅｌ Ｓｔａｔｅ Ｖａｒｉａｂｌｅｓ ａｎｄ Ｏｂｓｅｒｖａｔｉｏｎ ａｎｄ Ｆｏｒｅｃａｓｔ Ｂｉａｓｅｓ Ｕｓｉｎｇ ａ Ｔｗｏ－Ｓｔａｇｅ Ｈｙｂｒｉｄ Ｋａｌｍａｎ Ｆｉｌｔｅｒ，ＮＡＳＡ，ＡＳＩＮ：Ｂ０１ＤＧ０ＡＴ６Ａがある。２段階機構はまた、センサパラメトリックデータが劣化を示すか否かを決定し、センサを配置し、劣化を定量化し、結果を出力する。
２段階カルマンフィルタは、図３４により詳細に示されている。離散線形時変状態空間時間方程式を使用して、構成要素パラメータの力学を記述する。これらは以下の通りである。

ここで、
ｕｋは入力データストリームであり、
ｖｋは、第１の性能推定値である。

Ｃ１およびＣ２は定数である。

共分散行列は、段階１と段階２との間のパラメータ結合を提供する。

および

は無相関ランダムガウスベクトルである。
入力データストリームｕｋ（ｐ）および残差２７５１は、性能推定モジュール２７５５の性能状態推定モジュール２７５６に送られ、これは、２セットの式１）時間更新式および式２）測定更新式を計算する。これらは、図３４において、時間更新式については下付き文字（ｋ＋１｜ｋ）と、測定更新式については（ｋ＋１｜ｋ＋１）と区別される。時間更新方程式は、状態およびエラー共分散１からｎの工程を時間的に進めることによって事前推定値を計算する役割を果たす。測定方程式は、ｕｋ＋１の静的計算によって表され、事前推定値へのフィードバック測定を通じて事後推定値を得る役割を果たす。時間依存更新は性能予測、測定更新は予測の補正の役割を果たす。この予測補正反復プロセスは、それらの実値に近い状態を推定する。測定方程式ｖ（ｋ＋１｜ｋ＋１）は結合モジュール２７５７に渡される。新しい時間依存パラメータ状態ｖ（ｋ＋１｜ｋ）が性能最適化モジュール２７６６に渡され、下付き文字（ｋ＋１｜ｋ）を有するパラメータ状態はパラメータ残差２７５１で修正され、下付き文字（ｋ＋１｜ｋ＋１）を有するパラメータ状態はそれらの決定に残差を含まない。パフォーマンス履歴モジュール２７６８は、最適化された性能予測の履歴を提供し、維持し、かつ更新する。新たな最適化された性能状態ｙｋ＋１が性能最適化モジュール２７６６によって生成され、Δ性能生成器モジュール２７６７に渡される。モジュール２７６７は、現在の前方時間１からｎの工程数にわたって動的Δ（デルタ）構成要素パラメータ性能を提供する。モジュール２７６７は、時間依存デルタ更新ｙ（ｋ＋１｜ｋ）を結合モジュール２７５７に渡し、測定更新ｙ（ｋ＋１｜ｋ＋１）をエラー補正モジュール２７５８に渡す。結合モジュール２７５７は、共分散行列Ｚｋを解くことによって測定更新ｖ（ｋ＋１｜ｋ＋１）と時間依存デルタ予測更新ｙ（ｋ＋１｜ｋ）とを結合（求解）し、エラー補正モジュール２７５８においてエラー補正された最終的な性能パラメータ

をもたらす。
２段階カルマンフィルタ法で利用されるフローチャートを図３５に示す。プロセスは再帰的に実行される。これは、工程２７８０における事前状態の予測および工程２７８５における事前エラー共分散、ならびに工程２７８７における最適カルマンゲインの計算をカバーする。それは、工程２７９０における事後予測状態および工程２７９５における事後エラー共分散を更新する。その後、プロセスは、次の処理サイクルのために初期工程２７８０に再利用される。この結果は、フィードバックループを介して物理ベースのモデルモジュール２７１０にルーティングされる。物理ベースのモデルモジュール２７１０は、物理ベースのモデリングに欠陥が否かを判定する際にこの結果を使用する。複数の時間依存摺動データウィンドウにわたる（すなわち、性能推定モジュール２７５５の出力結果からの）劣化事象のサイズ（定量化）および速度は、モデルの改良を促進する。これらの改良結果および関連するセンサパラメトリックデータは、後の再生および学習／訓練のために故障予測モデルＤＢ ２６３５に記憶される。
損傷推定モジュール２６２５は、各構成要素の損傷量の決定を行う。ブラインポンプの例では、損傷ベクトル方程式は次式で与えられる（物理ベースモデル方程式のすべての変数は、直接測定されたパラメトリックセンサ値またはこれらのセンサパラメトリックデータから導出された値であることに留意されたい）。
摩擦摩耗（摺動および転がり摩擦）
ｒｔｈｒｕｓｔ（ｔ）＝ｗｔｈｒｕｓｔｒｔｈｒｕｓｔω２
ｒｒａｄｉａｌ（ｔ）＝ｗｒａｄｉａｌｒｒａｄｉａｌω２
ここで、
ｗｔｈｒｕｓｔ＝スラスト軸受摩耗係数
ｗｒａｄｉａｌ＝ラジアル軸受摩耗係数
ω＝ポンプ回転速度（先に定義）
ｒｔｈｒｕｓｔ＝摺動摩擦
ｒｒａｄｉａｌ＝転がり摩擦
損傷ベクトル
ｄ（ｔ）＝［ａ４（ｔ），ｒｔｈｒｕｓｔ（ｔ），ｒｒａｄｉａｌ（ｔ）］θ
ここで、
ｄ（ｔ）＝は損傷ベクトルであり、
ａ４（ｔ）＝インペラ面積係数（先に定義）
ｒｔｈｒｕｓｔ＝摺動摩擦（先に定義）
ｒｒａｄｉａｌ＝は転がり摩擦（先に定義）
θ＝ポンプ温度
ブラインポンプの著しい損傷は、軸受の摩耗に起因して発生し、これは摩擦の増加の関数である（すなわち、摩擦係数を受ける）。
摩耗ベクトルは、摩耗係数によって形成される。
ｗ（ｔ）＝φ（ｔ）＝［ｗａ４，ｗｔｈｒｕｓｔ，ｗｒａｄｉａｌ］θ
ここで、
φ（ｔ）は、予測アルゴリズムにおけるパラメータベクトルとして使用され、
重量計算からそれを微分する
θ＝ポンプ温度
損傷推定器モジュール２６２５におけるＲＵＬ計算は、ＲＵＬが現時点で計算され、将来の投影／予測ではないことを除いて、状態予測器２６７０について以下に説明するＥＯＬ計算と同一である。経時的な劣化したブラインポンプ劣化を表す典型的なＲＵＬグラフ３００５を図３０に示す。ＲＵＬは、障害／故障および／または構成要素の欠陥がない場合であっても（すなわち、欠陥方程式は、データが利用可能な過去または現在の時間ホライズンのいずれかにおけるすべての動作条件に対して有効）、航空機／システムの動作履歴の任意の時点で推定することができる。ＲＵＬ（データが利用できない場合）の将来の予測は、寿命末期（ＥＯＬ）予測として知られている。
状態予測器２６７０は、時間依存式である状態ベクトルを使用する。ブラインポンプの場合、完全な状態ベクトル方程式は次のように書くことができる（物理ベースモデル方程式のすべての変数は、直接測定されたパラメトリックセンサ値またはこれらのパラメトリックセンサデータから導出された値であることに留意されたい）。
ｘ（ｔ）＝［ω（ｔ），θｔｈｒｕｓｔ（ｔ），θｒａｄｉａｌ（ｔ），θｏｉｌ（ｔ），ａ４（ｔ），ｒｔｈｒｕｓｔ（ｔ），ｒｒａｄｉａｌ（ｔ）］θ
θｔｈｒｕｓｔ＝は推力軸受の温度である（先に定義）
θｒａｄｉａｌ＝ラジアル軸受の温度（先に定義）
θｏｉｌ＝油の温度（先に定義）
ａ４（ｔ）＝インペラ面積係数（先に定義）
ｒｔｈｒｕｓｔ＝摺動摩擦（先に定義）
ｒｒａｄｉａｌ＝は転がり摩擦（先に定義）
ω（ｔ）＝ポンプモータ回転（先に定義）
状態予測器２６７０は、時間依存式である状態ベクトル、すなわち、任意の時点におけるブラインポンプの状態を使用する。損傷方程式および状態方程式は共に、任意の時点における構成要素の物理学を定義する。
ブラインポンプのＥＯＬの予測は、上述の状態ベクトル方程式および損傷方程式の方程式を用いてブラインポンプの将来の状態を予測する粒子フィルタアルゴリズムを使用して数値的に計算される。将来の状態粒子確率密度（ｘは上記の状態ベクトルであることに留意されたい）は、粒子フィルタ（ＰＦ）プロセスによって与えられる。
粒子フィルタ（ＰＦ）は以下の計算をする。

この分布をｎ工程で近似する。

そのため、粒子ｉは、利用可能な新しいデータなしでｎ工程前方に伝播され、
その重量を


とし、ＥＯＬは以下の近似をされる。

すなわち、ＥＯＬ予測の重量に対するｋｐでの粒子の重量を使用しながら各粒子をそれ自体のＥＯＬまで前方に伝播する。
粒子フィルタプロセスは、カルマンフィルタリングの線形性およびガウスノイズの仮定を回避するロバストな手法であり、不確実性を効果的に考慮しながら、長期ホライズン故障予測のためのロバストなフレームワークを提供する。収集された解析データ２６５５からの長期ホライズン予測のためのアルゴリズムの精度および正確性を改善するために、オフライン訓練／学習において補正項が推定される。粒子フィルタリング方法は、経時的な劣化モードの発展を表す状態方程式が、加法ノイズ、反復的に洗練されたサンプリング重量、および条件的に独立した出力を有する一次マルコフ過程としてモデル化され得ると仮定する。
図３２および図３３は、それぞれ粒子フィルタアルゴリズムおよびＥＯＬ予測の例示的なフローチャートを示す。工程３２０５において、粒子フィルタアルゴリズムは、メモリに記憶された初期粒子パラメータで初期化される。工程３２１０において、初期粒子パラメータに基づいて初期粒子集団が生成される。工程３２１５において、粒子は、状態予測子モデルを使用して伝播される。工程３２２０において、様々なパラメータに割り当てられた重量は、工程３２２５におけるそれぞれのパラメータの現在の測定値に基づいて更新される。工程３２３０において、更新された重量が縮退した重量であるか否かの判定が行われる。縮退した重量は、粒子重量の差、すなわち、少数の粒子が高い重量を有し、残りの粒子が小さい重量を有する場合として定義される。すべての再サンプリングされた粒子が＜＝５％以内の同様の重量を有する場合、粒子変動重量縮退は中断される。工程３２３０によるＮＯ判定は、工程３２１５に戻ることによるプロセスの反復をもたらす。工程３２３０によるＹＥＳ判定は、工程３２３５による再サンプリングをもたらし、続いて工程３２１５に戻ることによるさらなる反復が再び続く。縮退が中断されていない場合、再サンプリングが必要である。推定に寄与しない粒子の計算を回避するために、現在の粒子数（工程３２１５に伝搬された粒子）に対して再サンプリング（３２３５）が行われる。これらの粒子重量は外れ値であり、拒絶される。粒子フィルタプロセスはまた、上記の粒子フィルタ方程式によって説明される。
図３３は、ＥＯＬ判定を提供するための例示的な方法のフロー図である。工程３３０５において、ＥＯＬ生成が開始される。工程３３１０において、初期粒子集団（計算のために選択された粒子の任意の初期数であり、記憶された生データおよび解析データからのオフラインアルゴリズムおよびモデル訓練の後の改善）の推定が行われる。工程３３１５において、粒子は、状態予測子モデルを使用して伝播される。工程３３２０において、検討中の構成要素について所定のパーセンテージのＥＯＬに達したか否かの判定が行われる。工程３３２０によるＮＯ判定は、工程３３１５に戻る反復をもたらし、そこで状態予測子モデルを使用した粒子のさらなる伝播が発生し、続いて工程３３２０による再度の判定が行われる。工程３３２０によるＹＥＳ判定の結果、工程３３２５でＥＯＬ予測が生成される。航空機／システムの動作中の（劣化した構成要素についての）連続構成要素ＥＯＬ予測は、解析データ２６５５に記憶される。このＥＯＬ予測は、将来の航空機／システム動作に使用される。ＥＯＬ予測は、製品支援チームにレポートとして提供されるＥＯＬ予測を生成するためのさらなる解析のために、地上およびオフラインの車両レベル故障予測エンジンによって、このデータおよび以前の履歴データからＥＯＬ確率分布関数（ＰＤＦ）を作成することを可能にする。上記の式は、ＥＯＬ決定のより詳細な説明を提供する。なお、ＲＵＬは、現時点で計算されており、将来の状態予測を伴わない。この計算は、上述のＥＯＬ方程式および方法を使用して現在の時点のＲＵＬ計算が決定されることを除いて、上述のＥＯＬ計算と同一である。
図４４により詳細に示すように、図３６および図３７は、ユーザ選択可能な制御がＧＵＩ ３６０１によって提供される例示的な車両レベル故障予測システム３６００のブロック図を提供する。例示的なＧＵＩ ３６０１は、複数のメニューを有するメニューバー３６０２と、ボタンアイコン上にマウスをホバーさせたときに示されるツールチップ３６０４内の名前によって示される行動を開始するように構成された複数の実行可能ボタンアイコンを有するツールバー３６０３とからなる。メイン画面本体３６０５は、利用可能なすべての航空機の行を表示するテーブルであり、各行は尾部番号によって識別される一機の航空機を表示する（同様のタイプの航空機の車両からの航空機は、それらの尾部番号によって個別に識別される）。表の各列は、そのシリアル番号、尾部番号、ミッション能力（地上ベース、部分的にミッション可能（ＰＭＣ）、非ミッション可能（ＮＭＣ）、および完全ミッション可能（ＦＭＣ））、そのゾーン、その位置、および他のユーザ定義属性など、航空機の尾部番号に固有の属性を表示することができる。表示された各航空機は、その状態、機器資産などを示すためにマウス選択することができる。ＧＵＩは、役割ベースの動作モードを有し、すなわち、各役割は、異なる目的を有する人員による異なる使用に関係する。これらの人員は、１）航空機ミッションを計画および実行するミッション操作者、２）航空機のメンテナンスの役割を果たすメンテナンス管理者、３）ミッション操作者およびメンテナンス管理者を訓練する訓練士、４）物理的構成要素のモデル（物理学ベース、データ駆動、および経験的）を開発するモデルデザイン者、５）データベース機能を維持するデータベース管理者、および６）車両レベル故障予測システムの動作のためのソフトウェアを開発、維持、および生成するプログラマであり得る。ＧＵＩは、柔軟で同時の利用を提供するために、異なるオペレーティングシステムおよび様々なサーバ（例えば、ミッションサーバ、メンテナンスサーバ、訓練サーバ、技術データサーバなど）を有するサーバ上で独立して実行することができる。
ツールバー３６０３の「サーバ」ボタンアイコンが（ミッション操作者モードのミッション操作者によって）「オフ」から「オン」に変更されると、車両レベルの故障予測システムは自律モードに入り、ＣＯＭＭＳシステム３６０５と様々なデータソケットリンクを確立し、ＣＯＭＭＳシステムは、フライト中の様々な航空機、またはフライト前テスト、地上走行、および打ち上げ前などの地上動作における他の航空機からデータを受信する。すべてのＧＵＩ機能は、典型的には、手動で実行するようにミッション操作者によって選択されない限り、自律的に実行される。メンテナンス管理者は、ＧＵＩ ３６０１を介して、オフラインの「メンテナンスモード」（すなわち、新たな航空機データを取得しようとしていないか、またはＣＯＭＭＳ ３６０５が非アクティブである場合）で実行し、様々な計算および予測を実行し、予測メンテナンススケジュールに必要なレポートを構築し、航空機構成要素の平均故障間隔（ＭＴＢＦ）に基づいてメンテナンススケジュールを構築するようにシステムに指示することができる。ＭＴＢＦは、構成要素サプライヤの信頼性およびテストデータからの構成要素仕様からデザイン段階で開発される。これらは、図４３に関連付けられた説明されるように、予測メンテナンスが必要性を通知するとき、または即時の補正メンテナンスを必要とする故障が発生したときに、企業資産管理（ＥＡＭ）システムにおける在庫管理および供給チェーン動作を支援し、構成要素および構成要素を保管し、修理／交換の準備を整える。ＧＵＩ ３６０１を介したトレーナは、蓄積された生データおよび解析されたデータを再生することによって車両レベル故障予測システムの使用を他者に教示および訓練するために、オフライン「トレーナモード」でシステムを実行することができる。デザイナモードでは、デザインフェーズおよび他の段階における後の改良の間に、デザイン者は、モデルを作成し、それらを検証し、ＧＵＩ ３６０１（図４４）を介して４３５５テストマネージャ（図４１）の合成および／または実際のフライトデータでそれらをテストする。メンテナンス管理者は、ＧＵＩ ３６０１（図４４）を介してこの能力も有する。プログラマモードは、車両レベル故障予測システム３６００を構築、修正、または強化するための開発モードである。
図３６および図３７は、例示的な車両レベル故障予測システム３６００のブロック図である。システムは、車両レベルのデータを収集し、オンボード故障予測モデルを改善し、すべての同様の航空機の共通の構成要素のメンテナンスが必要か否かの判定を可能にするための構成要素メンテナンスメトリックを生成する。システム３６００は、認定技術者による実施可能なメンテナンスタスクのための動的な予測メンテナンススケジュールを提供する。本明細書で使用される場合、「車両レベルのデータ」は、複数の同様のタイプの航空機からのデータを指す。当然ながら、複数の異なる車両のデータを収集し、車両レベルで解析することができる。データインターフェース３６２５は、異なる入力デバイスからデータを受信するための通信インターフェース（ＡＰＩ）を提供する。通信チャネル３６０５は、（戦術通信リンクを介して）車両／航空機のオンボード埋め込みアビオニクス故障予測エンジンから地上ベースサーバ上で動作するシステム３６００へ無線通信によって無線送信されるデータを表す。すべての航空機は、アビオニクスミッションコンピュータまたはアビオニクスベイに設置された独立したＩＶＨＭコンピュータ上で動作するこのエンジンを有する。ＣＯＭＭＳ ３６０５は、航空機の全車両に利用可能な複数の通信チャネルである。システム３６００は、これらすべての通信チャネルからデータを受信するようにデザインされている。「同様の航空機／同様のタイプの航空機」は、同じモデルおよび仕様カテゴリの航空機である。例えば、同じ軍用航空機、例えば米国空軍による使用が指定されたＦ－３５Ａは、米国海軍によって使用するために指定されたＦ－３５Ｂ、および米国海軍によって使用するために指定されたＦ－３５Ｃとは異なる構成要素および能力を有し得る。そのような状況では、１つの「同様の航空機」グループ（車両）は、米国空軍による使用が指定されているＦ－３５Ａ航空機を含み、別の同様の航空機グループは、米国海軍によって指定されているＦ－３５Ｂ航空機を含み、別の同様の航空機グループは、米国海軍による使用が指定されているＦ－３５Ｃ航空機を含む。地上では、航空機データは、アンビリカルケーブル（ネットワークケーブル）接続３６１０によって、またはホットスワップ可能なソリッドステートドライブ（ＳＤＤ）３６１５を航空機から取り外し、それらをメンテナンス管制センターに物理的に輸送し、ＳＳＤドライブレセプタクル３６２０を介して車両レベル故障予測エンジン３６００にデータを渡すことによって転送することができる。データインターフェース３６２５は、（航空機通信リンクに接続されたときの）異なるデータレートおよびソースからの入力データの受信に関連付けられたフォーマットを収容する。データインターフェース３６２５によって識別された航空機から受信された入力データは、データが受信された特定の構成要素／航空機の尾部番号を識別するための既存のヘッダ（メタデータ）を有するタイムスタンプ付きセンサデータを含む。入力データはまた、オンボードＭＢＲ診断エンジン１０６（１４）によって生成された関連する構成要素／航空機尾部番号を識別するようにタグ付けされた解析データ、およびオンボード故障予測システム２６００によって生成された関連する構成要素を識別するようにタグ付けされた解析データを含む。このデータは、２つのパスでストレージ３６２６データベースに記憶される。１）航空機が動作可能であり、無線通信リンクを介してデータを送信している場合、データインターフェースモジュール３６２５は、データを受信してデータ分配モジュール３６３０に直接渡し、データ配信モジュールは、このデータをデータストレージ３６２６データベースに記憶する。２）航空機が地上にあるとき、例えばフライト後の動作中に、データは、手動転送３６１５を介してアンビリカルケーブル接続３６１０またはＳＳＤドライブレセプタクルインターフェース３６２０を介して車両故障予測システム３６００に、データインターフェースモジュール３６２５に、次いでデータストレージ ３６２６データベースに渡される。データ配信モジュール３６３０からストレージ３６２６へ行われる要求は、オフライン使用のためにデータストレージ３６２６モジュールから新たに記憶されたデータを取得する。
モデル、アルゴリズム、および構成要素は、トリプレット（１つ、１つ、１つ）または（１つ、多数、１つ）または（１つ、多数、多数）の三つ組でマッピングされる。マッピング（１つ、多数、１つ）および（１つ、多数、多数）は、構成要素が同様／同一であり、複数のアルゴリズムが構成要素の正確な結果を生成し得る場合に生じる。このマッピング方式モデルでは、常に、構成要素に関連する唯一の（すなわち、３階層モデルの組み合わせ）であることに留意されたい。これにより、故障予測モデルモジュール３６４０におけるモデルアルゴリズム構成要素の自動選択が可能になる。データ配信モジュール３６３０は、ストレージモジュール３６２６データベースからデータを引き出し（新しいデータが到着するとデータの自動プルを可能にするデータベーストリガへのアクセスを有する）、「引き出された」データを故障予測モデルモジュール３６４０解析システムに配信する。モジュール３６４０は、アルゴリズムモジュール３６７０の構成要素に適用され、アルゴリズムライブラリ３６８０から選択された適切なアルゴリズムを用いて、構成要素に固有の適切な３層モデルを選択する。これにより、モデルアルゴリズム構成要素システムが構成要素に対して故障予測を実行することが可能になる。データ配信モジュール３６３０は、生データを自動ロジスティクス環境（ＡＬＥ）モジュール３８００および３８３０に送信する。故障予測モデルモジュール３６４０は、構成要素モデルに関連するアルゴリズムのマッピングを有する。各構成要素は、個別に調整されたアルゴリズムを有する（例えば、電子システムは、機械システムまたは構造システムと同じアルゴリズムを有さない）。故障予測モデルモジュール３６４０内で、データは物理ベースの故障予測モデル３６４１、経験的故障予測モデル３６４２、およびデータ駆動の故障予測モデル３６４３にさらに分配される。同様に、故障予測アルゴリズムモジュール３６７０は、物理ベースモジュール３６７１、経験的モジュール３６７２、およびデータ駆動モジュール３６７３からなる。データはモジュール３６４１からモジュール３６７１に送信され、累積モデル残差は残差分配モジュール３６５０からモジュール３６７１に送信される。これは、モジュール３６４２、３６７２、および３６５０、ならびにそれぞれモジュール３６４３、３６７３、および３６５０についても同じ方法で行われる。これらのモジュールの処理および動作は、モジュール２６３０（図２７の）、すなわち、対応するモデル、物理ベースのモデルモジュール２７１０、経験的モデルモジュール２７１５、およびデータ駆動機能物理システムモデルモジュール２７２０について説明したものと実質的に同じである。図３６に示されるモジュール３６４０において使用される故障予測モデルは、複数の同様の航空機内に配置される同様の構成要素のそれぞれの故障予測を提供するように機能し、その結果、同様の構成要素のそれぞれの相対的な性能が、データ配信モジュール３６３０から受信されるデータに対する他の同様の構成要素の集合的な性能（平均、中央値など）と比較され得る。同様に、モジュール３６７０で使用されるアルゴリズムは、複数の同様の航空機に配置された同じ構成要素のそれぞれについてモジュール３６４０の３層モデルにアルゴリズムを提供するように機能し、その結果、同様の構成要素のそれぞれの相対的な性能は、データ配信モジュール３６３０から受信したデータに対する他の同様の構成要素の集合的な性能と比較することができる。故障予測モデルモジュール３６４０および故障予測アルゴリズムモジュール３６７０の様々なモデルは、それぞれモデルライブラリＤＢ ３６６０およびアルゴリズムライブラリＤＢ ３６８０に記憶され、評価される特定の構成要素データに基づいて使用するために取得される。残差分布モジュール３６５０は、予測結果の精度および正確性を高めると共に、モデルおよびアルゴリズムの両方の継続的に改良する。改良点は、それぞれモデルおよびアルゴリズムについてモデルライブラリＤＢ ３６６０およびアルゴリズムライブラリＤＢ ３６８０に記憶される。システム２６００に記載されているように、非ゼロ残差は、その後パラメータ性能推定モジュール２７５５によって確認される劣化事象を示す。これは、システム３６００で使用されるのと実質的に同じ処理である。
図４１は車両レベルの故障予測システムのデザイン、訓練、および改良を示す図である。デザインモードでは、モデリングエンジニア４３１０は、グラフィカルユーザインターフェース４３１５、４３２５、および４３３５を使用して、対象構成要素の物理ベースモデル、データ駆動モデル、経験的モデルにそれぞれ変更および修正を入力する。例えば、修正を含む予測モデルマークアップ言語（ＰＭＭＬ）に記憶することができるそれぞれのモデル４３２０、４３３０、および４３４０は、その後、故障予測モデルライブラリ４３５０に記憶される。同様に、アルゴリズム開発インターフェース４３７５を利用するアルゴリズムエンジニア４３７０は、それぞれのアルゴリズムの修正を、例えばＪａｖａ（登録商標）ファイル、ＪＮＩファイル（Ｊａｖａ（登録商標）とＣ＋＋データ構造との間のインターフェース）、およびＣ＋＋ファイルとしてのプログラミングファイル４３８０に入力することができる。更新されたプログラミングファイル４３８０は、アルゴリズムライブラリ４３８５に記憶される。
故障予測モデルライブラリ４３５０からのモデルおよびアルゴリズムライブラリ４３８５からの対応するアルゴリズムを利用するテストマネージャ４３５５は、ストレージデータベース４３６０（３６２６ストレージから移行されたフライトデータ（図３６））からのシミュレートまたは記録されたフライトデータに基づいて予測精度をテストすることができる。回帰テストおよび精度テストの結果は結果４３６５に記憶され、これは、アルゴリズムライブラリ４３８５に記憶された対応するアルゴリズムを修正して精度を高めるためにアルゴリズム改良および訓練モジュール４３９５によって使用され、また、それぞれのモデルの精度を高めるために故障予測モデルライブラリ４３５０に記憶された対応するモデルのモデル改良および訓練モジュール４３９０の修正によっても使用される。
デザインモードでは、ユーザは、グラフィカルユーザインターフェース（ＧＵＩ）ならびに適切な構成要素アルゴリズムを介して、同様の航空機および時間ホライズン（数時間、数時間、数ヶ月、数年、および数十年）における同様の構成要素の解析を選択する能力を有する。これらの選択肢は、構成要素モデルおよびアルゴリズムのＡＮＳＩ ＳＱＬ文を含むＸＭＬファイルとして記述され、故障予測モデルライブラリ４３５０およびアルゴリズムライブラリ４３８５のデータベースに記憶されてもよい。ＸＭＬファイル内の組み込みＳＱＬ文は、テストマネージャ４３５５で実行されるときに様々なデータベースからのデータの自動抽出を可能にする。ＸＭＬファイルは、再現可能なテストを実行するためのスクリプトファイルとなる。自動スクリプトファイルテストは、テスト対象の構成要素に適用されるモデルおよびアルゴリズムの回帰テストにとって非常に重要である。これらは、新しいパラメータ改良のために容易に更新され、一方、古いパラメータは、ＸＭＬファイル内の＜ｈｉｓｔｏｒｉｅｓ＞＜／ｈｉｓｔｏｒｉｅｓ＞ラベルの下に保持される。動作モードでは、システム２６００において、故障予測モデルおよび対応するアルゴリズム構成ファイルが航空機に転送され（モデルデータベースが移行され）、それぞれ故障予測モデルＤＢ ２６３５およびアルゴリズム２６６８ファイルに航空機に記憶される。同様に、システム３６００では、これらはモデルライブラリＤＢ ３６６０およびアルゴリズムライブラリＤＢ ３６８０に記憶され、故障予測モデルモジュール３６４０およびアルゴリズムモジュール３６７０での処理に利用される。車両レベル解析は、オンボードシステム２６００データ上で動作する損傷推定器モジュール３６７４について説明したのと同じ方法で車両データ上で動作する損傷推定器モジュール２６２５（システム２６００の通信回線２６００を修正してシステム３６００から取られた同様の処理制御）においてさらに進む。同様に、車両レベル解析は、オンボードシステム２６００データ上で動作する状態推定器モジュール２６７０について説明したのと同じ方法で車両データ上で動作する状態予測器モジュール３６７５（システム２６００内のＳＯＨ計算および通信回線２６００の修正を伴ってシステム３６００から取られた同様の処理制御）で進行する。
アルゴリズムライブラリＤＢ ３６８０は、性能解析が利用可能な航空機上のすべての構成要素に対して開発されたすべてのアルゴリズムを記憶する。アルゴリズムモジュール２６６８で使用されるアルゴリズムは、車両レベル故障予測システム３６００用に開発されたアルゴリズムの完全なセットの小さなサブセット（すなわち、オンボード処理のために効率的かつ高速であるニューラルネットワーク、カルマンフィルタ、および粒子フィルタ）である。特定の構成要素に適用されるこれらのアルゴリズムのいくつかは、ロジスティクス回帰、線形回帰、時系列、記号時系列、ランダム森、決定木、移動平均、主成分（ＰＣＡ）、サポートベクターマシン（ＳＶＮ）、マルコフ連鎖、ベイズ法、モンテカルロ法、ニューラルネットワーク（それらの多く）、粒子群最適化、様々なフィルタ（カルマンフィルタおよび粒子フィルタ）、高速フーリエ変換（ＦＦＴ）、勾配およびＡｄａブースト、ウェーブレット、遺伝的、自然言語、クラスタリング、分類、学習および訓練、ならびにデータマイニングを含む。
損傷推定器モジュール３６７４からの出力は、図３８により詳細に示されている解析融合モジュール３６９０への入力として提供される。損傷推定器モジュール３６７４、状態推定器モジュール３６７５、および警報生成器モジュール３６７６の処理は、システム２６００および３６００の対応する機能と実質的に同じであることに留意されたい。状態予測器モジュール３６７５は、システム３６００におけるＳＯＨ計算のために強化され、それによって、システム２６００およびシステム３６７５の両方がＣＯＭＭＳ ３６０５アクティブで動作しているときに、モジュール３６７４および３６００の両方がそれらの解析結果をシステム２６００に送信するために（ＣＯＭＭＳ ３６０５を介して）追加の通信リンクを有する。これらのモジュールは、可能なハードウェアおよびソフトウェアの再構成のために航空機フライト制御システム（ＦＣＳ）に情報を提供する（これについては後述する）。同様に、システム３６００では、モジュール３６７４および３６７５の両方が、短期ホライズン（１日より長い）から長期ホライズン（航空機の車両がいつ陳腐化するかに依存する、５０年未満または５０年超）に最適化される。システム２６００では、これらのモジュールは、航空機のミッションフライト時間（離陸から着陸まで）に依存する短期ホライズンで機能する。解析融合モジュール３６９０は、すべての同様の構成要素のモジュール３６７４からの解析出力および関連データを、選択された解析時間ホライズン（例えば、数時間、数日、数ヶ月、数年、数十年の持続時間）においてすべての同様の航空機のために融合する。データ融合モジュール３６９１（図３８）は、図２６のデータ融合モジュール１１７０と同様の方法で動作し、適切にタグ付けされた構成要素または同様の構成要素のグループに相関付けられた移動時間ウィンドウ内で損傷推定モジュール３６７４の予測からの入力出力をマッピングおよび平均化する。モジュール３６９１は、タグ付けされた警報を警報発生器３６７６（警報発生器２６４５と同様の機能であるが、車両レベルの計算のために最適化されている）に送信し、これらの警報はその後、ミッション操作者モードでＣＯＭＭＳ ３６０５に接続されたときにミッション操作者ダッシュボード３７８５に、およびメンテナンス管理者のモードでメンテナンス管理者ダッシュボード３７９０に登録される。このモジュール３６９１はまた、データおよび解析を状態予測器モジュール３６７５にも送信し（車両レベルの計算のために強化および最適化され、ＳＯＨ計算を含む）、これは先に定義されたのと同じタスクを実行するが、解析融合モジュール３６９０では、これはまた、４４０５における構成要素の状態健全状態（ＳＯＨ）インジケータを計算および予測する（図４２）。ＲＵＬおよびＥＯＬは、損傷推定モジュール３６７４で計算され、構成要素の状態（異常な挙動）である（故障／障害、故障分離、誤警報、および根本原因解析は、ＭＢＲ診断エンジン１０６（１４）から得られる）。ＭＢＲ診断エンジン１０６（１４）から得られた異常な挙動データおよび解析は、その後、解析データリポジトリ３７１０に記憶され、それぞれメトリック３７４０におけるメトリック計算およびレポート３７５０におけるレポート生成に使用される。
解析融合モジュール３６９０からの出力は、ユーザが選択可能なベースで情報のグループ化を提供するメトリックモジュール３７４０への入力として提供される。例えば、図４２のＧＵＩ ４４００は、解析融合モジュール３６９０によって提供された情報を、レポートモジュール３７５０で生成された選択された故障予測レポート４４０５、メンテナンススケジュールレポート４４１０またはＱｏＳレポート４４１５にソートするために使用できる様々なユーザ選択可能な基準を示す。図２８に示すメトリックおよびレポート機能は、図４２に示すもののサブセットであることに留意されたい。図４２に示す故障／劣化およびサービス品質（ＱｏＳ）基準に加えて、様々なタイプのメンテナンスレポート、例えば、スケジュールされたメンテナンス、予防メンテナンス、予測メンテナンス、および補正メンテナンスもまた、ユーザによって選択され、閲覧（ミッションダッシュボード３７８５およびメンテナンスダッシュボード３７９０内）およびプリント（プリント機能プリントモジュール３７９５）のために生成され得る。予測を実行するための既存の時間ホライズンが４４２０に示されている。これは、短い（１日まで）、中程度（数ヶ月）、および長い（数十年）ホライズンについてボタン４４４０を介して更新することができる。レポートは、単一の航空機４４２５、航空機４４３０のサブセット、または航空機４４３０の全車両について生成することができる。４４３５ボタンは、先に実行された既存の記憶された予測を検索することを可能にし、より良いレポート結果を得るために調整を行うことを可能にする。４４４５ボタンは、選択されたレポートのプリントを可能にし、ボタン４４５０は、レポートおよび予測を保存し、ボタン４４５５は、レポート画面を終了する。
電子部品のレポートモジュール３７５０（図３７）によって生成された例示的な予測メンテナンススケジュール４５００を図４３に示す。単一／複数の同様の構成要素の健全状態（ＳＯＨ）、残存耐用年数（ＲＵＬ）、および寿命末期（ＥＯＬ）メトリックは、メトリックモジュール３７４０（損傷推定モジュール３６７４および状態予測モジュール３６７５から取得）にグループ化され、レポートを生成するために、ならびに故障予測結果ＤＢ ３７６０にメトリックおよびレポートを記憶するために、レポートモジュール３７５０に送信される。レポート目的のために図４２に示される他のすべてのメトリックは、モジュール解析データリポジトリ３７１０および故障予測結果ＤＢ ３７６０から得られる現在のデータおよび現在の解析を用いて、メトリックモジュール３７４０において計算される。ユーザの選択により、メトリックおよびレポートの閲覧およびプリントは、ユーザによって選択された正しい既存のパラメータを有する既存のデータ（新しいものではない）および既存のメトリック、レポート、およびデータ（解析データリポジトリ３７１０からのデータ）についての故障予測結果ＤＢ（図３７）に対するクエリによって達成される。そうでなければ、新しいデータおよび新しいパラメータの選択肢について、新しいメトリック予測およびレポートがオンザフライで生成され、ユーザの要求に応じて後で使用するために記憶される。解析データリポジトリ３７１０および故障予測結果ＤＢモジュール３７６０からのデータはまた、それぞれ既存のメトリックおよびレポートと同時に視覚化され得るか、または新しいレポートとしてまとめて生成され得る。
図４３は、上にグラフ４５０５を有するチャート４５００と、下にグラフ４５１０とを示し、それぞれが同じｘ軸タイムラインを有するが異なるｙ軸を有し、ｙ軸上のパーセンテージとしてＲＵＬ／ＥＯＬを有するチャート４５０５と、チャート４５１０は任意のｙ軸（すなわち、視覚的影響のための棒グラフの任意の高さ）を有する。グラフ４５０５は、対象構成要素の予測されたＲＵＬを表す線４５１５を示しており、これは、１月の１００％から４月の７５％まで増加する下降傾斜で下降している。下降傾向の増大は、メンテナンスの観点から懸念の原因となり、場合によっては数日で構成要素の重大な故障の懸念の原因となる。線４５２０は、さらに増加する下降傾向に基づいて４月に線４５１５の将来に行われた１つの予測を表し、線４５２５は、より小さい下降傾向に基づいて４月に線４５１５の将来に行われた別の予測を表す。線４５２０は５月の０％ ＲＵＬを示し、線４５２５は６月の０％ ＲＵＬを示し、０％ ＲＵＬは潜在的な重大な故障を表す。線４５２０と線４５２５との間の持続時間は、不確実性の期間（または不確定性の包絡線）と呼ばれる。これらの予測と、特定の構成要素ならびにＲＵＬ予測の量および傾斜の変化によって変化し得る所定の閾値量、例えば３０％のＲＵＬとに基づいて、例えば信頼性中心メンテナンス（ＲＣＭ）解析を介してロジスティクスエンジニアリングによって生成されたスケジュールされたメンテナンス間隔などの、固定された所定のメンテナンススケジュール間隔の前に、これらの実際の状態に基づく予測に基づいてメンテナンスの必要性が示される。０％ ＲＵＬは、構成要素の寿命末期（ＥＯＬ）を示す。グラフ４５１０は、グラフ４５０５の予測に基づいて、５月初めの直前の間隔４５３５の間にスケジュールされた予測メンテナンスを示す。これは、ロジスティクスエンジニアリングが、１０月から１１月の間の構成要素の事前にスケジュールされたメンテナンス間隔４５４０を計画したこととは対照的である。また、ライン４５３０は、構成要素の状態に基づいてこの動的にスケジュールされた予測メンテナンス事象で４５３５回の予測メンテナンスが発生しなかった場合、ライン４５２０またはライン４５２５（０％ ＲＵＬのＥＯＬ）と整列することに留意されたい。予測メンテナンス４５３５が発生した場合、線４５１５上の影響、すなわち線４５３０は、航空機の稼働率の増加に利益をもたらしながら、問題の構成要素の寿命の大幅な増加を示す。ボタン４５４５は、以前に記憶されたグラフデータおよび予測の表示を提供し、ボタン４５５０は、現在のグラフデータおよび後で使用するための予測を記憶し、ボタン４５５５は、現在のグラフをプリントし、ボタン４５６０は、現在の画面を終了する。
履歴および訓練データデータベース３７３０は、オンラインおよびオフライン動作中に解析されたすべての構成要素に関連付けられたデータの解析から収集された履歴データを含む。訓練システムモジュール３７２０は、より精緻で正確な解析を提供するために、データベース３７３０に含まれるデータを利用して、解析融合モジュール３６９０で利用されるアルゴリズムを周期的に更新する。
解析データリポジトリ３７１０は、ＭＢＲ診断エンジン１０６（１４）、故障予測エンジン２６００のオンボードＰＭＢＲ、およびＰＭＢＲＧＣＳ（地上ベースの車両レベル故障予測エンジン３６００）からの以前に解析されたデータのすべてを含む。この情報は、解析の精度を高めるのを支援し、モジュール３７５０によってユーザ選択レポートを生成するためにメトリックモジュール３７４０によってこの情報へのアクセスを提供するために、解析融合モジュール３６９０に利用可能にされる。また、モジュール３６９０によって行われた解析は、履歴データ情報と統合されるようにデータベース３７１０に送信される。データベース３７１０はまた、アルゴリズムを継続的に改良できるように、アルゴリズムライブラリデータベース３６８０と通信する。両方のモデルおよびアルゴリズムの改良は、訓練システムモジュール３７２０においてオンラインまたはオフラインで自律的に行うことができる（モジュール３６００は地上に配置されたサーバ上で実行されており、航空機運用のためのフライトまたはミッションクリティカルなシステムではないため）。これらの改良は、モジュール３６９０から受信したデータおよび解析をモジュール３７２０における累積解析に提供し、モジュール３７１０からデータを受信し、モジュール３７７０および３７８０からデータおよび解析を受信する。モジュール３７２０の訓練アルゴリズムは、アルゴリズムライブラリＤＢ ３６８０から得られる。履歴データベースからのデータを用いて、既存の解析のための移動平均アルゴリズムおよび他のモジュール（上述）のパラメトリックおよびＢＩＴデータのための主成分アルゴリズムと組み合わせて、高忠実度の改良を行うことができ、履歴および訓練データＤＢモジュール３７３０内の同様の構成要素の次のデータの解析を実行するために記憶することができる。また、故障予測精度およびアルゴリズム調整・訓練モジュール３７７０は、アルゴリズムライブラリデータベース３６８０との対話型通信を提供し、解析データリポジトリ３７１０に入力を提供する。モジュール３７７０は、構成要素データの解析に利用される対応するアルゴリズムの修正に反映される継続的な精度更新を提供する。同様に、モジュール３７１０はまた、モデルライブラリデータベース３６６０に記憶されているモデルと順に通信する、故障予測モデル調整および訓練モジュール３７８０とも通信する。
故障予測結果データベース３７６０は、メトリックモジュール３７４０からユーザが選択したメトリックおよびデータと、レポートモジュール３７５０からの対応するレポートとを受信し、記憶する。データベース３７６０はまた、解析されたデータへのアクセスを提供する解析データリポジトリ３７１０と通信する。データベース３７６０はまた、ミッションダッシュボード３７８５およびメンテナンス管理者ダッシュボード３７９０に情報を提供する。ミッションダッシュボード３７８５は、運用車両レベル故障予測システム３６００のミッション操作者モード（役割ベースのアクセス）でアクセス可能である。それは、すべての動作中および地上ベースの航空機の状況認識、ならびに、モデルデザイン機能を除く、車両レベル故障予測システム３６００ ＧＵＩモジュール３６０１内のすべてのメニューおよびボタンへのアクセスを提供する。同様に、維持管理者ダッシュボード３７９０は、維持管理者の動作モードまたは維持管理者の役割で維持管理者にアクセス可能である。メンテナンス管理者は、モデルデザイン機能を除いて、ＧＵＩ ３６０１内のすべてのメニューおよびボタンにアクセスすることができる。これらのダッシュボードの各々からの出力は、ＧＵＩ ３６０１でプリントボタンがクリックされると、プリント機能モジュール３７９５に提供され、その後ダッシュボードで選択された項目のプリント出力を提供する（図４４参照）。
この例示的な実施形態では、データ配信モジュール３６３０からのデータは、有機自動ロジスティクス環境（ＡＬＥ）（すなわち、メンテナンスおよび支援システム）３８００およびＡＬＥ請負業者ロジスティクス３８３０に提供される。モジュール３８００からの出力は、ストレージのためのデータを選択し、データベースファーム３８２０から使用のためのデータを引き出すデータマイニングモジュール３８１０に提供される。同様に、モジュール３８３０からの出力は、ストレージのためのデータを選択し、データベースファーム３８５０から使用するためのデータを引き出すデータマイニングモジュール３８４０に提供される。ＡＬＥメンテナンスおよび支援システム（軍事およびその契約業者の両方のためのロジスティクス運用）は、３レベルのメンテナンス、修理および／または交換、オーバーホールなどのメンテナンス機能、ならびに在庫管理、スペア部品および部品注文のためのサプライチェーン機能などの他の組織機能のために必要な企業レベルのアプリケーションを提供する。車両レベル故障予測診断システム３６００は、診断および故障予測データならびに解析をこれらのＡＬＥに提供する。図３９Ａおよび図３９Ｂは、オンボード構成要素（システム２６００）およびオフボード構成要素（システム３６００）の両方の性能評価ならびに関連するモデルおよびアルゴリズムの改良に使用されるモデルおよびアルゴリズムの精度を高めるために、車両レベルの構成要素性能メトリックがどのように使用されるかを示すフロー図４１００である。フローチャート４１０１は、図４１に示す統合開発環境（ＩＤＥ）システムを使用してモデルおよびアルゴリズムを改良するために実行される訓練および学習を定義する。以下に提供される説明は、モデルの改良およびアルゴリズムの両方に等しく適用可能であることに留意されたい。ストレージ３６２６またはデータファーム３８５０内の収集された生データは、工程４１０５において、航空機および同様の航空機構成要素メタデータ（すなわち、末尾番号）を記憶されたファイル内で検索するデータマイニングアルゴリズムを介して抽出される。データファーム３８２０は、一般に、システムを構築した軍事請負業者には利用できない。システムを所有する軍事支部のみが利用可能である。分類および機械学習アルゴリズムを使用する構成要素および同様の構成要素のパラメータおよびパラメータ特徴抽出が、工程４１１０においてこのデータに対して実行される（すなわち、データは前処理される）。一般に、航空機の動作時間間隔全体にわたって収集される十分なデータがあるので、少量の欠落データがある場合でも、解析に悪影響を与えない。工程４１１５において、統計的サンプリングフィルタアルゴリズムを使用して、訓練データセットおよびテストデータセットの代表的なセットの構成要素および同様の構成要素パラメータを選択、操作、および解析し、訓練データセットの工程４１２０およびテストデータセットの工程４１２５に示すように、検査中のより大きなデータセットのパターンおよび傾向を識別する。工程４１３０において、訓練データセット４１２０は、特徴選択、スケーリング、および次元縮小のためのさらなる前処理を経る。特徴選択は、訓練データセットが特徴除外、すなわち外れ値データの除外を受け、したがって不正確な解析をもたらし得るデータセット内の望ましくない特徴を低減するプロセスである。次元削減は、データセットをより低い次元に変換し、迅速なパターン認識を提供し、結果の計算の複雑さを低減する。スケーリングは、最小値と最大値との間（一般にゼロと１との間）のスケーリング要因を有するアルゴリズムおよびモデルの両方の数値安定性を改善するために使用することができる。このデータはまた、テストデータセット４１２５に追加され、より細かい改良を提供する。工程４１３５において、訓練データセットは、モデルに関連付けられた３層モデルパラメータおよびアルゴリズムパラメータを改良する最も正確な特徴およびパターンを検索するように機械学習アルゴリズムを訓練する。これらのパラメータは、工程４１４０において、履歴および現在のデータセットからの３層モデルおよびそれらのアルゴリズムを最もよく記述するデータの重み付けサンプリングによるパラメータ最適化でさらに最適化される。工程４１４５において、後処理および判定時点、ＲＵＬ、ＳＯＨ、およびＥＯＬが計算され、過去および現在の航空機フライトデータ結果と比較される。これらが既に利用可能な値から遠く、例えば１０％より大きい場合、改良は工程４１３０で継続する。既に利用可能な値に近い（十分に近くない、例えば１％より大きく１０％以下の）場合、改良は工程４１３５で継続する。ｎ回の改良の後、値があまり変化しない、例えば１％以内である場合、最終的なモデルおよびアルゴリズムのパラメータおよびメトリックは、工程４１５５の新しいデータに記憶され、新しいパラメータは、４１２５のテストデータに追加され、４１５５の新しいデータにも記憶される。４１５５の新たなデータは、図４１のデータベース４３５０の故障予測モデルライブラリ、４３８５のアルゴリズムライブラリ、および４３６５個の結果（改良されたテストデータセットおよびメトリックについて）を指す。次いで、これらのデータベース（４３５０，４３８５，４３６５）は、それぞれ、車両レベル故障予測システム３６００の３６６０モデルライブラリＤＢ、３６８０アルゴリズムライブラリＤＢ、および３７４０故障予測結果ＤＢに移行される。同様に、これらのデータベース（４３５０，４３８５，４３６５）は、オンボードシステム２６００の２６３５個の故障予測モデルＤＢ、２６６８個のアルゴリズム（サブセットアルゴリズムのみ）、および２６５５個の解析データにそれぞれ移行される。４３５０、４３８５、および４３６５のデータベースをシステム２６００および３６００に移行することにより、モデルおよびアルゴリズムの精度向上および改良が達成される。
動作状態４１０２において、工程４１６５のモデルおよびアルゴリズムデータベースは、システム３６００内のデータベース３６６０モデルライブラリＤＢおよび３６８０アルゴリズムライブラリＤＢをそれぞれ参照する。工程４１７０から４１８５は、それぞれアルゴリズムおよびモデルについての３７７０故障予測精度ならびにアルゴリズム調整および訓練と３７８０故障予測モデル調整および訓練において生じる既存の処理に対する並列処理である。これは、パラメータ性能調整およびモデルおよびアルゴリズムの改良のために新しいデータが到着したときにのみ発生する（ＣＯＭＭＳ ３６０５がアクティブであり、かつシステム３６００へデータを送信している場合、さもなければ、３６２６ストレージ内の既存のデータが利用される）。最初の解析およびデータは、上述の工程４１０１訓練システムの学習および訓練アルゴリズムで抽出される。新しいデータが到着すると、工程４１７０でモデル解析の感度および特異性が開始される。モデルの場合、この解析は、モデル入力値の変化から生じるモデル出力値の変化を検索する。それはまた、入力から出力結果までのモデルパラメータの不確実性を決定する。アルゴリズムの感度は、「真陽性」の劣化率を確認し、アルゴリズムの特異性は、正しく識別される「真陰性」の劣化率を確認する。真陰性のレートは、航空機上の同様の構成要素全体に対して取られたときに、真陽性のレートを低下させる傾向がある。感度および特異性は、ＲＵＬ、ＥＯＬ、およびＳＯＨの測定における精度を高める。工程４１７５は、メトリック計算の不確実性を、例えば±５％に決定する。このパーセンテージが設定量より大きい場合、工程４１７０が再開始され、そうでない場合、プロセスは工程４１８０の検証および妥当性確認テストに進む。工程４１８０において、回帰テストが実行され（既存の成功したテストスクリプトが実行される）、以前のテスト結果と比較される。これらのテスト結果が工程４１８５で合格した場合、新しい解析およびデータは、ストレージおよび将来の処理のために工程４１０１のデータベースに送信される。これらのテスト結果が合格しない場合、解析および処理は工程４１７０に戻り、プロセスは上述のように継続する。
図４０は、航空機の車両内の単一の／すべての同様の構成要素がいつメンテナンス／同時メンテナンスを必要とするかを決定するために構成要素の車両レベル性能メトリックがどのように使用されるかを示すフロー図である。１）自律モードおよび２）オフラインのミッション操作者／メンテナンス技術者モードの２つのモードがある。自律モードは、ＣＯＭＭＳ ３６０５がアクティブであり、３６０１のサーバボタンが「オン」にクリックされるとアクティブになり、ソフトウェアソケット接続を介したシステム３６００とＣＯＭＭＳ ３６０５との間のハンドシェイクを可能にする。ＣＯＭＭＳ ３６０５からデータ配信モジュール３６３０へのリアルタイムデータ伝送は、自動化モードを検証する（すなわち、到来するデータはトリガである）。自律モードでは、劣化／障害／故障事象警報が存在する場合、これらは、特定の航空機尾部番号について、「地上ベース」航空機のカラーグレー、「完全ミッション可能（ＦＭＣ）」のカラーグリーン、「部分ミッション可能（ＰＭＣ）」のカラーオレンジ、および「非ミッション可能（ＮＭＣ）」のカラーレッドとして、画面３６０５（図４４）に視覚化される（すなわち、すべての同様の航空機のテーブルである）。さらなる行動は、ミッション操作者の介入を必要とする。注記として、ＰＭＣは、航空機が依然としてそのミッションを劣化モードで実行することができることを意味する。一方、ＮＭＣは、航空機がリカバリモード（フライト終了シーケンス）に入る、すなわちできるだけ早くホームに戻り、安全な場所に着陸する、または墜落することを意味する。操作者は、色がオレンジまたは赤の行をクリックすることができる（すなわち、画面３６０５上の各行は、動作中または地上で固有の尾部番号を有する航空機に関する情報である）。行がクリックされると、別の詳細画面が、メトリックモジュール３７４０から取得されたそれらの関連するメトリックと共に、その特定の航空機上のすべての材料資産の可視性を提供する。低いＲＵＬおよびＳＯＨのパーセンテージは、ミッション操作者が劣化した資産行を単にクリックして図４３に示すような画面を表示することによって予測メンテナンススケジュールを見るための推進力となる。オフラインのミッション操作者／メンテナンス技術者モードでは、ストレージ３６２６で収集されたデータは、上記と同じ動作を実行するために使用されるが、３６０１で「予測を実行する」ボタンをクリックすることによってオフラインで、または３６０５で航空機（行）をクリックし、その後、資産行をクリックすることによって上記で説明したように、図４３の結果を見るために、すなわち、とるべきさらなる措置を決定するために使用される。劣化した資産の図４３に示す予測メンテナンススケジュールは、図４０に示すフロー図に依存する。
図４３は、図４０の決定形状４２３０における決定ごとに、予測メンテナンスが事前に計画されたスケジュールメンテナンスよりも「先に」発生する場合を示す。工程４２３５でメンテナンススタッフへの作業指示が発行される。「後の」予測メンテナンススケジュールは、（工程４２４５において）計画されスケジュールされたメンテナンスライン４５４０を予測メンテナンススケジュールライン４５３５の上に移動させる効果を有する。「先の」場合および「後の」場合の両方において、訓練システムモジュール３７２０（履歴および訓練ＤＢ ３７３０を更新する）および故障予測結果ＤＢ ３７６０は、工程４２４０を介して更新される。工程４２００は、モジュール３６６０、３６８０、および３７６０から入力を受信し、モジュール３６７４および３６７５内のＲＵＬ、ＥＯＬ、およびＳＯＨを計算し、劣化事象および構成要素性能の低下を識別する。モジュール３６９０および３７４０は、工程４２１０、４２１５において必須の処理を提供し、工程４２２０、４２２５、４２３０、４２３５、４２４０、および４３４５は、それぞれ予測メンテナンススケジュールおよび事前に計画されたスケジュールされたメンテナンスについて、レポートモジュール３７５０において計算される。図４３に示すグラフ化トリガ能力は、プリント機能３７９５を介してレポートモジュール３７５０、ならびにグラフ化機能を必要とし得る他のモジュールに存在する。
ＳＯＨは、構成要素の関連する物理学、化学、および／または生物学（すなわち、バイオテクノロジー）に依存するパーセンテージスコアであり、例えば、電池のＳＯＨは、ｉ番目のサイクルの最大残存容量Ｃｉを公称容量Ｃ０で割ることによって推定される。

電池のＳＯＨは、サイクル充放電に依存し、そのＲＵＬおよびＥＯＬは、その構成材料の物理的および化学的プロパティに依存する。他の構成要素の場合、このプロセスは周期的ではなく、例えば、構造、機械設備、電子回路基板、回転機械などである。例えば、油水混合物中の砂粒子は、チョークバルブに深刻な侵食を引き起こす可能性がある。侵食が発生すると、開放値の増加により流体フロー係数Ｃｖの値が増加する。このシステムのＳＯＨは次のようになる。

Ｃｆは、（ダルシー・ワイスバッハの式）によって与えられるパイプフローの摩擦係数であり、

ここで、
Ｈｆは損失水頭（ｆｔ）
Ｌはパイプの長さ（ｆｔ）であり、
Ｄはパイプの内径（ｆｔ）であり、
ｖは流体の速度（ｆｔ／ｓ）であり、
ｇは重力加速度（ｆｔ／ｓ２）である。
Ｃｆは、一般に、対応するサプライヤの仕様書に記載されている。Ｃｖの計算値は直接的ではないが、チョークバルブ内およびチョークバルブの近くで利用可能なセンサに応じて、センサデータ、すなわち上流圧力、下流圧力、温度、フローレート、流体密度、エントロピーから計算することができる。
別の例は、構造（ターボファン航空機エンジンのターボブレード、ターボファンハウジング、ヘリコプタブレード、翼構造など）における亀裂進展である。フロー図を図４５に示す。有限要素解析（ＦＥＡ）４６１０（利用可能なデータ４６０５を使用）は、デザイン段階中に、問題の亀裂空間を要素（より小さい空間セルまたはゾーン）に分割する初期メッシュを用いて実行され、その上で偏微分方程式を解くことができ、亀裂空間の正味のより大きな領域の結果を生成する。図４５の動作段階４６１５から４６５０において、工程４６１５は、ＦＥＡ ４６１０から構造破壊パラメータを抽出し、これらのパラメータを入力センサデータで処理し、その後、亀裂伝播方向、その長さの成長を計算し、その後、亀裂先端の新しい位置を登録する。工程４６２５は、全方向の亀裂長さを決定し、以前の計算または以前のフライト計算と比較する。工程４６３０において、ＳＯＨが計算され、モジュール３６９０に送信される。ＦＥＡ ４６１０はまた、航空機の空力不安定を引き起こす臨界亀裂長さ「Ｌｃｒｉｔｉｃａｌ」を計算する。この不安定性が発生すると、工程４６３５で「Ｌｃｒｉｔｉｃａｌ」に到達し、工程４６４０で警報が生成され、即座の行動のための点滅警報としてミッション操作者ダッシュボード３７８５に表示される。工程４６４５において、決定工程４６３５における臨界亀裂長さに達していない場合、処理は亀裂パラメータの更新によって継続し、工程４６５０においてこれらの新しい亀裂進展パラメータで再メッシュ化が適用される。処理は工程４６１５へのフィードバックによって継続する。これらの構成要素のＳＯＨは、経時的な亀裂伝播のパーセンテージおよびその臨界性を示す。ＳＯＨは、材料組成（すなわち、ミクロ構造変形および材料不純物）、環境条件、ならびに様々な運航操縦およびミッションの下（重力を増減させる効果を有する高加速度および低加速度、高速旋回、高速上昇および下降）での航空機の使用に依存する。図４７に示すように、亀裂進展は、経時的にゆっくりと成長する小さな亀裂（４８０５）または経時的に急速に成長し、周期的な外部負荷サイクルＮに応じて非常に短い時間間隔で重要なシステム故障に伝播する可能性がある長い亀裂進展（４８１０）（すなわち、ｄａ／ｄＮ ４８１５）であり得、亀裂の周りの領域の引き裂きの増加は、この周期的な外部負荷および構造材料上の応力（４８２０）によるものである。ＳＯＨは数学的に与えられる。


；パリの法則
ここで、
ａ＝亀裂長さ
Ｎ＝負荷サイクル
ΔＫ＝応力強度係数
「Ｃ」および「ｍ」は、周波数、温度、応力比および環境条件から実験的に得られる。

ここで、ｓ＝印加応力

電池の例は、外部負荷に電気を供給するため、その内部の化学的および物理的構造に起因して周期的な充電および放電を扱っていることに留意されたい。一方、亀裂進展の例では、外部の繰り返し負荷が構造に変形を引き起こし、亀裂を成長および引き裂く材料の引き裂き剪断応力および歪みをもたらす。構造に対するこの外部負荷は、周期的ではなく連続的であってもよい。
工程４６３５において、構造的故障が予測される臨界亀裂長さＬｃｒｉｔｉｃａｌに達したか否かの判定が行われる。工程４６３５によるＹＥＳ判定の結果、工程４６４０においてミッションダッシュボードで警報が生成される。構造的故障を引き起こす可能性のある亀裂の臨界長さＬｃｒｉｔｉｃａｌが決定されているため、警報の生成は適切である。臨界亀裂長さが構造的故障を引き起こすと予測されるＬｃｒｉｔｉｃａｌにまだ到達していないことを示す工程４６３５によるＮＯ判定は、工程４６４５で亀裂パラメータ、センサパラメータ、新しい環境条件およびミッションプロファイル、ならびに新しい使用パラメータを更新する。この更新に続いて、工程４６５０において、工程４６１５に戻ることによって別の計算反復が継続され、その結果、新しい情報に基づいて工程４６３５によって継続的な決定を行うことができる。
図４６Ａおよび図４６Ｂは、構成要素のメンテナンス特性対時間のグラフである。モジュール３８００は、メンテナンスタスク注文の生成、（最低でも）メンテナンスの中間レベル（Ｉレベル）の実施、サプライチェーンおよび在庫管理などに使用される軍の有機メンテナンスおよび支援システムを表す。モジュール３８３０は、防衛請負業者のメンテナンスおよび支援システムを表す。防衛請負業者は、航空機を運用する組織によってＤレベル（すなわち、保管所レベルのメンテナンス）を実行するように求められてもよく、次いで、組織は、そのサプライヤおよび製造業者にＤレベルメンテナンスを要求してもよい。Ｏレベルメンテナンスは、航空機を運用する組織（すなわち、軍事）によって、航空機の請負業者または開発者によって提供される技術データおよび場合によってはサービスと共に提供される（すなわち、請負業者チームは、軍内に組み込まれてもよい）。様々なタイプのメンテナンスは、ｙ軸上で１００％の性能からほぼ０％の性能までの範囲の「性能状態」４７０５対「時間」の確率として図４６Ａに記載されており、補正メンテナンスを示し、構成要素のＥＯＬを反映することができる（構成要素を稼働させたままで非常に高価な構成要素のオーバーホールが実行され得る）。メンテナンス目的として、構成要素／ライン交換可能ユニット（ＬＲＵ）の残存耐用年数（ＲＵＬ）および残存耐用性能（ＲＵＰ）は、スケジュールされていないメンテナンスを回避しながら最大化されるべきである。図４６Ａに示す用語の定義を以下に定義する。


このグラフから、潜在的な故障４７１０の発生時には、構成要素が予防メンテナンスのスケジュールされた時間４７１５を超えて実質的なＲＵＬを有することが多いため、予防メンテナンス４７１５は、典型的には、予測メンテナンス４７３０よりも多くのコストを追加しながら、実質的に費用対効果が低くなることは明らかである。したがって、予測メンテナンスを利用して実際の性能に基づくメンテナンスを利用すると、構成要素のより長い動作寿命が得られ、したがって構成要素の交換／修理費用、ならびに航空機の動作をより長く維持しながらメンテナンスを実行するための人件費が最小限に抑えられる。
図４６Ｂにおいて、破線４７５５は、ゼロのメンテナンス値４７５０を表す。この値は、航空機のスケジュールされていないメンテナンスのための作業指示を伴う航空機のダウンタイムによる）平均ロジスティクス遅延時間（ＭＬＤＴ）と平均修理時間（ＭＴＴＲ）との間の移行点およびその動作状態の準備完了４７５５を表す。ＭＬＤＴは、管理作業の様々な遅延、輸送手段の欠如または往復輸送のための長い時間、および他の理由に起因し得る。ＭＬＤＴが解決されると、メンテナンス修理または交換動作を実行するために追加のＭＴＴＲが必要とされる。グラフ４７６０の正のピークおよびゼロへの直接降下は、一般に、ＥＯＬに近づく構成要素を表し、スケジュールされていないメンテナンス（高価な構成要素の完全なオーバーホール）につながる可能性があることに留意されたい。
図４８において、障害管理４９１０は、診断および監督４９０５（障害検出、障害分離、誤警報拒否、および根本原因解析）および故障予測４９１５（劣化解析およびメトリック計算：航空機機器の健全性のためのＲＵＬ、ＥＯＬ、ＳＯＨ）ならびに様々な相互に関連するメンテナンス行動、手順、および再構成（すべて４９２０から４９９９）からなる。高忠実度および正確な診断および故障予測が、構成要素および航空機のメンテナンス、修理、およびオーバーホール（ＭＲＯ）活動に大きな影響を与えることを理解することが重要である。正確な障害および故障の分離、誤警報の拒否、および機器の劣化の判定は、メンテナンス作業負荷を低減し、航空機の運用の車両を低減し、正確な診断および故障予測を用いて費用負担の最大５０％（数十年にわたって重要）を排除する数十年にわたる運航の費用を支援する。車両レベル故障予測診断システム３６００は、これらの様々なメンテナンス機能のそれぞれについて解析、計算、記憶、およびレポートをする。メンテナンス４９２０の手順は、スケジュールメンテナンス４９３５およびスケジュールされていないメンテナンス４９４０に分類される。スケジュールメンテナンス４９３５は、予防メンテナンス４９５０、予測メンテナンス４９５５、補正メンテナンス４９６０、および必要に応じたメンテナンス４９６５（緊急かつミルメンテナンスの必要性の実行を指す）においてさらに分類される。同様に、スケジュールされていないメンテナンス４９４０は、反応的／緊急メンテナンス４９７０に分類される。ブロック４９５０～４９６５はそれぞれ、それぞれ、スケジュールメンテナンス４９３５のためにブロック４９９１～４９９４において認定技術者によって実行されるそれらの典型的なメンテナンス動作に関連付けられている。反応的／緊急メンテナンス４９７０は、その参照メンテナンス行動ブロック４９９５を有する。反応的／緊急メンテナンス４９７０と必要に応じたメンテナンス４９６５との重要な差は、反応的／緊急性の必要性と併せて計画されたメンテナンスタスクを含めることであるが、オンデマンドメンテナンスタスクは、アドホック時間間隔メンテナンスが計画されない結果となり得る（例えば、利用可能な最良の時間）。交換／修理４９２５のタスクは、スケジュール／計画された修理４９７５およびスケジュールされていない／計画されていない修理４９８０に分類される。ブロック４９７５および４９８０は、それぞれ関連するメンテナンス動作４９９６および４９９７を有する。航空機フライト制御システムは、耐障害性があり、適応回復力を有し、その結果、（例えば、ハードウェアビットの固着、スイッチの固着、リレーの固着など）再構成するためのコマンドを送信することによって、障害からのハードウェアおよびソフトウェアのフライト中の再構成が可能である。再構成４９３０は、静的冗長性４９８５および動的冗長性４９９０を有する耐障害性システム４９４５でのみ利用可能なそのような適応回復力を実行する。損傷推定モジュール３６７４および状態推定モジュール３６７５は、車両レベル故障予測システム３６００が動作可能であり、ＣＯＭＭＳ ３６０５を介してオンボード故障予測システム２６００に接続されている間、フライト中の動作においてのみ利用可能なこの再構成機能を実行する。システム２６００は、システム３６００に追加の処理を要求し、システム２６００は、必要な解析およびコマンドシーケンストリガに関する情報を提供する。システム２６００は、航空機フライト制御システム（ＦＣＳ）に伝送するためのコマンドシーケンスを構築し、検証する。何らかの理由でシステム３６００が利用可能でない場合、システム２６００は、利用可能な情報から不確実性を有する最良の可能なコマンドシーケンスを構築する。航空機を停止させることなく再構成するための（システム２６００によって提供されるトリガからの）コマンドシーケンスを生成するためのシステム３６００への直接フィードバックリンクがある。なお、このコマンドシーケンス情報は、ＦＣＳへの推奨に過ぎない。システム２６００および３６００は状況認識のみを提供する、ＦＣＳは、利用可能なハードウェアおよびソフトウェアの冗長性、現在のミッション、環境条件、起こり得るカスケード障害および故障（１つの構成要素の障害が他の構成要素、ならびに他のサブシステム構成要素の障害を生成する）などの様々な要因に応じて、再構成コマンドシーケンスを送信するか否かの最終決定を行わなければならない。この情報の大部分は、システム２６００および３６００によって提供される。静的冗長性および動的冗長性は、ＦＣＳによって処理される。耐障害性システムにおける静的冗長性（リアルタイム性能で高い信頼性を必要とする）は、一般に、（ＦＣＳにおける）ブロック４９９８のメモリ補正コードおよび多数決方式「ｍ ｆｒｏｍ ｎ ｓｙｓｔｅｍｓ」を扱う。同様に、動的冗長性は、高忠実度および正確な診断（モジュール１０６（１４））、故障予測診断（モジュール２６００および３６００）、および冗長ハードウェアを必要とする。計算ハードウェアは、単一、２重、３重または４重の冗長システム（すなわち、あらゆる点で同一である）とすることができる。そのような場合、ＦＣＳは、最も可能性が高く最良の結果を決定するためにハードウェア出力間で多数決方式を使用する（すなわち、単一は、単一故障点、２重は、マスタがスレーブを引き継ぐ場合、マスタ－スレーブ構成にあり、３重は、３つの同様の結果のうちの２つ、４重は、４つの同様の結果のうちの３つなど）。４重冗長ハードウェアでは、２つのペアが異なる結果を示し、各ペアが同じ結果を示す場合の複雑化のハードウェア複雑性の結果の場合、どのペアを選択するか。正しいペアを選択するには、他の情報／証拠が必要である。各コンピュータが異なる結果を示す場合、さらに困難である。これらは、診断および故障予測システムではなく、ＦＣＳにおいて懸念されるトピックである。図４８の要素は、劣化に伴う冗長性（ＨＷ，ＳＷ）を介して、故障防止、故障除去、および故障防止の役割を果たすことに留意されたい。

Claims (8)

  1. 地上ベースコンピューティングシステムによって実施される方法であって、
    複数の同様の航空機に配置された同様の構成要素の性能パラメータのデータを受信する工程と、
    前記それぞれの同様の構成要素の対応する劣化レベルおよび劣化変化率を判定する工程と、
    それぞれのグループ内の同様の構成要素の合成劣化の解析に基づいて、前記同様の構成要素の前記グループのための車両レベルの劣化を生成する工程と、
    前記同様の構成要素の各々の劣化レベルと同様の構成要素の前記グループの前記車両レベルの劣化との比較に基づいて、前記それぞれの同様の構成要素の各々の残存耐用年数（ＲＵＬ）および健全状態（ＳＯＨ）のうちの少なくとも１つを判定する工程と、
    同様の構成要素の前記ＲＵＬおよび前記ＳＯＨのうちの対応する少なくとも１つに基づいて、各々の前記同様の構成要素のメンテナンスの予測時間を判定することによって、車両レベル情報に基づいて構成要素の費用効果の高いメンテナンスの判定を可能にする工程とを含む方法。
  2. データを受信することが、前記航空機が地上にある間に、複数の同様の構成要素のデータをそれぞれの同様の航空機から前記地上ベースコンピューティングシステムに転送することを含み、前記データが、前記航空機がフライト中に航空機データストレージデバイスに記憶された構成要素性能パラメータに基づく、請求項１に記載の方法。
  3. データを受信することが、前記航空機がフライト中に、複数の同様の構成要素のデータをそれぞれの同様の航空機から前記地上ベースコンピューティングシステムに無線通信リンクを介して転送することを含む、請求項１に記載の方法。
  4. 前記それぞれの同様の構成要素の対応する劣化レベルおよび劣化変化率を判定することが、
    前記それぞれの同様の構成要素の物理モデルおよび前記それぞれの同様の構成要素の経験的モデルのうちの少なくとも一方によって、前記物理モデルおよび前記経験的モデルのうちの少なくとも一方によって判定された、前記同様の構成要素の前記性能パラメータの現在の状態と前記同様の構成要素の前記性能パラメータの対応する状態との差である第１の残差を判定することと、
    前記それぞれの同様の構成要素の物理システムモデルによって、前記同様の構成要素の性能パラメータの現在の状態と、前記物理システムモデルによって判定された対応する同様の構成要素の性能パラメータの所定の範囲の状態との差である第２の残差を判定することと、
    前記第１の残差および前記第２の残差の組み合わせに基づいて、前記それぞれの同様の構成要素の劣化レベルおよび前記それぞれの同様の構成要素の劣化変化率を判定することとを含む、請求項１に記載の方法。
  5. それぞれの同様の構成要素について前記車両レベルの劣化を生成することが、
    すべての同様の構成要素の前記ＲＵＬの加重平均を生成することを含む、請求項１に記載の方法。
  6. 前記それぞれの同様の構成要素の各々について前記ＳＯＨを判定することが、
    同様の構成要素の各々の現在のＳＯＨを判定することと、
    前記同様の構成要素の各々について、現在の対応するＳＯＨを１００％の性能の状態と比較して、同様の構成要素の現在のＳＯＨを生成することとを含む、請求項１に記載の方法。
  7. 前記それぞれの同様の構成要素の各々について前記ＲＵＬを判定することが、
    同様の構成要素の前記ＲＵＬの以前の判定および前記それぞれの同様の構成要素の性能の劣化率に基づいて、前記同様の構成要素の各々のＲＵＬを判定することを含む、請求項６に記載の方法。
  8. 航空機のオンボード構成要素の劣化判定の精度を改善するために地上ベースコンピューティングシステムによって実施される方法であって、
    複数の同様の航空機に配置された同様の構成要素の性能パラメータのデータを受信する工程と、
    対応する同様の構成要素の各々の少なくとも２つのモデルによって、受信データに基づいて、それぞれの同様の構成要素の対応する劣化レベルおよび劣化変化率を判定する工程と、
    各グループ内の同様の構成要素の劣化に基づいて、前記同様の構成要素の前記各グループの車両レベルの劣化を生成する工程と、
    前記車両レベルの劣化に基づいて同様の構成要素の前記少なくとも２つのモデルのうちの少なくとも１つを修正して、前記少なくとも１つのモデルの精度を改善する工程と、
    前記修正された少なくとも１つのモデルを同様の航空機に送信する工程であって、前記修正された少なくとも１つのモデルが、前記少なくとも１つのモデルの以前のバージョンを交換するために使用されて、オンボード劣化解析を生成することができ、それにより、車両レベルのデータに基づいてオンボード劣化解析の精度を高める工程とを含む方法。
JP2022573618A 2020-07-31 2021-06-18 車両の改善されたメンテナンスのための車両レベル故障予測 Pending JP2023536677A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/945,263 US10964130B1 (en) 2018-10-18 2020-07-31 Fleet level prognostics for improved maintenance of vehicles
US16/945,263 2020-07-31
PCT/US2021/038036 WO2022026079A1 (en) 2020-07-31 2021-06-18 Fleet level prognostics for improved maintenance of vehicles

Publications (1)

Publication Number Publication Date
JP2023536677A true JP2023536677A (ja) 2023-08-29

Family

ID=77338751

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022573618A Pending JP2023536677A (ja) 2020-07-31 2021-06-18 車両の改善されたメンテナンスのための車両レベル故障予測

Country Status (4)

Country Link
EP (1) EP4189505A1 (ja)
JP (1) JP2023536677A (ja)
CA (1) CA3176638A1 (ja)
WO (1) WO2022026079A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240096147A1 (en) * 2022-09-20 2024-03-21 International Engine Intellectual Property Company, Llc Scanner for monitoring the reliability of systems
CN117634303B (zh) * 2023-12-06 2024-06-21 北京京能能源技术研究有限责任公司 一种基于ai建模的汽轮发电机铁心过热故障预警方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120283963A1 (en) * 2011-05-05 2012-11-08 Mitchell David J Method for predicting a remaining useful life of an engine and components thereof

Also Published As

Publication number Publication date
WO2022026079A1 (en) 2022-02-03
EP4189505A1 (en) 2023-06-07
CA3176638A1 (en) 2022-02-03

Similar Documents

Publication Publication Date Title
US10964130B1 (en) Fleet level prognostics for improved maintenance of vehicles
US10814883B1 (en) Prognostics for improved maintenance of vehicles
US10725463B1 (en) High frequency sensor data analysis and integration with low frequency sensor data used for parametric data modeling for model based reasoners
US11308250B2 (en) Learning expected operational behavior of machines from generic definitions and past behavior
EP3867718B1 (en) Parametric data modeling for model based reasoners
Esperon-Miguez et al. A review of Integrated Vehicle Health Management tools for legacy platforms: Challenges and opportunities
Dangut et al. An integrated machine learning model for aircraft components rare failure prognostics with log-based dataset
US10643187B2 (en) Reporting and prioritizing faults for aircraft downtime reduction
US9399526B2 (en) Method, devices and program for computer-aided preventive diagnostics of an aircraft system, using critical event charts
US9266626B2 (en) Method, devices and program for computer-aided analysis of the failure tolerance of an aircraft system, using critical event charts
EP3497527B1 (en) Generation of failure models for embedded analytics and diagnostics
JP2023536677A (ja) 車両の改善されたメンテナンスのための車両レベル故障予測
KR20180114255A (ko) 헬리콥터 엔진의 정비 추천 시스템
Miller et al. System-level predictive maintenance: review of research literature and gap analysis
CA3163790C (en) Prognostics for improved maintenance of vehicles
Das et al. An open architecture for enabling CBM/PHM capabilities in ground vehicles
Dibsdale Aerospace Predictive Maintenance
King et al. Equipment health monitoring in complex systems
Knight et al. Intelligent management of helicopter health and usage management systems data
Zaluski et al. Developing data mining-based prognostic models for cf-18 aircraft
Schoenmakers Condition-based Maintenance for the RNLAF C-130H (-30) Hercules
Reasoners et al. Faisal Khan
e Lima Development of an Aircraft Health Monitoring Program for Predictive Maintenance
Khan Vehicle level health assessment through integrated operational scalable prognostic reasoners
Koelle et al. Lessons Learned in Implementing a Practical Aircraft System Health Management (ASHM) Syste

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240416