Sampling и publishing в подписке OPC UA
Как связаны sampling и publishing в OPC UA: revised-интервалы, очередь MonitoredItem, фильтры, Overflow и проверка полноты уведомлений на стенде.
На тренде OPC UA значение меняется раз в секунду, хотя клиент запросил выборку каждые 100 мс. При кратком переключении между публикациями новое состояние иногда вообще не появляется. Такая картина может соответствовать настройке очереди, а не неисправной связи.
Разберём путь от обновления источника до уведомления клиента: sampling, фильтр, очередь MonitoredItem и publishing. Лимит количества переменных и общую диагностику застывшего тега здесь не повторяем. Главный вопрос состоит в том, какие изменения подписка способна наблюдать и какие из наблюдённых изменений сохраняет до отправки.
Короткий ответ
Sampling interval задаёт запрашиваемую частоту наблюдения значения MonitoredItem, а publishing interval относится к работе подписки и выдаче уведомлений. Сервер возвращает фактически принятые revised-параметры, которые могут отличаться от запроса. Очередь размером один обычно оставляет последнее подходящее значение до публикации. Большая очередь позволяет сохранить несколько уведомлений, но имеет предел и политику вытеснения. Ни маленький интервал, ни большая очередь не восстановят событие, которое сам источник или механизм выборки не успел наблюдать.
Четыре разных времени
Первое время относится к источнику. Переменная может обновляться задачей ПЛК раз в 20 мс, драйвером раз в 200 мс или внешним прибором ещё медленнее. Запрос выборки каждые 10 мс не создаёт новых измерений, если источник обновляет данные раз в секунду. Клиент будет повторно наблюдать то же состояние.
Второе время задаёт sampling MonitoredItem. Сервер проверяет значение с принятой частотой в пределах возможностей реализации. Спецификация описывает sampling как обслуживание с ограничениями источника и сервера, поэтому его нельзя считать аппаратным захватом каждого фронта. Событие между наблюдениями может остаться незамеченным.
Третья часть относится к фильтру уведомлений. Из наблюдённых значений не каждое обязательно попадёт в очередь: результат зависит от DataChangeFilter, изменения статуса, временной метки и выбранной мёртвой зоны. Если клиент настроил фильтрацию малых изменений, отсутствие промежуточных значений может быть ожидаемым поведением.
Четвёртое время связано с publishing подписки и обслуживанием Publish-запросов клиента. Оно определяет организацию выдачи накопленных уведомлений, но не является гарантированной полной задержкой от физического процесса до экрана. Добавляются обновление источника, sampling, сеть, обработка клиентом и его отрисовка.
Что означает revised
При создании или изменении MonitoredItem сервер возвращает revisedSamplingInterval и revisedQueueSize. При создании подписки клиент получает revisedPublishingInterval и другие параметры. В диагностике сохраняют именно эти ответы, а не только числа, которые приложение попросило установить.
Например, клиент запросил sampling 10 мс, а сервер согласовал 100 мс. Интерфейс настройки может продолжать показывать исходное пожелание, если разработчик не выводит ответ сервера. Для технической приёмки нужно проверить реальные параметры через журнал клиента или поддерживаемый диагностический инструмент.
Если sampling наследуется от publishing при создании, дальнейшее изменение publishing не следует трактовать как автоматическое изменение всех уже назначенных интервалов. Поведение проверяют по правилам используемой версии спецификации и результатам сервисов. Удобная общая кнопка «ускорить подписку» не заменяет чтение revised-параметров отдельных элементов.
Также проверяют monitoring mode и состояние publishing. Элемент может существовать, но не выдавать данные в ожидаемом режиме. Настройка интервала не поможет, если клиент создал объект для выборки без передачи уведомлений или приостановил публикацию подписки.
Очередь размером один
Рассмотрим условный источник: значение меняется с 0 на 1 на 200-й миллисекунде и возвращается в 0 на 500-й. Сервер действительно наблюдает оба изменения, а публикация происходит на 1000-й миллисекунде. При очереди в один элемент более позднее значение может заменить предыдущее, и клиент получит только 0.
Этот пример предполагает, что изменения прошли фильтр и не были отправлены раньше. Он показывает ограничение очереди, а не точное расписание любого сервера. Если фактическая выборка вообще не увидела единицу, увеличение очереди ничего не изменит: сохранять будет нечего.
Для очереди размером один политика discardOldest не имеет обычного смысла выбора между несколькими элементами и игнорируется по правилам спецификации. Такой режим подходит для представления последнего состояния, когда промежуточные изменения не нужны. Для подсчёта кратких технологических событий это часто неверная постановка задачи.
Большая очередь и переполнение
При размере больше одного сервер может накопить несколько уведомлений между отправками. Это помогает увидеть уже наблюдённые изменения. Но очередь не является бесконечным архивом и не даёт права отключать клиента на произвольное время без оценки потерь.
При заполненной очереди и discardOldest = true удаляется старое уведомление, чтобы добавить новое. При false спецификация описывает замену последнего добавленного значения новым, а не простое правило «никогда не принимать новые данные». Поэтому содержимое после переполнения нужно понимать точно, особенно при восстановлении последовательности состояний.
Для DataValue при отбрасывании в очереди больше одного предусмотрен Overflow в StatusCode. Клиент должен сохранять и проверять этот признак. Если он извлекает только числовое Value и выбрасывает статус, предупреждение о потере промежуточных уведомлений исчезает из дальнейшей обработки.
| Задача | Подход к данным | Что проверить |
|---|---|---|
| Экран текущей температуры | Последнее состояние может быть достаточным | Допустимую задержку и качество |
| Тренд с промежуточными точками | Sampling, фильтр и очередь согласуют вместе | Временные метки и Overflow |
| Подсчёт изделий | Счётчик у источника или подходящая событийная модель | Потери, переполнение счётчика, восстановление |
| Расследование последовательности | Фиксация событий у источника | Полноту и порядок журнала |
| Длительная потеря клиента | Отдельный механизм истории или буферизации | Границы хранения и процедуру дочитывания |
Как оценить требуемый размер
Начальная инженерная оценка связывает максимальную частоту подходящих уведомлений со временем между их выгрузками. Если ожидается десять значимых изменений в секунду, очередь в один элемент не сохранит все изменения при публикации раз в секунду. Но назначить ровно десять тоже недостаточно без учёта неравномерности и задержек.
Расчёт должен учитывать всплески, ограничения сервера и фактическое обслуживание Publish-запросов. На подписку также могут действовать ограничения числа уведомлений в одном ответе. Очередь элемента и очередь сообщений подписки решают разные задачи; увеличение одной не отменяет предел другой.
Сначала определяют, действительно ли требуется передавать каждое изменение. Для общего экрана разумнее ограничить частоту, чем создавать большую нагрузку ради незаметных промежуточных значений. Для событийной задачи лучше явно моделировать событие или счётчик, чем надеяться, что ускоренный тренд случайно станет журналом.
Проверка на стенде
Создают воспроизводимый тестовый источник с известными состояниями и временными метками. Сначала используют медленную последовательность, которую гарантированно наблюдает выбранный механизм. Затем проверяют её при очереди один и при большей очереди, сохраняя одинаковые остальные настройки.
Клиент записывает Value, StatusCode, SourceTimestamp, ServerTimestamp и время локального получения. Эти отметки относятся к разным событиям; время прихода пакета нельзя выдавать за время измерения. Нужна также проверка достоверности часов источника, если вывод зависит от абсолютного времени.
После базового теста увеличивают частоту изменений до согласованного предела и проверяют переполнение. Отдельно испытывают приостановку клиента, восстановление подключения и поведение его локального буфера. Если приложение рисует только последнее значение пачки уведомлений, график может скрыть точки, которые сервер успешно передал.
В протоколе сохраняют запрошенные и revised-настройки, фильтр, размер очереди и политику вытеснения. Затем указывают, какие изменения действительно наблюдались сервером и какие дошли до приложения. Это позволяет обсуждать конкретный участок потери вместо общего утверждения «OPC UA тормозит».
Полнота данных и подтверждение сообщений
В подписке существуют механизмы подтверждения NotificationMessage и восстановления доступных сообщений, но они не возвращают уведомление, которое уже потерялось в очереди MonitoredItem. Нужно различать два участка: формирование и хранение уведомлений до отправки, затем доставка сформированных сообщений клиенту. Успешное повторное получение пакета исправляет определённый транспортный пропуск, но не создаёт пропущенную выборку источника.
Для клиента полезно вести отдельные показатели: состояние соединения, номер последовательности сообщения, обнаруженный разрыв и Overflow значений. Один зелёный индикатор OPC UA не описывает полноту истории. Приложение может оставаться подключённым и получать актуальный последний статус после потери нескольких промежуточных изменений. Для экрана это допустимо, для расследования последовательности может быть существенным ограничением.
Если нужна историческая полнота, сначала проверяют наличие подходящего исторического источника и механизм чтения истории. Обычная подписка с большой очередью не становится историком на произвольную глубину. Разрешённое время отключения клиента, объём хранения и способ закрытия пробела задают отдельно. В протоколе приёмки должно быть видно, каким механизмом восстанавливается каждый тип пропуска.
Мёртвая зона и характер процесса
Для медленно меняющейся аналоговой величины мёртвая зона уменьшает поток почти одинаковых уведомлений. Но вместе с размером очереди она определяет, какую форму тренда увидит потребитель. Если каждое небольшое изменение отбрасывается, высокий sampling сам по себе не вернёт мелкие детали. Нужно согласовать требуемую точность представления с фильтром, а не просто выбирать минимальные интервалы.
При использовании процентной мёртвой зоны проверяют доступный инженерный диапазон и правила его применения. Проценты без определённой базы не дают понятного абсолютного порога. Изменение диапазона тега при модернизации способно изменить результат фильтрации, даже если процент остался прежним. Это ещё один повод сохранять полный набор параметров MonitoredItem рядом с данными испытаний.
Дискретное состояние с кратким возвращением в исходное значение требует другого подхода. Для него важны наблюдение каждого перехода и возможность сохранить несколько уведомлений. Если задача состоит в учёте количества срабатываний, накопительный счётчик у источника часто даёт более определённый результат. При этом отдельно решают его переполнение и поведение после перезапуска, а не объявляют счётчик бесконечным.
Проверка клиентского приложения
Сначала сохраняют все принятые уведомления в диагностический буфер без прореживания отрисовкой. Затем сопоставляют их с тем, что показал график. Многие интерфейсы обновляют экран реже получения данных, и это само по себе нормально. Ошибка возникает, когда разработчик по картинке делает вывод о потере на сервере, не проверив фактическую последовательность входных уведомлений.
Проверяют также обработку пачки данных с одинаковым временем получения. Если архив использует только локальную метку и имеет уникальный ключ по времени, несколько уведомлений могут перезаписать друг друга. Сервер передал их корректно, а прикладная база сохранила одно. Для диагностики нужны исходные временные метки, порядок приёма и правила записи архива.
Наконец испытывают перегрузку клиента. Медленный обработчик, синхронная запись на диск или тяжёлая визуализация могут создать локальную очередь. Увеличение серверного publishing не исправляет медленную обработку уже полученных данных. Разделение счётчиков на стороне сервера, транспорта и клиента помогает найти конкретное место, где полнота перестала соответствовать требованиям. Итоговую оценку дают для всей проверенной цепочки, а не для одного успешно созданного MonitoredItem.
При анализе полезно хранить отдельно время последнего уведомления и время последнего изменения значения. Постоянная исправная температура может долго не создавать новых изменений, а это не равно отказу источника. Для проверки доступности применяют подходящие механизмы состояния подписки и качества. И наоборот, регулярные транспортные ответы не доказывают, что физический датчик обновляется. Критерий свежести измерения определяется на уровне источника и его модели данных.
Вопросы при работе
Почему sampling 100 мс не даёт десять точек каждую секунду? Уведомления зависят от изменения данных и фильтра, а источник может обновляться реже. Кроме того, сервер мог согласовать другой интервал. Сначала читают revised-параметры и временные метки.
Можно ли большой очередью поймать короткий импульс? Только если импульс уже наблюдался и сформировал уведомление. Очередь хранит результаты наблюдения, а не непрерывный физический сигнал. Для коротких событий выбирают подходящий захват у источника.
Overflow означает полный обрыв связи? Нет, он указывает на определённую потерю уведомлений при переполнении. Текущее значение при этом может успешно приходить. Такой статус важен для оценки полноты истории, даже когда экран выглядит живым.
Publishing interval равен задержке на экране? Нет. Он является одной частью цепочки. Полную задержку проверяют от определённого события источника до согласованной точки приложения с учётом качества синхронизации времени.