PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Rumours & News (https://www.pprune.org/rumours-news-13/)
-   -   BA038 (B777) Thread (https://www.pprune.org/rumours-news/340666-ba038-b777-thread.html)

tanimbar 23rd February 2008 09:08

Fuel stratification - bowing out (for now)
 
Warning: I'm non-professional; not crew, not engineer - just guest here, thanks.

Green-dot,your post #328, thanks for the clarification regarding the visibility of maintenance pages to the flight crew. And, we agree with each other, there is no indication in the AAIB bulletins to suggest that water content in any of the tanks triggered a warning message. I also think the AAIB statements of fuel testing rule out gross water contamination of the fuel. This does not mean that H20 did not contribute to the cause of the accident, but then, neither does it mean H20 did contribute.

I seem to have reached a point where my lack of understanding of the 777 systems, coupled to some contradictory statements on how the systems work on this thread, has convinced me that I should now stop scribbling.

I'll leave the fuel stratification idea hanging mute and await the final AAIB report.

Thanks to the moderator(s) for allowing me to participate on this professional forum and for the forbearance of the professionals.

Last words - the flight crew performed truely wonderfully. I wonder how much additional revenue BA will earn over the coming years from that display of pure professionalism.

Regards, Tanimbar

PS. I reserve the right to return :ok:

borghha 23rd February 2008 09:52


.... My only thought then was it was all down to the filters plus a bit of heat and agitation and thought no more about it.
Very interesting post Enicalyth, thanks!

That bit of heat might just not have been there. Could the temperature of the fuel at the boost pump inlets have been significantly lower than the recorded total fuel temperature according to you (due to suction, ie pressure drop when more thrust was commanded) could this in turn have influenced viscosity enough to cause a restriction and hence cavitation? No water or ice involved in this scenario, nor any post-incident evidence after a certain time.

Jetdoc 23rd February 2008 12:40

I am not sure if it has been mentioned before, but in addition to the 2 fuel pumps in each main tank, there is a pump bypass valve in the left and right tanks that allow the engine driven fuel pump to suction fuel from the tanks in the event the boost pumps are not working. I believe that this situation would be highlighted by a level B ENG FUEL PRESSURE warning which includes an audio warning.
Additionally, if the boost pumps were not providing flow, they would also give a similar LOW PRESSURE warning. And if all that ice was heading down to the engine, I am sure that the FUEL FILTER clogging warning would have come on.
Even if the crew had no time to deal these warnings, these should have been recorded and the data should have been correlated with system faults in the central maintenance computers. I am sure that these computers have been interrogated already and we would have heard about these problems.

Green-dot 23rd February 2008 12:43

Quoting hotdog:

". . .from aliens to EMI to RMI. . . ."

May i remind you that a bad connection in aircraft wiring can result in EMI?

Neither the electronics nor the well shielded wiring itself but the wiring connections seem to have been problematic on occasions.

Sometimes the cause has been traced to such bad connection by disconnecting and reconnecting LRUs, solving the problem.

For example on one such incident (i stress, a different time, different plane), a MCP (mode control panel) was doing strange things intemittently like letting both pitch and autothrottle fight each other to maintain speed. Nearly all LRUs involved were changed before it was discovered that the windshield heat was not correctly grounded. This is located just a few inches from the MCP and is one of the big consumers on board. Tightening a few nuts solved the problem.

From examples like this the industry has learned over the years.

There is also a difference between a factory fresh airplane and an airplane being in service for several years subjected to the elements, and wear and tear. Good maintenance keeps things in check but EMI can be something intermittent which can only be addressed if it exists at the time of an inspection or an operational check.

Not to mention if it is a combination of signals mixing in like multiple signals from PEDs or from outside sources. PEDs also have specs but what happens to those specs if the user has dropped his PED once or twice on occasion, perhaps damaging it but is still functioning?

Now (and this is just theory) to go back to the aircraft in question and its engine feed system. What if EMI in some way had gotten hold of both spar valve control relays or open-close actuators on the valve control, mounted on the rear spar (outside of the fuselage / Faraday cage) and were temporarily closed and re-opened as the EMI appeared and disappeared. This would have restricted fuel flow to the engine pumps. What effect would that have had on pump cavitation . . . . .?


Also, i am aware that fuel "run" to "cut-off" switching would have appeared on the DFDR recording but would the DFDR also record uncommanded closure of the spar valves with the cut-off switches still in "run" position?


Regards,
Green-dot

FrequentSLF 23rd February 2008 13:59


For example on one such incident (i stress, a different time, different plane), a MCP (mode control panel) was doing strange things intemittently like letting both pitch and autothrottle fight each other to maintain speed. Nearly all LRUs involved were changed before it was discovered that the windshield heat was not correctly grounded. This is located just a few inches from the MCP and is one of the big consumers on board. Tightening a few nuts solved the problem.
Based on my knowledge such kind of problem is not EMI. A badly grounded windshield heat cannot generate radio frequency which is the cause of EMI. Grounding issues are not related to EMI.

SyEng 23rd February 2008 15:52

Re. Avrflr post 330.
 
Avrflr,


“We'll call that miracle number 1 “

“Miracle” is not standard systems safety analysis terminology. Please define. Here are some of the terms we use in the industry by way of example. Personally though, I prefer to stick to numbers for clarity.

Remote: < 1E-5 failure events per flying hour
Extremely remote < 1E-7 “
Extremely improbable < 1E-9 “

Are “centre tank pump1, 2 running normally” recorded FDR parameters?
Are the centre tank push-buttons positions recorded?
Would failure of the CT pump pressure sensors be recorded?
Note that some things can’t be recorded as they are not signalled e.g. jet-pump induced water scavenge flow.
Can anyone out there help with an applicable list of FDR parameters?
While I'm asking, can anyone help with a schematic?



“So, miracle number 2 is that the last drop of water passes through the injectors on both engines at the precise moment that the engines hit the ground? Come on.”

That’s not what I said. So, what I did say is very unlikely. The accident was unlikely too. It had unlikely causes. Dismissing possibilities on the grounds that they are unlikely is not helpful. I’ve never noticed blinkers in the kit of any of the air accident investigators that I’ve met.

The key to this accident is that there was a common-mode failure. The same thing happened to both engines at the same time. One common failure mode could originate from the engine control system/software. This has been ruled out by the AAIB. The engines themselves also got a posthumous clean bill of health. Another source of a common-mode failure might be the fuel quality. The AAIB have found no fault with it. Likewise temperature: the aircraft was operating within its environmental design envelope.

As far as systems common-mode failure sources are concerned, the only possibility that has occurred to me so far is that the fuel feed system allows both engines to be fed simultaneously from the same (centre) tank. If anyone can think of any others, please post them.

forget 23rd February 2008 16:00

FrequentSLF.

Based on my knowledge such kind of problem is not EMI. A badly grounded windshield heat cannot generate radio frequency which is the cause of EMI. Grounding issues are not related to EMI.
Disagree. Arcing across a bad electrical connection can cause, and is called, Electro Magnetic Interference. Isn't that what Marconi used to send his first radio signals? :)

A spark-gap transmitter is a device for generating radio frequency electromagnetic waves. These devices served as the transmitters for most wireless telegraphy systems for the first three decades of radio (1885-1916) and the first demonstrations of practical radio were carried out using them.

Swedish Steve 23rd February 2008 16:45

Are “centre tank pump1, 2 running normally” recorded FDR parameters?
Are the centre tank push-buttons positions recorded?
Would failure of the CT pump pressure sensors be recorded?


Fuel pump switch position is recorded.
Fuel pump output pressure switch sense is recorded.
I.e. Pump switch ON or OFF command
and pressure switch Pressure or NO Pressure.
Failure of sensors is not recorded, has to be determined by logic.(not computor logic but human logic!)

FrequentSLF 23rd February 2008 17:06


Disagree. Arcing across a bad electrical connection can cause, and is called, Electro Magnetic Interference. Isn't that what Marconi used to send his first radio signals? :)

A spark-gap transmitter is a device for generating radio frequency electromagnetic waves. These devices served as the transmitters for most wireless telegraphy systems for the first three decades of radio (1885-1916) and the first demonstrations of practical radio were carried out using them.
Agreed.
However here we are talking about grounding. There should be no arching on the ground connection.

forget 23rd February 2008 17:12


There should be no arcing on the ground connection
. :confused::confused:

If the ground connection is the 'bad' connection that's where you get arcing. Where else?

IcePack 23rd February 2008 17:47

When using the ctre tank do they on the 777 switch off the pumps with 500kg remaining in the tank as is done on 75/76's due the alleged problems with fuel pumps. On the 76 this amount gets scavenged when the wing tanks are down to approx 7 tons each side. Mmm! just wondering?

Swedish Steve 23rd February 2008 18:18

When using the ctre tank do they on the 777 switch off the pumps with 500kg remaining in the tank as is done on 75/76's due the alleged problems with fuel pumps. On the 76 this amount gets scavenged when the wing tanks are down to approx 7 tons each side. Mmm! just wondering?

you get an EICAS msg when the centre tanks pumps are on, and the qty is around 900kg. You then turn off the centre tank pumps for the remainder of the flight. Later on as the Wing tank qty decreases, two transfer jet pumps transfer this 900kg to the wing tanks. This procedure is completed well before landing.

THICKO 23rd February 2008 18:28

............ at least all that garbage about EMI can be buried.....

Why?:confused:

MU3001A 23rd February 2008 19:28

Common-mode failure
 
SyEng


As far as systems common-mode failure sources are concerned, the only possibility that has occurred to me so far is that the fuel feed system allows both engines to be fed simultaneously from the same (centre) tank. If anyone can think of any others, please post them.
Normal procedure would appear to be that the centre tank pumps are switched off in response to the 900kgs EICAS message, meaning they wouldn't re-start manually or automatically unless they were 1st switched back on. System logic has the centre tank pump switches serving as annunciators for low pump pressure when the switches are on but this function is inhibited when the switches are off and I don't believe system logic would allow the centre tank pumps to operate automatically with the pumps switched off and this feature inhibited.

As I understand it, the only way the engines get fuel directly from the common source centre tank is when those pumps are operating and there is sufficient fuel in the tank. I expect the position of those switches will be a recorded parameter and thus known to investigators, who will therefore also know what source was feeding the engines at the time of the accident. If the engines were receiving fuel from the centre tank and not their respective wing tanks this would constitute an anomaly which I am sure the AAIB would have mentioned in their report. Therefore it seems reasonable to assume that at the time of the accident the centre tank switches were off and the engines were receiving fuel from their respective wing tanks. Any contaminated fuel scavenged from the centre tank would logically therefore be still present in some quantity in the wing tanks, but according to the AAIB they didn't find any.

The only remaining common mode failure in respect to the fuel system would appear to be the fuel itself.

Curiouser and curiouser.

barrymung 23rd February 2008 19:36

Quote: "Based on my knowledge such kind of problem is not EMI. A badly grounded windshield heat cannot generate radio frequency which is the cause of EMI. Grounding issues are not related to EMI."

Correct grounding is extremely important if EMI/EMC problems are to be minimised, especially if there are sensitive instruments nearby.

(I'm not saying this caused the problem)

barrymung 23rd February 2008 19:48

Can anyone tell me what happens if the AAIB/Boeing fail to find the cause of the crash?

Will they keep plodding on until they find something? Will they admit defeat and say "We don't know"? Will they do something else.

Obviously the effect of a non-result on the flying public can only be imagined but I suspect they'll lose faith in the 777 and possibly more..

grebllaw123d 23rd February 2008 19:55

SyEng,
 
You write:

"As far as systems common-mode failure sources are concerned, the only possibility that has occurred to me so far is that the fuel feed system allows both engines to be fed simultaneously from the same (centre) tank."

I fully understand that you are searching for a common-mode failure - so am I!

But I have a big problem finding a scenario in which your CTR tank theory fits.:ugh:

If the SOP was followed, and I have no reason to believe otherwise, the CTR tank became empty LONG before arriving LHR (as already mentioned in many posts).
Any fuel left would imply double scavenge pump failure - very unlikely!

In any case the AAIB report states that there was an indicated fuel load of 10500 kg upon arrival - distributed between the 2 wing tanks (5100 kg and 5400 kg). Nothing is mentioned about fuel in the CTR tank.

Also "the flight was uneventful until the later stages of the approach"

With the information we have received (so far), I cannot see that the CTR tank played any part in the accident.

SyEng 23rd February 2008 19:57


Swedish Steve
“Fuel pump switch position is recorded.
Fuel pump output pressure switch sense is recorded.”

Thanks for that. If this is the case and the FDR shows no switch selected on and no pump outlet pressure at the end of the flight, then I reckon this rules out my centre tank feed theory. Do you have a full list of ATA28 FDR parameters? How about a schematic? Training notes?

PAXboy

“We learnt that 777 standard procedure is to use the Centre tank fuel first and it it's entirety. Any fuel remaining in CT is then scavenged out to the wing tanks. The rest of the flight is supplied from each wing tank to it's respective engine. (Presumably for better trim?)”

It’s not SOP, it’s system design. The SOP is to select all tank pumps on before engine start, I expect. With all pumps on, the system feeds from the centre tank first by design. The reason for using centre tank fuel before wing tank fuel is for wing bending moment relief.

barrymung 23rd February 2008 20:03

"The key to this accident is that there was a common-mode failure"


Hmmmm. Does anyone know if any fuel related devices share any of the electronics, eg data bus, earth wires or whatever..?

My car uses a system called VANBus (Vehicle Area Network Bus) which is designed to save on cabling and thus cost...basically, all devices in the car are connected to this bus system and can talk to each other. It enables things like the speedo to talk to the radio so the volume gets adjusted as the speed increases...the wipers speed up and slow down automagically as well, depending on rain levels/road speed. The heater can talk to the headlights if it wants and the interior light to the engine management system if it wanted to. Well, you get the idea.

The major disadvantages is that a fault on the VANBus can cause all sorts of odd problems. One dodgy wire and the whole lot goes boof!

Aditionally, if a device on the VANBus starts sending out spurious data it can cause another device to mis-behave despite it being fully functional and apparently not related...

avrflr 23rd February 2008 21:50


Originally Posted by SyEng (Post 3933019)
Avrflr,


“Miracle” is not standard systems safety analysis terminology. Please define. Here are some of the terms we use in the industry by way of example. Personally though, I prefer to stick to numbers for clarity.

Remote: < 1E-5 failure events per flying hour
Extremely remote < 1E-7 “
Extremely improbable < 1E-9 “

A miracle: the odds of it happening within the lifetime of the Universe is indistinguishable from zero.
Probability that I may be proven to be totally wrong: 1 in 4:)

I accept that the accident was unlikely and therefore had an unlikely cause. I don't believe that gives one carte blanche to suggest miraculously improbable coincidences as the cause of the failure.

Originally Posted by SyEng (Post 3933019)
Can anyone out there help with an applicable list of FDR parameters?

That might be a useful exercise. We can agree that something did happen, and it appears to have gone unnoticed by the FDR. Perhaps a gap can be found where no data is collected that could provide a place for the problem to "hide".

The trouble with playing this game is that we are working with only partial information. If we knew exactly what the AAIB had tested and how they had tested it, we could come up with better theories, and for that matter, better arguments against theories. I may very well be making false assumptions as to what has been established as fact, based only on the very brief reports I have read. I don't believe any of the theories I have read are credible, based on the evidence in front of me. It seems that this is the conclusion the AAAIB have come to (with much more evidence), hence the continuing investigation.

Milt 23rd February 2008 22:18

The longer the puzzle persists the more we PPRuNers learn about airliner fuel systems and many interesting associated sub systems.

Pity we are not getting some inputs from the two pilots and Boeing who seem to be all overcome with secrecy. No doubt the investigation board sifts through this thread for ideas and what ifs.

Another thread has just addressed the complexity of the Joint Strike Fighter fuel system which has been subject to successful? exhaustive ground testing. As a TP I hope I can get access to the items which are planned for flight testing. It is likely that fuel will be used as a convenient cooling medium and there may be a problem with heated fuel which has elevated vapour pressures. The FADEC, FBW and software will need to be 'state of the art'.

Oldlae 23rd February 2008 22:20

Anyone is not going to beat the AAIB on this if there is an answer/cause they are going to find it. I have always said that that the FDR/QAR may not have the answers that might explain the loss of thrust of both engines durng a routine landing which might have been repeated many times before from the same airfields in the far east. Almost all of the aircraft operating from China are from the western world and the Chinese are most unlikely to supply contaminated fuel.

SyEng 23rd February 2008 22:53

MU3001A
Thanks for the info. See above, and below.

grebllaw123d

If the SOP was followed, and I have no reason to believe otherwise, the CTR tank became empty LONG before arriving LHR (as already mentioned in many posts).

Forgive me, but I would re-write this as “If the system functioned as per design intent the CTR tank became empty of fuel…”.

BTW, anyone who has worked in tanks will be aware that there is no such thing as an empty tank in operational aircraft. Those who have been involved in fuel systems design or support will be aware that there is always an unpumpable volume and there is always an undrainable volume.


Any fuel left would imply double scavenge pump failure - very unlikely!
The causes of this accident were very unlikely. The water scavenge systems and the fuel scavenge systems may have been compromised by FOD or ice. Failure of unsignalled systems is dormant i.e. they may have been failed for years with no indication, unless there is a secondary effect e.g. uncommanded tank transfers. Ice in the CT would have thawed only during the later part of descent, starting with that in the sections of the CT exposed to external temperatures.


In any case the AAIB report states that there was an indicated fuel load of 10500 kg upon arrival - distributed between the 2 wing tanks (5100 kg and 5400 kg). Nothing is mentioned about fuel in the CTR tank.
Correct.


Also "the flight was uneventful until the later stages of the approach"
Agreed. So it’s a reasonable assumption that there were no failure warnings.


With the information we have received (so far), I cannot see that the CTR tank played any part in the accident.

Agreed. Also, with the information we have received (so far), I cannot see that the CTR tank did not play any part in the accident.


Here’s a process.

1) Understand the system
2) Find all possible ways in which combinations of failures could have the potential to cause the observed failure effect (regardless of your opinion as to their probability).
3) For each postulated failure mode, work out what evidence it would leave behind.
4) Look for evidence.
5) Rule out (and if you’re lucky, rule in) failure modes based on evidence.

