トップ > Databricks > Databricks を活用した機械学習プロジェクトの PoC フェーズの高速化に向けた取り組みの紹介(その 2): 予知保全のための boilerplate の開発

Databricks を活用した機械学習プロジェクトの PoC フェーズの高速化に向けた取り組みの紹介(その 2): 予知保全のための boilerplate の開発

Databricks オペレーションズ・リサーチ 機械学習

こんにちは，研究開発室の福井です．研究開発室においてオペレーションズ・リサーチ(OR)のビジネス活用について研究を行っております．今回は予知保全の PoC プロジェクトを高速化するために開発室メンバーの北村さん，東さんとともに開発を進めてきた boilerplate を紹介します．

本記事は以前の記事『Databricks を活用した機械学習プロジェクトの PoC フェーズの高速化に向けた取り組みの紹介』の続きとなります．

前回のおさらい: Databricks Asset Bundle (DAB) による PoC フェーズの高速化

以前の記事でも述べたように，何らかの機械学習を実務課題に適用する際には PoC フェーズを通した検証が重要となります．PoC を通してコストを掛けすぎずに素早く機械学習アプローチの性能の評価を行い，その結果をもとに次のステップの進め方を検討します．「素早く」と書いたように，PoC はできるだけ効率よく進められることが理想となります．以前の記事では，PoC を素早く進めるためのアイデアとして，Databricks Asset Bundle (DAB) を活用して PoC 中の実装をテンプレート化するアイデアを紹介しました(図 1)．本記事では，このアイデアに沿って社内で開発した予知保全のための boilerplate を紹介します．

図1 機械学習 PoC をテンプレート化するためのアイデア．

予知保全の PoC のための boilerplate の開発

センサーなどを用いて機器の状態を監視し，残りの寿命(残耐用時間，RUL)を予測しつつ，その情報をもとにメンテナンスを計画するアプローチを予知保全と呼びます．予知保全に関する詳細については過去の北村さんの記事に詳しくまとめられておりますのでそちらを参照してください．今日まで，研究開発室ではこの予知保全に必要となる寿命予測タスクの PoC を高速化するために DAB を用いて boilerplate の開発を進めてきました．この boilerplate を用いることで「センサデータは取れているけど，これらをどのように活用したらよいかわからない」とお悩みのお客様に対し，具体的なデータの活用方法のご提案とスピーディーな検証が可能になるものと期待しています．以降では，この boilerplate を用いてできることを紹介していきます．

今回開発した boilerplate でできること

まず，機械学習では(使える状態の)データが必要となります．ここでは一旦，寿命予測に必要となる Run-to-failure の訓練データは既に得られており，それらデータが既に Databricks の Volume 上に格納されているものとします*1．この後に続く，Databricks を用いた寿命予測 PoC の主なステップ以下のようになります．

  1. データクレンジングを行うための pipeline の作成 (図 1(A))
  2. 寿命予測に適した主要な特徴量の抽出 (図 1(B))
  3. 寿命予測を行う機械学習モデルの訓練 (図 1(C))
  4. 訓練したモデルの性能の評価 (図 1(D))

ステップ 1 の pipeline の作成は，機器やセンサーの種類に応じて大きく変わってくるため案件ごとに作り込む必要があります．一方，ステップ 2 からステップ 4 までのフローは，機器への依存度が下がり，一般の機械学習のタスクとして扱うことができるため事前に実装を準備しておくことができます．今回私達が開発した boilerplate は，このステップ 2 からステップ 4 までのフローをテンプレート化したものとなっており，寿命予測の PoC で必要となる実装作業の時間の削減に大きく貢献します*2．

この boilerplate では DAB として各種の実装や設定がまとめられています．そのため，ステップ 2 からステップ 4 までのフローを Databricks 上で実施するための環境は， Databricks CLI から bundle deploy コマンドを叩くだけで簡単に作成することが可能となります．デプロイされる環境には以下のような機能が含まれています．

実際の PoC において pipeline の準備が整えば，後は上記の 2 つの workflow を実行して結果を待つだけとなります．

特徴抽出用 workflow では pipeline においてクレンジングされたセンサーデータから複数の異なる特徴量が抽出されます．これらの特徴量は，何らかの寿命予測の既存研究で用いられた実績のある特徴量となっています．各特徴量は，後段のモデルの学習において複数の異なる機械学習モデルから参照されるため，再利用しやすいように一度 Databricks の Feature Store に格納されます(図 2)．

図2 特徴抽出のための workflow と Feature store．

モデルの学習用 workflow では，先に得られた Feature store 上の特徴量を参照し複数の異なる機械学習モデルを学習します．そして，設定された評価指標に基づく評価が行われます(図 3)．これらのモデルは，開発室内での事前の調査/実験の上で寿命予測に効果的と判断されたモデルを追加しています．もし，新しいモデルを検証したい場合は，この workflow にモデルを追加するだけで他のモデルと同時に学習と評価が行えるようになります．

図3 モデルの学習の workflow．

この他にも，Databricks Apps を用いて，アノテーション作業や予測結果の確認を行うための UI を用意しています．これらの UI は Databricks 上で動作するため，Databricks の環境だけで PoC を完結させやすくなります(図 4)．

図4 PoC を支援するその他の Databricks Apps．

今後の発展の方向性

