熱供給事業者の段階別熱交換ステーションにおける運転データ収集と行政への報告
熱供給設備の運転では、中央監視室が各段階の熱交換ステーションの圧力、温度、流量、バルブ状態を把握する必要があります。一方、行政の監督用データプラットフォームにも、規定に従って運転データを送信しなければなりません。現場データが各ステーションの制御盤、計測器、個別のシステムに分散していると、当直担当者は運転状況を確認しながら報告内容も整理することになり、同じデータを何度も処理しがちです。
ここでは、段階的な熱交換を行う熱供給事業者を想定します。各熱交換ステーションは上位ネットワークの熱を当該段階のネットワークへ伝え、そのネットワークが対応する熱供給輸送を担います。本文では次の対応関係を用います。以下は想定シナリオであり、導入済み顧客の実績を示すものではありません。
| 熱交換ステーションの段階 | 上位ネットワーク側 | 当該段階のネットワーク側 | 熱交換の関係 |
|---|---|---|---|
| 第1段熱交換ステーション | ネットワーク1 | ネットワーク2 | ネットワーク1から2へ熱を伝える |
| 第2段熱交換ステーション | ネットワーク2 | ネットワーク3 | ネットワーク2から3へ熱を伝える |
| 第3段熱交換ステーション | ネットワーク3 | ネットワーク4 | ネットワーク3から4へ熱を伝える |
これは各段階の別々のステーションに対応する熱交換関係であり、ネットワーク1・2・3がすべて同じステーション内にあるわけではありません。各ステーションで上位ネットワーク側と当該段階のネットワーク側のデータを別々に収集します。熱交換器の両側では熱を伝えますが、水は直接混ざりません。段階、拠点、所属ネットワークを併記する必要があります。
各熱交換ステーションの両側の運転データを収集する
接続にあたっては、圧力や温度の変数をひとまとめにするのではなく、「ステーションの段階・拠点・上位ネットワーク側／当該段階のネットワーク側・設備・測定点」の単位で整理します。例えば「第2段ステーション A・上位ネットワーク側（ネットワーク2）・入口水圧」と「第2段ステーション A・当該段階のネットワーク側（ネットワーク3）・出口水圧」は別の測定点です。「ネットワーク2の圧力」「ネットワーク3の圧力」だけで拠点と位置の識別を代用してはいけません。
| 収集対象 | 各熱交換ステーションの両側に別々に設定する測定点 | 利用時に区別・確認する事項 |
|---|---|---|
| 圧力 | 入口水圧、出口水圧 | 測定点の位置、単位、ゲージ圧か絶対圧か |
| 温度 | 入口水温、出口水温 | センサー位置と、入口・出口の定義 |
| 流量 | 上位ネットワーク側と当該段階のネットワーク側の所定位置の流量 | 瞬時流量と積算量は別々の測定点として扱い、相互に代用しない |
| バルブ | 開閉状態、開度フィードバック、異常状態など、取得可能な変数 | 実際のフィードバックと制御設定値を分け、機器の対応範囲に従って収集する |
| その他の運転指標 | 現場の必要に応じて追加する循環ポンプの状態、周波数、設備異常など | 機器が実際に提供するデータに従う |
Woody 産業用インテリジェントゲートウェイは、機器側で利用可能な通信インターフェースを通じてこれらのデータを読み取ります。例えば、現場の PLC に圧力、温度、流量の信号が集約されている場合は、対応する PLC プロトコルで変数を読み取れます。計測器に Modbus RTU または Modbus TCP インターフェースがある場合は、その計測器のアドレスマップに従って収集を設定します。
アナログ出力しかなく、通信インターフェースを持たないセンサーは、適合する PLC またはデータ収集モジュールに先に接続する必要があります。ゲートウェイのシリアルポートや Ethernet ポートをアナログ入力端子として使うことはできません。拠点が異なる場合や、機器ネットワーク同士が直接通信できない場合は、実際のネットワーク境界に合わせて収集用ゲートウェイを配置します。1台で現場全体をカバーできるとは限りません。
収集後は、プロジェクトでの取り決めに従ってフィールド名、単位、レンジ換算、タイムスタンプを統一し、通信状態、データの有効性、最終更新時刻も保持します。機器の切断やデータのタイムアウトは、表示と報告のロジックで明示的に扱う必要があります。古い値を現在値として扱ったり、正常な測定値の代わりにゼロを入れたりしてはいけません。
中央監視室では運転を確認し、行政のプラットフォームでは報告データを受信する
この構成で重要なのは、単にデータをネットワークにつなぐことではなく、収集したデータを、用途の異なる2つの明確な利用先へ届けることです。
中央監視室で段階・拠点・両側のネットワーク別にまとめて表示する
既存の監視画面構築ソフトウェアや熱供給監視システムがある場合は、双方が対応するプロトコルまたはインターフェースを使って、ゲートウェイが収集したデータを既存システムへ連携できます。画面、トレンド、業務用の表示はそのシステムが担当するため、収集対象を追加するだけのために別の画面を一式作る必要はありません。
適切な画面がない場合は、ゲートウェイのローカル App フレームワークを利用し、プロジェクトの要件に合わせて運転ダッシュボードやトレンド画面を開発する方法もあります。アクセスが許可され、ネットワーク的に到達可能な中央監視室の端末から、ブラウザーで閲覧できます。具体的な画面、履歴記録、異常通知には設定や開発が必要です。機器を接続するだけで完全な熱供給運用管理システムが自動的に備わるわけではありません。履歴データの保存範囲も、ストレージ資源を踏まえて計画する必要があります。
例えば、第1段熱交換ステーションの単一ユニット向けにローカル App の監視画面を構築する場合、上位ネットワーク側（ネットワーク1）と当該段階のネットワーク側（ネットワーク2）の往き水と戻り水の温度・圧力、流量、調節弁の開度、循環ポンプの状態、補給水系統の測定点を、それぞれ対応する設備の近くに配置できます。当直担当者は配管をたどりながらデータを確認できます。画面の「一次側／二次側」はこの熱交換ユニットの相対的な両側を表し、事業者全体のネットワーク番号の固定的な別名ではありません。第2段ではそれぞれネットワーク2／3、第3段ではネットワーク3／4に対応します。温度差や差圧などの計算値は計測器から収集した値と区別し、データの有効性と最終更新時刻も併せて表示します。
図中の数値、状態、時刻はすべてデモ用データです。この画面は、個別開発と実際の測定点への紐付けが必要な読み取り専用の設計例であり、現場に接続済みの操作画面ではありません。図が示すのは第1段ステーションのネットワーク1／2の熱交換回路1組だけで、第2段のネットワーク2／3や第3段のネットワーク3／4の回路は含みません。他の段階には対応する拠点・ユニットのページを別途作成し、この図のネットワークラベルをそのまま流用してはいけません。バルブへの書き込み条件と制御権限については後述します。
例えば、当直担当者がある第2段ステーションの当該段階のネットワーク側（ネットワーク3）で出口水温の変化に気づいた場合、そのステーションのページで上位ネットワーク側（ネットワーク2）の温度、圧力、流量、バルブのフィードバックを照合し、当該段階のネットワーク側の循環ポンプと往き・戻りの状態を確認できます。更新時刻と通信状態も照合してから、現場に点検を依頼するかを判断します。画面の役割は情報を集約して示すことであり、1つの値の変化だけから故障原因を自動的に断定するものではありません。
行政の監督用プラットフォームへ接続仕様に従って送信する
ゲートウェイのデータ配信機能では、MQTT、HTTP/HTTPS などを使ってプラットフォームと連携できます。また、Lua でフィールド変換や送信ロジックを記述することも可能です。ただし、行政のプラットフォームが使用するプロトコルや要求するメッセージ形式は、担当部門が実際に提供する接続仕様に従う必要があります。「MQTT、HTTP に対応している」ことは、「適合作業なしであらゆる監督用プラットフォームに接続できる」ことを意味しません。
接続時には、事業者、熱交換ステーションの段階、拠点、所属ネットワーク、熱交換側、測定点のコードをプラットフォームの要求フィールドに対応付け、指定された単位、時刻形式、報告周期、認証方式に従ってメッセージを構成します。同じネットワーク2の測定点でも、第1段ステーションの当該段階のネットワーク側にあるのか、第2段ステーションの上位ネットワーク側にあるのかを区別し、ステーションをまたいで統合したり相互に代用したりしてはいけません。監督要件で求められる現在値、期間ごとの統計値、積算量は別々に扱い、瞬時の測定値をそのまま統計結果として送らないようにします。
中央監視室の画面更新周期と行政への報告周期は、用途ごとに異なる設定にできます。送信後も、プラットフォームのインターフェース仕様に従って応答や受領通知を処理し、運用保守担当者が「データを収集済み」「リクエストを送信済み」「プラットフォームが受信済み」を区別できるようにします。ゲートウェイがネットワークに接続されているかどうかだけでは判断できません。
上位ネットワークが切断された場合は、ゲートウェイのオフラインキャッシュと中断後の再送機能を組み合わせ、未送信データの補完送信を設計できます。ただし、キャッシュ容量、保存期間、復旧後の送信ペースに加え、プラットフォームが過去データの補完送信を認めるか、重複をどう排除するかを事前に確認する必要があります。補完送信では元の収集時刻を保持し、過去の記録を現在のデータに書き換えてはいけません。無制限のキャッシュや、データが絶対に失われないことを保証するものでもありません。
前述のデータ収集・報告の構成図では、WD2EC による 4G 接続を例として示しています。インターネット接続は WiFi、4G、有線から、利用者が現場条件に合わせて選び、対応する機種を選定します。監督用プラットフォームが専用ネットワークや専用の接続経路を要求する場合は、その要件に従って構築する必要があり、通常のインターネット回線で代用することはできません。
バルブのフィードバック確認と制御権限を分ける
バルブの状態を収集することと、開度を変更することは別の操作です。監視だけが必要な場合は、取得可能な状態と開度フィードバックを収集するにとどめ、通信接続があるという理由で書き込みを許可しません。
事業者が求めるバルブ制御には、適合作業を行った制御画面とゲートウェイの書き込み経路を通じて、中央監視室からバルブを調整する構成で対応できます。操作には、機器がその操作に対応していること、アクセス権限が付与されていること、現場で確認が取れていること、安全インターロックが有効であることの4条件が必要です。まず対象の拠点、バルブ、書き込みが許可された設定値を確認してから指令を送り、実際の開度または状態のフィードバックを読み取ります。「指令を送信済み」を「バルブが所定の位置に到達済み」とみなしてはいけません。現場の PLC またはコントローラーは引き続きローカル制御と安全保護を担当します。ゲートウェイは安全インターロックを代替せず、通信断時のバルブの動作も現場の制御設計で明確にしておく必要があります。
この構成で行政のプラットフォームのデータ報告インターフェースが担うのは、監督用データの受信だけです。報告を受けることによってバルブの制御権限を得るわけではありません。中央監視室からのバルブ制御と行政へのデータ報告では、権限と処理フローを別々に設定します。導入前に、書き込み可能な変数、制御方式、インターロック条件を確認する必要があり、報告経路が自動的に制御経路になるものではありません。
接続前に2つの一覧を照合する
1つ目は、現場の測定点一覧です。第1段はネットワーク1／2、第2段はネットワーク2／3、第3段はネットワーク3／4という対応関係を明確にし、各ステーションで両側の入口・出口の測定位置、PLC または計測器の機種、プロトコル、変数アドレス、読み書き権限、データの単位、有効性の判定ルールを確認します。
2つ目は、プラットフォーム接続要件の一覧です。中央監視室のシステムインターフェースと表示要件、および監督用プラットフォームのコード体系、メッセージ構造、報告周期、認証、ネットワーク経路、受領通知、補完送信の要件を明確にします。外部へ報告するのは許可されたデータフィールドだけとし、認証情報とアクセス権限はプロジェクトの要件に従って管理します。
2つの一覧を対応付けた後は、ゲートウェイが現場データの収集、整理、取り決めに従った送信を担当し、中央監視室のシステムまたは個別開発のローカル App が表示を担当します。行政のプラットフォームは監督用データの受信と、そのプラットフォーム自身の業務処理を担当します。熱供給事業者は、同じ測定点のデータを基に運転状況の確認と行政への報告を行えるようになり、明確なデータの出所、処理ルール、制御の境界を保ちながら、転記や整理の重複を減らせます。