It looks like my centre tank feed theory can probably be ruled out (as posted above) as the AAIB would have almost certainly seen indication of CT pumps running from the FDR.

So, my analysis is running on fumes and unless someone gets me a system schematic, FDR parameter list, system description or training notes soon, I’m off to bed.

the bald eagle 23rd February 2008 23:52

As Milt states, does seem a bit strange why the pilots and Boeing are still keeping quiet? which makes you think that the crew made a bit of a hash of it, does anyone know if they are suspended from duty or still flying?

NSEU 24th February 2008 00:46

Swedish Steve said:


Yes, took a peek in the AMM. It is not very clear but the Centre tank scavenge pump and the Centre tank Water scavenge pump are linked. It looks as though with the Centre Tank scavenge system running, liquid is sucked through the centre tank water scavenge lines as well. The centre tank scavenge jet pump motive power comes from the wing booster pumps.
Steve....
I think I'm looking at the same blurry picture from the AMM, but enlarging it, I don't see the CT water scavenge system hooked up to wing tank pumps. So, with the CT O/J pumps OFF, I don't see the CT water scavenge system operating.

However, the scavenge pickups for fuel and water in the CT appear to be very close together on the schematic. If they are at the same height... what liquid the CT fuel scavenge system will be pumping would depend on what's in the CT (water, fuel, melted ice/slush) :)

