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

[Simple-Scada]

просто не было "Publish requests" со стороны SCADA какое то время?

Крайне маловероятно, т.к. в последних версиях скада постоянно отдельным таймером проверяет отправку Publish запросов и повторяет их, если возникли какие-либо проблемы. Это легко проверить сделав снимок трафика через Wireshark.

Раньше мы и на своих ПК сталкивались с этой проблемой, когда скада для контроля связи периодически читала на OPC-сервере стандартный тег ServerStatus (i=2256). Все OPC-UA серверы работали правильно (мы всегда тестируем 13 OPC-серверов разных производителей), кроме одного: MasterOPC Universal Modbus Server.  Он иногда не отвечал на чтение ServerStatus, что логично воспринималось скадой как Bad_Timeout (не ответил за отведённое время). Затем выяснилось, что если вместо ServerStatus читать ServerStatus_State (i = 2259), то проблема решается. Поэтому мы специально для данного UA-сервера изменили проверку статуса на чтение ServerStatus_State.

Можем повторить Ваш тест на наших ПК. Вы используете MasterOPC на 32 тега со стандартной конфигурацией и читаете в скаду теги симуляции (из группы PN_SIMULATOR)? Или сделали свою конфигурацию и читаете теги с устройств? Какая частота опроса у переменных в скаде? Как часто возникает Bad_Timeout?

[Eugene_]

>>Вы используете MasterOPC на 32 тега со стандартной конфигурацией
да, demo версия с сайта

>> читаете в скаду теги симуляции (из группы PN_SIMULATOR)?
да, на локальном ОРС всего 1 тег в конфигурации оставлен, пила от 0 до 10. Период генерации 1000 мс. Изменение в диапазоне от 1000 до 100 мс на картину не влияет существенно.

>>Какая частота опроса у переменных в скаде
20мс, для теста стоит 50мс, не влияет на результат

>> Как часто возникает Bad_Timeout?
с текущими настройками - не менее 2-5 раза в сутки стабильно, четко периода между событиями нет

>>всегда тестируем 13 OPC-серверов разных производителей
к слову, есть несколько подключенных OPC UA серверов на основе ПЛК Wago 750-ххх (в последних релиза прошивок у них это поддерживается нормально) -  обрывов и таких сообщений,  за все все время работы, с любым релизом SCADA (начали с 2.5.ххх) в логах не наблюдалось. Но у них может быть весьма упрощенная реакция на опросы и прочие допущения.

upd: зафиксировать удалось и потерю с двух серверов ОРС Insat, и с удаленного и с локального, зеленая и желтая линия соответственно.

[Simple-Scada]

Проверили. Это ошибка MasterOPC, такая же проблема возникает при подключении с других UA-клиентов (например UaExpert). Причина в том, что UA-сервер допускает неправильный порядок номера последовательности в ответах (Sequence Number). Например, если UA-клиент передаст MasterOPC два запроса: PublishRequest + ReadRequest, то есть вероятность, что MasterOPC ответит с номером последовательности в обратном порядке, например, первый ответ вернёт с Sequence Number = 100, а второй = 99, что недопустимо. Данная проблема хорошо фиксируется в логе UaExpert (пример на скрине) и снимках трафика Wireshark. Если создать подписку с частотой 100 мс. и выставить таймер чтения статуса сервера почаще (например каждые 2 секунды), то вероятность воспроизведения ошибки вырастет многократно, т.к. PublishRequest + ReadRequest будут передаваться значительно чаще.

зафиксировать удалось и потерю с двух серверов ОРС Insat, и с удаленного и с локального

Если связь по сети стабильна, то не имеет значения локальный OPC, или удаленный.

к слову, есть несколько подключенных OPC UA серверов на основе ПЛК Wago 750-ххх - обрывов и таких сообщений,  за все все время работы, с любым релизом SCADA (начали с 2.5.ххх) в логах не наблюдалось. Но у них может быть весьма упрощенная реакция на опросы и прочие допущения.

Реакция на опросы для любых UA-серверов всегда одна и та же (соответствующая спецификации OPC-UA, при условии что в UA-сервере нет ошибок), в ином случае пришлось бы писать отдельный "драйвер" для каждого UA-сервера.

