Хроника: как разворачивается авария, когда смотреть некуда
Ситуация типовая для здания, где автоматика есть на каждом узле, а верхнего уровня нет. Каждый щит умён сам по себе, но никто не видит их одновременно. Дальше — как это выглядит по времени.
| Когда | Что происходит на объекте | Что знает служба эксплуатации |
|---|---|---|
| Вечер пятницы | Насос контура отопления шумит и подъедает ток | ничего: обход был утром |
| Ночь | Защита снимает насос; резервный не запускается — после обслуживания остался в ручном режиме | ничего |
| Утро субботы | Температура в дальнем крыле ползёт вниз | ничего |
| День субботы | Звонок арендатора: «у нас холодно» | что где-то холодно |
| Вечер субботы | Дежурный обходит узлы и находит щит в аварии | причина найдена, склад закрыт |
| Понедельник | Замена насоса, разбор с арендатором | акт, претензия и потерянные выходные |
Ничего экзотического здесь нет, и оборудование отработало ровно так, как было настроено: защита сняла насос, щит встал в аварию и зажёг лампу на дверце. Лампу никто не увидел — смотреть на неё было некому. Вся стоимость инцидента набежала не из-за поломки насоса, а из-за того, что об отказе узнали от арендатора, а не от системы: к этому времени дальнее крыло успело остыть, а когда причину нашли, склад был уже закрыт.
Три места, где цепочка порвалась
- •Нет телеметрии: авария существует только на дверце щита и в пределах помещения,
- •Нет адресного оповещения: даже когда сигнал есть, он никому конкретному не приходит,
- •Нет истории: ток насоса рос ещё с вечера пятницы, но записывать его было нечем.
Ни одно из трёх мест не лечится покупкой более дорогого щита. Это разрывы верхнего уровня, и закрываются они диспетчеризацией — независимо от того, чьё оборудование стоит на объекте.
С чего начать, чтобы хроника обрывалась на первой строке
| Шаг | Что делаете | Что появляется на выходе |
|---|---|---|
| 1 | Инвентаризация: какие узлы стоят, какие у них контроллеры, что они умеют отдавать | перечень точек и протоколов |
| 2 | Список аварий, которые нельзя пропустить, и кто на каждую реагирует | регламент оповещения |
| 3 | Пилот на одном критичном узле | рабочая цепочка «датчик — сервер — дежурный» |
| 4 | Каналы связи и поведение системы, когда связь пропала | локальная автономность и буфер данных |
| 5 | Расширение контура на остальные системы здания | единая картина объекта |
Первые два шага бумажные, и именно они определяют и стоимость, и результат. Перечень точек показывает, где хватит подключения к существующей автоматике, а где придётся ставить свой модуль сбора. Список аварий отвечает на вопрос, ради которого всё затевается: что считать аварией и кому она адресована. Тревога, которая уходит на общий ящик, в хронике выше не изменила бы ни строчки.
Шаг с каналами связи выглядит формальностью ровно до первого обрыва. Верхний уровень не должен управлять безопасностью: локальные защиты и блокировки остаются в щите и работают, даже когда сервер недоступен, а данные за время обрыва накапливаются на объекте и догружаются потом.
Для климатических систем логика та же, но набор точек другой: приточные установки, чиллеры, параметры среды — это разобрано в диспетчеризации HVAC. Общая механика сбора данных с оборудования, включая старое и «немое», — в IoT-мониторинге оборудования. Если оборудование на объекте разных марок и у каждого свой интерфейс, выбор между родными панелями и одной общей разобран в статье одна панель на разнородный парк оборудования.
Чего не делать на старте
- •Не начинать с выбора платформы: перечень точек определяет платформу, а не наоборот,
- •Не тащить в первый контур всё здание — цепочка ломается там, где её не проверили,
- •Не заводить аварии на общий адрес, который никто не читает по ночам,
- •Не переносить защиты и блокировки на верхний уровень: при обрыве связи объект останется без них,
- •Не соглашаться на систему, из которой нельзя выгрузить историю: разбор инцидента без архива невозможен.
Диспетчеризация и оповещение об авариях — направления, которыми мы занимаемся; взяться готовы как за пилотный узел, так и за здание целиком. Чем занимаемся и что остаётся у вас после работы — в разделе что мы делаем.
Частые вопросы
С чего начинать диспетчеризацию здания?
С двух документов: перечня узлов с их контроллерами и протоколами и списка аварий, которые нельзя пропустить, с указанием, кто на них реагирует. Эти списки определяют и объём работ, и цену. Без них проект превращается в закупку оборудования наугад.
Придётся ли менять существующую автоматику?
Чаще нет. Если у щита есть Modbus или хотя бы сухие контакты аварии, узел подключается к верхнему уровню без замены автоматики. Менять приходится там, где контроллер закрыт производителем и наружу не отдаёт ничего.
Что делать со старым оборудованием без цифрового выхода?
Ставится отдельный модуль сбора: датчики и дискретные сигналы заводятся на него, а он уже говорит с верхним уровнем. Это дешевле замены щита и позволяет включить в контур насосы, задвижки и вводные автоматы, которые проектировались вообще без связи.
Диспетчеризация — это про аварии или про экономию ресурсов?
На старте про аварии: система окупается тем, что о проблеме узнают раньше жалобы. Экономия появляется позже, когда накопится история и станет видно, где режимы работают вхолостую. Обещать её до первых месяцев наблюдений некорректно.
Держать систему на объекте или в облаке?
Работают оба варианта. Сервер на объекте не зависит от внешнего канала и держит данные внутри периметра; облако удобнее, когда объектов несколько, а служба эксплуатации распределена. Выбор упирается в требования безопасности заказчика, а не в технологию.
Сколько узлов брать в пилот?
Один, самый критичный. Пилот должен доказать всю цепочку — от датчика до сообщения дежурному, — а не покрыть максимум оборудования. Расширять контур проще и дешевле, когда цепочка уже работает и ей доверяют.