Привет, Хабр! В конце 2020 года мы в ЕВРАЗе поставили цель — научиться лучше прогнозировать и предотвращать отказы установок непрерывного литья заготовок. Для этого мы обратились к Data Science и в этой статье хотим поделиться подробностями проекта. Расскажем о подходе к построению предиктивной модели, процессе разработки, ну и, конечно, о том, что из всего этого вышло.

Добро пожаловать в конвертерный цех!

Чем плохи простои в конвертерном цехе на производстве стали

Когда металлургический завод получает заказ на выпуск продукции, производственное управление планирует под него сырье и мощности. Если речь идет о производстве стальных заготовок, то это чугун, который дает доменный цех. Из доменной печи чугун отправляется в конвертерный цех, где превращается в жидкую сталь. Затем она поступает на МНЛЗ для разливки в твердые заготовки.

МНЛЗ — это машина непрерывного литья заготовок, последний агрегат в технологической цепочке конвертерного цеха. Неисправности МНЛЗ часто приводят к дефектам и могут потребовать внепланового ремонта, для которого нужно останавливать машину. Тогда заказ не отдается в срок, а подготовленный чугун приходится разливать в чушки. Продавать чугунные чушки заводу менее выгодно, чем стальные заготовки, а незапланированные остановки и запуски вредны для оборудования: МНЛЗ «любит» лить всю серию от начала до конца непрерывно.

Каждый час простоя машины непрерывного литья в среднем по отрасли обходится производителю стали примерно в 15 тыс. долларов. Из-за плановых ремонтов МНЛЗ на сталелитейных производствах простаивают порядка 420 часов в год, к ним добавляются еще 150 часов простоев по причине внеплановых ремонтов и аварий. Простоев конвертерного цеха в целом и МНЛЗ в частности стараются избегать, и любые способы сократить остановки оборудования и время, которое тратится на ремонт, ценны для производства.

Как функционируют МНЛЗ и как их обслуживают

У нас в конвертерном цехе ЕВРАЗ НТМК четыре машины непрерывного литья заготовок. На них ежегодно выплавляется более 4 млн т стали. Сама технология литья выглядит следующим образом:

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

• Разворотом стенда его перемещают в позицию разливки и начинают заполнять жидкой сталью промежуточный ковш.

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

• Там сталь охлаждается водопаровой смесью и обретает нужную форму, формируется корочка.

• Из кристаллизатора металл попадает в секцию вторичного охлаждения, где обжимается роликами до нужного формата, слиток затвердевает по всему сечению.

• Заготовка прокатывается по всему радиусу и поступает в зону газокислородной резки, где режется на мерные длины.

Хотя основные принципы работы неизменны, каждая из четырех машин имеет свои особенности: различается количество ручьев, расположение оборудования, его наименования и параметры. На выходе получаются стальные заготовки разного сечения: круги, квадратные и прямоугольные блюмы и слябы, фасонные заготовки, которые на языке металлургов зовут «собачьей костью». Далее заготовки либо поставляют потребителю без дополнительной обработки, либо отправляют на прокатные станки, чтобы превратить в колеса, рельсы, трубы и т. д.

Разливка стали идет сериями по несколько суток, и между ними всегда есть технический перерыв на 5–6 часов. В это время происходит «перевалка» — оборудование готовят к разливке следующего заказа. Короткие ремонты в основном можно успеть провести за перевалку, хотя есть и такие, на которые нужно несколько дней. Но самое неприятное — это внеплановые ремонты. Они требуют быстрой реакции и часто прерывают разливку стали, что негативно сказывается на выполнении всего производственного плана комбината.

Предиктивная аналитика для МНЛЗ

Сегодня все крупные промышленные агрегаты оборудованы датчиками: температуры, давления и т. п. Есть они и на МНЛЗ. Данные с датчиков обычно стекаются в программы, которые поставляют вместе с агрегатами. Но такие программы не могут похвастаться продвинутым статистическим аппаратом, и «подсвечивать» проблемы с оборудованием заранее они, как правило, не умеют.

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

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

