Amazon Web Services ブログ

Amazon Monitron による多拠点工場群設備の不良予知保全ダッシュボードデモを AWS Summit 2024 Japan で展示しました(Part 2:サービス解説編 )

複数の拠点に工場やプラントを持つ企業では何千もあるモーターやポンプなど設備の保全タイミング管理は操業品質とコストに影響する重要な課題です。 AWS Japan ソリューションアーキテクトチームはこの課題に対するソリューションのデモを開発しました。 このブログは デモ解説の Part 2として、利用している各サービスの役割、デモ開発のための工夫と実運用へ適用するための検討点を解説します。

開発したデモのサービス構成

Part 1 で解説したデモのユーザーストーリーを決めた後、私達はデモを行うための設計を開始しました。 デモ特有の要件として、 Monitron のセンサー状態を任意のものに変更したり、ダッシュボード上へニアリアルタイムにデータを反映し、連携する機器に即時通知するといった必要があるため、私達は新たな設計を行い、その解決にチャレンジしました。下の図はデモで開発した多拠点予兆保全ダッシュボードのハイレベルアーキテクチャです。

(図: 多拠点予兆保全ダッシュボードのハイレベルアーキテクチャ)

Part 2では各コンポーネントに焦点をあてて、デモでの役割と仕組みを説明します。

Amazon Monitron センサーと Amazon Monitron ゲートウェイによる撹拌機の測定

Monitron センサーと Monitron ゲートウェイは、今回のイベントに展示するミニチュアファクトリーの１つである「プロセス工場」に設置しました。工場の中に連続稼働する撹拌機をつくり、そのモーターに Monitron センサーを取り付けました。センサーが測定したデータは柱に取り付けられた Monitron ゲートウェイへ BLE (Bluetooth Low Energy) で送信され、Monitron ゲートウェイはそれを Wi-Fi でインターネット上の Monitron サービスへ送信します。このデータは Monitron アプリでデモ会場内から確認できます。

(図: Monitron 実機を設置するミニチュアプロセス工場)

このデモは多拠点設備の一元管理をテーマにしていますが、イベントで展示するすべてのミニチュアファクトリーに Monitron センサーを取り付けるのはサイズなどの問題もあり困難でした。そこで、 3D プリンターを用いてミニチュアサイズの Monitron センサーのモックを作り、それを各工場のモーターやポンプに貼り付けました。 これにより、Monitron センサーの設置イメージをわかりやすくご理解いただけます。このミニチュア Monitron センサー はとてもかわいらしいのですが、非売品です。またセンサー機能はありません。

(図: Monitron センサーとミニチュア模型)

(図: 複数の工場の設備に Monitron が設置される様子をミニチュアで表している)

AWS IoT SiteWise によるデータの収集

(図: AWS IoT SiteWise によるデータの収集)

AWS IoT SiteWise は産業データの収集・整理・分析を簡素化するマネージドサービスです。Monitron からのデータを保存・分析にするには Amazon S3 に保存し、AWS Glue などの ETL サービスで前処理と型付けを行った後に Amazon Athena などで分析することが考えられますが、今回は以下の理由から　AWS IoT SiteWise を採用しました。

  1. 収集から表示までの時間を短縮する：通常 Monitron はセンサー 1 台あたり 1 時間に 1 回の頻度でデータを送信します。分析の目的は不良予兆の検知ですから、短い時間の対応は多くの場合必要なく、数時間から 1 日に 1 回といった頻度のバッチ処理で分析すれば十分です。しかし、デモではデータ送信から結果の報告までを数秒から数分といった短い時間内に表現する必要があるため、Amazon S3 と AWS Glue を使ったデータレイク的な構成は適しません。AWS IoT SiteWise であれば、AWS IoT SiteWise API を用いて、Monitron から Amazon Kinesis Data Streams に送信されたデータを AWS Lambda で取得しニアリアルタイムで AWS IoT SiteWise 内に収集・蓄積できます。
  2. アセット管理機能： Amazon Monitron はアプリケーション内でサイトや設備といったアセットを管理します。AWS IoT SiteWise はデータをモデル化してアセットモデルを管理できるため、Monitron から受信したデータをアセットモデルのメトリクスとして収集・保存し、外部から AWS IoT SiteWise API でデータへアクセスできます。
  3. Grafana 連携の容易さ： Amazon Managed Service for Grafana には AWS IoT SiteWise との連携機能があり、Grafana から AWS IoT SiteWise 上のデータをノーコードで検索し可視化できます。
  4. アラートからのイベント発生：AWS IoT SiteWise は収集したデータを変換・評価し、しきい値に応じてアラートを作成し、AWS IoT Events を経由して他のサービスへイベントを生成できます。
  5. API による他サービスとの連携：AWS IoT SiteWise は API をもち、蓄積したデータを他のサービスから API 経由で検索したり、 AWS IoT Analytics を用いて SQL で分析できます。 また、AWS IoT TwinMaker と連携してデジタルツインを実現することも容易です。

