В процессе производства стали есть точно такие же проблемы. Плавка должна прийти на разливку, будучи строго определенной температуры, но по дороге ее ждёт множество шагов, на каждом из которых металл остывает. Чтобы знать, до какой температуры нагреть металл на выходе, нужно очень точно, вплоть до минуты, спрогнозировать весь маршрут стали до разливки.
Человеку в такой задаче трудно достичь идеальной точности, поэтому у нас работает цифровой сервис, который называется «Заказ температуры».
Меня зовут Михаил Чмель. Я работаю в Группе НЛМК уже 8 лет. Точнее, я работаю на предприятии НЛМК-Калуга в электросталеплавильном цехе. До этого работал на Челябинском металлургическом комбинате, а потом прислал резюме на новый завод. Пригласили, понравилось, переехал в Калугу насовсем.
Изначально я пришел на позицию помощника сталевара, теперь стал специалистом по повышению эффективности производства и очень хочу стать мастером участка выплавки и внепечной обработки.
Это я на своем рабочем месте
Моя задача: обеспечить максимально безопасное производство стали с нужной производительностью — к примеру, сделать за смену 17 плавок.
В марте 2020 года мы с командой провели небольшой штурм на тему «какой цифровой сервис облегчит и улучшит нашу работу». Идею предложили дирекции по цифровой трансформации. Так что официально именно я – product-owner сервиса. Разработка началась в первых числах мая, а к эксплуатации мы приступили уже в октябре.
Разумеется, со стороны производства проектом занимался не только я. Целая команда технологов генерировала входные данные, рассказывала, как устроен процесс, что уже оцифровано, а что нет. Я собирал информацию, аккумулировал ее и передавал в IT.
Что мы хотели получить от сервиса
Прежде чем переходить к описанию построенной нами цифровой системы, стоит разобраться с тем, как устроен процесс производства стали у нас в Калуге (немного отличается от того, что в Липецке). Итак, три ключевых этапа.
- В дуговую сталеплавильную печь (ДСП) загружается порядка 145 тонн металлолома. Полученный в результате плавки «жидкий полупродукт» попадает в сталеразливочный ковш и отправляется на установку ковш-печь (УКП).
- На УКП металл путем добавления ферросплавов и нагрева с помощью графитовых электродов доводится до требуемого химического состава и температуры.
- Далее расплавленный металл на сталеразливочном ковше доставляется к машине непрерывной разливки стали (МНЛЗ), которая производит финальный продукт — непрерывно литую заготовку (НЛЗ).
Наиболее интересным для оптимизации и автоматизации нам показался этап №2, а именно доведение стали до нужной температуры перед отправкой на МНЛЗ.
Так стальные заготовки выходят из ручьев МНЛЗ (машины непрерывного литься заготовок)
В идеале сталь должна быть на 20-30 градусов Цельсия горячее температуры ее плавления — в рамках liquidus. Как доставить её из пункта А в пункт Б, учитывая все издержки?
Ранее мы производили расчет по собственным таблицам — у каждой марки стали свои значения. Чтобы гарантированно избежать ошибки, мастер, исходя из своего опыта, оставлял небольшой запас. Это было необходимо, так как стальковш с расплавленной сталью может, например, встать в «очередь» и потерять температуру.
Такой подход, проверенный годами, увы, несовершенен. Тот самый «запас», о котором мы говорили выше, приводит к увеличению себестоимости продукции. Быстрее выгорают графитовые электроды, впустую расходуется электроэнергия. Требовалась специальная система, которая, обрабатывая большой массив входных данных, рассчитывала минимально оптимальную температуру стали.
Так заготовки выглядят остывшем виде
Внутренняя подготовка к разработке решения
Прежде всего нам потребовалось определиться, какие именно данные требуются системе расчета температуры для корректной работы. Почти все уже было оцифровано и готово к передаче в сервис, но некоторые параметры мастер должен ввести самостоятельно. Простой пример — 8-ручьевая машина НЛМЗ. Человек определяет, сколько ручьев будет задействовано, и вводит эти цифры в систему.
Состояние футеровки также влияет на температуру — поэтому мастер обязан указать, производился ли ее ремонт, и если да, то в какое время.
Первое время мы подготавливали необходимый пакет данных для сервиса и проводили мониторинг со стороны data science: собирали историческую информацию за 2 года, изучали, какие именно параметры требуются, искали закономерности. Основная цель этого этапа была в том, чтобы понять, насколько можно снизить температуру и, соответственно, какова будет экономическая выгода от этого понижения.
Данные передавались в Kafka внутри нашей единой цифровой платформы (ЕЦП). Без ЕЦП разработка могла существенно затянуться. В нашем распоряжении было множество готовых компонентов — для перемещения данных или, например, для хранения. Grafana — для отчетности. Различные инструменты мониторинга. Платформе ЕЦП мы во многом обязаны тем, что продукт вышел в срок и уложился в начальный бюджет. Некоторые узкоприкладные сервисы для мониторинга активности и жизнеспособности серверов в формате агентов установлены на машины. Они следят за загрузкой, фиксируют, нет ли сбоев. Все это тоже предоставила ЕЦП.
Для контроля версий мы использовали GitNLMK: это существенно облегчило понимание, с какой версией продукта мы работаем, куда происходят коммиты, какая — с фиксами, какая — нет.
Данные агрегировались сначала на уровне БД, затем — непосредственно в приложении, которое выдает рекомендации. Новые датчики устанавливать не пришлось, все необходимое уже было. Из АСУ ТП мы получали детальную информацию по плавкам. Дополнительные данные — сведения по ковшам, материал футеровки и прочее — брались из MES. На данном этапе большое спасибо за активное участие и неравнодушие к делу представителям IT от НЛМК-Калуга Семену Денисову, Павлу Лебедеву, Виктору Никулину и Евгении Смолкиной.
Этапы разработки
Процесс разработки у нас был стандартный:
- Мы изучили идею со всех сторон, подбили экономику, проверили концепцию — что есть необходимые данные, возможности интеграции, а модель в принципе осуществима и применима.
- На техсовете подтвердили цифры предварительной плановой эффективности и постановили, что гипотеза имеет право на реализацию в MVP.
- Разработали и внедрили продукт. Уже больше года сервис работает и приносит пользу. Сейчас он развернут на мощностях в Липецке, Калуге и Ревде.
Партнером по разработке для нас стали коллеги из компании Accenture.
Процесс был разбит на 6 спринтов по две недели:
- После определения источников, состава данных и способов интеграции подрядчику были предоставлены исторические данные за 2 года. На инфраструктуре НЛМК развернуты компоненты будущего сервиса.
- Сформирован сценарий использования и спроектирован интерфейс сервиса. Настроены подключения к источникам данных.
- Разработаны интеграция с СИ, интерфейс экрана сталевара и подготовлена первая пользовательская инструкция.
- Построен аналитический модуль, прогнозирующий теплопотери и выдающий рекомендации по температуре выдачи на УКП. Разработан порядок проведения тестирования системы.
- Подготовлены спецификации на аналитическое решение и интеграцию с источниками с описанием интеграционных потоков.
- Произведена оценка фактического экономического эффекта.
Ранее мне ни разу не приходилось работать по гибкой методологии — со спринтами, бэклогами и прочим подобным. Совершенно новый опыт, новая специфика. Работая в продуктовой команде наших цифровизаторов, я очень многое почерпнул для своей основной работы. Даже завел SCRUM-доску — я на ней пишу текущие задачи. По-моему, это очень правильно, что каждая задача должна быть законченным продуктом, нести какую-либо ценность.
Это электроды, которыми при необходимости можно разогреть плавку
Тестирование сервиса
В рамках холодного теста мы изучали, насколько адекватны прогнозы и рекомендации на исторических данных. Без этой проверки ни в коем случае нельзя вводить продукт в «боевую» эксплуатацию.
Теплое тестирование происходило так: мы включали сервис, и он начинал выдавать рекомендации. Сталевары субъективно оценивали их адекватность и давали обратную связь о качестве рекомендаций и работе сервиса в общем.
Во время горячего тестирования сталевары прислушивались к рекомендациям сервиса. Большая группа лиц следила за работой, анализировала, приводят ли рекомендации к достижению целевых показателей — снижению расхода электроэнергии и электродов, — или есть аномалии, которые следует устранить.
Как работает сервис
Для лучшего понимания логики работы сервиса взгляните на эту схему:
Как видно из схемы, сервис состоит из 4-х подсистем.
- Подсистема интеграции данных отвечает за загрузку данных из источника, а также обмен данными между подсистемой хранения данных и другими подсистемами. Реализована на базе Apache Nifi (вот, кстати, статья нашего гуру по этой системе) и Apache Kafka.
- Аналитическая подсистема отвечает за оценку оптимальной температуры разливки, прогнозирование целевой температуры на МНЛЗ, а также за обновление моделей (дообучение).
- Подсистема хранения данных обеспечивает операционное хранение необходимого для расчетов объема исходных данных, результатов расчетов подсистемы анализа данных, а также статус выполнения рекомендаций оператором. Реализована на СУБД PostgreSQL.
- Подсистема визуализации данных отвечает за визуализацию ключевых индикаторов на основе расчетов аналитической подсистемы, отображение рекомендуемых параметров. Реализована на React + TypeScript.
Вот так это работает на более высоком уровне:
Обратите внимание: система не управляет температурой напрямую, а выдает рекомендации мастерам.
В процессе выдачи рекомендаций участвуют сразу 2 математические модели:
- линейная регрессия ловит общий тренд по теплопотерям;
- бустинг позволяет осуществлять точную донастройку тренда.
Для достижения максимально точного результата показания обеих моделей совмещаются.
Придется ли в будущем дообучать модель, зависит от подвижности среды. В рамках прогнозирования теплопотерь не было факторов, которые могут меняться ежеминутно, поэтому, грубо говоря, вчерашний день ничем критично не отличается от сегодняшнего. В рамках тестирования, разумеется, происходило дополнительное переобучение модели на новых данных, качественные метрики оценивались вплоть до достижения требуемого результата.
Чем все закончилось (или нет?)
Нам удалось снизить среднюю температуру стали в промковшах на 2 ºC. Казалось бы, совсем незначительная цифра. Однако уже первые тесты показали, что экономия электроэнергии и графитовых электродов на УКП составила более 500 тысяч рублей в месяц. Мы ожидаем, что после окончательной стабилизации сервиса, подключения новых площадок и полном охвате технологических карт и плавок эффективность его применения вырастет в 2-2,5 раза.
В НЛМК-Калуга жидкая сталь, которую мы перевозим в ковшах, в конце концов становится арматурой
…или стланым уголком
Поначалу новый сервис вызвал массу скепсиса и непонимания. Людям казалось, что это всего лишь дань моде на оцифровку данных, которая не принесет практической пользы. Однако спустя короткое время, когда наши цеховые специалисты привыкли к сервису и начали учитывать его рекомендации, наметился существенный прогресс. Снизился риск возникновения «человеческой» ошибки, возросла экономическая эффективность производства. Особая благодарность за поддержку внедрения начальнику электросталеплавильного цеха (ЭСПЦ) Артему Ивахнюку и начальнику участка выплавки стали Николаю Бугуеву.
Что касается сложностей проекта — казалось, что для правильного прогноза нужно неподъемное количество данных, которые мы попросту не сумеем собрать.
Еще один спорный момент (я касался его вскользь в самом начале статьи) — «Как могут непосвященные в металлургию люди (т.е. айтишники) разрабатывать для нас алгоритмы и процессы? Они же ничего подобного в жизни не видели!» Коллеги не понимали, каким образом математические модели могут спрогнозировать специфические цифры на сложном производстве. У многих это в голове не укладывалось. Я лично верил, что всё получится, потому сам объяснял IT-команде, как все работает, видел, что ребята движутся в правильном направлении. Помогали сотрудники нашего производственно-технического отдела Сергей Вербный и Вадим Конюхов — обсуждали, как строить гипотезу, какие данные передавать и сам механизм работы сервиса.
Ребята из IT шутили: мол, я для них — «глаза», камера в цехе, с помощью которой можно рассмотреть любые процессы. Им даже не приходилось выезжать на производство — они были только один раз, перед самым запуском. Пандемия все-таки, меньше ездишь — здоровее будешь. Хотя датасаентисты прекрасно видят мир через призму данных, я был их «камерой» в реальном цехе :)
Над проектом мы работали фактически 24/7 — И мы, и коллеги из Accenture подключались в любое время. Производство у нас непрерывное и ценный фидбэк может прийти в том числе от сотрудников, заступивших на ночную смену. Все идеи мы старались отрабатывать максимально быстро. Бывало, на этапе испытаний сервис не всегда выдавал корректные рекомендации. Мы вместе изучали цифры: и в 11 вечера, и в полночь собирались. Плавки-то идут каждый час — нужно отслеживать, какую рекомендацию сервис в 22:00 выдал, какую — в 23:00 и дальше.
Многие мои коллеги из цеха сомневались, что команда непосвященных в металлургию IT-специалистов сможет грамотно погрузиться в процесс. Новой информации для всех было много, и у производственников, и у IT кипел, но все вникли по итогу.
Сейчас система постоянно совершенствуется и дорабатывается — ее потенциал все еще не раскрыт до конца. Мы можем еще сильнее снизить температуру в стальковшах и обеспечить еще более точное прогнозирование. Продуктовая команда круглосуточно отслеживает работу сервиса и отмечает дополнительные точки роста его функциональности. Отдельное спасибо лидеру продуктовой команды Андрею Фимушину! Без него наш продукт бы никогда не получился, ему очень круто удалось объединить столь разную по своим качествам, возрасту и профессиональным навыкам команду.
P.S. А еще из трудностей: «айтишники» придумали для наших внутренних терминов свой жаргон. Для нас прямо дико звучало, когда мы слышали что-то типа «сталевар жарит плавку» или «истопил электроды». Бомбило, но юмор таки победил)
Автор: Михаил Чмель