Rgds.
NSEU

Chris Scott 24th February 2008 00:54

FBW architecture - an ex-pilot's viewpoint
 
Quote from PBL [Feb23/0913], re. A320 FBW architecture:
The FACs, ELACs and SECs run in parallel on the inputs. The outputs cannot be determined by voting (you can't vote with only two processors!) but I don't know how the checks work.
[Unquote]

Although some of your post went over my head, as an ex-A320 driver (from airline launch), found it fascinating and succinct. For a given computer type, we always wondered how genuinely independent the "command" SW programmer-team could be from the "monitor" team. After all, they presumably each have the same basic mission? One is minded of a murder trial, where the jury has to be isolated from outside information sources while reaching its verdict.

To suggest an answer to your question, my simplistic understanding was that, in the event of an anomaly between the command channel and the monitor channel, the computer concerned merely shut itself down. If it was an ELAC or SEC, not much of a problem for us: there were 4 more remaining. And we were allowed an attempt at reset. If it was a FAC, that was 50% of the flight-data calculation gone, but I don't think it was particularly serious. [I write in the absence of my FCOM, which is now way out of date anyway.]

Notwithstanding my second paragraph, and the gloomy predictions that were banded about with such relish when we put it into service 20 years ago, the A320 is now a mature design, and - so far - the worst scenarios expected have been conspicuous by their absence.
Let's hope the same can be said for the B777 in 10-years' time, despite the radically different philosophy adopted by Boeing.

PS: Isn't it remarkable that, 20 years on, the SECs may still be employing an Intel 80186 chip, now ancient history in the home-PC world? We were all buying PCs with 80286/80386 chips, even as the A320s were first going into service.

NSEU 24th February 2008 02:10

Originally Posted by SyEng

Now, here are the 2 functional failures necessary to support my theory (post 216):

1) Failure to scavenge effectively CT water.
2) Engine feed source switches from wings to CT during approach.
Re 2).... This scenario seems very unlikely. Remember that with the crossfeed valves closed, each (L/R) CT pump feeds its respective engine. the control of the CT pumps would have to fail almost simultaneously to make both engines receive the contents of the CT.

