Привет, Хабр! В конце 2020 года мы в ЕВРАЗе поставили цель — научиться лучше прогнозировать и предотвращать отказы установок непрерывного литья заготовок. Для этого мы обратились к Data Science и в этой статье хотим поделиться подробностями проекта. Расскажем о подходе к построению предиктивной модели, процессе разработки, ну и, конечно, о том, что из всего этого вышло. Добро пожаловать в конвертерный цех!  Когда металлургический завод получает заказ на выпуск продукции, производственное управление планирует под него сырье и мощности. Если речь идет о производстве стальных заготовок, то это чугун, который дает доменный цех. Из доменной печи чугун отправляется в конвертерный цех, где превращается в жидкую сталь. Затем она поступает на МНЛЗ для разливки в твердые заготовки.  МНЛЗ — это машина непрерывного литья заготовок, последний агрегат в технологической цепочке конвертерного цеха. Неисправности МНЛЗ часто приводят к дефектам и могут потребовать внепланового ремонта, для которого нужно останавливать машину. Тогда заказ не отдается в срок, а подготовленный чугун приходится разливать в чушки. Продавать чугунные чушки заводу менее выгодно, чем стальные заготовки, а незапланированные остановки и запуски вредны для оборудования: МНЛЗ «любит» лить всю серию от начала до конца непрерывно.  Каждый час простоя машины непрерывного литья в среднем по отрасли обходится производителю стали примерно в 15 тыс. долларов. Из-за плановых ремонтов МНЛЗ на сталелитейных производствах простаивают порядка 420 часов в год, к ним добавляются еще 150 часов простоев по причине внеплановых ремонтов и аварий. Простоев конвертерного цеха в целом и МНЛЗ в частности стараются избегать, и любые способы сократить остановки оборудования и время, которое тратится на ремонт, ценны для производства. У нас в конвертерном цехе ЕВРАЗ НТМК четыре машины непрерывного литья заготовок. На них ежегодно выплавляется более 4 млн т стали. Сама технология литья выглядит следующим образом:    На поворотном стенде из двух консолей крепится сталеразливочный ковш с горячим металлом.  Разворотом стенда его перемещают в позицию разливки и начинают заполнять жидкой сталью промежуточный ковш.  Когда промежуточный ковш заполнен, металл, распределяясь по ручьям, начинает поступать в кристаллизатор. Там сталь охлаждается водопаровой смесью и обретает нужную форму, формируется корочка.  Из кристаллизатора металл попадает в секцию вторичного охлаждения, где обжимается роликами до нужного формата, слиток затвердевает по всему сечению.  Заготовка прокатывается по всему радиусу и поступает в зону газокислородной резки, где режется на мерные длины. Хотя основные принципы работы неизменны, каждая из четырех машин имеет свои особенности: различается количество ручьев, расположение оборудования, его наименования и параметры. На выходе получаются стальные заготовки разного сечения: круги, квадратные и прямоугольные блюмы и слябы, фасонные заготовки, которые на языке металлургов зовут «собачьей костью». Далее заготовки либо поставляют потребителю без дополнительной обработки, либо отправляют на прокатные станки, чтобы превратить в колеса, рельсы, трубы и т. д.  Разливка стали идет сериями по несколько суток, и между ними всегда есть технический перерыв на 5–6 часов. В это время происходит «перевалка» — оборудование готовят к разливке следующего заказа. Короткие ремонты в основном можно успеть провести за перевалку, хотя есть и такие, на которые нужно несколько дней. Но самое неприятное — это внеплановые ремонты. Они требуют быстрой реакции и часто прерывают разливку стали, что негативно сказывается на выполнении всего производственного плана комбината. Сегодня все крупные промышленные агрегаты оборудованы датчиками: температуры, давления и т. п. Есть они и на МНЛЗ. Данные с датчиков обычно стекаются в программы, которые поставляют вместе с агрегатами. Но такие программы не могут похвастаться продвинутым статистическим аппаратом, и «подсвечивать» проблемы с оборудованием заранее они, как правило, не умеют.  В нашем конвертерном цехе предиктивную функцию на себя, по сути, всегда брали специалисты — ремонтники, операторы и технологи, которые постоянно следят за информацией с датчиков МНЛЗ и анализируют ее. Глубокое понимание производственных процессов и годы опыта за плечами позволяют им отлавливать многие поломки еще на стадии зарождения проблемы.  Конечно, опыт — это хорошо, но еще лучше, если он грамотно дополняется технологиями, помогающими принимать решения. В этом мы лично убедились, когда внедрили модель предсказания состава угольных шихт, которая теперь экономит производству порядка 300 млн рублей в год (о проекте рассказывали подробно в этой статье). И вот одним ноябрьским днем мы вооружились уже имеющимся опытом совместной работы дата-сайентистов, разработчиков и технологов и приступили к разработке предиктивной модели для наших МНЛЗ. Большинство идей проектов приходят в ИТ-подразделение с производства. В этот раз инициатива исходила от дирекции по ремонтам дивизиона «Урал» ЕВРАЗа и руководства конвертерного цеха.  Рабочую группу мы сформировали из специалистов разного профиля — преимущественно экспертов из производственных подразделений и айтишников. На ранних этапах к команде также присоединялись консультанты и дата-сайентисты из McKinsey. В постоянный состав рабочей группы входили девять человек: владелец продукта — замначальника цеха по технико-технологическому развитию; бизнес-транслятор из службы БСЕ (Бизнес-система ЕВРАЗа) — связующее звено между бизнес-функцией и функцией ИТ; эксперт из технического управления комбината; руководитель ремонтного подразделения цеха; руководитель проекта по ИТ; дата-сайентист; три разработчика — один фронтенд- и два бэкенд-разработчика. По необходимости также подключались инженеры DevOps, дизайнеры, администраторы баз данных и серверов.    Если в кругу ИТ-специалистов произнести «предиктивная аналитика для предотвращения отказов оборудования», у большинства в голове возникнет вполне однозначная картинка. А именно — методы и модели машинного обучения на парах: производственные показатели (параметры сырья, показатели датчиков и сопутствующая метаинформация, например о погоде) и соответствие классу неисправности (или отсутствия неисправности). Прогнозирование отказов в таком случае превращается в чисто статистическую задачу.  И это отлично работает, если на производстве много однотипных агрегатов — допустим, 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 года приложение запущено на всех трех МНЛЗ и приносит экономический эффект. Идут технические работы по рефакторингу: код приводится к единому стилю, оптимизируется время расчетов и обращений к базам данных. Для пользователей эти правки незаметны, но при развитии продукта в будущем они заложат фундамент для масштабируемости и удобной поддержки. Параллельно продолжается непрерывный сбор комментариев и замечаний со стороны ремонтников, операторов, технологов. Встречи с ними проходят каждое утро, а во второй половине дня бизнес-транслятор общается с руководителем проекта и бэкенд-разработчиками, чтобы зафиксировать конкретные задачи по внесению новых параметров и корректировке работы модели. Исправная машина — это значит вовремя отданная заказчику заготовка без дефектов. В срок начинать и заканчивать запланированные серии, не увеличивать время перевалки, чтобы не терять неразлитый чугун, — вот главное, чего мы хотели добиться, внедряя предиктивную аналитику в конвертерном цехе. Сейчас наша модель оцифровывает экспертизу на производстве, сводит все данные воедино и автоматически подсвечивает проблемы. Это помогает предвидеть неисправности МНЛЗ и планировать их устранение. Но возможности проекта шире. Хорошо понимая, в каком состоянии находится машина, можно повысить эффективность планово-предупредительных ремонтов, которые на деле зачастую проводятся преждевременно. Если состояние МНЛЗ позволяет запустить еще серию — почему бы это не сделать?