Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
Необходимые программные инструменты в ПТК (страница 2)

Версия для печати (настроить)
Страницы: 1 2 3 4 5

Новая тема | Написать ответ

Подписаться

Автор Тема:   Необходимые программные инструменты в ПТК
Avsha
Junior Member

Сообщений: 15
Регистрация: Июль 2005

написано 15 Августа 2005 10:47ИнфоПравкаОтветитьIP

Спасибо за подробный ответ по тревогам, возьму на вооружение.

В принципе, более-менее стратегия тревог укладывается:
- тревоги делятся на группы, привязанные к оборудованию, которое в свою очередь имеет статус-режим (работа, останов, и т.д.)
- отключаем тревоги группами, индицируем это отключение на мнемосхемах, или в виде списка.

Правда готовых механизмов по отображению списков активных, запрещенных и т.д. тревог у нас нет - будем делать, а у вас как я понял система их выдает без проблем.

У нас чтобы выдать такой список, необходимо сформировать запрос к реальной БД и выбрать те параметры, у которых поле включения тревоги = DISABLE, а базы у нас большие и поэтому эта процедура занимает достаточное количество времени.

Что у нас есть, так это счетчики тревог - показывают сколько тревог выключены/активны/квитированы и т.д. и в какой зоне - это пожалуйста, а посмотреть какие - этого готового уже нет.

Есть вопросы к вам:
1. Как устанавливаются режимы оборудования в вашей системе - автоматически или человеком?
2. Режим автоквитирования тревог - это когда параметр вернулся к своему нормальному состоянию после тревоги и прошло заданное количество времени, а его за это время не квитировали, то он сам квитируется, так?
3. Что такое структуры в вашей системе - переменные с функциями?

Anatol_K
unregistered
написано 15 Августа 2005 15:02  ПравкаОтветитьIP

Я как то видел у одной фирмы, которая тоже работает с iFix, они просто наделали дополнительных мнемосхем, на которых показали все датчики и в каких режимах они находятся: запрет, имитация или испытатательный режим. В этой системе как правило, для запрета тревоги, не квитируют ее (поскольку это надо делать постоянно, если датчик срабатывает), а ставят запрет по датчику. И у оператора всегда под рукой эти мнемосхемы, где он всегда может увидеть, в рабочем состоянии у него датчик или нет , то есть будет по нему тревога и будут ли исполняться какие либо действия. Это и наша идеология тоже. Вообще идеология системы тревог в нашей системе и iFix несколько различна. Наши тревоги формирует не скада, а контроллер и передает в скаду. А iFix, насколько я понимаю работает независимо от контроллера и для формирования тревожных сообщений надо писать кучу тэгов. Хотя может я и шибаюсь, поскольку плохо знаком с iFix. Поэтому в нашей системе сообщений есть специальная встроенная утилита, работающая с тревогами, пришедшими от контроллера и имеет достаточную гибкость.
Теперь по вопросам:
1. Я может немного, не понимаю ваш вопос по поводу установки режима оборудования. Вообще, оборудование может работать по заданному алгоритму, а задает его человек, если мы подразумеваем одно и тоже под словом режим. Возьмем к примеру какой нибудь насос. Для него оператор задает программу работы в виде режима, например АВТОМАТИЧЕСКИЙ - значит он будет управляться каким либо технолгическим параметром. РЕЗЕРВ - значит он перехватит управление от неисправного основного и сам станет основным, КНОПОЧНЫЙ - управляется только оператором ну и так далее. В некоторых случаях, например система регулирования давления, режим управления может переключаться автоматически, например сейчас это САР позиционирования, а потом надо по программе перейти в САР давления.
Так что думаю это зависит от конкретных требований.
2. Hежим автоквитирования - это немного не то. Правило у нас такое - если по какому либо параметру возникает тревога, то она будет находиться в системе тревог, если параметр в норме - тревога может автоматически сниматься, а может и нет. Пример - аналоговый параметр куда то ушел - тревога установилась, параметр пришел в норму - тревога автоматически снялась. Другой пример - самопроизвольно включился насос - тревога установилась, но не снимется до квитирования оператором, посколку это действие одноразовое и его надо зафиксировать. А вот автоквитирование работает независимо от действий оператора и от того пришел параметр в норму или нет. Логика такая - параметр вышел за норму - тревога держится 10 секунд и автоматически сбрасывается. Конечно - автоквитирование используется редко, как вспомогательное средство для экономии нервов напрмер при проверках датчиков. Были такие случаи, когда оператор забыл снять этот режим ( а в инструкции у него четко написано, чтобы он этим не баловался), заснул и проспал перелив нефти. В результате всю станцию залило, слава богу все обошлось. Ну а оператора выгнали.
3. Теперь о структурах - это вообще базовый элемент нашей системы и носит название "точка". Вообще структура - это набор разнородных данных, объединенных в некий конгломерат. Вот некоторые элементы этой структуры - значение датчика, статус датчика, идентификатор датчика, словесное название датчика, технический диапвзон датчика, зоны недостоверностей, тип преобразование, степень тревоги и еще куча всего. На этапе создания проекта в конфигурационную базу данных (SQL) пробиваются все необходимые точки, где определяются все необходимые поля (элементы этой структуры). Когда грузится контроллер, он забирает в себя все эти точки с необхлдимыми ему полями и работает с некоторыми только на чтение а с другими и запись и чтение. Когда грузится АРМ, он из той же конфигурационной базы грузит в себя информацию о точках. Таким образом общение контроллера и АРМ идет на уровне единой конфигурационной базы и разработчику нет нужды создавать отдельную базу для контроллера и скады и ломать голову над тем как правильно осуществить связь переменных и при этом не ошибаться. Этот комплексный подход имеет тот недостаток, что скада и контроллер составляют единое целое и следовательно универсальность отсутствует. Зато очень облегчает труд при создании базы данных. Хотя я уже отмечал, приняв концепцию ОРС технологии, наша скада стала универсальной.
У меня к вам вопрос - каким образом вы осуществляете связь переменных контроллера с переменными iFix? И существует ли у вас отладочные средства алгоритмов реального времени, то есть можете ли вы на работающем контроллере реально посмотреть свои алгоритмы и значения переменных?

