Posts about: "FADEC" [Posts: 231 Pages: 12]

There has been another incident of a TCMA equivalent function shutting down both engines. An airBaltic airbus a220 in July 2021 (YL- AAQ) had both PW1500 engines shut down by \x93TCM\x94 logic in the FADEC immediately upon landing.

This seems to have been caused by a mismatch between actual and commanded thrust caused by rapid throttle movement that was \x93saved up\x94 until TCM was subsequently activated by its air/ground logic.

A description can be found on flightglobal but I have too few posts to include a url - So google a220 revised software engine shutdown

TCMA continues to be one of the few (very unlikely) causes of/contributors to simultaneous shutdown of both engines. So far, though, I don't think we've seen a credible scenario explaining the possibility that TCMA was triggered in this accident. I'm not sure I understand your speculation.

In the scenario you are considering, it's clear that the air/ground state would be wrongly "understood" by the TCMA function. But we don't have, AFAIK , a credible theory for how that might happen. Surely it would have to result from either incorrect signals from the relevant sensors or a failure of the related logic in the FADEC TCMA function, or a combination of those. Indeed, I don't think we yet know exactly which sensor readings that logic depends on or how those readings are fed to the FADEC. Does your speculation include any thoughts about this?

Also, the FADEC TCMA function has to "believe" that the engine is operating at high power and not responding to thrust lever operation. In your proposed scenario, is this also a logic failure \x97 in both FADECs? Or false inputs from both TLs? Or are both engines actually operating at higher than commanded power levels?

Or do I misunderstand your post?

Further to the (logical in my view) points you make in response to AAKEE's ostensibly logical conclusion that the commencement of undercarriage retraction (if it did commence) is conclusive of the aircraft being 'in the air' for aircraft systems purposes, including TCMA purposes, I make the following points:

First, whilst it may be that every system that monitors and makes decisions about whether the aircraft is 'in the air' does so on the basis of exactly the same sensor inputs, that may not be true and I'd appreciate someone with the expert knowledge on the 78 to confirm or refute the correctness of the assumption, particularly in relation to, for example, FADEC functions compared with undercarriage control functions.

Secondly and probably more importantly, what happens if one of the sensors being used to determine 'in air' versus 'on ground' gives an erroneous 'on ground' signal after - maybe just seconds after - every one of those sensors has given the 'in air' signal?

Reference was made earlier in this thread to a 'latched' in air FADEC condition that resulted in engine shut downs after the aircraft involved landed and was therefore actually on the ground. But what if some sensor failure had resulted in the aircraft systems believing that the aircraft was now on the ground when it was not? I also note that after the 2009 B737-800 incident at Schiphol – actually 1.5 kms away, where the aircraft crashed in a field during approach - the investigation ascertained that a RADALT system suddenly sent an erroneous minus 8’ height reading to the automatic throttle control system.

The conceptual description of the TCMA says that the channels monitor the “position of thrust lever” – no surprises there – “engine power level” – no surprises there – and “several other digital inputs via digital ARINC data buses”.

WoW should of course be one of those "digital inputs" and be a 1 or 0. But I haven't seen any authoritative post about whether the change in state on the 78 requires only one sensor to signal WoW or if, as is more likely, there are (at least) two sensors – one on each MLG leg – both of which have to be ‘weight off’ before a weight off wheels state signal is sent. Maybe a sensor on each leg sends inputs to the ARINC data and the systems reading the data decide what to do about the different WoW signals, as between 00, 01, 10 and 11.

There is authoritative information to the effect that RADALT is also one of the “digital inputs” to the TCMA. The RADALTs presumably output height data (that is of course variable with height) and I don’t know whether the RADALT hardware involved has a separate 1 or 0 output that says that, so far as the RADALT is concerned, the aircraft to which it is strapped is, in fact, ‘in the air’ at ‘some’ height, with the actual height being so high as to be irrelevant to the systems using that input (if that input is in fact generated and there are, in fact, systems that use that 1 or 0).

