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

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

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

Подписаться

Автор Тема:   Необходимые программные инструменты в ПТК
Anatol_K
unregistered
написано 19 Августа 2005 20:16  ПравкаОтветитьIP

1. "Где будет находиться у Вас сервер тревог?" - на контроллере второго уровня, там же где и крутятся все алгоритмы. Если контроллер идет в улет или рушится связь, какой смысл в скаде заниматься генерацией тревог?
2. "Я считаю, что при хорошем ТП хранить архивы на АРМ-е оператора не получится." - правильно считаете и я того же мнения и во всех серьезных системах для архива отводится свой ПК. А то что с АРМа оператора можно достать по сети архивы, что ж в этом плохого то ?
3. "И сколько АРМ-ов оператора и архивных с контроллерами на одном ПК?" - отвечаю-ни одного ПК с таким набором приблуд в той системе нет, вещи там достаточно серьезные, чтобы можно было баловаться такими вещами. А вот на ЛПУМГах, ПК системы сбора сделан именно по такой схеме. Система сбора ведь вещь не такая серьезная, как управление магистральным агрегатом, там можно и не ставить дополнительных ПК и быстроты не требуется. Цикл опроса очень большой, бывает и за минуту зашкаливает.

Павел Мощицкий
Member

Сообщений: 1030
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

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

Anatol_K
какой смысл в скаде заниматься генерацией тревог?
А обработка алармов у Вас только автоматическая? Если ответ положительный, то смысл есть: с одной стороны АРМ оператора все равно прочитает, с другой, если упадет связь с верхним уровнем, все-равно отработка не штатной ситуации гарантировано.
Если контроллер идет в улет или рушится связь
Алармы бывают не только по вине АСУ ТП. Основное их предназначение - это сигнализация не штатных ситуаций ТП.
А то что с АРМа оператора можно достать по сети архивы, что ж в этом плохого то ?
Значит опять не правильно Вас понял.
Цикл опроса очень большой, бывает и за минуту зашкаливает.
Тогда да.

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

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

Avsha_offline
unregistered
написано 20 Августа 2005 22:41  ПравкаОтветитьIP

Немного вмешаюсь в ваши дебаты, по системе тревог и сообщений.
Я хотел обратить ваше внимание, что вопрос тревог и сообщений, как СИСТЕМЫ, более широкий.
Достаточно посмотреть реализацию в iFix (могу выслать .chm - справку).
Выделяются:
1. Генераторы тревог (они же SCADA-серверы БД реального времени, архивов)
(поддерживают резервирование и синхронизацию тревог)
2. Адресаты (получатели) тревог:
получают тревоги - в текстовый файл, в реляционную базу ODBC, оперативная сводка (окно) на АРМ, принтеры, сетевые клиенты АРМ.
3. Генерирование тревог возможно по аналоговому/дискретному параметру (границы сигнализации, срорость изменения, изменение состояния 0 - 1, приоритет)
4. Деление на группы тревог по технологическому оборудованию/по АРМ-у где показывать и т.д. - это так называемые зоны тревог. Каждому параметру назначается до 16 зон.
5. Рассылка сгенерированных тревог тревог по клиент-серверной сети указанным клиентам.
6. Формирование сообщений от программных приложений SCADA и
произвольных сообщений оператора с любого клиента АРМ.

Да, еще замечание, мы немного смешиваем генерирование тревог аналогового параметра по границам сигнализации, и сигнализацию отработки алгоритма по уставке.
По-моему здесь может быть по теории три (как максимум) сообщения сигнализации:
1.Аналоговый параметр - предупредительная сигнализация HI
2.Аналоговый параметр - критическая сигнализация HIHI
3.Алгоритм - сработала сирена по превышению заданной уставки аналогового параметра.

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

Павел Мощицкий
Member

Сообщений: 1033
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

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

Anatol_K
Так вот и зачем там запускать задачу обработки и генерации тревог, если нет информации?
Смотря где там. На АРМ-е? Нужно с сообщением о неисправности связи. Я не знаю, если у Вас отдельный экран или АРМ, отвечающий за контроль оборудования АСУ ТП, но какие-то ручные или автоматические действия должны быть, например, запуск механизма переключения на горячий резерв.
что то автоматически сделает контроллер по управлению технологического процесса
как призыв к автоматическому действию
Ну для истории и журнала алармов данный аларм носит чисто информационный характер. Если действие автоматическое, то оно не требует чьего либо подтверждение. А у Вас есть списки действий, которые прикреплены к аларму и запускаются при активизации аларма?

