Denver Airport Automated Baggage Handling System

A Consulting Report and Case Study by Richard H. Caro

The new (at the time, 1997) Denver Airport United Airlines terminal had been

designed and built with an automated baggage handling system - but it just

didn’t work as planned. United Airlines at the Denver airport has its own

unique terminal building from which all United domestic flights departed and arrived. However, checked baggage was first handled at the main terminal building where each airline had its own check-in stations, self-service check-in stations, and

baggage drops. Checked baggage was tagged with the industry-standard destination barcode at curbside, at self-service terminals, or by the United check-in attendant, transported by conveyor belt to the Denver Airport baggage handling system. United Airlines baggage was trucked to the United Airlines automated

baggage handling system. Once bags entered the United Airlines baggage

handling system, each piece of checked baggage would be loaded onto

transport carts that were identified with a barcode. Each transport cart was to

carry one piece of baggage. The system was designed so that the baggage

transport carts would travel on a rail track that would pass by every United departure gate. A track switching system was designed to read the cart identification barcode, determine if the baggage item on the cart was destined for the next departure gate, and if true, route the transport cart to that departure baggage unloading station where the baggage being carried would be moved to a receiving station destined for the flight scheduled to depart from that designated gate.

Only, it didn’t work more than 50 percent of the time. As a result, baggage that missed the intended departure gate staging area was routed and unloaded at a generic baggage departure transfer station where it was manually transported by local attendants to the correct departure gate. Baggage might be delayed often

enough to miss the correct departing aircraft and become “lost baggage.” Lost

baggage had to be manually routed to the next departure flight destined for

the lost baggage final destination in violation of FAA rules that required that the passenger and their baggage be on the same aircraft.

Another problem with the baggage handling system was mechanical. The

transport carts were unpowered. They rode on a rail track and were propelled

by linear induction motors located at intervals between the rails. The linear

induction motors were designed to propel the cart as it entered its induction

field down the track to the next induction motor. Only, it didn’t work so well. Often the “shove” given by a linear induction motor was not enough to overcome rolling

and track friction, and the cart would just stop somewhere before the next

linear induction motor. The result was that the following cart would collide

with the stalled cart often resulting in the contained baggage being

discharged and falling to the ground beneath. Some baggage survived the

fall, but most were quite damaged, often spilling the contents.

With the unreliability of the system to deliver undamaged baggage to the

correct departure gate, United Airlines quickly abandoned the baggage

handling system and returned to the manual handling system previously used.

However, hope springs eternal and a viable solution to the automated system

continued, but only with test baggage, not with the airline passengers actual

baggage.

United Airlines, seeking a solution to the problems of the automated baggage

handling system hired one of the “big-three” accounting/consulting firms

(which to avoid litigation, I will refer to only as the “firm”) to “fix” the problems.

The firm formed a task force that quickly concluded that there were two

separate problems with the automated baggage handling system:

• Poor design of the transport carts, and

• Failure of the control system to deliver commands to the track switching system in time to deliver baggage to the correct departure gate.

Recognizing that the firm lacked the technical skills to solve the mechanical

problems by redesigning the transport carts, the firm sub-contracted with my employer, Arthur D. Little (ADL) to do the cart redesign, and also to assist in solving the control problems. As Arthur D. Little’s expert for both automation and barcode identification, I was assigned to work with the firm to solve the control and automatic identification problems.

Problem Solving

An ADL team was assigned the mechanical redesign of the baggage handling

carts. They solved the cart problem by reducing the rolling friction: the simple

solid wheel bearings were replaced with roller wheel bearings.

I had a complex problem to solve since the track switching logic was

controlled by redundant Programmable Logic Controllers (PLCs) at each gate.

I inspected several of the control centers where they were located. The logic

diagrams for the PLCs were available in the control centers. It was here that I

learned how the total system was intended to work and why it failed.

System Design

At the Denver airport, baggage enters the baggage handling system in three

different ways:

• Curbside check-in

• Ticketing agent or self-service baggage drop check-in

• By transfer from connecting flights

Baggage entering the system will have an industry-standard barcode tag

specifying the baggage final destination and the PNR (Passenger Name

Record) attached by the curbside attendant, the gate agent, or the traveler at a

self-service terminal. Baggage arriving on connecting flights would have the

industry-standard bar-coded tag already in place. The PNR has the passenger

itinerary that includes the departure airline, original departure flight number,

and any connecting airlines and flight numbers. If departure from Denver is on a United Airlines flight the baggage is delivered to the intake portal of the United

Airlines baggage handling system.

