Интеграция систем автоматизации зданий — KNX, BACnet, Modbus и Loxone

KNX

KNX — стандарт управления зданием для освещения, солнцезащиты, управления помещениями и некоторых терминалов ОВК. Устройства работают в общей шине на витой паре, а адреса организованы в линии и области. Конфигурация хранится в самих устройствах и задаётся инженерным инструментом; шлюз может предоставить групповые адреса в IP-сеть или другую платформу. KNX силён там, где функциям помещения нужна стабильная, независимая от поставщика шина. Работа по интеграции сосредоточена на именовании групповых адресов, типах точек данных и поведении при переходе шлюза или сегмента шины в офлайн. Установку KNX с хорошей документацией проще расширять; установка без именования групповых адресов превращается в чёрный ящик. Шлюз следует проверять при реальной нагрузке шины, а не только с лабораторным устройством. Значение имеют также питание шины, терминация и число устройств на линию: пограничная по параметрам линия KNX даёт неисправности, похожие на отказы устройств.

• Шина устройств на витой паре
• Групповые адреса по линиям и областям
• Шлюз в IP-сеть или другую платформу
• Проверка поведения при потере связи

BACnet

BACnet — общий язык систем управления оборудованием и зданием. Он определяет объекты, свойства и сервисы, поэтому чиллер или приточная установка могут структурированно передавать свой статус, уставки и тревоги. BACnet/IP работает поверх Ethernet, MS/TP — поверх последовательной шины. Для интеграции нужны экземпляр устройства, идентификаторы объектов, единицы измерения и права чтения и записи. Подписки на изменение значения снижают нагрузку опроса, но реализованы хорошо не во всех устройствах. В карте точек следует фиксировать, какие объекты доступны только для чтения, какие допускают команды и что происходит при потере связи. Перечень объектов нужно выгружать и проверять до построения мнемосхем, а не обнаруживать на пусконаладке. Точки статуса только для чтения и уставки, допускающие команды, следует разделять и на мнемосхемах, и в правах доступа. Номера экземпляров устройств BACnet должны быть уникальны в пределах всей объединённой сети, а конфигурацию BBMD или маршрутизаторов необходимо документировать, когда трафик пересекает подсети.

• Объекты, свойства и сервисы
• BACnet/IP поверх Ethernet
• MS/TP поверх последовательной шины
• Права чтения и записи и поведение при отказе

Modbus

Modbus прост, широко распространён и не прощает ошибок. Он предоставляет регистры и катушки, и интегратор обязан знать карту регистров, тип данных, масштабирование и порядок байтов. Modbus RTU работает поверх RS485, Modbus TCP — поверх Ethernet. Его используют счётчики, инверторы, источники питания, датчики и многие PLC. Поскольку у Modbus нет стандартной объектной модели, два устройства разных производителей могут применять один и тот же номер регистра для разных величин. Карта регистров и инженерные единицы должны быть в документе по интеграции, а не в чьей-то памяти. Один неверный коэффициент масштабирования делает энергетический отчёт правдоподобным, но ложным — это хуже очевидного отказа. Слишком частый опрос перегружает последовательную шину и вызывает тайм-ауты, похожие на отказы устройств. Последовательным сегментам также нужны правильные терминация, смещение и изоляция, а число устройств должно соответствовать реальной возможности шины.

• Регистры, катушки и функциональные коды
• RTU поверх RS485, TCP поверх Ethernet
• Масштабирование и порядок байтов
• Документированная карта регистров

DALI и шины Loxone

DALI управляет адресуемыми светильниками: индивидуальная адресация, группы, сцены и обратная связь по неисправностям. Это шина освещения, а не универсальная шина здания, и для подключения к более широкой системе ей нужен шлюз или контроллер. Loxone использует Tree для проводных устройств, Air для беспроводных и 1-Wire для простых датчиков. Tree и Air передают совместимым устройствам и питание, и данные; 1-Wire — низкоскоростная шина датчиков. Выбор между ними определяется способом строительства, типом устройств и необходимостью сохранять простую топологию шины. Шины DALI и Loxone следует держать в пределах проектных размеров сегментов и ограничений по мощности, а в проекте показывать, где начинается и заканчивается каждый сегмент. Выбор нужно фиксировать в проекте вместе с обоснованием, чтобы последующие изменения не смешивали типы шин без необходимости. Также следует документировать график проверок аварийного освещения DALI: это процедура обеспечения безопасности людей, а не сцена.

• Адресация, группы и сцены DALI
• Tree для проводных устройств Loxone
• Air для беспроводных устройств
• 1-Wire для простых датчиков

Шлюзы, сопоставление точек и тестирование

Выбор шлюза — проектное решение. Шлюз должен поддерживать требуемую версию протокола, число точек, частоту опроса и направление передачи данных. Затем сопоставление точек задаёт каждому элементу данных имя, адрес, тип, единицу измерения и права. Именование должно совпадать с чертежами и мнемосхемами оператора. Тестирование начинается на заводе с проверки «точка — точка», продолжается на объекте с реальными устройствами и завершается проверками блокировок и отказов. В комплект при передаче объекта должны входить перечень адресов, конфигурация шлюза, протоколы испытаний и однозначное указание, что доступно только для чтения. Документ по интеграции должен быть живой записью: при замене устройства его адрес и сопоставление точек обновляются в одном и том же месте. В протоколах испытаний следует указывать устройство, версию прошивки, точку и ожидаемое значение, а не только «пройдено» или «не пройдено». Недокументированный шлюз — это будущий простой с неизвестной причиной.

• Версия протокола и число точек
• Имя, адрес, тип и единица измерения
• Заводские и объектные испытания
• Перечень адресов и протоколы испытаний

Проектирование сети, адресация и синхронизация времени

Интеграция удаётся или проваливается на сетевом уровне. Начните с плана адресации: диапазоны IP для каждой системы, VLAN для инженерных систем и правило, какие устройства маршрутизируются, а какие изолированы. Для BACnet/IP важны широковещательные домены, номера экземпляров устройств и конфигурация BBMD, когда трафик пересекает подсети. Modbus TCP требует стабильной адресации и плана опроса; последовательному Modbus нужны корректные терминация, смещение и изоляция, а также ограничение числа устройств на сегмент. Шлюзы должны располагаться рядом с обслуживаемым оборудованием и питаться от цепи, которая не отключается на время обслуживания. Синхронизация времени должна идти от одного источника, и все контроллеры и шлюзы должны использовать один и тот же сервис NTP; иначе отметки времени трендов и последовательности тревог невозможно сопоставить. Сетевая документация должна входить в комплект при передаче объекта, а не быть схемой, нарисованной после первой неисправности.

• План адресации IP и VLAN
• Широковещательные домены и BBMD
• Терминация и изоляция последовательных линий
• Единый источник NTP для всех устройств

Тестирование, документация и типовые отказы

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

• Проверки точек на стенде и на объекте
• Испытания на отказ связи
• Сквозные проверки тревог и блокировок
• Перечень адресов, карта точек и запись версий прошивок

Интеграция контроля доступа

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