Разработка для заводов. Как это было

Эта статья — ответ на ранее опубликованную статью про IT на заводах. Я почитал и понял, что мне есть что об этом рассказать. Вопросы оттуда же и немного больше. Сразу уточню, что я не работал непосредственно на заводах, а работал в компании, которая предоставляла услуги по автоматизации производственных линий разным предприятиям, но в основном ориентированные на работу с весами и дозированием.

Что привело в промышленность?

Это была моя самая первая работа программистом после самой первой работы — крупье в казино. В далёком октябре 2008-го я пришёл на собеседование с полным отсутствием знаний SQL, очень базовым знанием Delphi и некоторыми знаниями, которые успел получить до этого в школе и универе (основы Basic, Prolog, List, C++). Так себе кандидат, но никто не горел желанием идти туда работать. Мне так и сказали: «Ты только приходи. Мы тебя всему научим.» И я пришёл.

Началось всё с автоматизации первого бетонного завода, которая должна быть готова через пару месяцев, к Новому году. Первым делом я взялся переписывать то, что было сделано предыдущим программистом и разбираться, что за зверь такой — RS-232 и протокол ModbusRTU, который я должен буду использовать для управления некими МДВВ и Мастером.

Первый блин был не комом, но подгорел немного. Но видеть, как оживает сначала одна железка, лежащая у тебя на столе, а потом целая линия на заводе — сравнимо разве что с первым сексом. Итог: приходит оператор на работу, включает всё железо, обогреватель в своей коморке и тепловую пушку в помещении с дозаторами,, садится за комп, запускает программу, выбирает нужный рецепт бетона, задаёт массу и жмёт на «Пуск». Сказка на этом заканчивается и начинается реальность. Щебень застыл на морозе и ещё не отогрелся. Оператор берёт кувалду и начинает бить по дозатору. Через несколько секунд щебень пошёл. Оператор возвращается и продолжает следить за процессом. И это лишь первая из десятков всевозможных проблем и затыков в производстве. И никакие сложности не должны мешать работать программе и железу (шкафу электроники и с управляющими реле).

Интересные задачи

Каждый раз было что‑то интересное. Самый запомнившийся проектом был, пожалуй, проект на создание экспериментального «аналога» американской установки по разделению материала на грязный (превышающий определённый радиоактивный фон) и чистый. Началось с того, что можно было сделать всё существенно проще и дешевле, но хотели «как у них». Когда установка была готова, её увезли, но вскоре (через несколько месяцев простоя где‑то на складе, когда при заказе она нужна была «вчера», как обычно) оказалось, что уже что‑то не работает. Так у меня случилась командировка на закрытое предприятие в закрытом городе. т. е. мало просто попасть в город, минуя посты, так ещё и предприятие охраняется как будто там суперсолдат выращивают. Пропускная похлеще, чем в аэропорту. И в складском помещении в 20 метрах от здания, на двери которого знак радиоактивной опасности, стояла наша установочка, которую мы благополучно оживили. Почему же она стояла без дела? Ждали главное действующее лицо — экспериментальный датчик из‑под Москвы, из другого научного центра. На выходе из предприятия я лишился ноутбука, т.к. он оказался оформлен недолжным образом, а выносить что попало оттуда нельзя. Как водится, всё было решено к утру.

Спустя ещё несколько месяцев установка‑таки оказалась там, где должна быть (наверно). И теперь предстояла уже её настройка с тем самым датчиком (своего рода особый счётчик Гейгера), который ещё и передавать информацию может. Так меня вызвали второй раз и я впервые оказался в Питере. Проездом. В Сосновый Бор. На другое закрытое предприятие. При входе ознакомили с инструкцией на случай радиоактивного заражения, одели в халат и дали специальное оборудование собой, а ещё талончик на обед. Пройдя через проходную и долго почти через всю территорию в самом последнем складском помещении с надписью 0,7 мкЗв на стене (если правильно помню. Хотя могло быть и 7). От входа в прямой видимости за деревьями где‑то в паре километров были видны градирни ЛАЭС.Половина помещения было заставлено ящиками, к которым не было большого желания подходить, а в середине свободного пространства была наша установочка. Так себе идея — пытаться настроить тонкое оборудование в помещении, в котором в десяти метрах от нас фон превышает тот, который считается «чистым» для материала. Тем не менее, у нас были оба образца и мы плодотворно поработали.

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