Avsha
Junior Member

Сообщений: 16
Регистрация: Июль 2005

написано 15 Августа 2005 16:05ИнфоПравкаОтветитьIP

Очень интересно, что у вас тревоги генерирует контроллер, у нас, как вы правильно заметили, генерирование тревог осуществляется на уровне SCADA-сервера.
В отдельных случаях, когда логика формирования тревоги сложная, мы формируем значение тревоги в контроллере в виде значения тега.
Вопрос "Про режим" был в том смысле - кто переводит оборудование в режим "Ремонт" - человек кнопкой с АРМ и тем самым снимается группа параметров с сигнализации?

Общая конфигурационная база - это хорошо, мы наелись проблемой синхронизации двух баз.
Но потом нашли одно решение.
Ответы на ваши вопросы:
1. Приняли определенные соглашения:
- наименования переменных контроллера совпадают с именами переменных SCADA,
- создали систему обозначения переменных - аналоговые/дискретные, параметры измерений, расчетные, параметры регулятора, параметры диагностики и т.д. Шифры параметров набиваются один раз с разумным запасом и не привязаны к УСО, имени параметра.
- переменные связаны единым адресом драйвера MBE, структуру разбивки MBE - тоже продумали.
- создали служебные видеокадры в SCADA - которые отображают все параметры, в том числе их представление в структуре контроллера
- в итоге представление двух баз стало одинаковым, конечно мы никуда не делись от двойной конфигурации, но на этапе разработки база набивается один раз, затем через Excel переносится
в SCADA. Были разработаны механизмы легкого изменения комментариев, шкалы и т.д. Дополнительного добавления параметров в контроллер и SCAD-у не требуется.

2. Да! Почему так восторженно, да потому что IsaGraf - это позволяет сделать легко.
Значения переменных в натуральных единицах, представление алгоритмов в FBD - в виде функциональных блоков и связей между ними, комментарии можно везде вставлять. Вдобавок есть в нем маленькая SCADA - Прожектор называется, быстрые графики и небольшие мнемосхемы можно создавать. И главное все живое в реальном времени.

