Зарегистрирован: Mar 14, 2006 Сообщения: 128 Рейтинг: +2/-0 Откуда: Липецк
Добавлено: Ср 07 Фев, 2007 9:00:41 Заголовок сообщения: Контроль Alarm в RSView ME
Уважаемые коллеги!
Подскажите, пожалуйста, можно ли каким-либо образом отследить появление алармов в проекте ME? Я по-умолчанию в настройках направляю вывод аварийных сообщений на отдельный экран, при этом при появлении аварии, мне не хочется, чтобы этот экран автоматически появлялся поверх всех остальных.
Есть ли возможность узнать, что в системе появился любой из алармов?
Попробуйте отключить на вкладке "Messages" опцию "Display" и включить "Message to Tag". На вкладке "Triggers" укажите этот тэг. Потом, анализируя этот тэг можно увидеть, есть ли Alarm.
Попробуйте отключить на вкладке "Messages" опцию "Display" и включить "Message to Tag". На вкладке "Triggers" укажите этот тэг. Потом, анализируя этот тэг можно увидеть, есть ли Alarm.
Т.е. получается, что для всех строк в списке AlarmMessages ставим галочку MessageToTag и дальше следим за строковым тегом?
1. Но тогда получается неинтересная штука: когда срабатывает триггер аларма, то назначенный строковый тег принимает значение сообщения (как и должно быть), а кто его (этот тег) очистит, когда аларм будет снят?
2. Для разных триггеров необходимо создавать свой строковый тег. Т.к. если добавить в списке AlarmMessages пустую строку, то разные алармы могут влиять на данный один и тот же для всех триггеров строковый тег.
3. Нельзя ли использовать какой-нибудь финт для всех алармов?
Как решить простейшую задачу: имеется пять экранов, из них только один содержит список алармов, а на остальных четырех должна быть лампочка, которая всегда горит зеленым, а при возникновении аварии(хотя бы одной) она загорается красным? Далее лампочка должна загореться зеленым, когда аварии будут сняты.
3. Нельзя ли использовать какой-нибудь финт для всех алармов?
Как решить простейшую задачу: имеется пять экранов, из них только один содержит список алармов, а на остальных четырех должна быть лампочка, которая всегда горит зеленым, а при возникновении аварии(хотя бы одной) она загорается красным? Далее лампочка должна загореться зеленым, когда аварии будут сняты.
Сделай в контроллере бит - наличие хотя бы одной тревоги.
Не хватает желтого цвета - тревоги есть и подтверждены.
Согласен про желтый цвет. Но моя задача от этого только усложняется.
Однако про создание тега в контроллере: не всегда это подходит, т.к. часть критических ситуаций может быть сформирована на основе макросов, когда собирается ситуация из нескольких зависимых сигналов. Об этом мы уже думали, что в данном случае надо все аварии собирать в контроллере, но это не совсем интересно. Ведь все понимают, что отслеживание аварий - прерогатива SCADA.
Ведь все понимают, что отслеживание аварий - прерогатива SCADA.
Не все! Я, например.
Что контроллер не следит за ситуацией и продолжает работать?
А, если RSViewME отключили, перегрузили...
RSViewME - терминал оператора
В RSViewSE и RSView32 все решается просто см. системные теги:
- system\AlarmSummaryItems
- system\AlarmSummaryItemsUnacked
Ведь все понимают, что отслеживание аварий - прерогатива SCADA.
Если под термином SCADA Вы понимаете его классическое определение, т.е. Supervisory Control And Data Acquisition, то Вы правы. Но, видите ли, мне кажется, что в данном контексте Вы применяете этот термин, не как собственно SCADA, понимаемую, как "input/output signal hardware, controllers, HMI, networks, communication, database and software", а имеете в виду только часть SCADA, именуемую HMI.
Если это так, то мне кажется, что Вы несколько смещаете понятия. Прерогатива HMI - это визуализация информации, в том числе, информации об аварийной ситуации, а не собственно детектирование и оперативное реагирование на аварию. А распознавание аварии является прерогативой других компонентов SCADA - контроллеров, которые, собственно, и нужны для того, чтобы контролировать ситуацию, предотвращая непредсказуемое развитие событий на объекте управления.
dv_ писал(а):
А, если RSViewME отключили, перегрузили...
RSViewME - терминал оператора
Абсолютно согласен с коллегой.
Компьютер предназначен, собственно, не для распознавания аварий, а для их отображения и приёма инициативных команд оператора.
По моему убеждённому мнению, именно контроллер, а не компьютер интерфейса оператора является тем местом, где должно осуществляться детектирование аварийных ситуаций и оперативное, в реальном времени, реагирование на них. Информация (в т.ч. аварийная) должна немедленно обратываться в том месте, где она непосредственно образуется (в контроллере), а не в том месте, куда она потом поступает по сети - в компьютере оператора.
Компьютер может быть и выключен, или на него в момент возникновения аварийной ситуации могут и не смотреть. Но это не значит, что аварийная ситуация имеет право оставаться нераспознанной на протяжении какого-то непредсказуемого периода времени. А вот в контроллере (в отличие от пакета визализации) есть всё необходимое - многозадачная операционная система реального времени, максимально возможная скорость обработки информации, развитая система команд, отсутствие подвижных механических частей, повышенная по сравнению с компьютером живучесть, непосредственная локальная обработка критичных сигналов поступающих непосредственно от объекта через модули ввода-вывода. Он работает всегда, и в нём нет Windows
Детектирование и реагирование на аварийные ситуации обычно и реализуются в контроллере. А пытаться реализовать детектирование и реагирование на аварии в компьютере, предназначенном для отображения информации, используя макросы или какие-то сложные механизмы и ухищрения, на мой взгляд, неэффективно.
Не все! Я, например.
Что контроллер не следит за ситуацией и продолжает работать?
А, если RSViewME отключили, перегрузили...
RSViewME - терминал оператора
Я с вами согласен и прекрасно все понимаю, что при возникновении неисправности, аварии, PLC должен ее обрабатывать, выполнять какие-либо задачи, отвечающие за их обработку.
Однако речь идет о регистрации этих аварий, отображении их на экране.
В RSViewSE и RSView32 все решается просто см. системные теги:
- system\AlarmSummaryItems
- system\AlarmSummaryItemsUnacked[/color]
Если под термином SCADA Вы понимаете его классическое определение, т.е. Supervisory Control And Data Acquisition, то Вы правы. Но, видите ли, мне кажется, что в данном контексте Вы применяете этот термин, не как собственно SCADA, понимаемую, как "input/output signal hardware, controllers, HMI, networks, communication, database and software", а имеете в виду только часть SCADA, именуемую HMI.
Думаю, что понимать под SCADA еще и набор оборудования в корне не верно. SCADА - это специализированное программное обеспечение, ориентированное на обеспечение интерфейса между диспетчером и системой управления, а также коммуникацию с внешним миром (простите, методическое определение).
Поэтому, я понимаю под SCADA то, что она обозначает. И не хочу от нее больше того, чего она должна делать! Другое дело, что то, что нам предложено, убого реализует ряд функций, что приходится выкручиваться старым дедовским способом.
Если это так, то мне кажется, что Вы несколько смещаете понятия. Прерогатива HMI - это визуализация информации, в том числе, информации об аварийной ситуации, а не собственно детектирование и оперативное реагирование на аварию. А распознавание аварии является прерогативой других компонентов SCADA - контроллеров, которые, собственно, и нужны для того, чтобы контролировать ситуацию, предотвращая непредсказуемое развитие событий на объекте управления.
Ну хорошо, не распознавание, а отображение. Но от этого флейма поставленная задача не решается.
SCADA-контроллеры, хм, интересно . Честно говоря, я все понял, о чем вы пытаетесь сказать, но с терминологией не согласен.
Компьютер предназначен, собственно, не для распознавания аварий, а для их отображения и приёма инициативных команд оператора.
По моему убеждённому мнению, именно контроллер, а не компьютер интерфейса оператора является тем местом, где должно осуществляться детектирование аварийных ситуаций и оперативное, в реальном времени, реагирование на них. Информация (в т.ч. аварийная) должна немедленно обратываться в том месте, где она непосредственно образуется (в контроллере), а не в том месте, куда она потом поступает по сети - в компьютере оператора.
На самом деле, все это понятно, и именно так и делается, но регистрацию этих ситуаций никто не отменял. Компьютер и панель в том числе, во многих случаях становится единственным способом, чтобы донести в реальном времени оператору критическую информацию. От действий оператора могут зависеть задачи контроллера. По-моему ничего сверхестественного от панели в данном случае не запрашивается. И очень часто PC или панель также должны работать в постоянном режиме, их можно продублировать для надежности и т.д. и т.п.
Детектирование и реагирование на аварийные ситуации обычно и реализуются в контроллере. А пытаться реализовать детектирование и реагирование на аварии в компьютере, предназначенном для отображения информации, используя макросы или какие-то сложные механизмы и ухищрения, на мой взгляд, неэффективно.
Ох как пристали к термину! А как назвать тот механизм, который реализован в ME? Не детектирование? Когда сначала напиши триггер, с его результатом свяжи messages, да еще кое-чего. Это просто отображение?
Чувствуется склонность к поучению А помощи в реализации увы...
Еще раз задача: Есть приблизительно 100 тегов в контроллере, которые отвечают за контроль состояния объекта управления, схем управления и т.д., на основе которых в RSViewME должен формироваться список аварийных сообщений. Теги контроллера и SCADA связаны между собой. Реализованы триггеры, по которым сообщения вываливаются на экран, где AlarmList. Необходимо, чтобы при возникновении хотя бы одной аварии (изменении в одном из 100 тегов) загорелась лампочка красным цветом. Лампочка размещается на остальных (скажем 10-ти) экранах и сигнализирует о том, что в AlarmList есть новое сообщение.
Я понимаю, что можно в контроллере организовать какую-нибудь задачку и все 100 тегов по "ИЛИ" проверять и записывать результат в 101-й тег. Но это же полный отстой, при условии, что если нам надо добавить еще контролируемые теги! А еще можно с каждым тегом в PLC связать строковый тег (строку) и ее пулять по сети для отображения на экране - вообще красота!
Подозреваю, что это слишком крутое желание для ME, но вы упорно об этом молчите, пытаясь рассказать о концепции сбора и обработки диспетчерской информации.
Кстати, про AcknowledgeAll так тоже нет ответа. Совсем беда.
Спасибо за ответы.
Думаю, что понимать под SCADA еще и набор оборудования в корне не верно. SCADА - это специализированное программное обеспечение, ориентированное на обеспечение интерфейса между диспетчером и системой управления, а также коммуникацию с внешним миром (простите, методическое определение).
Знаете, возможно, Вы удивитесь, но то, что Вы по этом поводу думаете, не соответствует классическому определению термина SCADA. Вы, конечно, можете понимать под SCADA то, что Вам больше нравится понимать, но я бы порекомендовал Вам почитать классическое описание. Хотя бы в Wikipedia:
http://en.wikipedia.org/wiki/SCADA
После того, как Вы поймёте, что SCADA - это не только и не столько программное обеспечение, а система, Вы поймёте немного лучше, чего следует, и чего не следует ожидать от каждого её компонента.
Цитата:
то, что нам предложено, убого реализует ряд функций, что приходится выкручиваться старым дедовским способом.
То, что предлагается Вам, предлагается ещё и тысячам фирм во всём мире, и не разработано вчера группой энтузиастов, а является результатом и сделано с учётом более, чем 20-летнего опыта одного из ведущих мировых брэндов. Извините, но разработчики не могли исходять из Вашего собственного (не вполне корректного) понимания того, что должна уметь HMI-система, а исходили из классического опыта и классического же набора функций для каждого системного компонента SCADA.
Другое дело, что если функции панели оператора не позволяют лично Вам реализовать Ваши конкретные представления - что ж, не нужно использовать эту панель. Не нравится? Не используйте. Но Ваше "убого" - простите, но.... Вы что, чувствуете себя умнее, чем десятки тысяч инженеров, которые с успехом применяют это во всём мире? Вы, вероятно, полагаете, что Rockwell Automation мог бы себе позволить делать убогие вещи? Не намерен разубеждать Вас, а просто уверяю Вас, это не так. Просто Вы, видимо, не совсем адекватно представляете себе функции и задачи техники, на базе которой собираетесь работать.
Цитата:
Ну хорошо, не распознавание, а отображение. Но от этого флейма поставленная задача не решается.
Это, уважаемый, не флейм. Мы Вам тут пытались показать, что Ваши представления не совсем соответствуют действительности. Поэтому я прочёл Вам небольшую лекцию о достаточно простых и очевидных вещах. Если Вы не согласны с терминологией - что ж, это Ваше право
Можете продолжать оставаться неcогласны
Цитата:
SCADA-контроллеры, хм, интересно
Да, видимо, Вы всё-таки не поняли. Ну что ж, ничего страшного. Бывает.
Впрочем, чтение тут ещё одной лекции не входит в мои планы, уж извините. Я не собираюсь объяснять основополагающие вещи, тем более, что мне не нравится, откровенно, говоря, Ваш агрессивный тон.
Здесь - форум. Здесь отвечает тот, кто хочет ответить. Тот, кто ответить не хочет, соответственно не отвечает.
Я мог бы ответить на Ваши вопросы, но в таком тоне вести диалог не имею желания, уж извините. Может быть, кто-нибудь из коллег захочет.
Всего Вам доброго, желаю Вам успехов.
Последний раз редактировалось: oldDad (Пн 12 Фев, 2007 10:20:36), всего редактировалось 1 раз
От действий оператора могут зависеть задачи контроллера.
Не должны зависеть - оператор самый ненадежный элемент системы.
Старый анекдот:
Горбачев, в эпоху борьбы с алкоголем, приехал на завод и спрашивает у работника:
- Скажите, выпив 50 грамм водки вы можете работать?
- Могу.
- А 100?
- Могу.
- А стакан?
- Ну работаю же...
Mr_Wasp писал(а):
SCADА - это специализированное... (простите, методическое определение).
Мне интересно, кто автор такого определения?
С появлением Windows появилось много HMI систем, в которых аббревиатура HMI отсутствовала, зато было SCADA. Немного ошибаюсь - в те времена вместо HMI применялось MMI.
Mr_Wasp писал(а):
А помощи в реализации увы...
Помошь разная бывает некоторая только за деньги, например для Вашей задачи (с предоставлением кода). И никакого:
Знаете, возможно, Вы удивитесь, но то, что Вы по этом поводу думаете, не соответствует классическому определению термина SCADA. Вы, конечно, можете понимать под SCADA то, что Вам больше нравится понимать, но я бы порекомендовал Вам почитать классическое описание. Хотя бы в Wikipedia:
http://en.wikipedia.org/wiki/SCADA
Мое определение взято из учебника
"SCADA - системы: взгляд изнутри" Андреева Евгения Борисовича (Российский Университет Нефти и Газа им. И.М.Губкина) и Куцевич Надежды Александровны (компания РТСофт)
Полностью согласен с авторами, а трактовка с wikipedia меня удивила. Отсюда и непонятки. Честно говоря, останусь при своем мнении. Хотя если вчитаться в то определение, которое вы приводите, PLC - это источник данных для SCADA, это не противоречит моему пониманию.
После того, как Вы поймёте, что SCADA - это не только и не столько программное обеспечение, а система, Вы поймёте немного лучше, чего следует, и чего не следует ожидать от каждого её компонента.
Извините, но разработчики не могли исходять из Вашего собственного (не вполне корректного) понимания того, что должна уметь HMI-система, а исходили из классического опыта и классического же набора функций для каждого системного компонента SCADA.
Ну тогда почему в RSView32 или RSViewSE у них появилось другое представление? И другие возможности?
Другое дело, что если функции панели оператора не позволяют лично Вам реализовать Ваши конкретные представления - что ж, не нужно использовать эту панель. Не нравится? Не используйте. Но Ваше "убого" - простите, но....
Да вот же, наша ошибка есть в этом, повелись на рекламные высказывания, а оказалось гораздо слабее ожидаемого.
Вы что, чувствуете себя умнее, чем десятки тысяч инженеров, которые с успехом применяют это во всём мире? Вы, вероятно, полагаете, что Rockwell Automation мог бы себе позволить делать убогие вещи? Не намерен разубеждать Вас, а просто уверяю Вас, это не так. Просто Вы, видимо, не совсем адекватно представляете себе функции и задачи техники, на базе которой собираетесь работать.
Я не хотел сказать, что я умнее, чем другие, не претендую на лавры. И разубеждать меня ни в чем не следует, я не говорю обо всех продуктах фирмы, а речь вполне о конкретных вещах. Со многими продуктами удалось поработать и не один проект успешно функционирует даже с моими понятиями.
Мы Вам тут пытались показать, что Ваши представления не совсем соответствуют действительности. Поэтому я прочёл Вам небольшую лекцию о достаточно простых и очевидных вещах.
Впрочем, чтение тут ещё одной лекции не входит в мои планы, уж извините. Я не собираюсь объяснять основополагающие вещи, тем более, что мне не нравится, откровенно, говоря, Ваш агрессивный тон.
Достаточно ссылки.
Агрессии нет никакой, но коль скоро вы меня поучаете, я хочу понять причину моей темности.
А если обижаться на каждую реплику, то ни о какой прогрессивной работе может и не идти.
Здесь - форум. Здесь отвечает тот, кто хочет ответить. Тот, кто ответить не хочет, соответственно не отвечает.
Я мог бы ответить на Ваши вопросы, но в таком тоне вести диалог не имею желания, уж извините. Может быть, кто-нибудь из коллег захочет.
Да, жаль. Получается по принципу "знаю, но не скажу". Не хотите - не надо, спасибо.
... полностью автоматическую систему в наших условиях мы сделать не можем. Такова особенность.
Надо стремиться.
«One of my favorite predictions is the one about the factory of the future.
It will have two occupants, a man and a dog.
The man will be there to feed the dog and the dog will be there to keep the man from touching anything.»
Dick Morley
Mr_Wasp писал(а):
Помните у Хазанова:
"Мы тоже были молодыми, но чтоб за деньги...никогда!"
Лучше из Жванецкого:
"Можно даром, если вас не интересует результат."
Ладно совет - чтогбы не проверять 100 битов по "ИЛИ" -
кто мешает сделать тревоги в DINT[4] итого 128 битов.
Если все слова равны нулю (ЧЕТЫРЕ проверки) тревог нет.
При реализации действий по тревоге в контроллере следует
учесть, что в случае, когда отключение чего-то приводит к снятию сигнала тревоги, тогда высока вероятность потери факта тревоги для регистрации
Ладно совет - чтогбы не проверять 100 битов по "ИЛИ" -
кто мешает сделать тревоги в DINT[4] итого 128 битов.
Если все слова равны нулю (ЧЕТЫРЕ проверки) тревог нет.
Спасибо за халяву
Если серьезно, то думаю, что так и придется делать и поковыряться с битиками и привязками к бинарным тегам RSView. Также можно и считать единички в каждом DINTе и т.д. Просто в данном случае получается двойная работа: в PLC все аварии собрать в одну структуру и реализовать способ отслеживания количества алармов, а затем в RSView реализовать триггеры, по которым выкидывать сообщения.
Честно говоря надеялся, что слежение за количеством алармов можно организовать внутри среды, тем более, что сама она умеет, например, стартануть экран для отображения аварий по срабатыванию триггера.
При реализации действий по тревоге в контроллере следует
учесть, что в случае, когда отключение чего-то приводит к снятию сигнала тревоги, тогда высока вероятность потери факта тревоги для регистрации
Ну это уже детали реализации программы контроллера, как обеспечить гарантию предоставления данных обо всех изменениях в системе.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.156 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
. Честно говоря, я все понял, о чем вы пытаетесь сказать, но с терминологией не согласен.