Как в ПГК учатся делать точные прогнозные рекомендации по своевременной отправке вагонов в ремонтные депо.

В июле мы писали о старте проекта «Цифровой вагон». Он позволяет выстраивать предиктивную аналитику на основании данных о состоянии колесных пар. Меня зовут Надежда Костякова, я лидер команды разработки проекта в ПГК и расскажу, как он развивается, а также о проблемах, с которыми мы столкнулись в процессе, и способах их решения.

Как мы пришли к предиктивной аналитике

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

Когда по инициативе РЖД на сети начали массово устанавливать датчики, которые измеряют технические показатели колесных пар вагонов, мы разработали модуль — ИС КТИ (контрольно-технические измерения). Он позволяет нам анализировать информацию о толщине гребня и обода колесной пары. Это ключевые показатели, с помощью которых определяют техническое состояние колесных пар и принимают решение о том, куда вагон отправится – к клиенту или в депо на ремонт.

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

Для чего это нужно:

• исключить процедуру натурного осмотра вагона и экономить время сотрудников;

• замечать неисправности, незаметные глазу.

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

В общем, будущее перед нами открывалось волшебное. Но как этого достичь? Мы начали с анализа тех данных, которые у нас есть. Вскоре стало понятно, что с ними невозможно работать: у них было несколько источников шума из-за того, что замеры снимаются не только при движении вагона «туда», но и «обратно». Получается, что одни и те же датчики снимают замеры с разных колесных пар, и сопоставить данные – задача не из легких. В результате можно было запросто запутаться. Это ставило под угрозу всю нашу идею.

Первые проблемы с данными

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

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

Через некоторое время был определен победитель. Выбранный алгоритм предобработки обладал важными преимуществами: понятность, управляемость, простота реализации и, самое главное, эффективность. С его помощью мы могли привести наши данные в вид, пригодный для анализа, и использовать для построения рекомендаций.

Снижение затрат на верификацию алгоритма

Данные есть, они очищены, но возникла новая проблема. Как собрать обучающую выборку для построения модели? Зачастую она формируется достаточно просто: мы берем данные, которые у нас есть, и создаем из них целевую переменную. Однако сейчас целевую переменную собрать было неоткуда, ведь мы хотели получать рекомендации до возникновения поломки.

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

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

Такой сбор данных с вовлечением специалистов позволил нам добиться нескольких целей:

1. понять, что выявлять неисправности по данным КТИ действительно возможно;

2. проверить работу разработанного алгоритма рекомендации;

3. собрать данные для дальнейшей доработки алгоритмов;

4. отремонтировать неисправные вагоны и улучшить состояние нашего парка.

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