Мой путь в пром. автоматизацию. Инженер-программист АСУТП
Итак, не так давно был пост Замкнутый круг - Siemens вокруг! не думал, что оставленный мною комментарий приведет к появлению у меня подписчиков и интересу к вопросу как стать программистом АСУТП.
Опишу вкратце саму специальность, обязанности и как я к этому пришел. Будет много текста.
Что делает любой программист? Правильно - программирует. И на этом можно было бы окончить описание, но не все так просто. Начнем.
АСУТП - автоматизированные системы управления технологическим процессом. Из расшифровки аббревиатуры уже можно понять, что задача инженера по автоматизации - создание программного продукта, который упрощает жизнь в первую очередь оператору механизма, который нужно автоматизировать (чаще происходит наоборот, так как не все хотят учить новое и упираются нововведениям всеми силами).
Обязанности могут быть самые разнообразные. В небольших компаниях инженер-программист может проектировать электрические схемы для автоматизируемого устройства, а затем и писать программу. В более крупных компания только программирование. Работал в компании где было 10 человек, не считая монтажников и в компании, где было свыше 200 сотрудников. Всегда будут командировки - вы будете участвовать в пуско-наладочных работах. Это если из основного. Не удивляйтесь и ситуации когда программист будет с отверткой что-то ковырять в щите управления чем-либо, отсюда следует, что вы обязаны уметь читать и при необходимости изменять электрические схемы, знать технику безопасности и ПУЭ ваша настольная книга. Иногда меня хотели заставить что-то изменить в силовой части подключения, но я этого не делал как бы косо на меня не смотрели электрики/монтажники. А вот объясню почему, на всех фирмах, где я работал у меня не было допуска по электробезопасности, а отсюда следует, что я вообще не должен лезть туда, где есть напряжение. Так что нет допуска - нет и каких-либо изменений схемах шкафа управления.
Часто бывает, что изначальная схема и то, что собрано по факту на объекте отличается. Причины могут быть разные - экономия (купили дешевле оборудование, решили поставить, что на складе нашлось, кто-то откат получил и т.д.). Задача программиста, который приехал на пуско-наладку подружить это все и заставить работать. Иногда это бывает очень непросто. Но про это будет позже, сначала необходима программа, а потом уже запуск объекта.
В общем выполнение работ по автоматизации проходит следующие стадии (упрощенно, на самом деле все немного сложнее):
1. Если участвуют несколько отделов в реализации проекта, то, когда приходит запрос из отдела продаж, каждый отдел предоставляет часы, которые потратит специалист на реализацию своей части. Далее это все суммируется и возвращается в отдел продаж. Они офигевают и ообычно на этом этапе уменьшаются часы, заложенные различными заинтересованными отделами, ибо дорого, и нужно продать. Ненавижу за это "продажников", хотя и понимаю, что это бизнес. Чтобы было понятно, в компании, где было больше 200 сотрудников были: департамент проектирования, департамент разработки ПО, департамент пуско-наладочных работ. И каждое подразделения выдавало кол-во часов на этот проект, необходимое для выполнения их части работ. И как итог выиграли тендер (если повезло, не будем говорить про остальные схемы).
2. На этом этапе обычно пишется ТЗ (технологическое задание) программистом на автоматизацию, хотя должно быть наоборот, заказчик должен предоставить описание того, что он хочет получить. Но у меня было так, как описываю. Дальше это ТЗ долго и нудно согласовывается с заказчиком, вносятся правки, ставятся подписи. Хотя это совсем не гарантия того, что ТЗ останется неизменным. Правки могут прийти, когда до начала пуско-наладочных осталось совсем немного времени, но почти всегда фирма-исполнитель прогибается под заказчика и программист потом в панике вносит изменения, что приводит к тому, что ПО будет не протестировано до конца, что приводит к задержкам при вводе в эксплуатацию и т.д. Но никого это обычно не волнует, хоть спи на объекте, но оно должно работать.
3. Когда есть ТЗ начинается, собственно, и реализация/придумывание того, как же оно все должно работать. Помимо программы для контроллера (ПЛК - программируемый логический контроллер) иногда нужно сделать и визуализацию. Для визуализации, в зависимости от поставленных целей применяется SCADA или HMI. В чем отличия отлично гуглится (статья и так уже огромная, сам не ожидал).
4. Тестирование программы на стенде или в симуляторах. Отлично работающая программа в симуляторе не равно иногда даже работающей на «живом объекте».
5. И самый интересный момент — это пуско-наладка (ПН). Об этом напишу подробнее.
Итак, что должен делать инженер во время ПН. Для удобства разделю на этапы.
1. I/O check проверка правильности подключения всех входов/выходов ПЛК (программируемый логический контроллер). И если что-то неправильно – то исправление. На данном этапе никакого ручного управления, не говоря уже про автоматизацию нет. Просто в контроллере можно жестко активировать выход и посмотреть, тот ли механизм включился. С входами проще, бегаешь вокруг механизма и тыкаешь кнопки, замыкаешь вручную концевые выключатели и смотришь, соответствует ли это тому, что ты заложил в программу. Для тех, кто не в теме, каждый контроллер имеет входа и выхода. Входа используются для сбора данных с механизма (всякого рода датчики, кнопки и т.д.). Выхода же нужны для управления устройством, например включить двигатель, закрыть задвижку и т.д. Это если очень упрощенно и не вдаваясь в подробности.
2. Если предыдущий этап закончился успешно и все собрано правильно (на более-менее больших объектах с первого раза никогда все правильно собрано не будет) – то приступаем к проверке в ручном режиме. Для этого либо со SCADA либо HMI включаем/выключаем узел агрегата и смотрим все ли правильно работает и все ли правильно отображается. Часто бывают ошибки (если используется визуализация) в привязках переменных к объекту на визуализации. Например, запустили один механизм, а на панели/скаде отображается, что включился другой, хотя работает правильный ну и т.д. Эти ошибки сразу же исправляются и процесс проверки продолжается.
3. Когда закончили ручное тестирование – переходим к самому сложному и интересному (вот тут симулятор, если тестировалась программа на нем, и дает прикурить иногда). Автоматический режим. Ну с ним все ясно, перевели все механизмы в автомат и запустили объект.
С этим режимом всегда могут быть проблемы. И когда вы пишете программу нужно учитывать максимально возможные варианты. Например, на двигателе перестал работать датчик температуры и из-за этого запускать этот узел в автоматическом режиме нельзя (ведь датчик не просто так там установлен), но если этот узел нельзя запустить в автомате, то и остальные по идее тоже нельзя, так как в автоматическом режиме реализовываются блокировки, которые отключат механизм при неисправности. Неисправность одного узла не дает запустить другой от него зависящий ну и т.д. И теперь нужно ждать пока починят неисправность, а производство в это время стоит. И владелец кричит какие в обще все, хм, хорошие люди. Но обычно так не делается. Почти всегда есть возможность запустить все в автомате, даже если какой-то из узлов агрегата не может работать в автомате. Часто дается возможность отключить контроль какого-то сигнала, например, тот же датчик. Активируем эту функцию и все у нас работает в автомате, так как сигнал от датчика не учитывается и в дальнейшем это может привести к проблемам, но это уже ответственность заказчика. Все эти режимы описываются в инструкции и с большими предупреждающими знаками. При использовании систем визуализации часто делают так называемый лог событий сюда входят аварии (это всегда делается) и действия оператора (имя оператора, что нажал, какой режим выбрал, что изменил и т.д.). И если возникает поломка механизма по вине заказчика, так как отключили какой-то элемент контроля – то это уже не гарантийный случай и фирма, что делала автоматизацию не попала на деньги. Так как любой гарантийный ремонт делается за счет изготовителя, а в этом случае они сами виноваты.
На этом пока хочу закончить. И так уже вышел далеко за рамки того объема, который хотел написать. Возможно получилось как-то не слишком структурировано, но я старался))) Будет кому-то интересно возможно продолжу еще что-то по теме автоматизации писать.