И вот одним ноябрьским днем мы вооружились уже имеющимся опытом совместной работы дата-сайентистов, разработчиков и технологов и приступили к разработке предиктивной модели для наших МНЛЗ. Большинство идей проектов приходят в ИТ-подразделение с производства. В этот раз инициатива исходила от дирекции по ремонтам дивизиона «Урал» ЕВРАЗа и руководства конвертерного цеха.

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

• владелец продукта — замначальника цеха по технико-технологическому развитию;

• бизнес-транслятор из службы БСЕ (Бизнес-система ЕВРАЗа) — связующее звено между бизнес-функцией и функцией ИТ;

• эксперт из технического управления комбината;

• руководитель ремонтного подразделения цеха;

• руководитель проекта по ИТ;

• дата-сайентист;

• три разработчика — один фронтенд- и два бэкенд-разработчика.

По необходимости также подключались инженеры DevOps, дизайнеры, администраторы баз данных и серверов.

Машинное обучение vs человеческая экспертиза

Если в кругу ИТ-специалистов произнести «предиктивная аналитика для предотвращения отказов оборудования», у большинства в голове возникнет вполне однозначная картинка. А именно — методы и модели машинного обучения на парах: производственные показатели (параметры сырья, показатели датчиков и сопутствующая метаинформация, например о погоде) и соответствие классу неисправности (или отсутствия неисправности). Прогнозирование отказов в таком случае превращается в чисто статистическую задачу.

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

В нашем же случае агрегата всего четыре, и это априори настолько ограничивало объем данных, что машинное обучение в его классическом формате было неприменимо. На старте нам были доступны данные за полгода, и инцидентов за этот период произошло совсем немного. Попытайся мы обучить на них какой-нибудь алгоритм, это бы привело к тому, что он, во-первых, не учитывал бы всего множества поломок, которые могут произойти в МНЛЗ, а во-вторых, грешил бы предвзятостью в пользу тех пяти-шести инцидентов, которые случились за эти шесть месяцев.

Поэтому мы решили отказаться от машинного обучения и идти экспертным путем. То есть разработать набор правил для модели совместно с нашими специалистами-производственниками.

С экспертного языка на математический

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

Происходило это следующим образом. Специалисты из производственных подразделений определяли, какие параметры или совокупность параметров могут сигнализировать о проблеме. Вначале они давали довольно абстрактные рекомендации, например: «Смотрим на нагрузки на приводные ролики». Что значит «смотрим»? Сколько у машины приводных роликов и датчиков нагрузки? Как получить с них данные? Эта нагрузка должна быть больше или меньше какого-то числа? Это число нам известно или его нужно определить на основе данных за предыдущие периоды?

Мы задавали сотни таких вопросов и вместе с технологами прорабатывали ответы. В результате абстрактное «смотрим на нагрузки на приводные ролики» превращалось в подробное, математически конкретизированное правило:

• У машины есть 18 приводных роликов, на каждом по одному датчику нагрузки. 18 роликов расположены на последних девяти сегментах зоны ручья, по два на сегмент.

• Данные о нагрузках можно взять из такой-то системы. Она присылает большой словарь и нужные нам ключи: 15.1–15.18 включительно. Данные поступают в килоньютонах.

• Текущее значение должно лежать в двустороннем коридоре допустимости. Если оно выходит за нижнюю или верхнюю границу, подсвечиваем сегмент как «требующий внимания».

• Нижнюю и верхнюю границы коридора определяем так: это 1-й и 99-й перцентили значений нагрузки на данный привод за предыдущие периоды. При этом перцентили должны каждый раз подбираться из выборки, отфильтрованной по текущему формату сечения, группе марок стали и скорости разливки. Эти три параметра, в свою очередь, доступны в такой-то системе под такими-то ключами.

Так мы переводили правила, озвученные ремонтниками, в формат конкретных технических принципов, ведь только в таком — подробном — виде их можно было передавать бэкенд-разработчикам для интеграции в систему. Мы вместе собирались в операторской агрегата и шаг за шагом «разбирали» каждую единицу оборудования МНЛЗ. В итоге подобных правил в рамках проекта образовалось много — по паре сотен на каждую машину. Чтобы хранить их в одном месте и без затруднений отслеживать ход внедрения, мы вели облачную таблицу, к которой был доступ у всей команды.

