Posts by user "Furr" [Posts: 5 Total up-votes: 13 Pages: 1]

Originally Posted by appruser

IMO

In the CCTV video, the aircraft stops climbing at 00:28. 3 seconds after, it starts visibly descending. At peak altitude, using the 197ft wingspan as a measure, the altitude is around 200ft or below. The fireball is at 00:48, 17s after descent starts visibly.

Per google maps and the impact location mapped at avherald, the impact point is ~3990ft from the airport boundary road and about 4200ft from the midpoint of the runway threshold and the airport boundary road.

16:1 to 25:1 is what I could find for the 787 glide ratio range (unpowered) with main landing gear down and flaps 5. So the aircraft could cover 16 to 25 ft horizontally for every 1 ft of descent.

With a starting altitude of 200ft, that would imply it could have covered 3200ft.to 5000ft during unpowered descent.

The actual distance covered, around 4000ft, certainly seems to suggest that the descent was unpowered.

Originally Posted by soarbum

Engineer not a pilot. Experience in analog front ends, A2D and R2D conversion and embedded systems generally but no specific knowledge of the 787 or GEnx.



Thanks to tdracer's explanation on TMCA (albeit 747 not 787), we know that TMCA is a logic block within the FADEC whose only external inputs are a logic signal fron the aircraft that indicates whether it is on the ground or not and throttle position as determined by two independent resolvers per throttle side.

The logic would seem to be something of the form
If (G AND (N2>A OR N2>B)) Then CutOffFuel()
where G is true when the aircraft is on the ground,
A is an envelope defined by throttle resolver channel A and
B is an envelope defined by throttle resolver channel B

Originally Posted by JustusW

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