OPC UA Client/Server или PubSub для MES

Передавать данные станков в MES через OPC UA Client/Server стоит тогда, когда MES должен находить теги, читать состояние по запросу, подтвержденно получать изменения и иногда записывать задания. PubSub оправдан, когда один и тот же поток телеметрии нужен нескольким потребителям, число станков растет, а издатель не должен держать отдельное соединение с каждым из них.

Выбор протокольной модели нельзя свести к вопросу «что быстрее». Задержку определяют цикл контроллера, частота выборки, интервал публикации, очередь шлюза, брокер и обработчик MES. Плохая модель данных добавит больше проблем, чем несколько миллисекунд в сети: MES получит число 742 без единицы измерения, времени источника и признака качества и запишет его как достоверный выпуск.

На действующем производстве я чаще выбираю гибрид. Станок или локальный шлюз предоставляет Client/Server для адресного пространства, диагностики и команд, а подготовленные наборы производственных событий отправляет в брокер через PubSub. Но гибрид не должен быть ответом по умолчанию. Сначала надо разделить потоки, проверить возможности конкретного MES и провести испытание на своей сети.

Выбор начинается с операций MES

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

Для периодических значений MES нужен поток с понятными временем источника, статусом качества и идентификатором оборудования. Для события «деталь завершена» нужен уникальный идентификатор, иначе повторная доставка увеличит счетчик выпуска. Для записи задания нужен ответ о результате и проверка, что команда относится к нужному станку и рецепту. Для диагностики инженеру нужны Browse, Read и доступ к структуре адресного пространства, а не только заранее выбранные поля.

Client/Server естественно покрывает адресные операции. Клиент открывает защищенный канал и сеанс, просматривает узлы, читает и пишет атрибуты, вызывает методы, создает MonitoredItem и объединяет их в Subscription. PubSub передает заранее настроенные DataSetMessage. Издатель не знает получателей, а подписчик не обязан знать издателя; между ними работает доставка через UDP или брокер.

Из этого следует первое проектное решение: разделите интерфейс чтения, поток событий и интерфейс команд. Если MES нужен только OEE с минутной агрегацией, прямой сеанс к каждому контроллеру может оказаться лишним. Если диспетчер из MES запускает задание и должен увидеть конкретный код отказа, один поток PubSub не заменит запрос с ответом.

Полезно составить матрицу до выбора продукта:

Последняя строка намеренно не называет победителя. Ни OPC UA Session, ни MQTT QoS сами по себе не мешают MES дважды провести одно производственное событие. Это задача контракта приложения.

Client/Server дает контекст и обратную связь

Client/Server лучше подходит MES, которому нужно исследовать и изменять информационную модель станка, а не только принимать фиксированный набор чисел. OPC UA Part 4 определяет сервисы Browse, Read, Write, Call и подписки; сервер возвращает StatusCode по операциям, поэтому интегратор видит частичный отказ в пакетном запросе, а не гадает по молчанию.

Подписка здесь не равна PubSub. Клиент создает свой Subscription и MonitoredItem, задает интервалы выборки и публикации, фильтр изменения, размер очереди и правило отбрасывания. Сервер хранит состояние для этого клиента. OPC UA Part 14 в сравнительном приложении прямо отмечает, что такая доставка использует буферизацию, подтверждения и повторные передачи, но расходует ресурсы сервера на каждого подключенного клиента.

Это удобно для MES по трем причинам. Во-первых, клиент может при вводе станка выполнить Browse и проверить, что обязательные узлы существуют. Во-вторых, он может прочитать начальное значение перед подпиской или после восстановления. В-третьих, он получает sequence number и может запросить повтор пропущенных NotificationMessage, пока данные остаются в очереди сервера.

Гарантия имеет границы. Обычные очереди часто находятся в памяти, их размер конечен, а длительный разрыв сети или перезапуск сервера может привести к потере. Durable Subscription существует в спецификации, но это отдельная возможность профиля, которую должны поддерживать обе стороны. Нельзя записывать в проект «OPC UA надежен» и считать вопрос закрытым. Надо запросить RevisedQueueSize, revised publishing interval, lifetime и поведение после перезапуска конкретного сервера.

