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

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

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

Подписаться

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

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

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

Предлагается обсудить такой вопрос:
Какие программные инструменты нужны вам для разработки, эксплуатации, контроля работы и администрирования ПТК?
В теории - что необходимо, или в практике - что у кого работает.

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

Что имеется в видц под ПТК? Программно-технический комплекс? Если да, то программный инструмент для данной области, если хоть и не наука в чистом смысле, но цедое напрвление со своими ответвлениям. Поэтому вопрос, мне кажется стоит конкретизировать. Например, отправной точкой может являться обект автоматизации, далее идет выбор железа, под него точится драйверное ПО, потом алгоритмическое обеспечение, а потом ИЧМ в виде приложений СКАДЫ. Это общие принципы.

Avsha
Junior Member

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

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

ПТК - программно-технический комплекс, в общем случае состоит:
- полевая автоматика (датчики, исполнительные механизмы)
- контроллеры
- SCADA-система

т.к. программированию больше подлежат контроллеры и SCADA, то я имел в виду эти части ПТК.

Например:
- контроль работы и диагностика состояния контроллеров, ПЭВМ серверов, клиентов, сетевого оборудования

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

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

Avsha
Junior Member

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

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

Было бы интересно,
особенно какие функции каждый из элементов на себя берёт,
так как мне тоже на практике приходиться дорабатывать стандартный фукнционал SCADA и алгоритмов контроллера.


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

Во превых - исторически так было сделано, что ПТК у нас с точки зрения программного обеспечения - двухплатформенный. То есть на уровне контроллеров работает ОС РВ QNX 4.0. Здесь крутятся драйверы устройств ввода-вывода, которые к тому же решают диагностические задачи, в частности определяют исправность аналогового датчика по техническому диапазону (в противном случае выставляют наличие обрыва или КЗ по датчику), а также наличие ответа от устройств воода-вывода ( в противном случае устанавливается признак ошибки по датчику). Задачи ввода также приводят АЦП единицы к техническому диапазону датчика (то же с телерегулированием, только наоборот), чтобы снять эту функцию с алгоритмов. В контроллере QNX также крутятся алгоритмы, которые имеют две различных концепции работы, но это отдельная песня. Скажу лишь, что с точки зрения разработчика одни алгоритмы, которые написаны в среде Ремиконт, имеют табличную форму пердставления в контроллере и работают под задачами ОС QNX, а другие FBD и ST работают в режиме интерпретации. Вся информация, будь то входная или результаты вычислений алгоритмов, хранятся в ОЗУ контроллера в виде структур. Двухконтроллерные системы с резервированием имеют механизм так называемой репликации, то есть переноса данных с мастера на слэйв. Если существует какое либо расхождение, специальная программа диагностики информирует об этом оператора и запрещает переключение контроллеров, а там в зависимости от создавшейся ситуации. Далее, все необходимые данные из контроллера по протоколу ТСР или Modbus направляются на архивный сервер и на АРМ оператра, где крутится СКАДА под управлением NT2000 (раньше было NT 4.0). Данная СКАДА под фирменным названем КАСКАД-САУ имеет в своем составе некий прообраз ОЗУ контроллера, где и хранятися данные прекачанные с контроллера или направляемые ему. Данная СКАДА имеет все элементы разработки АРМ и алгоритмов (редактор базы данных точек,редактор мнемосхем, редактор табличных форм, редактор сводок, редактор алгоритмов Ремиконт, редактор алгоритмов IEC, настройщик архивных и текущих трендов, систему диагностики связи с серверами, доступ к архиву событий и вообще архивной иныормации, включая логи системы). В общем ничего сверхнового здесь нет. Просто это еще одно направление разработки САУ. Естественно мы развивиаемся, и то что я изложил - так было пять лет назад. На сегодняшний день у нас контроллеры не только под QNX но и под NT, есть и другие платформы, да и к устройствам мы не очень привязаны, поскольку ввели ОРС технологию в нашу систему. Но все же, дабы не сильно зависеть от разработчиков железа (поскольку производим и сами), все же используем тот двухплатформенный подход, который я описал. К сожалению информацией на нашем сайте похвастать не могу. Он не обновляляся года 2-3, но сейчас готовится обновление. Ну и еще - выпущена для продажи версия СКАДЫ Каскад-САУ.

