IT & Digital
Компьютерное зрение для определения дефектов, VR/AR в обучении, экзоскелеты для облегчения труда — мы используем технологии, которым необходим качественный рабочий код. У наших IT-специалистов исключительно интересные и продвинутые задачи.
0:26
Цифровая сталь
1700
сотрудников
20
городов, где работает «Северсталь-инфоком»
6,7
млрд рублей — инвестиции в IT и диджитал
Big data управляет заводами
Более двух тысяч команд улучшали нашу нейросеть для поиска дефектов на металле
Как мы организовали соревнование на Kaggle
Severstal deploys AI at Cherepovets steel mill
Severstal has started using a machine learning model to control speed optimisation at the Cherepovets steel mill’s continuous pickling line.
2:34
Система машинного зрения
Causal inference for a steel mill.
How to create a data science product for a steel mill
2:43
Единая система управления инженерными данными в «Российской стали»
Властелины стихии.
Взрывники «Олкона» осваивают I-Blast
«Цифровое сердце» компании.
Платформа нового поколения S/4HANA, которая заменит SAP ERP
37:20
Использование Кафки в стальном производстве
Цифровое сердце компании
5:18
Информационная безопасность: как стать трудной мишенью
Константин Иванов, заместитель начальника управления информационной безопасности
Мария Лорман
Руководитель программы трансформации в ИТ
«Увязать всех коллег вместе и рассказать, что автоматизация должна быть совместной, эффективной — это большой челлендж»
0:55
5:03
Слово эксперту
Интервью с директором «Северсталь Диджитал» Борисом Воскресенским
5:40
Поговорим о цифровых компетенциях
Сергей Дунаев, CIO
Вакансии в IT & Digital
Все города
digital
it
айти
диджитал
Бизнес-аналитик Lean Digital
Воркута
Бизнес-аналитик
Москва
Администратор проекта (стажер)
Череповец
Веб-разработчик (back-end Node.js, front-end React)
Череповец
Старший менеджер по информационной безопасности
Колпино
Старший менеджер по информационной безопасности
Ярославль
Менеджер по организации обучения
Москва
Ведущий эксперт (по автоматизированным системам)
Череповец
Тест-менеджер R2R(МСФО, Налоги, Базовый учет)
Москва
Тест-менеджер на направление IC
Москва
Data Scientist
Москва
Разработчик Computer Vision
Москва
Консультант SAP SD
Москва
Консультант SAP BW
Пермь
Младший специалист SAP APO
Череповец
Специалист (1С)
Череповец
Младший специалист
Новосибирск
Разработчик программного обеспечения
Череповец
Программист-консультант 1С ЗУП КОРП
Ярославль
Разработчик Vue.js
Москва
Консультант SAP FI TRM
Москва
Консультант SAP FI-AP, FI-AR, FI-GL
Москва
Android разработчик
Череповец
Младший специалист SAP APO
Череповец
Разработчик PHP / 1C-Bitrix
Москва
Ведущий Full stack разработчик
Санкт-Петербург
Разработчик баз данных SQL Sybase
Воронеж
DevOps
Воронеж
Консультант SAP BW
Москва
Руководитель группы нагрузочного тестирования
Москва
Бизнес-аналитик
Санкт-Петербург
Консультант SAP HR
Москва
Специалист SAP HCM
Череповец
Ведущий сетевой инженер
Москва
Менеджер по техническому развитию
Череповец
Старший консультант SAP SD
Москва
Директор по продукту, проект "Маркетплейс закупок"
Москва
Системный аналитик (e-com)
Москва
Старший инженер по тестированию
Москва
Специалист по техническому обслуживанию систем неразрушающего контроля
Череповец
Специалист АСУТП
Костомукша
от 70000 ₽
Разработчик MS SQL (BI)
Костомукша
от 69000 ₽
Разработчик Python, c# (IoT, CV, ML, AI)
Костомукша
от 69000 ₽
Бизнес-аналитик (разработчик) BPM'Online (Creatio)
Москва
Full-stack разработчик
Санкт-Петербург
Менеджер по аудиту (информационная безопасность)
Москва
Младший консультант / консультант SAP CO (Контроллинг)
Москва
Ведущий эксперт (по прогнозной аналитике и машинному обучению)
Череповец
Консультант SAP Solution Manager
Москва
Разработчик CUDA C++
Москва
Старший специалист по функциональному тестированию
Воронеж
Сетевой инженер
Белгород
Подземный Инженер АСУТП
Белгород
Разработчик C++
Москва
Консультант SAP (Электронный документооборот)
Воронеж
Data scientist
Москва
Менеджер по консолидированному анализу
Череповец
Разработчик Сomputer Vision
Воронеж
Специалист по автоматизации
Череповец
Менеджер по верхнеуровневой автоматизации
Череповец
Технический архитектор по телекоммуникациям
Череповец
Администратор баз данных Oracle
Череповец
Разработчик JavaScript (удаленный формат)
Воронеж
Hybris-разработчик (удаленный формат)
Москва
Старший специалист SAP HCM
Воронеж
Специалист (разработчик .net)
Череповец
Специалист по сопровождению инфраструктуры обработки данных (DataLake)
Череповец
Тестировщик
Москва
Младший специалист SAP (Электронный документооборот)
Воронеж
Старший специалист функционального тестирования
Воронеж
Младший консультант SAP (Электронный документооборот)
Воронеж
Старший консультант SAP APO
Москва
Администратор Business objects
Череповец
Специалист (JavaScript)
Воронеж
Все вакансии
Центральный ФО
Северо-Западный ФО
Южный ФО
Сибирский ФО
Приволжский ФО

