Simple-Scada forum
Simple-Scada 2 => Ваши вопросы => Тема начата: Alexander S от 18 Февраля 2021, 15:22:50
-
Ошибка: Simple-Scada Server может завершить работу без отключения от OPC-сервера.
Возникает при перезагрузке, при завершении работы Windows, при выходе пользователя из учетной записи с запущенным в Simple-Scada Server проектом.
Может стать источником возможной утечки ресурсов OPC-сервера.
Ошибка наблюдается в Simple-Scada 2.5.1.0 с подключением по OPC-DA к MasterOPC Universal Modbus Server 5.0.1.
Параметры работы Simple-Scada Server:
- отключен запуск при старте Windows;
- включен автоматический запуск проекта;
- проект не деактивируется, если у него нет клиентов.
Запуск приложения (не сервиса) Simple-Scada Server - при входе пользователя в учетную запись.
-
Здравствуйте.
Simple-Scada Server может завершить работу без отключения от OPC-сервера.
Сервер скады при завершении работы проекта всегда выполняет отключение от OPC-сервера. Отключение происходит в соответствии со спецификацией OPC-DA и поэтому оно совершенно одинаково для всех OPC-DA серверов.
Ошибка наблюдается в Simple-Scada 2.5.1.0 с подключением по OPC-DA к MasterOPC Universal Modbus Server 5.0.1.
Как Вы определили, что отключения не произошло? У нас все отключается корректно (в нижней части окна OPC-сервера отображается строка "Клиенты DA". После подключения из скады значение равно 1, после деактивации проекта 0, значит отключение проходит корректно). При желании можете установить другой OPC-сервер, например, arOPC или Kassl dOPC Simulation Server и проверить с ними (код отключения одинаков для всех DA-серверов, в этом суть OPC-DA). У нас от них тоже отключение происходит корректно и при выключении сервера скады и при деактивации проекта.
Может стать источником возможной утечки ресурсов OPC-сервера.
Почему будет утечка? Любая программа должна предусматривать освобождение ресурсов, чтобы не допустить нехватки памяти (независимо от того было ли отключение штатным или нет). Если она этого не делает, то память накапливается и приложение завершается с ошибкой. Это обычная утечка памяти. OPC-сервер должен освобождать ресурсы после того как связь с клиентом была потеряна, ведь связь не всегда может быть корректно разорвана. Например, в нестабильной сети связь всегда будет теряться мгновенно, без возможности корректного отключения и, если OPC-сервер этого не предусматривает, он будет постепенно растрачивать память и зависать в итоге. Но это никак не касается скады. Скада всегда освобождает ненужные ресурсы, например, при аварийном отключении OPC-сервера все связанные с ним данные освобождаются. Аналогично это должен предусматривать и OPC-сервер.
-
Ошибка возникает при перезагрузке, при завершении работы Windows, при выходе пользователя из учетной записи с запущенным в Simple-Scada Server проектом.
В нижней части окна OPC-сервера отображается строка "Клиенты DA - 1". Лог Simple-Scada Server обрывается, в нем нет завершающих строк остановки сервера.
Согласен, что здесь наблюдается "косяк" OPC-сервера, но это не оправдание для такого-же поведения SS2.
-
По описанию похоже, что сервер не завершает работу корректно, а выключается аварийно (как если бы был выключен через диспетчер задач Windows). Возможно сервер скады просто не успевает корректно завершить работу за отведенное ему в Windows время и ОС выключает его аварийно. Попробуем сделать чтобы сервер сигнализировал ОС о том, что ему нужно дополнительное время, может быть это поможет.
возникает при перезагрузке, при завершении работы Windows, при выходе пользователя из учетной записи с запущенным в Simple-Scada Server проектом
Видимо в этом вся проблема. В таких условиях стандартное приложение сервера скады не сможет работать корректно, т.к. оно рассчитано на работу под конкретной учетной записью в постоянном режиме. В таком случае правильнее было бы установить сервер как службу (https://simple-scada.com/help/manual/installation-as-service.html), т.к. служба создана для того чтобы работать независимо от учетных записей Windows.
-
Установка Simple-Scada Server как службы не поможет при перезагрузке и при завершении работы Windows.
Возможно, сервер скады не получает WM_CLOSE, это нормально. И не похоже на проблемы с таймингом. Проверьте работу обработчиков сообщений WM_CLOSE, WM_DESTROY, WM_QUIT.
-
Установка Simple-Scada Server как службы не поможет при перезагрузке и при завершении работы Windows.
Служба по другому обрабатывает сообщения Windows и сам процесс завершения работы, она должна работать корректно и при завершении работы Windows и при смене пользователя. На всякий случай в ближайшем будущем перепроверим. Суть в том, что утечки которых Вы хотите избежать не имеют никакого смысла при завершении работы WIndows, ведь вся память будет стёрта как только ОС выключится. И при следующем запуске ОС память будет заполняться в нуля. Таким образом утечка может накапливаться только если завершать сеанс пользователя, затем снова входить и подключаться к OPC-серверу и повторять эти действия очень много раз, пока OPC-сервер не зависнет.
Проверьте работу обработчиков сообщений WM_CLOSE, WM_DESTROY, WM_QUIT.
Это не те события. Для завершения работы при выключении ОС используются события WMEndSession и WMQueryEndSession и скада конечно обрабатывает их. Причина видимо, как мы писали ранее, в том, что серверу нужно больше времени на завершение работы, чем даёт ОС (или может быть сервер рано ответил что готов к завершению работы ОС). Теоретически это можно исправить запросив больше времени у ОС. Поэтому попробуем сделать чтобы сервер сигнализировал ОС о том, что ему нужно дополнительное время, может быть это поможет.
UPD: проверили со службой. Сервер как служба завершает работу правильно. Проект и OPC-серверы останавливаются тоже корректно, логи полные. Вы пробовали установить сервер как службу?
-
вся память будет стёрта как только ОС выключится
Это произойдет, только если OPC-сервер находится на этом-же компьютере.
С переходом на OPC-UA все чаще это другие ПК или ПЛК, каждый со своим uptime, который может быть о-очень большим.
Вы пробовали установить сервер как службу?
В демо-версии сервера как службы нет.
Проверить в лицензионной версии смогу позже, когда буду на объекте.
Скада-сервер как служба уже вышел из бета-версии?
-
OPC-UA не имеет практически ничего общего с DA. И в отличие от DA он хорошо подходит для работы для нестабильной сети и нештатного отключения клиентов, т.к. для поддержания связи предусмотрены специальные методы и проблемы с соединением всегда можно обнаружить, независимо от величины таймаута. Поэтому с OPC-UA такие проблемы просто невозможны (либо возможны в крайнем случае, когда OPC-сервер не соответствует с стандарту UA, мы с такими не сталкивались).
Пожалуйста, напишите конкретно с какими OPC-серверами Вы планируете работать (DA, UA или оба сразу). Удаленные ли это сервера, или локальные? Планируете ли настраивать DCOM для OPC-DA серверов? Планируется ли на серверном ПК периодически завершать сеанс пользователя не перезапуская сервер? Тогда мы сможем дать Вам точный ответ что именно и как нужно установить чтобы не возникало проблем.
Мы пока не можем представить реальный проект (и на практике пока не сталкивались с таким) в котором перезапуск ОС или завершение сеанса могли бы привести к каким-то реальным проблемам. Для OPC-DA это теоретически возможно, но нужно работать удалённо, через DCOM и получить проблемы гораздо легче из-за сети, чем из-за перезагрузки серверного ПК. Причем обязательно нужен DA-сервер который никогда не освобождает ресурсы (мы даже не знаем, есть ли реально утечка памяти в DA-сервере который Вы используете, может быть он очистит ресурсы через время). Через UA описанная Вами проблема вообще не может возникнуть.
Также мы пока не видим реальных проблем в скаде. При выключении ОС сервер завершает работу максимально быстро, не блокируя выключение ОС. Сервер действительно может выключиться без прямого отключения от DA-сервера. Но это обычная ситуация, нет никаких требований которые обязывали бы OPC-клиентов всегда отключаться с уведомлением сервера. В сети таких требований и не может быть, т.к. сеть может быть нестабильной. Утечек памяти в скаде тоже нет.
Если мы правильно поняли, то в данный момент Вы опасаетесь что всё будет плохо работать, когда Вы сделаете проект? Что DA/UA серверы будут вылетать с ошибками? Но пока не запускали ни сервер как службу ни OPC-UA сервер? Если да, то рекомендуем не предполагать, а именно выполнить установку сервера как службы, как и писали ранее. Если у Вас есть возможность использовать UA-сервер, то рекомендуем использовать его, т.к. DA давно устарел (особенно плох и небезопасен для удалённого подключения).
Скада-сервер как служба уже вышел из бета-версии?
Пользователи уже используют, мы всё ещё тестируем, но пока нет никаких известных проблем.
-
У меня нет вопросов как и с какими OPC-серверами работать, как использовать скаду.
Мы пока не можем представить реальный проект (и на практике пока не сталкивались с таким) в котором перезапуск ОС или завершение сеанса могли бы привести к каким-то реальным проблемам.
Когда возникли небольшие, вполне решаемые затруднения при перезагрузке компьютера, была определена исходная причина - неправильная остановка скада-сервера.
Поэтому появился первый пост.
Сейчас проверил следующий кейс:
- на скада-сервере запускаем демо-проект, в котором нет подключений к OPC-серверу и серверу БД;
- выходим из учетки;
- смотрим лог - завершение работы сервера скады прошло без деактивации проекта, без отключения клиента системы отчетов, без остановки сервера.
Т.о. ошибка возникает в скаде, а не во взаимодействии с OPC-сервером.
Можно ожидать, что исправите?
-
без отключения клиента системы отчетов, без остановки сервера
Так и должно быть. При выключении ОС/при выходе из системы задача сервера - как можно быстрее завершить работу, что он и делает. Ожидание остановки системы отчетов и остановки сервера приведёт только к ухудшению (ведь они остановятся в любом случае, т.к. ОС выключается), ОС придётся дольше ждать выключение сервера скады, чем сейчас. При этом никакой практической пользы не будет, только вред.
Можно ожидать, что исправите?
Исходя из вышеописанного можем добавить только деактивацию проекта перед выключением, чтобы сервер наверняка выполнил оставшиеся задачи связанные с проектом. В этом есть смысл. Остановку сервера скады и системы отчетов точно добавлять не будем. Отключение от OPC-серверов скорее всего не добавим. За прошедшие дни сделали тесты с отключением от OPC при выключении ОС и тоже стало только хуже, потому что возникает проблема: если OPC-сервер на том же ПК, что и сервер скады (в большинстве случаев так и есть), то при выключении ОС приложение OPC-сервера может выключиться первым (до выключения сервера скады), получив сигнал WMEndSession. И тогда сервер скады вынужден выждать таймаут, чтобы понять, что связь с OPC-сервером потеряна и теперь можно выключиться. Так для каждого OPC-сервера в проекте. В результате ОС приходится долго ждать выключения сервера скады и ОС выдаёт сообщение, что есть программы которые не позволяют завершить работу системы.
-
Спасибо за данные пояснения.
Проверил завершение работы скада-сервера как службы при перезагрузке компьютера с запущенным проектом, в котором используется подключение к СУБД и OPC-DA-серверу на этом-же компьютере.
Судя по логу скада-сервера, он останавливает сервер, а далее пытается что-то выгрузить в БД, которая к этому моменту, похоже, уже не отвечает. В результате через 5 секунд его принудительно останавливает система. Отключения от OPC-сервера в логе нет.
Прихожу к выводу, что процедура завершения работы скада-сервера не предусматривает возможные отказы программ-партнеров, при этом сама провоцирует их на возможный отказ.
-
Судя по логу скада-сервера, он останавливает сервер, а далее пытается что-то выгрузить в БД, которая к этому моменту, похоже, уже не отвечает.
При выключении проекта выполняется запись архивных данных из очереди. Её длительность зависит от количества архивных данных и количества пользовательских SQL-запросов в очереди.
Прихожу к выводу, что процедура завершения работы скада-сервера не предусматривает возможные отказы программ-партнеров.
Перепроверим запись данных в БД при остановке службы MySQL. Возможно скада в случае остановки службы СУБД пытается выполнить каждую вставку из очереди выжидая таймаут. Тогда выключение действительно будет слишком долгим и это можно будет устранить.
при этом сама провоцирует их на возможный отказ
Не совсем понятно каким образом можно спровоцировать какую-либо СУБД на отказ? В Вашем случае вроде бы отказов не было, судя по описанию служба СУБД уже была остановлена в момент выключения скады, из-за чего и возникла данная ситуация. Или у Вас СУБД вылетела с ошибкой? Если да, то просьба выслать текст ошибки.
Интересно также, что на четырёх тестовых ПК (с ОС Windows 10 и Windows 7) служба СУБД всегда выключается после службы сервера скады, выполняя все необходимые операции по архивации и проблем с выключением не возникает. Возможно в ОС можно как-то задать порядок выключения служб. Может быть нужно добавить в ОС зависимость службы СУБД от сервера скады.
-
Уточняю: в проекте используется СУБД MS SQL Server Express Edition.
При остановке наблюдаемой ошибки SQL-сервера нет. Если что-то увижу в его логе - сообщу.
В СУБД действительно тяжело получить отказ. А вот в OPC-сервере, как оказалось, просто.
-
Возможно скада в случае остановки службы СУБД пытается выполнить каждую вставку из очереди выжидая таймаут.
Проверили. Это предположение подтвердилось. Если остановить службу СУБД раньше, а потом попытаться выключить сервер скады то все запросы пытаются выполниться с таймаутом. Сделаем по-другому: если первый выполнился с таймаутом, то все остальные запросы будут удалены из очереди без попыток выполнить их. В результате, если СУБД выключится раньше сервера скады, то сервер скады будет выключаться дольше чем обычно (т.к. один таймаут выждать всё равно придётся чтобы понять, что с СУБД что-то не так) но не так долго, как сейчас.
В СУБД действительно тяжело получить отказ. А вот в OPC-сервере, как оказалось, просто.
По вопросам, связанным с работой другого ПО можно обратиться к разработчикам этого ПО. Мы не можем из своего кода исправить другое ПО независимо от того СУБД это или OPC-сервер, или другая программа.
-
Мы не можем из своего кода исправить другое ПО
Этого не требуется.
Надо только в своем ПО придерживаться правильного порядка завершения работы. Работа СУБД показывает, что это возможно.
-
Решили подвести итог по результатам последних тестов. В ближайшем обновлении в скаду будет добавлено только одно изменение которое слабо касается описанных Вами вопросов, а именно: сервер скады будет быстрее выключаться, если служба СУБД в этот момент остановлена. Другие изменения, к сожалению, принесли только отрицательные результаты и добавлены не будут.
В результате тестов мы приходим к выводу что единственным приемлемым для Вас вариантом будет блокирование выключения ОС / выхода из учетной записи со стороны сервера скады. Старые версии скады работали так, но мы ушли от этого по двум причинам:
1. Несоответствие документации Microsoft, согласно которому приложение получившее от ОС сообщение WM_ENDSESSION должно забыть о выполнении обычных задач, как можно быстрее сохранить критические данные во временном хранилище и затем в любой момент быть готовым к выключению со стороны ОС.
2. Пользователи, у которых сигнал о выключении ПК даёт источник бесперебойного питания жаловались, что скада блокирует выключение ОС.
Текущая версия скады правильно работает по двум пунктам, поэтому возвращаться к старому варианту мы не планируем.
За последние восемь дней нам не удалось найти описанные Вами «ошибки» / «проблемы» в работе скады. Вот краткие выводы по ним:
Согласен, что здесь наблюдается "косяк" OPC-сервера, но это не оправдание для такого-же поведения SS2.
Мы не обнаружили «такого-же» поведения со стороны скады. Вы можете убедиться в этом самостоятельно, запустив проект в скаде и выключая через диспетчер задач OPC-серверы. Скада будет освобождать ресурсы, связанные с разорванным подключением, хотя OPC-сервер не уведомлял её о разрыве связи и не выполнил корректного отключения. Аналогично можно аварийно завершать работу СУБД. Скада также освободит ресурсы, связанные с разорванным подключением к СУБД. Таким образом «такого-же» поведения со стороны скады нет, Вам показалось.
Возможно, сервер скады не получает WM_CLOSE, это нормально.
Для нас это не нормально, если приложение не получает (или не обрабатывает) сообщения от ОС. Как мы писали ранее скада получает и реагирует на сообщения Windows, иначе попытки выхода не происходило и выключение ОС блокировалось бы с сообщением о том, что есть программы, которые ожидают завершения работы. Как описано выше сейчас скада обрабатывает сообщение WM_ENDSESSION в соответствии с рекомендациями Microsoft, избегает блокирования ОС в момент выхода и предусматривает сохранение критически важных данных.
смотрим лог - завершение работы сервера скады прошло без деактивации проекта, без отключения клиента системы отчетов, без остановки сервера.
Т.о. ошибка возникает в скаде, а не во взаимодействии с OPC-сервером.
Вам снова кажется, что есть какая-то «ошибка» в скаде. Это умышленное поведение в соответствии с сигналом от ОС. Завершение работы ОС – это принудительное выключение, на которое отводится мало времени. Программы не должны заботиться о некритичных задачах. Главное как можно быстрее сохранить критические данные, чтобы не возникло сбоев при последующем запуске. Нет смыла записывать красивые логи или останавливать систему отчетов. Прочесть о реакции программ на сообщения Windows можно в интернете.
Изначально (см. сообщение #9) мы хотели добавить попытку деактивации проекта при выключении ОС. Но после проведения тестов выяснили что это бесполезно, т.к. никаких критических данных не теряется в любом случае. Сервер как служба выполняет попытку деактивировать проект, но суть не меняется, т.к. теперь, как Вы пишете, СУБД выключается раньше и сервер вынужден ждать таймаут на который у ОС нет времени.
Прихожу к выводу, что процедура завершения работы скада-сервера не предусматривает возможные отказы программ-партнеров
Вывод очевидно неправильный. Мы предприняли несколько попыток, но не смогли понять точное значение термина «отказ». Возможно речь об аварийном завершении работы или ошибках внутри сторонних программ. Вы можете как угодно (аварийно или нормально) выключать/перезапускать любые сторонние приложения, с которыми работает сервер скады. Сервер не зависнет, не вылетит с ошибкой именно потому, что он предусматривает любую реакцию со сторону других программ.
при этом сама провоцирует их на возможный отказ.
Здесь также непонятно в чем выражается «отказ» и как он касается скады. Прочтите предыдущие сообщения в теме. Там мы писали: «Сервер действительно может выключиться без прямого отключения от DA-сервера. Но это обычная ситуация, нет никаких требований, которые обязывали бы OPC-клиентов всегда отключаться с уведомлением сервера. В сети таких требований и не может быть, т.к. сеть может быть нестабильной.». Не знаем, как можно описать ещё подробнее. Если Вы подразумеваете под «отказом» то, что OPC-сервер не уменьшает счетчик подключений при аварийном разрыве связи, то причем здесь скада? Скада при аналогичных действиях со стороны OPC-сервера уменьшает счетчик подключений и удаляет связанные с ним ресурсы. И при этом мы не обвиняем OPC-сервер в том, что он «провоцирует скаду на отказ», хотя это было бы очень удобно. Важно также понять, что нам до сих пор неизвестно, существует ли какая-то проблема, есть ли реально утечка памяти в DA-сервере, который Вы используете, может быть он очистит ресурсы через время или по превышению количества подключений. Даже если этого не произойдёт, то мы не сможем исправить это, т.к. не можем менять работу другого ПО.
Надо только в своем ПО придерживаться правильного порядка завершения работы. Работа СУБД показывает, что это возможно.
Когда сервер скады работает как служба, он придерживается самого обычного порядка завершения работы (точно такого же, как при обычном выключении в работающей ОС), от наиболее важных к наименее важным. Выполняется стандартная деактивация проекта, сначала сохранение восстанавливаемых переменных, затем запись архивных данных и отключение от СУБД (чтобы сохранить последние данные в БД) и от OPC-серверов (и СУБД и OPC-серверы работают в отдельных потоках и они одновременно помечаются на выключение. Далее успеют ли они выключиться зависит от многих факторов). Если в момент выключения сервера служба СУБД уже выключена, то очевидно, что для выполнения финальных запросов придётся выжидать таймаут на запросы (как минимум один) и выключение затянется. Аналогично с OPC-серверами. В результате ОС может принудительно выключить сервер скады если время выйдет. Т.к. мы не можем повлиять на порядок выключения служб и ПО на Вашем ПК, можем только порекомендовать попробовать добавить зависимость служб в Windows. Может быть это поможет. Если СУБД будет активна в момент выключения, то сервер скады быстро отправит архивные данные и отключится и в теории может больше времени уделить отключению от OPC-серверов (но нет гарантии, что успеет). Исходя из вышеописанного, мы не видим причин добавлять изменения в порядок завершения работы (или выполнять отключение от OPC-серверов в самую первую очередь) ради счетчика подключений в окне OPC-сервера, который нас не касается и возможно вообще не является реальной проблемой. Для этого нужны какие-то веские (а не гипотетические) причины, которые принесут реальную, а не мнимую пользу.
Попытались дать максимально развёрнутый ответ по всем вопросам в этой теме. Часть информации выходит за рамки тех. поддержки и касается работы ОС, её мы также постарались описать. Если наши выводы оказались непонятными или неправильными для Вас, то что-то добавить, мы, к сожалению, не можем. Если счетчик подключений в окне OPC-сервера является ключевым для Вас, то единственным решением будет обратить внимание на SCADA-системы других производителей. Возможно какие-то системы в первую очередь пытаются отключиться от OPC-серверов или блокируют выключение ОС.