Each CT pump is controlled by an independent ELCU (electronic load control unit). I haven't yet seen an internal diagram of the ELCU, but the control relay in the ELCU probably needs to see "inhibit circuit" deactivated AND the pump switched ON (by the pilots) before it will switch on: The pilot has to have the ability to turn OFF the pump in the air by deslecting the switch, irrespective of automatics.

Note that the ELCU control relay needs to be energised to turn on the pump. If the coil of the relay failed, relay would relax, turning OFF the pump. If relay contacts had fused ON (earlier), the CT pump would run out of fuel and the crew would have several indications of this.

The inhibit signal comes from ELMS. The inhibit is only for loadshedding under certain circumstances. As far as I can see, the pump doesn't switch itself off if pump pressure is low. Normally, the pilot responds to an EICAS message to turn off the pump during normal ops.
Note that low pump pressure turns on the overhead PRESS light for the pump, but unfortunately, the Boeing Maintenance Manual D&O section doesn't offer any insight into what turns on the EICAS message (low pump pressure and/or fuel quantity). We know that 900Kg is the trigger point, but whether this is how high the fuel pump pickup is in the CT or whether this is FQUIS generated, I don't yet know. Swedish Steve?

Note that fuel jettison system cannot turn on the CT pumps automatically if they have been manually turned off.

