Nextmv Cloud is the fastest way to get hands on with the Nextmv decision stack. Our Dispatch app on Nextmv Cloud offers an out-of-the-box experience for route planning and optimization and supports a growing list of common constraints for representing the reality of your business.
In a previous blog post, we explored a few common routing problem constraints, such as capacity and speed. In this post, we’ll explore target times, hard time windows, timeliness penalties, and unassigned penalties.
If you haven't already, sign up for a free Nextmv Cloud account and follow along!
When you log into Nextmv Cloud, you’ll land on the page with an input data selector and an empty map. This is the place where many routing problems — great and small — begin.
Within our Dispatch app, we’re optimizing for a KPI or business objective that minimizes our fleet’s combined travel time. This is measured in seconds and represented as the
value in Nextmv Cloud. Several factors contribute to total travel time, including vehicle speeds, how long a vehicle spends at each stop, how punctual a vehicle is at each stop, and/or if a stop doesn’t get assigned to a vehicle. We’ll be keeping an eye on each of these as we walk through this example.
OK, let’s dive in. Under Input Data, choose the file called “Fleet with Pickup/Delivery & Time Windows.” You’ll see a new input file appears and includes several default settings that apply default properties to all vehicles and stops.
For our vehicles, there’s a defined start and end location (they’re the same in this case, so it’s a depot scenario), a shift start and end (amounting to a two-hour window), and average vehicle speed (in meters per second).
For our stops, there’s a defined stop duration of 120 seconds and several penalty fields that follow, including:
unassigned penalty: The cost applied to the value function in seconds for not visiting a stop. While the units here don't measure an actual span of time for not visiting a stop, it provides a way to represent the severity of missing a stop in the final value function.
earliness penalty: The cost applied to the value function for arriving at a stop too early and having to wait. This is a scalar value that's applied to every second before a target time.
lateness penalty: The cost applied to the value function for arriving at a stop too late. This is a scalar value that's applied to every second beyond a target time.
We’ll come back to the specifics of these penalties shortly.
We now have an understanding for our default settings. Let’s do two more things:
Now, click the teal “Run” button. You should see routes (generated using a Haversine measure) appear on the map. But it’s also clear that our order fulfillment didn’t exactly go according to plan. Curious... Let's see what happened.
In our input file, we are looking to route 2 vehicles to visit 13 stops, which represents 5 orders. The resulting routes on the map show us that the 3 stops for order 3 do not get visited. What happened?
To investigate, scroll down to our Output Data located below the map. Click into
state and expand each of the sections. Within
vehicles we learn the following about the routes:
So we’ve confirmed that no vehicles handled order 3, which consisted of three stops (2 pickups and 1 dropoff). This means order 3 was unassigned. This is also reflected under the
unassigned section of the output. And based on what we covered in the defaults, this means we’ve incurred an unassigned penalty.
To see the impact, click into
value_summary. You’ll see a list of several fields and values. For now, let’s focus on a few. We can see that
total_unassigned_penalty: 600000, which accounts for 3 unassigned stops multiplied by the unassigned penalty of 200,000 seconds we set in the default. This means if our fleet had visited those 3 stops, our
value: 620284 would be 600,000 seconds smaller. Let’s put this to the test by assigning order 3.
First, we need to understand why the order 3 stops weren’t assigned. If you have a detailed look at the vehicle and stop details in the input file (which we’ve not thus far), you’ll see we have a capacity issue. Our vehicle capacities are set to 85 units. Order 3’s pickups total 156 units. Our vehicles couldn’t accommodate those quantities, so those stops went unassigned.
While this may not be exactly what you’d do in the real world, let’s change both vehicle capacities to be 160. Click “Run”. You should see the following:
And if you look at the value function, you’ll see it’s decreased to 27,574 seconds and our unassigned penalty dropped to 0. This is a lot better compared to our previous value of 620,284 seconds!
But why didn’t the value drop by a clean 600,000 seconds? To understand this, let’s have a proper look at the earliness and lateness penalties.
At the start of this post, we reviewed the information in the defaults section of the input file and deleted a bunch of vehicle and stop information. But we didn’t look too closely at the details of what remained. That time has come.
vehicles section of the input is familiar to us since we just modified the vehicle capacity. Let’s look at the
stops section. The stops for each order contains the following information:
idto uniquely identify the stop using free-form text (useful for denoting pickups and dropoffs)
positionof the stop using geo coordinates
precedesto specify if a stop must precede another (when multiple stops share the same value for precedes, it indicates multiple pickups before a dropoff)
quantityindicating how many units will be picked up (a negative value to indicate consuming capacity from a vehicle) or dropped off (a positive value to indicate returning capacity to a vehicle)
target_timeto specify the date and time when the vehicle ideally visits the stop
hard_windowto specify a date and time range for when the vehicle must visit the stop
We know that earliness and lateness penalties are calculated using a scalar that’s applied to every second a vehicle arrives at a stop before or after a defined
target_time. Let’s have a look at the earliness penalties we have for our current scenario. In the Output Data, we can see that we incur a
total_earliness_penalty of about 7,091 seconds. If you really dig into the details of the output for each
vehicle, you’ll learn that this is derived from the dropoff stops for orders 1, 2, and 3.
Our current value in this state is 27,574 seconds. What if we zeroed out our earliness penalties? Let’s try. Set the `earliness_penalty: 0” in your input in the default section. Now click “Run”. Once the job is complete, view the output, and you should see our new value is 20,484 seconds — essentially 7,091 seconds less than our value before.
This post explored timeliness penalties that account for earliness, lateness, and unassigned stops that you can configure with the Dispatch app on Nextmv Cloud. In future posts, we’ll explore other constraints such as compatibility attributes for defining delivery zones or ensuring ice cream gets picked up by a vehicle with a freezer), in addition to ways to evaluate the outputs that make up the overall value function. This includes the makeup of penalties in your final solution and how long you let your app run impacts the quality of solutions over time.
We’re incorporating new functionality all the time to help you reflect the reality of your business and streamline the decision-making workflows that power it. Let us know what you’d like to see us add to Nextmv in the future by contacting us.
Learn how to route a fleet of vehicles while working with time windows, time penalties, and unassigned penalties using the Dispatch app on Nextmv Cloud.
It’s important to create opportunities to connect when building a distributed company. Retreats are one way to do that, even if they’re virtual. Here’s an in-depth look at our exact agenda for our first virtual retreat at Nextmv and what we learned in the process.
We’ve released Hop v0.7.1! This release introduces a new assigner framework for Hop to make it easier for customers to add custom business logic to assignment problems within our fleet engine.
You have two vehicles and ten locations to visit. What's the best way to route your fleet? You have seconds to solve and Nextmv Cloud. Ready, set, go!
Transporting raw milk from farms to processing plants is a daily occurrence that seems simple at first glance. But it gets complex quickly when time is of the essence and milk volumes vary.
We've released Hop v0.7.0! This release introduces a cool new feature we call expanders into Hop to help customers manage time to first feasible solution and memory use as they scale their models.
Building decision models into binaries is a beautiful thing. It eliminates a lot of sticky deployment processes and gets you to production faster.
We're thrilled to have FirstMark Capital lead our Series A round, putting even more momentum behind our vision to bring the power of decision science to every developer.
Everyone talks about Santa's big night on his sleigh - a vision of efficiency with millions of chimneys traversed in a mere 24 hours
Launching Nextmv Cloud
Our quarantined world is even more on-demand than it used to be. We order groceries, gadgets and green goddess salad, and they all show up at our doors within minutes.
Routing, Packing, and Clustering - Optimization Fundamentals
We completed our seed round!
How does Hop make decisions?
What does nextmv do?