Client/Server также упрощает двустороннюю работу. MES может вызвать метод с аргументами и получить код выполнения либо записать значение с отдельным контролем доступа. Я все равно не разрешаю MES писать напрямую в технологические переменные. Команда должна попадать в выделенный узел или метод, а логика ПЛК проверяет режим, рецепт, межблокировки и повторный идентификатор команды.

Цена этой ясности проявляется при масштабе. Сто станков означают сто защищенных соединений, сеансов, наборов MonitoredItem, таймеров keep-alive и сценариев переподключения. Это нормальная нагрузка для правильно подобранного агрегирующего сервера, но тяжелая для слабого встроенного сервера ЧПУ. Ограничения по числу сеансов и элементов подписки надо измерять, а не выводить из логотипа OPC UA в паспорте.

PubSub отделяет станок от получателей

PubSub лучше масштабирует распространение заранее определенного потока, потому что работа издателя не растет вместе с числом подписчиков. По OPC UA Part 14 Publisher формирует DataSet, WriterGroup задает режим публикации, а DataSetWriter кодирует сообщения. Subscriber получает их через промежуточный транспорт и сопоставляет с DataSetReader.

В варианте UDP UADP станок или шлюз отправляет бинарное сообщение в multicast-группу либо на конкретный адрес. Один пакет могут принять MES, архив, система мониторинга энергии и аналитика. Для локального сегмента с контролируемой сетью это дает предсказуемую нагрузку на издателя и убирает установление сеанса с каждым получателем. Но обычный UDP остается доставкой best effort: пакет может потеряться, прийти не по порядку или повториться после действий промежуточного оборудования.

В брокерном варианте Publisher отправляет UADP или JSON в MQTT-брокер, а потребители подписываются на темы. Брокер отделяет время жизни потребителя от станка, может хранить сообщения по своей конфигурации и раздает один поток нескольким системам. Это удобно, когда MES находится в другом сетевом сегменте или данные нужны сразу нескольким приложениям.

PubSub не дает подписчику произвольно просматривать все адресное пространство. DataSet заранее определяет, какие поля выходят наружу. Если инженер добавил новый код причины простоя, он должен обновить метаданные и контракт потребителя. Эта предсказуемость хороша для эксплуатации, но требует управления версиями.

Минимальный контракт события выпуска может выглядеть так:

{
  "schemaVersion": 3,
  "machineId": "LINE2-LATHE04",
  "eventId": "LINE2-LATHE04-184467",
  "eventType": "PartCompleted",
  "sourceTime": "2026-07-26T14:08:31.482Z",
  "partNo": "A17-442",
  "quantity": 1,
  "quality": "Good"
}

eventId позволяет MES повторно принять сообщение без повторного проведения, schemaVersion отделяет совместимые изменения от несовместимых, а sourceTime не дает подменить время станка временем приема брокером. Поле quality должно происходить из проверяемого состояния источника, а не всегда содержать строку Good.

PubSub стоит выбирать не ради модного брокера, а когда существует стабильный договор о данных. Если состав тегов меняется каждую неделю и интегратору постоянно нужен Browse, сначала стабилизируйте модель через Client/Server или агрегирующий шлюз.

Задержку надо измерять по всей цепочке

Ни одна модель не обещает меньшую задержку без оговорок, потому что сетевой пакет занимает только часть пути от физического сигнала до записи MES. Сигнал сначала попадает в цикл ПЛК или ЧПУ, затем сервер или Publisher выбирает значение, кодирует сообщение, передает его, а потребитель разбирает и фиксирует результат.

Для Client/Server важны sampling interval MonitoredItem и publishing interval Subscription. Спецификация разрешает серверу пересмотреть неподдерживаемый интервал, поэтому запрошенные 10 мс не означают фактические 10 мс. Если источник обновляется раз в 100 мс, опрос сервера каждые 5 мс не создает новые данные. Он лишь добавляет работу.