Avsha
Junior Member

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

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

Да, у нас похожая структура.
В контроллерах внизу - QNX - Isagraf, наверху - iFix.
Только наша служба - в первую очередь внедрения и эксплуатации, а затем уже разработки.
Но разработать нам пришлось немало, чтобы привести проект к шаблонному использованию:

по контроллерам:
1) библиотека алгоритмов на ST в виде блоков, которые можно использовать в FBD.
масштабирование, обработка и т.д.
2) механизмы сохранения переменных при перезапуске контроллера
3) механизмы резервирования мастер-модулей контроллера

по SCADA:
1) разработка унифицированной системы обозначений переменных
2) разработка служебных видеокадров контроля и изменения переменных БД.
3) конфигурирование и настройка всех подсистем SCADA (сетевая структура, тревоги, защита, интерфейс пользователя, графики, панели управления, протоколы, расчеты и алгоритмы, диагностика и контроль всего комплекса из SCADA), создание дополнительных инструментов (про которые я и завел тему) для оперативного просмотра и управления всем этим хозяйством.

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

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

Как показывает практика, ничего готового, даже из существующего на рынке софта, практически нет. Всегда необходимо иметь группу адаптации софта под конкретные задачи и лезть практически в потроха этого софта. У нас с этим полегче, поскольку софт разрабатывается самими, причем программисты выдумывают не что то из головы, а тут же напрямую сотридничают с группой матаематической и информационной поддержки, которая в свою очередь контактирует с заказчиками и эксплуатацией объектов. Все огрехи сразу видны. Из всего перчисленного вами комплекса решенных проблем, многие мне знакомы им ногие также успешно решены. Возможно на сегодняшний момент интересна проблема сохранения переменных при перзапусках контроллера. В нашей версии ПО, сохранению подлежат только те переменные, которые когда то установил опреатор АРМ. Причем если контроллер грузится с нуля, то начальные значения считываются из конфигурационной базы данных, если же флэш память или другая энергонезависимая память уже были когда то проинициализированы первой загрузкой, то данные читаются из этой памяти. Но вот возникает проблема - в процессе работы вычислительного алгоритма, приходится хранить некоторые переменные, которые будут использованы не сразу, а скажем через час, и т.д. Представим, что контроллер рухнул, а потом его чинят неизвестно сколько времени и запускают. Поезд давно ушел, а он начинает вытягивать данные суточной давности и приходится для каждого конкретного случая решать проблему индивидуально, высчитывая при запуске время простоя контроллера. Если оно превышает какую то величину, инициализируем какие то переменные, если нет, то оставляем как было во флэшке. Эта проблема достаточно актуальна при построении ПАЗ систем, где защиты должны запоминаться на программных триггерах. И не дай бог, если эта защита куда то денется при перезагрузках. Такая же проблема стоит при учете чего нибудь количественного, где необходимо делать накопительные счетчики. И возникает масса проблем с пересчетом времен, аппроксимацией значений счетчика и т.д. Хотелось бы услышать ваше мнение, если таковой опыт имеется.

Avsha
Junior Member

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

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

Наша стратегия при сохранении следующая:
Делим все переменные контроллера на группы:
- переменные, значение которых при работе изменять не требуется
- переменные, которые редко меняются, но их стартовое значение КРИТИЧНО, пробиваем им в программе или в “начальных условиях” конфигурационной базы данных жесткое фиксированное значение. Соответственно намеренное изменение этих переменных осуществляется с принудительной перезагрузкой программы в контроллер. Муторно, зато надежно.
- переменные которые необходимо менять в процессе работы (коэффициенты, настройки регулятора, задания, выход регулятора т.д.). Здесь мы программно сохраняем значения таких переменных при их изменении в файл SRAM-энергонезависимой памяти. При перезапуске переменные берут начальное значение из этого файла, а если он по каким-то причинам недоступен или удален, то заранее выставленные “начальные значения” из конфигурационной базы данных – получается две степени защиты от потери данных.

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

