在车辆路径问题 (VRP) 中使用 Optaplanner 对车队进行长途旅行规划

Question

我正在应用带有时间 windows 的 optaplanner 的 VRP 示例，每当我在 24 小时（00:00 到 23:59）的范围内定义时间 windows 时，我都会得到可行的解决方案。 但我需要：

• 管理长途旅行，我知道从离开仓库到第一次访问之间的持续时间或访问之间的持续时间将超过 24 小时。 所以目前它没有给我可行的解决方案，因为 TW 格式是 24 小时格式。 碰巧在应用评分规则“arrivalAfterDueTime”时，“arrivalTime”总是高于“dueTime”，因为“dueTime”在（00:00到23:59）的范围内，而“arrivalTime”是第二天。

我想我应该拿每个客户的每个 TW 并添加更多的 TW，计划的每一天一个。 例如，如果我计划进行为期 3 天的旅行，那么我将在每个客户中有 3 次 windows。 像这样：如果客户 1 在 [08:00-10:00] 可用，那么说它也将在 [32:00-34:00] 和 [56:00-58:00] 可用，它们是相当于接下来几天的相同 TW。 同样，我处理时间很长，转换为毫秒。

我不知道这是否是正确的方法，我的咨询将更多地是关于解决这个约束的一些想法，也许你有类似的问题，对我来说任何想法都会非常感激。

抱歉措辞，我是说西班牙语的人。 谢谢你。

Answer 1

在没有检查示例的情况下，处理多天不应该很复杂。 这完全取决于您如何 model 您的时间变量。

例如，您可以：

• model 时间戳作为一个long值，表示为自纪元以来的秒数。 如果我没记错的话，这就是大多数示例的 model。 请注意，这不是人类可读的，但计算速度最快
• 您可以使用时间数据类型，例如LocalTime ，这是一种人类可读的时间格式，但将在 24 小时范围内工作，并且比使用原始数据类型慢
• 您可以使用日期时间数据，例如LocalDateTime ，这也是人类可读的，并且可以在任何时间范围内工作，并且也比使用原始数据类型慢。

我强烈建议不要简单地将当前日期或当前时间的 map 归零并从那里开始计数。 因此，在您的示例中，您将时间表示为 [32:00-34:00]。 这使它看起来就像您使用当天的午夜作为第 0 个小时并从那里开始计数一样。 虽然您可以这样做，但它会影响代码的调试和可维护性。 这只是我的一般建议，您不必遵循它。

我的建议是拥有自己的域模型和 map 到 Optaplanner 模型，在其中您对任何时间戳使用long值，表示为自纪元以来的秒数。