Slashdot Mirror
Denver Airport Automated Baggage System Abandoned
cherylchase writes "Denver International Airport opened in 1995 with an ambitious fully automated baggage system: 26 miles of underground track, thousands of small gray carts, all controlled by a mainframe programmed for just in time delivery. But the system never worked well; bugs delayed the airport's opening for months (at $1M/day). The system has now been abandoned as a cost cutting measure." From the article: "Technology, too, has brought change. Back then, the big-brained mainframe doing it all from command central was the model of high tech. Today the very idea of it sounds like a cold-war-era relic, engineers say. Decentralization and mobile computing technology have taken over just about everything, allowing airlines, warehouse operators and shippers like FedEx to learn with just a few clicks the whereabouts of an item in motion, a feature that was supposed to be a chief strength of the baggage system."
This was on the world news (well nightly network news) almost 3 weeks ago, bleck.
Also, they mentioned that this system was the first one run by PCs! Wikipedia has had this up for quite some time as well.
Reading up on it, it appears more that the lack of PLANNING was more at fault. The system was designed AND implemented with only 2 years left before opening, and with the majority of construction on the airport already completed, meaning the physical aspects of it had to be squeezed in where ever spae was available, given that, the results are not to surprising.
If anything this represents a massive failure on the part of management to allocate enough time for a project, implementations of far smaller systems than the one at Denver spent two years alone in just the research phase!
Need help treating your acne? Come here!
I did a google search on Denver Airport baggage system and found this: classic case of bad software design.
95% of all sigs are made up.
Not mentioned much these days was that the huge delays in getting the Denver Airport baggage handling system was a huge black eye to IBM who had been bragging loudly about how their OS/2 operating system was running it.
The BAE design includes a number of high-tech components. It calls for 300 486-class computers distributed in eight control rooms, a Raima Corp. database running on a Netframe Systems fault-tolerant NF250 server, a high-speed fiber-optic ethernet network, 14 million feet of wiring, 56 laser arrays, 400 frequency readers, 22 miles of track, 6 miles of conveyor belts, 3,100 standard telecars, 450 oversized telecars, 10,000 motors, and 92 PLCs to control motors and track switches.
Let's make some educated guesses here. How many PCs? 300? Good grief! Later in the article it says the PCs were running OS/2. So what? This is just bad architecture, regardless of OS. So many parts, so many points of potential failure. And the NetFrame Systems "fault tolerant" server is simply...a glorified PC. (It's X86, ~300 MHz P2, and likely running Windows NT, according to other sources.) This article has more on the sad fate of NetFrame.
There's nothing even close to a mainframe computer in this baggage handling system. The New York Times sucks again!
there is a section on this fiasco In "waltzing with bears' a book on software risk management by demarco and lister.
they point out that although the software is blamed for the 1.1m / day cost of lateness, the reality is that many other contractors unrelated to the baggage handling system hid their own lateness behind the very public software problems. Even if the baggage system was on time the airport likely wouldn't have opened when it was supposed to.
The book is pretty interesting and uses the Denver thing to show how a lack of risk management played a big part in the software woes.
I personally know the conveyor mfg'r in NZ. His co is the only serpintine conveyor patent holder worldwide. If your bags go around, that's his system. Early-on he could not get US engineers to respect design limits of his product's radii limitations.
It wasn't just a botched set of expectations. Blatently they designed away in full-face of specifications to the contrary that components had working limitations. The attitude was fix-it, rather than design to product spec.
For more background see Software Runaways: Monumental Software Disasters, ISBN: 013673443X, 1997 by Robert P. Glass includes the history of the Denver airport baggage handling system and 15 other desasters in large software systems, e.g. the FAA Air Traffic Control system (death by committee), American Airlines reservation system and others.
Be aware that this is not a technical book and mostly concerned about project management and the problems of defining the requirements of large projects years ahead of their finalization. All the project failures described are very large, complex projects including lots and lots of politics.
As a whole the book is rather depressing, because although in review the cause of failure seems rather obvious, but there is no obvious way to avoid them. It's also a rather dry subject, do not expect to many laughs. But it is great for a large picture on software development, a kind of "how not to do it" guide.
memomo: free web based language trainer DE-EN-ES-FR-IT
There were a whole host of problems, including late starts, moving specs, a plan for a small system that was changed to make a plan for a large system by simply multiplying the spec for the small system, construction interferance, etc.
Software Runaways has lots of information about this projects problems. And lots of good info about other runaway projects such as the new ATC system that hasn't gotten off the ground yet.
According to the Fine Article:
BAE Automated Systems of Carrollton, Tex., which designed the system, has since been liquidated, and no one associated with the effort could be reached for comment.
I think you're confusing it with BAe, formerly British Aerospace.
If your comment title says 'Re: Foo', I'm not likely to read it.
Rrrrright. No other airports have a layout with runways in different directions. Certainly not places like (caution, PDF warnings):
JFK
Chicago O'Hare
San Francisco
Your map is a bit out of date, by the way. It's missing runway 34L, the recently added runway to the northwest side of the field.
Oh, and the reason for the layout is pretty simple, aside from the obvious weather strange-ness that pervades Denver. When winds are out of the northwest (pretty common), planes can land on 26, 35L, and 35R and taxi to the terminal without delay if they roll all the way to the end of the runway on landing. Similarly, planes can take off from 34L, 34R, and 25 with a relatively short taxi from the terminal. That, and the fact that all of the runways are spaced far enough apart that they can take concurrent instrument approaches in bad weather points to some pretty clever designers in my book.
It's "no one," not "noone." Who the hell is noone anyway?
If you walk the bridge from Concourse A, you may waiting a lot longer than ten minutes! That's why if it's more than I can carry on, it ain't going. That's also why UAL/Ted wants to get gates on Concourse A. Frontier, with all their gates at close-in (by DIA standards) Concourse A, has a competitive edge. Many customers like having walk-in access, with a separate security screening station restricted to Concourse A passengers. Concourse A is a lot like going though the old Stapleton Field terminal, except it's a half hour closer to Kansas City!