Технический стек

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

Для создания API мы взяли Python-фреймворк Falcon, а для работы с БД — библиотеку SQLAlchemy. Из-за сложности запросов решили использовать не ORM, а ядро библиотеки, то есть писать сырые SQL-запросы. Микросервисы связывались между собой через RabbitMQ. Оперативные данные с датчиков на МНЛЗ передавались в брокер Kafka, откуда с помощью модуля ETL они перекладывались в нужной агрегации во внутреннюю базу данных нашего приложения. Фронтенд написали на React со стандартным HTTP API.

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

MVP решили запускать на трех машинах конвертерного цеха: четвертой, первой и третьей. Мы начали с МНЛЗ-4: несмотря на новизну, у нее был наименьший среди «коллег» коэффициент технической готовности, что говорило о высоком потенциале для предиктивной аналитики. Запуск системы на МНЛЗ-1 и МНЛЗ-3 запланировали на более поздний срок: по просьбам сотрудников, которые непосредственно имеют дело с агрегатами, там дорабатывались системы охлаждения.

Как работает приложение

Нормальное состояние оборудования программа маркирует серым. Если на одном или нескольких узлах что-то идет не по плану, это подсвечивается красным. ​​Желтым цветом обозначаются узлы оборудования МНЛЗ, где в конкретный момент фиксируются некритичные отклонения одного из отслеживаемых параметров. Индикаторы с батарейками показывают запас устойчивости узла до замены — по аналогии с батареей телефона.

Все данные выводятся в операторской на большой монитор, и оператор в режиме онлайн отслеживает данные, которые требуют его внимания и подключения ремонтников, либо накапливает информацию для дальнейшего разбора и действий. Если проблему можно устранить непосредственно во время работы МНЛЗ, она решается без остановки оборудования. Прочие инциденты фиксируются в журнале дефектов, и ремонтная бригада начинает ремонтировать или менять конкретную секцию во время перевалки.

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

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

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

Промежуточные результаты

На старте мы ставили себе такие цели: сократить простои МНЛЗ-4 на 135 часов в год, МНЛЗ-3 — на 27 часов и МНЛЗ-1 — на 26,9 часа. Целевой экономический эффект — 115 млн, 36 млн и 35,4 млн рублей соответственно.

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

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

Эффект от MVP в цифрах мы измерили в мае 2021 года, через полгода после старта разработки. За май удалось сократить простои на 4 часа и получить общий эффект в размере 5 млн рублей. Стоит оговориться, что MVP охватывал лишь небольшую часть МНЛЗ — роликовую зону из 11 сегментов, через которые проходит стальной слиток. Именно в этой зоне внеплановые ремонты проводились чаще всего.

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

Бэклог и планы

На февраль 2022 года приложение запущено на всех трех МНЛЗ и приносит экономический эффект. Идут технические работы по рефакторингу: код приводится к единому стилю, оптимизируется время расчетов и обращений к базам данных. Для пользователей эти правки незаметны, но при развитии продукта в будущем они заложат фундамент для масштабируемости и удобной поддержки.

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

Исправная машина — это значит вовремя отданная заказчику заготовка без дефектов. В срок начинать и заканчивать запланированные серии, не увеличивать время перевалки, чтобы не терять неразлитый чугун, — вот главное, чего мы хотели добиться, внедряя предиктивную аналитику в конвертерном цехе. Сейчас наша модель оцифровывает экспертизу на производстве, сводит все данные воедино и автоматически подсвечивает проблемы. Это помогает предвидеть неисправности МНЛЗ и планировать их устранение.

Но возможности проекта шире. Хорошо понимая, в каком состоянии находится машина, можно повысить эффективность планово-предупредительных ремонтов, которые на деле зачастую проводятся преждевременно. Если состояние МНЛЗ позволяет запустить еще серию — почему бы это не сделать?