If we now consider the ‘worst case scenario will be preferred’ concept that apparently applies to the TCMA design so as to achieve redundancy, the number of sensor inputs it’s monitoring to decide whether, and can change its decision whether, the aircraft is on the ground, becomes a very important matter. The TCMA is only supposed to save the day on the ground, if the pilots select idle thrust on a rejected take off but one or both of the engines fail to respond. In the ‘worst case’ (in my view) scenario, both TCMA channels on both engines will be monitoring/affected by every WoW sensor output and every RADALT output data and, if any one of them says ‘on ground’, that will result in both engines’ TCMAs being enabled to command fuel shut off, even though the aircraft may, in fact, be in the air.

Of course it’s true that the TCMA’s being enabled is not, of itself, sufficient to cause fuel cut off to an engine. That depends on a further glitch or failure in the system or software monitoring engine power and thrust lever position, or an actual ‘too much thrust compared to thrust lever position’ situation. But I can’t see why, on balance, it’s prudent to increase the albeit extraordinarily remote risk of an ‘in air’ TCMA commanded engine or double engine shut down due to multiple sensor failure – just one in-air / on-ground sensor and one of either the thrust lever sensor/s or engine power sensor/s – or, in the case of an actual in air ‘too much thrust compared to thrust lever position situation’, why that ‘problem’ could not be handled by the crew shutting down the engine when the crew decides it’s necessary. Once in the air, too much thrust than desired is a much better problem to have than no thrust. The latter is precisely what would happen if all ‘on ground / in air’ sensors were functioning properly and some ‘too much thrust’ condition occurred.

Hopefully the design processes, and particularly the DO-178B/C software design processes done by people with much bigger brains than mine, have built in enough sanity checking and error checking into the system, followed by exhaustive testing, so as to render my thoughts on the subject academic.

Let me try and summarise one possible scenario and then link in some of the better posts provide evidence relating to it:

• In error, PF reduces power to idle and/or reverse at a speed after V1 (either deciding to reject, or for some unexplained reason e.g. the recent BA incident at LGW)
• Decision is changed to continue take-off, thrust levers moved to TOGA
• Let's say the thrust inputs are similar to NM985 and TCMA is triggered; and engines shut down around the time of rotation
• A/C rotates achieving a maximum speed in the region of 184kts

Relevant "ruling out" questions, with links to posts that add new information:

Q: Would the a/c have enough kinetic energy a 184kts to climb to 100-150ft agl and then reach its final position if the engines had failed at, or just, before rotation?
A: Theoretically possible - see calculation here . NB, the a/c actually flew 1.5km from the end of the runway and 2.3km from the likely point of rotation.

Q: Doesn't the forward position of the gear mean that power failed after the pilots had selected gear up?
A: Inconclusive - had hydraulic power had been lost prior to rotation, the gear could also be in this position - explanation here

Q: If the throttle levers were brought to idle during take-off, would the A/C have applied autobrake, reversers and speedbrake?
A: Yes, although there is a built in delay before reverser and speedbrake actually deploy - see here .

Q: Is the ADS-B data consistent with this scenario?
A: Yes, e.g. the Flightradar data shows the aircraft decelerating rapidly (12 knots in 4.2 seconds) from close to rotation. However, it's not clear how accurate this data is. For one, the altitude data is +/- 25 feet, second, while I was under the impression FR would have received airspeed data from the a/c sensors, this post suggests maybe not.

Q: Does TCMA activation require the thrust levers to be at idle or does it function when the thrust levels are above idle, but where the actual thrust is above that commanded?
A: No, the latter is true (i.e. idle is not required) - confirmed here - there are of course many protections against false activation

Q. Did AI171 have the same software version / logic paths as NH-985
A. Unknown. That a/c had Trent 1000s so to some extent the software is different, but we understand the TCMA logic is broadly the same regardless of engine. I have not seen a post clarifying whether the TCMA software has been updated /changed via SB since 2019 to account for this incident.

Be grateful if posters could refrain from speculative responses "e.g. I think this is unlikely because I feel x". I am not opining on how likely this sequence of events is, simply trying to summarise whether or not this theory has been ruled in or out.

I also recommend this post for a summary to read before posting. .

This has been setting a bit wrong with me for the entirety of the thread. When people say "software" they have an image in their head, and in this case the image is rather unhelpful if not outright wrong.
When we say "Software" we mean things like this:
This is the type of software we are usually subject to in our everyday lives basically everywhere. Your phone, your fridge, your oven, your water heater, your car, etc. pp. ad nauseam.

