Old Engineer

The fuel pump pictured at Post #1636, lower item in the sketches, is the scroll case (etc) housing for the pump impeller, as manufactured in the UK by Eaton Aerospace Ltd for the B777. The impeller is on the same shaft as the motor and part of that assembly which is not shown; it enters the pump housing from the left. The fuel inlet is axial from the right, and the fuel discharge is upward and turning to exit horizontally to the right. The maximum discharge pressure (at zero discharge) is 30.5 psig [pressure edited for particular pump used in 777-200 aircraft].

Its motor is 200 V, 400 Hz, 3 phase, [12000 rpm, explosion-proof, fuel-cooled, drawing nearly 9.5 amps approximately constant over all discharge rates from 0 to 40000 lb/hr at 12 psig--[correct option identified by edit and dc & var frequency options omitted as n/applicable]]. The printed flow rate maximum per pump is 35000 lbs/hr, which may account either for discharge backpressure in the piping of this particular airframe or for operation at altitude. The performance graph suggests a discharge pressure of 16 psig for this rate; the graph does not identify data as applying at standard conditions (ie, sealevel pressure, etc) as do some of the other graphs. Four such pumps are fitted to the aircraft when the Eaton equipment is used; they are each two-stage pumps. [Last three sentences specific to the Eaton application in the 777-200 were added by edit.]

The first fuel pump pictured at Post #1545 is a similar arrangement, but is shown opposite hand, and includes the motor, showing it assembled into the scroll casing of the pump (a note implies the impeller is in the motor area, but it would be in the area of the scroll casing, although it would disassemble attached to the motor assembly). There is a Goodrich Corporation fuel pump made in the USA for the B777; I assume this may be it, but my computer locked unable to read a PDF fueling brochure (I lack latest Acrobat reader). Of interest is that Goodrich makes FADECs and what they call an integrated fueling system.

I hope this info may be of help. Again, I don't know [whether Eaton or Goodrich equipment] is in this aircraft [reworded on edit]. Just an experience footnote, I used to design and troubleshoot hydrant fueling systems for both fighters and very large transports.

OE

DozyWannabe

My knowledge on the subject is admittedly 10 years old, but as I learnt it that statement is 100% correct. In addition to that, when the code is reviewed if even the slightest correlation in the two methods is found, the code is rejected and one or both of the teams has to rewrite it from scratch using a different methodology.

Pacplyer, I know you're aware of this but I can't emphasise enough that real-time and embedded software engineering is a completely separate discipline from application development, with a completely different definition of 'finished product'. I'm groping for an analogy here, so bear with me, but if application development could be described as an engineering discipline like building an F1 car (lots of whiz-bang features and cutting edge technology, but expected to only be used for a short period of time and to have frequent problems), then real-time software is more akin to engineering the Forth Bridge (old and proven technology, redundancy up the wazoo and designed to last for centuries if necessary).

dxzh

1. How much water would be needed to allow enough "icing" to develop in each of the relevant valves (mentioned by Top Bunk) sufficient to restrict them?

2. Is this really realistic given that the AAIB reported that there was no significant quantity of water in the main tanks?

3. If true, would the recognition of "icing" conditions in a turbulent fuel flow in or near these valves open up a Pandora's box, namely the much discounted possibility of ice forming elsewhere in the fuel supply system (eg at other valves or scavenge pump discharge outlets in the tanks)?

BOAC

Any 777 guys know what caused the a/p disconnect? Eg %Vs, stick shake, no more pitch authority etc etc?

ChristiaanJ

Not totally relevant to the cause of the crash, you'll admit.
But since we're now 83 pages into the subject... I was asking myself the same question as an A/P ancient, and maybe we can be allowed a post or two on that subject without being banned to JetBlast.
Alpha? Or one of the reasons you mentioned?

pacplyer

Good points Dozy,

I agree that's the time-tested ideal formula for success: split teams . What I worry about/suspect is corporate corner-cutting:

