Как стать автором
Обновить
63.57

Приходите к нам на завод, у нас тяжело

Время на прочтение10 мин
Количество просмотров139K
Короче, ИТ на заводе — это вам не романтика, особенно в нашем цифровом направлении.

Между «давайте этим займёмся» и «о, смотрите, какая гламурная ML-модель» лежит очень много того, про что не рассказывают. Сейчас расскажу.

Вначале у нас была банда энтузиастов из разных подразделений: несколько человек из ИТ, АСУТП, технологи со знанием статистики — чтобы смотреть с разных углов и видеть всё в целом, насколько это возможно. Начали с оценки перспектив. Они были необъятные — наше производство размером с небольшой город. Стали формироваться подразделения и направления: кто-то пошёл собирать роботов, кто-то в видеоаналитику, кто-то в лайтовый анализ данных, кто-то в самый хардкор — в дата-сатанизм. Работы у нас всегда больше, чем рук.

И на каждой из этих дорожек нас поджидали свои чудеса и сюрпризы.

Вот, к примеру, видеоаналитика:

  • Мы поняли, что ML в 50% задач не нужны. Нужна, например, камера, которая по цвету определяет, где есть железка, и смотрит её геометрию в реальности. Всё. Или другая камера, которая следит, чтобы в нужной зоне ничего не шевелилось.
  • Всё это прекрасно до первого солнечного зайчика. ML отлично показывают себя там, где вам лень строить крышу или ставить прожектор над конвейером.
  • У нас была идея, что мы можем сами в нейросети. Чуть не написали свой сервис для распознавания номеров вагонов. Казалось, делов-то на 20 минут, а у подрядчика это стоит 25 копеек за фото. Сделали свой, сферические вагоны в вакууме он определял хорошо. Потом приехало вот это:

image

А потом внезапно пошёл дождь. Знаете что? Вагоны под дождём становятся мокрыми. Это было неожиданно. Ещё они бывают после снега, битые, немытые, обновлённые криворукими малярами и ПРОЧИЕ. И в солнечных зайчиках тоже.

Мы накалывались на получении данных (кто сказал, что прошивка станка без костылей?), на роботизации, инфраструктуре, связи, на всём. Мы облазили весь завод, испачкались в солидоле, мазуте и масле. Но стали делать то, что должны, — оптимизировать мир.

Получение данных


Одна из первых вещей, которые нам были нужны, — это дата-сеты с оборудования. Ну знаете, телеметрия, параметры заказа, вот это всё.

В цеху данные используются, цех автоматизирован. Вот, например, есть очень хорошо цифровизированный стан-5000, всё очень чётко и данные классные, но усреднённые. То есть вместо лога там одно число: в среднем на единицу продукции, а хочется глубже, детальнее.

image

Все исходные данные тоже есть, они складываются в базу. Точнее, на самом деле там две базы.

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

Там то самое махровое легаси, которое никогда никого не отпустит. На заводе сменится поколение, все будут ездить на электромобилях, а эти базы так и будут работать вместе в паре, и никто их не разделит. Казалось бы, надо рефакторить, вот только у нас завод.

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

А работать-то надо! Ок, есть боевые базы, которые около АСУТП. Так вот, если туда запустить храброго пользователя с кривым SQL, а ещё хуже — подрядчика или студента, то не иллюзорен риск, что база превратится в тыкву. А вместе с ней остановится производство. И это не гипотеза.

Угадайте, кстати, как мы это узнали.

На что вообще похож завод с точки зрения ИТ


Есть большая система ERP, где крутятся закупки, планы производства и прочие числа. С ERP работают клиенты: закупки, CRM, здесь деньги, заказы, поставки и тому подобное.

ERP спускает конкретный запрос в MES, систему управления производством. MES дробит стратегию на конкретные задания для смен.

Если MES соединена с АСУТП, то это всё автоматизируется вплоть до правильного раскроя металла и прочих оптимизаций. Дальше первый уровень — контроллеры, исполнительные механизмы, датчики. Вокруг этого всего всякие автоматизации кадров, электронные журналы, закупки, прогнозы спроса и так далее.

