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