Posts about: "Parameters" [Posts: 71 Pages: 4]

The checks on the Indian 787 fleet are proceeding apace. Hindustan Times :

Reply to Magyar Flyer:

Hindustan Times :

OK, another hour spent going through all the posts since I was on last night...
I won't quote the relevant posts as they go back ~15 pages, but a few more comments:

TAT errors affecting N1 power set: The FADEC logic (BTW, this is pretty much common on all Boeing FADEC) will use aircraft TAT if it agrees with the dedicated engine inlet temp probe - but if they differ it will use the engine probe . The GE inlet temp probe is relatively simple and unheated, so (unlike a heated probe) a blocked or contaminated probe will still read accurately - just with greater 'lag' to actual temperature changes.

TCMA - first off, I have to admit that this does look rather like an improper TCMA activation, but that is very, very unlikely. For those who don't know, TCMA is a system to shutdown a runaway engine that's not responding to the thrust lever - basic logic is an engine at high power with the thrust lever at/near idle, and the engine not decelerating. However, TCMA is only active on the ground (unfamiliar with the 787/GEnx TCMA air/ground logic - on the 747-8 we used 5 sources of air/ground - three Radio Altimeters and two Weight on Wheels - at least one of each had to indicate ground to enable TCMA). TCMA will shutdown the engine via the N2 overspeed protection - nearly instantaneous. For this to be TCMA, it would require at least two major failures - improper air ground indication or logic, and improper TCMA activation logic (completely separate software paths in the FADEC). Like I said, very, very unlikely.

Fuel contamination/filter blockage: The fuel filters have a bypass - if the delta P across the filter becomes excessive, the filter bypasses and provides the contaminated fuel to the engine. Now this contaminated fuel could easy foul up the fuel metering unit causing a flameout, but to happen to two engines at virtually the same time would be tremendous unlikely.