А теперь про анализ технологии и как у нас дела с источниками:

  1. ERP нам совсем не подойдёт — там хорошо выверенные данные, но в очень крупной детализации (на заказ, например).
  2. В базах MES обычно детализируется до единицы продукции, но не всегда глубже. То есть там не всегда сохраняются все нужные данные. И ещё туда не подключишь мощные аналитические запросы. Базы начинают тормозить, а вместе с ними и производство в базах MES-уровня.
  3. Базы АСУТП самые лучшие, и данные там самые крутые, но к ним и подключиться сложно, и данные быстро удаляются. Потому что это боевые базы, к которым напрямую обращается производство, и если что-то пойдёт не так, любой баг будет стоить большие миллионы денег.

То есть первая задача для того, чтобы можно было работать с данными, — хоть куда-то их вытащить. Причём желательно не просто агрегаты типа «среднее отклонение за час», а прямо сырые данные телеметрии оборудования, увязанные с данными производственного задания и замеров того, что выходит из станков. То есть это сбор данных, соединение их в одно хранилище и какая-то обработка.

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

Хранилище технологических параметров для нужд техперсонала уже было. Его сделали технологи сами, без архитектора, и сделали хорошо. Оно продолжает работать успешно, но достигло своего потолка производительности. Позже туда пришёл архитектор, пришли мои коллеги, кое-что переделали, и оно круто ведёт себя под нормальным ИТ-контролем уже. Но там предел возможностей — традиционная база данных, Oracle с оптимизацией на небольшие участки, из которых можно собрать быстрые задания. Это не подходит для join'ов по всей базе, которыми так славятся дата-сатанисты.

Соответственно, мы понимаем, что надо что-то с этим делать, и стартуем процесс модернизации платформы технологических данных.

Как тащили


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

Но жизнь — боль, поэтому кое-что пошло не по плану.

Для начала в феврале 2022 года, когда мы уже нашли подходящее железо, внезапно стало нужно искать другое. Кстати, с софтом мы оказались сразу очень продуманными: вендорский иностранный не рассматривался в принципе в первых приоритетах, только опенсорс или отечественный. Ну отечественный — это, как правило, какие-то форки опенсорса, которые нормально поддерживаются коммунистическими коммерческими компаниями. Мы не можем, как ряд коллег по производственной линии, пойти и купить космолёт. Потому что деньги всегда можно пустить на покупку нового оборудования, и мы здесь конкурируем с производством. В смысле, что зачем им какие-то айтишные приблуды, когда можно купить ещё станок?

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

Дальше начались кадровые проблемы у подрядчиков. Мелочей на самом деле была куча, некоторые мелочи были размером с дом. Вроде бы всё простое, но каждым вопросом надо заниматься. Прилагать усилия. Одна только неопределённость требований стоила многих дней точно. Иногда хотелось вернуться в свой уютный свитер и в тишине писать код на Питоне, а не письма на русском. Но нет, хотелось довести проекты.

Но перехожу к сути.

image

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

Само хранилище в облаке — это симбиоз S3-хранилища для хранения тяжёлых файлов (в основном временных рядов) и Greenplum для хранения реляционных данных и для пользовательского доступа.

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

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

Ну или, по крайней мере, выгоднее.

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

Сейчас он вернётся в реальный мир и напишет, наверное, что может пойти не так с данными на заводе. Но сразу предупреждаю: все, кто его слушал до этого, тоже чуть не сошли с ума.

В общем, в какой-то момент мы собрали для производства нужные данные, показали эффект и доказали, что мы для чего-то нужны. Производство обрадовалось. Чтобы как можно быстрее достичь результата, мы строили многие вещи по принципу «Долой дедукцию — гони продукцию».

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

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

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

Давайте вернёмся к видеоаналитике


Заводу нужен результат. Всегда речь про практический результат, а не красоту решения задачи.

Вот железяка, про которую я рассказывал вначале:

image
Рабочий день CV: надо померить изгиб железяки на конце листа, чтобы понять его влияние на технологию

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

А вот ещё пример, где без нейросетей не обойтись.

image

