Что нужно знать инженеру АСУТП

[Ivan3]

Народ, всем здрасьте)

Хочу поинтересоваться у опытных АСУТП-шников, какие навыки и знания необходимы в сфере их деятельности.

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

Итак, что нужно знать и как выглядит работа инженера АСУТП(программиста)?


В моих представлениях нужны знания:
-Языки высого уровня(с/с++/с#), возможно скриптовые языки, ассемблер, языки МЭК61131.3
-Представления о работе ПЛК Siemens, Atmel, STM
-Электроника, схемотехника, электротехника
-Помимо Windows/Unix, операционные системы реального времени(аля VxWorks или QNX)
-Сети(TCP/IP)
-Проектирование(AutoCAD)

А сама работа в двух словах представляется так. Участие в разработке и реализации ТЗ(проектирование, программирование, документирование), выезд на объект и проведение пуско-наладочных работ(отладка и т.п).

Прошу меня поправить.

[Бондарев Михаил]

-да
-да
-нет
-да
#webTrollMode_OFF#

[Ryzhij]

-да
-да
-нет
-да
#webTrollMode_OFF#

+ Знания в области ТАУ (САР, САУ)
И таки да, автокад (и прочие) это ИМХО инструмент документирования, а понятие "проектирование" несколько шире и глубже ;)

[Ivan3]

Да, точно... про ТАУ забыл. Спс.

А так просто собрался профиль немного изменить. Работаю прогером. Хочу переметнуться в АСУТП. Тем более в универе схожая специальность была - АСОИУ.

[agent_serg]

А так просто собрался профиль немного изменить. Работаю прогером. Хочу переметнуться в АСУТП.

Программист - это далеко не инженер АСУТП.
Мыслить прийдётся по-другому. Техпроцессы не в теории, а практически (в железе) надо будет знать лучше авторов этих техпроцессов.
Ошибка инженера АСУТП может стоить кому-то здоровья. Надо всегда помнить об этом.
Но, главное - есть стремление.

[Ivan3]

А так просто собрался профиль немного изменить. Работаю прогером. Хочу переметнуться в АСУТП.

Программист - это далеко не инженер АСУТП.
Мыслить прийдётся по-другому. Техпроцессы не в теории, а практически (в железе) надо будет знать лучше авторов этих техпроцессов.
Ошибка инженера АСУТП может стоить кому-то здоровья. Надо всегда помнить об этом.
Но, главное - есть стремление.

Спасиб. Ну что ж делать - будемс потихоньку изучать и пробовать)

[Exactamente]

Добавлю/поправлю:

- не, сначала всё же МЭК 61131 (ну, LD и ST), потом VB, потом уже C/C++/C#/Java - встроенные скриптовые постигаются за полдня, если есть понимание какого-либо из С-ей;
- принципы работы циклических рил-тайм алгоритмов;
- принципы обработки входных-выходных сигналов;
- протоколы связи, интерфейсы (обжать DB9 под 232, 485, например) и OPC;
- знание чего-то из популярнейшего железа: ПЛК и HMI;
- SCADA, какая именно - зависит от решаемых масштабов; от себя предложу при проектировании мнемосхем и прочего придерживаться здравого смысла, почитать литературу на тему проектирования UI и UX - на сегодняшний день это на 99% по разработке под мобильные платформы и веб, но отличное формирует общее понимание; ещё, ИМХО, знание граф. редакторов необходимо, потому что стандартное говнецо из библиотек панелей и скад - это фу;
- и БД этих скад, преимущественно SQL, Access может ещё, MySQL, Oracle;
- настройка АРМов и серверов - от сетей до настройки ОС, прав, доменов; над никсами можно не заморачиваться, только QNX, про остальные в АСУТП слышал только один раз;
- средства резервного, создания бекапов;
- иногда веб;
- иногда excel для отчётов;
- ТАУ;
- технология;

[Ivan3]

Спасибо, за развернутый ответ)

[Exactamente]

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

С другой стороны, это чистый восторг - работаешь не над супер-стартапами а-ля стотыщным мобильным приложением для фотографирования котиков или не над очередной офисной прогой для бухучёта) РВСы с сотнями миллионов рублей внутри, или электростанции, обеспечивающие целые районы, или ещё что-нибудь интересное. ЧСВ таки поддерживается на уровне, да))

[Степа]

Забыто самое главное: базовые знания - математика, физика, химия. Без этого весь этот мощный список мало что значит. Люди "на земле", бывает, очень неплохо разбираются, но из каких-то своих соображений не идут в начальники проектировщиков, а работают слесарями, токарями и т.п. Такой разок заметит, что программист "плавает" в некоторых вопросах, обязательно найдет повод его выставить на посмешище и доверять уже точно не будет. Ну как доверять инженеру-математику, если он думает, что в угловом градусе 100 угловых минут? "С математикой сталкивался десять лет назад" - не оправдание.
Да и не получится толковый программист без знания той же математики. Копипастер - получится.

