OPC UA И MQTT: как оборудование общается с системами
Связующая цепочка: от промышленного оборудования к корпоративным системам
Когда на производстве говорят «подключить станок к системе», за этой простой фразой обычно скрывается целая цепочка.
Между этими уровнями должны существовать понятные правила обмена данными. И здесь часто встречаются два названия: OPC UA и MQTT.
Их иногда ставят рядом как конкурирующие протоколы и задают вопрос: «Что лучше использовать для промышленной автоматизации — OPC UA или MQTT?» Но постановка вопроса не совсем правильная.
Ориентирован на стандартизированное представление промышленной информации, взаимодействие между приложениями и устройствами, доступ к данным, событиям и объектным моделям.
Лёгкий протокол обмена сообщениями по модели publish/subscribe, рассчитанный в том числе на IoT и распределённые системы с ограниченными ресурсами или каналами связи.
Поэтому в промышленной архитектуре они могут не только заменять друг друга в отдельных сценариях, но и работать последовательно в одной системе.
Сначала нужно понять, что именно мы передаём
До выбора протокола полезно разделить две вещи: значение параметра и информацию о том, что это за параметр.
Допустим, от станка пришло:
Для одной системы этого может быть достаточно. Но промышленному приложению может понадобиться знать полный контекст:
- › Оборудование: Токарный станок №7
- › Параметр: Температура шпинделя
- › Значение: 82.4 °C
- › Единица: °C
- › Время: 2026-10-05 10:43:17
- › Статус: Good
- › Качество: Valid
А если речь идёт о сложном оборудовании, то данных становится ещё больше:
├── Шпиндель
│ ├── Скорость
│ ├── Температура
│ └── Нагрузка
│
├── Охлаждение
│ ├── Давление
│ └── Расход
│
└── Производство
├── Заказ
├── Деталь
└── Состояние
И здесь становится понятно, почему промышленный обмен данными — это не просто вопрос «как отправить число из точки А в точку Б».
Важно не только доставить данные, но и сохранить их смысл.
Где находится OPC UA
OPC UA — это не просто способ передать значение переменной.
Стандарт включает механизмы коммуникации, информационного моделирования, безопасности и взаимодействия между клиентами и серверами. OPC Foundation прямо описывает OPC UA как платформонезависимый стандарт для обмена информацией между промышленными устройствами и системами — от устройств и контроллеров до MES и ERP.
В такой модели приложение выступает клиентом, а OPC UA Server предоставляет ему доступ к данным. Причём клиент получает не просто набор адресов.
OPC UA использует адресное пространство и информационные модели, позволяющие представлять структуру объектов, их свойства и взаимосвязи. Это одна из фундаментальных особенностей стандарта.
OPC UA превращает данные оборудования в структурированную информацию
Это особенно важно для промышленной интеграции.
Представим, что у компании 200 станков от нескольких производителей. Без унифицированного подхода один станок может отдавать:
Если система просто получает значения, разработчику приходится отдельно разбираться с каждым источником. OPC UA позволяет построить более абстрактное представление.
Пример абстрактного адресного пространства OPC UA:
├── Identification
│ ├── Manufacturer
│ ├── Model
│ └── SerialNumber
│
├── Spindle
│ ├── Speed
│ ├── Temperature
│ └── Load
│
└── Production
├── CurrentJob
└── Status
Конкретная модель зависит от оборудования и используемых информационных моделей. Но сама идея принципиальна:
Система должна понимать не только значение, но и объект, которому это значение принадлежит.
OPC UA Companion Specifications как раз используются для создания отраслевых и предметных информационных моделей, позволяющих различным системам работать с данными в более согласованном виде.
А где здесь MQTT
MQTT устроен иначе. Его основная модель — publish/subscribe.
- › Есть отправитель сообщения;
- › Есть брокер;
- › Есть подписчики.
Отправитель не обязан знать, какие конкретно приложения получат его данные.
Производственное оборудование или шлюз публикует сообщение в определённый topic:
А подписчики самостоятельно получают интересующие их сообщения. MQTT специально построен как лёгкий publish/subscribe-протокол с небольшими накладными расходами и рассчитан, в том числе, на M2M и IoT-сценарии.
Это делает его особенно интересным там, где данные должны распространяться между большим количеством независимых потребителей.
Почему MQTT удобен для распределённой архитектуры
Представим производство, где данные одного станка нужны сразу нескольким независимым системам.
При прямых интеграциях без использования брокера сообщений пришлось бы строить множество жестких соединений:
│
├─────► MES
│
├─────► Analytics
│
└─────► Cloud
При увеличении числа потребителей архитектура быстро усложняется. Publish/subscribe позволяет полностью отделить производителя данных от конечных потребителей.
Станок или шлюз просто публикует данные в брокер, не заботясь о получателях.
Кому эти данные действительно нужны — тот самостоятельно на них подписывается.
Это одно из главных архитектурных преимуществ MQTT. Стандарт предусматривает разные уровни QoS, позволяющие выбирать гибкий компромисс между гарантией доставки и стоимостью обмена.
Но MQTT не превращает промышленный сигнал в OPC UA-модель
Здесь часто возникает неправильное ожидание.
Если отправить через MQTT обычный сырой JSON:
сам по себе MQTT не знает, что это температура шпинделя. Он не знает:
- - что такое станок;
- - кто производитель;
- - какая единица измерения;
- - где находится оборудование;
- - что означает значение;
- - какие свойства есть у объекта.
MQTT отвечает прежде всего за доставку сообщения между участниками обмена. Смысл сообщения полностью определяется приложением и выбранной моделью данных.
Поэтому архитектура на MQTT требует отдельно продумывать структуру topics, payload, идентификаторы оборудования, версии сообщений, схемы данных и правила совместимости.
Это принципиальная разница
Можно представить архитектурное разделительное позиционирование протоколов следующим образом:
Оба подхода полезны.
Просто они находятся на разных уровнях архитектурной задачи.
Как данные реально доходят от станка до MES
Теперь можно собрать всю цепочку. На практике редко бывает так, что MES напрямую подключается к каждому датчику. Гораздо чаще между оборудованием и верхним уровнем существует несколько слоёв.
Именно gateway часто становится важной точкой архитектуры.
Он может:
- › читать данные с оборудования;
- › преобразовывать форматы;
- › нормализовать значения;
- › буферизовать сообщения;
- › выполнять локальную обработку;
- › передавать данные выше;
- › работать как OPC UA Client;
- › публиковать данные в MQTT;
- › контролировать доступ.
Таким образом, верхний уровень не обязан знать, каким внутренним протоколом разговаривает конкретный станок.
OPC UA и MQTT могут работать вместе
Это один из самых важных моментов. Необязательно выбирать между OPC UA или MQTT.
В этом случае OPC UA используется для работы с промышленным источником, а MQTT — для дальнейшего распространения данных. Это не противоречие. Наоборот, каждый механизм выполняет ту часть работы, для которой он подходит.
OPC UA при этом имеет собственную PubSub-модель и может использовать MQTT как один из механизмов обмена в соответствующих сценариях. OPC Foundation отдельно указывает MQTT среди вариантов, с которыми OPC UA PubSub может быть сопоставлен для интеграции с облачными и аналитическими системами.
А где здесь SCADA
SCADA находится ближе к производственному процессу, чем большинство корпоративных систем.
Ей нужно получать текущие значения:
- › Температура
- › Давление
- › Скорость
- › Состояние
- › Авария
- › Режим работы
Она также может отображать события, тревоги и состояние оборудования. OPC UA для такого взаимодействия естественен, поскольку стандарт предусматривает не только доступ к значениям, но и механизмы работы с событиями, историческими данными и структурированными моделями информации.
Но MQTT тоже может присутствовать в SCADA-контуре — особенно если система построена вокруг брокера сообщений и подписок.
Поэтому вопрос не в том, какой протокол «разрешён для SCADA».
Вопрос заключается исключительно в архитектуре конкретного предприятия.
А MES решает уже другую задачу
MES не просто показывает температуру. Ему нужно связать технологические данные с производственным контекстом.
Теперь простое абстрактное значение temperature = 82.4 может трансформироваться в полноценную запись бизнес-контекста:
Партия №B-102
Операция №17
Станок №7
Температура шпинделя: 82.4 °C
Время: 10:43:17
Именно здесь промышленная интеграция перестаёт быть простой передачей телеметрии.
Данные оборудования начинают связываться с бизнес-контекстом производства.
Почему нельзя просто подключить MES напрямую к каждому станку
На маленьком производстве это иногда возможно. Но по мере роста оборудования появляется проблема масштабирования интеграций.
Представим реальный масштаб промышленного узла:
5 производителей
3 PLC-платформы
2 SCADA
1 MES
1 ERP
Если каждый компонент знает специфику каждого оборудования, количество зависимостей начинает быстро расти:
А если завтра появляется новое оборудование? MES должен знать, как с ним работать. Без абстракции система становится хрупкой.
При использовании промежуточного шлюзового слоя:
специфика нижнего уровня остаётся ближе к производственному контуру. Это кардинально снижает связанность систем.
Но gateway не должен превращаться в «свалку логики»
Это тоже распространённая ошибка. В шлюз постепенно начинают складывать разнородные задачи:
- - преобразование протоколов;
- - бизнес-правила;
- - расчёты;
- - маршрутизацию;
- - хранение;
- - преобразование справочников;
- - логику MES;
- - логику ERP.
В результате получается огромный промышленный монолит. Правильнее разделять ответственность.
Gateway должен помогать системам взаимодействовать, а не незаметно становиться новой системой управления производством.
Что происходит при потере связи
Промышленная сеть не всегда идеальна. И это нужно учитывать ещё на этапе архитектуры.
Может исчезнуть связь по всей цепочке передачи данных:
└── сервер
└── центральная система
Если связь пропала на две минуты, правильная архитектура шлюза реализует локальное буферизованное накопление:
Это особенно важно для производственных данных, где потеря нескольких минут телеметрии может безвозвратно испортить всю историю технологического процесса.
MQTT имеет механизмы сессий и QoS, позволяющие выбирать разные гарантии доставки сообщений; при этом конкретная надёжность системы всё равно определяется всей архитектурой, а не одной настройкой протокола.
QoS в MQTT — не просто «включить надёжность»
У MQTT есть три уровня QoS:
QoS 0
At most once
QoS 1
At least once
QoS 2
Exactly once
Они дают разные гарантии доставки. При QoS 1 возможны повторные сообщения, тогда как QoS 2 обеспечивает более строгую семантику доставки. Это важно понимать в промышленной системе.
Например, для частой телеметрии:
temperature = 71.3
temperature = 71.4
temperature = 71.5
потеря одного промежуточного значения может быть приемлемой, если следующее значение появится через короткое время.
требования совсем другие.
Нельзя просто сказать: «Для всего поставим максимальный QoS». У каждого потока данных должна быть своя семантика.
Данные и команды — не одно и то же
Это ещё один принципиальный момент. Важно разделять чтение состояния и выдачу управляющих воздействий:
Телеметрия обычно движется от оборудования к системам мониторинга и несет минимальный риск.
Команда может менять состояние физического процесса — это критическая операция.
Поэтому архитектура управления должна отдельно учитывать:
- › права доступа;
- › аутентификацию;
- › авторизацию;
- › безопасность;
- › подтверждение операции;
- › аудит;
- › отказоустойчивость.
OPC UA включает механизмы безопасности, аутентификации, шифрования, подписи сообщений и контроля доступа.
Но наличие защищённого протокола не означает автоматически безопасную промышленную систему.
Безопасность всегда определяется всей цепочкой.
Где заканчивается протокол и начинается архитектура
Очень легко переоценить значение протокола. Допустим, компания использует OPC UA — это ещё не означает, что данные качественные.
Можно построить прекрасное соединение и передавать:
Но если никто не знает, что скрывается за этой цифрой:
- - это реальное значение или ошибка;
- - датчик отключён или действительно показывает ноль;
- - какая единица измерения;
- - когда измерение получено;
- - насколько актуальны данные,
то технически корректная передача не делает информацию пригодной для бизнеса.
Поэтому промышленная интеграция имеет несколько иерархических уровней:
OPC UA может закрывать значительную часть первых уровней и предоставляет развитую модель информации. MQTT отлично решает задачу транспортировки сообщений и распределения данных.
Но ни один протокол сам по себе не строит правильную производственную модель.
Как выбрать между OPC UA и MQTT
Не стоит начинать с вопроса:
«Какой протокол лучше?»
Нужно спросить: «Что именно происходит с данными после того, как они появились на оборудовании?»
Выбирайте OPC UA, если требуется:
- • работать со структурированной моделью оборудования;
- • обнаруживать новые объекты и свойства на лету;
- • получать данные через синхронную клиент-серверную модель;
- • обрабатывать сложные промышленные события;
- • бесшовно интегрировать оборудование с классическими промышленными приложениями.
Выбирайте MQTT, если требуется:
- • распределять сообщения между большим количеством независимых потребителей;
- • полностью изолировать и отделить отправителей от получателей;
- • организовать сквозной асинхронный обмен через центральный брокер;
- • передавать данные по лёгкому, экономящему трафик publish/subscribe-механизму.
А если нужны оба сценария, совершенно нормально использовать оба.
Упрощённое сравнение
Но такую таблицу нельзя превращать в рейтинг.
Она лишь показывает, какую проблему каждый механизм решает непосредственно.
Как это выглядит на реальном предприятии
Представим производство с несколькими цехами.
Это не единственная возможная архитектура.
Но она наглядно показывает важную идею:
промышленный обмен данными — это цепочка уровней, а не один протокол между конкретным станком и ERP.
Самая частая ошибка — выбирать технологию раньше архитектуры
Иногда проект начинается с безальтернативного выбора конкретного инструмента:
«Нам нужен MQTT».
«У нас всё должно быть на OPC UA».
Но это всё равно что начинать строительство здания с выбора типа двери.
Сначала нужно определить базовые параметры системы:
- › какие данные появляются;
- › где они формируются;
- › кто является источником истины;
- › кто их потребляет;
- › насколько быстро они нужны;
- › допустима ли потеря отдельных сообщений;
- › нужна ли история;
- › нужны ли команды;
- › сколько потребителей будет;
- › что происходит при обрыве связи;
- › как обеспечивается безопасность;
- › где должна находиться логика преобразования.
И только после этого выбирать протоколы и компоненты.
Почему OPC UA и MQTT часто оказываются не конкурентами
Если посмотреть на промышленную систему целиком, становится видна сквозная синергия технологий:
В такой архитектуре вопрос: «OPC UA или MQTT?» вообще теряет смысл.
Может отвечать за структурированное представление, семантическое описание и надежное получение промышленной информации.
Может отвечать за сквозную асинхронную транспортировку и распределение сообщений между независимыми ИТ-системами.
Дальше MES связывает эти данные с производственным контекстом, аналитическая система строит историю и показатели, а корпоративные приложения используют уже готовое бизнес-представление информации.
И всё начинается не с протокола
Самая важная задача промышленной интеграции — не заставить оборудование «говорить по OPC UA» или «публиковать MQTT-сообщения».
Нужно построить управляемый поток информации от физического процесса до бизнес-системы.
На каждом инженерном переходе есть свой критический вопрос:
- › Данные получены?
- › Они корректны?
- › Понятно, что они означают?
- › Не потерялись ли они?
- › Можно ли восстановить связь?
- › Имеет ли потребитель право их видеть или изменять?
- › Можно ли связать значение с конкретным заказом, операцией или партией?
Только когда на эти вопросы есть системные ответы, интеграция становится промышленной системой,
а не просто базовым сетевым соединением.
Главное
OPC UA и MQTT не стоит рассматривать как два взаимоисключающих стандарта, между которыми нужно выбрать победителя.
Прежде всего помогает стандартизировать взаимодействие с промышленной информацией и представить данные оборудования в структурированной модели.
Решает задачу лёгкого и распределённого асинхронного обмена сообщениями по классической модели publish/subscribe.
Поэтому на одном предприятии вполне может быть выстроена сквозная цепочка:
А на другом — достаточно только одного из этих механизмов или вообще потребуется другой набор технологий. Правильная архитектура определяется не популярностью протокола.
Она определяется тем, какие данные возникают на производстве, какой смысл они несут, кому они нужны и что должно произойти с ними после получения.
Именно поэтому промышленную интеграцию лучше начинать не с вопроса «OPC UA или MQTT?», а с карты движения данных:
от какого оборудования появляется информация → через какой слой она проходит → как сохраняется её смысл → кто её потребляет → что происходит при сбое связи → и где эта информация превращается в решение для производства.
Когда эта цепочка спроектирована правильно, выбор конкретного протокола становится уже не спором о технологиях, а инженерным следствием архитектуры.
API, Webhook или очередь сообщений?
Когда API есть, а интеграция всё равно не работает
Как соединить производство и корпоративные системы
Все инженерные материалы и экспертные статьи
Полный алфавитный справочник ИТ-терминов
🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.
Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).
Автоматизация бизнеса и ИИ-решения под ключ
Самозанятый Скопец Антон Викторович ИНН 741709260870