BA038 (B777) Thread
Join Date: Oct 2003
Location: Canberra Australia
Posts: 1,300
Likes: 0
Received 0 Likes
on
0 Posts
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'.
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'.
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.
Last edited by Oldlae; 24th Feb 2008 at 08:35.
Join Date: Jul 2007
Location: UK
Age: 59
Posts: 43
Likes: 0
Received 0 Likes
on
0 Posts
MU3001A
Thanks for the info. See above, and below.
grebllaw123d
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.
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.
Correct.
Agreed. So it’s a reasonable assumption that there were no failure warnings.
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.
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).
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!
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.
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.
Join Date: Feb 2007
Location: west sussex
Posts: 156
Likes: 0
Received 0 Likes
on
0 Posts
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?
Join Date: Feb 2004
Location: Australia
Posts: 1,307
Likes: 0
Received 0 Likes
on
0 Posts
Swedish Steve said:
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
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.
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
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.
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.
Join Date: Feb 2004
Location: Australia
Posts: 1,307
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by SyEng
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
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.
1) Failure to scavenge effectively CT water.
2) Engine feed source switches from wings to CT during approach.
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
Join Date: Jan 2008
Location: home
Posts: 24
Likes: 0
Received 0 Likes
on
0 Posts
"...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.
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.
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!
"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!
Last edited by ve3id; 24th Feb 2008 at 02:31. Reason: added original attribution
Join Date: Nov 1999
Posts: 324
Likes: 0
Received 0 Likes
on
0 Posts
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.
.
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.
Join Date: Aug 2007
Location: USA
Posts: 24
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Jan 2008
Location: US
Posts: 22
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes
on
0 Posts
Chris Scott said of the two channels in the ELAC/SEC/FAC boxes:
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?
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.
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
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.
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?
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.
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
Last edited by PBL; 24th Feb 2008 at 07:08.
NSEU,
From Boeing AFM:
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.
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.
Join Date: Apr 2005
Location: Stockholm Sweden
Age: 74
Posts: 569
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Usual disclaimers apply!
Join Date: Nov 1999
Location: EGGW
Posts: 843
Likes: 0
Received 0 Likes
on
0 Posts
You beat me to it Steve 
I cannot find a reference to the shutdown either only the load shedding.
Except the fuel system is really quite simple.....mechanically!
I cannot find a reference to the shutdown either only the load shedding.
Shows how difficult the B777 is for engineers.
I cannot see any reference to a 15 sec T/D or ELMS auto shut off.
Join Date: Jun 1997
Location: auckland, new zealand
Posts: 224
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.