Цифровизация «Северстали»: раннее выявление и устранение неисправностей
Здравствуйте! Меня зовут Осминкин Ярослав, я работаю руководителем службы мониторинга состояния оборудования дирекции по ремонтам, и сегодня я поделюсь с вами нашим опытом из компании «Северсталь» по использованию цифровых инструментов для раннего выявления неисправностей оборудования и предотвращения отказов.
Главной задачей наших ремонтных служб, как и у ремонтных подразделений любой крупной промышленной компании, является обеспечение бесперебойной работы основных технологических агрегатов и удержание необходимого коэффициента технической готовности (КТГ). Только при стабильной и надёжной работе оборудования можно оперативно выполнять производственные задачи и поддерживать темпы выпуска продукции.
Понимание важности надёжности оборудования привело нас к тому, что ещё в начале 2010-х годов в «Северстали» стартовала масштабная трансформация функции ремонтов. Мы разработали и внедрили методику технического обслуживания, ориентированную на надёжность, которую в нашей компании называют «Колесо ТООН».
Эта методика стала основой изменения подхода к управлению агрегатами и их состоянием.
Модель позволяет управлять нашими основными фондами и обеспечивать нужный уровень коэффициента технической готовности агрегатов.
Для наших ремонтников важно не только качественно выполнять свою работу, но и иметь быстрый и удобный доступ ко всем необходимым данным и инструментам. Современные цифровые решения значительно упрощают рабочие процессы, автоматизируют рутинные задачи и позволяют сосредоточиться на главном — предотвращении аварий и повышении надёжности оборудования.
В рамках трансформации ремонтной функции мы разработали и внедрили несколько ключевых программных продуктов, которые полностью заменили устаревшие импортные решения, использовавшиеся ранее. Эти решения созданы с учётом специфики наших бизнес-процессов и обеспечивают интеграцию всех этапов ремонтной деятельности под единое цифровое управление.
Перечислю основные из них: (ПО) «Надёжность», ПО «Планирование», мобильное решение для обходчиков ПО «МТОРО», а для оперативного мониторинга за состоянием оборудования, ПО «ИСМД» (Интеллектуальная система мониторинга и диагностики) и ПО «СУРС» (Система управления ремонтными событиями).
Все программные продукты, о которых я уже упоминал, являются результатом совместной разработки между дирекцией по ремонтам и нашими IT-специалистами из компании «Северсталь-Инфоком». Это важный момент: каждый инструмент разрабатывался на основе многолетнего опыта в организации и проведении ремонтов промышленного оборудования, а также глубоких знаний и компетенций в области IT. Такой симбиоз опыта ремонтников и профессионализма IT-разработчиков стал ключевым фактором успеха в создании эффективных и действенных решений, которые максимально адаптированы под наши конкретные процессы и потребности.
Однако в этой статье я хочу подробнее остановиться на двух основных цифровых решениях, которые наиболее важны для службы мониторинга состояния оборудования: Интеллектуальная система мониторинга и диагностики (ИСМД) и Система управления ремонтными событиями (СУРС). Эти системы непосредственно связаны с нашей повседневной деятельностью и играют ключевую роль в достижении как наших внутренних целей, так и глобальных задач компании.
Рождение идеи ПО «ИСМД»
Идея по созданию ИСМД возникла ещё в 2013 году, когда только начиналась работа по внедрению новой философии обслуживания оборудования — методологии, ориентированной на надёжность. В тот момент, когда мы разрабатывали и адаптировали подходы, такие как плановое техническое обслуживание и профилактическое обслуживание, стало очевидно, что для успешного функционирования этих стратегий недостаточно просто регламентировать работы. Для максимальной эффективности необходим был инструмент, который бы в реальном времени позволял не просто следить за состоянием оборудования, но и предупреждать о возможных отклонениях.
На этом этапе к нам на Северсталь приезжали международные консалтинговые компании, которые проводили аудит наших процессов и оказывали экспертные рекомендации по улучшению системы эксплуатации и ремонта оборудования. Результаты аудитов показывали, что традиционные методы мониторинга и анализа, которые были у нас на тот момент, не полностью соответствовали вызовам и масштабам нашего производства. Мы поняли, что для достижения оптимальной эффективности нам нужно было двигаться в сторону цифровизации процессов и внедрения современных инструментов мониторинга.
В 2013 году мы сделали первый шаг в этом направлении, запустив одно из наших первых решений для мониторинга состояния агрегатов. Эта система называлась «Система мониторинга технического состояния оборудования» и, по сути, представляла собой веб-таблицы, где операции мониторинга присутствовали в виде настроенных тревог. Это было похоже на веб-интерфейс Excel, который отображал списки датчиков с установленными пороговыми значениями и простыми рекомендациями. Мы старались сделать систему максимально удобной для сотрудников службы мониторинга.
Но, как скоро выяснилось, один из ключевых вызовов состоял в пользовательской вариативности. Несмотря на старания сделать систему удобной и «дружественной» к пользователю, появилось много сложностей, связанных с разницей в подходах на местах. Например, каждый сотрудник, имея за плечами разный опыт, мог называть одно и то же оборудование разными терминами, что вызывало большое количество путаницы при работе с каталогом оборудования. Один специалист называл узел по его заводскому наименованию, другой — по внутреннему корпоративному обозначению или даже устоявшемуся в разговорной речи варианту. Это несоответствие приводило к тому, что ремонтные службы на местах не всегда правильно понимали, о каком именно агрегате шла речь в системе и в рекомендациях по действиям.
Аналогичная проблема касалась получаемых тревог. Когда система только начинала действовать, мы часто сталкивались с тем, что большое количество тревог о неисправностях было ложными. По нашей оценке, менее 1% всех срабатываний тревожных сигналов действительно указывало на реальные неисправности, тогда как остальные 99% случаев были ложными срабатываниями, которые приводили к тому, что ремонтные службы и технологи тратили своё время на проверки и диагностики оборудования, которое на самом деле работало исправно. Это отвлекало их от их основных производственных задач и, как вы догадываетесь, вызывало недовольство на местах.
После первого опыта с системой мониторинга мы поняли, что необходимо существенно доработать наш подход. Неудачи первого проекта научили нас многому: от важности стандартизации каталога оборудования до необходимости логировать каждое действие ремонтников и специалистов службы мониторинга, чтобы видеть, как реакцию на возникающие инциденты. Собрав выводы и осознав свои ошибки, вместе с командой ИТ-специалистов в 2017 году мы запустили вторую систему — «Автоматизированную систему мониторинга и диагностики» (АСМД).
Что же изменилось с приходом АСМД? Прежде всего, мы осознали, что для успешной работы систем мониторинга необходим единый и надёжный каталог оборудования. К этому моменту у нас уже был сформированный и протестированный каталог, связанный с нашей ERP-системой. Это означало, что больше не возникало путаницы между названиями оборудования — у механиков, электриков и специалистов по мониторингу было чёткое понимание и синхронизация данных.
Другим важным улучшением стало внедрение функции квитирования событий. Это была действительно решающая функция: каждый раз, когда система генерировала тревогу или уведомление, специалист верифицировал её. Он должен был не просто реагировать на сигнал, а подробно фиксировать все сделанные действия и их результаты. Если оборудование не требовало вмешательства, это отмечалось, а если требовались меры — вносилась информация о том, какие шаги были предприняты и какой результат достигнут. Такая задокументированная обратная связь позволила не только улучшить прозрачность процессов, но и существенно облегчить анализ эффективности работы системы.
Кроме того, мы добавили статистическое модульное решение, которое позволяло нам видеть детализированные отчёты в реальном времени. Я, как руководитель, теперь мог чётко понимать, что происходило на смене, видеть статистику тревог и действия персонала, а также оценивать качество устранения неисправностей.
Ещё одним новым блоком, добавленным в систему, стала интеграция с системами стационарной вибродиагностики. На нашем предприятии активно внедрялись такие системы, и их данные стали важной частью общего мониторинга. Однако эти данные требовали особой обработки и другого алгоритма реагирования, что потребовало разработки специального модуля в АСМД.
Но тут возник новый вызов: непонимание между ремонтниками и автоматчиками. Когда возникали проблемы с датчиками или сигналами, автоматики часто не могли быстро найти источник данных, особенно если речь шла о тысячах сенсоров на крупных агрегатах. Это замедляло процесс выявления и устранения неисправностей и порой приводило к пропуску критических ситуаций.
По завершении первых лет эксплуатации АСМД мы провели детальную оценку её эффективности. На тот момент мы уже смогли оптимизировать процессы так, что точность выявления реальных неисправностей повысилась до 10–15%. Этот результат был ощутимым шагом вперёд, но всё же недостаточным для наших амбиций.
Одним из достижений стала разработка методики финансовой оценки рисков, возникающих при появлении неисправностей. В конце 2021 года мы внедрили автоматический расчёт предотвращённых финансовых потерь, который рассчитывал потенциальные убытки в случае незамеченного отказа оборудования. За счёт раннего обнаружения неисправностей в 2022 году нам удалось предотвратить риски на десятки миллионов рублей. Это был значимый экономический результат, который позволил более внимательно подходить к оценке эффективности системы.
Но несмотря на положительные сдвиги, нам предстояло решить ещё несколько серьёзных проблем. К концу 2021 года система мониторинга всё ещё вызывала недовольство в некоторых цехах и подразделениях: точность обнаружения неисправностей всё ещё составляла относительно низкие 10–15%. Очевидно, что этого было недостаточно. Перед нами стояла задача поднять этот показатель до 70–80%, чтобы система начала по-настоящему экономить время ремонтников и минимизировала ложные срабатывания.
Кроме того, мы столкнулись с новым поколением работников — поколением Z, которое вошло в производственные процессы. Молодым сотрудникам нужен современный интерфейс. Команда разработчиков и мы, как пользователи, начали осознавать, что для привлечения новых кадров и улучшения их опыта работы с системой нужно адаптироваться и создавать современные и удобные интерфейсы, а также вносить элементы упрощённости в использование системы.
В конце 2021 года перед нашей командой встал важный вопрос: как оценить эффективность работы систем раннего выявления неисправностей оборудования? В мире промышленности понятие «эффективность» имеет не только техническое, но и вполне материальное измерение — финансовое. На первый взгляд, задача кажется простой: подсчитай стоимость предотвратимых аварий, и готово. Но в реальности учитывать все аспекты — от прямых финансовых потерь до косвенных убытков, связанных с остановкой производства, — оказалось куда сложнее.
Мы разработали методику, которая позволила нам связать технические показатели работы системы с реальными финансовыми метриками. Основной идеей было рассчитать стоимость потенциальных убытков, которые могли возникнуть в результате выхода оборудования из строя, и сопоставить их с количеством предотвращённых ситуаций. Эти оценки были объективны и не зависели от того, кто непосредственно эксплуатировал систему, что добавляло прозрачности и доверия к показателям.
Несмотря на положительную динамику, точность выявления отказов в 10–15% была всё ещё неприемлемо низкой для наших амбиций. В конце 2021 года мы снова собрали команду экспертов и поставили задачу повысить точность срабатываний до хотя бы 70–80%. Эта новая цель стала вызовом, который требовал пересмотра подходов к проектированию и обработки данных.
Еще одним значимым вызовом для нашей команды стала неизбежная смена поколений специалистов. Опытные сотрудники, которые годами накапливали знания о работе оборудования и нюансах устранения сложных инцидентов, начали выходить на пенсию или расти по карьерной лестница переходя на более высокие должности в компании. На их место приходят молодые специалисты, технологически подкованные, но не обладающие столь же глубоким практическим опытом. Это поставило перед нами задачу: как сохранить и передать накопленные знания, чтобы новые коллеги могли не только оперативно вникнуть в процессы, но и продолжать развивать их на новом уровне. Вместе с ними начали «уходить» уникальные знания о том, как правильно и эффективно решать проблемы на местах. Это поставило перед нами вопрос: как сохранить уровень сервиса и не допустить провалов в работе систем, когда на смену опытным инженерам приходят молодые без достаточного опыта?
Ответом на этот вызов должна была стать система, которая не просто фиксирует действия специалистов, но и обучает новых сотрудников на основе накопленного опыта. Необходимо было создать инструмент, который предоставлял бы стандартизированные решения и советы по устранению неисправностей, что позволило бы молодым специалистам быстро вникать в задачи и эффективно справляться с ними.
Таким образом, наш следующий шаг в эволюции системы мониторинга и диагностики заключался в том, чтобы сделать её:
— более точной и эффективной (сделав акцент на точности прогнозов до 70–80%);
— удобной, чтобы привлечь молодое поколение пользователей;
— интуитивно понятной и обучающей, чтобы компенсировать недостаток опыта у новых сотрудников.
Одновременно с этим мы осознали необходимость изменений в самих процессах. Оперативная реакция на неплановые неисправности, хотя и эффективна, имеет значительный минус — она сбивает выполнение плановых задач. Чтобы минимизировать такие сбои, требуется развивать инструменты раннего обнаружения отклонений. В ответ на эту потребность у нас в службе появилось экспертное направление, цель которого — разработка и внедрение экспертных правил и моделей детекторов аномалий для выявления неисправностей на более раннем этапе. Это позволяет заранее планировать мероприятия по их устранению и интегрировать их в уже существующую систему планирования, вместо того чтобы постоянно «тушить пожары» в экстренном порядке.
Эти задачи стали основой для наших следующих шагов в развитии системы.
Новая концепция ПО «ИСМД»
В оперативном блоке мы продолжили развивать функционал мониторинга. Настройка условий срабатывания тревог, основанная на пороговых значениях, выполняется через справочник параметров системы. При возникновении тревоги соответствующее сообщение отображается в ленте событий и подсвечивает нужный блок на мнемосхеме, облегчая специалистам оперативное реагирование. Появление тревог реализуется с помощью алгоритмов проверки достоверности данных, а также учитывает дополнительные условия, задаваемые в настройках системы, что позволяет повысить точность и своевременность уведомлений о неисправностях.
Мы сделали упор на улучшение юзабилити интерфейсов, чтобы адаптировать их к привычкам нового поколения специалистов. Мы стремимся сделать работу с системой интуитивно понятной и даже в какой-то мере «игровой». Это некое сочетание лёгкости взаимодействия и эффективности, а-ля «тапай хомячков», где специалисты работают с визуальным интерфейсом, выполняя квитирование системы событий.
Идея здесь такова — перед ними всегда «чёрный экран», на котором моментально всплывают события, требующие их реакции. Всё хорошо, когда экран пустой, и никаких событий нет. Это как принцип «тушения огней» — когда что-то загорается, задача специалистов быстро всё погасить. В случае старших сотрудников, которые сталкиваются с подобными системами, этот принцип называется принципом чёрного экрана — всё в порядке, пока нет тревожных сигналов. Для молодых более привычным и увлекательным становится «тапать» эти события для квитирования и обработки.
Автоматический процесс квитирования мы также серьёзно переработали. В карточке квитирования фиксируются причины возникновения тревоги и мероприятия по её устранению. В процессе обработки сообщений о тревогах осуществляется автоматизированный обмен данными с модулем EAM ERP системы, что обеспечивает связность процессов. Результаты успешного квитирования, с подробным описанием выполненных действий, сохраняются в истории тревог. Это помогает в дальнейшем выбрать оптимальную стратегию реагирования на аналогичные неисправности, опираясь на уже накопленный опыт и данные. При создании сообщения о неисправности система автоматически подтягивает каталог оборудования, справочник дефектов и справочник персонала, что позволяет мгновенно добавить контекст к событию и затем правильно его отработать.
Если возникают проблемы с отсутствием данных из-за проблем в ИТ-инфраструктуры, то инцидент регистрируется в Helpdesk, также отслеживаются все действия по нему.
Чтобы уменьшить поток телефонных звонков и отвлечение технологического персонала на экстренные случаи, мы внедрили модуль аналитики. Этот инструмент мы заимствовали у мировых лидеров отрасли. Модуль позволяет сгруппировать несколько параметров в одном интерфейсе и проводить комплексный анализ. Дополнительно мы интегрировали его с централизованной системой видеонаблюдения, которая активно используется на наших производственных площадках, например, на Череповецком металлургическом комбинате, где установлено более 5000 цифровых камер.
Цифровое видеонаблюдение теперь не просто «глаз», который смотрит, но и важный источник данных для системы мониторинга. Мы можем в режиме реального времени сопоставить показания датчиков с тем, что происходит на производственном участке. Это особенно актуально в условиях, когда для эффективного анализа недостаточно наблюдать параметрические данные. Можно проводить всесторонний разбор ситуации и принимать более взвешенные и точные решения.
Такое интегрированное решение позволяет нам оперативнее реагировать на события, минимизировать количество «незапланированных» решений и буквально отслеживать состояние оборудования в реальном времени.
Развитие инструментов диагностики: от единицы оборудования до узла
Для проведения качественного анализа недостаточно полагаться на отклонение от нормальных значений по одному параметру. Изолированные данные о состоянии одного датчика или агрегата могут дать ограниченное понимание, не отображая общую картину состояния оборудования. В реальности каждый промышленный узел состоит из множества взаимосвязанных элементов, параметры которых могут оказывать взаимное влияние. Например, температурное отклонение на одном узле может быть вызвано падением давления на другом, и без системного подхода к анализу такие зависимости легко остаются незамеченными, что потенциально может привести к недооценке рисков.
Именно поэтому мы сосредоточились на разработке инструмента в рамках ИСМД, который помогает проводить комплексный анализ состояния узлов оборудования. Такой подход открывает новые возможности для автоматической диагностики и предсказания отказов.
Суть данного подхода заключается в оценке состояния многомерной системы признаков. Вместо того чтобы фиксировать сработку на один, условно говоря, «критический» параметр, система анализирует множество связанных параметров, таких как температура, давление, вибрации, электрические характеристики и т. п. Сопоставляя эти данные и выявляя взаимосвязи, система может не только определить наличие отклонений, но и автоматизировать процесс идентификации проблемы. Кроме того, анализ взаимосвязанных параметров позволяет делать более взвешенные прогнозы.
Перед вводом параметров в работу разрабатывается двусторонний регламент взаимодействия с подразделением, который затем прикрепляется к соответствующему параметру.
В текущей практике мы используем инструкции в формате Word, которые прикрепляются к каждому параметру в системе. Эти документы содержат подробные алгоритмы действий, описывающие шаги, которые должен выполнить персонал в случае возникновения тревожного события или отклонения параметров. Перед внедрением в работу инструкции проходят обязательное согласование между службой мониторинга и цеховыми подразделениями, что гарантирует их соответствие требованиям и особенностям конкретного оборудования и процессов. Эти инструкции обязательны для выполнения: если регламент не соблюдается, то инициируется эскалация на руководство для предотвращения просрочек или неправильных действий.
Такой подход позволил нам существенно повысить эффективность: по нашим оценкам, успешное управление событиями благодаря этим инструкциям улучшилось до 65%. Они предоставляют ясные действия для каждого сотрудника, что помогает стандартизировать поведение и избежать разногласий между сменами. Однако, несмотря на очевидные преимущества, остаётся одна весомая проблема: человеческий фактор. Как известно, «многие люди не всегда любят читать инструкции», особенно когда приходится действовать в условиях стресса или срочности. Этот момент, к сожалению, не всегда позволяет полностью избежать сбоев в передаче опыта и правильном исполнении алгоритмов, особенно среди менее опытных сотрудников или в новых сменах.
Именно необходимость решения этой проблемы и созданию более комфортных условий для сотрудников подтолкнула нас к следующему этапу улучшений — разработке цифровых инструкций, встроенных непосредственно в систему мониторинга.
Проект Data governance — новые возможности для ПО «ИСМД»
Параллельно с запуском проекта по разработке ПО «ИСМД», наши айтишники запустили проект Data governance. Основная его цель — унификация и стандартизация всех данных, поступающих из АСУ ТП, с целью обеспечения полной прозрачности и однозначности информации. С помощью этого проекта мы смогли выстроить систему, в которой каждый источник данных детально описан и привязан к конкретному оборудованию через каталог ERP. Это обеспечило единый язык, на котором теперь разговаривают все службы: механики, ИТ-специалисты и автоматчики.
Такой подход даёт нам уверенность в том, что все процессы максимально прозрачны и предсказуемы. Например, данные по параметрам оборудования, которые используются для мониторинга, анализа и прогнозирования, всегда имеют точную привязку к конкретным компонентам агрегационного узла. Это позволяет избежать путаницы и снижает риски ошибок при интерпретации данных на всех уровнях — от полевых инженеров до аналитиков и руководителей подразделений.
Возможности ПО «ИСМД» для экспертного направления
Второе направление, которое мы считаем экспертным, направлено на предсказательное выявление неисправностей на более ранних горизонтах — от недели и больше. Это позволяет не только заранее готовиться к внеплановым ремонтам, но и интегрировать работы по устранению неисправностей в плановые задачи, что является ключевым аспектом для снижения незапланированных простоев. Чтобы работы ремонтников были более предсказуемыми и их планы не срывались, мы для наших коллег — менеджеров по экспертным правилам — разработали три инструмента.
1. Поиск корреляций. Этот инструмент позволяет экспертам просматривать и анализировать события, произошедшие в системе, и сопоставлять их с историческими данными. Проще говоря, можно вернуться в прошлое и увидеть, что происходило с системой на аналогичных временных отрезках. Этот анализ помогает определить, что стало причиной нынешней неисправности и, возможно, предсказать дальнейшее развитие событий. Инструмент сравнивает параметры, фиксированные системой, с поведением оборудования на предыдущих этапах, что помогает идентифицировать предполагаемые закономерности.
2. Экспертные правила. Это мощный функционал, который базируется на математических алгоритмах обработки группы параметров оборудования для раннего выявления потенциальных дефектов. Основная задача данного модуля заключается в том, чтобы на ранних стадиях идентифицировать отклонения, которые могут привести к серьёзным неисправностям, и заранее сигнализировать об этом специалистам.
Работа начинается с исследования данных, где наши эксперты анализируют прошлые случаи возникновения неисправностей, которые имеют высокую вероятность повторения. Эти дефекты выявляются на основании анализа поведения взаимосвязанных параметров, что позволяет строить прогностические модели и находить ранние признаки аномалий в работе оборудования. Анализируется большой массив исторических данных, чтобы понять, какие комбинации параметров предшествовали известным сбоям и могут служить ранними индикаторами предстоящих поломок.
После того, как эксперты формулируют гипотезы и выявляют закономерности, разработка логики экспертных правил осуществляется через встроенный редактор на основе синтаксиса JavaScript. Это позволяет не только гибко настраивать правила обработки параметров, но и интегрироваться с существующими системами и процессами мониторинга.
3. Детектор аномалий. Пока он у нас в разработке. Если экспертные правила основаны на выявленных закономерностях прошлых событий и позволяют реагировать на повторяющиеся сценарии, то детектор аномалий даёт возможность обнаруживать отклонения, которые не могут быть захвачены привязанными к конкретным правилам алгоритмами. Это особенно важно для случаев, когда неисправность ещё недостаточно проявилась, и система не имеет исторических данных для создания точного экспертного правила.
Детектор аномалий способен выявлять потенциальные неисправности за недели или даже месяцы до их критического проявления. Такой горизонт обнаружения даёт нам возможность заранее подготовить необходимые материалы и компоненты, организовать их доставку со складов и спланировать работы так, чтобы они вписались в плановые остановки агрегатов.
Эффективность этих решений начинает существенно влиять на показатели всего предприятия. Как я уже упоминал ранее, за последние годы мы добились значительного роста точности в выявлении неисправностей, причем более 65% тревожных событий теперь отрабатываются правильно и вовремя. Это позволяет не только предотвратить аварии, но и оптимизировать затраты на техническое обслуживание, так как все работы планируются более осознанно и рационально.
Наш текущий фокус — достичь 85% эффективности выявления неисправностей в следующем году. Мы уверены, что дальнейшее совершенствование наших инструментов и синергия между системами помогут нам выполнить этот план.
Что касается предотвращённых финансовых рисков, то показатели говорят сами за себя. На текущий момент последнего анализа, счётчик предотвращённых рисков превысил несколько миллиардов рублей.
