Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Programming Businesses IT Technology

Denver Airport Automated Baggage System Abandoned 268

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 discussion has been archived. No new comments can be posted.

Denver Airport Automated Baggage System Abandoned

Comments Filter:
  • Airports and Baggage (Score:4, Interesting)

    by Nosferatu Alucard ( 713350 ) <justingoodman@gmail. c o m> on Saturday August 27, 2005 @02:27PM (#13416635)
    I've been in airports all over the place, I would think 26 miles of track underground wouldn't speed up the process, especially if it is unmanned. I trust eyes on my luggage more than nobody knowing if it is really being moved or not. I've had luggage take forever in JFK airport, and the fastest was in another country!
    • I've had luggage take forever in JFK airport, and the fastest was in another country!

      This may come as a surprise to you, but some of us out here in the rest of the world don't consider US technology to represent the absolute pinnacle of human achievement.

      That's not to say that you don't lead in some areas, just not all of them. Judging by the horror stories one hears about US airports, I'm lead to think that aerial transportation is in the latter category.
    • by magarity ( 164372 ) on Saturday August 27, 2005 @05:00PM (#13417426)
      I would think 26 miles of track underground wouldn't speed up the process
       
      As a Denver resident and occasional traveller, I can tell you that when the new airport first opened and they used the automated system the bags were riding around the carousel before you could get from the plane to the pickup. My biggest worry was that someone would snatch my bag(s) before I could get there. Without the automated system, you wait at the carousel at least 10 minutes after dawdling to get off the plane. And there are plenty more places where sticky fingers in the back rooms can steal luggage away.
      • Incoming bags have never used this system. From the article:

        "United, Denver's busiest airline, has been using a stripped-down, simplified version of the network for its outgoing flights since the airport opened in 1995 - though 'enduring' is probably the better word, since regular breakdowns have continued despite years of tinkering.

        Automation never worked for incoming flights, whose baggage has been moved by handlers from the beginning. And no other airline ever tried to use the error-prone system at al

  • by Gothmolly ( 148874 ) on Saturday August 27, 2005 @02:27PM (#13416638)
    Look, you have to store the data somewhere. Just because your FedEx guy clicks his little wireless dealie when you sign for a package, doesn't mean that his little wireless dealie is the datastore for all info about the package.
    Why is the 'big central mainframe' the cause of the problems here?
    • by Anarkhia ( 2342 ) <graememc&gmail,com> on Saturday August 27, 2005 @02:32PM (#13416671)
      I agree. Actually, this sounds like exactly the kind of application that a big 'mainframe' would excel at - thousands of transactions per second as baggage is tracked by sensors along the way.

      I'm not sure why the idea of a mainframe is 'cold-war-esque', since they are still at the centre of much of what we do today.
      • Because mainframes aren't fashionable. A zSeries machine can do everything that any other big ass server can do.
        • Sure, deep blue and other contendant for the 1000000 googlyflop use mainframe for computer power. but most of the world do not use mainframe for that, but for transaction based system which handle a LOT of transaction per second with real time big database (for example airline RES system, bank system...) and security (transaction termin properly and start properly, and save data properly on disk). Processing power is your LEAST problem. Plus those mainframe system are so old they have been debugged by 2-3 g
    • by timeOday ( 582209 ) on Saturday August 27, 2005 @02:53PM (#13416769)
      Why is the 'big central mainframe' the cause of the problems here?
      Oh, I don't think anybody is really saying that. NBC did a report on this, including soundbytes with baggage handlers. By far the main problems were mechanical - the system broke down all the time and ate luggage like popcorn.
      • Other than the opening days a decade ago, the system has one of the best records of any US airport. The problem is that when trying to decide where to send it to, it would send it down the wrong ramp. basically, the system could not detect the bags correctly. Sadly, with RID coming online with baggage, the system would have been made reliable. Since this system will NOT be ripped out, it may still be brought back in the future.
      • by Anonymous Coward on Saturday August 27, 2005 @03:53PM (#13417078)
        I'm posting anonymously, because I was a maintaince guy on the baggage system until a couple weeks ago when I decided I'd better look for somewhere else to be because it became painfully clear that my job was going away. I've been there for ten years, and I'll admit that the machine has had some problems... But it very rarely goes down to the point to dosen't work.

        The fact is, it's *the biggest machine in the world*, bar none. There's almost 30 miles of completely automated track, more motors and linear accelerators than you can shake a stick at. A machine that big is going to require lots of time to shake out, and that happened about 5 years ago.. It's been running very smothly since then, because we've established protocols to cataloge and rank priority of repairs. You can't imagine the dynamic loads on it. 1/4 inch thick track pieces can snap in two if they weren't repaired correctly, and yeah, 5 years ago we were having problems. It's all but solved today, it's very smoth running and despite it's costs, it's STILL the cheapest way to move bags around in the world.

        Those baggage handlers are full of shit, it should be known. One of the main reasons it eats baggage is because those asshats load the baggage like morons. I've seen more panties strewn about than you'd like to know, and it's almost always a women's bag that gets ate. You know why? They pack the fuckers like sausages, and the baggage handlers just plain don't load them correctly. They won't put them flat, one end will be hanging out--and it's always the heavy end. The machine has close tolerances in some places where tracks intersect go over-under, and tight turns that can fling the bags out if they're loaded poorly, I mean they're going 30mph at some points, an improperly loaded bag will get tossed, regardless of it's weight or size.

        It is a mechanical monster, no doubt, any machine that big is bound to be... But it baffles me why they've got to shut it down at the peak of it's opperating efficeincy. It's never run so good, and they decide to kill it after we tamed the beast. You should realize that the command and control system they have in place that operates the machine is always being optomized, and sometimes poor programming has led to breakdowns and increased baggage eating.

        Conveyors will be much less efficient, and the airport dosen't have the infrastructure in place to handle the entire load of bags by hand, and even if they did it will be far more expensive. There are 4 turnstyles that will need to be built soon--and airport construction is anything but fast.. Like I said, it dosen't make anything but political sense to shut the machine down.
        • by MagikSlinger ( 259969 ) on Saturday August 27, 2005 @04:46PM (#13417358) Homepage Journal

          I can feel your pain. I've seen perfectly good systems thrown away for no other reason than politics and focusing on the one feature that doesn't work well ignoring the 95% that performs exceptionally and delivers value. But I gotta say to this:

          Those baggage handlers are full of shit, it should be known. One of the main reasons it eats baggage is because those asshats load the baggage like morons. I've seen more panties strewn about than you'd like to know, and it's almost always a women's bag that gets ate. You know why? They pack the fuckers like sausages, and the baggage handlers just plain don't load them correctly. They won't put them flat, one end will be hanging out--and it's always the heavy end. The machine has close tolerances in some places where tracks intersect go over-under, and tight turns that can fling the bags out if they're loaded poorly, I mean they're going 30mph at some points, an improperly loaded bag will get tossed, regardless of it's weight or size.

          I'm sorry. That's like saying "Because the user didn't click in PRECISELY the right spot the program crashed" or "because the assembly tech didn't cut to the 1/4" tolerance required for this car, it shook itself apart". If, at the end of the day, you have humans at either end of the system, you need to design for them. How they do their work and how they will use it. If you get frustrated that they won't behave like a computer, then the problem is with you -- not the people.

          • by MurphyZero ( 717692 ) on Saturday August 27, 2005 @05:16PM (#13417510)
            I'm sorry. That's like saying "Because the user didn't click in PRECISELY the right spot the program crashed" or "because the assembly tech didn't cut to the 1/4" tolerance required for this car, it shook itself apart". If, at the end of the day, you have humans at either end of the system, you need to design for them. How they do their work and how they will use it. If you get frustrated that they won't behave like a computer, then the problem is with you -- not the people.
            You do have a good point; however, if the human workers ignore the big label saying "FRAGILE" and toss the thing onto its destination, your comment is defending their actions because we didn't think of the 'human' nature. If their job is to load the bags correctly, then they need to load the bags correctly. If they do that, and the system doesn't work, then it is most definitely time to blame the designers, the machine, whatever.
          • by Anonymous Coward
            I agree, I'm not the guy that designed it, I'm just the guy that has to fix it when it screws up. But, it's a machine, it expects certian paramaters for it to work correctly, and the humans are the dynamic element who's job is to make it work. It's not like there are tolerances of 1/4", an inch, or even three that will screw it up... The thing is the carts are rectangular shape, and they will throw a rectangular bag into it carelessly, such that it goes in the short way, so long as the tag is pointing u
          • Japanese subway (Score:5, Insightful)

            by Spy der Mann ( 805235 ) <`moc.liamg' `ta' `todhsals.nnamredyps'> on Saturday August 27, 2005 @07:51PM (#13418302) Homepage Journal
            I agree with you, and I hope the following example can contribute.

            The inventor of the japanese subway tickets system had the same problem (regarding users not being precise enough, sometimes the tickets would go sideways, etc). People were sick tired of having the machines eat their tickets just because they weren't in the right position.

            He was so pressured that he almost gave up, so to clear his mind, he took a walk in the park. Then, as he was on a wooden bridge over a small river, he saw a leaf floating on the river moving against a rock. The leaf was perpendicular to the river flow, but then it collided with a small rock, that made it turn parallel with the flow.

            Based on this idea, he implemented a small device consisting of a round piece of metal that would rotate the tickets to the correct order, so they would pass the magnetic scan. Currently this magnetic ticket system is implemented in many countries, including the mexican subway which is over 25 years old now.

            So, in the end, it all comes to this: A well-designed system will pass even the worst conditions. The Denver Airport Baggage design team certainly needed to work more, and think of the worst cases - i.e. quasi-spherical (i.e. bloated) luggage.
          • No, it's the user's fault in this case. There's bad software, then there's apathetic, stupid teenage baggage handlers.

            Sometimes there is a Right Way and a Wrong Way to do things. It's not always true that if a person wants to do it in a certain way, they should be able to.

        • I'll grant you it's big -- but automotive assembly lines (which could be considered "machines") are larger, and CERN is certainly larger.
        • The fact is, it's *the biggest machine in the world*, bar none. There's almost 30 miles of completely automated track, more motors and linear accelerators than you can shake a stick at. A machine that big is going to require lots of time to shake out, and that happened about 5 years ago..

          How about the Frankfurt Airport? It has probably more passengers than Denver and had a functional baggage transport system for years (decades).

          In fact almost all bigger german airport have automated baggage transport. And
    • Why is the 'big central mainframe' the cause of the problems here?

      1) Everyone knows that mainframes are obsolete.
      2) Mainframes can't defend themselves while being scapegoats.

      • HAL 9000? (Score:3, Insightful)

        by benhocking ( 724439 )
        Mainframes can't defend themselves while being scapegoats.
        I don't know, I always kind of pictured "HAL" as a mainframe...
    • by BBCWatcher ( 900486 ) on Saturday August 27, 2005 @03:02PM (#13416817)
      You're exactly right. I really wish the NYT reporter would have done a better job figuring out why the baggage system didn't work. Instead we're left guessing, with vague anecdotes about carts tipping over and barcodes not being properly scanned -- all of which has nothing whatsoever with the computer in the back office. By the way, mainframes are at the heart of every major package shipper's operations, tracking every little bit of package-related data. Not so surprising: it's a job that must run reliably, without downtime. Mainframes do that well. And if the mainframe was to blame, why didn't United (or the airport or whomever) just drop in one of those wonderful Peecees to do the job? That would have fixed everything, right? Obviously no, that wasn't the problem.

    • They're just looking for a way to diffuse culpability. The fact is that someone screwed up big time, and it cost someone else a metric crapload of money. That's how things are done in the U.S.
  • Creepy stuff (Score:5, Interesting)

    by knappz ( 856470 ) on Saturday August 27, 2005 @02:29PM (#13416653) Homepage
    Go ahead and Google Denver International Airport [google.com] and look into some of the conspiracy-theories surrounding the building, murals, underground facilities, etc. It's pretty wierd stuff, interesting to say in the least.

    Whether or not it's true, I don't know. You decide.
    • Re:Creepy stuff (Score:4, Informative)

      by brajesh ( 847246 ) <brajesh DOT sachan AT gmail DOT com> on Saturday August 27, 2005 @02:40PM (#13416712) Homepage
      I did a google search on Denver Airport baggage system [google.com] and found this [bham.ac.uk]: classic case of bad software design.
    • I've read through all that. Most of it is stupid. Hey the airport has art! Hey the airport has a freemason's stone! Just like almost every single large construction project built in, i don't know, 400 years?
    • by lullabud ( 679893 ) on Saturday August 27, 2005 @05:11PM (#13417488)
      I took a picture of my punk rock cousin standing next to a mural of a soldier in a gas mask stabbing a white dove in the ass with what looks like a scimitar. Freakin weird. Who on earth would paint such a thing in the airport??
    • Re:Creepy stuff (Score:2, Interesting)

      by thinkmast ( 662468 )
      First of all there is no reason for this project to come so far along. It had to be cancelled long time back. The problem in Academic literature is called "Escalation of Commitment". it is not software per se, but a combination of psychological, social, organizational and social factors contributing to such big failure.... Mark Keil http://www.cis.gsu.edu/~mkeil [gsu.edu] has done a lot of work in this area. He published some recommendations based on the case study of DIA, that it needed to be abandoned long time
    • That isn't what does it for me.

      This is. [colorado-mapsite.com]

      There are no other airports in the world with runways like that. Most have runways in the direction of the prevailing winds, not in all four directions.
      • Re:Creepy stuff (Score:4, Informative)

        by jskiff ( 746548 ) on Saturday August 27, 2005 @08:11PM (#13418401) Homepage
        Rrrrright. No other airports have a layout with runways in different directions. Certainly not places like (caution, PDF warnings):

        JFK [myairplane.com]
        Chicago O'Hare [myairplane.com]
        San Francisco [myairplane.com]

        Your map is a bit out of date, by the way. It's missing runway 34L [myairplane.com], 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.
    • I don't know about any conspiracy theories; what I do know is that the Denver Airport, in all its several manifestations, has been one giant fuckup from my first acquaintance with it back in 1968.

      I don't recall the order or details of the various fuckups, but as I vaguely recall some general problems:

      The old airport was just plain old, neglected, and overloaded. Baggage and passenger areas were a day's hike apart, with no delivery system at all.

      So they built a new airport. Years over schedule, it finally ..
  • I can see it now. A bunch of guys staring at their PDAs wondering why the luggage sitting in front of them isn't going anywhere. On a side note, anyone else ever want to ride those tracks a la Toy Story 2?
  • by peculiarmethod ( 301094 ) on Saturday August 27, 2005 @02:32PM (#13416668) Journal
    When's the opening of the electronica club that is replacing it?
  • by Com2Kid ( 142006 ) <com2kidSPAMLESS@gmail.com> on Saturday August 27, 2005 @02:33PM (#13416676) Homepage Journal
    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!
    • I totally disagree that planning time was the problem. That may have been a valid reason/excuse at launch time, but they've continued pouring *millions* of dollars into the system for a decade!

      What I wonder is, are there comparable systems elsewhere that actually work? When NBC Nightly News covered this story they had pictures of utterly mangled bags, and it made me think how hard it would be to make a system that could handle any size or shape of bag, thousands upon thousands per day, with miles of cha

      • by Anonymous Coward
        That's because they have a contract with United to get it working. United uses DIA has a hub which is worth tons of money to DIA and Colorado, part of that deal was that they'd have this fully automated BAE monstrosity.

        The hardware and software itself are a classical example of engineering failure. In this world of "agile" and "xp" people don't want to acknowledge that, instead they'll blame it on "mainframes" or "old school this" or IBM or whatever. Bottom line is BAE did just about everything wrong

      • Um... Federal Express? millions of packages in every weird shape, and most of 'em manage to survive the sorting warehouse and get to their correct loading dock. What would be wrong with an airport using an effectively identical system?? after all, it's the same general type of operation -- packages/baggage comes in from all over, gets sorted, and sent somewhere else.

  • by Elrac ( 314784 ) <carl@smotr i c z . c om> on Saturday August 27, 2005 @02:40PM (#13416708) Homepage Journal

    Just as the implementation of IBM's OS/360 forms part of the "history" section of many Computer Science texts, so the Denver Airport baggage system is fast becoming history. The big difference of course being, OS/360 was a spectacular success, wheras Denver was a catastrophic failure.


    Writing this stuff up is fine and good, but I think it would be worthwhile to try to learn from it. What was done differently?


    If folklore serves me correctly, IBM was not afraid to throw money at the problem. I seem to remember they put two separate teams on the problem and took the best from each, fully conscious that half the effort would be thrown away. They sank as much money on it as was required, and ultimately succeeded.


    Denver probably ate many more Dollars than OS/360, though I wouldn't know. But:

    • It was done by a conglomerate of consulting firms, not in-house at a computer manufacturer
    • It presumably had many more people contributing to the specification
    • It attempted to be shiny, new, revolutionary
    • The like had never been done before, raising both the price and the expectation of failure

    Apparently, this last has become a self-fulfilling prophecy.


    I work in software development for an airline. It's amazing how much of a megaproject a reservation system is proving to be these days, and how many past attempts have failed. That's why one of the world's major reservation systems still runs in assembler on an IBM mainframe.


    I think we're talking over-engineering, Big Design Up Front, profiteering, and (attempted, far too late) price-gouging.


    Either that, or the only way to make a very large project successful is to code it in Assembler on an IBM mainframe.

    • You may be right. I've certainly worked on some hellishly bad COBOL systems on IBM mainframes and yet someone posted here that those projects were examples of how to do it. Jeez I feel so sorry for you Windows guys if that really is the case.
    • by Doctor Memory ( 6336 ) on Saturday August 27, 2005 @05:10PM (#13417475)
      The like had never been done before, raising both the price and the expectation of failure

      Actually, that isn't true. There are at least three other automated baggage-handling systems (at San Francisco, Munich, and Frankfurt). I think the biggest problem was the #1 project killer: a delivery date was dictated before any analysis or design work was done. Not to mention the fact that the airport had actually begun construction before the system was even fully specified (forcing the design to fit the established plans, instead of allowing flexibility in the plans to accomodate the new system).

      I heard a rumor that Siemens (who built the Frankfurt system) was invited to bid on the Denver system, and quickly declined after reading the RFP.
    • The real lesson is to always hire experts to do the job that will stake their reputation on the success of the project. All too often, people will exaggerate their capabilities and think they can defy the laws of physics.

      The mechanical failures of the project reek of poor coordination of the project and a failure to coordinate very early in the project with the architects and engineers. The loading, scanning, and software failures show a further lack of understanding of what needed to happen.

      Clearly, it w
  • by __aaclcg7560 ( 824291 ) on Saturday August 27, 2005 @02:46PM (#13416733)
    It's bad when your luggage is stuck in an infinite loop and the airport can't claim that the luggage was lost when it whizes by.
  • OS/2 (Score:5, Informative)

    by TheAncientHacker ( 222131 ) <TheAncientHacker&hotmail,com> on Saturday August 27, 2005 @02:46PM (#13416734)
    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 operating system is only one small part of the puzzle. Part of the problem could be bad custom software, bad planning, bad mechanical engineering, bad civil engineering, bad politics, maybe some payoffs and conflicts of interest and so on.
      • From what I heard, it was poor software control and management along with bad mechanical design. IBM has demoed standard OS/2 doing realtime tasks by balancing a stick or pencil on a 2 axis motion table. FWIW, out of the box, you can get 10ms timing accuracy as long as you control threading correctly and you keep the GUI/PMShell off the mission critical systems. Windows NT was only only getting close to 50ms back when I did some OS/2 and NT work for mil messaging systems. Oh, and the carts were falling off
  • Unions killed it? (Score:5, Interesting)

    by Anonymous Coward on Saturday August 27, 2005 @02:49PM (#13416751)
    "Automation always looks good on paper," said Veronica Stevenson, a lead baggage handler for United Airlines and president of the union local that represents United's 1,300 or so baggage handlers in Denver. "Sometimes you need real people."

    A system that would have streamlined and reduced the need for union employees has been found to not be very good by those union employees? Shock and awe, gentlemen. Shock and awe.

    Robots do exactly what you tell them to. It only damaged luggage if the luggage wasn't loaded onto the robot correctly, it only misplaced luggage if the robot was told to go to the wrong place.

    Can you blame me for wondering if the failure of this system was not entirely because of technical reasons?
    • Yeh, after all, what do we need people for? We should just do away with people completely and have robot consumers buying the things made by robot creators. Its the ultimate economic model - a perfect capitalist loop with no wastage and infinite efficiency.

      Now, where's my patent application robot?

    • Can you blame me for wondering if the failure of this system was not entirely because of technical reasons?

      Actually, it sounds like you're implying that the failure was entirely due to union malfeasance.

      Mike

  • Does anyone know how their computerised baggage handling rate ? I never heard that kind of horror story and as far as I know they have a fully computerised system, Doesn't they ?
  • Given the strength of baggage and package handling unions, this comes as no surprise. The idea of a nearly-fully-automated system that could eliminate many human jobs in the name of efficency must have really stirred them into action.

    Systems like these work for Fedex and UPS, so why couldn't it work for bags?
  • by Matey-O ( 518004 ) <michaeljohnmiller@mSPAMsSPAMnSPAM.com> on Saturday August 27, 2005 @02:57PM (#13416790) Homepage Journal
    Living in Denver and flying in and out of DIA, I can say it's better that any of the other Big City airports I've used. (Dulles, Seatac, Atlanta, DFW, Las Vegas, etc.)

    It was accomplished on a scale and timeframe that was hard to imagine before the project. As a Student in Civil Engineering, I got a behind the scenes tour in college.

    As the automated baggage system a f*ckup? Oh yeah, most certainly. Did they recover well? I'd say so.

    Course, DIA is a political animal, and in all things politics, you're guaranteed to piss off more than half your constituents. But it's a damn sight better than Stapleton was.

    Funny thing is, I saw a newspaper article about Denver's new airport, how it was in the middle of nowhere, and had cost overruns, and how it was nothing but a boondoggle.

    It was written about Stapleton in the lates 1930's. The switchover in 1985 meant that Stapleton was useful for more than _50_ years. I suspect in another 40 years, DIA won't be in the middle of nowhere anymore.
  • by hazee ( 728152 ) on Saturday August 27, 2005 @02:58PM (#13416793)
    From reading the article, it sounds like the problems had almost nothing to do with the software aspect of the system, whether on a mainframe or not, and everything to do with the physical design of the tracks.

    The fact that bags fell off the tracks because the corners weren't banked has nothing to do with the control system. Same for using unstable pallets to hold the bags.

    This whole article seems to be based on a flagrant redefinition of the term "bug" as we understand it. It wasn't software bugs that caused the problems, it was crap engineering.

    Which begs the question why, when other airports (such as Heathrow) have miles of tracks that work just fine, couldn't Denver do the same?
    • Which begs the question why, when other airports (such as Heathrow) have miles of tracks that work just fine, couldn't Denver do the same?

      In all fairness Heathrow isn't 100% esp if making a hop to Heathrow from one airline to another. The flaw though seems to be in human part of the equation on that case.... where a person checks in in Manchester, their bags to to Heathrow just fine... but for some reason they stay in Heathrow.. for days to a week. This seems to be most troublesome for that Virgin connect
  • by HermanAB ( 661181 ) on Saturday August 27, 2005 @03:02PM (#13416823)
    Now they employ thousands of little grey bug eyed people to push the little grey carts around the 26 miles of dark underground tracks...
  • the article does not draw any correlation between mainframe programming, software, or the failures of the system. a major flaw, according to the article was that: "The whirring baggage carts, programmed to pick up and drop off bags in a perfectly coordinated ballet, often just tipped over and dumped their loads." it also speaks vaguely about some "lizard tongue conveyor" whose failures would hardly seems the domain of software development. the denver baggage system fiasco sounds more like a failure in re
    • by corngrower ( 738661 ) on Saturday August 27, 2005 @03:42PM (#13417021) Journal
      Ah yes. Mechanical systems such as these 'material handling' systems are prone to such problems. Those software engineers experienced in this field and who do a good job subscribe to one simple rule:

      Hardware Lies.

      Which means, those laser scanners don't always read the label as they should, boxes and things get caught on edges and don't move even when the conveyor is on, electro-mechanical equipment doesn't always work, switches sometimes stick, etc, etc. Your job as a software engineer is to anticipate these and to try to make sense out of the information the hardware's giving it, even though something may be garbled, and write your program so that the system can keep running and that operators are made aware of the mechanical problems the software is seeing so they can correct the situation.

  • by threaded ( 89367 ) on Saturday August 27, 2005 @03:10PM (#13416871) Homepage
    From a RTFA between the lines it would appear that they started on this project late, hadn't factored in where they were going to put the necessary IT equipment, almost as if it were an after thought. Essentially their customers baggage was well well down the list of priorities.

    And then they blame it on the computers.

    Typical.

    Some companies/public services really do give the distinct impression that they consider their customers/clients a major inconvenience as they attempt to make a profit/index linked pension.
  • by pilotcam ( 865896 ) on Saturday August 27, 2005 @03:16PM (#13416896)
    I'm an automation systems engineer. I always find the failure of systems such as this very interesting. I've done firefighting operations on many jobs where they were on their way down the toilet. Most of the time failures are caused by only one weak area in a project.. usually it's mechanical design problems, or software (logic) problems. I have seen an instance once where it was a union sabotage problem. It was interesting how that particular line would run perfectly well on it's own during the weekends; but during the week it was a disaster. Since I spend most of my time writing automation logic and robot programs, I tend to get stuck with developing software workarounds for bad mechanical designs. The worst that I recall was a tread booker for a tire plant. It was one of the most crude machines I've ever worked on. My favourite part was a coupling that tended to slip; I was asked to put code in that 're-homed' the servo axis every few minutes automatically. I was paid by the hour; I'll software patch the hell out of bad mechanics if you want! I'm not sure what the problem(s) "really" were in this instance, but it's kind of sad; what airport will be brave enough to try it again?
  • by BBCWatcher ( 900486 ) on Saturday August 27, 2005 @03:18PM (#13416905)
    If only the NYT reporter used Google! According to this article [calpoly.edu], here's what BAE used:

    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 [bizjournals.com] 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!

  • by dmh20002 ( 637819 ) on Saturday August 27, 2005 @03:25PM (#13416938)
    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.
  • by tulare ( 244053 ) on Saturday August 27, 2005 @03:38PM (#13416990) Journal
    I was living in the area when DIA was being built (and life sucked badly after it was complete - pretty much everyone I talked to preferred Stapleton for many reasons, the simplest of which was that you didn't have to drive 5 miles at 25mph after getting your short-term parking ticket that charges by the tenth of an hour).

    Anyhow, I remember they held a press conference when they finally started the baggage system, and it was one of the funniest things I've ever seen in my life. Suitcases were flying every which way, often ripped in half, and the reporters were all hitting the deck! Of course, this was funny to me because I wasn't down there dodging flying Samsonites; one of the problems with the baggage system was the startlingly high rate of Workers Compensation claims of the workers who had to deal with it, and the most-common cause of injury was, unsurprisingly, falling items.

    If anyone has a link to that video, I'd love to see it again. I've tried, but no luck. Maybe some enterprising soul in one of the Denver local news channels can put it up on their website as part of the story of the system's closure?
  • by ElitistWhiner ( 79961 ) on Saturday August 27, 2005 @03:38PM (#13416995) Journal
    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.
  • The history/internation history channel showed a program about the Denver Baggage system - I think under it's "Modern Marvels" series - not sure.

    Anyway, they did address the problems plagueing the system but made it sound like a thing of the past - that the entire system was deployed too early because of pressure to have it operational on the opening day of the airport.

    The major problems were that baggage would get stuck or lost.

    Lost - mainly due to the tags not being read by the single UPC like laser. The
  • by sisukapalli1 ( 471175 ) on Saturday August 27, 2005 @03:46PM (#13417040)
    A few years ago, K-Mart introduced automated checkouts (with all the buzz words of "convenience", "automatic", "quick"). It caused a lot of problems. The solution: K-Mart started putting notices that said, "To improve customer service, we are opeing more checkout lanes with a cashier" (the same ones that they closed earlier). In MBA speak, they have made two "improvements" in a space of a year!

    S

    • They still have those automated check outs at Home Depot and I love them!! Of course they only have 1 real person checkout open at the same time. And What I find odd, and they do this at banks is have like 15 checkout counters/teller windows but at the busiest time only have like 2 or 3 cashiers/tellers. It is like they want you to think they have capicity to serve, too bad the cashiers cost too much. I think those automated check outs are the way of the future. One cashier served counters. I have had issue
  • For more background see Software Runaways: Monumental Software Disasters [phptr.com], 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

  • ... mental note

    be
    more
    careful
    of
    the
    word
    PROTOTYPE
  • I believe this system was the subject of a Modern Marvels episode on the Discovery Channel. They talked about early issues but that they had been worked out and the system ran very well. Just when you could believe everything on television! Of course, I'm in effect believing what I'm reading on Slashdot if I think it never worked. Of course I could RTFA and then believe that and....my head hurts!
  • 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 [amazon.com] 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.
  • As a Coloradoan who has watched, DIA open and get going, the thing that struck me most of all was the planners expected everything to work perfectly. There was no backup plan for when baggage system failed, so people were scrambling to create one so DIA could open. The first time the train failed (which is rarely), there was a mad scramble to get some buses so that people could catch their planes. The first monster snow storm showed that that the airport could remain open, but the road to the airport clo
  • Technology is often cited as eliminating middle jobs and adding high and low end functions. By eliminating the need for engineers to design baggage robots, portable devices have made low end baggage haulers more valuable and high end airport managers more valuable.

    The same can be said of the lowly automobile. Just when you think airplanes are a better deal, new innovations like GPS and wireless internet make the car more valuable and service plans more valuable.

  • DIA is a success (Score:5, Interesting)

    by RzUpAnmsCwrds ( 262647 ) on Saturday August 27, 2005 @07:00PM (#13418029)
    With all of the cost overruns, the wierd artwork, and the abandoned baggage system, DIA is still the single most usable airport in the United States.

    1: There is more room for security which leads to shorter lines. Additionally, connecting flights don't require going through security again, further decreasing the load.

    2: The airport design is simple and easy to understand. There is only one terminal building to arrive at, and the concourses are arranged logically.

    3: The terminal is very nice - well lit and refresingly open. There is a distinct "open air" feeling that doesn't exist in many airports. There is a wide range of services as well - plenty of food, bookstores, coffee, etc.

    4: Unlike Stapleton, snow doesn't shut down DIA.

    5: The train system is fast and effective.

    6: There is room for expansion, which is particularly important as Frontier expands (DIA is a major United hub, and the only Frontier hub).

    7: The large size of the airport and openness of the runways make it easier to land and eaiser to route traffic.

    DIA is the world's 10th largest airport. Give it a bit of credit.
  • But... but... I thought mainframes rocked our socks and needed more fresh blood to replace the greybeards? [slashdot.org] What's this with a mainframe not doing the job sufficiently???

    (Disclaimer: to be fair, this is a strawman argument. I work in a heavily mainframe-dependent company and industry, and I have no doubt that the mainframe *could* have been programmed properly to handle the load. The real problem in this case were ones of mechanical engineering and bad design/system engineering... Things like bags being
  • Evidently they should have hired some better programmers.

    $200k, I'll have it fixed in one year, and it'll run on their mainframe.
  • Look at the problem domain.
    1) it is a routing problem. Probably an NP problem like the traveling salesman problem but they wanted to solve it in *real time*. What is the best way to route a piece of luggage and get it to the correct gate so it can be loaded in time?

    2) In addition to point 1, there is the added issue of the start and end points changing. This is more than a static routing problem, it is a dynamic problem., due to gate changes etc. It strikes me as a much harder problem.

    Applying a little *gas
  • Let me tell you a story. I work in the automation industry, and have for 5 to 8 years now, depending on when you start counting. When I started, I was so keen about automating everything. "Sure, we can make it do that!" All the experienced old fogies kept telling me to shut up in meetings because, absolutely we were NOT going to make it do that.

    Now, 5 years later I've become the old fogie, parading the KISS principle around like it's a religion unto itself. I've seen first hand on many occasions how an
  • That when you need it delivered
    • On Time,
    • Under Budget, and
    • To spec

    Involving the government in any way, shape, or form is the surest way to fail it.

    I'm sorry people, but the government is simply not capable of delivering quality results. How much money, lives and time will be wasted until people figure this out?

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Working...