In case of the Safran FADEC 3 this is not actually what we're dealing with. It uses something called an FPGA (Field Programmable Gate Array) which is a very different beast to what we are used to dealing with.

In a normal computer we simply translate code like above into something less human readable but instead interpretable by a microchip or the like. This "machine code" is then run sequentially and does whatever it is meant to do (hopefully). If we were to expand our little happy check above with another condition then our computer would sequentially check these conditions. This opens up a lot of hoopla about timing, especially when interacting with the real world.

Let's say you want to track N1 and N2 in an engine. You'd have to make a measurement, that value would have to go through an AD converter, which writes it to some (likely volatile) storage, where it is then accessed by some sort of (C)PU, transferred to yet another piece of volatile memory and then used in the computation. This takes time because you can't do those things within the same clock cycle.

Unsurprisingly this is rather inconvenient when dealing with the real world and especially when dealing with volatile physical processes that need monitoring. Like a modern turbine engine.

Enter the FPGA.

While it is programmable what that actually means is that (at a very high level) you can build a thing called a truth table, that means a definitive mathematical mapping of input states to output states. Unlike our sequential CPU driven system an FPGA will be able to perform its entire logic every time it is asked to do so. We don't have to wait for our happy check to perform any other check.

This is very useful for our Turbine Engine, because now we can verify that N2 is smaller than X without delaying our check that the Throttle Control Lever setting is within acceptable distance to N1 and N2, while also creating the appropriate output for all the different bypasses and bleed valves in a modern engine, and so on. The Safran FADEC 3 does this "up to 70 times per second" as per the vendor.

In order to be manageable the actual FADEC consists of multiple different pieces, many of which are FPGAs. At least two are used for so called "input conditioning". This is where we deal with converting messy real world values from sensors subject to real physics into nice and clean numbers. Here our values from the Throttle Control Levers come in, the signal from our N1 and N2 sensors, WOW signal, and on, and on, and on.

This is then changed into logic level signals provided to a different set of FPGAs. Lacking an actual schematic I suspect that this is what sometimes is referred to as "channels". The channel could consist of both a signal conditioning stage and then a logic stage or (more likely) redundant signal conditioning stages feed separately into separate FPGA "channels" are evaluated and then the end result is likely put into yet another FPGA for control output generation.

Why is this important?

Because it is basically impossible for a "bug" to exist in this system. These systems are the epitome of a dumb computer. They do _precisely_ what they are meant to do. The TCMA is simply a set of conditions evaluated just like any other condition in those FPGAs. If there is an "error" then it is in the requirements that lead to the truth table used by these devices but never in the truth table itself. In fact these types of computation device are used precisely because of that very property.

So when people say "the FADEC software" (ie TCMA) has "failed" or "has a bug" what they're really saying is: A bit of a mouth full, granted, but an important mouth full. This simply wouldn't be someone missing a semicolon somewhere in a thousand lines of code.

Regards,
Justus

Can you provide a source for this? I ask because when I look for info about FADECs generally and FADEC 3 more specifically, I find this kind of documentation (notice the mention of FADECs in the lower left corner):



... which is part of a larger Powerpoint presentation by Ansys , explaining that these products are developed with SCADE development workbench, generating either Ada or C code, and that the resulting code runs under a microkernel realtime operating system:



Now, obviously enough, a CPU can be embedded in an application-specific FPGA, but it would still execute machine code. And from my experience in other embedded systems development, current CISC or RISC CPUs have more than enough computation power to implement command and control on a modern turbofan.

Whilst you\x92re right to highlight the type of software in a FADEC, it should also be recalled that after the dual uncommanded engine shutdown event on the Baltic CS300, the FAA mandated updated FADEC software for all of a family of P&W engines. FADEC s/w can contain what we\x92d call bugs (whether they\x92re mistakes of coding or mistakes of logic in the design assumptions).

"it is basically impossible for a "bug" to exist in this system." This is not my experience.There are a lot of bugs in hardware and FPGAs. The guys doing this are real experts and bugs are less common than in software. But they do exist and they can be difficult to reproduce and subtle to diagnose. For someone new to FPGA it can be very intimidating because everything is parallel. It requires a different way of thinking. You can execute 1000 instructions simultaneously.Then various tricks to speed things up or reduce glitches add complexity. For example you may want to count in gray code or one hot instead of binary. Writing bug free FPGA code is very challenging. We cannot assume the FPGA code is free of bugs.