Добавление от 21 Августа 2005 00:54:

Avsha_offline
что вопрос тревог и сообщений, как СИСТЕМЫ, более широкий
Да мы до него еще и не дошли. Если Вы возьмете классификацию и системы работы с алармами GENESIS32, то они еще более разветвленные. Пока мы занимаемся конкретикой.

Avsha
Junior Member

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

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

Павел Мощицкий
По генерированию тревог на сервере, а не на контроллере:
Согласен с вами, у нас когда контроллер отвалился от сервера, по параметрам у которых включена сигнализация, для оператора на сервере генерируются сообщениия обрыва связи, тип тревоги - COMM.

А у Вас есть списки действий, которые прикреплены к аларму и запускаются при активизации аларма?
Мне кажеться не очень правильно привязывать какие-то конкретные действия к активизации аларма какого-то конкретного параметра.
Эта задача должна быть более гибкая - выполнение действия можно формировать с учетом многих входных данных:
- по изменению текущего значения параметра (или нескольких параметров),
- в том числе и по изменению текущего статуса тревоги параметра (-ов) (по вашему, активизации тревоги)
Один из примеров:Когда мы по одному или нескольким параметрам имеем текущую тревогу:СОMM, оператору вылетает экран - отказ контроллера, переведите такие-то схемы на РУЧНОЙ режим.

возьмете классификацию и системы работы с алармами GENESIS32
Не подскажете, где искать, в документации к DEMO-системе? где нибудь в WEB?

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

Говоря об алармах, всегда следует представлять, с какой системой мы имеем дело:
1) Система сбора информации - в данной системе все действия по аларму выполняет оператор. В такой системе достаточно обрабатывать параметр прямо в скаде и никаких контроллеров тут не нужно.
2) Система сбора и управления - вот здесь аларм напрямую может быть связан с исполнительными действиями, которые выполняет не оператор, а алгоритм на контроллере.
"А у Вас есть списки действий, которые прикреплены к аларму и запускаются при активизации аларма?" - вопрос, заданный П.Мощицким некорректен с той точки зрения, что не аларм должен вызывать действия а эти два процесса должны идти параллельно, а именно: нештатная ситуация -> действие + параллельно аларм. И не действия прикрепляются к аларму, а аларм и действие прикрепляются к нештатной ситуации. Как видим в данном случае, при нештатной ситуации и аларм и действие генерируются одинаковым образом, поэтому и целессобразно генерировать и аларм и действие в одном месте.

Далее, следует различать алармы технологические и алармы, не имеющие отношения к техпроцессу. Ко вторым следует отнести например, алармы относящиеся к исправности линий связи с серверами. В данном случае, алармы естественно должны генерироваться скадой, и дествия по данному аларму опять же должен принимать оператор.

Итак пришли к следующему:
1) Если действия по аларму выполняет исключительно оператор, то такие алармы могут генерироваться скадой
2) Если в результате нештатной ситуации нужно выполнить автоматические действия, то генерировать действие и аларм целесообразно в одном месте, например в контроллере, исключая дубляж в скаде

Avsha
Junior Member

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

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

Anatol_K

Чуть не согласен с вашими выводами:
Зачем делить задачу генерирования алармов на контроллеры и SCADA, если все можно сделать в SCADA. Может есть смысл, когда связь между контроллером и SCADA нарушилась, а в это время контроллер выполняет какие-то действия, то хотелось бы иметь архив и протокол алармов, чтобы узнать что там происходило, Но обрыв связи между SCADA-сервером и контроллером у нас как ЧП.
Немного перектрактую вами написанные цепочки
Нештатная ситуация -> изменение параметра 1 -> действие -> изменение параметра 2
изменение параметра 1 -> аларм 1
действие -> изменение параметра 2 -> аларм 2
Т.е. действие рождает аларм через изменение параметра. При этом алармы генерируются только в одном месте - SCADA.

Кстати как у вас решается вопрос, что на одни станции АРМ надо посылать аларм из контроллера, а на другие нет?

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

