下水処理場におけるデータ収集、ローカルダッシュボード、行政プラットフォームへの送信の活用例
交代時の引き継ぎでは、水質計の指示値、PLC 内のポンプやブロワーの状態、当直記録に記載された流量を、それぞれ別々に確認することがあります。報告の段階では、測定点の名称、サンプリング時刻、プラットフォームが求める形式も照合しなければなりません。データはすでに機器の中にあっても、閲覧や連携に使いやすい一連の経路にはなっていないのです。
ここでは、一般的な下水処理場を想定したシナリオを紹介します。Woody 産業用インテリジェントゲートウェイで、機器が公開しているデータを読み取り、ゲートウェイ上のローカル App に集約して表示し、行政プラットフォームの要件に合わせて整形・送信します。これは汎用的な接続の考え方であり、実施済みの特定顧客のプロジェクトを示すものではなく、特定地域の監督機関のプラットフォームによる受入検査に合格していることも意味しません。
まず機器のデータを取り込む
本例では WD2EC を採用し、2 つの Ethernet ポート、複数のシリアルポート、4G 接続機能を使用します。Modbus TCP に対応する PLC は Ethernet2 に接続し、Modbus RTU に対応するオンライン計測器は RS485 経由で COM1 に接続します。ゲートウェイは、機器が公開するアドレスマップに従って変数を読み取ります。収集周期、データ型、通信パラメーターは、機器の要件に合わせて設定する必要があります。
対象にできる変数には、流量、水位、pH、化学的酸素要求量（COD）、アンモニア性窒素、ポンプやブロワーの運転状態などがあります。ただし、これらは測定点の候補にすぎません。実際の収集範囲は、現場に設置されている計測器、PLC に集約されているデータ、公開されているアクセス権限によって決まり、すべての機器を直接接続できるという意味ではありません。ゲートウェイが読み取るのは通信データであり、水質を直接測定するものではありません。また、本例のゲートウェイに計測器のアナログ信号を直接入力する構成でもありません。
接続後は、合意したルールに従って、変数名、測定点コード、単位、タイムスタンプ、有効性の状態を統一します。たとえば、計測器との通信が途絶えた場合は、最終更新時刻を保持したうえで無効と明示し、直前の値をそのままリアルタイム値として扱わないようにします。機器時刻とゲートウェイ時刻を使用する場合も、時刻の取得元と同期方法を明確にする必要があります。
図では、WD2EC の 4G をインターネット接続の例とし、Ethernet1 を場内の管理ネットワークに接続して、当直室のブラウザーからゲートウェイにアクセスします。機器側と管理側のアドレス設計、アクセス権限、4G 側への外向きルーティングは、現場のネットワーク設定に合わせて検証する必要があります。有線と無線が自動で切り替わることは前提にしません。構成としては WiFi、4G、有線接続を選択できますが、それぞれに対応するモデルを選ぶ必要があります。有線でインターネットと PLC の両方に接続する構成へ変更する場合は、Ethernet1 をインターネット側、Ethernet2 を機器側に使用します。
当直室のブラウザーでまとめて確認する
当直担当者は、外部のクラウドプラットフォームに先にログインしなくても、場内の管理ネットワークを通じて、PC や大型ディスプレイのブラウザーから、ゲートウェイの Web 管理画面に組み込まれたローカル App にアクセスできます。画面には、処理工程のエリア別に現在値を整理し、更新時刻と通信状態を併せて表示できます。変化の経過を確認したい場合は、保存方針に従って記録された履歴トレンドを参照します。
たとえば、処理設備、配管、流量や水質の測定点を一つの工程監視画面に配置できます。設備状態や測定点一覧と組み合わせることで、長い変数名のリストを追うのではなく、エリアごとにデータを確認できます。
ローカル App の工程監視画面を模擬データで示した運転デモです。測定値、設備状態、イベント時刻はすべて模擬データであり、現場の実測値や検収記録ではありません。実際の工程と測定点は現場に合わせて設定します。本図は閲覧専用の監視を示し、設備の操作機能は含みません。
この下水処理用ダッシュボードは、プリインストール済みの完成品ではありません。ゲートウェイが提供するのはローカル App フレームワークです。個別の画面は JS/CSS/HTML で開発し、データ処理とバックエンドのインターフェースは Lua で実装します。履歴の保存には、内蔵 SQLite を使用できます。測定点の配置、状態の表現、記録頻度、履歴検索、ユーザーのアクセス範囲は、プロジェクトの要件に合わせた設定または開発が必要です。
このように整理すれば、引き継ぎの際に同じ画面を見ながら、「現在何が読み取れているか」「いつ更新されたデータか」「どの機器との通信が途絶えているか」を確認でき、正常に見える数値だけを照合する運用から変えられます。履歴の保存期間、定周期サンプリングや変化時記録の方針、バックアップ方法は、ゲートウェイのストレージ資源に合わせて決める必要があり、無期限の保存を保証するものではありません。
行政プラットフォームの要件に合わせて送信する
ローカル表示とプラットフォームへの報告は、異なる用途です。App は現場での閲覧と保存方針に基づく記録を担い、データ配信モジュールは、合意したデータを送信先プラットフォームの要求するメッセージ形式に整えます。両者で同じ確認済みの収集変数を使用できますが、「画面で見える」ことを「プラットフォームが受信した」ことと同一視してはいけません。
接続前には、プラットフォームが公開するインターフェース資料と接続許可を取得し、測定点コード、タイムスタンプ形式とタイムゾーン、単位とデータの定義、有効性の表現、認証方式、報告周期、応答結果の意味を明確にします。ゲートウェイは HTTP/HTTPS、MQTT などのデータ配信方式に対応し、Lua で独自の配信ロジックを実装することもできます。ただし、実際にどの方式を使い、どのようなメッセージを構成するかは、送信先プラットフォームの要件に従います。
プラットフォームが専用プロトコルや特殊な接続手順を要求する場合は、実現可能性を別途確認し、適応開発と接続試験を完了する必要があります。本構成は、HJ 212 などの未確認のプロトコルへの対応を主張するものではありません。また、ネットワークがつながることは、監督機関のシステムへの接続資格が得られることを意味しません。
配信処理では、送信失敗、エラー応答、取得可能なプラットフォームの受信確認結果も記録する必要があります。ダッシュボードに「受信済み」と表示する場合は、プラットフォームが提供する該当の確認結果を根拠とし、リクエストを送出したことやデータをキャッシュに格納したことだけで成功と判断してはいけません。
中断時は収集異常と送信異常を分けて扱う
機器との通信が失敗した場合やデータが無効な場合は、まず影響を受ける測定点を明示し、プラットフォームとの取り決めに従って欠測と無効状態を処理します。古い値で正常なリアルタイムデータを装ってはいけません。インターネットやプラットフォームへの接続に異常がある場合は、送信失敗を記録し、設定に応じてゲートウェイのオフラインキャッシュ機能を使用します。
キャッシュ容量、保持時間、容量上限に達した際の処理、再試行方針は、導入時に決める必要があります。ネットワーク復旧後も、プラットフォームが認める時間枠と重複排除ルールの範囲内でのみ、取り決めに従って再試行や遡及送信を行います。すべてのプラットフォームが履歴データの遡及送信を受け付けるわけではありません。キャッシュへの保存はプラットフォームの受信を意味せず、データが絶対に失われないと保証する根拠にもなりません。現場での閲覧と外部への報告の状態は別々に表示し、当直担当者がどの段階で問題が起きているかを判断できるようにします。
接続前に確認すること
- 機器と測定点：PLC と計測器のモデル、通信プロトコル、アドレスマップ、データ型、単位、読み取り権限を照合し、候補となる指標に信頼できるデータ取得元があることを確認します。
- 画面と記録：ローカル App の開発範囲、データを無効と判断する基準、時刻の取得元、アクセス権限、保存期間、バックアップ方針を明確にします。
- ネットワークとプラットフォーム：管理側と機器側のネットワーク、4G の通信エリア、外向きルーティングを確認します。プラットフォームのインターフェース資料と許可を取得し、フィールド、認証、周期、応答結果、遡及送信ルールの接続試験を完了します。
- 監督上の要件：ゲートウェイの直接接続が認められるか、指定のデータ収集装置、認証済み機器、専用ネットワークが必須か、どのような受入検査要件があるかを、所管当局またはプラットフォーム運営者に確認します。
場内の運転データの表示は、法定の監視・測定結果と同じものではありません。ゲートウェイは、水質計の校正、法定の監視・測定機器、行政プラットフォームによる判定を代替できません。本例が扱うのはデータの読み取り、閲覧、送信に限られ、遠隔制御、自動薬注、安全インターロックには範囲を広げません。
個別の数値確認から、明確なデータ経路へ
通信可能な PLC とオンライン計測器をすでに備えた下水処理場では、この構成によって機器からの読み取り、ローカルでの閲覧、プラットフォームへの送信を一連の経路につなげられます。当直担当者はブラウザーで運転情報をまとめて照合し、システムインテグレーターは明確なインターフェース仕様に従ってメッセージを適合させます。重要なのは、独立した表をもう 1 つ増やすことではありません。データの取得元、更新時刻、有効性、報告結果をそれぞれ根拠に基づいて確認できるようにしつつ、機器、アプリケーション、監督機関のプラットフォームそれぞれの責任範囲を保つことです。