The finished product is handed off to another senior manager who knows one team has a better product than the other.... and starts rationalizing that since he already has redundancy and since the team B load became ultra stable and has never crashed.. why take a chance on the "A team" screwing up a reliable product.....? (and no time to start over with a third team...)

Now if that were to happen (both A and B channels identical stable code,) you could be facing an unlikely dual-bug-crash should Murphy's Law present itself.

This is all, an improbable, 100% fictitious example on my part, but: recall others in the industry in this thread have voiced concern that we are already into a highly unlikely probability with this double engine failure in of itself.

The reason I discount LP side fuel problems (by themselves) is that Boeing had experience with long range 747SP's that stayed aloft for 18 hours for over thirty years without cold-soaking tank issues leading to multiple engine failure (to my knowledge.) Lots of pumps would have to fail (or already be defered) to loose tank to engine LP fuel feed right? And cavitating pumps were not unheard of in Boeing fuel systems. Various baffle mods and other fixes were put out if my memory serves.

And in the Case of BA038 the suction/grav feed fuel source should have backed it up on at least one side... wouldn't you think?

What about a compound problem? Momentary system selection of dry tanks (slug of water/ice) followed by a FADEC that couldn't resolve conflicting code since it's signal sensors got frozen like the GE engines did.

The FADEC turns into a HAL-9000 so to speak. (I'm sorry Dave, I'm afraid I can't allow you to do that.")

This might be a scenario where this particular subroutine of the software is unknowingly unable to cope with a fuel source interruption of some type since it is faked-out by a frozen FADEC signal sensor and causes the software to stay in it's current state (idle) since it couldn't interpret either corruption in the software load or non-sensical FADEC signal data. While maybe not technically a "rollback" (because we're already at idle,) the result is the same: a temporary loss of engine control.

Refresh my memory here: were the RR and GE development programs a cooperative effort for this class of engine? I can't remember now...

Anybody feel free to comment; I won't bite you today.....

Green-dot

Such as temporary, uncommanded closing of the spar valves perhaps?

In the Questions section of PPRune an incident was briefly posted regarding a B757 with an engine rollback immediately after take-off. The C/B of the spar valve for the affected engine had tripped but was ok when scanning the breakers during preflight. Any one have any information about the outcome of that incident? As far as i know, no other replies were added to that post after i made the suggestion about a possible uncommanded closure in that incident.

Here is a link to that post:

http://www.pprune.org/forums/questio...-back-t-o.html


Regards,
Green-dot

phil gollin

For those people who have jumped with interest on the possibility of looking at a valve in the fuel pump(s) - I would ask how they explain the almost exactly simultaneous occurance of this previously unrecorded (?) problem in two separate pumps (albeit working in similar conditions) and the even more remarkable fact that the power (i.e. fuel passing) ended up almost exactly the same through both affected pumps.

If this was a single incident the pump theory might well be worth looking at. However, the real problem is the simultaneous, and almost completely similar, effects on both engines/fuel systems.

.

DozyWannabe

Again, it's a completely different kettle of fish to your average bit of Silicon Valley skullduggery. If your hypothetical "senior manager" did that, then the person cross-checking *his* work would reject the code and send it back. Real-time software as it applies to aviation is treated in much the same way as flying the thing. *Everything* is cross-checked at least twice as I understand it.

Us software folk (even lowly app developers like myself) have enough problems with people's distrust of computers without shooting ourselves in the foot like that! You may hear stories of cutting corners in the non-safety-critical world, but even there we're constantly trying to make it harder to turn in bad code. Real-time developers are probably the strictest when it comes to adhering strictly to engineering principles of any of us.

TopBunk

Re my previous post (8/8 @ 1825):

I have been at work for the last few days. I will see is I can get any more specific details from my source. It may take a few days. I will report back.

Bis47

Airframe manufacturers DID cut corners in the past.
[Documented facts ... with authorities complicity]

Airbus software got thousands of "improvements" along the years ... Improvements, or corrections? An sure enough, the specs were not set with proper user inputs ...

Business is business ...

Herc708

The typical scenario for a software development like this is :
- original design has all the bells and whistles required and will be developed by two seperate software teams, full system testing of all paths will be achieved
- schedule starts to slip, new project manager brought in, functionality now reduced to 'basic system only' but still retain two seperate development teams as this is critical
- schedule slips further, decision taken to have single software development team but increase the level of testing substantially to mitigate against the loss of the second independent development team
- development is now on critical path, is very late, no chance of meeting schedule dates, functionality of basic system reduced to bare basics, extra testing abandoned, only minimum testing achieved
- product delivered but the functionality bares no resemblance to what was originally planned and does not meet the quality requirements set out at the start

DozyWannabe

Herc708:
Do you have a source for that, or have you merely grafted cherry-picked details of real-time development (like two separate teams) and applied them to a rant about software application development you found on the internet?

Bis47:
I presume you're referring to the DC-10 cargo door incidents, or possibly the Comet 1- in both cases those are down to an insufficient level of understanding of a systems-level failure (the door failing, causing the floor to fail and take the cables and hydraulic lines with it in the case of the former, and the fuselage being stress-tested in sections but never as a whole in the case of the latter). In the case of safety-critical software, systems-level failure is something that was understood from the get-go.

Again I'm groping for an analogy, but the level of discipline required for application development as compared to safety-critical real-time software is like comparing the discipline levels of an occasional Sunday jogger to an Olympic-level marathon runner.

And the "improvements" to the software (just as with airframe hardware) come from lessons learned while flying the line. No airframe, whether controlled by string and pulley, hydraulics or FBW has got it right straight from launch.

(Waits for 411A to post "But the TriStar...." )

bsieker

Herc708,

This hardly merits an answer, I think DozyWannabe got it right.

Your rant has absolutely nothing to do with real-time safety-critical embedded systems development. To start with, such software is never specified with "Bells and Whistles", and there is no way it can be delivered performing something different than what it was originally designed, specified and contracted to do.

What is originally specified is what it must do, the engine will not work if it does any less (barring requirements and specification errors, which do occur). And the fact that engines usually do work, incredibly reliably compared to previous generations, speaks for itself.


'nuff said.

Bernd

pacplyer

Err, Dozy, bis47 said software problems; not hardware problems like doors.

bis47

The quote below is from Wikipedia on aerospace software development problems where mysterious software "new loads" showed up on everybody's airbuses due to non-responsive engines reportedly before/after this accident

Air France Flight 296 - Wikipedia, the free encyclopedia
.

Any assertion that software development teams can't make development mistakes is patently absurd. Anybody who's subscribed to AW&ST knows aerospace has experienced a lot of these over the years. Even NASA lost two mars missions due to schoolboy errors in not converting values.

Here is the video of the Tourlouse, Frace A320 accident in 1988. Although denied by airbus, the crew stated in AW&ST in 1995 that they shoved the power all the way to the firewall and nothing happened. If this had been a cable 747-200 everybody would have lived, because it wasn't up to a fadec computer to schedule a gradual EGT longevity spoolup. Also considerable overboost to clear the trees is possible with the old hydro-mechanical cable design.

Overboost for emergencies is not possible with FADEC. Better to cook the motors and clear the trees imho. But your HAL-9000 FADEC doesn't know that.

YouTube - A320 Airbus Down (2 of 2) (Mulhouse, France - 1988)

The above post is all just my opinions only.

DozyWannabe

I never made that claim. However the chance of software produced by two independent teams who have submitted two *completely* different implementations coming up with the same erroneous value has to be considered pretty damn remote.

Not to disrespect NASA, but I think their coding standards were far less stringent than the teams writing Airbus and Boeing's control software.

And the old Airbus-Habsheim debate has been done to death. The crew screwed up. M.Asseline was way below alpha-floor protection height and the delay in spool-up time was caused *not* by the FADEC control commanding a gradual thrust increase (otherwise you'd have had multiple fatal failed go-arounds by now), but because the A320 uses high-bypass engines that do take a few seconds to spool up compared to the older low-bypass type. M.Asseline should have aborted the pass the second he went under 100ft RA.

The FBW protections did actually keep the A320 level when it hit the trees. Not only would a 747-200 not have survived a similar incident (it would never have been able to make that maneouvre in the first place - hence why Airbus were so keen on that demonstration), but without the protections the A320 had it would have probably augered into the trees wing-down and killed everyone.

Chris Scott

pacplyer,

I'm going to be a bit kinder to your post than CJ has been, particularly as you have promised not to bite. DozyWannabe has nicely summarised the main points of the A320 accident you have cited, but I hope he and the moderators will forgive me for commenting on your argument in greater detail, as your post demands.

You shouldn't believe everything you read in Wikipedia, and your quoted phrase from an AW&ST interview with the crew about 7 years after the accident is fairly meaningless, taken out of context.

Although I was flying A320s for another airline at the time (Summer 1988) of the Air France accident to which you refer – it was actually at a small airstrip at Habsheim, near Basel/Mulhouse – I was not aware of the OEBs referred to. I do not recall any prior or subsequent warning of "engine acceleration deficiency at low altitude". [I presume "altitude" means "height".] The other quoted OEB refers to barometric altitude, which is irrelevant to A/Thr or FADEC operation.

The captain evidently decided to manoeuvre the aircraft deliberately into a part of the flight envelope from which he believed it would extract itself automatically, using its unique (at the time) combination of FBW and A/Thr flight-envelope protections. The crew were apparently unaware, despite clear references in the FCOM, that the A/Thr protective mode they relied on, known as Alpha-Floor (previously well-proven on the A310 and A300-600), is inhibited below 100ftRadio, to avoid undesired operation during landing. Wikipedia quotes the captain as asserting that the "altimeter read 100ft", despite video evidence that the plane was as low as 30ft. It does not say which altimeter. We were certainly not experiencing any problems with our RadAlts over paved or unpaved surfaces. If it was the barometric altimeter, then it was the wrong one to be using (as I don't have to remind you), even if it was set to a correct QFE.

The crew would have clearly seen, despite the increasing pitch angle, that they were flying roughly level with the approaching tree tops, so they could hardly have thought they were above 100ft. Because the approach had been rushed, the thrust was still at idle, judging from the sound track of the video.

At some stage, as the trees loomed nearer, it was realised that Alpha-Floor was not providing the sudden command of TOGA thrust that they had relied on, so they "fire-walled" the throttles. The main question is: did the FADEC unnecessarily limit the engines' acceleration from whichever idle mode they were in (gear and flaps extended).

Because of the abysmal way the investigation was handled, we may never know for sure. But from the sound track, the acceleration sounds normal enough. The aeroplane was at or close to Alpha Max (just below the stall). I'm sure you are well familiar with the swing we used to get on take-off on airplanes like the 707 if we failed to "stand up" the thrust levers to let the engines stabilise at 1.2EPR (JT3D) before selecting take-off thrust (does it also happen on 747 Classics?). Now apply that swing to an incipient stall situation.

The programmed acceleration provided by the FADECs may have prevented a yaw-induced wing drop near the stall. [The FBW prevented a stall into the tree tops, ensuring the nose did not drop much, and the wings remained level.]

[If you want more information on Alpha-Floor logic and the Habsheim accident, you could start by looking at this link]:
http://www.pprune.org/forums/tech-lo...ml#post3973073


Although a spontaneous FADEC malfunction could have been responsible for the failure of an engine to accelerate in the BA038 accident, whatever unprecedented series of coding that produced the error is unlikely to have been replicated 0 – 8 seconds later in the other engine's FADEC, as phil gollin and many others have previously commented in relation to various failure mechanisms.

pacplyer

Good points everybody.

Chris Scott: good post. Our posts crossed at the same time. Glad to have an A320 driver here; my understanding of level change is limited to the predecessor A300 series; I could very well be wrong about everything here. Thanks for the link I'll read it.

Dozy said:
Dozy;
Corvair automobile owners screwed up and crashed, but it doesn't follow that the design that Ralph Nader finally got killed was faultless. This over-reliance on confusing automation is what caused the above airbus A320 accident, and not the old catch-all refrain "pilot error" imho.

These were experienced airbus [test?] pilots. The only screw up the crew made was not distrusting the automation sooner and switching to full manual early (which is what we are trained to do now.) The problem was that by the time they got done trying to analyze why the automation was not promptly applying climb thrust, it was [nearly] impossible (behind the power curve) to clear those trees even with GA thrust applied. They did override the throttles (about) four seconds prior to impact but [prompt climb] thrust had previously been rejected by FADEC in favor of a gradual level change/slow spool up routine. I've used this "level change" mode a million times on A300's. Nearly always (back then) in "level change" mode [when the machine has a small change in altitude sitting in the alt sel window], a two to four second delay would happen before you saw any appreciable power come up at all. Then you still had to wait another ~five or six seconds before target power showed up. It used to be a lot worse before the software changes came out. Still these are modes that you don't want to be in close to the ground even though airbus didn't used to have any restrictions on it.

747-100's & 200's have had thousands of super low & slow flybys and not one has ever failed to command all the thrust you can handle in six seconds. It has nothing to do with different types of engines or spool up times. Those were also high-bypass ratio engines that required a "flight idle" to get you out of bad go around situations.

Naaaa. A 741 or 742 would have never got that slow in the first place because the autopilot was not certified to be engaged below mins except on approach and the AOA is not in charge. A hand flying pilot would feel the required backpressure happening on the yoke and do something about it. The autopilot doesn't possess this airmanship "cowboy" instinct at all (regards to christianj). I don't think the hand-flown A320 sidestick provides a backpressure "feel" does it? In the 747 case, immediate overboost thrust and intentional flight below stick-shaker momentarily to clear trees is possible (like in modern wind shear training.) These "coffin corner" non-book emergency actions (over-boost and momentary extremely high deck angle in ground effect) are not available in the A320 if I understand the limits of FBW combined with FADEC. BTW, we did use them to escape FAA "non-survivable" t/o wind shear down-burst scenarios in the 727, 747, DC10. Sometimes you missed the ground by a whisker and sometimes you weren't so lucky. At least you had that capability if it was needed.

[Down low] Alpha Floor flight is dangerous with the level change mode and should never have even been attempted (we know now of course; and IF that's what actually happened.) There's the possibility that he was in "thrust latch" (A/T mode) at some point: but he stated that nothing happened so he cycled the thrust levers.

The problem with aerospace programers is they think they can anticipate every eventuality and therefore a pilot is just redundant. But what happens when the [Baro] altimeter malfunctions in this case as corrective airbus 320 directives allege it was (according to Wikipedia's et al contributors?) [You fly off the baro altimeter right?, the RA is just a backup.]

Now you don't get prompt power applied on a toga button push and the trees are coming up.

Not to say that a software corruption is what caused BA038. Just making the point that the FADEC between the hand and the spray nozzels is one more weak link that the PIC must use in an emergency GA whether he likes it or not.

Will it work? I know a steel cable will because I just used it hand flying the descent.

skridlov

Quote:
"However the chance of software produced by two independent teams who have submitted two *completely* different implementations coming up with the same erroneous value has to be considered pretty damn remote."

My experience of software development is limited to non safety-critical applications (test and implementation of custom software in print media.) I am not, and have never been, in the aviation industry and I also lack formal training in computer science, so I'm excessively unqualified to make any kind of comment here... However I've heard it said that the above assumption is significantly undermined by a "common culture" shared by programmers.

Whether this gotcha is now compensated for by appropriate strategies, I have no idea, but it does seem to me a real hostage to fortune to assume that any area of human endeavour has reached the stage of unblemished perfection - least of all software!

DozyWannabe

Said by whom?

And no one was talking about software attaining perfection. Merely that the probability of two completely separate pieces of imperfect software prohibited from sharing any common logic coming up with the same computational error is extremely remote.

You're just going to have to trust me that the only thing that safety-critical software development has in common with what we, the public, encounter as 'computer software' daily is that it all works on binary logic eventually.

I cannot stress enough that the development process for saftey-critical real-time software is unique in the industry.