Обновление ПО scada

[Eugene_]

да, теперь все нормально. Спасибо.

[Eugene_]

Все же прошу разработчиков вернуться к этому вопросу. Не все нормально в релизах .10 и .11 с  работой по ОРС UA.

В релизе .11 теперь да, при пропадании связи с ОРС UA сервером SCADA заново подключается и не зависает, обновление переменных не останавливается.  Наблюдение показало, что обрывы (запись этого события в логе/окне сервер SCADA) могут быть с частотой до 1 разрыва в 1-2 часа. Подозревались и искались внешние проблемы, но оказалось что нет - дело в  SCADA ? Очевидно, что во время переподключения на трендах идут заметные разрывы в графиках, что не допустимо.

На этом же сервере была установлена версия 2.5.6.0 Demo и создан проект с парой переменных с этого же источника, с ОРС UA сервера - обрывов нет, все работает четко и надежно. Также имеется с этим релизом 2.5.6.0 боевой сервер в режиме 24/7 несколько месяцев, где тоже проблем с обрывом по ОРС UA нет. Боевой сервер также читает данные с этого ОРС UA источника.

Прошу просмотреть механизм обращения к ОРС UA, который, судя по описанию релизов, был существенно изменён в релизах 10 и 11.

[Simple-Scada]

Ошибка Bad_Timeout выдаётся в следующих случаях:
1. UA-сервер не ответил на запрос со стороны скады за время заданное для UA-сервера в поле Request timeout (из меню Проект -> OPC-серверы -> кнопка "Расширенные настройки");
2. UA-сервер за 8 секунд не смог вернуть серверу скады текущий статус UA-сервера.

Других причин для ошибки Bad_Timeout нет. Если Вы сделаете снимки трафика через Wireshark, то увидите, что в моменты Bad_Timeout со стороны UA-сервера скада ничего не получала в ответ на свои запросы.
Чаще всего это происходит когда связь с UA-сервером действительно разрывается на время более 8 сек. или более чем "Request timeout". Но не всегда. Некоторые UA-серверы во время работы могут начать выполнять какие-то свои задачи и на время выполнения полностью прекращают отвечать UA-клиенту (что неправильно). Для скады это выглядит как зависание UA-сервера, ведь он перестаёт отвечать на запросы. Распространённый случай: в конфигурации UA-сервера есть контроллер (или несколько контроллеров), который временно не работает (или время от времени отключается, например из-за плохой сети). UA-сервер пытается подключиться к нему, но не может и вынужден выжидать таймаут на подключение, например 30 сек. В течение этого времени UA-сервер ничего не делает, а только ждёт таймаут. В таком случае в скаде возникнет Bad_Timeout, т.к. UA-сервер не ответит на запросы со стороны сервера скады, пока не выйдет таймаут подключения к контроллеру. Для корректной работы UA-сервер должен выжидать таймаут в отдельном потоке, чтобы ожидание никак не влияло на выполнение других задач, включая ответы на запросы UA-клиентов. К сожалению не все UA-серверы так работают.

Если нет возможности как-либо повлиять на работу UA-сервера или сети, то для решения со стороны скады можно увеличить время "Request timeout", например до 20000 (20 секунд) или выше. Это может помочь.
Но останется ещё опрос статуса сервера (сейчас он выполняется каждые 8 сек.) и он может помешать. В ближайшее время сделаем обновление с возможностью изменения частоты опроса статуса UA-сервера.

На этом же сервере была установлена версия 2.5.6.0 Demo и создан проект с парой переменных с этого же источника, с ОРС UA сервера - обрывов нет, все работает четко и надежно.

Это подтверждает вышеописанное, т.к. в старых версиях на операции отводилось больше времени, но это плохо влияло на выявление проблем связи, поэтому время было уменьшено.

[Eugene_]

в 2.5.6 есть раздельное время настройки этих параметров. Для проверки уменьшить менее чем до 8000ms не дает. Есть какие то внутренние переменные в коде ПО, не относящиеся к настройкам,  о которых вы говорите ? На тестовом сервере сейчас были такие настройки как на картинке и нет ни одной ошибки за 3 суток. В тестовом проекте два контроллера, с которых также опрашивается пилообразно меняющееся значение переменной.

