Использование Optaplanner для планирования длительных поездок парка транспортных средств в Задаче маршрутизации транспортных средств (VRP)

Я применяю VRP-пример optaplanner с временными окнами и получаю возможные решения всякий раз, когда я определяю временные окна в диапазоне 24 часов (с 00:00 до 23:59). Но мне нужно:

  • Управляйте длительными поездками, когда я знаю, что время между выездом со склада и первым посещением или продолжительность между посещениями будет более 24 часов. Так что в настоящее время он не дает мне эффективных решений, потому что формат TW имеет 24-часовой формат. Бывает, что при применении правила оценки arrivalAfterDueTime время прибытия всегда выше, чем dueTime, потому что dueTime находится в диапазоне (с 00:00 до 23:59), а arrivalTime - это следующий день.

Я подумал, что мне следует взять каждый TW каждого клиента и добавить к нему еще TW, по одному на каждый запланированный день. Например, если я планирую поездку на 3 дня, то у меня будет 3 временных окна для каждого Клиента. Примерно так: если Клиент 1 доступен с [08: 00-10: 00], то предположим, что он также будет доступен с [32: 00-34: 00] и [56: 00-58: 00], которые являются эквивалент той же TW на последующие дни. Точно так же я обрабатываю время как long, преобразованное в миллисекунды.

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

Извините за формулировку, я говорю по-испански. Спасибо.


optaplanner
person Gloria Leyva    schedule 11.02.2021    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

Например, вы можете:

  • смоделируйте отметки времени как значение long, обозначенное как секунды с начала эпохи. Вот как большинство примеров являются модельными, если я правильно помню. Обратите внимание, что это не очень удобно для чтения человеком, но быстрее всего вычисляется с
  • вы можете использовать тип данных времени, например LocalTime, это удобочитаемый формат времени, но он будет работать в 24-часовом диапазоне и будет медленнее, чем при использовании примитивного типа данных.
  • вы можете использовать данные даты и времени tpe, например LocalDateTime, они также удобочитаемы и будут работать в любом временном диапазоне, а также будут медленнее, чем при использовании примитивного типа данных.

Я настоятельно рекомендую не просто сопоставить текущий день или текущий час с нулевым значением и начинать отсчет оттуда. Итак, в вашем примере вы обозначаете время как [32: 00-34: 00]. Это заставляет его выглядеть так, как будто вы используете полночь текущего дня в качестве 0-го часа и начинаете отсчет оттуда. Хотя вы можете это сделать, это повлияет на отладку и ремонтопригодность вашего кода. Это всего лишь мой общий совет, вам не обязательно ему следовать.

Я бы посоветовал иметь свои собственные модели предметной области и сопоставлять их с моделями Optaplanner, где вы используете значение long для любой метки времени, которая обозначается как секунды с начала эпохи.

person k88    schedule 13.02.2021