TopBunk -- Curious if the removal or discharge (or both) check valves are the subject of deeper scrutiny.

http://i337.photobucket.com/albums/n...BoostPump1.jpg

If the boostpump discharge check valve or the inlet valve are suspect:

- That would suggest that all 4 boost pumps in the LH/RH main tanks failed to deliver due to above suspect reason (as explained by TopBunk) at almost the same time?

- What happened to suction feed in that case? That should have provided engine fuel feed in such a scenario. Certainly sufficiently enough with engines normally required to accelerate to somewhere above approach idle during adjustments on final approach in landing configuration.

By the way, the inlet valve (removal check valve) is a valve that closes when you remove the pump. This permits you to remove the pump when the tanks contain fuel. Therefore, i don't see how this particular valve could be a factor unless clogged with ice.


Green-dot

Not sure if this has been answered. The -400 is only EEC controlled, which, though a componenet of FADEC, is a little different on its own.

Green Dot, you are right. It's a pity Top Bunk's information is not more specific: perhaps it does in fact refer to the HP Pump (independently on each engine, with an interval of a mere 8 seconds). Hmmm.

By the way, I think you meant "gravity feed" rather than "suction feed"? Wasn't it you and Swedish Steve who proved a long time back in this thread that we are talking about wing tanks? And the aircraft was at sea-level, with plenty of atmospheric pressure available.

Quote from pacplayer [yesterday, 1212z]:
You keep talking about what fadec is designed to do from the factory. That's not the context of the conversation I was attempting to delve into. A rollback is a well-documented software created anomaly, as I understand it, in which, for whatever reason the fadec has either miscalculated the thrust solution (thinks it's at high power and stays at idle) or has had a dual failure of both channels and is presumably trying to reboot itself at idle (since both channels are susceptible to the same software bug.)
[Unquote]

I would be very surprised if both channels are susceptible to the same bug. Although Boeing decided not to follow Airbus's lead, I believe, in trying to create and segregate two independent software design teams, they would have done their utmost to avoid this obvious trap.

Chris

Vibration induced airlock?
 

Some years ago, a particular aircraft type with which I was involved, was experiencing false fuel indications. I observed research into this, which involved a transparent vessel of fuel being vibrated at various frequencies to represent vibration levels and frequencies seen in-flight.

When the vibration level was varied, it was possible to create what can only be described as a 'black hole', into which bubbles dissolved air from the surrounding fuel would head. Slight variation of the vibration level could make the 'black hole' move up or down in the fuel.

The supposition for our investigation was that if such a black hole occurred in a fuel probe stillwell, this could lead to a loss of signal and hence the erroneous level reading.

As I recall, the vibration levels in this case pretty well matched those seen when the aircraft throttled back from climb to cruise RPM, which tied in with the in-flight occurrences.

What I'm wondering is if a particular vibration level and rate of change could have caused a similar 'black hole' to occur near the fuel pick up point.

The fact that this event occurred on the final part of the flight, after the fuel had been 'degassed' of air in the cruise, would suggest not, and it seems highly improbable that it would occur in both wings at the same time, but if the system is symmetrical, who knows?

To Chris Scott:

The OEM AMM officially refers to it as the Engine Fuel Suction Feed.

Swedish Steve, CONF iture and I had analysed that there was sufficient fuel on board in the main tanks (wing tanks) and that the center tank was empty. Determining approx. volume by the area of frost on the wing lower surface and comparing it with the fuel quantity reading on the flight deck of another B777-200ER. See posts #844 thru #878 for details.


Green-dot

I apologize for yet another ignorant question (please delete if inappropriate). To get the fuel out of the tanks, air has to go in... What happens if that vent is obstructed? (Can it?)

In response to Pax2908; if the tank vent is blocked, the air pressure in the tank will drop, and probably result in at least partial deformation of the structure, as wings are not designed to be a vacuum chambers!

This is what happened to an HS125 with a blocked vent (type 'blocked' in the find box): www.flightsafety.org/fsd/fsd_jul02.pdf

pacplyer,
Your reply to Chris Scott makes me doubt your competence, if not your actual provenance and education....

Where I come from (admittedly some time ago), channel A and channel B software were maybe not actually written by two different companies, but definitely by two different teams, using different compilers, etc. etc.

"I submit that both channels use the same code."
If so, things have changed a long way from "my days", and maybe... "Houston, we have a problem"?
Duplicating a mistaek doesn't make it any less of a mistaek.

Duplex hardware monitoring works fine. The chances of any two op-amps, RAMs, PROMs, transistors, or whatever, failing identically, in the identical location in channel A and B are infinitesimal.
But if both channels run exactly the same crudware... when both of them execute exactly the same faulty instruction at the same time, no kind of monitoring is going to catch it.

I'm not suggesting this is really relevant to BA038. I DO think it's relevant to pacflyer's misinterpretation of software reliabilty.

CJ

Software
 

AAIB says the computers ordered the valves to open and the valves did open and were found open but the engines acted as if they didn't get fuel.

How is software relevant?

The "blocked vent" theory might be viable; there could be enough air entering the tanks to sustain the engines through TOD down to approach altitude, albeit at less-than-spec inlet pressure to the HP pumps.

