(57)【要約】  ルーティングテーブルの更新に関連する、資産、予測モデルおよび対応するワークフローに関連する、システム、デバイス、および方法が本明細書に開示される。具体的には、例は、予測モデルに基づいて、メッシュネットワークにおける複数の資産のうちの所与の資産が将来の所与の期間内に利用不可能になる可能性がある旨を決定することと、決定に応答して、メッシュネットワークにおける少なくとも１つの他の資産に関するルーティング設定を更新させることとを伴う。
2018528693.tif 000002
【特許請求の範囲】
【請求項１】
予測モデルに基づいて、メッシュネットワークにおける複数の資産のうちの所与の資産が、将来の所与の期間内に利用不可能になる可能性がある旨を決定する段階と、
決定する前記段階に応答して、前記メッシュネットワークにおける少なくとも１つの他の資産に関するルーティング設定を更新させる段階と、を備える、
コンピュータ実装方法。
【請求項２】
前記複数の資産のうちの前記所与の資産が利用不可能になる可能性がある旨を決定する前記段階が、
前記所与の資産からセンサデータを受信する段階と、
前記予測モデルを前記センサデータに適用することに基づいて、前記所与の資産に関する健全性スコアを決定する段階と、
前記所与の資産に関する前記健全性スコアが、利用不可能性尤度閾値を満たしている旨を決定する段階と、
を含む、請求項１に記載のコンピュータ実装方法。
【請求項３】
前記所与の資産に関する前記健全性スコアが前記利用不可能性尤度閾値を満たしている旨を決定する前記段階が、前記所与の資産が一定の期間の間、前記利用不可能性尤度閾値を満たしている旨を決定する段階を含む、請求項２に記載のコンピュータ実装方法。
【請求項４】
前記所与の資産が、前記所与の資産の故障、前記所与の資産のオフライン化、前記所与の資産に関して予定された休止期間、または、前記所与の資産が前記メッシュネットワークを介して通信不可能になること、のうち少なくとも１つに基づいて利用不可能になる可能性がある、請求項１から３のいずれか一項に記載のコンピュータ実装方法。
【請求項５】
前記複数の資産が、輸送用機械、工業用機械、医療用機械、またはユーティリティ設備のうち少なくとも１つを含む、請求項１から４のいずれか一項に記載のコンピュータ実装方法。
【請求項６】
前記メッシュネットワークにおける少なくとも１つの他の資産に関する前記ルーティング設定を更新させる前記段階が、
前記所与の資産が、前記メッシュネットワークにおける前記複数の資産のうち１つに、前記将来の前記所与の期間内に利用不可能になる可能性がある旨の決定を伝送する段階を備え、
前記メッシュネットワークにおける前記複数の資産のうち前記１つが、それのルーティング設定を更新する、
請求項１から５のいずれか一項に記載のコンピュータ実装方法。
【請求項７】
前記メッシュネットワークにおける少なくとも１つの他の資産に関する前記ルーティング設定を更新させる前記段階が、前記所与の資産が、前記メッシュネットワークにおける少なくとも１つの他の資産に、前記将来の前記所与の期間内に利用不可能になる可能性がある旨の決定を伝送することを備える、請求項１から６のいずれか一項に記載のコンピュータ実装方法。
【請求項８】
予測モデルに基づいて、メッシュネットワークにおける複数の資産のうち所与の資産が、将来の所与の期間内に利用不可能になる可能性がある旨を決定する手順と、
決定する前記手順に応答して、前記メッシュネットワークにおける少なくとも１つの他の資産に関するルーティング設定を更新させる手順と、
を演算処理システムに実施させるための、
コンピュータプログラム。
【請求項９】
前記複数の資産のうちの前記所与の資産が利用不可能になる可能性がある旨を決定する前記手順が、
前記所与の資産からセンサデータを受信する手順と、
前記予測モデルを前記センサデータに適用することに基づいて、前記所与の資産に関する健全性スコアを決定する手順と、
前記所与の資産に関する前記健全性スコアが、利用不可能性尤度閾値を満たしている旨を決定する手順と、
を含む、請求項８に記載のコンピュータプログラム。
【請求項１０】
前記所与の資産に関する前記健全性スコアが前記利用不可能性尤度閾値を満たしている旨を決定する前記手順が、前記所与の資産が一定の期間の間、前記利用不可能性尤度閾値を満たしている旨を決定する段階を含む、請求項９に記載のコンピュータプログラム。
【請求項１１】
前記所与の資産が、前記所与の資産の故障、前記所与の資産のオフライン化、前記所与の資産に関して予定された休止期間、または、前記所与の資産が前記メッシュネットワークを介して通信不可能になること、のうち少なくとも１つに基づいて利用不可能になる可能性がある、請求項８から１０のいずれか一項に記載のコンピュータプログラム。
【請求項１２】
前記複数の資産が、輸送用機械、工業用機械、医療用機械、またはユーティリティ設備のうち少なくとも１つを含む、請求項８から１１のいずれか一項に記載のコンピュータプログラム。
【請求項１３】
前記メッシュネットワークにおける少なくとも１つの他の資産に関する前記ルーティング設定を更新させる前記手順が、
前記所与の資産が、前記メッシュネットワークにおける前記複数の資産のうち１つに、前記将来の前記所与の期間内に利用不可能になりそうな旨の決定を伝送する手順を備え、
前記メッシュネットワークにおける前記複数の資産のうち前記１つが、それのルーティング設定を更新する、
請求項８から１２のいずれか一項に記載のコンピュータプログラム。
【請求項１４】
前記メッシュネットワークにおける少なくとも１つの他の資産に関する前記ルーティング設定を更新させる前記手順が、前記所与の資産が、前記メッシュネットワークにおける少なくとも１つの他の資産に、前記将来の前記所与の期間内に利用不可能になる可能性がある旨の決定を伝送することを備える、請求項８から１３のいずれか一項に記載のコンピュータプログラム。
【請求項１５】
少なくとも１つのプロセッサと、
非一時的コンピュータ可読媒体と、
予測モデルに基づいて、メッシュネットワークにおける複数の資産のうち所与の資産が、将来の所与の期間内に利用不可能になる可能性がある旨を決定する手順、および、
決定する前記手順に応答して、前記メッシュネットワークにおける少なくとも１つの他の資産に関するルーティング設定を更新させる手順
を演算処理システムに行わせるように前記少なくとも１つのプロセッサによって実施可能な、前記非一時的コンピュータ可読媒体に格納されたプログラム命令と
を備える、演算処理システム。
【請求項１６】
前記複数の資産のうちの前記所与の資産が利用不可能になる可能性がある旨を決定する前記手順が、
前記所与の資産からセンサデータを受信する手順と、
前記予測モデルを前記センサデータに適用することに基づいて、前記所与の資産に関する健全性スコアを決定する手順と、
前記所与の資産に関する前記健全性スコアが、利用不可能性尤度閾値を満たしている旨を決定する手順と、
を含む、請求項１５に記載の演算処理システム。
【請求項１７】
前記所与の資産に関する前記健全性スコアが前記利用不可能性尤度閾値を満たしている旨を決定する前記手順が、前記所与の資産が一定の期間の間、前記利用不可能性尤度閾値を満たしている旨を決定する段階を含む、請求項１６に記載の演算処理システム。
【請求項１８】
前記所与の資産が、前記所与の資産の故障、前記所与の資産のオフライン化、前記所与の資産に関して予定された休止期間、または、前記所与の資産が前記メッシュネットワークを介して通信不可能になること、のうち少なくとも１つに基づいて利用不可能になる可能性がある、請求項１５から１７のいずれか一項に記載の演算処理システム。
【請求項１９】
前記複数の資産が、輸送用機械、工業用機械、医療用機械、またはユーティリティ設備のうち少なくとも１つを含む、請求項１５から１８のいずれか一項に記載の演算処理システム。
【請求項２０】
前記メッシュネットワークにおける少なくとも１つの他の資産に関する前記ルーティング設定を更新させる前記手順が、
前記所与の資産が、前記メッシュネットワークにおける前記複数の資産のうち１つに、前記将来の前記所与の期間内に利用不可能になりそうな旨の決定を伝送する手順を備え、
前記メッシュネットワークにおける前記複数の資産のうち前記１つが、それのルーティング設定を更新する、
請求項１５から１９のいずれか一項に記載の演算処理システム。
【発明の詳細な説明】
【関連出願】
【０００１】
［関連出願の相互参照］
本出願は、それの全体が参照により本明細書に組み込まれる、２０１５年９月１４日に出願され、「資産の利用可能性に基づくメッシュネットワークルーティング」と題された、米国非仮特許出願第１４／８５３，１８９号の優先権を主張する。
【０００２】
さらに、本出願は、２０１５年６月５日に出願され、「資産健全性スコア」と題された、米国非仮特許出願第１４／７３２，２５８号、および、２０１５年６月１９日に出願され、「ローカル実施のための一括予測モデルおよびワークフロー」と題された、米国非仮特許出願第１４／７４４，３５２号を、参照により組み込み、それらのそれぞれは全体として組み込まれる。
【背景技術】
【０００３】
現在では、多くの業界において、機械（本明細書ではまた「資産（ａｓｓｅｔ）」とも呼ばれる）が広く使用される。国々を超えて貨物を運ぶ機関車から、看護師および医師が生命を救うことの助けとなる医療機器まで、資産は日常生活において重要な役割を果たす。資産が果たす役割に応じて、その複雑性およびコストは変わり得る。例えば、いくつかの資産は、資産が適切に機能するように調和して動作する必要がある複数のサブシステム（例えば、機関車のエンジン、変速機など）を含み得る。
【０００４】
資産が日常生活で果たす役割は重要であるので、資産は限られた休止期間の間に修理可能なことが望ましい。したがって、ある者は、資産内の異常状態を監視および検出して、おそらく最小の休止期間で資産の修理を容易にするための機構を開発した。
［概要］
【０００５】
資産を監視するための現在の手法は、資産の動作状態を監視する、資産の全体にわたって分布する様々なセンサから信号を受信する資産内コンピュータを一般に伴う。１つの代表例として、資産が機関車である場合、センサは数ある例の中でも、温度、電圧、および速度などのパラメータを監視し得る。１つまたは複数のセンサからのセンサ信号が特定の値に達した場合、資産内コンピュータは次に、異常状態が資産内に生じた旨の指示となる、「障害コード」などの異常状態インジケータを生成し得る。
【０００６】
一般的に、異常状態は資産またはそれらの要素における不具合となり得、それは資産および／または要素の故障につながり得る。したがって、異常状態が所与の故障または複数の故障の徴候となるという点で、異常状態は、当該所与の故障、またはおそらく複数の故障と関連づけられ得る。実際において、ユーザは通常、各異常状態インジケータに関連づけられる、センサおよびそれぞれのセンサ値を定義する。すなわち、ユーザは資産の「正常な」動作状態（例えば、障害コードをトリガしない動作状態）、および「異常な」動作状態（例えば、障害コードをトリガする動作状態）を定義する。
【０００７】
資産内コンピュータが異常状態インジケータを生成した後、インジケータおよび／またはセンサ信号は、ユーザが異常状態の何らかの指示および／またはセンサ信号を受信することができ、行動をとるかどうか判定することができる、リモートな位置に送られ得る。ユーザがとり得るであろう１つの行動は、資産を評価し、修理する可能性がある整備士などを指名することである。資産において一旦、整備士は資産を演算処理デバイスと接続して演算処理デバイスを動作させ、生成されたインジケータの原因の診断を容易にするための、１つまたは複数のローカルな診断ツールを資産に利用させ得る。
【０００８】
現在の資産監視システムは一般に、異常状態インジケータをトリガするという点で効果的である一方、そのようなシステムは通常、保守的である。すなわち、資産監視システムがインジケータをトリガする時までに、資産内の故障は既に生じている（または、直ちに生じようとしている）可能性があり、それは数ある不利益の中でも、コストがかかる休止期間につながり得る。さらに、そのような資産監視システムにおける資産内異常検出機構の単純な性質に起因して、現在の資産監視手法は、資産に関する演算の監視を実行し、次に、問題が検出された場合には資産に命令を伝送する、リモート演算処理システムを伴う傾向がある。資産が通信ネットワークのサービスエリアの外側に動くときには、このことは、ネットワークレイテンシに起因して不利なことがあり、および／または、実行できないことがある。
【０００９】
現場における資産は、特定の目的のためのメッシュネットワーク内に形成され得る。例えば、仕事創出現場は、位置データ、ステータスデータなどの情報を互いに通信する、資産を含み得る。メッシュネットワークは、資産間の通信を可能にすべく、安価で信頼できるやり方を提供し得る。メッシュネットワークにおける各資産は、データがメッシュネットワーク内を移動する１つまたは複数の経路を決定すべく、ルーティング設定を用い得る。例えば、第１の資産は、最短のレイテンシ、最短の距離、最小の移動時間、最小のエネルギー消費などを含む様々な要因に応じて、第２の資産または第３の資産にデータを伝送するかどうか決定し得る。ルーティング設定は、ルーティングテーブルを含む１つまたは複数の経路を格納するための、異なるデータ構造を含み得る。
【００１０】
メッシュネットワークにおける１つまたは複数の資産は、メッシュネットワークの外側のデータをリモート演算処理システムに伝送すべく、通信ネットワークを用い得る。この資産は、メッシュネットワークにおける資産に、追加のネットワークリソースへのアクセスを提供するので、この資産は「ゲートウェイ」として知られることがある。
【００１１】
メッシュネットワークにおける資産は、センサデータを生成するセンサを含む。資産は、資産がゲートウェイである場合に通信ネットワークにアクセスすることによって、または、センサデータをゲートウェイに伝送することによって、センサデータをリモート演算処理システムに伝送し得る。
【００１２】
リモートシステムは、資産の動作に関連する、予測モデルおよび対応するワークフロー（本明細書では「モデル・ワークフロー対」と呼ばれる）を定義する。予測モデルは、リモートシステム自体において実施され得るか、資産によってローカルに実施され得るかのいずれかである。例えば、資産は、モデル・ワークフロー対を受信し、モデル・ワークフロー対に従って動作するローカル分析デバイスを利用すべく構成され得る。
【００１３】
一般に、モデル・ワークフロー対は、資産に、特定の動作状態を監視させ得、特定の状態が存在するとき、特定のイベントの発生の妨げを容易にするのに役立ち得る挙動を、修正させ得る。具体的には、予測モデルは、特定のセットの資産センサから、入力としてセンサデータを受信し得、所与の資産が将来の所与の期間内に利用不可能となるであろう可能性を出力し得る。ワークフローは、モデルによって出力される１つまたは複数の特定のイベントの可能性に基づいて実行される、１つまたは複数の動作を伴い得る。
【００１４】
実際には、リモート演算処理システムは、一括予測モデルおよび対応するワークフロー、個別予測モデルおよび対応するワークフロー、またはそれらの何らかの組み合わせを定義し得る。「一括」モデル／ワークフローは、一群の資産に関する汎用のモデル／ワークフローを指し得る一方、「個別」モデル／ワークフローは、単一の資産、または一群の資産からの部分群の資産のために用意されたモデル／ワークフローを指し得る。
【００１５】
本開示に従うと、ある特定のモデル・ワークフロー対が、メッシュネットワークのルーティングテーブルを更新させるためのワークフローをトリガする予測故障モデルとなり得る。このモデル・ワークフロー対は、リモート演算処理システムにおいて実施され得る（その場合、リモート演算処理システムはそれらのそれぞれのルーティングテーブルを更新するように、メッシュ内の資産に命令するであろう）か、または、資産自体においてローカルに実施され得る（その場合、資産はテーブルを更新するように、メッシュ内の他の資産に命令するであろう）。
【００１６】
予測故障モデルは様々な形態をとり得る。その１つの例は、予測故障モデルが資産の健全性を監視して資産に関する健全性指標（例えば「健全性スコア」）を出力する、健全性スコアモデルである。それは、将来への所与の時間枠内に所与の資産に故障が発生するであろうかどうか（従って、所与の資産が利用不可能になるであろうかどうか）を示す、単一の一括指標である。具体的には、健全性指標は、将来への所与の時間枠内に、一群の故障からのいかなる故障も資産に生じないであろう可能性を示し得る。または、健全性指標は、将来への所与の時間枠内に、一群の故障からの少なくとも１つの故障が資産に発生するであろう可能性を示し得る。ルーティングテーブルを更新させるワークフローは、様々な形態をとり得る。その１つの例は、健全性スコアが特定の閾値以下に下がるときにトリガされるワークフローである。
【００１７】
一旦、所与の資産が将来の所与の期間内に利用不可能となる可能性があると決定されると、メッシュネットワークにおける少なくとも１つの他の資産に関するルーティング設定が更新される。例えば、リモート演算処理システムは、メッシュネットワークにおける複数の資産のうち１つに、所与の資産が将来の所与の期間内に利用不可能になる可能性がある旨の決定を伝送し得る。その資産は、次に、それのルーティング設定を更新し、決定をメッシュネットワークにおける別の資産に伝送する。別の例において、リモート演算処理システムは、対応する更新されたルーティング設定を、メッシュネットワークにおける１つまたは複数の資産に送信し得る。
【００１８】
本明細書で開示された例示的なシステム、デバイス、および方法は、これらの課題のうち１つまたは複数に取り組むことの助けを意図している。例示的な実装態様において、ネットワーク構成は、資産とリモート演算処理システムとの間での通信を容易にする通信ネットワークを含み得る。
【００１９】
当業者は、以下の開示を読むことで、これらの、ならびに多数の他の態様を理解するであろう。
【図面の簡単な説明】
【００２０】
【図１】例示的な実施形態が実装され得る例示的なネットワーク構成を示す図を示す。
【００２１】
【図２】例示的な資産の簡略ブロック図を示す。
【００２２】
【図３】例示的な異常状態インジケータおよびトリガ基準の概念図を示す。
【００２３】
【図４】メッシュネットワークの概念図を示す。
【００２４】
【図５】例示的な分析システムの簡略ブロック図を示す。
【００２５】
【図６】モデル・ワークフロー対を定義するために用いられ得る定義段階の、例示的なフローチャートを示す。
【００２６】
【図７】健全性指標を出力する予測モデルを定義するために用いられ得る、モデル化段階の例示的なフローチャートを示す。
【００２７】
【図８】メッシュネットワークのためのルーティング設定を更新するための、例示的な方法を示す図を示す。
【発明を実施するための形態】
【００２８】
以下の開示は、添付の図面、およびいくつかの例示的なシナリオを参照する。当業者は、そのような参照は説明のみを目的としたものであり、したがって限定を意味するものではないことを理解するであろう。開示されたシステム、デバイス、および方法の一部またはすべては、様々な方式で、再構成され、組み合わされ、追加され、および／または、除去され得、そのそれぞれは本明細書に企図される。
［Ｉ．  例示的なネットワーク構成］
【００２９】
ここで、図を参照すると、図１は、例示的な実施形態が実装され得る例示的なネットワーク構成１００を図示する。示されるように、ネットワーク構成１００は、メッシュネットワーク１０５において結合された、少なくとも３つの資産１０２、１０３および１０４、通信ネットワーク１０６、分析システムの形態をとり得るリモート演算処理システム１０８、出力システム１１０、ならびにデータソース１１２を含む。
【００３０】
通信ネットワーク１０６は、ネットワーク構成１００の各要素と通信可能に接続し得る。例えば、資産１０２、１０３および１０４は、通信ネットワーク１０６を介して分析システム１０８と通信し得る。資産１０２、１０３および１０４は、メッシュネットワーク１０５を介して互いに通信し得る。資産１０２、１０３および１０４は、メッシュネットワーク１０５を介して、および通信ネットワーク１０６を介して通信することによって、分析システム１０８ともまた通信し得る。例えば、資産１０２は資産１０３にセンサデータを伝送し得、それは通信ネットワークを介して、分析システム１０８にセンサデータを伝送する。さらに、メッシュネットワーク１０５は、資産１０２、１０３および１０４のサブセットが分析システム１０８と通信するべく構成され得る。例えば、資産１０３が、分析システム１０８と通信する唯一の資産であり得る一方、資産１０２、１０３および１０４は、メッシュネットワーク１０５において、それぞれ他の資産１０３および１０４または１０２および１０３とのみ通信する。
【００３１】
いくつかの場合において、資産１０２、１０３および１０４は、資産ゲートウェイ（図示されていない）などの、同様に分析システム１０８と通信する１つまたは複数の中間システムと通信し得る。同様に、分析システム１０８は通信ネットワーク１０６を介して出力システム１１０と通信し得る。いくつかの場合において、分析システム１０８は、ホストサーバ（図示されていない）などの、同様に出力システム１１０と通信する１つまたは複数の中間システムと通信し得る。多くの他の構成も、また可能である。
【００３２】
一般的に、資産１０２、１０３および１０４は、１つまたは複数の動作（分野に基づいて定義され得る）を実行すべく構成された任意のデバイスの形態をとり得、また、所与の資産の１つまたは複数の動作状態を示すデータを伝送すべく構成された機器も含み得る。いくつかの例において、資産は、１つまたは複数の動作をそれぞれ実行すべく構成された、１つまたは複数のサブシステムを含み得る。実際には、資産が動作すべく、複数のサブシステムは並列に、または連続的に動作し得る。
【００３３】
例示的な資産は、数ある例の中でも、輸送用機械（例えば、機関車、航空機、セミトレーラートラック、船舶など）、工業用機械（例えば、採掘機器、建設機器、処理機器、組み立て機器など）、医療用機械（例えば、医療画像機器、手術機器、医療監視システム、医療実験機器など）、ユーティリティ設備（例えば、タービン、太陽光発電所など）、および、無人航空機を含み得る。当業者は、これらは資産のいくつかの例にすぎず、多数の他のものが可能であり本明細書に企図されることを、理解するであろう。
【００３４】
例示的な実装態様において、資産１０２、１０３および１０４は、それぞれ同じ種類（例えば、数ある例の中でも、一群の機関車または航空機、一群の風力タービン、圧延機械の集まり、１セットの磁気共鳴映像（ＭＲＩ）機械）であり得、おそらく、同じクラス（例えば、同じ機器の種類、ブランド、および／またはモデル）であり得る。他の例において、資産１０２、１０３および１０４は、種類、ブランド、モデルなどが異なってもよい。例えば、資産１０２、１０３および１０４は、非常に数ある例の中でも、作業現場（例えば、掘削現場）または生産設備における異なる要素の機器であり得る。資産は、図２を参照して、以下で更に詳細に論じられる。
【００３５】
示されるように、資産１０２、１０３および１０４は、ならびにおそらくデータソース１１２は、通信ネットワーク１０６および／またはメッシュネットワーク１０５を介して、分析システム１０８と通信し得る。一般的に、通信ネットワーク１０６は、１つまたは複数の演算処理システムと、ネットワーク要素間でのデータの転送を容易にすべく構成されたネットワークインフラストラクチャとを含み得る。通信ネットワーク１０６は、有線および／または無線であり得、様々な程度の帯域幅、電力消費、および／またはレイテンシ特性を特徴とし得る、１つまたは複数のワイドエリアネットワーク（ＷＡＮ）、および／または、ローカルエリアネットワーク（ＬＡＮ）であり得るか、それらを含み得る。いくつかの例において、通信ネットワーク１０６は、数あるネットワークの中でも、１つまたは複数のセルラまたは衛星ネットワーク、および／またはインターネットを含み得る。通信ネットワーク１０６は、ＬＴＥ、ＣＤＭＡ、ＧＳＭ（登録商標）、ＷｉＦｉ、ＬＰＷＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｅｔｈｅｒｎｅｔ（登録商標）、ＨＴＴＰ／Ｓ、ＴＣＰ、ＣｏＡＰ／ＤＴＬＳなどの、１つまたは複数の通信プロトコルによって動作し得る。通信ネットワーク１０６が単一のネットワークとして示されているにもかかわらず、通信ネットワーク１０６は、それら自体が通信可能に結合された複数の、別個のネットワークを含み得ることが理解されるべきである。同様に、通信ネットワーク１０６は他の形態をとることがある。
【００３６】
一般的に、メッシュネットワーク１０５は、資産１０２、１０３および１０４（および潜在的には他のネットワーク要素）が、送信元（例えば、分析システム１０８）から送信先（例えば、資産１０３）へのデータのルーティングを容易にすべく構成される「ノード」の役割を果たす、ネットワークトポロジの形態をとり得る。例えば、分析システム１０８は、資産１０３が送信先であるデータを、資産１０３にデータを中継する資産１０４を介して、伝送し得る。同様に、資産１０３は、分析システム１０８が送信先であるデータを、通信ネットワーク１０６を介して分析システム１０８にデータを中継する資産１０２を介して、伝送し得る。データルーティングの他の例も、また可能である。メッシュネットワークは、図４に関して、以下で更に詳細に論じられる。
【００３７】
上記に留意すると、分析システム１０８は、資産１０２、１０３および１０４、ならびにデータソース１１２からデータを受信すべく構成され得る。広く言えば、分析システム１０８は、データを受信、処理、分析、および出力すべく構成された、サーバおよびデータベースなどの１つまたは複数の演算処理システムを含み得る。分析システム１０８は、数ある例の中でも、ＴＰＬ  ＤａｔａｆｌｏｗまたはＮｉＦｉなどの、所与のデータフロー技術に従って構成され得る。分析システム１０８は、図３を参照して、以下で更に詳細に論じられる。
【００３８】
示されるように、分析システム１０８は、資産１０２、１０３および１０４、ならびに／または出力システム１１０にデータを伝送すべく構成され得る。伝送される特定のデータは、様々な形態をとり得、以下で更に詳細に説明されるであろう。
【００３９】
一般的に、出力システム１１０は、データを受信して、何らかの形態の出力を提供すべく構成された、演算処理システムまたはデバイスの形態をとり得る。出力システム１１０は、様々な形態をとり得る。１つの例において、出力システム１１０は、データを受信し、そのデータに応答して聴覚的な、視覚的な、および／または触覚的な出力を提供すべく構成された出力デバイスであり得るか、それを含み得る。一般的に、出力デバイスは、ユーザ入力を受信すべく構成された１つまたは複数の入力インタフェースを含み得、出力デバイスは、そのようなユーザ入力に基づいて、通信ネットワーク１０６を介してデータを伝送すべく構成され得る。出力デバイスの例として、タブレット、スマートフォン、ラップトップコンピュータ、他のモバイル演算処理デバイス、デスクトップコンピュータ、スマートテレビジョンなどが挙げられる。
【００４０】
出力システム１１０の別の例は、整備士などに資産の修理の要請を出力すべく構成された、作業注文システムの形態をとり得る。出力システム１１０のさらに別の例は、資産の部品の発注を行い、その受領書を出力すべく構成された、部品発注システムの形態をとり得る。多数の他の出力システムも、また可能である。
【００４１】
データソース１１２は、分析システム１０８と通信すべく構成され得る。一般的に、データソース１１２は、分析システム１０８によって実行された機能に関連し得るデータを、収集、格納、および／または、分析システム１０８などの他のシステムに提供すべく構成された、１つまたは複数の演算処理システムであり得るか、そのような演算処理システムを含み得る。データソース１１２は、資産１０２、１０３および１０４とは独立してデータを生成、および／または取得すべく構成され得る。したがって、データソース１１２によって提供されるデータは、本明細書において「外部データ」と呼ばれ得る。データソース１１２は、現在および／または過去のデータを提供すべく構成され得る。実際には、分析システム１０８は、データソース１１２によって提供されるサービスに「加入」することによって、そのデータソースからデータを受信し得る。しかしながら、分析システム１０８は、他の方式においても同様に、データソース１１２からデータを受信し得る。
【００４２】
データソース１１２の例として、環境データソース、資産管理データソース、および他のデータソースが挙げられる。一般的に、環境データソースは、資産が動作する環境の、いくつかの特性を示すデータを提供する。環境データソースの例として、数ある例の中でも、所与の地域の自然の、および人工的な特徴に関する情報を提供する、天気データサーバ、グローバルナビゲーション衛星システム（ＧＮＳＳ）サーバ、地図データサーバ、および地形データサーバが挙げられる。
【００４３】
一般的に、資産管理データソースは、資産の動作または保守に影響を及ぼし得るエンティティ（例えば、他の資産）のイベントまたはステータスを示すデータ（例えば、いつおよびどこで資産が動作し、または保守を受け得るか）を提供する。資産管理データソースの例として、数ある例の中でも、空路、海路、および／または陸路の交通に関する情報を提供する交通データサーバ、特定の日付および／または特定の時間における資産の、期待されるルートおよび／または位置に関する情報を提供する資産スケジュールサーバ、欠陥検出器システム（「軸焼け」検出器としてもまた知られる）に近接して通過する資産の１つまたは複数の動作状態に関する情報を提供する欠陥検出器システム、特定の供給業者が在庫を有する部品およびそれらの価格に関する情報を提供する部品供給業者サーバ、および、修理業者の処理能力に関する情報を提供する修理業者サーバ、などが挙げられる。
【００４４】
他のデータソースの例として、数ある例の中でも、電気消費に関する情報を提供する送電網サーバ、および、資産に関する過去の動作データを格納する外部データベースが挙げられる。当業者は、これらはデータソースのいくつかの例にすぎず、多数の他のものが可能であることを理解するであろう。
【００４５】
ネットワーク構成１００は、本明細書に説明された実施形態が実装され得るネットワークの１つの例であることが、理解されるべきである。多数の他の構成が可能であり、本明細書に企図される。例えば、他のネットワーク構成は、図示されていない追加の要素を含み得、および／または、図示された要素より多いか少ない数の要素を含み得る。
［ＩＩ．  例示的な資産］
【００４６】
図２を参照すると、例示的な資産２００の簡略ブロック図が示される。図１からの資産１０２、１０３および１０４のうち１つまたは複数は、資産２００と同様に構成され得る。示されるように、資産２００は、１つまたは複数のサブシステム２０２、１つまたは複数のセンサ２０４、１つまたは複数のアクチュエータ２０５、中央処理装置２０６、データストレージ２０８、ネットワークインタフェース２１０、ユーザインタフェース２１２、および、おそらくローカル分析デバイス２２０もまた含み得、それらのすべては、システムバス、ネットワーク、または他の接続機構によって通信可能に結合され得る。当業者は、資産２００は、示されていない追加の要素を含み得、および／または、示された要素より多いか少ない数の要素を含み得ることを、理解するであろう。
【００４７】
広く言えば、資産２００は、１つまたは複数の動作を実行すべく構成された、１つまたは複数の電気的、機械的、および／または電気機械的要素を含み得る。いくつかの場合において、１つまたは複数の要素は、所与のサブシステム２０２にグループ化され得る。
【００４８】
一般に、サブシステム２０２は、資産２００の一部である一群の関連する要素を含み得る。単一のサブシステム２０２は、１つまたは複数の動作を独立して実行し得、または、単一のサブシステム２０２は、１つまたは複数の動作を実行すべく、１つまたは複数の他のサブシステムとともに動作し得る。通常、異なる種類の資産は、および、同じ種類で異なるクラスの資産でさえも、異なるサブシステムを含み得る。
【００４９】
例えば、輸送資産の文脈において、サブシステム２０２の例として、非常に数あるサブシステムの中でも、エンジン、変速機、ドライブトレイン、燃料システム、バッテリシステム、排気システム、ブレーキシステム、電気システム、信号処理システム、発電機、ギアボックス、ロータ、および油圧システムが挙げられ得る。医療用機械の文脈において、サブシステム２０２の例として、非常に数あるサブシステムの中でも、スキャンシステム、モータ、コイルおよび／または磁石システム、信号処理システム、ロータ、および電気システムが挙げられ得る。
【００５０】
上記に示唆されるように、資産２００は、資産２００の動作状態を監視すべく構成された様々なセンサ２０４と、資産２００またはその要素と相互に作用して資産２００の動作状態を監視すべく構成された様々なアクチュエータ２０５とを備え得る。いくつかの場合において、センサ２０４および／またはアクチュエータ２０５のいくつかは、特定のサブシステム２０２に基づいてグループ化され得る。このようにして、一群のセンサ２０４および／またはアクチュエータ２０５は、特定のサブシステム２０２の動作状態を監視すべく構成され得、その群のアクチュエータは、サブシステムの動作状態に基づいてそれらの挙動を変更し得るいくつかのやり方で、特定のサブシステム２０２と相互に作用すべく構成され得る。
【００５１】
一般的に、センサ２０４は、資産２００の１つまたは複数の動作状態を示し得る物理的特性を検出すべく構成され得、検出された物理的特性の、電気信号などの指示を提供し得る。動作中、センサ２０４は継続的に、周期的に（例えば、サンプリング頻度に基づいて）、および／または、いくつかのトリガイベントに応答して、測定値を取得すべく構成され得る。いくつかの例において、センサ２０４は、測定を実行するための動作パラメータで事前設定され得、および／または、中央処理装置２０６によって提供された動作パラメータ（例えば、測定値を取得するようにセンサ２０４に命令するサンプリング信号）に従って測定を実行し得る。例において、異なるセンサ２０４は異なる動作パラメータを有し得る（例えば、いくつかのセンサは第１の周波数に基づいてサンプリングし、一方、他のセンサは第２の異なる周波数に基づいてサンプリングし得る）。いずれの場合も、センサ２０４は、測定された物理的特性を示す電気信号を中央処理装置２０６に伝送すべく構成され得る。センサ２０４は、そのような信号を中央処理装置２０６に継続的に、または周期的に提供し得る。
【００５２】
例えば、センサ２０４は、資産２００の位置および／または動きなどの物理的特性を測定すべく構成され得、その場合、センサはＧＮＳＳセンサ、推測航法ベースのセンサ、加速度計、ジャイロスコープ、歩数計、磁力計、または同様のものなどの形態をとり得る。
【００５３】
さらに、様々なセンサ２０４が、資産２００の他の動作状態を測定すべく構成され得、その例として、数ある例の中でも、温度、圧力、速度、摩擦、電力使用量、燃料使用量、液位、実行時間、電圧および電流、磁界、電界、ならびに発電量が挙げられ得る。当業者は、これらはセンサが測定すべく構成され得るいくつかの例示的な動作状態にすぎないことを、理解するであろう。追加のセンサ、またはより少ないセンサが、工業的な応用または特定の資産に応じて、用いられ得る。
【００５４】
上記で示唆されるように、アクチュエータ２０５は、センサ２０４にいくつかの点で類似して構成され得る。具体的に、アクチュエータ２０５は資産２００の動作状態を示す物理的特性を検出し、センサ２０４と同様の方式でそれらの指示を提供すべく構成され得る。
【００５５】
さらに、アクチュエータ２０５は、資産２００、１つまたは複数のサブシステム２０２、および／または、それらの何らかの要素と相互に作用すべく構成され得る。したがって、アクチュエータ２０５は、要素またはシステムを移動させるべく、またはそうでなければ制御すべく構成された、モータなどを含み得る。特定の例において、アクチュエータは燃料流量を測定し、燃料流量を変更（例えば、燃料流量を制限）すべく構成され得、または、アクチュエータは、油圧を測定し、油圧を変更（例えば、油圧を増加または減少）すべく構成され得る。アクチュエータの、多数の他の例示的な相互作用も、また可能であり、本明細書において企図される。
【００５６】
一般に、中央処理装置２０６は１つまたは複数のプロセッサ、および／またはコントローラを含み得、それは汎用の、または専用のプロセッサ、またはコントローラの形態をとり得る。具体的には、例示的な実装態様において、中央処理装置２０６は、マイクロプロセッサ、マイクロコントローラ、特定用途向け集積回路、デジタル信号プロセッサなどであり得るか、それらを含み得る。同様に、データストレージ２０８は、数ある例の中でも、光メモリ、磁気メモリ、有機メモリ、またはフラッシュメモリなどの、１つまたは複数の非一時的コンピュータ可読格納媒体であり得るか、それらを含み得る。
【００５７】
中央処理装置２０６は、本明細書に説明される資産２００の動作を実行するために、コンピュータ可読プログラム命令をデータストレージ２０８に格納し、格納されたそれらの命令にアクセスして実施すべく構成され得る。例えば、上記に示唆されるように、中央処理装置２０６は、センサ２０４および／またはアクチュエータ２０５からそれぞれのセンサ信号を受信すべく構成され得る。中央処理装置２０６は、センサおよび／またはアクチュエータ２０５のデータをデータストレージ２０８に格納し、後でデータストレージ２０８からのデータにアクセスすべく構成され得る。中央処理装置２０６は、また、受信されたセンサ信号が、障害コードなどのいずれかの異常状態インジケータをトリガするかどうか決定すべくも構成され得る。例えば、中央処理装置２０６は、異常状態ルールをデータストレージ２０８に格納すべく構成され得、それらのそれぞれは、特定の異常状態を表す所与の異常状態インジケータと、異常状態インジケータをトリガするそれぞれのセンサ基準とを含む。すなわち、各異常状態インジケータは、異常状態インジケータがトリガされる前に満たされる必要がある１つまたは複数のセンサ測定値に対応する。実際、資産２００は、異常状態ルールで事前にプログラムされ得、および／または、新たな異常状態ルールもしくは既存のルールの更新を、分析システム１０８などの演算処理システムから受信し得る。
【００５８】
いずれの場合も、中央処理装置２０６は、受信されたセンサ信号がいずれかの異常状態インジケータをトリガするかどうか決定すべく構成され得る。すなわち、中央処理装置２０６は、受信されたセンサ信号がいずれかのセンサ基準を満たすかどうか決定し得る。そのような決定が肯定的であるとき、中央処理装置２０６は異常状態データを生成し得、資産２００のネットワークインタフェース２１０に、異常状態データを分析システム１０８へ伝送させ得る。中央処理装置２０６は異常状態データを生成し得、資産２００のユーザインタフェース２１２に、視覚的および／または聴覚的なアラートなどの、異常状態の指示もまた出力させ得る。さらに、中央処理装置２０６は、異常状態インジケータの発生がトリガされたことを、おそらくタイムスタンプと共に、データストレージ２０８に記録し得る。
【００５９】
図３は、資産に関する例示的な異常状態インジケータ、およびそれぞれのトリガ基準の概念図を示す。具体的には、図３は障害コードの例の概念図を示す。示されるように、テーブル３００は、センサＡ、アクチュエータＢ、およびセンサＣにそれぞれ対応する列３０２、３０４および３０６と、障害コード１、２および３にそれぞれ対応する行３０８、３１０および３１２とを含む。エントリ３１４は次に、所与の障害コードに対応するセンサ基準（例えば、センサ値の閾値）を指定する。
【００６０】
例えば、障害コード１は、センサＡが１３５回転毎分（ＲＰＭ）より大きい回転測定値を検出し、および、センサＣが摂氏６５度（℃）より高い温度測定値を検出するときにトリガされるであろう。障害コード２は、アクチュエータＢが１０００ボルト（Ｖ）より高い電圧測定値を検出し、および、センサＣが５５℃より低い温度測定値を検出するときにトリガされるであろう。障害コード３は、センサＡが１００ＲＰＭより大きい回転測定値を検出し、アクチュエータＢが７５０Ｖより高い電圧測定値を検出し、および、センサＣが６０℃より高い温度測定値を検出するときにトリガされるであろう。当業者は、図３は例示および説明のみの目的で提供され、多数の他の障害コードおよび／またはトリガ基準が可能であり、本明細書に企図されることを、理解するであろう。
【００６１】
図２に戻って参照すると、中央処理装置２０６は、資産２００の動作を管理および／または制御するための、様々な追加の機能を実行すべく構成され得る。例えば、中央処理装置２０６は、スロットル位置またはセンササンプリングレートを修正するなどのいくつかの動作をサブシステム２０２および／またはセンサ２０４に実行させる命令信号を、サブシステム２０２および／またはセンサ２０４に提供すべく構成され得る。さらに、中央処理装置２０６は、サブシステム２０２、センサ２０４、ネットワークインタフェース２１０、および／またはユーザインタフェース２１２からの信号を受信し、そのような信号に基づいて動作を発生させるべく構成され得る。さらになお、中央処理装置２０６は、データストレージ２０８に格納された診断ルールに従って、１つまたは複数の診断ツールを中央処理装置２０６に実施させる信号を、診断デバイスなどの演算処理デバイスから受信すべく構成され得る。中央処理装置２０６の他の機能は、以下に論じられる。
【００６２】
いくつかの実装態様において、中央処理装置２０６は、分析システム１０８または別の資産２００からのルーティング設定を受信し、または、そのルーティング設定を更新すべく構成され得る。中央処理装置２０６は、資産２００に、ルーティング設定またはルーティング設定の更新に基づいて、動作を実行させ得る。
【００６３】
ネットワークインタフェース２１０は、資産２００と、様々な他のネットワーク要素との間の通信を提供すべく構成され得る。例えば、ネットワークインタフェース２１０は、通信ネットワーク１０６との間での通信を容易にすべく構成され得、従って、様々な無線信号を伝送および受信するためのアンテナ構造および関連機器の形態をとり得、および／または、有線ネットワークインタフェースの形態をとり得る。ネットワークインタフェース２１０は、メッシュネットワーク１０５において動作する、資産２００と様々なネットワーク要素との間の通信を、また提供すべくも構成され得る。例えば、ネットワークインタフェース２１０は、メッシュネットワークにおける資産１０２、１０３および１０４の間の通信を容易にすべく構成され得る。他の例も同様に可能である。実際には、ネットワークインタフェース２１０は、上記で述べられたいずれかのものなどの、通信プロトコルに従って構成され得る。
【００６４】
ユーザインタフェース２１２は、資産２００とのユーザ対話を容易にすべく構成され得、また、ユーザ対話に応答する動作を資産２００に実行させることを容易にすべくも構成され得る。ユーザインタフェース２１２の例として、数ある例の中でも、タッチセンサ式インタフェース、機械的インタフェース（例えば、レバー、ボタン、ホイール、ダイヤル、キーボードなど）、および他の入力インタフェース（例えば、マイク）などが挙げられる。いくつかの場合において、ユーザインタフェース２１２は、ディスプレイスクリーン、スピーカ、ヘッドフォンジャックなどの出力要素を含み得るか、出力要素への接続性を提供し得る。
【００６５】
ローカル分析デバイス２２０は、一般に、データを受信および分析すべく構成され得、そのような分析に基づいて、１つまたは複数の動作を資産２００に発生させるべく構成され得る。具体的には、ローカル分析デバイス２２０は、センサ２０４からのセンサデータを受信し得、そのようなデータに基づいて、資産２００に動作を実行させる命令を中央処理装置２０６に提供し得る。例えば、いくつかの実装態様において、ローカル分析デバイス２２０は、例えば、予測モデルとセンサ２０４からのデータとに基づいて、資産が利用不可能になる可能性がある旨を決定し得る。応答して、ローカル分析デバイス２２０は、メッシュネットワーク（例えば、メッシュネットワーク１０５）に関するルーティング設定を生成し得、そのルーティング設定に基づいてデータを伝送するように中央処理装置２０６に命令し得る。ローカル分析デバイス２２０は、ルーティング設定、および／または、ルーティング設定の更新を格納するようにストレージ２０８に命令し得る。
【００６６】
実際には、ローカル分析デバイス２２０によって、資産２００は、ローカル分析デバイス２２０がなければ、資産内の他の要素とともに実行可能ではないことがある、予測モデルを実施するなどの、高度な分析および関連する動作をローカルに実行することが可能になり得る。したがって、ローカル分析デバイス２２０は、追加の処理能力および／または情報を資産２００に提供することに役立ち得る。
【００６７】
示されるように、ローカル分析デバイス２２０は、処理ユニット２２２、データストレージ２２４、およびネットワークインタフェース２２６を含み得、それらのすべては、システムバス、ネットワーク、または他の接続機構によって通信可能に結合され得る。処理ユニット２２２は、１つまたは複数のプロセッサを含み得、それらは上記で論じたプロセッサの形態のいずれかをとり得る。同様に、データストレージ２２４は、１つまたは複数の非一時的コンピュータ可読格納媒体であり得るか、それらを含み得、それらは、上記で述べたコンピュータ可読格納媒体の形態のいずれかをとり得る。
【００６８】
処理ユニット２２２は、本明細書に説明されるローカル分析デバイスの動作を実行するために、コンピュータ可読プログラム命令をデータストレージ２２４に格納し、格納されたそれらの命令にアクセスして実施すべく構成され得る。例えば、処理ユニット２２２は、センサ２０４からのそれぞれのセンサ信号を受信し、そのような信号に基づく予測モデル・ワークフロー対を実施すべく構成され得る。他の機能が以下に説明される。
【００６９】
ネットワークインタフェース２２６は、上記で述べられたネットワークインタフェースと同一または同様であり得る。実際には、ネットワークインタフェース２２６は、資産２００と分析システム１０８との間の通信を容易にし得る。
【００７０】
当業者は、図２に示される資産２００は、資産の簡略された表現の１つの例にすぎず、多数の他のものがまた可能であることを、理解するであろう。例えば、他の資産は、図示されていない追加要素、および／または、より多いか少ない図示された要素を含み得る。
［ＩＩＩ．  例示的なメッシュネットワーク］
【００７１】
上記で言及されたように、ネットワーク構成１００は、配信データと協働するノードの役割を資産が果たす、メッシュネットワークを含み得る。一般的に、メッシュネットワークは、おそらくメッシュネットワークの外側に位置するソースからのデータを、１つまたは複数のルーティングプロトコルに従って、メッシュネットワークを介して送信先に中継すべく構成される複数のノードを含む。メッシュネットワークは、中央アクセスポイントなどと直接通信するのとは対照的に、ノードが互いに通信するように構成され得、データがソースから送信先へ移動し得る複数の可能な経路を提供し得る。ノードは、動的に追加または除去され得、柔軟な通信ネットワークを可能にすることに役立つ。ノードは、移動式でもよく、固定された位置にあってもよく、それらの何らかの組み合わせであってもよい。
【００７２】
図４は、別の通信ネットワーク（例えば、通信ネットワーク１０６）と通信可能に結合された、例示的なメッシュネットワーク４００の概念図を示す。示されるように、メッシュネットワーク４００は、複数のノード４０２、４０４、４０６、４０８、４１０および４１２を含む。この例において、ノード４０４および４０６はノード４０２によって直接到達可能であり、一方、ノード４０８、４１０および４１２はノード４０２によって直接到達可能ではない。したがって、メッシュネットワーク４００は、数ある利点の中でも、ノード４０４および４０６がノード４０２の送信範囲を拡張するという点で有利であり得る。
【００７３】
例示的な実装態様において、ノード４０２は、メッシュネットワーク４００に、通信ネットワーク１０６（例えば、ひいてはＷＡＮ）への接続性を提供すべく構成され得る。このようにして、メッシュネットワーク４００の他のノードが、通信ネットワーク１０６へ戻る単一の接続を共有することを、ノード４０２が可能にする。ノード４０２は、有線もしくは無線の機構、またはそれらの何らかの組み合わせによって、通信ネットワーク１０６に通信可能に結合され得る。ノード４０２は、無線ルータなどのアクセスポイントを含み得るか、その形態をとり得るか、そうでなければそれと通信し得る。いくつかの実装態様において、ノード４０２は、資産２００などの資産の形態をとり得る。
【００７４】
ノード４０４−４１２は、資産の形態をとり得、それらのいくつかはすべて同じ種類および／またはクラスであり得、または、いくつかの点で異なり得る。いずれの場合も、ノードとしての役割を果たす資産４０４−４１２のそれぞれが、１つまたは複数のルーティング技法に従ってデータをルーティングすべく構成され得る。例えば、各資産は、図２を参照して上記に述べられたいずれかのネットワークインタフェースなどの、資産がデータを受信および伝送することを可能にする、１つまたは複数のネットワークインタフェースを含み得る。いくつかの実装態様において、所与の資産は、それ自体は通信インタフェースを含まないが、しかしメッシュネットワーク４００への接続性を所与の資産に提供する外部ネットワークインタフェースによって改良され得る、「レガシー」資産であり得る。さらに、例示的な実装態様において、資産はデータを受信するが、しかし伝送しないように構成され得る。例えば、資産４１２は、データを受信および格納するが、しかしメッシュネットワーク４００の他のノードにはデータを伝送しない、データストレージデバイスであり得る。他の例もまた可能である。
【００７５】
上記に示唆されるように、データは１つまたは複数のルーティング技法に従って、メッシュネットワーク４００を介して伝搬し得る。一般に、所与のルーティング技法は、ソースからのデータが中間ノード（すなわち、データの最終送信先ではないノード）を介して送信先に達することが可能な、複数の経路を提供し得る。そして、データが送信されたとき、最も速い、および／または、最も信頼できるルートを提供する経路が利用され得る。例として、所与のルーティング技法は、通信ネットワーク１０６と資産４０８の間に２つの経路（例えば、経路４０３および経路４０５）を提供し得る。したがって、数ある可能性の中でも、資産４０８から生じるデータ（例えば、動作データ）は、経路４０３を介して（例えば、中間ノード４０４および４０２を通って）通信ネットワーク１０６に移動し得る一方、通信ネットワーク１０６から生じるデータは、経路４０５を介して（例えば、中間ノード４０２および４０６を通って）資産４０８に移動し得る。
【００７６】
数あるルーティング技法の中でも、事後ルーティング技法（例えば、アドホックオンデマンド距離ベクトルルーティング（ＡＯＤＶ）、ダイナミックソースルーティング（ＤＳＲ）など）、事前ルーティング技法（例えば、最適化リンク状態ルーティング（ＯＬＳＲ）、ベターアプローチトゥモバイルアドホックネットワーク（ＢＡＴＭＡＮ）、デスティネーションシーケンス距離ベクトルルーティング（ＤＳＤＶ）、クラスタヘッドゲートウェイスイッチルーティング（ＣＧＳＲ）など）、および／または、ハイブリッドルーティング技法（例えば、事後ルーティング技法および事前ルーティング技法の何らかの組み合わせ）などの、様々なルーティング技法が利用され得る。
【００７７】
所与のルーティング技法に応じて、メッシュネットワーク４００を介してデータが伝搬し得る経路は、様々な方式において決定され得る。一般に、経路は、メッシュネットワーク４００の各ノードが、おそらく周期的に、それぞれのルーティング情報（例えば、距離ベクトル、ノードメトリックなど）を他のノードと交換し、メッシュネットワーク４００における各ノードから他のノードへの可能なルートを確立することによって決定される。より具体的には、メッシュネットワーク４００が確立され得、経路はノード４０２−４１２のルーティング情報に基づいて決定され得る。所与のノードのルーティング情報は、数ある検討事項の中でも、所与のノードの現在の負荷、無線周波数ノイズレベル、所与のノードのＧＰＳ座標、受信信号強度インジケータ、信号ノイズ比、コンパス角、所与のノードのバッテリパワー残量、および／または所与のノードのエネルギー残量（例えば、所与のノードのデータスループットおよび／またはホップ数の指示）、などの様々なノードメトリックを含み得、または、それらのノードメトリックに基づき得る。
【００７８】
各ノードは、次に、所与のルーティング技法に従って、ルーティングテーブルの形態などをとる、他のノードのルーティング情報のいくつかまたはすべてを格納し得る。一般に、所与のルーティング技法は、１つまたは複数の「最適な」経路をノードに決定させ、ルーティング情報に基づいてデータを配信し得る。例えば、ノードは、数ある例の中でも、最も速いデータ配信（例えば、最小のホップ数、最短の全体距離、および／または、最短の移動時間）、最も信頼できるデータ配信、または、速さと信頼性の両方を最適化する経路のために最適化し得る。いずれの場合も、所与のノードが特定のノードに関する送信先を示すデータを受信したとき、その所与のノードが、所与のルーティング技法に従うデータの配信を容易にするためにデータを中継すべきノード（例えば「次のホップ」）を簡単に決定可能であるように、ノードは、最適化されたデータ配信を反映すべく、それらのそれぞれのルーティングテーブルを構成し得る。
【００７９】
実際には、メッシュネットワーク４００は、ネットワーク状態および／またはノードメトリックの変更のとき、動的に更新され得る。例えば、ネットワーク状態が変化するとき（例えば、ネットワークレイテンシが増加または減少するとき）、ノードは、所与の経路が別の経路より不適切である旨を決定して、異なる経路が現在最も適切な経路である旨を反映するように、それらのそれぞれのルーティングテーブルを更新し得る。別の例において、ルータが変化するとき（例えば、以下で更に詳細に述べる、所与の資産の健全性が減少するとき）のサーバへの所与のノードの能力として、ノードは、所与の経路（例えば、経路において所与のノードが結合している経路）が、別の経路より不適切である旨を決定し、したがって、それらのそれぞれのルートテーブルを更新し得る。ルーティング情報の更新の他の例も、また可能である。
［ＩＶ．  例示的な分析システム］
【００８０】
ここで、図５を参照すると、例示的な分析システム５００の簡略ブロック図が示される。上記で示唆されたように、分析システム５００は、本明細書に説明された様々な動作を実行すべく通信可能に結合されて構成された、１つまたは複数の演算処理システムを含み得る。具体的には、示されるように、分析システム５００は、データ取得システム５０２、データサイエンスシステム５０４、および、１つまたは複数のデータベース５０６を含み得る。これらのシステム要素は、１つまたは複数の無線および／または有線接続によって、通信可能に結合され得る。
【００８１】
データ取得システム５０２は、一般に、データを受信および処理し、データをデータサイエンスシステム５０４に出力すべく機能し得る。したがって、データ取得システム５０２は、資産１０２、１０３および１０４、出力システム１１０、および／またはデータソース１１２などの、ネットワーク構成１００の様々なネットワーク要素からデータを受信すべく構成された、１つまたは複数のネットワークインタフェースを含み得る。具体的に、データ取得システム５０２は、数ある例の中でも、アナログ信号、データストリーム、および／または、ネットワークパケットを受信すべく構成され得る。したがって、ネットワークインタフェースは、ポートなどの１つまたは複数の有線ネットワークインタフェース、および／または、上記で述べられたものと同様の無線ネットワークインタフェースを含み得る。いくつかの例において、データ取得システム４０２は、ＮｉＦｉ受信機などの所与のデータフロー技術に従って構成された要素であり得るか、そのような要素を含み得る。
【００８２】
データ取得システム５０２は、１つまたは複数の動作を実行すべく構成された１つまたは複数の処理要素を含み得る。例示的な動作として、数ある動作の中でも、圧縮および／または解凍、暗号化および／または復号、アナログ−デジタル変換および／またはデジタル−アナログ変換、フィルタリング、ならびに増幅が挙げられ得る。さらに、データ取得システム５０２は、データ型および／またはデータの特性に基づいて、データを分析、分類、体系化、および／またはルーティングすべく構成され得る。いくつかの例において、データ取得システム５０２は、データサイエンスシステム５０４の１つまたは複数の特性または動作パラメータに基づいて、データをフォーマット、パッケージング、および／またはルーティングすべく構成され得る。
【００８３】
一般的に、データ取得システム５０２によって受信されたデータは、様々な形態をとり得る。例えば、データのペイロードは、単一センサ測定値、複数のセンサ測定値、および／または、１つまたは複数の障害コードを含み得る。他の例もまた可能である。
【００８４】
さらに、受信されたデータは、ソース識別子およびタイムスタンプ（例えば、情報が取得された日付、および／または時刻）などの、特定の特性を含み得る。例えば、一意的な識別子（例えば、コンピュータによって生成されたアルファベット、数字、英数字などの識別子）が、各資産、および、おそらく各センサに割り当てられ得る。そのような識別子は、データが生じる元である資産またはセンサを識別すべく動作可能であり得る。いくつかの場合において、別の特性が、情報が取得された位置（例えば、ＧＰＳ座標）を含み得る。データ特性は、数ある例の中でも、信号署名またはメタデータの形態で生じ得る。
【００８５】
データサイエンスシステム５０４は、一般に、データを（例えば、データ取得システム５０２から）受信して分析し、そのような分析に基づいて、１つまたは複数の動作を発生させるべく機能し得る。したがって、データサイエンスシステム５０４は、１つまたは複数のネットワークインタフェース５０８、処理ユニット５１０、およびデータストレージ５１２を含み得、それらのすべては、システムバス、ネットワーク、または他の接続機構によって通信可能に結合され得る。いくつかの場合において、データサイエンスシステム４０４は、本明細書に開示された機能のいくつかの実行を容易にする、１つまたは複数のアプリケーションプログラムインタフェース（ＡＰＩ）を格納、および／またはそれらのＡＰＩにアクセスすべく構成され得る。
【００８６】
ネットワークインタフェース５０８は、上述のいかなるネットワークインタフェースとも、同一または同様であり得る。実際には、ネットワークインタフェース５０８はデータサイエンスシステム５０４と、データ取得システム５０２、データベース５０６、資産１０２、１０３、１０４、出力システム１１０などの、様々な他のエンティティとの間の通信を容易にし得る。
【００８７】
処理ユニット５１０は、上述のプロセッサ形態のいずれかをとり得る、１つまたは複数のプロセッサを含み得る。同様に、データストレージ５１２は、１つまたは複数の非一時的コンピュータ可読格納媒体であり得るか、それらを含み得、それらは上記で論じたコンピュータ可読格納媒体のいずれかの形態をとり得る。処理ユニット５１０は、本明細書で説明された分析システムの動作を実行するために、コンピュータ可読プログラム命令をデータストレージ５１２に格納し、格納されたそれらの命令にアクセスして実施すべく構成され得る。
【００８８】
一般的に、処理ユニット５１０は、データ取得システム５０２から受信されたデータに関して分析を実行すべく構成され得る。その目的で、処理ユニット５１０は１つまたは複数のモジュールを実施すべく構成され得、モジュールはそれぞれ、データストレージ５１２に格納される１つまたは複数のセットのプログラム命令の形態をとり得る。モジュールは、それぞれのプログラム命令の実施に基づいて結果を発生させることを容易にすべく構成され得る。所与のモジュールからの例示的な結果として、数ある例の中でも、データを別のモジュールに出力すること、所与のモジュールおよび／または別のモジュールのプログラム命令を更新すること、ならびに、資産および／または出力システム１１０への送信のために、ネットワークインタフェース５０８にデータを出力することが挙げられ得る。
【００８９】
一般に、データベース５０６は、（例えば、データサイエンスシステム５０４から）データを受信し、格納すべく機能し得る。したがって、各データベース５０６は、上記に提供された例のいずれかなどの、１つまたは複数の非一時的コンピュータ可読格納媒体を含み得る。実際には、データベース５０６は、データストレージ５１２とは別個のものであっても、データストレージ５１２と統合されていてもよい。
【００９０】
データベース５０６は、数多くの種類のデータを格納すべく構成され得、それらのいくつかは以下に論じられる。実際には、データベース５０６に格納されたデータのいくつかは、データが生成された、またはデータベースに追加された日付および時刻を示すタイムスタンプを含み得る。さらに、データはデータベース５０６に複数の方式で格納され得る。例えば、数ある例の中でも、データは時系列順に格納され、表形式で格納され、および／または、データソースの種類に基づいて（例えば、資産、資産の種類、センサ、またはセンサの種類に基づいて）、もしくは障害コードに基づいて体系化され得る。
［Ｖ．  例示的な動作］
【００９１】
ここで、図１で図示された例示的なネットワーク構成１００の動作を、以下で更に詳細に述べよう。これらの動作のいくつかの説明の助けとなるように、実行され得る動作の組み合わせを説明するためのフローチャートを参照してよい。いくつかの場合において、各ブロックは、プロセスにおける特定の論理機能または論理ステップを実装すべくプロセッサによって実施可能な命令を含むプログラムコードの、モジュールまたは部分を表し得る。プログラムコードは、非一時的コンピュータ可読媒体などの、任意の種類のコンピュータ可読媒体に格納され得る。他の場合において、各ブロックは、プロセスにおける特定の論理機能または論理ステップを実行すべく有線接続された回路を表し得る。さらに、フローチャートに示されたブロックは、特定の実施形態に基づいて、異なる順序で再構成され、より少ないブロックへと組み合わされ、追加のブロックへと分離され、および／または除去され得る。
【００９２】
以下の説明は、資産１０２などの単一のデータソースが、データを分析システム１０８に提供し、分析システム１０８が次に１つまたは複数の機能を実行する場合の例を参照し得る。このことは、明確性および説明のためにのみなされており、限定を意味するものではないことが、理解されるべきである。実際に、分析システム１０８は、資産１０２、１０３および１０４などの複数のソースから、おそらく同時にデータを受信し得、そのような一括受信されたデータに基づいて、動作を実行し得る。
［Ａ．  ルーティングトポロジの生成］
【００９３】
例示的な実装態様において、資産１０２、１０３および１０４のいくつかまたはすべては、資産と分析システム１０８とがデータを転送し得るメッシュネットワーク１０５を確立すべく、セットアップメッセージを交換し得る。具体的に、メッシュネットワーク１０５は、図４を参照した上記の説明に沿って、資産１０２−１０４の間で確立され得る。
【００９４】
いくつかの実装態様において、資産１０２−１０４は、所望の最適化要因に従ってメッシュネットワーク１０５の最適化を容易にする、ルーティングトポロジ（例えば、データを転送する経路を反映するルーティングテーブル）を生成し得る。例えば、ルーティングトポロジは、数ある例の中でも、データを中継する最小数の資産（ノード）（例えば、ホップの最小化）、最短のデータ配信時間（例えば、レイテンシ最小化）、最小のエネルギー消費（例えば、エネルギー最小化）、最小量の冗長性、それらの何らかの組み合わせ、または上記で提供された他の例のいずれかのために、最適化される経路を示し得る。例示的な実装態様において、資産１０２−１０４は互いに、および／または分析システム１０８と、ルーティング情報を交換し得る。ネットワーク状態および／または資産（ノード）指標が変化するとき、ルーティングトポロジは、所望の最適化要因に従って更新され得る。
［Ｂ．動作データの収集］
【００９５】
上記で言及されたように、代表的な資産１０２は、様々な形態をとり得、複数の動作を実行すべく構成され得る。非限定的な例において、資産１０２は、米国各地で貨物を運ぶべく動作可能な機関車の形態をとり得る。輸送の間、資産１０２のセンサは、資産１０２の１つまたは複数の動作状態を反映するセンサデータを取得し得る。センサは、資産１０２の処理ユニットにセンサデータを伝送し得る。
【００９６】
処理ユニットは、センサからセンサデータを受信すべく構成され得る。実際には、処理ユニットは複数のセンサから同時に、または連続的にセンサデータを受信し得る。上記で論じられるように、センサデータを受信している間、処理ユニットはまた、障害コードなどのいずれかの異常状態インジケータをトリガするセンサ基準を、センサデータが満たすかどうか決定すべくも構成され得る。１つまたは複数の異常状態インジケータがトリガされたことを、処理ユニットが決定した場合、処理ユニットは、トリガされたインジケータの指示をユーザインタフェースを介して出力するなどの、１つまたは複数のローカルな動作を実行すべく構成され得る。
【００９７】
資産１０２は次に、資産１０２のネットワークインタフェースおよび通信ネットワーク１０６を介して、分析システム１０８に動作データを伝送し得る。動作中に、資産１０２は継続的に、周期的に、および／または、トリガイベント（例えば、異常状態）に応答して、分析システム１０８に動作データを伝送し得る。具体的に、資産１０２は特定の頻度（例えば、毎日、毎時間、１５分ごと、１分に１回、１秒に１回など）に基づいて周期的に動作データを伝送し得、または、資産１０２は、動作データの連続的な、リアルタイムのフィードを伝送すべく構成され得る。さらに、または代替的に、資産１０２は、それのセンサからのセンサ測定値がいずれかの異常状態インジケータのセンサ基準を満たすときなどの、特定のトリガに基づいて、動作データを伝送すべく構成され得る。資産１０２は、同様に他の方式で動作データを伝送し得る。
【００９８】
実際には、資産１０２に関する動作データは、センサデータおよび／または異常状態データを含み得る。いくつかの実装態様において、資産１０２は、単一のデータストリームにおいて動作データを提供すべく構成され得る一方、他の実装態様において、資産１０２は、複数の別個のデータストリームにおける動作データを提供すべく構成され得る。例えば、資産１０２は、センサデータである第１のデータストリームと、異常状態データである第２のデータストリームとを分析システム１０８に提供し得る。他の可能性もまた存在する。
【００９９】
センサデータは様々な形態をとり得る。例えば、あるときには、センサデータは資産１０２の各センサによって取得される測定値を含み得る。一方、他のときには、センサデータは資産１０２のセンサのサブセットによって取得される測定値を含み得る。
【０１００】
具体的には、センサデータは、所与のトリガされた異常状態インジケータに関連づけられたセンサによって取得された測定値を含み得る。例えば、トリガされた障害コードが、図３からの障害コード１である場合、次に、センサデータはセンサＡおよびＣによって取得された未処理の測定値を含み得る。さらに、または代替的に、センサデータは、トリガされた障害コードと直接関連づけられていない１つまたは複数のセンサによって取得された測定値を含み得る。引き続き、最後の例において、センサデータは、センサＢおよび／または他のセンサによって取得された測定値を、さらに含み得る。いくつかの例において、資産１０２は、分析システム１０８によって提供された障害コードルールまたは命令に基づいて、特定のセンサデータを動作データに含み得る。それは、例えば、センサＢが測定しているものと、障害コード１がそもそもトリガされる原因となったものとの間に相関がある旨を決定した可能性がある。他の例がまた可能である。
【０１０１】
さらになお、センサデータは、複数の要因に基づいて選択され得る、注目している特定の時間に基づいて、注目している各センサからの１つまたは複数のセンサ測定値を含み得る。いくつかの例において、注目している特定の時間は、サンプリングレートに基づき得る。他の例において、注目している特定の時間は、異常状態インジケータがトリガされる時間に基づき得る。
【０１０２】
具体的には、異常状態インジケータがトリガされる時間に基づいて、センサデータは、注目している各センサ（例えば、トリガされたインジケータと、直接的におよび間接的に関連づけられたセンサ）からの、１つまたは複数のセンサ測定値をそれぞれ含み得る。１つまたは複数のセンサ測定値は、トリガされた異常状態インジケータの時間の前後における、特定の数の測定値、または特定の期間に基づき得る。
【０１０３】
例えば、トリガされた障害コードが図３からの障害コード２の場合、注目しているセンサはセンサＢおよびＣを含んでよいであろう。１つまたは複数のセンサ測定値は、障害コードのトリガ（例えば、トリガとなる測定値）の前にセンサＢおよびＣによって取得された最新のそれぞれの測定値を含み得、または、トリガとなる測定値の前、後、もしくはほぼそのときの測定値のそれぞれのセットを含み得る。例えば、５個の測定値のセットは、数ある可能性の中でも、トリガとなる測定値の前または後の５個の測定値（例えば、トリガとなる測定値を除く）を含み得、トリガとなる測定値の前または後の４つの測定値とトリガとなる測定値とを含み得、または、トリガとなる測定値の前の２つの測定値と、トリガとなる測定値の後の２つの測定値と、ならびにトリガとなる測定値とを含み得る。
【０１０４】
センサデータと同様に、異常状態データは様々な形態をとり得る。一般的に、異常状態データは、資産１０２に生じ得るすべての他の異常状態から、資産１０２に生じた特定の異常状態を一意的に識別するために動作可能なインジケータを含み得るか、それの形態をとり得る。異常状態インジケータは、数ある例の中でも、アルファベット、数字、または英数字の識別子の形態をとり得る。さらに、異常状態インジケータは、数ある例の中でも、「エンジン過熱」または「燃料切れ」などの、異常状態を説明する単語列の形態をとり得る。
【０１０５】
分析システム１０８は、および、具体的には分析システム１０８のデータ取得システムは、１つまたは複数の資産および／またはデータソースから動作データを受信すべく構成され得る。データ取得システムは、受信されたデータへの１つまたは複数の動作を実行し、次に、分析システム１０８のデータサイエンスシステムにそのデータを中継すべく構成され得る。同様に、データサイエンスシステムは、受信されたデータを分析し、そのような分析に基づいて１つまたは複数の動作を実行し得る。
［Ｃ．  予測モデルおよびワークフローの定義］
【０１０６】
１つの例として、分析システム１０８は、１つまたは複数の資産に関する受信された動作データ、および／または、１つまたは複数の資産に関連して受信された外部データに基づいて、予測モデルおよび対応するワークフローを定義すべく構成され得る。分析システム１０８は、同様に様々な他のデータに基づいて、モデル・ワークフロー対を定義し得る。
【０１０７】
一般的に、モデル・ワークフロー対は、特定の動作状態を資産に監視させ、監視された動作状態によって示唆される特定のイベントの発生の防止を容易にすることに役立つ特定の動作を資産に実行させる、プログラム命令のセットを含み得る。具体的に、予測モデルは、その入力が資産の１つまたは複数のセンサからのセンサデータであり、その出力が、特定のイベントが将来の特定の期間内に資産に生じ得る確率を決定すべく利用される、１つまたは複数のアルゴリズムを含み得る。同様に、ワークフローは１つまたは複数のトリガ（例えば、モデル出力値）、および、資産がトリガに基づいて実行する、対応する動作を含み得る。
【０１０８】
上記に示唆されるように、分析システム１０８は、一括、および／または、個別予測モデル、および／または、ワークフローを定義すべく構成され得る。「一括」モデル／ワークフローは、一群の資産に関して汎用であり、モデル／ワークフローが展開される資産の特定の特性を考慮することなく定義される、モデル／ワークフローを指し得る。その一方で、「個別」モデル／ワークフローは、単一の資産、または一群の資産からの部分群の資産のために具体的に用意され、モデル／ワークフローが展開される単一の資産または部分群の資産の特定の特性に基づいて定義された、モデル／ワークフローを指し得る。 
【０１０９】
本開示によれば、モデル・ワークフロー対の１つの実装態様は、将来の所与の期間内に所与の資産が利用不可能になる可能性がある旨を予測するためのモデル、および、この予測モデルに基づいてルーティングテーブルを更新させるための対応するワークフローの形態をとり得る。このモデル・ワークフロー対は、様々な形態をとり得る。
［１．資産利用不可能性に関する予測モデル］
【０１１０】
上記に留意して、分析システム１０８は、将来の所与の期間内に所与の資産が利用不可能になる可能性がある旨を予測するためのモデル（すなわち「利用不可能性モデル」）を定義すべく構成され得る。分析システム１０８は、様々な方式でこの段階を実行し得る。
【０１１１】
図６は、利用不可能性モデルを定義するために用いられ得る定義段階の１つの可能な例を図示するフローチャート６００である。例示の目的で、例示的な定義段階が、分析システム１０８によって実行されるものとして説明されるが、しかし、この定義段階は、同様に他のシステムによっても実行され得る。当業者は、フローチャート６００は明確性および説明のために提供されることと、動作の多数の他の組み合わせが、モデル・ワークフロー対を定義すべく利用され得ることとを、理解するであろう。
【０１１２】
図６に示されるように、ブロック６０２において、分析システム１０８は、所与の利用不可能性モデルのための基礎を形成するデータのセット（例えば、注目しているデータ）を定義することによって始まり得る。注目しているデータは資産１０２、１０３および１０４、ならびにデータソース１１２などの複数のソースから導き出され得、分析システム１０８のデータベースに格納され得る。
【０１１３】
注目しているデータは、一群の資産からの特定の１セットの資産、または一群の資産からの資産のすべて（例えば、注目している資産）に関する過去のデータを含み得る。さらに、注目しているデータは、注目している資産のそれぞれからの特定の１セットのセンサおよび／もしくはアクチュエータ、または、注目している資産のそれぞれからのセンサおよび／もしくはアクチュエータのすべてからの測定値を含み得る。さらになお、注目しているデータは、２週間相当の過去のデータなど、過去の特定の期間からのデータを含み得る。
【０１１４】
注目しているデータは、様々な種類のデータを含み得、それは所与の利用不可能性モデルに依存し得る。いくつかの事例において、注目しているデータは、少なくとも、資産の動作状態を示す動作データを含み得、動作データは「動作データの収集」の項目において、上記で論じられている。さらに、注目しているデータは、資産が通常動作する環境を示す環境データ、および／または、資産が特定のタスクを実行する、計画された日付および時間を示すスケジュールデータを含み得る。他の種類のデータもまた、注目しているデータに含まれ得る。
【０１１５】
実際には、注目しているデータは、複数の方式で定義され得る。１つの例において、注目しているデータは、ユーザ定義のものであり得る。具体的には、ユーザは、特定の注目しているデータの選択を示すユーザ入力を受信する出力システム１１０を動作させ得、出力システム１１０は、そのような選択を示すデータを分析システム１０８に提供し得る。受信されたデータに基づいて、次に、分析システム１０８は注目しているデータを定義し得る。
【０１１６】
別の例において、注目しているデータは、機械定義のものであり得る。具体的には、分析システム１０８は、最も正確な予測モデルを生成する注目しているデータを決定するために、シミュレーションなどの様々な動作を実行し得る。他の例もまた可能である。
【０１１７】
図６に戻ると、ブロック６０４において、分析システム１０８は、注目しているデータに基づいて、資産の動作状態と資産が将来の所与の期間内に利用不可能になる可能性との関係を表す一括予測モデルを定義すべく構成され得る。具体的に、一括予測モデルは、資産のセンサからのセンサデータ、および／または、資産のアクチュエータからのアクチュエータデータを入力として受信し得、資産が将来の所与の期間内に利用不可能になるであろう確率を出力し得る。
【０１１８】
一般的に、一括予測モデルを定義することは、０と１との間の確率を戻すモデルを生成するために、数あるモデル化技法の中でも、ランダムフォレスト技法、ロジスティック回帰技法、または他の回帰技法などの、１つまたは複数のモデル化技法を利用することを伴う。しかしながら、他の技法も同様に可能である。
【０１１９】
１つの特定の例示的な実装態様において、利用不可能性モデルは、資産の健全性を監視して資産に関する健全性指標（例えば「健全性スコア」）を出力する予測モデルの形態をとり得る。それは、将来への所与の時間枠内に所与の資産に故障が発生するであろうかどうか（従って、所与の資産が利用不可能になるであろうかどうか）を示す、単一の一括指標である。具体的には、健全性指標は、将来への所与の時間枠内に、一群の故障からのいかなる故障も資産に生じないであろうという可能性を示し得る。または、健全性指標は、将来への所与の時間枠内に、一群の故障からの少なくとも１つの故障が資産に生じるであろう可能性を示し得る。
【０１２０】
健全性指標の所望の粒度に応じて、分析システム１０８は、異なるレベルの健全性指標を出力する異なる予測モデルを定義すべく構成され得、それらのそれぞれは利用不可能性モデルとして用いられ得る。例えば、分析システム１０８は、全体として資産に関する健全性指標（すなわち、資産レベルの健全性指標）を出力する予測モデルを定義し得る。別の例として、分析システム１０８は、資産の１つまたは複数のサブシステムに関するそれぞれの健全性指標（すなわち、サブシステムレベルの健全性指標）を出力する、それぞれの予測モデルを定義し得る。いくつかの場合において、サブシステムレベルの各予測モデルの出力は、資産レベルの健全性指標を生成すべく組み合わされ得る。他の例もまた可能である。 
【０１２１】
一般的に、健全性指標を出力する予測モデルを定義することは、様々な方式において実行され得る。図７は、健全性指標を出力するモデルを定義するために用いられ得るモデル化段階の、１つの可能な例を図示するフローチャート７００である。例示の目的で、例示的なモデル化段階は分析システム１０８によって実行されるものとして説明される。しかし、モデル化段階は、同様に他のシステムによって実行されてもよい。当業者は、フローチャート７００は明確性および説明のために提供され、動作の多数の他の組み合わせが、健全性指標を決定すべく利用され得ることを、理解するであろう。
【０１２２】
図７に示されるように、ブロック７０２において、分析システム１０８は、健全性指標の基礎を形成する１つまたは複数の故障のセット（すなわち、注目している故障）を定義することから始まり得る。実際に、１つまたは複数の故障は、それらが発生するならば資産を（またはそれらのサブシステムを）動作不能にすることがある故障であり得る。定義された故障のセットに基づいて、分析システム１０８は、将来の所与の時間枠（例えば、次の２週間）内に何らかの故障が発生する可能性を予測するためのモデルを定義する段階をとり得る。
【０１２３】
具体的には、ブロック７０４において、分析システム１０８は、所与の故障の過去の発生を故障のセットから識別すべく、１つまたは複数の資産の群に関する過去の動作データを分析し得る。ブロック７０６において、分析システム１０８は、所与の故障の、識別された過去の発生とそれぞれ関連づけられた、動作データのそれぞれのセット（例えば、所与の故障の発生前の所与の時間枠からの、センサデータおよび／またはアクチュエータデータ）を識別し得る。ブロック７０８において、分析システム１０８は、所与の故障の過去の発生に関連づけられた動作データの、識別されたセットを分析して、（１）動作指標の所与のセットに関する値と（２）将来の所与の時間枠（例えば、次の２週間）内に所与の故障が発生する可能性と、の間の関係（例えば、故障モデル）を定義し得る。最後に、ブロック７１０において、定義されたセットにおける各故障に関して定義された関係（例えば、個々の故障モデル）は、次に、故障の発生の全体的な可能性を予測するためのモデルへと組み合わせられ得る。
【０１２４】
分析システム１０８は１つまたは複数の資産の群に関する更新された動作データを受信し続けるので、分析システム１０８は、更新された動作データで段階７０４−７１０を繰り返すことによって、定義された１つまたは複数の故障のセットに関する予測モデルを補正することも、また続け得る。
【０１２５】
図７に示された例示的なモデル化段階の機能が、ここで更に詳細に説明されるであろう。ブロック７０２で始まって、上記で留意されるように、分析システム１０８は、健全性指標の基礎を形成する１つまたは複数の故障のセットを定義することから始まり得る。分析システム１０８は、様々な方式でこの機能を実行し得る。
【０１２６】
１つの例において、１つまたは複数の故障のセットは、１つまたは複数のユーザ入力に基づき得る。具体的に、分析システム１０８は、出力システム１１０などの、ユーザによって動作する演算処理システムから、ユーザが１つまたは複数の故障を選択した旨を示す入力データを受信し得る。したがって、１つまたは複数の故障のセットはユーザによって定義されたものであり得る。
【０１２７】
他の例において、１つまたは複数の故障のセットは、分析システム１０８によって行われる（例えば、機械によって定義された）決定に基づき得る。具体的には、分析システム１０８は、複数の方式が生じ得る、１つまたは複数の故障のセットを定義すべく構成され得る。
【０１２８】
例えば、分析システム１０８は、資産１０２の１つまたは複数の特性に基づいて故障のセットを定義すべく構成され得る。すなわち、特定の故障は、資産の種類、クラスなどの、資産の特定の特性に対応し得る。例えば、資産の各種類および／またはクラスは、それぞれ注目している故障を有し得る。
【０１２９】
別の事例において、分析システム１０８は、分析システム１０８のデータベース、および／または、データソース１１２によって提供される外部データに格納される過去のデータに基づいて、故障のセットを定義すべく構成され得る。例えば、分析システム１０８は、数ある例の中でも、どの故障が最長の修理期間をもたらすか、および／または、これまでの状況から、どの故障の後にさらなる故障が続くかを決定すべく、そのようなデータを利用し得る。
【０１３０】
さらに他の例において、１つまたは複数の故障のセットは、ユーザ入力と、分析システム１０８によって行われた決定との組み合わせに基づいて定義され得る。他の例もまた可能である。
【０１３１】
ブロック７０４において、故障のセットからの各故障に関して、分析システム１０８は一群の１つまたは複数の資産に関する過去の動作データ（例えば、異常挙動データ）を分析し、所与の故障の過去の発生を識別し得る。一群の１つまたは複数の資産は、資産１０２などの単一の資産、または、資産１０２、１０３および１０４を含む資産の群などの、同一または同様の種類の複数の資産を含み得る。分析システム１０８は、数ある例の中でも、特定の時間量相当（例えば、１か月相当）のデータ、または、特定数のデータ点（例えば、最新の１０００個のデータ点）などの、特定の量の過去の動作データを分析し得る。
【０１３２】
実際に、所与の故障の過去の発生を識別することは、所与の故障を示す異常状態データなどの動作データの種類を、分析システム１０８が識別することを伴い得る。一般的に、所与の故障は、障害コードなどの１つまたは複数の異常状態インジケータと関連づけられ得る。すなわち、所与の故障が発生するとき、１つまたは複数の異常状態インジケータがトリガされ得る。したがって、異常状態インジケータが、所与の故障の根本的な症状を反映し得る。
【０１３３】
所与の故障を示す動作データの種類を識別した後、分析システム１０８は、複数の方式で、所与の故障の過去の発生を識別し得る。例えば、分析システム１０８は、分析システム１０８のデータベースに格納された過去の動作データから、所与の故障と関連づけられた異常状態インジケータに対応する異常状態データを捜し出し得る。捜し出された各異常状態データは、所与の故障の発生を示すであろう。この捜し出された異常状態データに基づいて、分析システム１０８は、過去の故障が生じた時間を識別し得る。
【０１３４】
ブロック７０６において、分析システム１０８は、所与の故障の、識別された過去の発生とそれぞれ関連づけられた、動作データのそれぞれのセットを識別し得る。具体的には、分析システム１０８は、所与の故障の所与の発生時の前後の特定の時間枠から、センサデータおよび／またはアクチュエータデータのセットを識別し得る。例えば、データのセットは、故障の所与の発生の前、後、または前後の特定の時間枠（例えば２週間）からであり得る。他の場合において、データのセットは、故障の所与の発生の前、後、または前後の、特定数のデータ点から識別され得る。
【０１３５】
例示的な実装態様において、動作データのセットは、資産１０２のセンサおよびアクチュエータのいくつかまたはすべてからの、センサデータおよび／またはアクチュエータデータを含み得る。例えば、動作データのセットは、所与の故障に対応する異常状態インジケータに関連づけられたセンサおよび／またはアクチュエータからのデータを含み得る。
【０１３６】
図７に戻ると、分析システム１０８が、所与の故障の所与の発生に関する動作データのセットを識別した後、分析システム１０８は、動作データのセットを識別すべき発生が何か残っているかどうか決定し得る。残っている発生がある場合、ブロック７０６は、残っている発生の各々に関して繰り返されるであろう。
【０１３７】
その後、ブロック７０８において、分析システム１０８は、所与の故障の過去の発生に関連づけられた動作データの、識別されたセットを分析して、（１）動作指標の所与のセット（例えば、センサ測定値および／またはアクチュエータ測定値の所与のセット）と、（２）将来の所与の時間枠（例えば、次の２週間）内に所与の故障が発生する可能性と、の間の関係（例えば、故障モデル）を定義し得る。すなわち、所与の故障モデルは、入力として１つまたは複数のセンサおよび／またはアクチュエータからのセンサ測定値および／またはアクチュエータ測定値を取得し得、所与の故障が将来の所与の時間枠内に発生するであろう確率を出力し得る。
【０１３８】
一般的に、故障モデルは、資産１０２の動作状態と故障が発生する可能性との間の関係を定義し得る。いくつかの実装態様において、資産１０２のセンサおよび／またはアクチュエータからの未処理のデータ信号に加えて、故障モデルは、センサ信号および／またはアクチュエータ信号から引き出された複数の他のデータ入力（特徴としてもまた知られる）を受信し得る。そのような特徴は、故障が生じたときに測定された過去の値の平均または値の範囲、故障の発生前に測定された過去の値の勾配（例えば、測定値の変化率）の平均または勾配の範囲、故障の間の持続時間（例えば、第１の故障の発生と第２の故障の発生との間の、時間またはデータ点の数）、および／または、故障の発生前後のセンサ測定値および／またはアクチュエータ測定値の傾向を示す１つまたは複数の故障パターンを含み得る。当業者は、これらはセンサ信号および／またはアクチュエータ信号から引き出されることが可能ないくつかの例示的特徴にすぎず、多数の他の特徴が可能であることを、理解するであろう。
【０１３９】
実際には、故障モデルは、複数の方式で定義され得る。例示的な実装態様において、分析システム１０８は、０と１との間の確率を戻す１つまたは複数のモデル化技法を利用することによって故障モデルを定義し得、それは上述の任意のモデル化技法の形態をとり得る。
【０１４０】
特定の例において、故障モデルの定義は、ブロック７０６で識別された過去の動作データに基づいて応答変数を生成する分析システム１０８を伴い得る。具体的に、分析システム１０８は、特定の時点で受信されたセンサ測定値および／またはアクチュエータ測定値の各セットに関する関連応答変数を決定し得る。したがって、応答変数は、故障モデルと関連づけられたデータセットの形態をとり得る。
【０１４１】
応答変数は、所与の１セットの測定値が、ブロック７０６において決定されたいずれかの時間枠内にあるかどうかを示し得る。すなわち、応答変数は、所与のデータのセットが、故障の発生について注目している時点からのものかどうかを反映し得る。応答変数は、所与の１セットの測定値がいずれかの決定された時間枠内にある場合、関連応答変数が１の値を割り当てられ、そうでない場合、関連応答変数が０の値を割り当てられるように、２進値の応答変数であり得る。
【０１４２】
応答変数に基づいて故障モデルを定義する特定の例を続けると、分析システム１０８は、ブロック７０６において識別された過去の動作データ、および生成された応答変数によって、故障モデルをトレーニングし得る。このトレーニングプロセスに基づいて、分析システム１０８は次に、様々なセンサデータおよび／またはアクチュエータデータを入力として受信し、応答変数を生成するために用いられる時間枠と同等の期間内に故障が発生するであろう、０と１との間の確率を出力する故障モデルを定義し得る。
【０１４３】
いくつかの場合において、ブロック７０６で識別される、過去の動作データによるトレーニング、および生成された応答変数は、各センサおよび／またはアクチュエータに関する変数重要度統計値をもたらし得る。所与の変数重要度統計値が、将来への期間内に所与の故障が発生するであろう確率に対する、センサの、またはアクチュエータの相対的な影響を示し得る。
【０１４４】
さらに、または代替的に、分析システム１０８は、コックス比例ハザード技法などの、１つまたは複数の生存率分析技法に基づいて、故障モデルを定義すべく構成され得る。分析システム１０８は、上記で述べたモデル化技法といくつかの点で同様の方式で、生存率分析技法を利用し得るが、しかし、分析システム１０８は、最後の故障から期待される次のイベントまでの時間を示す生存時間応答変数を決定し得る。期待される次のイベントは、センサおよび／もしくはアクチュエータ測定値のいずれかの受信、または故障の発生のうち、先に発生したどちらでもあり得る。この応答変数は、測定値が受信される特定の各時点と関連づけられた、１対の値を含み得る。応答変数は、次に、将来の所与の時間枠内に故障が発生するであろう確率を決定すべく利用され得る。
【０１４５】
いくつかの例示的な実装態様において、故障モデルは、数あるデータの中でも、気象データ、「軸焼け」データなどの外部データに部分的に基づいて定義され得る。例えば、そのようなデータに基づいて、故障モデルは出力する故障確率を増加または減少させ得る。
【０１４６】
実際には、外部データは、資産センサおよび／またはアクチュエータが測定値を取得する時刻と一致しない時点で観測されることがある。例えば、「軸焼け」データが収集される時刻（例えば、機関車が軸焼けセンサを備える鉄道線路の区間を通過する時刻）は、センサ測定値および／またはアクチュエータ測定値の時刻とは一致しないことがある。そのような場合において、分析システム１０８は、センサ測定時刻に対応する時刻において観測されたであろう外部データ観測値を決定するために、１つまたは複数の動作を実行すべく構成され得る。
【０１４７】
具体的には、分析システム１０８は、外部データ観測値の時刻および測定の時刻を利用して、外部データ観測値を補間して、測定の時刻に対応する時刻に関する外部データ値を生成し得る。外部データの補間は、外部データ観測値またはそれから引き出された特徴が、故障モデルへの入力値として含まれることを可能にし得る。実際には、数ある例の中でも、最近隣補間、線形補間、多項式補間、スプライン補間などの様々な技法が、センサデータおよび／またはアクチュエータデータによって外部データを補間すべく用いられ得る。
【０１４８】
図７に戻ると、分析システム１０８が、ブロック７０２に定義された故障のセットから所与の故障に関する故障モデルを決定した後に、分析システム１０８は、故障モデルが決定されるべき何らかの残りの故障があるかどうか決定し得る。故障モデルが決定されるべき故障が残っている場合には、分析システム１０８は、ブロック７０４−７０８のループを繰り返し得る。いくつかの実装態様において、分析システム１０８は、ブロック７０２で定義されるすべての故障を包含する単一の故障モデルを決定し得る。他の実装態様において、分析システム１０８は、資産１０２の各サブシステムに関する故障モデルを決定し得、それは次に、資産レベルの故障モデルを決定すべく利用され得る。他の例もまた可能である。
【０１４９】
最後に、ブロック７１０において、定義されたセット（例えば、個々の故障モデル）における各故障に関して定義された関係は、次に、将来の所与の時間枠（例えば、次の２週間）内に故障が発生する全体的な可能性を予測するためのモデル（例えば、健全性指標モデル）へと組み合わされ得る。すなわち、モデルは、１つまたは複数のセンサおよび／またはアクチュエータからのセンサ測定値および／またはアクチュエータ測定値を入力として受信し、故障のセットのうち少なくとも１つの故障が、将来の所与の時間枠内に発生するであろう単一の確率を出力する。
【０１５０】
分析システム１０８は、複数の方式で健全性指標モデルを定義し得、それらの方式は健全性指標の所望の粒度に依存し得る。すなわち、複数の故障モデルがある場合の事例において、故障モデルの結果が、健全性指標モデルの出力を取得するための複数の方式において利用され得る。例えば、分析システム１０８は、複数の故障モデルから最大値、中央値、平均値を決定し得、その決定された値を健全性指標モデルの出力として利用し得る。
【０１５１】
他の例において、健全性指標モデルを決定することは、個々の故障モデルによって出力される個々の確率に重みづけをする分析システム１０８を伴い得る。例えば、故障のセットからの各故障は、等しく望ましくないとみなされてよく、健全性指標モデルの決定において各確率は同様に、同一の重みづけをされてよい。他の事例において、いくつかの故障（例えば、より破局的なもの、またはより長い修理期間が必要なものなど）は他のものより望ましくないとみなされてよく、それらの対応する確率は、他のものより大きく重みづけされてよい。
【０１５２】
さらに他の例において、健全性指標モデルを決定することは、回帰技法などの１つまたは複数のモデル化技法を利用する分析システム１０８を伴い得る。一括応答変数は、個々の各故障モデルの応答変数の論理和（論理ＯＲ）の形態をとり得る。例えば、ブロック７０６において決定された任意の時間枠内に発生する任意の測定値のセットに関連づけられた一括応答変数は、１の値をとり得、一方、任意の時間枠外に発生する測定値のセットに関連づけられた一括応答変数は、０の値をとり得る。健全性指標モデルを定義する他の方式もまた可能である。
【０１５３】
いくつかの実装態様において、ブロック７１０は不要であり得る。例えば、上記で論じたように、分析システム１０８は単一の故障モデルを決定し得、その場合には健全性指標モデルは単一の故障モデルであり得る。
【０１５４】
実際には、分析システム１０８は、個々の故障モデルおよび／または全体の健全性指標モデルを更新すべく構成され得る。分析システム１０８は、毎日、毎週、毎月などでモデルを更新してよく、資産１０２からの、または他の資産からの（例えば、資産１０２と同じ群の他の資産からの）、過去の動作データの新たな部分に基づいてモデルを更新してよい。他の例もまた可能である。
【０１５５】
同様に、利用不可能性モデルは、様々な他の形態をとり得る。例えば、利用不可能性モデルは、（例えば、資産の動作データに基づいて）メッシュネットワークにおける資産の通信能力を予測し得る。別の例において、利用不可能性モデルは、（例えば、時刻、バッテリ寿命、予定された保守などに基づいて）資産がオフライン化するかどうか予測し得る。
【０１５６】
図６に戻ると、また、分析システム１０８は、資産に関する個別予測モデルを定義すべくも構成され得、それはベースラインとして一括予測モデルを利用することを伴い得る。個別化は、資産の特定の特性に基づき得る。このようにして、分析システム１０８は、所与の資産に、一括予測モデルと比較してより正確かつロバストな予測モデルを提供し得る。
【０１５７】
具体的には、ブロック６０６において、分析システム１０８は、資産１０２などの所与の資産に関してブロック６０４で定義された一括モデルを、個別化するかどうか判定すべく構成され得る。分析システム１０８は、複数の方式でこの判定を実行し得る。
【０１５８】
いくつかの場合において、分析システム１０８は、個別予測モデルをデフォルトで定義すべく構成され得る。他の場合において、分析システム１０８は、資産１０２の特定の特性に基づいて、個別予測モデルを定義するかどうか判定すべく構成され得る。例えば、いくつかの場合において、特定の種類またはクラスの資産、または特定の環境で動作する資産、または特定の健全性スコアを有する資産のみが、個別予測モデルを受信し得る。さらに他の場合において、ユーザは、個別モデルが資産１０２に関して定義されるかどうか定義し得る。他の例もまた可能である。
【０１５９】
いずれの場合も、分析システム１０８が資産１０２に関する個別予測モデルを定義すると判定した場合、分析システム１０８はブロック６０８においてそのように定義し得る。そうでない場合、分析システム１０８は定義段階を終了し得る。
【０１６０】
ブロック６０８において、分析システム１０８は、個別予測モデルを複数の方式で定義すべく構成され得る。例示的な実装態様において、分析システム１０８は、資産１０２の１つまたは複数の特性に少なくとも部分的に基づいて、個別予測モデルを定義し得る。
【０１６１】
個別予測モデルを資産１０２に関して定義する前に、分析システム１０８は、個別モデルの基礎を形成する、注目している１つまたは複数の資産特性を決定している可能性がある。実際には、異なる予測モデルは、対応する注目している特性が異なる可能性がある。
【０１６２】
一般的に、注目している特性は、一括予測モデルに関連する特性であり得る。例えば、注目している特性は、分析システム１０８が一括予測モデルの精度に決定的な影響を有する、という特性であり得る。そのような特性の例として、数ある特性の中で、資産年数、資産使用量、資産の処理能力、資産負荷、（おそらく、以下で論じられる資産健全性指標によって示される）資産健全性、資産クラス（例えば、ブランドおよび／またはモデル）、および資産が動作する環境が挙げられ得る。
【０１６３】
分析システム１０８は、注目している特性を複数の方式で決定していた可能性がある。１つの例において、分析システム１０８は、注目している特性を容易に識別する１つまたは複数のモデリングシミュレーションを実行することによって、そのように決定していた可能性がある。別の例において、注目している特性は、事前に定義されて、分析システム１０８のデータストレージに格納されていた可能性がある。さらに別の例において、注目している特性は、ユーザによって定義され、出力システム１１０を介して分析システム１０８に提供されていた可能性がある。他の例もまた可能である。
【０１６４】
いずれの場合も、注目している特性を決定した後、分析システム１０８は、決定された注目している特性に対応する資産１０２の特性を決定し得る。すなわち、分析システム１０８は、注目している特性に対応する資産１０２の特性の、種類、値、それらの有無などを決定し得る。分析システム１０８は、複数の方式でこの動作を実行し得る。
【０１６５】
例えば、分析システム１０８は、資産１０２および／またはデータソース１１２から生じるデータに基づいて、この動作を実行すべく構成され得る。具体的には、分析システム１０８は、資産１０２に関する動作データ、および／または、データソース１１２からの外部データを利用して、資産１０２の１つまたは複数の特性を決定し得る。他の例もまた可能である。
【０１６６】
資産１０２の、決定された１つまたは複数の特性に基づいて、分析システム１０８は一括モデルを修正することによって個別予測モデルを定義し得る。一括モデルは、複数の方式で修正され得る。例えば、一括モデルは、数ある例の中でも、１つまたは複数のモデル入力を変更する（例えば、追加する、除去する、並び替えるなど）こと、資産動作限界に対応する１つまたは複数のセンサおよび／またはアクチュエータ測定範囲を変更すること（例えば、「重要インジケータ」イベントに対応する動作限界を変更すること）、１つまたは複数のモデル計算を変更すること、変数または計算の出力を重みづけする（または、重みを変更する）こと、一括モデルを定義すべく利用されたものとは異なるモデル化技法を利用すること、および／または、一括モデルを定義すべく利用されたものとは異なる応答変数を利用することによって修正され得る。
【０１６７】
実際には、一括モデルを個別化することは、所与の資産の１つまたは複数の特性に依存し得る。具体的には、特定の特性は、他の特性とは異なる影響を、一括モデルの修正に与え得る。さらに、特性の種類、値、存在などが、同様に修正に影響を与え得る。例えば、資産年数は一括モデルの第１の部分に影響を与え得る一方、資産クラスは一括モデルの第２の、異なる部分に影響を与え得る。そして、年数の第１の範囲内の資産年数は、第１の方式で、一括モデルの第１の部分に影響を与え得る一方、年数の第１の範囲とは異なる第２の範囲内の資産年数は、第２の、異なる方式で一括モデルの第１の部分に影響を与え得る。他の例もまた可能である。
【０１６８】
いくつかの実装態様において、一括モデルを個別化することは、資産特性に加えて、または資産特性の代替的に、検討事項に依存し得る。例えば、一括モデルは、資産が（例えば、整備士などによって定義されるような）比較的良好な動作状態にあると知られるときの、資産のセンサおよび／またはアクチュエータ読み取り値に基づいて個別化され得る。より具体的には、重要インジケータ予測モデルの例において、分析システム１０８は、資産が良好な動作状態にある旨の指示を、資産からの動作データとともに、（例えば、整備士によって動作する演算処理デバイスから）受信すべく構成され得る。少なくとも動作データに基づいて、分析システム１０８は次に、「重要インジケータ」イベントに対応する動作限界をそれぞれ修正することによって、資産に関する重要インジケータ予測モデルを個別化し得る。他の例もまた可能である。
【０１６９】
いくつかの例示的な実装態様において、分析システム１０８は、一括予測モデルを最初に定義することなく、所与の資産に関する個別予測モデルを定義すべく構成され得ることが、また理解されるべきである。他の例が、また可能である。
［２．  ルーティングテーブルを更新するためのワークフロー］
【０１７０】
上記で留意されたように、分析システム１０８はまた、利用不可能性モデルに基づいてルーティングテーブルを更新させるためのワークフローを定義すべくも構成され得る。上記で述べられたように、分析システム１０８は、メッシュネットワークにおける複数の資産のうち所与の資産が、将来の所与の期間内に利用不可能になる可能性があるかどうか決定する、利用不可能性モデルを実施し得る。所与の資産は、数あるシナリオの中でも、所与の資産の故障、所与の資産がオフライン化すること、所与の資産に関する予定された休止期間、所与の資産がメッシュネットワークを介して通信不可能となること、または、そうでなければ、所与の資産がメッシュネットワークにおけるデータリレーとして機能することが不可能となることに基づいて利用不可能となり得る。
【０１７１】
いずれの場合も、ルーティングテーブルを更新するワークフローは、１つまたは複数の他の資産が将来利用不可能になる可能性がある旨を考慮すべく、メッシュネットワーク内のノードとしての役割を果たす資産に、それのルーティング情報を更新させ得る。このようにして、メッシュネットワークは、将来利用不可能になりそうなノード（資産）に依拠しない経路を利用するように、あらかじめ更新されていてもよい。
【０１７２】
分析システム１０８は、そのようなルーティングテーブルワークフローを、様々なトリガに基づいてトリガされるように定義し得る。一般的に、そのようなトリガは、所与の資産が利用不可能になる可能性があることを示し得る。例示的な実装態様において、トリガは、所与の資産の健全性スコアの形態をとり得る。具体的に、ルーティングテーブルワークフローは、所与の資産の健全性スコアが、利用不可能性閾値（例えば、健全性スコア閾値の値）を満たす旨、下回ったままである旨、または超える旨を決定する分析システム１０８（または、おそらく、所与の資産のローカル分析デバイス）に基づいてトリガされ得、利用不可能性閾値は、スコアがどのように構成されているかに依存し得る。
【０１７３】
代替的に、トリガは、所与の資産の健全性スコアが所与の期間、利用不可能性閾値を満たす旨、下回ったままである旨、または超える旨を決定する分析システム１０８に基づき得る。例えば、所与の資産が瞬間的に利用不可能であることは十分ではないかもしれない。所与の資産が、例えば３０分、１時間または数時間などの特定の時間に利用不可能になる可能性があろう旨が決定される場合、所与の資産は利用不可能であるとみなされ得る。例示的な実装態様において、分析システム１０８は、分析されている所与のルートの最近のスループットと、そのスループット状態が示されると想定している所与のルートを通って所与の（例えば、特定のサイズの）メッセージを伝送するために必要な最小時間との比較に基づいて、ワークフローをトリガする利用不可能性の期間を決定し得る。期間は、同様に他の方式でも決定され得る。
【０１７４】
実際には、分析システム１０８は、資産１０２、１０３および１０４のすべてに関してルーティングテーブルワークフロー（例えば、一括ワークフロー）を定義し得る。しかしながら、いくつかの実装態様において、分析システム１０８は、１つまたは複数の資産に関してワークフローを個別化し得る。例えば、資産１０２は、資産１０３の利用不可能性閾値とは異なる利用不可能性閾値を有し得る。
【０１７５】
分析システム１０８は、個別予測モデルに基づいて、個別ワークフローを定義するかどうか判定し得る。さらに別の実装態様において、分析システム１０８は、個別予測モデルが定義された場合に個別ワークフローを定義するように判定し得る。別の実装態様において、分析システム１０８は、一括ワークフローの効果に影響を及ぼす注目している特性を用いて、異なる資産に関して異なる利用不可能性閾値を決定し得る。他の例もまた可能である。
【０１７６】
動作中において、分析システム１０８は、実施されるワークフローに基づいて、１つまたは複数の資産１０２−１０４にシグナリングメッセージを伝送し得る。すなわち、シグナリングメッセージは、所与の資産が将来の所与の期間内に利用不可能になる可能性がある旨の、分析システム１０８の決定を反映し得る。シグナリングメッセージは、それのルーティングテーブルを更新してルーティングトポロジを更新するように資産に命令し得、また、他の資産の更新をリレーするように資産に命令もし得る。例えば、利用不可能性モデルの実施、および、資産１０４が利用不可能になる可能性がある旨の決定に基づいて、分析システム１０８は、資産１０２にシグナリングメッセージを伝送し得、同様に、それのルーティングテーブルを更新する。その後に、資産１０２は、資産１０３にシグナリングメッセージを伝送し得、それはそれのルーティングテーブルを更新する。
【０１７７】
さらに、いくつかの実装態様において、シグナリングメッセージは、すぐに利用不可能となる見込みの資産（例えば、資産１０４）をルーティングトポロジから除去する旨の命令を含み得る。別の実装態様において、分析システム１０８は、メッシュネットワーク１０５における各資産に関するルーティングトポロジを更新し得、更新されたルーティングトポロジの指示を（例えば、それぞれのルーティングテーブルを資産に伝送することによって）各資産に伝送し得る。
［Ｄ．  モデル・ワークフロー対の実施］
【０１７８】
上記で開示されたモデル・ワークフロー対が、分析システム１０８によって一旦定義されると、そのモデル・ワークフロー対は次に分析システム１０８によって実施されることがあり、および／または、（例えば、ローカル分析デバイスによる）ローカル実施のために資産に送信されることがある。
【０１７９】
利用不可能性モデルを実施する間、分析システム１０８および／または所与の資産は、所与の資産が将来の所与の期間内に利用不可能になる可能性がある旨を決定し得る。例えば、分析システム１０８および／または所与の資産は、利用不可能性モデルの出力を閾値と比較し、それにより、出力が閾値を満たしているか上回っている旨を決定することによって、この決定を行い得る。同様に、分析システム１０８および／または所与の資産は，１つまたは複数のルーティングテーブルを更新させるためにワークフローを実施し得る。例えば、分析システム１０８は、所与の資産が利用不可能になる可能性が低い旨の決定を含む信号メッセージを、１つまたは複数の資産に伝送し得る。別の例において、分析システム１０８は、それぞれの資産に関するルーティング設定の更新を含む信号メッセージを、１つまたは複数の資産に伝送し得る。
【０１８０】
このワークフローの実施の結果として、すぐに利用不可能となる見込みの資産がルーティングテーブルから除去され得るか、その資産を含む経路が無効にされ得る。例えば、メッシュネットワークにおける他の資産が、すぐに利用不可能となる見込みの資産を迂回して、それが利用不可能であることを前提にしてルーティングするように、ルーティングテーブルは更新され得る。
【０１８１】
本明細書に開示されたモデル・ワークフロー対はまた、すぐに利用不可能となる見込みの資産が改めて利用可能になる旨の決定があった場合、改めて後でルーティングテーブルを更新もさせ得る。
【０１８２】
上記は、ネットワーク内のノードの役割を果たす資産を論じる一方、これは限定を意図するものではない。いくつかの例示的な実装態様において、センサ（例えば、環境センサ、工業自動化センサなど）がノードの役割を果たし得、したがって上記の動作は修正され得る。
［ＶＩ．  例示的な方法］
【０１８３】
図８は、メッシュネットワーク１０５に関するルーティングテーブルを更新するための例示的な方法を図示する、フローチャート８００である。例示の目的で、例示的な方法は分析システム１０８によって実行されるものとして説明されたが、しかし、この定義段階は、メッシュネットワーク１０５における資産のうち１つのローカル分析デバイス２２０を含む他のシステムによっても同様に実行され得る。当業者は、フローチャート５００は明確性および説明のために提供され、動作の多数の他の組み合わせが、メッシュネットワークにおけるルーティングテーブルを更新するために利用され得ることを、理解するであろう。
【０１８４】
図８に示されるように、ブロック８０２において、分析システム１０８は、予測モデルに基づいて、メッシュネットワークにおける複数の資産のうち所与の資産が将来の所与の期間内に利用不可能になる可能性がある旨を決定することによって始まり得る。いくつかの実装態様において、複数の資産は、輸送用機械、工業用機械、医療用機械、およびユーティリティ設備のうち少なくとも１つを含み得る。
【０１８５】
いくつかの実装態様において、予測モデルは、複数の資産に関するセンサから受信された過去のデータに基づき得る。分析システム１０８は、所与の資産から、または他の資産からセンサデータを受信することに基づいて、所与の資産が利用不可能になる可能性がある旨を決定し得、センサデータに予測モデルを適用することに基づいて、所与の資産に関する健全性スコアを決定し得、所与の資産に関する健全性スコアが利用不可能性尤度閾値を満たす旨を決定し得る。いくつかの他の実装態様において、予測モデルは、資産に関連づけられた情報に基づき得る。例えば、所与の資産は、資産の故障、資産に関して予定された休止期間（例えば、オフライン化する資産）、夜に資産の電源が切られること、および、資産がメッシュネットワークを介して通信不可能になること、に基づいて利用不可能となり得る。予測モデルは、資産の年数、合計の動作時間、最後の保守イベント以来の時間などに基づいて、所与の資産が利用不可能になる可能性がある旨を決定し得る。
【０１８６】
ブロック８０４において、決定に応答して、メッシュネットワークにおける少なくとも１つの他の資産に関するルーティング設定を更新させる。ルーティング設定は、メッシュネットワークにおける各資産が、１つまたは複数の他の資産にデータを伝送するか、それからデータを受信し、図１を参照して上記で述べられたシステム内の他のエンティティへデータを伝送する経路を含み得る。
【０１８７】
ルーティング設定は、利用不可能になる可能性があるルーティングテーブルから資産を除去することを含み得る。代替的に、または加えて、分析システム１０８は、ルーティングテーブルの部分としてそれらの資産を維持し得るが、しかし、それらの資産の状態が変化するまで、利用不可能になりそうな資産を含む経路を更新し得る。例えば、資産が健全性スコアに関連する場合、健全性スコアが利用不可能性尤度閾値を下回る範囲で増減する場合、資産は利用可能であると決定されてよい。資産２００がメッシュネットワークに関するルーティングテーブルを更新するいくつかの実装態様において、資産は更新済みルーティングテーブルに基づいて通信し得、更新済みルーティングテーブルの少なくとも一部を、複数の資産のうち別の資産へ伝送し得る。
【図１】
2018528693.tif 000003
【図２】
2018528693.tif 000004
【図３】
2018528693.tif 000005
【図４】
2018528693.tif 000006
【図５】
2018528693.tif 000007
【図６】
2018528693.tif 000008
【図７】
2018528693.tif 000009
【図８】
2018528693.tif 000010
【国際調査報告】
2018528693.tif 000011
2018528693.tif 000012