Теперь применительно к вашим ситуациям:
- защиты – выбираем 2 способ сохранения, программные тригерра – я думаю меняются редко?
- счетчики – здесь есть вариант посчитать и наверху и там сгородить алгоритм аппроксимации, да и механизмы контроля расчетов и их корректировку при простое лучше организовать там.
- к вопросу безопасного включения алгоритмов и схем управления после длительного простоя, то здесь должно быть предусмотрено переключение управления Система управления – Ручное. И при длительном простое переходить оператору на ручное перед загрузкой контроллера, а затем ставить на автомат.

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

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

" - переменные которые необходимо менять в процессе работы (коэффициенты, настройки регулятора, задания, выход регулятора т.д.). Здесь мы программно сохраняем значения таких переменных при их изменении в файл SRAM-энергонезависимой памяти. При перезапуске переменные берут начальное значение из этого файла, а если он по каким-то причинам недоступен или удален, то заранее выставленные “начальные значения” из конфигурационной базы данных – получается две степени защиты от потери данных." - это напиано вами.
Как видим - это практически одно и то же, а именно это те измененния переменных, которые осуществляет человек в процессе работы. Да их обязательно надо восстанавливать.

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

Avsha
Junior Member

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

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

По какому признаку вы сохраняете переменные в этом случае?

У нас есть встроенный штатный механизм сохранения переменных с частотой цикла контроллера,
так называемый крыжик "Хранить" в IsaGraf, для вашего случая он как раз подойдет.

Но он имеет нехорошее свойство, если SRAM почистили или добавили/удалили крыжик для еще одного параметра в БД, то значения переменных с крыжиком обнуляются при перезагрузке.

Мы этот крыжик используем совместно с механизмом сохранения в файл SRAM для задания(Zdn) и выхода(Y) аналогового регулятора.

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

Насколько, я понял, если ваша переменная сохранена и вдруг кто то переконфигурит ваши крыжики, то для нормальной работы надо два раза перегрузить контроллер, первый раз вхолостую, когда переменные обнулятся,после чего еще раз, после которого переменные примут значения, которые они получили в "холостом" цикле работы контроллера.
Насчет признаков, по которым у нас сохраняются переменные: как правило сохраняются таймерные переменные и переменные, которые ответственны за хранение булевской информации в логических конечных автоматах, частным случаем которого является обыкновенный RS-триггер. Механизм таков - на этапе разработки алгоритма определяются все такие переменные, а в конфигурационной базе ставится не крыжик, как у вас, а галочка в соответствующей колонке. Тогда эти переменные сохраняются в каждом такте ситемы. Есть другой механизм - в FBD имеется специализированный блочок, который сохраняет подаваемую на вход переменную, причем можно выбрать либо каждый такт , либо по изменению, либо по меткам времени.
Вопрос сохранения не самый сложный. Более актуален вопрос, а как же мы будем восстанавливать переменные, в случаях сбоев контроллера. Тут все зависит, обслуживается система оператором или нет.Если это кратковременный сбой ( в течение одной минуты) и нет обслуживания, то восстанавливается все, а в архиве сохраняется "был перезагруз контроллера". Во всех остальных случаях по подтверждению оператора восстанавливаются только защиты, все остальное начинает заново формироваться алгоритмами.
Мне кстати непонятно, зачем вы сохраняете во флэш выход (Y) аналогового регулятора? Ведь за время простоя контроллера, регулирущее воздействие может измениться и вы получите на выходе скачок, скажем от 4 до 20 ma. И как вы решаете проблему при исчезновении питания на аналоговом выходе, который управляет регулятором? Конечно если сам регулятор умный и при значении управляющего воздействия равным нулю - остановится, то это хорошо, а если нет и закроет то что не нужно закрывать?

Avsha
Junior Member

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

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

Как я понял, у нас в общем одинаковые механизмы сохранения:
- с частотой цикла контроллера в энергонезависимую память SRAM через крыжик (галочку)
- по изменению или по времени (в том числе с чаcтотой цикла) в файл SRAM или FLASH

