Any comments on this?

AD_ward9

EN 14143:2003 Page 7 requires EN 61508, Part 0 and 1 of which require 1 billion hours.
The safety case for a safety critical product includes preventative maintenance. The MTBCF figures quoted assume all preventative maintenance is followed as per the manufacturer's recommendations.
It depends on the mod. For example, I have posted pictures of an Inspo I modified, to deal with several failure points. The modified unit has a much better MTBCF than the unmodified unit. Take another example, where someone replaced the filter material of the Inspo with foam, that causes a big increase in the work of breathing and almost instant failure! There are lots of other examples: using the Micropore scrubbers instead of lime (a good idea, if you also add a water flushing pump), etc. Given the effort going into a good design, buying a rebreather and modifying it should be done with the utmost care and only after proper safety assessment, including contact with the manufacturer.

Cheers,

Alex

jradomski

Andy,
With the proper analysis and precautions a "complex" controller could still be realized, but this requires alot of foresight trying to anticipate all types of failures..

On any Critical application I work on, I keep the potentially dangerous routines seperated from the most commonly used ones.. All unused spaces must perform jumps to some type of error test and recovery and usually have to be added manually.. Checksums on the code is an absolute must, this would immediately recognize any problems with the code and take appropriate actions.. On critical applications, I have periodic code integrity checks, as well as data integrity checks, these additional precautions frequently take longer to implement that most of the base application itself!

I find with dealing with alot of programmers is that many of them ONLY work in high level languages like C (which is really necessary over assembly for thinks like deco programs), and since they don't program in assembly language they dont know how to analyze the generated assembly code for potential "gotchas".. Up until recentlyly I only programmed in assembly when doing embedded work because I wanted full contol, I have switched to C for alot of the work, but still carefully analyze the generated code.. Alot of times the C code can be perfect but the generated code has errors from the compiller..


Brown out, and clock fault detectors are a must in my book.. Unfortunately most micros clock fault detection is NOT part of the micro's design and reliable and simple implementaion is hard to add in afterwards (and still have the code executing instead of a simple reset), voltage fault detection IS pretty easy..

__________________
Joe Radomski
CCR Trimix Instructor Trainer
ANDI Instructor Trainer Director #10

All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated.

AD_ward9

The particular manufacturer involved reportedly indicated in answers to a Coroner, that they had sold more than 1500 CCRs of that "early" model. The number is surprising, but is in line with statements they subsequently made to some component suppliers.

Today the document "How rebreathers kill people" was updated: the number of CCR failure modes causing serious incidents has increased to 20, and we still have not completed the Accident Study. The link is:http://www.deeplife.co.uk/or.php. We would be grateful for any advice on any mode we have missed.

If I can explain about the Accident Study: amongst the other documents required for a safety case, our QA procedure for designing safety critical systems requires an Accident and Incident Study to check the HAZOP conclusions.

For a CCR an accident study is a lot of work because there have been so many accidents. The report must compile all the sources of information on all the fatal and serious accidents and incidents on rebreathers (with a lot of interviews, requests for coroners reports), review these by a technical team and reach a conclusion of the cause for each case - which in some instances does differ from the Coroner as Coroners have not been aware of some failure modes. The whole report will be published. We are considering doing this in HTML format, so a reader can follow the links to the reports etc. We hope this is useful in looking at the HAZOP and FMECA conclusions.

Cheers,
Alex

silent running

Hi Joe, thanks for the explanation of the differing applications of higher and lower level computer codes, interesting. And while I don't doubt that it's possible to make a full function deco and SP controller that works perfectly, it seems to be a bit hard to come by right now, probably because it's not going to make anybody rich in the near future. I wish there were more potential CCR customers, we'd get better products and there would be less to worry about...
But for now, given that most of the better units are designed by overworked geniuses, I'll stick with the simplest ECCR and spread my risk around btw the overworked genius CCR designers and the overworked genius deco computer designers/deco theorists. -Andy

silent running