Anatol_K
unregistered
написано 16 Августа 2005 11:09  ПравкаОтветитьIP

Насчет того, что тревоги генерируются на контроллере. В этом есть некая сермяжная правда. Как правило, формирование тревожной сигнализации тесно связано с тем, как эти тревоги обрабатывает контроллер, например по превышению вибрации нужно остановить агрегат. Что я должен сделать? Сформировать тревогу и произвести останов. Как вы это делаете с iFix - пишете тэг по по обработке уставки, а потом то же самое делаете алгоритмически в Isagraf. Получается дубляж, да и уставки нужно синхронизировать. У нас же параметр обрабатывается алгоритмом и если нужно, по нему, в сервере тревог контреллера ставится признак тревоги , который передается в систему сообщений скады на АРМ.
Кроме того, если внешний контроллер не является элеменнтом нашего ПТК, а лишь передает информацию в нашу систему, то у нас для обработки параметров запускается внутренний контроллер, работающий под NT, который также формирует тревоги алгоритмическим способом. Внутренний контроллер под NT также используется как отладочное и тренажерное средство, поскольку внешне все выглядит как при работе с реальным контроллером.
Но вот "живых" средств отладки у нас пока нет, конечно это минус, но работы в этом направлении ведутся.
Интересный у нас разговор получается, а именно о несколько разных идеологиях построения систем. Могу высказать мнение людей, эксплуатирующих нашу систему и системы на Ifix + Concept (примерно то же, что и у вас). С точки зрения отладки и корректировки алгоритмов "вживую" предпочтение они отдают Conceptу, а вот когда дело касается интерфейса АРМ относительно, мнемосхем, управления, трендов, , тревог, архивов, то здесь они считают, что с iFix лучше не связываться и считают нашу систему более "очеловеченной".
Интересно было бы у вас еще узнать, есть ли у вас средства, позволяющие менять и настраивать какой нибудь аварийный датчик на работающей системе? И как у вас производится процесс переконфигурации алгоритмов на работающей системе, влечет ли это за собой какие либо непредсказуемые последствия? И вообще какие объекты вы автоматизируете, если не секрет?

Avsha
Junior Member

Сообщений: 17
Регистрация: Июль 2005

написано 16 Августа 2005 12:13ИнфоПравкаОтветитьIP

Тревоги подобного рода (например по превышению вибрации нужно остановить агрегат) мы формируем следующим образом:
На контроллере:
1. параметр вибрации – аналоговая переменная (AI_01)
2.уставка превышения - тоже аналоговая переменная (AI_02), которую есть возможность изменять из SCADA
3. результат сравнения есть дискретная переменная (DI_01), значение формируется в контроллере
На SCADE:
1. Заведены те же переменные AI_01, AI_02, DI_01
2. На параметр AI_01 введены границы предупредительной сигнализации HI,HIHI и включается генерация тревог
3. На параметр DI_01 включается генерация тревог (из 0 в 1, из 1 в 0 или изменение состояние).
4. Оператору предоставлены возможность установки уставки вибрации, и границ предупредительной сигнализации.
Часто уставки пробиваются жестко в контроллер и не требуют изменения.
Также можно при изменении уставки автоматически ее писать в границы HI,HIHI

Оператору тревоги представляются примерно в таком виде:
12.08.05 17:16:02,7 16:17:07,6 AI_01 HI 68,99 Значение параметра вибрации
12.08.05 17:26:02,7 DI_01 COS останов Сработала система отключения агрегата №1

По моему система достаточно гибкая, чтобы реализовать всевозможные ситуации.

Вы немного коснулись момента сравнивания готовых систем, как ваша, и сборных, как наша из универсальных SCADA и ПО конфигурирования и программирования контроллера.
Можно пообсуждать плюсы и минусы этих вариантов реализации ПТК, причем мне доводилось работать и с готовыми системами (Круг, ПИЛОТ).
Но позвольте немного защитить iFix – он действительно мощный пакет (по производительности и функционалу) с полной поддержкой VBA – полнофункционального языка программирования. Да – это конструктор, который необходимо дорабатывать под себя, для многих предприятий он не подойдет (у них нет возможностей и сил вести эксплуатацию и развитие систем), но как инструмент – он нас устраивает полностью и весь функционал мы в нем реализовали.