All United Airlines checked baggage enters the Automated system on a conveyor belt that routes the baggage item past the barcode reading station and moves the baggage item onto the next transfer cart that arrives. As the empty transport cart arrives at the loading point, its ID barcode is read by a trackside barcode reader. The control system then determines the departure gate for the flight departing from Denver from the PNR  information on the baggage tag. The departure gate is then determined by the system and matched with the cart ID. The transport cart continues on the track propelled by the linear induction motor at the baggage loading station, and continues on the track that passes all United Airline gates.

This is the logic for routing the transport cart to the proper gate:

When the transport cart approaches a gate, a barcode reader reads the cart ID

that is mounted on the cart. The system logic determines if the baggage item

associated with the cart that is next in line for the next unloading station (United

Airline gate). If this is true, the track switch for that gate is moved to route the

cart to the gate unloading station. Otherwise, the cart continues on the main

track bypassing that gate. At the gate unloading station, the cart is tilted to

unload the baggage to a conveyor belt that carries the baggage to the gate

baggage storage area where it is eventually loaded onto the departing flight

assigned to that gate. The empty cart re-enters the system (main track) and

continues circulation until it picks up the next piece of baggage.

To interconnect the logic stations, the PLCs controlling the track switching

operation, the entire system of PLCs installed at every United Airlines gate

were connected to an Ethernet network. All of the barcode readers in the

system are terminated in the PLCs with Ethernet interfaces in the control

room for that station.

Well, that’s the way it was supposed to work. Here are the problems that were

documented:

1. More than 50% of the bags were not unloaded at the destination gate

1. The tag barcode attached to the baggage had not been read

2. Barcode reader could not see the tag on the baggage and failed to associate the departure gate with the transport cart

3. Barcode reader misread the barcode

4. The transport cart was not routed to the gate unloading station

1. The transport cart barcode had not been read 

2. The transport cart barcode had been read, but the logic to make the track switch was received after the transport cart had passed the switch  

3. The bag was not on the transport cart; it fell out of the cart along the way, or it missed the cart as it was to be loaded

5. The transport cart stalled on the main track baggage was damaged or completely lost (When transport carts stalled on the main track, succeeding carts would crash into them usually propelling contained baggage to the floor below)

6. Baggage was not actually transferred to the transport cart at the loading station, sometimes falling to the floor below

7. Baggage tag was damaged, ripped off, or was otherwise unreadable

2. Timing was off; track switching occurred after the transport cart had

passed the track switch

1. Transport Cart was moving too fast

2. System was too slow in operating the switch after reading the transport cart ID barcode

Finding a Solution

Rebuilding the transport carts with roller bearing wheels was expected to

solve some of these problems, like the carts stopping before the next linear

induction motor and crashing from behind. Fixing the barcode reading

problem at the transport cart loading station was also simple: install redundant

barcode readers at different angles to be sure that the barcode could be read from any angle. That would require new PLC programming for the loading station to “vote” on the barcode reading.

However, the biggest problem, and the one most often experienced, was why

carts bypassed the track switch for the unloading station at the correct gate and carried the baggage to the default manual baggage distribution station. When I inspected the control room for the baggage unloading station, I found that there were redundant PLCs to be sure that failure of a single PLC would not cause track switching to fail. Yet it did fail more than 50% of the time. These PLCs had input data from contact and optical sensors, but the primary system input came from the barcode reader stationed on the mainline track immediately before the gate..

As a transport cart approaches the United Airlines departure gate, its barcode

is scanned by a reader located ahead of the gate. That barcode data identifies the identity of the transport cart. The contained baggage, departure gate information from the PNR is known to the baggage handling system. If the baggage on the transport cart is intended for this departure gate, the control system is supposed to trigger the track switch to divert the transport cart to the gate unloading station. These barcode readers were connected to the gate PLCs using an Ethernet communications link.

What I observed was a flashing red indicator light on the front of the Ethernet

communication interface cards plugged into all of the PLCs. The indicator was

labeled “Collision” that refers to an event which occurs on older Ethernet networks. Collisions were a regular event on Ethernet networks that used hubs which created a "shared medium" or single collision domain for all connected devices. This system is governed by a protocol called Carrier Sense Multiple Access with Collision Detection (CSMA/CD). The CSMA/CD process works like this:

• Carrier Sense: Before transmitting, a device "listens" to the network to see if it is currently being used.
• Multiple Access: If there is no data being transmitted, the device can begin transmitting its own data. Because multiple devices have access to the same network, there is a chance two devices will sense a clear line at the same time and start transmitting at the same time. That is a collision.
• Collision Detection: If a collision happens, the transmitting devices detect the resulting garbled signal. They immediately stop transmitting and send a special "jam signal" to ensure all other devices on the network know a collision has occurred. This turns on the “Collision” light on the Ethernet interface card.
• Random Backoff: After an Ethernet collision, all devices that were transmitting wait for a random amount of time. This randomized wait, called a "backoff algorithm," ensures that the same two devices don't try to retransmit at the same moment again, but have no effect on other devices attached to the same Ethernet network.

