"Power frozen" meaning that the 3 engines remained at take off power when they were throttled down shortly after TO whilst engine 4 reduced as planned???
All 4 throttles then reduced to idle which they all responded to and when power reapplied, 3 engines stayed at idle whilst engine 4 responded as expected?

Do the reports / discussions relate to a software version (separate program loads) or the (re)configuration of a single ‘standard’ software?

A comparison with ‘older’ conventional aircraft, the production pre first flight testing could include installing specific testing devices such as control rod loading and angle measurements in the aircraft. These were not flight-worthy and thus had to be clearly identifiable and/or have ‘interference’ links preventing flight use. Similarly, failure conditions could be tested with system pin-outs or interference links (grnd/flt switches) which created abnormal situations which could not or would not be advisable to test in flight. The devices would again be clearly identified – big red flag, etc; which of course did not prevent the rare ‘surprise’ during first flights if some aspect was overlooked.

Are we to assume that similar activities with software loads/configurations are conducted during ground testing; i.e. not flight worthy programs / configurations. If so then the problem is perhaps more with software control/configuration opposed to the design/operation of the power-plant control system, but the latter should never be discounted.

I recall one ‘conventional’ design weakness which was not discovered during ground testing and resulted in all engines going sub idle at touchdown after first flight – ‘wt on wheels’/engine control logic, and a minor unrelated system failure. This could have happened in flight but fortunately the specific trigger circumstances were not encountered.

Multiple sources have published Airbus stating that the problem was one of quality control in the final assembly process, and not a fault in the "design/operation" of the aircraft.

Wing bending relief
 

KenV-'There are four wing tanks on the C-17. And they feed fuel to their associated engines equally. The outer tanks are not kept full for wing bending relief.'

I beg to differ Ken, the outboard tanks on the C-17 are kept full until the inboards reach the same level then they all come down together.

Most FADEC s/w has the ability to be 'trimmed' via a s/w adjustment. This trim capability is typically used during flight testing for specific testing - e.g. allowing a certain amount of overboost, or changing an idle schedule to facilitate some specific flight test objective. We have very specific processes and procedures on how these trims are used - for example if a trim is going to be used on all engines, it must be flight tested on a single engine first before it can be installed cross-wing. As I noted in the previous post - we are quite aware we're messing with flight critical s/w.

We had an incident in service a while back where a newly installed engine was squawked on the next flight for T/O thrust shortfall and excessive throttle stagger. The engine in question was a brand new spare received from the engine manufacture. It turned out that the engine manufacture used software trims in the engine test cell in order to perform some of the normal production acceptance testing on a new engine - and somehow this engine had gotten shipped with those s/w trims still installed in the FADEC :eek:. Very embarrassing for the engine company, but fortunately there was a happy outcome, and new procedures were implemented to prevent a repeat.
Sorry for the speculation, but it rather sounds like some sort of s/w trim had been installed in the engine s/w (either by the engine manufacture, or by Airbus as part of their pre-flight functional testing) and not "removed prior to flight" on the three engines.

You are of course correct. I was not clear. The inboard tanks are larger than the outboard tanks. Fuel is fed from the inboard tanks to both engines until the fuel volume is equal in the inboard and outboard tanks. From that point both tanks feed their respective engines equally, with the outboard tanks not kept full for wing bending relief.

It seems so easy to modify a software without all the tests with the test data are done. That is a specific danger of flying computers. It implies too to have a low level of written history of the system , and that bad history may hide for a long time a software mistake/fault.

Arrived back at Bordeaux-Merinac on Wednesday 0845 local and there was a A400 on the stand. Could only see the fin, but had not realised how big the aircraft is. Also an RAF Airtanker there both 27 May and 3 June.

It seems so easy to modify a software without all the tests with the test data are done.

In the spacecraft world, launch vehicles and devices to be launched are subect to a hardware freeze and a software freeze both in development and manufacture, and these pre-determined freezes are written in stone: nothing can be changed after that date. Oh, except in France, of course.

Well I muss confess the whole narrative is perplexing.

I have admittedly no experience with this specific power plant but I really fail to see how it's engine control software can be erroneously installed, be functional to the point of passing all static tests yet fail in such an extreme way to crash the aircraft.

I can understand that it was mis-configured, was getting erroneous inputs from sensors or - most likely - was simply buggy - all explanations apparently not applying here. An installation error that goes undetected until flight time ? On 3 out of 4 engines ? Wow... :uhoh:

O/T
 

I think when they said a quality failing you have to take a metaphorical step back and look at the "whole" picture.

A software install can be 100% correctly completed and still be "wrong" ie the installers have been issued a wrong version of the correct software; configuration control, process control-it may well be not the fault of the techs doing the actual upload if the information they were supplied with was wrong in the first place...

Roulis,

Have a good look at DAL. It's not a case of rewrite the code, upload, off you go. Safety critical software has to demonstrate an appropriate level of verification and assurance in manufacture and testing before it goes anywhere near an aircraft.

Something went wrong, speculation over such a complex failure will not solve anything.cwe will get the investigation findings in due course.

A cornerstone of the ZD576 case! It is depressing reading many of the excellent comments here as you could substitute tail numbers and be talking about any number of accidents.

Modification
 

Why don't Airbus introduce a suitable series of levers and rods from the thrust levers on the flight deck directly to the fuel control units on the engines.

Then they could have a third chap sit on the flight deck to help manage these levers and when not doing that could carry out walk rounds, a bit of down route engineering and seek out "interesting" places to take the crew too for refreshments...

Ditch FADEC and software and bring back flight engineers?

Bigpants, if only it were that simple!

Bigpants wrote: Yes, if you want to turn the clock back about 30 years. But at least that would mean the presence of a moose-trapper amongst the aircrew....:yuk:

