Posts by user "Feathers McGraw" [Posts: 22 Total up-votes: 0 Pages: 2]

Feathers McGraw
June 16, 2025, 22:33:00 GMT
permalink
Post: 11903844
I'd like to mention something that, while unrelated, does shed a bit of light on how computerised systems can misinterpret input data and take the wrong action. I spent 40 odd years as an electronics engineer involving complex systems, it can be surprising just how careful one must be in systems that sample data and then process it for decision making in software.

On August 9th 2019, there was a significant grid failure in the UK leading to load shedding (removing supply to many consumers, including Newcastle Airport) which started when a series of several lightning strikes in Hertfordshire caused a trip out of generators at Little Barford combined-cycle gas turbine generation plant. This was followed by the shut down of the power concentrator and grid connector from the Hornsea1 off-shore wind farm, significant changes in the grid frequency away from the acceptable limits which is what triggered further load shedding.

The reason I mention it is that Hornsea1 going off line was due to the software that operated the concentrator/connector sensing large voltage transients due to the lightning strikes 120 miles away, however these transients were only of the order of 10us length spikes with nominal 20ms cycles at 50Hz on the grid. In old reliable grid equipment that had been in use for decades such spikes would have been ignored because the large rotating machine inertia would make them irrelevant. Other systems went into various states of shut down for protection reasons, some of the Siemens Class 700 trains had to be reset by the train crew, others required a Siemens engineer to drive to each train and reload its firmware. The train protection mode occurred because the grid frequency on the 25kV AC supply went below 49.8Hz, this was a programmed default and it turned out to have been a very conservative one, the trains could have continued to operate normally at even lower frequencies but someone decided to write the programs without actually testing what a sensible limit was. The whole very widespread problems this caused could have been avoided by not acting instantly on microsecond transients in a 50Hz system.

Is it possible that the monitoring systems on a Boeing 787 also sample the electrical system voltages and currents at a relatively high frequency, and thus in the event of a transient of some type perhaps over-react to this event by taking precipitate action instead of waiting a short time before re-sampling again. I have seen a suggestion that an alternative explanation for the "bang" heard by the survivor in seat 11A might have been the sound of a Bus Tie Contactor closing, which in itself suggests something quite important relating to the electrical system. The 787 is unusual in that it uses variable frequency AC generators whose outputs are rectified and then inverted to other AC voltages and also quite high DC voltages, some in the 250-300V region.

I hope that some hard information is going to come out from the investigators soon, but given that the flap mis-selection idea is effectively debunked and we know that the main undercarriage either started its retraction cycle with bogies tilting forwards or that falling hydraulic pressure caused the same thing to happen, then the only thing that fits the observed flight path is loss of thrust on both engines which could have either preceded or followed an electrical failure. We also know that the RAT deployed and in the relatively undamaged tail cone the APU inlet was open or opening indicating a likely auto-start of the APU due to the parameters to trigger that occurring.

I would like to know how many tests of the electrical/computer interactions in 787 development involved arcing/shorting voltage/current transient testing. Is this the sort of thing that is done at all? The EECs (FADECs) in the engines are self-powered via magnetos and self-controlling in many circumstances, but perhaps something caused them to think that the thrust levers had been retarded, and such a thing might have been down to the effect of electrical transients on the various signals received by the EECs.

I have read the original 65+ pages of the thread, but I have not seen any discussion of this particular idea. Maybe that is because the 787 is quite a significant departure from Boeing's previous design practices with totally different electrical systems, higher pressure hydraulics and no doubt other aspects as well.

What do you all think?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): APU  Electrical Failure  Generators/Alternators  Hydraulic Failure (All)  Parameters  RAT (All)  RAT (Deployment)

Feathers McGraw
June 17, 2025, 10:31:00 GMT
permalink
Post: 11904184
Presumably they must also supply that information to the FDR at least, but I don't know how.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): FDR

Feathers McGraw
June 19, 2025, 15:02:00 GMT
permalink
Post: 11906093
The more important recorder, from under the flight deck which probably has better cockpit voice data, is highly likely to be much more damaged.

This is in reply to EDLB