Еще надо уметь выступать: частенько придется общаться с людьми, далекими от программирования, автоматизации... Но от них зависит, какое решение принимать. Блеющий докладчик, в речи которого полно жаргона и специальных терминов, провалит даже очень блестящую идею. Гладко говорящий с простой ясной речью способен "пробить" даже откровенную хренотень /для примера: мошенники не заикаются, они гладко и уверенно презентуют свою идею, что вызывает доверие у некоторых/.
Разбираться, кому что можно говорить, а о чем лучше умолчать. Скажем, при рассказе о сотовых телефонах возможным покупателям не стоит говорить, что у некой категории граждан появляется возможность следить за владельцем сотового телефона: перемещения, круг общения.
Грамотно строить презентацию своего продукта. Как пример: реклама датчиков ОВЕН ПД100:

Высокая помехоустойчивость. Соответствуют требованиям к оборудованию класса А по устойчивости к воздействию электромагнитных помех по ГОСТ Р 51522-99

Сколько народу возьмет на себя труд найти указанный ГОСТ, прочитать его и понять, что ни о какой высокой помехоустойчивости речи и быть не может? Это просто хороший и вполне обычный датчик для нормальных условий эксплуатации.

[Exactamente]

Вот в каждой такой теме появится кто-нибудь и заведёт абстракцию про грамотную речь, что инженер должен цитировать "Евгения Онегина" и уметь поддержать разговор об античных скульпторах, обладать сияющуим умом и быть примером для дошкольников. Мило, но не практично) Совершенно не должен ни инженер, ни программист, ни инженер-программист уметь презентовать товар. Для этого должны быть специальные люди, которые умеют гладко 3,14здеть, благо, в нашем государстве таких хватает. Что само собой не отменяет факта - блеющим и заикающимся идиотом инженер-программист тоже быть не должен.

[Степа]

Вот в каждой такой теме появится кто-нибудь и заведёт абстракцию про грамотную речь, что инженер должен цитировать "Евгения Онегина" и уметь поддержать разговор об античных скульпторах, обладать сияющуим умом и быть примером для дошкольников. Мило, но не практично) Совершенно не должен ни инженер, ни программист, ни инженер-программист уметь презентовать товар. Для этого должны быть специальные люди, которые умеют гладко 3,14здеть, благо, в нашем государстве таких хватает. Что само собой не отменяет факта - блеющим и заикающимся идиотом инженер-программист тоже быть не должен.

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

[Exactamente]

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

[MuadDib]

-Представления о работе ПЛК Siemens, Atmel, STM

Atmel и STM выпускают ПЛК?

ИМХО, при желании сменить профиль работы необходимо для начала разобраться, с каким оборудованием предстоит иметь дело. И определиться, чем вы хотите заниматься - "верхом" или "низом".

"Низ" - это ПЛК от Siemens, Mitsubishi, Schneider, Allen Bradley, Omron, многочисленные "китайцы" - Delta, ICP DAS, Advantech, представители отечественных пород - Овен, Ремиконт. Я назвал только самые известные марки, есть множество других. Кроме того, отдельные упертые конторы продолжают использовать для типичных ПЛК-задач промышленные ПК с операционной системой (например, с MS DOS) и с рантаймом какой-либо Softlogic-системы. В частности, это подход Трейс Моуда, системы весьма популярной на просторах необъятной (особенно среди мелких контор). Программируются ПЛК... по-разному, но самым важным скиллом является знание МЭК-языков. Абсолютное большинство сред разработки в своем развитии пляшет именно от МЭК, но разница со стандартом бывает очень существенная (*cough* Siemens *cough*).

"Верх" - это SCADA-системы типа WinCC, InTouch, Genesis, Indusoft Web Studio - тысячи их. Из отечественных - тот же Трейс Моуд, Мастер Скада и еще несколько брэндов.

Есть еще операторские панели, эдакий встраиваемый вариант машины с простой SCADA-системой.

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

Опять же ИМХО, программисту, ищущему свою дорогу в АСУТП, лучше всего присмотреться к "верхам". Если у вас есть контора на примете, узнайте, какие SCADA они применяют, раздобудьте демо-версию и поизучайте на досуге.

Если же хочется поработать именно с контроллерами, то, как уже сказали коллеги, придется быть готовым к погружению с головой в технологический процесс (всплытие опционально :D ). Также следует иметь в виду, что программирование ПЛК идет рука об руку с составлением электрических схем системы автоматизации. Программировать будете в обнимку с кипой схем (принципиалка на 500+ листов А4 конкретно в моей работе вполне обычна, но у всех по-разному), эти схемы нужно очень хорошо понимать и, зачастую, уметь быстро дополнять и править.

