Jay Jeffires recently provided us with a listing of causal factors in military submarine accidents, since accidents yeild a treasure trove of safety data. He then lamented that the psubs community does not have access to that sort of data relative to submersible accidents. He was not lamenting the dearth of accidents, of course, only the dearth of data. He contrasted that to the aviation community, which collects and reports detailed data on all aviation accidentss.
For those of you who do not to read this entire post, I will cut to the chase. While the general aviation community continues to benefit from substantial accident investigation information, the air carrier community no longer has enough accidents to provide much useful safety information. The community has shifted it's focus from examining accident data to (1)focusing on the precursors to accidents, and (2) shifting from outcome measures to process measures. The psubs community can take the same approach, so the lack accident investigation data is not really a concern. I then go on to discuss the application of each of these approaches to psubs. The end.
Jay's analogy holds up well for one segment of the aviation community: General Aviation (GA). This is private pilots flying private planes. We continue to experience about 350 fatal accidents per year (and many more non-fatal ones). The FAA investigates every one, with the NTSB investigating a subset of high profile GA accidents. We have, unfortunately, plenty of accident data available.
The same is not true for the Air Carrier community. Back in the 1950's that community had close to an accident a week, so we had plenty of accident data to mine. But those days are long gone. Today we have one or often zero accidents each year. So the community has had to look elsewhere to find useful safety data and measures.
US air carrier accidents are so rare today that they are sometimes referred to as "designer accidents"...so one-of-a-kind that investigating them does not tell you much that you do not already know. The professional submersibles industry probably falls into this same category. Safety professionals refer to communities like commercial aviation, petrochemical and nuclear power as "high hazard-low risk". There are plenty of dangers out there, but the safety systems are so over-engineered with redundancy and the safety culture of the employees is so strong, that bad things almost never happen.
So how has the community (meaning the air carriers and the FAA) responded to the shrinking pool of accident data? The response has been two fold. First, collect different data. Second, shift from outcome goals to process goals. Because the psubs community is in the same boat, lacking accident data, we may want to follow the lead of this community.
First, the collect different data approach. Every safety community has its own accident ratios. For air carriers, the numbers are 1:15:300:15,000. This means that for every major accident there are 15 minor accidents, 300 incidents and 15,000 observed work errors. As accident data has dried up, the focus has shifted to collecting data on the right side of the ratio. These are accident precusors, rather than accidents themselves. These are the failures of people, equipment and processes which, left uncorrected, can result in an accident.
In highly engineered safety systems, accidents rarely result from a single failure. These systems are failure tolerant, with their multiple redundancies. It requires a chain of unfortunate events, usually called an "error chain" to cause an accident. In commercial aviation most accidents have 6-8 links in their error chain, while manufacturing accidents often have twice that many. We teach our pilots how to "break the error chain" before it leads to an accident. It is these "errors and failures caught" that are the percusor data we now collect and examine. The data consists of the links in the chain.
What could the psubs community do? We could establish an area on the website for lessons learned, common mistakes, safety observations. We can post the safety issues we have experienced or read about as we design, fabricate, test, operate and maintain our psubs. For example, I made a few significant mistakes when I built the Undaunted. I could post them. The Needlefish is good recent example. A number of members of our community commented on the failure of the builder to use common best practices in many areas, yet we never made a list. These are safety opportunities lost. In the absence of accident data, we can collect data on accident precursors.
That was the first approach "collect different data". The second approach is to shift from outcome measures to process measures. Instead of relying exculsively on the outcome (accident yes or accident no), measure the extent to which a psubber followed best safety practices, regardless of the outcome.
If I may re-use an analogy I used at the last psubs convention. My goal it to avoid the outcome lung cancer. I cannot prevent lung cancer (or an accident, such are the laws of random numbers). But I can control the risks. That I can control. If I (1) avoid smoking, (2) avoid second-hand smoke, (3) eat 3 vegetable servings a day, and (4) take vitamins A and C, I have done all I can. Now my neighbor may smoke like a chimney and live to be 100, while I die of lung cancer at an early age. Who is safer? Based on outcomes, my neighbor was safer. He lived and I died. Based on procss, I was safer. I did all I could to avoid lung cancer, but I was unlucky. He did nothing, but he was lucky.
On any given day the safest air carrier in the US is about as likely to have an accident as the least safe carrier, because the odds of an accident are so very low. But over days and weeks and months and years, the safer carrier will have less chance than the unsafe carrier. Following the rules pays off over significant time horizons. This is measuring safety according to safe processes, rather than simply safe outcomes.
How would this work for the psubs community? We would estabish a set of best safety practices for designing, fabricating, testing, operating and maintaining psubs. Hugo has made the argument more than once that the psubs community should develop such standards. I agree with him, in everything but timing. He seems to be ready to go right now. I don't think this community is mature enough to take this on for many, many years. We have to crawl before we walk, and walk before we run. We are, or have been to date, a good discussion group. Not a good work group. Our individuals have done great work, but various ad-hoc groups that have formed over the years have not, it appears to me, generated many final products.
My advice, instead, is to hew as closely to the commercial standards as each of us is able. Hew to such standards as ABS, PVHO and USCG. The main reason I do not follow Hugo's lead is not simply my assessment that this group is not yet up to the task, but that the data on which to base such guidance is not available. In what areas will we compromise the ABS standards? How far will that compromise go? On what basis of factual data do we make those decisions? Hugo is a professional submersible pilot. How many members of our community have those sorts of credentials? Until this community starts to document the very sort of data I have addressed in this long-winded riff, I don't think we will have the data we need to develop our own standards. Do you agree, or am I selling this community way too short?
Perhaps my perceptions are clouded by my own experience. I have participated in standards development committees many times at the FAA. I am on one right now, that involves dozens of people and will take many months to complete. Building standards is a big, big deal. Are we up for that?
Now we do have a lot of folks I view as stars. Phil, of course, our alpha male. But we also have, in my opinion, Carsten and Alec and Dan L. and Cliff and others. But these guys, it appears to me, all hew to ABS standards. Are there any heavy hitters other than Hugo who think we can do this now? I am very curious. Again, I don't mean to sell the group short.
Now, don't get me wrong. If we form a committee to developm psubs standard, I will volunteer to assist. Just because I don't think we are ready does not mean I am unwilling to test that hypothesis and prove myself right or wrong. This is all conjecture and opinion.
Sorry to be so wordy...it is my nature. I am not an engineer and can rarely make a contribution on design issues. But I do know a little bit about safety, so I wanted to jump in.
Thanks,
Doug Farrow
SeaLordOne