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
For this specific problem, it was more that they modified an existing product to get it to market (in order to sell the company).
Your nitrogen uptake in diving is a function of the nitrogen partial pressure (79% in air, 60-75% with oxygen enriched air (nitrox). Making a computer calculate based on nitrox rather than air should be as simple as changing the O2 percentage. The problem is that at the surface, this computer still assumed you were still breathing O2 enriched air.
Good diving practices dictate a minimum 1-hour surface interval, and 24-hours before flying when using nitrox. Professional divers often push these limits, especially at the end of a trip when it is most dangerous.
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.
Don't forget about these little modules, that *most* of us in society today bet our safety on, putting our very lives in the hands of the developers. So many people just dont even realize they are there, or what they are doing.. zero clue..
Even if you drive an old vehicle that doesn't have these things, the guy next to you, or behind, in that huge SUV you probably does.
Airplanes too, its bad for one to fall out of the sky due to bad code...
---- Booth was a patriot ----
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.
That's the irony. Good management practices, including systematic diligence about assumptions, would have avoided this defect. The fact that the grandparent poster essentially thought "it compiles, it runs without crashing, and it's efficient" would mean that it worked and was ready to ship is the problem itself.
I imagine they teach all CS undergraduates about the THERAC-25, and how simple safety measures like hardware interlocks are much, much more reliable than software...
In this case, couldn't you check dive times against a book or something to make sure you're not completely off the mark?... what about something to measure nitrogen levels? Anything so you're not relying purely on software... (or, as someone has already suggested, you could use two completely different pieces of software).
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?
They also by their own admitance did their deeper dive later. This also is quite contrary to all of the PADI stuff that I have been taught.
For anyone who doesn't know-- taking the deeper dive second tends to help you get the bends faster (it is similar to the reasons you always start off the night drinking the drink with the highest alcohol content).
There is also some recommendation about not doing more than 3 dives in one day without at least a 1 hour surface interval.
I have been using a Suuanto Stinger for about a year (this is the same one that the British Navy divers use). It has never let me down. But, I also never push it to the limits, nor have I ever done more than three dives in one 24-hour period.
-CPM
---You're all I need, When the water runs deep, You're all I need, Now I cry my soul to sleep -- Collective Soul, Needs
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.
If you're interested in the hazards of software in the real world check out the risks forum.
They take submissions from people about faults and errors in software (and related meatware) that put lives at risk.A weekly digest can be found here.
It's a good read, especially browsing through the archives. eg:
"A woman drowned during a flood when the elevator she was riding in incorrectly sensed a fire alarm and went to the ground floor which was underwater."
"Three people killed when a computer glitch caused a 16-inch pipeline to rupture, dumping 237,000 gallons of petrol."
and so on. Makes you a little paranoid. Now I know why indemnity insurance is so high these days.
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.
where the diver gets a blue screen on one of those :-p
The war with islam is a war on the beast
The war on terror is a war for peace
BTW, moderators who modded down the original post, doesn't this qualify as "When Bad Software Kills"?
Even if they were pros, the injured divers made a rookie mistake.
Diving is really, really wonderful and very safe if you follow proper security measures. But like in many other activities there are always some risks involved, and it is YOUR responsabiliy to do all you can to minimize this risks.
You never trust your computer alone, you always doble check with the tables, and you memorize the tables, just in case. Ok, calculations with Nitrox are more difficult than with air, but anyway after a while you should develop some mental aproximations to right values based on experience.
I mean, I would never accept a "5 hours to fly safely" time, after 3 dives in a row (RTFA). No matter what computer says it, I'll relax in the sun for at least 12 hours before even getting close to an airport.
On the other hand, Uwatec executives should be impaled on air tanks, and dragged to Bonaire, Cozumel, or any other location full of divers year round, where we can take turns torturing them for years before killing them and feeding their corpses to the sharks.
There were just less than 400 defective computers, this could have been solved quite easily.
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.
Companies are out to make money.
Take the expected number of products that customers have that will fail and harm/kill someone, then multiply that by the average settlement. You end up with what your company can expect to pay from all the court cases from people dying with whatever product a company sells.
If this is cheaper than doing a recall, the company won't do a recall. Even when the company knows people will die from their shitty products
That's what Fight Club says, though I think most companies these days will do a recall anyway, in an effort to avoid bad PR as well.
Ford/Firestone didn't do too well by not doing a recall for a long time. Yeah, they might have expected to lose less money by not doing a recall, but the massive amout of bad PR that came around (people started noticing they were more likely to die on the things) ended up doing a lot worse damage to the bottom line than a recall.
I would love to find some attribution to this, I believe I remember reading it in Computerworld in the mid-'80s:
A manufacturer of particle accelerators for treating cancers had a unit, that due to a software bug, would occasionally blow a fuse. It wasn't considered important enough to track down, since you could just reset the machine, and it'd be fine.
Until they upgraded the equipment for a higher power unit, with the same software. The radiation dose killed a patient.
This came up originally under the subject of software malpractice.
Design for Use, not Construction!
Anybody remember ther Therac 25? It was a medical radiation machine, and killed a handful of people, due to a firmware bug...
Therac 25 Investigation
ToaterBoy
An OPEN mind is a beautiful thing...
do a google search for it......Lots of information out about it
_ 25/The rac_1.html
heres one link i found super fast
http://courses.cs.vt.edu/~cs3604/lib/Therac
Lawyers, MBA's, RIAA? A jedi fears not these things!
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.
All that mathematical methods allow you to do is prove that code satisfies a specification. Unfortunately, in most application domains, generating a rigorous specification is not significantly easier or less error-prone than just writing code.
I think it's very sad when CS people fail to notice this obvious fact.
Also as a certified diver (1994) I know that tissue nitrogen saturation is highly dependent on the individual and a multitude of complex factors. There are tables for very general estimations, which have to be very conservative to be useful at all to a diverse group of individuals diving in a variety of circumstances.
Dive computers allow the use of less conservative "tables" by applying the algorithms to sensor data. By applying actual depth/time/gas data to the algorithmic tables a diver can dive more agressive profiles, and also have the convenience of having the calculations automated in real time.
The 'no flying within 12 hours' and similar rules are simple conservative safeguards, and don't assume much at all about dive profiles. Also, it's not just a rule against flying, driving home via a route that elevates you a few thousand feet above your dive elevation can result in the same effects. (I live and dive at sea level, but I can't drive more than a few miles in any direction without significantly increasing my elevation.)
The alleged problem with the computer in question (if I understood the story correctly) is that the program assumed the diver continued breathing nitrox while surfaced between dives. That's a considerable problem, since it provides incorrect data. Even worse, it's an anti-conservative error.
Nitrox diving is an inherently more agressive attempt to increase dive profile limits. I am not personally a nitrox diver, but I understand the principles. I certainly don't want my computer to base it's calculations on an air mixture I'm not breathing between dives.
There is no rational excuse for knowingly allowing such an error to go unreported or fixed.
Narcosis has nothing to do with dive tables... only with depth. The rough figure is 30 meters... I think narcosis at 20 meters is rare if not impossible. All you have to do if you experience narcosis is ascend to a depth where you realize that fish can breathe water, and you can't.
When you learn to dive, you usualy do a deep dive to a) show you what depth you start to experience narcosis and b) learn what it feels like, so you can recognize it when you are diving.
It's the first paragraph!!! THE FIRST PARAGRAPH!!!!
BMW has told CNETAsia that an electronic fault caused the problem, rather than a system crash of the car's Windows-based central computer, as other reports have speculated.
THE FIRST FUCKING PARAGRAPH!!!
It sounds to me like the market for these computers was agressive divers...people who were trying to push the limits of safe dive times. That means the company should have been even more vigilant of there calcuation methodology, especially considering the price those computers went for.
And as far as fly time, NAUI recommends 24 hours wait time after a dive before flying...extremely conservative, but one again I prefer to be safe (especially since it's a hobby!).
"We make our world significant by the courage of our questions and by the depth of our answers." Carl Sagan
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.
I have two friends who have had laser eye surgery, one, very succesfully so far, the other somewhat less so.
Things they don't tell you
1) Your eye is stll going to change shape with age, so your prescription will change, so you will have to have it redone in 5 years or so (less if you want to keep driving without glasses)
2) If you indulge in any activities involving pressure (eg scuba diving) or lack of (eg mountaineering) then there is a risk that your eye will deform and render you temporarily unfocussed until normal pressure is restored.
3) the scars cause massive internal reflections and this will affect your night vision when driving.
4) you may need to have tune-ups. two in one friend's case.
5) Cross infection risks means that it is wiser to have each eye done at different times.
I'm not a big fan.
or as we call them ABS.
These are software driven just like vehicle stability systems (in fact VSS is just ABS hardware with a few more sensors).
We don't seem to have a plague of rogue software killing occupants because, guess what, we really try to be careful with this stuff. The FMEA for ABS software is huge, and detailed. How many of you guys ever have to do an FMEA? or even know what one is?
Here's a funny war story (I know everyone involved, this happened).
The wheel speed is picked up via a sensor on a 40 tooth tone wheel. Cars without ABS don't have tone wheels. Someone asked, what will happen if a non-ABS wheel gets onto an ABS car?
Mechanic fits non-ABS wheel to car. Development engineer drives off, hits brakes at 10 kph, no prob.
same at 20, same at 30
same at 40
same at 50
same at 70
Drives up to 80 kph hits the brakes, one wheel locks, the car slews sideways into a bank and rolls up on two wheels.
Engineer needs new undies.
What had happened was that the sensor could pick up the back of the wheelstuds. There are 5. The software assumed that the car was travelling at the speed of the slowest wheel, so the non-ABS wheel was the vehicle speed. Our ABS is disabled below 9 kph to ensure that you can stop the car, on some surfaces it will only inch to a halt unless you lock the wheels.
So, at 80 kph the ABS realised it was supposed to work, activated, saw one wheel almost stopped, released the brakes on that wheel, and locked the other one. Hilarity ensued.
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?
On the other hand, one does tend to take for granted, for example, supervised or standardized testing procedures / quality control to be in place regarding such products as airbags in cars, and as was mentioned in earlier posts, medicinal equipment. And a lot of this goes for guns, too, though i don't mean to start an NRA/regulation flamewar here.
Manufacturers of gear in the more critical fields are definitely aware that consumers expect them to adopt adequate safety measures. Does this make the cover-up worse? In principle, I'd say yes. But legally, I dunno (IANAFL) ... Of course, once you plunge in, that's your own decision. And my diving instructor did in fact tell us, even with all these fancy computers around these days, know your dive tables and multilevel wheel. Plan the dive and dive the plan.
But one does wonder, who should start initiatives to protect such specific consumers? Organisations of peers (PADI, in this case)? Government? Or is it, in the end, as simple as: every man for himself? Seems to me that these scattered, fragmented suits that the article mentions, are bound to be less effective than a collective effort could be.