Более двух тысяч команд улучшали нашу нейросеть для поиска дефектов на металле

Как мы организовали соревнование на Kaggle

В чём состояла задача

В производстве листового металла существует одна проблема — иногда на поверхности металла могут образовываться дефекты. Дефекты бывают разных типов в зависимости от причины их возникновения.

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

Плены и трещины на металле

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

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

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

Один из финальных участков производственной линии с готовой продукцией

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

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

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

Основных причин этому три:

  • Дефицит данных. Если датасетов с кошками или собаками в свободном доступе предостаточно, то открытый датасет с дефектами поверхности металла до недавнего времени существовал только один. Этот датасет опубликовал Северо-восточный Университет США в Бостоне. Он включает всего 1800 изображений размером 200х200 пикселей для шести классов дефектов.
  • Сложные условия эксплуатации. Большой поток данных и непрерывность производства предъявляют высокие требования к скорости работы системы компьютерного зрения, что сильно ограничивает выбор моделей.
  • Очень высокие требования к используемым системам в плане качества работы. Система должна находить все дефекты, допуская как можно меньше ложных срабатываний.

Подготовка данных

«Северсталь» совершенствует свои технологические процессы и системы контроля качества. Когда мы решили использовать современные достижения в области компьютерного зрения и улучшить существующую систему детекции дефектов, встал вопрос подготовки обучающего датасета. Качественная обучающая выборка — это, наверное, 50% успеха всего проекта, поэтому мы подошли к этому вопросу с большим вниманием.

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

Уже после первой тренировочной разметки стало понятно, что размечать дефекты — совсем не то же самое, что размечать котиков. Мы столкнулись с несколькими проблемами, которые можно проиллюстрировать следующими изображениями:

Различия в разметке. Разные люди по-разному определяют границы дефектов и их количество
Цветом показан тип, к которому аннотатор отнес данный дефект. Видно, что один и тот же дефект разные аннотаторы относят к разным типам

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

Что же делать в таком случае? Нам нужно было в относительно короткие сроки (два-три месяца) при сильно ограниченных человеческих ресурсах разметить большой датасет. При этом хотелось, чтобы разметка была максимально качественной, и мы были если не на 100%, то хотя бы на 80% уверены в представленных типах дефектов.

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

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

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

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

Поэтому в итоге мы использовали следующий подход. Каждую картинку независимо размечали два аннотатора. Если оказывалось, что в получившихся разметках не совпадают типы дефектов или величина IoU (Intersection over Union) между отдельными инстансами дефектов ниже порогового значения, то такая картинка отправлялась на дополнительную разметку самому опытному из экспертов. После чего на основе трёх полученных разметок мы генерировали финальный, более точный вариант разметки.

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

  • Металл с окалиной.
  • Изображения, на которых видно маркировку.
  • Металл с рифлением.
  • Изображения, где на поверхности металла присутствует грязь или масляные разводы.
  • Сталь разных марок.

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

