База знаний — Диспетчеризация

Modbus, BACnet, OPC UA и MQTT: какой протокол выбрать для автоматизации

2026-09-14 21:30
В проектах автоматизации вопрос часто формулируют так: «Какой протокол лучше — Modbus, BACnet, OPC UA или MQTT?» Но универсального победителя здесь нет. Эти технологии создавались для разных уровней системы и по-разному отвечают на четыре ключевых вопроса: как прочитать данные из оборудования, как описать их смысл, как организовать взаимодействие инженерных систем и как передать события в верхний уровень или облако.
Поэтому грамотный выбор начинается не с названия протокола, а с архитектуры объекта. На одном проекте Modbus может работать на уровне приборов и контроллеров, BACnet — объединять инженерные системы здания, OPC UA — передавать структурированные данные в SCADA или MES, а MQTT — доставлять телеметрию в аналитическую платформу. Это не конкуренты в чистом виде, а инструменты для разных задач.

Коротко: чем отличаются четыре протокола

Modbus — простой доступ к данным устройства. Обычно используется для счетчиков, ПЛК, преобразователей, датчиков и ИБП. Передает адрес регистра и значение, а его физический смысл задается картой регистров.
BACnet — взаимодействие систем автоматизации здания. Применяется для HVAC, освещения, электроснабжения, доступа и BMS. Вместе со значением передает тип объекта, свойства, состояние и служебные данные.
OPC UA — безопасный и семантически богатый обмен между промышленными системами. Связывает ПЛК, SCADA, MES, ERP и IIoT, сохраняя структуру объектов, типы данных, связи, события и метаданные.
MQTT — легкая доставка сообщений множеству потребителей через брокер. Подходит для edge-уровня, IIoT, облака, аналитики и удаленного мониторинга. Модель тем и полезной нагрузки проектируется отдельно.
Главный вывод: выбирать следует не один протокол «на весь объект», а подходящий механизм для каждого уровня архитектуры.

Modbus: простой язык оборудования

Modbus остается одним из самых распространенных протоколов промышленной автоматизации. Его поддерживают счетчики электроэнергии, анализаторы сети, частотные преобразователи, ИБП, контроллеры, модули ввода-вывода и множество других устройств.
В основе Modbus лежит простая модель данных: дискретные входы, катушки, входные регистры и регистры хранения. Клиент запрашивает у сервера определенный диапазон адресов, а устройство возвращает значения. В Modbus TCP обмен идет по Ethernet, а в Modbus RTU — по последовательной линии, чаще всего RS-485.
Сильная сторона Modbus — простота. Протокол легко диагностировать, он нетребователен к ресурсам и поддерживается огромным количеством оборудования. Но сам номер регистра почти ничего не говорит о физическом смысле значения. Чтобы понять, что в регистре 40121 хранится температура подачи с коэффициентом 0,1 °C, нужна документация производителя — карта регистров.
Типовые риски Modbus:
  • несовпадение адресации в документации и программном обеспечении;
  • разные порядки байтов и слов для 32-битных значений;
  • неверные коэффициенты масштабирования;
  • слишком частый опрос и перегрузка медленной линии RS-485;
  • отсутствие встроенной защиты в классических вариантах Modbus.
Для защищенных сетей Modbus Organization отдельно определяет Modbus Security: традиционные Modbus-сообщения передаются с использованием TLS, сертификатов и контроля целостности. Это отдельное архитектурное решение; наличие обычного Modbus TCP само по себе не означает защищенный обмен.
Когда выбирать Modbus: когда нужно надежно и без лишней сложности подключить конкретное устройство, а карта регистров известна и будет зафиксирована в проектной документации.

BACnet: общий язык инженерных систем здания