Rgds.
NSEU

soem dood 24th February 2008 02:28

"...does seem a bit strange why the pilots and Boeing are still keeping quiet? which makes you think that the crew made a bit of a hash of it..."

Perhaps they have nothing of value to add at this point, while the investigation continues?

(Some people do remain silent when that is the case.)

I certainly can't agree that silence equates to any sort of probable fault. Even the fire-handles/fuel switch order of precedence issue looks to be more about allowing ambiguous (by process) timing of two independent activities by two actors, rather than a unique human error by this specific crew. In addition, the quirky wiring (prior to the directive to rewire the switch power) is a contributing factor to that (minor, in this instance) issue.

ve3id 24th February 2008 02:30

Use of mature ICs in control systems
 
Chris Scott said:

"PS: Isn't it remarkable that, 20 years on, the SECs may still be employing an Intel 80186 chip, now ancient history in the home-PC world? We were all buying PCs with 80286/80386 chips, even as the A320s were first going into service."

I couldn't let this go! NO, It is not remarkable, it is just good engineering. If a chip performs the designed task within spec it should stay in the design forever. The engineering world is not motivated by specsmanship and marketing like the consumer electronics world is. If you put a more modern chip in there, what benefit is it going to give you? Absolutely none, but what about the risk of mask errors introducing bugs that the original programmers did not test for because the new chip has circuits that were not even known back then? Very probable.

