Решили подвести итог по результатам последних тестов. В ближайшем обновлении в скаду будет добавлено только одно изменение которое слабо касается описанных Вами вопросов, а именно: сервер скады будет быстрее выключаться, если служба СУБД в этот момент остановлена. Другие изменения, к сожалению, принесли только отрицательные результаты и добавлены не будут.
В результате тестов мы приходим к выводу что единственным приемлемым для Вас вариантом будет блокирование выключения ОС / выхода из учетной записи со стороны сервера скады. Старые версии скады работали так, но мы ушли от этого по двум причинам:
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-серверов или блокируют выключение ОС.
