Диспетчеризация систем вентиляции под ключ в Москве и области

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

Ventilationsystems выполняет диспетчеризацию вентиляции для управляющих компаний и владельцев нескольких объектов в Москве и Московской области — от аудита существующего оборудования до организации рабочего места дежурного диспетчера.

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

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

Диспетчеризация как отдельная услуга закрывает задачи:

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

Общая черта этих клиентов — они, как правило, не располагают полной документацией на уже установленное оборудование, и первый этап работы фактически всегда — не проектирование, а обследование того, что реально стоит на объектах.

Полевой уровень — датчики и исполнительные механизмы на каждом объекте, остаются без изменений. Контроллерный уровень — существующая автоматика каждой установки, которая часто уже работает и не подлежит замене. Верхний уровень — единая SCADA (диспетчерское управление и сбор данных), которая агрегирует данные со всех объектов, а не ставится по одной штуке на каждый.

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

Совместимость оборудования разных производителей обеспечивают стандартные протоколы — Modbus, BACnet, LONworks, KNX. Современные контроллеры поддерживают их «из коробки», а интеграция с системой управления зданием (BMS, Building Management System) сводится к настройке шлюза без переделки существующей автоматики.

По практике интеграции на объектах старше пяти лет — в шести случаях из десяти часть установленных контроллеров работает по устаревшим или недокументированным протоколам производителя. Такое оборудование не переставляют — под него подбирают шлюз-конвертер, транслирующий его протокол в Modbus или BACnet для верхнего уровня, и это отдельная строка в проекте, которую редко закладывают на этапе первичной оценки бюджета.

Простое уведомление «авария на объекте» бесполезно для управляющей компании с десятками установок — важна не сама тревога, а приоритет и адресат. Систему настраивают на эскалацию: если дежурный не подтвердил получение сигнала за заданное время, уведомление автоматически уходит следующему по регламенту SLA (Service Level Agreement — соглашение об уровне обслуживания) сотруднику или подрядчику.

По практике эксплуатации многообъектных диспетчерских без настройки приоритетов — дежурный получает по несколько десятков уведомлений в сутки с 20–30 объектов, и значимая авария тонет в потоке плановых информационных сообщений. Фильтрация по критичности и разнесение по каналам — SMS для аварий, журнал для плановых событий — решает эту проблему на этапе настройки, а не количеством персонала.

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

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

Для верхнего уровня применяют MasterSCADA — совместима с контроллерами Segnetics и Siemens, — либо Desigo Insight от Siemens для более крупных многообъектных инсталляций с интеграцией охранных и противопожарных систем. Для небольшого числа объектов встречаются облачные сервисы диспетчеризации на контроллерах ОВЕН — решение проще и дешевле полноценной SCADA, но с ограниченной глубиной интеграции стороннего оборудования.

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

Стоимость диспетчеризации считают по числу точек контроля — датчиков, приводов и параметров, выведенных на верхний уровень, — а не по числу объектов или квадратных метров. Объект с одной крупной установкой и полусотней точек контроля может стоить дороже, чем три объекта с простой автоматикой и минимумом параметров.