Wreck diver killed by leaking computer - UK

[John the Pom]

Two is one and one is none. You need 3 and some sort of voting communication between them.. or is that also not a thing?

Indeed - early NASA space missions used three redundant computers with a voting system, for the same reason a CCR has three O2 sensors. Not infallible, but robust against failure of a single system, which is not a bad thing from a safety engineering perspective. However, it can lead to an insidious kind of failure where the user misunderstands the reason for triple redundancy and argues to themselves, "Well, one system is on the blink but no need to worry because there are two back-ups."

 

[doctormike]

Indeed - early NASA space missions used three redundant computers with a voting system, for the same reason a CCR has three O2 sensors. Not infallible, but robust against failure of a single system, which is not a bad thing from a safety engineering perspective. However, it can lead to an insidious kind of failure where the user misunderstands the reason for triple redundancy and argues to themselves, "Well, one system is on the blink but no need to worry because there are two back-ups."

I don’t understand how this applies to controllers.

I understand the concept of a backup controller if your primary fails. But with sensors, you have three that are each giving you their own measurement of loop PO2, and then you can apply voting logic. The operator can override that vote by doing a dil flush to see if two sensors have failed.

But how would that work with controllers, which simply take the voted on PO2 from the three sensors and decide whether or not to open the solenoid. And don’t you need a minimum of three for a vote?

 

[dmaziuk]

But how would that work with controllers, which simply take the voted on PO2 from the three sensors and decide whether or not to open the solenoid. And don’t you need a minimum of three for a vote?

They have to ping each other periodically: "heartbeat", and decide who controls the solenoid. A dead controller won't answer to pings and it'll all work -- except when the failure is in the heartbeat channel. In that case you have "split brain" where each controller thinks it's the only one left standing and they fight over the solenoid. So you add the "tie breaker" node (that doesn't necessarily need to control the solenoid) but of course it can fail too...

The easy way out is to have the human monitor their hud and take over if anything looks wrong.

 

[doctormike]

They have to ping each other periodically: "heartbeat", and decide who controls the solenoid. A dead controller won't answer to pings and it'll all work -- except when the failure is in the heartbeat channel. In that case you have "split brain" where each controller thinks it's the only one left standing and they fight over the solenoid. So you add the "tie breaker" node (that doesn't necessarily need to control the solenoid) but of course it can fail too...

The easy way out is to have the human monitor their hud and take over if anything looks wrong.

Your last sentence is exactly right.

I'm still a CCR newbie, but I haven't seen this sort of heartbeat setup implemented anywhere - multiple controllers automatically deciding which one works. If the failure that you are addressing is a dead controller, not sure why you would need something so complex. Controller 1 runs the solenoid unless there is no signal on its line, in which case Controller 2 takes over. Stuff like voting logic and tie breakers (a third controller?) is only an issue if you are worried about other failure modes, where controller 1 still is sending a signal but it's a wrong signal. Not sure if that's a real world issue, that seems to be more in the realm of sensor redundancy than controller redundancy.

There seem to be two schools of philosophy in rebreather design - the continual addition of smart electronics to address failure modes, and simpler, more robust designs. Every time there is a fatality, there is the urge to let the engineers figure it out and make a unit more foolproof by adding new systems. Or, you could know your PO2, and bail out if there is any question about the veracity of your sensor readings, as you suggested.

Normally I think that it's Ok to let these discussions range widely apart from the actual incident, but in this case I really want to know what happened, since I think that's very relevant to the question of whether a smarter rebreather would have saved this diver. One of the things that I love about my JJ is that for an eCCR, it's pretty simple.

It would be good if Shearwater could get a log of the OBOE PO2 recordings. If the diver was using a NERD, that would have been available, and we would know loop PO2 for the whole dive even with a dead controller (on the SOLO board). But I don't know of any OBOE logging in the head for the stock JJ with a standard HUD.

 

[JonG1]

MCCR vs ECCR is relevant, and the muscle memory response that MCCR promotes in relation to PPO2, it would seem in this isolated incident (notwithstanding the fact that we still don't actually know the proximate cause).

I also suggested on the UK thread that maybe tethering at deco might also be a considered SOP along with a gag strap, so that at least in a circumstance such as this the airway remains protected and the individual concerned doesn't simply sink into the abyss in a loss of consciousness situation.

This may be more relevant on a station where you could be last diver out, but boat is monitoring, or even when others are in the water but due to zen or narrowed field of vision a diver could slip away unnoticed before a reaction can be stimulated from others.

 

[rjack321]

Normally I think that it's Ok to let these discussions range widely apart from the actual incident, but in this case I really want to know what happened, since I think that's very relevant to the question of whether a smarter rebreather would have saved this diver. One of the things that I love about my JJ is that for an eCCR, it's pretty simple.

If he had been diving a Poseidon I am pretty sure it would have forced him to bail. Maybe a Poseidon diver can confirm what would happen if the handset just flooded and quit working.

 

[dmaziuk]

There seem to be two schools of philosophy in rebreather design - the continual addition of smart electronics to address failure modes, and simpler, more robust designs.

You start with cost-benefit analysis and design back from there. Unfortunately as soon as someone throws "life saving equipment" in there, the analysis goes out of the window.

 

[doctormike]

If he had been diving a Poseidon I am pretty sure it would have forced him to bail. Maybe a Poseidon diver can confirm what would happen if the handset just flooded and quit working.

How does it do that? If you don't have a backup PO2 monitor like a HUD or a NERD or a second handset display, that would force a bailout (again, forgetting about SCR). Is that what you mean?

 

[Dusty123]

Apparently has a solenoid on diluent and literally starts puking gas at you. If I remrmber correctly there is a built in hud in the dsv and has magnet switches for position of the bov.

 

[rjack321]

Apparently has a solenoid on diluent and literally starts puking gas at you. If I remrmber correctly there is a built in hud in the dsv and has magnet switches for position of the bov.

yea it sort of self bails with diluent flushes. Not sure what happens when the dil runs out.
But I'm pretty sure there is no way to operate the VII manually. I dont think it even has a manual add valve for O2?
That's what I was thinking about it forcing you to bail. It's either working perfectly or doesnt work at all and you have to bail.