Для PubSub важны PublishingInterval WriterGroup, режим key frame и delta frame, размер пакета, очередь сетевого интерфейса и транспорт. UDP UADP может убрать брокерный переход. MQTT добавляет брокер и подтверждения выбранного QoS, но может выиграть у плохо настроенных сотен сеансов за счет общей очереди и стабильного fan-out. Сравнение имеет смысл только на одинаковом наборе полей и одинаковой частоте источника.

Я измеряю четыре времени: t_source на станке, t_publish у Publisher или сервера, t_receive на входе интеграционного слоя и t_commit после подтвержденной записи MES. Тогда видны две разные величины:

transport_latency = t_receive - t_publish
end_to_end_latency = t_commit - t_source

Первая показывает сеть и доставку. Вторая показывает то, что чувствует производство. Для сравнения нужны медиана, 95-й и 99-й процентили, максимум, доля потерянных событий и доля дублей. Один средний показатель скрывает паузы сборщика мусора, переподключения и переполнение очереди.

Часы должны быть синхронизированы, иначе отрицательная задержка выглядит как оптимизация. Если станок не поддерживает надежную синхронизацию времени, ставьте отметку на ближайшем шлюзе и честно называйте ее временем наблюдения, а не временем события. Для аварийного останова дополнительно сравните физический вход и журнал ПЛК, иначе тест проверит только красивую часть цепочки.

Для OEE часто достаточно доставки за секунды, но команда или блокировка может иметь иной предел. Не превращайте MES в контур реального времени. Движение осей, защита оператора и быстрые межблокировки должны оставаться в контроллере, где задержка и отказ сети не меняют безопасное состояние оборудования.

Сетевая нагрузка зависит от изменений и получателей

PubSub не всегда создает меньше трафика, а Client/Server не всегда перегружает сеть. Итог зависит от числа полей, частоты изменений, кодирования, служебных заголовков, количества получателей и политики повторной доставки.

Возьмем расчетный пример, а не обещание производительности. Сто станков передают по 200 числовых значений десять раз в секунду. Только полезные 8-байтовые значения дают 1,6 Мбит/с. К ним добавятся идентификаторы, время, StatusCode, заголовки OPC UA, IP и транспорта. JSON заметно увеличит объем по сравнению с бинарным UADP, особенно если каждое поле несет имя.

Client/Server Subscription может отправлять только изменения и упаковывать несколько Notification в одно сообщение. Deadband отсекает шум аналогового сигнала. Если MES остается единственным потребителем и большинство значений меняется редко, такая подписка может быть экономнее периодического полного DataSet.

UDP multicast отправляет один NetworkMessage независимо от числа слушателей в том же домене рассылки. Это сильное преимущество при нескольких получателях, но multicast требует настройки коммутаторов, IGMP snooping, VLAN и правил маршрутизации. Неконтролируемая рассылка способна разнести поток по портам, где он не нужен.

MQTT принимает один поток от Publisher, после чего брокер отправляет отдельные копии подписчикам. Нагрузка на станок остается предсказуемой, но трафик и ресурсы не исчезают, а переходят к брокеру и его исходящим соединениям. QoS 1 и QoS 2 добавляют подтверждения и возможные повторные передачи. Сохранение сообщений требует диска и четкой политики срока хранения.

Считайте трафик на трех участках отдельно: станок - шлюз, шлюз - брокер, брокер - MES. Проверьте штатный режим и восстановление после разрыва. Система, которая спокойно передает 5 Мбит/с, может создать очередь на гигабайты после часа недоступности MES, если никто не ограничил срок жизни и глубину буфера.

Надежность и безопасность не идут в комплекте с названием

Client/Server дает механизмы обнаружения пропусков и повторной передачи NotificationMessage, но надежность сохраняется только пока живы Subscription и очереди. PubSub делегирует свойства доставки транспорту. Поэтому фразы «OPC UA с шифрованием» и «MQTT с exactly once» слишком коротки для технического задания.

