Переподключение OPC UA сборщика: новый канал или новый сеанс
После краткого отказа беспроводного участка сборщик хозяйства снова получает значения. Это ещё не объясняет, сохранился ли прежний OPC UA сеанс или клиент создал новый. Разница важна для подписок, диагностики и ресурсов сервера. Проверяйте восстановление по идентификаторам и реальным операциям, чтобы слово «reconnect» в журнале не скрывало несколько разных процедур с неодинаковыми последствиями.
Составить карту состояния
OPC UA разделяет Session и SecureChannel. Сервис CreateSession создаёт сеанс с собственными идентификаторами; ActivateSession позволяет связать существующий сеанс с новым защищённым каналом в предусмотренных условиях. Поэтому смена SecureChannelId сама по себе не доказывает создание новой Session. Возможность конкретного восстановления зависит от состояния сервера и поведения клиента, а не от одной подписи статуса. (OPC Foundation — Part 4, CreateSession)
До испытания запишите SessionId, идентификатор канала и наблюдаемые ресурсы клиента. Секретный authenticationToken в общий отчёт не включайте. Укажите согласованные таймеры и версии обеих сторон, но не назначайте их универсально. Для каждого события оставьте отдельные поля: канал создан, сеанс активирован, данные возобновились. Такая запись помогает сопоставить техническое состояние с фактическим поступлением измерений в хозяйственный архив.
Увеличить схему
Сравнить два отказа
На стенде сначала воспроизведите краткий разрыв, после которого предусмотрено использование прежнего сеанса. Сопоставьте старые и новые идентификаторы, операции активации и возобновление подписок. Затем отдельным опытом создайте согласованные условия, при которых прежний сеанс уже недоступен. Не делайте вывод о сохранении только потому, что окно клиента выглядит одинаково: интерфейс может скрывать пересоздание всех серверных ресурсов.
После каждого опыта проверьте поступление собственной различимой последовательности тестовых значений. Отдельно наблюдайте число активных сеансов на сервере и освобождение ненужных ресурсов. Если после повторных обрывов их количество растёт, это нужно исследовать независимо от видимой доступности данных. Не запускайте нагрузочное многократное переподключение в рабочей системе хозяйства без согласованного испытательного режима и достаточной наблюдаемости серверной стороны.
Зафиксировать границу восстановления
В отчёте покажите, где сохранился сеанс, где появился новый и какие данные реально дошли до прикладного потребителя. Не объявляйте историю полной только по успешной активации: наличие пропусков проверяется отдельно. Приёмка подтверждает предусмотренное поведение клиента в обоих сценариях и корректное управление ресурсами. Для хозяйства это позволяет различать успешное восстановление транспорта, сохранение контекста работы и фактическую непрерывность телеметрии, не подменяя три результата одной зелёной надписью подключения.