ODL Live route optimiser API

2 Technical overview

2.1 Available ways to run models

ODL Live provides multiple ways you can run an optimisation model. The most suitable way will depend on your use case. It is important to understand if you have a realtime or nextday (a.k.a. ‘static’) use case. A realtime model will need updating - i.e. re-optimising from an initial solution - when data changes, for example if a new job is added or a vehicle is delayed. A next day model is only ever optimised once, because you know all the data (jobs, vehicles) at the start of the optimisation and these will not change.

The available ways of running a model are:

  1. Main webservice endpoint (realtime mode). The main webservice runs in a webserver and can run both realtime and next-day models, as well as process planning queries for appointment booking. Realtime models will respond to changes (e.g. new job) very quickly on the main webservice, as they are held ready in-memory. Models on the main endpoint will continue optimising indefinitely unless you stop then.

  2. Static queue. The static queue is designed primarily for next-day models and is accessed via a different endpoint on the webservice. Models queue up and are optimised until they reach the stopping criteria (e.g. max time, max iterations without improvement etc).

  3. Command line. The command line API can also run both realtime and next-day models. Response time for realtime models will however be slower on the command line compared to the main endpoint, as when you reoptimise an existing model on the command line it has to startup and load data into memory (e.g. load initial solution, distances state, road network if needed). You can configure the command line to optimise a model for a maximum amount of time or until ODL Live estimates it has reached a certain solution quality.

The ODL Live webservice is designed to work with your pre-existing IT system - so you keep your current driver’s app, dashboards etc. You simply connect your existing back-end system to either the ODL Live webservice, using a secure HTTPS connection over the internet, or use the ODL Live command line API. The command line is suitable for use in serverless event-driven computing environments.

Start, stop, pause and restart optimisation models. The webservice version 2 (webapp2), supports optimisation requests that you can use to start and stop an optimisation model, running in either realtime or static mode. So you can send updates (e.g. new jobs, GPS coords etc) to a model even when it’s stopped, and then start optimising it again when you want to update the plan. When models are inactive they use no system resources.

Server clusters and failover. Webapp2 supports setting up clusters of ODL Live servers, which automatically distribute running models across them, and automatically failover a model from one server to another in the case of hardware failure.

2.2 Input / output data formats

ODL Live supports input/output using either its native JSON format or Excel (using a templating system to convert Excel input into JSON). Excel input is a handy way to learn the ODL Live system, by using our example Excel templates as quickstarts.

2.3 Realtime mode

In realtime route optimisation mode, the engine takes real-time data feeds as input - stop arrival and completed events, GPS traces and manual dispatches as well as new or cancelled jobs. It processes the real-time data to estimate the state of your vehicle fleet and then plan accordingly, reassigning and re-ordering jobs when drivers are running ahead or behind schedule.

Dispatching support lets you lock-down a driver’s near-future, by marking their next one or two planned stops as dispatched, so the engine optimises their route after the dispatched stops (i.e. it optimises their longer-term future). This handles delays in communication between your driver (via your mobile app or pre-existing job dispatching system) and the planning engine, as the driver holds a short-term buffer of locked-down jobs to be actioned by them in the immediate future.

In a real-time setting, unexpected delays are unavoidable and jobs will sometimes run late. ODL Live optimises to minimise lateness (technically speaking, it supports a soft end time window) as well as respecting the usual ‘hard constraint’ start and end times. This is a key feature for real-time planning; if instead you used a hard end time window on its own, jobs would be dropped from the plan even if they were only going to be served one second late.

In real-time freight collection and delivery scenarios, ODL Live can lock on-board-deliveries to a route after leaving the depot or at a pre-determined time before loading commences. Pending collections can be reassigned between routes and deliveries locked to a route can still be re-ordered within the route, to maximise efficiency as new collections come in or other conditions change.

ODL Live is engineered for response speed and can reoptimise routing plans in seconds, when input data changes (e.g. updated vehicle events, new or cancelled jobs), dependent on problem size and system configuration. Using the webservice in realtime mode, a model is always ready pre-loaded in server memory (e.g. the road network data, travel time matrix, solution state are all loaded or cached) and the model is always running, constantly refining its routing plans. The engine reuses its current calculations when new data becomes available, by incrementally adding new records to the travel distance / time matrix and updating its collection of routing plans. By updating and reoptimising its plans in response to new data, it finds high quality routes far quicker than starting the optimisation from scratch on each data update.

2.4 Appointment booking

Appointment booking is a process where you give a customer one or more possible service slots (e.g. Monday 2pm – 5pm, Tuesday 10am – 11am, etc) and they select their preferred slot, which is then booked and confirmed in your order processing system. As your workforce resource is finite, available slots are finite and a customer booking one slot can make it unavailable for another customer. Traditionally companies manage this process in a simple manner without considering routing costs, e.g. by allowing a maximum number of bookings per hour or per AM / PM. Appointment booking is a real-time planning problem, even if you’re booking jobs for tomorrow, next week etc, because the booked slots affect the availability and efficiency of other slots.

ODL Live provides route-aware appointment booking with response times within a second or two, dependent on problem size. You send a planning query to ODL Live, to gather metrics such as increased travel time or lateness associated with different slots, which you use to preferentially offer customers route-efficient slots (e.g. through dynamic pricing). Route-aware appointment booking gives a much better estimate of your available resource, ability to serve customers within SLAs and better management of your transport costs.

Appointment booking is a conversation between your order processing system and ODL Live - post the planning query, poll for the results, present to the customer, send the selected slot back to ODL Live for acceptance into the routing plan. ODL Live uses optimistic locking when accepting a job into the routing plan, you specify metrics such as ‘no increase in lateness’ or ‘no more than 10 minutes extra driving’ when you create the planning query and again when you send the slot back for acceptance. The slot is accepted into the plan if the metrics still hold.