• Experiments on Ethernet networks show that networks that are lightly

loaded, i.e. less than 5% of time transmitting data, rarely experience

collisions. As the network becomes more highly loaded, collisions become more frequent. Ethernet networks become less useful as the number of collisions reach 40% resulting in numerous random backoff periods.

Without doing any further analysis, I concluded that this Ethernet network used hubs and had become useless based upon the frequency of the collision indicator light on all of the PLCs. If the Ethernet network was useless, then the barcode ID on the cart was probably not reaching the gate PLCs in time to have the track switch activated, resulting in the transport cart bypassing the correct departure gate, which indeed was happening at least half of the time.

After consulting the wiring diagram for the Ethernet network, I discovered that the same Ethernet trunk cable was wired to an Ethernet hub located at each United Airlines discharge gate, the transport cart loading station, and the default transport cart unloading station. This was a single domain Ethernet network for the entire baggage handling system, and it was completely overloaded.

The solution to Ethernet network collision problems is very well known: 

• Replace the network hubs at all of the loading and unloading stations with an Ethernet full duplex managed switch. 

The purpose of the Ethernet switch is to prevent Ethernet messages originating on devices attached to the switch, from finding their way to the Ethernet trunk cable

connecting all stations. In other words, all Ethernet messages originating from any connected reader or PLC were being broadcast to every other Ethernet device connected to the network, whether it was intended or useful or not. Furthermore, since the Ethernet trunk cable was more than 100 meters long, messages would degrade, failing the network error detection method. 

Ethernet networks today use managed switches to avoid collisions. The “switch” is a network component that contains a memory buffer for every connected device. Full duplex switches contain separate memories for input and output. When a connected device sends a message using Ethernet protocol, it listens to the network, but it will always find it clear of messages. The message is uploaded to the switch memory. The switch maintains a list of Ethernet devices to which it is

directly connected on one of its own (local) ports; all other Ethernet addresses are considered “foreign”. Messages destined for local ports are transferred directly to the input buffer for that device. Messages for foreign devices are sent without delay to the connected port on an upstream switch. There is no contention for access to the Ethernet cables and therefore no collisions. Each port of a switch amplifies the signal

thereby extending the length of the network.

At the Denver Airport United Airlines automated baggage handling system, every time a transport cart passed a barcode reader anywhere in the system, or a piece of baggage with a barcode was read by a barcode reader, that message was being sent to the intended receiver, and the message was received by every Ethernet interface card in every PLC in the entire system because that’s the way a collision domain Ethernet network works. And what did those PLCs do with that information that was not relevant to them? They ignored it if it did not relate to the gate for which they were assigned, but more likely, they received an unintelligible message due to a collision and generated a jam signal further loading the network. Once in a while the message was received by the correct PLC and acted upon correctly. This was a highly loaded Ethernet network that had no chance of notifying the gate PLCs of an arriving transport cart and routing it in time to the proper gate

unloading station, all due to Ethernet collisions and delayed backoff periods.

In addition to the collision problem, the main Ethernet trunk cable was too long making it unlikely that data needing to travel more than 100 cable feet would reach its destination at all, that being the physical limit of collision domain Ethernet. 

My conclusion reported to the firm was the rebuilding of the Ethernet network to include a multiport managed switch for each gate of the United Airlines baggage handling system replacing the existing hubs, and to add new switches to separate the Ethernet trunk system into segments each with less than 100 feet of cable. With the revised Ethernet network, there would be no collisions and messages from the barcode readers along the mainline track would transmit the transport cart identity in time for the gate logic to evaluate and recognize the associated baggage in time to activate the track switch, routing the cart to the proper unloading station at the proper gate.

In other words - make the system work the way it was intended to work. I estimated the cost of rebuilding the United Airlines Ethernet network, adding the purchase of the number of high-quality managed Ethernet switches, and the cost of re-wiring new Ethernet cabling. I also included the installation of 3 new barcode readers in the transport cart loading station to assure the proper reading of the baggage tags wherever their position was as the baggage passed the cart loading station barcode readers. There would be some reprogramming of the PLCs installed at that station to accept the reading from the 4 barcode readers and select the best reading from the 4 results. The total cost estimate to rebuild the Ethernet network was less than one million dollars, would take approximately 4 months, and would be followed by about 30 days of testing.

Final Results

Unfortunately, the firm had taken this project in anticipation that this was at least a 6–7-million-dollar, 3-year effort and would be staffed by their own programming team skilled in the programming of mainframe computers. My estimate did not require any mainframe programmers and was not in the scope of the firm’s staffing. My estimate was rejected and not presented to the client, United Airlines. The entire project to automate the United Airlines automated baggage handling system was abandoned by United Airlines, and the manual baggage handling system that had previously been activated remained.