Как стать автором
Обновить

Решение задачи определения RUL трансформаторов с помощью машинного обучения на python

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров4.2K
Всего голосов 2: ↑2 и ↓0+2
Комментарии11

Комментарии 11

Рискну Предположить, что Вы не совсем глубоко понимаете работу силовых трансформаторов и возникновение внутренних повреждений из-за развития дефектов. СТО это, конечно, хорошо.
Современные трансформаторы оснащаются системами мониторинга и некоторые российские компании очень и очень продвинулись в этом направлении. Трансформаторы оснащаются приборами контроля по 7 (семи) растворенных газов. Трансформатор имеет множество других параметров, от которых зависит его жизнь, например: нагрузка, ток, напряжение, частота, скорость изменение параметров, короткие замыкания, работа системы охлаждения, вибрация, и много других. Сейчас, в связи с внедрением элегазовых и, особенно, вакуумных выключателей, при отключении повреждения, в сети образуются очень высокие частоты, которые практически не фиксируются, но приводят к повреждению оборудования (есть мнение, что ОПН их полностью не срезают).
Ваша модель, со всеми регрессиями, градиентами, возможно прекрасна среди программистов, как "Квадрат" Малевича среди художников, но сильно сомневаюсь, что трансформаторщик восхитятся.
Если Вы не можете понять причину, то это вряд ли поможет. Есть дефекты, которые генерируют много газа, выше всех норм, но производитель их знает и разрешает работу и оборудование работает.
Не очень ясно Ваше заявление:
"Возникновение практически всех типов дефектов в оборудовании сопровождается образованием газов, растворяющихся в масле, а при определенных типах дефектов образуются собственные газы в разном количестве (например, при локальном перегреве изоляции или возникновении разрядов в масле)."
Приведите мне пример дефекта в трансформаторе, что бы не был связан с перегревом или разрядами, но генерировал газ?
Мне на память приходить один, когда заливают масло без должной дегазации, но ведь это не дефект трансформатора.

«Ваша модель, со всеми регрессиями, градиентами, возможно прекрасна среди программистов»

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

Выбор метрики и Лосс функции (стремящейся к среднему), «брутфорс» генерация признаков без нормальной «селекции», не показана работа с пропусками и грязными данными, нет разбора дрифта значений и разбросов от типа оборудования.

Это бейзлайн «студента», которому два года до продакшена.

Реклама канала сомнительна, если «это» подаётся за МЛ прорыв и экспертизу.

Спасибо за комментарий! Конечно, о прорыве (в рамках поста) речь не идет, это очевидно. Пост скорее о кейсе решения задачи с помощью МЛ с ссылкой на код и данные, что можно использовать в своих исследованиях, работе, обучении и тд. То есть речь о популяризации МЛ в промышленности.

Комментарии справедливые, но важно понимать, что материал для начального/среднего уровня специалистов. Для тех кто хочет познакомиться с МЛ в промышленных приложениях, для тех, кто разбирается в технической стороне задачи, но хочет начать решать типичные задачи диагностики с помощью МЛ, наконец, для тех, кто учится МЛ. И действительно, мне стоит добавить дисклеймер с указанием аудитории, согласен. Здорово, что вы сравниваете с Титаником, ведь цель такая и была - снизить порог входа и сделать понятный блокнот типа Титаника, чтобы дальше каждый сам мог углубиться, сравниваясь с представленными мной подходами и полученными метриками. Как я и сказал в конце, у нас при решении этой задачи на чуть более глубоком уровне результат был в несколько раз лучше.

Кстати о рекламе канала, про работу с пропусками и грязными данными вы можете найти материал в моем канале (я серьезно), в дальнейшем будут детальные посты на эти темы, так как опыта с промышленными данными немало, даже целый доклад можете посмотреть (он без кода и конкретики по методам обработки, но это все еще будет в канале), вдруг найдете, чем его дополнить, было бы отлично!

Если Вы не можете понять причину, то это вряд ли поможет.

Хроманализ по качественному и количественному составу газов как раз позволяет установить "причину" : пожар стали, витковое замыкание, деградация бумажной изоляции, деградация полимерной изоляции и так далее

Спасибо за комментарий! Отличное дополнение к посту с точки зрения технической экспертизы, которой мне в этой узкой области может не хватать!

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

Кстати, о решении задачи поиска и классификации аномалий можете прочитать в этой статье. Был бы рад обратной связи!

PS Добавил важный дисклеймер, который должен пояснить уровень детализации написанного в статье.

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

420 записей концентраций газов

Столько записей будет и в продуктивной среде? Или там будете обучать модель на бОльшем количестве записей?

Здесь данных все-таки 2100 файлов по 420 записей. То есть 420 записей используются для одного инференса (расчета) модели и прогнозировании (вычислении) одного числа. В продуктивной среде это может реализоваться как "искусственное" нарезание окна в 420 точек для прогноза из более длительного временного ряда. Можно и обучить модель заново на другом количестве точек, например, на большем. В принципе можно проверить гипотезу о применении этой модели на большем числе точек, то есть выделение того же набора признаков, требующегося на вход модели, можно производить и для большего (>420 точек) датасета.

420 записей это, как я понимаю, история измерения концентраций четырех газов за некий фиксированный промежуток времени. 2100 (поправьте меня, если я ошибаюсь) - это либо результаты измерений по такому же количеству трансформаторов, либо результаты многократных измерений по меньшему количеству трансформаторов.

Если назначенный срок службы 25 лет, а 420 записей это 210 календарных дней (12 часов между снятием показаний) - у трансформатора, пущенного в эксплуатацию это будет одна история, а у трансформатора, работающего уже (допустим) 24 года, другая. Другой износ металла, другая степень загрязнения изоляторов, и так далее. Насколько корректно по сути ставить рядом 210 дней нового трансформатора и те же 210 дней трансформатора перед списанием, и по такой выборке строить регрессионную модель?

Вот если была бы в наличии история 2100, или хотя бы 1000 трансформаторов за 25 лет (или за 10, или даже за 5), причем у всех за один и тот же промежуток времени от начала эксплуатации, получилась бы куда более значимая выборка. Есть ощущение что имеющихся данных для имеющей предсказательную силу модели сильно недостаточно.

Да, все верно, теперь понял Вашу мысль! Замечу, что у нас, к сожалению, нет информации о том, замеряются ли данные для разных трансформаторов или за разные периоды времени. Было бы полезно иметь признак id трансформатора, а также время работы с момента запуска. Еще полезны в таких случаях данные о ППР и значительных ремонтных работах, чтобы учитывать время с последнего ремонта.

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

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

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

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

  1. Добавить в модель (и в данные для обучения) этот самый период и проверить гипотезу о зависимости / не зависимости предсказаний от периода эксплуатации

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

    Не очень понял чем нам в отсутствие данные о периоде эксплуатации поможет градиентный бустинг. Это ведь просто один из способов минимизации функции потерь. Где итерационным методом подбирается формула "модели". В отличие, например, от градиентного спуска, где так же итерационно подбираются параметры модели (без изменения собственно формулы). Использование градиентного бустинга (или любой другой нелинейной модели) может ускорить сходимость итерационного процесса, позволить увереннее "проскакивать" локальные минимумы функции потерь в поисках глобального. Разве он может как-то заместить дефицит данных для обучения (в данном случае о периоде эксплуатации)?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации