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

Question

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

• 管理长途旅行，我知道从离开站点到第一次访问之间的持续时间或访问之间的持续时间将超过 24 小时。所以目前它没有给我可行的解决方案，因为 TW 格式是 24 小时格式。碰巧在应用评分规则“arrivalAfterDueTime”时，“arrivalTime”总是高于“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 处理时间，转换为毫秒。

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

对不起，我是说西班牙语的。谢谢。

Answer 1

如果没有检查示例，处理多天应该不会很复杂。这完全取决于您如何为时间变量建模。

例如，您可以：

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

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

我的建议是拥有您自己的域模型并将它们映射到 Optaplanner 模型，您可以在其中使用 long 值作为表示为自纪元以来的秒数的任何时间戳。