Subjects: None

Feathers McGraw
June 20, 2025, 12:03:00 GMT
permalink
Post: 11906898
VT-ANB flew DEL-AMD, approximately 1hr 15 minutes, before its fatal departure from AMD.

Does anyone know if fuel was added at AMD or was the total fuel required to LGW already aboard on departure from DEL?

Subjects: None

Feathers McGraw
June 20, 2025, 13:01:00 GMT
permalink
Post: 11906962
Originally Posted by Roo
Unlikely to have tankered in fuel & even if they did they would still have had to uplift more. It would be normal to load the onward fuel in AMD having only flown in with what they needed for the short sector.. Would most likely have departed DEL with wing tank fuel only and an empty centre tank. I wont speculate here but I do wonder what works might have occurred in the 8 hour stop in DEL.
I don't disagree, but I wondered if there could be a plausible reason for filling up at DEL. I am sure the investigation will consider all fuel sources used by VT-ANB in the last day or perhaps more of its operation. Not that I am pointing the finger at fuel problems, I just don't know that's all.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Centre Tank

Feathers McGraw
June 21, 2025, 13:50:00 GMT
permalink
Post: 11907772
Originally Posted by Crossky
Hello, this is my first post on pprune; as a 787 pilot I’m also puzzled by this accident. All seem to agree that for some reason there was a complete electrical failure and RAT deployment. With a complete electrical failure all six main fuel pumps fail. Each engine also has two mechanically driven fuel pumps. On takeoff, if there is fuel in the center tank, it will be used first, pumped by the two center tank pumps.
My airline’s manuals don’t go into much detail, but I read on another site that if both the center tank pumps fail, the engine driven pumps aren’t able to suction feed well enough from the center tanks to sustain engine operation. If there was fuel in the center tanks, a complete electrical failure would soon lead to center tank fuel pumps failure (all fuel pumps failure as stated previously) and fuel starvation of both engines. A rescue from this situation would be an immediate selection of both center tank fuel pumps OFF (not if my airline’s non-normal checklists) and waiting for successful suction feed from the L and R main tanks to occur, this would take a number of seconds.
Is this something that you train for in your airline? Am I correct that to do this requires making the needed switch selections on the overhead panel?

Further up the thread one of the posters mentions that it is very unlikely that any crew action (checklist, QRH) would have got anywhere near to changing a fuel pump switch position.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Centre Tank  Electrical Failure  Fuel (All)  Fuel Cutoff  RAT (All)  RAT (Deployment)

Feathers McGraw
June 21, 2025, 19:24:00 GMT
permalink
Post: 11907998
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:
The conditions that were experienced in the real world by the system were incorrectly assessed in the system requirements and lead to an undesired output state when taking into account the real world result we would have preferred.
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
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.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Air Worthiness Directives  FADEC

Feathers McGraw
June 22, 2025, 15:27:00 GMT
permalink
Post: 11908621
Originally Posted by za9ra22
While suspecting that mods may consider this subject outside the realm of this thread - and I think it was raised previously - I have to say that to my mind, there would be significant questions over the integrity and reliability of data collected via third-party commercial businesses or agencies which may or may not have vested interests, and the vulnerability to any transmitted data to unauthorised and unknown outside access.

Just that last consideration, meaning the need to introduce information security 'experts' into the analysis of data might create far more problems than it solves.

If the data is either encryted and/or signed with a suitably validated certificate, then any tampering becomes immediately obvious which itself makes the tampering pointless especially if it is sent via multiple routes.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Thread Moderation

Feathers McGraw
July 10, 2025, 16:33:00 GMT
permalink
Post: 11919132
Originally Posted by The Brigadier
With the recent (albeit unofficial) indications that both engine fuel control switches were found in the CUTOFF position
Given that it would have been obvious to the crew very late on that they were going down, might the switches being set to CUTOFF be a last ditch measure to try to prevent a post-crash fire?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All)  Fuel Cutoff Switches  RUN/CUTOFF