1. "Может есть смысл, когда связь между контроллером и SCADA нарушилась, а в это время контроллер выполняет какие-то действия, то хотелось бы иметь архив и протокол алармов, чтобы узнать что там происходило, Но обрыв связи между SCADA-сервером и контроллером у нас как ЧП." - вот вот , именно еще одна причина, по которой сервер тревог у нас находится на контроллере. Мы не расцениваем потерю связи как ЧП, это вполне нормальная ситуация на наших линиях связи. Если говорить о высконадежной сети, то и ее можно подцепить ковшом экскаватора или стрелой крана.
Кусочек вашей цепочки:
2. "Нештатная ситуация -> изменение параметра 1 -> действие ......
изменение параметра 1 -> аларм 1" Вот не кажется ли вам,что вы в контроллере и в скаде делаете одно и то же, а именно обработку изменения параметра 1 ?
3. "Кстати как у вас решается вопрос, что на одни станции АРМ надо посылать аларм из контроллера, а на другие нет?" - ну во первых - если на одном АРМе одни тревоги, а на другом другие - то это уже два разных АРМа, поскольку у них есть отличия. Во вторых - АРМ принадлежит к какому то одному тех.процессу и следовательно имеет некий набор алармов, которые не только отображаются как тревоги, но и валятся в архив и смысла разделять алармы по АРМам мы как то не видим. В третьих, если кого то не устраивает набор алармов, то он вправе выфильтровать нужные и убрать ненужные через опции окна сообщений.
И вот мой вопрос - предположим у вас N одинаковых АРМов. Добавляется параметр с обработкой аларма. Как вы синхронизируете в данном случае систему тревог всех N АРМов?

Avsha
Junior Member

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

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

Anatol_K
2. "Нештатная ситуация -> изменение параметра 1 -> действие ......
изменение параметра 1 -> аларм 1" Вот не кажется ли вам,что вы в контроллере и в скаде делаете одно и то же, а именно обработку изменения параметра 1 ?

Нет,

  • в контроллере по изменению параметра 1 производится действие,
  • в SCADA по изменению параметра 1 производиться генерирование аларма

здесь системы выполнения алгоритма и генерирования тревог развязаны и более универсальны.
(была бы возможность на форуме нарисовать схемку и поместить в тему, мы бы быстро обсудили все вопросы.)

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

Вот реальная схема, у нас 3 АРМ-а, расположенные в трех разных зонах (назовем эти зоны A,B и С), на всех доступна информация по всему участку. Информация собирается сервером со всех контроллеров и передается всем АРМ-ам.
Для примера, мы включаем генерирование сигнализации по параметру, тревоги которого должны лететь только на АРМ-"C". Для этого нам надо в свойствах этого параметра в БД сервера указать, что тревоги должны лететь в зону С, это штатный механизм.
Окна просмотра и квитирования алармов на клиентах (АРМ-ах) настраиваются на прием сообщений своих зон A, B и С соответственно. В итоге, тревогу видит и квитирует только оператор на АРМе "C".

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

1. "в контроллере по изменению параметра 1 производится действие,
в SCADA по изменению параметра 1 производиться генерирование аларма" - давайте здесь заострим внимание не на результате, а на "по изменению параметра". Итак , параметр изменился - контроллер сравнивает его с уставкой, далее - параметр изменился - скада сравнивает его с уставкой (зона Н или НН , не важно). Логика обработки в контроллере и скаде - одинакова. Вот что я имел в виду , когда говорил, про одно и тоже. И как следствие - добавление еще одного порога, по которому надо действовать (например LL) влечет за собой и изменение алгоритма контроллера и изменение в скаде. Гибко и независимо, но громоздко.
2. "Информация собирается сервером" - поясните про сервер, это сервер данных или сервер тревог, или все вместе? И где генерируются тревоги - на этом общем сервере или на каждом АРМе в отдельности?

Avsha
Junior Member

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

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

для Anatol_K
цитата:
"Информация собирается сервером" - поясните про сервер, это сервер данных или сервер тревог, или все вместе? И где генерируются тревоги - на этом общем сервере или на каждом АРМе в отдельности?

Структура ПТК следующая: Контроллеры (10шт) -> 2 Сервера (резервируемых) -> 3 АРМа.
Сервер является сервером данных, тревог и истории. На нем выполняется задача SAC-обработки БД реального времени, а именно - выполняются процессы сканирования (сбора данных), генерирования тревог, и выполнения алгоритмов (обработка данных). Т.е. генерирование тревог идет параллельно с обработкой базы данных реального времени на SCADA-серверах.
Тревоги генерируются на сервере и отсылаются на АРМы.
АРМ-ы только получают данные и тревоги, операторы на АРМах тревоги квитируют (подтверждают кнопкой получение тревоги).
Сам же процесс квитирования происходит на сервере,(могу выслать .chm - справку).

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

