複数工場の設備データを一元的に確認する活用シーン

異なる地域に生産拠点を持つ製造企業を想定してみましょう。生産調整会議の準備にあたり、責任者は各工場に設備の状態や生産の進捗を問い合わせます。設備画面の写真を送る工場もあれば、手作業で作成した表を提出する工場、現場の確認を待っている工場もあります。情報がそろった頃には、写真に写っている状態がすでに変わっているかもしれません。

問題は工場同士が離れていることだけではなく、情報を確認する共通の窓口がないことです。各工場の産業用インテリジェントゲートウェイで設備データを収集し、共通のプラットフォームに接続すれば、接続済み設備の状態やカウント値をまず一元的に確認し、具体的な問題について現場に連絡できます。ゲートウェイはデータを取り出して送信し、プラットフォームは各工場の情報を使いやすい画面に整理します。

各工場で必要なデータから取り出す

最初から設備の全パラメータを本社に集める必要はありません。日常の生産調整に使うのであれば、設備 ID、稼働状態、既存のアラーム情報、生産集計に利用できるカウント値から選べます。

Woody 産業用インテリジェントゲートウェイは、さまざまな主要 PLC/CNC のデータ収集に対応しています。エンジニアは各工場で設備の具体的な型式、インターフェース、プロトコル、読み取り権限を確認します。そのうえで、ゲートウェイの Web 管理画面で対応するドライバー、通信パラメータ、データポイントを設定し、読み取った値を設備画面や現場で使われているロジックと照合します。

例えば、マシニングセンターが提供するカウント値は、良品数ではなく加工サイクル数を表している場合があります。生産量の集計に使えるかどうかは、設備の信号と現場の集計基準に照らして確認する必要があります。収集した数値を、そのまま「生産量」と呼び替えることはできません。

ゲートウェイの型式は、現場のインターフェースとネットワーク条件に応じて選びます。複数工場に導入する場合でも、同じハードウェア型式に統一する必要はありません。まず重要なデータを正しく取得し、その後で接続範囲を段階的に広げます。

同じ項目には、同じ意味を持たせる

工場を横断してデータを見る際に起こりやすい問題は、グラフが足りないことよりも、同じ名前の項目が異なる意味を持つことです。ある工場では「稼働」が自動加工中を意味し、別の工場では単に電源が入っている状態を意味するかもしれません。両者を同じ列に並べると、かえって判断を誤りやすくなります。

連携前に、工場 ID、設備 ID、状態の定義、カウントの集計基準、単位、データ収集時刻を共通で取り決めます。設備 ID は、合意した範囲内で一意である必要があります。対応付けられない状態は無理に分類せず、「不明」や「要確認」と明示できます。

シフト別や日次の集計を行う場合は、タイムゾーン、シフトの区切り、カウンターのリセット時の処理も明確にします。異なる工程や製品のカウント値を単純に足し合わせ、グループ全体の総生産量とすることはできません。こうした業務ルールは、連携先のプラットフォームで設定するか、開発して実装する必要があります。

ゲートウェイがデータを送信し、プラットフォームが表示を整理する

現場でのデータ収集ができたら、各工場のゲートウェイは MQTT や HTTP/HTTPS などを使い、受信側プラットフォームの要件に合わせてデータを送信できます。エンジニアは、プラットフォームのアドレス、認証情報、トピックまたは API のパス、項目のマッピングを設定します。具体的にどのプロトコルを使うかは、双方が対応するインターフェースによって決まります。

この経路では、役割を明確に分ける必要があります。

• 設備は元となる信号を提供：読み取り可能な状態、カウント値、アラームなどのデータを公開します。
• 各工場のゲートウェイは収集と送信を担当：設定されたデータポイントを読み取り、合意した形式で送信します。
• 共通プラットフォームは業務用の画面を担当：工場別の絞り込み、設備一覧、履歴検索、必要な集計ルールと権限設定を実装します。

プラットフォームには、既存システムを使うことも、別途構築するアプリケーションを使うこともできます。ゲートウェイがデータ送信に対応しているからといって、複数工場を管理するダッシュボードまで付属するわけではありません。プラットフォームの受信インターフェースと表示機能は、別途整える必要があります。

設備の状態を見る前に、更新時刻を確認する

生産調整会議の場面に戻りましょう。接続と画面設定が完了すれば、責任者はまず工場別に設備一覧を確認し、どの設備が稼働しているか、どの設備に既存のアラームが出ているかを把握してから、該当する現場に状況を確認できます。一つの状態を知るために、各工場から画面の写真を集める必要はありません。

ただし、画面に「稼働」と表示されていても、そのデータが現在のものとは限りません。プラットフォームには更新時刻も表示し、合意したしきい値に基づいてデータの期限切れや通信異常を示す必要があります。これにより、最後に受信した状態を現在の現場の状態と取り違えることを防ぎます。こうした表示は、プラットフォーム側で設定するか、開発して実装する必要があります。

ゲートウェイはオフラインキャッシュと中断箇所からの再送に対応しており、ネットワーク復旧後に蓄積データを追加送信するために利用できます。実際に使う際は、設定、利用可能なストレージ、データ送信経路の動作を確認する必要があり、あらゆる中断状況でデータが失われないことを保証するものではありません。履歴が必要な構成では、連携時にデータ収集時刻の記録方法とプラットフォーム側の処理を決め、遅れて送信された記録と現在のデータを区別します。後からデータを送信しても、通信断の間に状態を確認できなかった空白は解消されません。

設備が停止していても、一つの状態だけで故障や材料不足と判断することはできません。一元的な確認で得られるのは、現場に問い合わせるための手がかりです。停止の理由は、アラーム、現場からの報告、または別途設定した理由の記録を組み合わせて確認する必要があります。

接続前に確認すること

• 各工場で設備の型式、プロトコル、インターフェース、読み取り権限、公開されているデータを確認します。あるブランドに対応していても、そのすべての型式に対応するとは限りません。
• 工場 ID と設備 ID、状態の定義、カウント値の意味、単位、タイムスタンプ、集計ルールをそろえ、異常データの扱いを明確にします。
• 各工場のネットワークアクセス条件、プラットフォームの受信インターフェース、認証方式を確認します。受信側の要件に従って対応する暗号化接続を使い、認証情報とアクセス権限を設定します。
• 現場の保全担当者と収集頻度および通信負荷を確認します。プラットフォームの画面、権限、履歴、データの期限切れ表示を整え、実際のストレージ容量に応じてキャッシュと履歴データの保持を計画します。

本記事の構成は、設備データの読み取りと送信のみを行います。遠隔での起動・停止、パラメータの書き込み、プログラムのダウンロードは含みません。また、複数ゲートウェイによる Grid ネットワークの構築を、工場横断での一元的な確認の前提とするものでもありません。

一度の調整会議で本当に必要な情報から始める

最初に接続するのに適しているのは、各工場で毎日繰り返し問い合わせがあり、実際に設備から読み取れる情報です。重要なデータを一組選び、意味と時刻の基準をそろえてから、実際に利用する人にプラットフォームの画面を確認してもらいます。

こうすることで、一元的な確認は、各工場の数値を一つの画面に並べるだけではなくなります。責任者は出所をたどることができ、古くなっていないか判断できる情報を先に得たうえで、明確な質問を持って現場に連絡できます。現場とのコミュニケーションは引き続き重要ですが、毎回、画面の写真を集め直すところから始める必要はありません。