Simple-Scada forum
Simple-Scada 2 => Ваши вопросы => Тема начата: Серега от 09 Сентября 2021, 13:18:23
-
Добрый день!
Столкнулись со следующей ситуацией.
У нас на отдельных виртуальных машинах стоят:
1. Инсат ОРС Modbus сервер (v5.0.3) (UA) + демо arOPC (для тестирования фишек)(v1.84.182.1835)
2. Сервер Simple-scada (v2.5.8.1)
И клиенты.
На версии SS (v2.5.8.1) в связке с ОРС Инсат все работает.
Ставим версию v2.5.9.0 или v2.5.10.0 правильность работы вызывает сомнения. В чем заключается:
1. В ОРС UA качество переменных good. На клиенте !. При этом в ходе тестирования знаки появляются рандомно. И не на всех переменных
2. При нажатии на кнопку и видя, что команда отправлена через ОРС большая часть ! знаков уходит. Но часть остаётся.
3. При нажатии на кнопку с командой довольно часто кнопка зависает. Через какое то время при повторном нажатии может отвиснуть и принять первоначальное положение.
4. Есть два хардбита. Один ПЛК->СКАДА второй СКАДА -> ПЛК. До и включая v2.5.8.1 графики ровные без рывков. После "корявые", как бы с задержкой что-ли.
Что делали:
1. Отключали полностью брандмаузер на обоих и по отдельности.
2. Запускали и то и то под админом
3. Меняли настройки шифрования в редакторе
4. Меняли доступ и на ОРС и на скаде по паролю
Допускаю, что после телефонных консультаций с техподдержкой версия ОРС компонентов для OPC UA не влияет и не нужна.
Допускаю, что согласно руководству на появление ! влияет качество переменных и брандмаузер. Но качество хорошее, брандмаузер отключили.
Допускаю, что возможно у меня не последняя версия update. Но пришло письмо со ссылкой и телефонный разговор с суппортом потвердил, что по ссылке последняя версия ПО СКАДЫ (На всякий случай если есть возможность письмом перешлите ссылку)
В общем пока мне не понятно в чем проблема. Возможно Вы прольете свет на тьму не понимания!
Жду вопросов и ответов!
-
Здравствуйте.
Нашли возможную причину. Позже напишем о результатах проверки.
-
Обновили. Скачайте последнюю версию скады 2.5.10.0 повторно (ссылки те же) и установите её. После этого значения на мнемосхемах должны обновляться правильно.
-
Добрый день!
Обновил. Все работает в штатном режиме. Описанных выше явлений не наблюдаю.
Отдельное спасибо за быструю реакцию.
-
Есть вопрос к этому же последнему релизу - .10. Файл demo64 и demo-time на сайте какую версию содержат ?
При использовании demo64 появилась некоторая проблема, достаточно стабильная - самопроизвольно и без ошибки зависает клиент, точнее, судя по логу в сервере - отключается и заново не подключается.
Установка типовая - сервер и клиент на одной машине, запущены как приложения. Ранее работало стабильно в этом же окружении, поменялась только версия SCADA с .9 на .10. Зависание происходит где то после 2-5 часов работы. Используется несколько тегов (тестовый проект системы мониторинга, проверки различных доработок до переноса в продукт). На основой инсталляции SCADA с последним скачанным релизом .10 проблем не наблюдается с зависанием клиента, но там клиенты на отдельных ПК.
-
Здравствуйте.
Файл demo64 и demo-time на сайте какую версию содержат ?
На сайте всегда размещены актуальные демо-версии, на данный момент версии 2.5.10.0. Проверить, какая версия используется можно запустив сервер скады - номер версии отображается на вкладке "Состояние сервера (https://simple-scada.com/help/manual/server-status.html)".
При использовании demo64 появилась некоторая проблема, достаточно стабильная - самопроизвольно и без ошибки зависает клиент
Изменений в работе клиента между указанными версиями не было. Если происходит зависание клиента, то значит имеются проблемы с видеокартой, драйверами на видеокарту и т.д. Рекомендуемые действия для такой ситуации можно посмотреть по ссылке (https://simple-scada.com/help/manual/faq-other.html?anchor=q21). Если используется виртуальная машина, то также нужно установить требуемые компоненты - инструкции для VirtualBox и VMware можно найти по ссылке (https://simple-scada.com/help/manual/faq-other.html?anchor=q1). Также, следует проверить настройки виртуальной машины, возможно причина в них. Например, в этой теме (https://simple-scada.com/forum/index.php?topic=964.msg8128#msg8128) год назад Вы задавали подобный вопрос и вероятнее всего тогда проблема была в отключенном параметре "Enabled 3D Support" на виртуальной машине.
На основой инсталляции SCADA с последним скачанным релизом .10 проблем не наблюдается с зависанием клиента
Это только подтверждает, что на проблемном ПК имеются какие-то неполадки в работе видеокарты, драйвера или проблема в каких-либо настройках оказывающих влияние на работу видеокарты и нужно устранить эти проблемы.
-
Зависание происходит где то после 2-5 часов работы. Используется несколько тегов (тестовый проект системы мониторинга, проверки различных доработок до переноса в продукт). На основой инсталляции SCADA с последним скачанным релизом .10 проблем не наблюдается с зависанием клиента, но там клиенты на отдельных ПК.
Это точно проблема в машине, тоже есть объект где начали появляться зависания клиента, но там версия вообще 2.5.7.0. На других компах с 5.9 и 5.10 такого не наблюдалось
-
Нет коллеги, проблема не аппаратная, так как все установлено на виртуальных машинах. Вот скриншоты.
В случае прерывания соединения по ОРС UA SCADA в последнем релизе некорректно восстанавливает соединение. Само соединение судя по логам в сервере восстановлено, но визуализация висит. Причем, отметил на первой картинке - для локального ОРС UA SCADA показывает статус Bad и значение не меняется, а для удаленной - не показывает, но также значение не меняется.
К сожалению не могу заменить/переустановить Demo версии 10 на версию 9 без создания нового проекта, так как downgrade проекта не предусмотрено, если проект в 10-ке то в 9-ке не открыть. В первом сообщении возможно неверно выразился, "зависание" - в смысле прекращение изменений/обновлений значений на странице проекта, а не зависание всего проекта без реакции.
На картинке ниже - уже с 18:29 SCADA висела после первого обрыва. График контрольной переменной, циклически меняющейся, в архиве ровный (последнее значение), а не пилообразный.
-
касательно VM - в данном случае была заменена только версия SCADA .9 на .10 и проблема зависания при прерывании появилась практически в тот же день. Сначала было решено что одиночная ошибка, но оказалось что стабильно проявляется. Ничего больше не менялось, ни версии ПО на VM ни настройки VM
-
В первом сообщении возможно неверно выразился, "зависание" - в смысле прекращение изменений/обновлений значений на странице проекта, а не зависание всего проекта без реакции.
Понятно. Значит проблема вообще не касается клиента скады, ведь все изменения/обновления получает от OPC-сервера и передаёт клиенту - сервер скады. По последнему описанию похоже что после переподключения к UA-серверу публикация изменений не восстановилась по каким-то причинам. Уточните, в проекте используется три OPC-сервера? Два из них это локальный и удалённый Insat Modbus сервер (UA), а третий это arOPC (DA)? Других OPC-серверов нет? Каким образом разрывается связь? Вы вручную останавливаете/перезапускаете UA-сервер, или отключение происходит в результате проблем в сети между ПК с сервером скады и ПК с OPC-сервером?
-
>>в проекте используется три OPC-сервера?
В этом, отдельном тестовом проекте - два. Локальный demo Insat и удаленный с ключом Insat. Прерывается соединение и восстанавливается - от обоих, что странно. В логах имена скрыл.
>>в результате проблем в сети между ПК с сервером скады и ПК с OPC-сервером
прерывание возможно в результате проблем этих, но маловероятно, так как - прерывается связь и с локальным сервером OPC UA, установленным тут же на ПК с сервером SCADA. С локальным сервером вообще никак не взаимодействую (не прерываю соединение принудительно), запущен постоянно и всегда статус переменных в нем ОК и значения меняются.
Сейчас снова перезапустил проект, посмотрю сколько проработает при визуальном наблюдении процесса.
-
Сейчас сделаем аналогичные тесты с локальным MasterOPC и удаленным.
-
Сейчас сделаем аналогичные тесты с локальным MasterOPC и удаленным.
Вот снова зависла таким образом. При этом и локальный ОРС UA как bad отобразился, но сам ОРС UA работал без ошибок. Попробовал перезапустить вручную ОРС сервер локальный - данные стали отображаться, связанные с ним. Данные со второго сервера, удалённого, остаются в статусе в bad. Полагаю, что если его перезапустить то обновление связанных с ним переменных также восстановится.
Пояснение:
- dmz - это сервер где стоит локальный ОРС UA + SimpleScada demo64
- орс - удаленный сервер с ОРС UA
- 14:22:08 - ошибка при перезапуске локального ОРС, это нормально.
-
Удалось повторить проблему после разрыва с Bad_Timeout. В ближайшее время внесём изменения и сделаем обновление.
-
Внесли изменения в обновление 2.5.11.0. Теперь после Bad_Timeout подписка должна правильно возобновляться.
-
да, теперь все нормально. Спасибо.
-
Все же прошу разработчиков вернуться к этому вопросу. Не все нормально в релизах .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.
-
Ошибка Bad_Timeout выдаётся в следующих случаях:
1. UA-сервер не ответил на запрос со стороны скады за время заданное для UA-сервера в поле Request timeout (https://simple-scada.com/help/manual/opcuanew.html?anchor=uapar) (из меню Проект -> 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 сервера - обрывов нет, все работает четко и надежно.
Это подтверждает вышеописанное, т.к. в старых версиях на операции отводилось больше времени, но это плохо влияло на выявление проблем связи, поэтому время было уменьшено.
-
в 2.5.6 есть раздельное время настройки этих параметров. Для проверки уменьшить менее чем до 8000ms не дает. Есть какие то внутренние переменные в коде ПО, не относящиеся к настройкам, о которых вы говорите ? На тестовом сервере сейчас были такие настройки как на картинке и нет ни одной ошибки за 3 суток. В тестовом проекте два контроллера, с которых также опрашивается пилообразно меняющееся значение переменной.
Сейчас оба параметра выставил в минимальные 8000 мс , пронаблюдаем.
-
Для версии 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-сервер перестал отвечать и как долго он не отвечал (либо будут видны какие-то проблемы с трафиком и т.п.).
-
Внесли изменения в обновление 2.5.12.0. Теперь скада в случае Bad_Timeout во время проверки статуса делает ещё одну попытку чтения статуса (с меньшим таймаутом). Если и вторая попытка закончится неудачно, то будет выдана ошибка. Если после обновления ошибка Bad_Timeout продолжает возникать, то можно в окне расширенных настроек UA-сервера (https://simple-scada.com/help/manual/opcuanew.html?anchor=uapar) изменить время в поле "Проверка статуса" на 10000 или 12000. Также можно попробовать увеличить время в поле "Таймаут запросов" до 12000 или 14000.
-
В недавних тестах обнаружили, что на нескольких ПК возникают периодические проблемы с ошибкой Bad_Timeout при работе с OPC-сервером MasterOPC во время чтения статуса сервера. С другими UA-серверами такая же проблема не возникает. В обновлении 2.5.14.0 мы изменили процесс чтения статуса, теперь данная ошибка не должна возникать без повода.
-
в релизе 2.5.15.0 (beta) указано
1. >> OPC-UA: исправлено долгое ожидание подключения/переподключения, когда связь с сервером нарушена;
это исправление ошибки релизов 2.5.14.0 - 2.5.12.0 ? в смысле - это изменение (ошибка) появившаяся в этих релизах или это исправление какой-то боле ранней ошибки более ранних релизов ?
2. >>разрывы в трендах теперь всегда отображаются без "падения" тренда;
подскажите, как теперь узнавать что в какой то момент времени статусы тегов были Bad или не было связи с ОРС (проблема у ОРС) ? как это будет отображаться на графиках ? если есть пример картинки было бы хорошо. Режим трендов и графиков "ступенчатый" используется.
-
это исправление ошибки релизов 2.5.14.0 - 2.5.12.0? в смысле - это изменение появившаяся в этих релизах или это исправление какой-то боле ранней ошибки более ранних релизов?
Так было во всех пред. версиях. Стоял долгий сетевой таймаут в моменты подключения/переподключения к UA-серверу. Он практически не используется в реальных ситуациях, т.к. сбой сети обычно определяется по сообщениям поддержания активности / периодической проверкой статуса UA-сервера.
подскажите, как теперь узнавать что в какой то момент времени статусы тегов были Bad или не было связи с ОРС (проблема у ОРС) ? как это будет отображаться на графиках ? если есть пример картинки было бы хорошо. Режим трендов и графиков "ступенчатый" используется.
Будут обычные разрывы в трендах, без "лишних" линий падения на ноль (ведь падения в реальности не было). Касаемо статуса тегов и bad-качества - ничего не изменилось в новой версии.
-
Будут обычные разрывы в трендах, без "лишних" линий падения на ноль (ведь падения в реальности не было). Касаемо статуса тегов и bad-качества - ничего не изменилось в новой версии.
Подскажите, а как-то можно избежать появление "падения тренда" при старте проекта после остановки на сервере?
По примеру на ScreenShot в Вашем сообщении все переменные приняли значение =0 в 17:53:45.
Или это особенность взаимодействия с OPC-сервером (который стартует возможно медленнее чем успевает запуститься архивация) и от нее никуда не деться?
-
Подскажите, а как-то можно избежать появление "падения тренда" при старте проекта после остановки на сервере?
В последних версиях для внешних тегов первая точка добавляется после полного подключения к OPC-серверу, поэтому линии не будет (если OPC-сервер реально не возвращает сначала 0, а затем настоящее значение). На скрине из пред. сообщения тренды основаны на внутренних переменных, которые сначала равны 0, а затем начинают меняться. Если нужно чтобы внутренние переменные не стартовали с нуля, то нужно включить у них автоматическое восстановление (https://simple-scada.com/help/manual/varmain.html).
-
В недавних тестах обнаружили, что на нескольких ПК возникают периодические проблемы с ошибкой 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
-
В случае аварийного разрыва связи с UA-сервером (т.е. после Bad_Timeout) скада не сможет штатно удалить подписки (т.к. связь разорвана) и они могут быть активны на OPC-сервере ещё некоторое время. После переподключения скада создаст новые подписки. И если она обнаружит, что старые подписки ещё существуют на OPC-сервере, то она удалит их (чтобы не передавать лишние данные и не нагружать UA-сервер) и выдаст сообщение "delete unknown subscription" с id-подписки в журнал. По сути, после переподключения скада выполняет удаление старых подписок, которые она не смогла корректно удалить из-за неожиданного разрыва связи.
-
все понятно, такое поведение нормальное, спасибо!
-
Вернусь к этому вопросу. Не удается никак найти зависимости от внешних факторов работы связки 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 и был выпущен с некоторыми поправками по этому вопросу, но проблема не ушла.
-
просто не было "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?
-
>>Вы используете 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, и с удаленного и с локального, зеленая и желтая линия соответственно.
-
Проверили. Это ошибка 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-сервера.
-
Списался с технической поддержкой Insat, также отправил ссылку на эту беседу. Говорят у них проблема не воспроизводится. Запросил возможность вести коллективную переписку тут :) и ваш продукт и их весьма широко распространены и популярны, и такая связка ПО полагаю не редкая и у кого-то еще возможно такая же проблема есть.
Также поставил последнюю версию UaExpert с сайта разработчика, и одновременно к одному ОРС UA подключил локально установленную SCADA и UaExpert. Снимок во вложении. Интересно, что за сравнительно небольшой период у SCADA в логах было одно переподключение, а у UaExpert нет. Понятно, что у каждого клиента своя подписка и событие для каждого клиента произойдет не одновременно (или вообще не произойдет для какого то из них)
прим.: на картинке 09:14 последнее время события в UaExpert, он был запущен ранее и больше событий в логах нет, а 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 на скринах во вложении).
Если вышеописанной информации недостаточно для решения проблемы, то, к сожалению, не знаем что ещё можно добавить.
-
Вопрос к вашей стороне закрыт. Служба поддержки Insat подтвердила обнаружение этой проблемы в рабочей переписке. Ждём исправления.