Feathers McGraw
July 11, 2025, 22:39:00 GMT
permalink
Post: 11919930
Originally Posted by HUTCHP
So, if the switches haven't been fully lifted over the guard but are just sitting on the top could the acceleration/ rotation cause them to snap back to the off position. Have seen this effect on toggle switches before but not on an aircraft system.

Hutch
Might there have been something resting in front of the switches that moved backwards on rotation? A phone, small iPad, book, wallet?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Switch Guards

Feathers McGraw
July 11, 2025, 22:59:00 GMT
permalink
Post: 11919958
Originally Posted by AlexGG
Could be installed with a locking mechanism disengaged.

I don't see in the report that the switches were in fact installed with the locking mechanism disengaged. Maybe I have missed it.
There is mention of fire damage or thermal damage to the centre pedestal, perhaps enough to identify the position of the switches but not to be able to determine their internal physical state relating to the detent mechanisms.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All)  Fuel Cutoff Switches  Fuel Cutoff Switches (detent)

Feathers McGraw
July 11, 2025, 23:07:00 GMT
permalink
Post: 11919969
Originally Posted by galaxy flyer
it would have to be small enough to fit between the idle throttle position and guards on each side of the switches and weigh enough to push the switches over the detent, unless the SAIB cones into play.
Yes, which is why I said a small such range of objects. I can't see how both switches could unintentionally be moved individually one after the other unless there was something wrong with the detent mechanisms. I suppose a careless hand is also a possibility, removed from the thrust levers on rotation?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All)  Fuel Cutoff Switches  Fuel Cutoff Switches (detent)  Special Airworthiness Information Bulletin  Switch Guards

Feathers McGraw
July 12, 2025, 18:59:00 GMT
permalink
Post: 11920753
Earlier today I watched Mentour Pilot's YouTube discussion, one of the things Petter said was "Brain fart of the century" regarding the erroneous selection of cut-off 3 seconds after leaving the ground. Somewhere else I saw this sort of thing described as a "Car keys put in the fridge" event.

I'm also reminded of the Moorgate tube train crash in 1975, no one has ever determined why an experienced driver who had driven the short out and return route 4 times that day suddenly accelerated while bringing his train into a terminus station with a closed tunnel beyond the platform end.

As someone married to a person who suffers with epilepsy, I'm used to short term memory interruption events where my wife will have done something and then not remember doing it 10 seconds later. I suppose such a thing in a pilot is a possibility, a new sufferer may not even realise that they have this kind of condition or even know they have performed an action.

I don't have anything else I can add to this, I read the preliminary report twice and checked every word. It doesn't offer any clear suggestions without expanding on the limited information provided. Undoubtedly the investigators have a lot more information they can examine but it will take time. One thing is that it doesn't mention a positive rate call, in the circumstances that suggests that this wasn't made and was replaced with the "Why did you cut-off?" question.

I note that this crash might have been more survivable with a 15 degree change of heading to the left towards a more open area to the south of the 5 buildings involved, but of course there would be no reason for the crew to have done this or indeed any time to do it.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All)  Fuel Cutoff Switches  Pilot "Why did you cut off"  Preliminary Report

Feathers McGraw
July 13, 2025, 17:39:00 GMT
permalink
Post: 11921476
Originally Posted by B2N2
Everything is recoverable given the right set of circumstances.
Given a different set of circumstances at some point the situation is unrecoverable and you become “dead man walking”.
Stalls, spins, unusual attitude recovery, MCAS events, they all become unrecoverable below a certain altitude.
If I had to take a guess I would say 2500-3000’ AGL and this could have been recoverable.
In this particular case, shoving the nose down together with having no hydraulics for gear retraction could only have caused an earlier collision with the ground due to the low initial altitude. There was insufficient energy to try to climb higher to extend the time for the relights to work, doing so would have bled off airspeed and led to an increased descent rate. PF did everything he could with what he had to work with.

It's this narrow window of opportunity which is making the deliberate suicide theory appear more attractive, but in reality the accidental "action-slip" or "brain fart" theory is at least as strong given that something, like a positive rate call, could have triggered the wrong action even if each switch was operated sequentially.

Subjects: None