"You haven't seen ugly until you've seen something rejected by an air engineer!"

I'm not quite sure what you mean by that statement Beags?

Well, I'm not a military airman, but I'm absolutely certain I know what Beags was referring to!

A400M crash due to fubar data
 

https://www.yahoo.com/tech/s/exclusi...--finance.html
Exclusive: A400M probe focuses on impact of accidental data wipe

basically some torque calibration data got wiped during software installation/checkout. Missing that data, computers decided engines were maybe harmed and to prevent further damage- simply shut down- Three out of four engines..

HAL wins again !! :ugh:

So much for ' fail safe' modes due to garbaged data...:sad:

Missing calibration parameters on 3 engines, detected after getting airborne
 

Exclusive: A400M probe focuses on impact of accidental data wipe | Reuters

I can't understand why a very possible failure mode (lack or erasure of parameters) is not self-detected (e.g. by a checksum/hash mechanism), and reported in pre-flight checks. Note: I'm an engineer designing security-critical software (though no safety-critical as in aviation).

Computers are smart :E

Keep it simple folks.

I've long been skeptical of FADEC systems that decide that an engine should go to idle, or shut down absent pilot input. In many cases (eg uncommanded reverser deployment), it's easy to see the logic, but I've always thought that it's best to have some sort of override built in, just in case of corrupt data.

an override of the override?

The latest twist in the tale - Airbus is now running out of ramp space to park its grounded A400Ms Airbus running out of room to park grounded A400Ms - IHS Jane's 360

Park them on the `grass`...they are `tactical `aircraft after all...

Sycamore

I had to chuckle at your "park em on the grass". I put this down to how we sometimes miss the glaringly obvious. It reminded me of a story from the space race in the 60s. Apparently the Americans spent $10 million trying to develop a biro type pen that would perform in zero gravity. The soviets used a pencil.

Ah that old chestnut.

You can buy one too!

Fisher Space Pen Co.

I suspect that lots of graphite dust floating around electronics in zero g isn't the most fabulous idea, either. :E

If I was going to buy a pen then it wood be one of these, pun intended...

Caithness Pens

Having visited Airbus at Seville on numerous occasions, I can vouch for there being very little in the way of spare grass on which to park grounded A400Ms. Not only is the Airbus side of the facility pretty much completely paved (and I assume it is this area that is rapidly filling up), but the facility abuts onto the international airport which would again limit room for overspill.

False story.

1. NASA used pencils all through the Mercury and Gemini programs. It was not until Apollo that they used pens.

2. The "space pen" was developed commercially by the Fisher company at zero cost to NASA or the government. (And it cost $2M to develop, not $10M) It did not sell well commercially because it was pricey. Not until they sold their pens to NASA did Fisher call it the "Space Pen", but they made a bundle from that point on. Indeed Fisher claimed that their space pen saved the astronauts on the moon on Apollo 11. The toggle for the switch that armed the launch engine for the lander broke off. Buzz Aldrin used a pen to reach inside the switch to close the circuit and launch the lander. Fisher still markets the space pen and still claims it saved Apollo 11. But in his book Buzz revealed that he did not use a Fisher space pen to do the job.

3. Russia used (and continues to use) Fisher space pens on all its Soyuz flights as well as Mir and ISS flights. Its still the only pen that works in zero G.

Opinion is divided on that one, Ken.

Ballpoints don't feed by gravity, the feed by capillary action. Most won't work if held upside down for any length of time because the -1g tends to pull the ink away from the ball and, once separated from it, the ink loses its capillary action. Zero g is a different matter. There is no force to pull the ink either way so the surface tension can do its work.

One of the astronauts on ISS (or was it Space Lab?) tried it with a ball point he nicked from NASA and reported in his blog that it was working fine.

That said, if the 50c biro stopped working they wouldn't be able to do their homework any more so the space pen is certainly a safer option!

But it wasn't a FADEC system. FADEC systems are certified under engine rules and have their own backup, fail-safe protocols. If a FADEC system had it's data wiped beforehand you wouldn't even have been able to takeoff.

I stand corrected.

It's still the only pen that works reliably in zero G.

Nice post Nutty! now that is enterprising :D:D:D

Wait........the Spitfire used wooden propellers? I never knew.

I keep thinking there is still more to this than is being reported. It is a "FADEC" control. For those of you who may not know, on a turboprop, the FADEC will adjust the prop to hold a constant speed, then adjust the turbine to hold the desired output torque (and the FADEC measures the torque on the output shaft directly - at least on the turboprop I worked on many moons ago it measured the shaft twist to determine the output torque).

The linked articles suggest that they have the ability input engine specific torque calibrations - but as a long time engine guy it's inconceivable to me that the FADEC would not have a 'default' torque calibration, and/or set some sort of no-dispatch message (or even prevent the engine from starting) if the engine specific torque calibration was corrupted or "wiped".

We're still not getting the full story.

At least on the FADEC systems I've worked, the only reason the FADEC will go to idle or shutdown absent pilot input is for:
a sensed unsafe condition (e.g. rotor overspeed), or
failures have made the FADEC incapable of safely controlling the engine.

I know there is still a certain skepticism of FADEC, but the fact is that engine control caused shutdowns and "loss of thrust control" events are roughly an order of magnitude better with FADEC than with the old hydromechanical systems.

I would certainly agree.

And I can't imagine that if it wasn't the case (ie no "fallback / safe mode") this would not raise some alerts during the static tests that have (hopefully ?) been undertaken before this flight !?

Another question: given that the aircraft was most likely nowhere near MTOW wouldn't this situation allow some measure of controlled flight / managed emergency landing ? Or where they extremely unlucky not being able to walk out of this one ?