А вот так могут выглядеть изображения с дефектами:

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

Следующий шаг — baseline-модель

Лучший способ убедиться, что собранные данные позволяют решить вашу задачу, — обучить на них свою модель.

Примерно в середине работы по разметке data science-команда «Северстали» подготовила proof of concept на тех картинках, что уже были размечены. Мы обучили собственную baseline-модель детекции дефектов на основе AlbuNet-34. Двухмесячные пилотные испытания прототипа показали существенное улучшение по точности и полноте детектируемых дефектов по сравнению с исходной системой детекции.

Кроме того, испытания позволили обкатать процесс вывода модели в промышленную эксплуатацию — отладить подключение к источникам данных, проработать архитектуру ПО. Появилась уверенность в том, что мы не только в теории, но и на практике можем улучшить систему детекции дефектов. Нейросеть, запущенная в ЦОДе на сервере с парой GPU, в режиме реального времени детектировала дефекты на поверхности металла, прокатываемого в цехе, расположенном в паре километров от неё.

Итак, модель работает. Работает лучше, чем существующая система инспекции. Но можно ли её улучшить? Если да, то насколько?

Давайте устроим соревнование на Kaggle!

Тем, кто так или иначе связан с data science, не нужно объяснять, почему из всех существующих соревновательных платформ мы выбрали именно Kaggle. Для тех, кто мало знаком с этой темой, скажем, что Kaggle – это не просто сайт с соревнованиями по машинному обучению и анализу данных. Это крупнейшее сообщество, объединяющее специалистов в области data science со всего мира.

Если вы хотите понять, что вообще можно выжать из тех данных, которые у вас есть, то место лучше, чем Kaggle, сложно придумать. Над вашей задачей будут думать тысячи профессионалов. Соревнования на Kaggle устраивали такие компании и организации, как Microsoft, Facebook, CERN и другие. Российских компаний, проводивших свои соревнования по data science, совсем немного. На ум приходят «Авито», «Сбербанк» и «Яндекс». Мы подумали, что будет здорово, если «Северсталь» войдёт в их число.

Короче говоря, вопрос, где проводить соревнование, был решен быстро. Оставался ещё один: как его проводить?

Выбор формата соревнования

Kaggle предлагает много разных опций для организации соревнований. Например, так называемые code competitions, когда участники обязаны использовать только ресурсы самой платформы Kaggle для обучения своих моделей и инференса (вычисления, выполняемые моделью машинного обучения для получения предсказаний на тестовой выборке). Можно, наоборот, никак не ограничивать участников. Оба варианта имеют свои преимущества и недостатки.

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

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

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

С одной стороны, участники не были ограничены в ресурсах и могли обучать свои модели на чём угодно, что потенциально стимулировало использовать «тяжёлые» модели, ансамбли и SOTA-решения (state of the art). С другой, мы всё же требовали, чтобы инференс выполнялся на ресурсах Kaggle. Это позволило скрыть от участников тестовую выборку, немного регулировать итоговую сложность моделей и гарантировало воспроизводимость результатов.

В принципе, с этим форматом соревнования всё хорошо, кроме одного момента. Да, вероятно, мы получим качественное решение, которое великолепно находит дефекты на металле. Но что если этим решением окажется ансамбль из десяти Mask-RCNN (одна из современных архитектур искусственных нейросетей) и кучей TTA (test time augmentations) , который на доступных нам вычислительных мощностях способен обрабатывать одну картинку в секунду?

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

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

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

Мы также решили, что во втором раунде участники будут вольны делать со своими моделями что угодно, даже выставить полностью новую модель, отличную от той, которую они использовали в первом раунде. Но при одном условии — результат модели на тестовой выборке во втором раунде не должен опуститься ниже топ-50. Для оценки производительности моделей во втором раунде мы выбрали средненький для такой задачи компьютер с Core i7, одной GPU 1080Ti и 64 гигабайтами оперативной памяти.

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

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

