障害が発生する前にその兆候を特定するための予測保守モデル

状況

センサーデータを使用して、障害が発生する前にマシンの障害を予測する問題に取り組んでいます。調査する方法についてアドバイスが必要です。

具体的には、実際に障害が発生する前に、差し迫った障害の兆候を特定したいと考えています。理想的には、これにより、障害が発生する前に何が起こっても修正できる十分なリードタイムが得られます。

問題

私がいる概念的なロードブロックは、さまざまな分類モデル（ロジスティック回帰、決定木、最近傍など）をデータに適合させて、その時点で特定のパラメーターが与えられた場合の失敗の確率を特定できることを知っています。ただし、実際に何かを行うのに十分な時間をかけて、次の障害の兆候を特定する方法を理解することはできません。

可能なアプローチ

私はサバイバル分析に精通していますが、複数のマシンからのデータがないため、修理後にマシンが100％に戻ったとは言えないので、必ずしも適切であるとは思いません。

また、障害が発生した時間を取り、それを1時間戻し、その点をどれだけ正確に予測できるかを考えました。可能な場合は、ターゲットをさらに1時間戻し、自信を持って予測できるリードタイムを確認します。しかし、これが適切かどうかはわかりません。

利用可能なデータ

私が持っているデータは、1台のマシンから1年間にわたって記録されています。2分ごとに記録される約60個のセンサーがあります。これらのセンサーは、マシンを構成するさまざまなコンポーネントの温度（サーモスタットの設定と実際の温度を含む）、マシンの動作速度、マシン全体の蒸気圧、ファン速度、マシンが動作しているかどうかなどの変数を測定します、など

センサーの読み取り値に加えて、マシンが実行されていない理由（シフトの変更、予防保守、故障など）も含まれるようにデータセットを充実させました。この記事の最後に、データがどのように表示されるかについての例をまとめました。データセット全体でキャプチャされた多様性の一部をキャプチャするように例を変更しました。実際には、マシンが実行を停止すると、理由にもよりますが、2分から2日の間停止します。また、変数は以下の例のように必ずしもそれほど急速に変化するわけではありませんが、いくつかの種類を提供したいと思いました。

+-----------------+----------+-------------+------------+------------+-------+-------+-----+--------------------------+------------+
|    Datetime     | CircFan  | CircFanAct  | EntrySpeed | ExhaustFan | Speed | Temp1 | Run |          Reason          | TimeBtwRun |
+-----------------+----------+-------------+------------+------------+-------+-------+-----+--------------------------+------------+
| 2009-10-19 0:00 |      100 |         600 |        461 |         40 |    45 |  1126 |   1 |                          | NA         |
| 2009-10-19 0:02 |      100 |         600 |          0 |         39 |    45 |  1120 |   0 | shift change             | 0:00       |
| 2009-10-19 0:04 |      100 |         600 |          0 |         39 |    45 |  1118 |   0 | shift change             | 0:02       |
| 2009-10-19 0:06 |       95 |         600 |        461 |         39 |    45 |  1119 |   1 |                          | 0:00       |
| 2009-10-19 0:08 |       95 |         599 |        461 |         40 |    45 |  1120 |   1 |                          | 0:02       |
| 2009-10-19 0:10 |       95 |         598 |        461 |         40 |    45 |  1120 |   1 |                          | 0:04       |
| 2009-10-19 0:12 |       95 |         597 |        461 |         40 |    45 |  1130 |   1 |                          | 0:06       |
| 2009-10-19 0:14 |      100 |         597 |          0 |         40 |    45 |   699 |   0 | failure                  | 0:00       |
| 2009-10-19 0:16 |      100 |         597 |          0 |         40 |    45 |   659 |   0 | failure                  | 0:02       |
| 2009-10-19 0:18 |      100 |         597 |          0 |         40 |    45 |   640 |   0 | failure                  | 0:04       |
| 2009-10-19 0:20 |      100 |         600 |        461 |         40 |    45 |  1145 |   1 |                          | 0:00       |
| 2009-10-19 0:22 |      100 |         600 |        461 |         40 |    45 |  1144 |   1 |                          | 0:02       |
| 2009-10-19 0:24 |       80 |         600 |        461 |         40 |    45 |  1138 |   1 |                          | 0:04       |
| 2009-10-19 0:26 |       80 |         600 |        461 |         41 |    45 |  1133 |   1 |                          | 0:06       |
| 2009-10-19 0:28 |       80 |         600 |        461 |         41 |    45 |  1134 |   1 |                          | 0:08       |
| 2009-10-19 0:30 |      100 |         600 |        461 |         41 |    45 |  1134 |   1 |                          | 0:10       |
| 2009-10-19 0:31 |      100 |         600 |        461 |         41 |    45 |  1133 |   1 |                          | 0:11       |
| 2009-10-19 0:34 |      100 |         600 |        461 |         40 |    45 |  1140 |   1 |                          | 0:13       |
| 2009-10-19 0:36 |      100 |         600 |        100 |         40 |    45 |   788 |   0 | preventative maintenance | 0:00       |
| 2009-10-19 0:38 |      100 |         600 |        100 |         40 |    45 |   769 |   0 | preventative maintenance | 0:02       |
+-----------------+----------+-------------+------------+------------+-------+-------+-----+--------------------------+------------+

これは、よく尋ねられた興味深い質問です。

いくつか質問があります。

• 目標の実現可能性について洞察はありますか？（いくつかの失敗を予測）失敗を引き起こす変数を特定しましたか？
• 障害が発生するまでの典型的な時間はどれくらいですか？

そのような問題を研究する自然な方法は、生存分析を使用することだと思います。そして、それに精通していることはプラスになります！

私が何をするか（私はあなたの問題の特定性をすべて知っていませんが）：

• 関心時間変数を計算します（$y$）およびイベント変数の発生（$delta$）：このステップでは、次のことを実行できます。

  • 障害時間をイベントと見なす
  • 予防保守時間を打ち切り変数と見なす
  • 故障時間と打ち切りの計算のためにシフト時間をスキップします

• このデータにCoxモデルを当てはめます。

  • 備考：共変量を変更する時間があります（このアドレスには、Coxモデルの時間依存共変量の処理方法に関するビネットがあります。https：//cran.r-project.org/web/packages/survival/vignettes/timedep.pdf）
  • このステップは簡単ではないかもしれません（私が時間依存共変量の専門家ではないことを知りません）。たとえば、データの変化点が多すぎる（共変量の1つが変化するとき）ため、問題が発生していると思います。

• 次に、モデルを使用するには（そして、将来的に障害が発生すると予測できるかどうかを確認するには（十分な時間前に））、Coxモデルを使用します。

  • Coxモデルは、ハザード率の推定を提供します。したがって、モデルを使用するために行う最も簡単なことは、マシンの実行中にオンライン予測を計算し、ハザード率がしきい値を超えたときにマシンを停止することを決定することです）

問題を研究する自然な方法は生存分析を使用することですが、特に失敗までの時間が短い場合は、分類方法を使用できます（この方法では、過去のデータを分析していて、打ち切りの影響を受けません）。この場合、全体的なアプローチは非常に似ていると思います。

問題についてフィードバックをお寄せください。

私は同様の問題に取り組んでいます。

これを分類タスクとしてモデル化することをお勧めします。データにラベルを付けます...システムが故障する前に閉じているシステム/時間...システムが正常なシステム/時間

次に、この分類を行うためにモデルを適合させる必要があります。おそらく、最初に間隔でデータを集計する必要があります。