Solving the needs of the needs of the container management industry

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:

 

  1. Pickup full container at port.
  2. Take to customer and wait for unloading.
  3. 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:

 

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:

 

  • Simple full movement: pickup full container and drop it off at a customer.

  • Simple empty movement: pickup empty container and take it to a specific depot.

  • Pickup full container, take to customer, empty, take empty container to restitution point.

  • Pickup empty container, take to customer, fill, take to port.

 

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:

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:

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.