И да, в уважающей себя и своих работников конторе, "верхом" и "низом" занимаются разные люди. В общем случае, сами понимаете, бывает по-всякому.

[Ivan3]

Вообще, хотелось бы заниматься "низом". Думал даже на курсы Siemens отправиться, но ценник просто беспощаден.

Короче, пока буду повторять теорию и изучать SCADЫ и потихоньку "низы".

После НГ попробую устроиться куда-нибудь.

[alex_ugrumov]

Вообще, хотелось бы заниматься "низом". Думал даже на курсы Siemens отправиться, но ценник просто беспощаден.

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

[Ivan3]

Вообще, хотелось бы заниматься "низом". Думал даже на курсы Siemens отправиться, но ценник просто беспощаден.

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

Да это понятно) Меня просто зацепило, что там реальная практика(по крайней мере по их заявлениям).

[rwg]

Вот в каждой такой теме появится кто-нибудь и заведёт абстракцию про грамотную речь, что инженер должен цитировать "Евгения Онегина" и уметь поддержать разговор об античных скульпторах, обладать сияющуим умом и быть примером для дошкольников. Мило, но не практично) Совершенно не должен ни инженер, ни программист, ни инженер-программист уметь презентовать товар. Для этого должны быть специальные люди, которые умеют гладко 3,14здеть, благо, в нашем государстве таких хватает. Что само собой не отменяет факта - блеющим и заикающимся идиотом инженер-программист тоже быть не должен.

У нас в стране возникла путаница, связанная с должностью инженера. Были инженеры по уборке территории, по технике безопасности и т.п. Тот программист, который на самом деле кодировщик, инженером не является. Это техник. Инженер занимается постановкой задачи на программирование. Инженер - это тот, кто принимает проектные решения и следит за их исполнением и доведением до ума. Это ГИП, инженер-наладчик и подобные. Для этого они на стадиях составления технического задания, монтажа и наладки должны быть в постоянном контакте с заказчиком. Без умения слушать, думать и говорить настоящему инженеру не справиться. А вот технику, которого официально называют инженером, но который не решил ни одной инженерной задачи, можно спокойно 3,14 только в курительном углу.

[alex_ugrumov]

Да это понятно) Меня просто зацепило, что там реальная практика(по крайней мере по их заявлениям).

Реальная практика - это, то что вам покажут живут контроллер и дадут залить в него программу. Да и пожалуй всё. Вам не расскажут о реальных задачах, и способах их решений (кстати во многом потому, что технические специалисты вендоров обычно хорошо разбираются в своей техники и редко имеют большой опыт внедрений, или он был очень давно и забылся). А у вас не будет вопросов активных, кроме разве что: а как мне зажечь выход 5-ю разными способами? Это представьте, вы пошли на недельный курсы, по, например, С, а потом вас сразу взяли в Яндекс на поисковую оптимизацию? Или для этого неплохо бы закончить физ-мат школу и скажем матмех/мехмат? А запускать компилятор походу научится. Курсы это хорошо для систематизации знаний и качественного улучшения, когда у вас уже есть реальный опыт и накопились вопросы. Сейчас вам вполне хватит эмулятора. По тем же SCADA есть видеоуроки, с ними можно вообще долго развлекаться.

[alex_ugrumov]

У нас в стране возникла путаница, связанная с должностью инженера. Были инженеры по уборке территории, по технике безопасности и т.п. Тот программист, который на самом деле кодировщик, инженером не является. Это техник.

+1

[Степа]

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

Хорошо, простые примеры.
1. Идет сдача установки заказчику. Рассказывать устройство установки обслуживающему персоналу заказчика должен делать её непосредственный разработчик. Во всяком случае мы так делаем, чехи так делали, итальянцы, немцы... Если программист /или любой другой, участвующий в обучении/ мекает-бекает-кашу жует - слушать его никто не будет. И подпись в графе "обучение проведено" никто ставить не будет /особенно если приемщики не дураки/ - работа коллектива пошла насмарку.
2. Прочтено ТЗ, у программиста /как и у любого другого, участвующего в разработке/ есть некое решение по архитектуре. Мекающего-бекающего просто не будут слушать. Или выслушают и отмахнутся от предложенного как от недостаточно понятного - у каждого же есть свое решение. В лучшем случае идею просто украдут. Украдут те, кто говорить умеет. И все плюшки в случае успеха получат тоже они.
3. На презентации к будущему заказчику, для работы на выставочных стендах грамотные люди берут с собой хотя бы одного технического специалиста: отвечать на возможные сложные технические вопросы. В основном там работают как раз специалисты по связям, но на сложные вопросы отвечать приглашают именно технических специалистов. Вот здорово-то будет - длинноногая девочка выложилась, привлекла возможного клиента, а тут пришел жующий кашу инженер и заинтересованный просто развернулся и ушел. Ушел не куда-нибудь, к конкуренту напротив...
Ни в одном из перечисленных случаев /список далеко не полный, это просто то, что сходу в голову пришло/ работать с людьми должен будет непосредственно сам инженер, а не какой-то там персонал отдела по работе с клиентами....

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

