Inside Logistics

Materials Handling: Warehouse automation

Startup considerations


May 3, 2016
by Dave Luton

Dave Luton is a consultant in the Greater Toronto Area.

Dave Luton is a consultant in the
Greater Toronto Area.

A lot of warehouse automation projects are unsuccessful or only partially successful. While there are a number of reasons for a project failure, often they can be traced to failure to properly consider the “Six Esses” of automation.

  • Speed
  • Strategy
  • Simplicity
  • Software
  • Sensors
  • Startup

This is too complex to consider in a single column, so we will show how ignoring them on a large project caused problems.

Speed is a rarely mentioned cause of an automation failure but it is often an important underlying factor. In a world of constant change, with the emphasis on “just-in-time’ for everything, insufficient time to properly design, purchase, build, test and commission a project is often a key consideration. When a project failure is audited the need to use shortcuts to meet an impossible schedule is frequently the true root cause of many problems.

A well-studied real world example provides a good illustration. One of the more famous examples of automation failure was the attempted startup of a new baggage system at the Denver Airport a couple of decades ago. At the time it was the largest system to be built, by a factor of 10, and it had to be completed up and running in just two years. This was a shorter time frame than was required to commission the largest systems that had been built prior to this one.

The short time frame was caused and compounded at the outset by changes in strategy. Initially, each airline would arrange its own baggage handling. This was changed at a late stage to an airport-wide system. While this helped—in theory—because a centralized control would help in system integration, it greatly increased the complexity of the overall system design.

Add to that a key design decision that directly affects the simplicity variable of a conveyor system. As any person involved in conveyor systems knows, one of the key design issues is determining what is conveyable and what is not conveyable.

For baggage system designers Denver’s location in the mountains posed a problem that is not (often) encountered in lowland airports such as New Orleans or Toronto. The seasonal problem is called ‘skis’ which can be a pain to convey around curves.

For short conveyor systems which operate in a straight line, getting skis conveyed is one thing. Around corners and curves is another matter entirely. This problem was never resolved in Denver.

Complicating matters, the building design and construction were done before the material handling system design was finalized. Automated systems are best designed from the inside out. Specifics of the automated system are known before a building structure is finalized around it.

Computer systems and software also caused problems in Denver. Successful functioning of the system required advancement of complex queuing-system mathematical ‘line balancing’ algorithms. However the PC hardware was not capable of handling them at the time.

I remember talking to the chief engineer of a large conveyor manufacturer who had NOT bid on the system because he felt his company could not successfully meet the performance variables. He was right.

Interestingly enough, a consultant hired by the airport had come to the same conclusion over a year before but their advice was ignored.

I would like to emphasize the need in complex automation systems of the time and effort for a successful startup. Some of the steps required include:

  • Development of a successful preventive maintenance plan including spare parts supply.
  • Development of a proper commissioning program that gradually steps up production in phases.
  • Proper training of personnel is essential.
  • Finally measuring productivity and determining if the goals are being met. If not, why?

In complex systems also remember the risks of vulnerability in the loss of key people or key system components. Redundancy has value. In the Denver airport example the chief customer (i.e. airport) engineer died before the project was completed. His replacement did not have the same degree of project knowledge.