Don’t let the Denver International Airport’s experience turn you off to the use of linear motors in material handling or other linear applications. Instead, learn from the mistakes.
At the beginning of the Denver Airport automated baggage-handling project, Federico Pe˜na, Denver Mayor from 1983-1991, said “I hope it will be said of our effort, when history sits in judgment, that we reached out beyond our borders and helped shape the world’s aviation future.” (At press time, Mr. Pe˜na was still Secretary of Transportation in the Clinton administration).
Reach, they certainly did. But after a year’s delay in opening, the result was a heavily downsized baggage-handling system that cost slightly over $200 million. To put it kindly, initial judgments say the Denver project has not helped shape aviation’s future. Instead, it may have dampened the use of linear-motion-based baggage handling systems. Which is a shame, because this technology works. There are three major installations successfully operating and one planned to begin operation in 1998.
After Denver’s three failed attempts at opening the airport, however, blame centered on the computerized, digitally coded vehicle system — a trackmounted car propelled by linear induction motors. Some “authorities” claimed the problem was wayward power surges that shorted the linear motors. But technical problems were not the fault of linear-motor technology. They were a result of too little time, little or no planning, no project management, no development of teams, and politics.
Why use linear motor technology?
In Denver’s case, it was to move luggage faster, reduce maintenance, and resolve political situations.
As the distance between an airline’s gates to the terminal increases and as each airline attempts to handle more traffic, new ways are needed to move baggage efficiently and quickly, into, out of, and between concourses and gates. Cars powered by linear motors can move luggage faster than traditional belt conveyor systems. One of the newest belt systems, for example, at the new Pittsburgh terminal, has a total speed of 1,000 fpm. The plan at Denver was to have linear- motor propelled cars move luggage at 19 mph, or over 1,600 fpm.
Linear-motor-based, baggage-handling systems work. “They are an application of the future,” said Howard Zollinger, president of Zollinger Associates Inc., a consulting firm for the Oslo Hovedflyplass airport project. “They can lower maintenance costs and offer higher system performance over conventional cart-tug and conveyor systems.”
Properly implemented, the cars pick up and unload bags when called by a PC. Otherwise, they wait in a holding area. This reduced movement on a track means less wear on the wheels and other sections of the car, which reduces maintenance.
As for politics, one cannot underestimate the importance of a major carrier’s, such as United Airlines, desire to have automated cars. Its gates were going to be a mile from the terminal, and it hoped to have airplanes land, disembark passengers, unload luggage, replenish fuel and supplies, load in new luggage, take in new passengers, and fly out of the airport in 35 min.
The linear-motor car system
As with most linear motors, the stator is a flat linear section of electrical iron with coils wound in it such that ac waves travel down the stator. The rotor is a piece of aluminum or copper backed by steel.
The early implementations all have a flat stator segment as the fixed element, embedded in the track in the floor. The flat rotor is on the underneath side of the moving car. Benefits of this arrangement are that it eliminates the need for collector shoes and the need to put power to the moving devices. The same interaction of magnetic fields that turns an induction motor propels these cars equipped with linear motors.
The cars have wheels that ride the track and keep the air-gap between stator and rotor of 4 to 7 mm.
Continue on page 2
“Cars move over a linear motor track with what we call a sling-shot effect,” said Mr. Zollinger. Typically, linear motors are spaced out along the track at a distance that assures a car will travel at the required average speed. In baggage systems that are yards long, for example, flat segments of the track have linear motors placed every 10, 20, or 30 ft.
When a car passes over one of the motors, it’s propelled as it passes over the motor stator. Momentum carriers it to the next motor. After a specific distance, (the 10, 20, or 30 ft) the car comes to the next motor at a speed slightly lower then the designed system’s average speed. The motor accelerates it, and it leaves at a speed that is slightly above the desired average speed.
This sling-shot motion means that engineers need not put linear motors continuously along the track or in curved segments of the track, thus reducing costs, Figure 1.
For inclines, several linear motors are placed close together to ensure enough thrust to increase speed and overcome friction and gravity. For an incline of 20 to 30 deg, for example, the linear motors may be spaced 5 ft between centers instead of 20 or 25 ft. The first motor on the incline magnetically “grabs” the car and pushes it up to the next motor, and so on until the car reaches the last motor. By then, there is enough momentum to get the car over the upper radius of the incline.
The Denver project combined several unique elements that eventually created the fiasco: an untested new rotor design, modified tilt-tray design on the cars, luggage tracking software designed for 300 cars modified to handle 3,500, and automatic loading and unloading onthe- fly, all of which were going into a facility already more than half built.
The fin. In San Francisco, wheel wear on the automated cars is a high maintenance problem — as the wheels wear down, the air gap shrinks. The contractor for Denver, also the contractor for the San Francisco airport, thought that a new design for the rotor, a fin design, would reduce the costly maintenance. Engineers prototyped a fin-design car in Texas in 1991, but Denver was the first application implementation. Instead of having a flat rotor on the underneath side of the car, they turned it 90 deg, making it look like a fin. The stator portion of the motor is shaped like a U and mounted under the track. The fin on the bottom of the car passes through the slot in the track formed by the stator.
This design was intended to eliminate the problems of wheel wear for the main wheels. But, adds one consultant, the guide rollers that keep the car centered from side to side have to be accurate too. So far, this issue has not been addressed. The fin design does work, and would have worked in Denver were it not for the design of the tilt-tray cars and the problems with the automatic loading and unloading system.
The cars. Each of San Francisco’s weighs about 100 lb. Each of Denver’s moving cars weighs 300 lb because the baggage handling designers wanted a tilting container on the car, Figure 2. It normally rides with the width dimension on a 30 deg angle above horizontal and the height dimension on a 60 deg angle. To load, the container tilts so that the width is horizontal. A belt conveyor then shoots the luggage into the container, Figure 3. When the car leaves the loading zone, it returns to its 30 deg tilt. Then, the car travels through the system, tilted up so the bags don’t fall out. At unload, the side that’s sitting up now tilts down 30 deg, and the bag slides out. The tilting mechanisms and all the extra pieces add to the weight. The car is made of steel, for easier fabrication, bringing the total weight to 300 lb.
Loading and unloading. This loading, tilting, and unloading were to be done while the cars traveled at 19 mph. However, the automated baggage loading and unloading system has never worked reliably in Denver. In tests, bags and cars often have not come together at the same time, with unintentional results. During a trial run for example, in front of news media and cameras, some pieces of luggage fell onto the tracks. At over 300 lb and traveling at a speed of 19 mph, the cars had a lot of momentum. Rather than stop at the impeding luggage, the cars rammed and sliced through the luggage sending clothes and personal belongings flying through the air.
According to one consultant, there’s no reason why the cars can’t be loaded on the fly, as long as everything is planned well. After such a demonstration, the system designers realized they needed a little speed control.
Continue on page 3
Initially, engineers or operators simply turned the linear motors on or off as needed, because the initial specifications avoided any mention of a speed-control system.
After the episode of flying luggage, friction drives were added to slow the speed as the cars moved into and out of the loading and unloading areas. (Because of problems with the tracking software, the cars speed was eventually reduced on all segments of the track. Now, all the cars move at about 9 or 10 mph.) Friction drives also control the cars as they emerge from a holding area.
Permanent magnet decelerators are also used, sometimes in combination with a friction drive, to reduce speed.
The original design did not include plans for a backup baggage-handling or backup power-supply systems. If the baggage system failed, the airport would effectively shut down until the problem was corrected. If power went out, the cars would coast until friction finally stopped them, which could be anywhere along the track.
With the addition of friction drives, as a car coasts over one, the drive drops the speed to zero. But friction drives are not on the main tracks, so the cars there will coast until they stop. To start up again, system personnel must use methods similar to the San Francisco airport, but these are the methods the Denver design was supposed to eliminate.
In San Francisco, once the cars stop, they are manually moved over a linear motor. Then, when the operators turn the power on, the cars move up to speed.
In the new Oslo airport, the engineers designed the system to use a little bit of gravity to solve this problem. If power shuts down, the cars will coast until they run across permanent magnet retarders placed at the top of slight inclines at various locations along the track. These retarders collect the cars before friction takes effect. Friction brakes can also be used for emergencies. At system restart, an operator pushes the cars out one by one and lets gravity roll the cars down the decline where they are propelled by a linear motor.
Control. Depending on the baggage system, one or more programmable controllers or personal computers provides control. At Denver, the control portion added much complexity to this ambitious automated baggage-handling system. The idea was to use a hierarchy of personal computers, networked together and to a personal-computer-group supervisor, then to a supervisory control.
At check-in, each piece of luggage has an identification tag that is scanned while the bag is conveyed on a belt conveyor through the terminal to a car loading station. The scan signals a PC to send a car to that loading station. As mentioned earlier, the bag is supposed to be automatically loaded onto the car. The car has an identification tag too. A PC receives the luggage data and car identification from a radio frequency (RF) identification transponder mounted on the car as it barrels through the tunnels. The PC is supposed to send destination information back to the RF transponder, telling the car where to leave the main track to take a secondary track to a gate or claim carousel, or to divert bags based on changes in flight arrivals, departures, and gates.
The software to control this complex car and baggage tracking is called empty vehicle management software and is used primarily in material handling applications. At Denver, the contractor has had difficulty with it, lack of experience with it being one of the problems. Other problems of the software include, losing some destination information in the database, delivering outbound bags to inbound claim carousels, and not properly controlling the spacing between cars resulting in multiple car crashes. Engineers have been rewriting parts of the code since 1994.
In the mean time, to open and operate the airport, the solution was to have 400 to 600 cars continuously circulating around the track, rather then wait in a holding area until called by a PC. Thus, when a load station needs an empty cart, one is diverted off the main line to the loading station. This works, but it means that the cars are always running, which increases maintenance.
The Denver fiasco teaches us two main lessons:
• Invest in planning, with all the material handling, software, controls, mechanical, electrical, operations, and maintenance engineers necessary.
• Select a strong, competent project manager with a team and authority to do the job.
Continue on page 4
Denver’s plan was that the already built baggage tunnels would accommodate tug and cart or belt conveyor, whichever system was finally chosen. United Airlines, however, as part of its agreement to take one of the concourses, demanded an automated rail-mounted cart system. The tunnels were not designed to accommodate such a system. Rework continues to this day.
There have been two project managers over this project. The last one was a civil engineer with experience in hydraulic systems, not electric. Neither manager managed well. Denver politicians, city council, airport council and others repeatedly changed the airport design and construction plans. The project managers never told the council that more time was needed to make the changes as well as debug whatever the final system would be. The contractors dropped the ball here too, because they’ve worked with municipalities before and should know the potential trouble spots.
• Denver’s design called for the empty cart management software to juggle incoming flights dumping luggage in varying quantities, at varying locations, at varying times. A tough project for any software program, especially so when the contractor has had little experience with this software.
• The motors should be controlled by adjustable-speed drives.
• Lock up the design of the baggage system before the architects finalize the building.
• All engineers should be involved in program specification to answer the what-if questions. Don’t rely solely on programmers to design the software.
• Integration is crucial. Selection of a system’s integrator should not be left to politicians. The individual components of this system had been tested in some form separately, and had worked, separately. But, the integration of these components and the politics needed to build a new airport, attract major carriers, and finish the task in less than three years proved too much.
The new Denver Airport is operating, however the design is far from complete. There are still plans to expand this system to Concourse A. But the software-control portion faces major hurdles. It is not operating properly, still. And not unsurprisingly, several lawsuits are flying, including one regarding whether the software-control system meets initial specification, what can be done to get it to meet specification, and who will do the work.
It was a grand design . . .
The concept was for bags, at check-in, to be placed on belt conveyors that interfaced with computerized, digitally coded vehicles. These track-mounted vehicles, propelled by linear induction motors, would move around a network of 22 miles of tracks.
The belt conveyors would automatically load luggage into the cars as they whizzed by at an average speed of 19 mph. Plastic pods mounted on bolted-together cars would handle skis and golf clubs.
When the cars reached the proper luggage destination, from among 42 gates or claim carousels, they would automatically unload the bags onto belt conveyors that would load bags into the planes or onto the carousel. About 3,500 of these cars would transport up to 42,000 pieces of luggage per day. Total time for luggage transport, 8 min on average.
The automated baggage handling system was expected to cost approximately $192 million and was to deliver baggage among 19 airlines. Implementation of the system began in early 1992. The airport was supposed to open in early 1994. After three failed attempts, and considerable rework on the design, it finally opened at the end of February 1995.
. . . that failed
The downsized version presently serves only United Airlines. Tracks set to serve Concourse C (for other airlines) were diverted to United’s Concourse B and added to the two tracks already there. Instead of 3,500 cars, 400 to 600 circulate continuously around bag-input loops. Cars are diverted to a specific loop as needed. Bags are manually loaded and unloaded onto the cars, as the automated loading and unloading portion never did work reliably in tests, and still doesn’t. Because the cars move continuously, maintenance costs are high.
Continue on page 5
The baggage system only handles luggage for outbound delivery. Luggage from incoming flights is manually loaded onto carts and towed to the terminal or to other gates for transfer. So far, the total cost of the Denver airport hovers around $5 billion.
The success stories
San Francisco has had a linear-motor-based, baggage-handling system in operation for over 18 years. Unlike other systems, it is basically all linear motor driven. While it is old technology, it will be in place for at least another two years. After that, it will undergo renovation, primarily because United Airlines placed an order to increase the size of its concourse.
The baggage handling design here uses 300 linear-motor-driven cars. Loading luggage onto to the cars is done manually. Car movement and bag tracking are simple, and there is no bar-code, radio-frequency-identification hand-off.
Moreover, parts of the Charles de Gaulle airport in Paris, which uses linear motors in its 7,000- tray baggage handling system, are undergoing expansion. Three tilt sorters, driven by linear motors, are being added.
The system in Changi, Singapore, also uses linear-motor-powered cars that handle approximately 10 bags each. Some cars are loaded and unloaded automatically, others manually. (San Francisco, Denver, and Oslo Hovedflyplass AS have several areas where cars are diverted for loading and unloading.)
The Oslo plan
The timetable for the linear-motor-driven baggage system for the Oslo Hovedflyplass AS goes like this: Planning began in 1992, specifications were written in 1993; the contractor, Vanderlande Industries Nederland B.V. received its design and installation contract in June 1994; final layout was in February 1995. The airport is scheduled to be ready for operation in June 1998. System training will be complete by October 1998. The airport is scheduled to open in October 1998, with final acceptance scheduled for December 1998.
Single-bag, computer-controlled, rail-mounted cars will be the main baggage transportation system. Belt conveyors will be used for oversized luggage, such as skis and golf clubs, and as backup in case the rail system goes down. All the tilt-tray cars will be flat armatures, not the fin design. The cars are made of aluminum and are loaded automatically from above. At unload, lifting arrangements tilt the car and the bag slides off.
To solve the problem of wheel wear, and thus heavy maintenance, engineers have devised a preventive maintenance program. Once a month each car goes through a thorough check. It is placed on a special table that measures all the aspects to control air gap.
The control software uses much of the architecture developed for Charles de Gaulle airport, which operates a 7,000 car rail system.
Belt conveyors still transport luggage
Pittsburgh opened a new terminal in October 1992. The baggage handling system cost $34 million. It consists of two 3,500-foot tunnels that connect the terminal with the concourse. Two belt conveyors are in each tunnel, and each conveyor travels at 500 fpm. On outbound and inbound conveyor routes, scanners read the bar codes on bag tags and activate the diverters, which push bags off to belts that feed bags to gates. Every main conveyor and diverter lane has a backup. The same contractor installed Pittsburgh’s and Denver’s systems.
In 1990 when designers were planning the baggage system for the new Denver airport, consultants recommended carts pulled by tugs for long hauls and belt conveyors for short distances.
Continue on page 6
In the mean time, the automated digitally coded vehicle-on-track system, initially developed by BAE Automated Systems Inc., with American Airlines money for a new terminal in Dallas, was undergoing prototype testing. American Airlines got into financial difficulty and the terminal was not built.
In 1991, United Airlines had not agreed to occupy the Denver Concourse B that was designed for them. Eventually though, United did agree to come into Concourse B, but only if they got a baggage system that would move luggage over a mile’s distance fast enough to turn aircraft around in 35 min. Airport officials didn’t know of any system that could meet this requirement. United suggested that the BAE prototype system of an automated car-ontrack might meet the need.
The city’s charter, however, mandated a bidding process. So system requirements were defined and specifications sent out for bids. A few contractors bid, including a consortium of Harnischfeger Engineers Inc., Syscon Corp., UTDC, CCC-Pentek, and ElectroCom Automation, but not BAE. The city’s evaluation committee determined that the bids did not meet the specs. With no apparent way to meet United’s requirements, the airport faced the prospect of losing the major carrier. They called on BAE for help. BAE reluctantly (a point everyone involved agrees on) came in to the rescue. BAE signed a contract to build the system in June 1992, with the city’s requirements that it be completed by October 1993.
At present, parts of the system work reliably. For those segments that don’t, there are charges and counter charges between United and BAE about where the fault lies.