[Eugene_]

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

Также поставил последнюю версию UaExpert с сайта разработчика, и одновременно к одному ОРС UA подключил локально установленную SCADA и UaExpert. Снимок во вложении. Интересно, что за сравнительно небольшой период у SCADA в логах было одно переподключение, а у UaExpert нет. Понятно, что у каждого клиента своя подписка и событие для каждого клиента произойдет не одновременно (или вообще не произойдет для какого то из них)

прим.: на картинке 09:14 последнее время события в UaExpert, он был запущен ранее и больше событий в логах нет, а SCADA была запущена позже

[Simple-Scada]

Списался с технической поддержкой Insat, также отправил ссылку на эту беседу. Говорят у них проблема не воспроизводится.

Мы же описали выше точную причину ошибки и как сделать так, чтобы она воспроизводилась чаще. На наш взгляд информации для выявления и исправления более чем достаточно. Вот суть ошибки:

если UA-клиент передаст MasterOPC два запроса: PublishRequest + ReadRequest, то есть вероятность, что MasterOPC ответит с номером последовательности в обратном порядке, например, первый ответ вернёт с Sequence Number = 100, а второй = 99.

Чтобы ошибка не возникала, такую ситуацию нужно исключить.

Вот способ её воспроизведения, чтобы не приходилось делать слишком долгие тесты:

Если создать подписку с частотой 100 мс. и выставить таймер чтения статуса сервера почаще (например каждые 2 секунды), то вероятность воспроизведения ошибки вырастет многократно, т.к. PublishRequest + ReadRequest будут передаваться значительно чаще.

Вот инструкция для UaExpert по шагам:
1. В меню "Settings -> Configure UaExpert" выставляем "General.WatchdogTime" = 2000 и "General.WatchdogTimeout" = 2000. Теперь UaExpert будет каждые 2 секунды читать статус сервера. Также включаем опции "Trace.SDKTraceEnabled", "Trace.StackTraceEnabled", чтобы лог был подробнее;
2. Создаём подписку на тег Saw из стандартного проекта MasterOPC и выставляем PublishingInterval = 100 мс. Теперь UaExpert будет чаще посылать PublishRequest.
В результате этих действий вероятность одновременного выполнения запросов "PublishRequest + ReadRequest" вырастет и ошибка будет возникать чаще. В наших тестах она возникла через 6 часов теста, а в другой раз через всего три минуты.

Также поставил последнюю версию UaExpert с сайта разработчика, и одновременно к одному ОРС UA подключил локально установленную SCADA и UaExpert. Снимок во вложении. Интересно, что за сравнительно небольшой период у SCADA в логах было одно переподключение, а у UaExpert нет. Понятно, что у каждого клиента своя подписка и событие для каждого клиента произойдет не одновременно (или вообще не произойдет для какого то из них)
прим.: на картинке 09:14 последнее время события в UaExpert, он был запущен ранее и больше событий в логах нет, а SCADA была запущена позже

В чем смысл данного теста? Ошибка выявлена, её причины подробно описаны, не видим смысла тратить время на решённый вопрос и рассматривать результаты новых тестов. Она может вообще никогда не возникать (и она, конечно, не будет возникать одновременно для разных UA-клиентов). У неё просто есть вероятность, которая зависит от частоты выполнения PublishRequest и ReadRequest со стороны UA-клиента. Если скада это делает чаще, то и вероятность ошибки в журнале скады увеличится. Возможно есть также небольшая зависимость от производительности ПК. Если есть сомнения в описанном, то Вы можете самостоятельно сделать снимок трафика через Wireshark, посмотреть на пакеты ответов UA-сервера, сравнить номера последовательностей и убедиться в наличии проблемы (пример разбора снимка для UaExpert на скринах во вложении).

Если вышеописанной информации недостаточно для решения проблемы, то, к сожалению, не знаем что ещё можно добавить.

[Eugene_]

Вопрос к вашей стороне закрыт. Служба поддержки Insat подтвердила обнаружение этой проблемы в рабочей переписке. Ждём исправления.