AD_ward9

Because there are a number of separate but interconnected issues and we are not being clear enough with each other in separating them. In fact, they are not separable, as a CCR is so tight a system, a decision on one matter when considered from many different angles, usually affects other parts of the system. If I break your post up into neuron sized elements, perhaps we can overcome this communications barrier (at least it will make it easier to point out where my neurons may be miswired):
I take a different view. That is, ensure the design does not allow one failure to spread to other sections.

For example, water in the handset should not affect the base. It should continue functioning completely normally.
Sensors are not the whole story, but an important element (and the theme of this thread).
The only things we keep at 1 ATM are batteries and the rear face of pressure sensors: we keep both of them outside the rebreather in thick stainless steel tubes. They can fail in any way they like, they are not going to affect any other electronics, other than reducing battery life. We are opposed to hard encapuslation (it causes failures).

It is this approach that gives us fundamental differences in the way we look at a problem. It affects trivial things like how to route the O2 sensors, how much ESD protection to provide, what failure modes to cover (i.e. all). We would both agree there is a lot of nonsense posted about the cost of these things: most cost very little - a resistor here, a buried track somewhere else. Added up, it is not a lot but together they implement a certain philosophy or method in approaching the design.
A good case in point. We do not connect multiple devices to one sensor, except through high valued resistors. This prevents one failure in one set of electronics from affecting anything else.
I believe we meet the latter condition, and the latter condition is the correct design objective for safety critical systems. At the sensor end, we prevent the situation where any rail can ever be across any of them, by taking proper ESD precautions, protecting the sensor from the electronics using a series resistor, and the electronics from a new sensor plugged in with an open load using the same resistor/diodes, burying the track and guarding it with ground so a conductive electrolyte (e.g. water from a flooded scrubber, or sea water), cannot put a potential onto the sensor wires. Safe design means the design should be resiliant, not just tell you that it has failed. When underwater you may not have another bail out option left: you want the rebreather to just work - tell you to bail out by all means, but keep you alive until you can.
Please tell me the situation where it is not true for the system I just described, and we have published right down to circuit level. We try to design such that the assertion you are making is not true.
A deduction based on a false assumption.
You do not have to know why a failure has occured, or what failure, at all. One just needs containment of the failure and enough true redundancy so that when the failure happens, the system can operate as normal. For example, our using two batteries on the base and one in the handset, all packaged separately, and wired such that any one battery can power the whole system, and we monitor power supplies and shut them down when a failure occurs: all this is published in circuit diagrams and circuit review in our Open Revolution submission.
On the surface during pre-dive checks, I could not agree with you more. But underwater, I disagree. In a recent fatal accident review we did, the fatality occurred because the software would not let the unit perform its life critical function when it was powered up underwater with a fault condition present.
100% right, which is why this debate is worthwhile. It is also part of the concept behind the Open Revolution initiative: that each company, not just Deep Life, publish sufficient data to prove the safety of their products, that way the whole community designing rebreather controls can adopt the best practices and best design philosophies. I saw another post that made the good point that a rebreather controller should either demand everything from the user, or nothing. Where do you stand on this?

Cheers,

Alex