OPC UA и MQTT часто сравнивают так, будто это два конкурирующих протокола на одну вакансию. Один должен победить, второй уйти со сцены, а инженер наконец-то получит простой ответ. В реальном цехе все работает иначе. OPC UA и MQTT закрывают разные части задачи, и вопрос обычно не в том, “что лучше вообще”, а в том, какие данные вы передаете, кому они нужны, как быстро, с каким качеством и кто потом отвечает за смысл этих данных.
Если нужно дать SCADA, HMI, шлюзу или MES структурированный доступ к текущим параметрам оборудования, OPC UA часто выглядит естественно. У него есть модель узлов, типы данных, качество, права доступа, сертификаты, подписки, дерево оборудования. Это удобно, когда верхняя система должна понимать не только значение 72.4, но и что это температура конкретной зоны, в градусах, с определенным статусом качества.
MQTT сильнее там, где данные должны распространяться как события: появилось новое значение, изменилось состояние, узел пропал, шлюз восстановил связь, сервису аналитики нужно подписаться на поток без прямого подключения к каждому PLC/SCADA. В связке со Sparkplug он становится более промышленным: появляется дисциплина имен, состояние узлов, birth/death-сообщения и понятная структура публикаций. Но MQTT сам по себе не превращает поток сообщений в отчет, MES или качественную модель производства.
Эта статья не про настройку endpoint, broker, сертификатов или payload. Для базовой логики OPC UA можно отдельно посмотреть материал «OPC UA для инженера АСУ ТП», а для MQTT - статью про MQTT Sparkplug на производстве. Здесь разберем практический выбор: данные цеха, отчеты, historian, MES, облако и ответственность за то, чему потом будут верить технолог, смена и руководитель производства.
Короткий ответ
OPC UA чаще подходит как аккуратный промышленный доступ к текущим данным и модели оборудования. Он хорош для SCADA, локальных интеграций, чтения состояния, передачи структуры объекта, подписки на значения и контролируемого доступа к данным нижнего уровня.
MQTT чаще подходит как событийный транспорт и IIoT-слой. Он хорош, когда данные нужно развести нескольким потребителям, отправить через брокер, пережить нестабильную связь через edge-буфер, подключить аналитику, облако или корпоративные сервисы без каскада прямых соединений к цеху.
Historian или MES нужны там, где появляется память, период, производственная сущность и ответственность за отчет. Если вопрос звучит “что сейчас?”, OPC UA или MQTT могут дать ответ напрямую. Если вопрос звучит “что было за смену, партию, простой или спорный интервал?”, нужен слой, который хранит историю, качество, метки времени и контекст.
OPC UA: когда важна модель, а не просто поток
Сила OPC UA не в том, что он “современнее старых протоколов”. Его сила в том, что данные можно отдать как осмысленную модель. В хорошей OPC UA-структуре параметр не болтается одинокой переменной с техническим именем. Он живет в дереве оборудования, имеет тип, может иметь единицы измерения, описание, права доступа и качество.
Для цеховой интеграции это важно. Когда SCADA или MES получает данные через OPC UA, меньше шансов перепутать счетчик с уставкой, статус с аварией, внутреннюю переменную с производственным параметром. Конечно, OPC UA не спасет от плохого нейминга и хаотичной публикации “всех переменных проекта”. Но он дает удобный каркас, в котором инженер может навести порядок.
OPC UA особенно уместен там, где верхней системе нужно читать текущие значения, подписываться на изменения, видеть качество тега и работать с объектной структурой оборудования. Например, SCADA забирает состояния насосов, текущие температуры, готовность линии, активный рецепт, аварийные признаки и диагностические параметры. В таком контуре OPC UA выглядит понятно: есть сервер, есть клиенты, есть правила доступа, есть модель.
Но у этого подхода есть граница. OPC UA хорошо отвечает на вопрос “что сейчас доступно на источнике”. Он не обязан сам хранить историю смены, восстанавливать потерянные данные за период, считать простой по классификатору причин или связывать параметры с партией. Это уже работа historian, SQL-модели, MES или отчетного слоя.
MQTT: когда важна доставка событий и подключение потребителей
MQTT устроен иначе. Его естественная логика - публикация и подписка через брокер. Источник публикует сообщение, потребители подписываются на нужные темы. Если завтра появляется новый сервис аналитики, ему не обязательно лезть напрямую в каждый контроллер или OPC UA-сервер. Он подключается к брокеру и читает свой поток.
Для распределенных производств, IIoT-шлюзов, удаленных участков, облачной аналитики и Unified Namespace-подхода это удобно. MQTT снижает количество point-to-point связей. Вместо десятков прямых интеграций “система к системе” появляется слой, через который данные можно распространять более управляемо.
Но здесь есть важная оговорка: MQTT - это транспортная идея, а не готовая производственная семантика. Если просто публиковать line1/temp/value, temp2, AI_37 и state_old, получится тот же теговый хаос, только через брокер. Поэтому в промышленности часто обсуждают Sparkplug: он добавляет правила структуры, состояние узлов, birth/death-сообщения и более дисциплинированную модель обмена.
MQTT хорошо работает там, где значение должно доехать событием, где потребителей много, где связь может быть нестабильной, где edge-узел может временно буферизовать данные и догрузить их позже. Но если потом нужен сменный отчет, отчет по партии или расчет OEE, MQTT-поток сам по себе не решает вопрос владения данными. Кто подтвердил партию? Где хранится качество? Какая метка времени считается главной? Что делать с дублями после восстановления связи? Эти правила должны жить выше транспортного слоя.
Качество тега: не мелочь, а часть смысла
В производственных данных значение без качества опасно. 85.2 может означать нормальную температуру, последнее замороженное значение перед потерей связи, ошибку датчика, ручной ввод, симуляцию, замещенное значение или результат после фильтрации. Для оператора на экране это может выглядеть одинаково. Для отчета это разные ситуации.
OPC UA в этой части удобен тем, что понятие качества встроено в модель обмена. Клиент может получить не только значение, но и статус качества. Это не значит, что все автоматически станет хорошо. Потребитель должен учитывать качество, показывать его, писать в архив и не смешивать достоверные и недостоверные интервалы в одну уверенную среднюю.
В MQTT качество тоже можно и нужно передавать, но его нужно явно заложить в payload и правила модели. Если команда публикует только значение и timestamp, а статус качества “потом добавим”, она почти гарантированно получит красивые, но спорные отчеты. Особенно после аварий, потери связи и ручных режимов.
Главное правило простое: для данных, которые попадут в отчет, качество должно быть не украшением, а обязательной частью записи. Иначе система будет честно хранить то, чему нельзя доверять.
Метка времени: время источника или время получения
Вторая больная тема - timestamp. В цеховых интеграциях часто смешивают три разных времени: когда значение появилось на источнике, когда шлюз его получил и когда верхняя система записала его в базу. Пока все работает стабильно и задержки малы, разница незаметна. Как только связь начинает пропадать, эта разница превращается в источник споров.
Для оперативной мнемосхемы обычно достаточно свежего значения. Оператору важно видеть актуальное состояние. Но для отчета по смене или партии важно другое: когда событие реально произошло. Если насос остановился в 07:58, а сообщение доехало в 08:04 после восстановления связи, отчет должен понимать, к какой смене относится событие.
OPC UA может передавать source timestamp и server timestamp. MQTT-сообщение тоже может нести время источника, но это нужно явно согласовать. Edge-шлюз должен не просто отправлять “когда смог”, а сохранять момент происхождения значения. Historian должен хранить это время и качество, а отчет должен использовать правильную временную ось.
Именно поэтому в задачах отчетности вопрос “OPC UA или MQTT?” вторичен. Главный вопрос - есть ли у данных надежная метка времени источника и не теряется ли она по дороге.
Буферизация: где переживаем потерю связи
Если данные нужны только для текущего экрана, кратковременная потеря связи неприятна, но часто не критична. Связь восстановилась, экран снова показывает состояние. Если данные нужны для отчета, учета, качества или расследования, потеря связи уже означает дыру в истории.
MQTT-архитектура часто выигрывает там, где есть edge-узел с локальным буфером: данные собираются рядом с оборудованием, временно хранятся при потере внешнего канала и догружаются после восстановления связи. Это удобно для удаленных объектов, распределенных линий и облачных интеграций.
Но буферизация не является магией MQTT. Ее нужно проектировать: сколько хранить, что делать при переполнении, как не задвоить сообщения, как отмечать задержанную доставку, как передавать качество, как восстанавливать порядок событий. Без этих правил брокер может доставить поток, но отчет все равно останется спорным.
OPC UA тоже может быть частью устойчивой архитектуры, если данные сначала пишутся в локальный historian или сборщик, а уже потом используются для отчетов. Прямое чтение текущих тегов через OPC UA не заменяет память. Об этом мы отдельно говорили в статье «Отчеты из АСУ ТП через OPC UA: когда хватит тега, а когда нужен архив».
Отчеты: почему протокол не должен быть владельцем отчета
Сменный отчет, отчет по партии, отчет по качеству и отчет по простою живут не на уровне протокола. Они живут на уровне производственной логики. Им нужны интервалы, смены, партии, статусы, причины, подтверждения, классификаторы, права на корректировку и понятный владелец данных.
OPC UA может дать текущие теги. MQTT может доставить события. Historian может сохранить временные ряды. MES может связать данные с заказом, партией, рецептом, бригадой и качеством. Если заставить один слой делать работу всех остальных, архитектура быстро станет хрупкой.
Типичная ошибка - строить сменный отчет прямым опросом OPC UA “в момент формирования”. Такой отчет показывает не историю смены, а состояние системы на момент запроса плюс куски того, что успели накопить. Вторая ошибка - отправить все через MQTT в корпоративную базу и считать, что теперь MES сам разберется. MES не должен быть мусорным баком для сырых тегов без качества, времени и контекста.
Для отчетов правильнее мыслить так: протокол доставляет, historian хранит технологическую историю, MES или отчетная модель связывает данные с производственными сущностями. Иногда все это реализовано в одном продукте, иногда в нескольких. Но роли все равно должны быть разделены.
Облако и корпоративная аналитика
Когда в разговоре появляется облако, MQTT часто выглядит привлекательнее. Брокерная модель, публикация событий, edge-сборщики, буферизация и подписчики хорошо ложатся на корпоративную аналитику и IIoT-сценарии. Можно отдавать наверх не весь нижний уровень, а подготовленный поток: статусы, агрегаты, события, KPI, диагностические признаки.
Но здесь особенно важно не тащить облако напрямую в управление. Облако может анализировать, сравнивать, предсказывать, строить отчеты, помогать обслуживанию. Оно не должно становиться неявным владельцем исполнительной логики, если это не предусмотрено архитектурой безопасности и регламентами. Нижний уровень должен оставаться предсказуемым, даже если внешний канал недоступен.
OPC UA в облачную архитектуру тоже попадает, но обычно через шлюз, edge-сервис или промежуточный слой. Он может быть источником структурированных данных на площадке, а MQTT - способом доставить отобранные данные дальше. Такой гибрид часто устойчивее, чем попытка выбрать “один протокол на все случаи”.
Кто владелец данных
Самая недооцененная часть интеграции - ownership. Кто владеет тегом “линия в работе”? ПЛК, SCADA, MES, шлюз, отчетный сервис? Кто имеет право поменять смысл статуса? Где хранится справочник причин простоя? Кто отвечает за качество данных после замены датчика? Кто подтверждает ручную корректировку?
Если на эти вопросы нет ответа, OPC UA и MQTT будут только разными способами распространить неопределенность. Нижний уровень отдаст сигнал, верхний уровень его прочитает, аналитика построит график, а при споре выяснится, что никто не знает, чему именно соответствовал тег в тот день.
Хорошая архитектура данных начинается с простых договоренностей. ПЛК владеет технологическим фактом и безопасным управлением. SCADA владеет оперативным отображением, авариями и журналом оператора. Historian владеет временной историей. MES владеет производственными сущностями: заказ, партия, смена, качество, маршрут, статус выполнения. MQTT-брокер или OPC UA-сервер не должны становиться “серой зоной”, где смысл данных меняется без владельца.
Таблица выбора: задача -> OPC UA / MQTT / historian или MES
Таблица не говорит “берите только OPC UA” или “берите только MQTT”. Она показывает другое: протокол выбирают под роль. Если роль не определена, спор о протоколе будет бесконечным.
Практичный сценарий для предприятия
На большинстве площадок разумный путь выглядит гибридно. На уровне оборудования и локальной интеграции используется OPC UA: аккуратная модель, доступ к текущим значениям, качество, подписки, безопасность. Рядом или выше появляется MQTT/Sparkplug-контур: он забирает отобранные данные, события и агрегаты, публикует их через брокер и дает доступ нескольким потребителям.
Данные, которые нужны для отчетов и расследований, пишутся в historian. Данные, которые относятся к партии, заказу, качеству и смене, связываются в MES или отчетной SQL-модели. Облако получает не хаотичный поток сырых тегов, а подготовленные события, агрегаты и исторические выборки с понятным происхождением.
Такой подход не самый эффектный на презентации, зато самый живучий. Он признает, что у цеха есть текущая оперативная реальность, у отчетов есть память, у MES есть производственный контекст, а у аналитики есть потребность читать данные без вмешательства в управление.
Типовые ошибки выбора
Первая ошибка - выбирать протокол по привычке. “У нас всегда OPC UA” или “сейчас все делают MQTT” не являются инженерными критериями. Критерий - задача данных.
Вторая ошибка - путать транспорт и источник истины. Если MQTT доставил сообщение, это еще не значит, что сообщение стало правильным производственным фактом. Если OPC UA отдал тег, это еще не значит, что тег можно без проверки положить в отчет.
Третья ошибка - забывать про качество и timestamp. Без них красивый поток данных превращается в спорный набор чисел.
Четвертая ошибка - строить отчеты без historian. Прямой доступ к текущему тегу удобен, но он не заменяет историю за период.
Пятая ошибка - отдавать MES слишком сырые данные. MES должен работать с производственными сущностями, а не разбираться в каждом шумном аналоговом теге.
Шестая ошибка - не назначать владельцев. Если никто не отвечает за модель данных, она постепенно превращается в склад исторических компромиссов.
Что спросить до выбора
Перед тем как писать в ТЗ “интеграция по OPC UA” или “интеграция по MQTT”, полезно собрать короткий разговор между АСУ ТП, ИТ, эксплуатацией и производством.
Какие данные нужны: текущие значения, события, архив, партии, качество, KPI? Кто потребитель: SCADA, MES, отчетный сервис, аналитика, облако, обслуживание? Нужна ли история при потере связи? Где хранится качество тега? Какая метка времени считается главной? Кто владелец модели оборудования? Кто имеет право менять состав тегов и смысл статусов? Что будет, если брокер, OPC UA-сервер или внешний канал недоступен?
После этих вопросов выбор обычно становится спокойнее. Где нужна модель и текущий промышленный доступ - берите OPC UA. Где нужен событийный поток и много потребителей - смотрите в сторону MQTT/Sparkplug. Где нужен отчет за период - проектируйте historian, SQL или MES. И не заставляйте протокол быть тем, чем он не является.
Итог
OPC UA и MQTT не надо сталкивать как две команды на поле. OPC UA хорош как структурированный доступ к текущим данным и модели оборудования. MQTT хорош как событийная доставка, IIoT-слой и способ подключать новых потребителей через брокер. Historian и MES нужны там, где появляется память, период, партия, качество и ответственность за отчет.
Если выбираете протокол для цеха, начните не с названия технологии, а с карты данных. Что является текущим состоянием, что является событием, что должно храниться, что попадет в отчет, что уйдет в MES, что можно отправить в облако, а что должно остаться на нижнем уровне. Тогда OPC UA и MQTT перестают спорить друг с другом и начинают работать каждый на своем месте.
Главная мысль простая: протокол доставляет данные, но не делает их автоматически достоверными, историчными и производственно осмысленными. За это отвечает архитектура.
Обсуждение