AWS IoT Events によるイベント発生

外部のサービスや装置と連携するには、データに基づいて判定し、外部サービスを操作するイベントを発生させる必要があります。 AWS IoT Events は機器またはデバイスの障害や動作の変更を状態遷移としてモニタリングし、状態変化にあわせてイベントを発生させ、必要なアクションを起こすことができるサービスです。 デモでは AWS IoT SiteWise からのデータから、信号灯を点灯させるためのイベントと、チャットツールへ投稿するイベントを生成します。

AWS Chatbot によるチャット通知

(図: AWS Chatbot による通知)

現場の保守担当者へ保全が必要であることを通知するために、チャットツール (今回は Slack)を用いました。AWS Chatbot は AWS のイベントに応じてチャットツール (Slack や Teams) に投稿を行うことができます。また、チャット画面で AWS CLI のコマンドや AWS Lambda 関数の実行を指示することができます。 このデモでは、保守要請のポストに対して、保守担当者が「私が担当します！」ボタンを押すことで、保守担当者がアサインされる想定にしました。 また、ボタン押下に応じて、イベントの情報をチャット内に表示しています。カスタマイズによってより詳細な情報を表示するなどのワークフローも実現可能です。

信号灯による保守担当者への通知

(図: 信号灯による通知の仕組み)

監視拠点や工場の現場では、保守担当者が常時ダッシュボードをチェックしつづけることは困難です。多くの現場では信号灯の点灯や鳴動によって現場の異常を作業員に知らせます。パトライト社製のネットワーク制御信号灯 NHV シリーズ は AWS 連携機能をもち、 AWS IoT Core からの MQTT 通信による指示に応じて簡単に信号の点灯などの制御が可能です。制御と連携方法の詳細は以下の AWS ブログをご覧ください。

Amazon Monitron とパトライト社の信号灯で、設備異常の予兆を逃さない保全を実現

エミュレータによる仮想的な複数設備の状態変化

イベントには多くの来場者が訪れます。多くの来場者は 1 つの展示に多くの時間をかけて説明を聞くことはできません。 一方、予兆保全は比較的長い時間 (数週間から数か月、場合によっては数年) にわたって行う運用です。 Amazon Monitron はセンサーから 1 時間に 1 回の頻度で情報を送るためダッシュボードが頻繁に変化することはありません。また実際には短い期間に頻繁に不具合を通知することはまれです。そこで不具合発生時の運用をデモンストレーションするために私達は Monitron のデータを生成するエミュレーターアプリケーションを開発しました。
このアプリケーションは内部的に複数の Monitron センサーのように振る舞い、アプリ画面のボタンを押すことで、データを送信します。

(図: Monitron エミュレーターによる予兆検知のデモンストレーション )

実際の大規模な設備保全に適用するための検討ポイント

私達はデモの短い時間に効果を表現するために、スケーラビリティよりもリアルタイム性にこだわった設計を採用しました。多拠点・大規模な設備群の予知保全を管理する場合、今回開発したデモンストレーションのアーキテクチャは参考になるでしょう。一方で、商用環境では長期間に多数・多品種の設備を管理することが必要ですし、運用はより複雑です。このデモを気に入ったユーザーが商用環境に同様のソリューションを構築しようと考えた時に役に立つ代表的な考慮事項を以下に記載します。