Auto Thrust thrust lever retard - the TO lockup in the logic makes this very unlikely (it won't unlock below (IIRC) 400 ft., and even that requires a separate pilot action such as a mode select change or thrust lever movement). And if it did somehow happen, all the pilot needs to do is push the levers back up.

Engine parameters on the FDR: I don't know what exactly is on the 787 FDR with regards to engine parameters, but rest assured that there is plenty of engine data that gets recorded - most at one/second. Getting the FDR readout from a modern FDR is almost an embarrassment of riches. Assuming the data is intact, we'll soon have a very good idea of what the engines were doing

777/787 driver here.

Reading a few posts about an APU-to-pack takeoff, or a packs off takeoff on a 787, because of the hot weather, makes me shake my head.
There is no bleed air on the 787. A packs off takeoff, or an apu to pack takeoff, is never done. There isn’t a procedure in the fcom to describe it. It is also pointless. The packs are electrical.

Then the gear.
When you lift off the runway, the gear doors open REGARDLESS of gear lever position. If you do not raise the gear within 30 seconds, the gear doors close again and you keep the gear down as you apparently desire. In the video, the gear doors are closed again as the airplane flies into the suburb. This requires normal hydraulics in system C, which was apprently available as the doors are closed again.

takeoff performance:
I entered all relevant weather parameters into my performance tool for Ahmedabad VAAH, rwy 23, 42 degrees C and no wind, qnh 1005.
It comes up with flaps 10 as optimum, albeit for a 787-9 (don’t have the possibility to calculate for the 787-8) But even the 787-9 is able to depart with flaps 5 in those conditions. Max tow around 230tons.

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?

Having gone through every possible way the aircraft (or those in it) can shut down both engines, thought it would be helpful to look at what investigators have looked at/for in a somewhat similar case. Perhaps it will move the discussion to more unplowed ground.

Going through AAIB Bulletin10/2008 from the British AAIB in the BA 38 case. Before finding the exact cause, they had investigated the following with findings in quotes:

1. General aircraft examination - "no pre‑existing defects with the electrical systems, hydraulics, autoflight systems, navigation systems or the flying controls."
2. Spar valves - "Extensive testing to induce an uncommanded movement, that remained unrecorded, could not identify any such failure modes."
3. High Intensity Radiated Field (HIRF) and Electro- Magnetic Interference(EMI) - "There is therefore no evidence to suggest that HIRF or EMI played any part in this accident."
4. Fuel System - "The examination and testing found no faults in the aircraft fuel system that could have restricted the fuel flow to the engines."
5. Engines - "No pre‑existing defects or evidence of abnormal operation were found with the exception of signs of abnormal cavitation erosion on the delivery side of both HP pumps. Some small debris was recovered from the left FOHE inlet chamber but this would not have restricted the fuel flow."
6. Fuel Loading/Fuel Testing - "No evidence of contamination was found." "The properties of the sampled fuel were also consistent with the parameters recorded in the quality assurance certificate for the bulk fuel loaded onto G‑YMMM at Beijing."
7. Water in Fuel - "It is estimated that the fuel loaded at Beijing would have contained up to 3 ltr (40 parts per million (ppm)) of dissolved water and a maximum of 2 ltr (30 ppm) of undissolved water (entrained or free). These quantities of water are considered normal for aviation turbine fuel."

Knowing the history of this flight, the previous flights and the climate that day, I left out all the discussion in the report of fuel waxing/ice. That seems as irrelevant as 'vapor lock'.

I too am beginning to think this will be, as an earlier poster termed it, a "unicorn" event.

Source: Bulletin_10-2008.pdf

Here's an answer from the other thread: Sailvi767 , 14th Jun 2025 18:00

625 feet is straight from ADS-B data, which is just pressure altitude using sea-level STP. I don't know if it has been mentioned in this thread yet but in the other thread it was pointed out several times that this would have come out to ~100ft in true altitude AGL. The mathematics of that checks out to me (QNH 1001, temperature 37\xb0C, and field elevation of 189 feet).

The aircraft also visibly never gets much more than roughly its own wingspan above the ground in CCTV footage, at least to my eyes.

News articles tend to be fairly unreliable sources of info as far as parameters like altitude go in my experience.

I (and I think everyone else here) have been assuming that the FADEC does in fact have a dedicated permanent-magnet alternator, as is the case on the Airbuses (confirmed by FCOM) and surely the 737.

I have been told elsewhere that this is not the case. A read of the draft FCOM available online for the 777 & 787 makes no mention of a FADEC generator, but then neither does the 737 manuals. Is this simply a case of "Boeing thinks you don't need to know"?

It has been proposed that the primary source of power for the FADECs is actually the flight control PMGs, mounted on the engine gearbox, but that this power goes to the avionics bay, has failover switching gear, and comes back to the EEC.

Can anyone shed concrete light on this (e.g. a source that clearly states there is both an EEC alternator and a flight control PMG on the accessory gearbox)?

Alternator and generator seem to be used interchangeably in this context.

It's not quite that, but there is a list of received channels for a GEnx 787 in the FDR report into one of the original battery fires . Unfortunately, it is only a list of parameters that they used and verified in the investigation - the only ones listed for the engines are N1 and cutoff switch. Other accident/incident FDR reports might be more focused on engines and include a similar table.

I don't think you'll find an actual wire list for it (or it won't be useful) as apparently most/all of the data is via an ARINC bus.

I attempted to PM this but your inbox is full.

[SLF with an electrical background and some exposure to ground-side critical facilities power]

There seem to be issues with the evaluation due to damages. Cannot assess the reliability of the source.

https://weeklyvoice.com/damaged-blac...medium=twitter

I think the mods are right to squelch vapor-lock theories because AFAIK there's no support for the notion that it would happen under these circumstances. I can provide a brief explanation but I don't know the operating parameters of a 787 fuel system so I can't speak authoritatively on that. I can speak authoritatively on modern automotive fuel systems where vapor lock on a running system is just not a thing, even though gasoline has much higher vapor pressures and cars can be operated in temperatures much higher than 43C with fuel temperatures to match.

This explanation comes with a money-back guarantee and if I'm wrong I'll send out refunds.

First, vapor lock is simply where a pump or other device becomes inoperative because it is designed to pump liquids but is presented with a gas (vapor) at it's inlet and thus cannot develop pressure and pump the fuel. Think of a very old car with a mechanical fuel pump on the engine block that draws fuel through a long tube from the fuel tank. If you shut the car off on a hot day, the residual heat may boil off the fuel in the lines and carburetor so that when you try to restart, there's no fuel anywhere and your pump has lost it's prime. It is key to note that even with a very crude system like this and volatile gasoline as a fuel, vapor lock usually only affects starting and not running engines. There are exceptions, of course.

The three key factors are the absolute pressure at a particular point in the fuel system, the vapor pressure of the fuel at whatever temperature it is at and system design. System design has all but eliminated vapor lock as a serious issue in the gasoline automotive world. At near sea level, the outside pressure is about 1 bar (15psi) and at 50C typical jet fuel will have a vapor pressure of perhaps 0.02 bar. So the only way to cause it to vaporize jet fuel, even at 50C+, would be to subject it to a very, very strong suction. AFAIK there are no vulnerable points where you'd have suction during normal operation because the fuel pumps are presumably (I don't actually know) immersed in fuel and the entire system has greater than 1 bar pressure all the way to the high pressure pumps. Even without the electric pumps, the inlet to the mechanical pump is below tank level. So absent some major fuel line restriction, there aren't any points where you'd have strong suction aka very low absolute pressure.

The discussions about fuel temperature also seem a big irrelevant to me--even at 60 or 70C the vapor pressure is still very low and I doubt you'd see significant vapors at all under 100C with any reasonable fuel system design and properly blended fuel . I'm assuming the fuel temperature limits are for other reasons, perhaps flash point or ignitabilty (TWA 800) or viscosity and lubricity concerns with the high pressure pump. Again, IDK, but vapor lock with Jet A seems very far fetched to me. I would note that improperly blended fuel could have a much higher vapor pressure and still work OK in most cases as long as positive pressure was maintained. So if the electrics and the pumps went offline and the fuel vapor pressure was way too high, I suppose there could be vapors formed in the suction line going to the mechanical pumps. But I don't have nearly enough knowledge to proclaim that as a possibility. I presume they've taken fuel samples at the source and tested them. Here's a paper on Jet A vapor pressure:

https://www.researchgate.net/publica...Kerosene_Jet_A

From earlier in one of the threads, I believe the ground/air logic is a function of the airframe's processing, and fed to the FADEC/TCMA as a binary value.

It is to be noted, IIRC, that only the parameters for a 74? have been given for this air/ground relationship.

EDIT: Replace single with binary value. Binary yes/no not value say 1/0/-1 Ground/?/Air...

These same points arose in the dozen or so AF447 threads regarding stall, & recovery.

The TCMAs will not 'activate' - trigger fuel shut off - on a rejected take off if the engines do what they are told when the thrust levers are set to idle. The software monitoring the engine parameters v throttle position is quite sophisticated, for obvious reasons.

In general, we can classify computer errors into 3 categories:

1. Errors in system design, specifications, or algorithms. These are cases where the computer does exactly what it was designed to do, but the design itself was flawed or inadequate, or had unforeseen consequences. This would include things like MCAS on the 737 MAX.
2. Software errors. These are cases where the computer does exactly what the code tells it to do, but not what the designers wanted it to do. This results from mistakes in writing the actual code, and this is usually what we'd refer to as a "bug." This includes things like race conditions, loops that fail to terminate, incorrect type conversion, etc.
3. Hardware malfunctions. These are cases where the computer does something different from what the code instructs. It can involve memory corruption or data bus corruption. It can result in a system that appears to work, but returns incorrect outputs, e.g. a calculator saying 2+2=5. It can also cause the computer to execute valid instructions, but at an inappropriate time. It can result from manufacturing defects in components, cosmic rays (SEU or SEE), radiofrequency interference (HIRF), moisture ingress, failed solder joints, and numerous other things.

As I said previously, I think we can rule out category 3 in this case. Hardware malfunctions are essentially random events. They're inherently unpredictable since there's little to no relationship between what the system was supposed to do and what it actually does. It would be astronomically improbable for the same failure to occur on both engines at the same moment.

Categories 1 and 2 would be common to both engines, so they both remain plausible. For category 2, it would be impossible to identify the issue without analyzing the complete source code. Since we don't have access to that code, this is a dead end. It could be the cause, but we won't be able to figure it out. Looking at how the FADECs are designed to work isn't going to be very useful here, since by definition, they'd be doing something they weren't supposed to.

Category 1 is a bit different. There are 2 functions we know of that can close the fuel shutoff valve: TCMA and N2 overspeed protection. We don't have the complete specifications, but the basic logic of both functions has been described. If we assume that one of these was the cause, then the conditions for one of those functions must have been met.

The conditions for TCMA, at least as it's been described in this thread, are:

• Airplane on ground
• Thrust higher than commanded by thrust lever angle (TLA) for some period of time

It's reasonable to assume that the first condition is common to both engines. But that still leaves the second. To my knowledge, there's no plausible scenario that would cause that condition to be met on both engines simultaneously. Each thrust lever has 2 resolvers which are wired directly to the corresponding FADECs. That means the signals don't pass through any common component. An incorrect reading from one resolver could conceivably trigger TCMA, but I don't see any reason why that would happen to both engines simultaneously.

As for the overspeed protection, as far as I know, there's only one condition: N2 greater than a certain value. That reading comes from sensors that are inside each engine and wired directly to the FADECs. I don't see any way this could affect both engines simultaneously either, but it still seems a bit more likely than something involving TCMA since it only requires 2 separate, simultaneous failures rather than 3 or more.

For the sake of accuracy, I should also note that not everything fits neatly into one of my 3 categories. For example, let's say we have a machine that's programmed to shut down if any one of 3 parameters goes above a certain value. If one of those values gets corrupted by a faulty memory chip, the machine could shut down unnecessarily. If we add more parameters to the list, the probability of an inadvertent shutdown increases since there are more critical areas in memory. As another example, consider a case where corruption of the CPU's program counter causes it to inadvertently jump to a particular subroutine. If we add more subroutines that can trigger a shutdown, we make the machine more vulnerable, albeit to a very small degree. Changes like these are sometimes referred to as "increasing the surface area."

Due to those types of scenario, I will admit that the existence of something like TCMA probably makes an engine ever-so-slightly more likely to fail. Whether the benefit is worth the cost could be debated. In any case, I still find it pretty unlikely that any of this will turn out to have been a factor in this accident.

If I may - going back to the upthread report of an Indian Express newspaper interview with "an official" who was pointing at possible "water contamination". This is very misleading by either the "official" or the newspaper. The incident specified by "the official" near Gatwick in 2020 is this one:

https://www.gov.uk/aaib-reports/airc...-february-2020

which was explicitly biocide contamination not water. As in the Japanese similar case discussed here already, the excessive biocide use caused chemical reactions in the fuel that - eventually - caused starvation and abrupt shutdown.

The Japanese incident , discussed already above, has much more detail on how the biocide is used and what happens if it's used excessively.

I do not know how Air India / Boeing / Ahmedabad do their biocide treatment, but it appears generally (from a good number of accident / incident reports) that it is very particular to the given aircraft. Once the desired fuel load level is known, a desired concentration of biocide can be calculated for that fuel load. That biocide is then introduced, via an intermediate little bowser, into the specified quantity of fuel being loaded on the tarmac into the subject aircraft tanks. So, the biocide does its thing in suspension in the regular fuel, as the aircraft operates its route. In a number of cases, orders of magniture more biocide (of which there are various brands) has ended up in the fuel, causing engine shutdowns at very difficult moments.

So, some questions. If the investigators are looking at a biocide contamination:
- after such a fireball, would there be any way of determining whether the fuel had in fact been biocide contaminated? Perhaps the inner surfaces of the tanks? Assorted valves and piping along the fuel route?
- what relevant engine parameters are captured and (hopefully) usefully recorded by the FDRs? A couple of incident reports have mentioned monitoring of the exhaust gases, with an ability to detect contaminants as they are expelled.
- does anyone here know what records are kept regarding the biocide treatment at the point of fuelling? Iirc, in the Japanese incident it was forensic interviews with the ground crew responsible that revealed the details of the error, rather than captured hard data.

Gary Brown Yes that was what I was wondering too. Biocide contamination not water. Hence my earlier curiosity about what might have occurred to the aircraft in the DEL stopover. If the inner surface of just the centre tank somehow got contaminated there, any issues may have been hidden flying with the tank empty and the problem only arose on the subsequent sector when the tank was used.

I suppose an informed guess is the best answer I can get here, short of someone having access to an actual sim or a Boeing engineer chipping in. Though I am curious that you are guessing that it would engage, when in the example you give to point out the autothrottle being inhibited at low altitudes (the Asiana accident at SFO) the autothrottle didn't engage - not even to provide low speed protection, a potentially life-and-death matter. If that accident was my only datapoint my guess would be that if it's strict enough to not engage for stall protection, it's strict enough to not engage for altitude capture.

Also to be clear I do know that the autopilot and autothrottle are independent - I have been talking about the autopilot because as I listed, in the incidents I could find where the aircraft automatically tried to capture a target altitude on takeoff, the autopilot was first engaged. So my impression was that until then the aircraft might provide guidance (like in the Emirates case) but will not actually do anything to change the thrust, pitch, etc parameters that have been set.

FWIW, They`re actually somewhat different scenarios as far as the auththrottle behavior situation. In FLCH below 400` in a descent, they are deliberately inhibited (to include low speed protection) because the jet thinks you`re landing. And very clear in the FCOM.

I am not aware of any requirement for a DFDAU (or equivalent) to store any data. I say "or equivalent" because in B717 the DFDAU is not an LRU. It is a functional partition of the VIA.

It's not clear to me that 787 EAFR even requires an external DFDAU. The GE EAFR does not -

"Provides Flight Data Acquisition function of ARINC 664 p7 data parameters – No need for a Digital Flight Data Acquisition Unit (DFDAU)."

ref https://www.geaerospace.com/sites/de...rder-3254F.pdf