Как выглядит разнородный парк
Типовая картина в здании, которое строили и достраивали не за один заход: приточные установки одного производителя, чиллер другого, узел ввода тепла третьего, счётчики четвёртого, а часть щитов собрана местными подрядчиками в разные годы. Каждая система при этом работает нормально — проблема не в оборудовании, а в том, что у каждого куска свой язык и свой экран.
Языки действительно разные: где-то Modbus RTU по витой паре, где-то Modbus TCP или BACnet/IP по сети здания, где-то только местная панель на дверце щита, а где-то — сухой контакт «авария» и больше ничего. Отдельные установки отдают телеметрию исключительно в облако своего производителя, под его учётной записью и по его правилам. Пока объект один и дежурный ходит мимо всех щитов, это терпимо. Как только объектов становится несколько, картинка рассыпается.
Путь первый: оставить родные интерфейсы
Самый дешёвый на старте вариант — ничего не строить. У каждой системы уже есть свой интерфейс: панель на щите, веб-интерфейс контроллера, приложение или личный кабинет производителя. Всё это уже оплачено вместе с оборудованием и поддерживается тем, кто его поставил.
Сильная сторона у этого пути одна, но серьёзная: глубина. Родной интерфейс показывает все параметры машины так, как их задумал производитель, включая служебные, диагностические и те, о существовании которых интегратор обычно не знает. Для разбора сложной неисправности конкретной установки он остаётся самым полным источником — и остаётся им независимо от того, построена ли поверх общая панель.
Слабые стороны вылезают не в работе одной системы, а в эксплуатации парка:
- •Разные учётные записи и разные интерфейсы — состояние объекта дежурный собирает в голове,
- •Тревоги приходят в разные каналы и в разных форматах, общего регламента дежурства не получается,
- •Истории лежат порознь, разной глубины и в разных единицах — сравнить периоды между системами нельзя,
- •Доступ привязан к поставщику: сменили обслуживающую организацию — часть кабинетов ушла вместе с ней.
Путь второй: одна панель поверх всего парка
Второй путь — не менять то, что работает, а надстроить над ним уровень сбора. Локальная автоматика продолжает управлять своей установкой; сверху появляется слой, который опрашивает контроллеры, приводит показания к единому словарю и хранит их в одной базе. Общая механика такого сбора разобрана в статье IoT-мониторинг оборудования, а её частный случай для климата — диспетчеризация HVAC.
Ключевая работа здесь не в дашборде, а в приведении к общему знаменателю. У одного производителя параметр называется «уставка притока», у другого — «SetPoint Supply», у третьего это регистр без имени; температура может отдаваться целым числом с множителем, а авария — битовой маской. Единый словарь тегов и есть тот продукт, за который платят: без него панель показывает те же разрозненные показания, только в одном окне.
Что появляется вместе со слоем сбора:
- •Общие правила тревог: одинаковые границы нормы и единый порядок эскалации для той дежурной службы, которая уже есть,
- •Единая история: сравнимые графики по всем узлам и объектам за один период,
- •Роли доступа: подрядчик видит своё оборудование, служба эксплуатации — весь объект,
- •Независимость от поставщика: меняется источник данных, а панель, история и регламенты остаются.
Сравнение по существенным критериям
| Критерий | Родные интерфейсы | Одна панель |
|---|---|---|
| Затраты на старте | уже оплачены с оборудованием | нужен проект интеграции |
| Глубина по одной машине | максимальная, все параметры производителя | обычно меньше: только значимые параметры |
| Картина по объекту целиком | складывается в голове дежурного | видна сразу, в одном месте |
| Тревоги | каждая система шлёт по-своему | один канал, общие границы и эскалация |
| История и отчёты | у каждого своя, разной глубины | единая база, сравнимые периоды |
| Несколько объектов | умножает число кабинетов | один список объектов |
| Смена подрядчика | доступ уходит вместе с ним | слой остаётся, меняется источник |
| Кто отвечает за работу | каждый производитель за своё | нужен владелец панели с вашей стороны |
Кому какой путь подходит
Родные интерфейсы честно достаточны, если оборудование однотипное и от одного поставщика, объект один, обслуживает его тот же, кто ставил, а дежурный и так обходит все щиты. Строить в такой ситуации слой интеграции — платить за задачу, которой нет: общая картина и без панели умещается на одном экране.
Единая панель начинает окупаться там, где сходятся несколько условий: техника от разных производителей и разных лет, объектов больше одного, есть своя служба эксплуатации со сменами, нужны сравнимая история и единый регламент тревог, а парк меняется по частям. Чем ближе ситуация к этому описанию, тем дороже обходится отсутствие общего уровня — и тем заметнее это в счетах за аварийные выезды, а не в бюджете на автоматику. Смежный случай — распределённые котельные и тепловые узлы, про них подробнее в статье удалённый мониторинг котельной.
Если выбран второй путь
Сам порядок внедрения у верхнего уровня общий и от разнородности парка не зависит — инвентаризация, пилот на одном узле, правила тревог, остальное очередями, — и по шагам он разобран в статье диспетчеризация здания: с чего начать.
Разнородный парк добавляет к этому порядку одно: выбор пути делается не один раз на объект, а по узлам. Установка с закрытым облаком и щит с одним сухим контактом попадают в общую панель как факт «авария/норма», а разбор их неисправностей остаётся в родном интерфейсе — это нормальный проектный результат, а не недоделка. Пилот на одном узле нужен ровно затем, чтобы увидеть такую границу до того, как в проект заложен весь остальной парк: если значительная часть парка говорит только сухими контактами, дешевле пересобрать план, чем обнаружить это на сдаче.
Мы готовы взяться и за обследование парка, и за слой интеграции — что именно делаем и что остаётся у заказчика, описано на странице что мы делаем.
Частые вопросы
Можно ли совмещать оба пути?
Да, эти пути друг друга не исключают. Единая панель закрывает ежедневную эксплуатацию: состояние парка, тревоги, сравнимая история. Родной интерфейс остаётся инструментом разбора конкретной неисправности — доступ к нему никуда не девается после появления общего слоя, и отказываться от него незачем.
Как понять, что родных интерфейсов уже не хватает?
По трём признакам. Состояние объекта приходится собирать из нескольких кабинетов и панелей. Тревоги приходят в разные каналы и по разным правилам, общего регламента дежурства не получается. Сравнить один период по двум системам нельзя без ручной выгрузки. Пока ни один признак не мешает работе, платить за второй путь рано.
Чем единая панель на парк отличается от диспетчеризации здания?
Уровнем задачи, а не технологией. Диспетчеризация здания — верхний уровень над инженерными системами одного объекта: котельная или тепловой узел, вентиляция, электрика, вода. Панель на разнородный парк — тот же верхний уровень, но собранный из оборудования разных производителей и часто по нескольким объектам сразу. Порядок запуска верхнего уровня на одном здании разобран отдельно, в статье про диспетчеризацию здания.
Теряется ли глубина, когда всё сводят в одну панель?
Да, и это осознанный размен. В общий слой берут параметры, по которым есть тревога или регламент; служебные и диагностические величины остаются в родном интерфейсе производителя. Панель отвечает на вопрос «что происходит с парком», а не заменяет сервисный инструмент конкретной машины.
Что делать, если установка отдаёт данные только в облако производителя?
Сначала выяснить, есть ли у этого облака выгрузка или интерфейс обмена: у части производителей он есть, у части нет, и это проверяется до проекта, а не предполагается. Если обмена нет, узел заводят в панель по тому, что доступно физически, — обычно это сигналы аварии с клемм, — а полная картина по нему остаётся в кабинете производителя.
Кто со стороны заказчика должен отвечать за общую панель?
Один человек с правом менять границы тревог и список получателей — главный инженер или руководитель службы эксплуатации. У родных интерфейсов такого владельца нет по устройству: за каждый отвечает свой поставщик. Панель без владельца зарастает неактуальными порогами и перестаёт читаться.