上下水道のSCADA警報：溢水・内水氾濫・通信途絶をどう扱えば監視室が追いつくか

上下水道の警報と工場の警報は、発見経路が違う。画面の色ではない

工場で水位が閾値を超えても、運転員は通常中央操作室にいて、数分で現場に歩けます。上下水道のポンプ場は市街に散らばり、夜間は少人数当直か無人の施設も多い。工場の「停止 / 品質 / 安全」だけで分けると、上下水道が本当に扱うべきこと——下水の溢水、道路の内水氾濫、「施設が沈黙した」ことそのもの——が抜けます。

より本質的な差は発見の経路です。多くの事業体は今も通報起点です。浸水、異臭、マンホールからの流出を受付が受け、それから出動します。ここでの SCADA は、工場の警報一覧をポンプ場に移すことではありません。住民が電話する前に、溢水と内水氾濫を施設側から上げることです。

• 地理的な分散：警報は市街の揚水場、下水ポンプ場、加圧ポンプ場から届く。監視員は現場が見えず、信号だけで出動を判断する
• 公共影響が生産より先：溢水と内水氾濫が損なうのは都市環境と住民であり、ライン停止の分数ではない
• 通報は今も発見チャネル：受付の案件と現場信号が食い違うときは、測点の欠落か、すでに通信が切れていることが多い
• 降雨は複数施設を同時に上げる：同じ雨で複数ポンプ場の水位が一緒に上がる。工場の単機連鎖モデルは当てはまらない
• 通信途絶それ自体が事象：工場なら回線が切れても盤まで歩ける。上下水道で沈黙した施設は、すでに溢水しているかどうかを監視室が確認できない

したがって上下水道の警報設計で先に問うのは「何段階に分けるか」ではなく、住民が電話する前に、この信号で出動すべきかどうかを監視室が判断できるか、です。

溢水・内水氾濫・通信途絶・ポンプ故障：点数ではなく、結果で分ける

色、音、不感帯の付け方は工場向けの別稿にあります。上下水道では先に事象の結果で優先度を並べます。溢水と内水氾濫が成立したあとの対応窓は分単位です。ポンプ故障は予備ポンプがあるか、そのとき雨かを見ます。通信途絶は晴天と豪雨で意味がまったく違います。

次の四種類は監視室が日常で扱うものです。すべてを「水位高」一条にまとめず、それぞれを独立した事象種別として書くことを推奨します。

• 溢水：吸水井の高高水位、越流堰、放流口の異常——成立したら必要に応じて直ちに出動し、排水側にも同期する。設備保全のリマインドではなく、公共環境への影響
• 内水氾濫：場外の滞水、雨量とポンプ停止の同時発生、道路観測点の閾値超え——降雨の経過と突き合わせ、その場の排水不足か、上流流入が定格流量を超えたのかを判断する
• 通信途絶：ゲートウェイのハートビート消失、MQTT クラウド送信の中断——晴天なら巡回計画で回線を確認。降雨中は「溢水しているか不明」として上げ、先に電源と回線を確認し、通報を待たない
• ポンプ故障：過負荷、インバータトリップ、吐出圧力の異常——予備があれば切替えて点検を組む。最終台が止まり水位が上がっているなら溢水リスクとして上げ、単機故障として閉じない

分散施設の通知と当直：目標値は案件で検証する

施設が散らばると、すべてのポンプ場にフル当直は置けません。通知と当直はセットで設計します。どの事象を監視室の大画面に残し、どれを当直携帯へ同時に出すか、雨の日と晴れの日で名簿は同じか。当直体制（少人数当直または施設に常駐しない運用）と、警報から出動指示までの時間は目標値です。個別の案件で検証する必要があり、すでにどこでも達成済みとは書けません。

• 事象種別で振り分ける：溢水と内水氾濫は当直の即時チャネルへ。予備があるポンプ故障は保全班へ。通信途絶は降雨の有無でチャネルを切り替える
• 時間帯で名簿を変える：夜間・休日は実際に出動できる担当だけ残し、すべての事象を同じ一台に送らない
• 未確認は上位へ：リセットも出動指示もない溢水と途絶は、当直長または予備当直へ上げ、同じ一条を鳴らし続けない
• 通報案件を戻す：受付がすでに浸水を受けているのに SCADA に対応信号がない場合は、被覆の欠落として記録し、センサ追加か通信確認に回す。案件を閉じるだけにしない

通知チャネルはメール、チャット、音声のいずれでもよく、土地の当直慣行と通信事業者に合わせます。チャネルを増やすこと自体が応答を速くするわけではありません。事象で振り分けない一斉送信は、当直携帯がすぐに消音になる原因です。

事象種別・信号源・中央監視側の動きの対照

監視室が使うのは色の表ではなく、「この事象はどこから来て、何をするか」です。下表は上下水道現場でよくある事象です。単一ポンプ場の試験接続で信号と役割を突き合わせる下書きとして使え、汎用の規格ではありません。

確認済みの現場範囲は、単一ポンプ場の IoT ゲートウェイ接続、ModbusTCP 収集、MQTT によるクラウド送信です。表の出動までの時間、複数チャネル通知、少人数当直は目標値であり、施設タイプ、通信条件、当直編成に照らして個別の案件で検証する必要があります。

群管理テンプレートとのつなぎ：まず単一施設に事象定義を入れる

複数ポンプ場の群管理は別稿で、標準ポンプ場テンプレート、アドレス表出力、ゲートウェイ接続、プラットフォーム集約という横展開の考え方を書いています。本記事で足すのは一点です。溢水、内水氾濫、通信途絶、ポンプ故障の四種類と、通報を戻す規則は、単一ポンプ場テンプレートの警報定義に書き、施設が増えてから中央監視で場当たりに組まないことです。

テンプレートが次の施設へ引き継げるのは、事象種別、信号源の約束、監視側の動きの書き方です。そうすれば「水位高」が隣の施設で別の意味になりません。テンプレートが代替できないのは施設ごとの確認です。越流堰に信号があるか、場外に滞水観測があるか、受付案件が同じ事象レコードに戻せるか。

能力の境界は明示します。確認済みの納入範囲は、単一ポンプ場のゲートウェイ、ModbusTCP、MQTT クラウド送信、アドレス表の整備です。群管理テンプレートと施設横断の集約はエンジニアリング資産と提案能力であり、複数都市への展開が済んだことを意味しません。アーカイブ上の手がかりを、複数都市ですでに導入済みと言い換えると、調達判断を誤らせます。