Сложно ли быть руководителем в ИТ?

Я бы не мог ответить на этот вопрос, если бы однажды мой начальник не сказал: «Я устал, я ухожу.» Он начал компанию, когда я ещё пешком под столом ходил. Через год он сказал, что теперь точно уходит, но за этот год что‑то поменялось у меня в голове и я предложил ему просто переоформить фирму на меня. Так и сделали. Коротко: это был полезный опыт.

Если подробнее, то я был к этому максимально не готов. Я понял, что ненавижу бухгалтерские процессы. Один день в месяц из‑за этого я не любил свою работу. Разрабатывать ПО — как это просто! Быть директором без опыта и знаний для этого — это очень трудно! Но интересно! Надо искать клиентов, встречаться с ними (зачастую в других городах), договариваться, считать стоимость, обсуждать ТЗ, составлять договор, делегировать задачи, договариваться с подрядчиками, собирать оборудование, писать ПО (я продолжал этим заниматься, тем более, что на тот момент процессы уже были отлажены), устанавливать оборудование, приезжать по запросу «у нас ничего не работает» и объяснять, как не надо и как надо делать, приезжать снова, подписывать акт выполненных работ, получать деньги, приезжать снова, но уже за деньги, допиливать функциональность по запросу и т. д.

Мой офис был дома, два других сотрудника работали по факту наличия работы (занимаясь в свободное время своими делами). На дворе был 2013-й год. У нас была удалёнка ещё за много лет до того, как это стало мейнстримом.

Сложно договариваться с безопасностью?

Странный вопрос. Договориться можно о чём угодно. Даже о возврате ноута из закрытого предприятия. А главные вопросы безопасности в нашем случае — это безопасность труда. Это не работа с табличками в офисе. Тут железо работает, которое легко может лишить конечности или даже жизни. Поэтому все возможные ситуации должны быть предусмотрены. И кнопка экстренной остановки в программе, и кнопка стопа в релейном шкафе, и отдельные средства защиты на этапе производства/монтажа оборудования (тросик экстренной остановки вдоль конвейера, датчик открытия крышки бетонного смесителя и т. д.). Так что защите здоровья с нашей стороны уделялось особое внимание.

Касательно безопасности ещё стоит упомянуть юридическую. Перед тем, как начать делать аналог американской установки, нам прислали договор, который стоило очень внимательно прочитать. По нему получалось, что при любом чихе мы должны были нести всевозможные издержки, а заказчик — ничего. По договору получалось так, что мы должны были начать делать за свой счёт, потом заказчик мог передумать и просто расторгнуть договор. В итоге мы бы остались без денег с никому не нужным железом. Три месяца я общался с их юристами, объясняя, почему мне это не нравится. В итоге наша взяла. Был подписан наш стандартный договор с добавлением одного абзаца из их договора. Заказчики были адекватными, но даже если вы им всецело доверяете, в договоре нужно исключить всевозможные моменты, где вы можете просто остаться без денег.

Импортозамещение как-то влияло на твою работу?

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

Но в одной из последних работ поступил заказ на подсчёт количества наполненных пакетов для наполнителей кошачьих туалетов. (Тогда я узнал, что некоторые иностранные наполнители от российских отличаются лишь упаковкой.) Было три контроллера (на двух из которых работали)., из которых надо было собирать информацию о количестве отдозированного материала. И я понял, что это прекрасная возможность использовать Raspberry Pi! В магазине была куплена китайская пластиковая коробочка, заказан китайский блок питания, умещающийся в неё, использован китайский переходник USB/RS-485 с «Алишки» (российский был сделан по спецификации и потому были проблемы со стартом на Линуксе, а китайский просто всегда работал). Также был куплен светодиод и на 3D‑принтере распечатано крепление на дин‑рейку для «малинки» (фото ниже). В итоге программа на Go при запуске начинала мигать светодиодом, информируя о том, что работает, и, постоянно опрашивая контроллеры, в нужный момент сохраняла полученную информацию. А потом уже специально обученный сотрудник в программе на Delphi печатал отчёты за смену.

