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/
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 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.
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.
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.
Being comfortable and being dumb are two very different things. Pushing the absolute limit set by your dive computer IS DUMB, and if you are comforatable with that then it is VERY dumb. You give the reasons not to push the limits yourself. 1)Every person is different, 2)the dive tables that the PC programming is based upon is an approximation, 3)as is the programming itself.
You have a pretty fine-tuned bullshit detector if you can tell the difference safe and not safe when pushing the limits of a dive computer. One problem with this particular computer was that it gave the right results MOST of the time, but in certain situations it gave very wrong results (short, frequent dives). No one's bullshit meter would have detected the problem with these dive computers that gave reasonable results 99% of the time and then totally screwed you the other 1%. Neither is there any way you could have "researched" the algorithms in this particular computer to determine its accuracy because the error came from a hidden programmning error. So I think we return to the original idea - pushing the limits of any dive computer is very dumb.
The bigger issue here for /.ers is that because of its digital readout too much importance was probably given to the dive computer's implied precision. I'm sure it said it something like it was safe to fly after 6 hours and 18 minutes. Digital readouts imply greater accuracy than is often actually present, whether it is regarding a safe number of minutes to fly displayed on a dive computer or milliseconds until your cake is ready on the microwave. Placing one's life on th eline using this implied but non-existent accuracy is very dumb. All that apparent accuracy is totally useless given your original parameters were wild-ass guesses and approximations to begin with.