Обработка алармов и сообщений
| Автор |
Повідомлення |
|
Повідомлення створено: 20. 11. 2012 [09:04]
|
|
pentagon128
Руслан Кучерявый
Автор теми
Зареєстрован(а) с: 15.11.2011
Повідомлення: 102
|
Добрый день. Интересует цена вопроса и возможность реализации модуля контроллера групповой обработки алармов и сообщений, с их выдачей в протокол. Т.к. существующая концепция реализации алармов на основе виджетов неприемлема в принципе. Можно конечно делать "костыли" и в обёртку Java завернуть решение данной задачи, но всё это не то и считаю это потерей времени (ветки форума посвящённые алармам читал). Решение - в чём то похожее на реализацию в Trace Mode. Т.е. контроллер, в входных параметрах которого можно задавать массивы булевых, вещественных (для начала) переменных, целые тоже не помешают, с контролем в отдельности битов по маске. К которым линковать теги техпроцесса (атрибуты). Границы предупредительные и аварийные (верхние и нижние), тест сообщения при превышении границы, ресурс или имя проигрываемого звукового файла при превышении границы. Ввод и использование гистерезиса для обработки границ. Контроллер должен держать в памяти копии входных переменных последнего цикла и отслеживать их изменение. Изменение+превышение границы=> событие в протокол. +контроллер должен иметь входа квитирования оператором. С руководством своим предварительно тему обговорил.
[Повідомлення редагувалось 2 раз(ів), останній раз 20.11.2012 в 09:08.]
|
|
Повідомлення створено: 20. 11. 2012 [10:09]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3747
|
"pentagon128" wrote:
Интересует цена вопроса и возможность реализации модуля контроллера групповой обработки алармов и сообщений, с их выдачей в протокол.
Чем для этого модуль логического уровня не устроил?
"pentagon128" wrote:
Т.к. существующая концепция реализации алармов на основе виджетов неприемлема в принципе.
Кому как, а меня устраивает полностью, и Вы тут скорее всего просто не разобрались.
"pentagon128" wrote:
Можно конечно делать "костыли" и в обёртку Java завернуть решение данной задачи, но всё это не то и считаю это потерей времени (ветки форума посвящённые алармам читал).
Если костыли делать то они и получатся, а так подобного рода задача решается на логическом уровне вполне прозрачно и не многим хуже прямой реализации в модуле. А порой даже лучше, поскольку в виду непонимания существующей концепции, а значит и неполное понимание ожидаемого, такой подход позволяет легко вносить коррективы.
"pentagon128" wrote:
Решение - в чём то похожее на реализацию в Trace Mode. Т.е. контроллер, в входных параметрах которого можно задавать массивы булевых, вещественных (для начала) переменных, целые тоже не помешают, с контролем в отдельности битов по маске. К которым линковать теги техпроцесса (атрибуты). Границы предупредительные и аварийные (верхние и нижние), тест сообщения при превышении границы, ресурс или имя проигрываемого звукового файла при превышении границы. Ввод и использование гистерезиса для обработки границ. Контроллер должен держать в памяти копии входных переменных последнего цикла и отслеживать их изменение. Изменение+превышение границы=> событие в протокол. +контроллер должен иметь входа квитирования оператором.
Многое из этого уже есть, а остальное можно без проблем добавить туда-же, в шаблоны логического уровня.
"pentagon128" wrote:
С руководством своим предварительно тему обговорил.
Собственно не вопрос. Можно существующие шаблоны расширить в этом направлении, если нужно.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 20. 11. 2012 [11:11]
|
|
pentagon128
Руслан Кучерявый
Автор теми
Зареєстрован(а) с: 15.11.2011
Повідомлення: 102
|
Алгоритм предупредительной и аварийной сигнализации АСУТП мне понятен и я встречался с его реализацией на разных платформах неоднократно. На Visual Studio Net подобный класс для обработки данной задачи (на входе массивы переменных тегов и теги квитирования, на выходе потоки сообщений) я смогу пожалуй сделать за несколько дней. Но тут Linux. Касательно опен-скада у меня почему то через использование шаблонов+виджеты сигнализация незаработала. Буду тут ещё разбираться. Шаблон base.anUnif например не обеспечивает в коде обработки симуляцию входного значения. Накладывает rnd на 50% (пару месяцев назад разбирался кодом Java обсчитывающим данный шаблон). Т.е. шаблоны надо переделывать (вернее новые делать). И так одно цепляется за другое...т.е. инкапсулированного решения нет (инкапсуляция, наследование, полиморфизм - киты ООП страдают), обработка алармов не сконцентрирована в одном месте - контроллере - а размазана по всему проекту (шаблоны, виджеты, JAVA код в логическом уровне). И на логическом уровне прийдётся кучу кода писать на Java. Учитывая то что у меня нет полноценного отладчика с контрольными точками и просмотром переменных - код на Java - мне писать неудобно, на отладку много времени уходит. При этом хочется в конфигураторе контроллера обьвлять массив переменных входных, а потом уже к ним линковать теги. Исходя из этого удобнее данный код написать на си и инкапсулировать в типовой модуль контроллера обработки алармов. Для чего мне например прийдётся QtSdk или QTCreator копать исходники Open Scada...что уже как я называю - низкоуровневое программирование, которое требует погружения в задачу....А если бы в OpenScada был готовый контроллер обработки сигнализации с входами и выходами - думаю многие бы спасибо сказали. И считаю - можно данную работу и профинансировать.
|
|
Повідомлення створено: 20. 11. 2012 [11:39]
|
|
pentagon128
Руслан Кучерявый
Автор теми
Зареєстрован(а) с: 15.11.2011
Повідомлення: 102
|
Сейчас написал проект АРМ оператора на опен скада. Скоро поставим заказчику. Думаю по результатам внедрения можно будет сделать тут публикацию с описанием проекта. До этого реализацию армов подобных проектов я делал на Trace Mode. Управляющий контроллер использован Trei 5-я серия М911Е (http://www.trei-gmbh.ru/), Система контролирует довзрывную концентрацию паров нефтепродуктов в воздухе на территории нефтебаз. Частично оборудование располагается во взрывоопасной зоне. На опен скада пока не решена проблема с фиксацией событий в протоколе. Временно вывел события на битовый график.
[Повідомлення редагувалось 2 раз(ів), останній раз 20.11.2012 в 11:53.]
|
|
Повідомлення створено: 20. 11. 2012 [11:53]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3747
|
"pentagon128" wrote:
Касательно опен-скада у меня почему то через использование шаблонов+виджеты сигнализация незаработала. Буду тут ещё разбираться. Шаблон base.anUnif например не обеспечивает в коде обработки симуляцию входного значения. Накладывает rnd на 50% (пару месяцев назад разбирался кодом Java обсчитывающим данный шаблон).
base.anUnif ни разу не панацея, а скорее пример на основе которого можно легко писать свои, просто скопировав. Хотя в моих решениях его более чем достаточно и вход имитации там прекрасно работает.
"pentagon128" wrote:
Т.е. шаблоны надо переделывать (вернее новые делать). И так одно цепляется за другое...т.е. инкапсулированного решения нет (инкапсуляция, наследование, полиморфизм - киты ООП страдают), обработка алармов не сконцентрирована в одном месте - контроллере - а размазана по всему проекту (шаблоны, виджеты, JAVA код в логическом уровне).
С наследованием и ООП там всё нормально если делать с пониманием, и обработка алармов находится в одном месте, а именно в шаблонах, а в виджетах только уведомление о них, что концептуально разные вещи!
"pentagon128" wrote:
Учитывая то что у меня нет полноценного отладчика с контрольными точками и просмотром переменных - код на Java - мне писать неудобно, на отладку много времени уходит.
Там и не нужен отладчик поскольку всё меняется на ходу, а любые переменные можно вывести в отладочные атрибуты или просто напечатать банально поменяв код и сразу увидев результат, уж куда проще, исключая однако СВУ.
"pentagon128" wrote:
При этом хочется в конфигураторе контроллера обьвлять массив переменных входных, а потом уже к ним линковать теги.
Объявляйте массивы, кто мешает?
"pentagon128" wrote:
Исходя из этого удобнее данный код написать на си и инкапсулировать в типовой модуль контроллера обработки алармов.
Но неэффективно, жёстко и бессмысленно, особенно если учесть что главный аргумент тут фактически нежелание разобраться во внутреннем языке программирования JavaLikeCalc, что ещё и неконструктивно.
"pentagon128" wrote:
Для чего мне например прийдётся QtSdk или QTCreator копать исходники Open Scada...что уже как я называю - низкоуровневое программирование, которое требует погружения в задачу....А если бы в OpenScada был готовый контроллер обработки сигнализации с входами и выходами - думаю многие бы спасибо сказали. И считаю - можно данную работу и профинансировать.
Задача бессмысленна и неконструктивна поэтому откланяется!
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 20. 11. 2012 [12:04]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3747
|
"pentagon128" wrote:
Сейчас написал проект АРМ оператора на опен скада. Скоро поставим заказчику. Думаю по результатам внедрения можно будет сделать тут публикацию с описанием проекта.
OK
"pentagon128" wrote:
До этого реализацию армов подобных проектов я делал на Trace Mode. Управляющий контроллер использован Trei 5-я серия М911Е ( http://www.trei-gmbh.ru/), Система контролирует довзрывную концентрацию паров нефтепродуктов в воздухе на территории нефтебаз. Частично оборудование располагается во взрывоопасной зоне.
Реализация алармов отдельной SCADA вовсе не является панацеей кроме того в OpenSCADA подобным образом тоже делается, если разобраться. Да, нет по этому поводу готовых шаблонов и элементов визуализации, но во первых они делаются под нужды пользователей, а значит под себя, и во вторых сделать подобные библиотеки под различные SCADA у меня нет ни времени ни желания, что такой возможности не исключает!
"pentagon128" wrote:
На опен скада пока не решена проблема с фиксацией событий в протоколе. Временно вывел события на битовый график.
Событий чего и в чём проблема с их фиксацией?
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 20. 11. 2012 [12:09]
|
|
pentagon128
Руслан Кучерявый
Автор теми
Зареєстрован(а) с: 15.11.2011
Повідомлення: 102
|
Ситуация понятна. Это тоже решение. И таким путём идти можно, и пожалуй нужно. Дорогу осилит идущий. JavaLikeCalc меня не пугает, не лучше и не хуже других, код на нём мне понятен. Буду двигаться в сторону разработки грамотных шаблонов + логический уровень. Это всё уже обсуждалось в ветке [Alarms][Сигнализация]Есть ли способ формирования алармов без виджетов? http://oscada.org/ru/forum/posts//alarmssignalizacijaest_li_sposob_formirovanija_alarmov//5/
|
|
Повідомлення створено: 20. 11. 2012 [12:17]
|
|
pentagon128
Руслан Кучерявый
Автор теми
Зареєстрован(а) с: 15.11.2011
Повідомлення: 102
|
Событий чего и в чём проблема с их фиксацией?
срабатывание сигнализации по объектовому направлению обрабатываю в контроллере выставлением битового флага, который фигурирует в карте модбаса и уходит на верхний уровень. Т.е. на верхнем уровне в протокол надо фиксировать изменение состояния с 0 на 1-цу и наоборот, + дата и время. Ну и текст "событие есть" или "событие нет". Проблема с реализацией протокола на опенскада. Пока у меня не получается. Надо будет сделать шаблон обработки сигнала этого и контроллер логического уровня прикрутить, в контроллере вызывать системную функцию сообщения (это всё в теме есть http://oscada.org/ru/forum/posts//alarmssignalizacijaest_li_sposob_formirovanija_alarmov//5/).
Да, и логику сигнализации я прописал в контроллере TREI-M911E как положено на триггерах шмидта (RS), и квитирование тоже. Т.е. на верхнем уровне (опен скада) мне надо только регистрировать факт прихода события, и что оператор отработал (квитирование нажал).
[Повідомлення редагувалось 1 раз(ів), останній раз 20.11.2012 в 12:21.]
|
|
Повідомлення створено: 20. 11. 2012 [12:29]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3747
|
"pentagon128" wrote:
срабатывание сигнализации по объектовому направлению обрабатываю в контроллере выставлением битового флага, который фигурирует в карте модбаса и уходит на верхний уровень. Т.е. на верхнем уровне в протокол надо фиксировать изменение состояния с 0 на 1-цу и наоборот, + дата и время. Ну и текст "событие есть" или "событие нет". Проблема с реализацией протокола на опенскада. Пока у меня не получается. Надо будет сделать шаблон обработки сигнала этого и контроллер логического уровня прикрутить, в контроллере вызывать системную функцию сообщения (это всё в теме есть http://oscada.org/ru/forum/posts//alarmssignalizacijaest_li_sposob_formirovanija_alarmov//5/).
DAQ.ModBus поддерживает тип параметра "Логический", что совмещает "сырой" опрос данных по ModBus и обработку их по шаблону (как в логическом уровне) с той лишь разницей, что в качастве адреса, во вкладке конфигурации шаблона, указывается адрес регистра или коилса: http://wiki.oscada.org/Doc/ModBus#h592-17 .
Вот прямо в этом шаблоне анализируйте бит нарушения и устанавливайте/снимайте его.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 20. 11. 2012 [14:30]
|
|
pentagon128
Руслан Кучерявый
Автор теми
Зареєстрован(а) с: 15.11.2011
Повідомлення: 102
|
Спасибо. Про совмещение логического шаблона знаю. Как оказалось - я рассматривал и применял не те базовые шаблоны, поэтому и невязалось ничего. Базовый шаблон для вещественных anUnif как оказалось надо брать из примера AGLKS где ключевым является код в конце
if(tErr.toInt() && tErr.toInt() != f_err.toInt()) this.nodePrev().alarmSet((NAME.length?NAME:SHIFR)+": "+DESCR+": "+tErr.parse(1,":"), levErr, SHIFR);
else if(f_err.toInt() && !tErr.toInt()) this.nodePrev().alarmSet((NAME.length?NAME:SHIFR)+": "+DESCR+": НОРМА", 1, SHIFR);
f_err = tErr;
+ быстрый старт последняя редакция стр. 88
Регистрацию сообщений лучше всего осуществлять на стороне типизированных ш
сточника данных посредством специальной функции "
"Controller"].alarmSet(string mess, int lev = -5, string prm = "")",
атегорию. Для вызова этой функции из контекста шаблона нужно добавить IO "this"
Объект", после чего установка нарушения будет иметь вид "this.nodePrev(
арушение", -5, "prm");". Указанная функция сейчас используется во мног
сточников данных для учёта глобальных нарушений объектов контроллер
арушение с категорией: al{ModId}:{CntrId}[.{PrmId}], где:
• ModId — идентификатор модуля;
• CntrId — идентификатор контроллера;
• PrmId — идентификатор параметра, из аргумента <prm>.
В целом нужно отметить, что уведомления и регистрация нарушений э
оторые могут использоваться по отдельности, для простых проектов, или
омплексных проектов.
буду разбираться дальше...
|
|
|
