Republish OPC UA: что можно вернуть после пропущенного уведомления
После сбоя сборщик хозяйства обнаруживает пропуск в последовательности уведомлений. Функция Republish может помочь, если нужное сообщение ещё доступно на сервере. Но она не является запросом произвольной истории датчика. Приёмка должна проверить как успешное возвращение сообщения, так и честное обозначение невосстановимого пробела. Иначе восстановление связи создаст видимость полного архива там, где необходимые уведомления уже недоступны выбранному механизму.
Назвать возвращаемый объект
Republish запрашивает конкретное NotificationMessage из retransmission queue подписки. Если сервер больше не имеет нужного сообщения, он возвращает ошибку. Запрос связан с идентификатором подписки и номером сообщения, а не просто с желаемым временем измерения. Этот механизм отличается от чтения исторических значений. Поддержка и сохранённый контекст установленного сервера должны быть проверены до обещания восстановления данных пользователю. (OPC Foundation — Part 4, Republish)
Запишите последовательность до отказа, обнаруженный номер пропуска и доступный клиенту контекст подписки. Отдельно сохраните прикладные идентификаторы тестовых данных, если они есть. Номер протокольного сообщения не заменяет смысл каждого измерения. Поясните, кто обнаруживает пробел и кто запрашивает повтор, чтобы две параллельные процедуры восстановления не создавали необъяснимые повторные записи в архиве хозяйства после возобновления нормального потока телеметрии через шлюз.
Проверить два исхода
На стенде сформируйте собственную различимую последовательность и воспроизведите согласованный пропуск получения. В первом опыте запросите сообщение, которое ещё доступно для повторной передачи. Сопоставьте возвращённое содержимое с первоначальной последовательностью и результатом прикладной записи. Сам успешный ответ сервиса не подтверждает, что данные попали в нужный архивный ряд с правильным источником, исходным временем и сохранённым качеством каждого значения.
Во втором отдельном опыте запросите заведомо недоступное сообщение в допустимых условиях стенда. Клиент должен показать понятный исход и обозначить незаполненный участок согласно проектной политике. Не заменяйте его последним текущим значением и не выдумывайте промежуточные состояния. Если предусмотрен другой источник восстановления, проверяйте его отдельной процедурой с сохранением происхождения данных, а не выдавайте результат этой процедуры за возможности одного сервиса Republish.
Принять ограниченное восстановление
В акте перечислите восстановленные номера, недоступные сообщения и результат обработки повторов приложением. Укажите условия сохранения контекста и ограничения наблюдаемости. Приёмка подтверждает реальную возможность вернуть доступное уведомление и корректно сообщить о невозможности вернуть другое. Для хозяйства это даёт прозрачную историю после отказа канала: восстановленные данные имеют проверяемое происхождение, а сохранившийся пробел остаётся видимым вместо необоснованного утверждения, что повторное подключение автоматически вернуло все измерения.