Как не допустить leak в данных

Data leakage или просто leak (утечка) — одна из главных опасностей при проведении соревнований по data science. Участники всегда скрупулёзно изучают данные на предмет неочевидных закономерностей и подсказок, которые организатор не заметил на этапе подготовки датасета.

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

Так что при подготовке train- и test-сета нам нужно было, с одной стороны, сделать так, чтобы в обеих выборках было одинаковое распределение по дефектам и видам поверхностей металла, а с другой, избежать leak’а. Сделать это было не так-то просто.

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

Приняв всё это во внимание, мы совместно с командой Kaggle внимательно подошли к разбиению данных:

  • Удалили из датасета все дубликаты изображений (правда, несколько дубликатов мы в итоге всё-таки пропустили).
  • Оставшиеся картинки распределили между выборками так, чтобы в тестовой не было картинок с того же рулона, что и в тренировочной.
  • Большую часть тестовой выборки составили изображения, полученные позже по времени. При этом мы постарались сделать так, чтобы в обеих выборках все типы дефектов были одинаково представлены.

Про метрику

С выбором метрики тоже были свои нюансы. На производстве качество системы детекции дефектов оценивают в терминах «перебраковки» и «недобраковки». По смыслу две эти величины связаны с привычными precision и recall как:

Перебраковка = 1 — precision

Недобраковка = 1 — recall

Поэтому изначально для оценки качества решений мы собирались использовать кастомную метрику, комбинирующую precision и recall по всем типам дефектов. Но от этой идеи пришлось отказаться. Создание новой метрики и интеграция её в существующую инфраструктуру потребовали бы от команды Kaggle больших усилий на разработку и тестирование. Кроме того, было сложно предугадать, как может повести себя новая метрика во время соревнования.

Команда Kaggle предложила использовать одну из их стандартных метрик для картиночных соревнований ­— mAP при разных порогах по IoU. Но тут мы столкнулись с забавным багом. Хорошо, что в нашем распоряжении была baseline-модель и мы могли протестировать метрику на прочность.

Данная метрика была написана таким образом, что учитывала фон изображений как отдельный класс. Если в качестве входных данных в функцию расчёта метрики подать наивный прогноз ­— на картинках вообще нет дефектов, — метрика выдавала значение 0,7. Если подать идеальный прогно ­— правильно сегментировать все дефекты на изображениях, — значение метрики становилось равным 1.

На первый взгляд, всё нормально. Но при тестировании метрики на предиктах нашей baseline-модели, которая неплохо сегментирует дефекты, оказалось, что значение метрики равно 0,67. Получается, выгоднее не предсказывать ничего, чем пытаться обнаруживать дефекты.

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

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

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

О результатах

Само соревнование длилось три с половиной месяца: с 26 июля по 13 ноября 2019 года. Участие приняла 2431 команда, что, на наш взгляд, довольно много и говорит о том, что конкурс оказался интересным для сообщества.

Участники быстро смогли побить результат нашей baseline-модели. Как мы и предполагали, команды, занявшие призовые места в первом раунде, использовали ансамбли из нескольких глубоких нейронных сетей.

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

Избежать сильной головной боли при тестировании решений во втором раунде нам помог Docker — участникам предлагалось завернуть свои модели в контейнер. Мы подготовили подробную инструкцию с примером по упаковке модели в контейнер, так что всё, что оставалось сделать командам, — это заменить файлы в примере на собственные. Это минимизировало вероятность того, что присланные командами решения не запустятся или упадут с ошибкой из-за разницы в используемом программном обеспечении.

Подводя итоги, можно сказать, что мы остались очень довольны результатами. Организация и сопровождение соревнования со стороны команды Kaggle была на высоком уровне. Нам удалось избежать типичных для картиночных соревнований проблем, таких как data leakage, и достичь тех двух целей, которые ставили изначально:

  • Оценили, модель какого качества в принципе можно получить на наших данных
  • Решение победителя второго раунда смогли с минимальными доработками интегрировать в производство на заводе в Череповце

Severstal deploys AI at Cherepovets steel mill