Для MQTT OPC UA Part 14 сопоставляет best effort и at most once с QoS 0, at least once с QoS 1, exactly once с QoS 2. QoS 1 допускает дубли. QoS 2 гарантирует обмен с брокером, но не гарантирует, что бизнес-логика MES проведет событие ровно один раз. Если обработчик записал выпуск, а затем упал до фиксации подтверждения, сообщение может вернуться. Уникальный eventId и ограничение уникальности в базе MES закрывают эту дыру лучше громкого названия QoS.

UDP без дополнительного механизма не подтверждает доставку. Для периодической телеметрии потеря одного пакета может быть приемлемой, если скоро придет полное key frame. Для завершения детали или изменения рецепта молчаливую потерю принимать нельзя. Такие события направляют через надежный брокерный транспорт либо дублируют в подтверждаемом интерфейсе.

В Client/Server SecureChannel защищает сообщения между клиентом и сервером, приложения используют сертификаты, а пользователь или приложение проходит аутентификацию согласно настройке. Нужно управлять доверенными списками, сроком сертификатов, закрытыми ключами, отключенными алгоритмами и отзывом доступа. Сертификат, который оператор однажды принял вручную «навсегда», превращает строгую схему доверия в формальность.

В PubSub через MQTT TLS защищает каждый участок до брокера. Брокер видит данные и должен считаться доверенной стороной. Part 14 отдельно предупреждает, что JSON-сообщения полагаются на безопасность MQTT и брокера; сквозная безопасность сообщений определена для UADP. Для подписи и шифрования UADP применяет групповые ключи, которыми управляет Security Key Service. Это добавляет ротацию ключей, группы безопасности и восстановление после истечения ключа.

Практическое правило простое: нарисуйте границы доверия и владельца каждого сертификата или группового ключа. Затем отключите один сертификат, смените ключ, перезапустите брокер и проверьте журнал. Если команда не может объяснить, кто восстанавливает поток и как отличает отказ доверия от сетевого сбоя, безопасность пока существует только на схеме.

Сертификат проверяют по профилю, а MES по интерфейсу

Надпись «OPC UA supported» не подтверждает совместимость нужной модели. OPC UA Part 7 разделяет профили приложений Client, Server, Publisher и Subscriber и добавляет Facet для конкретных функций и транспортов. Сертифицированный Server может не быть Publisher, а сертифицированный Client не обязан принимать MQTT UADP.

OPC Foundation проверяет продукты по заявленным профилям и публикует каталог, где можно фильтровать Client, Server, Publisher, Subscriber, PubSub UDP UADP, MQTT JSON и MQTT UADP. В закупочной спецификации надо указать точный профиль, версию, кодирование, транспорт и функции. Сам логотип сертификата без перечня профилей мало что говорит об интеграции.

У MES запросите не презентацию, а таблицу возможностей. Нужны ответы на конкретные вопросы:

• MES работает как OPC UA Client или требует отдельный коннектор?
• Поддерживает ли он Subscription, очереди, перенос подписки и StatusCode?
• Принимает ли он PubSub напрямую, через MQTT-коннектор или только через API интеграционного слоя?
• Какие кодирования, версии MQTT, QoS, темы и метаданные он понимает?
• Как он хранит source timestamp, quality, sequence number и идентификатор события?

Поддержка MQTT еще не означает поддержку OPC UA PubSub. Обычный MQTT-коннектор может принять JSON, но не распознать структуру OPC UA NetworkMessage, метаданные DataSet и правила совместимости. Обратная ошибка тоже встречается: команда покупает PubSub Publisher, а MES умеет только Client/Server Data Access.

Проверьте и сторону станка. Встроенный OPC UA Server может ограничивать сеансы, MonitoredItem и минимальный интервал. Publisher может поддерживать только UDP UADP, хотя архитектура требует MQTT JSON. Шлюз способен закрыть разрыв, но он становится отдельным активом с конфигурацией, обновлениями, резервированием и сертификатами.

Гибридная схема обычно честнее

Гибрид подходит большинству разнородных цехов, потому что оставляет сильные стороны каждой модели на своем месте. Локальный интеграционный слой подключается к станкам как OPC UA Client, просматривает адресное пространство, нормализует единицы и статусы, а затем публикует устойчивый производственный контракт для MES и других потребителей.