I will just comment here that FPGAs contain many logic blocks which have around them routing channels which allow these logic blocks to be connected up in various ways, some of the logic is asynchronous, some of it is synchronous and thus uses clock signals to advance the state of the logic according to a combination on input signals, asynchronous logic outputs and signals fed back from other logic blocks.

All of this is created by writing software using something like VHDL (VHSIC Hardware Description Language where VHSIC stands for Very High Speed Integrated Circuit) with the output of the compiler for this software being an object file that contains the connection information for the on-FPGA routing. However, this process requires careful simulation, not just of the logical behaviour of the FPGA being designed but also of the ability of the programmable routing on the FPGA to get the required signals to where they are required with the necessary set-up delays so that the next clock edge does not allow a glitch where a signal changes state during the period when it must be static so that it propagates correctly through the logic blocks. With clock signals that form a clock tree across the device the skew on the clock signals must be carefully checked so that the lowest skew requirements are always met, there may be more margin for the less critical parts of the system.

Now, I am sure that the state of the art has moved on a lot since I was heavily involved in this sort of engineering but I can say that when my colleagues were prototyping ASICs (which are application specific devices that are not programmable like an FPGA) using FPGAs because it can be reprogrammed to cure bugs found in the code that created it I am absolutely sure that it is possible for a latent bug to exist in what has been built despite extensive testing being carried out. I well remember sitting down with an FPGA designer and a software engineer and showing them a situation where one of my radio devices was not being commanded to transmit, they refused to believe me until we captured their output signals in the failed state and I was thus able to prove to them that it was their logic and code that was failing and that my radio system was fully working except it couldn't possibly transmit when its enable line was inactive.

I would therefore never state that an FPGA-based FADEC is infallible. The devil will be in the detail of the functions contained within the devices and how they interact with each other and how the original logical functions are described and specified and then coded and checked for logical errors before getting on to the actual physical reality of the FPGA manufacturer's design and development system that bolts on to the back of the source code. If the FPGA devices are being pushed anywhere near the edge of their performance envelope, just like an aircraft things can go wrong. If a design begins with a device that is only just large enough in terms of how many logic blocks and routing channels are available for the logic required it's almost a certainty that development will take it to this area of its performance and a lot of tweaking may be needed which means that even more testing will be needed to be reasonable sure that it does what it is supposed to.

I don't think ‘worst case scenario will be preferred’ is the philosophy they use. The way tdracer explained it, there can't be any single failure that leads to uncommanded high thrust on the ground. Presumably, each FADEC channel is treated as a single 'fault isolation area.' That's why the inactive channel has to be able to effect a shutdown in case the active channel causes a runaway.

For the sake of argument, imagine if every air/ground sensor had to say 'ground' to enable TCMA. That should still meet the 'no single failure' requirement since you'd need at least 2 failures to get a runaway engine: the original thrust control problem, and a faulty air/ground sensor.

IIRC, he said that the 747-8 looks at weight on wheels, gear truck tilt, and radio altimeters. At least one of each has to say 'ground' for TCMA to be enabled.

Sadly I'm unable to post links or I would have done so in my original post.

First off I should note that what I wrote is a massive oversimplification. I'd expect that neat metal box with the nice rugged connectors that Safran shows on their homepage to contain an ungodly mess of microcontrollers, ICs for signal conditioning, the FPGAs I mentioned and components that are well beyond my understanding of electronics. But from personal experience with a certain aircraft related company operating in Munich I can tell you that marketing level slides like you showed are so far removed from the technical reality that they might as well be fan-fic.

I agree with your observation that current microcontrollers are more than capable enough of dealing with these types of real time computation, but keep in mind that the Boeing 787, and thus its FADEC, had its first flight in 2009. Back then I would be rather more careful with that statement. Mostly because I would have just started my Computer Science Degree at the time XD

