This is still about modern FADEC. I understand that it’s me going into a bit of a rabbit hole on this one, but I really don’t mind and moreover that’s why I stand to be corrected. The latest rumours are that fuel control switches have been moved. One, admittedly very very rare, option at least to my mind could be that following a s/w update (BP 4.1) induced erroneous TCMA activation on take off (dual fadec but one line command to both engines shut off as per design), the F/C confronted with both engines out and in the absence of any SOP in such a state, were subjected to the only possible action that is to switch the engines fuel valve to cut off and to re engage them in the hope to restart. However, nothing could have saved them at this low starting altitude. In this scenario they were doomed from takeoff.

Not necessarily TURIN If air India 171 was for some extraordinary reason confronted with both engines out on lift off, to switch off fuel levers and to re engage them would be the only way for a restart. For which there wasn’t altitude

Not necessarily - while the engine inputs are unique to the engine, aircraft inputs are common (except for thrust lever position). If there is some particular aircraft input that finds a 'hole' in the software, it'll likely effect both engines in exactly the same way.
After all, we're talking a very serious error in the s/w - if it was known, it wouldn't be there.
There are lots of ways a software error can cause an engine failure - mis scheduling the vanes or bleeds can cause an unrecoverable surge, obviously the FADEC has full control of the fuel metering valve - an error that commands that valve full closed will cause a flameout (and, while auto-relight is basic on all the newer engines, the igniters won't spark at very high burner pressures so the engine needs to spool down quite a bit (especially near sea level) before the igniters can actually function).
That's why the FADEC s/w is exhaustively tested to flight critical status before it gets certified - to prevent just that sort of thing.

Exactly! Despite best intentions, it's extremely difficult to imagine (and more so, to evade) every bad possibility. Have had the same experiences - many of mine (fortunately for me) while testing "it" myself. "Oh Bu99er! Didn't know/realise/recognise/think of THAT!" Sometimes, it's enough to completely eliminate a 'damn good idea'. Not saying that re FADECs of course. But people do get attached to their own beliefs/ideas/experience/egos... Confirmation Bias and all that as well. The human condition. We must never forget Sun Tzu's wisdom. Sadly, a deep study of anything is all too often a means to avoid deep study of self. I can personally vouch for that! And a way to compensate for what one secretly fears. Geeks, anyone? Face the fear!

Never a truer word! Indeed, "You can't prove a negative!"

Being new here, I tried to give this post a "Like" but clicked on the down arrow thinking it was a drop-down menu. Oops. Sorry if I tarnished your reputation. It was a nice explanation, thanks.

Now, does anybody know if a pack was being used to cool the cabin by virtue of the "Ground test enable switch" using two GPUs prior to departure? If that were the case, and if the switch remained in the "Enable" position, would Flight 171 have been able to get airborne? If so, what would FADEC do if, say, N2 bumped the upper limits soon after rotation?
If anybody has covered this potential breadcrumb trail, I missed it and apologize.

As a non pilot but having been an airline passenger for around 45 years I have found this particular thread to be fascinating. Whilst I knew that modern jet flying relied on computers I did not realise the extent to which computers are effectively flying / controlling the plane.

It seems that Pilots have to be both "Pilots" in the true sense and also computer system experts.

Whilst statistically it maybe much safer to fly because of these computer systems it seems to me that when things do go occasionally go wrong it is much more difficult for the Pilot to establish exactly what has in fact gone wrong.

That is a non normal procedure that some crews used to use in the early days of operation, which was a bit naughty because after extended operation in this condition the ground power would be overloaded and trip off. As most of us know, tripped GPUs on a 787 is to be avoided as it will bring up a multitude of spurious faults that will require maintenance action to reset.
When selected the switch enables a status message on EICAS. I doubt very much this would be missed by the crew on their preflight checks.
I've never heard of a takeaway off being attempted with the maintenance enable switch selected on for this reason.

The Air India Flight 171 thread has been reopened. If you are done discussing FADECs please don't try to turn this into that thread.
Or, go back to discussing FADECs as was this thread's intended purpose.

Thank you all in advance.

(I moved a couple of posts, as suggested by TURIN)

That switch wouldn't prevent takeoff, and it would have no effect on the FADECs. It's basically impossible for N2 to reach its limit while at ground level, the engine is pressure-limited. If N2 does approach the overspeed threshold, the FADEC will aggressively cut back fuel to bring it back down. If it reaches the threshold anyway, both channels will immediately command the high-pressure shutoff valve closed. All of that is true regardless of air/ground status.

No kidding? "Regardless of air/ground status"? I was wondering about the ground test switch vs. FADEC because I understand it inhibits the inhibits, so to speak, and therefore might inhibit a safeguard that prevents FADEC from shutting down in the air. So, there's no safeguard against that anyway?

If the N2 goes too far above design speed, one of the high-pressure turbines will burst. That is, it'll fracture into several pieces which will then be ejected from the engine at an unfathomably high speed. They'll punch right through the engine casing, wing, fuselage, and possibly some unfortunate passengers. Even before FADEC, basically all turbine engines had some form of overspeed protection for this reason. The risk of an inadvertent shutdown is outweighed by the catastrophic consequences of a turbine burst.

Here's an example of what happens when a high-pressure turbine bursts. One piece sliced through the belly and ended up embedded in the other engine. Another piece was found half a mile away from the plane. This wasn't caused by an overspeed, but an overspeed scenario would be even worse.

FADEC computing
 

Say a 787 is at or near rotation. All is well when the Flight Deck pulls the switches to CutOff. The FO sees EICAS, as does Captain... "ENG#1CUTOFF" "ENG#2CUTOFF" The FO, quite naturally asks "Why did you CutOff?" The Captain replies "No, I did not..."
Question: forget the Cockpit, what does FADEC "DO"...
Do the engines get CutOff, immediately? Does the a/c perform all auto procedures? Including ReLight, ReStart?
RAT out?

As I understand it, when FADEC gets conflicting data, it pauses (not long) then shuts down the engines, fearing Fire, Birds, OVERBOOST etc. Wrong?
Not including either Ground Mode or Airborne, for now.

I don't think the engine being instructed to shut down by all poles of the cutoff switch constitutes 'conflicting data' - that's an intended operating condition, even if not a common one. Crew shut engines down because of e.g. oil over-temperature from time to time.

The FADECs attempt a relight and restart automatically if the switch is moved back to the run position. They do not attempt to use the starter motor (cross-start or APU assisted start) unless the start switch is also in start.

Going back to basics two engines, each with their own FADECs shut down. We are therefore looking for a single point of failure. The flight recorder noted the binary word for each Run/Cutoff switch "transition" from a Run to a Cutoff condition. This signal is sent to each FADEC, commanding it to close the shutoff valve on its engine's electro-mechanical unit. What was the single point of failure leading to that transition? i noticed that the preliminary report includes a Common Core MEL item. What was this MEL for?

humm. boxing way over my weight here but…
If someone or something moves the fuel valve switches is that a direct connection from switch to fuel valve? Is there then wiring from switch or valve to advise the Fadec of fuel valve position.

It is speculated that in the AI tragedy someone selected the fuel valves to OFF . In normal ops are not engines shut down through the Fadec ( depending on the aircraft ) via the crew moving the throttles to off or moving the switches from RUN back to iIDLE and then to OFF with fuel valve switches being moved to OFF as part of post shut down checks.

I am not being type specific. because Helicopter FADEC setups vary between types and manufacturers and I assume it is the same in airplanes.
However I have never seen a fuel valve which usually cuts off fuel at the firewall controlled via the fadec

The “Flight Deck” cannot select CUTOFF, only a human can do that. As you continue to offer hypotheticals, posit there’s a massive failure of all four poles of BOTH switches resulting in both engines shutting down. The engines wind down, at some point around 55% N2 all generators go offline with no other source of power, the RAT deploys, the APU starts an auto-start sequence using the APU battery. RAT comes online, probably within 2-3 seconds, APU around 60 seconds. Quick Relight would not happen because, in your hypothetical, the ALL four poles of BOTH switches failed in CUTOFF. Or, you could offer the hypothetical that switches failed back to RUN and they quick relight.do you see why this scenario is so ludicrously unlikely?

Yes, GF ludicrously unlikely. I was unclear. More like "what is a single point of failure" that would cause ShutDown other than deselect RUN. As for the pilots, both knew the problem, or at least said they did. Trying to fly in Ground Mode ? If I cannot find six others, I won't come back to pester you.

This is the challenge with the patent system - sufficient disclosure of your idea to make it novel and unique, but as little detail as possible for your competitors to copy. Elon Musk has a different concept - develop your product faster than the competition can keep up. You only have to run faster than the slowest person to escape an attacking lion. As long as they don't catch up, you are fine.

Would you deliberately throw in a few errors in your publicly showing patent documents to throw the competition off the scent, to distract them? Of course. It is commercially prudent to do so. The lawyers and patent examiners are not always up to speed, otherwise they would be out there inventing too! I've been in meetings where this has been 'robustly' discussed, my patent being pulled to bits, and the competing sides arguing about how little to disclose versus how much, to prevent others from stealing the idea, but making it broad enough to protect similar copycat ideas from slipping through later. Technical brilliance vs financial gain - which wins?

All this questioning of redundancy, design, and software, risk control, faulty relays, and the potential of errors reminds me that in the space industry they have seperate teams, completely isolated from each other, given a set of specifications and asked to develop a system, deliberately using different hardware and software to arrive at a working, testef solution. Code in C++, the other team in Ada, and for redundancy, another in FORTRAN or suchlike. They have radiation hardened space rated ICs (chips), deliberately designed to cope with stray 'death rays from outer space'. All these systems running in parallel, using the same inputs but unique software and hardware to process it, have to agree before the coundown is allowed to reach LIFTOFF. If not, you abort. This is why your twin space Voyager 1 and 2 missions (launched in 1977) are still functioning, DECADES past their design life, sending back data, error corrected, and your 737MAX MCAS system now has three AOA sensor inputs, not one, and you are wondering if a company that builds multimillion dollar airframes might not deploy similar design teams? Your flight only goes for a few hours, and you have the same redundancy principles applied. This thread denigrates the dedicated teams that develop, check, submit, certify designs, review them constantly, and revise them, based on industry advancement in technology and research, and investigation of incidents, crashes, and 'near misses' (what a delightful turn of phrase, as it means 'near hits' - the very opposite). Why is it safer to fly around the world than to cross a street? It is because this process of design, review, and modifications has been finely honed to a fine art over a long period of time.

Example: My refrigerator in the back shed, running strongly after all these years, using MECHANICAL technology such as thermostats and relays, still keeps my beer cold, as designed, reliably. Sure, for a mental exercise I have thought about using a digital sensor so I can monitor the temperature of my chilled beer to a thousanth of a degree, and replace the thermostat with a hobby microcomputer like an Arduino or Raspberry Pi, and drive a SSR (solid state relay) to switch the compressor motor so I have zero crossing on the AC to prevent voltage spikes, but then I would have to hook it up to my cell phone and home automation to record it, write software to run it, test it, just to show my friends next time they come around for a BBQ. Why would I fix a design that is simple, reliable, fit for purpose, and stood the test of time?

Pass me another cold beer. I'm off to buy a lottery ticket.

Delightful
 

My last Aero patent went through so much money I had to abandon it. I pitched it to Boeing, haven't heard back.. my beer is 35° ....life is good