Выход (Y) аналогового регулятора мы сохраняем в файл SRAM и при кратковременной перегрузке контроллера как раз сохранение выхода не дает скачка, это значение заводиться на вход регулятора и используется при перезагрузке.
При длительном останове контроллера, управление переводиться на ручное управление со щита КИП, для особенно надежных случаях используются импульсные исполнительные механизмы.
По исчезновению питания: используются АВР и ИБП. Если совсем плохо управление переводится на щит КИП.

Как оператор в вашем случае подтверждает восстановление защит и влияет на процесс загрузки контроллера и и выполнение программ в них?

Сталкиваетесь ли в своей работе с задачами в SCADA?

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

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

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

Кстати нашел в другой ветке такое вот ваше сообщение
"3. Возникла задача оперативно отключать-включать тревоги (Tag.A_ENAB=NO/YES) по неработающему оборудованию,
чтобы исключить лишние срабатывания тревог, когда оборудование остановлено.
Может кто-нибудь сталкивался с этой задачей, поделитесь опытом и соображениями.
Интересует следующее:
а) отключать/включать параметры по одному или группами?
б) дать оператору отключать/включать параметры вручную или автоматически?
в) как напоминать оператору об отключенных тревогах -
показывать список/количество отключенных тревог или индицировать отключенную группу?

Могу поделиться следующим опытом по данной проблеме. Хоть в iFix я не силен, но идеология формирвания правильных тревог и сообщений - вещь достаточно серьезная и если будет отсутствовать четко разработанная концепция, в этих сообщениях черт ногу сломит, то же касается и тревог.

Так вот, начнем с пункта а)
1) Как правило под неработающим оборудованием можно понимать следующее: либо оно находится в нормальном режиме работы (АВТ,КНОП,РУЧ и т.д) и состояние его - ОТКЛЮЧЕН или же оно находится в режиме РЕМОНТ. Идея такова - если объект ОТКЛЮЧЕН, то перед пуском у работников КИП может возникнуть необходимость замены или проверки некоторых датчиков на предмет срабатывания сигнализации, поэтому мы не отключаем тревожную сигнализацию. Если объект выведен в Режим РЕМОНТ, вот тут вся тревожная сигнализация, связанная с этим объектом, а особенно с датчиками всяких защит - блокируется. Механизм следующий - в нашей системе ипользуются не переменные, а структуры и вот в этой структуре, помимо значения, хранится статус параметра, в частности есть там бит маскирования или запрета. При установке этого бита все тревоги по параметру исчезают. Как только оператор устанавливает режим РЕМОНТ во все статусы параметров автоматически однократно прописывается бит маскирования. Данный бит может устанаавливаться или сбрасыаваться оператором из АРМа, если есть такая необходимость, в любой момент.
Далее, при выводе агрегата из режима РЕМОНТ, бит маскирования по всем параметрам сбрасывается и разрешение по тревогам возобновляется.
По пункту б) - давать ли возможность оператору возможность отключать тревоги вручную. Это уже вопрос администрирования. В нашей системе в структуре параметра есть поле, ответственное за уровень доступа Так вот если администратор ситемы назначит оператору уровень досткпа, ниже чем имеющийся доступ по данному параметру, то ничего оператор сделать не сможет.
по пункту в) на мнемосхемах параметр с отключенной тревогой всегда выделяется цветом - аналоговый коричневым, вокруг дискретного - коричневая рамочка. В системе сообщений также имеется возможность сортировки, например показать все замаскированные параметры.
Кроме того в нашей системе имеется многооконаая система сообщений и тревог. В разных окнах можно сортировать параметры по разным признакам, например вывести окно всех активных тревог. Оператор может квитировать тревоги поштучно или все, а может включить режим автоквитирования, если ему это позволено. Но не следует путать квитирование с запретом тревог. При квитирование тревога не запрещается а лишь исчезает из окна тревог и возникает вновь при ее вторичном появлении. Понятно, что и звуковая сигнализация при квитировании - исчезает.

Ваш ответ:

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


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

Все время MSK

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

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

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

Copyright © skunksworks.net, 2000-2018

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


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