Таким образом, и у вас и у нас сервер тревог и АРМ разделены и проблема синхронизации АРМов автоматически отпадает. Насчет синхронизации - видите ли существует и такой подход - на каждом АРМе в скадах запускается своя отдельная задача генерации тревог и для того, чтобы на всех АРМах тревоги работали одинаково, их нужно править на всех АРМах. А вот по поводу того, чтобы данные со всех контроллеров поступали на единый сервер а затем раздавались клиентам (причем выборочно), то это уже относится к иделогии построения системы. Как правило для систем, в состав которых входят автономные подсистемы, мы избегаем такой централизации и к каждому контроллеру подцепляется своя группа АРМов, которые имеют единую систему тревог. Обмен между контроллерами может вестись на уровне клиентов данных каждого контроллера. Если же мы делаем централизованную систему как у вас, то на одном ПК запускается как и у вас задача сбора данных и формирования тревог, только входит она у нас не в функции скады, а в функции контроллера, который запускается под NT и в частности может выполнять те же функции, что и ваш сервер тревог на iFix, только у нас это делается на языках IEC(FBD, ST). Чего у нас нет, так это раздача с единого центра различного списка тревог различным клиентам - все клиенты, подцепленные через сеть к одному контроллеру - равнозначны . Может быть и стоит нам разделить возможности клиентов и ваша идея даже очень разумна. Просто мы не встречались с такими требованиями. Поясните практическую пользу такого разделения.

Mihan
Junior Member

Сообщений: 2
Откуда: Кемерово
Регистрация: Август 2005

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

Вообще , если связь между контроллерами и скадой переодически пропадает то Вам надо что то делать со связью а не мудрить с тем " где же лучше отрабатывать сигнализации ? " :-)

Avsha
Member

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

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

для Anatol_K

Поясните практическую пользу такого разделения.
У нас ПТК на участок, участок состоит например из 3-х узлов, на каждом узле свой оператор с АРМ, за ним закреплено определенное оборудование, соответственно и тревоги он хочет получать только по своему оборудованию, а не по узлу соседа.
На всех АРМ доступна вся информация и проект SCADA для всех АРМ-ов у нас один, с небольшими отличиями. Это мы считаем своим небольшим достижением.

Павел Мощицкий
Member

Сообщений: 1037
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

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

Avsha
- по изменению текущего значения параметра (или нескольких параметров),
А кто мешает в списках воздействий использовать условия?
переведите такие-то схемы на РУЧНОЙ режим
Думаю, можно и это сделать автоматически.
где искать
Ну тут вопрос к Формозе. Если документации у демо-версии мало. Хотя, я большинство взял оттуда.

Avsha
Member

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

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

для Павел Мощицкий

А у Вас есть списки действий, которые прикреплены к аларму и запускаются при активизации аларма?
А кто мешает в списках воздействий использовать условия?

Активизация аларма (в нашей системе) - это изменение конкретного свойства параметра - текущая тревога.
Мне кажется, довольно жестко привязывать действия только к одному из свойств и только одного параметра.
В iFix у нас работает программное средство - планировщик, запускаемый по изменению любого из свойств (текущее значение, текущая тревога, и др.) параметра, а также по логическому выражению, или по времени.
Если значение выражения = истина, то запускается скрипт VBA, где можно нагородить условий и действий сколько угодно.

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

Когда видишь, что для программирования контроллера используются одни средства, а для конфигурирования той же самой системы тревог нечто иное, становится несколько скучно. Если уж говорить о ПТК, как о едином комплексе, все что связано с технологией и информационным обеспечением, должно было бы выполняться в единой среде, в тех же языках IEC например. К сожалению разработчики скад это плохо понимают. Считаю это большим недостатком существующих систем, ибо говорю это не голословно, а высказываю мнение людей , эксплуатирующих системы, поэтому в нашей скаде выбрана и разрабатывается стратегия единой среды технологического и информационного программирования, будь то контроллер, будь то анимация или система тревог.

Ваш ответ:

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


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

Все время MSK

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

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

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

Copyright © skunksworks.net, 2000-2018

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


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