- Electronic Engine Controls -
A Peek at the Technology and Associated Reliability Issues
In the late 1960's, electronic engine controls began to appear in the automotive world. One of the first I remember was a fully-analog fuel injection computer developed by Bosch (D-Jetronic™) which was used in Type-4 VW vehicles. Back then, I was working at Pratt & Whitney Research Labs on the development of electronic control systems for turbine engines. That Bosch Jetronic system provided the basis for some of the research and development on that project. There have been immense advances in digital technology since then, when digital computers occupied large rooms, required huge outdoor cooling towers, and were the sole province of the beancounters. The amazing technology in today's devices (huge reductions in power consumption and size; immense increases in, speed, computing power, reliability and environmental tolerance) have made Full Authority Digital Engine Controllers (FADEC) commonplace in commercial and military aviation.
Spurred by governmental requirements for reduced engine emissions, that control technology spread into the automotive world, to the extent that contemporary piston engines in most applications (cars, trucks, locomotives, tugboats, etc. etc) have at least one dedicated digital computer (aka ECU's or Engine Control Units) in complete control of the fuel delivery and ignition events, producing levels of efficiency, emissions, flexibility and smoothness which were unimaginable with mechanical fuel and ignition systems.
Indeed, contemporary compression ignition ("diesel") engines now operate at unimaginably low emissions levels, while producing race-winning power and better efficiency than is possible in a spark-ignition engine. The performance of the LeMans-winning Audi and Peugeot diesel engines (140 bhp per liter at 5000 rpm) is made possible by digitally-controlled fuel injection systems which operate in the 30,000 psi neighborhood (that's THIRTY THOUSAND) and can have as many as five separate injection events per combustion cycle.
So there can be little argument that computer control over piston engines is a desirable advance, and could be very attractive for civil aviation. Several mainline companies in the certificated civil aircraft world have produced digital controls of one level or another.
However, it has recently become fashionable in the experimental aviation community to install contemporary automotive engines into aircraft. One major problem with that practice is the fact that a single system composed of singular elements (computer, sensors, injector solenoids, spark coils, and wiring) completely controls the engine's fuel delivery and the spark timing, and a host of other variables as well. It is well established that the new technology in ECU control is splendid in its accuracy, responsiveness and fuel efficiency. However, it represents a single point of failure for the whole powerplant, and moreover, the failure of any one of a myriad of components in this control system can render the engine immediately inoperative.
The following description is a broad-based, general description of the logic contained in contemporary ECU's. The fuel and spark schedules exist in the ECU as sets of values in 3D tables. Typically, the X-axis of the tables is RPM, and the Z-axis is either manifold absolute pressure (MAP) or mass airflow (MAF).
In the fuel tables, the Y-axis values represent pulse widths (in microseconds) necessary to cause the existing injectors to deliver the amount of fuel required for at each combination of RPM and MAP (or MAF). In the spark table, the Y-axis values represent the number of degrees of delay after the reference pulse in order to produce the required spark advance for each combination of RPM and MAP (or MAF). The instantaneous spark and fuel values are produced by interpolating between the 8 "corners of the box" defined by the points closest to the measured values of RPM and MAP (or MAF). Then those spark and fuel values are modified dynamically by computations using tables of trim values for such parameters as throttle position, inlet air temperature, cold-start enrichment, coolant temperature, cranking condition, fuel injector nonlinearity and delay characteristics, and other parameters.
It is obvious that if the computer fails, the engine can be severely damaged or simply stop, depending on the nature of the failure. But there is the exponentially greater risk that if any one of the sensors fails (in one of several possible failure modes), then the ECU becomes unable to determine one or more of the critical input values needed to determine the spark and fuel requirements.
Further, since the driver transistors controlling the injectors and spark coils are "grounding" (they close the path from the injector or coil to ground), then the failure of a driver can cause a fuel injector to fully saturate and go to full flow, potentially causing serious mechanical engine damage or an inflight fire (neither of those is a Good Thing).
There are various different strategies to compensate for the loss of one sensor and provide a "limp-home" mode of operation. For example, on an MAF system, if the MAF sensor fails, the ECU can revert to the use of MAP and / or throttle position to estimate fuel requirements. If the RPM sensor fails, the ECU can roughly estimate RPM once per revolution using the cam position sensor (if the engine is so-equipped). Clearly, the available fallback strategies will vary with the available sensor suite, the sophistication of the sensor diagnostic code in the ECU, and the algorithm sophistication and programmability of the ECU.
From the above (very brief) description, it is easy to see that the functioning of the engine is entirely dependent on the correct operation of the ECU and the supporting sensors. There have been various attempts (a) to rationalize flying on a single ECU, based on the delusion that "automotive ECU's don't fail very often" and (b) to provide a "backup" ECU, (usually a cobbled wiring mess) which, in the best of cases, has the backup unit fully operational, in synch, and ready to be manually switched over.
In addition to an operational backup ECU, a reasonable backup system must include a suite of backup sensors (MAP, MAF, throttle position, crank position, cam position, coolant temperature, inlet air temperature, etc.) and servos (fuel injectors, spark coils, actuators, etc.).
In order to completely isolate one ECU and it's sensor and servo network from the other, a complete circuit- switching system is required, which is also subject to catastrophic failure. Most of the existing "backup ECU" designs depend on a network of diodes to isolate each ECU from the other, but I have seen cases in which one ECU failed and destroyed the "backup UCU" at the same time.
Many times, I have tried to explain to purveyors of these "backup" systems that diagnosing engine problems and switching ECU's when one is 200 feet off the ground at Vx is a very unhealthy situation. In fact, the number of pilots who have survived an engine failure just after takeoff in an easy-to-fly, low wing-loading airplane (with two independent ignition systems and either a gravity-feed fuel system or a running, backup fuel pump) is alarmingly small.
This discussion can go on in great detail, but the bottom line is that, having been directly involved in the design and development of jet engine FADEC's and the various fail-safe strategies necessary to get the FAA to stop laughing, I am well aware of what constitutes an airworthy computer control system.
Although the two new engines I am developing will both require direct, sophisticated computer control, I have not yet devised a system which will provide suitable reliability. Certainly none of the aftermarket or OEM systems provides acceptable reliability and / or backup, and certainly a single ECU application is, in my opinion, unairworthy.