Plastic Pilot

Yes, this is your favorite aviation blog, even if this post title sounds much more like the typical anoucenement for a patch for a mysterious software. Apparently, the problems with the Eclipse 500 Very Light Jet FADECs is now solved.

The FADECs software did crash when it received an out of range value from the trhottles. According to AvWeb: “Eclipse says its solution will increase the range limit of the throttle quadrant assembly to prevent the fault condition from occurring.” Given the kind of problem - both FADECs failing at the same moment, when throttle is pushed full forward - this is not really a surprise to me.

Eclipse will deliver a software update that will remove the problem. It is not the first time in aviation history that a software patch will solve a problem, but given the mediatic buzz around the VLJs, and the Eclipse 500 in particular, this is gets more coverage than an Airbus patch.

The name of the patch I mentionned in this post is a personal inventon, trying to be fun, and to make you think. The serious problem that affected the Eclips will be solved by simply uploading a new firmware. I don’t know however if the Eclipse interface uses USB or Bluetooth.

Jokes put aside, I know many pilots that will feel uncomfortable with the concept of flying a software controlled plane. Most of them associate “software” with their own experience at home, with their PCs. Airplanes are not all the same, airlines are not all the same, and software are not all the same.

The development standards, and quality of software used aboard aircraft has nothing to to with what you have in your PC. The hardware is also different, and there are no third products that you can download yourself in the FADECs, making the environment much more controllable.

Another thing that make software sounds mysterious (and then dangerous) is that most pilots don’t understand exactly what it is, how it’s made, how it works, and what it does. A magneto, alternator or carburetor is much easier, and these things can be seen, touched, examined, dismantled, and inspected. You can’t do that with software.

Shall we get rid of software in our planes ? Hell NO ! There is no efficient engine management without electronics and software. There is no GPS, no RNAV tools without software. Without software, no cockpit integration is possible. Things like TCAS, GPWS, Mode-S transponders, FMS, and many others are all software based. Did I mention autopilots ?

As any airplane part, software can fail. It’s not because something is computer-based that there will be more or less failures. Just like a crankshaft, pump, belt, servo, landing gear assembly, fuel line, piston, windshield, voltage regulator, intercom, or any other mechanical or electrical component, software can fail.

This is exactly why there are so many different computers on board. For engines management, avionics, navigation, and so on, each system uses its own, separate hardware and software, to avoid crashing all of them at the same time. That would be bad. At least as bad as a failing wing-root, or a lost engine making the plane out of balance.

So please don’t be affraid of software simply because it can’t be seen or touched, and don’t compare aircraft embedded software with “quickly downloaded - quickly deleted” kind of stuff that fulfills most harddisks. Software is the next step in aviation, just like voice replaced morse code, and composite slowly replaces aluminium.

With the highly demanding validation and certification standards required in aviation, the risk levels remain minimal. Not zero, but well acceptable. Remember that safety is not defined as the absence of hazards, but the absence of unacceptable hazards.

On the 5th of June, an Eclipse 500 was about to land when it experienced a windshear. The pilot applied full power to counteract it. After touchdown, the plane accelerated, with both engines delivering full power, and the crew was forced to take-off again.

Both engines were still delivering full power, and both FADECs were reporting failure. The Quick Reference Handbook (QRH) do not mention procedures for a double FADEC failure, but says that if a FADEC is failed, the corresponding engine must be shut down.

The crew decided to shut the right engine down. After that, the left engine stopped delivering thrust, remaining at idle power, whatever the throttle position. The crew achieved to land, kudos for that, and this hopefully happened in VMC conditions.

Each FADEC is made of two channels, and if one fails the second one takes over. If both fail, parameters are taken from the other engine. If the other engine FADEC is also failed, the last known parameters are kept. As both FADECs failed simultaneously, the engines continued to deliver maximal thrust. After the right engine was stopped, its FADEC was no longer reporting failure, so the left engine FADEC “copied” its parameters, leading to idle thrust.

The system behaved as designed, and if it allows for more redundancy that classical (electro-mechanical) systems, in that particular case, it failed almost completely. The open question is why pushing the throttles to a full forward position causes a double FADEC failure..

On request of the NTSB, Eclipse did upgrade the AFM and QRH to inlcude a procedure to handle such an even, and the FAA mandated an inspection of the throttle assembly of all Eclipse 500 aircraft. Read more from Eclipe, and from NTSB.

The problem could be reproduced (on the ground), and the FAA issued an airworthiness directive requiring an inspection of all Eclipse 500 aircraft before their next flight, and inclusion of the new procedures in AFM and QRH. This inspection can be performed by the pilots themselves, and simply requires to turn electrical power on and push the throttles forward, looking for any FADEC alert