Кейс, посвященный автоматизации управления цистернами и сокращению порожнего пробега
Задача
Разработать прототип по сокращению эксплуатационных затрат парка цистерн
Нашим заказчиком выступила компания, организующая единую систему вывоза нефтепродуктов железнодорожным транспортом. Компания обслуживает крупное нефтегазовое предприятие и обязана выполнять ежемесячный план погрузки на 100%, а также отвечать за состояние подвижного состава, в котором больше десятка тысяч цистерн. Это непростая задача для оператора и команды диспетчеров: ежедневно нужно принимать множество решений по регулировке парка транспорта с учетом различных вводных, от промывок цистерн до изменений расписания РЖД.
Из-за большого количества изменений, происходящих на Ж/Д сети ежедневно, не всегда удается принять правильное решение и направить цистерну в оптимальный, с точки зрения текущей ситуации, маршрут, чтобы порожний пробег в сумме по всем вагонам был минимален. На момент обращения у заказчика присутствовала частичная автоматизация данного процесса, но она не подразумевала оптимального возврата, а лишь возвращала вагоны обратно по заранее созданным правилам. Коэффициент порожнего пробега был близок к единице, что влияло на операционную эффективность заказчика.
Наша задача состояла в следующем — сделать прототип системы по оптимизации движения парка вагонов и сократить порожний пробег. В этой статье расскажем, как решали эту задачу и чего смогли достичь.
Структура работы, или как создавался прототип
Заказчик обратился к нам осенью 2021, а готовый прототип нужно было сдать к концу года. На создание решения были даны ограниченные сроки — за 3 месяца нужно было провести весь цикл необходимых работ. Чтобы успеть, мы предложили для начала создать пилотный проект, подтвердить его эффективность и дальше пойти в разработку полноценной системы. Процесс построения прототипа был разбит на четыре этапа:
- Формулирование целей пилота и основных гипотез.
- Проектирование и разработка прототипа.
- Тестирование на ретроспективных данных.
- Внедрение в ИТ-контур заказчика.
Решение
Формулирование целей, гипотез и разработка прототипа
Этап 1. Формулирование целей прототипа и основных гипотез
Целей у прототипа было две:
1. Предстояло создать работающий прототип, который получает входные данные по плану и дислокации вагонов и на выходе формирует оптимальные рейсы вагонов и выступает как рекомендательная система.
2. Добиться сокращения трат на железнодорожный тариф при проверке прототипа на ретроспективных данных за один месяц 2021 года.
Вместе с этим были сформулированы следующие гипотезы:
- Сможем учесть ключевые ограничения и посчитать по ним оптимальную модель, и таким образом подтвердим, что математическая оптимизация возможна.
- Сможем сократить затраты на передвижение цистерн на какой-то процент. Для этого мы планировали взять ретроспективные данные августа, проанализировать их и сравнить с результатами от работы прототипа.
Этап 2. Проектирование и разработка
Компания, обратившаяся к нам, осуществляет организацию вывоза нефтегазовой продукции с помощью железнодорожного транспорта, вагонов-цистерн. Для разработки пилота нужно было понять, как происходил процесс по выполнению плана погрузки — одного из важнейших показателей для заказчика. Планирование подачи цистерн к точкам погрузки осуществлялось на основе заявок от компаний-производителей нефтепродуктов на ближайший месяц. Заявка содержала различные данные по характеристике груза и погрузке. Исходя из информации в заявке, формировался план подачи парка цистерн на месяц, декаду или сутки. В течение месяца план корректировался в зависимости от задержек РЖД, новых заявок или внеплановых ремонтов цистерн. Отслеживание цистерн и корректировка плана подачи осуществлялась в рамках процесса ежедневной диспетчеризации.
Происходило это следующим образом: диспетчеры получали файл, содержащий дислокацию каждой цистерны парка и ее технические характеристики. На основе этой информации специалисты определяли, выполнялся ли план по подаче порожних цистерн, а также достаточно ли вагонов для выполнения исходного плана. При обнаружении отклонений диспетчер корректировал прогноз подачи цистерн на станции погрузки путем увеличения количества вагонов, направленных на станцию, или перенаправлял цистерны с других направлений на требуемую станцию.
На основе этих данных была сформирована целевая картина взаимодействия:
- На входе от заказчика поступает два документа: план погрузки вагонов — точки, где в течение месяца будет производиться налив нефтепродуктов, а также таблица с дислокацией вагонов, где дана информация о местонахождении и состоянии каждого вагона.
- Полученные данные проводим через прототип, где учитываются основные ограничения и допущения.
- На выходе получаем выходной документ, где показан оптимальный маршрут для каждой цистерны.
На втором этапе происходило самое интересное: собственно обработка входных документов с учетом параметров, которые затрудняли принятие оптимального решения диспетчерам.
Архитектура решения: целевая функция, ограничения и допущения
Под целевой функцией определили сумму эксплуатационных затрат по каждому рейсу вагона. Затраты состояли из трех частей:
1. Затраты на порожний железнодорожный тариф. Под ними подразумевалась сумма, уплачиваемая за проезд вагона по железнодорожной сети в порожнем состоянии.
2. Затраты на промывку цистерн. Сумма затрат на промывку каждой цистерны.
3. Затраты на аренду цистерн. Сумма затрат на использование цистерн, в которой учитываются затраты на эксплуатацию и простой цистерн.
Ограничения алгоритма:
- Промывка цистерн. Тут мы учитываем, что не можем смешивать разные типы нефтепродуктов — например, использовать цистерну из-под мазута для налива бензина, потому что это приведет к порче нефтепродукта. Согласно с этим ограничением, система направляет цистерну на промывку перед погрузкой в зависимости от типа груза.
- Ремонт цистерн. Здесь учитываются технические параметры каждой цистерны, по которым активы своевременно отправляются на обслуживание.
- Скорость погрузки и разгрузки. В рамках прототипа используется единый норматив по всем станциям – трое суток.
- Емкость станции. Учитываем, что каждая станция обладает своей мощностью, и мы не можем подавать больше определенного количества цистерн, так как станция их просто не примет.
- План погрузки. Самое главное ограничение, так как этот пункт алгоритм должен выполнять на 100%. То есть, количество вагонов по входному плану должна совпадать с количеством вагонов на выходе.
В числе допущений мы учли такие параметры, как единую скорость движения цистерн, единую стоимость промывки и равномерность подачи в плане отгрузки.
Пользовательский интерфейс
Помимо внутренней работы прототипа было необходимо продумать пользовательский интерфейс в соответствии с запросом заказчика. В нашем случае должен прототип должен был быть реализован в виде файла на рабочем столе, в который можно было загружать файлы и выгружать из него итоговую рекомендацию.
Ключевыми результатами первого этапа работ были: подготовленное техническое задание со всеми прописанными требованиями к прототипу и собственно zip-файлы прототипа. Далее нужно было протестировать полученный прототип на ретроспективных данных.
Этап 3. Тестирование на ретроспективных данных
Методика тестирования представляла собой A/B тестирование на данных за один месяц. В версии А мы рассчитали затраты: взяли журнал рейсов подвижного состава заказчика и в Excel посчитали, сколько составили затраты.
Далее мы по тем же данным посчитали, сколько бы потратил заказчик, если бы использовал наш прототип в том же месяце. Это была версия В.
По итогам получилась разница в 30%. Эта цифра может показаться очень большой, но здесь следует понимать, что мы закладывали идеальные ограничения и допущения. Например, мы взяли самые простые правила промывки, не учитывали емкость станций, а срок для погрузки и разгрузки у нас был единый — три дня, что не всегда совпадает с реальностью.
Результаты
Прототип с доказанной эффективностью
В итоге работы над кейсом мы добились поставленных изначально целей: разработали прототип, который на перспективных данных показал эффективность в 30%. Полученный пилот был передан заказчику для тестирования.
Также было принято решение о создании полноценной системы, которая будет учитывать все расширенные ограничения и содержать интерфейс верификации рейсов. Помимо этого в будущей системе будет предусмотрена возможность работы через браузер.