Пересылка событийной информации между Scada-станциями
| Автор |
Повідомлення |
|
Повідомлення створено: 04. 08. 2012 [23:16]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3743
|
"roman" wrote:
"DJ-AMIGO" wrote:
Роман, а имеется ли возможность обработать ситуацию с длительным тайм-аутом SSL-транспорта в пользовательском скрипте?
Нет таких механизмов в libSSL.
Добавил таймаут подключения в исходящий транспорт Transport.SSL.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 08. 11. 2012 [10:53]
|
|
DJ-AMIGO
Михаил Гончаров
Автор теми
Зареєстрован(а) с: 26.05.2012
Повідомлення: 15
|
Добрый день, уважаемые участники сообщества!
После непродолжительного тайм-аута, я решил вернуться к начатому проекту.
На данный момент мне удалось выяснить, что описанные выше проблемы с непроизвольным отказом автозапуска всех DAQ-контроллеров при очередной начальной загрузке системы OpenSCADA были связаны с неправильно выбранными периодами опроса контроллеров логического уровня. Эти периоды были слишком маленькими, из-за чего система была перегружена и частенько зависала. А после очередной перезагрузки ПЛК все DAQ-контроллеры не запускались автоматически на выполнение, несмотря на выставленный флаг автозапуска в настройках DAQ-контроллера.
Следующая проблема с невозможностью повторного установления SSL-соединения с удаленной SCADA-станцией при обрыве канала связи на достаточно длительное время (достаточно около 2-5 мин.), либо с изначально отсутствующей возможностью связи с удаленной SCADA-станцией на момент старта системы. В этом случае способность передачи сообщений на удаленную SCADA-станцию утрачивалась. Решение этого недостатка было найдено экспериментально! Проблема заключалась не в SSL-транспорте как таковом, а в DAQ-контроллере логического уровня, в котором был реализован механизм отправки сообщений на удаленную SCADA-станцию. Был применен следующий нехитрый прием:
-рядом создается еще один контроллер логического уровня, в задачи которого входит отслеживание состояния работоспособности канала связи по SSL-транспорту;
-в случае неработоспособности указанного канала связи по SSL-транспорту в течение 30 сек., DAQ-контроллер осуществляющий пересылку сообщений на удаленную SCADA-станцию автоматически перезапускается.
Таким образом, DAQ-контроллер будет периодически перезапускаться до момента очередного удачного установления SSL-соединения. Данное решение оказалось очень действенным.
И последняя проблема с чрезмерно большим временем выборки из локальной очереди сообщений для длительных временных интервалов пока что не решена. Приходится разбивать выборку на более мелкие временные интервалы и выборку их в цикле для последовательного сканирования нужного интервала. Это существенно замедляет время обработки архива очереди сообщений, но другого подхода я пока что так и не придумал...
|
|
Повідомлення створено: 08. 11. 2012 [16:39]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3743
|
"DJ-AMIGO" wrote:
А после очередной перезагрузки ПЛК все DAQ-контроллеры не запускались автоматически на выполнение, несмотря на выставленный флаг автозапуска в настройках DAQ-контроллера.
Всёравно никогда у себя такого не наблюдал!
"DJ-AMIGO" wrote:
Решение этого недостатка было найдено экспериментально! Проблема заключалась не в SSL-транспорте как таковом, а в DAQ-контроллере логического уровня, в котором был реализован механизм отправки сообщений на удаленную SCADA-станцию. Был применен следующий нехитрый прием:
-рядом создается еще один контроллер логического уровня, в задачи которого входит отслеживание состояния работоспособности канала связи по SSL-транспорту;
-в случае неработоспособности указанного канала связи по SSL-транспорту в течение 30 сек., DAQ-контроллер осуществляющий пересылку сообщений на удаленную SCADA-станцию автоматически перезапускается.
Жуть! Сейчас, при наличии таймаутов всё должно нормально переподключаться за прогнозируемое время.
"DJ-AMIGO" wrote:
И последняя проблема с чрезмерно большим временем выборки из локальной очереди сообщений для длительных временных интервалов пока что не решена. Приходится разбивать выборку на более мелкие временные интервалы и выборку их в цикле для последовательного сканирования нужного интервала. Это существенно замедляет время обработки архива очереди сообщений, но другого подхода я пока что так и не придумал...
Что-то в алгоритме у Вас там некорректно поскольку реально при смещении времени головы запроса и опроса начиная от него, а не вообще, продолжительность этой операции должна быть невелика.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 09. 11. 2012 [08:31]
|
|
DJ-AMIGO
Михаил Гончаров
Автор теми
Зареєстрован(а) с: 26.05.2012
Повідомлення: 15
|
"DJ-AMIGO" wrote:
А после очередной перезагрузки ПЛК все DAQ-контроллеры не запускались автоматически на выполнение, несмотря на выставленный флаг автозапуска в настройках DAQ-контроллера.
Всёравно никогда у себя такого не наблюдал!
Роман, может быть это особенность функционирования OpenSCADA под конкретным ПЛК?
"DJ-AMIGO" wrote:
Решение этого недостатка было найдено экспериментально! Проблема заключалась не в SSL-транспорте как таковом, а в DAQ-контроллере логического уровня, в котором был реализован механизм отправки сообщений на удаленную SCADA-станцию. Был применен следующий нехитрый прием:
-рядом создается еще один контроллер логического уровня, в задачи которого входит отслеживание состояния работоспособности канала связи по SSL-транспорту;
-в случае неработоспособности указанного канала связи по SSL-транспорту в течение 30 сек., DAQ-контроллер осуществляющий пересылку сообщений на удаленную SCADA-станцию автоматически перезапускается.
Жуть! Сейчас, при наличии таймаутов всё должно нормально переподключаться за прогнозируемое время.
Я все еще не перешел на новую сборку OpenSCADA, решил попытаться разобраться со старой.
"DJ-AMIGO" wrote:
И последняя проблема с чрезмерно большим временем выборки из локальной очереди сообщений для длительных временных интервалов пока что не решена. Приходится разбивать выборку на более мелкие временные интервалы и выборку их в цикле для последовательного сканирования нужного интервала. Это существенно замедляет время обработки архива очереди сообщений, но другого подхода я пока что так и не придумал...
Что-то в алгоритме у Вас там некорректно поскольку реально при смещении времени головы запроса и опроса начиная от него, а не вообще, продолжительность этой операции должна быть невелика.
А алгоритм тут не причем! Я просто вызываю функцию get для локального архива сообщений способом, который обсуждался ранее в этом же топике:
req = SYS.XMLNode("get").setAttr("path","/sub_Archive/%2fserv%2fmess").setAttr("tm",cur_tm).setAttr("tm_grnd",cur_tm-20000).setAttr("cat","").setAttr("lev",0);
SYS.cntrReq(req);
ret_rez = req.attr("rez");
ret_msg = req.text();
ret_time = req.childGet(1).attr("time");
ret_utime = req.childGet(1).attr("utime");
ret_cat = req.childGet(1).attr("cat");
ret_lev = req.childGet(1).attr("lev");
И, в принципе, более ни с чем не мудрю. Так вот, если tm - tm_grnd > 30000, то выборка уже сильно замедляется. Это ощущается сильными тормозами и иногда даже зависаниями (хотя зависания могут быть не по этой конкретной причине, а вот существенное замедление выборки это факт).
|
|
Повідомлення створено: 09. 11. 2012 [09:21]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3743
|
"DJ-AMIGO" wrote:
Роман, может быть это особенность функционирования OpenSCADA под конкретным ПЛК?
Как бы у меня было и есть большое разнообразие ПЛК.
"DJ-AMIGO" wrote:
Я все еще не перешел на новую сборку OpenSCADA, решил попытаться разобраться со старой.
А функция подключения через SSL по таймауту для чего делалась?
"DJ-AMIGO" wrote:
А алгоритм тут не причем! Я просто вызываю функцию get для локального архива сообщений способом, который обсуждался ранее в этом же топике:
==== Skip ====
И, в принципе, более ни с чем не мудрю. Так вот, если tm - tm_grnd > 30000, то выборка уже сильно замедляется. Это ощущается сильными тормозами и иногда даже зависаниями (хотя зависания могут быть не по этой конкретной причине, а вот существенное замедление выборки это факт).
Вот потому и замедление, что необоснованно большой интервал запрашивается периодично. С каких соображений указанно фиксировано 20000, что более 5 часов? Опрос с какой периодичностью вообще осуществляется?
Вот я и говорю, что "tm_grnd" нужно сохранять в конце, установив в cur_tm, а запрос осуществлять прямо по сохраняемой переменной "tm_grnd", кроме первого запуска, где нужно в нужную глубину от текущего значения установить, как сейчас.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 09. 11. 2012 [10:04]
|
|
DJ-AMIGO
Михаил Гончаров
Автор теми
Зареєстрован(а) с: 26.05.2012
Повідомлення: 15
|
Роман, новую версию я собираюсь внедрять в следующие комплекты системы сбора данных, на данном этапе идет обкатка на старой версии OpenSCADA, заодно отрабатываются различные исключительные ситуации потенциально вероятные во время эксплуатации!
Вот потому и замедление, что необоснованно большой интервал запрашивается периодично. С каких соображений указанно фиксировано 20000, что более 5 часов? Опрос с какой периодичностью вообще осуществляется?
Вот я и говорю, что "tm_grnd" нужно сохранять в конце, установив в cur_tm, а запрос осуществлять прямо по сохраняемой переменной "tm_grnd", кроме первого запуска, где нужно в нужную глубину от текущего значения установить, как сейчас.
С природой замедления я теперь разобрался! Спасибо за пинок в нужную сторону! =)
Теперь буду оптимизировать механизм обработки архива сообщений и передачи сообщений на центральную SCADA-станцию.
При этом я решил усовершенствовать протокол обмена сообщениями с учетом оптимизации обработки локального архива.
|
|
Повідомлення створено: 07. 12. 2012 [13:25]
|
|
DJ-AMIGO
Михаил Гончаров
Автор теми
Зареєстрован(а) с: 26.05.2012
Повідомлення: 15
|
Приветствую представителей сообщества!
Наконец-то мне удалось решить основную массу проблем с внедрением OpenSCADA под задачи пересылки событийной информации между SCADA-станциями!
Мною была использована версия OpenSCADA-сборки для ПЛК ICP DAS LP 5441 от 12.09.2012г.
Благодаря этому действию толком ничего не изменилось, ранее имевшиеся трудности никуда не исчезли! Проблемы с SSL остались - зависание DAQ-модуля при попытке инициировать SSL-соединение в момент недоступности удаленной SCADA-станции.
Тогда я решил более детально исследовать суть проблемы!
Теперь я могу заявить, что истинная причина незапуска DAQ-модулей установлена!
В подсистеме сбора данных имеется список удаленных станций и в этом списке была заведена удаленная SCADA-станция, настроенная через SSL-подключение.
Так вот при очередной загрузке системы автоматически происходила попытка установления соединения для задачи redundant (видимо это фоновая задача передачи данных для целей резервирования)! При условии доступности удаленной SCADA-станции SSL-соединение устанавливалось и все работало благополучно, но если сервер в момент старта системы был недоступен, тогда происходил упомянутый мной инцидент (т.е. незапуск ВСЕХ DAQ-контроллеров)!
После удаления redundant-задач и задействования соединений selfsystem через HTTP для разведочных целей, мною была решена проблема зависания DAQ-контроллера, обслуживающего задачу транспортировки сообщений на удаленную станцию! После удачной попытки соединения типа selfsystem через HTTP сразу включается SSL-соединение, что в 99% случаев гарантирует доступность удаленной станции на момент установления SSL-соединения, чем достигается отсутствие зависания DAQ-контроллера, занимающегося транспортировкой сообщений.
ps: Ну да, конечно же описанные меры вовсе не гарантируют 100% работоспособность и отказоустойчивость системы, поэтому были предприняты дополнительные ухищрения для обработки исключительных ситуаций. Такие ситуации в большинстве своем решаются топорными методами: при условии зависания DAQ-контроллера, занимающегося транспортировкой сообщений, производится его автоматический перезапуск, если же его перезапуск заканчивается неуспехом в течение определенного контрольного интервала времени, тогда происходит перезапуск OpenSCADA!
[Повідомлення редагувалось 1 раз(ів), останній раз 07.12.2012 в 13:36.]
|
|
Повідомлення створено: 07. 12. 2012 [16:17]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3743
|
"DJ-AMIGO" wrote:
Теперь я могу заявить, что истинная причина незапуска DAQ-модулей установлена!
В подсистеме сбора данных имеется список удаленных станций и в этом списке была заведена удаленная SCADA-станция, настроенная через SSL-подключение.
Так вот при очередной загрузке системы автоматически происходила попытка установления соединения для задачи redundant (видимо это фоновая задача передачи данных для целей резервирования)! При условии доступности удаленной SCADA-станции SSL-соединение устанавливалось и все работало благополучно, но если сервер в момент старта системы был недоступен, тогда происходил упомянутый мной инцидент (т.е. незапуск ВСЕХ DAQ-контроллеров)!
Возможно такое.
Если таймаут подключения SSL-транспорта более 5 секунд то выход из ожидания создания задачи резервирования будет аварийным и запуск контроллеров DAQ будет опущен. Установите таймаут соединения SSL-транспорта меньше 5 секунд!
"DJ-AMIGO" wrote:
ps: Ну да, конечно же описанные меры вовсе не гарантируют 100% работоспособность и отказоустойчивость системы, поэтому были предприняты дополнительные ухищрения для обработки исключительных ситуаций. Такие ситуации в большинстве своем решаются топорными методами: при условии зависания DAQ-контроллера, занимающегося транспортировкой сообщений, производится его автоматический перезапуск, если же его перезапуск заканчивается неуспехом в течение определенного контрольного интервала времени, тогда происходит перезапуск OpenSCADA!
По нормальному нужно выяснить где конкретно происходит это зависание иначе это как вилами по воде, и решать причину, а не следствие.
P.S. Есть подозрение, что "подвисание" задачи контроллера связано как раз с большим таймаутом подключения транспорта SSL, из-за чего задача контроллера останавливается по своему таймауту, который 10 секунд обычно! В архив сообщений на предмет системных сообщений смотрели, после зависания? Вообще возьмите и проверьте руками корректность работы таймаута подключения на транспорте SSL этого контроллера, а именно попробуйте его включить при отсутствии сервера и замеряйте время ожидания. Таймаут установите в одну секунду: http://wiki.oscada.org/Doc/SSL/files?get=SSL_out.png .
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 10. 12. 2012 [13:35]
|
|
DJ-AMIGO
Михаил Гончаров
Автор теми
Зареєстрован(а) с: 26.05.2012
Повідомлення: 15
|
Роман, ваш акцент на параметре тайм-аута SSL-соединения я принял во внимание, и в ближайшее время попробую его покрутить более тщательно! Однако до сих пор я экспериментировал с этим параметром наоборот в сторону увеличения тайм-аута. Просто до сих пор мне казалось логичнее увеличивать тайм-аут, тем более по умолчанию там выставлено как раз 5:1, если мне не изменяет память.
|
|
|