But once the controls demanded accel in late approach, the blocked vents placed a real limitation on the amount of fuel delivered to the HP pumps. Ergo cavitation and failure to accel.

It might not be enough "vacuum" (i.e. tank pressure below ambient) to permanently deform the wing skins, but enough to starve the donks.

Quote from Green Dot:
The OEM AMM officially refers to it as the Engine Fuel Suction Feed.
[Unquote]

I stand corrected: thanks. The point I was trying to make was that, in the event of failure of all the tank pumps we are not actually relying – as you know better than I do – on the ability of the HP Pump to suck fuel from the wing tanks to the engine: gravity will do the job. On all the aircraft I flew with pylon-mounted engines, this mode of operation was known as gravity feed, not suction feed. I wonder why the B777 uses a different term.

Thanks also for the references to the posts in which you established beyond reasonable doubt that the wing tanks had plenty of fuel remaining: I remember the discussion only too well. It's worth mentioning that, if the remaining fuel had all been in the centre tank and the centre tank pumps had failed, the only possible way of getting fuel to the engines would be by suction. This was, however, plainly not the case.


pacplyer,

Suggest you read my post again more carefully?

Chris,

I misread you post, my apologies. I have deleted it.

ChristiaanJ,

Good post, that's what I wanted to know.

Sorry all, I was not quite myself last night.

Cheers

It doesn't! the same term is used for the 747 'Engine fuel suction feed' AMM 28-22
Better make that two blocked vents then because there is a NACA duct and flame arrestor on each wing. Plus of course the relief valves!:8

What's that a drawing of Machaca:confused: It doesn't look much like a triple seven BP housing...Try this:8:ok:http://img.photobucket.com/albums/v4...untitled-1.jpg
Incidently the outlet check valves have a habit of shedding the their 'rubber' face seals and are being modded for valves without the seal. Awkward but can be changed without going into the tank... After emptying of course:)

Booster pump discharge NRVs
 

SLF but 40 years operating pumps. Interesting comment on the discharge NRV.
When a Booster pump discharge NRV fails in service and the pump is stopped for operational reasons, what stops the flow of fuel from another booster pump in service from discharging its fuel back through the defective pump NRV and into the fuel tank? (Are there motorised discharge valves on each booster pump which close automatically when a booster pump stops?) In the oil busines this is know as pump cross circulation. It has happened many times and action similar to what you have mentioned taken to minimise the risk. In systems where a failure of this nature would be a life or process threatening event, two NRVs of different manufacture are mounted in series on the critical pump discharge.This cross circulation would also result in a very significant fall in the booster pump header discharge pressure.
Obviously if all booster pumps are running whilst A/C in flight, there would be no backflow and no prospect of fuel starvation to the HP pump from this NRV failure mode.

To be clear, if a scoop or flame arrestor becomes blocked, a pressure relief valve in the surge tank opens to make a vent.

There is a pressure relief valve in the inboard access door of each purge tank.

The pressure relief valve is normally closed. When it is closed, the valve is in line with the bottom of the wing. If a pressure difference opens the valve, it moves up as it opens. A spring holds the valve open until you close it. You have to pull a reset handle to move the valve back to the closed position.

When you do an inspection, you must look at the pressure relief valves to make sure they are closed. An open pressure relief valve is an indication of a blocked vent scoop or flame arrestor. The pressure relief valve can also open to relieve air or fuel pressure if there is too much pressure during refueling.

Sounds to me both the vent scoops/flame arrestors and pressure relief valve position are pre-flight/walk around items and should be snagged/corrected if any deviation from the normal was noticed.

Personally, while most issues focus on possible causes at subsystem level, i remain wondering if the cause to this accident should be viewed against the total scheme of things. Observing the aircraft as a whole with all systems interacting with each other. Why is no effort made to rebuild the original frame?

It is a unique opportunity with the aircraft relatively intact. Attach 2 serviceable engines (as far as the AAIB reports sofar engines are no suspect), re-attach the original gear, LRUs and wiring as much as feasible, put it on jacks and in the freezer, and do an air mode simulation with all systems operating and selected between TOD and moment of failure? Oh, and put the tail back on, the only reason i can figure why they took it off is either because it makes the frame sensitive to strong gusts or to remove the reference to the BA logo on it.

Who knows what such simulations may reveal?

Like i mentioned, just a personal thought.

Green-dot

Not BA's property anymore! As soon as the a/c was recovered the insurance co. payed out and the title changed hands. The fin was removed (by BA) at the request of the insurance co. so they could sell it. :suspect: and also to prevent the hulk from 'weathercocking'.
Only the trouble is the fuel manifolding has been removed.:8

When they have tested it and find absolutely nothing out of the ordinary with it, they can put it all back in. :ok:


Green-dot

UK & USA centrifugal (LP) fuel pumps
 

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

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).

"Icing" in valves theory
 

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)?

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

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?

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..... :E

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

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.

.

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.

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.

Corner cutting?
 

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 ...

Fuel System Software development
 

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

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...." ;) )

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

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. :uhoh:

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

The above post is all just my opinions only.

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.

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.

"Indictment of over reliance on automation" or "What's it doing now?"
 

:) 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. :eek:

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.

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!

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.