Received-SPF: softfail
 receiver=logan.com; client-ip=64.102.122.149; envelope-from=echristley@nc.rr.com
Message-ID: <42A5B35D.90501@nc.rr.com>
Date: Tue, 07 Jun 2005 10:46:53 -0400
From: Ernest Christley <echristley@nc.rr.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
MIME-Version: 1.0
To: Rotary motors in aircraft <flyrotary@lancaironline.net>
Subject: Re: [FlyRotary] Re: rotary risks. MTBE and the gospel ...
References: <list-986793@logan.com>
In-Reply-To: <list-986793@logan.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

al p wick wrote:

>There are three components that define RISK. Most of your comments
>address only 1 of those, the failure rate. Yes, it's a little tough to
>nail the fail rate on the rotary engine. The other two components have
>equal weight. What EFFECT the failed component will have on flight. How
>likely to notice the defect before flight. It's not too difficult to
>assess those two components accurately. So if we have the discipline to
>use these methods, we've got most of the risk equation nailed. Therefore,
>we don't have to be precise in defining the fail rate. We just have to do
>our best to be moderately objective.
>
>  
>
Al,
I think your method is great.  In fact, I started working up the 
resources that would be necessary to add a web application to my website 
that would automate the method.  I need to demostrate some proficiency 
in tying PHP to a Postgres database backend if I want to stay employed, 
so I figured this would be a perfect testbed. The problem is, the more I 
listen, the less I understand. 

You first say that everything is irrelevant until you peg down the 
possibility of a failure.  Sure, you say, a piston engine is more 
complicated, but that doesn't matter because failures just don't happen 
in all that complication.  And then you go on to say that the rotary 
installation is extremely dangerous because of a single point failure 
possibility with the CAS.  You counter the argument that "failures just 
don't happen there" with, "Yeah, but it could be so much more robust 
with just a few more pieces."  We've now lowered an all but zero chance 
occurance to a lower value of zero chance occurance, but we've had to 
add more connections and more software to handle multiple inputs.  
Basically, a lot of unecessary complication to handle a non-existant 
problem.

You claim that complexity doesn't determine the failure exposure of a 
system.  I've tried to come to terms with that.  I've worked to see 
around it.  I've tried to see how it can be true.  All I can do at this 
point is call bullshit.  Increasing parts count increases system 
interactions, increasing possible failure points, DECREASING 
reliability.  In a mechanical system, each moving part provides for an 
additional wear point, with it's own sets of tolerances that must be 
measured and maintained properly.  Anywhere the word 'properly' pops up, 
you've DECREASED reliability.  A complex system can have many advantages 
of a simplified one, but I can not see how reliability can ever be 
amoung them if they are both properly designed and built to equal 
tolerances. 

So we add the complexity of an additional CAS.  The failure probability 
was 1/1,000 with one, but it is now 1/1,000,000.  But we've had to add 
software that correlates the two.  Everyone likes to expound on the 
glorious reliability of the digital age, but being a Software Engineer 
working in the QA field, I can authoritatively say that very few people 
understand the subtle errors hiding in the edge cases of a piece of 
software.  The problem with software is you can't see it, and you'll 
never know the edge case exists until you hit it.  Then there are more 
wires, more connections, and more 'stuff' in the engine compartment that 
has the possibility of interfering with other 'stuff' in the engine 
compartment.  We don't know what the original failure probability was, 
but we know that it was very small.  I would submit that with all the 
added complexity that the failure of a CAS failure has been reduced, but 
the system reliability has increased but STILL completely unknown.

Reliability is getting thrown around a lot, but I don't think is 
sufficiently describes what we're after.  What we're after is 
'demonstrable reliability'.  How do you demonstrate a system's 
reliability? 

You can do it with statistics.  That's easy enough for a car 
manufacturer.  They get patents on all the minor modifications to parts 
so that you have to go back to them for replacements.  Just track how 
many cars you sold and how many CAS you had to replace.  Simple enough.  
But that doesn't help us much.  Statistics from one sample are called 
anecdotes.  But unfortunately with a prototype, which is what we have, 
all you've got is one.

The only other way of demonstrating reliability is with physics and 
modeling the system.  You can't model a system you don't at least 
partially understand, and here again complexity is the enemy here.  
Increasing possible interactions increases the possibility of one 
ruining your day.  We can run the engine on the ground, taking careful 
measurements, which will give us an indication of how reliable the sytem 
will be in the air.  But the more stuff you have to consider, the more 
likely something important will be overlooked in preference to a system 
that is actually more reliable than the wing spar to begin with. 

Education (what we're been doing here for a long time) is the only way 
we can better model our systems on the ground.  The FMEA method adds 
almost nothing because there is a big box at the very start of the 
process labelled 'magic happens here'. 

If you're willing, I look forward to being corrected.

-- 
         ,|"|"|,                                    |
----===<{{(oQo)}}>===----        Dyke Delta         |
        o|  d  |o          www.ernest.isa-geek.org  |