BACnet разработан специально для автоматизации зданий и стандартизован как ANSI/ASHRAE 135 и ISO 16484-5. В отличие от Modbus, он передает не только числовое значение по адресу, но и работает с объектами и их свойствами.
Например, температура помещения может быть представлена объектом Analog Input. У объекта есть идентификатор, имя, текущее значение, единицы измерения, статус надежности и другие свойства. Аналогичным образом BACnet описывает команды, расписания, тренды, календари, аварии и уведомления.
Это особенно важно для BMS бизнес-центра, отеля, торгового комплекса или больницы: диспетчерская система должна объединить вентиляцию, холодоснабжение, теплоснабжение, освещение, электроснабжение и другие подсистемы разных производителей.
Основные варианты транспорта:
  • BACnet/IP — обмен в IP-сети;
  • BACnet MS/TP — обмен по последовательной линии RS-485;
  • BACnet/SC — защищенный вариант для IP-инфраструктуры с TLS, сертификатами и соединениями WebSocket.
При этом надпись BACnet на оборудовании еще не гарантирует беспроблемную интеграцию. В проекте необходимо проверить поддерживаемые объекты, сервисы, профиль устройства, BIBB и PICS, правила формирования имен, а также возможность подписки на изменения COV. Иначе интеграция может свестись к ограниченному набору точек с ручным сопоставлением.
Когда выбирать BACnet: когда основной контекст — инженерные системы здания, нужна межвендорная интеграция и важно передавать не только значение, но и свойства объекта, расписания, события и аварии.

OPC UA: данные вместе с их смыслом

OPC UA применяется там, где недостаточно просто получить набор сигналов. Протокол позволяет построить информационную модель: представить оборудование как объекты, связать параметры между собой, задать типы данных, методы, события и ссылки.
OPC UA поддерживает две основные модели обмена. В Client–Server клиент обращается к серверу, просматривает адресное пространство, читает или записывает значения и подписывается на изменения. В PubSub издатели распространяют данные подписчикам, что удобно для масштабируемого обмена внутри промышленной сети и с IT- или облачными системами.
Важное отличие OPC UA — встроенные механизмы идентификации приложений и пользователей, шифрования и контроля целостности. Но безопасность появляется не автоматически: необходимо управлять сертификатами, отключать устаревшие режимы, задавать политики доступа и контролировать доверенные узлы.
Преимущества OPC UA раскрываются, когда информационная модель спроектирована осмысленно. Если сервер публикует тысячи переменных с именами вроде DB12.DBD44, верхний уровень получает канал связи, но не получает понятной семантики. Поэтому для интеграции с SCADA, MES или аналитикой нужны единые правила именования, типовые модели оборудования и согласованный состав данных.
Когда выбирать OPC UA: когда требуется безопасно связать промышленное оборудование и программные системы, сохранить структуру и смысл данных, передавать события и предоставить клиентам возможность автоматически исследовать модель.

MQTT: транспорт событий и телеметрии

MQTT — легковесный протокол публикации и подписки. Устройства и приложения не отправляют сообщения напрямую друг другу: издатель публикует данные в определенную тему, брокер принимает сообщение и доставляет его всем подписчикам этой темы.
Такой подход развязывает источники и потребителей данных. Контроллеру не нужно знать, сколько систем используют его телеметрию. Одно сообщение могут одновременно получить платформа мониторинга, архив, сервис уведомлений и аналитическая модель.
MQTT определяет три уровня качества доставки:
  • QoS 0 — доставка без подтверждения, возможна потеря сообщения;
  • QoS 1 — доставка как минимум один раз, возможны дубликаты;
  • QoS 2 — доставка ровно один раз на уровне протокольного обмена, с большим количеством служебных сообщений.