Кран с магнитом поднимает лом из вагона и нужно делать снимки слоёв выгрузок. Детектируем магнит, детектируем вагон, и как только фиолетовая рамка выехала из зелёной, делаем снимок слоя. Зачем? А затем, чтобы передать это другим нейросетям, которые определят вид лома и уровень его засорённости всякой дрянью, которая в печке превратится не в жидкую сталь, а в дым (который металлурги называют ласково угар), чтобы не платить продавцам лома за эту дрянь по цене лома.

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

image
Эта камера следит и подтверждает, что техника безопасности у нас на высшем уровне

Предположим, вам нужна видеоаналитика там, где, кроме железяк на конвейере могут ехать солнечные зайчики. И от брака их никак не отличить. В этом месте вы как инженер можете предложить два решения:

  1. ML-модель, отделяющую железяки от зайчиков.
  2. Кожух на конвейер, чтобы закрыть его от солнца.

Или вот не зайчики, а к примеру капли воды. Была у ребят в соседнем подразделении задача по определению наличия стружки на полосе металла. Стружка — это плохо и никому не нужно.

Убирать её потом больно и тяжело. Когда она только появляется, то увидеть её можно, с этим можно жить — кратковременно остановить станок, убрать стружку и всё хорошо. Потом внезапно оказалось, что вместе со стружкой на металле могут быть капли, которые безумно на неё похожи.

Что ребята попробовали? Они попробовали смотреть на тень. Если у капли есть тень, то, скорей всего, она не капля. Но оказалось, что разводы очень похожи на тень. Тогда начали следить за тем, чтобы на нескольких кадрах тень поворачивалась. В целом идея-то правильная — подставить дополнительные подсветки.

В общем, ML-модель часто оказывается дешевле, но иногда и наоборот — простой фонарь решает все проблемы.

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

Ну про вагоны вы уже знаете. 25 копеек за фото на начало того проекта казались нам грабежом, поэтому мы решили писать сами. Через месяц мы подумали и решили, что есть некоторые темы, где лучше платить 25 копеек. Несмотря на то что у нас на тот момент уже были шесть крутых спецов по CV.

Реанимация идей


Ещё одно направление — регулярная проверка того, что хотят рабочие и что за идеи были записаны раньше. Потому что в 2020 году мы успели сказать, что технически невозможно сделать очень много вещей, которые оказались реальными в 2023-м. Ну вот взять тот же голосовой ввод, один из самых парадоксальных проектов производства. Всегда было дешевле поставить ещё одного человека, который слушает, что ему говорят, и нажимает на кнопки. Но вот вдруг оказалось, что Алиса на производстве тоже пригодится. Точнее, спичкит Яндекса.

И так надо с каждой идеей, которая когда-то казалась нереальной.

Вместе с реанимацией идей надо проверять то, что не делают обычные подразделения.

Конкретно искать задачу, которую можно решить на производстве, анализировать эффект, пробовать делать прототип. То есть прямо команда, у которой задача — помочь идее не сдохнуть. Или найти сдохшую и оживить, вывести до состояния старта проекта.

Прочее


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

В общем, поле всё ещё больше и мы всё ещё очень быстро растём.

Чего достигли


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

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

Но, пожалуй, самое важное, чего мы добились, — появилась уверенность в себе. Мы теперь не боимся влезать в задачи, потому что знаем, что сделаем. С бизнесовой точки зрения самый крутой результат, которого мы смогли добиться, — в том, что мы достаточно полазили по заводу и достаточно испачкались мазутом и маслом до уровня, что можем написать ТЗ для любого подрядчика, который придёт внедрять. Это реально круто. И это многого стоит.

Сейчас у нас много вакансий. Ищем дата-сайентистов, архитекторов, аналитиков данных, спецов поддержки, экспертов ИИ, бизнес-экспертов, да вообще много кого. Вот тут все вакансии. Гламура не будет. Флёра цифровизации и смузи — ну порционно раз в неделю на общем созвоне. Но точно будет тяжело. Местами так, что захочется плакать, но надо будет терпеть. Потому что заводу нужен результат.
Теги:
Хабы:
Всего голосов 228: ↑224 и ↓4+268
Комментарии278

Публикации

Информация

Сайт
omk-it.ru
Дата регистрации
Дата основания
Численность
501–1 000 человек
Местоположение
Россия