But maybe I should explain how I've arrived at the post above. I've basically spent the past few days on and off scavenging anything I could find on the 787 FADEC specifically. It was mentioned in this thread or the old one that the 787 uses the Safran FADEC 3, so my primary jumping off point was the Safran website and the information available on it. That plus a couple of press releases namely by Actel about their flash-based ProASIC3 and ProASICPLUS FPGAs was the evidence I used to arrive at my conclusions above. I can't for the life of me find the quote about the dual signal conditioning FPGAs anymore, but they are in there as far as I can tell.
Overall information on the actual inner workings of these things are so sparse that outside of a few patents (keyword: configurable CPU) I was hard pressed to find anything at all to be honest. This all not being helped by me now finding references to my own post, thus having created my very own Woozle. Hooray.

I have only looked into the Safran FADEC 3 used on the 787 with the GEnx-1B engine. The system was very innovative for its time and uses technology not previously used on FADECs to my knowledge. Even saying that, this could be one of those "technically true" kind of statements. My intention was to highlight that due to the totality of the processes and architectural style of these types of computational device the typical kind of "software error" or "bug" was basically impossible and that we'd be looking at something way further back with implications for the base requirements. I merely want to correct the implied misconceptions about the "software" being used here. As I said, FPGAs are just very different kinds of beasts.

I half agree and half disagree. Obviously I shouldn't have stated an absolute because, yes, it is possible despite multiple layers of engineering coordination that an error occurs at one step or another and is not caught by the multiple layers of checking. My point is that even in normal development FPGAs are well known to be bug resistant due to the way they are programmed. In general we create the logic condition tables using software which then translates our table into an actual FPGA configuration. This process is obviously not immune to faults but highly resistant and most importantly: Can easily be simulated.
Now, in normal "everyday" usecases I'd fully agree with you, but in case of the FADEC we're talking about an FPGA with logic condition tables where every line is likely to have its own separate binder of engineering notes, discussions and recommendations. It is there where any "error" or "bug" is most likely to reside by a considerable margin.

They were, and continue to be, a valid and reliable technology for this type of application especially before the extreme proliferation of consumer microelectronics in the last 20 years. The Safran FADEC 3 was designed at basically the same time as the first iPhone. And boy do I feel old now.

I realize that my post is a massive simplification of the topic, considering the intricate details that are simply unknown to the general public in a system as complex as a FADEC I certainly agree that things can go wrong. What I wanted to point out is the reliability of the last steps versus the design and requirements engineering phase. In general software development bugs will happen at any stage with basically equal likelihood. Given the way the standard processes around FPGA development alone would influence this probability towards the design and requirements engineering stage and then combining it with how it is handled in the Aerospace Sector I felt it was justifiable to state the extreme mismatch in probabilities of error the way I did. With the system being in operation for this length of time I do still feel comfortable with my original statement although I would now decorate it with a little * for the reasons mentioned by you and others.

In the end I hope it was useful for understanding where the reluctance of apportioning blame to these systems originates and ​​​​at the same time talk about some pretty nifty tech that I know few Software Engineers will ever deal with in their entire career. I do still find the idea of a fault (with the understanding above of where that fault originates) in the FADEC a convincing possibility, it's merely the nature and location of that fault that I felt could benefit from some more specifics in regards to the nature of how they were most likely to actually happen. I would love to actually hear more about how the FADEC 3 is structured internally and which components it uses, but I suspect that those who know are under NDA.

Regards,
Justus

Why should it? It\x92s part of the FADEC as are the TLA sensors.

Found It
Truth Table Line 101 = Service Terminated (licence agreement expired please contact your service provider)

I read the whole threads, keeping my hands on the mousewheel so far since I'm not a pilot, just a EE / safety / systems engineer.
The hamsterwheel ist spinning a lot here, and of course it could be anything including some VHDL FPGA code line or a broken RAM cell in a cheap memory bar within the computer it was compiled with. Anything is possible, but to be honest: development processes, if followed, are usually pushing the probability to a level where it becomes pure theory. BOSCH uses FPGA+\xb5C on the brake control box of cars. They sold 100 millions of those, used 4000h each (car lifetime) without error, with less strict development process. Most errors are made on requirement level, not code.

Also, so far there is no evidence I've seen regarding the 'chicken-egg' problem, did the engines fall below idle (fuel, stall...) and this caused an electrical blackout (-> battery, RAT...) or did an EE problem cause the engines to reduce thrust (FADEC, SW bug...). And where is the common cause in all this?
There has to be a systematic error common to both engines, an external failure affecting both or a dependent fault with one affecting the other within seconds. This is the only thing I think everyone agrees here. And I refuse to beleave the external failure or dependent fault was sitting in the cockpit.
I think it is something not common to every aircraft type for the last 50 years.
So I started searching and found a candidate.