Feathers McGraw
July 13, 2025, 18:56:00 GMT
permalink
Post: 11921533
Originally Posted by Contact Approach
We are we not permitted to discuss the highly probable scenario that one of the crew were responsible for this incident? This is a discussion forum after all, not a cult. Those of us who actually operate these aircraft have to discuss away from this forum now purely because it\x92s no longer fit for purpose.
It's not easy to discuss this aspect when you have essentially no confirmatory information to go on. I quite understand it's a possibility, but then so it is for any one of us and knowing something about a stranger's state of mind is essentially impossible.

Subjects: None

Feathers McGraw
July 13, 2025, 19:20:00 GMT
permalink
Post: 11921557
Originally Posted by Mrshed
Thanks - apologies for the stupid follow on question but the report notes that the APU inlet door started to open approx 8 seconds after RAT started to generate hydraulic power.

I assume this means that the APU was not operational until this point?
I believe the APU can take quite a while to start, certainly more than 30 seconds. The APU inlet door in the wreckage is open but it's not clear if it is fully open or perhaps closed a little with the loss of whatever power is used to drive the actuator. Electrical or hydraulic? I have seen other 787 APU inlet door photos showing what seems to be a wider aperture but that was on an aircraft on the ground.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): APU  Hydraulic Failure (All)  RAT (All)

Feathers McGraw
July 13, 2025, 19:42:00 GMT
permalink
Post: 11921575
Originally Posted by za9ra22
That totally clears up any doubt then, because a media interview where claims are made without any substantive evidence at all are clearly to be taken as gospel.

What I found interesting when viewing the Captain's background, was that he was a long-time carer for his aging father, and had called home before the flight to confirm that he would be in contact again once arrived in London. Also that he was highly respected with no history of difficult personal interactions, and had passed all medical clearances.

I'm sure we're all open to actual evidence though.
Good information there, that certainly suggests no intention *not* to arrive in London on his part.

Subjects: None

Feathers McGraw
July 13, 2025, 19:53:00 GMT
permalink
Post: 11921584
Originally Posted by cargun
Indeed.
I previously mentioned that my wife suffers from epilepsy, some of her seizures can be of the very short absence type where she very quickly returns to what she was doing but then stops to gather her thoughts for a few seconds.

Occasionally I have short microsleep events when tired where I lose awareness and then come to with my hand on the mouse and then carry on using my computers. This often happens in summer when early morning light affects my sleep pattern and the additional warmth of the PCs under my desk lull me to snooze a bit. I usually have a few seconds needed to remember where I was.

Not saying that a 15,000 hour captain would do something like this just after rotation but you just never know for sure.

Luckily for everyone I am not in charge of a complex aircraft.






Last edited by Feathers McGraw; 13th July 2025 at 19:55 . Reason: Missed the word 'hour'

Subjects: None

Feathers McGraw
July 14, 2025, 16:57:00 GMT
permalink
Post: 11922366
Originally Posted by YYZjim
Two posters above have quoted AvHerald's report that "... India's media reports that the investigation is NOT focusing on a human action causing the fuel switches to appear in the CUTOFF position, but on a system failure." One interpretation of this is that the investigation knows all about the human action and that the system they refer to is the industry's approach to pilot mental heath and well-being.

YYZJim
Perhaps that is the Indian media fooling themselves. Maybe they looked in the mirror and tried to avoid seeing what was there.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All)  Fuel Cutoff Switches  RUN/CUTOFF

Feathers McGraw
July 16, 2025, 12:33:00 GMT
permalink
Post: 11923701
Originally Posted by slats11
As a critical care physician (with AVMED background), these last few years we seeing unprecedented rates of self-reported stress, anxiety, depression, and deliberate self-harm. This is being experienced in most western countries (perhaps globally, but I have less direct knowledge of non-western countries). It is absolutely off the scale. In my 35 year career, I have never seen anything like the last 4 years.
This is a result of various things, but essentially it comes down to when the globalist system has removed all slack and shock absorbtion from people's everyday lives and interactions, then something has to give. That something is the next weakest link in the chain which is the wet-ware inside our skulls that has not had time to evolve defences against the type of threats that have changed massively since we were hunter-gatherers.

Subjects: None