Severstal has started using a machine learning model to control speed optimisation at the Cherepovets steel mill’s continuous pickling line
The new system was created by integrating "Adelina", a digital model already in use at the NTA-3 pickling line since November 2019, with "Ruban", a new AI agent.

Ruban uses a "deep - reinforcement learning algorithm" —a relatively new technique in which neural networks learn by trial and error.

Adelina controls the speed of the unit, while Ruban adjusts the speed to achieve optimal results.

"The Adelina model had already met our expectations, demonstrating an initial increase in productivity of NTA-3 by more than 5%. In March 2020, we produced a record volume of pickled metal at this unit - more than 130,000t", said Evgeny Vinogradov, chief executive of Severstal Russian Steel Division.

"After introducing the Ruban agent, we recorded a further 1.5% increase in productivity, and we estimate that using the two technologies in parallel could provide more than 80,000t of additional metal each year. This is a remarkable increase for one of the most significant units in the production of flat rolled products."

The company noted that Ruban differs from classic machine learning models in that it learns not just from historical data, but also exploring the digital twin of NTA-3.

The operating speed at the unit largely depends on the parameters of the passing steel strip - the length, width and thickness of the roll, its steel grade and temperature, among other factors.

"Ruban learns from combinations of different parameters, specifically created for it by a generative adversarial network, which uses two neural networks to generate new data. It also sets a production plan and creates unique situations for training purposes," said the company.

For effective learning, the agent was assigned a training system based on rewards and penalties; Ruban experiments to find a solution where the reward amount surpasses the penalties as far as possible.

Boris Voskresenskii, chief digital officer of Severstal, added: "The use of reinforcement learning to control production units is not widespread, particularly in metallurgy. We believe the use of Artificial Intelligence at NTA-3 to be the first such case in Russian practice. The performance improvement recorded on NTA-3 following the introduction of digital tools proves that a data.

Causal inference for a steel mill.

How to create a data science product for a steel mill

How to create a data science product for a steel mill that combines human expertise and causal inference principles.

Our project

I want to share my experience in creating a data science products for a Severstal mill located near St. Petersburg. We produce steel rolls up to 5 meters wide at this mill. For example, you can create oil and gas pipes from this type of steel. As an input, you send a 20-tonne steel slab, and after 15–30 iterations steel is transformed into a sheet with expected thickness.

Here is the video you can watch to get more insights on the process:

Before our project, an operator used to choose a speed for each iteration manually, and our goal was to automate this process. Our model is working in the real-time mode right now, and we can observe that model’s speed is more than a human’s speed by 5+ %.

Why can’t you choose the maximum possible speed in each iteration? The higher the speed, the higher the electric current (I) on engines, and if a current is more than a threshold, your engine will stop working to prevent a failure. So, an operator chooses a speed considering thickness, delta (a difference in thickness before and after an iteration), and other parameters.

Data

For simplicity, we assume that we only have thickness, delta, speed, and current in our data.

Let’s have 20000 iterations in our dataset. Let’s generate thickness from a uniform distribution with a minimum equal to 5 and a maximum equal to 15 and generate delta from the same distribution but with a minimum equal to 1 and a maximum equal to 4. It means that the metal thickness before an iteration will be between 5 and 15, and this thickness will be reduced by 1–4 points in each iteration.

Suppose that an operator chooses a speed according to this rule:

df['speed'] = np.round(25 - 0.1 * df['thickness'] ** 0.9 - 4 * df['delta'] ** 1.1

Also, an operator can choose a speed higher by 1 unit with a 5 % probability or lower by 1 unit with the same probability.

So, our speed is within 4.61–21.47 range.

Let our electric current obeys this rule:

df['I'] = 3000 + 1500 * (df['thickness'] ** 0.8 + 5 * df['delta'] ** 1.4) + 2000 * df['speed']

Additionally, let’s add some noise to our current. The noise would be taken from a normal distribution with a standard deviation equal to 500.

So, we can split our dataset into three parts: 15000 observations in a train set, 2500 — dev, 2500 — test.

Let an electric current excess starts from 78647 units — it is a rare situation with a frequency of about 0.3 % in our dataset.

Everything is ready for our research =)

Direct approach

