Slashdot Mirror
When Bad Software Can Kill
bhoman writes "A wrist computer that tracks and calculates safe diving times and
limits for SCUBA divers had a dangerous software bug that may have been covered
up by company executives.
This SF Chronicle Article
details the problem, product, company, and some of the lawsuits.
According to the Chron article, company execs tried to cover up and
deny the problem for years, but their
official website
makes it look like they did a voluntary recall."
And it has extensive safety measures built into it to prevent insulin over delivery. Obviously, when you put your life in the hands of a machine, you want to make sure it works, and that when it doesn't, you're notified. If a company is guilty of covering up a problem like this, I hope they get sued out of existence and the people guilty spend some time in jail.
Fortunately, there are still (I hope) some companies out there that are honest and worry about the safety of their users, particularly in life-critical applications.
What a slimy guy though, to prevent any notice of the fault from getting out, and firing managers for trying to get the word out! Man. Makes me angry. *Fumes*
There are two major diving computer companies with "original" systems-- UWATEC and SUUNTO. Uwatec (named in the suit) has been known for less conservative systems; they let a diver stay down longer.
This is attractive to people who do decompression diving, because it means that they don't have to hang out shivering at 5-10m with nothing to see as long at the end of the dive.
Suunto takes a different approach, has a more conservative model, and makes it easier to force your computer to be more conservative still. Most divers don't use that function, because it is contrary to their desire to have maximum bottom time.
Proper diving procedures recommend using two different computers, and always relying on the more conservative unit for your decompression limits. (Assuming that you are doing a computer-only dive and not a table dive.) When your life is at stake, you have to assume that equipment has problems, and act accordingly.
I had a friend in the US who underwent LASIK surgery. He told me that his wife, who was computer-savvy, and was watching him being operated on, saw a Win95 box dedicated to controlling the laser and the mount's stepper motors, and that the operator was repeatedly hitting ENTER to make that recurring message box with a red X disappear. She got worried but the surgery was already under way, so she didn't say anything.
...
Fortunately, his LASIK succeeded. Later on however, he went back to the hospital and asked about the operator's behaviour : the response was "well, we were worried at first, but that error message comes back every five minutes and the machine always works anyway".
Scary
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
On the issue of punishing companies for unsafe practices like this, sometimes it's 50/50. Depends how much sway they have. I'm not anti-capitalist über-left cynical jaded moron, but after reading Fast Food Nation recently, I don't have a whole lot of faith in the government's ability to control this kind of activity on a large scale. The government used to have a lot more power over companies since Theodore Roosevelt's time, but the book seems to point the finger at the Reagon era for the change.
Anyway, it wouldn't have been bad PR to admit a mistake, hell it's only human to make mistakes, even when something is as serious as this. The problem shouldn't have been there at all, but it was caught before anyone was hurt, so they should have just apologised and fixed it. Cover-ups make me sick.
Yup...
This is slashdot... you have to be an anti-capitalist über-left cynical jaded moron to be here.
I have dealth with Healthcare Software for Pharmacy and Lab systems where a delay or missed processing of an order can be fatal to a patient. One thing I found before leaving that industry was that there was a massive migration of these systems from reliable-high uptime servers (VMS, Unix, Mainframe) to Windows client server enviroment. If you think that the Klez virus is bad in a regular office, try working in an enviroment where it brings down a server critical to patient care.
Exposure is a good fictional title about a certain floating-point bug in a mainstream CPU by a popular fictional chip maker. Doesn't matter if the software is perfect if the hardware isn't.
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
I've always wondered why the Engineers had to sit through the ethics lectures, and the Comp Sci people didn't. In this day and age, we are relying on automated systems and programs enough so that the people making them should be aware of the consequences of failure.
Until one of the software packages that controls the new-ish electronic traction, suspension and stabilization systems bugs out killing a family of 6 in their SUV.
The sad part is that for an error like this, multiple people will have to die or risk death before anyone will clue into what the error could be.
Of course they died, because they were missing the single most important piece of dive safety equipment: A hyperintelligent dolphin with miraculous capabilities of interspecies communication.
Flipper: Ennnhhhhhh! Ennnhhhhhh! (backs up)
Diver: What's that Flipper? There's a software bug in my wrist diving computer that could lead to my grisly death?
Flipper: Ennnhhhhhh! Ennnhhhhhh! (backs up)
Diver: Well thank God you told me! Otherwise I never would have known!
Flipper: Ennnhhhhhh! Ennnhhhhhh! (back up)
Diver: What? There's a Russian sub off the coast?
In short, never go diving without your near-omniscient dolphin.
Lawrence Person (lawrencepersonh@gmailh.com (remove all "h"s to mail)
http://www.lawrenceperson.com/
When I dive, I plan with a conservative dive table. Why risk your life just so you can stay underwater for another few minutes?
Corporations, by their very nature, don't care about their customers. All they care about is profits. Granted, some people within coporations may care about customers, but they have to follow the corporate rules.
Leeman and Ruchti (the founders of the company) ought to be thrown in jail for a long time and the company liquidated. All proceeds should be given to those harmed by their actions. I don't care that the current owners "didn't know" about the problems. It should serve as an incentive for future people/corporations that you will be held responsible for what your company does.
But why is the rum gone?
Who are you? The apprentice of "PhysicsGenius"? That would at least explain the pseudo-intellectual gibberish you are writing.
That being said: what makes you believe that it was a programming error? If you had bothered to read the article instead of spouting some nonsense about mathematics and the "flaw of modern computer science", you would have seen that it was a design error, meaning the specification itself is in error. You can answer "the equivalence" problem, but if the specification is flawed you're going to get flawed code. Garbage in, garbage out.
-- The plural of 'anecdote' is not 'data'.
I attend a small state university that is decidedly not renowned for its CS program. I'm coming up on my senior year. In no less than three class (Data Structure, Software Engineering, Algorithms) I have spent at least a week concentrating purely on proof of the correctness of an algorithm by various methods. Software Engineering took over a month on testing, primarily concentrating on mathematically rigorous proofs and automated tests (because a mathematically correct and proven algorithm can easily be implemented incorrectly). Pardon my insulting question, but when was the last time you attended college?
You like splinters in your crotch? -Jon Caldara
I would have to say that the above is the best argument I have ever seen for open source software. If your life is on the line, if you may be damaged by software, then that software sourcecode should be forced to be open source. At the very least it would prevent weasly scumbags from thinking they could cover up their misdeeds, at best it might insure that companies would try and get the product right when peoples lives are at stake.
ok, I work at a dive shop in Toronto Canada, I am a certified rescue diver. No diver should _EVER_ rely strictly upon a dive computer, they should always have a backup depth and pressure gauge. Not only that but they should plan their dive using Naui or padi (or similar) dive tables and follow their plan. If at that point their computer thinks they can stay longer.. thats good but follow your plan anyway, better safe than sorry! The point is, get trained properly, and use ur brain not a computer to do the thinking.
Oooooh, you're so wrong!
You can prove the correctness of a bit of code, but it's very hard, takes a long time and is highly skilled work. It becomes especially hard if you're trying to do it with a grammar for any real-world programming language and the code is anything approaching complex. For most real world cases it's simply imppossible.
Mathematical proof of a program's correctness is simply too hard and costs too much money to be applicable in the real world.
If you did a real CompSci course, such as the one I did at Cambridge University, you'll discover that "CS people" are very very far from being "code nerds". I was supervised by a couple of mathematicians for some courses who could code no Java, C++ or Perl (although one of them knew much ML). Proper Computer Science folk are seriously academic and embrace the mathematical side of the field. You can't write an optimising compiler without doing so, to name but one thing.
People don't "ignore this issue" - it's just virtually inapplicable to real world problems. Exteme programming is not "management rubbish". If you'd ever actually read a book about it and tried some of the methodology you'd appreciate that. You forget that the driving force for commerical products is pretty much how much it costs, against the feature set and speed. Provided it doesn't crash very often, that's Good Enough. Unless you're the sort of type who doesn't pay for Windows, I'd suspect most people would rather have a version for $100 that crashes once a month than a version for $1000 that crashes only once a year.
Get down off your pretentious high horse and get a clue.
I don't dive much, but I still have my padi dive table.
h tm l
"For flying up to 8,000 feet after diving: Less then one hour TBT (Total bottom time) , wait 4 hours; less then 4 hours TBT, wait 12 hours." *PADI tive tables (C) 1983
[where TBT = RNT Residual nitrogen time) + Actual Bottom time ]
I dont have my padi manual onhand to estimate how long the folks were down as my table doesn't cover flight, only covers up to 24hours reccomended desaturation time, and doesn't cover this Nitrox stuff.
http://www.stud.ntnu.no/~playboy/diving/diving.
My old PADI book wouldn't cover Nitrox either, so if I were to use it, I would have no choice but to accept their information as fact, or buy new tables.
There is no sanctuary. There is no sanctuary. SHUT UP! There is no shut up. There is no shut up.
Six or seven years ago, I worked with a fellow with the very British
name of Ken Appleby. He had a Spitfire, I had my '74 B, and we used
to motor out to Pickwick's Pub and throw darts after work on occasion.
Ken used to work for Lucas in the UK, specifically for a division
of Lucas that did military electronics. My favorite of his stories
was about the time he had been working on a computer-controlled
torpedo. It used magnetic core memory to store the programs, which
had the advantage of being very non-volatile as well as not susceptible
to EMP discharge.
So Ken got to ride on the boat for the first test of the torpedo that
used the computer with his program in it. Somewhere out in the North
Sea, on an R. N. cutter, Ken and his crew launched the first ever run
of this new weapon, and Ken learned a new respect for debugging...
The program was supposed to make the torpedo shoot off the boat, dive
to a depth at which it couldn't be easily detected, then circle
toward the target, climb to striking depth, and hit the target. There
were on-board sensors to detect sea level, and the torpedo was supposed
to travel at a preset distance below sea level, with constant feedback
keeping it on track.
Somehow, somewhere, Ken had multiplied one of the 3D coordinates by
a negative number, and this error soon propagated through the
transformation matrix (the mathematical construct that models 3D
space), with predictable results.
Within instants of hitting the water, the torpedo -- instead of
sinking out of visible range -- blasted up and out from the water in
a great silver fountain, then continued skipping across the surface of
the blue like some sort of deranged wingless flying fish. Worse yet,
instead of circling toward the target, it circled all right, but began
to return to the ship that launched it. Fortunately it was not armed,
but they still detonated the self-destruct on it rather than let it
slice through their ship at 50 knots or whatever rate it travelled.
Because of the non-volatile core memory, Ken was able to debug the
program from what the Royal Navy frogmen could recover from it, and
he fixed the problem for Rev 2.0.
But I must admit that the image of the torpedo, splashing happily
above the surface of the water like an aroused porpoise, is one that
returns to me in idle moments such this. What else would a Lucas
torpedo do but try to fly?
I had a scuba instructor for my first certification, Di Dieter, who had experience diving with Coustou (hope I spelled that right), he also dove the Andrea Doria on several occasions, and basically has been around. I'm sure he's had thousands of dives, perhaps approching or even exceeding the ten thousand mark, under his belt (close to forty years of diving, multiple daily dives, several hundred dives a year, including a grueling dive schedule with Coustou, and he's a dive instructor). He's a no-nonsense guy with a good dose of common sense, and has little patience with screwups.
He did it right. He taught us to dive the navy dive tables, one up, one over, plus a safety margin. This was when the recreational tables had just come out. My friend and I dove for some years after that, and never had a problem. At that time, dive computers were out for a few years, and all the dive shops, through their "train with really expensive gear so you buy it" training programs had all their students diving with computers throughout their training.
Di Dieter did it right. He trained us with the old fashioned, and RELIABLE mechanical guages, waterproof clocks/watches, and tables on waterproof material. No computers.
While computers can extend dive times because you don't spend all your time at maximum depth, you also increase risk in doing so. Whether you decide to use the dive computers or not, you should ALSO have the mechanical pressure and depth guages, and manually calculate your dives.
Solely relying on a computer for diving is sheer stupidity and absolutely reckless. The minimal increase in bottom time is not worth the risk of an embolism, or the bends, which can be a debilitating condition for the rest of your life, or even fatal.
Do it right. Manually calculate your dive, and rely on your brain, not a computer, to stay safe and not risk your life. Bring that fancy computer with you if you want, but don't trust it over basic guages.
And Di, if you're reading this, this is the dude with the 43 lbs of lead on his weight belt! Hope you're still diving. And enjoying life. Peace.
Attacked by mathematical methods?! I've just spent another 4 hours revising Z, a horribly evil formal language designed to almost exactly the system you propose. Unfortunately, it doesn't work, at least not for the vast majority of software programmed.
I don't know about most other CS students, but the reason I despise mathematical formal proofs in computer is because they are infeasible, and, frankly, you're more likely to make a mistake with the math then you are with the code, once the project gets big enough.
Have you ever used formal methods such as Z to prove your software? Believe me, it's not something you'd do willingly. The only possible uses for mathematically proved software is with simple, but important code, like in an ATM, for example. Anything larger and it all falls apart.
My point is that mathematical methods aren't the answer. Even my lecturer on this subject, who co-wrote the language, would use such techniques on a large software project. You'd have to be insane.
I've never worked in an environment where the specifications and the infrastructure stayed constant long enough to finish a proof of correctness.
I've never worked in an environment where I was coding on top of something that was already proven correct.
I've never worked in an environment where the specification itself was proven correct. For example, the dive computer problem was that somebody didn't specify that the computer should count time at the surface as 79% nitrogen.
As a security geek, I'd be delighted to see perfectly correct code. There have been plenty of attempts to devise formal models of security, e.g. Bell-LaPadula and Clark-Wilson. Apply those all you want, but in real life zlib will have a buffer overflow, and the minimum-wage operator who needs a new refrigerator will sell information to the nice private detective.
I actually had a little trouble with an ABS system a few years back, on a '94 Pontiac Grand Am. The system failed in such a way that once in a while when I would apply the brakes, the pedal would sink all the way to the floor without doing anything to slow the vehicle... the brakes were just plain not there. I would immediately let up on the pedal and reapply the brakes, and then they would work.
Luckily, the first time this happened I was slowing from about 25mph to turn into a parking lot, with no other traffic around-- otherwise things might have been more, shall we say, interesting.
I was stunned when the service people told me that the failure of the ABS could take out the brakes entirely. One can just imagine the kind of lawsuit that could have been unleashed, had my brakes gone out at a truly inopportune time-- like if a little kid ran out in front of my car, or I were unable to stop at an intersection and ended up getting t-boned by a speeding 18-wheeler as a result.
~Philly
In my experience as a diver for the last 15 years, I have seen many divers who rely on dive computer technology to get closer to the edge and get more bottom time, longer dives, deeper dives, etc. The original "paper" dive tables were based on the experience and testing by U.S Navy diver's and are VERY conservative. The advent of widespread use of dive tables for recreational diving resulted in diving being a lot safer. The advent of computerized tables has promoted a false sense of security to the diver (kind of like having a radar detector in car - you might avoid more tickets, but you may speed more also) - I myself have dove profiles I would never have attempted based on the dive tables but the computer "said" it was OK so we did it. Here is a story about a dive computer specifically designed to be used with mixed gas diving (nitrox) adding yet another element of risk over regular diving. I think that dive computers should come with a waiver that says "if you trust you life to this device you do so at your own risk". Based on what the story said I would never have gone flying so soon after diving using regular dive tables - they threw the dice and lost, and now they want to pretend that what they were doing was risk free and the dive computer caused all the problems - Its nice that the dive computer maker is recalling the units to make them more conservative. Too bad those divers didn't buy the "common sense" computer too.
This kind of story makes you want to stick your head in the sand and not buy any critical applications from corporations...Unfortunately, for some "leaders of industry," protecting image is more important than the safety of the users. Users are expendable; image is not.
So you're saying you're not going to ever drive a car again?
Computer applications aren't the only life-critical products we depend on. You put your life in the hands of corporations every minute of the day. How are you going to make sure your house is structurally sound? Buy open-source lumber and build it yourself? Are you going to keep eating food which has been prepared by corporations?
But as you, the Pinto history and others point out, corporations will only care about the lives of their consumers to the point at which it becomes economically favorable to do so. If it's cheaper to settle 10 probable death cases than issue a recall for the faulty product, they settle. The value of human life doesn't factor in. Today's cars only sell themselves on safety because it has become economical to do so, i.e., consumers value safety and demand it from their products.
This is why we need government oversight. I'll tell you what makes me want to put my head in the sand: how we are not funding the oversight agencies enough to do their job. We just passed two tremendous tax cuts in three years; I don't know where the cuts are going, but I feel like people take safe food and transportation for granted around here. I hope at least the sand is clean.
I'm an avid scuba diver, but I have never been keen on using the dive computer for this very reason; rather I go for the manual method even though you supposedly cut your dive time down.
Having worked in software for many years, I have yet to see a perfect program, and I have never wanted to trust my life and/or health to the programming and testing skills of someone else.
Don't forget that, for years, the PADI dive tables were Navy Dive Tables. For a very good history of dive tables, click here. Dive tables are based on the same theories and technology as dive computers. The biggest difference is that they are more prone to human error than are dive computers.
It's great to say "plan your dive and dive your plan", but people are fallible. Your buddy may go a little deeper than he/she intended. You may, because of narcosis, get confused about the maximum time or depth. You or they might have problems that slightly delay your ascent. If you plan to go to 90 feet and you drop a video camera to the bottom at 110, unless you're Bill Gates, you're probably going to go get the camera and cut the dive short. So much for the plan. (I've been a diver for over fifteen years. I've seen everything from divers getting entangled in wrecks to outright equipment failures. Don't reply with some macho explanation of how you can foresee and prevent every error. You can't and if you believe that you can, then you need to stop diving until your ego and testosterone stop affecting your reasoning.)
My buddy and I each bought dive computers at the same time. I made it a point to choose dive computers from different manufacturers so that a sofware flaw in one would not put us at undue risk. We stick close together and always use the more conservative of the two computer readings. Had one of us had a UWATEC computer, we would have noticed the problem immediately when comparing the two computers.
You are a 'certified rescue diver'? That has as much weight in the diving community as saying you are 'Network +' certified in a room full of CCNPs. You are positively wrong.
The dive computer uses algorithms to calculate the amount of nitrogen going into and out of the tissue compartments. Different pressures affect the rate you on and off gas. If you drop to 100 feet, you are absorbing gas quickly. If you then ascend to 80 feet, you will off-gas some of the absorbed nitrogen at one rate and yet still on-gas nitrogen at a different rate. Ascend again and the same thing occurs, off gas some of the previous nitrogen and still on gas nitrogen at another rate. This is called 'multi-level' diving. Tables assume you are at the deepest depth for the whole dive. If you were to do a square profile (descend, stay at one depth, and then do a straight ascent) then a dive computer has a lesser no-decompression limit than the table would. What you have confused is a dive computer that is air integrated. that may, as a feature, have a different display that calculates your given air consumption and figures out how long you may stay at depth before reaching a reserve point (generally 500 psi). That is simple algebra, but decompression algorithms are a lot more complicated.
I should know, I teach this several times a month as a current and experienced dive instructor (check my profile) and use this information weekly on my technical dives to wrecks where we (my dive group) consider anything above 200 feet to be shallow. I have been on most of the sites that the article mentioned in passing (Florida caves [look at my web site]), the Andrea Doria, U-boats, etc.
Dive computers may be used to help avoid decompression, but not for decompression diving. I generate my own tables for any technical dive. Most people commenting here so far seem just to be newbie divers themselves. It is like someone that just finished a VB class starts spouting off about C++.
Most divers don't know how to properly ascend and decompress as it is. for the laymen, think of it like a soda bottle that is slightly agitated with dissolved gases (CO2). You would slowly open the bottle until there is a slight release in pressure and then close it; allows gasses to equalize, and then open, stop, repeat. You are allowing the gas to escape slowly enough that bubbles do not form. In the case of diving and human bodies, it is to prevent nitrogen from forming bubbles. Most divers just do direct ascents too quickly or a quickly stop at 15 feet before hitting the surface. The best way to ascend is to do a full stop (assuming a deep dive) at 40 feet for 15-20 seconds, stop at 30 feet for 30-60 seconds, stop at 20 60 seconds, and a stop at 10 for 120-180 seconds. this allows the nitrogen time to slowly come out at a slow rate; i.e. like opening the coke bottle slowly so it doesn't spill over.
If you decompress properly, then flying isn't a big deal. The general problem with flying after diving is the reduced pressure. You are going at a reduced pressure (most commercial craft will pressurize to no more than 8000 feet) so the nitrogen currently in the body comes out more quickly.
Cave, wreck, and deep diver.
As long corporations can figure out when it's cheaper to just go-ahead and let a few people die, some will. There needs to be a 3 strikes your company is dissolved law.
No more company, all assets sold, stockholders get whats left over, after all debts payed (as usual). Corporate officers and board members prohibited from serving in either capacity in any corporation for a period of at least 2 years. Don't worry if they don't actually have enough cash to cover that, they can always get real jobs...
At one point in our history, it actually required an act of Congress to incorporate, it isn't a right its more like a drivers license, the only thing Congress would need to do is care.
At the bottom of their recall web page:
"We apologize for any inconvenience this may have caused you."
Now *that* is an understatement...
I routinely do dive profiles that my dive tables say I should get bent on. My computer knows better, because it knows the actual depth profile I dive, and not just the max depth and total dive time.
Almost any dive profile on a wall will do this. You start deep, and drift slowly more shallow as you go, and you can do a nice hour-long dive with a max depth of about 80ft, and an average noticably shallower than that.
Yes, you can do this with a multi-level dive table, with a wheel or similar. I've done that. You know how much trouble that is? And how difficult it is to know, for a sloping wall dive, exactly how long you'll spend at any particular depth looking at coral? Yes, plan your dive, and dive your plan. But realize that you aren't a robot, and don't dive like one.
Multilevel dive planning is for deco diving where your computer can't handle it, and, incidentally, you *have* to know deco times ahead of time so you can hang stage bottles at the right depth.
But that dive profile above, for a normal set of dive tables, diving with a computer, will almost always end with your tables telling you that you went into deco. Because all it uses is max depth and total bottom time.
Yeah, and the tables are approximations, too. Actually, they are statistical representations, and state that 98% of divers that stay within these guidelines will not get DCS, with some confidence bound. Yes, diving tables, you can still be that unlucky 2% that does everything right and gets bent anyway. Sometimes it's just not your day.
No. You do research, you find out what algorithm your computer uses, how conservative or liberal it is, how it was modified from standard industry-published algorithms, and you pick a computer that works the way you want it to. And then you dive within the bounds the computer sets, so long as those bounds pass your internal bullshit detector. (You *do* have an internal bullshit detector, right?) But diving close to those bounds is not "dumb" it is simply using your equipment to the limits you are comfortable with.
Can't disagree with that at all. Finishing a dive at 10pm and flying at 6:30am the next morning is not safe.
This is my sig. There are many like it but this one is... Oops. Frank, I've got your sig again! Where's mine?