[spasup]

Проработав 6 лет на производстве "ручками" поднялся выше и задался именно вопросом обсуждаемой темы...
Инженер по АСУ ТП должен знать если не всё, то многое. Должность ОЧЕНЬ ёмкая. Если с кондуктором или продавцом всё понятно, то c инженером по автоматизации нет. Перечислить всё по пунктам не реально, так как все равно чего-то не хватит и придётся дополнять. Скажу кратко:
1. Инженер по АСУТП должен знать, как развиваться дальше!

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

[Valerich]

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

[Михайло]

Лучшие специалисты выходят из тех, кто любит учиться. Если соединить это суждение с

лучшие АСУшники выходят из технологов.

то получается софизм:
Технологи любят учиться.

:D

[Exactamente]

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

Хорошо, простые примеры.
1. Идет сдача установки заказчику. Рассказывать устройство установки обслуживающему персоналу заказчика должен делать её непосредственный разработчик. Во всяком случае мы так делаем, чехи так делали, итальянцы, немцы... Если программист /или любой другой, участвующий в обучении/ мекает-бекает-кашу жует - слушать его никто не будет. И подпись в графе "обучение проведено" никто ставить не будет /особенно если приемщики не дураки/ - работа коллектива пошла насмарку.
2. Прочтено ТЗ, у программиста /как и у любого другого, участвующего в разработке/ есть некое решение по архитектуре. Мекающего-бекающего просто не будут слушать. Или выслушают и отмахнутся от предложенного как от недостаточно понятного - у каждого же есть свое решение. В лучшем случае идею просто украдут. Украдут те, кто говорить умеет. И все плюшки в случае успеха получат тоже они.
3. На презентации к будущему заказчику, для работы на выставочных стендах грамотные люди берут с собой хотя бы одного технического специалиста: отвечать на возможные сложные технические вопросы. В основном там работают как раз специалисты по связям, но на сложные вопросы отвечать приглашают именно технических специалистов. Вот здорово-то будет - длинноногая девочка выложилась, привлекла возможного клиента, а тут пришел жующий кашу инженер и заинтересованный просто развернулся и ушел. Ушел не куда-нибудь, к конкуренту напротив...
Ни в одном из перечисленных случаев /список далеко не полный, это просто то, что сходу в голову пришло/ работать с людьми должен будет непосредственно сам инженер, а не какой-то там персонал отдела по работе с клиентами....

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

То, а чём вы говорите, это элементарные навыки формального общения. Любому человеку следует ими обладать. Так же как многими другими навыками: уметь писать (разумеется, с соблюдением всех правил языка), читать, зашнуровывать ботинки, застёгивать ширинку и много чего ещё.
Но презентовать товар - должны отдельные люди. Провести обучение - это не презентовать товар. ПО должно вообще быть таким (и с таким руководством пользователя), чтоб стоять рядом с на глазах самообучающимся оператором и молча кивать :) Вот тогда можно называться Инженером, кмк.

UPD
Нет, давайте даже по пунктам.
1. Если человек не может рассказать что-либо из воей профобласти настолько понятым языком, чтоб его понял сколько угодно далёкий от этого слушатель - он нихрена не понимает в своей области. Перефразировано сами знаете откуда. Или второй вариант. Есть люди, которым трудно даётся монолог на широкую малознакомую аудиторию. Они сами себе в себе, и там в голове решают сложнейшие задачи. Если вам инженер круто решил поставленную задачу - вы его прогоните, потому что он не умеет рассказывать мартышкам в каком порядке на кнопки нажимать? А умные из обслуживающего персонала в проекте даже сами разберутся, если проект хорошо сделан.
2. Вам шашечки или ехать? Нет среди людей равноправия, это миф, и это самое мнение, которое есть у каждого, не одинаково ценно. И если человек не раз показывал, что он знает своё дело, то пусть он хоть слюни себе на подбородок пускает, его выслушают.
3. Эти люди не грамотные, если отправили на выставку человека, у которого язык не подвешен. Или второй вариант: если не удосужились отправить такого вот "выставочного" технического специалиста (которому что ль работы нет по профилю, кроме как лицом торговать?) на банальные курсы по риторике, публичным выступлениям и т.п.


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


---

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