You can choose the wrong way to deal with this problem: select a powerful algorithm and train it on your data. For example, you can use gradient boosting, train it, and vary a speed in a way to improve productivity and do not to exceed an electric current.

We have selected an algorithm with 12 leaves, 0.1 learning rate, and 500 trees, and our RMSE is 500±50 on all our datasets (train, dev, and test). The metric is remarkably close to the actual error (500), so we can say that our algorithm is close to the perfect one.

But this is correct only if we are working within the same distribution =)

Let’s choose a speed for each observation in our test set. We will start with maximum speed from our distribution and will stop if our electric current prediction is less than a critical one minus three standard deviations. As a standard deviation, we will take 600 (our 500±50 and small insurance):

def speed_choose(thickness, delta, model=bst, prelimit=limit - 600 * 3): speeds = list(range(4, 22)) speeds.reverse() for speed in speeds: df = pd.DataFrame({'speed': [speed], 'thickness': [thickness], 'delta': [delta]}) if model.predict(df) < prelimit: return speed return 4

Source: gistfile3.py on GitHub.

Our new speed is more than 30 % better than the old one! Great result!

Let’s see how our engines are working. Since we know the true dependency between speed and electric current in our virtual world, we can simulate the result of our experiment:

test = test.assign(I_new=test['I'] + (test['ml_speed'] - test['speed']) * 2000) print((test.I_new > limit).sum() / test.shape[0])

Source: gistfile4-py on GitHub.

So, we have 31.7 % of cases when our electric current is higher than critical, and it is 100 times more frequent event comparing the manual control period. How is it even possible? When we trained our algorithm, it didn’t have any information about the causation between speed and thickness with delta. Therefore, our algorithm remembered an electric current for each combination of speed, thickness, and delta. If we change speed, the model still sees old thickness and delta and thinks that everything will be fine. What can we do in this situation?

Maybe we should predict a speed?

Our goal is to speed up our mill. We know that an operator can work better or worse in similar situations. So, we can predict speed based on the best speed from our past!

For these types of problems, k-NN is a perfect algorithm (we can choose a speed exactly from the past by it):

mm_scaler = preprocessing.MinMaxScaler() X_train_minmax = mm_scaler.fit_transform(X_train[['thickness', 'delta']]) neigh = KNeighborsRegressor(n_neighbors=20) X_train_clean = X_train[y_train['I'] < limit].reset_index(drop=True) X_train_clean_minmax = mm_scaler.transform(X_train_clean[['thickness', 'delta']]) neigh.fit(X_train_clean_minmax, X_train_clean[['speed']])

Source: gistfile5-py on GitHub.

With this algorithm we can achieve a 1.2 % increase in the productivity with the electric current excess rate of only 0.24%:

X_dev_minmax = mm_scaler.transform(X_dev[['thickness', 'delta']]) kn = neigh.kneighbors(X_dev_minmax, return_distance=False) dev = dev.assign(ml_speed=[X_train_clean.loc[i, 'speed'].quantile(0.8) for i in kn]) print(dev.ml_speed.mean() / dev.speed.mean()) dev = dev.assign(I_new=dev['I'] + (dev['ml_speed'] - dev['speed']) * 2000) dev = dev.assign(I_new_predict=bst.predict(dev[['ml_speed', 'thickness', 'delta']])) print((dev.loc[:, 'I_new'] > limit).sum() / dev.shape[0])

Source: gistfile6-py on GitHub.

Great result! But can we do better?

Causal Inference

To reach a speed better than we got from k-NN, we should extract true dependency between a speed and an electric current. How can we do it when our dataset consists only of observations with interdependencies? We can start an experiment, but it is an expensive way on a real mill. However, we can work with interdependencies using causal inference methods.

We would like to demonstrate the work of one of the simplest causal inference methods. This method is simple, but also a strong one:

1) Let’s create a model where we will predict speeds through thicknesses and deltas. This model shouldn’t be too accurate but should incorporate dependency between our variables:

Xc = train[['thickness', 'delta']] Xc = sm.add_constant(Xc) Yc = train[['speed']] modc = sm.OLS(Yc, Xc) resc = modc.fit()

