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

Question

I am applying the VRP example of optaplanner with time windows and I get feasible solutions whenever I define time windows in a range of 24 hours (00:00 to 23:59). But I am needing:

• Manage long trips, where I know that the duration between leaving the depot to the first visit, or durations between visits, will be more than 24 hours. So currently it does not give me workable solutions, because the TW format is in 24 hour format. It happens that when applying the scoring rule "arrivalAfterDueTime", always the "arrivalTime" is higher than the "dueTime", because the "dueTime" is in a range of (00:00 to 23:59) and the "arrivalTime" is the next day.

I have thought that I should take each TW of each Customer and add more TW to it, one for each day that is planned. Example, if I am planning a trip for 3 days, then I would have 3 time windows in each Customer. Something like this: if Customer 1 is available from [08:00-10:00], then say it will also be available from [32:00-34:00] and [56:00-58:00] which are the equivalent of the same TW for the following days. Likewise I handle the times with long, converted to milliseconds.

I don't know if this is the right way, my consultation would be more about some ideas to approach this constraint, maybe you have a similar problematic and any idea for me would be very appreciated.

Sorry for the wording, I am a Spanish speaker. Thank you.

Answer 1

Without having checked the example, handing multiple days shouldn't be complicated. It all depends on how you model your time variable.

For example, you could:

• model the time stamps as a long value denoted as seconds since epoch. This is how most of the examples are model if I remember correctly. Note that this is not very human-readable, but is the fastest to compute with
• you could use a time data type, eg LocalTime , this is a human-readable time format but will work in the 24-hour range and will be slower than using a primitive data type
• you could use a date time data tpe, eg LocalDateTime , this is also human-readable and will work in any time range and will also be slower than using a primitive data type.

I would strongly encourage to not simply map the current day or current hour to a zero value and start counting from there. So, in your example you denote the times as [32:00-34:00]. This makes it appear as you are using the current day midnight as the 0th hour and start counting from there. While you can do this it will affect debugging and maintainability of your code. That is just my general advice, you don't have to follow it.

What I would advise is to have your own domain models and map them to Optaplanner models where you use a long value for any time stamp that is denoted as seconds since epoch.