VRt.Universal [UV] (6.20.2289)

Описание

Программный интерфейс для универсального планирования рейсов.

Возможности

  • Возможность забора груза из любой локации
  • Возможность разгрузки в любой локации
  • Парные заявки нескольких типов: PICKUP (погрузка), DROP (выгрузка)
  • Одиночные заявки нескольких типов: DROP_FROM_BOX (выгрузка груза, который уже находится в кузове), PICKUP_TO_BOX (забор груза в кузов без последующей выгрузки), WORK (работа на локации без перемещения груза)
  • Комплексный заказ может состоять из любого числа заявок любых типов
  • Транспорт и исполнители разделены на разные сущности, при планирование происходит оптимальное назначение исполнителя на транспорт
  • У транспорта несколько отсеков - каждый из которых может вмещать груз и обладает собственными характеристиками
  • Учёт совместимости груза с транспортом по параметрам габарита груза (длина, ширина, высота, дополнительные параметры вместимости)
  • Учёт совместимостей груз-отсек транспорта (возможность учесть свойства отсека: холодильник, термо-сумка, крепежи и т.п)
  • Заявки-заменители, т.е. возможность выполнить одну из заявок-заменителей, выбор которой происходит на основе её географического местоположения и временного окна

Поддержка ограничений

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

  • Место старта/финиша
  • Учет передвижения исполнителя до точки старта транспорта
  • График доступности исполнителя - список временных окон, в которые исполнитель может совершать перемещения и совершать работу на локациях
  • Максимальная продолжительность работы исполнителя в течение заданного временного периода

Ограничения на транспорт:

  • Место старта/финиша
  • График доступности транспорта - список временных окон, в которые транспорт может совершать перемещения
  • Максимальная протяженность маршрута
  • Несколько отсеков в транспорте, каждый со своими параметрами
  • Ограничение сверху на суммируемые вместимости (вес, объем, количество заказов, количество заявок)

Ограничения на заказ:

  • Жесткие временные окна
  • Возможность указать разные допустимые окна работы локации и окна желаемого выполнения заявки
  • Учет порядка исполнения заявок в пределах маршрута
  • Список желаемых временных окон выполнения с разными стоимостями для каждого из них

Используемые совместимости

Сущности являются совместимыми, если список свойств одной сущности полностью покрывает список требований другой сущности (наоборот для performer_blacklist - списки не должны пересекаться).

Поддерживаемые совместимости:

НазваниеТребованияСвойства
Заказ - Исполнительorder.performer_restrictionsperformer.performer_features
Заказ - Не Исполнительorder.performer_blacklistperformer.performer_features
Груз - Отсекorder.cargo.box_restrictionstransport.box.box_features
Локация - Транспортlocation.transport_restrictionstransport.transport_features
Транспорт - Исполнительtransport.performer_restrictionsperformer.performer_features
Исполнитель - Транспортperformer.transport_restrictionstransport.transport_features
Заказ - Заказorder.order_restrictionsorder.order_features
Груз - Грузcargo.cargo_restrictionscargo.cargo_features

Примеры бизнес правил:

НазваниеПример бизнес-правила
Заказ - ИсполнительДля выполнения заказа водитель должен иметь особое разрешение
Заказ - Не ИсполнительВодитель в черном списке
Груз - ОтсекДля перевозки замороженной продукции необходим отсек с особым температурным режимом
Локация - ТранспортОграничения на высоту транспорта
Транспорт - ИсполнительДля грузового транспорта водитель должен иметь категорию C
Исполнитель - ТранспортВодителю разрешено работать только на определенном транспорте
Заказ - ЗаказНельзя перевозить рыбу и фрукты в одном отсеке
Груз - ГрузДва груза нельзя одновременно размещать в одном отсеке транспорта, по очереди - можно

Назначения

Механизм назначений (hardlinks) необходим для указания требований по нахождению заказов, исполнителя и транспорта в одном рейсе.

Назначение гарантирует нахождения сущностей в одном рейсе и не гарантирует факт планирования сущности. Например, если исполнитель не успевает выполнить заказ, то он не запланируется, но назначится на рейс (попадет в waitlist).

Также назначение не отменяет указанные совместимости (и штрафы за нарушение совместимостей). Например, если заказ не может быть выполнен исполнителем, он не запланируется, но назначится на рейс (попадет в waitlist).

Размещение грузов в кузове

Список способностей объекта вращаться (с шагом в 90 градусов):

  • ALL - можно поворачивать по любой оси любое количество раз
  • YAW - можно повернуть один раз по вертикальной оси (вокруг своей оси)
  • PITCH - можно повернуть один раз по поперечной оси (поставить вертикально)
  • ROLL - можно повернуть один раз по продольной оси (положить на бок)

rotation

Модель рейса

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

Возможные значения флагов, отвечающих за географическое положение:

  • AROUND_LOCATION - исполнитель находится рядом с локацией - в процессе парковки или выезда с нее.
  • INSIDE_LOCATION - исполнитель находится на локации.

Возможные значения флагов, отвечающих за нахождения во временных окнах:

  • INSIDE_WORKING_WINDOW - исполнитель находится внутри рабочего временного окна.
  • INSIDE_LOCATION_WINDOW - исполнитель находится внутри времени работы локации.
  • INSIDE_EVENT_HARD_WINDOW - исполнитель находится внутри жесткого временного окна.
  • INSIDE_EVENT_SOFT_WINDOW - исполнитель находится внутри мягкого временного окна.

