|
|
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 |
|
|