I read myself into the EE architecture of this unique 'bleed-less' design and it's megawatt powergrid since this is the part where I may be able to contribute (and I'm most curious about). Generators on the 787 are >250kW instead of <100kW each and there are two per engine instead of just one. In fact, they can go up to 516 kW and shear off the gearbox at >2200Nm (equal to >2 MW, per generator).
https://www.easa.europa.eu/en/downloads/7641/en (page 11)
So while on any other aircraft the generator is more like the dynamo on your bicycle, those generators are massive (x10).
The gearbox is connected to the HP shaft (N2) on the GEnx. I learned from Wikipedia that RR moved this gearbox to the IP shaft on the Trend 1000. And RR is happy that the A330neo Trend 7000 uses bleed air and less load on the gearbox, since this maintains stability on the HP shaft at light load (also Wikipedia).
Those generators are not in phase and frequency sync, or in other words: If you parallel them, they fight each other, it's like a short. They will almost block if this is not handled by the control box if possible (or some melting fuse blows at some point).
787 electrical system - variable frequency generators?
Somehow I find it hard to believe that they are not able to disturb the engines despite that everyone here so far is claiming that there is no way an electrical problem could influence them because FADEC has it's own supply. I read that one is sufficent to start the engine, usually both are used.
In my mind I find lot's of ways this could influence both engines simultanously. If just the BTBs on the 230V grid got some humidity (hot, no AC, water cooling...) and went up in one big arc (I think they made them semiconductor relays, too).
Could those gearboxes and engines handle 4500Nm / almost 5 MW on each HP shaft, applied within a fraction of a second without any problem?
Or if the engines were in a condition not far from compressor stall, one was stalling and 400kW load jumped from one engines generators to the other...
I did some rough estimation and one of the generators could push N2 below idle in a second or less without fuel just with its normal 250kW load (just inertia).
This is one point which is unique to this airplane model, so maybe worth a closer look.

I know that those engines are burning at >100MW at full power, but how fragile in the balance between compressor load and this one turbine stage on the HP shaft / N2, without the inertia of a 2.8 meter fan? This is just out of my background, any thermodynamic expert here?
Of course I also have no insight in SW and communication within the control boxes, how much they are talking to each other, delaying/ramping load redistribution etc. If FADEC recognizes a flameout, could it instantly command the generators to cut the load, even above idle rpm?

I would assume that some fuel contamination, valve blockade, even compressor stall would pop up slower. But such a generator could kick in within milliseconds.

