У нас есть цех, где жидкая сталь превращается в слиток. Это происходит в УНРС — установке непрерывной разливки стали. На УНРС жидкая сталь проходит через кристаллизатор, где формируется «корочка» (оболочка) будущего непрерывнолитого слитка, и поддерживающую систему, состоящую из роликовых сегментов, где происходит окончательное затвердевание слитка за счёт охлаждения в зоне вторичного охлаждения (ЗВО) водо-воздушной смесью.
Сегменты имеют регламентированный ресурс, после достижения которого отправляются в ремонт. Плюс на сегментах могут забиваться отдельные форсунки, а это приводит к дефектам формируемых слябов.
Сегменты постоянно осматривают рабочие.
В предыдущей серии оказалось, что бумажный журнал — не самый эффективный способ отслеживания. Мы его заменили на ИТ-систему, что уже повысило безопасность и вызвало глубокое моральное удовлетворение рабочих.
Получилась критичная ИТ-система, которая не делает ничего космического или нагруженного, но предельно важна всем в цеху.
Вот про развитие этой системы я сейчас и расскажу.
Представьте: в машине, где всё работает как часы, вдруг один сегмент начинает чудить — износился. Ролик заклинивает, форсунка забилась, а вы не в курсе. Не заметили. Никто не сказал. Бумажный журнал, как всегда, лежит на пульте, технолог в смене был другой, и вроде всё шло по плану. А потом — раз, и дефект на слябе: остановка, устранение, потери.
Мы уже рассказывали, как устроена УНРС, что она делает и почему без неё никуда. Тогда у нас были бумажные журналы и Excel-файлы. А теперь у нас есть система — она показывает, где какой сегмент стоит и в каком он состоянии.
Что было не так — и почему это нельзя было игнорировать
До автоматизации всё держалось на людях. Ремонтники — с журналами, а технологи — с Excel-таблицами. Причём не по тоннажу, а по количеству плавок — как будто каждая плавка одинаковая. А они разные, в одном ручье может идти сляб на 300 мм, в другом — на 400 мм, это разная нагрузка. И износ тоже разный. А у нас — один коэффициент на всех. Это как считать износ шин у фуры и у легковушки по количеству поездок.
Данные хранились разрозненно. Прогноз вели в Excel, механики и технологи каждый день заполняли таблицы по всем сегментам, по всем ручьям. Данные собирали порой просто обзвонами по телефону. Мало того что они тратили немало времени, так ещё и человеческий фактор был на каждом этапе. Чтобы понять, когда последний раз ремонтировали сегмент, нужно было либо рыться в архивах, либо искать того самого коллегу, который когда-то это записывал. Кто-то что-то не записал, кто-то перепутал, кто-то забыл внести сегмент в таблицу — и установка вроде как в ремонте, хотя на самом деле работает.
Первая попытка: MVP как проверка гипотезы
Всё началось в 2020 году в КЦ1 (конвертерном цеху). Тогда к нам пришёл студент на испытательный срок. И собрал прототип — реальный, рабочий. Он не был идеальным и не был интегрирован с MES. Он не умел общаться с другими цехами и тормозил. 3D-модель была тяжёлая, работала с трудом, не позволяла открывать сразу несколько видов. Но он работал. И в этом был смысл.
Эта первая система показала, что считать наработку можно не вручную. Что люди готовы к цифре — если она помогает. Что стойкость можно учитывать не по плавкам, а по тоннажу. И это был уже другой уровень контроля. Мы могли в любой момент зайти и посмотреть, сколько тонн прошли через конкретный сегмент. Могли зафиксировать, что и когда с ним происходило. Правда, всё ещё вручную.
Система помогала, но жила отдельно, изолированно. Чтобы получить данные о сегменте, нужно было входить в отдельный интерфейс. Без связки с MES, без интеграции с паспортами плавок. Без возможности вносить замечания прямо на 3D-модель и без учёта в других цехах. Это была капсула — она работала, но не была частью всего организма.
Тем не менее этот MVP стал поворотной точкой. Мы поняли: людям цифра нужна. Не в отдалённом будущем, а здесь и сейчас. И когда в КЦ2 пришёл новый руководитель, он посмотрел и удивился: «А почему у вас этого ещё нет?»
В целом MVP подтвердил несколько ключевых гипотез:
Цифровой инструмент нужен и будет использоваться.
Расчёт износа по тоннажу — объективнее.
React + Three.js + Java — подходящий стек, но требует доработки для масштабирования.
Есть смысл развивать систему дальше, уже с учётом интеграции, модульности и отказоустойчивости.
Вторая версия: уже не эксперимент, а система
В 2020 году начался MVP. Спустя 12 месяцев состоялся промышленный старт, в 2022–2024-м мы проводили масштабирование, и в 2025 году будем подводить итоги. Было принято решение: вторую версию мы будем делать с нуля. С учётом всех косяков первой версии. С интеграцией с MES. Так, чтобы завтра к системе можно было прикрутить всё, для чего может понадобиться считать наработку или износ — от ковшей до валков и фурм.
Архитектуру выбрали микросервисную. Разбили по кусочкам: один сервис считает наработку, другой отвечает за ремонт, третий — за оборудование. Каждый работает отдельно, но вместе они рисуют полную картину. Хотите подключить ещё десяток устройств — пожалуйста. Хоть миксер в столовой. Если очень нужно, и его можно будет отслеживать.
Почему это удобно? Потому что обновлять теперь можно точечно. Нужно поправить расчёты? Меняем только нужный сервис, остальные не трогаем. Риски меньше, развивать проще. Каждый сервис растёт в своём темпе, под конкретные запросы пользователей.
Особенно пригодилось это при подключении к другим системам. MES отдаёт данные в своём формате, наш адаптер всё подхватывает, переводит и рассылает по своим. Если завтра поменяется API у источника данных, мы меняем только этот адаптер, а не всю систему.
Технический стек:
Java — бэкенд.
React + Three.js — фронт.
Резервирование каждого сервиса (работает, даже если один экземпляр упал).
Интеграция с MES — полноценная: данные о плавке, тоннаже и времени берутся напрямую. Например, после каждой разливки создаётся паспорт плавки и система УНРС автоматически получает всю нужную информацию, без какого бы то ни было ручного ввода.
Теперь система знает всё, что происходит в установке. Где, когда и какой сегмент установлен. Когда началась плавка. Сколько тонн прошли через каждый ручей. И умеет всё просчитывать с точностью до минуты.
Как это работает в цеху
Главный экран — это вся установка целиком. Цветовая индикация по сегментам: синий — всё нормально, жёлтый — 80–100% стойкости, красный — всё, пора в ремонт. Видно, где сегмент установлен, где в резерве, где в ремонте. Можно провалиться внутрь и посмотреть каждый сегмент отдельно: когда монтировали, какие были замечания, кто устранял дефекты.
Работает всё в 3D: сегмент можно крутить, увеличивать, смотреть с разных сторон и под любым углом.
Если технолог на обходе увидел, что ролик еле крутится, — он отмечает это прямо на модели. Не записывает на бумажке. Не пытается потом вспомнить. А просто кликает — и всё фиксируется.
Есть готовый справочник дефектов: забитая форсунка, течь воды, люфт ролика. Можно выбрать из списка. Можно добавить вручную, если случай нестандартный, и всё это остаётся в истории. Когда сегмент снимают и отправляют в ремонт, ремонтники уже знают, на что обратить внимание.
Сегмент после ремонта попадает в резерв. Система отслеживает его путь: монтаж, работа, замечания, демонтаж, ремонт, возврат. Это жизненный цикл — он больше не теряется, все знают, что с ним было.
3D-рендеринг и DevOps — подробности
Основной интерфейс построен на базе React с использованием Three.js — для интерактивной 3D-визуализации установки. Это важный инструмент: установка непрерывного литья стали работает на два ручья, с разными диаметрами роликов сегментов и двусторонним расположением форсунок. В 2D это была бы схема из десятков разрезов, в которой легко запутаться. 3D позволяет крутить модель, приближать, отмечать нужную точку — например, форсунку, у которой замечено неполное распыление воды. Сейчас — оптимизированная версия, с возможностью держать на экране несколько установок одновременно. Архитектурно визуализация стала отдельным фронтовым микросервисом — независимым, но связанным с системой через API. Сама система построена по микросервисной архитектуре: расчёт наработки, учёт оборудования, ремонты — каждый сервис занимается своим и может развиваться независимо. Всё это работает в контейнерах, оркестрация — через OKD (аналог OpenShift), с двукратным резервированием по каждому контейнеру. То есть даже если один экземпляр упадёт — второй продолжит работу, а первый поднимется автоматически.
Мерительные затравки: чтобы не гадать, а измерять
Одна из самых технологичных штук в этой истории — мерительная затравка, такой специальный сляб с датчиками. Внутри — сенсоры, снаружи — термостойкое шасси. Его прогоняют через установку как обычную заготовку. Только вместо стали — сенсоры, которые фиксируют расстояние между роликами, зазоры, отклонения.
Если зазор между роликами должен быть 220 мм, а затравка показывает 223 — всё, тревога. Раньше такое замечали, когда дефект уже появлялся на слябе. А теперь знаем об этом до того, как проблема станет проблемой.
Работает это так: затравка идёт по ручью, собирает данные, затем данные идут в систему и показания сверяются с нормой. И пользователю показывается, где начинается износ. С точкой на экране.
Это важно: когда ролики изнашиваются, зазор увеличивается и влияет на охлаждение, на геометрию, на прочность. Раньше всё это ловили вручную — и, бывало, когда уже поздно. Теперь система говорит: «Смотри сюда. Вот здесь начинается беда».
Где облажались и как выкрутились
Конечно, не всё сразу пошло как по маслу. Например, вначале мы заложили логику: если хоть один сегмент не установлен — установка как бы не работает. По аналогии: нет одного колеса — машина не поедет.
А потом жизнь сказала: вы шутите? Люди забывают внести данные. И система останавливает подсчёт наработки для всех сегментов, даже если 9 из 10 стоят и пашут. Пришлось менять подход. Теперь система считает по тем, что есть. А если потом забытый сегмент внесли — она сама всё пересчитае��. Спокойно и без претензий.
Так же сделали с замечаниями и ремонтами. Всё можно внести постфактум. Главное — чтобы данные не терялись и система продолжала видеть установку.
Самое сложное — это синхронизировать людей
В УНРС много участников. Технологи, ремонтники, инженеры — у всех своя правда. Каждый отвечает за своё. И если хотя бы один не работает в системе — всё рушится. Не внесли сегмент — тоннаж не считается. Не занесли замечание — дефект не отработан. Не согласовали монтаж — система считает, что сегмент в резерве.
Вначале было жёстко. Приходилось сопровождать внедрение лично. Встречаться, объяснять, руками заводить сегменты, поднимать старые списки. Иногда — спорить. Иногда — уговаривать. Кто-то бухтел: «Опять хрень какая-то, только бумажек прибавится».
Но через три месяца ворчать перестали. Потому что стало легче.
Самое интересное произошло примерно через месяц после внедрения. Один из ремонтников, который раньше ворчал про «новую хрень», сам позвонил мне: «Слушай, а можно как-то в нашей системе отметить, что этот ролик мы заменили на усиленный? Он должен служить дольше». Вот так, из «вашей системы» она постепенно стала «нашей». А ещё через месяц уже руководство ЦРСО спрашивало: «А когда мы сможем отслеживать в системе не только сегменты, но и запчасти к ним? Чтобы видеть, какой ролик сколько отработал после замены?»
Отдельная история — взаимодействие между цехами. Кто отвечает за внесение данных о монтаже — ремонтники или технологи? Кто подтверждает замечания? Кто закрывает ремонт? Приходилось садиться за стол переговоров, рисовать блок-схемы, прописывать регламенты. И обязательно — показывать преимущества. Чтобы ремонтники знали заранее, какой сегмент готовить. Чтобы технологи могли прогнозировать. Чтобы руководство видело всю картину в целом.
Что в итоге поменялось
Теперь всё фиксируется — кто установил сегмент, кто сделал ремонт, какие были замечания и что именно исправили.
Не нужно никому звонить, искать бумажки, расшифровывать чужой почерк. Все видят одну и ту же картину. Когда технолог, инженер и ремонтник смотрят на одни и те же данные — возникает доверие. Исчезают конфликты. Снижается вероятность ошибок. Увеличивается прозрачность.
И самое важное: теперь можно прогнозировать. Система считает, сколько тонн прошло через сегмент, и говорит, когда примерно он достигнет критического износа. Не точно в час, но достаточно точно, чтобы запланировать замену без суеты и авралов.
Самый заметный эффект — время на поиск информации о состоянии сегмента сократилось кратно. При этом точность прогнозирования сроков ремонта повысилась.
Факторы успеха:
Гибкая архитектура. Всё построено на микросервисах, каждый компонент можно обновлять независимо от других.
Интеграция с MES. Данные подтягиваются автоматически — ни звонков, ни бумажной волокиты.
3D-модель как основной интерфейс. Рабочие визуально отмечают дефекты на сегментах — быстрее и точнее.
Резервирование и отказоустойчивость. Система работает непрерывно даже при падении части компонентов.
Обратная связь от пользователей. Изменения и улучшения вносились на основе реального опыта цехов.
Масштабируемость. Сервисы переиспользуются: сейчас их применяют не только для УНРС, но и, например, для учёта стойкости футеровки ковшей.
Что дальше
Сейчас система работает на КЦ2. В КЦ1 — всё ещё MVP. Но и там уже готовы перейти, сами просят, потому что разница очевидна.
Параллельно части системы начинают использовать в других подразделениях. В учёте стойкости футеровки в сталеразливочных ковшах. В отслеживании износа валков. Архитектура позволяет.
Следующим большим шагом станет интеграция с системой планирования ремонтов. Сейчас мы знаем, когда сегмент нужно будет заменить, но планирование ремонтов происходит в другой системе. Объединив их, мы сможем автоматически резервировать ремонтные ресурсы с учётом прогнозируемого износа оборудования.
Также мы начинаем внедрять предиктивную аналитику на основе машинного обучения. Система будет анализировать не только тоннаж, но и условия эксплуатации, чтобы ещё точнее прогнозировать срок службы каждого конкретного сегмента в каждом конкретном ручье.
Мы начинали с учёта стойкости. А сделали — основу цифрового ремонта. Масштабируемую. Гибкую. Прозрачную. И теперь это уже не просто инструмент. Это подход. Основа для более широкого подхода — к ремонту оборудования вообще.