При этом MQTT не определяет инженерный смысл полезной нагрузки. Тема plant/line1/motor7/temperature выглядит понятно, но формат сообщения, единицы измерения, отметка времени, качество и версия схемы должны быть описаны отдельно. Без единой модели данных масштабирование быстро приводит к множеству несовместимых тем и JSON-форматов.
MQTT хорошо подходит для телеметрии, событий, удаленного мониторинга и интеграции edge-уровня с дата-центром или облаком. Но его не следует воспринимать как замену локальному управлению оборудованием или детерминированной полевой сети. Критические алгоритмы и защиты должны продолжать работать локально независимо от брокера и внешнего канала связи.
Когда выбирать MQTT: когда данные нужно эффективно распределять между множеством независимых потребителей, особенно через нестабильные или ограниченные каналы, а модель тем и полезной нагрузки будет заранее стандартизована.

Как протоколы работают вместе

  1. Счетчики, преобразователи и локальные контроллеры подключаются по Modbus RTU или Modbus TCP.
  2. Системы вентиляции, холодоснабжения и освещения бизнес-центра объединяются на уровне BMS по BACnet.
  3. Промышленное оборудование и SCADA обмениваются структурированными данными через OPC UA.
  4. Edge-шлюз нормализует нужную телеметрию и публикует ее по MQTT в платформу мониторинга, архив или облачную аналитику.
Такой подход позволяет не тянуть «сырой» полевой протокол через всю инфраструктуру. На каждом уровне используются данные подходящей детализации: регистры — рядом с оборудованием, объекты здания — в BMS, информационные модели — на уровне промышленной интеграции, сообщения — при распределении телеметрии.

Матрица выбора протокола

Нужно подключить прибор или контроллер с готовой картой регистров?

Чаще всего подойдет Modbus. Сразу согласуйте тип транспорта, скорость опроса, адресацию, форматы данных и порядок байтов.

Нужно объединить HVAC и другие инженерные системы здания?

В первую очередь рассматривайте BACnet. Проверьте поддержку нужных объектов и сервисов, документацию PICS, механизм COV и требования к кибербезопасности.

Нужно связать ПЛК, SCADA, MES и аналитические системы с сохранением структуры данных?

Подходит OPC UA. Определите информационную модель, требования к сертификатам, ролям, шифрованию, событиям и историческим данным.

Нужно отправлять телеметрию нескольким сервисам или в облако?

Подходит MQTT. Спроектируйте дерево тем, формат payload, временные метки, признаки качества, retained-сообщения, QoS, управление сессиями и права доступа.

Пять ошибок при выборе протокола

  1. Выбирать по принципу «его поддерживает больше оборудования». Совместимость интерфейса не заменяет проверку модели данных и необходимых функций.
  2. Пытаться решить одним протоколом все уровни системы. Полевой обмен, объектная модель здания и облачная доставка имеют разные требования.
  3. Откладывать кибербезопасность до пусконаладки. Сертификаты, сегментация, роли, шифрование и удаленный доступ должны быть частью проекта.
  4. Не фиксировать семантику данных. Карта регистров, PICS, модель OPC UA или схема MQTT должны входить в комплект рабочей документации.
  5. Проверять только чтение текущего значения. Для эксплуатации важны качество данных, аварии, временные метки, потеря связи, подписки, архивирование и восстановление после перезапуска.

Что выбрать для конкретного объекта

Для небольшого узла учета может быть достаточно Modbus. Для бизнес-центра основой межсистемного обмена часто становится BACnet. Для промышленного предприятия с интеграцией SCADA и MES разумно применять OPC UA. Для распределенной телеметрии и IIoT удобен MQTT. На сложном объекте нормальна комбинация всех четырех технологий.
Инженеры KWIK проектируют архитектуру диспетчеризации не от названия протокола, а от задач объекта: определяют уровни системы, состав данных, требования к надежности и кибербезопасности, подбирают шлюзы и контроллеры, разрабатывают правила именования и проверяют интеграцию на стенде.
Если вам нужно объединить разнородное оборудование в единую BMS, SCADA или IIoT-платформу, мы поможем подготовить архитектуру обмена и технические требования к каждому участнику проекта.

Официальные источники