Сокращение затрат на эксплуатацию парка нефтебензиновых цистерн

Задача

Разработать прототип по сокращению эксплуатационных затрат парка цистерн

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

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

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

Структура работы, или как создавался прототип

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

• Формулирование целей пилота и основных гипотез.
• Проектирование и разработка прототипа.
• Тестирование на ретроспективных данных.
• Внедрение в ИТ-контур заказчика.

Решение

Формулирование целей, гипотез и разработка прототипа

Этап 1. Формулирование целей прототипа и основных гипотез

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

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

2. Добиться сокращения трат на железнодорожный тариф при проверке прототипа на ретроспективных данных за один месяц 2021 года.

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

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

Этап 2. Проектирование и разработка

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

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

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

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

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

Архитектура решения: целевая функция, ограничения и допущения

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

1. Затраты на порожний железнодорожный тариф. Под ними подразумевалась сумма, уплачиваемая за проезд вагона по железнодорожной сети в порожнем состоянии.

2. Затраты на промывку цистерн. Сумма затрат на промывку каждой цистерны.

3. Затраты на аренду цистерн. Сумма затрат на использование цистерн, в которой учитываются затраты на эксплуатацию и простой цистерн.

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

• Промывка цистерн. Тут мы учитываем, что не можем смешивать разные типы нефтепродуктов — например, использовать цистерну из-под мазута для налива бензина, потому что это приведет к порче нефтепродукта. Согласно с этим ограничением, система направляет цистерну на промывку перед погрузкой в зависимости от типа груза.
• Ремонт цистерн. Здесь учитываются технические параметры каждой цистерны, по которым активы своевременно отправляются на обслуживание.
• Скорость погрузки и разгрузки. В рамках прототипа используется единый норматив по всем станциям – трое суток.
• Емкость станции. Учитываем, что каждая станция обладает своей мощностью, и мы не можем подавать больше определенного количества цистерн, так как станция их просто не примет.
• План погрузки. Самое главное ограничение, так как этот пункт алгоритм должен выполнять на 100%. То есть, количество вагонов по входному плану должна совпадать с количеством вагонов на выходе.

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

Пользовательский интерфейс

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

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

Этап 3. Тестирование на ретроспективных данных

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

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

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

Результаты

Прототип с доказанной эффективностью

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

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