Возможные значения флагов, отвечающих за действия:

  • ON_DEMAND - исполнитель работает над заявкой.
  • WAITING - исполнитель находится в режиме ожидания.
  • RELOCATING - исполнитель перемещается к следующей остановке.
  • BREAK - исполнитель находится на перерыве.

Пример маршрута с множеством состояний в каждый момент времени

ВремяНабор активных флаговЛокация / Заказ / Заявка / СобытиеКомментарий
10:00INSIDE_LOCATION
AROUND_LOCATION
2 / - / - / -Стартовая локация
10:10RELOCATING- / - / - / -Едем к первому заказу
10:20AROUND_LOCATION2 / - / - / -Подъехали к первому заказу
10:40AROUND_LOCATION
INSIDE_LOCATION
WAITING
2 / - / - / -Припарковались
11:00AROUND_LOCATION
INSIDE_LOCATION
INSIDE_LOCATION_WINDOW
WAITING
INSIDE_EVENT_HARD_WINDOW
2 / - / - / -Дождались начала окна локации и одновременно доступности заказа
11:25AROUND_LOCATION
INSIDE_LOCATION
INSIDE_LOCATION_WINDOW
ON_DEMAND
INSIDE_WORKING_WINDOW
INSIDE_EVENT_HARD_WINDOW
2 / 1 / 2 / 3Дождались смены исполнителя
11:30AROUND_LOCATION
INSIDE_LOCATION
INSIDE_LOCATION_WINDOW
ON_DEMAND
INSIDE_WORKING_WINDOW
INSIDE_EVENT_HARD_WINDOW
INSIDE_EVENT_SOFT_WINDOW
2 / 1 / 2 / 3Пока работали - случилось мягкое окно
11:40AROUND_LOCATION
INSIDE_LOCATION
INSIDE_LOCATION_WINDOW
INSIDE_WORKING_WINDOW
2 / - / - / -Закончили работать
11:45AROUND_LOCATION
INSIDE_WORKING_WINDOW
2 / - / - /-Выехали с парковки
11:45RELOCATING
INSIDE_WORKING_WINDOW
- / - / - / -Едем на следующий заказ

Конфигурация планирования

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

Название конфигурации планирования передается в поле trips_settings.configuration.

Основные конфигурации:

НазваниеЗадача
optimize_distanceРасставить как можно больше заказов, затем оптимизировать суммарный пробег (количество транспорта выбирается исходя из пробега), используется по умолчанию
optimize_transportsРасставить как можно больше заказов, при этом использовать как можно меньше транспорта, при прочих равных оптимизировать время работы исполнителей
optimize_locality_groupingРасставить как можно больше заказов, при этом стремиться оптимизировать визуальную группировку маршрутов, но не их количество
optimize_cars_then_distanceРасставить как можно больше заказов, затем оптимизировать количество транспорта, затем пробег
optimize_timeРасставить как можно больше заказов, затем оптимизировать суммарное время работы исполнителей
optimize_cars_then_timeРасставить как можно больше заказов, затем оптимизировать количество транспорта, затем суммарное время работы исполнителей
optimize_moneyОптимизировать величину "прибыль - затраты", складывается из наград за заявки и расходов на исполнителей и транспорты (оптимизируемая величина неотрицательна)

Дополнительные конфигурации:

НазваниеЗадача
visual_groupingРасставить как можно больше заказов, при этом использовать как можно меньше транспорта и маршруты должны быть визуально сгруппированы
optimize_visual_groupingРасставить как можно больше заказов, затем равномерно распределить заказы с учетом зон транспортной доступности (как visual_grouping, но визуальная группировка рассчитывается иначе)
optimize_cars_then_locality_groupingРасставить как можно больше заказов, затем оптимизировать количество транспорта, затем визуальную группировку маршрутов
optimize_cars_then_single_location_grouping_sequencedРасставить как можно больше заказов, затем оптимизировать количество машин, а затем надёжность

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

Для разработки рекомендуется использовать optimize_cars_then_distance, так как данная конфигурация не требует детального подбора тарифов и стоимостей заказов.

Валидация данных

Валидация входных данных состоит из нескольких этапов, которые описаны ниже.

1. Проверка по схеме

Если запрос не проходит по схеме, то планирование не запускается целиком и такая ошибка возвращается вместе с кодом 400 в schema_errors.

Мы рекомендуем проверять запрос по схеме (или yaml-файлу) перед отправкой на сервер.

2. Проверка на логические ошибки, которые не позволяют продолжить планирование

Корректные по схеме данные проходят второй этап проверки на возможность запуска планирования.

Пример ошибок на данном этапе - ключи, ведущие на пустые сущности, или если все заказы несовместимы со всеми исполнителями, т.е. то, что делает задачу планирования бессмысленной.

Данные ошибки возвращаются вместе с кодом 400 в logical_errors.

3. Проверка на логические ошибки, которые не позволяют продолжить планирование

На третьем этапе происходит проверка каждой сущности отдельно.

Все сущности, которые не прошли проверку - вырезаются из исходной задачи и не отправляются на планирование.

В зависимости от настройки treat_warnings_as_errors результаты данного типа проверки возвращаются в warnings вместе с кодом 400, либо вместе с результатом планирования.

4. Проверки в процессе планирования

Часть проверок можно осуществить только в процессе планирования.

Например - что согласно указанным тарифам и по актуальному прогнозу пробок физически невозможно доехать до определенной точки.

Результаты данных проверок возвращаются в warnings либо вместе с результатом планирования.

Диаграмма сущностей