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

[Большаков Олег]

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

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

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

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

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

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

Спасибо,
Большаков Олег,
email: [email protected]

[VADR]

Но это в случае, если он будет не просто конкурентоспособен, но и превышать по своих характеристикам западные аналоги. А еще- очень надежен.

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

[pike]

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

В корне, не верное предположение. Формы языков МЭК взяты не с потолка: это набитые шишки в разработке и обслуживание систем в течение 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. Все довольны.

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

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

[Большаков Олег]

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

[Большаков Олег]

В корне, не верное предположение. Формы языков МЭК взяты не с потолка: это набитые шишки в разработке и обслуживание систем в течение 40 лет.

Cтандарт МЭК-61131-3 принимался в 1993. По вашему мнению, за 17 последних лет новых шишек не набилось? CFC и Motion BASIC в МЭК не входят, а появились как раз потому, что МЭКа не достаточно.

Язык программирования без привязки к характеристикам контроллера - это слишком абстрактно.

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

Однако, замечу что представление списка команд мне не понравилось из-за горизонтальной прокрутки. Не удобно.

Неудобно, потому что вы предпочитаете вертикальную прокрутку? Или же считаете неэффективной концепцию представления программы/использования рабочего места?

[pike]

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 (дискретка, …). Дальше пробовал бы подвязать это к фаствел, октагон…

[Jackson]

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

• чтобы было экономически обосновано
• чтобы было удобно и возможно применение в качестве типового решения
• чтобы было эффективно и удобно с точки зрения заказчика

А в нынешнее время предугадать мнения заказчиков у нас в России стало куда как проще чем 15 лет назад: заказчик с одной стороны привык к тому что он обычно пользует (значит принцип построения можно взять от имеющегося), а с другой стороны тот же опыт подсказывает ему то что хотелось бы улучшить. И упаси RND предлагать что-то ну совершенно целиком инновационное, потому как это напугает заказчика необходимостью переучиваться полностью.

[Владимир Николаевич]

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

[Владимир Николаевич]

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

[Владимир Николаевич]

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

[Jackson]

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

Так. Теперь уже я близок к точке кипения. Владимир Николаевич, ещё один рекламный пост и случится непоправимое.

[Михайло]

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

[VADR]

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

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

PS: Уже и я закипел :twisted:

[Marrenoloth]

Глубина, если не ошибаюсь, 600 мм? Это человек туда полностью войти может. Учитывая, что там ~220В, это ещё и опасно

Идеальный шкаф для любовников жены! А Ремиконт пусть его медленно до хрустящей корочки со всех сторон прожаривает! :twisted:

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

[Михайло]

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

Что правда так плохо все в МЭИ? У нас в УГТУ-УПИ тоже не все гладко... Но это уже в прошлом, на производстве я уже получил информации в 3 раза больше (мне 29 лет).

[green_3mii]

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

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

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

[Marrenoloth]

Что правда так плохо все в МЭИ? У нас в УГТУ-УПИ тоже не все гладко... Но это уже в прошлом, на производстве я уже получил информации в 3 раза больше (мне 29 лет).

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