Как увеличить операционную эффективность оператора подвижного состава

Кейс F5Devs, посвященный разработке прототипа по сокращению эксплуатационных затрат парка цистерн

Нашим заказчиком выступила компания, организующая единую систему вывоза нефтепродуктов железнодорожным транспортом. Компания обслуживает крупное нефтегазовое предприятие и обязана выполнять ежемесячный план погрузки на 100%, а также отвечать за состояние подвижного состава, в котором больше десятка тысяч цистерн. Это непростая задача для оператора и команды диспетчеров: ежедневно нужно принимать множество решений по регулировке парка транспорта с учетом различных вводных, от промывок цистерн до изменений расписания РЖД.

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

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

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

Целей у прототипа было две:

Вместе с этим были сформулированы следующие гипотезы:

Компания, обратившаяся к нам, осуществляет организацию вывоза нефтегазовой продукции с помощью железнодорожного транспорта, вагонов-цистерн. Для разработки пилота нужно было понять, как происходил процесс по выполнению плана погрузки — одного из важнейших показателей для заказчика. Планирование подачи цистерн к точкам погрузки осуществлялось на основе заявок от компаний-производителей нефтепродуктов на ближайший месяц. Заявка содержала различные данные по характеристике груза и погрузке. Исходя из информации в заявке, формировался план подачи парка цистерн на месяц, декаду или сутки. В течение месяца план корректировался в зависимости от задержек РЖД, новых заявок или внеплановых ремонтов цистерн. Отслеживание цистерн и корректировка плана подачи осуществлялась в рамках процесса ежедневной диспетчеризации.

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

На основе этих данных была сформирована целевая картина взаимодействия:

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

Под целевой функцией определили сумму эксплуатационных затрат по каждому рейсу вагона. Затраты состояли из трех частей:

Ограничения алгоритма

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

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

Ключевыми результатами первого этапа работ были: подготовленное техническое задание со всеми прописанными требованиями к прототипу и собственно zip-файлы прототипа. Далее нужно было протестировать полученный прототип на ретроспективных данных.

Методика тестирования представляла собой A/B тестирование на данных за один месяц. В версии А мы рассчитали затраты: взяли журнал рейсов подвижного состава заказчика и в Excel посчитали, сколько составили затраты.

Далее мы по тем же данным посчитали, сколько бы потратил заказчик, если бы использовал наш прототип в том же месяце. Это была версия В.

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

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

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

Проще всего — написать нам на contact@f5devs.ru или оставить заявку на нашем сайте. Мы оперативно свяжемся с вами, чтобы обсудить проект.
В нашей команде работают сильнейшие специалисты — выпускники МГУ, МФТИ, ВШЭ и ШАД Яндекса с опытом работы в промышленности и логистике. Мы поможем вам сформулировать задачу, разработаем и протестируем несколько гипотез и создадим сервис, который повысит показатели вашей компании. Если вы пока не решили, можно ли решить ваш запрос с помощью алгоритма, вы можете взять консультацию — мы давно работаем с лидерами рынка и понимаем специфику возможных задач.