If you re-design with a new chip, you have to re-test all system components, and that costs a lot of money.

I used to make a lot of money keeping old PDP-11s going in Candu nuclear reactors, because they were reliable and every path through the program had been documented and tested for safety.

It's not a matter of keeping up with the Joneses!

UNCTUOUS 24th February 2008 02:36

Those OTHER EFFECTS of ICING and sub-zero FREEZING
 
Looking at the Center Tank componentry that controls the automatic fuel transfer of CT fuel and pump inhibiting due to low pressure/contents etc, what components in the center-tank could conceivably be PREVENTED from operating (and possibly also from supplying warnings or inhibiting or switching off pumps) - by being iced (up or OVER)? Thinking float switches, flow switches, pressure switches or any combo of intermediating transducers or relays that could become iced (and later thaw and operate - creating the "on approach" situation of water-contaminated fuel supply).
.
Center section tank-mounted components that are low in the tank and would be covered by sheet ice are possible candidates - but also some components may have a lower temperature non-functioning trigger threshold that has so far not shown up.
.
Electronics can be prone to hibernation at extremely low temperatures and many components have moving parts, however small, that can be prone to immobilization due freezing/ice-over.

glob99 24th February 2008 02:43

FAA Required 88 Parameters
 
http://www.flightsimaviation.com/dat..._121-appM.html