今回開発した boilerplate を発展させる方向性としては以下のようなものが考えられます．

  • (特徴抽出前段の) pipeline の作成で必要となる探索的な分析やデータクレンジングを支援する仕組みの検討
  • 予知保全に関連した他の機械学習タスクに対応する

探索的な分析やデータクレンジングを支援する仕組みの検討

ご紹介した boilerplate は，センサーデータからの特徴抽出からモデルの学習と評価までのフローをほぼ自動化してくれます．その一方，pipeline の作成工程は自動化が難しい状況にあります．IoT デバイスから得られるセンサーデータは，監視対象の機器の性質やセンサーの性質に応じて大きく異なってきます．このため必要な分析処理や前処理も機器に応じて大きく変わることになり，今回の boilerplate のような事前準備による自動化が難しくなります．センサーデータの振る舞いが大きく異なる例を図 5 に示します．図 5(a)のベアリングのデータは典型的な高周波の振動データとなりますが，図 5(b)のイオンミリング装置のデータはビームの照射に伴う各種センサーデータのゆっくりとした変化を記録しており，これらのデータの見た目は大きく異なっています．

図5 ベアリングのデータとイオンミリング装置のデータ．

開発した boilerplate の再利用性を確認するために，複数の異なるセンサーデータのデータセットを用いてある種のドッグフーディングのような実験を行いました．その結果，特徴抽出からモデルの学習と評価までは大幅に作業が簡略化できることを確認できた一方で，pipeline 作成の工程の作業負荷が未だ高いということがわかりました．特徴抽出からモデルの学習と評価までの流れと同じような自動化は難しいと思われますが，少なくとも pipeline を構築する上で助けとなるようなツール類をいくつか事前に用意して boilerplate 上に実装しておくことはできるのではないかと考えられます*3．

予知保全に関連した他の機械学習タスクに対応する

予知保全に大きく関わる機械学習のタスクは機器の寿命予測に限られません．例えば，センサデータの異常検知や故障診断も重要なタスクとなります．今回開発した boilerplate にこれらの機能を追加していくことで，より多くの場面/案件で boilerplate を活用することができるようになると考えられます．

最後に

最後まで読んでいただきありがとうございました．Flect では，今回紹介した boilerplate の開発だけではなく業務計画を最適化するためのオペレーションズ・リサーチの研究も進めております． もし，「センサーデータは取れているけどうまく活用できていない」，「センサーデータを活用して業務を最適化したい」などのお悩みをお持ちでしたらぜひご相談ください．

Appendix: メンテナンス時期とメンテナンスチーム編成の自動計画

以前の記事において，「予測した寿命をもとにメンテナンスの計画をたてられる」という旨のお話をさせていただきました．ここでは，実際に起こり得るシナリオの一例を紹介します．

実務においてメンテナンスの対象となる機器には様々なものが存在するものと思われます．特に対象の機器が大型かつ複雑である場合，様々なスキルを持ってメンバーから成るメンテナンスチームを編成する必要があります．しかし，メンテナンス対象の機器は複数存在することも多々あり，一方で，メンテナンスを行えるエンジニアの数は有限です*4．この状況を改めてまとめると以下のようになるかと思います．

  • メンテナンス対象の機器が複数存在しており，それぞれの機器が異なるタイミングで故障する
    • ただし，故障のタイミングは，本記事で紹介した boilerplate 等によって事前に予測されている
  • 機器が故障する前にメンテナンスを行う必要がある
  • 各機器をメンテナンスするためには，あるスキルの要件を満たしたエンジニアのチームを編成する必要がある
  • エンジニアの数は有限であり，各エンジニアが保有するスキルセットは異なる

この状況下において，メンテナンス計画作成の担当者は限られた人員をうまくやりくりしつつメンテナンスチームの編成とメンテナンス時期を同時に決定する必要があります(図 A1)．このような複雑な計画立案を人力で行うのは大変ですが，オペレーションズ・リサーチ(OR)の手法を用いることで，自動で計画案を作成することが可能となります．

図A1 メンテナンス時期とメンテナンスチーム編成の計画．

今回，研究開発室ではこのようなケースを想定した OR のアプリケーションの簡易的なデモを Databricks Apps で用意しました(図 A2)．このデモ用 App では，各機器のメンテナンスチームの条件の情報(図 A2(a))，各エンジニアの保有スキルの情報(図 A2(b))，予測した寿命/故障時期の情報(図 A2(c))をもとに，メンテナンスの実施時期とメンテナンスチームの編成を自動で算出しています(図 A2(d))*5．

図A2 ORによるメンテナンス計画案(メンテナンス実施時期とチーム編成)の自動作成．

研究開発室では，このような計画業務支援のためのソリューションの研究も行っております．もし，機器の寿命予測だけでなく上記のような後段の計画作成業務にもお困りでしたらぜひご相談ください．

*1:Databricks の環境構築に関しては東さんの記事を御覧ください．

*2:この試みはある種の AutoML と同じと言えます．Databricks にもAutoML の機能は存在します．しかし，Databricks の AutoML はビジネスのテーブルデータに特化した作りとなっているため，IoT データから寿命予測を行うには自前の仕組みが必要でした．

*3:このような，その都度作り込まなければいけない要素においては，もしかしたら Databricks Genie 等が役に立つかもしれません．またなにかアップデートがあれば本ブログでお伝えします．

*4:恐らくですが，風力発電のメンテナンスなどはこのような課題を抱えているのではないかと思われます

*5:このデモはメンバーの北村さんが用意してくれました