number_6

Thank you for that insight. The ATSB report just says that the auto-pilot disconnected, and the context caused me to interpret that the auto-pilot was unable to deal with the engine configuration. It sounded like the auto-pilot was causing the speed to drop to 1 knot below the desired speed, and was unable to increase the speed so it decided to disconnect (which isn't a happy situation).

From the ATSB report: "The PIC was aware that accurate speed control on final would be important to avoid either an aerodynamic stall condition, or a runway overrun. Consequently, the PIC set the thrust levers for Nos 1 and 4 engines to provide symmetric thrust, and controlled the aircraft’s speed with the thrust from No 3 engine.
The autopilot disconnected a couple of times during the early part of the approach as the speed reduced to 1 kt below the approach speed. The PIC initially acted to reconnect the autopilot but, when it disconnected again at about 1,000 ft, he elected to leave it disconnected and to fly the aircraft manually for the remainder of the approach. Due to the limited landing margin available, the CC reminded the PIC that the landing would have to be conducted with no flare14 and that there would be a slightly higher nose attitude on touchdown.
The flight crew briefed the cabin crew to prepare the cabin for a possible runway overrun and evacuation.
The aircraft touched down at 0346, the nosewheel touched down within about 6 seconds, and the PIC commenced maximum braking and selected reverse thrust on the No 3 engine. The flight crew observed that the deceleration appeared to be ‘slow’ in the initial landing roll, but that with maximum braking and reverse thrust, the aircraft began to slow. The PIC recalled feeling confident that, as the speed approached 60 kts, the aircraft would be able to stop in the remaining runway distance. In consequence, the No 3 engine was gradually moved out of maximum reverse thrust. Manual braking was continued and the aircraft came to a stop about 150 m from the end of the runway."

jb747

The autopilot handles engine out (multiple engine out actually) extremely well. Autopilot is available in alternate law I (but not II or direct law). You have to mentally separate the autopilot and the auto thrust. They are two separate systems, and many failure modes will affect one but not the other.

The autopilot, in either ALT mode, or APP mode will be using pitch to control altitude (ALT), or to control the glideslope (APP). Speed control via pitch control is not used in these modes...speed is controlled by power only, by the A/THR or by manual thrust lever positioning.

I'm not exactly sure which of the many 'trips' was causing the autopilot to disengage, but seeing it disengage as you hit a well marked speed bug would instantly alert you to the fact that it didn't like that speed. The problem in this instance is that the normal response of just going a bit faster wasn't desirable (you want as little energy as possible at touchdown). The approach speed chosen would still have had a large margin over the stall (20% or so), so flying manually and accepting a couple of knots below the target would be perfectly reasonable.

Whilst overweight landings are normally flown using the autopilot to touchdown, the autopilot cannot handle automatic landings in unusual slat/flap configurations (lots of reasons), so the landing would have ultimately had to be done manually. Automatic landings also tend to use up a couple of hundred metres of extra runway...another reason not to do it. When manually landing, there is no fixed rule as to when we disconnect the autopilot..anywhere below 1000' would be quite normal.

jb747

What crashes were they?

Your understanding of the A330 test crash is incorrect.

The most famous of the Airbus incidents involving the automatics were A300s, so FBW was not involved. In both of those cases, the pilots attempted to manually fly the aircraft in a go around, without disconnecting the autopilot.

Who said it was perfect?

number_6

June 1994 crash of A330-300 during testing of new flight control software. Airbus blamed it on "pilot error" which was bought by the French investigators. The actual cause was quite interesting, hence my knowledge of the case. The A330 was configured for extreme aft center of gravity, and they were testing engine out on takeoff. The autopilot performed the programmed ascent to 2000 feet but due to errors in software prioritized altitude over speed, and speed fell to 100 knots -- below the minimum control speed of 118 knots. This resulted in the plane starting to roll, which the crew tried to recover by reducing thrust since they thought the roll was from asymmetry with the engine out (true for older flight control software versions). The nose pitched down and it flew into the ground. The error is a classic problem: how to prioritize and integrate multiple problems, that can be parallel, orthogonal, converging or diverging. In 1994 Airbus got it wrong (but fixed it quite well, with no A330 crashes for the next decade). On the A380, there is the same problem but in different form: the many ECAM messages, many of them irrelevant or even conflicting with other messages. The software has to do better to prioritize and act on the most important factors first; still it is left as an exercise for the pilots to do, often by the seat of their pants and unaided by the ops manual. And this is 15 years later, with tens of thousands of man years of effort.

jb747

Like most accidents, that A330 crash had a lot of incidental inputs that let to the final result. Reading through the report, I see very little that says anything other than pilot error. They weren't flying it, and initiated a very critical test with the aircraft in an unstable situation.

If the aircraft starts to roll at a speed below Vmca1, I fail to see what else could be causing the roll other than the thrust asymmetry.

Whoever initiated the test had his eye well and truly off the ball, in not ensuring the aircraft was in the correct state for the test..that's basic test flying 101.

As for the presentation of multiple ECAM messages...I'd much rather the system gave me all of them, rather than relying on even more software and programming to sort them out. It's easy enough to get rid of messages, and you can even inhibit them entirely if you want. The problem with all of this is that we already have too much intervention from software, and software engineers, who seem hell bent on teaching me how to fly..even though they have no idea themselves.

number_6

That particular test required close to a year preparation to set up (as it included physical mods to the aircraft, such as water bladders in the tail to move to center of gravity, and was being flown by not just any test pilot, but the chief test pilot for Airbus, famously thorough and competent. Categorizing it as a poorly thought out and haphazard test would be unfair as well as misleading. In my reading the aircraft was in the correct state -- but the software didn't work as expected. Which led to all the subsequent problems, starting with autopilot being reluctant to engage and through to the induced stall. My point is that the software is causing problems in the man-machine interface which changes the ability of the pilot to fly the plane -- and even a very experienced pilot, with months of preparation and focus on a particular scenario, can be surprised by the outcome, to the extent of crashing the plane. I like to think that this is recognized as a problem and improvement is being worked on; but sometimes I wonder. So little progress, in so much time.

QF would be well served to evaluate all of the Airbus incidents in the past decade and learn from that in updating their ops manuals -- which have earned criticism in several ATSB reports now for being in need of update. Seems like a simple and easy to do task, just requiring funding, and able to leverage pilot abilities in magical ways.

jb747

Water bladders in a test aircraft are a pretty normal installation. And whilst the pilot may have been the chief test pilot, that does not make him immune to errors. I've flown with many test pilots over the years, and they are very good at analysing and recording everything that happens, but aren't necessarily any better at flying than anybody else.

Actually that is your wording, not mine. I said "They weren't flying it, and initiated a very critical test with the aircraft in an unstable situation.", and I'll stand by that.

A major tenet of test flying is the accurate, and repeatable, initiation of tests. You have to hit the numbers exactly, otherwise the test is valueless. Over-rotating the aircraft, and then having it flying directly into an autopilot capture region, at which point a number of competing actions are being performed by the electronics does not make for a stable test entry.

Before initiating the test (reducing the power on an engine) the aircraft should have been totally stable, and the captain should have ensured that.

Of course it was not in the correct state...it had been overrotated and then flown way too rapidly into the altitude capture area. Autpilots are always reluctant to engage in anything other than stable conditions...they are not there to fix your poor flying.

Qantas uses the Airbus and Boeing manuals in an unadulterated form. They come straight from the maker, and are not changed all. There was a time in the past (10 plus years ago) when we did rewrite them, and they were vastly superior to the factory offerings. But, these days, even changing the spelling of one word (and the Airbus manual is full of Fringlish) requires a long drawn out process with the maker.

Which 'several' reports are they?

number_6

We have to go all the way back to Dec 13, 2010 for http://www.atsb.gov.au/publications/...-2008-003.aspx which includes in the summary: "The investigation identified a number of safety issues in regard to the protection of aircraft systems from liquids, and other factors including the provision of information to flight crews." and in the final report under Findings includes: "Significant safety issueThe flight crew quick reference handbook did not include sufficient information for
the flight crew to appropriately manage operations on standby power.
-
Action taken by the aircraft operator
As a result of this occurrence, the aircraft operator:
• evaluated the provision of additional formal guidance to 747-400 flight crew for operations on standby power, including a review of Section 6 – electrical of the non-normal checklist within the 747-400 quick reference handbook (QRH). On 30 April 2009, the aircraft operator reported that it did not plan any changes to the QRH unless recommended to do so by the aircraft manufacturer
• has drafted an addition to the 747-400 flight crew operations manual to provide guidance to flight crews on the effect and management of multiple AC electrical bus loss, including battery life, major systems affected, and recommended crew actions."

QF had to make a lot of changes in the past year due to that incident with a 744, including changing the repair/inspection process for A330s and B767s.

The pilot error in not declaring Pan or Mayday could have been serious (as well as additional error in not doing the correct post-landing check prior to taxi. Lots more to consider, but overall QF did well with this when it could have been much worse.

Good thing that ATSB publishes their reports, so pax can see what the airlines and manufacturers are doing (or not doing). Too bad that QF decided to limit discussion of this event to 744 pilots, when really all pilots would benefit from the core principles, at least to a level of being aware of the incident and the lessons learned from it. I am, as a pax, and would hope the pros would have a greater interest and understanding.

Globaliser

Nancy-Bird won't be back in service until February or March 2012: