На форуме обязательно:
  1. Заполнить свой профиль НА РУССКОМ ЯЗЫКЕ КИРИЛИЦЕЙ. См. Правила, п.2.d.
  2. Не писать свой вопрос в первую попавшуюся тему, а вместо этого создать свою. См. Правила, п.3.a.

Рекламу мы не размещаем ни на каких условиях.

Актуальные задачи АСУТП

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

Автор темы
Большаков Олег

Актуальные задачи АСУТП

Сообщение Большаков Олег » 16 окт 2009, 00:32

На базе СКБ института занимаюсь автоматизацией оборудования лабораторных стендов (РТК). Создана программная система автоматизации, разработаны языки представления управляющих программ: текстовый, и графические (http://gmdidro.googlepages.com/ironhand.htm).

Выиграли в этом году с этой системой конкурс У.М.Н.И.К (www.fasie.ru), получили финансирование в размере 200 тыс. рублей на внедрение созданной программной системы для программирования ПЛК.

Однако, как оно обычно и бывает, после более детального изучения существующей ситуации на рынке автоматизации производства, возникло ощущение, что подобная система не будет востребована. Основной преградой является закрытость продуктов таких популярных производителей, как Siemens, Mitsubishi и тому подобных гигантов области автоматизации. Предлагают они пользователям надежные, масштабируемые решения, однако не всегда оптимальные как по ценовым характеристикам, так и по некоторым другим параметрам (например, не всегда удобно программировать контроллеры только на языках стандарта МЭК). Программные продукты этих фирм не всегда удобны в использовании (например, банально поразило отсутствие возможности скроллирования окна редактора программы при разработке ее в виде LD в GX Developer от Misubishi).

Попытки найти возможность встраивания в существующие системы (ведь у них уже есть богатый и удобный инструментарий, зачем изобретать велосипед!), тоже не увенчались успехом. Так, например, оказалось, что при всей возможности встраивания плагина в систему CoDeSys, придется за это удовольствие заплатить порядка 50 тыс. евро (сам вариант встраивания плагина в CoDeSys, который бы позволил пользователю использовать альтернативные языки разработки управляющих программ, выглядел очень привлекательным).

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

Буду рад любым оценкам, идеям и тем более предложениям. Сложилась ситуация - деньги выделены, программисты\электронщики есть, есть и опыт работы, а вектора развития нет.

Спасибо,
Большаков Олег,
email: viona31@gmail.com

Аватара пользователя

VADR
администратор
администратор
Сообщения: 2821
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 58 раз
Поблагодарили: 42 раза

Re: Актуальные задачи АСУТП

Сообщение VADR » 16 окт 2009, 08:24

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


pike
частый гость
частый гость
Сообщения: 406
Зарегистрирован: 08 авг 2008, 09:43
Имя: Щукин Андрей Александрович
Благодарил (а): 1 раз
Поблагодарили: 8 раз

Re: Актуальные задачи АСУТП

Сообщение pike » 16 окт 2009, 09:21

Большаков Олег писал(а): (например, не всегда удобно программировать контроллеры только на языках стандарта МЭК).
В корне, не верное предположение. Формы языков МЭК взяты не с потолка: это набитые шишки в разработке и обслуживание систем в течение 40 лет. Так же как и вот это:
Если сравнивать предложенное языковое решение с применяющимся сейчас в автоматизации промышленности, то стоит в первую очередь сравнить с распространенными языками стандарта МЭК-61131-3 (IL, ST, LD, FBD и SFC) и их прямыми аналогами (СFC, упрощенный SFC) [3]. Языки данного стандарта имеют ряд недостатков [4,5]. Очевидно, что стандарта из пяти языков принятых более 15-ти лет назад не может быть достаточно для эффективного применения в разных предметных областях автоматизации. Так выходит и в ситуации создания данного аппаратно-программного комплекса: намного эффективнее оказывается язык, изначально заточенный под данную предметную область, каким и является LPMED.
1) МЭК, не отражает полного функционала языков программирования брэндов. Тот же LD с доп. функциями не плохо описывает позиционное управление, а SFC и управление движением.
2) "За пределами" МЭК уже существует два давно развивающихся языка CFC и Motion BASIC.
4) В машиностроение в подавляющем большинстве случаев используется один язык - LD. Иногда дополненый SFC, иногда Motion BASIC. Все довольны.
Большаков Олег писал(а): Насколько это вам интересно, стали бы вы использовать данные языки представления программ? Нет ли у вас каких-либо вариантов применения данных языков для решения каких-либо проблем или реализации специфических решений?
Язык программирования без привязки к характеристикам контроллера - это слишком абстрактно. Однако, замечу что представление списка команд мне не понравилось из-за горизонтальной прокрутки. Не удобно.
Авторы ТЗ, с которыми я работаю, не имеют права жаловаться на дороги, ЖКХ, бюрократию и правительство.