I found this document that shows the 88 parameters required by the FAA to be recorded by the FDR. The BA 777 is probably recording many more parameters than this minimum set.

BobT 24th February 2008 03:20

Older generation ICs
 
At one time, I also made my living engineering safety-critical systems.

Selection of last generation or older components for newer applications (like 186s for 777s) is effectively required to certify some systems. It's one of those small win-wins - it's typically a lower-cost component, but its maturity provides reliable failure rate figures and any (ahem) weaknesses in the component are known and can be engineered-around. It can be a feature, not a bug.

Regards redundant software written by different teams, I participated in one such effort that used diverse hardware and software. It's an immensely expensive proposition, with little practical advantage (Leveson's et al fine work notwithstanding).

A little thread drift, but I'll go no further.

Fascinating threads on this subject - I'm learning much.

PBL 24th February 2008 06:33

Chris Scott said of the two channels in the ELAC/SEC/FAC boxes:


Originally Posted by Chris Scott
my ...... understanding was that, in the event of an anomaly between the command channel and the monitor channel, the computer concerned merely shut itself down.

I'm sorry, Chris, what I wrote was ambiguous.

What you say is of course correct when considering "command" and "monitor" channels inside one of the boxes.
My comment was addressed to discrepancies *between* two (or more) of the ELACs; or SECs; or FACs, and I didn't make that clear.

There are three SECs: they could presumably vote. But there are only two ELACs (FACs are less critical). What happens when they disagree? I don't know.

But I do know of one case in which they should have disagreed: the March 2001 incident to Lufthansa at Frankfurt, when the captain's sidestick was reverse-wired in roll. Since only one ELAC had been rewired (all plugs), then the two ELACs should have been getting exactly opposite inputs in roll (one ELAC the commanded roll; the other the exact opposite of what was commanded). So what happened, and how was it dealt with? The report is absolutely silent on this. (As well as being on the BFU WWW site, the report is in our compendium computer-Related Incidents with Commercial Aircraft ) I wonder why?


Originally Posted by Chris Scott
For a given computer type, we always wondered how genuinely independent the "command" SW programmer-team could be from the "monitor" team. After all, they presumably each have the same basic mission?

The big question is which faults are likely to be correlated, and which not. Mismatches between requirements and actual operational environment, which I call "requirements faults", account by some studies into aerospace critical digital systems for well over 95% of failures (Lutz, NASA/JPL, early '90's. The UK HSE looked at all types of critical systems from simple to complex, digital and non-digital, and got a figure of over 70% in the late 90's). So if 19 of 20 failures are due to requirements faults, then N-version programming is only going to avoid at most 1 out of 20 failures. That doesn't seem to me like a huge win.

A classic example of a failure of this sort in aviation is the 1983 Lufthansa overrun at Warsaw (also in the compendium, with commentary, including some by the former chief aerodynamicist of Concorde, Clive Leyman).

Another possibility for correlation amongst teams performing N-version programming is dependencies caused by mode of presentation of requirements (one description might tend to lead all teams "along certain paths"; another description along other paths). A third possibility is common types of errors occurring in the most likely places in both.


Originally Posted by Chris Scott
Isn't it remarkable that, 20 years on, the SECs may still be employing an Intel 80186 chip, now ancient history in the home-PC world? We were all buying PCs with 80286/80386 chips, even as the A320s were first going into service.

ve3id and BobT hit the nail on the head. Evolution in desktop computers is driven by evolution in requirements (the need to process video streaming from the network, for example, which did not exist when the 80186 was designed). The requirements for digital kit on the A320 are more or less stable as of certification; why change something which does a demonstrably adequate job? Especially when you have put all that effort into the demonstration!

The PFCs on the Space Shuttle are even older! There are five of them. Four of them are identical, running identical but very highly inspected SW of a few thousand lines of code (LOC). The fifth is a fall back: extremely limited functionality, but different HW and SW from different organisations.

This is all a bit of a Tech-Loggie diversion, but it does make a change from the continuing catalog of attempts to (mis)understand the B777 fuel system :)

While I am at it, I might as well stick my neck out on this one. I am with avrflr: I am guessing that something lies in the cracks between what is recorded and what went on; either something was not recorded or something wrote it was "X" on the recorders when it was really "Y"; for example, the command signal was sensed and recorded but not the true state of the component. Such things can take months to years to sort out.