Отвечаю на вопросы:
1. С аварийным датчиком – не понял вопрос. Любой датчик снимаем/устанавливаем, при этом отключаем на некоторое время систему управления с Автомата на Ручной режим.
2. По переконфигурации алгоритмов – готовим изменение проекта, затем с организационными мероприятиями перегружаем, объекты – трубопроводы, мешалки, емкости, насосы, клапана.

Anatol_K
unregistered
написано 16 Августа 2005 15:09  ПравкаОтветитьIP

Я никоим образом не умаляю достоинств iFix. Это вы зря так подумали. Действильно мощное средство для разработки, да и насчет гибкости я не сомневаюсь. Только единственное - это действительно пакет для разработки. Конечно работникам КИП он не очень понятен и доступен. Да и спор , какая система хуже или лучше, тоже пустое занятие. Здесь на форуме достаточно копий по этому поводу сломано. В конечном итоге все определяется заказчиком системы. Он вправе выбирать, что ему нужно. Некоторым вообще никаких средств не нужно , а другим подавай все.
Цель нашей беседы, я думаю не спор, а обмен положительным и отрицательным опытом, поскольку работаем мы похоже над одними и теми же проблемами.
Ах да , насчет режима РЕМОНТ. Да , конечно его человек устанавливает, если агрегат действительно находится в отстое.
И еще насчет переконфигурации. Бывают такие ситуации, когда оргмероприятия быстро ну никак не удается осуществить. Во избежание всяких несуразностей в системе есть суперсекретный тумблер "отключение питания модулей телеуправления". Работники КИП не нарадуются никак на него. Так что можно спокойно творить в системе что хочется, все равно ничего не отключится, а контроль этого тумблера специально в систему не заведен. Диверсия скажете, но это по просьбе трудящихся сделано, да и нам она полезна бывает. Правда был случай, когда забыли киповцы про тумблерок, мда, забыли включить. Станция всю ночь пропахала без управления, понятно, что ничего не управлялось. Делали все вручную, бегали киломеровые кроссы открывать закрывать задвижки. ну намаялись бедолаги . А утром киповец пришел , втихушку включил тумблерок и как ни в чем не бывало. Объяснили все спонтанным влиянием магнитных бурь. Но это было давно.
Я спросил насчет аварийного датчика по той причине, что один заказчик достал этим требованием, чтобы он мог, например на работающей станции побаловаться загазованностью и чтобы ничего не происходило. Пришлось по всем датчикам, кроме режима запрета и имитации вводить так называемый испытательный режим и теперь это стало общесистемным подходом. Суть тут такая - ставим по датчику этот режим и он начинает работать только до уровня формирования тревог, при этом исполниельные действия по аварийным уставкам не происходят. Всем это очень понравилось.
Еще у меня к вам такой вопрос. Есть ли у вас в ситеме такое понятие как признак недостоверности датчика и что вы делаете в алгоритмах, если например датчик зашкалило в районе 20 ma (то есть короткое замыкание датчика произошло)

Avsha
Junior Member

Сообщений: 18
Регистрация: Июль 2005

написано 16 Августа 2005 16:01ИнфоПравкаОтветитьIP

Вы правильно подметили, что сравнивать ПТК - пустое занятие, у нас с успехом работают и те и другие системы.

Про "тумблер отключения":
Он у нас тоже широко используется, например для отключения шкафов релейных схем, и пользуются им как не странно и работники КИП и технологи, отключают эту "нехорошую" автоматику и давай вручную управлять аппаратом непосредственно через воздухораспределители и ИМ. А если серьезно, то к автоматике наши технологи ох как привыкли, простои тут же устраняются, для этого есть прикрепленные к участкам службы КИП.
Также распространены ПМУ в ответственных местах - посты местного управления, расположенные рядом с объектами, прибежал технолог или работник КИП, перевел на местное управление (отключил автоматику) и непосредственно управляет и видит как ходит заслонка.

