Vehicle routing software catches up with the needs of the container management industry
The container industry is not alone in being affected by the price of fuel, the general economic downturn and a need to reduce the corporate carbon footprint. These challenges have thrown a greater spotlight on other business areas that can deliver cost savings and greater efficiencies. The use of appropriate technology such as vehicle routing software, telematics and business intelligence are increasingly becoming key weapons in the fight to remain competitive and profitable.
However, operators that are engaged in planning and delivering containers using the road network have not historically been well served by transport planning and vehicle routing software. Although this type of software has been in use for over two decades to efficiently plan and schedule vehicle movements for multi-drop deliveries, the greater complexity resulting from managing container deliveries and collections has previously limited the usefulness of this software.
Computerised vehicle routing and scheduling
Computerised vehicle routing and scheduling is a well established field both academically and commercially. The role of the routing system is to take a set of orders and available resources and to plan the best set of trips that carries out all the deliveries and collections within the given constraints, such as delivery time windows. This process is commonly referred to as optimisation.
This article examines the specific requirements involved in routing and scheduling in the road container shipping arena. It examines how to overcome the challenges posed by such issues as how to efficiently manage the movement of containers between docks, customers and restitution points and classifies typical container movements.
Why conventional routing systems do not work
Most routing systems have evolved from solutions for multi-drop distribution. The main characteristic of this is that each "order" consists of a movement of goods from a central depot or warehouse to a customer site. Each order therefore has a customer and a depot associated with it.
|
Figure 1. Flows of delivery orders. |
Figure 2. A conventional multi-drop trip. |
The next stage in the evolutionary process was to mix deliveries with collections. Orders still have a customer and depot, but also a flag indicating whether the vehicle movement was to make a delivery or collection.
|
Figure 3. In this example the 2 orange orders are collections. |
Figure 4. A similar multi-drop trip is created. |
The third stage is to cope with "pickup and drop" orders where the flows do not go through the central depot. In this case orders have a start point and an end point, one of which may be (and usually is) a depot.
|
Figure 5. Two pickup and drop orders.
|
Figure 6. The Trip sequence changes. |
The pickup and drop scenario is much closer to a container shipment but fails to properly implement the container model because while each standard flow has 2 locations - a beginning and end, container flows frequently involve 3 locations, for example:
- Pickup full container at port.
- Take to customer and wait for unloading.
- Transport empty container to restitution point.
Another critical and related difference is that the container must be managed explicitly. Although in a traditional distribution environment goods may be delivered on pallets or in roll-cages that are off-loaded on site and brought back:
- The empty pallet or roll cage takes relatively little space and weighs little, whereas the empty container will still fill the vehicle.
- The pallets and roll cages are essentially anonymous and interchangeable, whereas a container will belong to a particular shipping line and have distinctive characteristics such as livery and refrigeration capability.
Changing how the routing software treats an order
For the routing software to deal adequately with container deliveries and collections, the "orders" or movements must be classified into standard movement types:
|
|
|
|
|
|
|
|
Consequently data on the two or three locations involved in the movement should be catered for. In addition to this there is the container owner (usually the shipping company) and the container type.
Creating an optimised set of movements
The standard optimisation process would be to take multiple orders and string them together in trips, so as to minimise empty running. For example:
|
Figure 7. Initially there are 2 orders. |
Figure 8. Initial solution (vehicle based at depot). Orders treated independently. Dashed lines are empty running. |
Figure 9. Optimised solution: empty running is minimised. |
The standard optimisation process can be applied to hundreds of road container movements spread across a multi-day planning horizon and involving either multi-shifted vehicles or vehicles where the driver is "tramping" during the course of a delivery week.
Empty container substitution
Sometimes containers being emptied are of an identical type to containers that need to be filled. In this case further optimisation possibilities exist:
|
|
|
|
Figure 10. The first job empties a container and drops off at point A, the second picks up an identical container from point B fills it and delivers the full container. |
Figure 11. The optimisation avoids restitution of the empty container |
This type of optimisation eliminates a trip to restitute the container. It can save a considerable amount of travelling and thus cut the associated transport costs. There are two sub-cases:
1. Where the restitution point for the empty container on the first job (A) is the same as the pickup point for the empty container on the second job (B), the effect of optimisation is completely neutral.
2. Where A and B are different, the net result of the optimisation is one fewer container at A and one more at B. It is possible that optimisations of this type should be restricted, for example to cases where B is a port or railhead.
Other constraints
Many standard routing constraints can be followed thus ensuring container movements are accurately catered for. These include:
- Time windows for delivery and collection.
- Driver shift and working hours limits.
- Vehicle/Container compatibility.
- Hazardous goods transport where specific driver qualifications are required for delivering some loads.
- Different unloading and loading times at ports and customer sites.
Other road optimisation possibilities
There is a lot of potential for other road-based optimisation opportunities to be developed and applied to the container industry, for example:
- Deferred restitution: Typically restitution of empty containers has a lower priority than deliveries or collections of full containers. Deferred restitution would allow an empty container to be dropped off at a depot near the unload point, while the vehicle goes on to carry out more urgent work, the restitution being deferred to a later time when there are spare resources.
- Intelligent container substitution: this is a refinement of empty container substitution with non-identical containers being substituted on the basis of matching rules.
Future research: incorporating multi-modal activity
Container movements are one of the few well-developed rail freight markets in the UK. There is a comparatively small number of suitable rail-heads and typically, freight trains are booked and run to a schedule. Future research in this area will ultimately see a routing system properly take the rail freight movements, with their lower per-mile cost, directly into account.
Conclusion
The advances that have been made in the sophistication of routing technology has seen the software catch up to the needs of the container operators, who can now enjoy the same transport efficiency benefits as their counterparts engaged in multi-drop distribution.
It is now possible to apply advanced optimisation techniques enabling container movements to be planned more effectively. There is more work to be done in this field to meet more of the unique requirements of the container industry however, the technology now exists that can allow container operators to make significant savings and efficiencies from the implementation of routing software.









