Eclipse Software 1.01 Release 2 Patch 3b released, and solves the FADECs problem !
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.







4 Comments, Comment or Ping
Lorenzo
Hi,
my compliments for the blog, very well done. As Safety Engineer working at Pilatus Aircraft Ltd. I felt I could add something to your discussion. I think that the big problem with software is that not only pilots don’t understand how it works but also engineers have big troubles with it. Software IS a black box for everybody but the software engineer that designed it. It is extremely difficult to perform proper Safety Assessments on software and Common Causes are even more difficult to identify. I feel that the safety activities that are extremely well developed for standard, electro-mechanical systems are still to be further improved for software. Until then, incidents like the one reported for the Eclipse (and what about heathrow 777?), considered impossible from a theoretical point of view, will continue to happen and to make people worry about unpredictability of “digital world”.
Jun 27th, 2008
Jess Sightler
I’m glad you were joking about the version. For a moment, I thought their software was written by Oracle!
Then I realized that the Oracle FADEC would be 1.3.1.8.2.1.7.
Jun 28th, 2008
PlasticPilot
@Lorenzo: Comment from a Pilatus guy… wow ! Being a software engineer myself, I agree with the black-box aspect of software. Safety methods and practices for software development exist and require huge amount of resources, to make sure that design is reviewed, software is tested agains its requirements – and not by the developper himself, and so on. But as it is a non-physical thing, inspecting it is not that easy. I don’t want to bore the readers with the details and impacts of such methodologies, they could be the topic of a separate blog…
@Jess: Oracle would be bad, but I can imagine worse…
Jun 28th, 2008
Reply to “Eclipse Software 1.01 Release 2 Patch 3b released, and solves the FADECs problem !”