Дано: здоровенный конвертерный цех. Два миксера, каждый с дом, перемешивают расплавленный чугун, три конвертера (куда грузят целые ковши) превращают его в сталь, четыре установки непрерывной разливки стали формируют огромные слитки-слябы. Между всеми этими агрегатами катаются тепловозы и сталевозы с многотонными ковшами жидкого металла. Всё это — размером с микрорайон города.
На каждом участке есть ответственные люди и механизмы.
За всем присматривают диспетчер и начальник смены, которые «играют» с этим в Satisfactory.
Раньше у них были телефон, два больших телевизора и пять аналоговых камер.
Теперь камер — 150, они с CV-детекторами событий и «тупыми» эвристическими детекторами отклонений, есть полноценные мнемосхемы с телеметрией с каждого узла, включающие в себя ML-модели, и всё это всё больше напоминает сложную компьютерную игру.
Сейчас я расскажу, как мы меняли интерфейс диспетчера, чтобы он мог рулить цехом.
Дисплей в диспетчерской
Тут надо сразу сказать, что диспетчеризация — это не планировщик операций. Она не управляет процессами, а показывает запланированные и фактические маршруты плавки, отслеживает всё — от поворота конвертеров до перемещения ковшей между агрегатами, агрегирует нужные рекомендации, например, прогнозируемый химический анализ чугуна в миксере, рассчитанный с помощью ML-модели и проекта заказа шихтовки. А ещё собирает аналитику и видеоархив с каждой камеры, прикрученной к цеху.
Визуальный контроль ковшей
То есть это сервис, который обеспечивает визуальный контроль, мониторинг и дальнейший разбор аналитики, которая требуется для отслеживания ключевых метрик, например, температуры выпуска металла с конвертера, уровня угара и состояния футеровки.
Система состоит из нескольких частей:
То есть все необходимые характеристики
Наблюдение и контроль за ковшами
Архив камер
Первый конвертерный цех занимается тем, что 24 часа в сутки семь дней в неделю на четырёх установках непрерывной разливки делает большие слябы. Для этого используются три конвертера, пять установок доводки металла, на которых в сталь всыпают необходимые (с учётом рекомендаций системы отдачи ферросплавов) для каждой конкретной марки добавки. А ещё — две печи-ковша для подогрева металла до нужной температуры и одна установка циркуляционного вакуумирования.
Цикл конвертера, завалка/заливка
Из доменного цеха к нам, в миксерное отделение, приезжают ковши с расплавленным чугуном. Первым делом нужно определить химический состав содержимого. Дальше чугун переливается в чугунозаливочные ковши (ЧЗК), которые примерно в три раза больше. Сделать это нужно определённым образом: либо напрямую, либо через миксер. Суть переливов — в усреднении химсостава.
Если в чугуне серы больше относительно требуемых пределов, то он едет на установку десульфурации (УДЧ), где добавляют реагенты для её удаления. Если меньше, то чугун поступает в конвертеры, где к нему добавляют лом из скрапного отделения, шлакообразующие материалы и ферросплавы. Затем мы измеряем окисленность и температуру, а также отделяем зёрна от плевел.
В смысле разделяем сталь и шлак.
Шлак уезжает на шлаковый двор. А сталь переливается в стальковши, которые затем обрабатываются на агрегатах внепечной обработки в зависимости от исходных характеристик сырья и типа необходимой на выходе стали. Какой-то ковш пройдёт через два этапа внепечной обработки, а потом уедет на установку непрерывной разливки стали. Кому-то нужно побывать на одном агрегате и после него сразу отправиться на разливку, а кому-то — пройти через несколько разных.
Завершающий этап — установка непрерывной разливки, где металл проходит через кристаллизатор и зону вторичного охлаждения, превращаясь в аккуратный сляб.
Оптимальная работа УНРС — когда следующая плавка запускается сразу после завершения предыдущей. Увеличить скорость разливки, чтобы нивелировать задержки в подаче, мы не можем: это нарушит технологию и приведёт к браку.
Наше самое узкое место — подача ковшей с миксера в конвертерное отделение. Конвертеры могут обрабатывать больше плавок, но миксер за ними не успевает, особенно при работе с какими-нибудь трудоёмкими марками стали, например, анизотропными или электротехническими, которые требуют обязательной обработки на УДЧ. К тому же путь из миксерного отделения в конвертерное всего один, поэтому тепловоз должен быть постоянно в нужном месте.
Качество конечного продукта очень зависит от времени выдержки, которое складывается из ожидания обработки, самой обработки на всех наших агрегатах и перемещения стальковша по цеху. Если плавка будет ехать слишком долго, то она остынет больше, чем нужно, и хороший сляб уже не получится.
Слив стали в стальковш
Чтобы спланировать работу цеха, нужно заранее получить задание по выплавке и разливке, а также знать, какие ограничения есть на каждом агрегате. Плавки запускаются в зависимости от доступности оборудования, текущей загруженности и требуемого химсостава стали. Стальковши при этом периодически меняются: часть работает, а часть отправляется на ремонт или замену футеровки, за состоянием которой вообще нужно следить особенно внимательно.
Организацией производства и взаимодействием с доменным и копровым цехами занимаются два человека: диспетчер и начальник смены. Они следят за тем, чтобы строго выполнялась технологическая инструкция, графикуют плавки и ведут каждую из них через все процессы, которые происходят в цеху. Диспетчер координирует работу из диспетчерской, а начальник смены периодически выходит в цех, чтобы контролировать ситуацию на месте.
По большому счёту, до внедрения системы диспетчеризации наша работа шла примерно так же, но без визуализации и цифровых решений. Камеры у нас уже были — около 20 штук на ключевых участках, но полностью цех они не покрывали. Статус плавки уточняли по радиосвязи, данные обрабатывали вручную.
Камер было пять. Аналоговых. В диспетчерской стояли два больших телевизора: один показывал конвертерное отделение, второй — отделение непрерывной разливки стали. Получить какую-то дополнительную информацию можно было только по телефону или по внутренней связи. Например, чтобы узнать, где находится сталевоз, и выяснить, какие ему были даны команды (передаёт он ковш в плавку, допустим, или забирает горелое), приходилось обзванивать бригадиров, мастеров и самого машиниста.
Ещё был видеоархив. Собственно, он и сейчас есть. Полноценный сервис, можно отсмотреть записи с видеокамер производственных процессов за любой необходимый период. Раньше он был обособлен, а сейчас интегрирован в систему диспетчеризации, и им активно пользуются для отслеживания объектов на производственной площадке.
В общем, работать было можно, но не очень удобно.
Главные минусы нашего прежнего мироустройства были такими:
В тандеме с диспетчерами и начальником цеха мы решили переработать подход к управлению и контролю.
Первым делом мы спроектировали всю систему целиком и нарисовали, что, где и как должно быть расположено исходя из нашего чувства прекрасного. В каком формате и с какими компонентами. Чтобы даже новому диспетчеру без опыта всё было интуитивно понятно. С этим эскизом мы пришли к дизайнерской команде, которая воплотила нашу задумку. Мнемосхему разметили в метрах строго по чертежам цеха, чтобы позиционирование было максимально точным.
Потом вместе с архитекторами разработали спецификации сервисов, интеграций и их взаимодействие с уже существующими системами. Ну и, конечно, согласовывали техническую документацию.
Разные части участков мы раскрасили в разные цвета.
Карта слежения
Сделали карту слежения (это такой сервис позиционирования) и саму мнемосхему объектов.
Подключили к ним «умное» зрение (это как раз нейросети), а также сервисы сбора и процессинга run-time-данных. Потом начали вешать камеры везде, где только можно, и выводить их на наши мониторы. Количество камер подросло с пяти до 150. На текущий момент их 226. Они стали выполнять разные задачи — от видеоаналитики до распознавания и позиционирования объектов, чтобы понимать, где какой ковш находится относительно цеха по координатам и что с ним происходит прямо сейчас. Докеры с моделями и нейросетками у нас, кстати, развёрнуты на тех же серверах и виртуальных машинах, на которых работают камеры для видеослежения.
RFID-метки и данные с камер агрегировали через нейросети, чтобы на выходе получить координатную позицию и номер объекта. А полученные сигналы отработали и визуализировали.
В итоге мы добились того, что частота обновления данных у нас теперь меньше секунды, а любое перемещение, даже всего на полметра, фиксируется системой. При этом логика у каждого объекта своя. Например, ковши приезжают и уезжают, а лотки спокойно стоят, пока их не заберут.
Для каждого объекта, атрибута или события мы разработали объектную модель (MDM), присвоили ей уникальный (в рамках справочника) идентификатор MDM-ID. Модель передаёт сигнал на конечный этап, обеспечивает его корректную передачу и точность данных на физическом уровне архитектуры. Объектные модели, MDM-справочники и НСИ, то есть нормативно-справочная информация, взаимодействуют друг с другом, чтобы мы могли сформировать правильный формат обмена данными.
Сложнее всего было собрать данные и правильно интегрировать всё это великолепие на схему: разные сигналы приходят с разными задержками. Всё это нужно консолидировать и проверить, чтобы всё билось с реальностью. Например, чтобы кран мог поднять ковш, они должны совпадать по координатам. Свести их воедино не так-то просто.
Выяснилось, что тех 500–600 сигналов, которые были в нашем распоряжении вначале, для корректного отображения агрегатов не хватает, а позиции, которые они нам показывают, не всегда совпадают с реальностью. Поэтому мы начали искать дополнительные сигналы для всего вокруг: движения, наклона, процессов обработки и так далее. Что характерно, все они уже существовали, просто не были учтены в каталоге. Мы дошли до 1 300 сигналов и всё ещё продолжаем их добавлять.
Мы разработали архитектуру системы позиционирования, продумали авторизацию, аутентификацию и ролевые модели, регулирующие доступ к данным.
Слив стали с конвертера
У нас большой цех, и есть отделения, которые работают исключительно за счёт видеоаналитики по данным с камер. Другие ориентируются на сигналы второго уровня. А есть те, что включают в себя все имеющиеся источники. По каждой из реализаций видеоаналитики нужно было подготовить все виды архитектурных и инфраструктурных схем, согласовать все спецификации и проектную документацию.
Дальше мы настроили взаимосвязь между уровнями. Наша мнемосхема реализована на третьем уровне. Данные, которые помогают отслеживать те или иные объекты, «живут» на втором — там находится оперативная диспетчерская система, ею пользуются некоторые отделения. Мы можем вытащить на третий уровень все необходимые данные, которых у нас раньше не было. Но делать это надо вручную: если что-то тихо и незаметно появится на втором уровне, то к нам на третий оно автоматом не прикатится (а как мы это делаем, расскажу чуть позже). То есть мы подвязаны на конкретный объём данных.
Заработало всё не сразу. Например, на этапе отладки часто зависали камеры, тогда из диспетчерской нам звонили и просили что-нибудь с этим сделать. Сейчас сбои случаются редко, а интерфейс даёт легко определить, какая именно камера зависла, передать это в саппорт, и в течение буквально получаса её включают обратно.
Работоспособность системы тестировали по отделениям. Мы знаем, какие данные нужны для каждого из них, чтобы всё заработало корректно. Мы вручную проверяли все используемые сигналы для каждой визуализации с помощью специального инструмента, визуализирующего синхронность приходящих сигналов. Он позволяет по временным меткам отследить все входящие данные.
Разработанный сервис мониторинга данных из смежных систем
Здесь можно почитать, как всё устроено у коллег из КЦ-2. А вот тут мы подробно писали про оцифровку завода и графикователи.
Допустим, приходит главный специалист цеха и говорит, что появился новый кран с весами (и датчики на них уже стоят). ОК, теперь мне нужно добавить на мнемосхему весы и кран.
У нас есть каталог данных, в котором присутствуют сигналы агрегатного уровня. Я прихожу к коллегам из АСУ ТП, которые занимаются этими сигналами, описываю нужный, и они проверяют по каталогу, существует ли он вообще.
Если нет, то нужно проверить, установлен ли контроллер, с которого можно собрать необходимые данные. Это задача для коллег из АСУ ТП. Если контроллер не установлен, то его нужно купить, установить и настроить для передачи данных, а также провести предварительный анализ по размещению на объекте. После отладки данные нужно передать на второй уровень системы для дальнейшего использования в сервисе.
Если он есть, то ребята отправляют его в топик, а я проверяю по логам, камерам и операциям на втором уровне, что происходит в цеху. Анализирую, в какой момент и какие данные я должна использовать, когда приходят сигналы и какой они продолжительности. Проверяю, есть ли задержка: это важно, потому что задержка даже в одну секунду недопустима.
Если сигнал подходит, то я завожу его в систему ручками, обновляю объектную модель, задаю атрибуты, если они нужны. После этого мы обрабатываем сигнал в смежном сервисе, передаём его в систему слежения, устанавливаем на карту и прописываем логику работы. Либо он агрегируется с другими сигналами, либо это новая функция, которая будет отдавать какую-то новую позицию, либо он пойдёт в текущую логику и будет обработан так же, как и предыдущие сигналы, просто дополняя их.
Объектная модель передаёт данные в брокер сообщений, а я, вычитывая топик, вижу, что в логах появилось что-то новенькое. Там же, в сервисе, автоматически формируется значение, которое улетает наверх в конечный сервис.
Дальше я передаю задачу разработчику, а после него — тестировщику, который проверяет, как всё работает, лучше стало или хуже и получилось ли вообще осуществить задуманное.
На въезде в каждое отделение установлены считыватели, а на ковши прикреплены RFID-метки, которые они идентифицируют. Кроме того, ковши распознаются некоторыми камерами с помощью нейросети.
В некоторых местах, например, в миксерах, производятся контрольные замеры температуры и текущего тоннажа металла. Уточнить их помогает сама модель миксера, которую мы реализовали. Нейросеть получает данные из RFID и обрабатывает кадры с определённых камер. Она обучена определять номера по конкретным зонам, а потом собирает эти данные и выдаёт на выходе номер ковша и его координатную позицию относительно цеха в метрах. Ещё мы обучили модель прогнозировать химический состав чугуна в миксере. Как только чугун из миксера переливается в ЧЗК, модель пересчитывает объём слитого и обновляет показатели.
За другими агрегатами мы следим с помощью других источников сигналов.
Например, мы знаем, что разливка стали идёт с фиксированной скоростью: 0,4 или 0,8 метра в минуту. Стальковш ставится на агрегат, под стальковшом есть промковш, потом — кристаллизатор, затем — ручьи, из которых получается сляб. Когда стальковш ставят на установку, у него открывается шибер (он же — клапан), который сделан для того, чтобы поворотные стенды поворачивались и была непрерывная разливка. У нас в системе есть показатели открытого и закрытого. Когда он меняет своё положение, мы получаем сигнал и дальше уже можем с этим что-то делать.
Мы, в принципе, много о чём получаем сигнал
Сейчас диспетчерская работает так: на большую стену выведены изображения с камер по участкам.
Контроль за процессами, происходящими на участках, со стороны диспетчера
В любой момент можно выбрать нужную камеру и увидеть, что происходит в режиме реального времени.
В то же время всегда можно посмотреть на мнемосхеме подробности о состоянии плавки, количестве извести или сорте лома в определённом лотке.
Можно параллельно открыть несколько камер и мнемосхему — всё сразу
Полные лотки с ломом отображаются оранжевым цветом, а полные ковши — жёлтым. Пустые лотки и ковши становятся серыми. Если мы, например, кликнем на условный 54-й ковш, то увидим номер выпуска и номер печи, из которой в него налили чугун. А ещё — данные о температуре и химсоставе, которые приходят из лаборатории доменного цеха.
При выходе химии или температуры за определенные пределы появляется уведомление об информации. Мы составили список триггеров, и при выходе за определённые пределы подсвечиваются конкретные стальковш и плавка, которые сейчас не ОК.
Также мы хотим настроить сервис так, чтобы они уходили на почту заинтересованным лицам.
Но если какие-то характеристики выходят за нормы, то это всё равно быстро становится известно
Всё, что происходит в цеху, можно посмотреть в режиме реального времени благодаря интеграции с сервисами обмена и производственных операций. По каждому объекту можно отслеживать загруженность, временные промежутки, временные обороты, количество приезжающих ковшей, операций и другие важные события. Если где-то есть сложности, то можно вызвать мастеров и бригадира и дать им ценные указания.
Аналитическая страница загруженности агрегатов (на интерфейсе используются произвольные данные)
Кроме того, диспетчер в режиме нон-стоп контролирует самые узкие места: налив миксера и подачу чугунозаливочных ковшей в конвертерное отделение. Камеры, которые на них направлены, открыты на большой панели постоянно.
Примерно вот так
Видеоархив стал частью единой системы данных. Теперь информация по всем интересующим нас объектам стекается в хранилище, и по ней автоматически формируются дашборды. Написанные один раз скрипты дают возможность просматривать графики и значения за любой период начиная с момента выхода сервиса в опытную промышленную эксплуатацию. Мы можем в любой момент проанализировать технологические, операционные и бизнес-метрики. Например, разобраться, сколько времени занимало перемещение тепловоза между миксерным и конвертерным отделениями в конкретный день. Если ковши проходят через агрегат для снижения серы, то это примерно 18 минут, а если они из миксера отправляются сразу в конвертер — 16 минут. Если время не совпадает, то можно проанализировать, где и почему произошла задержка. В будущем это позволит лучше планировать время тепловоза.
Цикл тепловоза
Мы не так давно используем сервис, но уже понятно, что он помогает уменьшить простои и лучше управлять узкими местами, например, переливом чугуна в миксер, работой установки непрерывной разливки металла или перемещением тепловоза.
Например, цикл разливки металла — 150 тонн. Минимальная скорость разливки на криволинейных установках — 0,8 метра в минуту. Если увеличить скорость до 1,1 метра в минуту, то это сократит время разливки одной плавки с 35 до 30 минут. То есть при непрерывном процессе за 12-часовую смену можно сделать бонусную плавку. Но для того, чтобы бригадир увеличил скорость, нужна аргументация. С камерами и визуализацией процессов аргументы стали весомее.
Раньше, если происходила поломка, мы не могли сразу понять, что случилось: нужно было дождаться вердикта бригадира и мастера. Например, если скорость разливки становилась нулевой, мы не знали, сломался ли стопор или остыл металл. Теперь благодаря камерам можно сразу увидеть, что происходит, быстро понять причину проблемы и принять меры: остановить серию, вызвать нужного специалиста или подготовить оборудование.
А ещё мы часто теряли время при перевозке чугуна из миксерного отделения в конвертерное. Когда тепловоз приезжал, чугун начинали лить не сразу, потому что нужно было завершить другие операции, например, слив ковша в миксер. Сейчас местоположение тепловоза выводится в цех, и как только он двигается в сторону миксерного отделения, бригада сразу готовится наливать чугун.
Процесс усовершенствования мнемосхемы идёт в режиме нон-стоп. В цеху постоянно что-то меняется: какие-то агрегаты уходят на капремонт, какие-то возвращаются, плюс мы периодически устанавливаем новые датчики и считыватели.
А ещё у нас есть планировщик, который автоматически рассчитывает задание для цеха. Если соединить эти два сервиса, то будет огонь.
Но об этом — в следующей серии.
На каждом участке есть ответственные люди и механизмы.
За всем присматривают диспетчер и начальник смены, которые «играют» с этим в Satisfactory.
Раньше у них были телефон, два больших телевизора и пять аналоговых камер.
Теперь камер — 150, они с CV-детекторами событий и «тупыми» эвристическими детекторами отклонений, есть полноценные мнемосхемы с телеметрией с каждого узла, включающие в себя ML-модели, и всё это всё больше напоминает сложную компьютерную игру.
Сейчас я расскажу, как мы меняли интерфейс диспетчера, чтобы он мог рулить цехом.
Как всё устроено
Дисплей в диспетчерской
Тут надо сразу сказать, что диспетчеризация — это не планировщик операций. Она не управляет процессами, а показывает запланированные и фактические маршруты плавки, отслеживает всё — от поворота конвертеров до перемещения ковшей между агрегатами, агрегирует нужные рекомендации, например, прогнозируемый химический анализ чугуна в миксере, рассчитанный с помощью ML-модели и проекта заказа шихтовки. А ещё собирает аналитику и видеоархив с каждой камеры, прикрученной к цеху.
Визуальный контроль ковшей
То есть это сервис, который обеспечивает визуальный контроль, мониторинг и дальнейший разбор аналитики, которая требуется для отслеживания ключевых метрик, например, температуры выпуска металла с конвертера, уровня угара и состояния футеровки.
Система состоит из нескольких частей:
- Первая часть — это сама мнемосхема, которая объединяет данные, сопоставляет их с метками, фиксирует события, отправляет уведомления диспетчеру, если показатели выходят за норму. На ней визуализируется всё, что происходит в цеху: расположение объектов, время выдержки металла, химический состав содержимого ковшей, необходимые технологические параметры.
То есть все необходимые характеристики
- Вторая часть — мозаика, на которой собраны изображения со всех камер, установленных в цеху. Если нужно найти определённый ковш или плавку, то можно прокликать вкладки и быстро определить, где и в каком состоянии они пребывают.
Наблюдение и контроль за ковшами
- Третья часть — видеоархив, в котором собрана информация со всех камер цеха. В любой момент можно его поднять и проверить, что происходило с ковшом или отдельным участком в конкретные день и время. Это бывает нужно при разборе инцидентов. Данные в архиве отсортированы по датам, камерам и временным промежуткам.
Архив камер
Что представляет собой КЦ-1
Первый конвертерный цех занимается тем, что 24 часа в сутки семь дней в неделю на четырёх установках непрерывной разливки делает большие слябы. Для этого используются три конвертера, пять установок доводки металла, на которых в сталь всыпают необходимые (с учётом рекомендаций системы отдачи ферросплавов) для каждой конкретной марки добавки. А ещё — две печи-ковша для подогрева металла до нужной температуры и одна установка циркуляционного вакуумирования.
Цикл конвертера, завалка/заливка
Из доменного цеха к нам, в миксерное отделение, приезжают ковши с расплавленным чугуном. Первым делом нужно определить химический состав содержимого. Дальше чугун переливается в чугунозаливочные ковши (ЧЗК), которые примерно в три раза больше. Сделать это нужно определённым образом: либо напрямую, либо через миксер. Суть переливов — в усреднении химсостава.
Если в чугуне серы больше относительно требуемых пределов, то он едет на установку десульфурации (УДЧ), где добавляют реагенты для её удаления. Если меньше, то чугун поступает в конвертеры, где к нему добавляют лом из скрапного отделения, шлакообразующие материалы и ферросплавы. Затем мы измеряем окисленность и температуру, а также отделяем зёрна от плевел.
В смысле разделяем сталь и шлак.
Шлак уезжает на шлаковый двор. А сталь переливается в стальковши, которые затем обрабатываются на агрегатах внепечной обработки в зависимости от исходных характеристик сырья и типа необходимой на выходе стали. Какой-то ковш пройдёт через два этапа внепечной обработки, а потом уедет на установку непрерывной разливки стали. Кому-то нужно побывать на одном агрегате и после него сразу отправиться на разливку, а кому-то — пройти через несколько разных.
Завершающий этап — установка непрерывной разливки, где металл проходит через кристаллизатор и зону вторичного охлаждения, превращаясь в аккуратный сляб.
Оптимальная работа УНРС — когда следующая плавка запускается сразу после завершения предыдущей. Увеличить скорость разливки, чтобы нивелировать задержки в подаче, мы не можем: это нарушит технологию и приведёт к браку.
Наше самое узкое место — подача ковшей с миксера в конвертерное отделение. Конвертеры могут обрабатывать больше плавок, но миксер за ними не успевает, особенно при работе с какими-нибудь трудоёмкими марками стали, например, анизотропными или электротехническими, которые требуют обязательной обработки на УДЧ. К тому же путь из миксерного отделения в конвертерное всего один, поэтому тепловоз должен быть постоянно в нужном месте.
Качество конечного продукта очень зависит от времени выдержки, которое складывается из ожидания обработки, самой обработки на всех наших агрегатах и перемещения стальковша по цеху. Если плавка будет ехать слишком долго, то она остынет больше, чем нужно, и хороший сляб уже не получится.
Слив стали в стальковш
Чтобы спланировать работу цеха, нужно заранее получить задание по выплавке и разливке, а также знать, какие ограничения есть на каждом агрегате. Плавки запускаются в зависимости от доступности оборудования, текущей загруженности и требуемого химсостава стали. Стальковши при этом периодически меняются: часть работает, а часть отправляется на ремонт или замену футеровки, за состоянием которой вообще нужно следить особенно внимательно.
Организацией производства и взаимодействием с доменным и копровым цехами занимаются два человека: диспетчер и начальник смены. Они следят за тем, чтобы строго выполнялась технологическая инструкция, графикуют плавки и ведут каждую из них через все процессы, которые происходят в цеху. Диспетчер координирует работу из диспетчерской, а начальник смены периодически выходит в цех, чтобы контролировать ситуацию на месте.
Нам явно не хватало визуального контроля
По большому счёту, до внедрения системы диспетчеризации наша работа шла примерно так же, но без визуализации и цифровых решений. Камеры у нас уже были — около 20 штук на ключевых участках, но полностью цех они не покрывали. Статус плавки уточняли по радиосвязи, данные обрабатывали вручную.
Камер было пять. Аналоговых. В диспетчерской стояли два больших телевизора: один показывал конвертерное отделение, второй — отделение непрерывной разливки стали. Получить какую-то дополнительную информацию можно было только по телефону или по внутренней связи. Например, чтобы узнать, где находится сталевоз, и выяснить, какие ему были даны команды (передаёт он ковш в плавку, допустим, или забирает горелое), приходилось обзванивать бригадиров, мастеров и самого машиниста.
Ещё был видеоархив. Собственно, он и сейчас есть. Полноценный сервис, можно отсмотреть записи с видеокамер производственных процессов за любой необходимый период. Раньше он был обособлен, а сейчас интегрирован в систему диспетчеризации, и им активно пользуются для отслеживания объектов на производственной площадке.
В общем, работать было можно, но не очень удобно.
Главные минусы нашего прежнего мироустройства были такими:
- Во-первых, нам не хватало чёткого контроля за перемещением ковшей и маршрутизацией плавок.
- Во-вторых, наше планирование явно не учитывало всех нюансов. То есть косяки с увеличением времени выдержки случались с завидной периодичностью. Возвращать плавку в печь или делать химподогрев на внепечном агрегате довольно неприятно: состав при этом безнадёжно портится, и пустить такие ковши на высокотехнологичные марки стали мы уже не можем.
Нужно было что-то менять
В тандеме с диспетчерами и начальником цеха мы решили переработать подход к управлению и контролю.
Первым делом мы спроектировали всю систему целиком и нарисовали, что, где и как должно быть расположено исходя из нашего чувства прекрасного. В каком формате и с какими компонентами. Чтобы даже новому диспетчеру без опыта всё было интуитивно понятно. С этим эскизом мы пришли к дизайнерской команде, которая воплотила нашу задумку. Мнемосхему разметили в метрах строго по чертежам цеха, чтобы позиционирование было максимально точным.
Потом вместе с архитекторами разработали спецификации сервисов, интеграций и их взаимодействие с уже существующими системами. Ну и, конечно, согласовывали техническую документацию.
Разные части участков мы раскрасили в разные цвета.
Карта слежения
Сделали карту слежения (это такой сервис позиционирования) и саму мнемосхему объектов.
Подключили к ним «умное» зрение (это как раз нейросети), а также сервисы сбора и процессинга run-time-данных. Потом начали вешать камеры везде, где только можно, и выводить их на наши мониторы. Количество камер подросло с пяти до 150. На текущий момент их 226. Они стали выполнять разные задачи — от видеоаналитики до распознавания и позиционирования объектов, чтобы понимать, где какой ковш находится относительно цеха по координатам и что с ним происходит прямо сейчас. Докеры с моделями и нейросетками у нас, кстати, развёрнуты на тех же серверах и виртуальных машинах, на которых работают камеры для видеослежения.
RFID-метки и данные с камер агрегировали через нейросети, чтобы на выходе получить координатную позицию и номер объекта. А полученные сигналы отработали и визуализировали.
В итоге мы добились того, что частота обновления данных у нас теперь меньше секунды, а любое перемещение, даже всего на полметра, фиксируется системой. При этом логика у каждого объекта своя. Например, ковши приезжают и уезжают, а лотки спокойно стоят, пока их не заберут.
Для каждого объекта, атрибута или события мы разработали объектную модель (MDM), присвоили ей уникальный (в рамках справочника) идентификатор MDM-ID. Модель передаёт сигнал на конечный этап, обеспечивает его корректную передачу и точность данных на физическом уровне архитектуры. Объектные модели, MDM-справочники и НСИ, то есть нормативно-справочная информация, взаимодействуют друг с другом, чтобы мы могли сформировать правильный формат обмена данными.
Сложнее всего было собрать данные и правильно интегрировать всё это великолепие на схему: разные сигналы приходят с разными задержками. Всё это нужно консолидировать и проверить, чтобы всё билось с реальностью. Например, чтобы кран мог поднять ковш, они должны совпадать по координатам. Свести их воедино не так-то просто.
Выяснилось, что тех 500–600 сигналов, которые были в нашем распоряжении вначале, для корректного отображения агрегатов не хватает, а позиции, которые они нам показывают, не всегда совпадают с реальностью. Поэтому мы начали искать дополнительные сигналы для всего вокруг: движения, наклона, процессов обработки и так далее. Что характерно, все они уже существовали, просто не были учтены в каталоге. Мы дошли до 1 300 сигналов и всё ещё продолжаем их добавлять.
Мы разработали архитектуру системы позиционирования, продумали авторизацию, аутентификацию и ролевые модели, регулирующие доступ к данным.
Слив стали с конвертера
У нас большой цех, и есть отделения, которые работают исключительно за счёт видеоаналитики по данным с камер. Другие ориентируются на сигналы второго уровня. А есть те, что включают в себя все имеющиеся источники. По каждой из реализаций видеоаналитики нужно было подготовить все виды архитектурных и инфраструктурных схем, согласовать все спецификации и проектную документацию.
Дальше мы настроили взаимосвязь между уровнями. Наша мнемосхема реализована на третьем уровне. Данные, которые помогают отслеживать те или иные объекты, «живут» на втором — там находится оперативная диспетчерская система, ею пользуются некоторые отделения. Мы можем вытащить на третий уровень все необходимые данные, которых у нас раньше не было. Но делать это надо вручную: если что-то тихо и незаметно появится на втором уровне, то к нам на третий оно автоматом не прикатится (а как мы это делаем, расскажу чуть позже). То есть мы подвязаны на конкретный объём данных.
Заработало всё не сразу. Например, на этапе отладки часто зависали камеры, тогда из диспетчерской нам звонили и просили что-нибудь с этим сделать. Сейчас сбои случаются редко, а интерфейс даёт легко определить, какая именно камера зависла, передать это в саппорт, и в течение буквально получаса её включают обратно.
Работоспособность системы тестировали по отделениям. Мы знаем, какие данные нужны для каждого из них, чтобы всё заработало корректно. Мы вручную проверяли все используемые сигналы для каждой визуализации с помощью специального инструмента, визуализирующего синхронность приходящих сигналов. Он позволяет по временным меткам отследить все входящие данные.
Разработанный сервис мониторинга данных из смежных систем
Здесь можно почитать, как всё устроено у коллег из КЦ-2. А вот тут мы подробно писали про оцифровку завода и графикователи.
Что если понадобится новый сигнал?
Допустим, приходит главный специалист цеха и говорит, что появился новый кран с весами (и датчики на них уже стоят). ОК, теперь мне нужно добавить на мнемосхему весы и кран.
У нас есть каталог данных, в котором присутствуют сигналы агрегатного уровня. Я прихожу к коллегам из АСУ ТП, которые занимаются этими сигналами, описываю нужный, и они проверяют по каталогу, существует ли он вообще.
Если нет, то нужно проверить, установлен ли контроллер, с которого можно собрать необходимые данные. Это задача для коллег из АСУ ТП. Если контроллер не установлен, то его нужно купить, установить и настроить для передачи данных, а также провести предварительный анализ по размещению на объекте. После отладки данные нужно передать на второй уровень системы для дальнейшего использования в сервисе.
Если он есть, то ребята отправляют его в топик, а я проверяю по логам, камерам и операциям на втором уровне, что происходит в цеху. Анализирую, в какой момент и какие данные я должна использовать, когда приходят сигналы и какой они продолжительности. Проверяю, есть ли задержка: это важно, потому что задержка даже в одну секунду недопустима.
Если сигнал подходит, то я завожу его в систему ручками, обновляю объектную модель, задаю атрибуты, если они нужны. После этого мы обрабатываем сигнал в смежном сервисе, передаём его в систему слежения, устанавливаем на карту и прописываем логику работы. Либо он агрегируется с другими сигналами, либо это новая функция, которая будет отдавать какую-то новую позицию, либо он пойдёт в текущую логику и будет обработан так же, как и предыдущие сигналы, просто дополняя их.
Объектная модель передаёт данные в брокер сообщений, а я, вычитывая топик, вижу, что в логах появилось что-то новенькое. Там же, в сервисе, автоматически формируется значение, которое улетает наверх в конечный сервис.
Дальше я передаю задачу разработчику, а после него — тестировщику, который проверяет, как всё работает, лучше стало или хуже и получилось ли вообще осуществить задуманное.
Работает это всё примерно так
На въезде в каждое отделение установлены считыватели, а на ковши прикреплены RFID-метки, которые они идентифицируют. Кроме того, ковши распознаются некоторыми камерами с помощью нейросети.
В некоторых местах, например, в миксерах, производятся контрольные замеры температуры и текущего тоннажа металла. Уточнить их помогает сама модель миксера, которую мы реализовали. Нейросеть получает данные из RFID и обрабатывает кадры с определённых камер. Она обучена определять номера по конкретным зонам, а потом собирает эти данные и выдаёт на выходе номер ковша и его координатную позицию относительно цеха в метрах. Ещё мы обучили модель прогнозировать химический состав чугуна в миксере. Как только чугун из миксера переливается в ЧЗК, модель пересчитывает объём слитого и обновляет показатели.
За другими агрегатами мы следим с помощью других источников сигналов.
Например, мы знаем, что разливка стали идёт с фиксированной скоростью: 0,4 или 0,8 метра в минуту. Стальковш ставится на агрегат, под стальковшом есть промковш, потом — кристаллизатор, затем — ручьи, из которых получается сляб. Когда стальковш ставят на установку, у него открывается шибер (он же — клапан), который сделан для того, чтобы поворотные стенды поворачивались и была непрерывная разливка. У нас в системе есть показатели открытого и закрытого. Когда он меняет своё положение, мы получаем сигнал и дальше уже можем с этим что-то делать.
Мы, в принципе, много о чём получаем сигнал
Что изменилось для диспетчера
Сейчас диспетчерская работает так: на большую стену выведены изображения с камер по участкам.
Контроль за процессами, происходящими на участках, со стороны диспетчера
В любой момент можно выбрать нужную камеру и увидеть, что происходит в режиме реального времени.
В то же время всегда можно посмотреть на мнемосхеме подробности о состоянии плавки, количестве извести или сорте лома в определённом лотке.
Можно параллельно открыть несколько камер и мнемосхему — всё сразу
Полные лотки с ломом отображаются оранжевым цветом, а полные ковши — жёлтым. Пустые лотки и ковши становятся серыми. Если мы, например, кликнем на условный 54-й ковш, то увидим номер выпуска и номер печи, из которой в него налили чугун. А ещё — данные о температуре и химсоставе, которые приходят из лаборатории доменного цеха.
При выходе химии или температуры за определенные пределы появляется уведомление об информации. Мы составили список триггеров, и при выходе за определённые пределы подсвечиваются конкретные стальковш и плавка, которые сейчас не ОК.
Также мы хотим настроить сервис так, чтобы они уходили на почту заинтересованным лицам.
Но если какие-то характеристики выходят за нормы, то это всё равно быстро становится известно
Всё, что происходит в цеху, можно посмотреть в режиме реального времени благодаря интеграции с сервисами обмена и производственных операций. По каждому объекту можно отслеживать загруженность, временные промежутки, временные обороты, количество приезжающих ковшей, операций и другие важные события. Если где-то есть сложности, то можно вызвать мастеров и бригадира и дать им ценные указания.
Аналитическая страница загруженности агрегатов (на интерфейсе используются произвольные данные)
Кроме того, диспетчер в режиме нон-стоп контролирует самые узкие места: налив миксера и подачу чугунозаливочных ковшей в конвертерное отделение. Камеры, которые на них направлены, открыты на большой панели постоянно.
Примерно вот так
Видеоархив стал частью единой системы данных. Теперь информация по всем интересующим нас объектам стекается в хранилище, и по ней автоматически формируются дашборды. Написанные один раз скрипты дают возможность просматривать графики и значения за любой период начиная с момента выхода сервиса в опытную промышленную эксплуатацию. Мы можем в любой момент проанализировать технологические, операционные и бизнес-метрики. Например, разобраться, сколько времени занимало перемещение тепловоза между миксерным и конвертерным отделениями в конкретный день. Если ковши проходят через агрегат для снижения серы, то это примерно 18 минут, а если они из миксера отправляются сразу в конвертер — 16 минут. Если время не совпадает, то можно проанализировать, где и почему произошла задержка. В будущем это позволит лучше планировать время тепловоза.
Цикл тепловоза
Мы не так давно используем сервис, но уже понятно, что он помогает уменьшить простои и лучше управлять узкими местами, например, переливом чугуна в миксер, работой установки непрерывной разливки металла или перемещением тепловоза.
Например, цикл разливки металла — 150 тонн. Минимальная скорость разливки на криволинейных установках — 0,8 метра в минуту. Если увеличить скорость до 1,1 метра в минуту, то это сократит время разливки одной плавки с 35 до 30 минут. То есть при непрерывном процессе за 12-часовую смену можно сделать бонусную плавку. Но для того, чтобы бригадир увеличил скорость, нужна аргументация. С камерами и визуализацией процессов аргументы стали весомее.
Раньше, если происходила поломка, мы не могли сразу понять, что случилось: нужно было дождаться вердикта бригадира и мастера. Например, если скорость разливки становилась нулевой, мы не знали, сломался ли стопор или остыл металл. Теперь благодаря камерам можно сразу увидеть, что происходит, быстро понять причину проблемы и принять меры: остановить серию, вызвать нужного специалиста или подготовить оборудование.
А ещё мы часто теряли время при перевозке чугуна из миксерного отделения в конвертерное. Когда тепловоз приезжал, чугун начинали лить не сразу, потому что нужно было завершить другие операции, например, слив ковша в миксер. Сейчас местоположение тепловоза выводится в цех, и как только он двигается в сторону миксерного отделения, бригада сразу готовится наливать чугун.
Совершенству, конечно, нет предела
Процесс усовершенствования мнемосхемы идёт в режиме нон-стоп. В цеху постоянно что-то меняется: какие-то агрегаты уходят на капремонт, какие-то возвращаются, плюс мы периодически устанавливаем новые датчики и считыватели.
А ещё у нас есть планировщик, который автоматически рассчитывает задание для цеха. Если соединить эти два сервиса, то будет огонь.
Но об этом — в следующей серии.
Комментарии (8)
woodiron
10.06.2025 07:34Когда смотришь на всю эту автоматизацию с сотнями параметров, удивляешься - как же вообще справлялись без неё.
avdonina_mk Автор
10.06.2025 07:34Раньше всё держалось на опыте и интуиции людей — параметры контролировали «на глаз» и «на слух». Теперь автоматизация и прозрачность позволяют точно видеть что происходит и быстрее реагировать на отклонения. Это даёт стабильность, снижает ошибки и повышает безопасность процесса.
woodiron
10.06.2025 07:34А как учитываются люди в опасных зонах - тоже камеры, или какие-либо РФИД метки в касках и т.п.? Или это относится не к производству, а к безопасности?
avdonina_mk Автор
10.06.2025 07:34Безопасность — это особое и важное направление. Для её обеспечения в компании есть отдельные проекты. Если читатели проявят заинтересованность — с удовольствием напишем и про них.
ramil_trinion
То есть просто вычислений бригадиру не хватило? Сомнительно.
Тк все равно люди будут решать что делать дальше и смотреть в камеры.
А просто позвонить и сообщить что в сторону бригады выехали тепловоз нельзя?
Резюмирую: Вы придумали усложнили систему слежения в несколько раз (даже судя по количеству камер) , но не автоматизации. По мне так сомнительное занятие.
Igor_Korablev
По ссылкам в статье есть дополнительный материал.
За сбором сигналов и визуализацией стоит следующий модуль - графикователь (мат модель, советчик, с функцией решения NP сложных задач, разработанный при поддержке кафедры больших данных УРФУ).
Вот этот графикователь в теории автоматизации и может давать и даёт 3-5% производительности, эффективности на том же оборудовании, при том же потреблении ресурсов.
Использование таких графикователей - это общий существующий тренд в металлургии.
AstorS1
Игорь Геннадьевич, чувствуется ваша поддержка и опыт.
Когда начал читать, думал, что вы автор статьи, но нет.
Спасибо за популяризацию ИТ в металлургии!
avdonina_mk Автор
Расчетов реально недостаточно. Бригадир понимает процесс через наблюдение и личный опыт. Просто сказать «увеличь скорость» — это, может, и правильно, но так можно качество на ноль помножить. Камеры дают наглядный контроль за металлом — бригадир видит, что процесс устойчив при большей скорости, и тогда уже даёт добро.
Тут сработает сломанный телефон. Могут забыть, не дозвониться или дать неполную информацию (например, тепловоз уже стоит, а мы в бинокли в другую сторону смотрим). Когда местоположение выводится сразу в цех на экран — это объективная картинка, все участники процесса видят одно и то же в реальном времени. Это снижает простои при наливе чугуна.
Тут суть не в полной автоматизации, а в повышении прозрачности процессов. Камеры — инструмент для снижения задержек и аварий за счет более быстрого принятия решений. Тут не замена людям, плюс к эффективности.