Вместо кофе — раскаленное железо, а вместо чашки — огромный ковш. Data Science на службе у сталеваров

Передача расчета температуры нагревания металла от человека компьютеру

Вообразите себе кофейню, которая помимо обслуживания в зале предлагает доставку на дом. При этом у кофейни есть четкие стандарты касательно температуры кофе: эспрессо должен быть нагрет строго до 80 °C, капучино — до 85 °C, а латте — до 83 °C и ни на градус больше или меньше. Добиться этого в помещении кофейни легко — бариста готовит напиток нужной температуры и сразу же отдает его клиенту. Но что делать с доставкой? Разные маршруты, трафик на дорогах, погодные условия — кофе в пути в любом случае остынет, а значит, курьеру его нужно отдавать более горячим. А насколько?

Вообразили?

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

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

Поэтому мастера изначально нагревали металл на 20–30 °C больше, чем необходимо в итоге. Расчеты производили по таблицам (в них указаны значения для разных марок стали) и иногда оставляли небольшой запас — что называется, на глаз.

Проблема

Каждый дополнительный градус — это огромное количество энергии (которое тратится на нагрев) плюс расход графитовых электродов (нагревательных элементов). В конечном счете несовершенство процесса выливается в увеличение себестоимости продукции.

Что делать?

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

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

Часть данных уже была аккумулирована во внутренних системах НЛМК в понятном цифровом виде. Остальное операторы вводили вручную — например, число ручьев машины непрерывного литья заготовок (то есть количество полос металла, которые получаются в итоге).

Как велась разработка?

Процесс разработки велся по гибкой методологии и был разбит на 6 спринтов, по 2 недели каждый.

1. Сбор датасета.
2. Проектирование интерфейса и настройка подключения к источникам данных.
3. Интеграция с цифровыми платформами НЛМК, создание интерфейса экрана сталевара и пользовательского мануала.
4. Построение аналитического модуля, который рассчитывает возможные потери тепла и выдает искомое значение температуры.
5. Подготовка спецификаций на полученное решение и интеграция с источниками.
6. Оценка полученного экономического эффекта.

Тестирование модели также проводилось в несколько этапов. Сначала ее проверяли на уже имевшихся исторических данных — если бы она выдавала значения, слишком далекие от тех, что выбрали мастера, пускать алгоритм в работу было бы слишком рискованно (и даже опасно).

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

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

Как устроен сервис?

Сервис оптимизации расходов состоит из четырех подсистем.

Подсистема интеграции загружает данные из источников и отвечает за обмен данными между всеми подсистемами. Работает на Apache Nifi и Apache Kafka.

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

Подсистема хранения данных аккумулирует все данные, которые участвуют в расчетах, а также данные, полученные в результате работы аналитической подсистемы. Работает на СУБД PostgreSQL.

Подсистема визуализации отображает рекомендуемые параметры и визуализирует основные индикаторы. Работает на React и TypeScript.

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

Итоги

Если рассуждать в цифрах, то внедрение сервиса позволило снизить среднюю температуру примерно на 2 °C — в денежном эквиваленте это экономия примерно полумиллиона рублей в месяц. При этом дальнейшее обучение и донастройка модели, по нашим расчетам, должны повысить эффективность сервиса в 2–2,5 раза.

Михаил Чмель, мастер электросталеплавильного цеха НЛМК-Калуга.

Источник: proglib.io/p/vmesto-kofe-raskalennoe-zhelezo-a-vmesto-chashki-ogromnyy-kovsh-data-science-na...