(57)【特許請求の範囲】
【請求項１】
少なくとも１つのプロセッサと、
非一時的コンピュータ可読媒体と、
前記非一時的コンピュータ可読媒体上に保存されたプログラム命令と
を備えるコンピューティングシステムであって、
前記プログラム命令は、前記少なくとも１つのプロセッサによって実行可能であり、前記コンピューティングシステムに、
少なくとも、複数の資産についての履歴動作データに基づいて、（ａ）入力として、資産についてのセンサデータを受信し、（ｂ）一群の故障タイプのうち少なくとも２つの故障タイプのそれぞれについて、前記故障タイプが今後の所与の期間内に前記資産で発生する可能性が高いかどうかのそれぞれの予測をし、（ｃ）それぞれの前記予測に基づいて、前記一群の故障タイプのうち少なくとも１つの故障タイプが、今後の前記所与の期間内に、前記資産で発生する可能性が高いかどうかを示す健全性指標を判定し、および、出力するように構成された予測モデルを定義することであって、前記履歴動作データは、（ｉ）前記一群の故障タイプに関連する、過去の異常状態の発生を示す、前記複数の資産についての履歴異常状態データと、（ｉｉ）過去の異常状態の発生に関連するセンサ測定を示す、前記複数の資産についての履歴センサデータと、を含む、ことと、
所与の資産の動作状態を示すセンサデータを受信することと、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障タイプのうち少なくとも１つの故障タイプが今後の前記所与の期間内に前記所与の資産で発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行することと、
判定された前記健全性指標に基づいて、コンピューティングデバイスに、前記一群の故障タイプのうち少なくとも１つの故障タイプが前記所与の資産で発生する可能性が高いかどうかの視覚的表示を表示させることと、
を行わせる、コンピューティングシステム。
【請求項２】
前記一群の故障タイプは、前記１つまたは複数の故障タイプが発生するときに前記所与の資産を動作不能にし得る１つまたは複数の故障タイプを含む、請求項１に記載のコンピューティングシステム。
【請求項３】
前記所与の資産の前記健全性指標は、（ｉ）前記一群の故障タイプのうちの、いかなる故障タイプも今後の前記所与の期間内に前記所与の資産で発生しない確率、または、（ｉｉ）前記一群の故障タイプのうちの少なくとも１つの故障タイプが今後の前記所与の期間内に前記所与の資産で発生する確率のうち、１つを含む、請求項１または２に記載のコンピューティングシステム。
【請求項４】
コンピューティングシステムに、
少なくとも、複数の資産についての履歴動作データに基づいて、（ａ）入力として、資産についてのセンサデータを受信し、（ｂ）一群の故障タイプのうち少なくとも２つの故障タイプのそれぞれについて、前記故障タイプが今後の所与の期間内に前記資産で発生する可能性が高いかどうかのそれぞれの予測をし、（ｃ）それぞれの前記予測に基づいて、前記一群の故障タイプのうち少なくとも１つの故障タイプが今後の前記所与の期間内に前記資産で発生する可能性が高いかどうかを示す健全性指標を判定し、および、出力するように構成された予測モデルを定義し、前記履歴動作データは、（ｉ）前記一群の故障タイプに関連する、過去の異常状態の発生を示す、前記複数の資産についての履歴異常状態データ、および、（ｉｉ）過去の異常状態の発生に関連するセンサ測定を示す、前記複数の資産についての履歴センサデータを備え、
所与の資産の動作状態を示すセンサデータを受信し、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障タイプのうちの少なくとも１つの故障タイプが今後の前記所与の期間内に前記所与の資産で発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行し、
判定された前記健全性指標に基づいて、コンピューティングデバイスに、前記一群の故障タイプのうち少なくとも１つの故障タイプが前記所与の資産で発生する可能性が高いかどうかの視覚的表示を表示する、
ように機能させるプログラム。
【請求項５】
コンピュータで実装される方法であって、
少なくとも、複数の資産についての履歴動作データに基づいて、（ａ）入力として、資産についてのセンサデータを受信し、（ｂ）一群の故障タイプのうち少なくとも２つの故障タイプのそれぞれについて、前記故障タイプが今後の所与の期間内に前記資産で発生する可能性が高いかどうかのそれぞれの予測をし、（ｃ）それぞれの前記予測に基づいて、前記一群の故障タイプのうちの少なくとも１つの故障タイプが今後の前記所与の期間内に前記資産で発生する可能性が高いかどうかを示す健全性指標を判定し、および、出力するように構成された予測モデルを定義する段階であって、前記履歴動作データは、（ｉ）前記一群の故障タイプに関連する、過去の異常状態の発生を示す、前記複数の資産についての履歴異常状態データ、および、（ｉｉ）過去の異常状態の発生に関連するセンサ測定を示す、前記複数の資産についての履歴センサデータを有する、段階と、
所与の資産の動作状態を示すセンサデータを受信する段階と、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障タイプのうちの少なくとも１つの故障タイプが今後の前記所与の期間内に前記所与の資産で発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行する段階と、
判定された前記健全性指標に基づいて、コンピューティングデバイスに、前記一群の故障タイプのうち少なくとも１つの故障タイプが前記所与の資産で発生する可能性が高いかどうかの視覚的表示を表示させる段階と、
を備える、コンピュータで実装される方法。
【請求項６】
前記所与の資産についての前記健全性指標は、
（ｉ）前記一群の故障タイプのうちの、いかなる故障タイプも、今後の前記所与の期間内に前記所与の資産で発生しない確率、または、
（ｉｉ）前記一群の故障タイプのうちの、少なくとも１つの故障タイプが、今後の前記所与の期間内に、前記所与の資産で発生する確率
のうち１つを有する、請求項５に記載のコンピュータで実装される方法。
【請求項７】
少なくとも１つのプロセッサと、
非一時的コンピュータ可読媒体と、
前記非一時的コンピュータ可読媒体上に保存されたプログラム命令と
を備えるコンピューティングシステムであって、
前記プログラム命令は、前記少なくとも１つのプロセッサによって実行可能であり、前記コンピューティングシステムに、
資産の所与のサブシステムについての一群の故障タイプに関連する、一群の異常状態タイプを識別することと、
識別された前記一群の異常状態タイプに基づいて、複数の資産についての履歴動作データのサブセットを識別することであって、前記履歴動作データは、（ｉ）識別された前記一群の異常状態タイプの過去の発生を示す、前記複数の資産についての履歴異常状態データと、（ｉｉ）識別された前記一群の異常状態タイプの過去の発生に関連するセンサ測定を示す、前記複数の資産についての履歴センサデータとを含む、ことと、
前記履歴動作データの識別された前記サブセットに基づいて、（ａ）入力として、資産についてのセンサデータを受信し、（ｂ）前記所与のサブシステムについての前記一群の故障タイプのうち少なくとも２つの故障タイプのそれぞれについて、前記故障タイプが今後の所与の期間内に前記資産の前記所与のサブシステムで発生する可能性が高いかどうかのそれぞれの予測をし、（ｃ）それぞれの前記予測に基づいて、一群の故障タイプのうちの少なくとも１つの故障タイプが今後の前記所与の期間内に前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を判定し、および、出力するように構成された予測モデルを定義することと、
所与の資産の動作状態を示すセンサデータを受信することと、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障タイプのうちの少なくとも１つの故障タイプが今後の前記所与の期間内に前記所与の資産の前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行することと、
判定された前記健全性指標に基づいて、コンピューティングデバイスに、前記一群の故障タイプのうち少なくとも１つの故障タイプが前記所与の資産の前記サブシステムで発生する可能性が高いかどうかの視覚的表示を表示させることと、
を実行させる、コンピューティングシステム。
【請求項８】
前記所与のサブシステムについての前記一群の故障タイプに関連する前記一群の異常状態タイプを識別することは、
前記所与のサブシステムに関連する１つまたは複数のセンサを識別することと、
前記１つまたは複数のセンサに対応する１つまたは複数の異常状態タイプを識別する、ことと
を有する、請求項７に記載のコンピューティングシステム。
【請求項９】
前記所与のサブシステムに関連する前記１つまたは複数のセンサを識別することは、前記履歴動作データ、および、履歴修理データまたはセンサ属性のうち少なくとも１つに基づいて、前記所与のサブシステムに関連する前記１つまたは複数のセンサを識別することを有する、請求項８に記載のコンピューティングシステム。
【請求項１０】
前記一群の故障タイプは、１つまたは複数の故障タイプが発生するときに前記所与のサブシステムを動作不能にさせ得る、前記１つまたは複数の故障タイプを含む、請求項７から９のいずれか一項に記載のコンピューティングシステム。
【請求項１１】
前記一群の故障タイプのうちの各故障タイプは、前記識別された一群の異常状態タイプのうち少なくとも１つの異常状態タイプに対応する、請求項７から１０のいずれか一項に記載のコンピューティングシステム。
【請求項１２】
コンピューティングシステムに、
資産の所与のサブシステムについての一群の故障タイプに関連する一群の異常状態タイプを識別し、
前記識別された一群の異常状態タイプに基づいて、複数の資産についての履歴動作データのサブセットを識別し、前記履歴動作データは、（ｉ）前記識別された一群の異常状態タイプの過去の発生を示す、前記複数の資産についての履歴異常状態データ、および、（ｉｉ）識別された前記一群の異常状態タイプの過去の発生に関連するセンサ測定を示す、前記複数の資産についての履歴センサデータを含み、
前記履歴動作データの識別された前記サブセットに基づいて、（ａ）入力として、資産についてのセンサデータを受信し、（ｂ）前記所与のサブシステムについての前記一群の故障タイプのうち少なくとも２つの故障タイプのそれぞれについて、前記故障タイプが今後の所与の期間内に前記資産の前記所与のサブシステムで発生する可能性が高いかどうかのそれぞれの予測をし、（ｃ）それぞれの前記予測に基づいて、前記一群の故障タイプのうち少なくとも１つの故障タイプが、今後の前記所与の期間内に前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を判定し、および、出力するように構成された予測モデルを定義し、
所与の資産の動作状態を示すセンサデータを受信することと、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障タイプのうちの少なくとも１つの故障タイプが今後の前記所与の期間内に前記所与の資産の前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行し、
判定された前記健全性指標に基づいて、コンピューティングデバイスに、前記一群の故障タイプのうち少なくとも１つの故障タイプが前記所与の資産の前記所与のサブシステムで発生する可能性が高いかどうかの視覚的表示を表示する、
ように機能させるプログラム。
【請求項１３】
前記所与のサブシステムについての前記一群の故障タイプに関連する一群の異常状態タイプを識別することは、
前記所与のサブシステムに関連する１つまたは複数のセンサの識別することと、
前記１つまたは複数のセンサに対応する１つまたは複数の異常状態タイプを識別することと
を含む、請求項１２に記載のプログラム。
【請求項１４】
前記所与のサブシステムに関連する前記１つまたは複数のセンサを識別することは、前記履歴動作データ、および、履歴修理データまたはセンサ属性のうち少なくとも１つに基づく前記所与のサブシステムに関連する前記１つまたは複数のセンサを識別することを含む、請求項１３に記載のプログラム。
【請求項１５】
前記一群の故障タイプのうちの各故障タイプは、前記識別された一群の異常状態タイプのうち少なくとも１つの異常状態タイプに対応する、請求項１２から１４のいずれか一項に記載のプログラム。
【請求項１６】
前記所与の資産についての判定された前記健全性指標が閾値を下回った場合、前記視覚的表示が変わる、請求項１２から１５のいずれか一項に記載のプログラム。
【請求項１７】
コンピュータで実装される方法であって、
資産の所与のサブシステムについての一群の故障タイプに関連する一群の異常状態タイプを識別する段階と、
前記識別された一群の異常状態タイプに基づいて、複数の資産についての履歴動作データのサブセットを識別する段階であって、前記履歴動作データは、（ｉ）前記識別された一群の異常状態タイプの過去の発生を示す、前記複数の資産についての履歴異常状態データ、および、（ｉｉ）識別された前記一群の異常状態タイプの過去の発生に関連するセンサ測定を示す、前記複数の資産についての履歴センサデータを含む、段階と、
前記履歴動作データの識別された前記サブセットに基づいて、（ａ）入力として、資産についてのセンサデータを受信し、（ｂ）前記所与のサブシステムについての前記一群の故障タイプのうち少なくとも２つの故障タイプのそれぞれについて、前記故障タイプが今後の所与の期間内に前記資産の前記所与のサブシステムで発生する可能性が高いかどうかのそれぞれの予測をし、（ｃ）それぞれの前記予測に基づいて、一群の故障タイプのうちの少なくとも１つの故障タイプが、今後の前記所与の期間内に前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を判定し、および、出力するように構成された予測モデルを定義する段階と、
所与の資産の動作状態を示すセンサデータを受信する段階と、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障タイプのうちの少なくとも１つの故障タイプが今後の前記所与の期間内に前記所与の資産の前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行する段階と、
判定された前記健全性指標に基づいて、コンピューティングデバイスに、前記一群の故障タイプのうち少なくとも１つの故障タイプが前記所与の資産の前記所与のサブシステムで発生する可能性が高いかどうかの視覚的表示を表示させる段階と、
を備えるコンピュータで実装される方法。
【請求項１８】
前記所与のサブシステムについての一群の故障タイプに関連する一群の異常状態タイプを識別する段階は、
前記所与のサブシステムに関連する１つまたは複数のセンサを識別する段階と、
前記１つまたは複数のセンサに対応する１つまたは複数の異常状態タイプを識別する段階と、
を有する、請求項１７に記載のコンピュータで実装される方法。
【請求項１９】
前記所与のサブシステムに関連する前記１つまたは複数のセンサを識別する段階は、前記履歴動作データ、および、履歴修理データまたはセンサ属性のうち少なくとも１つに基づいて、前記所与のサブシステムに関連する前記１つまたは複数のセンサを判定する段階を有する、請求項１８に記載のコンピュータで実装される方法。
【発明の詳細な説明】
【背景技術】
【０００１】
［関連出願の相互参照］
本出願は、（ｉ）２０１４年１２月１日に出願された、「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｄｉｓｐｌａｙｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｒｅｌａｔｅｄ  ｔｏ  Ｉｎｄｕｓｔｒｉａｌ  Ａｐｐｌｉｃａｔｉｏｎ  Ｈｅａｌｔｈ  ａｎｄ  Ｃａｐａｂｉｌｉｔｙ  Ｉｎｆｏｒｍａｔｉｏｎ」と題された、米国仮特許出願第６２／０８６，１５５号、（ｉｉ）２０１４年１２月７日に出願された、「Ｕｐｔａｋｅ  ＋  ＣＡＴ」と題された、米国仮特許出願第６２／０８８，６５１号、（ｉｉｉ）２０１５年６月５日に出願された、「Ａｓｓｅｔ  Ｈｅａｌｔｈ  Ｓｃｏｒｅ」と題された、米国特許出願第１４／７３２，２５８号、（ｉｖ）２０１５年６月５日に出願された、「Ｓｕｂｓｙｓｔｅｍ  Ｈｅａｌｔｈ  Ｓｃｏｒｅ」と題された、米国特許出願第１４／７３２，２８５号、（ｖ）２０１５年６月５日に出願された、「Ｈｉｓｔｏｒｉｃａｌ  Ｈｅａｌｔｈ  Ｍｅｔｒｉｃｓ」と題された、米国特許出願第１４／７３２，３０３号への優先権を主張する。これらは各々、参照によって全体が本明細書に組み込まれる。  現代では多くの業界において、機器（本明細書では「資産（ａｓｓｅｔｓ）」とも呼ぶ）が広く使用される。国々に貨物を輸送する機関車から、命を救う看護師および医者を助ける医療装置まで、資産は日常生活において重要な役割を担っている。資産が担う役割に応じて、その複雑性および費用は異なり得る。例えば、いくつかの資産は、資産が適切に機能するには調和して動作する必要がある複数のサブシステム（例えば、機関車のエンジン、トランスミッションなど）を含み得る。 
【０００２】
資産が日常生活で果たす役割は重要なので、限られたダウンタイムで資産を修理できることが望ましい。従って、おそらくダウンタイムを最低限に抑えながら資産を修理することを容易にするべく、資産内の異常状態を監視および検出するための機構が開発された。
【発明の概要】
【０００３】
資産を監視するための現在の手法は概して、資産全体に分布して資産の動作状態を監視している様々なセンサからの信号を受信する、資産上のコンピュータを伴う。１つの代表例として、資産が機関車である場合、センサは、数ある他の例の中で、温度、電圧、速度などのパラメータを監視し得る。１つまたは複数のセンサからのセンサ信号が一定の値に到達した場合、資産上のコンピュータは次に、異常状態が資産内で発生したという指示である「障害コード」などの異常状態インジケータを生成し得る。実際には、ユーザは通常、センサ、および、各異常状態インジケータに関連するそれぞれのセンサ値を定義する。つまり、ユーザは、資産の「通常」の動作状態（例えば、異常状態インジケータをトリガしない動作状態）、および、「異常」の動作状態（例えば、異常状態インジケータをトリガする動作状態）を定義する。
【０００４】
一般的に、異常状態は、資産、および／または、それらのコンポーネントの故障につながり得る、資産、または、コンポーネントにおける欠陥であり得る。従って、異常状態は１つ（または、おそらく複数）の所与の故障の兆候であるという点で、異常状態は、１つまたは複数の所与の故障に関連し得る。
【０００５】
資産上のコンピュータが異常状態インジケータを生成した後、インジケータおよび／またはセンサ信号は、遠隔地へ渡され得る。ここで、ユーザは異常状態のいくつかの指示を受信して、措置を講じるかどうか決定し得る。いくつかの場合において、ユーザは、異常状態インジケータの原因の診断を容易にするべく、異常状態インジケータに関連するセンサ信号も検討し得る。 
【０００６】
現在の資産監視システムは概して、異常状態インジケータをトリガすることについては有効であるが、そのようなシステムは通常、事後的である。つまり、資産監視システムがインジケータをトリガするときまでに、資産内の故障が既に発生している（または、発生しようとしている）ことがあり得る。このことは、数ある他の短所の中で、損失の大きいダウンタイムにつながり得る。更に、そのような資産監視システムにおける、資産上の異常検出機構の単純な性質に起因して、現在の資産監視手法は、「偽陽性」のインジケータを多く発生させる傾向があるので、これら有意でないインジケータをユーザが検討して応答せざるを得ないとき、非効率的になり得る。
【０００７】
本明細書に開示されている例示的なシステム、デバイス、および方法は、これらの問題のうち１つまたは複数に対処するのを助けることを意図している。いくつかの例において、ネットワーク構成は、１つまたは複数の資産、リモートコンピューティングシステム、１つまたは複数の出力システム、および、１つまたは複数のデータソースの間での通信を容易にする通信ネットワークを含み得る。 
【０００８】
上述のように、各資産は、資産の動作状態の監視を容易にする、資産全体に分布する複数のセンサを含み得る。資産は次に、資産の動作状態を示すデータをリモートコンピューティングシステムに提供し得る。リモートコンピューティングシステムは、提供されたデータに基づいて、１つまたは複数の動作を実行するよう構成され得る。
【０００９】
一態様において、例えば、リモートコンピューティングシステムは、所与の資産の健全性指標（本明細書では「健全性スコア」とも呼ばれる）を判定するよう構成され得る。健全性指標は、今後の一定期間内に所与の資産において故障が発生するかどうかを反映する単一の集計されたパラメータであり得る。例示的な実装において、健全性指標は、一群の故障に含まれるいかなる故障も、所与の資産で発生しない確率を示し得る。他の例示的な実装において、健全性指標は、一群の故障に含まれる少なくとも１つの故障が、所与の資産で発生する確率を示し得る。 
【００１０】
一般的に、健全性指標の判定は、資産の故障を予測するためのモデルを定義するべくリモートコンピューティングシステムが１つまたは複数の資産についての履歴動作データを解析し得る「機械学習」フェーズ、並びに、所与の資産の健全性スコアを判定するべくリモートコンピューティングシステムが所与の資産の現在の動作データ、および、機械学習フェーズにおいて定義されたモデルを使用する資産監視フェーズを伴い得る。
【００１１】
具体的には、機械学習フェーズの間、リモートコンピューティングシステムは、一定時間にわたり、１つまたは複数の資産から動作データを受信するよう構成され得る。動作データは、機関車上のエンジンの動作温度を反映するデータなどのセンサデータを含み得て、また、例えば、資産の「資産上のコンピュータ」によって生成された異常状態インジケータを含み得る。リモートコンピューティングシステムは、このデータに基づいて、従来的に所与の資産で故障を生じさせている、所与の資産の動作状態を示す、１つまたは複数のモデルを判定するよう構成され得る。 
【００１２】
リモートコンピューティングシステムは、資産監視フェーズの間に、機械学習フェーズからのモデル、および、所与の資産からの動作データに基づいて、１つまたは複数の特定の故障が、今後の予め選択された期間内（例えば、次の２週間）に所与の資産で発生し得る確率を判定するよう構成され得る。いくつかの場合において、特定の故障は、「高影響」イベントであり得る。このイベントは、発生するときに、資産を動作不能にさせ得る。判定された故障の確率から、リモートコンピューティングシステムは、予め選択された期間内に故障が発生するかどうかを示す、所与の資産についての、単一の集計された健全性指標を判定し得る。
【００１３】
リモートコンピューティングシステムは、所与の資産の最新の動作状態に基づいて、この健全性指標を動的に更新するよう構成され得る。つまり、資産の実際の動作状態が変化すると、特定の故障のうち１つまたは複数が発生し得る確率（および、従って、健全性指標）は、それに従って変化し得る。
【００１４】
具体的には、リモートコンピューティングシステムは、おそらくリアルタイムに、資産から動作データを受信し得る。リモートコンピューティングシステムは、動作データ、および、判定されたモデルに基づいて、特定の故障のうち１つまたは複数が発生し得る確率を再計算するよう構成され得る。確率が変化した場合、リモートコンピューティングシステムは、それに従って健全性指標を更新し得る。健全性指標を動的に更新するこの処理は、資産の動作可能期間にわたって継続的に発生し得る。 
【００１５】
リモートコンピューティングシステムは更に、健全性指標を使用して複数の措置をトリガするよう構成され得る。いくつかの場合において、例えば、リモートコンピューティングシステムは、おそらく、所与の資産の異常状態インジケータおよび／またはセンサデータと併せて、所与の資産の健全性指標の指示を出力システムに出力させることを容易にし得る。
【００１６】
別の場合において、リモートコンピューティングシステムは、健全性指標に基づいて、アラートを生成するよう構成され得る。例えば、リモートコンピューティングシステムは、健全性指標が健全性閾値に近づいている、または、到達した場合に、アラートメッセージを出力デバイスへ送信し、それにより、出力デバイスに、可視および／または可聴アラートをユーザへ出力させ得るよう構成され得る。他の例もあり得る。
【００１７】
更に別の場合、リモートコンピューティングシステムは、健全性指標を使用して様々な種類の予防的措置をトリガするよう構成され得る。例えば、リモートコンピューティングシステムは、健全性指標が健全性閾値に到達した場合に、健全性指標に影響し得る１つまたは複数の推奨される措置を出力デバイスに表示させることを容易にすること、資産を修理するための作業指示を生成することを容易にすること、資産の部品を注文することを容易にすること、および／または、資産にそれ自体の動作を修正させる１つまたは複数のコマンドを資産へ送信することを行うよう構成され得る。他の予防的措置もあり得る。
【００１８】
所与の資産について、単一の集計された「健全性スコア」を判定することに加えて、または、それに替えて、リモートコンピューティングシステムは、所与の資産のサブシステムそれぞれについても、資産からの動作データに基づいて、個別の健全性スコアを判定するよう構成され得る。個別の健全性スコアの各々は、今後の一定期間内に所与の資産の特定のサブシステムで故障が発生するかどうかを反映する単一の集計されたパラメータを示す。 
【００１９】
リモートコンピューティングシステムは、様々な方式で、所与のサブシステムの個別の健全性スコアを判定するよう構成され得る。例えば、リモートコンピューティングシステムは、所与のサブシステムに固有の動作データに基づいて、所与のサブシステムのための故障モデルを判定し得て、次に、資産レベル健全性指標について上述したものと同様の方式でサブシステム健全性指標を判定し得る。しかしながら、リモートコンピューティングシステムは、他の方式でも、所与のサブシステムの個別の健全性スコアを判定するよう構成され得る。
【００２０】
いくつかの場合において、リモートコンピューティングシステムはまた、所与の資産についての個別のサブシステムレベル健全性指標を使用して、資産レベル健全性指標を判定するよう構成され得る。リモートコンピューティングシステムは、様々な方式で、個別のサブシステムレベル健全性指標に重み付けするよう構成され得る。例えば、リモートコンピューティングシステムは、資産の全体的な動作に対する、対応するサブシステムの相対的な重要度に基づいて、あるサブシステム健全性指標を他と異なる方式で重み付けするよう構成され得る。この結果、資産レベル健全性指標がより正確になり得る。
【００２１】
リモートコンピューティングシステムは、資産レベル健全性指標と同様に、サブシステムレベル健全性指標を動的に更新すること、および、サブシステムレベル健全性指標を使用して、上述のものと同様の措置をトリガするよう構成され得る。しかしながら、サブシステムレベル健全性指標はまた、リモートコンピューティングシステムが、資産レベルの措置と比較して、より粒度が高い、および／または、より多くの措置をトリガすることを可能にし得る。更に、サブシステムレベル健全性指標は、資産レベルでは通常、いくらか後になるまで検出され得ないサブシステムレベルでの異常を検出することによって、より効果的な予防的措置を可能にし得る。
【００２２】
別の態様において、リモートコンピューティングシステムは、１つまたは複数の資産についての資産および／またはサブシステムレベル健全性指標の履歴データを保存するよう構成され得る。この履歴データはその後、様々な目的に使用され得る。 
【００２３】
一例において、リモートコンピューティングシステムは、出力システムに、保存された履歴データに基づいて、様々なビジュアリゼーションを提供させることを容易にするよう構成され得る。例えば、リモートコンピューティングシステムは、出力システムに、所与の資産（または一群の資産）についての、資産および／またはサブシステムレベル健全性指標の履歴のグラフィック表現を、所与の期間にわたって表示させることを容易にするよう構成され得る。 
【００２４】
別の例において、リモートコンピューティングシステムは、健全性指標と、ある資産関連の変数との間の関連を識別するべく、この保存された履歴データについて解析を実行するよう構成され得る。それらの変数には、数ある他の例の中で、資産クラス（例えば、ブランド、モデルなど）、資産に対して作業する整備士、および、資産が動作する環境条件などがある。例えば、リモートコンピューティングシステムは、この保存された履歴データに基づいて、資産のあるクラスが比較的高い健全性指標に関連していること、および／または、資産のある他のクラスが、比較的低い健全性指標に関連していることを判定し得る。別の例として、リモートコンピューティングシステムは、この保存された履歴データに基づいて、ある整備士が資産健全性指標のより大きな改善の原因となっていること、および／または、ある他の整備士が資産健全性指標のより小さな改善の原因となっていることを判定し得る。多くの他の例もあり得る。
【００２５】
例示的な実装において、リモートコンピューティングシステムは、履歴健全性指標の解析に基づいて、数ある他の動作の中で、例えば、特定の作業に資産の特定のクラスを推奨すること、資産修理スケジュールを最適化すること、並びに、特定の問題を修理するのに特定の修理業者および／または整備士を推奨することなど、様々な動作を実行するよう構成され得る。
【００２６】
更に別の態様において、リモートコンピューティングシステムは、１つまたは複数の出力システムからフィードバックデータを受信し、次に、このフィードバックデータに基づいて、インテリジェントに１つまたは複数の動作を実行するよう構成され得る。例えば、上述のように、リモートコンピューティングシステムは、所与の資産のための様々な種類の予防的措置を推奨および／またはトリガするよう構成され得る。この例において、リモートコンピューティングシステムは、予防的措置が資産の故障を成功裏に防止したかどうかを示すフィードバックデータを受信し、次に、このフィードバックデータに基づいて、健全性指標モデル、および／または、健全性指標によってトリガされる措置を更新するよう構成され得る。 
【００２７】
別の例において、上述のように、リモートコンピューティングシステムは、出力システムに、所与の資産についての異常状態インジケータ（例えば、障害コード）を、おそらく、そのようなインジケータに対応する推奨される措置と併せて表示させることを容易にするよう構成され得る。しかしながら、上述のように、従来の資産監視システムは、「偽陽性」（例えば、是正措置を必要とせず、従って、ユーザが注目していない異常状態）のインジケータを生成し得る。これにより、ユーザは有意のインジケータから注意をそらし得て、および／または、インジケータに対するユーザの反応が鈍感になり得る。従って、リモートコンピューティングシステムは、ユーザが特定のインジケータにどのように応答するかに関するフィードバックデータを受信し、次に、ユーザによる資産の操作の改善を助けるべく、あるインジケータが表示される方式をインテリジェントに調節するよう構成され得る。 
【００２８】
例えば、ユーザに異常状態インジケータを提示するとき、出力システムは、ユーザが、（例えば、「無視」アイコンなどを選択することにより）アラートを棄却すること、（例えば、「解決」アイコンなどを選択することにより）アラートに対して措置を講じること、または、（例えば、予め定められた時間にわたって選択を行わないことにより）アラートを放置することを可能にする選択肢をユーザに提示し得る。出力システムは、表示されているインジケータに関するユーザの決定を示すフィードバックデータをリモートコンピューティングシステムに提供するよう構成され得る。次に、リモートコンピューティングシステムは、インジケータとユーザの応答との間の関連（例えば、応答パターン）を識別するべく、おそらく、インジケータを検討している１または複数のユーザについての、そのようなデータについて集計し、解析を実行し得る。
【００２９】
その後、リモートコンピューティングシステムは、応答パターンに基づいて、ある異常状態インジケータが表示される方式を調節し得る。例えば、ユーザが通常、特定の種類のインジケータを無視または放置することを応答パターンが示す場合、リモートコンピューティングシステムは出力デバイスに対して、その種類の任意のインジケータを、この応答パターンに従って処理するよう指示し得る。その処理には、例えば、無視するという推奨を含むインジケータを表示すること、または、単に（即時に、または、ユーザが「無視」の応答を予め定められた回数だけ行った後に）インジケータを抑制することなどがある。
【００３０】
リモートコンピューティングシステムは、異常状態インジケータが表示される方式を調節するよう出力デバイスに指示する前に、インジケータの性質、インジケータに関連するサブシステムなど、他の情報も考慮に入れ得る。例えば、リモートコンピューティングシステムは、いくつかの種類のインジケータが、抑制される前に、より多くの回数の「無視」の応答を必要とし、一方、他の種類のインジケータが、抑制される前に、より少ない回数の「無視」の応答を必要とすることを決定し得る。他の例もあり得る。
【００３１】
上述のように、本明細書には、資産監視に関連する例が提供されている。一態様において、あるコンピューティングシステムが提供される。このコンピューティングシステムは、少なくとも１つのプロセッサと、非一時的コンピュータ可読媒体と、非一時的コンピュータ可読媒体に保存されたプログラム命令であって、コンピューティングシステムに様々な作業を実行させるべく、少なくとも１つのプロセッサによって実行可能なプログラム命令とを備える。
【００３２】
一実施形態によれば、プログラム命令は、少なくとも１つのプロセッサによって実行可能であり得て、コンピューティングシステムに、（ａ）資産の動作状態のうち少なくとも１つを示すセンサデータを参照時間に受信すること、（ｂ）受信されたセンサデータおよび履歴動作データに基づいて、一群の故障のうちの故障が参照時間後の一定期間内に資産で発生するかどうかを示す健全性指標を判定することであって、履歴動作データは、（ｉ）過去に資産で発生した故障に関連する履歴異常状態データ、および、（ｉｉ）過去における資産の動作状態のうち少なくとも１つを示す履歴センサデータを含むこと、ならびに、（ｃ）判定された健全性指標の表現をコンピューティングデバイスに表示させることを容易にするべく、判定された健全性指標を示す健全性指標データをコンピューティングデバイスへ送信することを実行させる。
【００３３】
別の実施形態によれば、プログラム命令は、少なくとも１つのプロセッサによって実行可能であり得て、コンピューティングシステムに、（ａ）少なくとも履歴動作データに基づいて、資産のサブシステムに関連する少なくとも１つの異常状態インジケータを判定することであって、履歴動作データは、（ｉ）過去にサブシステムで発生した故障に関連する履歴異常状態データ、および、（ｉｉ）過去におけるサブシステムの動作状態のうち少なくとも１つを示す履歴センサデータを含む、こと、（ｂ）サブシステムの少なくとも１つの動作状態を示すセンサデータを参照時間に受信すること、（ｃ）（ｉ）受信されたセンサデータ、（ｉｉ）判定された少なくとも１つの異常状態インジケータ、および、（ｉｉｉ）履歴動作データに基づいて、一群の故障のうちの故障が参照時間後の一定期間内にサブシステムで発生するかどうかを示す健全性指標を判定すること、ならびに、（ｄ）判定された健全性指標の表現をコンピューティングデバイスに表示させることを容易にするべく、判定された健全性指標を示す健全性指標データをコンピューティングデバイスへ送信することを実行させる。 
【００３４】
更に別の実施形態によれば、プログラム命令は、少なくとも１つのプロセッサによって実行可能であり得て、コンピューティングシステムに、（ａ）複数の動作データに基づいて、複数の資産に対応する複数の健全性指標を判定することであって、一群の故障のうちの故障が一定期間内に所与の資産で発生するかどうかを所与の健全性指標が示すこと、（ｂ）少なくとも複数の健全性指標に基づいて、閾値を超える健全性指標に関連する少なくとも１つの変数を判定すること、（ｃ）判定された少なくとも１つの変数に基づいて、複数の資産のうち、健全性指標が閾値より低い１つまたは複数の資産を識別すること、ならびに、（ｄ）推奨の表現をコンピューティングデバイスに表示させることを容易にするべく、少なくとも１つの変数に関する推奨、および、識別された１つまたは複数の資産を示す推奨データをコンピューティングデバイスへ送信することを実行させる。 
【００３５】
プログラム命令は、少なくとも１つのプロセッサによって実行可能であり得て、コンピューティングシステムに、様々な他の機能も実行させる。 
【００３６】
別の態様において、本明細書には、コンピューティングシステムに様々な作業を実行させるべく実行可能な命令が自身に保存されている非一時的コンピュータ可読媒体が提供されている。
【００３７】
一実施形態によれば、非一時的コンピュータ可読媒体は、自身に保存されている命令を含み得て、それらの命令はコンピューティングシステムに、（ａ）資産の動作状態のうち少なくとも１つを示すセンサデータを参照時間に受信すること、（ｂ）受信されたセンサデータおよび履歴動作データに基づいて、一群の故障のうちの故障が参照時間後の一定期間内に資産で発生するかどうかを示す健全性指標を判定することであって、履歴動作データは、（ｉ）過去に資産で発生した故障に関連する履歴異常状態データ、および、（ｉｉ）過去における資産の動作状態のうち少なくとも１つを示す履歴センサデータを含む、こと、（ｃ）判定された健全性指標の表現をコンピューティングデバイスに表示させることを容易にするべく、判定された健全性指標を示す健全性指標データをコンピューティングデバイスへ送信することを行わせるべく実行可能である。 
【００３８】
別の実施形態によれば、非一時的コンピュータ可読媒体は、自身に保存されている命令を含み得て、それらの命令はコンピューティングシステムに、（ａ）少なくとも履歴動作データに基づいて、資産のサブシステムに関連する少なくとも１つの異常状態インジケータを判定することであって、履歴動作データは、（ｉ）過去にサブシステムで発生した故障に関連する履歴異常状態データ、および、（ｉｉ）過去におけるサブシステムの動作状態のうち少なくとも１つを示す履歴センサデータを含む、こと、（ｂ）サブシステムの少なくとも１つの動作状態を示すセンサデータを参照時間に受信すること、（ｃ）（ｉ）受信されたセンサデータ、（ｉｉ）判定された少なくとも１つの異常状態インジケータ、および、（ｉｉｉ）履歴動作データに基づいて、一群の故障のうちの故障が参照時間後の一定期間内にサブシステムで発生するかどうかを示す健全性指標を判定すること、（ｄ）判定された健全性指標の表現をコンピューティングデバイスに表示させることを容易にするべく、判定された健全性指標を示す健全性指標データをコンピューティングデバイスへ送信することを行わせるべく実行可能である。
【００３９】
更に別の実施形態によれば、非一時的コンピュータ可読媒体は、自身に保存されている命令を含み得て、それらの命令はコンピューティングシステムに、（ａ）複数の動作データに基づいて、複数の資産に対応する複数の健全性指標を判定することであって、一群の故障のうちの故障が一定期間内に所与の資産で発生するかどうかを所与の健全性指標が示すこと、（ｂ）少なくとも複数の健全性指標に基づいて、閾値を超える健全性指標に関連する少なくとも１つの変数を判定すること、（ｃ）判定された少なくとも１つの変数に基づいて、複数の資産のうち、健全性指標が閾値より低い１つまたは複数の資産を識別すること、ならびに、（ｄ）推奨の表現をコンピューティングデバイスに表示させることを容易にするべく、少なくとも１つの変数に関する推奨、および、識別された１つまたは複数の資産を示す推奨データをコンピューティングデバイスへ送信することを行わせるべく実行可能である。
【００４０】
非一時的コンピュータ可読媒体は、コンピューティングシステムに様々な他の機能も実行させるべく実行可能である、自身に保存された命令を有し得る。 
【００４１】
更に別の態様において、本明細書には、コンピュータで実装される方法が提供されている。そのようなコンピュータで実装される方法の１つは、（ａ）資産の動作状態のうち少なくとも１つを示すセンサデータを参照時間に受信する段階と、（ｂ）受信されたセンサデータおよび履歴動作データに基づいて、一群の故障のうちの故障が参照時間後の一定期間内に資産で発生するかどうかを示す健全性指標を判定する段階であって、履歴動作データは、（ｉ）過去に資産で発生した故障に関連する履歴異常状態データ、および、（ｉｉ）過去における資産の動作状態のうち少なくとも１つを示す履歴センサデータとを含む、段階と、（ｃ）判定された健全性指標の表現をコンピューティングデバイスに表示させることを容易にするべく、判定された健全性指標を示す健全性指標データをコンピューティングデバイスへ送信する段階とを含み得る。 
【００４２】
別のコンピュータで実装される方法は、（ａ）少なくとも履歴動作データに基づいて、資産のサブシステムに関連する少なくとも１つの異常状態インジケータを判定する段階であって、履歴動作データは、（ｉ）過去にサブシステムで発生した故障に関連する履歴異常状態データ、および、（ｉｉ）過去におけるサブシステムの動作状態のうち少なくとも１つを示す履歴センサデータを含む、段階と、（ｂ）サブシステムの少なくとも１つの動作状態を示すセンサデータを参照時間に受信する段階こと、（ｃ）（ｉ）受信されたセンサデータ、（ｉｉ）判定された少なくとも１つの異常状態インジケータ、および、（ｉｉｉ）履歴動作データに基づいて、一群の故障のうちの故障が参照時間後の一定期間内にサブシステムで発生するかどうかを示す健全性指標を判定する段階と、（ｄ）判定された健全性指標の表現をコンピューティングデバイスに表示させることを容易にするべく、判定された健全性指標を示す健全性指標データをコンピューティングデバイスへ送信する段階とを含み得る。 
【００４３】
更に別のコンピュータで実装される方法は、（ａ）複数の動作データに基づいて、複数の資産に対応する複数の健全性指標を判定する段階であって、所与の健全性指標が、一群の故障のうちの故障が一定期間内に所与の資産で発生するかどうか示す段階と、（ｂ）少なくとも複数の健全性指標に基づいて、閾値を超える健全性指標に関連する少なくとも１つの変数を判定する段階と、（ｃ）判定された少なくとも１つの変数に基づいて、複数の資産のうち、健全性指標が閾値より低い１つまたは複数の資産を識別する段階と、（ｄ）推奨の表現をコンピューティングデバイスに表示させることを容易にするべく、少なくとも１つの変数に関する推奨、および、識別された１つまたは複数の資産を示す推奨データをコンピューティングデバイスへ送信する段階とを含み得る。 コンピュータで実装される方法は、様々な他の形態もとり得る。 
【００４４】
当業者は、以下の開示も読むことによって、これらの態様、および、他の多くの態様を理解するであろう。
【図面の簡単な説明】
【００４５】
【図１】例示的な実施形態が実装され得る例示的なネットワーク構成を図示する。
【図２】例示的な資産の簡略化されたブロック図を図示する。
【図３】例示的な異常状態インジケータおよびセンサ基準の概念図を図示する。
【図４】例示的な解析システムの簡略化されたブロック図を図示する。
【図５Ａ】健全性指標の判定に使用され得るモデリングフェーズの例示的なフローチャートを図示する。
【図５Ｂ】健全性スコアの判定に使用され得る資産監視フェーズの例示的なフローチャートを図示する。
【図６】モデルを定義するのに利用されるデータの概念図を図示する。
【図７】健全性スコアの表現を示す例示的なグラフィカルユーザインタフェースを図示する。
【図８Ａ】異常状態インジケータの例示的な可視指示を図示する。
【図８Ｂ】異常状態インジケータの別の例示的な可視指示を図示する。
【図９】履歴健全性スコアの表現を示す例示的なグラフィカルユーザインタフェースを図示する。
【図１０】変数を判定するための例示的なフローチャートを図示する。
【図１１】変数カウンタをインクリメントさせた結果のデータの概念図を図示する。
【図１２】健全性スコアを判定するための例示的な方法のフローチャートを図示する。
【図１３】資産のサブシステムのための健全性スコアを判定するための例示的な方法のフローチャートを図示する。
【図１４】高い健全性スコアに関連する変数に基づいて推奨を行うための例示的な方法のフローチャートを図示する。
【図１５】通常は異常状態インジケータを生じさせる動作データの処理を修正するための例示的な方法のフローチャートを図示する。
【発明を実施するための形態】
【００４６】
以下の開示は、添付の図、および、複数の例示的シナリオを参照する。当業者であれば、その参照は、単に説明のみを目的としたものであり、従って、限定を意味するものではないことを理解するであろう。開示されているシステム、デバイス、および、方法の一部または全部は、様々な方式で、並び替え、組み合わせ、追加、および／または、削除が行われ得て、その各々は、本明細書において想定されている。
［１．例示的なネットワーク構成］
【００４７】
ここで、図面を参照する。図１は、例示的な実施形態が実装され得る例示的なネットワーク構成１００を図示する。示されているように、ネットワーク構成１００は、１つまたは複数の資産１０２、通信ネットワーク１０４、解析システムの形態を取り得るリモートコンピューティングシステム１０６、１つまたは複数の出力システム１０８、および、１つまたは複数のデータソース１１０を備える。
【００４８】
通信ネットワーク１０４は、ネットワーク構成１００内のコンポーネントの各々と通信可能に接続し得る。例えば、資産１０２は、通信ネットワーク１０４を介して、解析システム１０６と通信し得る。いくつかの場合において、資産１０２は、解析システム１０６と通信する、クライアントサーバ（図示せず）などの１つまたは複数の仲介システムと通信し得る。同様に、解析システム１０６は、通信ネットワーク１０４を介して、出力システム１０８と通信し得る。いくつかの場合において、解析システム１０６は、出力システム１０８と通信する、ホストサーバ（図示せず）などの１つまたは複数の仲介システムと通信し得る。多くの他の構成もあり得る。
【００４９】
一般的に、資産１０２は、１つまたは複数の動作を実行するよう構成された（分野に基づいて定義され得る）任意のデバイスの形態をとり得て、また、資産１０２の１つまたは複数の動作状態を示すデータを送信するよう構成されている装置を含み得る。いくつかの例において、資産１０２は、１つまたは複数のそれぞれの動作を実行するよう構成された、１つまたは複数のサブシステムを含み得る。実際には、資産１０２が動作するために、複数のサブシステムは、並列に、または、順次に動作し得る。
【００５０】
例示的な資産には、数ある他の例の中で、輸送機器（例えば、機関車、航空機、セミトレーラートラック、船舶など）、工業機器（例えば、採掘装置、建設装置など）、医療機器（例えば、医療画像装置、手術装置、医療監視システム、医学研究装置など）、および、公共設備用機器（例えば、タービン、ソーラーファームなど）が含まれ得る。当業者であれば、これらは、資産のわずかな例に過ぎず、他の多くの例があり得て、それらも本明細書において想定されていることを理解するであろう。
【００５１】
例示的な実装において、図１に示されている資産１０２はすべて、同一の種類（例えば、数ある他の例の中で、一団の機関車もしくは航空機、一群の風力タービン、一組のＭＲＩ機器など）であり得て、おそらく、同一のクラス（例えば、同一のブランドおよび／またはモデル）であり得る。他の例において、図１に示されている資産１０２は、種類、ブランド、モデルなどが異なり得る。資産１０２は、図２を参照しながら、以下で更に詳細に記載されている。
【００５２】
示されているように、資産１０２、および、おそらく他のデータソース１１０は、通信ネットワーク１０４を介して解析システム１０６と通信し得る。一般的に、通信ネットワーク１０４は、ネットワークコンポーネントの間でデータを伝送することを容易にするよう構成されている１つまたは複数のコンピューティングシステムおよびネットワークインフラストラクチャを含み得る。通信ネットワーク１０４は、有線および／もしくは無線であり得る１つまたは複数のワイドエリアネットワーク（ＷＡＮ）、ならびに／または、ローカルエリアネットワーク（ＬＡＮ）であり得るか、または、それらを含み得る。いくつかの例において、通信ネットワーク１０４は、数ある他のネットワークの中で、１つまたは複数のセルラーネットワークおよび／またはインターネットを含み得る。通信ネットワーク１０４は、ＬＴＥ（登録商標）、ＣＤＭＡ、ＷｉＭａｘ（登録商標）、ＷｉＦｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＨＴＴＰ、ＴＣＰなど、１つまたは複数の通信プロトコルに従って動作し得る。通信ネットワーク１０４は単一のネットワークとして示されているが、通信ネットワーク１０４は、互いに通信可能に接続されている複数の別個のネットワークを含み得ることを理解するべきである。通信ネットワーク１０４は、他の形態もとり得る。
【００５３】
上述のように、解析システム１０６は、資産１０２およびデータソース１１０からデータを受信するよう構成され得る。概して、解析システム１０６は、データを受信、処理、解析、出力するよう構成された、サーバおよびデータベースなどの１つまたは複数のコンピューティングシステムを含み得る。解析システム１０６は、数ある他の例の中で、．ＮＥＴ（登録商標）またはＮｉｆｉ（登録商標）など、所与のデータフロー技術に従って構成され得る。解析システム１０６は、図３を参照しながら、以下で更に詳細に記載されている。
【００５４】
示されているように、解析システム１０６は、データを資産１０２、および／または、出力システム１０８へ送信するよう構成され得る。資産１０２および／または出力システム１０８へ送信される特定のデータは、様々な形態をとり得て、以下で更に詳細に説明される。
【００５５】
一般的に、出力システム１０８は、データを受信して、ある形態の出力を提供するよう構成されているコンピューティングシステムまたはデバイスの形態をとり得る。出力システム１０８は、様々な形態をとり得る。一例において、出力システム１０８のうち１つまたは複数は、データを受信し、データに応答して、可聴、可視、および／もしくは、触覚的出力を提供するよう構成されている出力デバイスであり得、または、それを含み得る。一般的に、出力デバイスは、ユーザ入力を受信するよう構成されている１つまたは複数の入力インタフェースを含み得て、出力デバイスは、当該ユーザ入力に基づき、通信ネットワーク１０４を通してデータを送信するよう構成され得る。出力デバイスの例には、タブレット、スマートフォン、ラップトップコンピュータ、他のモバイルコンピューティングデバイス、デスクトップコンピュータ、スマートテレビなどが含まれる。
【００５６】
出力システム１０８の別の例は、資産を修理するべく、整備士などへの依頼を出力するよう構成されている作業指示システムの形態をとり得る。出力システム１０８の更に別の例は、資産の部品を発注し、それらの受領書を出力するよう構成されている部品注文システムの形態をとり得る。多くの他の出力システムもあり得る。
【００５７】
１つまたは複数のデータソース１１０は、解析システム１０６と通信するよう構成され得る。一般的に、データソース１１０は、解析システム１０６によって実行される機能に関連し得るデータを収集、保存し、および／または、解析システム１０６など他のシステムへ提供するよう構成されている１つまたは複数のコンピューティングシステムであり得るか、または、それらを含み得る。データソース１１０は、資産１０２から独立してデータを生成および／または取得するよう構成され得る。従って、データソース１１０によって提供されるデータは、本明細書において、「外部データ」と呼ばれ得る。データソース１１０は、現在のデータおよび／または履歴データを提供するよう構成され得る。実際には、解析システム１０６は、データソースによって提供されるサービスに「加入」することによって、データソース１１０からのデータを受信し得る。しかしながら、解析システム１０６は、他の方式でもデータソース１１０からデータを受信し得る。
【００５８】
データソース１１０の例は、環境データソース、資産管理データソース、および、他のデータソースを含む。一般的に、環境データソースは、資産が動作する環境のいくつかの特性を示すデータを提供する。環境データソースの例には、数ある他の例の中で、所与の領域の自然な、および人工的な特徴に関する情報を提供する、天気データサーバ、全球測位衛星システム（ＧＮＳＳ）サーバ、地図データサーバ、および、地形データサーバを含む。
【００５９】
一般的に、資産管理データソースは、資産の動作またはメンテナンス（例えば、資産がいつ、どこで、動作し得るか、または、メンテナンスを受け得るかなど）に影響し得る、イベント、または業者の状態を示すデータを提供する。資産管理データソースの例には、数ある他の例の中で、航空交通、水上交通、および／または、陸上交通に関する情報を提供する交通データサーバと、特定の日付および／もしくは特定の時間における、資産の予期される経路ならびに／または場所に関する情報を提供する資産スケジュールサーバと、欠陥検出器システム（「軸焼け」検出器とも呼ばれる）の付近を通過する資産の１つまたは複数の動作状態に関する情報を提供する欠陥検出器システムと、特定の供給業者が在庫として有する部品およびそれらの価格に関する情報を提供する部品供給業者サーバと、修理業者の能力などに関する情報を提供する修理業者サーバとが含まれる。
【００６０】
他のデータソースの例には、数ある他の例の中で、電気消費量に関する情報を提供する送電網サーバ、および、資産の履歴動作データを保存する外部データベースが含まれる。当業者であれば、これらはデータソースのわずかな例に過ぎないこと、および、多くの他の例があり得ることを理解するであろう。
【００６１】
ネットワーク構成１００は、本明細書に記載の実施形態が実装され得るネットワークの一例であることを理解すべきである。多くの他の配置が可能であり、それらは本明細書において想定されている。例えば、他のネットワーク構成は、図示されていない追加のコンポーネントを含み得て、および／または、図示されているコンポーネントが追加または省略され得る。
［２．例示的な資産］
【００６２】
図２において、例示的な資産２００の簡略化されたブロック図が図示されている。資産２００は、図１の資産１０２の１つであり得る。示されているように、資産２００は、１つまたは複数のサブシステム２０２、１つまたは複数のセンサ２０４、処理ユニット２０６、データストレージ２０８、１つまたは複数のネットワークインタフェース２１０、１つまたは複数のユーザインタフェース２１２を含み得て、これらはすべて、システムバス、ネットワーク、または、他の接続機構によって、通信可能に接続され得る。当業者であれば、資産２００は、示されていない追加のコンポーネントを含み得て、および／または、図示されているコンポーネントが追加もしくは省略され得ることを理解するであろう。
【００６３】
概して、資産２００は、１つまたは複数の動作を実行するよう構成されている、１つまたは複数の電気的、機械的、および／または、電気機械的コンポーネントを含み得る。いくつかの場合において、１つまたは複数のコンポーネントは、所与のサブシステム２０２へとグループ化され得る。 
【００６４】
概して、サブシステム２０２は、資産２００の一部である、関連する一群のコンポーネントを含み得る。単一のサブシステム２０２は、独立して１つまたは複数の動作を実行し得るか、または、単一のサブシステム２０２は、１つまたは複数の他のサブシステムと共に動作して、１つまたは複数の動作を実行し得る。通常、種類が異なる資産、および、種類が同一でクラスが異なる資産でも、異なるサブシステムを含み得る。例えば、輸送資産の文脈において、サブシステム２０２の例には、多くの他の例の中で、エンジン、トランスミッション、ドライブトレイン、燃料システム、バッテリシステム、排気システム、ブレーキシステム、電気システム、信号処理システム、発電機、ギアボックス、ロータ、油圧システムなどが含まれ得る。
【００６５】
上述のように、資産２００は、資産２００の動作状態を監視するよう構成されている様々なセンサ２０４が装着され得る。いくつかの場合において、センサ２０４のいくつかは、特定のサブシステム２０２に基づいてグループ化され得る。このようにして、センサ２０４の群は、特定のサブシステム２０２の動作状態を監視するよう構成され得る。
【００６６】
一般的に、センサ２０４は、資産２００の１つまたは複数の動作状態を示し得る物理的特性を検出し、検出された物理的特性の、電気信号などの指示を提供するよう構成され得る。動作中、センサ２０４は、継続的に、（例えば、サンプリング周波数に基づいて）周期的に、および／または、いくつかのトリガイベントに応答して、測定結果を取得するよう構成され得る。いくつかの例において、センサ２０４は、測定を実行するための動作パラメータで事前に構成され得て、および／または、処理ユニット２０６によって提供される動作パラメータ（例えば、測定結果を取得するようセンサ２０４に指示するサンプリング信号）に従って測定を実行し得る。例において、異なるセンサ２０４は、異なる動作パラメータを有し得る（例えば、いくつかのセンサは、第１周波数に基づいてサンプリングし得て、他のセンサは、異なる第２周波数に基づいてサンプリングし得る）。いずれの場合も、センサ２０４は、測定された物理的特性を示す電気信号を処理ユニット２０６へ送信するよう構成され得る。センサ２０４は、そのような信号を継続的または周期的に処理ユニット２０６へ提供し得る。
【００６７】
例えば、センサ２０４は、資産２００の場所および／または動きなどの物理的特性を測定するよう構成され得る。この場合、センサは、ＧＮＳＳセンサ、デッドレコニング式センサ、加速度計、ジャイロスコープ、歩数計、磁気計などの形態をとり得る。
【００６８】
追加的に、様々なセンサ２０４は、資産２００の他の動作状態を測定するよう構成され得る。動作状態の例には、数ある他の例の中で、温度、圧力、速度、摩擦、電力使用量、燃料使用量、液面レベル、走行時間、電圧および電流、磁界、電界、発電量などが含まれ得る。当業者であれば、これらは、センサが測定するよう構成され得る動作状態のわずかな例に過ぎないことを理解するであろう。産業上の用途または特定の資産に応じて、より多くのセンサ、または、より少ないセンサが使用され得る。
【００６９】
処理ユニット２０６は、汎用または専用のプロセッサの形態をとり得る、１つまたは複数のプロセッサを含み得る。プロセッサの例には、マイクロプロセッサ、特定用途向け集積回路、デジタル信号プロセッサなどが含まれ得る。一方、データストレージ２０８は、数ある他の例の中で、光学メモリ、磁気メモリ、有機メモリ、または、フラッシュメモリなどの１つまたは複数の非一時的コンピュータ可読記憶媒体であり得るか、それらを含み得る。 
【００７０】
処理ユニット２０６は、本明細書に記載されている資産の動作を実行するべく、コンピュータ可読プログラム命令をデータストレージ２０８内に保存し、データストレージ２０８内に保存されたコンピュータ可読プログラム命令にアクセスして実行するよう構成され得る。例えば、上述のように、処理ユニット２０６は、センサ２０４からそれぞれのセンサ信号を受信するよう構成され得る。処理ユニット２０６は、センサデータをデータストレージ２０８内に保存し、後でそれにアクセスするよう構成され得る。
【００７１】
処理ユニット２０６はまた、障害コードなど、受信されたセンサ信号がいずれかの異常状態インジケータをトリガするかどうか判定するよう構成され得る。例えば、処理ユニット２０６は、データストレージ２０８内に、異常状態ルール（例えば、障害コードルール）を保存するよう構成され得る。異常状態ルールの各々は、特定の異常状態を表す所与の異常状態インジケータ、および、異常状態インジケータをトリガするそれぞれのセンサ基準を含む。つまり、各異常状態インジケータは、異常状態インジケータがトリガされる前に満たされる必要がある１つまたは複数のセンサ測定値に対応する。実際には、資産２００は、異常状態ルールで事前にプログラムされ得て、および／または、解析システム１０６などのコンピューティングシステムから、新しい異常状態ルール、もしくは、既存のルールに対する更新を受信し得る。 
【００７２】
いずれの場合も、処理ユニット２０６は、受信されたセンサ信号がいずれかの異常状態インジケータをトリガするかどうかを判定するよう構成され得る。つまり、処理ユニット２０６は、受信されたセンサ信号がいずれかのセンサ基準を満たすかどうか判定し得る。そのような判定が肯定的であるとき、処理ユニット２０６は、異常状態データを生成し得て、また、資産のユーザインタフェース２１２に、可視および／または可聴アラートなど、異常状態の指示を出力させ得る。追加的に、処理ユニット２０６は、おそらくタイムスタンプで、異常状態インジケータの発生をデータストレージ２０８内に記録し得る。 
【００７３】
図３は、資産についての例示的な異常状態インジケータおよびそれぞれのセンサ基準の概念図を図示する。具体的には、図３は、例示的な障害コードの概念図を図示する。示されているように、表３００は、センサＡ、Ｂ、Ｃにそれぞれ対応する、列３０２、３０４、３０６を含み、障害コード１、２、３にそれぞれ対応する、行３０８、３１０、３１２を含む。次に、エントリ３１４は所与の障害コードに対応するセンサ基準（例えば、センサ閾値）を指定する。
【００７４】
例えば、障害コード１は、センサＡが１３５回転／分（ｒｐｍ）より高い回転の測定結果を検出したとき、および、センサＣが摂氏６５度（℃）より高い温度の測定結果を検出したときにトリガされ、障害コード２は、センサＢが１０００ボルト（Ｖ）より高い電圧の測定結果を検出したとき、および、センサＣが摂氏５５度より低い温度の測定結果を検出したときにトリガされ、障害コード３は、センサＡが１００ｒｐｍより高い回転の測定結果を検出したとき、センサＢが７５０Ｖより高い電圧の測定結果を検出したとき、および、センサＣが摂氏６０度より高い温度の測定結果を検出したときにトリガされる。当業者であれば、図３は、単に例および説明の目的で提供されていること、ならびに、多くの他の障害コードおよび／またはセンサ基準があり得て、それらが本明細書において想定されていることを理解するであろう。
【００７５】
再び図２を参照すると、処理ユニット２０６は、資産２００の動作を管理および／または制御するための様々な追加的な機能も実行するよう構成され得る。例えば、処理ユニット２０６は、サブシステム２０２および／またはセンサ２０４にいくつかの動作（スロットル位置またはセンサのサンプリングレートの修正など）を実行させる命令信号をサブシステム２０２および／またはセンサ２０４へ提供するよう構成され得る。更に、処理ユニット２０６は、サブシステム２０２、センサ２０４、ネットワークインタフェース２１０、および／または、ユーザインタフェース２１２から信号を受信し、そのような信号に基づいて、動作を発生させるよう構成され得る。処理ユニット２０６の他の機能は以下に記載されている。 
【００７６】
１つまたは複数のネットワークインタフェース２１０は、資産２００と、通信ネットワーク１０４に接続された様々なネットワークコンポーネントとの間の通信を提供するよう構成され得る。例えば、少なくとも１つのネットワークインタフェース２１０は、通信ネットワーク１０４との間の無線通信を容易にするよう構成され得て、従って、アンテナ構造、ならびに、様々な無線信号を送信および受信するための関連する装置の形態をとり得る。他の例もあり得る。実際には、１つまたは複数のネットワークインタフェース２１０は、上述したいずれかのものなどの通信プロトコルに従って構成され得る。
【００７７】
１つまたは複数のユーザインタフェース２１２は、資産２００とのユーザインタラクションを容易にするよう構成され得て、また、資産２００に、ユーザインタラクションに応答して動作を実行させることを容易にするよう構成され得る。ユーザインタフェース２１２の例には、数ある他の例の中で、感圧式インタフェース、機械的インタフェース（例えば、レバー、ボタン、ホイール、ダイアル、キーボードなど）、および、他の入力インタフェース（例えば、マイク）が含まれる。いくつかの場合において、１つまたは複数のユーザインタフェース２１２は、表示画面、スピーカ、ヘッドフォンジャックなどの出力コンポーネントへの接続機能を含み得るか、または、それらを提供し得る。
【００７８】
当業者であれば、図２に示されている資産２００は、資産の簡略化された表現の一例に過ぎないこと、および、多くの他の例もあり得ることを理解するであろう。例えば、いくつかの例において、資産は、センサからセンサ信号を取得するよう構成されているデータ取得システムを含み得る。データ取得システムは、資産の動作を制御する中央制御部（処理ユニット２０６など）から独立して動作する。
［３．例示的な解析システム］
【００７９】
ここで、図４を参照すると、例示的な解析システム４００の簡略化されたブロック図が図示されている。上述のように、解析システム４００は、本明細書に記載の様々な動作を実行するべく通信可能に接続および配置されている１つまたは複数のコンピューティングシステムを有し得る。具体的には、示されているように、解析システム４００は、データ取得システム４０２、データサイエンスシステム４０４、および、１つまたは複数のデータベース４０６を有し得る。これらのシステムコンポーネントは、１つまたは複数の無線および／または有線接続を介して通信可能に連結され得る。
【００８０】
データ取得システム４０２は概して、データを受信および処理し、データサイエンスシステム４０４へデータを出力するように機能し得る。従って、データ取得システム４０２は、複数の異なる資産１０２および／またはデータソース１１０など、ネットワーク構成１００の様々なネットワークコンポーネントからデータを受信するよう構成されている、１つまたは複数のネットワークインタフェースを備え得る。具体的には、データ取得システム４０２は、数ある他の例の中で、アナログ信号、データストリーム、および／または、ネットワークパケットを受信するよう構成され得る。従って、ネットワークインタフェースは、ポートなど、１つまたは複数の有線ネットワークインタフェース、および／または、上述したものと同様の無線ネットワークインタフェースを含み得る。いくつかの例において、データ取得システム４０２は、Ｎｉｆｉ（登録商標）受信機などの所与のデータフロー技術に従って構成されているコンポーネントであり得るか、それらを含み得る。
【００８１】
データ取得システム４０２は、１つまたは複数の動作を実行するよう構成されている１つまたは複数の処理コンポーネントを有し得る。例示的な動作には、数ある他の動作の中で、圧縮および／または展開、暗号化および／または復号、アナログ‐デジタルおよび／またはデジタル‐アナログ変換、フィルタ処理、増幅などが含まれ得る。更に、データ取得システム４０２は、データ型および／またはデータの特性に基づいて、データを解析、ソート、編成、および／または、ルーティングするよう構成され得る。いくつかの例において、データ取得システム４０２は、データサイエンスシステム４０４の１つまたは複数の特性または動作パラメータに基づいて、データをフォーマットし、パッケージ化し、および／または、ルーティングするよう構成され得る。
【００８２】
一般的に、データ取得システム４０２によって受信されるデータは、様々な形態をとり得る。例えば、データのペイロードは、単一のセンサ測定結果、複数のセンサ測定結果、および／または、１つもしくは複数の障害コードを含み得る。他の例もあり得る。
【００８３】
更に、受信データは、ソース識別子、および、タイムスタンプ（例えば、情報が取得された日付および／または時間）など、ある特性を含み得る。例えば、一意識別子（例えば、コンピュータによって生成された、英字、数字、英数字などの識別子）が各資産に、および、おそらく、各センサに割り当てられ得る。そのような識別子は、データの発生元である資産またはセンサを識別するように動作可能であり得る。いくつかの場合において、別の特性には、情報が取得された場所（例えば、ＧＰＳ座標）が含まれ得る。データ特性は、数ある他の例の中で、信号署名またはメタデータなどの形態をとり得る。
【００８４】
データサイエンスシステム４０４は概して、データを（例えば、データ取得システム４０２から）受信し、解析し、そのような解析に基づいて、１つまたは複数の動作を発生させるように機能し得る。従って、データサイエンスシステム４０４は、１つまたは複数のネットワークインタフェース４０８、処理ユニット４１０、データストレージ４１２を含み得る。これらはすべて、システムバス、ネットワーク、または、他の接続機構によって、通信可能に接続され得る。いくつかの場合において、データサイエンスシステム４０４は、本明細書に開示されている機能のいくつかを実行することを容易にする１つまたは複数のアプリケーションプログラムインタフェース（ＡＰＩ）を保存し、および／または、それにアクセスするよう構成され得る。
【００８５】
ネットワークインタフェース４０８は、上述のいずれかのネットワークインタフェースと同一または同様であり得る。実際には、ネットワークインタフェース４０８は、データサイエンスシステム４０４と、データ取得システム４０２、データベース４０６、資産１０２、出力システム１０８など、様々な他の実体との間の通信を容易にし得る。
【００８６】
処理ユニット４１０は、上述のプロセッサのいずれかなど、１つまたは複数のプロセッサを有し得る。一方、データストレージ４１２は、上述の例のいずれかなど、１つまたは複数の非一時的コンピュータ可読記憶媒体であり得るか、それらを含み得る。処理ユニット４１０は、本明細書に記載の解析システムの動作を実行するべく、データストレージ４１２内に保存されたコンピュータ可読プログラム命令の保存、アクセス、および実行を行うよう構成され得る。
【００８７】
一般的に、処理ユニット４１０は、データ取得システム４０２から受信されたデータの解析を実行するよう構成され得る。この目的で、処理ユニット４１０は、１つまたは複数のモジュールを実行するよう構成され得る。各モジュールは、データストレージ４１２内に保存されたプログラム命令の１つまたは複数の組の形態をとり得る。モジュールは、それぞれのプログラム命令の実行に基づいて結果を発生させることを容易にするよう構成され得る。所与のモジュールからの例示的な結果には、数ある他の例の中で、別のモジュールへデータを出力すること、所与のモジュールおよび／または別のモジュールのプログラム命令を更新すること、資産１０２および／または出力システム１０８へ送信するべくデータをネットワークインタフェース４０８へ出力することが含まれ得る。
【００８８】
データベース４０６は概して、データを（例えば、データサイエンスシステム４０４から）受信し、保存するよう機能し得る。従って、各データベース４０６は、上述の例のいずれかなどの１つまたは複数の非一時的コンピュータ可読記憶媒体を有し得る。実際には、データベース４０６は、データストレージ４１２とは別であり得るか、または、データストレージ４１２に組み込まれ得る。
【００８９】
データベース４０６は、多くの種類のデータを保存するよう構成され得る。それらのいくつかは、以下に記載されている。実際には、データベース４０６内に保存されているデータのいくつかは、データが生成された、または、データベースへ追加された日付および時間を示すタイムスタンプを含み得る。更に、データは、複数の方式でデータベース４０６内に保存され得る。例えば、データは、数ある他の例の中で、表形式で時系列に保存され得て、および／または、データソースの種類に基づいて（例えば、資産、資産の種類、センサ、または、センサの種類に基づいて）、もしくは、障害コードに基づいて編成され得る。
［４．例示的な動作］
【００９０】
ここで、図１に図示されている、例示的なネットワーク構成１００の動作は、以下で更に詳細に記載される。これらの動作のいくつかを説明することを助けるべく、実行され得る動作の組み合わせを説明するフローチャートが参照され得る。いくつかの場合において、各ブロックは、処理における特定の論理的な機能またはステップを実装するべくプロセッサによって実行可能な命令を含むプログラムコードのモジュールまたは部分を表し得る。プログラムコードは、非一時的コンピュータ可読媒体など、いずれかの種類のコンピュータ可読媒体上に保存され得る。他の場合において、各ブロックは、処理における特定の論理的な機能またはステップを実行するべく配線されている回路を表し得る。更に、フローチャートにおいて示されているブロックは、特定の実施形態に基づいて、異なる順序に並び替えられ得て、より少ないブロックへと組み合わせられ得て、追加のブロックへと分けられ得て、および／または、削除され得る。
【００９１】
以下の記載は、資産２００などの単一のデータソースが、データを解析システム４００へ提供し、解析システム４００が次に、１つまたは複数の機能を実行する例を参照し得る。これは限定を意味するものでなく、単に、明確性および説明のために行われることを理解するべきである。実際には、解析システム４００は概して、複数のソースからデータを受信し、そのような集計された受信データに基づいて、おそらく同時に、動作を実行する。
［Ａ．動作データの収集］
【００９２】
上述のように、代表的な資産２００は、様々な形態をとり得て、複数の動作を実行するよう構成され得る。非限定的な例において、資産２００は、米国各地で貨物を輸送するように動作可能な機関車の形態をとり得る。輸送中、センサ２０４は、資産２００の１つまたは複数の動作状態を反映するセンサデータを取得し得る。センサ２０４は、センサデータを処理ユニット２０６へ送信し得る。
【００９３】
処理ユニット２０６は、センサ２０４からセンサデータを受信するよう構成され得る。実際には、処理ユニット２０６は、センサデータを複数のセンサから同時に、または、順次に受信し得る。上述のように、センサデータを受信している間、処理ユニット２０６はまた、センサデータが、障害コードなどのいずれかの異常状態インジケータをトリガするセンサ基準を満たすかどうか判定するよう構成され得る。１つまたは複数の異常状態インジケータがトリガされることを処理ユニット２０６が判定した場合、処理ユニット２０６は、ユーザインタフェース２１２を介して、トリガされるインジケータの指示を出力するなど、１つまたは複数のローカル動作を実行するよう構成され得る。
【００９４】
処理ユニット２０６は次に、ネットワークインタフェース２１０の１つ、および、通信ネットワーク１０４を介して、資産２００についての動作データを解析システム４００へ送信するよう構成され得る。例えば、資産２００は、継続的に、周期的に、および／または、トリガイベント（例えば、障害コード）に応答して、解析システム４００へ動作データを送信し得る。具体的には、資産２００は、特定の頻度（例えば、毎日、毎時間、１５分ごと、毎分、毎秒など）に基づいて、周期的に動作データを送信し得て、または、資産２００は、動作データの継続的なリアルタイムのフィードを送信するよう構成され得る。追加的または代替的に、資産２００は、センサ２０４からのセンサ測定結果がいずれかの異常状態インジケータのセンサ基準を満たすときなど、あるトリガに基づいて、動作データを送信するよう構成され得る。資産２００は、他の方式でも動作データを送信し得る。
【００９５】
実際には、資産２００の動作データは、センサデータおよび／または異常状態データを含み得る。いくつかの実装において、資産２００は、単一のデータストリーム内で動作データを提供するよう構成され得て、他の実装では、資産２００は、複数の異なるデータストリーム内で動作データを提供するよう構成され得る。例えば、資産２００は、解析システム４００に対して、センサデータである第１データストリーム、および、異常状態データである第２データストリームを提供し得る。他の可能性も存在する。
【００９６】
センサデータは、様々な形態をとり得る。例えばある時には、センサデータはセンサ２０４の各々によって取得された測定結果を含み得る。一方、他のときには、センサデータはセンサ２０４のサブセットによって取得された測定結果を含み得る。
【００９７】
具体的には、センサデータは、所与のトリガされた異常状態インジケータに関連するセンサによって取得された測定結果を含み得る。例えば、トリガされた障害コードが図３の障害コード１である場合、センサデータは、センサＡおよびＣによって取得された未処理の測定結果を含み得る。追加的または代替的に、センサデータは、トリガされた障害コードに直接関連していない１つまたは複数のセンサによって取得された測定結果を含み得る。引き続き、この最後の例において、センサデータは追加的に、センサＢおよび／または他のセンサによって取得された測定結果を含み得る。いくつかの例において、処理ユニット２０６は、例えば、センサＢが測定しているものと、障害コード１がそもそもトリガされる原因となったものとの間に関連があるかどうかを判定し得た解析システム４００によって提供される障害コードルールまたは命令に基づいて、特定のセンサデータを動作データ内に含み得る。他の例もあり得る。
【００９８】
更に、センサデータは、複数の因子に基づいて選択され得る、注目している特定の時間に基づいて、注目している各センサからの１つまたは複数のセンサ測定結果を含み得る。いくつかの例において、注目している特定の時間は、サンプリングレートに基づき得る。他の例において、注目している特定の時間は、異常状態インジケータがトリガされる時間に基づき得る。
【００９９】
具体的には、センサデータは、異常状態インジケータがトリガされる時間に基づいて、注目している各センサ（例えば、トリガされる障害コードに直接的および間接的に関連するセンサ）からの、１つまたは複数のそれぞれのセンサ測定結果を含み得る。１つまたは複数のセンサ測定結果は、トリガされる異常状態インジケータの時間の前後における、特定の数の測定結果、または、特定の期間に基づき得る。
【０１００】
例えば、トリガされる障害コードが図３の障害コード２である場合、注目しているセンサは、センサＢおよびＣを含み得る。１つまたは複数のセンサ測定結果は、障害コードのトリガ（例えば、トリガとなる測定結果）より前にセンサＢおよびＣによって取得された最新のそれぞれの測定結果、または、トリガとなる測定結果の前、後、もしくは、ほぼそのときの測定結果のそれぞれの組を含み得る。例えば、５つの測定結果の組は、数ある他の可能性の中で、（ａ）トリガとなる測定結果の前もしくは後の（例えば、トリガとなる測定結果を除く）５つの測定結果、（ｂ）トリガとなる測定結果の前もしくは後の４つの測定結果およびトリガとなる測定結果、または、（ｃ）トリガとなる測定結果の前の２つの測定結果、後の２つの測定結果、およびトリガとなる測定結果を含み得る。
【０１０１】
センサデータと同様に、異常状態データは、様々な形態をとり得る。一般的に、異常状態データは、資産２００で発生し得るすべての他の異常状態から、資産２００で発生した特定の異常状態を一意に識別するよう動作可能なインジケータを含み得るか、そのような形態をとり得る。異常状態インジケータは、数ある他の例の中で、英字、数字、または、英数字の識別子の形態をとり得る。更に、異常状態インジケータは、数ある他の例の中で、「エンジンの過熱」または「燃料切れ」など、異常状態を記述する文字列の形態をとり得る。
【０１０２】
解析システム４００、および、具体的には、データ取得システム４０２は、資産２００などの、１つもしくは複数の資産、および／または、データソースから、動作データを受信するよう構成され得る。データ取得システム４０２は、受信データに対して１つまたは複数の動作を実行して、次に、そのデータをデータサイエンスシステム４０４へ中継するよう構成され得る。次に、データサイエンスシステム４０４は、受信データを解析し得て、当該解析に基づいて、１つまたは複数の動作を実行し得る。
［Ｂ．健全性スコア］
【０１０３】
一例として、データサイエンスシステム４０４は、単一の集計された指標である、資産の「健全性スコア」を判定するよう構成され得る。これは、今後の所与の時間枠内（例えば、次の２週間）に資産で故障が発生するかどうかを示す。具体的には、例示的な実装において、健全性スコアは、一群の故障のうちいかなる故障も今後の所与の時間枠内に資産で発生しない可能性を示し得るか、または、健全性スコアは、一群の故障のうち少なくとも１つの故障が今後の所与の時間枠内に資産で発生する可能性を示し得る。
【０１０４】
実際には、データサイエンスシステム４０４はまた、健全性指標の望ましい粒度に応じて、異なるレベルの健全性指標を判定するよう構成され得る。例えば、データサイエンスシステム４０４は、資産全体としての健全性指標（すなわち、資産レベル健全性指標）を判定し得る。別の例として、データサイエンスシステム４０４は、資産の１つまたは複数のサブシステム各々について、それぞれの健全性指標（すなわち、サブシステムレベル健全性指標）を判定し得る。これらはまた、資産レベル健全性指標を生成するべく、組み合わされ得る。他の例もあり得る。 
【０１０５】
一般的に、健全性指標の判定は、２つのフェーズを伴い得る。すなわち、（１）故障が発生する可能性を予測するためのモデルをデータサイエンスシステム４０４が定義する、「モデリング」フェーズと、（２）データサイエンスシステム４０４が、機械学習フェーズにおいて定義されたモデル、および、所与の資産についての動作データを利用して、所与の資産の健全性指標を判定する、資産監視フェーズである。
【０１０６】
図５Ａは、健全性指標を判定するのに使用され得るモデリングフェーズの１つの可能な例を図示するフローチャート５００である。例示の目的で、データサイエンスシステム４０４によって実行されている、例示的なモデリングフェーズが記載されているが、このモデリングフェーズは、他のシステムによっても実行され得る。当業者であれば、フローチャート５００は明確性および説明のために提供されているものであること、および、健全性指標を判定するのに多くの他の動作の組み合わせが利用され得ることを理解するであろう。
【０１０７】
図５Ａに示されているように、ブロック５０２において、データサイエンスシステム４０４は、健全性指標の基礎を形成する１つまたは複数の故障（すなわち、注目している故障）の組を定義することから開始し得る。実際には、その１つまたは複数の故障は、発生した場合に資産（または、それらのサブシステム）が動作不能となり得る故障であり得る。データサイエンスシステム４０４は、定義された故障の組に基づいて、今後の所与の時間枠内（例えば、次の２週間）に故障のいずれかが発生する可能性を予測するためのモデルを定義するステップを行い得る。
【０１０８】
具体的には、ブロック５０４において、データサイエンスシステム４０４は、故障の組のうち、所与の故障の過去の発生を識別するべく、１つまたは複数の資産の群の履歴動作データを解析し得る。ブロック５０６において、データサイエンスシステム４０４は、識別された、所与の故障の過去の発生の各々に関連する動作データ（例えば、所与の故障の発生前の所与の時間枠におけるセンサデータ）のそれぞれの組を識別し得る。ブロック５０８において、データサイエンスシステム４０４は、（１）動作指標の所与の組の値と、（２）今後の所与の時間枠内（例えば、次の２週間）に所与の故障が発生する可能性との間の関係（例えば、故障モデル）を定義するべく、所与の故障の過去の発生に関連する、識別された動作データの組を解析し得る。最後に、ブロック５１０において、定義された組における各故障についての定義された関係（例えば、個別の故障モデル）が、故障の発生の全体的な可能性を予測するためのモデルへと組み合わされ得る。
【０１０９】
データサイエンスシステム４０４が１つまたは複数の資産の群についての更新された動作データを受信し続ける間、データサイエンスシステム４０４はまた、更新された動作データに対してステップ５０４‐５１０を繰り返すことで、定義された１つまたは複数の故障の組についての予測モデルを改良し続け得る。
【０１１０】
ここで、図５Ａに示されている例示的なモデリングフェーズの機能を更に詳細に記載する。上述のように、データサイエンスシステム４０４は、最初にブロック５０２において、健全性指標の基礎を形成する１つまたは複数の故障の組を定義することから開始し得る。データサイエンスシステム４０４は、様々な方式で、この機能を実行し得る。 
【０１１１】
一例において、１つまたは複数の故障の組は、１つまたは複数のユーザ入力に基づき得る。具体的には、データサイエンスシステム４０４は、ユーザによって操作される、出力システム１０８などのコンピューティングシステムから、ユーザによる１つまたは複数の故障の選択を示す入力データを受信し得る。従って、１つまたは複数の故障の組は、ユーザによって定義され得る。
【０１１２】
他の例において、１つまたは複数の故障の組は、データサイエンスシステム４０４による判定に基づき得る。具体的には、データサイエンスシステム４０４は、１つまたは複数の故障の組を定義するよう構成され得て、それは複数の方式で発生し得る。
【０１１３】
例えば、データサイエンスシステム４０４は、資産２００の１つまたは複数の特性に基づいて故障の組を定義するよう構成され得る。つまり、ある故障は、資産の種類、クラスなど、資産のある特性に対応し得る。例えば、資産の各種類および／またはクラスは、注目している故障をそれぞれ有し得る。 
【０１１４】
別の場合において、データサイエンスシステム４０４は、データベース４０６に保存されている履歴データ、および／または、データソース１１０によって提供される外部データに基づいて、故障の組を定義するよう構成され得る。例えば、データサイエンスシステム４０４は、そのようなデータを利用することで、数ある他の例の中で、どの故障が最長の修理時間を生じさせるか、および／または、従来的に、どの故障の後に更なる故障が続くかを判定し得る。
【０１１５】
更に他の例において、１つまたは複数の故障の組は、ユーザ入力と、データサイエンスシステム４０４による判定との組み合わせに基づいて定義され得る。他の例もあり得る。
【０１１６】
ブロック５０４において、データサイエンスシステム４０４は、所与の故障の過去の発生を識別するべく、故障の組のうちの故障の各々について、１つまたは複数の資産の群の履歴動作データ（例えば、障害コードデータ）を解析し得る。１つまたは複数の資産の群は、資産２００などの単一の資産、または、一団の資産など、同一もしくは同様の種類の複数の資産を含み得る。データサイエンスシステム４０４は、数ある他の例の中で、一定時間に相当する（例えば、１か月に相当する）データ、または、一定数のデータ点（例えば、最新の千のデータ点）など、特定の量の履歴動作データを解析し得る。
【０１１７】
実際には、所与の故障の過去の発生を識別することは、データサイエンスシステム４０４が、異常状態データなど、所与の故障を示す動作データの種類を識別することを伴い得る。一般的に、所与の故障は、障害コードなど、１つまたは複数の異常状態インジケータに関連し得る。つまり、所与の故障が発生するとき、１つまたは複数の異常状態インジケータがトリガされ得る。従って、異常状態インジケータは、所与の故障の基礎となる兆候を反映し得る。
【０１１８】
所与の故障を示す動作データの種類を識別後、データサイエンスシステム４０４は、複数の方式で、所与の故障の過去の発生を識別し得る。例えば、データサイエンスシステム４０４は、データベース４０６内に保存された履歴動作データから、所与の故障に関連するインジケータに対応する異常状態データを発見し得る。発見された異常状態データの各々は、所与の故障の発生を示すであろう。データサイエンスシステム４０４は、この発見された異常状態データに基づいて、過去の故障が発生した時間を識別し得る。 
【０１１９】
ブロック５０６において、データサイエンスシステム４０４は、所与の故障の識別された過去の発生の各々に関連する動作データのそれぞれの組を識別し得る。具体的には、データサイエンスシステム４０４は、所与の故障の、所与の発生の時間の前後における一定の時間枠からセンサデータの組を識別し得る。例えば、データの組は、故障の所与の発生の前、後、または、ほぼそのときの特定の時間枠（例えば、２週間）からのものであり得る。他の場合において、データの組は、故障の所与の発生の前、後、または、ほぼ発生したときにおける、一定数のデータ点から識別され得る。
【０１２０】
例示的な実装において、動作データの組は、センサ２０４のいくつか、またはすべてからのセンサデータを含み得る。例えば、動作データの組は、所与の故障に対応する障害コードに関連する、センサからのセンサデータを含み得る。
【０１２１】
図６では、例示の目的で、モデルの定義を容易にするべくデータサイエンスシステム４０４が解析し得る履歴動作データの概念図を図示する。プロット６００は、センサ２０４のいくつか（例えば、センサＡおよびセンサＢ）、または、すべてを発生元とする履歴センサデータの一部に対応し得る。示されているように、プロット６００は、ｘ軸６０２上の時間、ｙ軸６０４上のセンサ測定値、ならびに、センサＡに対応するセンサデータ６０６、および、センサＢに対応するセンサデータ６０８を含む。センサデータの各々は、特定の時点Ｔｉにおけるセンサ測定結果を表す様々なデータ点を含む。更に、プロット６００は、過去であるＴｆに発生した故障の発生６１０の指示（例えば、「故障時間」）、および、故障の発生の前の時間長ΔＴの指示６１２を含み、ここから、動作データの組が識別される。従って、Ｔｆ−ΔＴは、注目しているデータ点の時間枠６１４を定義する。 
【０１２２】
図５Ａに戻ると、データサイエンスシステム４０４が、所与の故障の所与の発生（例えば、Ｔｆにおける発生）についての動作データの組を識別した後、データサイエンスシステム４０４は、動作データの組が識別されるべき故障の発生が何か残っているかどうか判定し得る。発生が残っている場合、ブロック５０６が、残っている発生の各々について繰り返される。
【０１２３】
その後、ブロック５０８において、データサイエンスシステム４０４は、（１）動作指標の所与の組（例えば、センサ測定結果の所与の組）と、（２）今後の所与の時間枠内（例えば、次の２週間）に所与の故障が発生する可能性との間の関係（例えば、故障モデル）を定義するべく、所与の故障の過去の発生に関連する識別された動作データの組を解析し得る。つまり、所与の故障モデルは、１つまたは複数のセンサからセンサ測定結果を入力として取得し得て、所与の故障が今後の所与の時間枠内に発生する確率を出力し得る。 
【０１２４】
一般的に、故障モデルは、資産２００の動作状態と、故障発生の可能性との間の関係を定義し得る。いくつかの実装において、故障モデルは、センサ２０４からの未処理のデータ信号に加えて、センサ信号から導かれる、複数の他のデータ入力（特徴とも呼ばれる）を受信し得る。そのような特徴には、故障が発生したときの、測定されたセンサ値履歴の平均または範囲と、故障の発生より前に測定されたセンサ値履歴の勾配（例えば、センサ測定結果の変化の割合）の平均または範囲と、故障の間の期間（例えば、故障の第１の発生と、故障の第２の発生との間の時間長またはデータ点の数）と、および／または、故障が発生したほぼそのときのセンサ測定結果のトレンドを示す１つまたは複数の故障パターンとが含まれ得る。当業者であれば、これらは、センサ信号から導かれ得る特徴のわずかな例に過ぎないこと、および、多くの他の特徴があり得ることを理解するであろう。 
【０１２５】
実際には、故障モデルは、複数の方式で定義され得る。例示的な実装において、データサイエンスシステム４０４は、ランダムフォレスト技法、ロジスティック回帰技法、または、他の回帰技法など、０から１の間の確率を返す、１つまたは複数のモデリング技法を利用することで、故障モデルを定義し得る。
【０１２６】
特定の例において、故障モデルを定義することは、データサイエンスシステム４０４が、ブロック５０６において識別された履歴動作データに基づいて、応答変数（ｒｅｓｐｏｎｓｅ  ｖａｒｉａｂｌｅ）を生成することを伴い得る。具体的には、データサイエンスシステム４０４は、特定の時点で受信されたセンサ測定結果の各組についての関連する応答変数を判定し得る。従って、応答変数は、故障モデルに関連するデータセットの形態をとり得る。
【０１２７】
応答変数は、センサ測定結果の所与の組が、ブロック５０６で判定された時間枠のいずれかに含まれるかどうか示し得る。つまり、応答変数は、センサデータの所与の組が、ほぼ故障の発生のときの、注目している時間からのものであるかどうかを反映し得る。応答変数は、２進値の応答変数であり得て、それにより、センサ測定結果の所与の組が、判定された時間枠のいずれかに含まれる場合、関連する応答変数は、１の値を割り当てられ、そうでない場合、関連する応答変数は、０の値を割り当てられる。
【０１２８】
再び図６において、応答変数ベクトルＹｒｅｓの概念図がプロット６００に示されている。示されているように、時間枠６１４内にあるセンサ測定の組に関連する応答変数（例えば、時間Ｔｉ＋３からＴｉ＋８のＹｒｅｓ）は、１の値を有し、時間枠６１４の外にあるセンサ測定の組に関連する応答変数（例えば、時間ＴｉからＴｉ＋２、および、Ｔｉ＋９からＴｉ＋１０のＹｒｅｓ）は、０の値を有する。他の応答変数もあり得る。 
【０１２９】
引き続き、応答変数に基づいて故障モデルを定義する特定の例において、データサイエンスシステム４０４は、ブロック５０６で識別された履歴動作データ、および、生成された応答変数で故障モデルをトレーニングし得る。データサイエンスシステム４０４は次に、このトレーニング処理に基づいて、入力として様々なセンサデータを受信し、応答変数を生成するのに使用された時間枠と同等の一定期間内に故障が発生する確率を０から１までの範囲で出力する、故障モデルを定義し得る。
【０１３０】
いくつかの場合において、ブロック５０６で識別された履歴動作データによるトレーニング、および、生成された応答変数は、各センサについて、変数重要度の統計値を生じさせ得る。所与の変数重要度の統計値は、所与の故障が今後のある期間内に発生する確率に対するセンサの相対的な影響を示し得る。
【０１３１】
追加的または代替的に、データサイエンスシステム４０４は、コックス比例ハザード技法など、１つまたは複数の生存解析技法に基づいて、故障モデルを定義するよう構成され得る。データサイエンスシステム４０４は、上述のモデリング技法といくつかの点で同様である生存解析技法を利用し得るが、データサイエンスシステム４０４は、最後の故障から、次に予期されるイベントまでの時間長を示す、生存時間応答変数を判定し得る。次に予期されるイベントは、センサ測定結果の受信、または、故障の発生のうち、いずれか最初に発生する方であり得る。この応答変数は、センサ測定結果が受信される、特定の時点の各々に関連する値の対を含み得る。次に、今後の所与の時間枠内に故障が発生する確率を判定するべく、応答変数が利用され得る。
【０１３２】
いくつかの例示的な実装において、故障モデルは部分的に、数ある他のデータの中で、天気データおよび／または「軸焼け」データなどの外部データに基づいて定義され得る。例えば、故障モデルは、そのようなデータに基づいて、出力される故障の確率を増加または減少させ得る。 
【０１３３】
実際には、外部データは、センサ２０４が測定結果を取得する時間と同一でない時点に観測され得る。例えば、「軸焼け」データが収集される時間（例えば、軸焼けセンサが装着された線路の区間を機関車が通過する時間）は、センサ測定時間と一致しないことがあり得る。そのような場合、データサイエンスシステム４０４は、センサ測定時間に対応する時間に観測される外部データ観測結果を判定するべく、１つまたは複数の動作を実行するよう構成され得る。 
【０１３４】
具体的には、データサイエンスシステム４０４は、センサ測定時間に対応する時間の外部データ値を生成するべく、外部データ観測を補間するのに、外部データ観測の時間、および、センサ測定の時間を利用し得る。外部データの補間は、外部データ観測、または、それらから導かれた特徴を、入力として故障モデルへ含めることを可能にし得る。実際には、数ある他の例の中で、最近隣補間、線形補間、多項式補間、スプライン補間など、様々な技法が、センサデータで外部データを補間するのに使用され得る。
【０１３５】
再び図５Ａにおいて、データサイエンスシステム４０４が、ブロック５０２で定義された故障の組のうち、所与の故障の故障モデルを判定した後で、データサイエンスシステム４０４は、故障モデルが判定されるべきである、故障が何か残っているかどうか判定し得る。故障モデルが判定されるべきである故障が残っている場合、データサイエンスシステム４０４は、ブロック５０４−５０８のループを繰り返し得る。いくつかの実装において、データサイエンスシステム４０４は、ブロック５０２で定義される故障のすべてを包含する、単一の故障モデルを判定し得る。他の実装において、データサイエンスシステム４０４は、資産の各サブシステムの故障モデルを判定し得る。この故障モデルは次に、資産レベルの故障モデルを判定するのに利用され得る（更なる説明については以下を参照）。他の例もあり得る。
【０１３６】
最後に、ブロック５１０において、定義された組（例えば、個別の故障モデル）における各故障について定義された関係が組み合わされ得て、今後の所与の時間枠内（例えば、次の２週間）に故障が発生する全体的な可能性を予測するためのモデル（例えば、健全性指標モデル）となる。つまり、モデルは入力としてセンサ測定を１つまたは複数のセンサから受信し、故障の組のうち少なくとも１つの故障が今後の所与の時間枠内に発生する単一の確率を出力する。 
【０１３７】
データサイエンスシステム４０４は、複数の方式で健全性指標モデルを定義し得るが、その方式は、健全性指標の望ましい粒度に依存し得る。つまり、複数の故障モデルが存在する場合、故障モデルの結果は、複数の方式で、健全性指標モデルの出力を取得するのに利用され得る。例えば、データサイエンスシステム４０４は、複数の故障モデルから、最大値、中央値、平均値を判定し得て、その判定された値を健全性指標モデルの出力として利用する。
【０１３８】
他の例において、健全性指標モデルを判定することは、データサイエンスシステム４０４が、個別の故障モデルによって出力される個別の確率に重み付けすることを伴い得る。例えば、故障の組のうちの各故障は、等しく望ましくないと見なされ得て、従って、健全性指標モデルを判定するとき、各確率は同様に、同一の重み付けが行われ得る。他の例において、いくつかの故障は、他より望ましくない（例えば、より破局的、または、より長い修理時間を必要とするなど）と見なされ得て、従って、それらの対応する確率は、他より大きな重み付けが行われ得る。
【０１３９】
更に他の例において、健全性指標モデルの判定は、データサイエンスシステム４０４が、回帰技法など、１つまたは複数のモデリング技法を利用することを伴い得る。具体的には、データサイエンスシステム４０４は、個別の故障モデル、および、集計応答変数によって出力される確率に対して回帰分析を行い得る。集計応答変数は、個別の故障モデルの各々からの応答変数（例えば、図６のＹｒｅｓ）の論理和（論理ＯＲ）の形態をとり得る。例えば、ブロック５０６で判定されたいずれかの時間枠（例えば、図６の時間枠６１４）内に発生するセンサ測定のいずれかの組に関連する集計応答変数は、１の値を有し得て、一方で、いずれの時間枠についても、それらの外で発生するセンサ測定の組に関連する集計応答変数は、０の値を有し得る。健全性指標モデルを定義する他の方式もあり得る。 
【０１４０】
いくつかの実装において、ブロック５１０は不要であり得る。例えば、上述のように、データサイエンスシステム４０４は、単一の故障モデルを判定し得る。この場合、健全性指標モデルは、単一の故障モデルであり得る。
【０１４１】
実際には、データサイエンスシステム４０４は、個別の故障モデルおよび／または全体的な健全性指標モデルを更新するよう構成され得る。データサイエンスシステム４０４は、毎日、毎週、毎月などの頻度でモデルを更新し得て、資産２００からの、または、他の資産（例えば、資産２００と同一の一団における他の資産）からの履歴動作データの新しい部分に基づいて、これを行い得る。他の例もあり得る。
【０１４２】
次に、図５Ｂは、健全性指標の判定に使用され得る資産監視フェーズのあり得る一例を図示する、フローチャート５２０である。例示の目的で、データサイエンスシステム４０４によって実行されるときの、例示的な資産監視フェーズが記載されているが、この資産監視フェーズは、他のシステムによっても実行され得る。当業者であれば、フローチャート５２０は明確性および説明のために提供されているものであること、および、健全性指標を判定するのに、動作および機能の多くの他の組み合わせが利用され得ることを理解するであろう。
【０１４３】
図５Ｂに示されているように、ブロック５２２において、データサイエンスシステム４０４は、所与の資産の現在の動作状態を反映するデータを受信し得る。ブロック５２４において、データサイエンスシステム４０４は、モデリングフェーズ中に定義されたモデルへ入力されることになる動作データの組を、受信データから識別し得る。ブロック５２６において、データサイエンスシステム４０４は次に、識別された動作データの組をモデルへ入力し得て、これにより、次に、今後の所与の時間枠内（例えば、次の２週間）に故障が発生する全体的な可能性を判定および出力する。最後に、ブロック５２８において、データサイエンスシステム４０４は、この可能性を健全性指標へ変換し得る。
【０１４４】
データサイエンスシステム４０４が、更新された、所与の資産の動作データを受信し続ける間、データサイエンスシステム４０４はまた、更新された動作データに基づいてブロック５２２−５２８の動作を繰り返すことによって、所与の資産の健全性指標を更新し続け得る。いくつかの場合において、データサイエンスシステム４０４が新しいデータを受信するたびに、または、周期的（例えば、毎日、毎週、毎月など）に、ブロック５２２−５２８の動作が繰り返され得る。このようにして、資産が動作中で、使用されているときに、解析システム４００は、健全性指標を、おそらくリアルタイムに、動的に更新するよう構成され得る。
【０１４５】
ここで、図５Ｂに図示されている、例示的な「資産監視」フェーズの機能を更に詳細に記載する。ブロック５２２において、データサイエンスシステム４０４は、所与の資産の現在の動作状態を反映するデータを受信し得る。具体的には、データ取得システム４０２は、次にデータサイエンスシステム４０４へ渡される資産２００についての動作データを受信し得る。例示的な実装において、動作データは、少なくとも、センサ２０４のうち１つまたは複数からのセンサデータを含み得るが、異常状態データを含まない。他の実装において、動作データは、それら両方を含み得る。いくつかの例において、データサイエンスシステム４０４はまた、データソース１１０から、資産２００の現在の動作に関連する外部データを受信し得る。
【０１４６】
ブロック５２４において、データサイエンスシステム４０４は、モデリングフェーズ中に定義された健全性指標モデルへ入力されることになる動作データの組を、受信データから識別し得る。この動作は、複数の方式で実行され得る。
【０１４７】
一例において、データサイエンスシステム４０４は、資産の種類または資産クラスなど、健全性指標が判定されている所与の資産の特性に基づいて、モデルのための、動作データ入力の組（例えば、注目している特定のセンサからのセンサデータ）を識別し得る。いくつかの場合において、動作データ入力の識別された組は、所与の資産のセンサのいくつか、または、すべてからのセンサデータであり得る。
【０１４８】
別の例において、データサイエンスシステム４０４は、図５Ａのブロック５０２で定義された故障の組に基づいて、モデルのための動作データ入力の組を識別し得る。具体的には、データサイエンスシステム４０４は、故障の組のうちの故障に関連する異常状態インジケータをすべて識別し得る。データサイエンスシステム４０４は、識別された、これらのインジケータの各々について、所与のインジケータに関連するセンサを識別し得る。データサイエンスシステム４０４は、識別されたセンサの各々からのセンサデータを含めるように、動作データ入力を設定し得る。動作データ入力の組の識別には、他の例もあり得る。
【０１４９】
ブロック５２６において、データサイエンスシステム４０４は次に、健全性指標モデルを実行し得る。具体的には、データサイエンスシステム４０４は、動作データの識別された組をモデルへ入力し得て、モデルは次に、今後の所与の時間枠内（例えば、次の２週間）に少なくとも１つの故障が発生する全体的な可能性を判定して出力する。
【０１５０】
いくつかの実装において、この動作は、データサイエンスシステム４０４が、図５Ａのブロック５０８で定義された特定の動作データ（例えば、センサデータ）を１つまたは複数の故障モデルへ入力することを伴い得る。当該動作データの各々は、個別の確率を出力し得る。データサイエンスシステム４０４は次に、今後の所与の時間枠内に故障が発生する全体的な可能性を判定するべく、おそらく、健全性指標モデルに従って、いくつかを他のものより大きく重み付けして、これら個別の確率を使用し得る。
【０１５１】
最後に、ブロック５２８において、データサイエンスシステム４０４は、故障が発生する確率を、いかなる故障も今後の所与の時間枠内（例えば、２週間）に資産で発生しない可能性を反映する、単一の集計されたパラメータの形態をとり得る健全性スコアへ変換し得る。例示的な実装において、故障の確率を健全性指標へ変換することは、データサイエンスシステム４０４が故障の確率の余事象を判定することを伴い得る。具体的には、全体的な故障の確率は、０から１までの範囲の値の形態をとり得る。健全性指標は、１からその数を引くことによって判定され得る。故障の確率を健全性指標へ変換する、他の例もあり得る。
［Ｃ．資産情報の出力］
【０１５２】
別の態様において、解析システム４００は更に、出力システム１０８のうち１つまたは複数に、健全性指標の指示、ならびに、おそらく、それに加えて障害コードおよび／またはセンサデータの指示など、動作中の資産に関する様々な情報を出力させることを容易にするよう構成され得る。これらの指示は、様々な形態をとり得る。
【０１５３】
図７は、解析システム４００からの命令に従って、出力システム１０８によって表示され得る例示的なグラフィカルユーザインタフェース７００を図示する。このグラフィカルユーザインタフェース７００は、所与の資産（例えば、車両資産）に関する様々な情報を含むように示されている。例えば、示されているように、グラフィカルユーザインタフェース７００は、資産の全体的な健全性指標を示す（点線の白色の四角形で囲まれた）健全性指標表示部７０２を含み得る。ここで、健全性指標表示部７０２は、パーセンテージ、および、ダイアル状のビジュアリゼーションという形態をとり得るが、この表示部は、様々な他の形態もとり得る。
【０１５４】
更に、示されているように、グラフィカルユーザインタフェース７００は、所与の資産においてトリガされる異常状態インジケータに関連する情報を示すイベントログ７０４を含み得る。このイベントログ７０４は、所与のインジケータがトリガされた時間、インジケータがトリガされたときの資産の場所、および、インジケータに関連する簡単な説明など、インジケータに関する様々な情報を含み得る。また、イベントログ７０４は、各インジケータについての選択可能な要素を含み得て、これらは一旦選択されると、グラフィカルユーザインタフェース７００に、異常状態インジケータのトリガの一因となったセンサデータの指示を表示させ得る。更に、示されているように、グラフィカルユーザインタフェース７００は、資産の現在の場所、および、様々な主要パフォーマンスインジケータなど、所与の資産に関連する他の情報を含み得る。様々な他の例示的なグラフィカルユーザインタフェースもあり得る。
［Ｄ．健全性スコアに基づく措置のトリガ］
【０１５５】
別の態様として、解析システム４００は、健全性指標を使用して、資産２００の健全性指標を修正することを助け得る１つまたは複数の措置をトリガするよう構成され得る。いくつかの場合において、健全性指標が特定の閾値より低くなる場合、資産２００の健全性指標を増加させることを容易にし得る措置がトリガされ得る。そのような措置は、これらの措置が故障の発生を防止するのを助けることを目的としているという点で、本明細書において、「予防的措置」と呼ばれ得る。
【０１５６】
具体的には、データサイエンスシステム４０４は、資産２００について生成される健全性指標を監視し、健全性指標が閾値に到達するかどうか判定するよう構成され得る。その閾値は、予め定められ、データベース４０６内に保存され得るか、または、データサイエンスシステム４０４によって動的に判定され得る。健全性指標が閾値より低くなった場合、様々な措置があり得る。 
【０１５７】
例えば、解析システム４００は、出力システム１０８に、警告またはアラートを表示させるよう構成され得る。例えば、警告またはアラートは、減少している健全性指標の可視指示、可聴指示、または、それらの組み合わせを含み得る。特定の場合において、解析システム４００は、出力システム１０８に、ビジュアリゼーションを点滅させる、または、拡大するなど、動画によるビジュアリゼーションを表示させ得て、および／または、アラーム音などを出力させ得る。
【０１５８】
別の例において、解析システム４００は、健全性指標が閾値に到達したことに基づいて、健全性指標の増加を助け得る、１つまたは複数の推奨される措置の一覧を生成し得る。例えば、推奨される措置は、数ある他の例の中で、資産２００の特定のサブシステムを修理すること、ある動作状態に従って資産２００を動作させること、または、特定の地理的領域の周辺に資産２００を誘導することなどであり得る。解析システム４００は次に、出力システム１０８に、推奨される措置の指示を出力させ得る。
【０１５９】
他の例において、解析システム４００は、健全性指標が閾値に到達したことに基づいて、作業指示システムに、資産２００を修理するための作業指示を生成させるよう構成され得る。具体的には、解析システム４００は、作業指示システムに作業指示を出力させる作業指示データを作業指示システムへ送信し得る。この作業指示は、健全性指標を増加させることの助けとなり得る、ある修理を指定し得る。同様に、解析システム４００は、資産２００の修理に必要とされ得る、資産２００の特定の部品を部品注文システムに注文させるべく、部品注文データを送信するよう構成され得る。他の可能性も存在する。
【０１６０】
更に他の例において、解析システム４００は、健全性指標が閾値に到達したことに基づいて、資産２００の１つまたは複数の動作状態を修正することを容易にする１つまたは複数のコマンドを資産２００へ送信するよう構成され得る。例えば、コマンドは資産２００に、数ある他の例の中で、速度、加速度、ファン速度、プロペラ角度、および／または、空気吸入量などを減少（または増加）させ得る。他の措置もあり得る。
［Ｅ．サブシステム健全性指標］
【０１６１】
上述のように、いくつかの実装において、解析システム４００は、１つまたは複数のサブシステムレベル健全性指標を判定するよう構成され得る。具体的には、解析システム４００は、スタンドアロンの健全性指標としてのサブシステムレベル健全性指標を判定するように、および／または、資産レベル健全性指標を判定するのに利用され得る複数のサブシステムレベル健全性指標を判定するように構成され得る。所与のサブシステム健全性指標は、今後のある期間内に所与の資産の特定のサブシステムで故障が発生するかどうかを反映する、単一の集計されたパラメータを示し得る。
【０１６２】
概して、サブシステムレベル健全性指標は、少なくともいくつかの点で、図５Ａおよび図５Ｂを参照して記載された動作と同様の方式で判定され得る。しかしながら、サブシステムレベル健全性指標の判定においては、動作のいくつかが修正され得るか、もしくは、おそらく不要であり得、または、追加の動作が利用され得る。
【０１６３】
具体的には、いくつかの実装において、ブロック５０２で、故障の組は、発生した場合に特定のサブシステムを動作不能にさせ得る故障を含み得る。いくつかの場合において、故障の組は、障害コードなど、サブシステムに関連する異常状態インジケータから定義され得る。一般的に、サブシステムは、それに関連する１つまたは複数のインジケータを有し得る。例えば、図３の障害コード１−３はすべて、所与のサブシステム２０２に関連し得る。データサイエンスシステム４０４は、複数の方式で、所与のサブシステム２０２に関連するインジケータを判定し得る。
【０１６４】
いくつかの例において、所与のサブシステム２０２に関連する異常状態インジケータは、ユーザによって定義され得る。具体的には、データサイエンスシステム４０４は、おそらく、ユーザからの入力を受信した出力システム１０８から、所与のサブシステム２０２の指示、および、所与のサブシステム２０２に関連するインジケータを受信し得る。
【０１６５】
他の例において、データサイエンスシステム４０４は、所与のサブシステム２０２に関連する異常状態インジケータを判定するよう構成され得る。この動作は、データベース４０６内に保存された履歴データ、および／または、データソース１１０によって提供される外部データに基づき得る。 
【０１６６】
例えば、履歴修理データが利用され得る。データサイエンスシステム４０４は、そのようなデータに基づいて、所与のサブシステム２０２が修理されたときのインスタンス（ｉｎｓｔａｎｃｅ）（例えば、修理の時間および／または日付）を判定するよう構成され得る。データサイエンスシステム４０４は次に、判定に基づいて、履歴動作データから、修理前にトリガされた任意の異常状態インジケータを判定し得る。代わりに他の例において、データサイエンスシステム４０４は、履歴動作データから、修理前にトリガされて、修理後にトリガされていない異常状態インジケータのみを判定し得る。いずれの場合も、その結果、判定されたインジケータは所与のサブシステム２０２に関連し得る。
【０１６７】
更に別の例において、データサイエンスシステム４０４は、所与のサブシステム２０２に関連するセンサである関連センサを判定し、次に、関連センサに関連するインジケータを判定することによって、所与のサブシステム２０２に関連する異常状態インジケータを判定するよう構成され得る。いくつかの場合において、データサイエンスシステム４０４は、資産２００上のセンサの場所、および／または、センサの種類などのセンサ属性（例えば、センサが測定するよう構成されている物理的特性）に基づいて、関連センサを判定し得る。例えば、データサイエンスシステム４０４は、所与のサブシステム２０２上に、または、その中に物理的に配置されているセンサを判定するよう構成され得る。追加的または代替的に、データサイエンスシステム４０４は、所与のサブシステム２０２の下流または上流のセンサなど、所与のサブシステム２０２の付近にあるセンサを判定するよう構成され得る。
【０１６８】
更に、データサイエンスシステム４０４は、所与のサブシステム２０２の動作に影響する、サブシステムの上、または、その中に配置されているセンサを判定するよう構成され得る。例えば、データサイエンスシステム４０４は、所与のサブシステム２０２が入力をどのサブシステムから受信するか、および／または、所与のサブシステム２０２が出力をどのサブシステムへ提供するかを判定するよう構成され得る。または、その動作状態が所与のサブシステム２０２によって修正されるサブシステム、および／または、所与のサブシステム２０２の動作状態を修正するサブシステムが判定され得る。例えば、データサイエンスシステム４０４は、エンジンサブシステムの動作温度を低下させるべく動作する空気吸入サブシステム上のセンサがエンジンサブシステムに関連することを判定し得る。
【０１６９】
いずれの場合も、データサイエンスシステム４０４が関連センサを判定した後、データサイエンスシステム４０４は、関連センサからの測定結果を含むセンサ基準を有する、任意の異常状態インジケータを判定するよう構成され得る。これらの判定されたインジケータは、次に、所与のサブシステム２０２と関連付けられ、ブロック５０４において、故障の過去の発生を識別するのに使用される。
【０１７０】
いくつかの点でサブシステムレベル健全性指標の文脈と異なり得る、別の例示的な動作は、ブロック５１０に関する。具体的には、複数のサブシステムレベル健全性指標から資産レベル健全性指標を判定するとき、データサイエンスシステム４０４は、複数の方式で複数の健全性指標を組み合わせるよう構成され得る。それらの方式のいくつかは、いくつかの点で、上述の故障モデルを組み合わせる方法と同様であり得る。いくつかの実装において、データサイエンスシステム４０４は、各サブシステム健全性指標を等しく重み付けするよう構成され得るか、または、あるサブシステムレベル健全性指標に対して、サブシステムに基づき得る、他と異なる重み付けを行うよう構成され得る。
【０１７１】
重み付けは、資産の全体的な動作に対するサブシステムの相対的な重要度に基づき得る。例えば、サブシステムＡは、７５％の健全性指標を有し得て、サブシステムＢは、８５％の健全性指標を有し得る。資産レベル健全性指標を判定するときに各サブシステム健全性指標を等しく重み付けすると、結果的に、健全性指標は８０％になり得る。一方、サブシステムＡがサブシステムＢより３倍重要であると判定されたと仮定すると、サブシステムの相対的な重要度に従って各サブシステム健全性指標を重み付けする結果、健全性指標は７７．５％となり得る。他の例もあり得る。
【０１７２】
いずれの場合も、解析システム４００は、資産レベル健全性指標と同様に、サブシステム健全性指標に基づいて、複数の措置をトリガするよう構成され得る。しかしながら、トリガされる措置は、資産レベル健全性指標に基づいてトリガされる措置より、粒度が高くなり得る。具体的には、上述の措置のいずれも、所与のサブシステム、または、それらのコンポーネントを対象とし得る。
【０１７３】
更に、サブシステムレベル健全性指標は、解析システム４００が、今後に故障が発生し得ることを示唆するセンサ測定結果をより迅速に識別することを可能にし得る。従って、解析システム４００は、サブシステムレベル健全性指標を判定するとき、資産レベル健全性指標の場合と比較して、より短い期間について予測し、それにより、より有用な予測を提供するよう構成され得る。例えば、資産レベル健全性指標は、特定の正確度で、第１の時間長の分解能を有し得る（例えば、資産レベル健全性指標は、次の２週間中にいかなる障害も発生しない確率を示し得る）が、サブシステムレベル健全性指標は、同一の正確度で、より短い第２の時間長の分解能を有し得る（例えば、サブシステムレベル健全性指標は、いかなる障害も次の週に発生しない確率を示し得る）。サブシステムレベル健全性指標には、他の利点もあり得る。
［Ｆ．フィードバックに基づく健全性指標モジュールの更新］
【０１７４】
別の態様において、解析システム４００は、健全性指標に基づいてトリガされる措置に関するフィードバックデータを受信し、次に、フィードバックデータに基づいて、健全性指標モデル、および／または、健全性指標に基づいてトリガされる措置（本明細書では「健全性指標モジュール」と総称される）を更新するよう構成され得る。
【０１７５】
このフィードバックデータは、様々な形態をとり得るが、フィードバックデータは一般的に、健全性指標データに基づいてトリガされる措置の状態を示し得る。この状態の例として、数ある他の例の中で、措置が実行されたこと、措置が実行されて、差し迫った故障を成功裏に修正したこと、措置が実行されたが、問題を修正できなかったこと、または、措置は実現可能でなかったことなどがあり得る。更に、解析システム４００は、様々なソースから、このフィードバックデータを受信し得る。ソースの例には、ユーザによって操作される出力デバイスまたはシステムが含まれる。
【０１７６】
特定の例において、解析システム４００は、健全性指標に基づいて、所与の資産の特定のコンポーネントを修理するための作業指示を生成することをトリガし得る。作業指示の完成後、整備士は、作業指示に応答して講じられる措置に関するフィードバックを提供するのに、出力システム１０８のクライアントデバイスを利用し得る。それらのフィードバックには、特定のコンポーネントが実際に修理される必要があったこと、および／もしくは、修理が成功裏に実行されたこと、または、特定のコンポーネントが修理される必要がなかったこと、および／もしくは、修理を実行できなかったことの指示などが含まれる。解析システム４００は、このフィードバックデータを受信し得て、次に、それを使用して、様々な方式で健全性指標モジュールを更新し得る。
【０１７７】
例えば、解析システム４００は、このフィードバックデータに基づいて、健全性指標モジュールを改良し得る。具体的には、フィードバックデータは、数ある他の例の中で、解析システム４００に、図５Ａのブロック５０２における故障の組へ故障を追加させるか、もしくは、故障の組から故障を削除させ、所与の故障モデルの出力に適用される重みを修正させ、および／または、所与の故障が発生する可能性を予測するのに利用される特定の予測アルゴリズムを調節させ得る。別の場合において、解析システム４００は、健全性指標が今後に健全性閾値より低くなる場合に、ある種類の措置を他より優先するように、健全性指標モジュールを更新し得る。多くの他の例もあり得る。
【０１７８】
フィードバックデータの別の例において、解析システム４００は、出力システム１０８に、健全性指標を増加させる（または、少なくとも維持する）のを助け得る、所与の資産が通る推奨経路（例えば、高度の変化、および／または、上り坂がほとんどない経路）の一覧の指示を表示させ得る。その後、解析システム４００は、経路上の構造物が原因で、推奨経路は実現可能でないことを示すフィードバックデータを受信し得る。解析システム４００は、そのようなフィードバックに基づいて、推奨経路の一覧から推奨経路を削除し得る。他の例も可能である。
［Ｇ．インジケータの処理の改善］
【０１７９】
解析システム４００は、他の形態のフィードバックデータを受信し、他の動作も実行するよう構成され得る。例えば、解析システム４００は、障害コードなどの、通常であれば生成されてユーザに表示される異常状態インジケータをインテリジェントに抑制するよう構成され得る。
【０１８０】
上述のように、いくつかの従来の資産監視システムは、「偽陽性」の異常状態インジケータを生成する。その基礎となる障害は、資産の全体的な動作に影響しないので、これらのインジケータは、ユーザにとって有意でない。そのような障害の例には、数ある他の例の中で、フロントガラスワイパーの破損、フロントガラスワイパー液の残量低下、アネモメータの破損、計器パネルライトの熱損などが含まれ得る。そのような「偽陽性」インジケータは、有意のインジケータからユーザの注意をそらさせ得るか、または、異常状態の指示の受信に対するユーザの反応を鈍感にさせ得る。これらの問題のいくつかを解決することを助けるべく、解析システム４００は、特定の異常状態インジケータに対する応答に適応して、従来なら解析システム４００が異常状態インジケータを自動で生成することを生じさせる動作状態に対して、インテリジェントに応答するよう構成され得る。
【０１８１】
分かり易くするべく、通常なら異常状態インジケータがトリガされる動作状態を適応的に処理することに関連する動作および機能が、障害コードの文脈で記載されている。しかしながら、これらの動作および機能のうち、いくつか、または、すべては、様々な他の種類の異常状態インジケータについての他の文脈で実装され得る。
【０１８２】
解析システム４００は動作中、出力システム１０８に、所与の障害コードの指示を表示させることを容易にするよう構成され得る。解析システム４００は、複数の方式でそれを行い得る。
【０１８３】
一例において、解析システム４００は、出力システム１０８に、資産からのセンサデータに基づいて所与の障害コードの指示を表示させることを容易にし得る。具体的には、解析システム４００は、資産２００から、解析システム４００が解析するセンサデータを受信し得る。受信されたセンサデータが、おそらくはデータベース４０６に保存されているセンサ基準を満たす場合、解析システム４００は、出力システム１０８に所与の障害コードの指示を表示させるべく、障害コードデータを出力システム１０８へ送信し得る。
【０１８４】
別の例において、解析システム４００は、出力システム１０８に、資産からの障害コードデータに基づいて所与の障害コードの指示を表示させることを容易にし得る。具体的には、解析システム４００は、資産２００から、所与の障害を示す障害コードデータを受信し得て、解析システム４００は次に、障害コードデータを出力システム１０８へ中継し得る。いくつかの場合において、解析システム４００は、まず第１に、資産２００が障害コードデータを生成することを容易にし得る。例えば、解析システム４００は、資産２００に障害コードをトリガさせることを容易にするべく、解析システム４００が資産２００へ送信する障害コードルールを生成するよう構成され得る。障害コードルールは、所与の障害コードをトリガする、１つまたは複数のセンサと、対応するセンサ基準とを識別する。
【０１８５】
いずれの場合も、出力システム１０８は、所与の障害コードの指示を出力し得る。所与の障害コードの指示は、可視、可聴、または、それらの何らかの組み合わせなど、様々な形態をとり得る。いくつかの場合において、出力システム１０８は、障害コードをユーザへ表示し、アラートに関するユーザの選択肢を提供する。例えば、この選択肢によって、ユーザは数ある他の可能な選択肢の中で、障害コードを（例えば、「無視」アイコンなどを選択することによって）棄却し、障害コードに対して（例えば、「解決」アイコンなどを選択することによって）措置を講じ、または、障害コードを（例えば、予め定められた時間にわたって選択を行わないことによって）放置することが可能になり得る。
【０１８６】
図８Ａは、所与の障害コードの例示的な可視指示８００を図示する。出力システム１０８は、解析システム４００から障害コードデータを受信したことに応答して、可視指示８００を表示し得る。示されているように、可視指示８００は、トリガされた障害コード（例えば、障害コード４）を識別する障害アラート８０２、解決アイコン８０４、および、無視アイコン８０６を含む。動作中、ユーザは、障害アラート８０２の原因を直すべく実行され得る、推奨される措置の一覧を取得するべく、解決アイコン８０４を選択し得る。一方で、ユーザは、障害アラート８０２を無視するべく、無視アイコン８０６を選択し得る。これが一旦選択されると、可視指示８００は消失し得る。
【０１８７】
実際には、障害コードに関して検討し、決定するユーザは、複数の人間であり得る。いくつかの例において、複数の資産の監督を担当する、人間の管理者が、（例えば、解析システム３００と通信するコンピューティングシステムを介して、遠隔的に）障害コードを検討し得る。人間の管理者は、ある障害コードがどのように処理されるべきかに関する専門知識を有し得る。いくつかの例において、複数のユーザは、同一の障害コードを検討し得る。
【０１８８】
解析システム４００は、出力される障害コードに関するユーザの決定を示すフィードバックデータを受信するよう構成され得る。具体的には、ユーザによって操作される出力システム１０８は、フィードバックデータを提供し得る。フィードバックデータは、様々な形態をとり得る。
【０１８９】
いくつかの例において、フィードバックデータは、ユーザの決定（例えば、ユーザが無視アイコン８０６を選択したことを示すデータ）を明示的に示し得る。他の例において、解析システム４００は、フィードバックデータから、ユーザの決定を推測するよう構成され得る。
【０１９０】
具体的には、解析システム４００は、障害コードデータを送信後、資産２００から受信された動作データに基づいて、決定を推測するよう構成され得る。例えば、解析システム４００は、動作データが変化する場合、ユーザが措置を講じることを決定したと推測し、その結果、障害コードがもうトリガされなくなるよう構成され得る。一方で、解析システム４００は、障害コードデータを送信した後、一定時間（１時間、数時間、数日、または、数週間など）にわたって障害コードが存続する（例えば、所与の障害コード、および／または、障害コードに関連するセンサデータがセンサ基準を満たしていることを示す障害コードデータが継続的に動作データ内に含まれる）場合、ユーザが障害コードを棄却または放置することを決定したと推測するよう構成され得る。ユーザの決定を推測する他の例も可能である。
【０１９１】
いずれの場合も、解析システム４００は、経時的にフィードバックデータを集計し、そのようなデータをデータベース４０６内に保存するよう構成され得る。解析システム４００は、障害コードを検討する１または複数のユーザに対応するフィードバックデータを集計するよう構成され得る。更に、集計されたフィードバックデータは、資産２００および／または他の資産についての障害コードの決定に対応し得る。
【０１９２】
解析システム４００は、履歴フィードバックデータに基づいて、各障害コードについての応答パターンを判定し、そのようなパターンをデータベース４０６内に保存するよう構成され得る。応答パターンは、所与の障害コードに関して、特定の応答がどれだけ頻繁に利用されるかを反映し得る。
【０１９３】
応答パターンは、複数の方式で判定され得る。一例において、応答パターンは、所与の障害コードへのあり得る各応答に対応する応答カウンタから判定され得る。所与の障害コードのインスタンスについて、特定の応答が識別されるたびに、応答カウンタはインクリメントされ得る。そのようなカウンタから、応答パターンが判定され得る。
【０１９４】
いずれの場合も、解析システム４００は、応答パターンに基づいて、ユーザがどのように所与の障害コードを処理するか予測するよう構成され得る。つまり、所与の応答パターンは、特定の障害コードについて予期される行動を示し得る。いくつかの場合において、ユーザが所与の障害コードをどのように処理するか予測することは、解析システム４００がＮａｉｖｅ  Ｂａｙｅｓモデルなどの機械学習モデルを利用することを伴い得る。
【０１９５】
解析システム４００は、少なくとも応答パターンに基づいて、複数の動作を実行するよう構成され得る。例えば、１つのそのような動作は、特定の障害コードについて予測される挙動に従って、特定の障害コードを示す動作データを処理することを伴い得る。具体的には、ユーザが通常、特定の種類の障害コードを無視または放置することを応答パターンが示す場合、解析システム４００は、動作データが障害コードのトリガを示すときに、この応答パターンに従って動作を実行し得る。出力システム１０８に、障害コードがユーザにどのように表示されるかを修正させる、または、障害コードを完全に抑制させるなど、応答パターンに従って多くの動作が実行され得る。
【０１９６】
例えば、解析システム４００は、応答パターンおよび現在の動作データに基づいて、障害コード表示を修正するよう構成され得る。具体的には、解析システム４００は、応答パターンおよび現在の動作データに基づいて、所与の障害コードについての推奨される応答を判定し得る。その後、解析システム４００は、所与の障害コードに関してユーザが講じることが推奨される措置を反映する障害コード表示データを出力システム１０８へ送信し得る。
【０１９７】
図８Ｂは、障害コード表示データの受信に応答して表示され得る、障害コードの例示的な可視指示８１０を図示する。示されているように、可視指示８１０は、いくつかの点で、図８Ａの可視指示８００と同様である。しかしながら、可視指示８１０において、無視アイコン８０６は、可視指示８１０の中央に位置し、図８Ａの解決アイコン８０４は、他の選択肢アイコン８１２によって置き換えられる。他の選択肢アイコン８１２は、一旦選択されると、図８Ａと同様の方式で、解決アイコン８０４を表示し得る。この例において、解析システム４００は、障害コード４が従来的に棄却または放置されていることを判定し得て、従って、障害アラート８０２を無視するという、推奨される応答を判定し得る。いくつかの場合において、可視指示８１０は、一定時間後に消失し得て、それにより、障害コード４を見て手動で棄却するための時間をユーザに提供しつつ、また、最終的には障害アラート８０２を削除することで、有意でない障害について、ユーザを困らせないようにする。
【０１９８】
追加的または代替的に、解析システム４００は、応答パターンおよび現在の動作データに基づいて、障害コードを抑制するかどうか判定するよう構成され得る。つまり、解析システム４００は、そのような障害コードが従来的に棄却または放置されていることを応答パターンが示す場合、障害コードを抑制するよう構成され得る。具体的には、解析システム４００は、所与の障害コードを示す障害コードデータおよび／またはセンサデータを受信し、所与の障害コードに対応する応答パターンを識別し得て、応答パターンに基づいて、障害コードを抑制するかどうか（例えば、障害コードデータを出力システム１０８へ提供するかどうか）判定し得る。
【０１９９】
いくつかの場合において、解析システム４００は、障害コードを抑制する前に、障害、および／または、障害に関連するサブシステムに基づいて、応答パターンが一定の最低基準を満たすかどうか判定するよう構成され得る。例示的な最低基準は、以前の棄却および／もしくは放置の最低数、または、棄却および／もしくは放置の最低パーセンテージなど、複数回の応答を含み得る。いくつかの場合において、解析システム４００は、所与の応答パターンの基礎となる応答カウンタ、または、それらから導かれた値を、そのような最低基準と比較し、障害コードを抑制するかどうか判定するよう構成され得る。
【０２００】
いくつかの実装において、特定の障害コードによって識別される障害の重大度、および／または、特定の障害コードに関連するサブシステムに基づいて判定され得る複数のレベルの最低基準が存在し得る。最低基準の各層は、解析システム４００による異なる応答に対応し得る。例えば、もっとも低い、棄却の第１のパーセンテージは、（例えば、図８Ｂに示されているものと同様の）表示部の選択肢の調節に対応し得て、より高い、棄却の第２のパーセンテージは、（例えば、他の選択肢アイコン８１２を削除するなど）表示部の選択肢の別の調節に対応し得て、更に高い、棄却の第３のパーセンテージは、解析システム４００が障害コードを完全に抑制することに対応し得る。他の例もあり得る。
【０２０１】
更に、１つの障害コードを抑制するための最低基準は、別の障害コードの場合と異なり得る。これは、障害、および／または、障害コードに関連するサブシステムに依存し得る。例えば、いくつかの障害コード（例えば、重要なサブシステムに関連するものなど）は、抑制される前に、第１の回数の棄却を必要とし得て、他の障害コード（例えば、重要でないサブシステムに関連するものなど）は、第１の回数と同一か、それより小さくてよい、第２の回数の棄却または放置に基づいて抑制され得る。他の例もあり得る。
【０２０２】
少なくとも応答パターンに基づいて解析システム４００が実行し得る別の動作は、新しい障害コードルールを生成すること、または、既存の障害コードルールを更新することを伴い得る。具体的には、解析システム４００は、ユーザがどのように所与の障害コードへ応答するかに基づいて、所与の障害コードについてのセンサ基準を修正し得る。解析システム４００は、これらの新しい、または、更新されたルールを、資産２００、および／または、おそらく同一の資産の一団における他の資産へ送信するよう構成され得る。このようにして、動作状態が古い障害コードルールを満たす場合が次に発生したときに、障害コードアラートが資産でトリガされないようになる。
【０２０３】
更に、解析システム４００は、環境依存データの影響を考慮して、応答パターンを調節するよう構成され得る。具体的には、解析システム４００は、周囲温度などの環境因子が、環境因子が無ければトリガされないであろう、トリガされている障害コードの一因となっているかどうか判定するよう構成され得る。環境因子が障害コードのトリガに影響していることを外部データが示す場合、解析システム４００は、障害コードを抑制するよう構成され得る。例えば、外部の天気データは、周囲温度が比較的高いことを示し得る。このことは、温度に基づく障害コードのトリガの一因となり得る。解析システム４００は、少なくとも、外部の天気データに基づいて、そのような障害コードを抑制し得る。
【０２０４】
更に、解析システム４００は、部分的に資産２００の場所に基づいて、従来的に障害コードを生成することを生じさせる動作状態をインテリジェントに処理するよう構成され得る。具体的には、解析システム４００は、ある障害コードについての特定のユーザ応答を、所与の地理空間的場所に関連付け得る。解析システム４００は次に、所与の地理空間的な場所に対する近接度の特定の閾値内に資産２００があるとき、資産２００に、ある障害コードを抑制させ得る。他の例もあり得る。
【０２０５】
いくつかの例示的な実装において、機関車の操作者、または、ＭＲＩ機器の技師など、特定の資産についての障害コードを検討する所与のユーザは、特定の資産に対応する障害コードが所与のユーザへどのように表示されるかについて、個人設定し得る。つまり、所与のユーザは、ある障害コードをどのように処理するかについての解析システム４００の判定をオーバーライドし得る。所与のユーザがそれを決定する場合、解析システム４００は、オーバーライドの指示を受信し得て、おそらく、ある障害コードをどのように処理するかについての解析システム４００の判定を更新し得る。これにより、ある障害コードが今後他のユーザへ提示される方式が修正され得る。 
【０２０６】
具体的には、出力システム１０８は、所与の資産についての、いくつか、または、すべての障害コードがどのように処理されるかについて修正するための選択肢を、所与の資産のユーザに表示し得る。それらの修正は、ある障害コードの抑制に対応する最低基準を修正すること、および／または、いくつかの障害コードについての予測される挙動を修正することを含み得る。
【０２０７】
例えば、出力システム１０８は、選択可能な「設定」の要素などを表示し得る。これが一旦選択されると、ユーザは、所与の資産についてのいくつか、または、すべての障害コードに関して解析システム４００が推奨する処理をオーバーライドすることが可能である。例えば、ユーザは、数ある他の例の中で、障害コード４が図８Ｂの可視指示８１０内の方式ではなく、図８Ａの可視指示８００内の方式で表示されることを選択し得て、または、ユーザは、障害コード４が抑制されるべきでないことを選択し得る。
【０２０８】
別の例において、出力システム１０８は、最初に障害コードが抑制されるとき、選択可能なオーバーライド要素などを表示し得る。例えば、最初に障害コードが抑制されるとき、ユーザは、抑制をオーバーライドするように動作可能なオーバーライドアイコンと共に、特定の障害コードが抑制されていることを示す警告を受信し得る。ユーザは、解析システム４００が推奨する、障害コードの抑制をオーバーライドするべく、オーバーライドアイコンを選択し得る。
【０２０９】
いずれの場合も、出力システム１０８は、解析システム４００が所与の障害コードをどのように処理するかについてユーザがオーバーライドすることを示すオーバーライドデータを解析システム４００へ提供するよう構成され得る。解析システム４００はオーバーライドデータに基づいて、所与の障害コードについて予測される挙動を修正し得る。例えば、解析システム４００は、所与の障害コードを抑制するための最低基準を修正（例えば、増加または減少）し得て、および／または、所与の障害コードがユーザに対して、どのように提示されるか、もしくは、抑制されるかについて修正し得る。
【０２１０】
いくつかの実装において、解析システム４００は、所与の障害コードについての、閾値の数のオーバーライドに基づいて、所与の障害コードについて、その予測される挙動を修正し得る。つまり、閾値の数のユーザが、解析システム４００による所与の障害コードの処理、または、それを示しているオーバーライドの合計数の閾値がオーバーライドすることを決定した場合のみ、解析システム４００は、所与の障害コードについて、その予測される挙動を修正し得る。他の例もあり得る。
【０２１１】
上の説明の文脈では、解析システム４００が、出力システム１０８を操作するユーザからフィードバックデータを受信しているが、上の説明は、出力された障害コードとインタラクトする資産の操作者からのフィードバックデータに適用し得る。従って、いくつかの実装において、解析システム４００は、資産からのフィードバックデータに基づいて、応答パターンを判定および／または更新するよう構成され得る。具体的には、資産２００などの資産の操作者は、資産上のユーザディスプレイなどで、障害コードの指示を受信し得る。資産は、操作者が障害コードの指示をどのように処理するかに基づいて、フィードバックデータを解析システム４００へ提供し得て、解析システム４００は、上の説明に沿って動作を実行し得る。
【０２１２】
フィードバックデータの別の例において、解析システム４００は、今後に特定の障害コードが発生すると予測して、作業指示を生成し得る。作業指示を受信後、整備士は、いかなる修理も必要ないことを判定し得る。この一連のイベントが複数回発生する場合、解析システム４００は、障害コードの指示を資産が出力する頻度を修正（例えば、減少）することを容易にし得る。逆に、整備士がある程度の資産の損傷を発見することが複数回発生する場合、解析システム４００は、資産が障害コードの指示を出力する頻度を修正（例えば、増加）することを容易にし得る。
［Ｈ．履歴健全性指標］ 
【０２１３】
解析システム４００は、資産１０２に対応する健全性指標データをデータベース４０６内に保存するよう構成され得る。解析システム４００は、複数の資産について、経時的にそれを行い得る。解析システム４００は、そのような履歴健全性指標データから、複数の動作を実行するよう構成され得る。
【０２１４】
一例において、解析システム４００は、履歴健全性指標データを出力システム１０８の１つまたは複数へ提供するよう構成され得で、出力システム１０８は、健全性指標のグラフィック表現を表示し得る。図９は、出力システム１０８によって表示され得る経時的な健全性指標の表現を示す、例示的なグラフィカルユーザインタフェース９００を図示する。示されているように、グラフィカルユーザインタフェース９００は、例示的な期間（例えば、９０日の期間）示されている健全性指標曲線９０２を含む。この例において、健全性指標の急激な変化９０４は、例示的な期間において、３５日目の前後に発生した。このことは、資産２００に対する修理がそのときに発生したことを示し得る。経時的な健全性指標の他の例示的な表現もあり得る。
【０２１５】
別の例において、解析システム４００は、少なくとも履歴健全性指標データに基づいて、健全性指標に影響する変数を識別するよう構成され得る。例えば、解析システム４００は、健全性指標が比較的高い（または比較的低い）資産に関連する変数を識別するべく、履歴健全性指標データを解析するよう構成され得る。健全性指標に影響し得る変数の例は、数ある他の例の中で、所与の資産の特性、および、それらの動作を示す資産変数と、所与の資産を操作する人間の操作者の特性を示す操作者変数と、所与の資産に対する日常的なメンテナンスまたは修理を実行する整備士などの特性を示すメンテナンス変数を含み得る。
【０２１６】
資産変数の例には、数ある他の例の中で、資産ブランド、資産モデル、資産移動スケジュール、資産積載物、および、資産環境などが含まれ得る。資産ブランドは、所与の資産の製造者を示し得て、資産モデルは、所与の製造者からの資産の特定のモデルを示し得る（例えば、モデル識別子など）。資産移動スケジュールは、所与の資産が通過する経路を示し得て、高度、地形、および／または、移動時間の長さの指示を含み得る。資産積載物は、資産が輸送する貨物などの種類および／または量（例えば重量）を示し得る。資産環境は、数ある他の例の中で、地理空間的な場所、気候、平均周囲温度もしくは湿度、および／または、電気干渉源への近接度など、所与の資産が操作される環境についての様々な特性を示し得る。
【０２１７】
操作者変数の例には、数ある他の例の中で、操作者識別子、操作者スケジュール、および、操作者習慣など、資産を操作する１または複数の人に関連する任意の変数が含まれ得る。操作者識別子は、所与の資産を操作した操作者個人を識別し得る。操作者スケジュールは、所与の資産が操作されるシフトの種類（例えば、朝、日中、夜など）、または、シフトの長さ（例えば、数時間）を示し得る。操作者習慣は、平均制動距離、平均加速時間、平均減速時間、平均ｒｐｍなど、操作者が所与の資産を扱うときの様々なトレンドを示し得る。
【０２１８】
メンテナンス変数の例には、数ある他の例の中で、メンテナンスまたは修理の日付、資産の点検の間の時間、修理の場所、修理業者識別子、整備士識別子、および、修理時間の長さなど、資産のメンテナンス（例えば、一般的な維持、および／または、資産の動作状態の検討）および／または修理に関連するいずれかの変数が含まれ得る。メンテナンスまたは修理の日付は、所与の資産上でメンテナンスまたは修理が実行された日付および時間を示し得る。点検の間の時間は、メンテナンス担当者が任意の動作上の問題について資産を評価したときのインスタンスの間の時間長を示し得る。修理の場所は、修理がどこで実行されたか（例えば、修理業者、または、現場）を示し得る。修理業者識別子は、所与の資産を修理した特定の修理業者などを識別し得て、整備士識別子は、所与の資産で作業した特定の整備士などを識別し得る。修理時間の長さは、所与の資産の修理に費やした時間長を示し得る。
【０２１９】
当業者であれば、上述の資産関連の変数は、単に例および説明の目的で提供されているものであり、限定を意味するものでないことを理解するであろう。多くの他の変数もあり得、それらは本明細書において想定されている。
【０２２０】
実際には、解析システム４００は、データベース４０６内に保存されている、または、データソース１１０によって提供される、資産関連の履歴データに部分的に基づいて、変数を判定するよう構成され得る。そのようなデータの例には、数ある他の例の中で、製造者または資産の技術仕様、資産移動ログ、資産積載物ログ、天気記録、地図、建物の電気代請求書、操作者のタイムカードなど、操作者の作業スケジュール、資産動作データ、メンテナンスまたは修理ログ、整備士のタイムカード、または、本明細書に記載された任意の他のデータを含み得る。
【０２２１】
解析システム４００は、複数の方式で、履歴健全性指標データ、および、おそらく、他の履歴資産関連データに基づいて変数を判定するよう構成され得る。図１０は、変数を判定するための例示的なフローチャート１０００を図示する。
【０２２２】
示されているように、ブロック１００２において、解析システム４００は、経時的な健全性指標が解析される１つまたは複数の資産（本明細書では、「資産のプール」と総称される）を識別するよう構成され得る。いくつかの例において、資産のプールは、健全性指標が比較的高い資産を含み得る。例えば、資産プールは、数ある他の可能性の中で、特定の時間長にわたって履歴健全性指標が閾値を上回っている各資産、履歴健全性指標が閾値より低くなったことがない各資産、または、特定の時間長にわたって判定された履歴健全性指標の平均が閾値を上回っている各資産を含み得る。他の例において、資産プールは、健全性指標が上述の任意の閾値要件を満たす、特定の数の資産を含み得る。一方、他の例において、資産のプールは、健全性指標が比較的低い資産を含み得る。
【０２２３】
ブロック１００４において、解析システム４００は、資産のプールにおける各資産について、所与の資産の変数を判定するべく、所与の資産の履歴健全性指標データおよび／または資産関連データを解析するよう構成され得る。解析システム４００は、所与の時間長にわたって、または、各資産の動作寿命全体にわたって、それを行い得る。
【０２２４】
実際には、解析システム４００は、所与の資産について、上述の変数のいずれか、もしくは、すべてを判定するよう構成され得るか、または、解析システム４００は、数ある他の例の中で、資産属性のみ、または、メンテナンス属性のみなど、変数の選択されたサブセットについて、この判定を行うよう構成され得る。変数のサブセットは、数ある他の例の中で、予め定義されてデータベース４０６内に保存され得るか、または、動的に判定され得る。
【０２２５】
いくつかの実装において、解析システム４００は、少なくとも所与の資産の履歴健全性指標データに基づいて、変数のサブセットを判定するよう構成され得る。具体的には、解析システム４００は、所与の資産の履歴健全性指標データにおけるトレンドを識別し、おそらく履歴資産関連データから、そのようなトレンドの１つまたは複数の潜在的な原因を判定するよう構成され得る。いくつかの場合において、トレンドには、数ある他の例の中で、一定期間にわたる健全性指標の閾値量の変化（例えば、増加または減少）、一定時間にわたって定常的な健全性指標、または、閾値量の減少の前の一定時間経過後の一定量の増加などがあり得る。
【０２２６】
特定の例において、解析システム４００は、１週間などの所与の期間にわたって、履歴健全性指標の閾値量の増加（少なくとも１０％の増加など）を識別するよう構成され得る。解析システム４００は次に、変化の１つまたは複数の潜在的な原因を判定するべく、トレンドが開始した時間（または、トレンドが終了した時間、もしくは、その間の時間）を識別し得て、識別された時間前後の資産関連データ（例えば、識別された時間の前または後の一定時間に相当するデータ）を解析し得る。
【０２２７】
例えば、再び図９において、解析システム４００は、健全性指標曲線９０２によって表現される履歴健全性指標データを評価し得て、急激な変化９０４が、健全性指標の１０％の増加より大きいことを判定する。解析システム４００は次に、グラフィカルユーザインタフェース９００上に示される、３５日目に対応する日付（例えば、２０１５年５月１日）を識別し得て、様々な資産関連データに基づいて、急激な変化９０４の１つまたは複数の潜在的な原因を示し得る、５月１日の日付前後に発生した任意のイベントを判定し得る。一例において、解析システム４００は、修理ログより、２０１５年５月５日に修理業者１の整備士Ａが所与の資産のエンジンを修理したことを判定し得る。その結果、修理業者１および整備士Ａの識別子は変数になり得る。
【０２２８】
ブロック１００６において、解析システム４００は、判定された変数の記録を生成し得る。例において、解析システム４００は、データベース４０６の１つの中に、変数の各々についての変数カウンタを保存し得る。解析システム４００は、判定された変数の各々に対応する適切なカウンタをインクリメントするよう構成され得る。変数カウンタは、健全性指標が比較的高い資産の間で通常見られる変数の指示を提供し得る。
【０２２９】
ブロック１００８において、解析システム４００は次に、変数が判定およびインクリメントされるべき何らかの資産が資産のプールに残っているかどうかを判定し得る。資産が残っている場合、解析システム４００は、ブロック１００４−１００８のループを繰り返し得る。解析システム４００が、資産プールのうちの資産の各々について、変数を判定およびインクリメントした後で、結果として生じるデータは次に、高い健全性指標の原因となる変数の指示をある程度まで提供し得る。
【０２３０】
図１１は、変数カウンタをインクリメントした結果生じるデータの概念図を図示する。具体的には、ヒストグラム１１００は、資産のプールについてのメンテナンス変数のカウンタを図示する。より具体的には、ヒストグラム１１００は、整備士Ａによって修理された資産の方が、整備士ＢおよびＣによって修理された資産より、高い健全性指標を有するものが多かったことを示している。ヒストグラム１１０２は、資産環境変数のためのカウンタを図示し、具体的には、４５℃より高い周囲温度を有する環境内で動作した資産は、他のいずれかの温度範囲の場合と比べて、高い健全性指標を有するものが少なかったことを図示している。ヒストグラム１１０４は、操作者習慣の変数のカウンタを図示し、具体的には、操作者の平均加速時間が１０分から１５分までの間であった資産は、他の加速時間の場合と比べて、高い健全性指標を有するものが多かったことを図示している。ヒストグラム１１０６は、資産変数のカウンタを図示し、種類がブランドＡモデル７である資産は、他の２つのモデルの種類と比べて、高い健全性指標を有するものが多かったことを示している。当業者であれば、これらは単に、変数の数少ない例に過ぎず、多くの他の変数があり得ることを理解するであろう。
【０２３１】
再び図１０を参照すると、ブロック１０１０において、解析システム４００は、部分的に変数カウンタに基づいて、影響変数を判定するよう構成され得る。いくつかの例において、影響変数とは、変数カウンタが予め定められた閾値を超える変数である。他の例において、影響変数は、変数カウンタが最大値を有する変数である。例えば、ヒストグラム１１００を参照すると、整備士Ａが影響変数であることが判定され得る。なぜなら、整備士Ａについての変数カウンタは、他のカウンタの間で、最高の値を有するからである。他の例もあり得る。
【０２３２】
解析システム４００は、様々な他の方式で影響変数を判定し得る。例えば、他の実装において、解析システム４００は、最初に、図１０のブロック１００２に従って資産のプールを判定し、次に、資産のプールのうちの資産の各々について、資産関連データを解析することによって、影響変数を判定し得る。解析システム４００は、資産のプールのうちの資産が共通に有する変数を識別し得る。これらの識別された変数は次に、影響変数として定義され得て、または、識別された変数のサブセットは、影響変数（例えば、資産のプールのうちの、閾値の数の資産が共通に有する変数）として定義され得る。影響変数を判定する他の方式もあり得る。 
【０２３３】
影響変数を判定後、解析システム４００は、複数の動作を実行するよう構成され得る。例えば、解析システム４００は、おそらく、ランク付けされた推奨一覧を判定することで、資産に関する様々な推奨を判定し、次に、グラフィカルディスプレイに当該推奨の指示をユーザへ出力させるよう構成され得る。一般的に、所与の推奨は、すべての資産は最大能力の７５％より低い状態で動作すべきなどの一般的な推奨（例えば、一団全体の推奨）、または、特定の修理が実行されるように、特定の資産は、ある修理業者へ送信されるべきなど、資産もしくは資産の群に固有の推奨であり得る。
【０２３４】
更に、所与の推奨は、特定の資産が比較的低い健全性指標を有すると判定し、次に、特定の資産の変数を評価することに基づき得る。所与の推奨は、次に、ブロック１０１０で判定される影響変数とより緊密に一致するように、特定の資産の変数を修正することを容易にし得る。
【０２３５】
例示的な推奨は、数ある他の例の中で、購入すべき資産の推奨されるブランドもしくはモデル、今後の修理に推奨される修理業者もしくは個人の整備士、１つまたは複数の資産について推奨される修理スケジュール、今後の作業シフトに推奨される操作者、資産を効率的に動作させるよう操作者を教育するのに推奨される指示、および、資産を動作させるのに推奨される場所または環境を含み得る。
【０２３６】
他の例において、解析システム４００は、影響変数に従って資産を動作させることを容易にする動作コマンドを資産へ送信するよう構成され得る。例えば、解析システム４００は、ヒストグラム１１０４によって図で表現される変数データから、命令を資産へ送信し得る。資産において、その命令は、資産がどれだけ速く加速されるかを制限し得て、それにより、資産の動作を、平均的な加速時間である１０〜１５分に近づける。他の例もあり得る。
【０２３７】
追加的または代替的に、解析システム４００は、履歴健全性指標データに基づいて、他の動作を実行するよう構成され得る。一例において、解析システム４００は、健全性指標モジュールを修正するよう構成され得る。具体的には、解析システム４００は、健全性指標が特定の閾値に到達することに基づいて、作業指示の生成をトリガし得る。その後、解析システム４００は次に、閾値の時間長にわたって、健全性指標データを監視し得る。作業指示を生成した後、予め定められた時間内に、健全性指標が一定量増加した場合、解析システム４００は、特定のコンポーネントを修理する作業指示が実行され、健全性指標の減少の原因を修正したと推測するよう構成され得る。解析システム４００は、この推測に基づいて、健全性指標モデル、および／または、健全性指標モデルに基づいてトリガされた措置を修正するよう構成され得る。他の例も可能である。
［５．例示的な方法］
【０２３８】
ここで、図１２において、解析システム４００によって実行され得る、健全性指標を判定するための例示的な方法１２００を示すフローチャートが図示されている。方法１２００、および、以下に記載された他の方法について、フローチャートにおいてブロックによって示されている動作は、上の説明に沿って実行され得る。更に、上述の１つまたは複数の動作は、所与のフローチャートへ追加され得る。
【０２３９】
ブロック１２０２において、方法１２００は、解析システム４００が、現時点などの参照時間に、資産（例えば、資産２００）の少なくとも１つの動作状態を示すセンサデータを受信することを伴い得る。ブロック１２０４において、方法１２００は、解析システム４００が、受信されたセンサデータおよび（例えば、データベース４０６内に保存されている）履歴動作データに基づいて、一群の故障のうちの故障が、参照時間後の一定期間（現在の時間の後の２週間など）内に資産で発生するかどうかを示す健全性指標を判定することを伴い得る。履歴動作データは、少なくとも、（ｉ）過去（例えば、現時点より前の２週間の期間における、ある時間）に資産で発生した故障に関連する履歴異常状態データ、および、（ｉｉ）過去における資産の少なくとも１つの動作状態を示す履歴センサデータを含む。ブロック１２０６において、方法１２００は、可視および／または可聴表現など、判定された健全性指標の表現をコンピューティングデバイスに表示させることを容易にするべく、解析システム４００が、判定された健全性指標を示す健全性指標データをコンピューティングデバイス（例えば、出力システム１０８）へ送信することを伴い得る。
【０２４０】
図１３は、解析システム４００によって実行され得る、資産のサブシステムについての健全性指標を判定するための例示的な方法１３００のフローチャートを図示する。ブロック１３０２において、方法１３００は、解析システム４００が、少なくとも履歴動作データに基づいて、資産２００のサブシステム２０２など、資産のサブシステムに関連する、少なくとも１つの異常状態インジケータ（例えば、障害コード）を判定することを伴い得る。履歴動作データは、少なくとも、（ｉ）過去（例えば、現時点より前の２週間中の、ある時間など）にサブシステムで発生した故障に関連する履歴異常状態データ、および、（ｉｉ）過去におけるサブシステムの少なくとも１つの動作状態を示す履歴センサデータを含み得る。ブロック１３０４において、方法１３００は、解析システム４００が、現時点などの参照時間に、サブシステムの少なくとも１つの動作状態を示すセンサデータを受信することを伴い得る。ブロック１３０６において、方法１３００は、解析システム４００が、（ｉ）受信されたセンサデータと、（ｉｉ）判定された少なくとも１つの異常状態インジケータと、（ｉｉｉ）履歴動作データとに基づいて、一群の故障のうちの故障が、参照時間後の一定期間（現在の時間より後の１週間など）内にサブシステムで発生するかどうかを示す健全性指標を判定することを伴い得る。ブロック１３０８において、方法１３００は、解析システム４００が、判定された健全性指標の表現をコンピューティングデバイスに表示させることを容易にするべく、判定された健全性指標を示す健全性指標データを（例えば、出力システム１０８の）コンピューティングデバイスへ送信することを伴い得る。
【０２４１】
図１４は、解析システム４００によって実行され得る、高い健全性指標に関連する、資産関連の変数に基づいて推奨を行うための例示的な方法１４００のフローチャートを図示する。ブロック１４０２において、方法１４００は、解析システム４００が、複数の動作データに基づいて、複数の資産（例えば、資産１０２）に対応する複数の健全性指標を判定することを伴い得る。所与の健全性指標は、一群の故障のうちの故障が、一定期間内に、所与の資産で発生するかどうかを示す。ブロック１４０４において、方法１４００は、解析システム４００が、少なくとも複数の健全性指標に基づいて、閾値を超える健全性指標に関連する少なくとも１つの変数を判定することを伴い得る。ブロック１４０６において、方法１４００は、解析システム４００が、判定された少なくとも１つの変数に基づいて、健全性指標が閾値より低い複数の資産から、１つまたは複数の資産を識別することを伴い得る。ブロック１４０８において、方法１４００は、解析システム４００が、コンピューティングデバイスに推奨の表現を表示させることを容易にするべく、少なくとも１つの資産関連の変数に関する推奨、および、識別された１つまたは複数の資産を示す推奨データを（例えば、出力システム１０８の）コンピューティングデバイスへ送信することを伴い得る。
【０２４２】
図１５は、解析システム４００によって実行され得る、通常は異常状態インジケータを結果として生じさせる動作データの処理を修正するための例示的な方法１５００のフローチャートを図示する。ブロック１５０２において、方法１５００は、解析システム４００が、１つまたは複数の資産（例えば、資産１０２）における異常状態の１つまたは複数のインスタンスを示す複数の動作データを受信することを伴い得る。ブロック１５０４において、異常状態の１つまたは複数のインスタンスの各々について、方法１５００は、解析システム４００が、コンピューティングデバイスに異常状態の指示を出力させることを容易にするべく、異常状態の所与のインスタンスを示す異常状態インジケータ（例えば、障害コードデータ）を（例えば、出力システム１０８の）コンピューティングデバイスへ送信することを伴い得る。ブロック１５０６において、方法１５００は、解析システム４００が、異常状態の１つまたは複数のインスタンスの各々について、出力された異常状態の指示に対する応答を示すフィードバックデータを受信することを含み得る。ブロック１５０８において、方法１５００は、解析システム４００が、所与の資産での異常状態の追加的なインスタンスを示す追加的な動作データを受信することを伴い得る。ブロック１５１０において、方法１５００は、解析システム４００が、受信されたフィードバックデータ、および、受信された追加的な動作データに基づいて、所与の資産での異常状態の追加的なインスタンスを示す異常状態インジケータをコンピューティングデバイスへ送信することを見合わせることを判定することを伴い得る。
［６．結論］
【０２４３】
開示されたイノベーションの例示的な実施形態について上述した。しかしながら、当業者であれば、特許請求の範囲によって定義される、本発明の真の範囲および思想から逸脱することなく、記載された実施形態に対して変更および修正が加えられ得ることを理解するであろう。
【０２４４】
更に、本明細書に記載された例が、「人間」、「操作者」、「ユーザ」、または、他の実体などの主体によって、実行または開始される動作を伴う場合、これは、単に例および説明の目的に過ぎない。特許請求の範囲は、特許請求の範囲の文言において明示的に指定されている場合を除き、当該主体による措置を必要とするものと解釈されるべきではない。
（項目１）
少なくとも１つのプロセッサと、
非一時的コンピュータ可読媒体と、
前記非一時的コンピュータ可読媒体上に保存されたプログラム命令と、
を備えるコンピューティングシステムであって、
前記プログラム命令は、前記少なくとも１つのプロセッサによって実行可能であり、前記コンピューティングシステムに、
少なくとも、複数の資産についての履歴動作データに基づいて、一群の故障のうち少なくとも１つの故障が、今後の所与の期間内に、資産で発生する可能性が高いかどうかを示す健全性指標を出力するための予測モデルを定義することであって、前記履歴動作データは、（ｉ）過去に前記複数の資産で発生した１つまたは複数の故障に関連する履歴異常状態データと、（ｉｉ）過去の前記複数の資産の動作状態を示す履歴センサデータとを含む、ことと、
所与の資産の少なくとも１つの動作状態を示すセンサデータを受信することと、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障のうち少なくとも１つの故障が今後の前記所与の期間内に前記所与の資産で発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行することと、
前記所与の資産について判定された前記健全性指標の表現をコンピューティングデバイスに表示させることを容易にするべく、前記所与の資産について判定された前記健全性指標を示す健全性指標データを前記コンピューティングデバイスへ送信することと、
を行わせる、コンピューティングシステム。
（項目２）
前記一群の故障は、前記１つまたは複数の故障が発生するときに前記所与の資産を動作不能にし得る１つまたは複数の故障を含む、項目１に記載のコンピューティングシステム。
（項目３）
前記所与の資産の前記健全性指標は、（ｉ）前記一群の故障のうちの、いかなる故障も今後の前記所与の期間内に前記所与の資産で発生しない確率、または、（ｉｉ）前記一群の故障のうちの少なくとも１つの故障が今後の前記所与の期間内に前記所与の資産で発生する確率のうち、１つを含む、項目１または２に記載のコンピューティングシステム。
（項目４）
前記プログラム命令は更に、前記少なくとも１つのプロセッサによって実行可能であり、前記コンピューティングシステムに、
前記所与の資産についての前記健全性指標が閾値より低いことを判定することと、
前記所与の資産についての前記健全性指標が閾値より低いと判定したことに基づいて、前記所与の資産についての前記健全性指標の増加を容易にするための措置を実行させることと、
を行わせる、項目１から３のいずれか一項に記載のコンピューティングシステム。
（項目５）
前記措置を実行させることは、前記コンピューティングデバイスに、前記所与の資産についての前記健全性指標の減少を示すアラートを出力させることを含む、項目４に記載のコンピューティングシステム。
（項目６）
前記措置を実行させることは、前記コンピューティングデバイスに、前記所与の資産に対する１つまたは複数の推奨される修理の指示を出力させることを含む、項目４または５に記載のコンピューティングシステム。
（項目７）
前記措置を実行させることは、前記所与の資産に、１つまたは複数の動作状態を修正させることを含む、項目４から６のいずれか一項に記載のコンピューティングシステム。
（項目８）
前記措置は、複数の措置のうちの１つの措置であり、前記プログラム命令は更に、前記少なくとも１つのプロセッサによって実行可能であり、前記コンピューティングシステムに、
前記措置を実行させた後、前記措置の状態を示すフィードバックデータを判定することと、
前記フィードバックデータに基づいて、前記複数の措置における他の措置より、前記措置を優先化することと、
を行わせる、項目４から７のいずれか一項に記載のコンピューティングシステム。
（項目９）
コンピューティングシステムに、
少なくとも、複数の資産の履歴動作データに基づいて、一群の故障のうち少なくとも１つの故障が今後の所与の期間内に資産で発生する可能性が高いかどうかを示す健全性指標を出力するための予測モデルを定義することであって、前記履歴動作データは、（ｉ）過去に前記複数の資産で発生した１つまたは複数の故障に関連する履歴異常状態データ、および、（ｉｉ）過去の前記複数の資産の動作状態を示す履歴センサデータを備える、ことと、
所与の資産の少なくとも１つの動作状態を示すセンサデータを受信することと、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障のうちの少なくとも１つの故障が今後の前記所与の期間内に前記所与の資産で発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行することと、
コンピューティングデバイスが前記所与の資産についての判定された前記健全性指標の表現を表示させることを容易にするべく、前記所与の資産についての判定された前記健全性指標を示す健全性指標データを前記コンピューティングデバイスへ送信することと、
を行わせるプログラム。
（項目１０）
前記プログラムは更に、前記コンピューティングシステムに、
前記所与の資産についての前記健全性指標は閾値より低いことを判定することと、
前記所与の資産についての前記健全性指標が閾値より低いという判定に基づいて、前記所与の資産についての前記健全性指標の増加を容易にするための措置を実行させることと、
を行わせるように実行可能である、項目９に記載のプログラム。
（項目１１）
前記措置を実行させることは、前記コンピューティングデバイスに、前記所与の資産についての前記健全性指標の減少を示すアラートを出力させることを有する、項目１０に記載のプログラム。
（項目１２）
前記措置を実行させることは、前記コンピューティングデバイスに、前記所与の資産に対する１つまたは複数の推奨される修理の指示を出力させることを有する、項目１０または１１に記載のプログラム。
（項目１３）
前記措置を実行させることは、前記所与の資産に、１つまたは複数の動作状態を修正させることを有する、項目１０から１２のいずれか一項に記載のプログラム。
（項目１４）
前記所与の資産の前記健全性指標は、
（ｉ）前記一群の故障のうちの、いかなる故障も、今後の前記所与の期間内に前記所与の資産で発生しない確率、または、
（ｉｉ）前記一群の故障のうちの少なくとも１つの故障が、今後の前記所与の期間内に前記資産で発生する確率、
のうち１つを有する、項目９に記載のプログラム。
（項目１５）
コンピュータで実装される方法であって、
少なくとも、複数の資産についての履歴動作データに基づいて、一群の故障のうちの少なくとも１つの故障が今後の所与の期間内に資産で発生する可能性が高いかどうかを示す健全性指標を出力するための予測モデルを定義する段階であって、前記履歴動作データは、（ｉ）過去に前記複数の資産で発生した１つまたは複数の故障に関連する履歴異常状態データ、および、（ｉｉ）過去の前記複数の資産の動作状態を示す履歴センサデータを有する、段階と、
所与の資産の少なくとも１つの動作状態を示すセンサデータを受信する段階と、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障のうちの少なくとも１つの故障が今後の前記所与の期間内に前記所与の資産で発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行する段階と、
コンピューティングデバイスに、前記所与の資産についての判定された前記健全性指標の表現を表示させることを容易にするべく、前記所与の資産についての判定された前記健全性指標を示す健全性指標データを前記コンピューティングデバイスへ送信する段階と、
を備える、コンピュータで実装される方法。
（項目１６）
前記所与の資産についての前記健全性指標は、
（ｉ）前記一群の故障のうちの、いかなる故障も、今後の前記所与の期間内に前記所与の資産で発生しない確率、または、
（ｉｉ）前記一群の故障のうちの、少なくとも１つの故障が、今後の前記所与の期間内に、前記所与の資産で発生する確率、
のうち１つを有する、項目１５に記載のコンピュータで実装される方法。
（項目１７）
前記所与の資産についての前記健全性指標が閾値より低いことを判定する段階と、
前記所与の資産についての前記健全性指標が閾値より低いという判定に基づいて、前記所与の資産についての前記健全性指標の増加を容易にする措置を実行させる段階と、
を更に有する、項目１５または１６に記載のコンピュータで実装される方法。
（項目１８）
前記措置を実行させる段階は、前記コンピューティングデバイスに、前記所与の資産についての前記健全性指標の減少を示すアラートを出力させる段階を備える、項目１７に記載のコンピュータで実装される方法。
（項目１９）
前記措置を実行させる段階は、前記コンピューティングデバイスに、前記所与の資産に対する１つまたは複数の推奨される修理の指示を出力させる段階を備える、項目１７または１８に記載のコンピュータで実装される方法。
（項目２０）
前記措置を実行させる段階は、前記所与の資産に、１つまたは複数の動作状態を修正させる段階を備える、項目１７から１９のいずれか一項に記載のコンピュータで実装される方法。
（項目２１）
少なくとも１つのプロセッサと、
非一時的コンピュータ可読媒体と、
前記非一時的コンピュータ可読媒体上に保存されたプログラム命令と、
を備えるコンピューティングシステムであって、
前記プログラム命令は、前記少なくとも１つのプロセッサによって実行可能であり、前記コンピューティングシステムに、
資産の所与のサブシステムに関連する、少なくとも１つの異常状態インジケータを識別することと、
識別された前記少なくとも１つの異常状態インジケータに基づいて、複数の資産についての履歴動作データのサブセットを識別することであって、前記履歴動作データは、（ｉ）過去に前記複数の資産で発生した１つまたは複数の故障に関連する履歴異常状態データと、（ｉｉ）過去の前記複数の資産の動作状態を示す履歴センサデータとを含む、ことと、
前記履歴動作データの識別された前記サブセットに基づいて、一群の故障のうちの少なくとも１つの故障が今後の所与の期間内に前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を出力するための予測モデルを定義することと、
所与の資産の少なくとも１つの動作状態を示すセンサデータを受信することと、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障のうちの少なくとも１つの故障が今後の前記所与の期間内に前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行することと、
前記所与の資産について判定された前記健全性指標の表現をコンピューティングデバイスに表示させることを容易にするべく、前記所与の資産について判定された前記健全性指標を示す健全性指標データを前記コンピューティングデバイスへ送信することと、
を実行させる、コンピューティングシステム。
（項目２２）
前記所与のサブシステムに関連する前記少なくとも１つの異常状態インジケータを識別することは、
前記所与のサブシステムに関連する１つまたは複数のセンサを識別することと、
前記１つまたは複数のセンサに対応する１つまたは複数の異常状態インジケータを識別することであって、前記１つまたは複数の異常状態インジケータは、前記少なくとも１つの異常状態インジケータを含む、ことと、
を有する、項目２１に記載のコンピューティングシステム。
（項目２３）
前記所与のサブシステムに関連する前記１つまたは複数のセンサを識別することは、前記履歴動作データ、および、履歴修理データまたはセンサ属性のうち少なくとも１つに基づいて、前記所与のサブシステムに関連する前記１つまたは複数のセンサを識別することを有する、項目２２に記載のコンピューティングシステム。
（項目２４）
前記一群の故障は、１つまたは複数の故障が発生するときに前記所与のサブシステムを動作不能にさせ得る、前記１つまたは複数の故障を含む、項目２１または２２に記載のコンピューティングシステム。
（項目２５）
前記少なくとも１つの異常状態インジケータは、複数の異常状態インジケータを含み、前記一群の故障のうちの各故障は、前記複数の異常状態インジケータのうち少なくとも１つの異常状態インジケータに対応する、項目２１、２２、または２４のいずれか一項に記載のコンピューティングシステム。
（項目２６）
前記健全性指標を出力するための前記予測モデルは、今後の前記所与の期間内に前記複数の異常状態インジケータのうちいずれかがトリガされる確率を出力する予測モデルを含む、項目２５に記載のコンピューティングシステム。
（項目２７）
前記プログラム命令は更に、前記少なくとも１つのプロセッサによって実行可能であり、前記所与の資産についての判定された前記健全性指標に基づいて、前記所与の資産についての前記健全性指標を修正することを容易にするべく、措置を実行させることを前記コンピューティングシステムに行わせる、項目２１、２２、２４、または２５のいずれか一項に記載のコンピューティングシステム。
（項目２８）
前記措置を実行させることは、部品注文システムに、前記所与の資産の前記所与のサブシステムのコンポーネントを注文させることを容易にするべく、部品注文データを前記部品注文システムへ送信することを含む、項目２７に記載のコンピューティングシステム。
（項目２９）
前記措置を実行させることは、前記所与の資産に、前記所与のサブシステムの動作状態を修正させることを含む、項目２７または２８に記載のコンピューティングシステム。
（項目３０）
前記所与の資産についての前記健全性指標は、（ｉ）前記一群の故障のうちの、いかなる故障も、今後の前記所与の期間内に前記所与のサブシステムで発生しない確率、または、（ｉｉ）前記一群の故障のうちの少なくとも１つの故障が、今後の前記所与の期間内に前記所与のサブシステムで発生する確率のうちの１つを含む、項目２１、２２、２４、２５、または、２７のいずれか一項に記載のコンピューティングシステム。
（項目３１）
コンピューティングシステムに、
資産の所与のサブシステムに関連する少なくとも１つの異常状態インジケータを識別することと、
前記識別された少なくとも１つの異常状態インジケータに基づいて、複数の資産についての履歴動作データのサブセットを識別することであって、前記履歴動作データは、（ｉ）過去の前記複数の資産で発生した１つまたは複数の故障に関連する履歴異常状態データ、および、（ｉｉ）過去の前記複数の資産の動作状態を示す履歴センサデータを含む、ことと、
前記履歴動作データの識別された前記サブセットに基づいて、一群の故障における少なくとも１つの故障が、今後の所与の期間内に前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を出力するための予測モデルを定義することと、
所与の資産の少なくとも１つの動作状態を示すセンサデータを受信することと、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障のうちの少なくとも１つの故障が今後の前記所与の期間内に前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行することと、
コンピューティングデバイスに、前記所与の資産について判定された前記健全性指標の表現を表示させることを容易にするべく、前記所与の資産についての判定された前記健全性指標を示す健全性指標データを前記コンピューティングデバイスへ送信することと、
を実行させるプログラム。
（項目３２）
前記所与のサブシステムに関連する前記少なくとも１つの異常状態インジケータを識別することは、
前記所与のサブシステムに関連する１つまたは複数のセンサの識別することと、
前記１つまたは複数のセンサに対応する１つまたは複数の異常状態インジケータを識別することであって、前記１つまたは複数の異常状態インジケータは、前記少なくとも１つの異常状態インジケータを含む、ことと、
を含む、項目３１に記載のプログラム。
（項目３３）
前記所与のサブシステムに関連する前記１つまたは複数のセンサを識別することは、前記履歴動作データ、および、履歴修理データまたはセンサ属性のうち少なくとも１つに基づく前記所与のサブシステムに関連する前記１つまたは複数のセンサを識別することを含む、項目３２に記載のプログラム。
（項目３４）
前記少なくとも１つの異常状態インジケータは、複数の異常状態インジケータを含み、前記一群の故障のうちの各故障は、前記複数の異常状態インジケータにおける少なくとも１つの異常状態インジケータに対応する、項目３１に記載のプログラム。
（項目３５）
前記健全性指標を出力するための前記予測モデルは、前記複数の異常状態インジケータのいずれかが今後の前記所与の期間内にトリガされる確率を出力するための予測モデルを含む、項目３４に記載のプログラム。
（項目３６）
前記プログラムは更に、前記コンピューティングシステムに、前記所与の資産について判定された前記健全性指標に基づいて、前記所与の資産についての前記健全性指標を修正することを容易にするべく、措置を実行させることを行わせるように実行可能である、項目３１に記載のプログラム。
（項目３７）
前記措置を実行させることは、前記所与の資産に、前記所与のサブシステムの動作状態を修正させることを含む、項目３６に記載のプログラム。
（項目３８）
コンピュータで実装される方法であって、
資産の所与のサブシステムに関連する少なくとも１つの異常状態インジケータを識別する段階と、
識別された前記少なくとも１つの異常状態インジケータに基づいて、複数の資産についての履歴動作データのサブセットを識別する段階であって、前記履歴動作データは、（ｉ）過去に前記複数の資産で発生した１つまたは複数の故障に関連する履歴異常状態データ、および、（ｉｉ）過去の前記複数の資産の動作状態を示す履歴センサデータを含む、段階と、
前記履歴動作データの識別された前記サブセットに基づいて、一群の故障のうちの少なくとも１つの故障が、今後の所与の期間内に前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を出力するための予測モデルを定義する段階と、
所与の資産の少なくとも１つの動作状態を示すセンサデータを受信する段階と、
受信された前記センサデータに基づいて、前記所与の資産について、前記一群の故障のうちの少なくとも１つの故障が今後の前記所与の期間内に前記所与のサブシステムで発生する可能性が高いかどうかを示す健全性指標を判定するべく、前記予測モデルを実行する段階と、
コンピューティングデバイスに、前記所与の資産について判定された前記健全性指標の表現を表示させることを容易にするべく、前記所与の資産について判定された前記健全性指標を示す健全性指標データを前記コンピューティングデバイスへ送信する段階と、
を備えるコンピュータで実装される方法。
（項目３９）
前記所与のサブシステムに関連する前記少なくとも１つの異常状態インジケータを識別する段階は、
前記所与のサブシステムに関連する１つまたは複数のセンサを識別する段階と、
前記１つまたは複数のセンサに対応する１つまたは複数の異常状態インジケータを識別する段階であって、前記１つまたは複数の異常状態インジケータは、前記少なくとも１つの異常状態インジケータを含む、段階と、
を有する、項目３８に記載のコンピュータで実装される方法。
（項目４０）
前記所与のサブシステムに関連する前記１つまたは複数のセンサを識別する段階は、前記履歴動作データ、および、履歴修理データまたはセンサ属性のうち少なくとも１つに基づいて、前記所与のサブシステムに関連する前記１つまたは複数のセンサを判定する段階を有する、項目３９に記載のコンピュータで実装される方法。
（項目４１）
少なくとも１つのプロセッサと、
非一時的コンピュータ可読媒体と、
前記非一時的コンピュータ可読媒体上に保存されるプログラム命令と、
を備える、コンピューティングシステムであって、
前記プログラム命令は、前記少なくとも１つのプロセッサによって実行可能であり、前記コンピューティングシステムに、
資産の組についての動作データを受信することと、
前記受信された動作データに基づいて、前記資産の組の各資産について、一群の故障のうちの少なくとも１つの故障が今後の所与の期間内に前記資産で発生する可能性が高いかどうかを示す、それぞれの健全性指標を判定するべく、予測モデルを実行することと、
前記資産の組における各資産について、それぞれの前記健全性指標を監視することと、
前記資産の組における任意の資産を有する、資産のサブセットを識別することであって、前記資産のサブセットに含まれる、監視される健全性指標は、閾値条件を満たす、ことと、
少なくとも、識別された前記資産のサブセットについての資産関連データに基づいて、識別された前記資産のサブセットに関連する、少なくとも１つの影響変数を識別することと、
識別された前記少なくとも１つの影響変数に基づいて、資産健全性に関連する少なくとも１つの推奨を生成することと、
コンピューティングデバイスに前記少なくとも１つの推奨の表現を表示させることを容易にする、前記少なくとも１つの推奨を示す推奨データを、前記コンピューティングデバイスへ送信することと、
を行わせる、コンピューティングシステム。
（項目４２）
前記少なくとも１つの影響変数は、資産変数、操作者変数、メンテナンス変数のうち、少なくとも１つを含む、項目４１に記載のコンピューティングシステム。
（項目４３）
前記少なくとも１つの影響変数は、前記資産変数を含み、前記資産変数は、資産クラス、資産移動スケジュール、資産積載物、または、資産環境を含む、項目４２に記載のコンピューティングシステム。
（項目４４）
前記少なくとも１つの影響変数は、前記操作者変数を含み、前記操作者変数は、操作者識別子、操作者スケジュール、操作者習慣を含む、項目４２または４３に記載のコンピューティングシステム。
（項目４５）
前記少なくとも１つの影響変数は、前記メンテナンス変数を含み、前記メンテナンス変数は、修理の場所、修理業者識別子、または、整備士識別子を含む、項目４２から４４のいずれか一項に記載のコンピューティングシステム。
（項目４６）
少なくとも、識別された前記資産のサブセットについての前記資産関連データに基づいて、前記少なくとも１つの影響変数を識別することは、動作データまたはメンテナンスデータのうち少なくとも１つに基づいて、前記少なくとも１つの影響変数を識別することを含む、項目４１に記載のコンピューティングシステム。
（項目４７）
前記少なくとも１つの影響変数は、資産を修理する整備士を識別する整備士識別子を含み、前記少なくとも１つの推奨は、識別された前記整備士を使用するという推奨を含む、項目４１または４６に記載のコンピューティングシステム。
（項目４８）
前記少なくとも１つの影響変数は、所与の資産クラスを含み、前記少なくとも１つの推奨は、前記所与の資産クラスの資産を購入するという推奨を含む、項目４１、４６、または４７のいずれか一項に記載のコンピューティングシステム。
（項目４９）
前記少なくとも１つの影響変数は、動作状態の範囲を示す操作者習慣を含み、前記プログラム命令は更に前記少なくとも１つのプロセッサによって実行可能であり、識別された前記資産の組のうち少なくとも１つの資産に対して、前記少なくとも１つの資産を前記動作状態の範囲に従って動作させることを容易にするコマンドを送信することを前記コンピューティングシステムに実行させる、項目４１、４６から４８のいずれか一項に記載のコンピューティングシステム。
（項目５０）
識別された前記資産のサブセットについての前記資産関連データは、識別された前記資産のサブセットについての監視される前記健全性指標に基づいて識別される、項目４１、４６から４９のいずれか一項に記載のコンピューティングシステム。
（項目５１）
識別された前記少なくとも１つの影響変数に基づいて、前記少なくとも１つの推奨を生成することは、
前記資産の組における所与の資産が前記少なくとも１つの影響変数の閾値基準を満たしていないと判定することと、
前記判定に応答して、前記所与の資産の前記資産健全性を改善するための推奨を生成することと、
を含む、項目４１、４６から５０のいずれか一項に記載のコンピューティングシステム。
（項目５２）
コンピューティングシステムに、
資産の組の動作データを受信することと、
受信された前記動作データに基づいて、前記資産の組における各資産について、一群の故障のうちの少なくとも１つの故障が今後の所与の期間内に前記資産で発生する可能性が高いかどうかを示す、それぞれの健全性指標を判定するべく、予測モデルを実行することと、
前記資産の組における各資産について、それぞれの前記健全性指標を監視することと、
前記資産の組における任意の資産を有する、資産のサブセットを識別することであって、前記資産のサブセットに含まれる、監視された健全性指標は閾値条件を満たす、ことと、
少なくとも、識別された前記資産のサブセットについての資産関連データに基づいて、識別された前記資産のサブセットに関連する少なくとも１つの影響変数を識別することと、
識別された前記少なくとも１つの影響変数に基づいて、資産健全性に関連する少なくとも１つの推奨を生成することと、
コンピューティングデバイスに前記少なくとも１つの推奨の表現を表示させることを容易にするべく、前記少なくとも１つの推奨を示す推奨データを前記コンピューティングデバイスへ送信することと、
を実行させるプログラム。
（項目５３）
少なくとも、前記識別された資産のサブセットについての前記資産関連データに基づいて、前記少なくとも１つの影響変数を識別することは、動作データまたはメンテナンスデータのうち少なくとも１つに基づいて、前記少なくとも１つの影響変数を識別することを含む、項目５２に記載のプログラム。
（項目５４）
前記少なくとも１つの影響変数は、資産を修理する整備士を識別する整備士識別子を含み、前記少なくとも１つの推奨は、識別された前記整備士を使用するという推奨を含む、項目５２または５３に記載のプログラム。
（項目５５）
前記少なくとも１つの影響変数は、所与の資産クラスを含み、前記少なくとも１つの推奨は、前記所与の資産クラスの資産を購入するという推奨を含む、項目５２から５４のいずれか一項に記載のプログラム。
（項目５６）
識別された前記資産のサブセットについての前記資産関連データは、識別された前記資産のサブセットについての、監視された前記健全性指標に基づいて識別される、項目５２から５５のいずれか一項に記載のプログラム。
（項目５７）
識別された前記少なくとも１つの影響変数に基づいて、前記少なくとも１つの推奨を生成することは、
前記資産の組における所与の資産が、前記少なくとも１つの影響変数の閾値基準を満たさないことを判定することと、
前記判定に応答して、前記所与の資産の前記資産健全性を改善するための推奨を生成することと、
を含む、項目５２から５６のいずれか一項に記載のプログラム。
（項目５８）
コンピュータで実装される方法であって、
資産の組についての動作データを受信する段階と、
受信された前記動作データに基づいて、前記資産の組における各資産について、一群の故障のうちの少なくとも１つの故障が今後の所与の期間内に前記資産で発生する可能性が高いかどうかを示す、それぞれの健全性指標を判定するべく、予測モデルを実行する段階と、
前記資産の組における各資産についてのそれぞれの前記健全性指標を監視する段階と、
前記資産の組における任意の資産を有する資産のサブセットを識別する段階であって、前記資産のサブセットに含まれる、監視される健全性指標は閾値条件を満たす、段階と、
少なくとも、識別された前記資産のサブセットについての資産関連データに基づいて、識別された前記資産のサブセットに関連する少なくとも１つの影響変数を識別する段階と、
識別された前記少なくとも１つの影響変数に基づいて、資産健全性に関連する少なくとも１つの推奨を生成する段階と、
コンピューティングデバイスに前記少なくとも１つの推奨の表現を表示させることを容易にするべく、前記少なくとも１つの推奨を示す推奨データを前記コンピューティングデバイスへ送信する段階と、
を備える、コンピュータで実装される方法。
（項目５９）
識別された前記資産のサブセットについての前記資産関連データは、識別された前記資産のサブセットについての監視される前記健全性指標に基づいて識別される、項目５８に記載のコンピュータで実装される方法。
（項目６０）
識別された前記少なくとも１つの影響変数に基づいて、前記少なくとも１つの推奨を生成する段階は、
前記資産の組における所与の資産は、前記少なくとも１つの影響変数についての閾値基準を満たさないと判定する段階と、
前記判定に応答して、前記所与の資産の前記資産健全性を改善するための推奨を生成する段階と、
を含む、項目５８または５９に記載のコンピュータで実装される方法。
【図１】
0006652247.tif 000002
【図２】
0006652247.tif 000003
【図３】
0006652247.tif 000004
【図４】
0006652247.tif 000005
【図５Ａ】
0006652247.tif 000006
【図５Ｂ】
0006652247.tif 000007
【図６】
0006652247.tif 000008
【図７】
0006652247.tif 000009
【図８Ａ】
0006652247.tif 000010
【図８Ｂ】
0006652247.tif 000011
【図９】
0006652247.tif 000012
【図１０】
0006652247.tif 000013
【図１１】
0006652247.tif 000014
【図１２】
0006652247.tif 000015
【図１３】
0006652247.tif 000016
【図１４】
0006652247.tif 000017
【図１５】
0006652247.tif 000018