Про "режимы":
Все виды режимов, которые у вас введены, похоже так или иначе, полностью или частично отключают или наоборот включают работу систем управления и защит, функции генерирования тревог, записи в протокол и другие. У нас тоже выработаны подходы к наименованию режимов систем САР, ДУ и поведению алгоритмов в этих случаях. Так например, мы выделяем режим места управления - откуда ведется управление (ПМУ - Щит - ПЭВМ) и режим работы регулятора Ручной - Автомат.

Ответ на ваш вопрос:
1. При масштабировании параметра в контроллере (перевода его из мА в технологические единицы)мы проверяем тот факт, находится ли значение мА в диапазоне 0-20 мА, если нет то формируем на каждый параметр дискретный сигнал недостоверности (забавно, что мы тоже назвали его таким словом). Его можно использовать для общей диагностики системы, чтобы у работника КиП утром зажглась лампочка о том, что с сигналом непорядок. В некоторых алгоритмах регуляторов проверяем сигнал на определенный допустимый диапазон изменения, при выходе за который, регулятор блокируется и выходит сообщение оператору.
Честно говоря до нормальной реализации диагностики руки у нас еще не дошли, хотя средства ПТК позволяют.

Anatol_K
unregistered
написано 17 Августа 2005 09:15  ПравкаОтветитьIP

Насчет лампочки понятно. А вот в алгоритма, что вы с этим параметром делаете? Ведь если по датчику стоит КЗ, напримео по вибрации, то значение ее выйдет за верхний аварийный порог, как при этом на эту вибрацию реагирует алгоритм останова и выдается ли тревога о превышении?
Кстати недостоверность для аналоговых датчиков у нас трактуется 4 причинами - обрыв, короткое замыкание, превышение градиента, неисправность оборудования ввода. Для дискретных тоже есть понятие недостоверности - это неисправность оборудования ввода. Для разных причин недостоверности обработка параметра в алгоритмах ведется по разному. Причем недостоверностью параметра может управлять и оператор.

Avsha
Junior Member

Сообщений: 19
Регистрация: Июль 2005

написано 17 Августа 2005 12:06ИнфоПравкаОтветитьIP

Мы делаем следующее:

1. Сигнализация. Включаем генерирование тревог по регулируемому параметру (той же вибрации), чтобы алармы выходили технологу на АРМ, а когда параметр достаточно требовательный к себе – делаем механический звонок, и выводим на него сигнализацию, чтобы оператор услышал в любом случае.
2. Поведение алгоритма. Представим алгоритм как блок, на вход которого заводим наш параметр в исходном виде, на выходе соответственно дискретный параметр (на отключение оборудования). Далее, у этого блока алгоритма есть входы блокировки. Для этого входа необходимо сформировать признак блокировки этой схемы управления и если этот признак пришел со значением = 1, то алгоритм не выдает управляющий сигнал на выход.
Теперь вопрос – как сформировать такой признак блокировки оборудования, причем признак мы относим к схеме управления в целом. Ведь признак блокировки может формироваться не только по аварийному значению параметра вибрации, но и по другим условиям.

Для большинства аналоговых датчиков мы ничего не делаем, надежности добиваемся за счет повышения надежности измерения и оперативности реагирования операторов в аварийных ситуациях, у которых есть ручное управление (у нас как я говорил постоянные оперативные службы КИП и технологов).
Т.е. работает схема Неисправность–Сигнализация–Ручное управление-Устранение

То есть у вас главная проблема отличить нормальную работу аналогового параметра от неисправного значения? А если неисправность вызвана средствами КИП, то это шишки в сторону АСУТП. Тогда правильное и корректное формирование признака недостоверности выходит на первый план. Опять же необходимо обратить внимание на надежность системы измерения.

Anatol_K
unregistered
написано 17 Августа 2005 12:56  ПравкаОтветитьIP

Насколько я понял, проблема автоматической реакции на недостоверность перед вами остро не стоит. За все действия отвечает оператор. Может быть вы просто не сталкивались с подобными проблемами. А вот представтье, из пункта А откуда то издалека по нашим поганым линиям связи в систему сбора поступает аварийный параметр, причем реакция алгоритма на него идет с выдержкой времени. И вот в момент работы этой самой выдержки времени, связь рвется и следовательно параметр становится недостоверным, поскольку что там на самом деле в данный момент происходит на том пункте А, неизвестно. Какова должна быть реакция на подобную недостоверность? Довести дело до конца и включить аварию или плюнуть на тот параметр и ничего не делать? Как вы думаете?

