Главная //  Кейсы //  Сокращение затрат на эксплуатацию парка нефтебензиновых цистерн
Операционная деятельность

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

Кейс, посвященный автоматизации управления цистернами и сокращению порожнего пробега

Задача

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


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


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


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

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

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

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

Решение

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

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

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

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

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


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

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

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

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


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


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


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



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


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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

Результаты

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

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

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

Расскажите
о вашей задаче

icon /
icon /
icon /
icon /