SCADA для водоканала: аварии, переливы, подтопления

Сигнализация водоканала и завода: путь обнаружения, а не цвет на экране

На заводе при выходе уровня за уставку оператор обычно сидит в операторной и за несколько минут доходит до агрегата. ПНС водоканала разбросаны по городу; ночью на объекте часто остаётся сокращённый состав или никого нет. Если ранжировать сообщения только по заводской схеме «останов / качество / безопасность», из поля зрения выпадают как раз те события, которые обязан отрабатывать водоканал: перелив стоков, подтопление улицы и сама потеря связи со станцией.

Главное отличие — путь обнаружения. Во многих водоканалах отказ по-прежнему находят по жалобе: в диспетчерскую звонят из-за воды во дворе, запаха или излива, и только тогда выезжает бригада. Задача SCADA здесь не в том, чтобы перенести заводской перечень аварий на ПНС, а в том, чтобы перелив и подтопление приходили со станции раньше, чем позвонит абонент.

• Географическая разбросанность: сообщения идут с повысительных, канализационных и подкачивающих станций по всему городу; диспетчер объекта не видит и решает о выезде только по сигналам
• Городские последствия важнее минут простоя: перелив и подтопление бьют по среде и жителям, а не по длительности останова линии
• Жалоба остаётся каналом обнаружения: если заявка с горячей линии не совпадает с полевым сигналом, чаще всего не хватает точки измерения или уже оборвана связь
• Дождь поднимает уровни сразу на группе станций: одна ливневка заполняет несколько ПНС одновременно, заводская модель каскада одного агрегата сюда не подходит
• Обрыв связи — самостоятельное событие: на заводе при потере сети можно дойти до щита; на водоканале диспетчер не знает, не идёт ли уже перелив на потерянной ПНС

Поэтому первый вопрос при проектировании сигнализации водоканала — не «сколько категорий завести», а успеет ли этот сигнал дать диспетчеру основание для выезда раньше, чем позвонит житель.

Перелив, подтопление, обрыв связи, отказ агрегата: ранжировать по последствиям, не по числу точек

Как назначать цвет, звук и зону нечувствительности, разобрано в отдельной статье по заводской сигнализации. Для водоканала сначала нужно выстроить приоритет по последствиям события: окно на перелив и подтопление измеряется минутами; отказ агрегата зависит от наличия резервного насоса и от того, идёт ли дождь; обрыв связи в сухую погоду и в ливень означает разное.

Четыре типа ниже — то, с чем диспетчерская водоканала имеет дело ежедневно. Их целесообразно оформить как отдельные типы событий, а не складывать все в одну запись «высокий уровень».

• Перелив: высокий-высокий уровень в приёмном резервуаре, переливной порог, аномалия на выпуске — при срабатывании выезд аварийной бригады и уведомление службы водоотведения; это воздействие на среду, а не напоминание о ТО
• Подтопление: вода у станции, одновременные ливень и останов ПНС, выход дорожного датчика за уставку — сверять с ходом дождя и решать, не хватает откачки на этой станции или приток сверху превысил номинальную подачу
• Обрыв связи: пропал контрольный сигнал шлюза, прервалась передача в облако по MQTT — в сухую погоду проверять канал по графику обхода; в дождь поднимать как «неизвестно, идёт ли перелив», сначала питание и канал, а не ожидание жалобы
• Отказ агрегата: перегруз, отключение преобразователя, аномалия давления на нагнетании — при наличии резерва переключить и планировать ремонт; если встал последний насос и уровень растёт, поднимать как риск перелива, а не закрывать как отказ одной машины

Рассылка и дежурство по разбросанным ПНС: целевые показатели проверяют в проекте

Когда объекты разбросаны, держать полную смену на каждой ПНС нельзя. Рассылку и дежурство проектируют вместе: какие события остаются на видеостене диспетчерской, какие дублируются на телефон дежурного, совпадает ли список получателей в дождь и в сухую погоду. Режим дежурства (сокращённый состав или работа без постоянного персонала на объекте) и время от сигнала до наряда — целевые показатели, их нужно проверять в конкретном проекте и нельзя описывать как уже достигнутый повсеместный результат.

• Разведение по типу события: перелив и подтопление — в оперативный канал дежурного; отказ агрегата при наличии резерва — в службу эксплуатации; обрыв связи переключает канал в зависимости от дождя
• Смена списка по времени суток: ночью и в праздники оставлять тех, кто реально выезжает, а не слать все события на один и тот же телефон
• Эскалация при отсутствии подтверждения: перелив и потеря связи без квитирования и без наряда поднимать дежурному инженеру или подменной смене, а не повторять одну и ту же запись
• Возврат заявок с жалоб: если горячая линия уже сообщила о воде, а в SCADA нет парного сигнала, фиксировать разрыв покрытия, затем добавлять датчик или проверять канал, а не только закрывать заявку

Каналом может быть SMS, мессенджер или голос — выбор зависит от принятого на водоканале порядка дежурства и от местных операторов связи. Больше каналов само по себе не ускоряет выезд: рассылка без разведения по типу события быстро приводит к тому, что телефон дежурного переводят в беззвучный режим.

Тип события, источник сигнала, действие диспетчера

Диспетчеру нужна не таблица цветов, а ответ на два вопроса: откуда пришло событие и что делать. Ниже — типичные события на объектах водоканала. Таблицу можно взять как черновик сверки сигналов и обязанностей на пилотной ПНС; универсальным нормативом она не является.

Подтверждённый объём на объекте — подключение IoT-шлюза одной насосной станции, сбор по ModbusTCP и передача в облако по MQTT. Сроки выдачи наряда, многоканальная рассылка и сокращённое дежурство в таблице — целевые показатели; их нужно проверять в конкретном проекте по типу станции, условиям связи и составу дежурной службы.

Стыковка с шаблоном группового управления: сначала события на одной ПНС

Диспетчеризация группы станций разобрана в отдельной статье: типовой шаблон станции, выгрузка адресной таблицы, подключение шлюза, сведение на платформе. Здесь достаточно одного требования: четыре типа событий — перелив, подтопление, обрыв связи, отказ агрегата — и правило возврата жалоб нужно заложить в определения аварий одностанционного шаблона, а не собирать их потом вручную в диспетчерской, когда объектов станет больше.

Шаблон передаёт на следующую ПНС тип события, договорённость об источнике сигнала и формулировку действия диспетчера, чтобы «высокий уровень» не означал на соседней станции нечто иное. Чего шаблон не заменяет — так это проверки по каждой ПНС: есть ли сигнал с переливного порога, есть ли датчик воды у станции, возвращается ли заявка с горячей линии в ту же запись события.

Границу компетенций нужно держать явной. Подтверждённый объём поставки — шлюз одной насосной станции, ModbusTCP, MQTT в облако и проработка адресной таблицы. Типовой шаблон группового управления и сведение по нескольким станциям — это инженерный актив и проектная компетенция, а не факт развёртывания в нескольких городах. Смешивать архивные заготовки с уже выполненным внедрением в нескольких городах нельзя: закупка тогда опирается на неверную картину.