Avsha
Junior Member

Сообщений: 20
Регистрация: Июль 2005

написано 18 Августа 2005 07:05ИнфоПравкаОтветитьIP

Да, с такими задачами мне не часто приходиться сталкиваться, их не так много на нашем предприятии, поэтому могу лишь высказать свое мнение, а не предложить готовое решение.

Надо понять как часто происходят такие обрывы, и если причины в линиях связи принять меры по дублированию сигналов особенно важных параметров, может быть контрольный тест провести, передать сигнал на объект и получить ответ. Но главное не искать решение в том как приспособить алгоритм под “плохие” входные данные, а сделать эти данные “хорошими”. Конечно, если алгоритм будет четко определять недостоверность параметра это будет не лишним, но для этого надо алгоритму предоставить какие-то дополнительные данные и навертеть навеску проверки недостоверности, что иногда усложняет алгоритм.

У меня вопрос по другой теме:
Как в вашей системе реализуются расчеты на уровне SCADA, например расчеты которые используют данные нескольких контроллеров или расчеты типа усреднение/сумма за определенный период (час, сутки, месяц)?

Anatol_K
unregistered
написано 18 Августа 2005 12:40  ПравкаОтветитьIP

Да алгоритм несколько усложняется, но эта проблема давно решена и все причины недостоверностей анализируются в соответствующих блоках FBD. А информация о причине недостоверности забирается из статуса точки, который формирует контроллер на уровне драйвера и алгоритмы выявлением причин не занимаются.
Ваш вопрос я понимаю для себя , как вопрос об отчетах и сводках, которые может формировать скада (почасовые, посуточные и т.д), а также формирование архивных усредненных значений, которые могут быть использованы в качестве данных для построения усредненных трендов. В нашей скаде есть специальная утилита (менеджер сводок) которая решает задачи почасовой, посуточной и тд. регисрации данных и вывода их в виде таблиц. Исходная информация для менеджера формируется в контроллере, например в контроллере делается почасовой счетчик, который каждый час скидывает накопленное значение в заранее заведенную точку. Менеджер сводок забирает ее либо каждый час, либо по специальному сигналу от контроллера, который сообщает, что часовые данные готовы и заносит в таблицу с меткой времени. Сам менеджер сводок может настраиваться различными способами, либо формировать таблицу в течение часа, суток, декады, месяца и в конце таблицы все это суммировать либо формировать таблицу по запросу оператора. Вообще в сводку можно выводить любые данные, которые формирует контроллер и с различной временной логикой. В результате в архиве накапливается куча листов, которые можно экспортировать в различные форматы.
Кроме того сама скада решает вопросы и усреднения данных на внутреннем уровне архивной подзадачи. Во первых в архив сбрасываются мгновенные значения, а также эта подзадача усредняет данные за час, сутки, месяц и также сбрасывает их в архив. В результате при открытии тренда у вас имеется выбор, каие вы данные хотите посмотреть и за каой интервал времени. Очень интересными получаются тренды посуточных или почасовых данных, поскольку представляют собой гистограммы потребления, например природного газа, которые очень наглядно показывают процесс потребления в течение суток не в виде таблиц а а более удобных гистограммах.
Если в системе несколько контроллеров, то запускается дополнителный контроллер, работающий под NT, который и занимается обработкой данных от других контроллеров и результаты вычислений этого контроллера забирает менеджер сводок или архивная подзадача.
Можно сказать даже так, что если несколько контроллеров, то один (под NT) является как бы отдельной системой сбора и обработки со своей базой данных и скадой, а нижние контроллеры имеют уже свою базу данных и свои скады. Такие системы у нас внедрены как системы телемеханики, причем нижние контроллеры работают как автономные подсистемы.

Ваш ответ:

Коды форума
Смайлики


Ник:    Пароль       
Отключить смайлики
Страницы: 1 2 3 4 5

Все время MSK

Склеить | Разбить | Закрыть | Переместить | Удалить

Новая тема | Написать ответ
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика