Cистема отслеживания производственного цикла слябов

Разработать интеграционную площадку для обмена данными между двумя производственными площадками — в Липецке и Дании. Система должна отслеживать производственный цикл сляба от момента его производства на НЛМК в Липецке до конечной обработки на заводе DanSteel в Дании.

Расположенный в Фредериксверке, Дания, завод НЛМК DanSteel производит горячекатаные конструкционные стальные листы для строительства, строительства мостов, ветроэнергетики (на суше/на море), оффшорной добычи нефти и газа, судостроения, котельных и сосудов высокого давления, а также транспорта. Производственная мощность составляет 550 000 тонн листов в год.

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

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

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

1-й этап. Разливка металла
Процесс начинается с разливки жидкого металла из больших чан на агрегат УНРС (установка непрерывной разливки стали). Жидкий металл распределяется по ручьям.

2-й этап. Формирование слябов
Металл поступает на сепаратор, который разрезает его на большие куски — слябы. После остывания слябы проходят инспекцию, включая проверку макроструктуры, химического состава и дефектов.

3-й этап. Распределение
Осмотренные и обработанные слябы распределяются по складу или отправляются заказчикам. Возможна транспортировка на другие производственные площадки НЛМК.

В Дании из больших слябов изготавливают материнские листы и бэби-слябы. Это значит, что сляб разрезается на несколько частей и делится на более мелкие листы.

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

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

Хаотичное поступление информации

Уже на начальном этапе работы появилась проблема: данные от разных производственных цехов приходили через топики Kafka в хаотичном порядке. Например, сначала поступала информация об аттестации сляба, где его длина составляла 14 метров, а затем информация о его разливке, где указана длина 15 метров. Эти данные перезаписывали друг друга, и итоговая информация о продукте оказывалась некорректной.

Особенность заключалась в том, что Kafka является immutable-хранилищем. Для обновления данных в Kafka нужно было посылать новое сообщение, которое должно было заменить старое при обработке. Однако никто не гарантировал порядок этих сообщений. Это означало, что сообщения могли приходить в хаотичном порядке, и система могла случайно перезаписать более новые данные старыми.

Сложность с хранением данных

СУБД Clickhouse была выбрана до нашего выхода на проект и уже многое было завязано на эту базу данных, заменить её мы не могли. К тому же наши данные были иерархичными и даже в некоторых случаях рекурсивными: история одного и того же сляба могла храниться несколькими строками в одной таблице, а связь была через сложную схему id-адресации, а не единым сквозным идентификатором. На момент нашей работы Clickhouse был очень плохо приспособлен под JOIN и рекурсивные запросы, которые для наших отчетов были неизбежны.

Для решения проблем с синхронизацией данных из различных топиков мы разработали комплексное решение, фокусируясь на двух ключевых аспектах: обработке пересекающихся полей и предотвращении потерь обновлений (Lost Update).

Обработка пересекающихся полей

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

Проектируем новую архитектуру

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

С увеличением числа потоков данных значительно возросла нагрузка на систему. Ранее система получала данные только из одного потока, а теперь их стало шесть для каждого цеха. Это создало проблему: размер одного сообщения мог превышать допустимые архитектурные ограничения (например, сообщение не должно было превышать 1 Мб).

Для сохранения данных в Material Unit Service использовался паттерн Transactional Outbox. Этот паттерн обеспечивает надежную отправку сообщений, позволяя продолжать отправку с того места, где произошел сбой. Данные разбивались на четыре топика, чтобы избежать превышения лимита размера сообщения в Kafka и эффективно обрабатывались и сохранялись в ETL-базе данных.

В ETL-системе использовались временные таблицы и индексация для ускорения обработки данных. Затем данные агрегировались в ClickHouse, где проходила регулярная обработка данных и их консолидация из четырех таблиц. Учитывая, что данные могли поступать непоследовательно, создавался специальный буфер для отслеживания статусов отправки и обеспечения полной агрегации данных.

При разработке запросов для витрины данных в ClickHouse были учтены требования к динамическому формированию SQL-запросов. Мы использовали справочные таблицы для хранения информации о параметрах отчета и их преобразовании, что позволяло формировать SQL-запросы динамически.

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

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

Отчетный функционал получился достаточно гибким. Система позволяет визуализировать практически любые данные при условии правильной настройки параметров. Для этого пользователю необходимо четко понимать, какие данные он хочет увидеть, поскольку система предоставляет большой объем метрик для анализа.

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

На текущий момент в отчетах доступно около 144 параметров, которые могут быть использованы для анализа. Например:

• Марка стали
• Дата и время отгрузки, аттестации, разливки.
• Температуры, скорости, типы смеси, режим охлаждения.
• Размеры и результаты измерений.
• Параметры макроструктуры, технологические отклонения.
• Требуемая химия (например, содержание магния), фактическая химия и ее соответствие допустимым значениям.
• Наличие и тип обрезки.

Возможность работы с несколькими областями позволяет анализировать различные данные в нескольких разрезах одновременно. Пользователь может добавлять новые области для визуализации разных параметров, что особенно полезно при сравнении данных. Например, на ось X можно положить дату и время разливки, а на ось Y - параметр массы.

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

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

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

Выгрузка в .xls

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

Изменение порядка колонок

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

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

Липкие колонки

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

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

Легенда

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

Сохранении прогресса

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

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

Благодаря автоматизированной аналитике время расследования отклонений сократилось до нескольких минут. При анализе порядка 8-10 производственных ситуаций в сутки предприятие экономит около 120-180 часов экспертной работы ежемесячно, которые специалисты могут направить на оптимизацию производства вместо ручного поиска информации. Это экономия около 4 млн рублей на ФОТ ежегодно и 1–1,5 млн рублей на внутренних расследованиях.

Новая система обеспечивает сквозную интеграцию данных между разными этапами производства.
Если отклонение не обнаружить вовремя, то партия может уйти дальше в прокатку и металл придется переклассифицировать. Даже снижение доли брака на 0,05–0,1% при производительности DanSteel 550 тыс. тонн продукции в год потенциально означает предотвращение потерь на десятки миллионов рублей ежегодно.

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