Hi Alex, thanks for all the details and comparisons. I very much respect that you seem less concerned with just meeting the paper standards out there and more concerned with producing a truly safe CCR. And I hope for my own selfish reasons that your backers are right about those waiting in the wings for a safer product.

But I really wonder whether there will ever be that many who will want to put their bodies under 1000's of kgs of pressure and risk getting bent travelling to an environment which is 2nd only in it's hostility to space. Most of my non-diving friends think I'm nuts.
Even if you are able to produce a highly fault tolerant CCR, what about the lack of knowledge/safety in decompression theory and deco diving in general? And no matter how safe the unit may be, the user must still have a firm grasp on what forces are at work-their physiology, their equipment. No matter how failsafe the system, they will after all still be "flying" the unit solo. There will be no highly trained ex-Air Force pilot escorting them on their trip to inner space... -Andy

AD_ward9

You touch on a most fascinating topic - the deco risks. For design, all we can do is verify that we have implemented XYZ algorithm correctly. The user picks the algorithm, and takes the risk associated with it. Looking under the covers though, reveals an amazing mass of worms of two breeds:
a. The accuracy or otherwise of the deco algorithm a dive computer states that it implements
b. The deco algorithm risks themselves

There is a nice book called "The Bends" that gives the history of the development of deco algorithms. This shows the staggering risks people took to build caissons and for dives until the 1980s. Á very humbling read. Recommended to everyone: From UKP11 on Amazon.

The Bends: Compressed Air in the History of Science, Diving and Engineering (Hardcover)
by John L. Phillips
Hardcover: 262 pages
Publisher: Yale University Press (25 Jun 1998)
ISBN: 0300071256

On the other side of the coin, is the low level of DCI indicidents sports divers have. We can all debate this, but the fact is, there are around 8 million sports divers in the world, and couple of thousand people who use rebreathers. The sports divers have far fewer DCI incidents than the stats would predict.
Given that use of SMBs to control ascent rates is not usually taught by the biggest agency (PADI), this is quite an achievement.

My own theory is that loads of sports divers get the bends: it is the tiredness they feel after a dive, and after years of diving, they have brain and spinal lesions. Most sports dives only stress the compartments with very short half lives because sports dives are so quick.
Tech divers get dead bits of bone. They But the fact they all walk around and enjoy life, is a testimony to how some quite hairy science can get turned into something very useable.

Cheers

Alex

jhaaja

About case 19 I can not see that the CNS calculations were wrong. If the current half time of 180mins is not working then there could be error.

I am not at all sure anymore that that 180mins works all the time. I think it might have same kind of variance as CNS tolerance in general.

JH

dan@scuba-training.net

1. Every computer program can be made more efficient by reducing the amount of code by at least one line.

2. Every computer program has at least one line of code that doesn't work properly.

Conclusion:
Every computer program could be shortened down to one line of code...
...that doesn't work.

silent running

Hi Alex, thanks for the book recomendation. I'll get it. I got some backgound on the evolution of deco theory during my CCR tmix course. It's amazing how many people died or were injured testing out theories long ago, some of which appear to have been valid, but were poorly implemented. And some of these casualties were just plain unlucky. Many of these experiments were based merely on theories and supplemented by a few empirical observations of DCS symptoms...Yikes!
Even with most current deco models, it's still heavy doses of theory and thankfully much more observation. But it's always a big reach into areas that cannot be simulated effectively, even with the vast computing power of Los Alamos lab.

But I guess at the end of the day, empirical observation is still the most reliable validation. So for now, I'll have to go with whichever theory makes the most sense to me, implement it conservatively, and hope for the best. -Andy

AD_ward9

See the thread on the Open Revolution Forum on CCR calculations.

The problem is 100% CNS will cause O2 tox symptoms in 4% of divers. So, the trick is to work out what the statistical spread is, then stay far enough away to have a 1 in a billion chance of O2 tox affecting you. We propose an algorithm for that, which comes down to adding 0.2 or 0.3 to your PPO2 values when calculating CNS.

Cheers,

Alex