Source: gistfile7-py on GitHub.

2) Let’s split our dataset by predictions of this model, so in each part of this dataset will be similar predictions. Then we train different linear regression models on each of these datasets:

coefs = {} for i in range(6, 19): train_new = train.copy() train_new['bin'] = ((resc.predict(Xc) < (i + 2)) & (resc.predict(Xc) >= i)).astype(int) Xcb = train_new[train_new.bin == 1][['speed', 'thickness', 'delta']] Xcb = sm.add_constant(Xcb) Ycb = train_new[train_new.bin == 1][['I']] modcb = sm.OLS(Ycb, Xcb) rescb = modcb.fit() coefs[i] = rescb.params['speed']

Source: gistfile8.py on GitHub.

3) And now our coefficients are much closer to 2000: they vary from 1924 to 2031. If we create a linear regression without this split, we will receive a coefficient equal to 1404, which will lead us to an underestimation of a speed influence and, as a result, electric current excesses. Why is this approach working? We could presume that the splitting of our original dataset by these bins allows us to detect sets with similar values of thicknesses and deltas with respect to speeds. Therefore, we can better determine the relationship between speed and an electric current.

4) Now we can take a maximum of these coefficients and choose a speed with this knowledge:

dev.loc[:, 'ml_speed'] = dev['ml_speed'] + (limit - 600 * 3 - dev['I_new_predict']) / step dev.loc[:, 'I_new'] = dev['I'] + (dev['ml_speed'] - dev['speed']) * 2000 print((dev.I_new > limit).sum() / dev.shape[0]) print(dev.ml_speed.mean() / dev.speed.mean())

Source: gistfile9-py on GitHub.

The electric current excess is less than before! And we have achieved a 30 % speed improvement!

5) And we see that the result is consistent with our test set:

test = df[17500:] X_test = test[['speed', 'thickness', 'delta']] y_test = test[['I']] X_test_minmax = mm_scaler.transform(X_test[['thickness', 'delta']]) kn = neigh.kneighbors(X_test_minmax, return_distance=False) test = test.assign(ml_speed=[X_train_clean.loc[i, 'speed'].quantile(0.8) for i in kn]) test = test.assign(I_new_predict=bst.predict(test[['ml_speed', 'thickness', 'delta']])) test.loc[:, 'ml_speed'] = test['ml_speed'] + (limit - 600 * 3 - test['I_new_predict']) / step test.loc[:, 'I_new'] = test['I'] + (test['ml_speed'] - test['speed']) * 2000 print((test.I_new > limit).sum() / test.shape[0]) print(test.ml_speed.mean() / test.speed.mean())

Source: gistfile10-py on GitHub.

It is much better than the direct approach =)

Conclusion

We have an unfair advantage in this virtual example because we know the real dependency between a speed and an electric current, so we can see what actually happens with an electric current when a speed increase. In the real world, it is unknown to us. We can test our model on historical data, but in the real world our model might cause an electric current excess and stop a mill. So, we can do two simple things to prevent the risk:

1) We can start our improvement with small steps of speed. Thus, we can be close enough to our historical distribution and trace when it differs significantly.

2) Also, we can start with a recommendation system without direct control of the mill’s speed. Thus, an operator should confirm our recommendations on the first stage of the pilot.

In a short time, an operator will start to be confident in the proposed system, and it can be shifted to the full automation mode with a gradual increase in the speed. Today we have a maximum speed of the mill about 33 % higher than a year ago, and the average speed is higher by more than 5 %.

By the way, if you want to know more about causal inference, you can start with this tutorial.

The full code for this article available here.

Source: Towards Data Science.

Властелины стихии.

Взрывники «Олкона» осваивают новую компьютерную программу автоматизированного проектирования буровзрывных работ I-Blast

Рациональный подход

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

«Качество буровзрывных работ во многом зависит от правильно рассчитанного проекта. Это работа команды геологов, маркшейдеров, буровиков и взрывников. Чтобы выйти на новый уровень проектирования, „Олкон“ приобрел программный продукт французской компании Thierry Bernard Technologie», — рассказывает горный мастер Чингиз Магомедов.

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

Симулятор взрыва

