На новом объекте 2026 года в спецификации связи появляется строка «OPC UA, предпочтительно Pub/Sub». Поставщик SCADA кивает: подписки, меньше опроса, современный стек. Наладчик открывает файрвол: UDP multicast «как в брошюре» режется политикой ИБ, MQTT-транспорт Pub/Sub требует брокера, которого в ОТ-сегменте нет, а запись уставок с локальной панели всё равно идёт сессией Client/Server. Пусковая неделя уходит на то, чтобы вернуть опрос там, где он закрывает задачу, и оставить публикацию там, где потребителей много. Режим выбирают не по году на календаре, а по нагрузке, диагностике и праву писать.
Разбираем, чем OPC UA Pub/Sub отличается от Client/Server на живом объекте: нагрузка опросом против подписки и публикации, транспорт UDP и MQTT, файрвол, брокеры, диагностика «почему тег замер». Отдельно - когда Client/Server остаётся правильным выбором: уставки, точечный HMI, методы, сессии с сертификатом. Не повторяем базовый запуск OPC UA и не подменяем статью про MQTT как шину завода - здесь угол именно два режима OPC UA на новом объекте.
Client/Server в OPC UA - сессия между клиентом и сервером: создание подписки, контролируемые элементы, запись, методы, диагностика сессии. Нагрузка зависит от числа клиентов и интервалов publishing/sampling. Для диспетчерской, локальной панели и записи уставок это по-прежнему основной режим на новых объектах 2026 года.
Pub/Sub - публикация набора данных в сеть без обязательной сессии с каждым потребителем. Транспорт на практике: UDP (часто multicast/brokerless) или MQTT. Выигрыш - fan-out и разгрузка сервера от десятка одинаковых опросов. Цена - сложнее диагностика, другая дыра в файрволе, при MQTT снова появляется брокер, при UDP - шторм и «тишина» без статусов сессии.
На новый объект ставят гибрид, а не религию. Процесс и команды - Client/Server. Массовая телеметрия на MES, архив, несколько SCADA-клиентов с одним и тем же набором - Pub/Sub, если сеть, ИБ и диагностика это пережили на FAT. Если потребителя два и нужна запись - Pub/Sub не закладывают «для галочки 2026».
Классический OPC UA, с которого начинают почти все пуски, - сервер с адресным пространством и клиенты с сессиями. Клиент открывает защищённый канал, создаёт подписку, указывает sampling interval и publishing interval, получает notification с данными и статусом. Запись узла - Write. Вызов программы на сервере - Method. Диагностика живёт в серверных объектах: количество сессий, таймауты, rejected.
Это не «опрос как Modbus каждые 200 мс любой ценой». Подписка OPC UA уже умеет слать по изменению и keep-alive. Путают термины: «опрос» в разговоре наладчика часто значит Client/Server целиком, хотя внутри может быть нормальная подписка. Нагрузка растёт, когда десять клиентов каждый строит свои monitored items на одну тысячу тегов, когда sampling слишком частый, когда сервер на слабом контроллере ещё и крутит цикл технологии.
Запуск OPC UA закрывает модель, сертификаты и типичный хаос первого подключения. Режим Pub/Sub поверх этого не отменяет PKI и справочник узлов. Он меняет, как байты едут по сети и кто является «сессией».
Client/Server хорошо ложится на привычки АСУ: точечный клиент панели, инженерный UA Expert, SCADA как главный клиент, понятный обрыв - сессия умерла, Bad Quality, переподключение. Файрвол открывает TCP 4840 (или выбранный порт) между известными узлами. Для ИБ это белый список пар, а не «весь UDP цеха».
Спецификация OPC UA Part 14 описывает публикацию DataSet: Writer на стороне источника формирует кадры, Reader на стороне потребителя их разбирает, в кадре есть метаданные или идентификаторы наборов. Транспорты в реальных стеках 2026 года, с которыми сталкивается интегратор:
UDP UADP. Часто multicast. Без брокера. Хорошо для локального сегмента с управляемыми коммутаторами, IGMP, известным TTL. Плохо через NAT, через «глупый» файрвол, через Wi-Fi цеха, через маршрутизатор без multicast routing.
MQTT. Pub/Sub OPC UA едет топиками брокера. Появляется единая точка и все её свойства: ACL, TLS, очереди, retain как отдельный разговор. Это уже не «убрали сессии, стало проще» - брокер нужно паспортизовать.
Другие брокерные варианты (AMQP и прочие) на среднем заводе встречаются реже; если вендор настаивает, в ТЗ фиксируют изделие, версию и кто его обслуживает.
Важно: Pub/Sub не заменяет адресное пространство. Кто-то всё равно должен описать DataSet, масштабы, идентификаторы. Метаданные расходятся отдельно (часто всё тем же Client/Server) или зашиваются. На пуске половина «не работает Pub/Sub» - это несовпавшие DataSetWriterId и устаревшие метаданные после смены проекта.
Pub/Sub не даёт магическую запись уставок «как в сессии, только легче». Команды можно уложить в отдельный DataSet, но семантика подтверждения, прав и аудита беднее, чем Write в сессии. Поэтому панели и ключи «местное/дистанционное» оставляют на Client/Server.
Считать нужно оба конца.
Сервер Client/Server страдает от числа сессий и monitored items. Второй клиент SCADA «для технолога», третий - MES, четвёртый - подрядчик с UA Expert на ночь, пятый - резервный сервер архива. Каждый хочет свой интервал. Контроллер с встроенным UA-сервером начинает пропускать цикл. Лечение: вынести UA-сервер на шлюз, урезать набор, согласовать интервалы, запретить «ещё один клиент с полным деревом». Pub/Sub здесь помогает, если много читателей одного и того же: сервер пишет в сеть один раз.
Сеть Pub/Sub страдает от частоты и ширины кадра. Публикация 2000 аналогов каждые 50 мс multicast на весь VLAN - уже не разгрузка, а шторм. Коммутаторы без IGMP snooping размножают это во все порты, включая линию, где живёт полевая шина на Ethernet. Тогда «современный Pub/Sub» виноват в джиттере привода, хотя привод на другом протоколе.
Правило размера то же, что для MQTT-телеметрии и для группировки Modbus: наверх не копируют цикл ПЛК. DataSet делят: быстрые дискреты аварий отдельно и редко подтверждаемым heartbeat, медленные аналоги отдельно, рецепты не в UDP вовсе.
Keep-alive / watchdog публикации обязательны. Без них потребитель не отличает «ничего не изменилось» от «writer умер». В Client/Server это делает сессия. В Pub/Sub это нужно спроектировать: ключевой кадр, счётчик, timeout Reader.
В Client/Server наладчик смотрит сессию, статус безопасности, subscription keepalive, ServiceFault, логи сервера. Инструмент привычный. Обрыв кабеля даёт Bad, переподключение видно по счётчикам.
В Pub/Sub обрыв выглядит как отсутствие кадров. Reader молчит или держит last value - зависит от стека. Нет сессии - нет привычного дерева диагностики. Нужны: счётчик принятых кадров, время последнего кадра, статус DataSet, зеркало IGMP, на MQTT - очередь брокера и ACL.
Wireshark на UDP UADP полезен тем, кто умеет фильтр и не пугается бинарного кадра. На MQTT - топики и payload, плюс знание, как OPC UA упаковал DataSet. Подрядчик, который на SAT не может показать «writer шлёт, reader не в той группе multicast», будет спорить со сменой до утра.
Сертификаты в Pub/Sub (signing/encryption сообщений) настраиваются иначе, чем Endpoint Client/Server. Частая ошибка: TCP 4840 защитили, UDP оставили открытым «это же только телеметрия». Телеметрия уставок и состояний блокировок - не картинка для дашборда. Политика должна быть явной: что шифруем, чем ключуемся, как ротируем.
ИБ на новых объектах 2026 года чаще режет multicast по умолчанию, чем «не понимает OPC». Заявка «откройте UDP диапазон» без списка writer/reader, без IGMP, без ограничения VLAN проваливается - и правильно.
Для Client/Server заявка проще: TCP, известные IP панели, SCADA, шлюза. Для UDP Pub/Sub: VLAN процесса, multicast-группа, порт, IGMP querier на коммутаторе, запрет ухода multicast в MES-VLAN без шлюза. Для MQTT-транспорта: TCP к брокеру, не «весь цех друг на друга».
Публикация через брокер в DMZ часто единственный способ удовлетворить и ИБ, и MES. Тогда Pub/Sub OPC UA по MQTT и «просто MQTT JSON» начинают путать в переписке. В ТЗ пишут стек целиком: OPC UA Pub/Sub over MQTT, версия, Sparkplug это или нет (обычно нет: это другой контракт). Смешивать Sparkplug-метрики и UA DataSet в одном топике «чтобы брокер один» - путь к двум мёртвым интеграциям.
Локальный HMI в шкафу не должен ходить в брокер в соседнем здании, чтобы показать давление. Панель - Client/Server к ближайшему серверу. Иначе отказ брокера гасит и диспетчерскую, и местное управление взглядом, хотя цикл ПЛК жив.
Новый объект - не обязанность включить Part 14.
Запись уставок, режимов, квитирование. Нужны права, аудит, отказ с кодом. Write в сессии это умеет. Кадр Pub/Sub - «отправили в эфир».
Точечный HMI. Одна панель, один сервер, сто тегов. Pub/Sub не окупает IGMP и метаданные. Иерархия экранов и аварии живут от понятного качества тега, а не от multicast.
Методы, файлы, загрузка рецепта пакетом. Это сессионные сервисы.
Инженерный доступ. UA Expert, диагностика, принудительные, просмотр дерева. Только Client/Server.
Мало потребителей. Два клиента не создадут проблему нагрузки, которую надо лечить публикацией.
Сеть не готова. Нет IGMP, нет людей, кто чинит multicast, MQTT-брокер не заложен в ЗИП.
КИИ и жёсткий белый список TCP. Проще защитить сессии, чем подписывать UDP-поток и доказывать аудитору схему ключей.
В этих случаях строка ТЗ «OPC UA Pub/Sub обязателен» вредна. Пишут: OPC UA Client/Server на границе участка; Pub/Sub - опция при числе потребителей больше N и после испытания сети.
Имеет смысл закладывать, если одновременно:
три и более постоянных читателя одного большого набора; сервер не тянет сессии (измерено, не «на всякий случай»); есть выделенный VLAN и коммутаторы с IGMP, либо брокер в DMZ с ответственным; DataSet спроектирован (не «всё дерево»); Reader умеет timeout и качество; команды и HMI остаются на Client/Server; FAT включает обрыв writer, обрыв сети, рестарт брокера, шторм.
Типичные удачные ниши: энергоучёт на верх, зеркало для MES, второй архив, тестовый контур аналитики. Типичные неудачные: замена полевой шины, связь двух ПЛК для межблокировки, единственный канал к панели оператора.
| Сценарий | Client/Server | Pub/Sub | Аргумент |
|---|---|---|---|
| Локальная панель на двери шкафа | Да | Нет как основной канал | Сессия, запись, понятный обрыв, без зависимости от брокера |
| Главная SCADA участка, уставки | Да | Дополнительно только чтение | Write, права, журнал; публикация не заменяет команду |
| Три потребителя одной телеметрии (SCADA, MES, архив) | Можно, но грузит сервер | Да, если сеть готова | Один Writer вместо трёх полных подписок |
| Инженерный UA Expert / пуско | Да | Нет | Дерево, методы, диагностика сессии |
| Рваный канал, NAT, облако | Тяжело | MQTT-транспорт | Брокер и ACL; UDP multicast через NAT не едет |
| Межблокировка ПЛК - ПЛК | Нет как шина поля | Нет | Нет детерминизма цикла; оставляют полевой протокол |
| Объект без IGMP и без брокера в ЗИП | Да | Не закладывать | Иначе SAT превращается в настройку сети «с нуля» |
| КИИ, только белый список TCP | Да | Только через контролируемый брокер | UDP multicast плохо проходит аудит «как есть» |
| Рецепт, Method, файловый обмен | Да | Нет | Сервисы сессии |
| Резервная SCADA только читает | Можно второй клиент | Удобнее Reader | Меньше нагрузка на сервер, если DataSet уже есть |
Рабочая архитектура нового среднего объекта редко бывает «только Pub/Sub». Чаще так:
ПЛК или шлюз держит OPC UA-сервер Client/Server для панелей, SCADA и записи. Тот же шлюз (или отдельный Writer) публикует урезанный DataSet для MES/архива. Команды вниз - только сессия, с приоритетом местного ключа, как в контуре панель vs SCADA. Справочник имён один: узел UA, поле DataSet, тег SCADA. Часы NTP одни. Иначе Pub/Sub timestamp и журнал сессии не сходятся на разборе.
Дублирование одних и тех же 5000 тегов и сессией, и публикацией «на всякий случай» возвращает нагрузку и добавляет расхождение. Либо режут набор публикации, либо убирают лишних клиентов Client/Server.
Резервирование: failover сессии SCADA - понятный сценарий. Failover Writer Pub/Sub - нужны уникальность PublisherId, поведение двух писателей в одну группу, что делает Reader при двух потоках. Это проектируют, не надеются на «протокол сам разберётся».
В ТЗ на новый объект 2026 года полезнее не слово «Pub/Sub», а проверяемые пункты.
Режим для HMI и уставок: Client/Server, порт, политика сертификатов, кто клиент. Режим для массового чтения: Pub/Sub да/нет; транспорт UDP или MQTT; адреса, группы, брокер как изделие. Состав DataSet, период, heartbeat, поведение Reader по timeout. Запрет команд через публикацию либо отдельный защищённый канал с журналом. Испытания: отказ Writer, отказ брокера, отказ multicast (IGMP off), параллельная запись с панели и с SCADA.
На FAT не ограничиваются «тег живой в UA Expert». Для Pub/Sub показывают осциллограмму сети или счётчик кадров, обрыв на 30 и 600 секунд, отсутствие ложной «нормы». Для Client/Server - обрыв сессии и Bad на мнемосхеме. Сценарии в духе приёмки без сюрприза включают сеть как часть системы, не как «обеспечит заказчик».
Ключи подписи и шифрования Pub/Sub (SecurityGroup, KeyCredential) живут не там же, где сертификат Endpoint 4840. На пуске это всплывает поздно: сессия к серверу открывается, кадры UADP идут открытым текстом, ИБ подписывает акт «OPC UA защищён» по факту TCP. В паспорте отдельно: какие DataSet подписаны, где хранится ключ, кто ротирует, что видит Reader при просроченном ключе. Если ключей нет и объект не КИИ - это тоже решение, но записанное, а не «забыли включить».
Наладчику на смене нужна одна карточка: куда смотреть, если давление на панели живое, а в MES нет. Для Client/Server - сессия и статус узла. Для Pub/Sub - Writer, группа/топик, счётчик кадров, брокер. Без этой карточки два режима в одной системе превращаются в телефонный пинг-понг между ОТ и IT.
Вписать Pub/Sub в ТЗ, потому что год 2026. На объекте два клиента и нет IGMP.
Считать подписку Client/Server устаревшим опросом. Она уже не Modbus polling; сначала измеряют нагрузку.
UDP multicast в общий VLAN с полем. Шторм бьёт привода.
Команды в DataSet без аудита. Уставка «из эфира».
Метаданные не версионируют. Сменили проект - Reader молчит, Writer «всё шлёт».
MQTT-транспорт без хозяина брокера. IT патчит виртуалку, ОТ теряет телеметрию, виноват «OPC».
Панель оператора посадить на Pub/Sub. Местный экран зависит от инфраструктуры верхнего уровня.
Два Writer в одну группу без правил. Reader видит кашу или молчит при конфликте.
Обязателен ли Pub/Sub на новом объекте в 2026?
Нет. Обязателен документированный OPC UA (или иной открытый стык) с качеством и справочником. Pub/Sub - опция под fan-out и нагрузку сервера.
UDP или MQTT, если Pub/Sub всё-таки ставим?
Локальный сегмент с нормальными коммутаторами - UDP проще по железу и опаснее по шторму. Через границы, NAT, ИБ-шлюзы - MQTT и брокер. Не выбирать транспорт из маркетинга стека.
Можно ли обойтись только Pub/Sub?
Почти никогда, если есть уставки, панель и инженерия. Сессия всё равно нужна для конфигурации и записи.
Как понять, что Client/Server уже не тянет?
Измерения: CPU сервера, очередь уведомлений, задержка publishing, отказы сессий при добавлении клиента. Решение по графику, не по ощущению «слишком классика».
Что смотреть, если Pub/Sub «иногда пропадает»?
IGMP, storm control, CPU Writer, overflow брокера, NTP, несовпадение метаданных после выгрузки проекта, файрвол с несимметричным UDP.