As a safety guy I learned that one tends to look first at things one is familiar with (SW, HW, mechanics, pilot behaviour, maintainance, depending on one's profession) and in the end it's often the interface and dependent faults within which are not carefully considered (e.g. takeoff situation vs. thermodynamics vs. mechanics vs. power generation vs. humidity vs. generator control...) together with transient behaviour. It was the same with MCAS (safety culture vs. pilot training vs. SW design (repeated action) vs. single AOA input vs. bird strike probability close to ground vs. trim loading/blockade vs. stickshaker noise/distraction).
In fact, I was trying to find information on all those systems and directly found slides on how the engines and generators could be simulated and the power grid tested in a HIL (hardware in the loop) environment. My experience from automotive is that such simulated environments are often far from reality and HIL environment programming finished after the product is already at the customer. But of course its far easier and cheaper to apply and test faults there. But then, some programmer programms what he thinks the reaction of the engine would be.
This 'bleed-less' design was some massive change in airplane EE architecture with hugh consequences on the whole airplane design and extremely hard to fully analyze.

I'm just asking questions and hope that we all learn a lot and this was fully considered or just not an issue. It's just an aspect I found worth mentioning and not only spinning the wheel.

PS: I doubt it was TCMA. The air/ground decision is done in a different box, evaluating 5 inputs in a 1/3 and 1/2 decision according to this discussion. This is then safely sent to the FADEC (as one input) and combined with the thrust lever position and N2. But if the thrust lever position is sensed (redundant and direct) close to idle, you do not need TCMA or ground mode to expect reduced thrust.

Journos, when it comes to aviation, are morons. Kind of like my social skills, in my twenties, after a few more pints than I ought to have had.
That is what you are missing.
We thank you for the source of innocent merriment.
While I enjoyed your post, a lot, 787 has been in service for over a decade and there are over 1,000 of them doing their duty day in and day out. Yes, battery issues arose, but resolved.

Based on the mishap investigations I did, more than one of which involved fatalities, there is a whole family of maintenance / company culture errors possible that seem to me to get short shrift in the discussion here: thread number 1 and thread number 2.

But here's the problem: Air India, for very understandable reasons, isn't about to open the kimono until they are forced to.

Re the SAFRAN FADEC Gen 3 : It was used on the CFM56-5B and -7B and some CF6s amongst others. Unless those engines were re-FADECed later (seems unlikely), the FADEC dates to at least the early 90s.
Safran has some pictures that looks suitably early-90s high tech:




(I wouldn't be too certain that the second image shown is this generation FADEC, as it's also shown on the Gen 4 (LEAP) FADEC page).
(I recognise that soldering iron... Metcal makes good stuff).

There is some limited detail on the air/ground system here . It shows two truck tilt and two strut compression sensors on each of the two MLGs, 8 sensors total. Truck tilt sensors give 'fast' A/G detection; truck tilt + struts gives 'slow' A/G detection. Two systems but no mention of exactly how voting works. No mention of radalt but that could be handled separately before being provided to the FADECs.

I am also now thoroughly satisfied that the FADECs have their own alternators, and that these are separate to the flight control alternators integrated into each VFSG.

During a post-flight inspection, engineering discovered that all four engine fan cowl static ports on the 787-9 aircraft were covered with tape. This oversight, which occurred despite the aircraft's flight being uneventful, reduced redundancy in the engine electronic control system. Assuming here that only one engine was affected by taping.
https://www.atsb.gov.au/media/news-i...d-static-ports
"While the flight was uneventful, the covered ports meant that redundancy for the engine electronic control system was reduced;"

Not sure whether this aspect has been covered in respect of the Air India accident? Obviously did not adversely affect or alarm this QANTAS 787 freighter flight to the USA. If it had been a passenger-carrier, would the pax have noticed?
However the pitot obstruction/covers and static port taped/NZ A320 not taped (for a high-pressure hose wash) did kill many in past crashes.
A Lufthansa 777 Freighter's Static port left disconnected from its ADM nearly did. AoA damage by ramp vehicles have also killed many (Abidjan A310-300): Kenya Airways Flight 431 stick-shaker on rotate.
Any port in icing, a dust- or a rain-storm can become a portal to Paradise. Water ingested/sucked into a static system once gave me a very interesting ride/recovery challenge once above FZLvl in total IMC.
For maintainers, it's the ImPORTance of being earnest. Per the photo at the link above, what is a "barricade tape?"

Was there a follow-up "probe"? This raises a few flags. Blanks are everywhere on an aircraft parked for a few days or weeks. You need to develop a "blank stare". We'd have to assume that the ATSB pulled and reviewed the QF 787 recorders to ascertain the effect upon critical engine data. Yet maybe not? Doing so would have grounded the next freighter flight ex the US. But were they (later in OZ) able to post-flight compare the two engines comparative take-off and enroute/approach data? If not/why not? - and if so, what may they have found? Did the engines report anything of consequence via ACARS enroute? Are those engine cowl ports critical in any operational respects? IS/Was the tape used intentionally porous? Two totally different types of tape were used on the QF787.
Perhaps of greater significance: Are the various I/O plugs and ports (that festoon the EEC) prone to a mis-connect/disconnect?. I would imagine that an ECAM/EICAS would raise a red flag on some/most? Would a poorly-made connection or a duff-plug on an EEC severely affect its arcane functionalities and outputs?
Could the Air India event indicate yet another format outcome of pitot/static input error blight with the EEC. I'm sure that it must have those inputs. Like any port or orifice on an airplane, I'm sure that the EEC's sensors could well be partially or wholly internally obstructed. I've not heard of any such incident on another type being sheeted home to such an intrusion.

Covered at:
Dreamliner preflight error, ground and tech crew?

"The engine electronic control (EEC) uses the ambient air pressure data from the ADRS for engine control algorithms, engine thrust calculations and to optimize engine performance. The fan cowl static port air pressure data is only used when an EEC determines that the ADRS data is unreliable. Where no ambient pressure data is available, the EEC assigns a failsafe mode for continued engine operation."

"It would have set numerous FADEC maintenance faults and the "L/R ENG CONTROL" EICAS messages. However the ENG CONTROL messages are inhibited above 80 knots, so the crew would not have seen them until they landed, and we don't expect the flight crew to check CMC faults (I don't think there is anything that would prevent it, but unlikely there would be any reason for them to look).
Engine operation may have been a bit 'abnormal' - not up-to -speed on the Trent 1000 Air Data Logic, but the general rule is if both engine sensors agree but disagree with aircraft, the system defaults to the engine sensors to protect engine-to-engine isolation. Of course when engine sensed Pamb became greater than the P total, it likely would have faulted everything and gone to some default failsafe value."

HPSOVs within the FADEC are solenoid controlled but hydraulic (fuel) actuated. The valve will remain in the last commanded position if power is lost. This is very unlikely as FADECs have a small gearbox driven generator that supplies basic electrical power and engine speed info for engine control and command functions.

LPSOVs are motor driven sliding gate valves 28V DC from a hot battery bus.

SLF Engineer (electrical - not aerospace) so no special knowledge

Perceived wisdom may be applicable in normal circumstances but not when all the holes line up.

For example I've seen it quoted many times that the engine FADECs are self powered
by the engines, the TCMAs-whether part of the FADEC or a separate unit, similarly self contained
within the engine. The perceived wisdom seems to be that there is no common single fault
which can take out both engines.

And yet we're also told that the TCMA function can only function in ground mode and receives ground-air
signals from a combination of inputs from Rad Alts and WOW sensors.
There is therefore a connection from the central EE bay to the engine.

Yes I'm sure the Rad/Alt and WOW sensor processing will use different sensors for each side and powered from different
low voltage buses.
However as an analogy, in your house your toaster in the kitchen may be on a separate circuit from the water heater in
the bathroom, each protected by a fuse at the main switchboard. In normal operation a fault in one cannot affect the other.
However a lightning strike outside the house can send much higher voltages than normal operation throughout the entire
system and trash every electrical appliance not physically disconnected at the time.

Now I'm not suggesting the aircraft was hit by lightning but FDR has proposed a single event, buildup from a water leak entering
one of the EE bays at rotate. It would be possible for one or more of the HV electrical buses to short so that all the low voltage
buses go high voltage. I have no knowledge of how the FADEC / TCMA systems connect to or process the Ground-Air signals but
there is a single fault mechanism whereby high voltage could be simultaneously and inappropriately applied to both engine control systems.
It would be unfortunate if this failure mechanism did cause power to be applied to drive the fuel shut off valve closed.

Since the likelihood is that we're looking at a low probability event then perceived wisdom about normal operations and fault modes
might not be applicable.

The equipment on RAT/battery is limited:


(from the online 2010 FCOM)


(from the maintenance training )

The 787 battery fire report says the two recorders are on the left and right 28VDC buses. I don't think those get powered on RAT by the looks of it. I would wager you get whatever is on the 235VAC 'backup bus', plus the captain's and F/O's instrument buses via C1/C2 TRUs. You won't get all of that (like the F/O's screens) because the 787 energises/de-energises specific bits of equipment, not just whole buses.

Losing recorder power looks entirely expected.


400VAC/540VDC (+-270V) is not really known for blowing past input protection in the same way as actual HV or lightning. I would expect some optocouplers and/or transformers to be both present and adequate. There's definitely some big MOVs scattered around the main 235VAC buses.

Weight on wheels appears to go into data concentrators that go into the common core system (i.e. data network).

Presumably there is a set of comms buses between the FADECs and the CCS to allow all the pretty indicators and EICAS alerts in the cockpit to work. The WoW sensors might flow back via that, or via dedicated digital inputs from whatever the reverse of a data concentrator is called (surely they have need for field actuators other than big motors?). Either way, left and right engine data should come from completely different computers, that are in the fwd e/e bay (or concentrators/repeaters in the wings, maybe) rather than in with the big power stuff in the aft e/e bay.