Перенос OPC UA подписки: как сохранить сбор без второго потока
После восстановления сборщика хозяйство хочет использовать существующую подписку, а не создавать параллельную. Если клиент и сервер поддерживают TransferSubscriptions, перенос требует собственной проверки. Наличие прежнего номера подписки не даёт любому подключившемуся приложению права забрать её. Одновременно нужно проверить прикладной результат: данные продолжают поступать нужному потребителю и не записываются дважды из-за оставшейся процедуры пересоздания подписки в другом участке программы.
Подтвердить условия переноса
TransferSubscriptions переносит Subscription вместе с MonitoredItems между Session. Стандарт предусматривает проверки идентичности и безопасности; это не произвольное копирование ресурса по известному номеру. Параметр начальных значений также имеет отдельный смысл. Реальную поддержку и возвращённые результаты проверяйте на установленной реализации. Не называйте переносом ситуацию, в которой клиент молча создал новую подписку с похожим набором переменных после отказа старого сеанса. (OPC Foundation — Part 4, TransferSubscriptions)
До опыта сохраните идентификатор подписки, список контролируемых узлов и признаки исходного сеанса. Секретные токены в отчёт не помещайте. Опишите, какой клиент должен стать владельцем и какие операции разрешены его учётной записи по проекту. Отдельно укажите независимые механизмы автоматического восстановления, чтобы перенос и пересоздание ресурсов не запускались одновременно без согласованного управления и не мешали понять результаты испытания телеметрического сборщика.
Увеличить схему
Проверить владельца и данные
На стенде выполните предусмотренный перенос и сравните идентификаторы до и после. Подайте собственную последовательность изменений с различимыми метками. Наблюдайте, какой сеанс получает уведомления и сколько записей появляется у прикладного потребителя. Начальные значения после переноса не следует автоматически считать новыми физическими событиями. Их происхождение и назначение нужно сохранить при преобразовании в архив, журнал событий или другой формат данных хозяйства.
Затем проверьте согласованный отрицательный сценарий с участником, не удовлетворяющим требуемым условиям переноса. Он должен дать ожидаемый отказ и оставить понятное состояние действующего сбора. Не подменяйте этот опыт выдачей расширенных прав ради успеха. После завершения проверьте число подписок и корректное освобождение ненужных сеансов, а также возможность штатного повторного подключения без накопления лишних серверных ресурсов и нескольких незаметных потребителей одной переменной.
Зафиксировать непротиворечивый результат
В акте укажите фактический перенос, результаты проверок и число обработанных тестовых изменений. Если применён запасной путь пересоздания, опишите его отдельно с собственными ограничениями. Приёмка подтверждает управляемую смену владельца и корректный поток данных в выбранной конфигурации. Для хозяйства это позволяет восстановить сбор после отказа клиента, сохраняя прозрачное происхождение значений и не превращая каждый эпизод восстановления в несколько параллельных подписок с завышенным количеством записей и скрытой нагрузкой сервера.