Сейчас оба параметра выставил в минимальные 8000 мс , пронаблюдаем.

[Simple-Scada]

Для версии 2.5.6 эти параметры на работу уже подключенных подписок не повлияют. Request timeout в этой версии используется только для активации сессии, запросов на создание подписки и отслеживаемых переменных. А проблем в эти моменты у Вас явно не возникает.
Также в этой версии не отслеживается статус UA-сервера. Все необходимые проверки в соответствии со спецификацией OPC-UA выполняются сервером скады начиная с версии 2.5.9.0. В ней отслеживается статус сервера (чтение каждые 8 секунд. Смена этого времени будет доступна в ближайшем обновлении) и Request timeout используется для всех операций которые требуют ответа UA-сервера. Поэтому менять Request timeout (в данном случае) есть смысл только для версии 2.5.9.0 и выше. Если увеличение Request timeout не помогает в версии 2.5.9.0 (и выше), то причина точно в чтении статуса сервера.
Если нужно обнаружить конкретную проблему, то проще всего сделать снимок трафика через Wireshark по порту UA-сервера, в нём будет видно в какой именно момент UA-сервер перестал отвечать и как долго он не отвечал (либо будут видны какие-то проблемы с трафиком и т.п.). 

[Simple-Scada]

Внесли изменения в обновление 2.5.12.0. Теперь скада в случае Bad_Timeout во время проверки статуса делает ещё одну попытку чтения статуса (с меньшим таймаутом). Если и вторая попытка закончится неудачно, то будет выдана ошибка. Если после обновления ошибка Bad_Timeout продолжает возникать, то можно в окне расширенных настроек UA-сервера изменить время в поле "Проверка статуса" на 10000 или 12000. Также можно попробовать увеличить время в поле "Таймаут запросов" до 12000 или 14000. 

[Simple-Scada]

В недавних тестах обнаружили, что на нескольких ПК возникают периодические проблемы с ошибкой Bad_Timeout при работе с OPC-сервером MasterOPC во время чтения статуса сервера. С другими UA-серверами такая же проблема не возникает. В обновлении 2.5.14.0 мы изменили процесс чтения статуса, теперь данная ошибка не должна возникать без повода.

[Eugene_]

в релизе 2.5.15.0 (beta) указано
1. >> OPC-UA: исправлено долгое ожидание подключения/переподключения, когда связь с сервером нарушена;
это исправление ошибки релизов 2.5.14.0 - 2.5.12.0 ? в смысле - это изменение  (ошибка) появившаяся в этих релизах или это исправление какой-то боле ранней ошибки более ранних релизов ?

2. >>разрывы в трендах теперь всегда отображаются без "падения" тренда;
подскажите, как теперь узнавать что в какой то момент времени статусы тегов были Bad или не было связи с ОРС (проблема у ОРС) ? как это будет отображаться на графиках ? если есть пример картинки было бы хорошо. Режим трендов и графиков "ступенчатый" используется.

[Simple-Scada]

это исправление ошибки релизов 2.5.14.0 - 2.5.12.0? в смысле - это изменение появившаяся в этих релизах или это исправление какой-то боле ранней ошибки более ранних релизов?

Так было во всех пред. версиях. Стоял долгий сетевой таймаут в моменты подключения/переподключения к UA-серверу. Он практически не используется в реальных ситуациях, т.к. сбой сети обычно определяется по сообщениям поддержания активности / периодической проверкой статуса UA-сервера.

подскажите, как теперь узнавать что в какой то момент времени статусы тегов были Bad или не было связи с ОРС (проблема у ОРС) ? как это будет отображаться на графиках ? если есть пример картинки было бы хорошо. Режим трендов и графиков "ступенчатый" используется.

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

[teplocom]

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

Подскажите, а как-то можно избежать появление "падения тренда" при старте проекта после остановки на сервере?
По примеру на ScreenShot в Вашем сообщении все переменные приняли значение =0 в 17:53:45.
Или это особенность взаимодействия с OPC-сервером (который стартует возможно медленнее чем успевает запуститься архивация) и от нее никуда не деться?

[Simple-Scada]

