Good points Dozy,
I agree that's the time-tested ideal formula for success: split teams . What I worry about/suspect is corporate corner-cutting:
The finished product is handed off to another senior manager who knows one team has a better product than the other.... and starts rationalizing that since he already has redundancy and since the team B load became ultra stable and has never crashed.. why take a chance on the "A team" screwing up a reliable product.....? (and no time to start over with a third team...)
Now if that were to happen (both A and B channels identical stable code,) you could be facing an unlikely dual-bug-crash should Murphy's Law present itself.
This is all, an improbable, 100% fictitious example on my part, but: recall others in the industry in this thread have voiced concern that we are already into a highly unlikely probability with this double engine failure in of itself.
The reason I discount LP side fuel problems (by themselves) is that Boeing had experience with long range 747SP's that stayed aloft for 18 hours for over thirty years without cold-soaking tank issues leading to multiple engine failure (to my knowledge.) Lots of pumps would have to fail (or already be defered) to loose tank to engine LP fuel feed right? And cavitating pumps were not unheard of in Boeing fuel systems. Various baffle mods and other fixes were put out if my memory serves.
And in the Case of BA038 the suction/grav feed fuel source should have backed it up on at least one side... wouldn't you think?
What about a compound problem? Momentary system selection of dry tanks (slug of water/ice) followed by a FADEC that couldn't resolve conflicting code since it's signal sensors got frozen like the GE engines did.
The FADEC turns into a HAL-9000 so to speak. (I'm sorry Dave, I'm afraid I can't allow you to do that.")
This might be a scenario where this particular subroutine of the software is unknowingly unable to cope with a fuel source interruption of some type since it is faked-out by a frozen FADEC signal sensor and causes the software to stay in it's current state (idle) since it couldn't interpret either corruption in the software load or non-sensical FADEC signal data. While maybe not technically a "rollback" (because we're already at idle,) the result is the same: a temporary loss of engine control.
Refresh my memory here: were the RR and GE development programs a cooperative effort for this class of engine? I can't remember now...
Anybody feel free to comment; I won't bite you today.....