Современный промышленный взрыв уже давно стал управляемой стихией. За счет определенной последовательности соединения скважин системой Exsel с различным временем замедления взрывники получают заданный порядок инициирования зарядов. Поскважинное замедленное взрывание зарядов взрывчатых веществ на массовом взрыве обеспечивает требуемую направленность его действия. В программе I-Blast можно просчитать последовательность взрывания каждой скважины, распределить энергию взрыва с учетом твердости массива. С ее внедрением проектировщики буровзрывных работ смогут подбирать параметры сетки скважин, зарядов, способов инициирования. Это приведет к получению требуемой кусковатости и оптимальным удельным показателям.

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

«Условные обозначения позволяют сразу увидеть, что, например, в этом блоке после взрыва разлет кусков составит 205 метров, что вполне укладывается в наши расчетные данные. У нас она в проекте до 500 метров», — рассказывает Чингиз Магомедов.

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

Кстати

Горняки только осваивают возможности нового программного продукта. Обучали их представители компании-разработчика Thierry Bernard Technologie (Франция). В итоге четыре сотрудника горного управления успешно сдали экзамен уровня Basic.

«Цифровое сердце» компании.

Платформа нового поколения S/4HANA, которая заменит SAP ERP

В 2019 году запущена программа проектов S/4HANA — важный этап цифровой трансформации «Северстали». Это платформа нового поколения, которая заменит SAP ERP.

Высокий стандарт

Решение о старте программы было принято после утверждения новой стратегии «Северстали» в 2018 году.

«Для реализации ключевых стратегических задач необходима цифровая и процессная основа, которой станет платформа S/4HANA. Она существенно повысит эффективность наших процессов. За счет более высокой скорости, производительности и предоставления возможностей по отслеживанию сквозной эффективности S/4HANA позволит нам создавать дополнительную стоимость для „Северстали“», — отметил генеральный директор «Северстали» Александр Шевелев.

Платформа S4/HANA создает дополнительные возможности для повышения эффективности работы как отдельных сотрудников, так и компании в целом. «Уровень изменений, заявленный в рамках бизнес-трансформации „Северстали“, настолько высок, что, по предварительным оценкам, количество доработок в действующей системе придется увеличить почти вдвое, что фактически превратит нашу нынешнюю систему в набор собственного кода и создаст серьезный риск критического падения производительности. В то же время внедрение новой платформы — это реальный шанс отказаться от старых доработок и использовать стандартные решения SAP там, где это возможно», — комментирует генеральный директор «Северсталь-инфокома» Сергей Дунаев.

Свой путь

«Северсталь» выбрала свой путь внед­рения S/4HANA, отличный от опыта других компаний. Многие из них переходили на платформу как на новую систему, приостанавливая производственный цикл. «Северсталь» планирует внедрение без остановки ключевых процессов, что позволит продолжить работу всех функций в плановом режиме.

Уже сформирована проектная команда, завершается проектирование новых процессов. В первом квартале 2020 года начнется процесс разработки платформы S/4HANA, который должен завершиться успешным внедрением в августе 2021 года. Особенность проекта — использование стандартизированных процессов и отказ от существенной части собственного программного кода. Это позитивно скажется на качестве управления изменениями в новой системе, которые потребуются в будущем.

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

Сотрудничество

Все функции, которые являются пользователями SAP ERP, будут привлечены к изменению процессов. В тестировании и приемке платформы S/4HANA будут задействованы все подразделения, которые в своей работе используют возможности и данные учетного ядра. Им нужно будет убедиться, что при замене платформы их процессы работают надежно и корректно.

Переход на S/4HANA — сложный интересный проект, который повлечет значительные трансформации. Важно помнить, что любые изменения — это почти всегда трудоемкий процесс, требующий усилий от участников. Этим проект «Северстали» ценен и интересен.

Новая платформа является «цифровым сердцем» компании, ее учетным ядром, с которым интегрированы десятки систем. Сотни процессов будут затронуты внедрением платформы S/4HANA.

Преимущества платформы S/4HANA перед SAP ERP

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

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

Модули, ранее стоявшие отдельно, теперь могут работать внутри ERP, на единой модели данных.