スコア集計および分析機能の強化

何千ものアセットの状態からスコアを求めるには、よりスケーラブルな分析機能を使う方が良いでしょう。AWS IoT SiteWise は多数の産業設備から得るデータを収集し、設備毎に変換・評価することに優れたサービスです。一方、複数の設備から得たデータを集計・分析するには他のサービスと連携したほうが効率的な場合があります。このデモでは AWS IoT SiteWise で集計する方式と、リアルタアイム性を向上させるために AWS Lambda を用いて集計する方式を併用しました。 より大規模な集計・分析を要する場合は、AWS IoT SiteWise と連携可能な分析サービス (例えば Amazon Athena 、AWS Glue、 AWS IoT Analytics ) を用いて SQL による分析を行ったり、集計結果を Amazon Aurora のような RDBMS や Amazon Timestream のような時系列データベースへ保存することでより高度で大規模な分析に対応することができます。

保守を推奨するための基準を設定する機能

ユーザーの環境はさまざまです。商用利用においては、ユーザーの環境に合わせて保守推奨の基準を変更できる機能が必要です。このデモでは拠点とプロジェクト全体に対して、健全性を表すスコアを定義し、その値に基づいて保全を推奨するイベントを発生させました。このスコア算出方法は Monitron から出力される状態をもとに設備毎のスコアを決定しました。その後、拠点のスコアは拠点内の設備スコアの平均値を採用しました。プロジェクトスコアは最も保全を必要とする拠点の状態を優先して評価するために最もスコアの低い拠点の拠点スコアをプロジェクトスコアとして評価しました。商用環境に割り当てる基準スコアや拠点スコア・プロジェクトスコアの算出方法は管理する対象設備や運用、規模によって考慮する必要があります。さらに、運用性を考えると、このスコア設定を管理者が変更可能にする管理機能を具備することが望ましいです。

他システムとの API 連携

今回はシンプルなワークフローを用いましたが、大規模なワークフローのためには他のシステムとの統合が必要です。このデモでは AWS の外部にある装置やシステムと連携することを示すために信号灯とチャットサービスを連携しました。同様の仕組みを使うことによって、ユーザーが利用する他のシステム、例えば EAM (Enterprise Asset Management : 設備資産管理) システムやワークフロー管理システム、そして ERP (Enterprise Resources Planning) システムへ状態の変化を送り、部品の調達や人員配置計画に活用することが考えられます。

以下の情報は EAM などの外部システムとの連携において参考になるでしょう。

Amazon Monitron 以外のデータソースの統合

ユーザーが所有している別のデータソースを予知保全に活用することも検討する価値があります。実際、AWS Summit Japan 2024 の会場でこのデモを観たお客様からは、ポジティブなフィードバックとともに「Amazon Monitron に限らず、自社で利用している設備から取得できる情報も含めてこのような予知保全ダッシュボードを作りたい」というご意見を多くいただきました。 例えば多くの設備が PLC ( Programmable Logic Controller ) から情報を取得することができます。 AWS は PLC 等の工場・プラントにあるデータを AWS 上に蓄積するための IoT サービス (例えば AWS IoT SiteWise や AWS IoT Greengrass ) を提供します。 取得したデータから将来の不良予知を行うための、 機械学習サービス ( 例えば Amazon Sagemaker Canvas ) を提供しています。

AWS は Solutions Architect や Professional Service がお客様の課題を解決するご支援をします。また AWS 上でのシステム構築経験豊富な多くの AWS パートナーがいます。

おわりに

このブログでは、 多拠点工場群設備の不良予知保全ダッシュボードデモ解説の Part 2 として、利用している各サービスの役割を解説しました。 2 回のブログを通じて、 Monitron の大規模適用についての課題とソリューション、また、それをデモとして見せていくための要件と対応について説明しました。

このブログについて

このブログの内容は AWS Japan のソリューションアーキテクト 吉川晃平 、安田京太 、梶山 政伸 、三好史隆 、秦将之 、大井友三 が開発し、吉川晃平 が執筆しました。