Подскажите, а как-то можно избежать появление "падения тренда" при старте проекта после остановки на сервере?

В последних версиях для внешних тегов первая точка добавляется после полного подключения к OPC-серверу, поэтому линии не будет (если OPC-сервер реально не возвращает сначала 0, а затем настоящее значение). На скрине из пред. сообщения тренды основаны на внутренних переменных, которые сначала равны 0, а затем начинают меняться. Если нужно чтобы внутренние переменные не стартовали с нуля, то нужно включить у них автоматическое восстановление.

[Eugene_]

В недавних тестах обнаружили, что на нескольких ПК возникают периодические проблемы с ошибкой Bad_Timeout при работе с OPC-сервером MasterOPC во время чтения статуса сервера. С другими UA-серверами такая же проблема не возникает. В обновлении 2.5.14.0 мы изменили процесс чтения статуса, теперь данная ошибка не должна возникать без повода.

Стало реже проявляться.  Такой вопрос, верно ли понимаю: подряд идет несколько запросов на чтение запись, к примеру 1-2-3, если 1й запрос в нужное время не ответил, а 2 и 3 ответили - то сообщение о переподключении и удаление неизвестной подписки относится к 1-му запросу ?  То есть как на картинке с интервала 06:00:17 по 06:00:26 это обработка 1-го (условно) запроса и провала в получении данных нет в 9 секунд, а есть только короткий провал на время одного периода опроса OPC только (100-500мс) ?

Версия ОРС та же (5.0.14), SCADA обновлена с 2.5.12.0 до 2.5.14.0

[Simple-Scada]

В случае аварийного разрыва связи с UA-сервером (т.е. после Bad_Timeout) скада не сможет штатно удалить подписки (т.к. связь разорвана) и они могут быть активны на OPC-сервере ещё некоторое время. После переподключения скада создаст новые подписки. И если она обнаружит, что старые подписки ещё существуют на OPC-сервере, то она удалит их (чтобы не передавать лишние данные и не нагружать UA-сервер) и выдаст сообщение "delete unknown subscription" с id-подписки в журнал. По сути, после переподключения скада выполняет удаление старых подписок, которые она не смогла корректно удалить из-за неожиданного разрыва связи.

[Eugene_]

все понятно, такое поведение нормальное, спасибо!

[Eugene_]

Вернусь к этому вопросу. Не удается никак найти зависимости от внешних факторов работы связки SimpleScada и Insat Modbus OPC UA. Может часть сообщений и часть истории в отдельную тему стоит вынести ?

Ниже прилагаю скрин из логов. В данный момент, для тестов, на отдельной одной виртуальной машине вместе установлены SS последней версии 2.6.1.0  и Insat Modbus OPC 5.0.17, все самое новейшее 1-2 месяца давности. Все равно проявляется в логах эта запись, и по факту, если смотреть архивы трендов в SS периодически есть провалы в графиках. Для примера также вложил скриншот, где желтый график это бит с локального ОРС. зеленым - бит с удаленного ОРС на другой машине. Несколько удивительно, что удаленный не прервался.

Резюмируя: даже если SCADA и ОРС установлены вместе на одной машине в данный момент времени имеем проблему с прерыванием передачи данных. Так как локально все, вариант нестабильности сети отпадает. Настройки базовых параметров соединения как в SCADA системе в разделе ОРС, так и отключение немногочисленных настроек контроля соединения в Insat OPC прямо не влияют на периодичность этой ошибки в логах SS, можно сказать зависимости нет.

Есть мысль: по ссылке выше сказано, в пункте 8 цитата "...Closing the Subscription causes its MonitoredItems to be deleted. In addition the Server shall issue a StatusChangeNotification notificationMessage with the status code Bad_Timeout." То есть SCADA верно отображает возвращаемый статус, и подписка закрывается штатно на ОРС сервере, просто не было "Publish requests" со стороны SCADA какое то время ?  lifetime counter уменьшился до нужного порога и ОРС сервер штатно закрыл подписку с таким ID ?

Примечание: с техподдержкой Insat обговаривалась возможная нестабильность работы ОРС, собственно релиз 0.17 и был выпущен с некоторыми  поправками по этому вопросу, но проблема не ушла.