Автор темы
Большаков Олег

Re: Актуальные задачи АСУТП

Сообщение Большаков Олег » 16 окт 2009, 20:39

Создавали учебно-методический программно-аппаратный комплекс для проведения лабораторных в институте, разработали IronHand. Один из моих коллег, также сотрудник СКБ, в это время занимался автоматизацией комплекса на одном из предприятий города. Комплекс предназначался для создания особого вида материала, представлял из себя установку для плавки металлов. Соответственно, в комплекс входили: большая печка, вентиляторы, задвижки и т.п. Оборудование выбрали Mitsubishi: контроллер серии FX, частотные преобразовали (с нашей стороны нужна была прежде всего программная составляющая комплекса, почему именно с нашей стороны? да ведь так дешевле )) ). “Так дешевле” свелось к тому, что был приобритен наиболее дешевый стандартный пакет разработчика, в котором не было ни FBD, ни SFC. Человек, занимавшийся со стороны СКБ данным проектом – опытный программист, победитель большого количества конкурсов и олимпиад. По-моему, только такой человек возьмется реализовывать логический параллелизм на ассемблере IL в размере тысяч строк программного кода. Проследить в такой программе логику…ну сложно ее проследить ))
Тогда и возникли мысли по поводу возможных языков, применяемых в автоматизации, конечно же в сравнении с разработанными нами. Появилась идея использовать систему не напрямую для управления оборудованием, а для программирования контроллеров, которые будут уже автономно управлять установками. Тогда от бизнес-инкубатора пришло предложение учавстовать в конкурсе У.М.Н.И.К., победителям которого будет предоставлено финансирование из фонда Бортника (на самом деле 200 тыс – лишь первый год, далее при желании возможно продление и большие суммы). Программа государственная, всероссийская, проходит в рамках Зворыкинского проекта (http://zv.innovaterussia.ru/), финансирование вовсе не из РОСНАНО (точнее, Роснано спонсирует некоторые проекты в рамках Зворыкинского, но, очевидно, что только нано-проекты). С помощью данной программы поддерживаются наиболее перспективные проекты во многих регионах нашей страны.
Все аргументы в сторону невозможности нахождения на рынке автоматизации рынка стали видны нам после подробного изучения этой области. Те фирмы, которые и занимаются разработкой ПО, в первую очередь продают само оборудование как минимум, если не разрабатывают его сами. ПО разрабатывается в комплект оборудованию. Причем предприятие как заказчика мало интересует, насколько удобные языки будут использоваться для программирования контроллеров. Если нужно, наймут специалистов, да и свои всегда имеются. Зато Siemens. Зато надежно.
Значит ли это, что программная составляющая автоматизации производства сейчас полностью продиктована условиями рынка и ее развитие возможно лишь за счет воли монополистов? Здесь нет места полностью открытым системам, в которые можно было бы встроиться? Неужели новые подходы не нужны лишь из-за того, что не прорваться на рынок? А если нужны, то какие? Какие возникают проблемы при работе с программными системами? Неужели никого не заинтересует, например, возможность встраивания верификации управляющих программ (насколько мне известно, данный подход применяется редко)? Интересно узнать мнения по данным вопросам.


Автор темы
Большаков Олег

Re: Актуальные задачи АСУТП

Сообщение Большаков Олег » 16 окт 2009, 21:05

pike писал(а): В корне, не верное предположение. Формы языков МЭК взяты не с потолка: это набитые шишки в разработке и обслуживание систем в течение 40 лет.
Cтандарт МЭК-61131-3 принимался в 1993. По вашему мнению, за 17 последних лет новых шишек не набилось? CFC и Motion BASIC в МЭК не входят, а появились как раз потому, что МЭКа не достаточно.
pike писал(а): Язык программирования без привязки к характеристикам контроллера - это слишком абстрактно.
Действительно, контроллер устройство специфическое, именно поэтому нестандартное. Здесь играет необходимость надежности и максимального быстродействия. Однако заметим, что универсальность в последнее время приобретает все большее и большее распространение. Именно тем и выгодно универсальное устройство, что существует множественный удобный инструментарий для его программирования. И тогда технологу, задающему техпроцесс будет достаточно знать тот тех процесс, который он хочет реализовать, а специфические средства (компиляторы, оптимизаторы и т.п. для данного вида оборудования) заточат его управляющую программу под используемое им оборудование. Именно абстрагирование, программирование на уровне человеческого языка - вот приоритетное и перспективное направление, по которому сейчас происходит движение многих систем программирования и CASE-средств. Вы не считаете этот подход перспективным?
pike писал(а): Однако, замечу что представление списка команд мне не понравилось из-за горизонтальной прокрутки. Не удобно.
Неудобно, потому что вы предпочитаете вертикальную прокрутку? Или же считаете неэффективной концепцию представления программы/использования рабочего места?


pike
частый гость
частый гость
Сообщения: 406
Зарегистрирован: 08 авг 2008, 09:43
Имя: Щукин Андрей Александрович
Благодарил (а): 1 раз
Поблагодарили: 8 раз

Re: Актуальные задачи АСУТП

Сообщение pike » 19 окт 2009, 09:33

Большаков Олег писал(а): Cтандарт МЭК-61131-3 принимался в 1993. По вашему мнению, за 17 последних лет новых шишек не набилось? CFC и Motion BASIC в МЭК не входят, а появились как раз потому, что МЭКа не достаточно.
МЭК не отражал (не дотягивал) фукционала языков программирования ПЛК основных брэндов уже в 1993. Что уж говорить про сегодняшний день. При этом при создании МЭК многое было оставлено за бортом, в частности уже почти созревшей motion control (зато потом опять начали догонять под названием PLCOpen). Тот же Motion BASIC появился раньше, чем приняли МЭК, да и в принципе Motion BASIC это скорее развитие идеи ST. С CFC такая же история: FBD рос, рос и вырос. Кстати, у многих он так и остался называться FBD.
Да и так, между делом, а что нового может быть в работе с битами? А это, занимает где-то процентов 70-80 проекта для машиностроения.
Большаков Олег писал(а): Именно абстрагирование, программирование на уровне человеческого языка - вот приоритетное и перспективное направление, по которому сейчас происходит движение многих систем программирования и CASE-средств. Вы не считаете этот подход перспективным?
В том смысле, в каком это представляется Вам – да, подход бесперспективен. В промышленности имеют дело не «человеческим» языком, а «инженерным» и LD (РКС), FBD, SFC вполне соответствуют ему соответствуют. В машиностроении программирует не технолог, а электрик, приводчик или инженер-механик. Пытаться переучивать людей загруженных по самый «не балуй» – это гарантированное отторжение системы, вплоть до саботажа.
Большаков Олег писал(а): Неудобно, потому что вы предпочитаете вертикальную прокрутку? Или же считаете неэффективной концепцию представления программы/использования рабочего места?
Скаже,м так эргономика: всегда требуется однотипность действий. Если есть список требующей прокрутки, его надо делать вертикальным, так как такая прокрутка воспринимается человеком автоматически, ему не надо над данным действием думать.

Ну, и возвращаясь в вашему вопросу: Что делать?
Если я бы занимался вашим проектом, то я делал бы среду программирования для так называемых machine controller. За базу взял бы два МЭК языка (что клиенты работников не переучивали) SFC (основная структура проекта и управление движением) и LD (дискретка, …). Дальше пробовал бы подвязать это к фаствел, октагон…
Авторы ТЗ, с которыми я работаю, не имеют права жаловаться на дороги, ЖКХ, бюрократию и правительство.

Аватара пользователя

TEB
администратор
администратор
Сообщения: 9655
Зарегистрирован: 17 июн 2008, 15:01
Имя: Евгений свет Брониславович
Благодарил (а): 122 раза
Поблагодарили: 143 раза
Контактная информация:

Re: Актуальные задачи АСУТП

Сообщение TEB » 19 окт 2009, 12:07

Да, Дим, у вас в компании замечательная практика. На моем прошлом месте работы было примерно также но попроще: для каждой нетривиальной задачи рассматривались несколько решений, перед лицом корифеев надо было еще обосновать своё решение чтобы оно пошло в производство, причём корифеи как проектировщики, так и производственники (финансисты, технологи), и когда решение шло в производство и в итоге успешно работало на объекте, авторов поощряли и почётом и материально. Это здорово подхлёстывает молодых специалистов - по себе помню, был азарт.
И момент поощрения очень правильно выбирался: именно опытная эксплуатация заказчиком показательна. Естественно, потом эти решения если они оказывались успешными распространялись по всей конторе как типовые. Так что это очень правильные моменты при выборе любой новации:
  • чтобы было экономически обосновано
  • чтобы было удобно и возможно применение в качестве типового решения
  • чтобы было эффективно и удобно с точки зрения заказчика
А в нынешнее время предугадать мнения заказчиков у нас в России стало куда как проще чем 15 лет назад: заказчик с одной стороны привык к тому что он обычно пользует (значит принцип построения можно взять от имеющегося), а с другой стороны тот же опыт подсказывает ему то что хотелось бы улучшить. И упаси RND предлагать что-то ну совершенно целиком инновационное, потому как это напугает заказчика необходимостью переучиваться полностью.
По вопросам работы Форума можно обратиться по этим контактам.


Автор темы
Владимир Николаевич

Re: Актуальные задачи АСУТП

Сообщение Владимир Николаевич » 11 янв 2010, 13:18

Олег, а почему вы не используете отечественные контроллеры "МИКОНТ", "РЕМИКОНТ", "КОНТРАСТ" и программное обеспечение ЭСКАДА-КАСКАД. Я работаю с ними уже 20 лет и никаких проблем, все вопросы с поставщиками решаются очень быстро. :(


Автор темы
Владимир Николаевич

Re: Актуальные задачи АСУТП

Сообщение Владимир Николаевич » 13 янв 2010, 18:29

Смотрите характеристики "РЕМИКОНТ 320",
"КОНТРАСТ КР 300", "КР 500".


Автор темы
Владимир Николаевич

Re: Актуальные задачи АСУТП

Сообщение Владимир Николаевич » 13 янв 2010, 18:51

Дозирование на "КР 300"
У вас нет необходимых прав для просмотра вложений в этом сообщении.

Аватара пользователя

TEB
администратор
администратор
Сообщения: 9655
Зарегистрирован: 17 июн 2008, 15:01
Имя: Евгений свет Брониславович
Благодарил (а): 122 раза
Поблагодарили: 143 раза
Контактная информация:

Re: Актуальные задачи АСУТП

Сообщение TEB » 13 янв 2010, 19:28

Владимир Николаевич писал(а):Дозирование на "КР 300"
Так. Теперь уже я близок к точке кипения. Владимир Николаевич, ещё один рекламный пост и случится непоправимое.
По вопросам работы Форума можно обратиться по этим контактам.


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2610
Зарегистрирован: 10 ноя 2009, 04:58
Имя: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 75 раз
Контактная информация:

Re: Актуальные задачи АСУТП

Сообщение Михайло » 13 янв 2010, 20:59

Шкафчик на фотографии сделан аккуратно, но не технологично. Сейчас в моде более компактные клеммы и реле. И еще используют перфорированные короба. Ищите тему монтажа шкафов на форуме АБОК. Ну и желтый цвет - это цвет газопроводов и предупредительной сигнализации...

Аватара пользователя

VADR
администратор
администратор
Сообщения: 2821
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 58 раз
Поблагодарили: 42 раза

Re: Актуальные задачи АСУТП

Сообщение VADR » 13 янв 2010, 23:33

Михайло писал(а):Шкафчик на фотографии сделан аккуратно, но не технологично. Сейчас в моде более компактные клеммы и реле. И еще используют перфорированные короба. Ищите тему монтажа шкафов на форуме АБОК. Ну и желтый цвет - это цвет газопроводов и предупредительной сигнализации...
Внешне, конечно, шкаф смотрится аккуратно, но:
1. Плотность монтажа чрезвычайно низка. Судя по рядам реле, это шкаф ввода дискретных сигналов ~220В. 45 релюх - 45 сигналов. Так? У меня на объектах, где используется ввод/вывод ~220В, шкаф ввода/вывода вмещает до 256 сигналов. Это при далеко не самой новой технологии, но значительно удобнее в монтаже и обслуживании.
2. В левой части два пучка кабелей никак не закреплены в непосредственной близости к месту разделки и висят на контактах. Зацепиться и дёрнуть - и весь ввод-вывод - нафиг. Недопустимо.
3. Вводные автоматы - внутри на левой стенке. Для того, чтобы увидеть маркировку автомата, надо практически залезть в этот шкаф. Глубина, если не ошибаюсь, 600 мм? Это человек туда полностью войти может. Учитывая, что там ~220В, это ещё и опасно.
Так вот вопрос к автору снимка: это иллюстрация того, как нельзя делать? Или какой другой смысл этой фотографии?

PS: Уже и я закипел :twisted:
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.

Аватара пользователя

Marrenoloth
завсегдатай
завсегдатай
Сообщения: 523
Зарегистрирован: 05 окт 2009, 10:51
Имя: Тихомиров Дмитрий Викторович
Откуда: Москва
Благодарил (а): 17 раз
Поблагодарили: 20 раз
Контактная информация:

Re: Актуальные задачи АСУТП

Сообщение Marrenoloth » 13 янв 2010, 23:56

VADR писал(а):Глубина, если не ошибаюсь, 600 мм? Это человек туда полностью войти может. Учитывая, что там ~220В, это ещё и опасно
Идеальный шкаф для любовников жены! А Ремиконт пусть его медленно до хрустящей корочки со всех сторон прожаривает! :twisted:

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


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2610
Зарегистрирован: 10 ноя 2009, 04:58
Имя: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 75 раз
Контактная информация:

Re: Актуальные задачи АСУТП

Сообщение Михайло » 14 янв 2010, 05:03

Marrenoloth писал(а):А теперь вставлю свои 5 копеек:
Как человек, не так давно закончивший институт (конкретно МЭИ, Теплотехника, кафедра АСУ ТП), могу сказать, что при выходе из института я не только не понимал задачи АСУ (не говоря уже об их актуальности), но и АСУ от козы не отличал! Хоть, спасибо большое, разнице между термометром сопротивления и термопарой объяснили! Вообще ничего не дали. Но программирование Протаров (если не ошибаюсь, то он предшественник и младший брат Ремиконта) запомнилось надолго. Такое ощущение что пытаешься получить переходную характеристику с арифмометра...
Что правда так плохо все в МЭИ? У нас в УГТУ-УПИ тоже не все гладко... Но это уже в прошлом, на производстве я уже получил информации в 3 раза больше (мне 29 лет).

Аватара пользователя

green_3mii
осмотрелся
осмотрелся
Сообщения: 179
Зарегистрирован: 18 авг 2009, 14:30
Имя: Алексей
Откуда: Волгодонск
Контактная информация:

Re: Актуальные задачи АСУТП

Сообщение green_3mii » 14 янв 2010, 09:29

Дозирование на "КР 300"

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

Ах, да, еще и бирок не повешано - где какое реле, клеммник и т.д...

Аватара пользователя

Marrenoloth
завсегдатай
завсегдатай
Сообщения: 523
Зарегистрирован: 05 окт 2009, 10:51
Имя: Тихомиров Дмитрий Викторович
Откуда: Москва
Благодарил (а): 17 раз
Поблагодарили: 20 раз
Контактная информация:

Re: Актуальные задачи АСУТП

Сообщение Marrenoloth » 14 янв 2010, 15:55

Михайло писал(а):Что правда так плохо все в МЭИ? У нас в УГТУ-УПИ тоже не все гладко... Но это уже в прошлом, на производстве я уже получил информации в 3 раза больше (мне 29 лет).
Я, конечно, малость утрирую, но реально хорошо давали ТАУ, теорию эксперимента и математическое моделирование. Т.е. из полезного - самое начато ТАУ. Все остальное выходит за рамки ежедневных необходимостей АСУшника...
Программирования, как такового, не было. Да, мы изучали основы VB и C, но основы языков это не теория программирования, не основы программирования логических контроллеров и уж тем более не живая работа со стендами с современными АСУ. Из экспериментальных вещей были уже помянутые Протары и МН7 - гроб с четверть кубометра с усилителями внутри. На верхней панели миллион контактов. Правильно соединяя их можно было получить основные передаточные звенья. Потом на самописец (сами понимаете, не цифровой) снималось выходное напряжение системы - ее переходная характеристика. Ну и все! На втором курсе еще давали основы TraceMode'а но, сами понимаете, что это не дело для второкурсников. Да и давали их без контроллеров - все писали внутри него же.
Есть в МЭИ еще 2 кафедры АСУ - на АВТФ и Электротехе. Как там дела- не знаю. Отношения с ними не поддерживались (видимо, профессиональная конкуренция)...

Ответить

Вернуться в «Общие вопросы»