Модель бизнес-логики с атрибутами перехода

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

Прежде чем начать

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

Переход — это участок маршрута, соединяющий одно место с другим.

Под местоположением понимается любая из следующих точек на маршруте транспортного средства:

  • Начальная точка маршрута.
  • Остановка, где осуществляется погрузка или разгрузка.
  • Конечная точка маршрута.

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

Моделирование реальных сценариев

В этом разделе представлены два небольших примера реализации реальных бизнес-ограничений с использованием атрибутов переходов.

Зарезервируйте время для парковки

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

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

Для этого выполните следующие действия в запросе к API оптимизации маршрутов:

  1. Используйте VisitRequest.duration только для времени, необходимого для выполнения визита. Например, для передачи посылки и получения подписи от клиента.

  2. Для каждого отдельного парковочного места, используемого в модели, присвойте ему новый тег, который не используется ни для чего другого в модели, например, PARKING_123 .

  3. Добавьте этот тег к следующему:

    1. VisitRequest.tags добавлять во все запросы на посещение, использующие это парковочное место.

    2. Vehicle.start_tags , если транспортное средство начинает свой маршрут с этой парковочной точки.

    3. Если транспортное средство начинает движение и заканчивает свой маршрут на этом месте парковки, Vehicle.end_tags

  4. Для каждого нового парковочного талона добавьте в ShipmentModel.transition_attributes запись, которая добавляет задержку при парковке с другого парковочного места, выполнив следующие действия:

    1. Установите для TransitionAttributes.excluded_src_tag и TransitionAttributes.dst_tag значение PARKING_123 .

    2. Установите параметр TransitionAttributes.delay равным времени, необходимому для парковки автомобиля.

    Например, если метка местоположения — PARKING_123 , и на парковку транспортного средства требуется 150 секунд, добавьте следующую запись в ShipmentModel.transition_attributes :

    {
      "excluded_src_tag": "PARKING_123",
      "dst_tag": "PARKING_123",
      "delay": "150s"
    }
    

Обязательная уборка в конце маршрута.

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

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

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

  1. Выберите два новых тега, которые нигде в модели не используются, например, CLEANED и ROUTE_END . Первый предназначен для мест, где транспортное средство чистое или становится чистым, а второй — для конца маршрута.
  2. Для каждого транспортного средства добавьте новую отправку только для доставки, которая представляет собой посещение химчистки со следующими характеристиками:
    1. Каждое местоположение клинингового предприятия должно быть представлено как запрос на доставку данной партии груза.
    2. Добавьте CLEANED в VisitRequest.tags каждого запроса на посещение пункта приема отходов химчистки. Это означает, что транспортное средство, покидающее это место, чистое. Другие запросы на посещение в модели не должны использовать этот тег, чтобы транспортное средство считалось «нечистым» при их отъезде.
    3. Разрешите оптимизатору пропускать эту отправку, если транспортное средство не используется, установив значение параметра penalty_cost на небольшое число.
  3. Для каждого транспортного средства добавьте CLEANED в Vehicle.start_tags . Это используется для пометки транспортного средства как чистого перед выполнением любых погрузок или разгрузок, предполагая, что оно было очищено в конце предыдущего рабочего дня, и позволяет ему двигаться от начальной точки маршрута непосредственно к конечной. Даже если такие маршруты не встречаются на практике, разрешение этого сценария помогает оптимизатору более эффективно искать оптимизированные маршруты.

  4. Для каждого транспортного средства добавьте ROUTE_END в Vehicle.end_tags .

  5. Добавьте в свойство ShipmentModel.transition_attributes новую запись, запрещающую прибытие транспортных средств к конечной точке маршрута, если они не чистые, со следующими свойствами:

    1. Установите для TransitionAttributes.excluded_src_tag значение CLEANED .

    2. Установите TransitionAttributes.dst_tag в ROUTE_END .

    3. Установите для TransitionAttributes.delay большое значение. Если вы установите задержку больше максимальной продолжительности маршрута, вы фактически запретите оптимизатору использовать этот переход в маршруте.

    Например, если временной масштаб модели составляет один рабочий день, можно использовать задержку в 24 часа (86400 секунд), чтобы запретить переход к концу маршрута из любого места, кроме пункта уборки и начала маршрута:

    {
      "excluded_src_tag": "CLEANED",
      "dst_tag": "ROUTE_END",
      "delay": "86400s"
    }
    

Как выбрать между задержками и затратами

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

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

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

Как добавить атрибут перехода, который будет соответствовать всем запросам посещения?

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

Нельзя просто опустить теги, потому что каждое сообщение TransitionAttributes должно содержать один из тегов TransitionAttributes.src_tag и TransitionAttributes.excluded_src_tag , а также один из тегов TransitionAttributes.dst_tag и TransitionAttributes.excluded_dst_tag .

Однако вы можете сопоставить все теги, установив для параметров TransitionAttributes.excluded_src_tag или TransitionAttributes.excluded_dst_tag значение тега, который нигде в модели не используется. Это позволит сопоставить все местоположения, у которых нет этого тега, но поскольку вы намеренно выбрали тег, который не используется ни в одном местоположении, эти атрибуты перехода будут соответствовать всем местоположениям.

Дополнительная информация