Как клиент OpcUa может получить информацию о конфигурации сервера? Например, max-pending-publish-requests и т. Д.

Мой клиент MILO OpcUa работал нормально, пока я не набрал определенное количество подписок - 10. Затем он начал получать Bad_TooManyPublishRequests. Я решил проблему, установив OpcUaClientConfigBuilder#setMaxPendingPublishRequests = 10;, как было предложено этим ответом, и он работает нормально снова.

Но как мне заранее узнать, что сервер может обрабатывать только 10 ожидающих запросов на публикацию?

После подключения к серверу я могу прочитать некоторую информацию о сервере. Как ServerState, CurrentTime или ServerProductName, как показано в ReadExample#readServerStateAndTime. Но как мне получить настройки серверов MaxPendingPublishRequests, MinSamplingInterval и т. Д.?

Также какова связь между подпиской и MonitoredItem? Я использовал один MonitoredItem на подписку, что сейчас кажется плохим подходом. Если вы хотите отслеживать сотни узлов, должны ли они быть в одной подписке или разделены на несколько подписок? Должны ли они быть сгруппированы по publishingInterval или какова правильная логика для их группировки?

Правки приветствуются, спасибо.


java opc-ua milo
person Štarke    schedule 16.07.2020    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Я разделю ваш вопрос и дам вам ответы.

Но как я могу получить настройки серверов MaxPendingPublishRequests, MinSamplingInterval и т. Д.?

Чтобы прочитать значение MinSupportedSamplingRate, вы можете использовать службы чтения атрибутов OPC UA. Идентификатор узла MinSupportedSamplingRate узла равен ns=0;i=2272. Используя службу чтения атрибутов, вы можете прочитать значение атрибута, чтобы получить минимальный поддерживаемый интервал выборки сервера. Если вы используете клиент с графическим интерфейсом, вы можете просмотреть адресное пространство сервера, чтобы найти его значение. Он присутствует под Root->Object->Server->ServerCapabilities->MinSupportedSamplingRate

«Также какова связь между подпиской и MonitoredItem?»

Подписки используются для отправки уведомлений клиенту. Подписки имеют набор MonitoredItems, назначенных им Клиентом. MonitoredItems генерирует уведомления, которые должны быть отправлены клиенту по подписке.

«Если вы хотите отслеживать сотни узлов, должны ли они быть в одной подписке или разделены на несколько подписок?»

Одной подписки достаточно для мониторинга сотен узлов (а то и больше). Это зависит от вашего варианта использования.

Должны ли они быть сгруппированы с помощью публикацииInterval или какова правильная логика для их группировки?

Интервал публикации Подписки определяет циклическую скорость, с которой выполняется Подписка. Каждый раз при выполнении он пытается отправить клиенту сообщение NotificationMessage. NotificationMessages содержат уведомления, о которых еще не было сообщено клиенту.

Если в этом случае подписка создается с интервалом публикации 1 мс, то каждые 1 мс сервер отправляет уведомление, которое может быть

  1. уведомление об изменении данных, если произошли какие-либо изменения значений, или
  2. пустой ответ на уведомление, если нет изменений значений (только если истек интервал сохранения активности)

Нет необходимости группировать узлы по параметру интервала публикации.

Вот некоторые другие реализации с открытым исходным кодом, которые могут быть вам интересны:

Если вам нужна дополнительная практическая информация, вы также можете ознакомиться с этими ресурсами:

person Priyadharshini Prabhakaran    schedule 17.07.2020
comment
Это довольно хороший ответ. Одно небольшое изменение: подписка с интервалом публикации 1 мс не обязательно будет отправлять уведомление каждые 1 мс. Если ничего не меняется, он не будет отправлять пустой ответ «keep alive», пока не истечет настроенный интервал сохранения активности. - person Kevin Herron; 17.07.2020
comment
Спасибо Приядхаршини и @Kevin за разъяснения. Это очень помогает. Теперь я могу получить MinSupportedSamplingRate, но все еще не могу найти узел, содержащий максимальное количество запросов на публикацию в очереди MaxPendingPublishRequests. Или как еще нужно настроить клиента, чтобы он не получал ответ Bad_TooManyPublishRequests? - person Štarke; 21.07.2020
comment
К сожалению, эти значения не публикуются сервером каким-либо стандартизированным способом. Клиент Milo позволяет вам настроить некоторое максимальное значение, поэтому вам просто нужно выбрать максимальное значение, которое вы найдете для экспериментальной работы. Однако, если вы измените свой код так, что вы больше не используете одну подписку на элемент, вы вряд ли столкнетесь с этой проблемой. - person Kevin Herron; 21.07.2020
comment
Спасибо @Kevin. Это именно тот ответ, который я искал. Какая будет рекомендуемая настройка, если у меня есть группа узлов, где значения меняются ровно каждые 5 минут, и еще одна группа, где изменение значений может быть случайным образом с интервалом от миллисекунд до часов? (Настройки подписки и настройки MonitoredItem, ...) - person Štarke; 27.07.2020
comment
@ Štarke вы можете использовать одну подписку с быстрым интервалом публикации (например, 100 мс или 1000 мс), а затем варьировать интервалы выборки для всех элементов, которые ей принадлежат. Это не будет проблемой. Потребуется ли вам в конечном итоге еще одна подписка, вероятно, зависит от количества отслеживаемых элементов, которые у вас будут. Некоторые серверы могут ограничивать количество отслеживаемых элементов в одной подписке. К сожалению, это будет еще одно неопубликованное значение. - person Kevin Herron; 27.07.2020