Такая схема не требует, чтобы каждый старый контроллер стал полноценным PubSub Publisher. Она также не заставляет MES держать сотни прямых сеансов через межсетевые экраны. Команды идут обратно по отдельному Client/Server каналу с узкой авторизацией, подтверждением и проверкой в ПЛК. Телеметрия и события идут через PubSub с собственными правилами хранения и повторной обработки.

Цена гибрида реальна. Шлюз добавляет задержку, точку отказа и еще одну модель конфигурации. Если он переводит NodeId ns=4;s=Counter в поле quantity, команда обязана хранить версию сопоставления и журнал изменений. После замены прошивки станка старый NodeId может указывать не туда или исчезнуть, поэтому автоматическая проверка контракта при подключении обязательна.

Для нового проекта зафиксируйте канонические идентификаторы оборудования, единицы, source timestamp, StatusCode, версии схем и правила идемпотентности до выбора транспорта. Затем решите, где живет преобразование: в ЧПУ, промышленном шлюзе или интеграционном сервисе. Не размазывайте одно и то же сопоставление по каждому потребителю.

При подборе станков EAST CNC может уточнить доступные интерфейсы конкретной модели и включить проверку связи в пусконаладочные работы. Но приемку интеграции все равно надо привязать к вашему MES, сетевой схеме и перечню тегов, потому что название протокола не описывает готовый обмен.

Гибрид не нужен, если один MES читает десять станков, адресные пространства стабильны, а прямые подписки проходят испытание с запасом. Он также не спасет плохой контракт данных. Дополнительный брокер лишь быстрее разнесет неоднозначные значения по большему числу систем.

Приемка должна воспроизвести отказ

Решение можно принимать после короткого испытания, которое измеряет рабочую цепочку и намеренно ломает ее. Демонстрация одного тега на стенде подтверждает только то, что два продукта однажды обменялись числом.

1. Зафиксируйте 20-50 реальных полей: быстро меняющиеся значения, редкие состояния, тревогу, счетчик, событие выпуска и одну разрешенную тестовую команду. Для каждого поля задайте тип, единицу, источник времени, допустимую задержку и поведение при плохом качестве.
2. Запустите Client/Server и PubSub на одинаковой частоте источника. Записывайте eventId, sequence number, четыре временные метки, размер сообщения, пропуски, дубли и загрузку процессора на станке или шлюзе.
3. Отключите сеть на 30 секунд, затем на время, превышающее настроенную очередь. Перезапустите клиент, Publisher, брокер и MES по отдельности. Проверьте, какие значения восстановились, какие потерялись и не удвоился ли выпуск.
4. Добавьте второго и третьего потребителя. Для Client/Server смотрите рост сеансов и MonitoredItem; для UDP проверяйте multicast на коммутаторах; для MQTT измеряйте исходящий поток и очередь брокера.
5. Замените сертификат, отзовите учетные данные, измените версию DataSet и удалите один обязательный узел. Система должна выдать понятную ошибку, а не продолжить с нулем вместо неизвестного значения.

Результат удобно хранить в CSV с полями mode,machine,event_id,t_source,t_publish,t_receive,t_commit,bytes,status,duplicate. Один и тот же файл позволяет сравнить процентили задержки, сетевую цену и корректность после восстановления. Приложите к протоколу приемки конфигурацию Subscription или WriterGroup, версии прошивок, профиль OPC UA и настройки QoS. Без них повторить тест через год не получится.

Выберите Client/Server, если MES нужны контекст, адресные операции и прямой ответ от станка, а число соединений укладывается в проверенные пределы. Выберите PubSub для стабильных потоков многим потребителям, когда команда готова владеть брокером или промышленной multicast-сетью и версионировать DataSet. Если нужны оба набора свойств, разделите потоки и оставьте быстрый безопасный контур внутри станка. Окончательное решение должно объясняться результатами отказного теста, а не названием технологии в коммерческом предложении.