Realtime Software Engineer
Thought I'd pitch in with some general observations concerning realtime software development in such systems such as boeing 777 avionics, honeywell aims, autothrottle and fadec (I've not worked on these systems but know of them).
Firstly all realtime software is based on modelling. Your software is only as good as the model you have developed.
Very simplistically the model need to do two things. It needs to simplify the complex outside world into an internal representation that is 100% predictive within the expected boundaries of the inputs AND the expected way that various input ranges should work together. i.e. As one set of inputs is moving up the model expects another set of inputs to be moving down, perhaps with a lag, because this is what is physically happening in reality.
The second part of modelling is making the model fault tolerant or fail safe. This is where you try to analyse all possible failure modes (of the inputs) to ensure that your output is still appropriate to the task in hand.
Simplistically this whole model is captured as a specification, testing is done against specification, in the 777, 99% of the code used ADA programming language. ADA's strength is that it you can enforce expected input and output boundaries on functions/procedures/methods and capture programming logic errors on this basis. In other words after completing testing and certification you can be sure your software is 99.9999% accurate to the specification, and adheres accurantely to your model.
The largest problem, by far, for realtime software, is where the inputs fail in such a way that they still provide data that is within the expected range for the model. The software's ability to control is now VERY dependant on whether this particular failure mode, has been anticipated, in the second part of the modelling process explaination above. If it has not been anticipated then this is where the software starts to make bizarre choices in terms of controlling the output.
I believe, IF it is a software problem, it will be due to inputs from measuring devices that have partially failed.
In basic terms my understanding of auto-throttle ->AIMS->fadec process is as follows.
Physical throttle settings in the cabin -> read by auto-throttle module in the honeywell AIMS system -> processing based on internal model -> specific thrust request command to the fadec -> fadec compares request to current measure/calculated thrust - > fadec adjust thrust accordingly.
Even where the auto-throttle is turned off, the auto-throttle module is still doing the interpretation of the manual throttle settings.
When autothrottle is turned on, the auto-throttle makes DIRECT request to be FADEC (via hardware buses) for appropriate thrust based on its calculations, and the auto-throttle THEN sends a signal to the physical throttle servos to move the physical throttles in the cabin for feedback to the pilots.
Each engine has its own FADEC. The auto-throttle would appear to be working within its model, as the pilots have reported that auto-throttle detected lower speed than set, and requested additional thrust, and communicated this to the pilots via the physical movement of the throttles in the cabin.
AIMS connection to each fadec is via dual bus channels. I find it hard to believe both channels to both engines failed simultaneously (that's four channels failing at once).
Reports from the captain said that half the displays blanked. This would be consistent with a loss of electrical generating power from the engines. On detecting a power loss, the system switches to battery, cuts all unessential systems (i.e. only one set of displays), and commands the APU to start. Once the APU starts and stabilises voltage (30sec- 1minute) the non-essential systems should restart.
IMO the blanking displays is part of the engines spooling down past idle, not the cause of the engines spooling down.
Loss of electrical generating power from both engines would only occur if the electrical power management unit completely failed - as per the qantas flight going into Bangkok earlier this month - or if both engines spooled down past idle.
Given what we know about the engines, it seems clear the engines spooled down past idle, causing the power failure and not the other way around.
Loss of communication between the AIMS and both FADECS, i.e. multiple bus failure, would not cause this. Loss of power to the AIMS system would not cause this. In simple terms the FADECS proceed with the last thrust command until commanded otherwise.
I do not know what unit commands the fadecs to turn-off the engines. But that request will be so tightly predicated, for that to happen, literally hundreds of inputs that confirm that the plane is on the ground would have to be met. I don't believe that this command could be sent accidently by the software or through a modelling error. (Reset, restart, dealing with flameouts, if not dealt automatically by the fadec, would be a different set of predicates, but the same meticulousness would still apply. Many conditions would have to be met to allow this command to go ahead.)
To me the areas of interest are the fadecs on each engine, the inputs to the fadec that give feedback for actual measured thrust, the fuel management system, the fuel level sensors, and the fuel.
I can't see that both fadecs would fail simultaneously. Even if physical conditions outside the plane caused, say, engine thrust inputs to falsely give a high reading, the fadec would not spool the engines down past idle, based on this.
My best guess is that it is something to do with the fuel level sensors - which I believe are ultrasonic - and would go for the subtle, swopped inputs problem, as this by definition means the model is working in the fault-tolerant area of its model.
a. Swopped inputs.
For example, Sensor for Tank A is plugged into input for Tank B. Sensor for Tank B is plugged into input for Tank A. This would cause the system to swop from a full tank to an empty tank. Obviously with more sensors and more possible combinations of swopping you can see how you could have fuel on board, yet not get fuel to the engines. Obviously the swapping could be more subtle, even a digital swopping. i.e. If a sensor unit connects to the data-bus, and the unit malfunctions and starts sending out levels under multiple valid sensor ids, you can see how this would confuse the fuel management system. Don't know if this is possible in exactly this fashion, but you can see how swopped inputs, digital or physical, can cause havoc.