А стек разработки в промышленном IT-кластере отличается от стека классических IT компаний?

Смотря какая промышленность. У нас было всё очень просто. Программа на Delphi, БД Firebird, отчёты на MS Excel, OOo Calc (предок Libre Office) или Fast Reports. Одна разработка была на Go, как написал выше.

Не все программы нужно или могут быть написаны как обычное приложение. Несколько программ было написано для программируемых контроллеров с использованием CoDeSys. Там внутри 5 языков, которые можно комбинировать. Мне всегда хватало трёх из них: блок‑схемный (FBD), паскалеподобный (ST) и ассемблероподобный (IL). Особенность разработки для контроллеров в том, что написанный код будет выполняться в бесконечном цикле и нужно писать его, учитывая эту особенность.

В целом, на предприятии можно использовать что угодно, в зависимости от задач.

Как насчёт тусовок IT-шников для заводов?

Странный вопрос, но какой есть. IT‑шники, работающие для предприятий, ничем не отличаются от остальных и также посещают разные мероприятия. Просто у нас есть ещё и куча интересных промышленных выставок, где можно что‑то новое и интересное найти. Например, гибкий шнек для подачи цемента. Никогда не использовали, но звучит интригующе…

И пара слов о разработке

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

Работа с оборудованием. Только синхронная и бесконечная. У меня обычно было три очереди команд: на работу с весовыми контроллерами, на работу с управляющими контроллерами и ошибки. Всё это отображалось на главной форме приложения (мнемосхеме). Отдельный поток постоянно проверял очереди, постоянно подкидывая команд на чтение, когда очередь команд заканчивалась. Команды на запись имели более высокий приоритет и добавлялись в начало. Отдельный таймер на форме постоянно читал полученные данные из устройств и отображал на мнемосхеме в виде анимации, полос загрузки, чисел и т. д. Анимацией мы показывали состояние оборудование (открыто/закрыто или включено/выключено), в случае несоответствия ожидаемого состояние с реальным рядом мигала черепушка красным цветом. Полосы загрузки показывали заполнение дозатора относительно заданного веса. и т. д.

При дозировании бетона можно двигаться шаг за шагом, а можно сделать по‑умному. Если смеситель у нас на 0,5 кубов, а нужно 1,2, то мы дозируем три раза по 0,4. т. е. каждый дозатор и смеситель должны отработать по 3 раза. Таким образом, когда отрабатывает дозатор и материал сбрасывается в смеситель, он не ждёт следующего цикла, а сразу же начинает свой, если этот не последний. Но они не могут сбрасывать, пока не отработает предыдущий цикл в смесителе. Тут была довольно занимательная работа с потоками, отдельным для каждого дозатора, системы сброса и смесителя.

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

Результаты дозирования сохраняются в базу, чтобы потом использовать для разного рода отчётов. В т..ч. при ручном дозировании, чтобы не было возможности что‑то отгрузить налево. В этом, как правило, и состоит задача автоматизации в России. Лишь в одном случае делали ускоренный переход с ручного дозирования на автоматику, т.к. завод получил заказ на поставку бетона для строительства моста и нужна определённая точность дозирования. Наша система, даже с учётом погрешностей датчиков, на новом оборудовании обычно укладывалась в 0,5%.

Заключение

Вот такая у меня была работа. Сложная, но невероятно интересная!

Ещё можно написать про другие командировки. Про отладку на заводе с 8 утра до полуночи, про ледяные, шумные, пыльные помещения. Про крики по рации: «Останавливай!» Про споры и маты. Про неработающие датчики, выходящее из строя оборудование, заваленный с горкой смеситель и т. д. Но это было действительно увлекательно и я рад, что получил такой интереснейший опыт.

С тех пор я ни раз думал о том, чтобы вернуться к разработке для предприятий (не только ПО, но и железа), но что‑то мне подсказывало (особенно в последние годы), что уже не стоит. Пусть этим занимаются другие. Хотя однажды нашим соседям предстоит восстанавливать целые города и им понадобится очень много бетона хорошего качества и любая помощь. Так что посмотрим…