It is hard to fly without a little trust. Call it faith if you will, but we fundamentally can’t leave the ground without some sort of belief that the equipment we depend on to get us back down is somehow going to work. We don’t really care how that safe return to the surface of the planet is accomplished, but we want to make sure that it occurs. What we want is called “functional reliability”—the assurance that a required “function” can and will be performed.
Making sure that a machine or a mechanical system can fulfill a particular function can be accomplished a number of different ways. What I want to talk about is the concept of redundancy versus that of reliability. Both are means to an end—the way to ensure that a function occurs. Simply put, if you build reliability into a system or component, you are sure that it is going to work, all by itself, whenever it is needed, and won’t fail—at least to some magical statistical probability that you can accept.
Reliability is a lofty goal that takes time, money and testing to ensure you have met the requirements. Redundancy, on the other hand, supplies numerous methods of providing the required function: several of the same thing or multiple different ways of assuring that the function will occur. A good example might be the means of lowering the landing gear. The primary system is usually backed up with a secondary method to make sure that you won’t scrape that belly paint if the primary system fails.
While reliability is a wonderful way to build simple, light aircraft (redundancy almost always comes with a weight penalty), it is often very hard to achieve. Even when it is achieved, it must be maintained via exceptional quality control, preventive maintenance and periodic testing to make sure that the functionality is still there. Configuration control is very important in the world of reliability—once you have determined that a component is reliable, you need to make sure that every subsequent copy of the component meets the same standards as the original if you want to be able to trust it. Changes are the enemy. Build them the same or it’s back to the drawing board—or the statistical testing cycle.
Because reliability is difficult, many of us resort to redundancy whenever possible. (The general exception to the redundancy rule is aircraft structure. Redundant structure is heavy, and structural design is actually a pretty well-known science. Building a reliable structure is pretty easy if we are not trying for the ultimate in lightness.) In fact, I generally design with the explicit assumption that any system I build is going to fail in flight. I then ask myself the simple question, “What is the backup plan?” If I require the ability to fly a precision approach to minimums, I might put in an ILS system. If it fails, how about a second one? Or… I could limit myself to flying where I am assured to never need better than a non-precision approach—or always flight plan so that a PAR approach is available within available fuel reserves. There are often alternative, creative ways of creating functional redundancy that don’t even add anything to the aircraft!
Backup Plans
The concept of the “backup plan” is a simple and powerful tool for anyone trying to build a functionally reliable aircraft. First, define the list of functions required for the type of operations you wish to perform. Next, define the list of primary systems and equipment necessary to perform those functions. Then ask yourself what you will do to ensure the function if each primary system fails. Add only what you need to ensure the function, and you’ll have an efficient, redundant design. I said it was simple, didn’t I? Well, yes and no…because when we design airplanes, we often have to deal with certain realistic constraints.
Let’s take that single engine, for instance. We pretty much decide up front if we are going to build a single- or multi-engine aircraft. It is one of the key assumptions that goes into our preliminary design cycle. For homebuilders, it is generally a cost issue as well as one of complexity. The vast majority of homebuilts are single-engine due to these realities.
So what do we do when our desire for redundancy runs up against the facts of what is practical—or affordable? Well, there is always that reliability business. If you can’t make it redundant, then make it reliable, right? In the case of powerplants, this is the main reason that easily a third of the cost of an airplane you are going to build is going to be for the engine and propeller. Building reliability takes money—money for design, money for testing, and money for quality control of each and every end product. Fortunately (or some original thinkers may say unfortunately), we have purpose-built aircraft engines available to us—engines that have run for millions of hours over decades on aircraft of all sizes and designs. Engines by Lycoming and Continental are built to precise specifications and certification standards. (By the way, I am a big supporter of the clone engines as well, but they are still copies of the highly reliable certified versions.)
If you leaf through the maintenance and parts manuals for one of these engines, you will be amazed at the detail to which they go to define exact parts, right down to which washers go on which bolt—even those bolts that might seem quite trivial to us. The clamps that route ignitions wires, for instance, are specified exactly, as are the bolts and washers that hold the clamp to the engine. They don’t just say, “Clamp the wires so they don’t flop around.” No, they tell you exactly where each one should be held and which Adel clamp to use. Sealants, gaskets, safety wire—all are specified so that each engine exactly matches the engines that have been so thoroughly tested that we can be pretty well assured that they will keep running when we need them—which is anytime we decide to “commit aviation.”
Enter the Experimenter
We love to tinker. We love to try new things. We love to invent and hate to do things “just because that is how they are done.” But if we want to achieve the kind of reliability that we need in flight-critical systems, we need to be very, very careful when tinkering in the arena where we have no redundancy. Take, for an example, an incident that happened a while back in an Experimental airplane with a stock Lycoming engine. Well, an almost stock Lycoming motor. The builder had a good idea—instead of mounting the fuel flow transducer upstream of the engine where it is susceptible to pulsations from the pumps, why not put it between the fuel servo and the distribution spider—just before the fuel is split up to go to the cylinders. It would be isolated from the pulsating fuel pumps and measure the total fuel flowing into the cylinders very precisely. He was absolutely correct—this would be a good place for it! Unfortunately, changing the fuel line between the fuel servo and the spider altered the dynamics of the system. The “stock” system had, indeed, millions of flight hours on all sorts of airframes that proved it was OK. But his trivial redesign broke due to harmonic vibration after only about 65 hours total time. There was no testing or evidence that showed that this new configuration would be reliable—and that dropped the reliability numbers for the entire engine to what could best be described as unknown.
There is nothing fundamentally wrong with Experimental powerplants; how else are we ever going to advance the science of aviation if we don’t experiment? But we have to acknowledge that when we experiment, we can drastically affect the reliability numbers of the stock equipment that we have changed. We can deal with this by limiting our operations. For instance, until the powerplant has proven itself through testing, we can restrict operations to within gliding distance of a runway. That might seem like a drastic restriction, and it is…but it is exactly what aerospace companies do with their new designs until they have enough experience and data to let them leave the nest.
Amateur-Built Experimentals have a very poor record when it comes to engine failures due to systems issues, and many of them end up in off airport landings—many with serious injuries or fatalities. In the case I cited above, the pilot was in instrument conditions when the engine failed, but he was able to dead-stick it through the clouds and use his EFIS database to be pointed at a small private strip when he broke out. He then used his superior flying skills to plant the airplane safely on that runway. Fortunately, the area over which he was flying has numerous little private strips sprinkled about a flat coastal plain. Had he been over the mountainous West, things might not have turned out nearly as well.
Reliability is something that we need to understand if we are going to depend on it. Build in redundancy wherever you can. And when you can’t, make darn sure that you are using systems with proven reliability when you have to depend on them working—or else. There are no minor modifications to reliable systems. Any change needs to be rigorously analyzed and (if necessary) tested to make sure that it doesn’t compromise the overall reliability of the system. Make sure that your critical functions are covered—whether by reliability or redundancy—before you have to depend on them to achieve the functionality that you need.