BTW, bsieker has prepared both a Causal Control Flow Diagram (CCFD) of the EEC signal paths, and a similar diagram (but where what flows is fuel, not signals; maybe we should call it a CFFD) of the fuel paths in the Trent-powered B777. We have them out for review at the moment and will make them generally available after initial feedback. A CCFD is like a functional block diagram of a control system, except for three points:

* signal magnitudes are omitted (we sometimes use signs ± indicating monotone-increasing and monotone-decreasing influence where necessary, but it is not necessary here);

* equipment duplication (usually there to provide redundant pathways) may be omitted, and in this case only one instance of each duplicated device is shown;

* it will include the human operator as a control-system component if heshe is one

It shows the signal paths (or in the case of the fuel, the liquid-flow path) between all the various devices.

The CCFD (resp CFFD) is quite complicated. We find them indispensable for any reasonable understanding of how a moderately-complex system works; a necessary supplement to text-based description. They might well aid discussion here.

PBL

hunterboy 24th February 2008 06:40

Most big companies would suspend the crew/employee until an investigation has been completed. It "removes" them from the situation.

FullWings 24th February 2008 06:58

NSEU,

From Boeing AFM:


The design provides indication of low fuel quantity in the center tank based on input from the Fuel Quantity Processor Unit (FQPU) for a crew controlled wet-shutoff. If the crew fails to respond, or there is an error in the fuel gauging system, the ELMS system will de-power each center tank pump after 15 seconds of continuous low pressure based on input from the pump pressure switch.
So it looks like the pumps will shut themselves off and not run 'dry', based on pump outlet pressure. The FUEL LOW CENTER EICAS appears once the centre tank is <=900Kg.

Swedish Steve 24th February 2008 07:41

NSEU
Steve....
I think I'm looking at the same blurry picture from the AMM, but enlarging it, I don't see the CT water scavenge system hooked up to wing tank pumps. So, with the CT O/J pumps OFF, I don't see the CT water scavenge system operating.

Yes I agree with you now. The centre tank water scavenge pump motive flow comes from the centre tank pump, so with the pump off it will be disabled.

From Boeing AFM:


Quote:
The design provides indication of low fuel quantity in the center tank based on input from the Fuel Quantity Processor Unit (FQPU) for a crew controlled wet-shutoff. If the crew fails to respond, or there is an error in the fuel gauging system, the ELMS system will de-power each center tank pump after 15 seconds of continuous low pressure based on input from the pump pressure switch.

So it looks like the pumps will shut themselves off and not run 'dry', based on pump outlet pressure. The FUEL LOW CENTER EICAS appears once the centre tank is <=900Kg.

I have been studying the manuals for the last two hours. I have found a statement in the Schematics manual that shows the Fuel Low Centre message coming from the FQPU, so I agree that it is quantity derived.
I cannot see any reference to a 15 sec T/D or ELMS auto shut off. There is an ELMS driven Centre pump inhibit that shuts down the centre tanks, but this is mainly to do with lack of power on the aircraft. It is a load shed device.
In the ELMS there is a 30sec T/D. With centre pump selected ON, and low output pressure, it will set the message FUEL PUMP CENTRE L/R Advisory/status.
I do not doubt your manual, just cannot prove it from the maint manuals that we have.
Shows how difficult the B777 is for engineers. All the signals are shown entering an ARINC 629 bus, and on the next page coming off into AIMS. Impossible to say if they go ellsewhere!
Perhaps we poor engineers need an AFM to find out how it works.

gas path 24th February 2008 07:58

You beat me to it Steve :{
I cannot find a reference to the shutdown either only the load shedding.:8

Shows how difficult the B777 is for engineers.
Except the fuel system is really quite simple.....mechanically!

jafa 24th February 2008 09:15

I know where yr coming from spotty m Mr, but if there really is a lot of water it will show up a lot sooner than that.

FullWings 24th February 2008 09:40


I cannot see any reference to a 15 sec T/D or ELMS auto shut off.
I've had a further browse through the manuals and this appears to have come about through an update in 2006 (ELMS software?), so may not have found its way into all the documentation yet? Service bulletin was 777-28A0040.

cribble 24th February 2008 10:02

I bet I am not alone in this as a 777 driver:

It is outstanding to read the considered opinions of those who seem to know what they are talking about; to read posts of folks who are not afraid to say "yes, good point. How about.....?"

Outstanding. You may not get the answer, but are shedding more light than noise on the question.


All times are GMT. The time now is 17:20.


Copyright © 2026 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.