Внутригородские перевозки в Oracle SNO – моделирование и оптимизация транспортной логистики

sno-intracity-feature Недавно я занимался задачей по планированию и оптимизации транспортной логистики на горизонте нескольких недель в системе Oracle SNO (Strategic Network Optimization). У потенциального заказчика было множество интересных и сложных требований – доступность маршрутов, скорость машин (наполненных и порожних), спецоборудование, ограничения по погрузке/разгрузке, маршрутизация и т.д. Построив такую модель в SNO, я подумал о том, что можно также построить модель и для более оперативного контура планирования. Именно такая модель будет иллюстрирована в данной статье – модель оперативного планирования транспортных перевозок в Oracle SNO – и то, что Oracle SNO может стать очень ценным дополнением к TMS-системе.

Дополнительно в статье я кратко опишу свое решение по интеграции Oracle SNO и Google Maps.

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

Бизнес-сценарий:

  • 2 машины
  • 2 маршрута
  • Дополнительно 1 альтернативный маршрут
  • 2 заявки (заказа) доставки груза в разные точки

Доступны две машины, необходимо доставить груз по двум заказам, при этом транспорт может поехать по двум разным маршрутам (#1) для доставки Заказа 1. И одним маршрутом (#2) для доставки Заказа 2. После чего транспортные единицы возвращаются в гараж до 13.00.

В SNO построена модель, соответствующая описанному выше сценарию. Из РЦ машины едут по маршруту 1 (с возможностью выбора альтернативного маршрута) или по маршруту 2, при этом машина может поехать сначала как по первому, так и по второму маршруту, выбор очередности происходит по приоритету (время доставки) исполнения заказа. Далее машины должны вернуться.

Модель в интерфейсе Oracle SNO

Статус-точки нужны для анализа прохождения пути и для построения отчетов. Узел “monitor” получает информацию о том, сколько при заданных условиях и ограничениях составит потенциальный простой транспортной единицы в заданной точке при доставке заданного товара или возврате на стоянку в РЦ, как он работает, я продемонстрирую ниже.

Очень важно отметить, что в модели я не задаю жестко временные ограничения, т.е. время отправки транспорта, возвращения (за исключением физического ограничения рабочего дня – конца дня в 13.00) и доставки, таким образом, можно смоделировать и рассчитать оптимальный вариант. Т.е. система сама рассчитывает оптимальное время доставки заказов, исходя из текущих ограничений. Другими словами, модель можно использовать для того, чтобы рассчитывать время доставки по конкретным заявкам/заказам.

Интеграция Oracle SNO с Google Maps

В модели заметно большое количество узлов “working”, выше я их называл «статус-точки». На самом деле, их в модели гораздо больше и сейчас они сгруппированы с другими узлами, т.к. если показывать все логические узлы модели, то будет очень сложно что-то пояснить. Я использую эти узлы для интеграции Oracle SNO и Google Maps.

Дело в том, что на одном из прошлых проектов (внедрения системы планирования продаж и операций на базе продуктов Oracle Demantra и Oracle SNO) одним из требований Заказчика к отчетности было построение отчетов материальных потоков на географических картах. Я рассмотрел несколько вариантов и остановился на том, что оптимальный вариант – интегрировать SNO и Google Maps (у заказчика не было Oracle BI). Для интеграции используются дополнительные поля узлов или соответствующие специализированные поля узлов BLOCK.

oracle sno and google maps integration

Для решения внутригородской транспортной задачи варианты маршрутов могут быть выгружены из TMS вместе с заявками. Либо возможна более тесная интеграция с картами (Google, Яндекс) для построения возможных маршрутов из точки в точку, в таком случае из TMS будут загружены только заявки с адресами доставки.

Базовый сценарий модели

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

  • Машина 1 выезжает в 8 часов утра по маршруту #1, чтобы доставить заказ #1
  • Машина 2 выезжает в 8 часов утра по маршруту #2, чтобы доставить заказ #2
  • Обе машины должны вернуться в гараж до 13.00

Т.е. с точки зрения оптимизационной модели мы должны задать ограничение по минимальному использованию транспорта. Устанавливаем соответствующую доступность и ограничения для обеих машин. Также вводим упрощенную экономическую составляющую – затраты на одну машину 100 рублей на весь день.

blog-sno-supply

Произведем расчет и проанализируем результаты.

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

Во-первых, смотрим общие затраты по данному сценарию, они составили 200 рублей (затраты на отправку одной машины – 100 рублей за машину, другие экономические составляющие не учитываются в тестовой модели).

blog-sno-2trucks-results

Расчет был сделан менее чем за долю секунды, т.к. тестовая модель достаточно простая.

Посмотрим, как отработала модель по времени:

Рисунок S01-01 (09:00)
blog-sno-model-1-1

Рисунок S01-02 (11:00)
blog-sno-model-1-2

Рисунок S01-03 (12:00)
blog-sno-model-1-3

Во-вторых, на что необходимо сразу обратить внимание:

1. Смотрим отчет по заявкам на выезд транспорта – обе машины поедут по заданиям:blog-sno-model1-trucks-dispatched

2. На первой картинке видно, что машины выехали не в 8.00, как это возможно, а в 9.00. Проверим этот момент непосредственно по статус-точкам.

blog-sno-model1-start-point

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

Посмотрим отчеты о прохождении ключевых точек маршрутов, у меня создано два отдельных отчета, один для точек (START, RET) начала и возвращения и другой для точек (DEL) доставки.

blog-sno-model1-key-points

3. И последний пункт, на рисунке “S01-02″ видно, что отработал узел Monitor. Исследовав его содержание, мы увидим, что потенциальное время простоя – 1 час, это как раз то время, на которое был сокращен выезд транспорта. Т.е. в нормальной ситуации у машины есть еще как минимум один час утилизации (заложенная логика в данной модели в узел монитор не показывает весь потенциальный прострой, но лишь регистрирует его наличие для дальнейшего анализа). В сложных моделях подобная аналитика дает возможность оценить время простоя транспорта при текущих условиях.

blog-sno-model1-monitors

Сценарий 2. Оптимизация

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

blog-sno-model2-supply

Запустим расчет и проанализируем результат оптимизации.

blog-sno-model2-costs

Мы видим, что в данном сценарии затраты составили 100 рублей, т.е. в два раза меньше чем в исходном сценарии

1. Сразу отметим, что в данном сценарии система запланировала выезд только одной машиныblog-sno-model2-one-truck

blog-sno-model2-start

Т.е. это и является причиной 50% сокращения затрат. Проверим отчеты:

blog-sno-model2-results

Видим, что заявка на выезд выдана в 8.00 для одной машины, далее машина выехала в 8.00. Груз доставлен в 10.00 по заказу 1, далее с 10.00 до 11.00 машина перемещалась по маршруту для доставки заказа 2. В 11.00 груз был доставлен по заказу 2. В 12.00 машина вернулась в гараж.

Напоследок, думаю, что необходимо смоделировать ситуацию выбора маршрута. До сих пор машина 1 всегда ездила по маршруту 1.

blog-sno-model-1-1

Запустим событие изменений условий первого маршрута. Например, установим более длительное время прохождения по данному отрезку (в событии “road closed” инициируется время задержки – 4 часа). Запустив расчет, сразу видим, что система запланировала передвижение машины по альтернативному маршруту.

blog-sno-model2-alt-path

Итог: в данной статье мы рассмотрели возможности системы Oracle SNO (Strategic Network Optimization) для моделирования и оптимизации в системе внутригородских перевозок, точнее возможность использования системы оптимизации для решения задач контура оперативного планирования.

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