ポートフォリオ一覧
2024.06製造・エネルギー新規構築

スマートファクトリー設備モニタリング

設備信号をリアルタイムに受け取り、稼働と異常の状態を一画面で確認できるようにしました。

ウェブサーバー・インフラ
スマートファクトリー設備モニタリング
納品物をもとに再構成した画面です。顧客データは含みません。
開発期間
約5か月
体制
4名
対応プラットフォーム
ウェブ · サーバー
収集対象
設備PLC信号

背景

設備に異常が発生しても、現場作業者が目視で確認するまで誰も気づけませんでした。設備信号はPLCに残っていましたが、それを集約して見る画面がありませんでした。

実装範囲

  • 設備信号のリアルタイム収集
  • 稼働・停止・異常状態の表示
  • 設備別履歴の照会
  • 異常発生時の通知
  • 設備グループ別ダッシュボード

技術選定

その状況で何をなぜ選んだか

HTTPポーリングではなくMQTTによる設備信号の収集

設備のPLCは1秒あたり数百件単位で信号を送り出しますが、一定周期で状態を問い合わせるポーリング方式では周期の間に発生した信号がそのまま失われていました。ブローカーを置いて設備側が信号をパブリッシュする方式に変え、欠落なく順序どおりに受け取れるようにしました。

Azure上で収集と処理を分離して構成

信号収集が一時的に遅れても画面表示まで一緒に遅くなると、現場対応が遅れてしまいます。収集パイプラインと閲覧用データを分離し、片方が遅延してももう片方の画面は引き続き見られるようにしました。

技術課題

課題

設備の種類ごとに信号規格が異なり、同じ稼働中の状態でも表現される値がまちまちでした。

アプローチ

設備種類別の信号を共通の状態値へマッピングするルールを別途管理し、新規設備が追加された際はマッピングルールだけを登録すれば済むよう構造を分けました。

結果

画面上では設備の種類にかかわらず、同じ基準で稼働・停止・異常の状態を確認できるようになりました。

課題

ネットワークが一時的に切断されるとその間は設備信号が届かず、実際には正常なのに画面上は停止と表示される場合がありました。

アプローチ

MQTTのQoS 1設定で最低1回の配信を保証し、一定時間信号がない場合にのみ異常と表示するよう判定基準に猶予時間を設けました。

結果

瞬間的なネットワーク切断が設備異常として誤表示されるケースが減りました。

引き継ぎと運用

現場管理者向けのダッシュボード利用ガイドと設備信号マッピングの登録方法を文書として残しました。ソースコードと配布構成を引き渡し、新規設備タイプの追加は別途の保守で対応しました。

技術スタック

PythonMQTTAzure