pacplayer,
no offence intended, maybe my words were a bit harsh.
With cooler head:
I assumed you were talking about fly-by-wire since you specifically mentioned Airbus and B777, which are the most predominant and widely-used fly-by-wire airliners. Apologies.
Whether you know it or not in FADEC, code algorithms are constantly checking engine parameters and "voting" when, or if, to schedule twin spool acceleration.
No, that's not really how it works. There are feedback-control-loops, and additional safety checks, but when, e. g. requesting TOGA thrust in flight, which almost always indicates some sort of emergency, spool up is as fast as possible while still avoiding stalls and flameouts. Engine life protection does not usually take precedence over thrust demand. Case in point: engine vibration is measured and can be displayed in the cockpit. But this, although it may seriously damage the engine, is only advisory. Full thrust even on an excessively vibrating engine is available (if mechanically possible, but physics will decide that, not the FADEC).
(And just to be nitpicking again, the Rolls-Royce Trents are triple-spool, not twin-spool.)
Pilots with fully mechanical control (which has been very rare for a long time, even before FADEC) cannot always, especially in a high-workload situation such as a go-around, do the optimal spool-up.
Voting, if at all, only happens between two or more identical (or diverse, depending on the development model) circuits, one of which alone is sufficient to control the engine. Often there is no voting, but one computer (often called a "channel") internally checks its computations with a separate processor, and if both disagree, the entire channel declares itself failed, and the fallback channel takes over.
Since they won't allow overboost,
They do not allow anything beyond TOGA thrust. But continued TOGA thrust, while not recommended, is possible, even if it significantly shortens engine life. I don't know about the 777, but on the A320, TOGA thrust is allowed for a maximum of 5 minutes (or 10 minutes with one engine out). But this limit is not enforced by the FADEC.
... are concerned about thermodynamic engine life they sometimes reject a flight deck command in favor of a slower acceleration schedule.
Yes, but the reason for that is not only increased engine life, but also avoiding stalls and flameouts.
Sometimes they reject everything altogether and command idle logic instead
No.
Even if the readings from the thrust levers fail completely (or are inconsistent, i. e. both redundant sensors read differently), FADECs do not automatically command idle thrust. A lot of throught has gone into the logic what thrust to set in case of such failures. Depending on the flight phase, either idle, MCT or the last commanded thrust is set.
(which can't happen with old 747-100's and 200's with steel cable to hydomechanical control.)
Of course it can happen. The cable could just break. Rare, I know, but so are EEC/FADEC malfunctions.
Thus my position that the old design was safer from a "fail safe" consideration at spool up.
A snapshot (data point) of the sun in the sky does not mean it is daylight 24 hours a day. Fuel valve positions can be momentary recorded in the middle of transitory problems; so this report of everything being fine with the fuel valve means nothing to me.
Yes, I am aware that there may be issues with the digital electronics involved. You are mistaken if you think I have blind faith in them.
However, I assume FMV position is recorded once every second, or at worst every 4 seconds. It seems extremely unlikely that it was oscillating at .25 Hz, and always at the point of sampling for the DFDR, was fully open, and almost closed in between. There is still the remote chance that the recording as such was faulty. Since we have no access to the EEC software, we cannot say.
As to the relative numbers of engine control cables breaking, as opposed to FADEC problems: Just consider the sheer number of FADEC-engined aircraft today, and the dwindling numbers or airframes, and low number of flight hours, for mechanically controlled engines.
Even if both were equally safe, we would expect to see more problems with the electronic variant than the mechanical ones.
On the other hand, modern digitally controlled FADEC and autothrust systems offer increased stall protection, e. g. Airbus' "ALPHA-Floor-Protection".
But it does hurt your flying ability to have microsoft windows type crap software between you and the spray nozzles. No way to override it in time. Bad Bad design, imho. But that's how were doing it now.....
(my emphasis)
I know you're trying to make a point, but the development process for business software, and for safety-critical software for embedded systems cannot be compared. These are totally different things.
Not a single thing you may think you know about "Microsoft Windows" type software is applicable to embedded systems development.
I say again, this does not mean that I believe there are no problems with FADECs; I know that there are. But there are methods known in the industry to make extremely reliable software. Not all of those techniques seem to be applied with sufficient rigour all the time.
Try searching for "SCADE", "Lustre" and "SPARK" to get an idea of what embedded software development is like. Seriously no Windows-Type crap there.
----
Ptkay,
While it is true that very high software reliability cannot be shown by testing (i. e. subjecting the software to varying input combinations and checking its output), there are methods (see above) to develop very-high reliability software.
The limit is not the code size as such, but the inherent discontinuity of digital computers, i. e. even the smallest possible input variations can create a completely different output.
One name for development methods that do not rely on testing to ensure proper functioning is "Correct by Construction". Formal mathematical methods are applied to ensure that the software does what it is supposed to do.
Bernd