以下の開示では、添付図及びいくつかの例示的なシナリオを参照する。当業者であれば、そのような参照は説明を目的としているだけであり、したがって、限定するつもりはないことを理解するであろう。開示されるシステム、装置、及び方法の一部又は全てが、様々な方式で再構成され、組み合わされ、追加され、及び/又は除去されてよく、これらのそれぞれは本明細書において企図されている。
I.例示的なネットワーク構成
ここで図を参照すると、図1は、例示的な実施形態が実装され得る例示的なネットワーク構成100を図示している。示されるように、ネットワーク構成100は、資産102と、資産104と、通信ネットワーク106と、解析システムの形態をとってよいリモート演算処理システム108と、出力システム110と、データソース112とを含む。
通信ネットワーク106は、ネットワーク構成100内の要素のそれぞれを通信可能に接続することができる。例えば、資産102及び104は、通信ネットワーク106を介して解析システム108と通信することができる。場合によっては、資産102及び104は、資産ゲートウェイ(不図示)など、同じように解析システム108と通信する1つ又は複数の中間システムと通信することができる。同様に、解析システム108は、通信ネットワーク106を介して出力システム110と通信することができる。場合によっては、解析システム108は、ホストサーバ(不図示)など、同じように出力システム110と通信する1つ又は複数の中間システムと通信することができる。多くの他の構成もあり得る。例示的な場合において、通信ネットワーク106は、ネットワーク要素間のセキュアな通信を(例えば、暗号化又は他のセキュリティ対策によって)容易にすることができる。
概して、資産102及び104は、1つ又は複数の動作(これらは、分野に基づいて定義されてよい)を実行するように構成された任意の装置の形態をとってよく、所与の資産の1つ又は複数の動作状態を示すデータを伝送するように構成された機器を含んでもよい。いくつかの例において、資産が、1つ又は複数のそれぞれの動作を実行するように構成された、1つ又は複数のサブシステムを含んでよい。実際には、資産が動作するために、複数のサブシステムが並列に又は連続的に動作してよい。
例示的な資産は、いくつかある例の中でも特に、輸送機械(例えば、機関車、航空機、乗用車、セミトレーラートラック、船舶など)、工業機械(例えば、採掘機械、建設機械、工場自動化など)、医療装置(例えば、医療用撮像装置、手術用機器、医療用監視システム、医療用検査機器など)、及びユーティリティ設備(例えば、タービン、ソーラーファームなど)を含んでよい。当業者であれば、これらが資産のほんのいくつかの例であること、また多数の他の資産があり得、本明細書において企図されていることを理解するであろう。
例示的な実装態様において、資産102及び104は、それぞれ同じ種類であってよく(例えば、いくつかある例の中でも特に、機関車群若しくは航空機群、風力タービン群、又はMRI装置一式)、おそらく同じクラス(例えば、同じブランド及び/又は型式)であってよい。他の例において、資産102及び104は、種類、ブランド、型式などが異なってよい。これらの資産は、図2を参照しながら、以下でさらに詳細に論じられる。
示されるように、資産102及び104、並びにおそらくデータソース112は、通信ネットワーク106を介して解析システム108と通信することができる。概して、通信ネットワーク106は、1つ又は複数の演算処理システムと、ネットワーク要素間のデータ転送を容易にするように構成されたネットワークインフラストラクチャとを含んでよい。通信ネットワーク106は、1つ又は複数のワイドエリアネットワーク(WAN)及び/若しくはローカルエリアネットワーク(LAN)であってよく、又はこれらを含んでもよく、これらのネットワークは、有線及び/又は無線であってよく、セキュアな通信をサポートしてよい。いくつかの例において、通信ネットワーク106は、いくつかあるネットワークの中でも特に、1つ又は複数のセルラネットワーク及び/又はインターネットを含んでよい。通信ネットワーク106は、LTE、CDMA、GSM(登録商標)、LPWAN、WiFi、Bluetooth(登録商標)、Ethernet(登録商標)、HTTP/S、TCP、CoAP/DTLSなど、1つ又は複数の通信プロトコルに従って動作することができる。通信ネットワーク106は、単一のネットワークとして示されているが、通信ネットワーク106は、互いに通信可能に結合された複数の別個のネットワークを含んでよいことを理解されたい。通信ネットワーク106は、他の形態もとることがある。
上述されたように、解析システム108は、資産102及び104、並びにデータソース112からデータを受信するように構成されてよい。大まかに言うと、解析システム108は、データを受信、処理、解析、及び出力するように構成された、サーバやデータベースなど、1つ又は複数の演算処理システムを含んでよい。解析システム108は、いくつかある例の中でも特に、TPL Dataflow又はNiFiなど、所与のデータフロー技術に従って構成されてよい。解析システム108は、図3を参照しながら、以下でさらに詳細に論じられる。
示されるように、解析システム108は、資産102及び104、並びに/又は出力システム110へデータを伝送するように構成されてよい。伝送される特定のデータは、様々な形態をとってよく、これについては、以下でさらに詳細に説明されることになる。
概して、出力システム110は、データを受信して、何らかの形態の出力を提供するように構成された、演算処理システム又は演算処理装置の形態をとってよい。出力システム110は、様々な形態をとってよい。1つの例において、出力システム110は、データを受信し、そのデータに応答して、可聴出力、視覚出力、及び/又は触知出力を提供するように構成された出力装置であってよく、又はそのような出力装置を含んでもよい。概して、出力装置は、ユーザ入力を受信するように構成された1つ又は複数の入力インタフェースを含んでよく、出力装置は、そのようなユーザ入力に基づき、通信ネットワーク106を通じてデータを伝送するように構成されてよい。出力装置の例には、タブレット、スマートフォン、ラップトップコンピュータ、他のモバイル演算処理装置、デスクトップコンピュータ、スマートテレビなどが含まれる。
出力システム110の別の例は、資産を修理するために、整備士の要請などを出力するように構成された、作業発注システムの形態をとってよい。出力システム110のさらに別の例は、資産の部品を発注し、その受領書を出力するように構成された、部品発注システムの形態をとってよい。多数の他の出力システムもあり得る。
データソース112は、解析システム108と通信するように構成されてよい。概して、データソース112は、解析システム108により実行された機能に関連し得るデータを収集、格納、及び/若しくは解析システム108などの他のシステムに提供するように構成された、1つ又は複数の演算処理システムであってよく、又はそのような1つ又は複数の演算処理システムを含んでもよい。データソース112は、資産102及び104から独立して、データを生成及び/又は取得するように構成されてよい。したがって、データソース112により提供されるデータは、本明細書において、「外部データ」と呼ばれることがある。データソース112は、現在のデータ及び/又は過去のデータを提供するように構成されてよい。実際には、解析システム108は、データソースにより提供されるサービスに「加入」することで、データソース112からデータを受信することができる。しかし、解析システム108は、他の方式でも、データソース112からデータを受信することができる。
データソース112の例には、環境データソース、資産管理データソース、及び他のデータソースが含まれる。概して、環境データソースは、資産が動作する環境のいくつかの特性を示すデータを提供する。環境データソースの例には、いくつかある例の中でも特に、所与の地域の自然の特徴又は人工的な特徴に関する情報を提供する、気象データサーバ、全地球衛星航法システム(GNSS)サーバ、地図データサーバ、及び地形データサーバが含まれる。
概して、資産管理データソースは、資産の動作又は維持に影響を与え得るエンティティ(例えば、他の資産)のイベント又は状態を示すデータ(例えば、いつどこで資産が動作し、又は整備を受けたことがあるか)を提供する。資産管理データソースの例には、いくつかある例の中でも特に、空路交通、海路交通、及び/又は陸路交通に関する情報を提供する、交通データサーバ、特定の日付及び/又は特定の時間における資産の期待されるルート及び/又は位置に関する情報を提供する、資産スケジュールサーバ、欠陥検出器システム(「発熱軸箱」検出器としても知られている)に近接して通過する資産の1つ又は複数の動作状態に関する情報を提供する、欠陥検出器システム、特定の供給業者が在庫に持っている部品、及びそれらの価格に関する情報を提供する、部品供給業者サーバ、並びに修理工場の処理能力に関する情報を提供する修理工場サーバなどが含まれる。
他のデータソースに例には、いくつかある例の中でも特に、電気消費に関する情報を提供する送電網サーバ、資産の過去の動作データを格納する外部データベースが含まれる。当業者であれば、これらがデータソースのほんのいくつかの例であること、また多数の他のデータソースがあり得ることを理解するであろう。
ネットワーク構成100は、本明細書で説明される実施形態が実装され得るネットワークの1つの例であることを理解されたい。多数の他の構成があり得、本明細書において企図されている。例えば、他のネットワーク構成は、図示されていない追加の要素を含んでよく、及び/又は、図示された要素をより多く若しくはより少なく含んでもよい。
II.例示的な資産
図2を参照すると、例示的な資産200の簡略ブロック図が図示されている。図1の資産102及び104のうち、どちらか又は両方が資産200のように構成されてよい。示されるように、資産200は、1つ又は複数のサブシステム202と、1つ又は複数のセンサ204と、1つ又は複数のアクチュエータ205と、中央処理装置206と、データストレージ208と、ネットワークインタフェース210と、ユーザインタフェース212と、ローカル解析装置220とを含んでよく、それらの全ては、システムバス、ネットワーク、又は他の接続機構によって(直接又は間接的に)通信可能に結合されてよい。当業者であれば、資産200は、示されていない追加の要素を含んでよく、及び/又は、図示された要素をより多く若しくはより少なく含んでもよいことを理解するであろう。
大まかに言うと、資産200は、1つ又は複数の動作を実行するように構成された、1つ又は複数の電気的要素、機械的要素、及び/又は電気機械的要素を含んでよい。場合によっては、1つ又は複数の要素は、所与のサブシステム202にグループ化されてよい。
概して、サブシステム202は、資産200の一部である関連要素のグループを含んでよい。単一のサブシステム202は、1つ若しくは複数の動作を独立して実行してよく、又は、単一のサブシステム202は、1つ若しくは複数の動作を実行するために、1つ若しくは複数の他のサブシステムとともに動作してよい。通常、異なる種類の資産、及び異なるクラスの同じ種類の資産であっても、異なるサブシステムを含んでよい。
例えば、輸送資産という観点では、サブシステム202の例は、多数のサブシステムの中でも特に、エンジン、変速機、ドライブトレイン、燃料システム、バッテリシステム、排気システム、ブレーキシステム、電気システム、信号処理システム、発電機、ギアボックス、ロータ、及び油圧システムを含んでよい。医療装置という観点では、サブシステム202の例は、多数のサブシステムの中でも特に、スキャンシステム、モータ、コイル及び/又は磁石システム、信号処理システム、ロータ、並びに電気システムを含んでよい。
上記に示唆されたように、資産200には、資産200の動作状態を監視するように構成された様々なセンサ204と、資産200又はその要素と相互に作用して、資産200の動作状態を監視するように構成された様々なアクチュエータ205とが備えられてよい。場合によっては、センサ204及び/又はアクチュエータ205のいくつかが、特定のサブシステム202に基づいて、グループ化されてよい。このようにして、センサ204及び/又はアクチュエータ205のグループは、特定のサブシステム202の動作状態を監視するように構成されてよく、そのグループのアクチュエータは、これらの動作状態に基づいて、サブシステムの挙動を変更することができる何らかの方法で、特定のサブシステム202と相互に作用するように構成されてよい。
概して、センサ204は、資産200の1つ又は複数の動作状態を示し得る物理的特性を検出し、電気信号など、検出された物理的特性のインジケーションを提供するように構成されてよい。動作にあたっては、センサ204は、継続的に、周期的に(例えば、サンプリング頻度に基づいて)、及び/又は何らかのトリガイベントに応答して、測定値を取得するように構成されてよい。いくつかの例において、センサ204は、測定を実行するための動作パラメータで事前設定されてよく、及び/又は、中央処理装置206により提供される動作パラメータ(例えば、測定値を取得するようにセンサ204に命令するサンプリング信号)に従って測定を実行してよい。いくつかの例において、異なるセンサ204が異なる動作パラメータを有してよい(例えば、一部のセンサが、第1の頻度に基づいてサンプリングしてよく、他のセンサが、第2の異なる頻度に基づいてサンプリングしてよい)。いずれにしても、センサ204は、測定された物理的特性を示す電気信号を中央処理装置206へ伝送するように構成されてよい。センサ204は、継続的に又は周期的に、そのような信号を中央処理装置206に提供することができる。
例えば、センサ204は、資産200の位置及び/又は動きなどの物理的特性を測定するように構成されてよく、その場合センサは、GNSSセンサ、推測航法を基にしたセンサ、加速度計、ジャイロスコープ、歩数計、磁気計などの形態をとってよい。
さらに、様々なセンサ204が、資産200の他の動作状態を測定するように構成されてよく、それらの動作状態の例には、いくつかある例の中でも特に、温度、圧力、速度、加速度又は減速度、摩擦力、電力使用量、燃料使用量、流体レベル、ランタイム、電圧及び電流、磁界、電界、物体の有無、各要素の位置、並びに発電が含まれてよい。当業者であれば、これらは、センサが測定するように構成され得る、ほんのいくつかの例示的な動作状態であることを理解するであろう。産業上の応用又は特定の資産に応じて、追加のセンサ又はより少ないセンサが用いられてよい。
上記に示唆されたように、アクチュエータ205が、いくつかの点で、センサ204に類似して構成されてよい。具体的には、アクチュエータ205は、資産200の動作状態を示す物理的特性を検出し、そのインジケーションを、センサ204と類似した方式で提供するように構成されてよい。
さらに、アクチュエータ205は、資産200、1つ若しくは複数のサブシステム202、及び/又はそれらの何らかの要素と、相互に作用するように構成されてよい。したがって、アクチュエータ205は、機械的動作を実行する(例えば、動く)ように構成されている、モータなどを含んでよく、又は別の方法で、要素、サブシステム、若しくはシステムを制御してもよい。特定の例において、アクチュエータは、燃料流量を測定し、その燃料流量を変更する(例えば、その燃料流量を制限する)ように構成されてよく、又は、アクチュエータは、油圧を測定し、その油圧を変更する(例えば、その油圧を増やす又は減らす)ように構成されてよい。アクチュエータに関する多数の他の例示的な相互作用もあり得、本明細書において企図されている。
概して、中央処理装置206は、1つ又は複数のプロセッサ及び/若しくはコントローラを含んでよく、これらは、汎用若しくは専用のプロセッサ又はコントローラの形態をとってよい。具体的には、例示的な実装態様において、中央処理装置206は、マイクロプロセッサ、マイクロコントローラ、特定用途向け集積回路、デジタル信号プロセッサなどであってよく、又はそれらを含んでもよい。同じように、データストレージ208は、いくつかある例の中でも特に、光メモリ、磁気メモリ、有機メモリ、又はフラッシュメモリなど、1つ又は複数の非一時的コンピュータ可読記憶媒体であってよく、又はそれらを含んでもよい。
中央処理装置206は、本明細書において説明される資産の動作を実行するために、コンピュータ可読プログラム命令をデータストレージ208に格納し、格納されたそれらの命令にアクセスして実行するように構成されてよい。例えば、上記に示唆されたように、中央処理装置206は、センサ204及び/又はアクチュエータ205から、それぞれのセンサ信号を受信するように構成されてよい。中央処理装置206は、センサデータ及び/又はアクチュエータデータをデータストレージ208に格納し、後でデータストレージ208のデータにアクセスするように構成されてよい。
中央処理装置206は、受信されたセンサ信号及び/又はアクチュエータ信号が、障害コードなど、任意の異常状態インジケータをトリガするかどうか判定するように構成されてもよい。例えば、中央処理装置206は、異常状態ルールをデータストレージ208に格納するように構成されてよく、異常状態ルールのそれぞれは、特定の異常状態を表す所与の異常状態インジケータ、及び異常状態インジケータをトリガするそれぞれのトリガ基準を含む。すなわち、各異常状態インジケータは、異常状態インジケータがトリガされる前に満たされなければならない1つ若しくは複数のセンサ測定値、及び/又はアクチュエータ測定値に対応する。実際には、資産200は、異常状態ルールで事前にプログラムされてよく、及び/又は、解析システム108などの演算処理システムから、新たな異常状態ルール、若しくは既存のルールの更新を受信してよい。
いずれにしても、中央処理装置206は、受信されたセンサ信号及び/又はアクチュエータ信号が、任意の異常状態インジケータをトリガするかどうか判定するように構成されてよい。すなわち、中央処理装置206は、受信されたセンサ信号及び/又はアクチュエータ信号が、任意のトリガ基準を満たすかどうか判定してよい。そのような判定が肯定的である場合、中央処理装置206は、異常状態データを生成してよく、視覚アラート及び/又は可聴アラートなど、異常状態のインジケーションを資産のユーザインタフェース212に出力させてもよい。さらに、中央処理装置206は、異常状態インジケータの発生がトリガされたことを、おそらくタイムスタンプ付きで、データストレージ208に記録してよい。
図3は、資産の例示的な異常状態インジケータ、及びそれぞれのトリガ基準に関する概念図を図示する。具体的には、図3は、例示的な障害コードの概念図を図示する。示されるように、テーブル300は、センサA、アクチュエータB、及びセンサCにそれぞれ対応する列302、304、及び306と、障害コード1、2、及び3にそれぞれ対応する行308、310、及び312とを含む。次に、登録項目314が、所与の障害コードに対応するセンサ基準(例えば、センサ値の閾値)を指定する。
例えば、障害コード1は、センサAが135回転/分(rpm)より高い回転測定値を検出し、且つセンサCが摂氏65度(℃)より高い温度測定値を検出した場合にトリガされ、障害コード2は、アクチュエータBが1000ボルト(V)より高い電圧測定値を検出し、且つセンサCが摂氏55度より低い温度測定値を検出した場合にトリガされ、障害コード3は、センサAが100rpmより高い回転測定値を検出し、アクチュエータBが750Vより高い電圧測定値を検出し、且つセンサCが摂氏60度より高い温度測定値を検出した場合にトリガされることになる。当業者であれば、図3は、例示及び説明の目的のためだけに提供されていること、また多数の他の障害コード及び/又はトリガ基準があり得、本明細書において企図されていることを理解するであろう。
図2に戻って参照すると、中央処理装置206は、資産200の動作を管理及び/又は制御するための、様々な追加の機能を実行するように構成されてもよい。例えば、中央処理装置206は、サブシステム202及び/又はアクチュエータ205に、スロットル位置の修正など、何らかの動作を実行させる命令信号を、サブシステム202及び/又はアクチュエータ205に提供するように構成されてよい。さらに、中央処理装置206は、センサ204及び/又はアクチュエータ205からのデータを処理する速度を修正するように構成されてよく、あるいは、中央処理装置206は、センサ204及び/又はアクチュエータ205に、例えば、サンプリングレートを修正させる命令信号を、センサ204及び/又はアクチュエータ205に提供するように構成されてよい。さらに、中央処理装置206は、サブシステム202、センサ204、アクチュエータ205、ネットワークインタフェース210、及び/又はユーザインタフェース212からの信号を受信し、そのような信号に基づいて、動作を起こさせるように構成されてよい。さらにまた、中央処理装置206は、データストレージ208に格納された診断ルールに従って、1つ又は複数の診断ツールを中央処理装置206に実行させる信号を、診断装置などの演算処理装置から受信するように構成されてよい。中央処理装置206の他の機能が、以下に論じられる。
ネットワークインタフェース210は、通信ネットワーク106に接続された資産200と様々なネットワーク要素との間に、通信を提供するように構成されてよい。例えば、ネットワークインタフェース210は、通信ネットワーク106との間でやり取りされる無線通信を容易にするように構成されてよく、したがって、様々な無線信号を伝送及び受信するためのアンテナ構造及び関連機器の形態をとってよい。他の例もあり得る。実際には、ネットワークインタフェース210は、限定されないが、上述された通信プロトコルのいずれかなど、通信プロトコルに従って構成されてよい。
ユーザインタフェース212は、資産200とのユーザ対話を容易にするように構成されてよく、ユーザ対話に応答して、ある動作を資産200に実行させることを容易にするように構成されてもよい。ユーザインタフェース212の例には、いくつかある例の中でも特に、タッチセンサ式インタフェース、機械的インタフェース(例えば、レバー、ボタン、ホイール、ダイヤル、キーボードなど)、及び他の入力インタフェース(例えば、マイク)が含まれる。場合によっては、ユーザインタフェース212は、表示画面、スピーカ、ヘッドホンジャックなど、出力要素を含んでよく、又はそれらに接続性を提供してよい。
ローカル解析装置220は概して、資産200に関連したデータを受信して解析するように構成されてよく、そのような解析に基づいて、1つ又は複数の動作を資産200に起こさせてよい。例えば、ローカル解析装置220は、資産200の動作データ(例えば、センサ204及び/又はアクチュエータ205により生成されたデータ)を受信することができ、そのようなデータに基づいて、ある動作を資産200に実行させる命令を、中央処理装置206、センサ204、及び/又はアクチュエータ205に提供することができる。
この動作を容易にするために、ローカル解析装置220は、ローカル解析装置220を資産の内蔵システムのうち1つ又は複数に結合するように構成された、1つ又は複数の資産インタフェースを含んでよい。例えば、図2に示されるように、ローカル解析装置220は、資産の中央処理装置206に対するインタフェースを有してよく、これにより、ローカル解析装置220は、中央処理装置206から動作データ(例えば、センサ204及び/又はアクチュエータ205により生成され、中央処理装置206へ送信される動作データ)を受信し、その後、中央処理装置206に命令を提供することが可能になり得る。このようにして、ローカル解析装置220は、中央処理装置206を介して、資産200の他の内蔵システム(例えば、センサ204及び/又はアクチュエータ205)と間接的にインタフェースをとり、それらの搭載システムからデータを受信することができる。追加的に又は代替的に、図2に示されるように、ローカル解析装置220は、1つ又は複数のセンサ204及び/又はアクチュエータ205に対するインタフェースを有してよく、これにより、ローカル解析装置220は、センサ204及び/又はアクチュエータ205と直接に通信することが可能になり得る。ローカル解析装置220は、他の方式でも、資産200の内蔵システムとインタフェースをとることができ、図2に例示されたインタフェースは、示されていない1つ又は複数の中間システムによって容易になるという可能性を含んでいる。
実際には、ローカル解析装置220によって、資産200は、ローカル解析装置220がなければ、他の資産内要素とともに実行することができない場合がある、予測モデル及び対応するワークフローを実行するなど、高度な解析及び関連動作をローカルに実行することが可能になり得る。したがって、ローカル解析装置220は、追加の処理能力及び/又は知能を資産200に提供するのに役立ち得る。
ローカル解析装置220は、予測モデルと関連しない動作を資産200に実行させるように構成されてもよいことを理解されたい。例えば、ローカル解析装置220は、解析システム108又は出力システム110などのリモートソースからデータを受信してよく、受信されたデータに基づいて、1つ又は複数の動作を資産200に実行させてよい。1つの特定の例が、資産200のファームウェア更新をリモートソースから受信し、次にそのファームウェアを資産200に更新させる、ローカル解析装置220を伴ってよい。別の特定の例が、診断命令をリモートソースから受信し、次に受信された命令に従ってローカル診断ツールを資産200に実行させる、ローカル解析装置220を伴ってよい。多数の他の例もあり得る。
示されるように、ローカル解析装置220は、上述された1つ又は複数の資産インタフェースに加えて、処理ユニット222、データストレージ224、及びネットワークインタフェース226も含んでよく、これらの全ては、システムバス、ネットワーク、又は他の接続機構によって通信可能に結合されてよい。処理ユニット222は、中央処理装置206に関して上述された複数の要素のうちいずれかを含んでよい。同じように、データストレージ224は、1つ若しくは複数の非一時的コンピュータ可読記憶媒体であってよく、又はそれらを含んでもよく、これらの非一時的コンピュータ可読記憶媒体は、上述されたコンピュータ可読記憶媒体のいずれかの形態をとってよい。
処理ユニット222は、本明細書において説明されるローカル解析装置の動作を実行するために、コンピュータ可読プログラム命令をデータストレージ224に格納し、格納されたそれらの命令にアクセスして実行するように構成されてよい。例えば、処理ユニット222は、センサ204及び/又はアクチュエータ205により生成されたそれぞれのセンサ信号及び/又はアクチュエータ信号を受信するように構成されてよく、そのような信号に基づいて、予測モデル・ワークフロー対を実行してよい。他の機能が以下に説明される。
ネットワークインタフェース226は、上述されたネットワークインタフェースと同じ又は類似であってよい。実際には、ネットワークインタフェース226は、ローカル解析装置220と解析システム108との間の通信を容易にすることができる。
いくつかの例示的な実装態様において、ローカル解析装置220は、ユーザインタフェース212と類似し得るユーザインタフェースを含んでよく、及び/又はそのユーザインタフェースと通信してよい。実際には、ユーザインタフェースは、ローカル解析装置220(及び資産200)から遠く離れて位置してよい。他の例もあり得る。
図2は、ローカル解析装置220が、その関連資産(例えば、資産200)に1つ又は複数の資産インタフェースを介して物理的に且つ通信可能に結合されているところを示すが、常にこうであるとは限らないことも理解されたい。例えば、実装態様によっては、ローカル解析装置220は、その関連資産に物理的に結合されていない場合があり、代わりに、ローカル解析装置220は、資産200から遠く離れて位置してよい。そのような一実装態様の一例において、ローカル解析装置220は、資産200に無線で通信可能に結合されてよい。他の配置及び構成もあり得る。
当業者であれば、図2に示される資産200が、資産の簡略した表現のほんの1つの例であり、多数の他の例もあり得ることを理解するであろう。例えば、他の資産は、図示されていない追加の要素を含んでよく、及び/又は、図示された要素をより多く若しくはより少なく含んでもよい。さらに、所与の資産が、その所与の資産の動作を実行するために、協調して動作する複数の別個の資産を含んでよい。他の例もあり得る。
III.例示的な解析システム
次に図4を参照すると、例示的な解析システム400の簡略ブロック図が図示されている。上記に示唆されたように、解析システム400は、本明細書において説明される様々な動作を実行するように通信可能に結合及び構成された、1つ又は複数の演算処理システムを含んでよい。具体的には、示されるように、解析システム400は、データ取得システム402と、データサイエンスシステム404と、1つ又は複数のデータベース406とを含んでよい。これらのシステム要素は、1つ又は複数の無線接続及び/若しくは有線接続を介して、通信可能に結合されてよく、これらの接続は、セキュアな通信を容易にするように構成されてよい。
データ取得システム402は概して、データを受信して処理し、データサイエンスシステム404にデータを出力するように機能することができる。したがって、データ取得システム402は、資産102及び104、出力システム110、並びに/又はデータソース112など、ネットワーク構成100の様々なネットワーク要素からデータを受信するように構成された、1つ又は複数のネットワークインタフェースを含んでよい。具体的には、データ取得システム402は、いくつかある例の中でも特に、アナログ信号、データストリーム、及び/又はネットワークパケットを受信するように構成されてよい。したがって、ネットワークインタフェースは、ポートなど、1つ若しくは複数の有線ネットワークインタフェース、及び/又は、上述されたものに類似した無線ネットワークインタフェースを含んでよい。いくつかの例において、データ取得システム402は、NiFi受信機など、所与のデータフロー技術に従って構成された要素であってよく、又はそれらの要素を含んでもよい。
データ取得システム402は、1つ又は複数の動作を実行するように構成された、1つ又は複数の処理要素を含んでよい。例示的な動作には、いくつかある動作の中でも特に、圧縮及び/又は解凍、暗号化及び/又は複合、アナログデジタル変換及び/又はデジタルアナログ変換、フィルタリング、並びに増幅が含まれてよい。さらに、データ取得システム402は、データのデータ型及び/又は特性に基づいて、データを解析、分類、整理、及び/又はルーティングするように構成されてよい。いくつかの例において、データ取得システム402は、データサイエンスシステム404の1つ又は複数の特性若しくは動作パラメータに基づいて、データの書式を設定し、データをまとめ、及び/又はデータをルーティングするように構成されてよい。
概して、データ取得システム402により受信されるデータは、様々な形態をとってよい。例えば、データのペイロードには、センサ若しくはアクチュエータの単一の測定値、センサ及び/若しくはアクチュエータの複数の測定値、並びに/又は、1つ若しくは複数の異常状態データが含まれてよい。他の例もあり得る。
さらに、受信されたデータには、送信元識別子及びタイムスタンプ(例えば、情報が取得された日付及び/又は時刻)など、特定の特性が含まれてよい。例えば、固有の識別子(例えば、コンピュータによって生成されたアルファベット、数字、英数字などの識別子)が、各資産、並びにおそらくは各センサ及びアクチュエータに割り当てられてよい。そのような識別子は、データが生じる資産、センサ、又はアクチュエータを識別するように使用可能であってよい。場合によっては、別の特性に、情報が取得された位置(例えば、GPS座標)が含まれてよい。データ特性は、いくつかある例の中でも特に、信号署名又はメタデータの形態で生じてよい。
データサイエンスシステム404は概して、(例えば、データ取得システム402から)データを受信して解析し、そのような解析に基づいて、1つ又は複数の動作を起こさせるように機能することができる。したがって、データサイエンスシステム404は、1つ又は複数のネットワークインタフェース408、処理ユニット410、及びデータストレージ412を含んでよく、それらの全てが、システムバス、ネットワーク、又は他の接続機構によって通信可能に結合されてよい。場合によっては、データサイエンスシステム404は、本明細書において開示される一部の機能の実行を容易にする1つ若しくは複数のアプリケーションプログラムインタフェース(API)を格納、及び/又はそれらのAPIにアクセスするように構成されてよい。
ネットワークインタフェース408は、上述された任意のネットワークインタフェースと同じ又は類似してよい。実際には、ネットワークインタフェース408は、データサイエンスシステム404と、データ取得システム402、データベース406、資産102、出力システム110など、様々な他のエンティティとの間の通信を(例えば、あるレベルのセキュリティで)容易にすることができる。
処理ユニット410は、1つ又は複数のプロセッサを含んでよく、それらのプロセッサは上述されたプロセッサ形態のいずれかをとってよい。同じように、データストレージ412は、1つ若しくは複数の非一時的コンピュータ可読記憶媒体であってよく、又はそれらを含んでもよく、これらの非一時的コンピュータ可読記憶媒体は、上述されたコンピュータ可読記憶媒体のいずれかの形態をとってよい。処理ユニット410は、本明細書において説明される解析システムの動作を実行するために、コンピュータ可読プログラム命令をデータストレージ412に格納し、格納されたそれらの命令にアクセスして実行するように構成されてよい。
概して、処理ユニット410は、データ取得システム402から受信されたデータの解析を実行するように構成されてよい。そのために、処理ユニット410は、データストレージ412に格納された1つ又は複数のセットのプログラム命令の形態をそれぞれがとり得る、1つ又は複数のモジュールを実行するように構成されてよい。それらのモジュールは、それぞれのプログラム命令の実行に基づいて結果を生じさせることを容易にするように構成されてよい。所与のモジュールからの例示的な結果には、いくつかある例の中でも特に、データを別のモジュールに出力すること、所与のモジュール及び/又は別のモジュールのプログラム命令を更新すること、並びに資産及び/又は出力システム110への伝送のために、データをネットワークインタフェース408に出力することが含まれてよい。
データベース406は概して、(例えば、データサイエンスシステム404から)データを受信して格納するように機能することができる。したがって、各データベース406は、上記に提供された例のいずれかなど、1つ又は複数の非一時的コンピュータ可読記憶媒体を含んでよい。実際には、データベース406は、データストレージ412から分かれても、データストレージ412と統合されてもよい。
データベース406は、多数の種類のデータを格納するように構成されてよく、そのようなデータの一部が以下に論じられる。実際には、データベース406に格納されるデータの一部は、データが生成された、又はデータベースに追加された、日付及び時刻を示すタイムスタンプを含んでよい。さらに、データは、データベース406に複数の方式で格納されてよい。例えば、データは、いくつかある例の中でも特に、時系列で、表形式で、及び/又は、データソースの種類(例えば、資産、資産の種類、センサ、センサの種類、アクチュエータ、又はアクチュエータの種類に基づいて)若しくは異常状態インジケータに基づいて整理されて、格納されてよい。
IV.例示的な動作
次に、図1に図示される例示的なネットワーク構成100の動作が、ここで以下にさらに詳細に論じられることになる。これらの動作の一部を説明することに役立てるために、実行され得る動作の組み合わせを説明するフローチャートが参照されてよい。場合によっては、各ブロックは、ある処理における特定の論理機能又は論理ステップを実装するように、プロセッサによって実行可能な命令を含む、プログラムコードのモジュール又は部分を表してよい。プログラムコードは、非一時的コンピュータ可読媒体など、任意の種類のコンピュータ可読媒体に格納されてよい。他の場合において、各ブロックが、ある処理における特定の論理機能又は論理ステップを実行するように配線された回路を表してよい。さらに、フローチャートに示されるブロックは、特定の実施形態に基づいて、異なる順序に再構成されてよく、より少ないブロックに組み合わされてよく、追加のブロックに分離されてよく、及び/又は除去されてよい。
以下の説明は、資産102などの単一のデータソースが、後で1つ又は複数の機能を実行する解析システム108にデータを提供する例を参照し得る。これは、単に明確さと説明を目的として行われ、限定しようとするつもりはないことを理解されたい。実際には、解析システム108は概して、複数のソースから、おそらく同時にデータを受信し、そのような一括受信されたデータに基づいて動作を実行する。
A.動作データの収集
上述されたように、代表的な資産102は、様々な形態をとってよく、複数の動作を実行するように構成されてよい。非限定的な例において、資産102は、米国中に貨物を運ぶように動作可能な機関車の形態をとってよい。輸送中に、資産102のセンサ及び/又はアクチュエータは、資産102の1つ又は複数の動作状態を反映するデータを取得することができる。センサ及び/又はアクチュエータは、資産102の処理ユニットにデータを伝送することができる。
処理ユニットは、センサ及び/又はアクチュエータからデータを受信するように構成されてよい。実際には、処理ユニットは、複数のセンサからセンサデータを、及び/又は複数のアクチュエータからアクチュエータデータを、同時に又は連続的に受信してよい。上述されたように、処理ユニットは、このデータを受信している間、障害コードなど、任意の異常状態インジケータをトリガするトリガ基準を、データが満たすかどうか判定するように構成されてもよい。処理ユニットが、1つ又は複数の異常状態インジケータがトリガされると判定するイベントにおいて、処理ユニットは、ユーザインタフェースを介してトリガインジケータのインジケーションを出力するなど、1つ又は複数のローカル動作を実行するように構成されてよい。
次に資産102は、資産102のネットワークインタフェース及び通信ネットワーク106を介して、動作データを解析システム108へ伝送してよい。動作にあたっては、資産102は、動作データを解析システム108へ継続的に、周期的に、及び/又はトリガイベント(例えば、異常状態)に応答して、伝送してよい。具体的には、資産102は、特定の頻度(例えば、毎日、1時間ごと、15分ごと、1分に1回、1秒に1回など)に基づいて周期的に動作データを伝送してよく、又は、資産102は、継続的なリアルタイムフィードの動作データを伝送するように構成されてよい。追加的に又は代替的に、資産102は、センサ測定値及び/又はアクチュエータ測定値が、任意の異常状態インジケータのトリガ基準を満たした場合など、一定のトリガに基づいて動作データを伝送するように構成されてよい。資産102は、他の方式でも動作データを伝送することができる。
実際には、資産102の動作データは、センサデータ、アクチュエータデータ、及び/又は異常状態データを含んでよい。実装態様によっては、資産102は、単一のデータストリームで動作データを提供するように構成されてよいが、他の実装態様において、資産102は、複数の別個のデータストリームで動作データを提供するように構成されてよい。例えば、資産102は、センサデータ及び/又はアクチュエータデータの第1のデータストリームと、異常状態データの第2のデータストリームとを解析システム108に提供してよい。他の可能性も存在する。
センサデータ及びアクチュエータデータは、様々な形態をとってよい。例えば、場合によっては、センサデータ(又はアクチュエータデータ)は、資産102の複数のセンサ(又は複数のアクチュエータ)のそれぞれによって取得された測定値を含んでよい。またある時には、センサデータ(又はアクチュエータデータ)は、資産102の複数のセンサ(又は複数のアクチュエータ)のサブセットによって取得された測定値を含んでよい。
具体的には、センサデータ及び/又はアクチュエータデータは、トリガされた所与の異常状態インジケータと関連付けられたセンサ及び/又はアクチュエータによって取得された、測定値を含んでよい。例えば、トリガされた障害コードが図3の障害コード1である場合には、センサデータが、センサA及びCによって取得された未処理の測定値を含んでよい。追加的に又は代替的に、データは、トリガされた障害コードと直接に関連付けられていない1つ又は複数のセンサ若しくはアクチュエータによって取得された測定値を含んでよい。最後の例を続けると、データは、アクチュエータB及び/又は他のセンサ若しくはアクチュエータによって取得された測定値を追加的に含んでよい。いくつかの例において、資産102は、解析システム108により提供される障害コードルール又は命令に基づいて、特定のセンサデータを動作データに含めることができ、これにより、例えば、アクチュエータBが測定している動作データと、障害コード1が最初にトリガされる原因となった動作データとの間に相関があると判定した可能性がある。他の例もあり得る。
さらにまた、データは、対象とする特定の時間に基づく、対象とする各センサ及び/又はアクチュエータからの、1つ又は複数のセンサ測定値及び/若しくはアクチュエータ測定値を含んでよく、これらの測定値は、複数の要因に基づいて選択されてよい。いくつかの例において、対象とする特定の時間は、サンプリングレートに基づいてよい。他の例において、対象とする特定の時間は、異常状態インジケータがトリガされた時間に基づいてよい。
具体的には、異常状態インジケータがトリガされた時間に基づいて、データは、対象とする各センサ及び/又はアクチュエータ(例えば、トリガされたインジケータと直接的に及び間接的に関連付けられたセンサ及び/又はアクチュエータ)からの、1つ又は複数のそれぞれのセンサ測定値及び/又はアクチュエータ測定値を含んでよい。1つ又は複数の測定値は、特定の数の測定値、又は、トリガされた異常状態インジケータの時間前後の特定の継続時間に基づいてよい。
例えば、トリガされた障害コードが図3の障害コード2である場合、対象とするセンサ及びアクチュエータは、アクチュエータB及びセンサCを含んでよい。1つ又は複数の測定値は、障害コードをトリガする前に(例えば、トリガ測定値の前に)アクチュエータB及びセンサCによって取得された、それぞれの最新の測定値、又は、トリガ測定値の前の測定値、後の測定値、若しくはその前後の測定値からなるそれぞれのセットを含んでよい。例えば、5個の測定値のセットが、いくつかある可能性の中でも特に、トリガ測定値の前若しくは後の5個の測定値(例えば、トリガ測定値を除く)、トリガ測定値の前若しくは後の4個の測定値及びトリガ測定値、又は、トリガ測定値の前の2つの測定値及びトリガ測定値の後の2つの測定値並びにトリガ測定値を含んでよい。
センサデータ及びアクチュエータデータと同様に、異常状態データは、様々な形態をとってよい。概して、異常状態データは、資産102で発生した特定の異常状態を、資産102で発生し得る他の全ての異常状態から一意に識別するように使用可能なインジケータの形態を含んでよく、又はそのような形態をとってよい。異常状態インジケータは、いくつかある例の中でも特に、アルファベット、数字、又は英数字の識別子の形態をとってよい。さらに、異常状態インジケータは、いくつかある例の中でも特に、「エンジン過熱」、「燃料切れ」など、異常状態を説明する単語列の形態をとってよい。
解析システム108、具体的には解析システム108のデータ取得システムは、1つ又は複数の資産及び/又はデータソースから動作データを受信するように構成されてよい。データ取得システムは、受信されたデータに基づく1つ又は複数の動作を実行し、次にそのデータを解析システム108のデータサイエンスシステムへ中継するように構成されてよい。同じように、データサイエンスシステムは、受信されたデータを解析し、そのような解析に基づいて1つ又は複数の動作を実行してよい。
B.予測モデル及びワークフローの定義
1つの例として、解析システム108は、受信された1つ若しくは複数の資産の動作データ、及び/又は1つ若しくは複数の資産に関連する受信された外部データに基づいて、予測モデル及び対応するワークフローを定義するように構成されてよい。解析システム108は、様々な他のデータに基づいてモデル・ワークフロー対も定義してよい。
概して、モデル・ワークフロー対は、特定の動作状態を資産に監視させ、監視された動作状態によって示唆される特定のイベントの発生防止を容易にするのに役立つ特定の動作を資産に実行させる、プログラム命令のセットを含んでよい。具体的には、予測モデルは1つ又は複数のアルゴリズムを含んでよく、予測モデルの入力は、資産の1つ又は複数のセンサ及び/又はアクチュエータからのセンサデータ及び/又はアクチュエータデータであり、予測モデルの出力は、今後の一定期間内に特定のイベントが資産で発生し得る確率を決定するのに利用される。同じように、ワークフローは、1つ又は複数のトリガ(例えば、モデルの出力値)、及びそれらのトリガに基づいて資産が実行する対応する動作を含んでよい。
上記に示唆されるように、解析システム108は、一括予測モデル及び/若しくはワークフロー、並びに/又は個別予測モデル及び/若しくはワークフローを定義するように構成されてよい。「一括」モデル/ワークフローとは、資産のグループに汎用的であり、モデル/ワークフローがデプロイされる資産の特定の特性を考慮することなく定義された、モデル/ワークフローを意味し得る。一方、「個別」モデル/ワークフローとは、単一の資産、又は資産群からの資産のサブグループに合わせて特に用意され、モデル/ワークフローがデプロイされる単一の資産又は資産のサブグループの特定の特性に基づいて定義された、モデル/ワークフローを意味し得る。これらの異なる種類のモデル/ワークフロー、及びそれらを定義する解析システム108により実行される動作が、以下にさらに詳細に論じられる。
1.一括モデル及びワークフロー
例示的な実装態様において、解析システム108は、複数の資産の一括データに基づいて、一括モデル・ワークフロー対を定義するように構成されてよい。一括モデル・ワークフロー対の定義は、様々な方式で実行されてよい。
図5は、モデル・ワークフロー対の定義に用いられ得る、定義段階の1つの可能な例を図示するフローチャート500である。例示の目的で、例示的な定義段階は、解析システム108により実行されるものとして説明されるが、この定義段階は、他のシステムにより実行されてもよい。当業者であれば、フローチャート500は、明確さ及び説明を目的として提供されていること、及び動作の多数の他の組み合わせが、モデル・ワークフロー対を定義するのに利用され得ることを理解するであろう。
図5に示されるように、ブロック502で、解析システム108は、所与の予測モデルの基礎を形成するデータ(例えば、対象とするデータ)のセットを定義することから始めてよい。対象とするデータは、資産102及び104、並びにデータソース112など、複数のソースから引き出されてよく、その後、解析システム108のデータベースに格納されてよい。
対象とするデータは、資産のグループからの資産の特定のセット、又は資産のグループからの資産の全て(例えば、対象とする資産)の過去のデータを含んでよい。さらに、対象とするデータは、対象とする資産のそれぞれのセンサ及び/若しくはアクチュエータの特定のセットによる測定値、又は、対象とする資産のそれぞれのセンサ及び/若しくはアクチュエータの全てによる測定値を含んでよい。さらにまた、対象とするデータは、2週間相当の過去のデータなど、過去の特定の期間のデータを含んでよい。
対象とするデータは、所与の予測モデルに依存し得る様々な種類のデータを含んでよい。一部の事例において、対象とするデータは、資産の動作状態を示す動作データを少なくとも含んでよく、この動作データは「動作データの収集」の項目で上述されている。さらに、対象とするデータは、資産が通常動作する環境を示す環境データ、及び/又は、資産が特定のタスクを実行する計画日時を示すスケジュールデータを含んでよい。他の種類のデータも、対象とするデータに含まれてよい。
実際には、対象とするデータは、複数の方式で定義されてよい。1つの例において、対象とするデータはユーザによって定義されてよい。具体的には、ユーザが、対象とする特定のデータの選択を示すユーザ入力を受信する出力システム110を動作させてよく、出力システム110は、そのような選択を示すデータを解析システム108に提供してよい。受信されたデータに基づいて、解析システム108は次に、対象とするデータを定義してよい。
別の例において、対象とするデータは、機械によって定義されてよい。具体的には、解析システム108は、最も正確な予測モデルを生成する、対象とするデータを決定するために、シミュレーションなどの様々な動作を実行してよい。他の例もあり得る。
図5に戻ると、ブロック504で、解析システム108は、対象とするデータに基づいて、資産の動作に関連した一括予測モデルを定義するように構成されてよい。概して、一括予測モデルは、資産の動作状態と、資産で発生するイベントの可能性との間の関係を定義することができる。具体的には、一括予測モデルは、資産のセンサからのセンサデータ、及び/又は資産のアクチュエータからのアクチュエータデータを入力として受信し、今後の一定時間内にイベントが資産で発生する確率を出力することができる。
予測モデルが予測するイベントは、特定の実装態様に応じて様々であってよい。例えば、イベントは故障などであってよく、予測モデルは、故障が今後の一定期間内に起こるかどうか予測する故障モデルであってよい(故障モデルは、「健全性スコアモデル及びワークフロー」の項目で以下に詳細に論じられる)。別の例において、イベントは、資産のタスク完了などであってよく、予測モデルは、資産が時間通りにタスクを完了する可能性を予測してよい。他の例において、イベントは、流体又は要素の交換などであってよく、予測モデルは、特定の資産の流体又は要素が交換を必要とする前の時間を予測してよい。さらに他の例において、イベントは、資産の生産性の変化などであってよく、予測モデルは、今後の一定期間の間の資産の生産性を予測してよい。1つの他の例において、イベントは、期待される資産挙動と異なる資産挙動などを示し得る「重要インジケータ」イベントの発生であってよく、予測モデルは、1つ又は複数の重要インジケータイベントが今後発生する可能性を予測してよい。予測モデルの他の例もあり得る。
いずれにしても、解析システム108は、一括予測モデルを様々な方式で定義することができる。概して、この動作は、いくつかあるモデル化技法の中でも特に、ランダムフォレスト技法、ロジスティック回帰技法、又は他の回帰技法など、0から1までの確率を返すモデルを生成する1つ又は複数のモデル化技法の利用を伴ってよい。特定の例示的な実装態様において、解析システム108は、図7を参照する以下の説明に従って、一括予測モデルを定義することができる。解析システム108は、他の方式でも一括モデルを定義してよい。
ブロック506で、解析システム108は、ブロック504の定義されたモデルに対応する一括ワークフローを定義するように構成されてよい。概して、ワークフローは、予測モデルの特定の出力に基づいて実行される行為の形態をとってよい。例示的な実装態様において、ワークフローは、定義された予測モデルの出力に基づいて資産が実行する1つ又は複数の動作を含んでよい。ワークフローの一部になり得る動作の例には、いくつかある例示的なワークフロー動作の中でも特に、資産が、特定のデータ収集方式に従ってデータを取得すること、特定のデータ伝送方式に従ってデータを解析システム108へ伝送すること、ローカル診断ツールを実行すること、及び/又は資産の動作状態を修正することが含まれる。
特定のデータ収集方式は、資産がデータをどのように取得するかを示してよい。具体的には、データ収集方式は、資産の複数のセンサ及びアクチュエータのセンサ及び/又はアクチュエータのサブセットなど、資産がデータを取得する特定のセンサ及び/又はアクチュエータ(例えば、対象とするセンサ/アクチュエータ)を示してよい。さらに、データ収集方式は、対象とするセンサ/アクチュエータから資産が取得するデータの量、及び/又は、そのようなデータを資産が取得するサンプリング頻度を示してよい。データ収集方式は、様々な他の属性も含んでよい。特定の例示的な実装態様において、特定のデータ収集方式が、資産健全性の予測モデルに対応してよく、資産健全性の低下に基づいて、(例えば、特定のセンサから)より多くのデータ及び/又は特定のデータを取得するように調整されてよい。又は、特定のデータ収集方式は、重要インジケータ予測モデルに対応してよく、サブシステムの故障が発生し得ることを信号で伝えることができる重要インジケータイベントの発生の可能性が増加したことに基づいて、資産のセンサ及び/又はアクチュエータによって取得されたデータを修正するように調整されてよい。
特定のデータ伝送方式は、資産がデータを解析システム108へどのように伝送するかを示してよい。具体的には、データ伝送方式は、特定のセンサ若しくはアクチュエータからのデータ、資産が伝送する必要がある複数のデータサンプル、伝送頻度、及び/又は、資産がそのデータ伝送に含める必要があるデータの優先方式など、資産が伝送する必要があるデータの種類を示してよい(並びに、そのデータの書式及び/又は構造も示してよい)。場合によっては、特定のデータ収集方式はデータ伝送方式を含んでよく、又は、データ収集方式がデータ伝送方式と組み合わされてよい。いくつかの例示的な実装態様において、特定のデータ伝送方式は、資産健全性の予測モデルに対応してよく、閾値を超える資産健全性に基づいて、より低い頻度でデータを伝送するように調整されてよい。他の例もあり得る。
上記に示唆されたように、ローカル診断ツールは、資産にローカルに格納される手順のセットなどであってよい。ローカル診断ツールは概して、資産の障害又は故障の原因診断を容易にすることができる。場合によっては、ローカル診断ツールは、実行された場合、資産のサブシステム又はその一部に検査入力を送って検査結果を取得してよく、これにより、障害又は故障の原因診断を容易にすることができる。これらのローカル診断ツールは通常、資産では休止状態にあり、資産が特定の診断命令を受信しない限り、実行されることはない。他のローカル診断ツールもあり得る。1つの例示的な実装態様において、特定のローカル診断ツールは、資産のサブシステムの健全性に関する予測モデルに対応してよく、サブシステムの健全性が閾値にあるか、又は閾値を下回ることに基づいて実行されてよい。
最後に、ワークフローは、資産の動作状態の修正を伴ってよい。例えば、資産の1つ又は複数のアクチュエータは、資産の動作状態の修正を容易にするように制御されてよい。いくつかある例の中でも特に、速度、温度、圧力、流体レベル、電流の流れ、電力分配など、様々な動作状態が修正されてよい。特定の例示的な実装態様において、動作状態修正のワークフローは、資産がタスクを時間通りに完了するかどうか予測するための予測モデルに対応してよく、予測された完了確率が閾値にあるか、又は閾値を下回ることに基づいて、資産にその移動速度を増加させてよい。
いずれにしても、一括ワークフローは、様々な方式で定義されてよい。1つの例において、一括ワークフローはユーザによって定義されてよい。具体的には、ユーザが、特定のワークフロー動作の選択を示すユーザ入力を受信する演算処理装置を動作させてよく、演算処理装置は、そのような選択を示すデータを解析システム108に提供してよい。このデータに基づいて、解析システム108は次に、一括ワークフローを定義してよい。
別の例において、一括ワークフローは、機械によって定義されてよい。具体的には、解析システム108は、シミュレーションなどの様々な動作を実行して、予測モデルにより出力された確率の原因の決定、及び/又は、モデルにより予測されたイベントの発生防止を容易にし得るワークフローを決定してよい。一括ワークフローの定義に関する他の例もあり得る。
予測モデルに対応するワークフローを定義するにあたり、解析システム108は、ワークフローのトリガを定義してよい。例示的な実装態様において、ワークフローのトリガは、予測モデルにより出力された確率の値、又は予測モデルにより出力された値の範囲であってよい。場合によっては、ワークフローは複数のトリガを有してよく、それらのトリガのそれぞれは、1つ又は複数の異なる動作を発生させてよい。
例示するために、図6Aは、一括モデル・ワークフロー対600の概念図を示す。示されるように、一括モデル・ワークフロー対の例示600には、モデル入力602の列と、モデル計算604の列と、モデル出力範囲606の列と、対応するワークフロー動作608の列とが含まれる。この例において、予測モデルは、センサAからのデータとして単一の入力を有し、計算I及び計算IIとして2つの計算を有する。この予測モデルの出力は、実行されるワークフロー動作に影響を与える。出力された確率が80%より低い又は80%と等しい場合には、ワークフロー動作1が実行される。そうでない場合には、ワークフロー動作2が実行される。他の例示的なモデル・ワークフロー対があり得、本明細書において企図されている。
2.個別モデル及びワークフロー
別の態様において、解析システム108は、資産の個別予測モデル及び/又はワークフローを定義するように構成されてよく、これは、一括モデル・ワークフロー対をベースラインとして利用することを伴ってよい。個別化は、資産の特定の特性に基づいてよい。このようにして、解析システム108は、一括モデル・ワークフロー対と比較して、より正確且つロバストなモデル・ワークフロー対を所与の資産に提供することができる。
具体的には、図5に戻り、ブロック508で、解析システム108は、資産102などの所与の資産用にブロック504で定義された一括モデルを、個別化するかどうか判定するように構成されてよい。解析システム108は、この判定を複数の方式で実行してよい。
場合によっては、解析システム108は、個別予測モデルをデフォルトで定義するように構成されてよい。他の場合において、解析システム108は、資産102の特定の特性に基づいて、個別予測モデルを定義するかどうか判定するように構成されてよい。例えば、場合によっては、特定の種類若しくはクラスの資産、特定の環境で動作する資産、又は特定の健全性スコアを有する資産だけが、個別予測モデルを受信してよい。さらに他の場合において、ユーザが、個別モデルを資産102用に定義するかどうか定義してよい。他の例もあり得る。
いずれにしても、解析システム108が、個別予測モデルを資産102用に定義すると判定した場合、解析システム108は、ブロック510でそのように定義してよい。そうでない場合、解析システム108は、ブロック512へ進んでよい。
ブロック510で、解析システム108は、個別予測モデルを複数の方式で定義するように構成されてよい。例示的な実装態様において、解析システム108は、資産102の1つ又は複数の特性に少なくとも部分的に基づいて、個別予測モデルを定義してよい。
資産102の個別予測モデルを定義する前に、解析システム108は、個別モデルの基礎を形成する、1つ又は複数の対象とする資産特性を決定した可能性がある。実際には、異なる予測モデルが、対象とする異なった対応する特性を有してよい。
概して、対象とする特性は、一括モデル・ワークフロー対に関連した特性であってよい。例えば、対象とする特性は、一括モデル・ワークフロー対の精度に影響を与えると解析システム108が判定した特性であってよい。そのような特性の例には、いくつかある特性の中でも特に、資産年数、資産使用量、資産の処理能力、資産負荷、資産健全性(以下で論じられる資産の健全性指標によって、おそらく示される)、資産クラス(例えば、ブランド及び/又は型式)、並びに、資産が動作する環境が含まれてよい。
解析システム108は、対象とする特性を複数の方式で決定した可能性がある。1つの例において、解析システム108は、対象とする特性の識別を容易にする1つ又は複数のモデル化シミュレーションを実行することで、そのように決定した可能性がある。別の例において、対象とする特性は、事前に定義されて、解析システム108のデータストレージに格納された可能性がある。さらに別の例において、対象とする特性は、ユーザによって定義されて、出力システム110を介して解析システム108に提供された可能性がある。他の例もあり得る。
いずれにしても、対象とする特性を決定した後に、解析システム108は、決定された対象とする特性に対応する、資産102の特性を決定してよい。すなわち、解析システム108は、対象とする特性に対応する、資産102の特性の種類、値、それらの有無などを決定してよい。解析システム108は、この動作を複数の方式で実行してよい。
例えば、解析システム108は、資産102及び/又はデータソース112から生じるデータに基づいて、この動作を実行するように構成されてよい。具体的には、解析システム108は、資産102の動作データ及び/又はデータソース112からの外部データを利用して、資産102の1つ又は複数の特性を決定してよい。他の例もあり得る。
資産102の決定された1つ又は複数の特性に基づいて、解析システム108は、一括モデルを修正することで個別予測モデルを定義してよい。一括モデルは、複数の方式で修正されてよい。例えば、一括モデルは、いくつかある例の中でも特に、1つ若しくは複数のモデル入力を変更する(例えば、追加する、除去する、並べ替えるなど)ことで、資産動作限界に対応する1つ又は複数のセンサ及び/若しくはアクチュエータの測定範囲を変更する(例えば、「重要インジケータ」イベントに対応する動作限界を変更する)ことで、1つ若しくは複数のモデル計算を変更することで、計算の変数若しくは出力を重み付けする(又はその重みを変更する)ことで、一括モデルを定義するのに利用されたものとは異なるモデル化技法を利用することで、及び/又は、一括モデルを定義するのに利用されたものとは異なる応答変数を利用することで、修正されてよい。
例示するために、図6Bは、個別モデル・ワークフロー対610の概念図を示す。具体的には、個別モデル・ワークフロー対の例示610は、図6Aの一括モデル・ワークフロー対の修正バージョンである。示されるように、個別モデル・ワークフロー対の例示610は、モデル入力612及びモデル計算614の修正列を含み、図6Aのモデル出力範囲606及びワークフロー動作608の初期列を含む。この例において、個別モデルは、センサA及びアクチュエータBからのデータとして2つの入力を有し、計算II及び計算IIIとして2つの計算を有する。出力範囲及び対応するワークフロー動作は、図6Aのものと同じである。解析システム108はこのようにして、いくつかある理由の中でも特に、例えば、資産102が比較的古く、健全性が比較的劣っているという判定に基づいて、個別モデルを定義した可能性がある。
実際には、一括モデルを個別化することは、所与の資産の1つ又は複数の特性に依存し得る。具体的には、特定の特性が、一括モデルの修正に他の特性とは異なる影響を与え得る。さらに、ある特性の種類、値、存在なども、修正に影響を与え得る。例えば、資産年数が、一括モデルの第1の部分に影響を与えることがあり、資産クラスが、一括モデルの第2の異なる部分に影響を与えることがある。そして、年数について、第1の範囲内の資産年数が、一括モデルの第1の部分に第1の方式で影響を与えることがあり、年数について、第1の範囲と異なる第2の範囲内の資産年数が、一括モデルの第1の部分に、第2の異なる方式で影響を与えることがある。他の例もあり得る。
実装態様によっては、一括モデルを個別化することは、資産特性に加えて、又は資産特性の代わりに、複数の検討事項に依存し得る。例えば、資産が(例えば、整備士などによって定義されるような)比較的良好な動作状態にあることが分かっている場合、一括モデルは、資産のセンサ及び/又はアクチュエータの数値に基づいて個別化されてよい。より具体的には、重要インジケータ予測モデルの一例において、解析システム108は、資産が良好な動作状態にあるというインジケーションを、資産からの動作データとともに(例えば、整備士が操作する演算処理装置から)受信するように構成されてよい。この動作データに少なくとも基づいて、解析システム108は次に、「重要インジケータ」イベントに対応するそれぞれの動作限界を修正することで、資産の重要インジケータ予測モデルを個別化してよい。他の例もあり得る。
図5に戻り、ブロック512で、解析システム108は、資産102のワークフローを個別化するかどうか判定するように構成されてもよい。解析システム108は、この判定を複数の方式で実行してよい。実装態様によっては、解析システム108は、ブロック508に従って、この動作を実行してよい。他の実装態様において、解析システム108は、個別予測モデルに基づいて、個別ワークフローを定義するかどうか判定してよい。さらに別の実装態様において、解析システム108は、個別予測モデルが定義された場合、個別ワークフローを定義すると判定してよい。他の例もあり得る。
いずれにしても、解析システム108が、資産102の個別ワークフローを定義すると判定した場合、解析システム108は、ブロック514でそのように定義してよい。そうでない場合、解析システム108は定義段階を終了してよい。
ブロック514で、解析システム108は、個別ワークフローを複数の方式で定義するように構成されてよい。例示的な実装態様において、解析システム108は、資産102の1つ又は複数の特性に少なくとも部分的に基づいて、個別ワークフローを定義してよい。
資産102の個別ワークフローを定義する前に、個別予測モデルの定義と同様に、解析システム108は、個別ワークフローの基礎を形成する、1つ又は複数の対象とする資産特性を決定した可能性があり、これらの資産特性は、ブロック510の説明に従って決定された可能性がある。概して、これらの対象とする特性は、一括ワークフローの効果に影響を与える特性であってよい。そのような特性は、上述された例示的な特性のいずれかを含んでよい。他の特性もあり得る。
ここでもブロック510と同様に、解析システム108は、個別ワークフローの決定された対象とする特性に対応する、資産102の特性を決定してよい。例示的な実装態様において、解析システム108は、ブロック510を参照して論じられた特性決定に類似した方式で、資産102の特性を決定してよく、実際に、その決定の一部又は全てを利用してよい。
いずれにしても、資産102の決定された1つ又は複数の特性に基づいて、解析システム108は、一括ワークフローを修正することによって、資産102のワークフローを個別化してよい。一括ワークフローは、複数の方式で修正されてよい。例えば、一括ワークフローは、いくつかある例の中でも特に、1つ若しくは複数のワークフロー動作を変更する(例えば、追加する、除去する、並べ替える、交換するなど)ことで(例えば、第1のデータ収集方式から第2の方式に変更するか、又は特定のデータ収集方式から特定のローカル診断ツールに変更することで)、及び/又は、特定のワークフロー動作をトリガする、対応するモデルの出力値若しくは値の範囲を変更する(例えば、増やす、減らす、そこに追加する、そこから除去するなど)ことで、修正されてよい。実際には、一括ワークフローの修正は、一括モデルの修正と類似した方式で、資産102の1つ又は複数の特性に依存し得る。
例示するために、図6Cは、個別モデル・ワークフロー対620の概念図を示す。具体的には、個別モデル・ワークフロー対の例示620は、図6Aの一括モデル・ワークフロー対の修正バージョンである。示されるように、個別モデル・ワークフロー対の例示620は、図6Aのモデル入力602、モデル計算604、及びモデル出力範囲606の初期列を含むが、ワークフロー動作628の修正列を含む。この例において、個別モデル・ワークフロー対は、一括モデルの出力が80%より高い場合に、ワークフロー動作3が動作1の代わりにトリガされることを除いて、図6Aの一括モデル・ワークフロー対に類似している。解析システム108は、いくつかある理由の中でも特に、例えば、これまでの状況から、資産故障の発生を増加させている環境で資産102が動作するという決定に基づいて、この個々のワークフローを定義した可能性がある。
個別ワークフローを定義した後に、解析システム108は定義段階を終了してよい。その時点で、解析システム108は、資産102の個別モデル・ワークフロー対を有することができる。
いくつかの例示的な実装態様において、解析システム108は、一括予測モデル及び/又は対応するワークフローを最初に定義することなく、所与の資産の個別予測モデル及び/又は対応するワークフローを定義するように構成されてよい。他の例もあり得る。
上述された解析システム108が予測モデル及び/又はワークフローを個別化するが、他の装置及び/又はシステムが個別化を実行してよい。例えば、資産102のローカル解析装置が、予測モデル及び/若しくはワークフローを個別化してよく、又は、そのような動作を実行するために、解析システム108とともに働いてよい。そのような動作を実行するローカル解析装置が、以下にさらに詳細に論じられる。
3.健全性スコアモデル及びワークフロー
特定の実装態様において、上述されたように、解析システム108は、資産の健全性と関連付けられた予測モデル及び対応するワークフローを定義するように構成されてよい。例示的な実装態様において、資産の健全性を監視するための1つ又は複数の予測モデルが、資産の健全性指標(例えば「健全性スコア」)を出力するのに利用されてよく、この健全性指標は、今後の所与の期間(例えば、次の2週間)内に所与の資産で故障が発生するかどうかを示す単一の一括指標である。具体的には、健全性指標は、故障のグループからの故障が今後の所与の期間内に資産で発生しない可能性を示してよく、又は、健全性指標は、故障のグループからの少なくとも1つの故障が今後の所与の期間内に資産で発生する可能性を示してよい。
実際には、健全性指標及び対応するワークフローを出力するのに利用される予測モデルは、上記説明に従って、一括モデル若しくは個別モデル及び/又はワークフローとして定義されてよい。
さらに、健全性指標の所望の粒度に応じて、解析システム108は、異なるレベルの健全性指標を出力する異なる予測モデルを定義し、且つ異なる対応するワークフローを定義するように構成されてよい。例えば、解析システム108は、資産の全体的な健全性指標(すなわち、資産レベルの健全性指標)を出力する予測モデルを定義してよい。別の例として、解析システム108は、資産の1つ又は複数のサブシステムのそれぞれの健全性指標(すなわち、サブシステムレベルの健全性指標)を出力するそれぞれの予測モデルを定義してよい。場合によっては、サブシステムレベルの各予測モデルの出力は、資産レベルの健全性指標を生成するために、組み合わされてよい。他の例もあり得る。
概して、健全性指標を出力する予測モデルを定義することは、様々な方式で実行されてよい。図7は、健全性指標を出力するモデルを定義するのに用いられ得る、モデル化段階の1つの可能な例を図示するフローチャート700である。例示の目的で、例示的なモデル化段階は、解析システム108により実行されるものとして説明されるが、このモデル化段階は他のシステムにより実行されてもよい。当業者であれば、フローチャート700は、明確さ及び説明を目的として提供されていること、及び動作の多数の他の組み合わせが、健全性指標を決定するのに利用され得ることを理解するであろう。
図7に示されるように、ブロック702で、解析システム108は、健全性指標の基礎を形成する1つ又は複数の故障のセット(すなわち、対象とする故障)を定義することから始めてよい。実際には、1つ又は複数の故障は、それらが発生した場合、資産(又はそのサブシステム)を動作不能にし得る類の故障であってよい。定義された故障のセットに基づいて、解析システム108は、今後の所与の期間(例えば、次の2週間)内に発生する故障のいずれかの可能性を予測するためのモデルを定義するための、措置を講じてよい。
具体的には、ブロック704で、解析システム108は、過去に発生した所与の故障を故障のセットから識別するために、1つ又は複数の資産のグループに関する過去の動作データを解析してよい。ブロック706で、解析システム108は、所与の故障について、識別された過去の発生のそれぞれと関連付けられた、動作データのそれぞれのセット(例えば、所与の故障が発生する前の所与の期間の、センサデータ及び/又はアクチュエータデータ)を識別してよい。ブロック708で、解析システム108は、所与の故障の過去の発生と関連付けられた、識別された動作データのセットを解析して、(1)所与のセットの動作指標の値と、(2)今後の所与の期間(例えば、次の2週間)内に所与の故障が発生する可能性との関係(例えば、故障モデル)を定義してよい。最後に、ブロック710で、定義されたセットにおいて故障ごとに定義された関係(例えば、個々の故障モデル)は、故障発生の全体的な可能性を予測するためのモデルに組み合わされてよい。
解析システム108は、1つ又は複数の資産のグループの更新された動作データを引き続き受信するので、解析システム108も、更新された動作データに対して段階704〜710を繰り返すことで、1つ又は複数の故障の定義されたセットの予測モデルを引き続き補正してよい。
図7に示される例示的なモデル化段階の機能が、ここでさらに詳細に説明されることになる。上述されたように、ブロック702で始まるとき、解析システム108は、健全性指標の基礎を形成する1つ又は複数の故障のセットを定義することから始めてよい。解析システム108は、様々な方式でこの機能を実行してよい。
1つの例において、1つ又は複数の故障のセットは、1つ又は複数のユーザ入力に基づいてよい。具体的には、解析システム108は、出力システム110など、ユーザが操作する演算処理システムから、ユーザが1つ又は複数の故障を選択したことを示す入力データを受信してよい。したがって、1つ又は複数の故障のセットは、ユーザによって定義されてよい。
他の例において、1つ又は複数の故障のセットは、解析システム108により行われた(例えば、機械によって定義された)決定に基づいてよい。具体的には、解析システム108は、複数の方式で発生し得る1つ又は複数の故障のセットを定義するように構成されてよい。
例えば、解析システム108は、資産102の1つ又は複数の特性に基づいて、故障のセットを定義するように構成されてよい。すなわち、特定の故障が、資産の種類、クラスなど、資産の特定の特性に対応してよい。例えば、資産の各種類及び/又はクラスには、対象とするそれぞれの故障があってよい。
別の事例において、解析システム108は、解析システム108のデータベースに格納された過去のデータ、及び/又はデータソース112により提供される外部データに基づいて、故障のセットを定義するように構成されてよい。
例えば、解析システム108は、そのようなデータを利用して、いくつかある例の中でも特に、どの故障が最長の修理時間をもたらすか、及び/又は、これまでの状況から、どの故障の後にさらに故障が続くか判定してよい。
さらに他の例において、1つ又は複数の故障のセットは、ユーザ入力と、解析システム108により行われた決定との組み合わせに基づいて、定義されてよい。他の例もあり得る。
ブロック704で、故障のセットからの故障のそれぞれに対して、解析システム108は、1つ又は複数の資産のグループに関する過去の動作データ(例えば、異常挙動データ)を解析して、過去に発生した所与の故障を識別してよい。1つ又は複数の資産のグループは、資産102などの単一の資産、又は、資産102及び104を含む資産群など、同じ種類若しくは類似した種類の複数の資産を含んでよい。解析システム108は、いくつかある例の中でも特に、一定時間相当のデータ(例えば、1か月相当)など、特定量の過去の動作データ、又は一定数のデータ点(例えば、最新の1000個のデータ点)を解析してよい。
実際には、過去に発生した所与の故障を識別することは、異常状態データなど、所与の故障を示す動作データの種類を識別する解析システム108を伴ってよい。概して、所与の故障は、障害コードなど、1つ又は複数の異常状態インジケータと関連付けられてよい。すなわち、所与の故障が発生した場合、1つ又は複数の異常状態インジケータがトリガされ得る。したがって、異常状態インジケータは、所与の故障の根本的症状を反映し得る。
所与の故障を示す動作データの種類を識別した後に、解析システム108は、過去に発生した所与の故障を複数の方式で識別することができる。例えば、解析システム108は、解析システム108のデータベースに格納された過去の動作データから、所与の故障と関連付けられた異常状態インジケータに対応する異常状態データを捜し出すことができる。捜し出された各異常状態データは、所与の故障の発生を示すことができる。この捜し出された異常状態データに基づいて、解析システム108は、過去に故障が発生した時間を識別することができる。
ブロック706で、解析システム108は、所与の故障について、識別された過去の発生のそれぞれと関連付けられた、動作データのそれぞれのセットを識別してよい。具体的には、解析システム108は、センサデータのセット及び/又はアクチュエータデータのセットを、所与の故障の所与の発生時間前後の特定の期間から識別してよい。例えば、データのセットは、所与の故障の発生の前、後、又はその前後の特定の期間(例えば、2週間)のものであってよい。他の場合において、データのセットは、所与の故障の発生の前、後、又はその前後の一定数のデータ点から識別されてよい。
例示的な実装態様において、動作データのセットは、資産102のセンサ及びアクチュエータの一部又は全てからの、センサデータ及び/又はアクチュエータデータを含んでよい。例えば、動作データのセットは、所与の故障に対応する異常状態インジケータと関連付けられたセンサ及び/又はアクチュエータからのデータを含んでよい。
例示するために、図8は、解析システム108がモデルの定義を容易にするために解析し得る、過去の動作データの概念図を図示する。プロット800は、資産102のセンサ及びアクチュエータの一部(例えば、センサA及びアクチュエータB)又は全てから生じた、過去のデータのセグメントに対応してよい。示されるように、プロット800は、x軸802に時間、y軸804に測定値、並びにセンサAに対応するセンサデータ806及びアクチュエータBに対応するアクチュエータデータ808を含み、これらのデータのそれぞれが、特定の時点Tiにおける測定値を表す様々なデータ点を含む。さらに、プロット800は、過去の時間Tf(例えば、「故障時間」)に発生した故障810の発生に関するインジケーションと、故障の発生前の時間812(ΔT)に関するインジケーションとを含み、これらのインジケーションから、動作データのセットが識別される。したがって、Tf−ΔTが、対象とするデータ点の期間814を定義する。
図7に戻って、解析システム108が、所与の故障の所与の発生(例えば、Tfでの発生)に関する動作データのセットを識別した後に、解析システム108は、動作データのセットを識別する必要がある発生が何か残っているかどうか判定してよい。残っている発生がある場合、ブロック706が、残っている発生ごとに繰り返されることになる。
その後、ブロック708で、解析システム108は、所与の故障の過去の発生と関連付けられた、識別された動作データのセットを解析して、(1)動作指標の所与のセット(例えば、センサ測定値及び/又はアクチュエータ測定値の所与のセット)と、(2)今後の所与の期間(例えば、次の2週間)内に所与の故障が発生する可能性との関係(例えば、故障モデル)を定義してよい。すなわち、所与の故障モデルは、1つ又は複数のセンサ及び/又はアクチュエータからの、センサ測定値及び/又はアクチュエータ測定値を入力として取得し、所与の故障が今後の所与の期間内に発生する確率を出力してよい。
概して、故障モデルは、資産102の動作状態と故障発生の可能性との間の関係を定義することができる。実装態様によっては、資産102のセンサ及び/又はアクチュエータからの未処理のデータ信号に加えて、故障モデルは、センサ信号及び/又はアクチュエータ信号から引き出される、複数の他のデータ入力(特徴としても知られる)を受信することができる。そのような特徴には、故障が発生したときにこれまで測定された値の平均若しくは範囲、故障発生前にこれまで測定された値の変化量(例えば、測定値の変化割合)の平均若しくは範囲、故障と故障との間の継続時間(例えば、第1の故障発生と第2の故障発生との間の時間又はデータ点の数)、並びに/又は、故障の発生前後のセンサ測定値及び/若しくはアクチュエータ測定値の傾向を示す、1つ又は複数の故障パターンが含まれてよい。当業者であれば、これらが、センサ信号及び/又はアクチュエータ信号から引き出され得る、ほんのいくつかの例示的な特徴であること、また多数の他の特徴があり得ることを理解するであろう。
実際には、故障モデルは、複数の方式で定義されてよい。例示的な実装態様において、解析システム108は、0から1までの確率を返す1つ又は複数のモデル化技法を利用することで、故障モデルを定義してよく、これらのモデル化技法は、上述された任意のモデル化技法の形態をとってよい。
特定の例において、故障モデルの定義は、ブロック706で識別された過去の動作データに基づいて、応答変数を生成する解析システム108を伴ってよい。具体的には、解析システム108は、特定の時点で受信された、センサ測定値及び/又はアクチュエータ測定値のセットごとに、関連応答変数を決定してよい。したがって、応答変数は、故障モデルと関連付けられたデータセットの形態をとってよい。
応答変数は、測定値の所与のセットが、ブロック706で決定された期間のいずれかの中にあるかどうかを示すことができる。すなわち、応答変数は、所与のデータのセットが、故障発生に関して、対象とする時間のものであるかどうかを反映することができる。応答変数は、所与の測定値のセットが決定された期間のいずれかの中にある場合、関連応答変数は1の値を割り当てられ、そうでない場合には、関連応答変数は0の値を割り当てられるように、2進の値を持つ応答変数であってよい。
図8に戻ると、応答変数ベクトルYresの概念図がプロット800に示されている。示されるように、期間814内にある測定値のセットと関連付けられた応答変数(例えば、時間Ti+3〜Ti+8のYres)が1の値であり、期間814の外側にある測定値のセットと関連付けられた応答変数(例えば、時間Ti〜Ti+2、及び時間Ti+9〜Ti+10のYres)が0の値である。他の応答変数もあり得る。
応答変数に基づいて故障モデルを定義することに関する特定の例を続けると、解析システム108は、ブロック706で識別された過去の動作データ、及び生成された応答変数で、故障モデルをトレーニングすることができる。このトレーニングプロセスに基づいて、解析システム108は、様々なセンサデータ及び/又はアクチュエータデータを入力として受信し、応答変数を生成するのに用いられた期間と同等の期間内に故障が発生する、0から1までの確率を出力する故障モデルを定義することができる。
場合によっては、ブロック706で識別された過去の動作データ、及び生成された応答変数を用いたトレーニングは、センサ及び/又はアクチュエータごとに、変数重要度の統計データをもたらし得る。所与の変数重要度の統計データは、今後の期間内に所与の故障が発生する確率に対する、センサの相対効果又はアクチュエータの相対効果を示すことができる。
追加的に又は代替的に、解析システム108は、コックス比例ハザード技法など、1つ又は複数の生存時間解析技法に基づいて、故障モデルを定義するように構成されてよい。解析システム108は、いくつかの点で上述されたモデル化技法と類似した方式で、生存時間解析技法を利用してよいが、解析システム108は、最後の故障から期待される次のイベントまでの時間を示す、生存時間応答変数を決定してよい。期待される次のイベントは、センサ測定値及び/若しくはアクチュエータ測定値の受信、又はどちらが最初に発生するにしても故障発生に関する受信であってよい。この応答変数は、測定値が受信される特定の時点のそれぞれと関連付けられた1対の値を含んでよい。この応答変数は次に、今後の所与の期間内に故障が発生する確率を決定するのに利用されてよい。
いくつかの例示的な実装態様において、故障モデルは、いくつかあるデータの中でも特に、気象データ及び「発熱軸箱」データなど、外部データに部分的に基づいて定義されてよい。例えば、そのようなデータに基づいて、故障モデルは、出力される故障確率を増加又は減少させることができる。
実際には、外部データは、資産のセンサ及び/又はアクチュエータが測定値を取得する時間と一致しない時点で観測される場合がある。例えば、「発熱軸箱」データが収集される時間(例えば、機関車が発熱軸箱センサを備えた鉄道線路の区間を通過する時間)は、センサ及び/又はアクチュエータの測定時間と一致しない場合がある。そのような場合には、解析システム108は、センサ測定時間に対応する時間に観測されたであろう外部のデータ観測を決定する1つ又は複数の動作を実行するように構成されてよい。
具体的には、解析システム108は、外部のデータ観測の時間、及び測定の時間を利用して、外部のデータ観測を補間し、測定時間に対応する時間の外部のデータ値を生み出すことができる。外部データの補間で、外部のデータ観測又はそこから引き出される特徴が、入力として故障モデルに含まれることが可能になり得る。実際には、いくつかある例の中でも特に、最近傍補間、線形補間、多項式補間、及びスプライン補間など、様々な技法が、センサデータ及び/又はアクチュエータデータを用いて、外部データを補間するのに用いられてよい。
図7に戻ると、解析システム108が、ブロック702で定義された故障のセットからの所与の故障の故障モデルを決定した後に、解析システム108は、故障モデルを決定する必要がある故障が何か残っているかどうか判定してよい。故障モデルを決定する必要がある故障が残っている場合には、解析システム108は、ブロック704〜708のループを繰り返してよい。実装態様によっては、解析システム108は、ブロック702で定義された全ての故障を包含する単一の故障モデルを決定してよい。他の実装態様において、解析システム108は、資産102のサブシステムごとに故障モデルを決定してよく、その後、各故障モデルは、資産レベルの故障モデルを決定するのに利用されてよい。他の例もあり得る。
最後に、ブロック710で、定義されたセットの故障ごとに定義された関係(例えば、個々の故障モデル)は、今後の所与の期間(例えば、次の2週間)内に故障が発生する全体的な可能性を予測するためのモデル(例えば、健全性指標のモデル)に組み合わされてよい。すなわち、このモデルは、1つ又は複数のセンサ及び/若しくはアクチュエータからのセンサ測定値及び/又はアクチュエータ測定値を入力として受信し、故障のセットの少なくとも1つの故障が、今後の所与の期間内に発生する単一の確率を出力する。
解析システム108は、健全性指標モデルを複数の方式で定義してよく、それらの方式は、健全性指標の所望の粒度に依存してよい。すなわち、複数の故障モデルが存在する事例において、それらの故障モデルの結果は、健全性指標モデルの出力を取得するために、複数の方式で利用されてよい。例えば、解析システム108は、複数の故障モデルから、最大値、中央値、又は平均値を決定して、その決定された値を健全性指標モデルの出力として利用してよい。
他の例において、健全性指標モデルの決定には、重みを、個々の故障モデルにより出力された個々の確率に起因すると考える、解析システム108を伴ってよい。例えば、故障のセットの各故障は、等しく望ましくないものとみなされてよく、したがって、各確率も同様に、健全性指標モデルを決定するにあたって、同じ重み付けをされてよい。他の事例において、いくつかの故障は、他の故障より望ましくないもの(例えば、より破局的である、又はより長い修理時間を必要とする、など)とみなされてよく、したがって、これらの対応する確率は、他の故障より高く重み付けされてよい。
さらに他の例において、健全性指標モデルの決定には、回帰技法など、1つ又は複数のモデル化技法を利用する解析システム108を伴ってよい。一括応答変数は、個々の故障モデルのそれぞれからの応答変数(例えば、図8のYres)の論理的選言(論理和)の形態をとってよい。例えば、ブロック706で決定された任意の期間(例えば、図8の期間814)内に発生する測定値の任意のセットと関連付けられた一括応答変数は、1の値であってよく、それらの期間のいずれかの外側で発生する測定値のセットと関連付けられた一括応答変数は、0の値であってよい。健全性指標モデルを定義する他の方式もあり得る。
実装態様によっては、ブロック710が不要であってよい。例えば、上述されたように、解析システム108は単一の故障モデルを決定してよく、その場合、健全性指標モデルは単一の故障モデルであってよい。
実際には、解析システム108は、個々の故障モデル及び/又は全体的な健全性指標モデルを更新するように構成されてよい。解析システム108は、モデルを毎日、毎週、毎月などに更新してよく、資産102又は他の資産(例えば、資産102と同じ群の他の資産)の過去の動作データの新たな部分に基づいて、更新してよい。他の例もあり得る。
C.モデル及びワークフローのデプロイ
解析システム108がモデル・ワークフロー対を定義した後に、解析システム108は、定義されたモデル・ワークフロー対を1つ又は複数の資産にデプロイしてよい。具体的には、解析システム108は、定義された予測モデル及び/又は対応するワークフローを、資産102など、少なくとも1つの資産へ伝送してよい。解析システム108は、所与のモデル・ワークフロー対に対する任意の修正又は更新など、トリガイベントに基づいて、モデル・ワークフロー対を周期的に伝送してよい。
場合によっては、解析システム108は、個別モデル及び個別ワークフローのうち1つだけを伝送してよい。例えば、解析システム108が個別モデル又はワークフローだけを定義したシナリオにおいて、解析システム108は、個別モデル若しくはワークフローとともに、ワークフロー若しくはモデルの一括バージョンを伝送してよく、又は、解析システム108は、データストレージに格納された一括バージョンを資産102が既に有している場合に、一括バージョンを伝送する必要がなくてよい。要するに、解析システム108は、(1)個別モデル及び/若しくは個別ワークフロー、(2)個別モデル及び一括ワークフロー、(3)一括モデル及び個別ワークフロー、又は(4)一括モデル及び一括ワークフローを伝送してよい。
実際には、解析システム108は、資産ごとにモデル・ワークフロー対を定義するために、図7のブロック702〜710の動作の一部又は全てを複数の資産に実行した可能性がある。例えば、解析システム108は、資産104のモデル・ワークフロー対を追加的に定義した可能性がある。解析システム108は、資産102及び104へ、それぞれのモデル・ワークフロー対を同時に又は連続的に伝送するように構成されてよい。
D.資産によるローカルな実行
資産102などの所与の資産は、モデル・ワークフロー対又はその一部を受信し、受信されたモデル・ワークフロー対に従って動作するように構成されてよい。すなわち、資産102は、モデル・ワークフロー対をデータストレージに格納し、資産102のセンサ及び/又はアクチュエータによって取得されたデータを予測モデルに入力し、場合によっては、予測モデルの出力に基づいて、対応するワークフローを実行してよい。
実際には、資産102の様々な要素が、予測モデル及び/又は対応するワークフローを実行してよい。例えば、上述されたように、各資産は、解析システム108により提供されたモデル・ワークフロー対を格納して実行するように構成されたローカル解析装置を含んでよい。ローカル解析装置が、特定のセンサデータ及び/又はアクチュエータデータを受信した場合、ローカル解析装置は、受信されたデータを予測モデルに入力してよく、モデルの出力に応じて、対応するワークフローの1つ又は複数の動作を実行してよい。
別の例において、ローカル解析装置から分かれた、資産102の中央処理装置が、予測モデル及び/又は対応するワークフローを実行してよい。さらに他の例において、資産102のローカル解析装置及び中央処理装置は、モデル・ワークフロー対を協調的に実行してよい。例えば、ローカル解析装置は予測モデルを実行してよく、中央処理装置はワークフローを実行してよく、又はその逆であってもよい。
例示的な実装態様において、モデル・ワークフロー対がローカルに実行される前に(又はおそらく、モデル・ワークフローが最初にローカルに実行されるときに)、ローカル解析装置は、資産102の予測モデル及び/又は対応するワークフローを個別化してよい。これは、モデル・ワークフロー対が一括モデル・ワークフロー対の形態をとるのか、又は個別モデル・ワークフロー対の形態をとるのかにかかわらず生じてよい。
上記に示唆されるように、解析システム108は、資産のグループ又は特定の資産に関する、一定の予測、想定、及び/又は一般化に基づいて、モデル・ワークフロー対を定義してよい。例えば、モデル・ワークフロー対を定義するにあたって、解析システム108は、いくつかある検討事項の中でも特に、資産の特性及び/又は資産の動作状態に関して、予測、想定、及び/又は一般化してよい。
いずれにしても、予測モデル及び/又は対応するワークフローを個別化するローカル解析装置は、モデル・ワークフロー対が定義されたときに、解析システム108により行われた予測、想定、及び/又は一般化のうち1つ又は複数を承認又は否定するローカル解析装置を伴ってよい。ローカル解析装置はその後、予測、想定、及び/又は一般化に関する自身の評価に従って、予測モデル及び/又はワークフローを修正(又は、既に個別化されたモデル及び/若しくはワークフローの場合にはさらに修正)してよい。このようにして、ローカル解析装置は、より現実的な及び/又はより正確なモデル・ワークフロー対を定義するのに役立つことができ、その結果、より有効な資産監視をもたらすことができる。
実際には、ローカル解析装置は、複数の検討事項に基づいて、予測モデル及び/又はワークフローを個別化してよい。例えば、ローカル解析装置は、資産102の1つ又は複数のセンサ及び/若しくはアクチュエータにより生成された動作データに基づいて、そのように個別化してよい。具体的には、ローカル解析装置は、(1)1つ又は複数のセンサ及び/若しくはアクチュエータの特定のグループによって生成された動作データを取得すことで(例えば、そのようなデータを、資産の中央処理装置を介して間接的に取得する、又はおそらく、いくつかのセンサ及び/若しくはアクチュエータ自身から直接に取得することで)、(2)モデル・ワークフロー対と関連付けられた1つ又は複数の予測、想定、及び/又は一般化を、取得された動作データに基づいて評価することで、並びに(3)その評価が、どの予測、想定、及び/又は一般化も不正確だったことを示す場合、それに応じて、モデル及び/又はワークフローを修正することで、個別化してよい。これら動作は、様々な方式で実行されてよい。
1つの例において、センサ及び/又はアクチュエータの特定のグループによって生成された動作データを(例えば、資産の中央処理装置を介して)取得するローカル解析装置は、モデル・ワークフロー対の一部として、又はモデル・ワークフロー対とともに含まれる命令に基づいてよい。具体的には、それらの命令は、ローカル解析装置が実行するための、モデル・ワークフロー対の定義に関わった一部又は全ての予測、想定、及び/又は一般化を評価する1つ又は複数の検査を、識別してよい。各検査は、ローカル解析装置が動作データを取得する1つ若しくは複数の対象とするセンサ及び/若しくはアクチュエータ、取得する動作データの量、並びに/又は他の検査検討事項を識別してよい。したがって、センサ及び/又はアクチュエータの特定のグループによって生成された動作データを取得するローカル解析装置は、そのような動作データを検査命令などに従って取得するローカル解析装置を伴ってよい。モデル・ワークフロー対を個別化するのに用いる動作データを取得するローカル解析装置に関する、他の例もあり得る。
上述されたように、動作データを取得した後に、ローカル解析装置は、そのデータを利用して、モデル・ワークフロー対の定義に関わった一部又は全ての予測、想定、及び/又は一般化を評価してよい。この動作は、様々な方式で実行されてよい。1つの例において、ローカル解析装置は、取得された動作データを1つ又は複数の閾値(例えば、閾値及び/又は、値の閾範囲)と比較してよい。概して、所与の閾値又は範囲は、モデル・ワークフロー対を定義するのに用いられた1つ又は複数の予測、想定、及び/若しくは一般化に対応してよい。具体的には、検査命令で識別された、それぞれのセンサ若しくはアクチュエータ(又は、センサ及び/若しくはアクチュエータの組み合わせ)は、対応する閾値又は範囲を有してよい。ローカル解析装置は次に、所与のセンサ又はアクチュエータによって生成された動作データが、対応する閾値又は範囲を上回るか、又は下回るかを判定してよい。予測、想定、及び/又は一般化を評価するローカル解析装置の他の例もあり得る。
その後、ローカル解析装置は、評価に基づいて、予測モデル及び/若しくはワークフローを修正してよい(又は、修正しなくてもよい)。すなわち、評価が、どの予測、想定、及び/又は一般化も不正確だったことを示す場合、ローカル解析装置は、それに応じて、予測モデル及び/又はワークフローを修正してよい。そうでない場合には、ローカル解析装置は、モデル・ワークフロー対を修正せずに実行してよい。
実際には、ローカル解析装置は、予測モデル及び/又はワークフローを複数の方式で修正してよい。例えば、ローカル解析装置は、いくつかある例の中でも特に、予測モデル及び/若しくは対応するワークフローの1つ若しくは複数のパラメータ、並びに/又は、予測モデル及び/若しくはワークフローのトリガポイントを、(例えば、値又は値の範囲を修正することで)修正してよい。
1つの非限定的な例として、解析システム108は、資産102のエンジン動作温度が特定の温度を超えないと想定して、資産102のモデル・ワークフロー対を定義した可能性がある。結果として、資産102の予測モデルの部分は、第1の計算を判定し、その後、第1の計算が、想定されたエンジン動作温度に基づいて決定された閾値を超えた場合にのみ、第2の計算を判定することを伴ってよい。モデル・ワークフロー対を個別化する場合、ローカル解析装置は、資産102のエンジンの動作データを測定する1つ又は複数のセンサ及び/若しくはアクチュエータにより生成されたデータを取得してよい。ローカル解析装置は次に、このデータを、エンジン動作温度に関する想定が、実際に真であるかどうか(例えば、エンジン動作温度が閾値を超えたかどうか)判定するのに用いてよい。エンジン動作温度が、想定された特定の温度を超える値であるか、又はその温度を上回る閾値の値であることをデータが示す場合、ローカル解析装置は、例えば、第2の計算の判定をトリガする閾値を修正してよい。予測モデル及び/又はワークフローを個別化するローカル解析装置に関する、他の例もあり得る。
ローカル解析装置は、追加又は代替の検討事項に基づいて、モデル・ワークフロー対を個別化してよい。例えば、ローカル解析装置は、上述された特性のいずれかなど、1つ又は複数の資産特性に基づいてそのように個別化してよく、これらの資産特性は、ローカル解析装置によって決定されてよく、又はローカル解析装置に提供されてよい。他の例もあり得る。
例示的な実装態様において、ローカル解析装置が予測モデル及び/又はワークフローを個別化した後に、ローカル解析装置は、予測モデル及び/又はワークフローが個別化されたというインジケーションを解析システム108に提供してよい。そのようなインジケーションは、様々な形態をとってよい。例えば、インジケーションは、ローカル解析装置が修正した予測モデル及び/若しくはワークフローの態様又は一部(例えば、修正されたパラメータ、及び/又はパラメータが何に修正されたか)を識別してよく、及び/又は、修正の原因(例えば、ローカル解析装置に修正させた基本的な動作データ若しくは他の資産データ、及び/又は原因の説明)を識別してよい。他の例もあり得る。
いくつかの例示的な実装態様において、ローカル解析装置及び解析システム108は両方とも、モデル・ワークフロー対を個別化することに関わってよく、これは、様々な方式で実行されてよい。例えば、解析システム108は、資産102の特定の状態及び/又は特性を検査する命令をローカル解析装置に提供してよい。その命令に基づいて、ローカル解析装置は、資産102で検査を実行してよい。例えば、ローカル解析装置は、特定の資産のセンサ及び/又はアクチュエータによって生成された動作データを取得してよい。その後、ローカル解析装置は、検査された状態からの結果を解析システム108に提供してよい。そのような結果に基づき、解析システム108は、資産102の予測モデル及び/又はワークフローを適宜に定義し、それをローカルな実行のためにローカル解析装置へ伝送してよい。
他の例において、ローカル解析装置は、ワークフローの実行の一部として、同じ又は類似の検査動作を実行してよい。すなわち、予測モデルに対応する特定のワークフローは、ローカル解析装置に、特定の検査を実行させ、結果を解析システム108へ伝送させてよい。
例示的な実装態様において、ローカル解析装置は、予測モデル及び/又はワークフローを個別化した後に(又は、同じことをするために解析システム108と共に働いた後に)、ローカル解析装置は、最初のモデル及び/又はワークフロー(例えば、ローカル解析装置が解析システム108から最初に受信したもの)の代わりに、個別予測モデル及び/又はワークフローを実行してよい。場合によっては、ローカル解析装置は個別化されたバージョンを実行するが、ローカル解析装置は、モデル及び/又はワークフローの最初のバージョンをデータストレージに保有してよい。
概して、予測モデルを実行し、その結果として得られた出力に基づいてワークフローの動作を実行する資産は、モデルにより出力される特定のイベントが発生する可能性について、1つ又は複数の原因を決定するのを容易にしてよく、及び/又は、特定のイベントが今後発生することを防止するのを容易にしてよい。ワークフローを実行するにあたって、資産は、イベントが発生するのを防止するのに役立つ処置をローカルに決定して、この処置を講じてよく、このことは、そのような決定を行い、且つ推奨される処置を提供する解析システム108に依存することが、効率的ではなく、実現可能ではない状況(例えば、ネットワークレイテンシがある場合、ネットワーク接続が不安定な場合、資産が、通信ネットワーク106のサービスエリアから移動した場合など)では、有益になり得る。
実際には、資産は、予測モデルを様々な方式で実行してよく、これは、特定の予測モデルに依存し得る。図9は、予測モデルをローカルに実行するのに用いられ得る、ローカルな実行段階の1つの可能な例を図示するフローチャート900である。例示的なローカルな実行段階は、資産の健全性指標を出力する健全性指標モデルという観点で論じられるが、同じ又は類似のローカルな実行段階が、他の種類の予測モデルに利用されてよいことを理解されたい。さらに、例示の目的で、例示的なローカルな実行段階は、資産102のローカル解析装置によって実行されるものとして説明されるが、この段階は、他の装置及び/又はシステムによっても実行されてよい。当業者であれば、フローチャート900は、明確さ及び説明を目的として提供されていること、及び動作及び機能に関する多数の他の組み合わせが、予測モデルをローカルに実行するのに利用されてよいことを理解するであろう。
図9に示されるように、ブロック902で、ローカル解析装置は、資産102の現在の動作状態を反映するデータを受信してよい。ブロック904で、ローカル解析装置は、解析システム108により提供された、モデルに入力される動作データのセットを受信されたデータから識別してよい。ブロック906で、ローカル解析装置は次に、識別された動作データのセットをモデルに入力し、資産102の健全性指標を取得するためにモデルを実行してよい。
ローカル解析装置は、資産102の更新された動作データを引き続き受信するので、ローカル解析装置は、更新された動作データに基づいて、ブロック902〜906の動作を繰り返すことで、資産102の健全性指標も引き続き更新してよい。場合によっては、ブロック902〜906の動作は、ローカル解析装置が、資産102のセンサ及び/若しくはアクチュエータから新たなデータを受信するたびに、又は周期的に(例えば、1時間ごとに、毎日、毎週、毎月など)繰り返されてよい。このようにして、資産が動作に用いられるとき、ローカル解析装置は健全性指標を動的に、おそらくリアルタイムで更新するように構成されてよい。
図9に示される例示的なローカルな実行段階の機能は、ここで、さらに詳細に説明されることになる。ブロック902で、ローカル解析装置は、資産102の現在の動作状態を反映するデータを受信してよい。そのようなデータは、いくつかある種類のデータの中でも特に、資産102の複数のセンサのうち1つ又は複数からのセンサデータ、資産102の1つ又は複数のアクチュエータからのアクチュエータデータ、及び/又は異常状態データを含んでよい。
ブロック904で、ローカル解析装置は、解析システム108により提供された、健全性指標モデルに入力される動作データのセットを受信されたデータから識別してよい。この動作は、複数の方式で実行されてよい。
1つの例において、ローカル解析装置は、資産の種類又は資産のクラスなど、健全性指標が決定されようとしている資産102の特性に基づいて、モデルの動作データ入力のセット(例えば、対象とする特定のセンサ及び/又はアクチュエータからのデータ)を識別してよい。場合によっては、識別された動作データ入力のセットは、資産102のセンサの一部若しくは全てからのセンサデータ、及び/又は、資産102のアクチュエータの一部若しくは全てからアクチュエータデータであってよい。
別の例において、ローカル解析装置は、解析システム108により提供された予測モデルに基づいて、動作データ入力のセットを識別してよい。すなわち、解析システム108は、モデルの特定の入力について、資産102に何らかのインジケーションを(例えば、予測モデル又は別個のデータ伝送で)提供してよい。動作データ入力のセットを識別する、他の例もあり得る。
ブロック906で、ローカル解析装置は次に、健全性指標モデルを実行してよい。具体的には、ローカル解析装置は、識別された動作データのセットをモデルに入力してよく、これにより、次に、今後の所与の期間(例えば、次の2週間)内に少なくとも1つの故障が発生する全体的な可能性が決定され、出力される。
実装態様によっては、この動作は、特定の動作データ(例えば、センサデータ及び/又はアクチュエータデータ)を、健全性指標モデルの1つ又は複数の個々の故障モデルに入力するローカル解析装置を伴ってよく、それぞれの故障モデルが個々の確率を出力してよい。ローカル解析装置は次に、これらの個々の確率を用い、おそらく、健全性指標モデルに従って一部を他よりも高く重み付けして、今後の所与の期間内に発生する故障の全体的な可能性を決定してよい。
発生する故障の全体的な可能性を決定した後に、ローカル解析装置は、発生する故障の確率を健全性指標に変換してよく、この健全性指標は、今後の所与の期間(例えば、2週間)内に資産102で故障が発生しないという可能性を反映する単一の一括パラメータの形態をとってよい。例示的な実装態様において、故障確率を健全性指標に変換することは、故障確率の補数を決定するローカル解析装置を伴ってよい。具体的には、全体的な故障確率は、0から1まで変動する値の形態をとってよく、健全性指標は、その数を1から引くことで決定されてよい。故障確率を健全性指標に変換する他の例もあり得る。
資産が予測モデルをローカルに実行した後に、資産は、実行された予測モデルから結果として得られる出力に基づいて、対応するワークフローを実行してよい。概して、ワークフローを実行する資産は、(例えば、資産の内蔵システムのうち1つ又は複数に命令を送信することで)資産において動作を実行させるローカル解析装置、並びに/又は、解析システム108及び/若しくは出力システム110などの演算処理システムに、資産から遠く離れて動作を実行させるローカル解析装置を伴ってよい。上述されたように、ワークフローは、様々な形態をとってよく、したがってワークフローは、様々な方式で実行されてよい。
例えば、資産102は、データ取得方式及び/若しくはデータ伝送方式を修正する、ローカル診断ツールを実行する、資産102の動作状態を修正する(例えば、速度、加速度、ファン速度、プロペラ角度、吸気などを修正する、又は、資産102の1つ若しくは複数のアクチュエータを介して、他の機械的動作を実行する)、又は、おそらく比較的低い健全性指標のインジケーション、若しくは資産102との関連で実行されるべき推奨予防処置のインジケーションを、資産102のユーザインタフェースにおいて出力する、若しくは外部の演算処理システムへ出力するなど、資産102の何らかの挙動を修正する1つ若しくは複数の動作を内部で実行させられてよい。
別の例において、資産102は、出力システム110など、通信ネットワーク106上のシステムへ、資産102を修理するために、作業発注書を生成する、又は特定の部品を注文するなどの動作を当該システムに実行させる命令を伝送してよい。さらに別の例において、資産102は、資産102から遠く離れて動作を起こさせるのを容易にする、解析システム108などのリモートシステムと通信してよい。ワークフローをローカルに実行する資産102の他の例もあり得る。
E.モデル/ワークフローの修正段階
別の態様において、解析システム108は、修正段階を実行してよく、その間に、解析システム108は、デプロイされたモデル及び/又はワークフローを、新たな資産データに基づいて修正する。この段階は、一括モデル及びワークフロー、並びに個別モデル及びワークフローの両方について実行されてよい。
具体的には、所与の資産(例えば、資産102)がモデル・ワークフロー対に従って動作するとき、資産102は、動作データを解析システム108に提供してよく、及び/又は、データソース112は、資産102に関連した外部データを解析システム108に提供してよい。このデータに少なくとも基づいて、解析システム108は、資産102のモデル及び/若しくはワークフロー、並びに/又は、資産104など、他の資産のモデル及び/若しくはワークフローを修正してよい。他の資産のモデル及び/又はワークフローを修正するにあたって、解析システム108は、資産102の挙動から学習した情報を共有してよい。
実際には、解析システム108は、複数の方式で修正を行ってよい。図10は、モデル・ワークフロー対の修正に用いられ得る、修正段階の1つの可能な例を図示するフローチャート1000である。例示の目的で、例示的な修正段階は、解析システム108により実行されるものとして説明されるが、この修正段階は他のシステムにより実行されてもよい。当業者であれば、フローチャート1000は、明確さ及び説明を目的として提供されていること、及び動作の多数の他の組み合わせが、モデル・ワークフロー対を修正するのに利用され得ることを理解するであろう。
図10に示されるように、ブロック1002で、解析システム108は、解析システム108が特定のイベントの発生を識別するデータを受信してよい。当該データは、いくつかあるデータの中でも特に、資産102から生じる動作データ、又は資産102に関連した、データソース112からの外部データであってよい。イベントは、資産102での故障など、上述されたイベントのいずれかの形態をとってよい。
他の例示的な実装態様において、イベントは、資産102に追加される新たな要素又はサブシステムの形態をとってよい。別のイベントが、「重要インジケータ」イベントの形態をとってよく、これは、モデル定義段階の間に図7のブロック706で識別されたデータとは、おそらく閾値の差異だけ異なるデータを生成する、資産102のセンサ及び/又はアクチュエータを伴ってよい。この差異は、資産102が、資産102に類似した資産の標準動作状態を上回る又は下回る動作状態を有することを示してよい。さらに別のイベントが、1つ又は複数の重要インジケータイベントが後に続くイベントの形態をとってよい。
識別された特定のイベントの発生、及び/又は基本的なデータ(例えば、資産102に関連した動作データ及び/又は外部データ)に基づいて、解析システム108は、一括予測モデル及び/若しくはワークフロー、並びに/又は、1つ若しくは複数の個別予測モデル及び/若しくはワークフローを修正してよい。具体的には、ブロック1004で、解析システム108は、一括予測モデルを修正するかどうか判定してよい。解析システム108は、複数の理由で一括予測モデルの修正を判定してよい。
例えば、ある特定の故障が資産群のある資産で初めて発生した、又は、ある特定の新たな要素が資産群のある資産に初めて追加されたなど、識別された特定のイベントの発生が、資産102を含む複数の資産に関するこの特定のイベントの最初の発生であった場合、解析システム108は一括予測モデルを修正してよい。
別の例において、識別された特定のイベントの発生と関連したデータが、一括モデルを最初に定義するのに利用されたデータと異なる場合、解析システム108は修正を行ってよい。例えば、識別された特定のイベントの発生は、特定のイベントの発生と以前に関連しなかった動作状態のもとで、発生した可能性がある(例えば、特定の故障が、前に特定の故障で事前に測定されなかった関連センサの値で発生した可能性がある)。一括モデルを修正するための他の理由もあり得る。
解析システム108が、一括予測モデルを修正すると判定した場合、解析システム108は、ブロック1006でそのように修正してよい。そうでない場合、解析システム108は、ブロック1008へ進んでよい。
ブロック1002で受信された、資産102に関連したデータに少なくとも部分的に基づいて、解析システム108は、ブロック1006で、一括モデルを修正してよい。例示的な実装態様において、一括モデルは、図5のブロック510を参照して上述された任意の方式など、様々な方式で修正されてよい。他の実装態様において、一括モデルは、他の方式で修正されてもよい。
ブロック1008で、解析システム108は次に、一括ワークフローを修正するかどうか判定してよい。解析システム108は、複数の理由で一括ワークフローを修正してよい。
例えば、解析システム108は、一括モデルがブロック1004で修正されたかどうか、及び/又は、解析システム108で何らかの他の変化があったかどうかに基づいて、一括ワークフローを修正してよい。他の例において、資産102が一括ワークフローを実行したにもかかわらず、ブロック1002で識別されたイベントの発生が生じた場合、解析システム108は一括ワークフローを修正してよい。例えば、ワークフローが、イベント(例えば、故障)の発生防止を容易にするのに役立つことを目的とし、そのワークフローが適切に実行されたが、それにもかかわらずイベントが依然として発生した場合、解析システム108は、一括ワークフローを修正してよい。一括ワークフローを修正するための他の理由もあり得る。
解析システム108が、一括ワークフローを修正すると判定した場合、解析システム108は、ブロック1010でそのように修正してよい。そうでない場合、解析システム108は、ブロック1012へ進んでよい。
ブロック1002で受信された、資産102に関連したデータに少なくとも部分的に基づいて、解析システム108は、ブロック1010で、一括ワークフローを修正してよい。例示的な実装態様において、一括ワークフローは、図5のブロック514を参照して上述された任意の方式など、様々な方式で修正されてよい。他の実装態様において、一括モデルは、他の方式で修正されてもよい。
ブロック1012からブロック1018で、解析システム108は、(例えば、資産102及び104のそれぞれの)1つ若しくは複数の個別モデル、並びに/又は、ブロック1002で受信された、資産102に関連したデータに少なくとも部分的に基づいて(例えば、資産102若しくは資産104のうち1つの)1つ若しくは複数の個別ワークフローを修正するように構成されてよい。解析システム108は、ブロック1004〜1010と類似の方式で、そのように修正してよい。
しかし、個別モデル又はワークフローを修正するための理由は、一括の場合の理由と異なってよい。例えば、解析システム108はさらに、個別モデル及び/又は個別ワークフローを最初に定義するのに利用された基本的な資産特性を考慮してよい。特定の例において、解析システム108は、識別された特定のイベントの発生が、資産102の資産特性を有する資産に関して、この特定のイベントの最初の発生であった場合、個別モデル及び/又は個別ワークフローを修正してよい。個別モデル及び/又は個別ワークフローを修正するための他の理由もあり得る。
例示するために、図6Dは、修正されたモデル・ワークフロー対630の概念図を示す。具体的には、モデル・ワークフロー対の例示630は、図6Aの一括モデル・ワークフロー対の修正バージョンである。示されるように、修正されたモデル・ワークフロー対の例示630は、図6Aのモデル入力602の初期列を含み、モデル計算634、モデル出力範囲636、及びワークフロー動作638の修正列を含む。この例において、修正された予測モデルは、センサAからのデータとして単一の入力を有し、計算I及び計算IIIとして2つの計算を有する。修正されたモデルの出力された確率が75%より低い場合、ワークフロー動作1が実行される。出力された確率が75%と85%との間である場合、ワークフロー動作2が実行される。そして、出力された確率が85%より高い場合、ワークフロー動作3が実行される。修正された他の例示的なモデル・ワークフロー対があり得、本明細書において企図されている。
図10に戻ると、ブロック1020で、解析システム108は次に、モデル及び/又はワークフローの任意の修正を1つ若しくは複数の資産へ伝送してよい。例えば、解析システム108は、修正された個別モデル・ワークフロー対を資産102(例えば、データが修正を生じさせた資産)へ、修正された一括モデルを資産104へ伝送してよい。このようにして、解析システム108は、資産102の動作と関連付けられたデータに基づいて、モデル及び/又はワークフローを動的に修正し、資産102が属する資産群など、複数の資産にそのような修正を配信してよい。したがって、他の資産は、そのようなデータに基づいて、他の資産のローカルなモデル・ワークフロー対が補正され得るという点で、資産102から生じるデータから恩恵を受けてよく、それにより、より正確且つロバストなモデル・ワークフロー対の作成に役立つことができる。
上記の修正段階は、解析システム108により実行されるものとして論じられたが、例示的な実装態様において、資産102のローカル解析装置が、追加的に又は代替的に、上述されたのと類似の方式で修正段階を実行してよい。例えば、1つの例において、資産102が、1つ又は複数のセンサ及び/若しくはアクチュエータにより生成された動作データを利用することで動作するとき、ローカル解析装置は、モデル・ワークフロー対を修正してよい。したがって、資産102のローカル解析装置、解析システム108、又はそれらの何らかの組み合わせは、資産関連の状態が変化するにつれて、予測モデル及び/若しくはワークフローを修正してよい。このようにして、ローカル解析装置及び/又は解析システム108は、それらに利用可能な最新のデータに基づいて、モデル・ワークフロー対を継続的に適合させてよい。
F.モデル/ワークフローの動的な実行
別の態様において、資産102及び/又は解析システム108は、モデル・ワークフロー対の実行を動的に調整するように構成されてよい。具体的には、資産102及び/又は解析システム108は、資産102及び/又は解析システム108が予測モデル及び/又はワークフローを実行すべきかどうかに関して、役割の変更をトリガする特定のイベントを検出するように構成されてよい。
動作にあたっては、資産102及び解析システム108の両方は、資産102に代わって、モデル・ワークフロー対の全て又は一部を実行してよい。例えば、資産102がモデル・ワークフロー対を解析システム108から受信した後に、資産102は、そのモデル・ワークフロー対をデータストレージに格納してよいが、モデル・ワークフロー対の一部又は全てを中心的に実行するために、さらに解析システム108に頼ってよい。具体的には、資産102は、少なくともセンサデータ及び/又はアクチュエータデータを解析システム108に提供してよく、解析システム108は次に、そのようなデータを用いて、資産102の予測モデルを中心的に実行してよい。モデルの出力に基づいて、解析システム108は次に、対応するワークフローを実行してよく、又は解析システム108は、モデルの出力又は資産102の命令を資産102に伝送して、ワークフローをローカルに実行してよい。
他の例において、解析システム108は、モデル・ワークフロー対の一部又は全てをローカルに実行するために、資産102に頼ってよい。具体的には、資産102は、予測モデルの一部又は全てをローカル実行して、結果を解析システム108に伝送してよく、資産102は次に、対応するワークフローを解析システム108に中心的に実行させてよい。又は、資産102も、対応するワークフローをローカルに実行してよい。
さらに他の例において、解析システム108及び資産102は、モデル・ワークフロー対を実行する役割を分担してよい。例えば、解析システム108は、モデル及び/又はワークフローの一部を中心的に実行してよく、資産102は、モデル及び/又はワークフローの他の部分をローカルに実行してよい。資産102及び解析システム108は、自身がそれぞれ実行した役割の結果を伝送してよい。他の例もあり得る。
ある時点で、資産102及び/又は解析システム108は、モデル・ワークフロー対の実行が調整されるべきと判定してよい。すなわち、一方又は両方は、実行する役割が修正されるべきと判定してよい。この動作は、様々な方式で発生してよい。
図11は、モデル・ワークフロー対の実行を調整するのに用いられ得る調整段階の1つの可能な例を図示するフローチャート1100である。例示の目的で、例示的な調整段階は、資産102及び/又は解析システム108により実行されるものとして説明されるが、この修正段階は、他のシステムにより実行されてもよい。当業者であれば、フローチャート1100は、明確さ及び説明を目的として提供されていること、及び動作の多数の他の組み合わせが、モデル・ワークフロー対の実行を調整するのに利用され得ることを理解するであろう。
ブロック1102で、資産102及び/又は解析システム108は、モデル・ワークフロー対の実行の調整を必要とする状態を示す調整要因(又は、場合によっては複数の調整要因)を検出してよい。そのような状態の例には、いくつかある例の中でも特に、通信ネットワーク106のネットワーク状態、又は、資産102及び/若しくは解析システム108の処理状態が含まれる。例示的なネットワーク状態には、いくつかある例の中でも特に、ネットワークレイテンシ、ネットワーク帯域幅、資産102と通信ネットワーク106との間のリンクの信号強度、又はネットワーク性能に関する他のインジケーションが含まれてよい。例示的な処理状態には、いくつかある例の中でも特に、処理容量(例えば、利用可能な処理能力)、処理使用量(例えば、消費される処理能力の量)、又は処理能力に関する何らかの他のインジケーションが含まれてよい。
実際には、調整要因を検出することは、様々な方式で実行されてよい。例えば、この動作は、ネットワーク(又は、処理)状態が1つ若しくは複数の閾値に達したかどうか、又は、状態が、一定の方式で変化したかどうか判定することを伴ってよい。調整要因を検出する他の例もあり得る。
具体的には、場合によっては、調整要因を検出することは、資産102と解析システム108との間の通信リンクの信号強度が、閾値信号強度未満である、又は一定の変化割合で減少しているというインジケーションを検出する、資産102及び/若しくは解析システム108を伴ってよい。この例において、調整要因は、資産102が「オフライン」になろうとしていることを示してよい。
別の場合において、調整要因を検出することは、ネットワークレイテンシが閾値レイテンシを上回っている、又は一定の変化割合で増加しているというインジケーションを検出する、資産102及び/若しくは解析システム108を、追加的に又は代替的に伴ってよい。又は、このインジケーションは、ネットワーク帯域幅が閾値帯域幅未満である、又は一定の変化割合で減少しているということであってよい。これら例において、調整要因は、通信ネットワーク106が遅延していることを示してよい。
さらに他の場合において、調整要因を検出することは、処理容量が特定の閾値未満であるか、若しくは一定の変化割合で減少している、並びに/又は、処理使用量が閾値を上回っているか、若しくは一定の変化割合で増加しているというインジケーションを検出する、資産102及び/又は解析システム108を、追加的に又は代替的に伴ってよい。そのような例において、調整要因は、資産102(及び/又は、解析システム108)の処理能力が低いことを示し得る。調整要因を検出する他の例もあり得る。
ブロック1104で、検出された調整要因に基づいて、ローカルな実行の役割が調整されてよく、これは複数の方式で生じてよい。例えば、資産102は、調整要因を検出して、モデル・ワークフロー対又はその一部をローカルに実行すると判定した可能性がある。場合によっては、資産102は、資産102が予測モデル及び/又はワークフローをローカルに実行しているという通知を、解析システム108へ伝送してよい。
別の例において、解析システム108は、調整要因を検出して、モデル・ワークフロー対又はその一部を資産102にローカルに実行させる命令を、資産102へ伝送した可能性がある。その命令に基づいて、資産102は次に、モデル・ワークフロー対をローカルに実行してよい。
ブロック1106で、中心的な実行の役割が調整されてよく、これは複数の方式で生じてよい。例えば、中心的な実行の役割は、資産102が予測モデル及び/又はワークフローをローカルに実行しているというインジケーションを検出する解析システム108に基づいて、調整されてよい。解析システム108は、そのようなインジケーションを様々な方式で検出してよい。
いくつかの例において、解析システム108は、資産102が予測モデル及び/又はワークフローをローカルに実行しているという通知を資産102から受信することで、インジケーションを検出してよい。その通知は、2進数又はテキストなど、様々な形態をとってよく、資産がローカルに実行している特定の予測モデル及び/又はワークフローを識別してよい。
他の例において、解析システム108は、受信された資産102の動作データに基づいて、インジケーションを検出してよい。具体的には、インジケーションの検出は、資産102の動作データを受信して、受信されたデータの1つ又は複数の特性を検出する解析システム108を伴ってよい。受信されたデータの1つ又は複数の検出された特性から、解析システム108は、資産102が予測モデル及び/又はワークフローをローカルに実行していると推測してよい。
実際には、受信されたデータの1つ又は複数の特性の検出は、様々な方式で実行されてよい。例えば、解析システム108は、受信されたデータの種類を検出してよい。具体的には、解析システム108は、センサデータ又はアクチュエータデータを生成する特定のセンサ又はアクチュエータなど、データのソースを検出してよい。受信されたデータの種類に基づいて、解析システム108は、資産102が予測モデル及び/又はワークフローをローカルに実行していると推測してよい。例えば、特定のセンサのセンサ識別子の検出に基づいて、解析システム108は、資産102に特定のセンサからデータを取得させ、そのデータを解析システム108に伝送させる予測モデル及び対応するワークフローを、資産102がローカル実行していると推測してよい。
別の事例において、解析システム108は、受信されたデータの量を検出してよい。解析システム108は、その量を、データの特定の閾値と比較してよい。閾値に達した量に基づいて、解析システム108は、資産102に閾値と同等又はそれより多いデータ量を取得させる予測モデル及び/又はワークフローを、資産102がローカルに実行していると推測してよい。他の例もあり得る。
例示的な実装態様において、受信されたデータの1つ又は複数の特性の検出は、受信されるデータの種類の変化、受信されるデータの量の変化、又はデータが受信される頻度の変化など、受信されたデータの1つ又は複数の特性の特定の変化を検出する解析システム108を伴ってよい。特定の例において、受信されたデータの種類の変化は、受信されるセンサデータのソースの変化(例えば、解析システム108に提供されるデータを生成しているセンサ及び/又はアクチュエータの変化)を検出する解析システム108を伴ってよい。
場合によっては、受信されたデータの変化の検出は、最近受信されたデータを過去に受信されたデータ(例えば、現時点の1時間前、1日前、1週間前など)と比較する解析システム108を伴ってよい。いずれにしても、受信されたデータの1つ又は複数の特性の変化を検出することに基づいて、解析システム108は、資産102により解析システム108に提供されるデータにそのような変化をもたらす予測モデル及び/又はワークフローを、資産102がローカルに実行していると推測してよい。
さらに、解析システム108は、ブロック1102における調整要因の検出に基づいて、資産102が予測モデル及び/若しくはワークフローをローカル実行しているというインジケーションを、検出してよい。例えば、解析システム108がブロック1102で調整要因を検出した場合、解析システム108は、資産102にそのローカルな実行の役割を調整させる命令を、資産102へ伝送してよく、それに応じて、解析システム108は、自身の中心的な実行の役割を調整してよい。インジケーションを検出する他の例もあり得る。
例示的な実装態様において、中心的な実行の役割は、ローカルな実行の役割に対する調整に従って調整されてよい。例えば、資産102が現在、予測モデルをローカルに実行している場合、解析システム108はそれに応じて、予測モデルの中心的な実行を中止してよい(また、対応するワークフローの中心的な実行を中止しても、しなくてもよい)。さらに、資産102が対応するワークフローをローカルに実行している場合、解析システム108はそれに応じて、ワークフローの実行を中止してよい(また、予測モデルの中心的な実行を中止しても、しなくてもよい)。他の例もあり得る。
実際には、資産102及び/又は解析システム108は、ブロック1102〜1106の動作を継続的に実行してよい。そして場合によっては、ローカルな実行の役割及び中心的な実行の役割は、モデル・ワークフロー対の実行を最適化するのを容易にするように調整されてよい。
さらに、実装態様によっては、資産102及び/又は解析システム108は、調整要因の検出に基づいて、他の動作を実行してよい。例えば、通信ネットワーク106の状態(例えば、帯域幅、レイテンシ、信号強度、又はネットワーク品質の別のインジケーション)に基づいて、資産102は、特定のワークフローをローカルに実行してよい。この特定のワークフローは、通信ネットワークの状態を検出する解析システム108に基づいて、解析システム108により提供されてよく、資産102に既に格納されていてよく、又は、資産102に既に格納されたワークフローの修正バージョン(例えば、資産102はワークフローをローカルに修正してよい)であってよい。場合によっては、特定のワークフローは、いくつかある可能なワークフロー動作の中でも特に、サンプリングレートを増やす若しくは減らすデータ収集方式、及び/又は、解析システム108へ伝送される伝送レート若しくはデータ量を増やす若しくは減らすデータ伝送方式を含んでよい。
特定の例において、資産102は、通信ネットワークの1つ又は複数の検出された状態が、(例えば、不安定なネットワーク品質を示す)それぞれの閾値に達したと判定してよい。そのような判定に基づいて、資産102は、資産102が解析システム108へ伝送するデータの量及び/又は頻度を減らすデータ伝送方式に従ってデータを伝送することを含む、ワークフローをローカルに実行してよい。他の例もあり得る。
V.例示的な方法
ここで、図12を参照すると、解析システム108により実行され得る一括予測モデル及び対応するワークフローを定義してデプロイするための、例示的な方法1200を示すフローチャートが図示されている。以下に論じられる方法1200及び他の方法について、フローチャートのブロックで示される動作は、上記の説明に従って実行されてよい。さらに、上述された1つ又は複数の動作は、所与のフローチャートに追加されてよい。
ブロック1202で、方法1200は、複数の資産(例えば、資産102及び104)のそれぞれの動作データを受信する解析システム108を伴ってよい。ブロック1204で、方法1200は、受信された動作データに基づいて、複数の資産の動作に関連した予測モデル及び対応するワークフロー(例えば、故障モデル及び対応するワークフロー)を定義する解析システム108を伴ってよい。ブロック1206で、方法1200は、複数の資産のうち少なくとも1つの資産(例えば、資産102)へ、その少なくとも1つの資産によるローカルな実行のために、予測モデル及び対応するワークフローを伝送する解析システム108を伴ってよい。
図13は、解析システム108により実行され得る個別予測モデル及び/又は対応するワークフローを定義してデプロイするための、例示的な方法1300のフローチャートを図示する。ブロック1302で、方法1300は、複数の資産の動作データを受信する解析システム108を伴ってよく、複数の資産には、少なくとも第1の資産(例えば、資産102)が含まれる。ブロック1304で、方法1300は、受信された動作データに基づいて、複数の資産の動作に関連した一括予測モデル及び対応する一括ワークフローを定義する解析システム108を伴ってよい。ブロック1306で、方法1300は、第1の資産の1つ又は複数の特性を決定する解析システム108を伴ってよい。ブロック1308で、方法1300は、第1の資産の1つ又は複数の特性、並びに一括予測モデル及び対応する一括ワークフローに基づいて、第1の資産の動作に関連した個別予測モデル及び対応する個別ワークフローのうち少なくとも1つを定義する解析システム108を伴ってよい。ブロック1310で、方法1300は、第1の資産によるローカルな実行のための、定義された少なくとも1つの個別予測モデル又は対応する個別ワークフローを、第1の資産へ伝送する解析システム108を伴ってよい。
図14は、解析システム108により実行され得るモデル・ワークフロー対の実行を動的に修正するための、例示的な方法1400のフローチャートを図示する。ブロック1402で、方法1400は、資産(例えば、資産102)へ、資産の動作に関連した予測モデル及び対応するワークフローを、資産によるローカルな実行のために伝送する解析システム108を伴ってよい。ブロック1404で、方法1400は、予測モデル及び対応するワークフローのうち少なくとも1つを、資産がローカルに実行しているというインジケーションを検出する解析システム108を伴ってよい。ブロック1406で、方法1400は、検出されたインジケーションに基づき、予測モデル及び対応するワークフローのうち少なくとも1つの、演算処理システムによる中心的な実行を修正する解析システム108を伴ってよい。
方法1400と同様に、モデル・ワークフロー対の実行を動的に修正するための別の方法が、資産(例えば、資産102)により実行されてよい。例えば、そのような方法は、資産102の動作に関連した予測モデル及び対応するワークフローを、中央演算処理システム(例えば、解析システム108)から受信する資産102を伴ってよい。本方法は、予測モデル及び対応するワークフローの実行を調整することに関連した、1つ又は複数の状態を示す調整要因を検出する資産102も伴ってよい。本方法は、検出された調整要因に基づいて、(i)予測モデル及び対応するワークフローのうち少なくとも1つについて、資産102によるローカルな実行を修正する段階と、(ii)予測モデル及び対応するワークフローのうち少なくとも1つの、演算処理システムによる中心的な実行を中央演算処理システムに修正させるのを容易にするために、資産102が、予測モデル及び対応するワークフローのうち少なくとも1つをローカルに実行しているというインジケーションを、中央演算処理システムへ伝送する段階とを伴ってよい。
図15は、例えば、資産102のローカル解析装置により、モデル・ワークフロー対をローカルに実行するための例示的な方法1500のフローチャートを図示する。ブロック1502で、方法1500は、ローカル解析装置の資産インタフェースを介してローカル解析装置に結合された資産(例えば、資産102)の動作に関連した予測モデルを、ネットワークインタフェースを介して受信するローカル解析装置を伴ってよく、この予測モデルは、複数の資産の動作データに基づいて、ローカル解析装置から遠く離れて位置する演算処理システム(例えば、解析システム108)により定義される。ブロック1504で、方法1500は、資産インタフェースを介して、資産102の動作データ(例えば、1つ又は複数のセンサ及び/若しくはアクチュエータにより生成される動作データであり、資産の中央処理装置を介して間接的に受信されても、1つ又は複数のセンサ及び/若しくはアクチュエータから直接に受信されてもよい)を受信するローカル解析装置を伴ってよい。ブロック1506で、方法1500は、資産102の受信された動作データの少なくとも一部に基づいて、予測モデルを実行するローカル解析装置を伴ってよい。ブロック1508で、方法1500は、予測モデルの実行に基づいて、予測モデルに対応するワークフローを実行するローカル解析装置を伴ってよく、ワークフローの実行は、資産インタフェースを介して、資産102に動作を実行させることを含む。
VI.結論
開示された斬新な考えの例示的な実施形態が上述された。しかし、当業者であれば、特許請求の範囲により定義されることになる、本発明の真の範囲及び精神から逸脱することなく、説明された実施形態に対して、変更及び修正が行われ得ることを理解するであろう。
さらに、本明細書で説明された例が、「人」、「事業者」、「ユーザ」、又は他のエンティティなどの行為者によって実行される、又は開始される動作を伴う限りは、これは、例示及び説明のみを目的としている。特許請求の範囲は、請求項の文言に明示的に記載されていない限り、そのような行為者による行為を必要とするものと解釈されるべきではない。