Алексей @PorisulkiP
С++/Python программист, ML-инженер, художник
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Software Developer, ML Engineer
Senior
From 500,000 ₽
Python
C++
Pytorch
Machine learning
Deep Learning
Наверное 40ГБ
А касаемо темы статьи, то что по временным затратам? Я сам пытался устроить себе подобный эксперимент по рабочей задаче, но нужны прям уходить по делам и на что-то отвлекаться, пока идёт подбор. Ситуация "первые 15 экспериментов длинною в 10 часов выдали val_loss inf" даже более жизненна, чем хотелось бы)
Не знаю, можно ли спустя два года править статьи, но думаю эту опечатку лучше исправить.
Было бы интересно узнать как родился язык "Эмодзи" в переводчике. Или это просто побочный продукт?
Ещё и оформление рекламной ссылки битое...
Аварий считалось превышение значений вибропараметров уставок. Ставки даются ГОСТом
У нас центробежные насосы, которые качают пульпу.
Разработать можно все, если есть данные характеризующих их состояние, но нужно смотреть экономический эффект.
Цены заказчика это компетенция генерального директора компании диатех, вопросы к нему.
Датчики компании диатех, либо те что есть уже у заказчика.
Отказов мы не ждали, так как работали с историческими данными. Сколько было сегментов отказов? Много. Точнее сказать не могу. За два года на 500+ насосах данных накопилось слишком много, чтобы запоминать такие детали. И нет, наш ансамбль моделей не для одного насоса, а для всех, что есть у заказчика.
Это все признаки, которые я использовал. Понятно, что их, по‑хорошему, надо расписать поподробнее, но я оставлю это для следующих статей.
А предсказывались точки по количеству дней, то есть:
[кол‑во замеров в день] * [кол‑во дней] = [кол‑во предсказаний]
Это видно на первом графике последних двух изображений
К сожалению, вид вывода является частью ТЗ и мне запрещено его раскрывать....
Но всё равно спасибо за такой рьяный интерес к теме. Для следующих публикаций попытаюсь выпросить разрешение и показать вывод в Safe Plant и свои ранние наброски.
Целью было предсказать остаточное время работы насоса, а именно когда произойдёт авария (или пересечение ГОСТ уставок)
Короткий ответ: ну вы загнули конечно... Мы не AGI обучаем, а регрессионную НС.
Длинный ответ: мы берём все данные заказчика и пытаемся с их помощью решить проблему из ТЗ. Теоретически, мы можем выставить требования, которые вы описали, и надолго забыть об этом направлении, так как ни у кого такого объёма и качества данных просто нет и в ближайшем будущем не появятся.
Данные собирались 2 года и их было очень много, только подготовленных временных рядов было около миллиона. Самих насосов не тысячи, но чуть больше 500. И всего этого с головой хватило для решения проблемы заказчика.
Кстати, если сборную солянку из графиков неудобно воспринимать, то напишите, учту в дальнейших статьях.
Для большей ясности есть картинки "Первый пример" и "Второй пример". В них, на первом графике, отображён пример прогноза на две недели вперёд, основываясь на предыдущих 30 днях, в которые насос работал.
Зря вы так, на критичном оборудовании или том, где показания снимаются каждую секунду и полчаса могут оказаться решающими.
Это и есть цель модели, только не на на полчаса, а не 3 дня(краткосрочный прогноз) и на 14 дней(долгосрочный прогноз)
Нет, мы учитываем только последние замеры вибропараметров и ИТС насоса.
Не стоит забывать, что срок службы сложно посчитать, ведь у некоторых агрегатов за годы не раз сменились режимы работы и часть внутренних компонентов, которые напрямую влияют на уровень износа, а лишние погрешности нам ни к чему