Early last year, the FAA revised the SIDs and STARs at Los Angeles KLAX airport. I don’t know if I had annual leave or missed any associated documentation, but it’s fair to say that as a fleet that basically operates into the East Coast of Australia and LAX exclusively – it was something of a baptism of fire. There are a number of issues that subsequently developed, and we’re actually grappling with the best way to deal with some of the issues that resulted, even today. Let’s head down the rabbit hole.

I’ve been looking at Cold Temperature Altimetry Corrections in anticipation of potentially operating into such environments again in the near future. While my professional past includes operating the 777 to Moscow, Baku, Seuol, Beijing and a few other cold temperature destinations – most of the last decade has been focussed on Australia, Los Angeles, and the UAE. As such it’s been quite a while since cold temperature corrections have reared their ugly head – let alone metric altimetry. To say I haven’t really missed them is understating it.

Update 26.Jun.17 : Correcting Altitudes on APV – a Cluster

This one’s for you, Alex AFR!

The last week has been a whirlwind of contradictory opinions and conflicting manufacturer and regulatory guidance in this area. I am now firmly of the belief that I have no answer to the following questions (but I’m continuing to chase down something concrete, and definitive).

EASA guidance (AMC CAT.OP.MPA.126 (d) (2) Ii) (B), recently published) specifically prohibits changes to the FAF/FAP and DA/H (as opposed to “Minima” which would include MDA). From this document, correction to altitudes is not required from (and including) the FAP through to the MAP. Prior to final approach and the missed approach still requires correction.

This document (2.6.1.5) assumes that cold temp corrections have been made to the DA/H on APV.

The documentation provided by two Middle Eastern airlines to their respective crews conforms to this guidance. A highly respected Asian carrier however still corrects the minima on APV. My own airline conforms to the EASA guidance – no correction.

Meanwhile, there are FAA and several other regulators to do provide guidance on correcting the minima for APV.

That said, if you do not correct the minima on APV, I cannot find documentation that guarantees terrain clearance in the transition from the temperature independent obstacle protected final approach slope – into the temperature sensitive, correction required missed approach. Hence if you don’t correct the minima on an APV, you will be lower on approach – are you guaranteed obstacle clearance as you transition into the missed approach, with it’s requirement to correct temperatures?

The Middle Eastern carriers correct minima at 0ºC and below; and Terminal, Initial, Intermediate, Final (where necessary) and Missed Approach altitudes at -30ºC and below – with no clear explanation of why temperatures in between are ignored. There is some justification for this in the Boeing FCOM – but I’m not convinced.

Additionally the question occurs that if you correct your Intermediate constraint on an APV, but not your Final Fix (Point) altitude, your FMC commands a steeper (non CDFA) descent on the approach, and takes you below the minimum altitude between the IF and FAF. This would seem to be a clear violation of approach altitude constraints, and it’s unclear to me how you are protected at this point by the final approach slope inherent in APV approach design …

And for Alex – on baro-compensated FMS such as the A380, what corrections are required at the FAP, Minima for APV approaches. The A380 presumeably is flying the temperature corrected slope, which means if you do not correct the minima, you’ll be flying further down that slope than you would in either an un-compenstated uncorrected APV or an ISA approach – that can’t be right, can it?

As you can see – THIS IS A CAN OF WORMS. I can’t believe that I’m struggling to understand and obtain clear guidance on something that we’ve been doing for Decades (at least). This is really pissing me off.

It’s possible that the latest documentation from EASA contains an error (that would be the simplest for me!); it’s also possible that the recent change from EASA corrects a previous error. Frack.

More to come … meanwhile …

I thought I had a pretty good grasp on the concept, but as I dove deeper down the rabbit hole and came up hard against the fundamentals of the FMC and VNAV PATH on final approach – I was back to basics in trying to sort out what is required. Fortunately, I had the help of good friends at several other airlines to aid me in my quest. While they have reviewed the following material – any mistakes in what comes next are mine.

As always, the following content is couched firmly in the area of my own “expertise” – Boeing, the B777(-300ER), my airline. Your mileage may vary – but as mentioned I have passed this in front of a number of other consummate professionals across the globe.

Cold Temperature Altimetry Corrections

Aircraft altimeters and altimetry systems are calibrated for ISA conditions. When the OAT deviates from ISA, an indication error occurs in the altimetry information provided to the pilots as well as the barometric altitude reference passed along to the FMC and other systems. The 777/FMC does not currently have the ability to correct for non-ISA temperature deviations.

Deviations from ISA in terms of Altimetry are referenced against a ground-based temperature source, typically the temperature on the ground at the departure or destination airport. While it may not be entirely accurate, a uniform deviation is assumed from the ground to the level of the aircraft.
The size of cold temperature altimetry errors is proportional to:

The degree of variation from ISA; and

The height of the altitude being corrected above the ground temperature source (above airport elevation).

As shown here from the Boeing FCOM Supplementary Procedures, for a fixed deviation from ISA the correction required increases with altitude. For a fixed altitude, the correction required increases with height above the airfield. Note that ATC provided radar vector altitudes do not require pilot correction for cold temperature corrections.

Warmer the ISA

In warmer than ISA conditions, the altimetry system under-reads. When the aircraft is flown by reference to a barometric source (whether driven by the pilot/autopilot using the altimeter or the FMC using a barometric reference) the aircraft is invariably actually higher than indicated on the altimeter. An approximate rule of thumb is 0.3º of slope for every 15º of temperature above ISA.

For a Non-Precision Approach (whether driven by the pilot/autopilot using the altimeter or the FMC using a barometric reference) the aircraft will be higher than indicated. Since the error decreases with descent, the height above a 3 degree slope decreases until the aircraft is only a few feet above the required threshold crossing height. In effect the aircraft starts the approach high, descending on a steeper effective angle than promulgated by the instrument approach, which results in slightly higher descent rates and less thrust required. If a visual guidance system is provided the indications will show high on slope to the threshold (see below).

For Precision Approaches (whether ILS or GNSS based), the aircraft flies the commanded 3 degree (or otherwise) slope down to the runway and threshold crossing height. For such approaches, the altimeter will under-read since the aircraft is actually on slope, but the altimetry indications are impacted by the ISA deviation. This is often noticed at the outer marker crossing height check during precision approaches to warmer temperature airports. The minima will require correction for cold temperatures unless RA based (see below).

Boeing do not require corrections for warmer than ISA temperatures, and this information is provided for guidance only.

Visual Slope Guidance

From a barometric based approach, in non-standard ISA conditions, the aircraft will be higher (warmer) or lower (colder) than the promulgated instrument approach and any provided visual approach slope guidance system. The height error decreases as the aircraft reduces height above the ground and the aircraft approximates a steeper (warmer) or flatter (colder) approach path, which is maintained to the threshold. This deviation from the visual guidance system approach angle will be reflected in the visual approach slope systems indications.

The values shown here are approximates for a PAPI system aligned at 3 degree slope and are for guidance only.

NOTE : THERE IS (A LOT) OF CONTRADICTORY GUIDANCE ON (NON) CORRECTING FAF/FAP AND MINIMA ON APV. I’LL UPDATE TO WHAT I FINALLY BELIEVE IS CORRECT (WITH REFERENCES) WHEN I KNOW WHAT I FINALLY BELIEVE IS CORRECT!

The exception to this is APV (APproach with Vertical guidance) such as RNAV GNSS/GPS with LNAV/VNAV DH minima and RNP AR / RNP LNAV-VNAV approaches. Such approaches come with an operating temperature range on the chart (usually a minimum but often a min and max OAT). Down to the minimum temperature specified, the FAF and Minima (DH) are protected by a sloped obstacle clearance surface (OCS). There is no need to correct the minima for colder temperature altimetry, down to the minimum temp specified on the chart.

Note that Radio Altimeter (RA) based minima do not require cold temperature corrections.

Basic Modes using FPA in Non-Standard ISA Temperatures

When Flight Path Angle (FPA) is used in non-standard ISA temperature conditions, a higher approach angle (warmer conditions) or lower approach angle (colder conditions) is required to commence an approach from an un-corrected initial altitude. This is typically required for NPAs in high temperatures. For low temperature corrected NPAs the promulgated glide path angle should be used with FPA since the aircraft is at the corrected height above the runway, despite the altimeter indications.

Colder Than ISA

Here we go …

In colder than ISA conditions, the altimetry system over-reads. When the aircraft is flown by reference to a barometric source (whether driven by the pilot/autopilot using the altimeter or the FMC using a barometric reference) the aircraft is invariably actually lower than indicated. This can lead to unsafe clearance from terrain in relation to all minimum safe altitudes in the departure, arrival, approach and missed approach phases of flight. Boeing requires low temperature corrections when the ambient airport temperature is at or below 0C

SIDs and STARs

Minimum Safe Altitudes (MSA), Lowest Safe Altitudes (LSALT) and minimum altitudes on SIDs and STARs may need to be corrected in cold (Airport Temp At/Below 0º C) conditions. Corrections are based on the Boeing FCOM SP chart with extrapolation in accordance with the guidance provided. Corrections are made based on the ambient airport temperature and the height of the minimum altitude above the airfield elevation. Deviations from charted altitude constraints due cold temperature corrections must be communicated to ATC. Note that some FMC constraints cannot be cold temperature corrected (such as conditional altitudes).

The FMC & VNAV PATH in Cold Temperatures

Outside of the CDU LEGS page final approach angle, the FMC drives VNAV vertical path commands through the use of the on-board barometric reference systems, which are subject to cold temperature errors. As such for all instrument approaches, if VNAV is going to be used the FMC LEGS page altitude constraints will require cold temperature corrections. Crew should appreciate the difference between adjusting these altitudes to ensure clearance from terrain (yellow ovals) vs restoring the programmed aircraft flight path to that intended by the approach design (yellow highlight).

Strictly speaking, the Boeing FCOM requires corrections to altitude constraints, although correcting crossing altitudes is a similar procedure. Deviations from ATC cleared altitudes for cold temperature corrections must be communicated to ATC.

Once past the FAF, the FMC follows a path dictated by the geometric angle indicated in the LEGS page, as restricted by any constraining higher altitude in the LEGS page. However the FMC is fundamentally a barometrically driven device, and while a geometric angle is indicated on the LEGS page, in fact the FMC converts this to a barometric path based on the end of path lateral and vertical co-ordinates. As such the FMC flies the LEGS page slope by reference to altimetry, and is subject to temperature error. Since this error is magnified by deviation from ISA and height above the airport:

In warmer conditions the FMC will start the final approach high, and fly a steeper slope.

In colder conditions, the FMC will start the final approach low and fly a flatter slope.

With corrected FAF (or later) altitude constraints, the FMC calculates a steeper approach angle to meet this increased constraint altitude requirement. Since the barometric temperature error reduces with descent, these corrections will result in the FMC approximating the original promulgated approach angle (while believing it is flying the steeper angle).

In Short :
While nominally on a glidepath – FMC / VNAV PTH flies a barometrically calculated glide path that is subject to non-ISA temperature altimetry error.

Approach with Vertical Guidance (APV) including RNP-AR

APV approaches differ from standard NPAs in that they are constructed similarly to precision approaches with a sloped Obstacle Assessment Surface (OCS) in the final approach, rather than the traditional step-down criteria shown on such charts. These approaches must be flown in LNAV and VNAV, typically to a Decision Altitude (DA) rather than an MDA.

When these approaches are flown in cold temperature conditions, the final approach slope altitudes do not require correction, and the approach is flown from a lower FAF altitude on a shallower approach. The instrument approach chart includes a minimum ambient (airport) temperature below which the lower, flatter approach is not guaranteed to be clear of the OCS. When the ambient (airport) temperature is below the charted minimum, a reversion to LNAV only minima is usually available – but the charted LNAV/VNAV minima must no be used.

NOTE : THERE IS (A LOT) OF CONTRADICTORY GUIDANCE ON (NON) CORRECTING FAF/FAP AND MINIMA ON APV. I’LL UPDATE TO WHAT I FINALLY BELIEVE IS CORRECT (WITH REFERENCES) WHEN I KNOW WHAT I FINALLY BELIEVE IS CORRECT!

For APV approaches, cold temperature corrections are required to all altitudes outside the final approach – IAF, IF and other constraints as well as the Missed Approach. The FAF constraint does not require correction, nor any altitude constraint in the LEGS page after the FAF down to the Missed Approach Point (MAP). The minima while technically a barometric reference (you’re looking at an Altimeter) is protected by the OCS and so therefore does not require correction. On an APV in a cold temperature environment, you’re making your Continue/Don’t decision at a similar geographic location to an ISA approach, closer to the ground – but still clear of terrain (down to the minimum temperature on the chart.

While it’s far too early to tell what actually happened, in light of EK521 it’s perhaps germane to re-visit a topic that I wrote about in my Procedures and Techniques document quite some time ago – the Rejected Landing. As a reminder – the text of that entry into my tome is below, along with Boeing’s paragraph from the FCTM.

The Boeing text on this fairly unique maneuver is pretty quick and bland. In no way does it hint at the hands and feet going everywhere this exercise can become when it’s taught to pilots during their initial training onto the aircraft type. I recently completed training this exercise in the simulator to two new Captains transferring onto the 777, and as always I ensured each trainee had at least two goes at it; one to make the mistakes; one to learn and apply the lessons; sometimes a third to turn it into a maneuver that holds no mystery and less challenge.

That’s both the beauty and the trap of the simulator. It’s actually quite a challenge to introduce this maneuver into a simulated training environment in such a way as to take the pilots under training by surprise. You’re not trying to do that in transition training anyway – the lesson plan in full is pre-briefed and the techniques and procedures that will be used in response to pre-programmed events discussed at length so that everyone involved can get the most from their time in this expensive device.

But when it comes to training qualified line pilots – being able to instill?parameters into a developing situation on an approach that will lead to a genuinely surprising need for a rejected landing maneuver is actually quite challenging. But that’s exactly what you need. When it comes to rejected landing – no line pilot is going to get a couple of goes at it to get it right in the aircraft; and when it comes, the requirement to perform the maneuver well enough may be a complete surprise.

A bounced landing in particular may well come off an unstable approach and therefore be a foreseeable incoming maneuver for the pilots concerned – but equally it can all go pear-shaped in the last 100 ft with wind and temperature shifts that take a slightly less aware pilot into the runway with some force – and probably back up again. Then you’re firmly in the potential rejected landing regime.

In some ways – much like AAR214 it is often the case that the automation is not the reliable friend in this scenario that it usually is for the pilots. Once you’ve touched down the inherent automation paradigm is slowing down and stopping. Given enough time on the ground (and?in fact, not all that much time) the spoilers deploy up off the wings to spoil lift and push the aircraft down onto the wheels, where the automatic braking is just about to kick in.

The TO/GA switches which would have initiated a go-around (commanding a Pitch UP indication and an actual Thrust Increase) only a few seconds before; are now disabled until the aircraft registers airborne again. Thus the pilots who are heavily reliant on the relatively automatic response to the TO/GA switches may not get what they have been trained to expect by practice and preaching.

But it’s still a Boeing.

Push the thrust levers forward – and there will be thrust.

Pull back on the controls – and the aircraft will pitch up if there’s any airspeed at all – even if there’s not quite enough airspeed yet; there’ll still be enough pitch up and start a pretty sprightly climb away from the ground.

But sometimes, we forget that – pushing the buttons we’ve been told to push and waiting for the Flight Director to tell us what to do now …

Procedures and Techniques : Rejected Landing Procedure

Boeing FCTM

A rejected landing is a manoeuvre performed when crew decide to action a go-around after the aircraft has touched down. The reasons for this are few, but included in them would be a late landing with potentially insufficient runway to complete the landing roll safely.

Note that this could occur after speed brake deployment, but prior to reverse thrust application. The application of the reversers commits the aircraft to the landing.

While the FCTM documents Go-Around after Touchdown, the following points should be noted about the Boeing procedure.

After touchdown, the TOGA switches will be inhibited ? thrust application will be fully manual (maximum thrust should be used) and the flight directors will not give correct indications until the TOGA switches are used airborne.

Be aware that the stabiliser trim may not be set correctly and control forces may be unusual during rotation.

Speed brakes will stow and auto brakes will deactivate when the thrust levers are advanced sufficiently.

A takeoff configuration warning is typically generated as the thrust is advanced with landing flap.

Once airborne, the TOGA switches should be selected to provide normal FMA/Flight Director/Auto Throttle go-around.

A question concerning a recent change to the missed approach procedures in Dubai UAE (OMDB) has raised some interesting points about the 777 in this flight regime – high thrust, low altitude, high pilot workload; and ATC procedures that would seem to be not too well thought out.

Specifically the new procedure introduces a not-above altitude of 1300 ft AMSL after going around from a near sea level Precision or GPS approach minimum (1000 ft missed approach climb).

As any pilot of a two engine jet aircraft can tell you – early level off’s in the missed approach are not a good thing. Typically anything below 3000 ft introduces a significant workload on the pilots – and that’s when the missed approach is straight ahead, the autopilot is engaged and the aircraft fully functional. Add some manual flight and a non-normal element to this … the SandPit Pilots must be just loving this new procedure in the simulators in Dubai. The French did an extensive study on errors made during the missed approach and the folly of low altitude requirements in the missed approach path was just one of their conclusions.

This new procedure initially tracks straight ahead from the Missed Approach Point (MAP) [That’s a good thing] to DB710; but requires the crew to level off at 1300 ft AMSL [Not so good]. It then requires level flight for approximately 3nm [Why? Why?] during which a turn must be commenced (at DB710), and the then finally the missed approach climb segment may be continued (from DB711) to the final Missed Approach Altitude (MAA) of 3000 ft AMSL.

Multiple altitude requirements in missed approaches are nothing new. Typically however they are must-reach-by or at-or-above requirements to ensure terrain clearance, rather than “Stop” altitudes like this one. I haven’t looked around for a while, but I can’t actually recall a missed approach quite like this one.

That’s why I jumped into the simulator today and ran through it, just to see what it looks like. Looking at the chart – it looks like a dog’s breakfast. Looking at it in the simulator – I was not disappointed.

There clearly must be a reason driving this procedure. For the life of me I can’t think of an obstacle related one, unless a Sheikh has placed a permanent hot air balloon at 2000 ft off the end of the runway to see the sights, one of which is watching aircraft sailing by under his balloon at 1300 ft. This is Dubai remember, it could happen.

I can only assume that this altitude requirement in some way keeps aircraft going round from tangling with aircraft either (a) going around; or (b) approaching in the opposite direction on the other runway. In either case it’s a poor excuse for the potential cluster this introduces into the flight deck.

Thrust, Lots of Thrust

The biggest problem with these early level offs is Thrust. The 777 Autothrottle is supposed to limit thrust on a two engine go-around from full thrust back to a setting that guarantees at least 2000 fpm. It does this very, very well. In fact it does this so well that you usually get well over 3500+ fpm by the time things have settled down, which by definition is at least 2000 fpm, but is not particularly helpful when you’re trying to keep control of your aircraft. You have to remember these engines are designed to lift 350 Tons of aircraft (with one engine failed). Lifting the aircraft’s 250 ton landing weight on both engines is an underwhelming task to say the least. All two engine aircraft are fundamentally overpowered right up until the point where one of the engines fail …

Additionally the link between the software of the Autothrottle and the software of the AFDS Takeoff Go-Around (TO/GA) and Altitude Capture (ALT) modes is a tenuous one – in fact there isn’t one really. As such each and every time I ran this scenario – unless the pilot intervened, the 1300 ft restriction was exceeded by at least 100 ft because there was simply too much thrust/energy for the autopilot to capture the altitude adequately. This probably won’t set off alarm bells in the ATC center or the airline Flight Data Monitoring (FDM) programs. But it doesn’t look good in the sim on your check.

The really cool thing is that after this minor bust you’re about 1300 feet above the ground shortly after a go around and sinking back down to your required altitude – you guessed it, several times the GPWS activated to give me a stern “DON’T SINK” caution. It’s a good thing really. Because I spend far too much time operating this aircraft safely within the best practice envelope, I just don’t get enough practice at listening to GPWS warnings. It’s nice to know I can go somewhere in the world and operate the aircraft as the manufacturer intended but still get to hear “DON’T SINK” after the go-around …

What to do?

Well, you have a couple of options, all based around manual flight intervention. You could disconnect the AP early in the maneuver and manually capture the altitude, avoiding the altitude bust. Nothing is for free however, your workload will increase significantly also increasing the likelihood of error. Meanwhile your thrust won’t be behaving any differently, so as you push forward manually on the flight controls to capture your altitude (giving your passengers a free roller-coaster feeling) you’re likely to get an small overspeed as the thrust levers struggle to catch up. Options to fix that include overriding the Autothrottle temporarily and reducing thrust to contain the speed/altitude – or going full manual on the thrust. You thought the workload was higher going manual early in the missed approach? How is it now? The truth is that there just isn’t a simple, appropriate fix to this problem – if there was, the Autopilot would have been able to do it.

When to Accelerate

With an intermediate level off prior to the final MAA, the question occurs – when will you accelerate and retract Flap? Initially the speed will be flown based on the approach speed, with one stage of flap retracted in the go-around maneuver. Hence you are typically flying at Flap 20 and you’re a few knots below Flap 20 minimum speed, which is considered acceptable when you have a massive amount of thrust on and you’re rocketing up for the sky. But since you have not reached the final MAA, most airlines will require their pilots to retain this slower speed to ensure terrain clearance in the subsequent sectors of the missed approach procedure until reaching MAA or an earlier altitude that guarantees terrain clearance. As discussed elsewhere, typically terrain clearance for intermediate acceleration in the missed approach is not assessed – and there’s no indication that it has been assessed here. The presence of a 768 ft obstacle just at DB711 where you’re still held down at 1300 ft for no obvious reason isn’t encouraging. So the chances are you’ll want to retain your initial missed approach speed until you finally reach the MAA of 3000 ft AMSL.

But as your Autopilot Flight Director System (AFDS) captures 1300 feet as set in the Mode Control Panel (MCP) Altitude Selector – the speed automatically jumps up and the aircraft accelerates away, taking the decision away from the unaware pilot. Thrust – which is already very high for a 1000 ft altitude change – now increases as it’s released from the shackles of only needing to provide at least 2000 fpm, and instead drives to full GA thrust in order to accelerate the the Flap limit speed. Given this occurs as you’re still trying to level at 1300 ft – you can see why the altitude bust keeps occurring.

In any case – since most international airlines do not accelerate in the missed approach until reaching either MAA or a point at which terrain clearance is assured – you will NOT want to let the aircraft accelerate. This means winding the speed back after ALT capture; the later you managed to do this, the longer you’ll be under large thrust settings.

It’s worth noting that any physical change in the MCP Selected Speed after the TO/GA mode has been activated dis-arms the speed jump up when ALT captures. I demonstrated this several time today. Once estalbished safely in the go-around (Flight Mode Annunciator (FMA) modes verified; positive climb; Gear Up) – when the “Four Hundred” foot call was made I reached up and increased the selected speed by one knot. With this done, the speed remains at go-around speed when the AFDS ALT captures. This technique works even if you change the speed and then reset it to the initial go-around speed; or simply set it to the minimum speed for your go-around flap setting (Flap 20 or Flap 5) for a more comfortable level segment at 1300 ft.

Missed Approach Commenced Above MAA

In my Procedures and Techniques document, I have a small paragraph on commencing the Missed Approach from above MAA and a suggested technique for it – we experience this occasionally in KLAX where the approaches often commence from 4000 ft – but the MAA is 2000 ft.

When commencing a missed approach like this one where you’re actually higher than an altitude requirement – the standard procedure of TO/GA, Pitch/Thrust, Gear won’t help – you actually want to continue the descent down the approach to the altitude restriction (1300 ft). For a precision approach the priority is to de-select Approach (APP) mode. By design an engaged APP mode will fly you straight through your 1300 ft requirement.

Additionally if you’re in APP?mode at 1500 ft it locks in and you’re only way out of LOC/GS at that point is to disconnect the Autopilot AND cycle both Flight Directors OFF. Having de-selected APP the AFDS should be in HDG/TRK and VS. Laterally LNAV is probably the best choice (is your active waypoint ahead of you?), and VS will suit you fine until you capture either MAA or the lower requirement (in this case the 1300 ft). If you’re capturing MAA (such as in KLAX) you now have the option of accelerating and cleaning up. But for this strange procedure – you may need to maintain your approach speed flying level until you eventually reach the final MAA of 3000 ft. Don’t forget to raise the gear at some point …

In Summary

In summary – odd procedures like this expose some of the limitations of our aircraft, it’s systems and our procedures. It’s worth running a few of these low altitude captures next time you’re in the simulator.

Finally – a recent NOTAM indicates that UAE ATC may have had a change of perspective on this procedure. Whether this comes from operational experience and results in a permanent change – we’ll have to wait until the next documentation cycle to find out.

Many years ago when I was a junior FO new to the 777, I did one of my first recurrent checks in the simulator with an Examiner who started asking questions about the takeoff inhibits system. After several such questions – of both the Captain and myself – it became increasingly apparent that not only did we not seem to have the fullest of understanding of the in’s and out’s of this system, but that the Examiner himself was something of an expert. To my increasingly widening eyes he regurgitated fact after factoid as to the intricacies of this system, drawing a diagram on the board of such breadth and depth of complexity that by the time he was done, the result was unrecognizable as anything that could possibly relate to a system existing on this planet, let alone anything on board the aircraft. After it was over, I thought to myself “Man, this guy really knows the 777 inside and out. He Is Awesome.”

Now, I know better.

This particular Examiner missed the point. While the Boeing transition course, and the associated documentation explains the system in detail – the value of this system is in not needing to know the nitty gritty. The reason this system is in place is to keep the detail away from the pilot’s attention during critical phases of flight – such as high speed takeoff – and only present just what you really must know in order to make simple what would otherwise be a complex decision at high speed during a time critical phase of high stress. Unfortunately that wasn’t communicated to me at that time, nor was it communicated 6 months later when I did another check with the same Examiner, nor even the time after that. I finally realised that this display wasn’t being done to teach me anything in particular (or at least not anything useful); it wasn’t even being done to demonstrate my lack of knowledge or lack of commitment to excellence (even though it seemed that way at the time); it was done to show me the extensive repertoire of nonsense that this gentlemen had command of, along with a very firm grasp of the non-essentials.

So when I was asked about this recently during a briefing I was conducting for a sim check on two pilots – I brought out my diagram …

I showed this on the screen, and told the candidates they had a couple of minutes it memorise it before I start asking questions. Not.

The EICAS alerting inhibit system – specifically referring to takeoff – exists to be used practically to determine:

What to reject the takeoff for at Low Speed (nominally less than 80 knots); and

What to reject the takeoff for at High Speed.

In spite of the excessive focus given to this system by some Examiners, the system itself is not a memorisation item. Some things are worth nothing from the diagram above however:

For the most part the EICAS Warning/Caution messages are not inhibited during takeoff and will display during the takeoff in association with the malfunction/failure.

The Master Warning/Caution Lights and Aurals are inhibited from before V1 (Decision speed) until 400 ft / 20 seconds after liftoff.

Generally speaking alerts that commence before an inhibit is reached will continue to show/sound after the inhibit subsequently commences. It’s a clue that you shouldn’t be carrying low speed failures into the high speed regime, essentially.

Pilots (Captains!) should be particularly aware that the CABIN ALERT Com message and the associated Hi/Lo Chime is not inhibited at all during takeoff. See at the bottom of this post.

So what do we stop for?

Low Speed (<80 Knots)

Low speed rejected takeoff’s are usually less critical and as such you’ll initiate a reject for less serious reasons. That doesn’t mean they’re not a handful.

My previous carrier had a policy for quite some time that all takeoff’s in minimum visibility were to be conducted with full thrust irrespective of the weight of the aircraft. The theory I guess was to minimise the time spent in the risk window racing down the runway in almost no visibility (125m), which is good as far as it goes …

In practice however, I sat beside a Captain once who was given a complete engine failure at about 50 knots in just such a scenario. At these speeds the autobrake does not arm, and the auto throttle is still actively engaged. He rejected the takeoff, closing the thrust levers, before reaching for the speedbrake. But he forgot to disconnect the autothrottle and so the levers advanced up again as he reached for the speedbrake lever. Being the big beast that it is, the still functioning non-failed GE90 777 engine had barely begun to spin down from it’s 115,000 pounds of thrust before the lever was back up again and thrust began to restore the barely previously left full power setting. Since at these speeds you’re well below VMCG (minimum speed for being able to steer the aircraft straight with large amounts of asymmetric thrust) – we were in the grass off to the side of runway before He (or I for that matter) could work out what was going on. A quick analysis, a reposition to the start of the runway, and we did it again. And I mean we did it again – off the side of the runway once more. After the third try, and the third attempt to mow grass with a 270 million dollar airliner – cooler heads prevailed and we took a break.

Here’s the good guts on a low speed reject.

High Speed Reject

High Speed Rejected Takeoff is an exercise in and of itself – practiced and perfected in no small degree during transition and upgrade training. Despite the veneer of calm professionalism pilots display at all times (which my wife calls my “air of authority” Ha!); the last thing we actually like doing is making really important decisions with serious outcomes during highly critical phases of flight – in a hurry. That’s why the inhibit system is so great – it reduces genuine complexity down to some fairly simple options.

Further …

Keen eyes will note that the CABIN ALERT chime (referred to as the PILOT ALERT by cabin crew) is not inhibited at all during takeoff – and neither is the associated Hi/Lo Chime. A useful exercise, to be followed by a consequence-free and open discussion afterwards, is the following I like to give to newish 777 Captains in “extra time” in the sim.

The PFD failure is nasty because the Captain/PF loses his/her primary reference for speeds, pitch, altitude, tracking – all that good stuff. If you haven’t had it before, it’s not a small thing. But two deep breathes and the 777 automatically switches the PFD across to the secondary screen and all is good again. Besides – you’ve been taught that unless the aeroplane talks to you during takeoff (Buzzer/Chime/Siren etc) – you shouldn’t stop.

Then the CABIN ALERT Hi/Lo Chime goes off. At this point, one of two things happen:

The Captain rejects the takeoff – “STOP!” After he’s closed the thrust levers, applying maximum braking (or at least he thinks he is); Raises the Speedbrake lever and applies full reverse; steers the centerline and brings 350,000 kg of aircraft and souls-on-board to a halt just short of the end of the runway, he picks up the intercom and hears the Cabin Crew at L5 asking the Cabin Crew at L1 where they should go to dinner tonight in LA … or …

The Captain continues the takeoff “GO!” … Once the takeoff is complete and the aircraft is clean and above terrain, he reaches down for the intercom and the Flight Manager informs him that there’s smoke everywhere through the cabin and it all started on the takeoff roll …

Despite the latter (nasty) scenario, the right decision is almost always to take the problem – whatever it is – into the air. While cabin crew are trained in the concept of sterile flight deck and are well drilled on not calling the flight deck for any reason during takeoff, mistakes are made and the chances are that any problem identified in the cabin – but not seen on the Flight Deck – at high speed is best taken into the air, rather than (potentially) off the end of the runway.

Addendum

Having read the post above, a friend of mine asked “We seems to have a lot of guys stop for bird strikes in the high speed region. No indications of fire or failure just a bloody great thump. What do you think?? By the book it’s a no no.”

Response

When you are operating smaller aircraft on longer runways – it can be hard to argue with success, right up until the point where someone rejects at high speed for a birdstrike that doesn’t impact the aircraft’s ability to fly, and that aircraft runs off the side or the end of the runway. Fundamentally if the aircraft is safe to fly and you’ve reached the high speed regime, the manufacturer (and almost without exception your Standards Department) wants you to take the aircraft – and the problem – into the air.

Taking the aircraft into the air from the high speed regime is something we do everyday – sometimes several times a day – as part of our business-as-usual operational practice. Stopping the aircraft from high speed within the confines of possibly not longitudinally but always laterally limited piece of pavement is something we practice perhaps twice a year, in the simulator only. It’s a high risk maneuver. As such I agree with the Manufacturer (easy course to take, I know) – unless the aircraft isn’t safe to fly – take the problem into the air.

In some ways this argument parallels a similar discussion regarding Unstable Approach (see Checking in the Aircraft). If you get down to 1000 ft and you’re not stable, but you soon will be, why can’t you continue past 1000 ft and go-around later if you have to. The answer is that policy compliance here is required at least in part for the big pictures of safe aircraft operations. It may be justifiable that for your situation on the day continuation might not be unsafe at all; it is undeniable that the policy of requiring all aircraft to plan and fly to meet stabilisation criteria, and go-around if they are not stable, has reduced the industry accident rate considerable.

Recently I saw a failure in the sim at high speed of the loss of 4 of the 6 tyres on the LH bogie in a 777. I am certainly not new to any of the seats in the sim, and despite the fact that I am fully cognizant that when it comes to noise and vibration the simulator just can’t reflect the true severity we will see in the aircraft when the real thing occurs – I was surprised at the level of noise and vibration this failure gave us in the sim. As the examiner – I fully expected the Captain to stop the aircraft as a result, which he did not. Speed still increasing, thrust still there – “Go!“. While it was was what I wanted to see, what I expected (theoretically) to see, it was definitely nice to watch.

The introduction of the [] VNAV STEP CLIMB checklist highlights procedural handling of EICAS/ECL and the management of enroute climbing in the aircraft.

The FMC schedules step climbs throughout the flight based on the settings in the Cruise Altitude (CRZ ALT), Step Size (STEP) and potentially Step To (STEP TO) fields based on the aircraft weight, actual/forecast wind and temperature data and speed schedule (usually cost index). Additionally climb steps can be placed on the LEGS page of the FMC to schedule climbs at geographical waypoints in the flight plan, rather than the optimal weight/speed/wind schedule predicted by the FMC. What this all means is that for a long flight the FMC assumes that you will be able to increase your altitude as the flight proceeds, and calculates ETA and Fuel at Destination accordingly.

I remember when I first checked out on the 777, standard practice in my airline at the time was to set the Step Size to Zero during pre-flight and keep it there. In this way the fuel/time predictions for destination would be based on not getting any climbs – after all, how can you predict time/fuel based on climbs you may not get? At the time this was considered “conservative” and therefore safer. For shorter flights this was indeed unnecessarily conservative. For longer flights, it meant operating for half the flight with an “INSUFFICIENT FUEL” message flooding the CDU scratchpad … eventually wiser heads prevailed and we returned Step Size to the default value – which at the time was ICAO.

The “risk” here is that you may not get the climb(s) you need, but the FMC continues to assume you will. Indeed, if you pass a step climb point and don’t get a clearance, the FMC continues to calculate time and fuel assuming you’re just about to start a climb to the next step. This has been part and parcel of FMC’s of this type for decades and pilots haven’t been overly burdened by the requirement to monitor flight progress, seek climbs appropriately and deal tactically/strategically when we don’t get them.

For whatever reason, Boeing have implemented an EICAS message when the FMC Step Climb point is passed without an associated climb. This message, rather than just prompting crew to seek a climb, also comes with a full EICAS NNM checklist – although how this can be called a non normal is beyond me.

Purportedly this iniative came from the FAA’s involvement in extending ETOPS approvals for the 777 beyond 180 minutes. Rumour has it the checklist will benefit from further refinement in future blockpoint updates.

Can’t come too soon …

Long haul pilots tend to be pro-active about climbing and often seek climbs prior to the recommended step climb point. This is usually in an effort to avoid being blocked from higher levels by the increasing numbers of other aircraft on the more common routes. If you can get up there earlier, you’re more likely to be the one blocking, rather than finding yourself blocked from those fuel saving altitudes. Do it too early though and you’re punishing yourself, with deviation from optimum altitude typically being a 2:1 ration against being high – that is, you are approximately equally less efficient being 2000 ft above your optimum level as you are being 4000 ft below it.

In any event – Since ideally we probably don’t want to run an entire NNM checklist everytime we pass a step climb point without actually starting a climb, there are now several unofficial habits I’m seeing creep in that are being driven by the inclusion of this checklist. This includes manually setting a step climb point a waypoint or three down route while you wait for a clearance to climb. This isn’t bad technique as it at least “resets the timer” for the prompt to remind you to climb, and is in fact one of the responses within the checklist itself. Which waypoint should you choose? Well, the next one would seem to be the most obvious, but otherwise – the next one where you change FIR to another ATC unit isn’t a bad choice either. Perhaps Auckland will be more pro-active than Nandi in getting you that climb …

Another is setting the step size to an increasing value, or to set the Step To altitude higher than 2000 (RVSM) or even 4000 (ICAO) to delay the climb reminder.

Another is to ignore the EICAS and leave the message there until you get your step climb. While definitely within the purview of the crew – this response doesn’t keep a clear EICAS which is something we actively encourage.

Another is to override the checklist instead of running it. This is definitely no recommended, since you’re effectively removing the checklist (if not the message) from serving it’s intended function – dealing with a situation on board the flight deck that the manufacturer has decided you shouldn’t be ignoring.

On top of these techniques is running with the actual checklist occurrence itself. As you can see the checklist is a essentially a decision tree that says

The last action in the actual checklist (Step Size Zero) of course removes all reminders that a step climb is ever going to be needed for the rest of the flight, and is typically only the relevant choice towards the end of the flight when you are either unable to obtain or decide you don’t need that last increase in altitude. Setting 0 in the Step Size too early in a long flight will give you a falsely low estimate of fuel on board at destination (which contrary to common belief may not be the most conservative indication); as well as potentially an inaccurate estimate of your arrival time. Finally – find yourself forced down this path early enough and your FMC will continually be telling you you have INSUFFICIENT FUEL all the way to your destination (or not); or at least until you do get a climb. And we’re back to my Airbus airline of the mid 90’s that couldn’t learn from it’s Boeing pilots.

In the end this conundrum of what action to take when you aren’t able to climb straight away – or at all – enroute is something pilots have be dealing with since ATC was invented. I’m not convinced we needed a checklist to highlight it to us.

With the airline industry moving progressively towards GPS and GPS Augmented based approaches and away from the more traditional ground based navigation aid approaches, the use of LNAV/VNAV – with all it’s eccentricities – are becoming the norm for many airlines, rather than the exception.

The boon of flying such approaches more often is that your crews develop a body of expertise, particularly in regards to those eccentricities – but at the same time you expose crews to the vagaries of approach types that were previously not the norm, and to some degree were perhaps not designed from the ground up to be a mainstream solution for approach and landing.

Note : Stating that “VNAV may not have been designed from the ground up to be a mainstream solution for instrument approach” may sound a little harsh – but can you really look at the full scope of VNAV and it’s implementation across the various phases of flight from Departure to Destination (and go-around) and not shake your head and asked if someone really designed it to be this way?

Case in point is the requirement to intercept a VNAV Path based approach from above the programmed slope. For pilots coming from a precision approach – intercepting an electronic glideslope from above is less than ideal, but a documented procedure in the Boeing FCTM using Vertical Speed (VS) is provided.

The fundamental underlying assumption of this capture maneuver however is that the AFDS Glideslope (GS) mode is armed and will capture as the aircraft closes in on the electronic glideslope from above, hence providing protection against a below path situation developing during what can be a high workload phase of flight. There is no such armed mode in relation to VNAV – it’s either engaged (VNAV SPD/PTH) – or it’s not. Hence using VS to capture VNAV PTH approach from above is not considered appropriate.

Instead VNAV SPD is used. In this context – where VNAV is selected when more than 150 ft above the programmed approach path – VNAV SPD is an idle thrust descent mode, and the elevators will command speed without deviation (as far as possible).

Once the thrust levers reach IDLE (or earlier, if the PF overrides the thrust setting) – the PF can vary the thrust to control the rate of descent. Unless the rate of descent is excessive in regards to your Airline’s maximum rate of descent in the terminal area, retaining idle is usually the norm. The more likely requirement is to increase the rate of descent to expedite descent on the Flight Management Computer (FMC) approach path – using judicious Speedbrake.

Note that the MCP Altitude Selector is still a command instrument in this case – if you fail to capture the approach path before the relevant point on the approach – you’ll end up with VNAV ALT capture (ie: VNAV wants to go somewhere, and the MCP ALT-itude selector is in the way …). The MCP Altitude Selector also interferes with the progression of the approach down final, resulting in a capture anytime you forget to set a lower altitude, or the Missed Approach Altitude once that setting becomes appropriate. Refer back to the previous note on the designed-from-the-ground-up-NOT comment on VNAV.

It can therefore be seen that VS is not an appropriate mode. While it gives more direct control of the rate of descent (which may well be desirable) – the inability to arm VNAV means that the PF would be required to select VNAV when approaching the path – exposing the aircraft to a below path scenario in the event of a distraction (when was the last time there was a distraction just before an instrument approach …)

An engine failure at altitude above the maximum engine out altitude, followed by the obligatory engine out drift down is a bread and butter event for a cruise pilot. Typically this is practiced and evaulated using the highest levels of automation in LNAV and VNAV. For more information see Engine Out Drift Down and the FMA. However the ability to execute this maneouvre using basic autopilot/flight director modes is occaisionally tested – and a useful procedure to have when VNAV fails to do what you expect …

There are a couple of reasons why you might find yourself with the requirement to initiate and manage a basic modes engine out drift down from altitude, including a failure of VNAV to behave as expected/required – but the most common reason is because a Check Captain asks you to.

Broadly speaking the procedure required falls into one of two possibilities – when the FMC VNAV Cruise page is available; or when it’s not. When the FMC is there to give you an altitude and speed to aim for, you set those as part of the procedure shown here. Otherwise initial values of FL150 (or higher if MSA requires) and Turbulence Penetration speed are used until these can be refined using the QRH Performance Inflight.

Once VNAV is out of the picture, there are only two modes available for the descent – Vertical Speed (VS) or Flight Level Change (FLCH).

VS would be a high workload solution since fundamentally you are looking for a speed targeting manoeuvre (which VS is not), and without the constant attention of the PF, VS at high altitudes can risk overspeed / underspeed excursions. Hence FLCH is the mode of choice for a basic modes drift down.

However since FLCH is an idle thrust mode and you want to minimise the rate of descent, the Autothrottle is disconnected and CON thrust is set manually. This is done using the Thrust Lever Autothrottle Disconnect Switches so as to leave the Autothrottle armed (not the MCP Autothrottle Arm Switches). Note that the Autothrottle is disconnected after FLCH is selected, since engaging FLCH after would re-engage the Autothrottle.

If the engine is actually failed (either EICAS [] ENG FAIL or the Fuel Control Switch in Cutoff) then when FLCH is selected, the CON thrust limit will be set, and the PF must move the thrust levers as required to maintain the CON thrust limit. If necessary, the CLB/CON switch should set CON thrust limit manually (but not not the actual thrust setting).

I’m working on an update to the Practices and Techniques document I developed in 2008. While this has been a published document in my airline for several years, it was recently taken offline and is now a training background reference, as was the original intention for it’s development. Just one of the many subjects beng added is a section on whether to Stand the Crew Up during a Non Normal on the ground. Most particularly applicable to a Rejected Takeoff – this issue is the cause for much discussion at times.

What’s been missing for our documentation for some time is decent diagrams showing the normal procedures flows. The B777 normal operation centers around these flows, and the normal procedure ECL checklists that follow. For Normal Operations – the ECL Checklist is a “Done” list, where all then items you run through on the checklist should be done before you open the checklist.

By far the most common error we see in the simulator in regard to the flows is forgetting to select the CHKL button at the appropriate time to display the next ECL normal checklist; closely followed by innapropriately displaying the checklist early.

Before Start Flow

The Before Start Flow is triggered once the CM2 has obtained Start/Push Clearance from ATC. During the flow the CM2 will action an EICAS Recall “Recall … Engine Shutdown“. CM1 responds “Cancel EICAS” to the message(s) read by CM2 this action triggers the associated CM1 Before Start Flow (Trims). At the end of the flow the CM1 calls for the “Before Start Checklist“. Once this is “Before Start Checklist Complete” the CM1 returns to the Ground Engineer and pushback/engine start commences.

Before Start Checklist

The Before Start Checklist is called for by the CM1 once the trims have been set in the CM1 Before Start Flow. This assumes the associated CM2 flow is complete and the Before Start Checklist has been displayed by the CM2.

Flight deck door is verified by a visual check of the door and door arming mechanism by the CM2 as well as the center console door locking mechanism indications.

MCP V2, HDG/TRK and ALT should be called as selected, and verified appropriate. This includes the V1 (PFD vs CDU), V2 as displayed on the PFD (not just the MCP/CDU), an appropriate heading/track selection for the departure, and an Altitude selection appropriate for the (expected/cleared) departure clearance.

T/O speeds are called as displayed on the CDU, but the V1 and the V2 should be verified on the PFD.

CDU pre-flight confirms the completion of the CDU Pre-Flight Procedure as well as the Final FMC Performance Entry procedure. CDU-L should be set to the TKOFF REF page and CDU-R should be set to RTE Page 2 in preparation for the Departure Review.

Fuel is read from the EICAS totalizer indication and no cross check against required fuel for departure (OFP) is scripted, although a mental check of this is a reasonable action.

Trim commences with the Stabiliser setting as required from CDU-L and indicated on the Stabilizer Position Indicator. Note that prior to the completion of aircraft loading the stabilizer green band segments may not indicate correctly.

After Start Flow

The after start sequence is initiated after the second engine start. The associated CM2 After Start Flow commences automatically once the second engine EGT Start Limit has been removed.

Before Taxi Checklist

The Before Taxi Checklist is called for by CM1 after pushback/engine start is complete, the Engineer is disconnected and the flaps/flight control check is complete. The CM2 After Start Flow completes with the display of the Before Taxi Checklist.

Anti-ice is called based on switch position as selected in the CM2 After Start Flow. Normally the challenge response would be “AUTO” but in icing conditions with the EAI selected on, the correct response would be “AUTO” (wing anti-ice), “ON” (left engine anti-ice), “ON” (right engine anti-ice).

The EICAS Recall completed during the After Start Flow indicates aircraft serviceability status for flight.

Ground equipment reflects the removal of pushback tug and personnel removed after pushback is complete. This check does not obviate the requirement to report Clear Left / Clear Right prior to aircraft taxi.

Departure Review

Once clear of congested areas and when workload is low, the PF will call for a Departure Review. This review of EFIS and other settings for the departure is conducted by the PM, and monitored by the PF during taxi. It completes with the display of the Before Takeoff Checklist (CHKL). WXR/TERR is only activated once CABIN READY has been received.

Before Takeoff Checklist

The Before Takeoff Checklist is displayed by the PM as part of the Departure Review flow. PF calls for the checklist once the Departure Review is complete and Cabin Ready has been received. The Before Takeoff Checklist can be done any time and does not need to be delayed until approaching the runway.

Takeoff Flaps setting is closed loop and defined by the entry on the CDU TAKEOFF REF page.

Cabin Ready displays on EICAS with a chime but is removed automatically after one minute.

Once Cabin Ready is received and the Departure Review complete, PF/PM will select WXR/TERR as appropriate. This is typically PF/WXR & PM/TERR however there is non restriction in both crew being WXR or TERR as appropriate for the specific threats of the departure.

After Takeoff Flow

The After Takeoff Flow is commenced once the Flaps are selected UP. The PM should ensure that the flight stage is appropriate – low workload, low distraction environment. The Flow and the subsequent After Takeoff Checklist can wait until immediate terrain and weather clearance is assured, ATC is quiet, traffic is light and the immediate demands of the SID (tracking, speed, altitude) are met.

The APU … OFF is only usually required after a Packs on APU takeoff.

Similarly the PACKS … ON is only required after a PACKS … OFF takeoff

Note that if a NNM has occurred during departure, the CHKL button should not be pushed as this would pre-empt the selection of a NNM checklist by the PF

After Takeoff Checklist

The After Takeoff Checklist is displayed by the PM once the Flaps are selected Up as part of the After Takeoff flow. PF calls for the checklist once the workload is low and the aircraft clear of terrain on departure. PF can use the removal of the Pitch Limit Indicators (PLI) from the PFD as a tip to call for the After Takeoff checklist – although at high weights at UP speed the PLIs may not be removed straight after flap retraction is complete because of proximity to the manoeuvre margin.

Descent Preparation

Descent preparation is typically conduct by the PF who may hand over control to complete the setup. As a guide, preparation consists of some or all of the following actions/considerations, in any order determined to be suitable.

Recall EICAS and Operational Notes.

Obtain ATIS and if appropriate, updated TAF for Destination and Alternate.

Review Taxi Route after landing in view of NOTAMS and likely parking stand.

Descent Checklist

The Descent Checklist is typically completed once the Arrival Briefing is completed. Like all normal checklists, the Descent Checklist is intended to be completed against actions that have been already completed.

Recall verifies the aircraft status for the approach and landing and should be completed prior to the preparation for descent and approach.

Similarly, Notes may contain restrictions or requirements that may well affect the choice of airport, runway or approach.

Autobrake is chosen after a Landing Performance Assessment.

Landing Checklist

The Landing Checklist is displayed by the PM after selecting Flap 20 (irrespective of the landing flap setting). When calling for the Landing Flap setting, PF will add a call to complete the Landing Checklist “Flap 30 … Landing Checklist“. These two SOP requirements are important barriers to forgetting to run the Landing Checklist.

After Landing Flow

The After Landing Flow is actioned once the aircraft has reached Taxi speed, cleared all active runways, and the crew have received, briefed and understood the subsequent Taxi Clearance from ATC. The flow is actioned by the CM1 stowing the Speedbrake Lever – CM1 should not take this action until the aforementioned have been done. Should the aircraft be required to hold between two active runways – the speedbrake lever can be stowed and the flow completed while waiting. The flow completes (as they all do) with the EFIS CHKL switch to display the After Landing Checklist on the ECL

After Landing Checklist

The After Landing Checklist is displayed as the last item in the After Landing flow. The trigger to commence the flow is CM1 stowing the Speedbrake Lever after landing – irrespective of which pilot is PF

The Speedbrake lever is stowed after landing by CM1 and commences the PM After Landing flow. CM1 should not stow the Speedbrake Lever until all active runways are cleared, taxi clearance is received and the taxi brief confirmed/updated. If the aircraft is required to stop/wait between active runways, the Speedbrake Lever can be stowed and the After Landing flow commenced.

Strobe lights are left/turned ON while crossing any active runway after landing.

Clearing the runway, the PF may call for the PM to select the ground maneouvre camera (CAM) onto the PM ND. Ideally the PF/PM should turn off the WXR on that side prior to displaying the CAM, since WXR cannot be deselected on that side once the CAM is displayed on the ND.

Crew should be aware that extensive taxi after landing with the Flaps fully extended can be taken as a sign by ATC, particularly if communications with ATC has not been established.

If TERR mode was in use on landing, this is deselected as part of the After Landing flow by the onside pilot.

While this flow commences with the APU, starting the APU is typically delayed until approaching stand. At approximately 2 minutes prior to parking on stand the APU is started and the After Landing Checklist called for and completed.

Occaisionally the taxi to stand after landing is extremely short. In this instance the crew should consider starting a clock once reverse thrust is deselected to provide a time for the minum engine cool down after landing (3 minutes). Starting the APU by recall late in the landing roll is usually a better choice rather than commencing the After Landing flow before receiving/briefing the taxi clearance.

Shutdown Flow

The CM2 Shutdown Flow commences once the N1s have reduce to 10% and CM1 switches the SEATBELT Signs … OFF.

Shutdown Checklist

The Shutdown Checklist is displayed as the last item in the Shutdown flow.

The Parking brake is an item where the required state is not scripted and the CM1 calls whether the Parking brake is Set or Released. That said, best practice is typically to delay commencement of this checklist until the the ground engineer has confirmed that chocks are in place and the Parking brake is released. Crew should be aware that leaving the aircraft with the Parking brake set and chocks not in place leaves the aircraft liable to roll on inclines once residual hydraulic press as bled away.

Secure Flow

The Secure Flow is actioned once all passengers have left the aircraft. However if you’re handing over to the next crew these actions may not be required.

Secure Checklist

The Secure Checklist is commenced once all passengers have left the aircraft, and is to be completed anytime a handover to the next operating crew is not possible.

We have no policy on the retention of the ADIRU state after shutdown since we currently dont operate any turn around flights. Other airliens typically leave the ADIRU on for times on ground of two hours or less, although cycling the ADIRU off for 30 seconds to force a realignment is standard practice.

Packs are typically turned OFF for most of Virgin Australia operations as part of the Secure Checklist. This includes warm/humid countries where leaving the Packs on can causing icing issues after longer peroids on ground.

I’m working on an update to the Practices and Techniques document I developed in 2008. While this has been a published document in my airline for several years, it was recently taken offline and is now a training background reference, as was the original intention for it’s development. Something that’s been missing for a while is some content on one of the bread and butter check/training events for cruise pilots – engine failure at altitude and the subsequent drift down descent.

The Airspeed Unreliable scenarios is one of the more challenging non normals faced by pilots in the simulator. Of the many serious malfunctions I’ve witnessed crew deal with in the simulator – this one more than any other has caught crew out to the point of a serious limitation exeedence (high/low airspeed) or potentially an airframe loss. In the real world, this failure has killed people in the past, with the Air Peru B757 accident being the most common one that comes to mind. However accident and incident statistics are replete with this outlier failure that has recently become a major focus of the world’s airline training systems, most especially after the loss of Air France 447 in the Atlantic.

While the Air France and Air Peru events were clearly accidents of the first order with significant loss of life – unreliable flight instruments malfunctions have cause significant loss of control incidents that were eventually recovered. The following text is taken from another incident report, where a fully functioning set of co-pilot (and presumeably standby instruments) remained available to both crew. In spite of this the aircraft suffered signficant deviations of flight path owing to a combination of the autoflight and pilot inputs.

At 2203 the captain’s airspeed indicator increased from 276 to 320 knots and the captains altimeter increased 450 feet in approximately 5 seconds. To re-capture altitude, the autopilot commanded pitch down approximately 2 degrees. An overspeed warning activated whereupon the captain retarded the throttles to idle. The autothrottles disconnected automatically but the autopilot remained engaged. The autopilot pitched down another 2 degrees before pitching up approximately 8 degrees. The overspeed warning remained on for about 41 seconds. The captain disengaged the autopilot and manually initiated a climb. Thrust remained at idle and the captains airspeed indicator decreased to 297 knots. The captain increased pitch to 12 degrees nose up, his airspeed indicator rapidly increased to 324 knots producing a second overspeed warning. The aircraft climbed to an altitude of approximately 35,400 feet above sea level (asl), then started to descend. The captain’s indicated airspeed reached a maximum of 339 knots, before decreasing as the aircraft started to descend.

The aircraft was descending through 34,700 feet asl with the captain’s airspeed indicator decreasing through 321 knots and the overspeed warning on when the stick shaker activated (a stall warning device that noisily shakes the pilots control column as the stalling angle of attack is neared). The overspeed warning remained on for the next 20 seconds, became intermittent for 26 seconds, then stopped. The stick shaker activated intermittently for about 1 minute and 50 seconds from its initial activation. When the aircraft had descended through approximately 30 000 feet asl with the captains airspeed indicating 278 knots, the captain increased thrust and within 9 seconds the stick shaker stopped. As the aircraft descended through 29,100 feet asl, the captain’s airspeed indicator rapidly decreased from 255 knots to 230 knots and the airspeed fluctuations stopped. The aircraft continued its descent to 27 900 feet.

Throughout this event, the first officer’s airspeed indicator displayed information that was not indicative of an overspeed event.

The point here is that to a fully qualified, current and experienced crew, this is a failure that can present a significant challenge to retaining flight control and returning the aircraft safely back to the ground. The benefit of simulator training in this area cannot be under-estimated. The two thrusts of this simulator training should be:

Recognition and initial control; and

The procedures and techniques that will be required to return the aircraft safely to the ground with erroneous flight instruments, in various weather conditions.

This latter point is crucial. While it’s absolutely imperative that such training give crew the skills to recognise this failure and respond appropriately to regain/maintain control of the aircraft – the challenge inherent in returning a modern glass jet aircraft to the ground without functional airspeed/altimeter readings cannot be understimated. Except of course the 787 and the pilots that fly it – where with the flick of a switch airspeed is calculated from angle of attack and is accurate to about 5 knots. B@st@rds.

Recency & the Retention of Manual Flight Skills

A (previously) unspoken impact on this failure is the effect of a lack of aircrew skills and recency on basic instrument interpretation and maniulative skills. What this means is, pilots who spend most of their time either watching the autopilot fly, or following what the flight director tells them to do are in a poor position when these two marvelous systems are not available. Compounding this are crew who either don’t fly very often, or get little opportunity for manual flight.

I myself am a product of what is perhaps the worst combination of the various factors that impact my skills and my recency to perform my most basic task – hand fly the aircraft.

While I learnt to fly on conventional instrumentation, I am fundamentally a child of the magenta line. My last 10,000 hours have been in EFIS glass flight deck Airbus/Boeing aircraft that were heavily automated, and typically subjected to airline automation policies that both encouraged the use of the highest levels of automation, and discouraged the practice of manual flight.

As a long haul pilot (all sectors 12+ hours, augmented crew) I typically fly perhaps twice a month, which means 4 sectors, two of which (if I’m lucky) where I get to be the handling pilot. If the weather is reasonable and the airspace/traffic conditions conducive, and my partner (and myself) sufficiently alert – I can do some manual flying. Typically I make every attempt to do so, but my experience of flying with and watching other crew fly – I find myself an outlier in this. Much of the flying I see is “200 ft to 200 ft” with the autopilot used to nearly the maximum extent possible.

Worse than this, I am a simulator instructor. Hence I fly slightly less than an average line pilot. Offsetting this is the fact that I have (limited) access to this fabulous million dollar toy in which I can practice my craft. Of course, things are never that simple and while our entire regulatory system is built around the concept that the simulator is just like the aircraft, I’ll let you in on a secret – it’s not. Coupled with this is the issue that while the ability to jump into the seat and do a takeoff or a landing to maintain/return legal recency is a simple thing – using the device properly to maintain the complete spectrum of of operational familiarty is not.

Finally – I’m a Check Captain, This means that if I’m rostered with 3 flights this month (and by implication no simulator access because my roster is full at that point), typically two of those flights will be sitting on the jump seat watching other pilots fly. While it was clear that such activities have a detrimental impact on manual flying skills, at least you were part of the operation and therefore gaining valueable experience of watching other operate. Or so we used to think …

All this means that I have precious little opportunity to maintain these skills, and practically none to develop them.

Current regulatory requirements state I must have done a takeoff and landing in the last 45 days. This takeoff/landing doesn’t have to be on the same flight, and it can be (and is) accomplished in the simulator.

Why is the Simulator Different?

I’ve hinted before that the simulator is not like the aircraft. Which is a strange thing to say, given that this multi million dollar device probably has hundreds of millions of dollars and decades of research making every effort into making it so. Well, from a technical point of view – it’s pretty good. The “feel” is not quite the same, but as a device that serves as a next-best alternative to the aircraft, it does a great job.

The problem is in the way we use it.

While the simulator functions quite well as a tool to emulate a suitable environment for maneouvre practice – takeoff, landing, engine failure, instrument approaches, missed approaches, etc. – the problem is that while you can be trained to demonstrate technical competency in these maneouvres – it’s pulling them all together in the line operational environment where the “simulation” falls down. Sometimes in the aircraft the most difficult maneouvre to pull off without compromising safety is pushing the aircraft back and starting the engines [OTP]. There are so many people involved in this process that sometimes a Captain is like a traffic cop in the middle of a jam, rather than a manager steering the process while simultaneously mantaining the big picture awarness to safely integrate what must be done with would be nice to see done.

Simulators can provide this environment – but the preparation required of the instructors and the training management is extreme. This kind of simulation is called LOFT (Line Orientated Flight Training); or LOS (Line Orientated Simulation) – or when you’re being checked and not trained – LOE (Line Orientated Evaluation). While LOFT/LOS/LOE heavily influenced training thought up to a decade ago, many airlines seem to be back at that point where their training syllabii are driven towards a token half-session LOS/E; combined with multi-repositioning maneouvre training that completes set exercises as dictated by a regulatory matrix.

I might add some of these maneouvre are patently irrelevant to “modern” aircraft. In my 777 which was designed in the early 90’s and is now over 20 years old – we have to practice the failure of all primary flight instruments, a failure more appropraite to the aircraft of the 50”s, 60’s and perhaps 70’s. This basically means failing my two LCD screens (assuming I don’t just lean back and look at the two in front of my Co-pilot), each of which have a mean time between failure of something like 400,000 hours. So far in my 9000 hours/18 years on the 777 I haven’t had one fail – only 391,000 hours and 782 years to go before this check event that I have to do every year becomes beneficial …

When we step into a simulator perhaps 75% of the available time for training and assessment will be taken up by regulatory based maneouvre requirements. Matrix’s that dictate that each 6 months you must to an engine failure on takeoff in the lowest visibility with the engine failing at close to decision speed, for example. Not only this this simple exercise consume perhaps 20 minutes of simulator time – it dictates the nature of that section of the session – there must be a takeoff, it must be in low visibility, etc. The option of starting the session in mid flight nearing your critical diversion point over the pole goes out the window.

One final thing on skill retention. The rules that determine how often I must do a take off and landing to be legal to operate may or may not adequately address manual flight skills (or at least, the manual flight skills required to do a takeoff and landing) … but it does not address the wider skills required for manual flight in non-normal operations, nor does it consider “operational familiarity”, or if you like, recency as it relates to everything we do that doesn’t include takeoff or landing. Most particularly this means the cognitive skills that sits behind the manipulative ones. I recently came across an article on this in the Journal of Human Factors. The article itself is fascinating but the conclusions are both logical and startling; namely …

After large gaps between flight exposure, the basic manipluative skills of piloting tend to fade slowly, and return quickly to a good level of proficiency with exposure.

However after the same abscence, the cognitive skills required to operate safely and efficiently fade quickly and take more exposure to build to previous levels of proficinecy.

This second one is crucial. You can throw a pilot into a simulator after 45 days do a few takeoff/landings and be satisfied that as far as that skill goes, that pilot is good to go. But what about the cognitive aspoect. As a member of a small group of highly skilled, highly qualified pilots who seldom touch an aircraft, and have been this way for 8 years now – I can confirm that the least of my worries is takeoff, landing, basic flying. It’s everything else – and most particularly exposure to high workload situations that require practiced cognitive skills that present the greatest challenge to proficiency, efficiency – and safety.

To (finally) bring this round to the original heading – if you barely get the chance to practice hand flying the aircraft (while thinking at the same time) – how much harder is it going to be to respond correctly when your instruments are lieing to you?

Airspeed Unreliable Checklist

The Airspeed Unreliable checklist was revised in light of Air France AF447 to provide some short term figures for pilots to rely on. The basic intent of this change is to avoid the fixation that often occurs on airspeed and airspeed related alerts during this failure, to the exclusion of sensible pitch attitudes and power settings for existing aircraft configuration.

The settings promulgated in the checklist are designed to keep the aircraft in a safe (if not necessarily desirable) state of flight clear of high and low speed extremes for at least as long as it takes the crew to progress through the checklist to that point where they are looking up more appropriate values in the QRH. This may leave the aircraft in a climb or a descent, it may leave the aircraft at innapropriate (but safe) high or low airspeed compared to the normal flight regime. But safe.

It’s worth noting that the simulator leaves the Flight Path Angle displayed if selected. However while the FPA, PLI and Stick Shaker are fundamentally attitude based – all take airspeed as an input parameterfor validity checking. Boeing cannot guarantee that any of these will display, or will display correctly in the event of unreliable static/dynamic sources and hence the checklist warns against their use.

Cabin Altitude as … Altitude

In the event of a complete static port blockage, some crew have attempted to depressurise the simulator (Outflow Valves – Manual, Fully Open) to use the ASPC pressure sensor to provide an aircraft altitude through the Cabin Altitude display. This technique is technically (systemically) valid and will display an approximate aircraft altitude in a depressurised aircraft.

However it has been noted that when most crew takeoff with all static ports blocked (takeoff being the only time this is likely to occur), once crew recognise the malfunction, adopt the promulgated memory pitch attitude and thrust settings and commence the NNM checklist – by the time they achieve level flight in accordance with the QRH, they’re usually over 10,000 ft. Selecting the Outflow Valves open at this point would result in an EICAS [] CABIN ALTITUDE, followed by Oxygen Masks and a Rapid Descent – all while on unreliable flight instruments. As such this technique is not recommend by most Training/Standards Departments of the aircraft manufacturer. Using the Cabin Altitude earlier in this failure might indeed give you an altitude to maintain, but without valid power settings/attitudes, you’ll compromise your ability to maintain a safe airspeed until you get into the QRH.

I’m working on an update to the Practices and Techniques document I developed in 2008. While this has been a published document in my airline for several years, it was recently taken offline and is now a training background reference, as was the original intention for it’s development. Just one of the many subjects currently under revision is the section on Depressurisation Events – specifically the assessment of the Outflow Valve Position during an EICAS CABIN ALTITUDE or other related NNM’s that could lead to a Rapid Descent.

I’m working on an update to the Practices and Techniques document I developed several years ago. While this has been a published document in my airline for several years, it was recently taken offline and is now a training background reference, as was the original intention of it’s development. Just one of the many subjects currently under revision is the section on Fuel Quantity Indication System (FQIS) – Totalizer vs Calculated Fuel. This comes after ongoing investigation of the fuel stratification issue (still unresolved).

The last phase of recurrent simulator training – for Cruise Relief First Officers – included a two engine go-around after a Slats Drive failure. The outcome was usually surprising – for no apparent reason the AP/FD pitches to less than 10 degrees and accelerates well through Flap Limit speed. The PF is required to disconnect and pitch?manually?above the Flight Director toward the standard 15 degrees to recover speed control.

Update: I recently revisited this in the simulator and filmed the sequence as part of an investigation with Boeing.

– – – – – – – – – – – – – – – – – – – –

Practices & Techniques : Slats?Drive Go-Around

Slats Drive go-around has been shown in the simulator to have unusual flight characteristics. Boeing have confirmed that the simulator is following the same control law as the aircraft, and as such crew should expect the aircraft to behave the same way.

Essentially during a go around after a Slats Drive failure, the AFDS increases pitch rate slowly to a target of about 8-10 while airspeed continues to accelerate through the flap limit speed. The solution is to either disconnect and fly manually, or potentially a reversion to FLCH will restore correct AFDS speed/pitch behaviour.

Engine out Slats Drive Go-Around has the same pitch problem, although the result is less marked owing to reduced performance. Note that the use of FLCH to recover will reduce the thrust limit setting to the CLB/CON limit prematurely, and may compromise go around acceleration/performance.

I was asked recently to write for an internal newsletter to provide some Boeing 777 specific information to non-777 pilots on the role of the 777 Autopilot Flight Director System (AFDS) and Autothrottle in the Asiana 214 accident. The following article is based on that contribution.

Weather avoidance is part and parcel of an airline pilot’s standard task list. From the Mark One Eyeball to the Rockwell Collins WXR-2100 Weather Radar there are various tools available to assist in this task; all of which leverage the training and experience an airline pilot brings to the flight deck. But my last trip illustrates the changes we’ve seen over the past few years in weather avoidance becoming a wider task that just the pilots on the flight deck, so I thought I’d share it here.

In another article, I discuss the issue of acceleration and cleanup in the missed approach. The Boeing 777 FCTM mentions accelerating at 1000 ft (AAL) in the missed approach, and many airlines use this point on two engine missed approaches. As discussed – this is inappropriate and potentially dangerous in the event of a single engine missed approach as terrain clearance is not assessed. We use the Missed Approach Altitude MAA (or if lower/higher and more appropriate, the Minimum Safe Altitude MSA) instead. We use this point on both all engine as well as engine out go-arounds to maintain procedural consistency and reduce the likelihood of a crew acceleration (inappropriately) early on a single engine missed approach.

Recently I was asked about early ALT capture in the missed approach. The issue of concern was whether we could accept “early” acceleration in the missed approach when it’s associated with AFDS ALT capture. In essence – this is acceptable and in fact expected two engine go-around behavior.

Basically when you’re climbing up towards an altitude at which you intend to level off, the Autopilot Director Flight Director System (AFDS) is aware of this since it’s usually set in your Mode Control Panel (MCP). The AFDS monitors your current altitude, your rate of climb and your target MCP altitude during the climb (among other things …) and schedules a capture of the altitude earlier if your climb performance is good.

At some point you enter a capture range as you near the target altitude and an altitude capture mode engages in the AFDS. This is indicate by ALT on the Flight Mode Annunciator (FMA) and the AFDS either (a) commands the flight director to provide guidance for the level off; (b) commands the autopilot to action the level off; or (c) or both.

How early the capture phase begins is mostly dependent on your rate of climb. A rule of thumb when manually flying is 10% of your rate of climb. If you’re going up at 1000 ft/min – you can expect to have to begin the level off at 100 ft to go. My read of the AFDS is that it’s a little more sophisticated than that (one would hope so …) – it schedules level off much earlier than I would when manually flying – see the picture above. The AFDS level off process is?primarily limited by a “g” limit that the autopilot is is allowed to actuate through the flight controls – aimed at providing a smoother ride with less stomach pulling for the passengers.

Note : It’s worth noting that during climb you’re in a speed-on-elevator mode where speed control is provided through pitch (elevators). When leveled off – you’re in a speed-on-thrust mode where the autothrottle moves to protect speed. However during the capture you’re on neither.

I once had the capture mode described to me as “the aircraft following a pre-determined 3D path in space/time” by a particularly nerdy (but brilliant) Instructor – in which speed protection is NOT guaranteed. This 3D path is calculated at the commencement of the capture mode, and the AFDS follows it until the aircraft is levelled off. As such if the environmental or thrust conditions change during the capture process such that the initial calculated path is now invalid – all bets are off and pilot intervention may be required to protect speed and/or altitude. Supposedly the altitude capture mode does not heave the ability to re-calculate on the fly …

I’ve seen this myself on several occasions, where a change in MCP speed or thrust available – or resetting the QNH – completely throws the AFDS and a reversion to basic modes or manual flight is required. The classic scenario in the sim is to fail an engine in a two engine go-around just as the AFDS captures altitude early because of climb performance. Pilot intervention is almost always required as the aircraft tries to follow a 3D capture path based on 2 engines, using the thrust available from just one engine.

The missed approach – particularly the two engine missed approach – can be an extremely dynamic regime where large rates of climb – anywhere from 3000 to 5000 fpm – can “normally” be achieved. As such the capture phase can begin quite early, and owing to the dynamic nature of the maneuver – can seem too early for a normal level off.

This is where the question comes in. I recently encountered pilots who were intervening in the event of an early ALT capture off a two engine missed approach, because our SOP is to continue missed approach climb to the MAA. This is not required. On a two engine missed approach, the climb phase can be thought of as over when the AFDS enters ALT capture, even if it seems to be doing so well below the MAA. Early altitude capture is (usually) an entirely normal and appropriate action by the AFDS (or the pilot) and the SOP to climb to the MAA before accelerating was never intended to preclude this. In any case – on a two engine missed approach you’ll (almost) never be limited by?terrain clearance and commencing level off at an altitude below the MAA appropriate to the rate of climb is absolutely normal.?The issue doesn’t present on single engine go-arounds because the climb performance isn’t there to generate early captures.

None of this is of course intended to limit the PF/Captain from taking action in the event of inappropriate behavior of the AFDS – Fly The Plane.

A while ago I was looking into tail clearances on takeoff, rotation technique and most importantly what tools were available to train and evaluate rotation technique in the simulator and the aircraft.

As part of this review the question was raised about the calling of “Rotate” on takeoff and the initiation of the rotation manoeuvre itself. It seems an esoteric distinction but when the takeoff is critical – high weight, high density altitudes where limitations such as maximum tyre speed become a factor – it can be part of the problem of rotation technique.

Before you read on, answer honestly the following question – When do You start to pull back and initiate rotation on takeoff?

When the PM calls “Rotate“; or

When the airspeeds indicates you’ve achieved VR?

The answer of course comes from the FCTM.

The requirement for the PF to initiate rotation at VR rather than “Rotate” has some implications for takeoff. If you weren’t already – as the PF you should have airspeed in your scan (along with everything else) during the takeoff roll, particularly as you approach V1/Vr. Essentially as you hear the PM call “Rotate” – you should have already begun the control input; you should not be reacting to the call.

It’s a small difference (made bigger by any delay in the PM (Captain!) to call “Rotate“) but with the odd tyre speed exceedence seen in Abu Dhabi in the summer and occasionally Los Angeles at heavy weights – a difference that can bring you closer to an exceedence.

This concept provoked some discussions amongst the standards guys as to whether we should be calling “Rotate” a few knots early. Again – referring to the FCOM/FCTM – the answer is … No.

Background

Years ago when my previous operator transitioned from the awesome Boeing 777-200/ER’s to the even more awesome B777-300’s – prior to the ultimately awesome (… at least until the 777-X!) B777 300ER’s – we were concerned about the rotation technique our pilots were using in the -200 aircraft and how that would translate across to the far more critical -300 aircraft. I promise I won’t call anything else awesome for the rest of this page.

While training was provided in the simulator to Instructors (to teach/assess) and to Line Pilots (to do!) on takeoff rotation to refresh them in preparation for the -300’s; one of the most effective solutions was produced by Engineering.

After each takeoff in the aircraft, the onboard maintenance computer would print off a takeoff rotation report which listed some of the basic parameters associated with the rotation itself and allow the pilots to compare their own impression of the rotation manoeuvre as against the data itself. Pilots were heavily cautioned against reading too much into the data and reminded that the prime reference was the FCTM technique – but it was fascinating how often a rotation that felt slow, looked slow on the data; felt fast, looked fast on the data – or felt ok, looked slow or fast on the data. Over time we trained into our brains and muscle memories the correct technique using the aircraft itself as our guide. Quite cool really.

As an aside, I can remember several tailstrike incidents in the B777-300 (never the 300ER) during my time with my previous airline; all involved some fairly (not so) unusual (UK) weather with strong/gusty crosswinds involved. While information was never provided as to whether pilot technique was a factor – knowing as I did at least three?of the pilots in those occurrences, I really don’t think so.

Later the FCTM would be changed to recommend full TOGA thrust on all takeoff’s in strong and/or gusting crosswinds in all 777’s – an action which increases the tailskid margin on takeoff.

Boeing 777 Tailstrike Prevention Solutions

When the 777-300ER’s arrived they came with a software based tailstrike prevention system that would all but eliminate tail strikes. In fact to the best of my knowledge no 777-300ER’s have experienced a tailstrike in operational service – and the system had to be disabled during certification in order to produce the data necessary for unstick tests.

B777-300ER : Has detection; Tailskid Protection (tailskid); plus a software based protection system and semi-levered main gear which pivot during rotation to reduce the likelihood of a tailstrike.

Tailstrike Detection Skid

Tailstrike Detection (All)

The detection system is a sensor/antenna mounted on the underside of the aircraft, not far past the point where the lower body tapers upwards towards the tail, and when activated alerts the flight deck that a []TAILSTRIKE has occurred. This system is highly sophisticated, so to understand it – you need to read the next paragraph carefully.

Basically if you pull back hard enough during takeoff and drag the back end of the aircraft along the runway – you rip off this strategically placed orange fin, and an EICAS message goes off on the flight deck.

Highly sophisticated, wouldn’t you say? Still it seems to work.

In the event of an activation of this system – on any 777 – the checklist requires you to depressurise the aircraft and Land. Potentially you’ve done damage to the airframe, which could well be structural and include the cabin pressure cell.

Protection Skid/Cannister

Tailstrike Protection (Hardware, B777-300/300ER *)

The physical talkstrike protection cannister solution is a skid that retracts with the landing gear but during takeoff and landing provides a crushable cannister that absorbs the impact of a tailstrike. Note that you can drag this bit of kit along the runway – even crushing it – without activating the aforementioned detection system (no EICAS message). Apart from some harried calls from the crew and passengers – you might not even know it had occurred …?In any event in this circumstance it’s acceptable to continue the flight because the cannister has done it’s job of protecting the airframe, even if you failed to do so …

Accompanying this (B777-300ER only) is the implementation of the semi-levered landing gear which “consists of an additional hydraulic actuator that connects the forward end of each main gear truck to the shock strut. During takeoff, the actuator locks to restrict rotation of the main gear truck and allow takeoff rotation about the aft wheel axle, thereby improving airplane performance capability. During landing, the actuator is unlocked to permit rotation of the main gear truck and provide additional damping.”

We like to think that the aircraft essentially hops off the runway at the end of the rotation sequence …

Tailstrike Protection (Software, B777-300ER)

The 300ER’s come with a software innovation that assesses the likelihood of a tailstrike during takeoff based on a sea of parameters that include not only tailskid height but pitch attitude, rotation rate, airspeed as well as pilot control inputs. This is a solution that is a direct benefit from a fly by wire control system – there’s no doubt a stack of software in the background operating on a stack of data coming in at (I believe) 60 frames of information a second. Basically the system calculates how low the tail skid will be at the lowest point in the rotation – and if it believe that clearance will be less than 1.5 feet (yes – that’s 18 inches folks …) – it springs into action. Effectively?it reduces the pilot commanded elevator input, slowing the rotation of the aircraft, thereby preventing a tailstrike while continuing the rotation manoeuvre.

There is no pilot feedback, and no advisory to the crew that this has taken place. Depending on your airline’s setup – the flight deck, Engineering and/or Flight Operations Department could receive a report from the aircraft that the event has taken place, incorporating a subset of the data generated during the activation of tailstrike prevention.

Additionally an airline’s flight data monitoring (FDM) program that monitors digital data continuously for exceedences in a variety of parameters may well detect in the takeoff data indications an execeedence of various values such as fast/slow rotation rate; high rotation pitch attitude at liftoff, etc. It’s worth noting however that FDM captures data at about 5 times a second whereas TSP works on at least 12 times as much data – I’ve seen circumstances where the TSP has activated, but FDM never caught anything unusual (enough) on the takeoff to report.

* Finally – it’s worth noting that the software solution on the 777-300ER is so good that recently Boeing stopped placing the physical cannister tailstrike protection solution on the -300ER’s; this protection originally provided on the 777-300’s is no longer required and Boeing have been looking at rolling the software system back to the 777-300’s.

The issue of temperature inversions and the implications for takeoff performance calculation raised so many issues that I ended up having to remove the sequence from the session. I set about reviewing what the industry had in this area – particularly as relates to practice and procedure for dealing with reported temperature inversions.

There ain’t much. The theory is all there of course, covering the various mechanisms under which LLTIs (Low Level Temperature Inversions) are formed; their association with Windshear; the likely effect on performance. But when it comes to dealing with them practically …

Note: All of the following information is the collation of research from various sources. Specific references to values and performance impacts, and any procedural or practical recommendations are personal opinion only and in no way reflect policy or practice of any airline or flight department. Caveat Emptor.

Low Level Temperature Inversions (LLTI)

In the International Standard Atmosphere (ISA) the outside air temperature (OAT) decreases at a rate of 2 degrees per 1000 ft. In fact it’s not quite that simple, since the dry adiabatic lapse rate (DALR) is nearer 3?degrees/1000 and the saturated adiabatic lapse rate (SALR) nearer 1.5?degrees, so moist air rises less rapidly than dry, hence clouds that continue to build vertically while there’s high moisture content, hence the planet on which we live replete with clouds and rain and trees and forests and oceans and … but I digress.

On top of this, weather characteristics and the geographical environment may affect the lower layer of the atmosphere to produce an increase in ambient temperature with ascent, rather than the expected (various degrees of) decrease. This is called a temperature inversion and down low, abbreviated as an LLTI.

The wikipedia entry is decent. For our purposes the basis of formation isn’t necessarily relevant, but we can look at two types for our purposes – Known and Unknown. The unknown kind can be half expected (based on local experience) but is rarely accounted for – it just comes as an annoyance on performance as your all-engines operating aircraft encounters it. The likelihood of an LLTI occurring at the exact same time as a critical engine failure with an obstacle constrained flightpath is so statistically remote that we can ignore it.

Or is that what we say about ATC and mid air collisions?

But when planning a takeoff with a known LLTI – usually reported by ATIS after pilot observation “Pilot reported Low Level Temperature Inversion of 15 degrees at 1000 ft” – you’re now planning on the loss of an engine when you hit this thing, which makes it somewhat more serious.

An LLTI for our purposes occurs at low level and rarely penetrates 2000 ft AGL. A 10 degree temperature inversion is considered quite significant and will usually be reported on the ATIS. Dubai is a prime location for LLTI’s where the ambient temperature is relatively high during the day but the ground cools quickly and significantly at night, setting up the conditions for a morning LLTI. I’ve flown through LLTI’s of 20 degrees (all engines operating) and the effect is noticeable – generally a marginal but detectable loss of performance. The fact that it usually hits just as you reduce to climb thrust, commence 3rd segment acceleration and occasionally as you reduce flap doesn’t help. But two engine performance is not the issue here and a LLTI will never be anywhere near the impact of actually losing an engine – just to keep things in perspective …

Performance Impact

All performance is based on density altitude and temperature is a key factor. The higher the temperature the higher the density altitude, the thinner the air and the less performance from your engines (and wings, etc). The key performance factor we’re interested in here is thrust from the engines, and since we’re usually talking about higher temperatures, it means we’re usually operating beyond the flat rating temperature of your engine. So we’d better start with that and talk about Flat Rating and Tref.

Flat Rating and Tref

For certification purposes – turbine engines are required to be able to produce a minimum fixed thrust throughout their operating life. This predictable thrust level is constant up to a certain ambient temperature – above this temperature the thrust produced by the engine is scaled back as OAT increases. The point at which thrust starts to reduce is known as the Engine Flat Rated Temperature (or Tref in Airbus speak) and is usually defined as an ISA deviation. For the GE90-115B engine the flat rating temperature is 30 degrees C at Sea Level (or ISA+15 degrees).

There should always be a margin between the thrust an engine is capable of producing and that required of it by scheduled takeoff performance. Below Tref this is defined by a pressure limit on the engine. Above Tref, it’s defined by a temperature margin, and can be loosely associated with the difference between the EGT achieved during the takeoff roll and the EGT the engine is limited to at Takeoff Thrust. The GE90-11B’s are unlimited at an EGT of 1050 degrees C and below (N1/N2 limits apply also), or with a 5/10 minute All Engine/Engine Out limit of up to 1090 degrees .

Both above and below Tref – this translates broadly speaking to a margin below a critical exhaust gas temperature (EGT). In essence under ISA conditions a new engine will produce “maximum thrust” at a lower EGT than an engine at the end of it’s operating life.

For both of these engines, that “maximum thrust” is a pre-determined figure that your performance calculator has to be able to rely on. For a takeoff in excess of Tref, your performance computer counts on less and less thrust from the engine. A general rule of thumb is a loss of 0.75% thrust for each degree of temperature increase above Tref.

FADEC Thrust Setting

Another factor to bear in mind as we draw inexorably closer to actually discussing dealing with LLTI’s is thrust setting during takeoff. An engine with Full Authority Digital Engine Control (FADEC) continues to “tweak” the thrust set during the takeoff roll. Typically allowing for the increase in inlet pressure as the aircraft accelerates – in fact the N1 or EPR will be adjusted for a series of factors during the takeoff roll to produce a command parameter (N1/EPR) that results in the required thrust. When the ambient temperature increases on takeoff (instead of decreasing) it can be seen that the impact on thrust produced can be different depending on whether you’re above or below the Tref.

Watch the N1 during takeoff sometime – you’ll see it continue to change as the aircraft accelerates, even though the thrust levers are de-clutched in “HOLD”.

N1 : Is not actually a parameter used directly for engine thrust management. N1 is corrected internally in the Electronic Engine Control (EEC) as a function of the TAT (depending on aircraft speed). This corrected N1 (referred to here on as N1-K) bears a direct relationship to thrust.

As temperature increases but remains below Tref, N1-K is constant with the thrust produced even as as N1 increases. In essence as the temperature decreases it requires more and more N1 to produce a constant thrust (N1-K). Unfortunately – we see N1, so I’ll keep N1 as a primary parameter for our discussion.

Above Tref – N1 will decrease with increasing temperature, as will Thrust (N1-K)

EGT is a little different. Power management is essentially established to maintain a constant EGT (in relation to a critical maximum EGT) above Tref. So below Tref, EGT will increase as OAT increases until OAT is at Tref, after which EGT will essentially remain constant with further OAT increases even as thrust decreases.

Ok, so we now have enough information to start looking at LLTI’s. If you’ve followed so far, you can see how we might choose to plan for a LLTI depends on the relationship between ambient OAT and Tref – remembering the B777-300ER’s GE90-11b engines are flat rated to 30 degrees C (or ISA+15).

During takeoff the EEC’s continuously compute N1 based on the current ambient temperature as sensed by the TAT probe at the top of the Engine Nacelle. Thus the effect of a LLTI on takeoff performance will depend on the type of takeoff being performed and on the magnitude of the temperature increase.

LLTI; Maximum (or Fixed Derate) Thrust; Ambient below Tref

If you’re conducting a Maximum (or TO 1/2 derate) thrust takeoff with the ambient OAT below the flat rating temperature and a temperature increase occurs such that the ambient remains below Tref – the EEC’s will increase the N1 to maintain thrust required (N1-K constant) for the higher temperature. The EGT will increase but remain below maximum EGT.

Because this all takes place below Tref – there’s little impact on thrust. You may well still notice aerodynamic effects – but thrust loss is not one of them.

LLTI; Maximum Thrust; Ambient above Tref

If your conducting a Maximum (or TO 1/2 derate) thrust takeoff and an OAT increase occurs that takes the ambient above Tref – the EEC’s will reduce N1 to maintain power management requirements rather than thrust required. This is the engine protecting itself to avoid an EGT exceedance. Thrust levels will reduce (compared to a “normal” takeoff) to maintain a constant EGT. The higher the OAT above Tref, the greater the reduction of thrust.

As a general rule, a temperature inversion of 10 degrees will result in a thrust reduction of about 10% (anywhere from 8% to 12% depending on the engine). However the loss of thrust applies at the maximum magnitude of the temperature inversion. Typically the temperature increase in an LLTI is uniform; thus the thrust reduction associated should also be uniform through the atmospheric LLTI.

LLTI; Assumed Temperature Takeoff

If you’re using assumed temperature with a temperature inversion, the following two cases have to be considered:

If the OAT increase stays below the Assumed Temperature, then no effect on thrust will occur. The EEC’s will detect temperature and regulate thrust accordingly and not be limited by the Assumed value. Thrust will therefore remain constant compared to the standard atmosphere takeoff. You’ll see an increase in EGT due to the higher ambient; again you may notice aerodynamic effects – but thrust loss isn’t one of them.

If the temperature increase goes above the Assumed Temperature – then the assumed temperature solution is dropped by the FMC. The thrust solution reverts to maximum thrust (or max TO1 / TO2 thrust) and the implications are similar to the previous two situations – LLTI with Max Thrust above/below Tref. This scenario is less likely since it requires an already higher temperature on ground with a limited amount of reduced thrust and a temperature inversion higher than the difference between the OAT and the Assumed Temperature. Or is it?

That said, the situation in Abu Dhabi is actually quite close to what is being described here. A limiting takeoff where some derate (not much) is still available, where the ambient temperature is above the engine flat rating temperature – coupled with a report LLTI of 10 degrees or more. This sounds like a vintage Middle East morning departure.

Before we move on – it’s important to note that a temperature inversion during takeoff has little effect on engine performance when it occurs during Maximum/Derated/Assumed Thrust takeoff where the OAT is below Tref.

Effect of an LLTI on Aircraft Performance

It should be clear now that for an LLTI to be a consideration on takeoff performance, the aircraft needs to be in the following scenario:

Engine failure at V1; with an Obstacle constrained flight path (the runway will be behind you before you enter the LLTI);

LLTI is such that it results in a regulatory net flight path margin cancellation and leads to compromised obstacle clearance.

In all other cases, even if performance is affected the result is a detrimental flight path lower than the nominal one, but clear of obstacles and minimum net flight paths.

It’s worth nothing that FAR/JAR Part 25 rules introduced conservatism to account for inaccuracies of the data used for performance calculation, and although not specifically mentioned, the case could be made that LLTI’s are part of in that consideration. There is however no specific documentation to state or imply this.

The minimum climb gradient commencing at 35 ft above the runway for the second segment is 2.4% for a twin engine aircraft. Beyond this is a 0.8% margin between net and gross calculations. Typically a 10 degree LLTI over 1500 ft will halve the gross gradient between the planned/actual and net flight path if all else is equal. This implies that even with the LLTI the aircraft will remain clear of obstacles.

However the LLTI affected flight path is a curve, with performance continuing to degrade the higher and further the aircraft goes until it reaches a point where the aircraft will be below the net flight path. However LLTI’s are usually relatively shallow in nature, with a more normal atmosphere prevailing above which would restore climb performance to the aircraft.

What To Do?

If you don’t expect the engine to fail – LLTI’s are not a consideration. The combination of an engine failure with an LLTI of more than 10 degrees is extremely remote, which is perhaps why regulatory authorities have never addressed this issue. Hence we tend to ignore the possibility of unknown LLTI’s.

It’s somewhat different when you’re the Captain, and the ATIS says you have an LLTI over the airport, that probability has just been increased to 100% – now you’re back catering for an exceedingly unlikely engine failure into a known LLTI.

It should be clear now that when the ambient is below Tref; when there a healthy derate (assumed or otherwise); when there are no obstacles on departure – the LLTI is a consideration, but not a limiting one, or one that would result in a change in takeoff performance calculation.

Note that the use of TO1 or TO2 implies that if needed you can advance the thrust to full TO in the event of degraded performance. You’ll want to make sure you’re not operating in the low weight/low speeds part of the envelope where control can be compromised by full thrust in respect of VMCA/V2.

Therefore let’s address the specific scenario of concern as follows and suggest a recommendation.

LLTI is such that it’s likely to result in a regulatory net flight path margin cancellation leading to compromised obstacle clearance (at least 10 degrees)

If this is your scenario one possibility is to add the temperature inversion value to your OAT in order to correct the temperature used in performance calculations. For older engines that are EGT limited at higher thrust settings – this will recover some of your lost margin against EGT redline. If you’re using assumed thrust – you can still do this as long as the inversion does not exceed the assumed temperature value.

As with all such recommendations – this is only a real decision when it comes to a payload limited departure. It’s the Captain’s decision on the day to offload cargo and/or passengers and bags against the possibility of an engine failure combined with a reported LLTI and an obstacle critical flightpath. It’s worth emphasizing again that there’s no regulatory basis/requirement for this, even though there is no doubt that temperature inversions have a direct effect one engine and aircraft performance during climb.

After a debacle in Abu Dhabi – and another occurrence involving offload and a 4 hour delay – I was asked to prepare some specific advice for Captains operating out of Abu Dhabi.

Background

Due to high temperatures, most Abu Dhabi departures during mid-Summer experience a potential performance penalty for departure; in most cases resulting in loss of revenue payload, possible departure delays due offload and in the severest of cases the offload of all Cargo, Standby Passengers/Bags and Revenue Passenger Bags to enable departure.

At this time of year the midday temperatures in OMAA are in the mid 40’s. When contrasted with the average load carrying capability for our 777’s in these temperatures; and the high loads of passengers and freight departing Abu Dhabi during Summer – it’s clear that crew will be required to plan for a performance limitation on takeoff.

Note : The data provided here is for information only and not for operational use. Any statements of rules of thumb; values of temperatures and winds; preferred runway selections; performance limit weight changes due ambient conditions such as Temperature, Wind, Runway Selection, APU-PACK usage etc are informational only – all takeoff performance estimates must be verified and calculated by the crew in the actual operating environment of the day.

Effect of Temperature

From the charted data – it can be seen that increasing temperature has a significant impact on the load carrying capability of the aircraft. Once below the Certified Takeoff Weight, each degree increase reduces the takeoff performance limit by at least 3 Tons – often more.

Assuming a full load of passengers and crew – at planning temperatures of 40 and less, some revenue cargo can be carried for the departure.

However as the temperature increases, the performance limiting condition reaches a point where revenue cargo cannot be carried. In a highly subjective calculation – this is indicated by the yellow/bold sections of this sample chart. Your mileage may vary.

Effect of Wind

It can be seen that an increasing headwind component helps increase load carrying capacity by an average of 300 Kg/Knot. However this rule of thumb is far from reliable because there are points at which headwind helps with a specific performance limit and the increase in permitted takeoff weight is higher (900 Kg in some cases for 1 knot increase in wind). Crew must examine various contingencies of the wind before deciding on a planned set of departure conditions.

Departure Time

Our departure time of 11:00 am leads up towards the peak heat of the day. This has two operational impacts. Temperatures are high and therefore our capacity to fill the aircraft is compromised. Additionally any significant delay to the departure – such as to offload cargo/standby passengers in order to comply with a weight restriction – takes the aircraft into even higher operating temperatures. Once into this peak temperature regime (about 14:00 Local) it can be up to 4 hours after scheduled ETD before temperatures reduce.

Sea Breeze

During the morning temperatures build and OMAA general experiences southerly (crosswind) to easterly (HWC RW 13) winds of up to 10 knots. That said – usually the breeze is less than 5 knots and of variable direction.

Between late morning and early afternoon a wind change is usually experienced (RW13 -> RW31) and winds of up to 10 knots can result. Once the sea breeze is established it’s normal for temperatures to commence a slow decrease through the rest of the afternoon.

Choice of Runway

All runways in Abu Dhabi are of equal length and approximately equal slopes (actually 0.05% up to North/West). There are obstacles in the database off the end of all runways, and RW13 L&R have an EOP. It is this last factor which determines that generally RW31 gives better takeoff performance than RW13. However this advantage is generally less than 1 Ton and is quickly negated by wind.

APU to PACK

APU to PACK will generally provide a takeoff performance increase of about 3.5 Tons. Crew should familiarise themselves with the APU to PACK procedure from the FCOM SP during pre-flight; and consider reviewing the APU to PACK detail in the D5 OPT Guide prior to flight operations in Abu Dhabi.

APU To PACK in Abu Dhabi forces some additional operational considerations. Due to high on ground temperatures – with a full load the cabin temperature towards the back of the aircraft will be in the high twenties prior to engine start. As such the requirement to run two Packs out to the runway for passenger comfort is almost a certainty. Recommended technique is:

Use conventional data entry procedures to enter all takeoff data as planned for the departure – even if you’re not sure those figures will be used for takeoff. Select APU in the Assumed Temperature line, verifying small font APU on the Upper EICAS.

After engine start verify large font APU on Upper EICAS and Single Pack APU operation.

If deemed necessary delete the APU entry in the Assumed Temperature line of the CDU THR LIM page and verify dual pack operation to the cabin. This action will delete the takeoff speeds from the FMC.

Delay the Takeoff Review and Before Takeoff Checklist until final takeoff performance entries are complete

Plan to position near the runway such that a short delay will be acceptable to ATC. When ready, perform the FMC Final Performance Entry procedure in full and re-enter takeoff performance data while the aircraft is halted with both operational crew involved as scripted.

Complete Takeoff Review and the Before Takeoff Checklist when ready.

If APU to Pack should fail – Turn the Packs OFF (refer to SP) nearing the runway (note 30 seconds minimum before thrust advancement) in place of APU to Pack.

Over Fuelling

When planned at 40 OAT – the flight can include 10-15 tons of cargo with a full load of passengers, based on a re-dispatched OFP fuel load. However if temperatures increase and a subsequent offload (or non-load) of Cargo is undertaken – even with 3 ton below refuelling the aircraft can be left with too much fuel to even depart with minimum passenger load.

If an over fuel situation develops, De-Fuelling is almost always NOT an option. One option to consider is pushback and taxi to hold near the runway – to wait for fuel reduction (minimum 2.0 tons per hour during taxi) or improved ambient conditions (post peak temperature, wind change, sea breeze).

Flight Planning

The Flight Plan will be prepared to a forecast temperature at the time of departure plus (based on recent operational experience) a margin. In all likelihood it will include some capacity for revenue freight.

If the flight is planned with cargo, captains should consider the following plan of action:

Obtain an estimate of the ZFW required for Revenue Pax/Bags and Standby Pax/Bags from the AUH Ramp Dispatcher.

Obtain a minimum fuel OFP from Nav Services for this ZFW.

Refuel the aircraft to this minimum fuel (instead of originally planned OFP less 3 tons)

This will enable the crew to decide to offload/not load cargo (and potentially standby passengers/bags) – and be left with just the fuel required to complete the mission, giving the minimum takeoff weight available for departure and therefore the greatest margin to the performance limited takeoff weight. Although the correction figures could be considered to correct for freight offload – the magnitude of values involved are beyond the accuracy of the LAND/RAMP correction figures.

PushBack, Taxi, Departure – Performance Entry

Pre-Flight : can be characterised by finger-flying calculations on the OPT; multiple sources of ambient conditions (Tower, ATIS, Aircraft OAT); changing ambient conditions; different ZFW/TOW figures provided from different sources. Captains must proactively manage these conditions and decide early on a plan to minimise the risks associated. The integrity of the Final OPT Calculation and the Data Entry Procedure is paramount.

Decision Time : There may come a point where the Captain will have to make a decision on a ZFW that can be accepted based on a conservative use of the OPT and expected temperatures/conditions. The decision to take on cargo and the fuel to carry it must be balanced against the possibility of increasing temperatures that could force a cargo offload – and a delay into even higher ambient temperatures for the departure.

Performance Data Entry : Captains may well find themselves having to enter critical performance data during taxi. It is strongly suggested this should be done in full compliance of the Final FMC Pre-Flight entry procedure after a full cross check of the final OPT solution (from scratch) involving both operational crew members while the aircraft is halted near the departure runway. Takeoff Review and Before Takeoff Checklist is delayed until the completion of the Performance Entry Procedure.

I was recently asked whether we could still use LNAV to fly a Localizer Instrument Approach, and whether that was the preferred mode. This question was asked during a briefing on PBN which has caused some confusion.

Recently we’ve seen some changes in the way we do aircraft Navigation, or at least in the way we regulate it. PBN (Position Based Navigation) is here and exists in parallel with our existing Primary Means Navigation approval. We’ve moved away from the archaic limitations and practices of the specifics of manually and/or automatically referenced individual means of navigation sources and instead benefit from a system that encompasess and accounts for the limitations of all the individual available equipment and provides the best navigation information possible at any time.

Or we’ve just finally embraced GPS. It depends on how you look at it.

LNAV for Localizer Approaches

Localizer approaches are something of an oddity as far as they go. Basically it’s half a conventional ILS approach, where the glide slope (vertical path) component has failed, but we can still fly the approach using the Localizer (lateral path) albeit to higher minima and visibility requirements.

Officially classed as an NPA – at the same time a localizer approach meets the recency need for an ILS precision approach (CAO 40.2.1-11.4); meanwhile our GPS Primary Instrument specifically excludes LLZ approaches (A1 15.5); even as PBN procedures make no reference. Finally the 777 Airplane Flight Manual references the (non) use of the FMC for the purposes of a Localizer Approach, but this is actually miss-leading …

CAO 40.2.1 Instrument Ratings11. Recent experience requirements
11.4 The holder of a command instrument rating shall not carry out an ILS or LLZ approach in IMC as pilot in command of an aircraft unless, within the preceding 35 days, that person has performed in flight, or in a synthetic flight trainer approved for the purpose, either one of those approaches.

B777 AFM; Normal Procedures; Flight Management Computer System (FMCS)The FMCS has been shown to meet the requirements of FAA AC 20-130A for a multi-sensor area navigation system when operated with radio or Global Position System (GPS) updating. When operated in this configuration, the FMCS may be used for enroute, terminal area operations and instrument approach navigation (excludingILS, LOC, LOC-BC, LDA, SDF, and MLS approach procedures). The FMCS may be used to fly a RNAV approach procedure that overlays an ILS, LOC, LOC-BC, LDA, SDF, or MLS approach procedure when the localizer facility is inoperative subject to appropriate operational considerations, procedures, constraints, and authorizations.

The use of LNAV on a Localiser approach is fine as long as you have a valid Localiser signal and you remain within tolerance. When you use LNAV for this, your means of maintaining the centreline of the approach is the GPS / FMC / LNAV. But the means of validating your location on the centreline must continue to be the Localizer signal itself.

Thus the use of LNAV on Localizer approaches is acceptable with the same constraints as the use of the Autopilot/Flight Director LOC mode on a localizer approach – the engaged mode must keep the aircraft within navigational tolerance (half scale localiser deflection in either mode) at all times. There is no reason why LNAV shouldn’t achieve this to the same (or better) level of accuracy as the localizer signal; and both modes demand similar levels of situational awareness from the crew to ensure this. As long as you are monitoring the localizer on approach (and not just the flight director) – LNAV is a good choice.

As an aside – I like the use of LNAV to intercept the localizer for any ILS based approach, particularly when an overshoot (as scheduled by LOC capture) could infringe the approach of a parallel runway. However this does demand a higher level of SA from the crew than APP mode, since it delays arming glideslope capture until LNAV has sorted out the turn to final.

Boeing have begun incorporating an “Additional Information” section at the end of some NNM checklists. Presently on the 777 this feature exists for the Ice Crystal Icing, Airspeed Unreliable, and Fuel Leak checklists.

It is interesting to note that despite the location of this information at the end of the checklist, the information is clearly aimed at providing more background to assist in identifying the problem and the correctness of the checklist selection – information more suited to the front of the checklist. Those of us who have laboured through the old Fuel Imbalance checklist with it’s line after line belabouring the obvious (but necessary) can appreciate the economy of moving this information to the end …

So you won’t see this information when you first open the checklist (paper or electronic). Strictly speaking since this information could be important to (a) identifying the need for the checklist; and (b) confirming that you have opened the correct checklist – you could easily be forgiven to skipping straight to the end to read the “Additional Information” once you’ve opened the checklist.

While it could be easy to miss – the Electronic Checklist (ECL) being the clever beast that is it, doesn’t let you. Even should you take an action that completes the checklist halfway through (see below for the Airspeed Unreliable checklist) – since the Additional Information is a “white” item in the checklist, this page (or pages) of notes remain at the end of the checklist, and you have to page through them. ECL has you covered.

But what about Paper QRH?

Being children of the Magenta Line, or in the case of ECL, the White, Green and Cyan checklist items – it’s easy to foget that there may come a day (quelle horreur!) when you might have to Dispatch Without ECL. In this case – what happens with the Additional Information section?

Airspeed Unreliable

The current case in point is the new Airspeed Unreliable checklist. This checklist has essentially come about from the Air France 447 tragedy and reflects a total revision of the Airspeed Unreliable exercise – which has always been challenging, particularly to pilots of modern aircraft where perhaps not enough manual reversion is emphasised in training and full manual reversion almost almost neveroccurs, voluntarily or otherwise.

I am writing a separate post on this new checklist and will place a reference to it here shortly.

Basically you open the Airspeed Unreliable checklist and begin with the condition statement that apart from anything else – indicates that there is an Additional Information section. Moving through the checklist, you are eventually asked if a “Reliable airspeed indication can be determined.” If one can be – whether a Primary (PFD) or standby (ISFD) – the checklist ends.

At this point you would be forgiven for thinking that the checklist is over – and indeed technically it is. However while the ECL takes you through this additional information (which is quiteextensive) – with the Paper QRH you have to know to skip to the end and review it. I guess with the checklist over and the problem supposedly addressed, you could be forgiven for assuming you don’t need to read the additional information … but that’s another for post.

In any case it can be seen that the Additional Information section for Airspeed Unreliable contains a treasure trove of information as to what you might already have and what you might expect to further occur as you carry the NNM to the runway.

The lesson from all this is to be aware of the Additional Information prompt at the beginning of the NNM paper checklist, and ensure you get to read that section even if the checklist completes early.

A not-so recent amendment to the B777 FCTM (followed by a more recent update to the FCOM and QRH) instigated a procedure where ENG OUT mode of the FMC VNAV page is selected (confirmed) and EXECuted once CONtinuous thrust has been set after takeoff. While this sounds logical and orderly – as usual the devil is in the details and the specifics of actioning this needs to be understood and considered by the PF/PM should they find themselves in this situation.

Specifically – executing ENG OUT at this point in time of the departure removes the VNAV climb page speed/altitude restrictions. Typically this means the loss of 250/10000 on most initial climbs – but also any other coded or entered VNAV Climb Page speed/altitude restrictions. At our typical operating weights (in excess of 320 tons) this usually means an ENG OUT climb speed of about 285 knots.

Interestingly, any LEGS page restrictions on climb speed remains in spite going to ENG OUT mode.

Is there really anything wrong with this? You could safely assume that in the event of a non normal such as an engine failure (whether MAYDAY or PAN PAN PAN) , you’re no longer subject to the 250/10K restriction. And you’d probably be right. But it’s best keeping everyone in the picture and asking/advising ATC before doing so.

Perhaps the biggest alarm bell that goes off for me when I see this is that when the aircraft accelerates after the execute – it takes the crew by surprise. Since this procedure is new and therefore most crew haven’t seen it done – they’ve never seen the removal of this restriction before either, so should I be surprised?

Except that they have seen it. Immediately between the “VNAV Engine Out … Confirm?” from the PM and the PF’s “Execute“, the FMC VNAV Climb page shows you the future – Maximum Altitude with Engine Out; Cruise Altitude, reset as required for single engine service ceiling; Engine Out Climb Speed … and no 250/10,000 speed restriction. But no-one spots it. The PM doesn’t call it; the PF doesn’t see it during the (peremptory) cross check required before the “Execute“. I agree that it’s easier to see things that appear and things that are marked inverse because they’ve changed; but our job description is not to only notice the obvious when making FMC changes.

What should you do in this situation? If your SA is high, you’ll notice the change in target speed, the control column input as a nose down input is applied, and the change in pitch attitude on the PFD. Assuming you weren’t aware of the coming change, I would expect you to speed intervene and maintain current airspeed, whether UP speed or 250 knots. The next time round, the solution would be to speed intervene before executing ENG OUT. Anything else is too fiddly with the CDU while at a high workload period of flight.

All of this tells me we still have a way to go before we reach a gold standard of understanding what the FMC is telling us during these Confirm … Execute exchanges; and that VNAV is still (at times) damn confusing. Well, that last part I definitely knew.

Some time ago I wrote about a review of a Decision Making Model (FORDEC). During that article I clarified that there is a clear difference between a Decision Making Model versus a Non Normal Management Model. Usually you have to deal with the NNM first before you get as far into the flight as having to make real decisions with conflicting information and requirements. I’m using ANC AAM – AviateNavigateCommunicate – AssessActionManage.

Please note that :

(a) Diagrams are NOT my forte; and
(b) I’m NOT doing anything new here.

Non Normal Management Model – ANC AAM

Many pilots, in most situations, have no need of a non-normal management model to follow. Their training, practice and experience combined with SOPs and the support of a good PM/PF to take them through most NNM events to a good result without incident.

However outside of these beneficial influences, pilots at the beginning of their careers; pilots who don’t benefit from a common structure that promotes functioning as part of a team on the flight deck; pilots new to type, to a set of SOPs, to a Company; pilots experiencing a NNM the like of which they haven’t been directly trained for – in all of these situations a common management model framework brings direction and control to a NNM event. Encouraging both process and flow through the procedures while emphasising the importance of the basics – Blue Side Up; Power + Attitude = Performance; Who’s Flying The Plane?; and all that good stuff.

It must be appreciated that ANC (most particularly Aviate) underpins all NNM management. At no point should the instructor be able to lean forward and ask that terrible question – “So … Who’s Flying The Plane?“

Aviate Navigate Communicate (ANC)

ANC is an axiomatic industry standard to assist crew in task prioritisation at any stage of flight – not just during NNMs.

Action which can range from Memory Items, NNM checklist, or just the agreement that an immediate response is not required. After that …

Management of the NNM at the end of AAM release the crew into more traditional handling aspects of decisions relating to Return/Diversion; Weather and Terrain assessment; Aircraft Configuration Impact; Passenger Needs; Aircraft Performance Impact – and how these impact back on the Return/Diversion decision.

Note that at either the Assessment or Management phase the crew may well be required to utilise a Decision Making Model when the correct resolution is not clear to all involved – or especially if there’s conflicting views on the best (that is, safest) way forward.

Change(not as good as a Holiday)

Should the scenario change (such as a change to the NNM; an additional NNM; change to the conditions of weather/fuel/passengers, etc) – the pilot may well be required to abandon the current process (whether in the midst of Navigate/Communicate or Assess/Action/Manage) – and return to Aviate – Fly The Plane.

Sample Scenario : Engine Failure After Takeoff (EFATO)

During takeoff, an engine malfunction (severe damage) results in a failed engine with the additional loss of a hydraulic system. Apart from thrust loss, the primary means of flap retraction has also failed. The PF has dealt with the initial yaw response of the failure and safely delivered the aircraft to 400 ft, where the memory items associated with any applicable NNM checklist would normally be commenced. What do the crew do now?

AviateNavigationCommunicate – AssessActionManage

Aviate: Flight path always remains the highest calling for both the PF and the PM. Power, Attitude and Performance are the active task of the PF; monitoring remains the primary task of the PM to keep the aircraft safe.

Navigate : In this specific NNM – the PF/PM must consider the requirement for any Engine Out Procedure (EOP) to keep the aircraft clear of terrain. The EOP takes priority over everything else other than Aviate. Note that while navigation has come in at 400 ft during this narrative – it’s entirely possible that a turn may have been required earlier to comply with an EOP that keeps the aircraft clear of obstacles close in on the takeoff flightpath.

Communicate : Communications can be a priority for several reasons – whether to advise the intention to deviate from clearance to satisfy the requirements of the EOP; or to ensure that ATC are in the picture to be able to offer assistance when it becomes required. Of course, Aviate/Navigate remains a priority over Communicate.

Assess : Having ensured ANC, the crew now need to assess the required response to the NNM. In this situation, this is a formalised assessment of the EICAS and engine failure indications as well as any immediate requirements of a hydraulic system loss (this is a 777 – there aren’t any). In this situation – it’s a formalised assessment of EICAS commencing with an EICAS message Review (noting both Engine and Hydraulic failure indications) as well as assessing airframe vibration indications. In this case – checklist memory items will be required.

Action : The PF now calls for the action phase, “Engine Severe Damage Separation Left Memory Items“. Both crew are involved in actioning the checklist memory items. As always – ANC remains paramount with both PF and PM required to ensure/monitor flight path and compliance with the EOP during the Action phase.

Manage : Management commences after the required Assess/Action responses to the NNM are complete. By this time the aircraft is clean, clear of terrain and any relevant NNM and NM checklists are complete. Management at this point necessitates Decision Making – in which FORDEC may be required. The aircraft is damaged, with a landing performance impact from both the engine and hydraulic failures. These and other Facts?such as weather and terrain will require the crew to determine and evaluate the available Options?and the?Risk/Benefit to flight those options present, before agreeing on a Decision as to a course of action. Once a decision is reached the crew will Execute the decision along with all the necessary communication of intent that implies. Any good decision making process requires follow up and at some point the crew must implement a positive?Check that the outcomes are as expected.

ANC AAM – Circles within Circles

ANC and AAM do not exist in isolation. ANC overrides any sequence of events from the beginning to the end of the flight. AAM is continually in use during various phases of flight in response to stimuli external to the crew – for example:

During acceleration and cleanup after takeoff, the failed hydraulic system results in the EICAS alert [] FLAPS PRIMARY. The crew response? First response is always ANC – Fly The Aircraft. The crew will Assessthe failure, understanding that the FLAPS PRIMARY alert indicates that the flaps are attempting (and succeeding) to retract using the secondary (electric) system. As such, the only Actionrequired is perhaps to monitor airspeed as flap retraction will be slow and speed intervention may be required to keep clear of the flap limit speed. The flap system failure will involve itself later in the Management phase as a Fact when deciding the final disposition of the flight.

Having completed the acceleration and flap retraction phase of the takeoff – the crew have to decide what to do next. ANC requires that the crew ensure continued safe flight path, and suggests the requirement to make a short term Navigation decision. This navigation decision is typically between continuing away from the departure airfield; holding in the area; or diverting to a takeoff alternate. Much of this decision making is often made on the ground as part of the departure brief.

The 777 EICAS incorporates AAM principles as part of the EICAS Review / Memory Items / Checklist / Notes /Non-Normal before Normal methodology. During the above scenario, EICAS prompts crew during the takeoff (within the bounds of takeoff inhibits) with a series of alert messages (Warning, Caution, _Advisory) – some of which have checklists, some of those checklists require early completion of memory items. ANC requires that crew ignore these during the first critical phase of flight to 400 ft (unless Aviate is compromised). At 400 ft with ANC established the crew Assess the need for a response and Action the required memory items.

There has been some discussion recently around FMC scratchpad messages, their role in flight deck alerting, and an appropriate crew response. Most particularly around the habit that some crew develop – usually during transition simulator training when many spurious messages are generated and often cleared without real understanding of their meaning). We areseeing this in the sim and in the aircraft – occaisionally to the detriment of the operation of the aircraft.

FMC (Flight Management Computer) scratchpad messages are generated at the bottom of the screen built into the FMC CDU (Computer Display Unit). It is a one line display that the FMC uses in order to pass a message onto the crew. They are not (directly) a part of Boeing’s design intent for the alerting system of the aircraft – that said, some of them do come with an EICAS alert FMC MESSAGE – many do not though.

The scratchpad itself is the incongruous name given to the bottom line of the CDU. Any text entered in via the keyboard or line selected down from the higher lines of the CDU end up in the scratchpad. From here they can be either cleared or line selected up into one of the lines of the CDU display above. As an example, you can use the keyboard to enter the name of a waypoint “YOW” and enter it into the LEGS page to change aircraft navigation.

The scratchpad is also where the FMC places messages. These messages cover many purposes – data entry errors; a requirement for additional information; details of uplink/downlink COM status, and more. Apart from the messages themselves, the FMC CDU also has CDU Annunciator lights on the front used to communicate as well (DSPY – Display; OFST – Offset; MSG – Message; and EXEC – Execute) – do you know (exactly) what they all mean?

Scratchpad messages are classified as follows, and come with the following annunciations:

The use of the same space for data entry and to communicate messages would seem to be somewhat fraught – but not when you realise that there are actually two display lines in this area, one over the other, with the scratchpad data entry line having priority over the scratchpad message line. It is this feature that allows you to retain a scratchpad message while you correct the situation that prompted it – which is in keeping with the way we are trained to deal with most error messages on the flight deck. For example …

You were/are off track (due weather) and now that you are in the clear, decide to head back towards track and return to FMC LNAV navigation. You turn the track bug and the aircraft follows. You’re pointing towards the next waypoint, and select LNAV on the MCP. At this point LNAV appears in white on the FMA indicating that LNAV mode engagement is armed; but an FMC scratchpad message annunciates “NOT ON INTERCEPT HEADING“. According to the FMC Pilots Guide “LNAV is selected on the MCP and the airplane is not within the capture criteria of the active leg, or the current heading does not intercept the active leg.”

The most common response to this is to clear the scrathpad message and adjust the track of the aircraft so that it intercepts the active leg. However if instead the message was left in the scratchpad, while you turn the aircraft to intercept the active leg, the FMC would re-evaluate the intercept and remove the message by itself – validating the action of the Pilot Flying. From a CRM/NTS/Error Management point of view – this is a far more satisfying solution.

But wait, there’s more …

I mentioned that in fact there are two scratchpads – and there are. It is possible to interact with the CDU scratchpad, either entering data via the keypad or line selecting data down from the CDU screen into the scratchpad, while retaining the scratchpad message in memory. Any use of the scratchpad by the pilot will hide the message, but retain it (if it’s not cleared first). Once you have used the scratchpad and cleared it of your entries – the scratchpad message will be displayed.

Note that although it may seem clumsy, it’s impossible line select a scratchpad message into a CDU LSK position – but still, it seems like a lot of bother, doesn’t it.

But consider the case of a runway change on departure. A new runway is selected and the FMC generates “TAKEOFF SPEEDS DELETED”. It’s telling you something important – “New performance data is entered after the VSPEEDS have been entered on the TAKEOFF REF page, a takeoff thrust selection change is entered after the VSPEEDS have been entered, or pilot-entered values do not comply with the relative takeoff speed check. The crew must reselect proper VSPEEDS.”

Normally the pilot manipulating the FMC will clear this message (hopefully with the acknowledgement of the other pilot) and then ideally deal with the missing speeds straight away. However it is entirely possible to retain this message right through a takeoff speeds entry process until the speeds are re-entered, at which point the message will self clear. Which of these two process is less prone to error – less prone to forgetting to re-enter your speeds?

In any event, our discussions did resolve one thing – we are going to introduce an SOP whereby a pilot who intends to clear a scratchpad message is required to confirm that action with the other pilot. For the most part – this should be happening anyway, but taking this action raises the visibility of a good habit – and give Check Captains something to look for as well.

The CDU scratch pad is the FMC’s prime method of trying to tell you something. Messages like “UNABLE HOLD AIRSPACE” or “TAKEOFF SPEEDS DELETED” or “ROUTE DISCONTINUITY” are the FMC’s way of communicating a problem to the crew – a problem that is valid, even if the crew don’t understand the message. It’s not uncommon to see crew clear those messages with minimal acknowledgement, a habit that unfortunately commences during simulator training.

CDU Scratchpad messages need to be dealt with like any other annunciation in the flight deck. Noticed, Called, Analysed, Acted Upon. Some of the more common(ly ignored) FMC messages are listed here.

VAI SOP Standard Calls require the CM1/CM2/PF/PM to confirm a scratchpad message with the other pilot prior to clearing a message. This requirement commences once the pre-flight initial CM2 setup / CM1 cross check is complete.

While there are scratchpad messages which are all but inconsequential to flight (STANDBY ONE or INVALID ENTRY) and there are messages which are commonly understood and occur routinely (INSUFFICIENT FUEL [during route changes]; UNABLE HOLD AIRSPACE; DRAG REQUIRED or UNABLE RTA) there are also messages which can have a significant impact of flight path and flight safety (DISCONTIUITY; INSUFFICIENT FUEL; RW/ILS FREQ/CRS ERROR; or TAKEOFF SPEEDS DELETED).

Finally, a smart pilot may not choose to clear an FMC CDU Scratchpad Message – but instead retain the message in the scratchpad until the underlying cause has been corrected. The CDU is fully functional while a scratchpad message is displayed with any data entered into the scratchpad line replacing the message until that data is either line selected into the CDU or cleared, at which point the message is returned – if it’s still valid. An example of this could include “NOT ON INTERCEPT HEADING” when LNAV has been armed but the aircraft is not tracking towards an active leg – correcting the aircraft track will clear the scratchpad message.

Standard Calls : FMC Scratchpad Messages

The FMC CDU communicates with pilots through data entered and calculation results on the CDU itself, four CDU Annunciators (DSPY, OFST, MSG and EXEC) and CDU Scratchpad Messages. These messages are categorised into Alerting, Communication, Advisory and Entry Error messages.

Anytime a CDU scratchpad message is generated after the initial pre-flight CM1/CM2 data entry/cross check procedure is complete – the CM1/CM2/PM/PF is required to check awareness in the other pilot prior to clearing the message. This is required whether the EICAS FMS MESSAGE is generated or not.

PM : “FMC TAKEOFF SPEEDS DELETED”PF : “CHECK”

For a conservative NTS operation – consideration should be given to not clearing certain scratchpad messages, but instead dealing with the underlying cause behind the messages. Once the cause has been dealt with, the scratchpad message will be removed by the system. D5 Practices and Techniques refers.

One of the limitations I’ve encountered with today’s all singing all dancing aircraft simulators is the total inability to simulate casual mapshift.

As you know, the position of the aircraft (for display on the Map and as used by a number of systems) – is determined by the FMC (Flight Management Computer). Of course the FMC actually has no inherent ability to determine position at all – it merely looks at the positions provided by other systems and uses that information to decide where the aircraft is.

These systems include ADIRU/IRS (Inertial Reference System), Radio Navigation Aids and of course the now ubiquitous GPS. The FMC looks as these positions and uses the most accurate one – typically GPS – to update it’s own determination of aircraft position.

This distinction is important. In the event of a GPS failure which causes the FMC to re-consider (for example) the ADIRU/IRS as the new position source, it will take some time for the FMC position to “wander” across to the IRS determined position. It’s not instantaneous – which is a good thing, given that the aircraft would take a sharp turn to head back towards track if the position reference were to change quickly.

GPS is indeed ubiquitous, as these days at any point in space it’s not unusual to be able to gain position information from between 6 and 9 satellites. This is a whole lot of redundancy and increased accuracy in position fixing. While that many satellites are unlikely to fall out of the sky any time soon (solar flare activity notwithstanding) the weak point is of course the onboard GPS equipment. Should it fail then we revert to 1980’s navigation technology of Radio Navaids falling back on ADIRU/IRS. Today’s IRS’s are stunningly accurate – after 14 hours of flight, despite an ANP of 20 miles or more – it’s not unusual to see less than a mile’s difference between the GPS and ADIRU. But that mile discrepancy is a significant impact on terminal navigation – were it not for radio updating of the FMC position.

Isn’t it about time someone looked at the formula for determining the ANP of a current generate IRS? It sure seems like the numbers (which starts at about 4 nm/hr and ameliorates out to about 20 nm after 10 hours) seems a bit excessive when I’m scarcely seeing more than about half a mile drift on the IRS when I shut down after 14 hours).

Oh – and if you’re not clear on the difference between the ANP of an inertial position and actual IRS drift then you’d better stop reading this and head back into the FCOM.

Therefore, it’s such a pity we turn off NAV RAD updating of the FMC position by default in the FMC during Pre-Flight. There’s a reason we do this and it’s based on RNP / RNP-AR approvals, but it does leave the ignorant exposed should GPS position fixing fail.

From a training point of view – this is where the simulator frustrates me no end.

You see today’s simulator’s are totally unable to simulate IRS drift, except as a hugely obvious simulated mapshift failure. IRS drift is actually a normal event – rather than a non-normal one. At any stage of flight, pressing the EFIS POS button will show some degree of IRS drift – along with the FMC ignoring it because GPS or NAV RAD is in use. If these other more accurate sources aren’t available – you won’t see IRS drift because the FMC is following the IRS – even though the drift is there; you now have mapshift. But in the simulator – the IRS doesn’t drift and no matter how long you fly for, the IRS position is superimposed right over the GPS position – which is totally missleading.

This is where the GPS failure comes in. In preparation for RNAV RNP AR approaches – all radio nav updating in our aircraft has been disabled by default. Hence if the GPS fails, the FMC will not use radio aids to calculate position – instead it will default to the Inertial ADIRU/IRS position. Fortunately the GPS Checklist encourages the use of radio navaids as a navigation source – but it’s not exactly clear about the need for it.

Practices & Techniques : GPS Failure and Subsequent Navigation

In the event of total GPS loss to the aircraft, the QRH NNM checklist asks the crew to consider allowing the update of FMC position by radio updating “If radio updating is allowed.”

Radio Updating of the FMC position is inhibited by default, and checked in this position during pre-flight. After a GPS failure, if radio updating remains OFF, all position fixing all FMC position (and subsequent LNAV Navigation) is based on IRS positioning. On a typical 14 hour flight to LAX, this means the aircraft could be anything up to 1 nm left or right of centreline if LNAV is used to position onto a precision or non-precision approach.

This failure seems simple enough – one of the engines is low on oil pressure; the checklist reduces thrust and shuts down the affected engine. Then there’s the reality of dealing with an engine NNM under various conditions of high altitude and high thrust settings.

This failure has something of a history in 777 simulator training. As candidates (and instructors) encounter the failure after the first instance, there’s a tendency to “over think” and become somewhat inventive in how it’s handled. Let me explain.

In the simulator this failure is typically given at high altitude to add the complication of the requirement for an engine out drift down. Thus the PF needs to decide between running the checklist, or commencing a drift down in anticipation of the thrust loss – or both. The determining factor is usually the margin above minimum manoeuvring speed – it’s a judgement call by the PF/Captain.

Alternatively it’s given during climb with high thrust set on both engines. This reduces significantly the time before the onset of engine failure indications including further limit exceedences, engine/airframe vibration and more severe damage. You can’t run an engine for very long without oil pressure and the more thrust you ask of it, the shorter that time period is. It should be noted that in this circumstance one of the Engine Failure checklists (along with the associated memory items) is usually a more appropriate response to the failure than the annunciated ENG OIL PRESS checklist.

In the simulator, the time between the EICAS message and the onset of engine damage is pretty dependent on thrust on the engine and is essentially formulaic – driven by simulator programming. If the failure occurs in the climb and climb thrust remains set – engine failure with the potential for engine damage comes soon(er). Once the engine indicates the conditions for Limit/Surge/Stall or Severe Damage/Separation, the PF should commence an Analysis (P&T 7.13 Engine Failure Analysis) and commence any applicable memory items. Don’t forget the Fly The Plane.

It’s not unusual for the crew when first given this failure to be slow in actioning the checklist, and the engine fails with associated limit exceedence / damage indications. The crew’s reaction to this experience, combined with some (perhaps) inappropriate debriefing by the instructor leads to some inventive responses from both trainees and instructors alike during follow up encounters. This usually takes the form of:

Calling for the Engine Limit/Surge/Stall checklist memory items in response the low oil pressure indication. Since low engine oil pressure shows a limit exceedence, this would seem a logical response. Having run the memory items – the appropriate follow on would be the Engine Limit/Surge/Stall checklist rather than the annunciated Oil Pressure checklist (although attempting a re-start of the engine may not be advisable.) Note however that these memory items only reduce thrust on the engine and it’s the checklist that actually shuts it down precluding further damage. Thus the memory items will only delay the onset of engine damage. Therefore a follow action often seen in the simulator is …

Calling by memory for the Fuel Control Switch … Cutoff. Some instructors will frown upon this action, but it’s a legitimate call by the Captain of the day to make. This combination of Engine Limit/Surge/Stall and Fuel Control Switch secures the engine and prevents (further) engine damage when for some reason responding directly to the ENG OIL PRESS is not possible (why not?).

The above is however a fairly complex response to a simple loss of oil pressure. It’s hopefully fair enough to say that the simplest response is probably to (a) fly the aircraft; and (b) run the checklist. If the aircraft is in a high thrust situation this can often be relieved quickly by the PF through levelling off and slowing down – without the need for running checklist memory items or checklist items by memory. Levelling off and slowing down (where possible) usually achieves the aim of reducing thrust on the affected engine enough to give you time to complete the ENG OIL PRESS checklist (at least to Fuel Control Switch … Cutoff) prior to engine damage.

The point of Karlene’s article is that often the manfacturer’s profile doesn’t comply with the ATC environment we find ourselves in, and the performance characteristics of the aircraft we fly are such that conforming to ATC speeds on approach can lead to a requirement for exploring the flight envelope a little in terms of configuration and speed down final approach.

Any discussion about speed and configuration on final – especially when diverging from the manufacturer’s documented profiles – needs to commence with a review of the Stabilised Approach concept.

Stabilised Approach Criteria

Behind any discussion of speed and configuration on approach is the Stabilised Approach criteria. The specifics vary from airline to aircraft type, but the essential concept is the same. The stabilised approach concept has distant origins but was developed and promulgated by Flight Safety’s Approach and Landing Accident Reduction program. A clear decision point on the approach – typically a height above the runway – by which the aircraft must meet the stabilisation criteria documented by the airline. The criteria typically requires landing configuration, final approach speed, minimal required lateral and vertical divergence from the published approach path – essentially in position to land. It may even require the completion of the Landing Checklist.

Know your company stabilisation criteria and remember that not only must you meet the requirement by the decision point or go around – if at any point during the approach you realise you won’t be able to meet the requirement – you should go round then and not wait until the stabilisation point. My airlines’s requirements are pretty standard and the stabilisation altitude is 1000 ft.

Having established in our mind the stablised approach concept, optimising the approach prior to that point requires a clear understanding of how the Boeing FCTM promulgates the instrument approach.

Boeing 777 FCTM

The Boeing FCTM covers the 777-200/ER/LR/LRF/300 and 300ER, which means a variety of approach speeds. Apart from the documented aircraft variations, the FCTM is also aimed at a wide range of pilot skills and backgrounds, providing a clear, conservative baseline of operations which professional aviators must use as a basis from which to expand and extend to suit the operational environment.

A quick glance at the pictured profile shows quite a reasonable profile for an aircraft vectored in for a 2000 ft ILS with minimum run in to the FAF – but this is patently unsuitable for operations into many capital city airports – such as Los Angeles KLAX, or Melbourne YMML – where glideslope intercepts well above 3000 ft AAL are common. Flying that approach with gear down, flap 20 at glideslope alive and landing configuration at glideslope intercept won’t endear you to the approach controller. You’ll also chew through a several hundred kilos of your reserve fuel that might come in handy should you need to head for your alternate.

Delayed Flap

The FCTM documents a delayed flap concept for Noise Abatement or under “adverse conditions” (surely that describes ATC at KLAX?) which essentially flies you down the ILS with Gear Down, Flap 20, delaying landing flap selection until approaching 1000 ft AAL. At reasonable weights the 777-300ER Flap 20 speed is around 160 knots, which is still a little slow for final approach sequencing, and once again you’re basically dragging the aircraft in with lots of gear and flap.

Flap 5, Flap 5 Speed down the Glide Slope

Assuming for a moment glideslope intercept at altitudes AAL of 2500 upwards, experience has shown us that the 777’s (all of them) can be flown into a 3 degree slope with Flap 5, Flap 5 speed.

Note you need both of these – if you call for Flap 5 as you capture the slope, the aircraft will usually refuse to slow to Flap 5 speed – indeed at idle thrust it will often accelerate.

If you like living on the edge you can fly clean, level, at Up speed as the glideslope comes alive, calling for Flap 1 and 5 in turn, reducing speed and you’ll typically be at Flap 5/Speed as the glide slope captures – as long as you aren’t distracted by a radio call or the deceleration isn’t degraded by turbulence.

From that point what happens next depends on a range of factors including the specific aircraft type, the landing weight and therefore approach speed, ambient conditions, glideslope angle, etc. But in essence you’ll get one of three results.

The aircraft will maintain Flap 5 speed, with minor use of thrust on the way down (light aircraft, smooth air).

The aircraft will keep Flap 5 speed, but the thrust remains at idle and you might well get some creeping increase in the speed.

The aircraft will begin a slow acceleration down the slope, with the engines at idle thrust.

The first two are acceptable, the second requiring monitoring. The third possibility is typical in the heavy 777-300ER or even lighter aircraft when ambient temperature is high and thermal activity tends to de-stabilise your approach speed. At this point – this is where Flap 15 comes in.

Flap 15 on Approach?

I was taught for many years that Flap 15 (and Flap 25 for that matter) is a takeoff flap setting and therefore has no place during approach (lots of verbal flight deck hand slapping at this point). It took me a few years in the left seat (including training under a regime that for a time enforced this) and not a few progressive check/training captains to unhook my thinking in this regard. Flap 15 is a flap setting and nothing more. It uses the same minimum speed as Flap 20 (Vref30 + 20 knots) but carries less drag. While there are no limitations or issues using Flap 15 on approach, the FCTM does describe Flap 15 as a “manoeuvre” flap setting. It’s intended use is outbound / turning inbound on the approach, rather than down final … but …

Flap 15 is perfect when you’ve intercepted the glideslope at Flap 5/Flap 5 speed and find yourself in a speed-unstable configuration. If the thrust remains at idle and the speed (typically at 180 knots for Flap 5, perfect for ATC separation requirements) begins to increase, Flap 15 adds enough drag to recover your speed control. You can retain your 180 knots without the drag of Flap 20 and continue down the slope. Until …

The Flap 5/15 ILS continues to a point at which the end of … Gear Down (Speed Brake Armed) -> Flap 20 (Checklist Up) -> Speed Reduction -> Flap 30 -> Landing Checklist Complete … meets the stabilisation point of typically 1000 ft AAL. This sequence typically takes about 800 ft if done without interruption – a more conservative value of 1000 ft covers range of operating environments. So as you approach 2000 ft AAL, you should be thinking of establishing the landing configuration having optimised your approach to this point quite well indeed.

Sometimes something as simple in the aircraft as looking and assessing the indications in front of you can be far more complex that it first seems. I was reminded of this in the simulator recently as several crews were required to assess aircraft pressurisation performance during a door unlocked indication failure in flight. First, some background.

Our current phase training includes a DOOR FWD CARGO unlocked indication shortly after takeoff. Apart from satisfying a matrix requirement and giving crew experience of this non-normal, the overt intent of this failure in the simulator profile is to give crew a reason to divert to the nearest suitable airport.

The DOOR FWD CARGO checklist itself requires that the aircraft be de-pressurised to ensure that if the door was to come off, less damage would be done than if the aircraft were fully pressurised. At this point the crew are at 8,000 ft and de-pressurised. Continuing to Los Angeles seems unlikely.

That said in a previous simulator we had two similar failures like this. The first was Door Forward Cargo indicating not locked in flight; the second was Door Forward Cargo – door comes off the fuselage out into the airflow and on it’s way down the side of the aircraft, takes out the right engine along with two hydraulic systems. As the instructor it was easy to confuse the two failures in the IOS – well, it was easy to confuse them once. Being pressurised/unpressurised never seemed to make much impact on the amount of damage that forward cargo door did as it embedded itself in the right engine – but I digress.

Anyway – so I was supposed to program a Door Forward Cargo indication failure on takeoff. I did this through the gear lever so I wouldn’t have to hit the button on the failure myself. I programmed the simulator so that when the lever was selected UP, the failure became active – and sat back to watch.

At least that was my intention – so far it hasn’t been successful. The Sim Instructor Operator Station (IOS) indicated the failure was active – but there was no indication to the crew, even after the takeoff inhibit ended. Oops. As it turned out later – this failure is only written by CAE to work on the ground. We’re still trying to find out why, but even knowing that isn’t going to change the fact that the failure doesn’t work airborne.

As such I was forced to improvise on the spot – often not a great recipe for training fidelity …

Sticking with the theme – I failed one of the other cargo doors instead. The problem now is that the simulator is VH-VPD which was our first owned aircraft, and it has the small version of the main cargo door aft of the wing. The size distinction is important in this failure. All doors on the aircraft (Cargo, Cabin, E/E Bay, etc) are “Plug” type doors – a Boeing innovation where essentially the door is bigger than the hole it fills and therefore the higher the pressurisation differential between inside/outside the aircraft, the less likely the door will come open. Don’t ask me how a door that’s bigger than the hole opens outwards to let the passengers and cargo in – that’s just magic as far as I’m concerned.

Despite being a plug type door, when not indicating locked the Forward Cargo Door checklist requires the aircraft de-pressurise. We have always presumed this is related to the size of the door. The smaller Aft Cargo door does not require de-pressurisation and diversion – as long as the cabin is pressurising normally. Thus despite the failure the crew would assess and continue on to Los Angeles, extending the sim session from 2 hours to 14. Since I needed them to divert (no coffee or toilet in the sim) the next obvious choice was … you guessed it, pressurisation failure.

Because I knew the small door failure wouldn’t cut it, I programmed them simultaneously. Rather than the instantaneous heart-rate-raising big bang failure, I used slow de-pressurisation. Essentially the aircraft would fail to pressurise because the aforementioned small door was not only unlocked, but not properly closed. Hence the crew would assess pressurisation, realise the problem, and return. At least, that was the plan.

This statement seems pretty clear, doesn’t it?

Note: The aft lower cargo door is in a safe configuration
as long as cabin pressurization is normal. Positive cabin
differential pressure ensures the door stays in place.

That shouldn’t be too hard to work out, should it? Pressurisation at this point is assessed via the AIR Synoptic page. Apart from showing good bleed air from the engines to the air-conditioning packs, the AIR synoptic also shows values such as Cabin Altitude and Rate of Climb, Differential Pressure and Forwad/Aft Outflow value positions.

A good crew would typically see the picture shown here during climb after takeoff. By “good” I mean a crew who would initially see the failure, think about it, then ignore it. They’d have QRH familiarity and know that this checklist doesn’t come with memory items, but they’d also know what the most likely outcome of this checklist was. They’d follow Boeing doctrine and delay running it until the critical take off phase was over, the aircraft was clean (gear and flaps retracted) and usually wait until the aircraft had cleared any terrain issues associated with the departure airport. Thus typically the aircraft would be climbing through about 7,000 ft by the time they finished the checklist and had a look at the AIR synoptic to assess pressurisation.

A quick glance shows you – Cabin Altitude below aircraft (as it should be); Cabin Altitude Rate climbing (normal, so is the aircraft); Outflow Valves Closed; duct pressure adequate, differential pressure positive. The problem here is … the quick glance. Like me – you’re looking to confirm the normal, rather than seeking what’s abnormal and looking for indications against the normal bias – looking to confirm a problem. Now let’s look again.

Cabin Altitude – 5,500 is quite high. The cabin altitude is controlled in part by the selected cruise altitude. High takeoff weights (and therefore lower initial crusing altitudes) combined with the high cabin differential pressure capability of the 777 (9+ PSI), initial cabin altitudes in the 3000-4000 feet range are normal. This one is at 5,500 because the door is slightly ajar and the pressurisation system is unable to maintain the required lower altitude as the aircraft is climbing. It’s doing it’s best – I’ve been seeing cabin altitudes up to 2000 ft below the aircraft in the climb with this failure – but still to high for an initial cabin altitude.

Cabin Rate – 800 fpm is not extreme, but again given the high diff of the 777 and the typically lower initial cruise altitudes, you see less than this typically.

Cabin Differential Pressure – a Delta P of 1.2 is way too low. In cruise it would be well over 8. The 1.2 here is because the hole in the aircraft is not quite big enough to equalise the pressure – the Bleed Air/Packs are working hard. But 1.2 is far too low for this altitude when the pressurisation is working “normally”. Speaking of holes in the aircraft …

Outflow Valves – The basic operating premise of an aircraft pressurisation system is that air flows in at a faster rate than it flows out – but it does flow out. It is only during Non-Normal events that you see fully closed outflow valves. Closed outflow valves are an indication that the Bleed Air/Packs are unable to provide adequate airflow – a pressurisation problem.

It’s very easy as the instructor to sit at the back and judge the errors of your students in front of you. It’s slightly more difficult to divorce yourself from the insider knowledge you have as an instructor and assess realistically. In this case, the signs are subtle – but they’re there. I could certainly not state with my hand over my heart that confronted with the same situation the first time, I would have picked up on these indications. For me though, the outflow valves are definitive. The only time they’re both closed airborne is when something is wrong.

The discussion point here is the concept of assessing a system on the aircraft. With EICAS Warning/Caution/Alert messages – we are no longer used to looking at gauges and indicators and assessing the performance of a system. We are also separated from the normal operation of the aircraft by automatics and self monitoring systems and synoptics pages that were looked at during initial training, but now remain hidden away until they’re required by an unusual situation. We’ve become quite reliant on the alerting system to diagnose failures and provide clear, simple indications of what the problem is and what we have to do next.

So far most crew have missed the pressurisation problem that I programmed in concert with the door failure. Once the aircraft climbs above 10,000 ft (and the cabin above 8,000 ft) the pressurisation failure becomes clear and the crew act accordingly. For myself, serendipitously this experience has taught me to take simple checklist words such as “cabin pressurisation is normal” more carefully.

A while ago I wrote about issues we were having with inserting an arrival and approach into LAX prior to exiting Oceanic Airspace across the Pacific. Essentially during the 500 mile run into our exit point (such as ELKEY) our FANS system would send a CPDLC report every 12 minutes or so announcing to the world that the pilots on board the aircraft had been playing with the waypoints in the FMC after the exit point. Automated alarms and queries from ATC – and we’d have to remove our carefully built arrival until we were out of Oceanic Airspace and approaching descent into LA.

After a discussion with Oakland Oceanic while on the ground in LA, I worked out that the solution was to flight plan out by the two paired oceanic points, thus denying ATC the option of sneaking a peak at our flight plan after the last Oceanic waypoint.

Well, today we tried it and it wasn’t a problem. Our exit point was ELKEY and so Nav Services planned us via EDTOO->ELKEY->KLAX. I had the arrival and approach inserted and briefed shortly after I came back from rest with nary a peep from San Francisco.

One complication is that since we use effectively a random routing of lat/lon waypoints across the Pacific, and often don’t follow any of the established airways into the Oceanic exit waypoints, the additional waypoint may add a few track miles to our route. Nav Services has reviewed our most commonly used routes and decided on a standard set of paired waypoints for the exit. We should start seeing these paired waypoints on our flight plans, solving the problem of delayed FMC preparation for the arrival into LAX.

Crew need to understand the need behind these two paired waypoints, particularly in the event of a bit of a kink over the leader waypoint prior to the exit – and not ask for a direct to the Oceanic exit.

For the past several months I’ve been experiencing a CPDLC anomaly approaching the west coast of the US. Essentially I’ll come back from crew rest and begin preparation for the arrival into LAX. At this point the FMC will reflect the basic OFP route of:

Lat/Long -> ELKEY -> LAX

… where EKLEY is the end of the Oceanic area and LAX is of course the VOR at Los Angeles airport.

The problem comes about as I commence my customary preparation for the arrival, which includes selecting a STAR (Standard Terminal Arrival), Approach and Runway. This changes the route and sets off an alarm with Oakland Oceanic Control. An automated system advises the relevant controller that my FMC no longer matches our notified flight plan and eventually this results in a warning message to me on board the aircraft. It’s difficult negotiating/explaining the situation over a CPDLC link – and so essentially I return the FMC back to match the flight plan.

I prepared everything else I could for the arrival – Weather/NOTAM review, Charts, Briefing and the rest of the aircraft setup. Then once we were cleared out of Oceanic airspace – about 15 minutes before top of descent – I entered the arrival details into the FMC, had the PM cross check it and down we went.

The first time this occurred I didn’t think about it very much, but the second time I saw it was as a Check Captain sitting in the back seat, watching the primary crew prepare for the arrival. Essentially the same thing happened, except the crew delayed all arrival preparation activity until the could enter the arrival into the FMC. This meant that the briefing didn’t start until descent was well commenced and the whole thing was a bit of a shambles.

So I called Oakland Oceanic and spoke to the senior controller, who explained what was happening, and what had change to bring it about.

As it turns out, after a number of position reporting errors, Oakland Ocenic activated the alerting system that was now causing us problems. Essentially every 12 minutes (or so) the aircraft reports position via CPDLC to San Franciso Oceanic. This report consists of current position, estimate for the next position, and the name of the following waypoint. Thus on the several hundred mile run into ELKEY – it was reporting estimates for ELKEY and that the following position was LAX, which matched out Flight Plan. But as soon as we changed the FMC to reflect the fact that we weren’t going directly over the top of KLAX airport to the LAX VOR, the automated system still generates an alarm that our FMC doesn’t match the Flight Plan. And so on it goes.

I had an extensive discussion with the Senior Controller and together we realised that the solution was to file via the paired waypoints that complete all oceanic transitions across the Pacific – in this case:

Lat/Lon -> EDSEL -> EKLEY

Thus all position reporting right up to EDSEL would not reveal any changes to the flight plan after ELKEY. By the time you get to EDSEL and the problem is likely to occur, you’re cleared out of Oceanic Airspace, talking to SOCAL (Southern California Control) and the anomaly is moot.

I advised my company of this in April. In the meantime there are several options that can be considered to get around this problem.

Route 2.

Our FMC’s incorporate a Route 2 facility.Thus you can build an arrival, approach and runway in Route 2 , then activate it later on when cleared. This allows the crew to setup and brief and prepare for the approach – even check the route in the FMC – without interfering with the active flight plan.

Route 2 has the following limitations:

You can’t predict fuel/time with Route 2. Thus until we have a clearance, we would not have an accurate idea of fuel/time/top of descent planning until STAR clearance received and Route 2 activated. We tend to arrive in LAX with bags of fuel anyway (at least until we improve our EDTO limit) but it’s still not ideal.

When reviewing Route 2 you can’t get time/altitude predictions which means if you want to evaluate what altitude/speed an aircraft will be transiting a waypoint, you can’t. This is a technique crew can put to good use. In particular you can delete a hard constraint of the active route – without executing – and see what speed/alt the FMC would want to fly you through at that point, thus gaining pre-situational awareness on whether the STAR will have you high or low at that point; whether the constraint will be binding on the descent path; etc. You can’t do this with Route 2.

Activating and executing Route 2 is at least little fraught in that you end up with crew activating and executing a route that is out of sync compared to their progress on the active route. You can’t update Route 2 with a route copy because you lose your changes. You can edit Route 2 to keep it in sync with where you are up to in Route 1, although current track doesn’t follow so when you activate it you would still have to go direct to the correct waypoint before executing. On the other hand if we encourage our crew to regularly use Route 2 for arrival preparation into LAX and activate/execute it shortly before top of descent we will at least ensure our pilots become intimately familiar with all the tricks and traps of using an inactive route – as the Flight Safety Officer it will also be fun to read the reports in the meantime …

I personally would have concerns about flying a route that won’t be checked after it has been activated. To be honest I can’t yet articulate what my concerns are on this one – but loading Route 2 well ahead of time, then receiving a clearance, then activating and executing route 2 sometime later and flying it potentially without the time to check it thoroughly – that worries me.

If we start running around on Route 2 we are going to have a small set of senior captains (not pointing to any particular Asian airline here, or ex French aircraft drivers) who are going to insist on route copying and re-activating so Route 1 is the active route all the time, and I will be forced to mock them which is not good for morale.

This practice will hamper the more useful technique of planning the diversion in route 2 during times of bad weather at destination. This planning would need to take place after the clearance is received, at about the same time as the arrival briefing, with is a busy time. Diversion Alternate planning is a better use for Route 2 than as a work around for an ATC shortcoming.

If we go down the Route 2 route (sorry) ATC wins. Bugger that.

Route 2 is a viable short term fallback option – certainly better than doing nothing at all – but the simple solution is to plan via the paired oceanic exit points.

– – – – – – – – – – – – – – – – – – – – – – – – – –

I haven’t see any progress on this issue since my initial investigation and report in April. On my last flight to LAX, I had an arrival established in the FMC when I went off to last rest. When I came back, it had all been deleted. I asked the Sen FO – someone very experienced and capable (one does not necessarily imply the other …) – what happened to my arrival?

Essentially while ATC had not detected the discrepancy, it turns out that my cunning plan to fool ATC and leave ELKEY-LAX (route discontinuity) – FICKY / STAR / Approach / Runway – screwed up the arrival time shown on the in flight entertainment system, and the passengers start to worry about their connections, so my careful preparations were abandoned. Once again.

Recently I was in the simulator with two other instructors. One was my First Officer, the other was the Sadist … ahem … Sim Instructor. We were running without the ECL (paper QRH for NM and NNM) and the APU was failed. Climbing through about 5000ft, Los Angeles for Sydney – we received [] ELEC BUS L on the EICAS – the loss of the Left AC Electrical Bus. Fortunately I was flying and so my long suffering FO was forced to deal with not only this failure, but all the consequent failures, through the paper QRH.

Although reference to a few paper checklists are involved – when you look at the checklist – it’s a no brainer really. You try a few resets, see if the APU fixes the problem, but in the end without the ability to restore the left electrical bus, you’ve lost … Window Heat (Left) and a Primary Hydraulic Pump (Left). No Biggie …

” That’s It? ” my fly-buddy observed. I advised him to look at the roof.

Of course with the loss of one of the two main electrical busses in a modern (fly by wire) aircraft – there are a whole host of ancillary services lost. Many of these are reflected by the amber lights on the overhead panel.

Having looked at the roof – you later discover even then that it’s not the whole story. In this particular scenario we decided to return to KLAX. Part of the return process was fuel jettison down to maximum landing weight. Guess what? Without the Left Bus – the main tank jettison pumps are failed. You’ll be advised of this … when you start the fuel jettison.

I didn’t give this a second thought (I think I’ve been stuck on the same aircraft for too long) but it was interesting the discussion we had afterwards about this little quirk of the Boeing EICAS/ECL. There are no EICAS/STATUS messages to advise you of everything you’ve lost, and in many cases until you attempt to use something that’s failed – you won’t know about it. Older aircraft used to publish a Bus Distribution List (Electrical and Hydraulic) so that you’d know exactly what you’d lost with a particular electrical bus failure – but not on the 777. My fellow pilots were vaguely disturbed by the lack of information.

We discussed it. Our decision to return was primarily based on passenger comfort. The entire aircraft had lost galley power, IFE and other passenger services and we decided it was unrealistic to continue 14 hours to Sydney without them. Would knowing that we weren’t going to be able to complete a fuel jettison have affected this decision to return … no.

We came up with scenarios where knowing fuel jettison was compromised would lead to a different diversion airport, but in the main they were pretty far fetched. In most cases it would have resulted in diverting to that other airport anyway using some of the fuel we were unable to jettison.

It’s an interesting system design/human thought process discussion. It’s one of those cases where you presume that the manufacturer has gone to great lengths to ensure the Need To Know list is complete and correct, and accounts for all the possible permutations of the operational environment.

And you hope your presumption is correct …

Practices & Techniques : You Can’t Always Get What You Want.

Do you remember the rest of the Mick Jagger song? Well, that’s how Boeing treats pilots when it comes to NNM failures that impact multiple systems. As strange as it may seem – the aircraft will tell you what (it thinks) you need to know, when (it thinks) you need to know it – but it doesn’t go about telling you what you’ll probably want to know. The longer you are on the 777 (or more correctly, the more often you are in the Simulator) – the more you’ll find this to be true. As a student/pilot you’ll feel vaguely betrayed by the aircraft; as an instructor it’s a mild source of amusement … for example …

[] ELEC AC BUS L

Clearly I’ve eliminated the intermediate steps from the checklist, but from the picture here you can see that with this failure – if you are unable to recover the Left or Right Bus – you’ll lose Window Heat and a Primary Hydraulic Pump (Left or Right for both of these, depending on the Bus lost). No biggie, right? Well, now look at the roof.

Of course with the lost of an entire AC BUS – you lose a whole host of services. The amber lights on the roof give you more information, but for the most part, you won’t be told what you’ve lost until you try and use it.

Case in point – ELEC AC BUS L disables your ability to jettison fuel from the Main Tanks. Fuel Jettison will commence but eventually the system will fail and you’ve probably be left with a requirement to run the Overweight Landing Checklist – albeit with significantly less fuel that if you hadn’t attempted Jettison. Many pilots feel they should be told during the ELEC AC BUS L checklist that they’ve lost Fuel Jettison – but should they?

That’s an interesting discussion – but the point is that you won’t always be given everything you want to know about NNM events in the aircraft. Often at the conclusion of a NNM – particularly an electrical or hydraulic system failure – a general synoptic and overhead panel review can reveal more detail about what just took place.

Some time ago I wrote down all that I had been taught and learned about operating the Boeing 777 Electronic Checklist (ECL) in conjunction with the onboard Electronic Indication and Crew Alert System (EICAS). I’ve updated it along the way as I became an instructor and it’s become more and more of a formal document along the way.

Now it’s here on Infinidim. The disclaimer below says it all – read at your own risk.

If you have any comments, corrections or suggestions, please let me know in the Comments at the bottom of this post.

EICAS (Engine Indicating and Crew Alerting System) is the centralised system for monitoring the normal (NM) and non-normal (NNM) status of modern Boeing aircraft. It is a one stop shop for engine indications and crew alerting and in combination with the Electronic Checklist (ECL), providing a human centric set of problem solving tools for modern aircraft.

This document does not seek to explain the basic mechanics of EICAS or ECL and assumes that you already have the relevant systems and procedural knowledge from the Boeing FCOM, QRH, FCTM and some practical experience. Instead here I explain the philosophy behind EICAS and ECL, providing a consistent framework for all crew to use as a basis for handling EICAS messages, ECL NM and NNM checklists and NNM events in a consistent manner, using the best practice CRM/NTS principles of the modern multi crew cockpit. You will also find some handling tips that have come from experience with the aircraft.

You may find some of the procedures and techniques documented here somewhat pedantic and stilted, but they are intended to produce a level playing field in the handling of NNM events across crew of varied language skills, company cultures, experience levels and degrees of fatigue – these procedures become second nature with repetition.

Note that nothing in this document should be considered authoritative over any procedures found in the Boeing Normal Procedures (NP’s). The NP’s and your airline Flight Operations Manual document are overriding.

Finally, note that while most of the contents is applicable to all 777 models, a few items (such as 5.9 Engine In Flight Start Envelope)are specific to the B777-300ER with GE90 Engines.

Disclaimer

This document is based on extensive research and operational experience of the Boeing EICAS/ECL found in the 777, in conjunction with documented procedures in the Boeing 777 QRH, FCTM and FCOM. Material incorporated in this guide is taken from all three of the relevant Boeing documents, as well as Boeing publications from issues of Airliner magazine and other sources.

As such this document is to be regarded as secondary in precedence to all these reference texts and should not be actively referred to with respect to operation of the aircraft.

Additionally this document incorporates techniques that have been developed and tested in conjunction with Simulator Training but not validated in operation of the aircraft, and must be read with caution.

The pilots of many airlines have a procedural flow or checklist of items they review after the aircraft reaches cruising altitude. These are rarely documented in Airlines SOPs and even more rarely are they based on anything from the manufacturer. This is because fundamentally today’s airliners pretty much tell you what (it believes) you need to know, when (it believes) you need to know it when it comes to aircraft systems status. The pilots monitor fuel usage, flight progress, geographical situation with respect to enroute airports and the weather at those airports – but for the most part the aircraft keeps truckin’ on irrespective of how attentive the pilots are to the flight. Did I just write myself out of a job?

Top of Climb checks are traditionally the domain of the Training Department. Often personal techniques spread across instructors and training departments until eventually most of the company is performing a drill based on a (perhaps) a relatively common understanding, but damn little basis in documentation. Generally this means crew are doing something they don’t really understand, and don’t really understand why – to the point where they become very serious and pedantic about it. Inevitably this results in a kick back and in a reactionary move the trainers are advised to stop teaching any form of top of climb checks since the manufacturer doesn’t specify one. This lasts for a while until someone starts doing one and it catches on through the students to other instructors and then to the line … and the circle of life goes on.

At a recent training meeting there was a call for a documented top of climb check. Spirited discussion pared this down to the essentials and it was agreed to document one in the P&T. Thus I am surrendering to the Circle of Life …

Practices & Techniques : Top Of Climb Checks

Boeing SOP’s don’t specify a flow or sequence required after Top of Climb (TOC). Many airlines develop their own SOP flow at TOC – V Australia has chosen to specify a recommended list of actions and considerations at TOC, as follows.

Fuel/Time on OFP

Aircraft Trim

OFP Preparation

Complete NOTAM/Weather/INTAM/NTC Review

Fuel/Time on OFP

The TOC Time/Fuel should be recorded expeditiously on the OFP against the appropriate waypoint. The enables the calculation of climb fuel/time and can be compared against ACARS Departure Report Takeoff Fuel to also calculate Taxi Fuel. Note the Fuel On Board at TOC is not a particularly accurate reflection of fuel progress against Minimum Required fuel (MINR) – the first waypoint after TOC provides the first accurate indication of fuel status.

Aircraft Trim

Once the aircraft has stabilised in cruise, aircraft trim should be reviewed. It’s unusual for one of our aircraft to require more than one unit of rudder trim; but it’s not unusual for some rudder trim to be required.

The FCTM provides two rudder trim techniques, the second of which is required in the event of excessive rudder trim or aileron displacement as the result of the first technique. An excessive requirement for rudder trim should potentially be recorded in the aircraft maintenance log.

As the aircraft burns fuel and progresses through the flight, trim setting should progressively be reviewed.

OFP Preparation

OFP Preparation is covered in detail elsewhere (Practices & Techniques : Filling in a Flight Plan) but the following areas need addressing shortly after top of climb:

Completion of the Departure Times/Fuels (Out, Off, Ramp Fuel etc)

Navigation Log Waypoint Times to the end of the OFP

EDTO Contingency Summary Page

NOTAM / Weather / INTAM / NTC Review

The pre-flight environment is hectic and often time poor. The essences of the pre-flight documentation review is to ensure a legal and safe dispatch. The review of all Enroute Airport NOTAMS/Weather and FIR specific NOTAMS is not a requirement of this phase of flight.

However once established in cruise, it’s crucial that the flight crew review completely all the documentation provided for the flight by Navigation Services. The impact of NOTAMS & Weather at non-EDTO airfields and FIR NOTAMS should be reviewed and if necessary notes made to provide this information to the relief crew for the next handover. Since it’s often NOT the Primary Crew who review Departure/Destination/Alternate Weather and NOTAMS during pre-flight – this is the time for those areas to be reviewed in detail to ensure nothing was missed.

Systems Review ( [Very] Optional )

If desired, the PF can consider a system review of the aircraft at top of climb. It must be noted that this is for personal awareness only and is not a required procedure. When reviewing systems pages, you’re not expecting to see anything unusual – that should have been notified by EICAS.

I should mention that each of these systems pages should be reviewed for normal operation. Think carefully before you decide something is no normal (especially if there’s no associated EICAS/STATUS message …)

After this, the FMC FIX and ALTN pages can be prepared for EDTO Alternates / Enroute Situational Awareness.

Any long haul pilot is well aware that changes in the weight of the aircraft at takeoff have a significant impact on the fuel burn of the flight. This includes changes in Fuel as well as Payload. For example – If I decide that I want to carry an extra 2000 kg of fuel from Los Angeles to Sydney for holding purposes (which is less than 20 minutes or 4 holding patterns by the way), then apart from the holding fuel – I’ll need to load an extra 900 kg of fuel – to carry the extra 2 tons. As such – I’ll need to load almost 3000 kg of fuel in order to be able to carry out 4 holding patterns prior to approach into Sydney. Has anybody mentioned this to Sydney ATC?

The correction required is partly based on the weight concerned, partly based on the length of the flight. Our flight plans come with a correction figure to allow us to calculate the change in Fuel Burn that results from a change in Take Off Weight – assuming the weight is being carried to destination – it’s called the the LNDG correction figure. For example if the payload of the aircraft increases by 1500 kg and the LNDG correction figure is 500 Kg/Ton – I’ll have to add 750 kg to the refuelling figure to cover the increase payload. Note that this 750 kg not only covers the 1500 kg of weight – but the overall increased 2250 kg total weight of the aircraft. Confused? Read On.

Recently we’ve been having fun in Abu Dhabi with restricted take off weights due to the high ambient temperatures. This has necessitated some fast figuring on the backs of the flight plans as well as some quick SATCOM calls to Nav Services. And it has renewed my interest in a technique that our ex-Cathay pilots have shown us on how to use the OFP LNDG correction figure to calculate a new limiting ZFW based on a force TOW change.

Time to write it into the P&T.

Practices & Techniques : 8.25 Using LNDG To Calculate A Change in ZFW based on RAMP Weight Change.

The OFP LNDG figure can be used to calculate a limiting Zero Fuel Weight (ZFW) based on a required change in Takeoff Weight (TOW).

While significant changes in weight should trigger a request for a new flight plan calculation – when a performance limited takeoff weight requires the quick calculation of a new ZFW, crew can use this technique to calculate a reasonably accurate figure.

In this example the OFP has a TOW of 340.0 tons, while the flight has a takeoff performance limit of 333.0 tons. The resulting 7 ton reduction will be partly payload, partly the fuel no longer required to carry the load. Simply offloading 7 tons of payload is an excessive reaction to the TOW change (assuming the fuel is not already on board …)

The formula uses the difference in TOW and a figure of (1 + LNDG); all calculations are done in Tons to keep consistent. The mathematical basis of the calculation is similar to removing a previously applied percentage by dividing – rather than subtracting.

The 7 Tons is divided by (1 + 0.44) to give a 4.86 ton change in ZFW. This results in a limiting ZFW of 212.450 tons.

An additional calculation will be required to calculate the change in Trip Fuel associated with the ZFW reduction.

In this specific example, a re-run of the OFP using the same parameters results in an accurate ZFW of 212.877 Tons – the manual calculation is out by only 420 Kg over a 7000 Kg change. Remember that the RAMP/LNDG figures lose accuracy over large weight changes. Changes (outside ± 3 tons of ZFW) may prompt the crew to contact Nav Services for an updated OFP Calculation.

Sometimes during a NNM in the simulator you see that when landing configuration is established, and the aircraft is being manoeuvred around the approach at the minimum flap manoeuvre speed – a further speed reduction will be required to set the NNM checklist specified reference speed (plus 5 knots). Exactly when to set this speed often becomes a discussion point in the debrief …

The most common error is to forget to reduce the speed and fly the approach and landing at the minimum flap speed, rather than reduce it to final approach speed for final approach and landing. This results in a slightly longer landing distance.

The next most common error is to reduce speed too early – the aircraft is left manoeuvring (turning, levelling) at several knots below minimum flap speed.

The correct technique is to set final approach speed – when on final approach. That is, when established on final descent straight in to the runway.

Occasionally NNM events that require a non-standard final approach speed create a gap between the PFD placard minimum speed for the existing flap configuration and the required final approach reference speed – despite in landing flap configuration.

Specifically – while planning to land at Flap 20 because of a NNM, the manoeuvring component of the approach (vectoring, outbound, turning inbound, etc) is completed while maintaining the Flap 20 minimum speed.

However final approach and landing will be flown at the NNM checklist specified reference speed (+5 knots) which is often based on Vref 30 (plus additive) and can be several knots below the Flap 20 minimum speed. If this is the case – then the time to set the speed to the final approach reference speed is … when on final approach with, descent established towards the runway. Intermediate manoeuvring should be accomplished at the minimum flap speed – in other words don’t reduce speed too early (and don’t forget to reduce it …)

A Runway Change, particularly once the aircraft has begun to move under it’s own power, can be a profound change to implement on the flight deck.

If you sit on the flight deck in cruise, look around and consider the worst sequence of runway change – say from a long runway away from terrain and weather, to a shorter runway in a different direction towards terrain and weather – then roll your eyes over all the switches, buttons and knobs in the flight deck and all the FMC CDU pages and entries as well – there are dozens (at least) of potential changes required to action a runway change. All while taxiing for the new runway (not a good idea) or while stopped on the taxiway, blocking aircraft behind you (otherwise know as collateral damage). Oh, and you’re burning fuel (about 2000 kg/hr) at this point as well, I hope the runway change was towards your destination, rather than away from it.

In looking at all the changes required on the flight deck – did you miss the biggest one? The Pilots. Each pilot develops during pre-flight a mental model of the Departure, including aspects of aircraft movement across the ground and through the air, configuration during takeoff and what will be required to change that configuration airborne, direction of turn, acceleration, noise abatement, speed and altitude control and other more subtle aspects of the departure. In the midst of what can be quite frankly the chaos of a runway change on the run – you’ll need to re-build that mental model as well. Often it’s easier to get the plane to do the right thing after a runway change than it is to update the pilots on the full implications of the change on the flight.

Preparation for the expected runway and the associated development of a mental model is accomplished during pre-flight in a sequenced, logical, time pressure free flow (I know it doesn’t always seem that way …). Each time you depart, the majority of actions performed during pre-flight that relate to the specific runway are performed the same way each time, and runway specific items are not separated out from that process. We never set the flight deck up, calculate and cross check takeoff data, complete the Departure Briefing, then the Pre-Flight and Before Start Checklists – then finish of by doing all those items only related to the runway. Preparing for runway is integral in the pre-flight process – which is why determining the changes that must be made when the departure runway changes can be such a challenge.

In my previous company I was fortunate (?) to experience many runway changes. We flew a higher number of sectors each month, runway changes were, well if not common place, at least regular. As a line pilot, particularly a First Officer, I never gave it a great deal of thought – you just did what had to be done.

When I moved to the Left Hand Seat, I had a number of encounters which altered my world view. I suddenly found I was managing a runway change, rather than actioning one – and that made all the difference in the world (how many times has that been said by new Captains about 12 months after they upgrade …). Eventually I developed for myself a Runway Change Procedure and stuck it on the back of my Clipboard.

After that, every time I was subject to a runway change – whether on stand or approaching the runway – I reviewed it. Over time it grew a little, but it hasn’t really changed for quite a while.

When I commenced Training for my previous airline, it became even more useful. For some reason as a line trainer, I seemed to attract runway changes (more related to the nature of the multi sector flying than a personal vendetta by ATC, I hope …) and whether Cisco or Pancho (or Diablo) on the flight deck – I would pull it out and use it after making the change. My little checklist made it onto many other pilot’s clipboards as a result, and if you line trained with me in those days, there was always a lively discussion in cruise about runway changes.

As an aside – I have never been a fan of preparing more than one runway for departure. I would often see command training candidates, seeking to be prepared for any contingency on departure, who’d would prepare for multiple possible runways on departure. This would include the use of Route Two and preparing takeoff performance data for the possible runway change(s). Usually only two were involved – the planned runway and the most likely change. I see that practice regularly now with Abu Dhabi and occasionally Los Angeles and Sydney.

I remember on one memorable Singapore departure, where my budding Captain under training had 8 distinct sets of takeoff calculations going – two runways, variable winds, and it looked like rain … When he was considering two runways it looked simple enough but having started down that road …

In that particular instance we had one runway in the FMC, a different heading set on the MCP, and we’d briefed on the third possibility, with speeds and takeoff performance entered for a fourth (it’s amazing what you can achieve on a distracted flight deck during pre-flight) before I called a halt to the exercise and we started again. Some days you were just never meant to push back on time.

My advice – and that’s ALL it is, this is NOT policy – is prepare for just one runway. Set everything up for just one runway. By all means think about the possibilities – for example, if a runway change is possible, knowing whether you’ll be performance limited on that runway is a good thing – but keep your aircraft and your mind on one runway until that option is gone. Then start again with the new runway. I would also point out that while you can pre-calculate take off performance and write it down, when the change comes you should be sticking to procedures and pulling out the laptop for both calculation, cross check and data entry. So why confuse things? Nothing like having three sets of numbers written on the flight plan to incorrectly choose from when you’re checking data entry during pre-flight …

When I arrived at my present company I was fortunate to inherit the responsibility of establishing the aircraft SOPs. While I stuck as close to Boeing as I was comfortable with (accompanied by input from an extensive review of several other international 777 operator’s SOPs) I made sure that my little runway change procedure (above) was inserted into the Normal Procedures for the 777. During the few runway changes I’ve had, I’ve used the checklist. From discussion over the last few weeks, many other pilots have as well, contrasted with some of our pilots who have never seen it. Personally I now find with so little flying, it’s become indispensable, although clearly, I’m biased.

Owing to recent events, we are re-evaluating that checklist and moving it to a more accessible location on the flight deck (well, more accessible for others, it will stay in my clipboard for me). As part of that re-evaluation I reviewed updated documentation for several airlines and found that Delta and United both have similar a procedure. Focussed primarily on the FMC and impacted by their own specific type of performance limits – our new one certainly incorporates anything I’ve found in other airlines. The version below is a draft only and subject to approval, but hopefully we’ll see it soon in print. Certainly it’s availability in a more accessible form will highlight it’s existence to crew who are subject to runway changes in future.

Implementation

What is yet to be determined is how it will be used. Going on my own practice, I typically work as a crew to implement the change and cross check the work done by the other pilot – then just as everyone agrees all is done, I drag out the checklist and verbally review the items, getting assent from the other crew at each item before continuing down the list – effectively, a done list. In fact when you review the documentation below, it’s something of a hybrid between a procedure; procedural guidance – and a checklist.

Thinking about it – I would prefer crew continue action runway changes as they always have – by relying on experience and the recent familiarity they have with the pre-flight process that’s brought them to this point. Chances are crew will do the best job of thinking of all the items they should – the checklist should be used as a follow up to catch the items that might otherwise cause a safety issue.

Runway Change on Departure

A crew make dozens of entries, selections and decisions during pre-flight that are tied to a specific runway and the departure direction associated. In addition a complex mental model which includes terrain, weather and procedural implications is established by briefing and other thought developing processes. All of these are typically accomplished through practiced, familiar processes that happen in sequence and are the result of learned, practiced behaviours.

Hence a runway change – especially once the aircraft has begun to taxi – is a significant disruption to many aspects of safe flight. Dozens of changes are often required to ready the aircraft for flight, including changes to the aircraft setup:

Airways Clearance and ATIS

Take off performance calculation

Aircraft Configuration (Flaps, Thrust)

FMC (Runway, SID, Takeoff Performance)

MCP (Modes, Heading, Altitude)

Engine Out Procedure (Fix page, FMC EOAA)

Departure Briefing

While most of these changes are mechanical in nature and can be the result of a checklist – such as the Runway Change Procedure shown here – more complex is the development of a pilot’s mental model of the taxi, takeoff and flight departure. This can generally only be achieved – particularly across the flight deck – by repeating/updating the Departure Briefing once the changes have been determined, evaluated and implemented in the flight deck.

Often the first indication of a previously unknown runway change is the direction of pushback in the push/start clearance. In this case the most appropriate response is usually to cancel push/start, remain on stand and action the change. While this can result in an OTP departure delay, it results in a better change action with less time pressure on the crew to accomplish what needs to be done.

Once the aircraft has begun to move, the recommended response to a runway change is to find an appropriate place for the aircraft to stop so all crew can be involved in the procedure. While relief crew can perform some useful preparation for a runway change during taxi, PF and PM should be fully engaged in ensuring safe taxi of the aircraft, rather than actioning a runway change procedure while the aircraft is moving.

The Final FMC Performance Entry procedure must be actioned in full no matter how small the changes involved in takeoff performance – from ZFW verification through to MCP and VNAV Climb Page Altitude/Fuel Checks. Once the Departure Briefing is updated the Takeoff Review and Before Takeoff Checklist must be completed (or repeated if necessary).

Currently I’m evaluating research on the roles of the Captain vs the First Officer in the detection and correction of procedural errors on the flight deck. Fortunately I’m not looking at our entire operation, just one small corner of it.

First, some background.

Delaying Final FMC Performance Data Entry

Our SOP’s are pretty much based on Boeing’s for the 777. Initially the FMC is (almost) completely programmed by the First Officer while the Captain does the walk around outside during the pre-flight phase. I say almost, because the crucial takeoff performance figures are left out deliberately at this stage.

The Captain will verify the FMC entries made by the First Officer against the flight plan and other sources once back on the flight deck. Once again critical Aircraft Weight, Take off Thrust / Configuration / Speed and other take off related performance information is left blank.

There are good reasons behind delayed entry of this data. The first is the changing nature of this information during pre-flight – between initial data entry and pushing back for departure a number of the variables upon which performance information is based can and does change. Aircraft weight, departure runway, airport weather, configuration – and several more – are all subject to change. If the FMC were completed initially, each change on one of the variables would require an update to the FMC.

There is also the likelihood that a single change in a variable can produce several settings changes in the FMC. All this multiplies and complicates the process of achieving accurate, cross checked performance information into the FMC.

Thus we wait until we have the final weight of the aircraft known and updated airfield weather data available. Then if necessary a re-calculation of takeoff performance data is done and the final figures entered into the FMC shortly before pushback.

The cross check for the initial FMC setup is one pilot entering information into the FMC; later on a second pilot independently verifies the data entered.

Final FMC Performance Data Entry

Once the load sheet is received and a final run of laptop calculated take off performance is done – the Final FMC Performance Entry Procedure results in (hopefully) the accurate entry and cross check of the required data. The importance of the accurate calculation and entry of this information cannot be over emphasised.

While the procedure certainly looks complicated (as shown here on the right), a lot of the complexity here comes from the detailed scripting of who does what in terms of the source of the information and who has it; the entry of information and who does it; and the cross checking. In practice it’s a lot easier than it reads.

This procedure is learned and practised on the ground using a computer training aid and then a flight simulator until it becomes fluid from recall. A competent crew with procedural repoire aren’t at all challenged by the correct completion of this procedure – omissions and errors stand out clearly to an observer familiar with the flow it.

That said …

Reading through the procedure the roles of the two pilots involved are clear.

– First Officer has the take off performance data (laptop) and provides the figure to the CA.
– Captain has the Load Sheet (aircraft weight and center of gravity) and enters the numbers provided by the First Officer.
– First Officer cross checks that the numbers provided to and verbalised by the Captain are actually entered correctly into the FMC.

This is where the current issue comes in … Who should be doing What?

The cross check here is two pilots working together using a tightly defined, scripted procedure to enter data across several pages of the FMC. Omissions by one pilot should be picked up by the other. Though it ties up both pilots at once and is subject to an elevated risk due any interruptions; this procedure is considered industry best practice.

Who Flies?

There has been a number of research projects, based on data collected from airline flight operations, examining the rates of error production – and more importantly the rate of error detection – when comparing a procedure done by the Captain and monitored by the First Officer, versus reversed roles. Our procedures (above) are clearly designed based on the Captain – being the more experienced and therefore more likely to correctly action a procedure – as the protagonist in our script physically entering the data.

However there is data now (actually it’s been around for a while) to suggest that while an increased error rate may occur if the junior less experienced crew member is performing a procedure, the error capture rate (as enforced by the Captain) is significantly higher, achieving an overall better result.

As such, the procedure I was taught and have been using for 15 years; the procedure we’re now passing on, would seem to be ass-about. The First Officer should be entering critical performance data while the Captain provides, monitors/cross checks.

The impetus of this report was the Emirates A340 Tail Strike incident in Melbourne, March 2009 – an investigation which interestingly is still ongoing. While prompted by this incident, AR2009/52 doesn’t dwell on the Emirates event in Melbourne, instead selectively reviewing related incidents from Australia and Overseas.

For the most part our procedures are highly compliant with the observations and recommendations of this report. That said, I did see 9 ways in which we could improve safety with respect to our operation – inside and outside the flight deck – and provided the summary to Flight Operations Management.

In particular, this table from AR2009/052 caught my eye. It took a while, but I was able to track down one of the authors, Dr Matthew Thomas and obtain his report and some additional data. I’m still working through this in detail at the moment as I formulate a report for our Standards Committee to look at altering our procedure.

Behind the data and the statistics is essentially the axiom that while a First Officer may make more mistakes (statistically) than a Captain; a Captain is much better at detecting – and correcting – the mistakes of the other pilot that a First Officer is.

From my personal perspective, I’ve been training and checking pilots here since pretty much the first pilot arrived 8 months before our first aircraft did. During training and occasionally during checking, this specific procedure has at times not been without error and as such the cause of a number of debriefing discussions. In essence I’ve been watching Captains making mistakes in the data entry/checking of this procedure on and off for two years now – albeit usually minor, low/no direct impact mistakes.

During the subsequent debrief discussion, the procedural error would be clarified – but also discussed was the lack of cross check from the First Officer. Only rarely do I encounter a lack of procedural knowledge on the part of the FO – just a hesitancy to correct the Captain over what was perceived as a relatively minor procedural error – particularly in the check/training environment. This is classic flight deck authority gradient stuff.

Captain/First Officer Authority Gradient

If you think about it – both our Captain and First Officer are trained (at least in terms of the aircraft/operation itself) to a pretty similar standard; in our airline both hold a command aircraft type endorsement/command instrument rating on the aircraft; both are trained initially and recurrently according to the same lesson content. From the training point of view, there’s no reason to expect that our First Officers make more mistakes than our Captains. Add on top of this the fact that as a new start airline – most of our First Officers came to this airline with significant experience levels; the competency gradient between the Left and Right hand seat is pretty flat at times.

Cockpit Authority Gradient

In addition to the style adopted by the Captain, the interaction between the flight-deck members will define the authority gradient between the two. A steep gradient results in ineffective monitoring from the co-pilot, and a flat one reduces the Captains’ authority by constant (unnecessary) challenge. The optimum gradient, which may differ between individuals and national cultures, encourages an open atmosphere to monitor and challenge, while respecting the Captain’s legal authority. Most airlines encourage a flat cockpit authority gradient, since there are a number of nationalities, levels of experience and different cultural backgrounds in the pilot group. Nevertheless the duties and responsibilities of the pilot-in-command should in no way be affected by a shallow authority gradient.

Based on this fairly equivalent capability (at least in terms of aircraft knowledge and procedural familiarity) one would think that the CRM concept of Authority Gradient would be pretty flat in our airline as well. But in terms of this procedure – it would appear this is not the case.

That’s the beauty of reversing the procedure so that the First Officer enters the data and the Captain cross checks – challenges – the accuracy : Authority Gradient works for the final result. The solution would seem simple – reverse the procedure so that the First Officer enters the data and the Captain monitors and cross checks. Simple enough.

Risk Analysis and Change Management

Any proposed change to SOPs undergoes a review of a fleet management committee to evaluate the need for and impact of the change. A change like this however is going to be something else again. I all likelihood we’ll involve personnel from the Flight Safety Department to evaluate the risks and benefits of the procedural change. Assuming the benefits are considered worth the risks, then the risks need to be managed – including managing the risks of the change process itself.

The concept of the First Officer flying with the Captain monitoring as a safety paradigm is not new. While it’s application to an operation as a whole is unlikely to find favour – I’m hoping it’s application to this little corner of our SOPs will improve the safety of our operation.

There is (what can only be described as) a software bug in the Thrust Reference setting software in the 777. While this bug manifests itself in several situation on normal and non-normal operations, it manifests significantly with flight safety implications during VNAV engine out approaches.

I discovered this issue back in the late 90’s when I was working in the Sim. I kept noticing it and writing it up for the Sim Engineers to fix. They would report back that they’d fixed it (or couldn’t understand what was wrong); another instructor would review the fix and miss-understand what the original report was about, and clear the fault. Then later I’d see it again, and report it – and round and round we went.

Eventually the Sim Engineers hunted me down and got me to show them exactly what the problem was – which I did. We all referred to the FCOM, agreed that it was not working, but then one of the S/Eng asked me “What does the Aircraft do?”. Hum. I said – so I went and checked. Lo and Behold – the Sim wasn’t the problem, the aircraft was. Oops.

I brought this to the attention of several levels of Training/Technical management, without much interest, so I circulated an e-mail amongst instructors and ensure my students were aware of it.

In early 2000’s – A friend of mine at Cathay approached me about it (someone sent him the email) and they chased it down with CAE/Boeing as well (to no avail as far as I can work out – the anomaly is still there). Then about 3 years ago a pilot upgrading to Command at Ek was commencing an engine out NPA into a high altitude airport in Africa – and managed to stall the aircraft because of this (actually I would suggest there was some SA involved as well). This kicked of another flurry of investigation – including approaching me for details (which amused me greatly since I’d left the airline and come to V). But again – nothing much seems to have come from that – because the anomaly is still there …

Boeing’s airplane design is such that GA (Go Around) is set as the thrust limit (displayed above the N1 indication) any time the flaps are extended (FCOM 04.20.16 refers) or the glide slope is captured. One assumes that Boeing’s intent was that GA should remain the thrust limit to either Landing or the Go-Around in order to provide maximum available thrust for manoeuvring while configured for landing.

However when VNAV is engaged after flaps have been extended, the Thrust Limit is reset to CRZ. Irrespective of the demands of the situation (Weight, Density Altitude, Configuration, Selected Airspeed, etc) – by design the auto throttle cannot command more than this selected Thrust Limit – CRZ.

In most normal ops situations this reduced thrust limit is adequate to preserve airspeed irrespective of configuration (Engine Out, Gear, Flap) – particularly in the 777-300ER. But 777’s with less thrust such as the -300/-200, or in performance limiting situations such as weight in excess of MALW, high density altitudes, etc – insufficient thrust can exist to maintain airspeed/altitude.

Prior to a low speed excursion, stick shaker activation and AP stall protection, the problem can be corrected by :

Selecting GA through the FMC Thrust Lim page;

Pressing the CLB/CON switch (only CON* thrust limit will be selected, not GA);

* While CON thrust should be enough to maintain speed at maximum landing weight, higher weights may require even more thrust.

Scenario Description

Assume a 777 at maximum landing weight, approaching the final approach fix (FAF) at platform altitude for an Engine Out NPA. The crew intend to use VNAV for the approach, but have manoeuvred to the initial approach altitude using Basic Modes (FLCH / VS). Configured correctly at Flap 5/Flap 5 Speed, thrust reference will most likely be GA, set automatically when the Flaps were extended.

At 3 nm from the FAF, Gear Down/Flaps 20/Flap 20 speed is selected. Thrust levers retard to slow the aircraft to Flaps 20 speed. Meanwhile the PF will set the minima in the altitude select window on the MCP, check track, engage VNAV PATH and speed intervene.

However with the selection of VNAV, CRZ thrust reference is set – unnoticed by the crew. As the aircraft approaches Flap 20 speed, thrust levers advance in anticipation to achieve speed stability (giving the PF the tactile feedback expected of thrust maintaining speed), but thrust is now limited by CRZ thrust. On a Bad Day, Engine Out with the combination of near maximum landing weight and/or high density altitude, CRZ thrust is insufficient to maintain speed, but often enough to preclude a negative speed trend indication. Speed will now continue to reduce until (a) descent for the approach commences, (b) an increase thrust limit is set; or (c) stick shaker/stall protection.

Speed Protection? At minimum manoeuvring speed, low speed protection would normally kick in (minimum AFDS speed or eventually auto throttle wakeup), but in this case this protective feature is limited by the CRZ thrust limit setting. The only low speed protection (through the autopilot) that will function is stall protection – as the aircraft approaches stick shaker speed, it will pitch forward and descend with failed FMA AFDS mode indications.

Prior to a low speed excursion and stick shaker activation, the problem can be corrected by selecting GA through the FMC Thrust Lim page or pressing the CLB/CON switch (CON thrust limit only will be selected) – or simply pushing the thrust levers forward – whether disconnecting the A/THR first or not. CON thrust should be enough to maintain speed at maximum landing weight. Higher weights may require more thrust.

Additionally …

On all approaches (after flap selection), FLCH may set CLB/CON, but glide slope intercept will reset to TO/GA.

Managing a departure with a performance limited takeoff weight can be one of the more challenging tasks that face an Airline Captain today. It all sounds simple enough in theory. Based on the Airport/Runway, Ambient Weather Conditions and Aircraft, a computer will spit out – down to the kilogram – how much weight you’re allowed to lift off the runway. From this number a passenger/cargo and fuel load is determined – and off you go. But all is not as it seems.

– – – – – – – –

Having been caught in the past, on the back of my clipboard is a little cheat sheet for the airfields we operate to, which gives me either

– the maximum weight I can expect to lift off an airport/runway in standard conditions (generally shorter runways); or
– the temperature above which I can expect to have to reduce below maximum certified takeoff weight (351,534 Kg in the 777-300ER).

This is certainly not an operational document – indeed it’s always out of date because I only update it infrequently – but it gives me an approximate idea long before I get to the plane as to what sort of limits I might encounter on the departure. A heads up, so to speak. And with temperatures in Abu Dhabi (OMAA) reaching into the 40’s – you can see where the problems begin.

Interestingly, in my previous airline, I rarely encountered performance limited takeoff’s – which could be considered a regular event at our home airfield of Dubai. The most common place for me personally was actually Melbourne (YMML/MEL) when a heavy departure combined with a light breeze from the north would leave you with the poor man’s choice of a departure to the north into the wind over the climbing terrain – or a departure to the south over nice flat suburbs leading to the bay – with a tailwind.

Combine temperatures above 30 degrees with 10 knots from the north and with the fickleness of the wind, the optimum solution would flick back and forth between the two opposite runways. When the wind from the north was feeble enough (typically less than 10 knots) to embolden you for a tailwind departure to the south, often you’d sit at the holding point for 45 minutes waiting for a space in the traffic pattern before you could go – all but negating the advantage of the southerly departure. But I digress.

Briefing

Our little saga begins in Abu Dhabi (OMAA/AUH) on our fourth and last day in the UAE, at 9am. We have arrived early at Etihad briefing where we were usually provided with the flight plan and other documentation on arrival. We were a little early but even so the flight plan was already 30 minutes late with no indication as to when it would arrive. Several fruitless phone calls later I implemented the Paul McCartney solution to airline problem solving – I just Let It Be.

The plan eventually arrived and we noted that we were (unsurprisingly) performance limited for Takeoff. Instead of our certified 351.535 Tons – today’s takeoff was planned at 342.036 Tons, which included 122.5 tons of fuel – the minimum required to get the aircraft safety from Abu Dhabi back to Sydney.

Operations had thoughtfully provided the basis of their calculation:

Runway 13L; Temp 40; Wind Calm

I looked into my Android phone and found the current temp at OMAA airport was 36 degrees, and a ten knot headwind was blowing down the active runway. A departure 90 minutes from now at 40 degrees seemed conservative enough – we reviewed the documentation, briefed the crew and headed for the aircraft.

Apart from our departure threat – there were two jet streams to contend with – one a headwind that we were to cross just after entering the Sea of Oman; the second we would follow like a ski run across the Southern Indian Ocean and right across Australia. This 160 knot (300 kph) tailwind was responsible for our shorter flight time (12:30 hours) but could well bring some moderate or worse turbulence. Finally Sydney was forecasting passing showers with a cloud base as low as 800 ft. Nothing un-toward but since our dispatch was to be with minimum fuel, I was already considering way to increase our fuel load – nothing gives you more options like additional fuel.

At the Aircraft

V’s first flight to AUH was full of celebration and hoopla. Ours, not quite so much …

We arrived at the aircraft at about 60 minutes before departure. Traditionally I offer the Flight Management Computer setup to one of the Relief First Officers, but I realised time was going to be tight (how little I knew at that point) and we stuck to standard SOPs.

Gareth and I did our setup, Ben headed out into the sauna for the aircraft walk around, and Tian completed safety and security checks for us, as well as kick starting the laptops, pulling out the charts, preparing the flight docs and the dozen or so other jobs that our unsung relief crew perform on every flight to assist the primary crew in getting the plane moving.

Fairly soon after arriving on the flight deck, we were approached by the Dispatcher Misha – who wanted an increase in takeoff weight.

The weight dictated by Ops required her to offload an entire pallet of approximately 4 tons for a 900 kg overload. There’s generally no time to split pallets this close to departure so unless you can get the whole thing on, the whole thing has to come off. I told her it might be possible, but we’d not be able to confirm for 15 minutes or so.

With the takeoff on our minds and Misha’s request in our ears, we reviewed the latest ATIS and asked for current temp/wind from the Control Tower. Often the ATIS can be a little old and the Tower often has useful gen on the history and future of winds and temps – they see the same thing day after day after all, particularly somewhere highly predictable like Abu Dhabi. In this case – both of the latter two suppositions were incorrect. The ATIS was accurate and the Tower not particularly helpful.

The temperature was now 37 degrees and the wind 10 knots down the runway. We were approaching 40 minutes to departure and passenger boarding well underway. Gareth and I pooled our 20 years of Middle East experience and decided to plan on a temperature of 40 degrees and 5 knots of headwind, which felt conservative enough. This gave us an additional 3 tons to play with. Pushback time was 10:55 local and despite a long taxi to the far runway (closest runway closed) – we were confident it would be ok. We gave Misha her additional ton and ourselves an extra ton of fuel, leaving us a margin of a final ton under our hopefully conservative takeoff performance calculations. We then continued on with our preparations.

Final Zero Fuel Weight

As all airline pilots know – this is make or break it time. Load control (in our case, Misha the dispatcher) provide you with the final weight of the aircraft and based on this you determine your fuel load. Misha had increased the aircraft weight by 1.1 tons (cheeky) to which we added our extra ton of fuel – plus the 500 kg’s of fuel required to carry Misha’s extra ton. We checked the ATIS weather again – still 37 degrees and 1o knots of headwind – and Gareth and I separately calculated Zero Fuel Weight, Takeoff Weight, Landing Weight and Fuel At Destination – and then compared them to each other and the structural/performance limitations to ensure calculation accuracy and practical legality. Then we gave the relevant figures to Misha, advised the refueller of our final fuel requirement, and rolled on into the straight run towards pushback and departure. Pretty quickly the refueller completed our final fuel and disconnected the refuelling truck. We were almost ready to go.

This is when things started to wrong.

Typically up to this point you have refuelled to 3 tons below the fuel you’re expecting to need. That way if the final weight comes in under what’s expected – there’s often a variance like this – you can reduce your final fuel order and not carry extra fuel un-necessarily. Changes in weight have a significant impact on long haul flights – for our flight a decreased of the aircraft weight of 1000Kg reduces the requireed fuel by 450Kg. Given the price of fuel and the economics of operating an airline today – not carrying extraneous fuel is a significant impact on the economics of the operation when taken across all the flights operated by the airline.

Wind and Temperature

Over the next thirty minutes we watched as the wind dropped off to 5 knots with a variable direction such that we could not count on any head wind at all. The temperature meanwhile climbed from 37 degrees to 38, 39, 40 – and 41. In these conditions, every degree of temperature rise reduces the performance limited takeoff weight by anything from 1500-3000Kg. Each knot of wind loss reduces takeoff performance by approximately a 200 kg change. Ask me how I know this.

By the time the cargo and passengers were fully loaded, the paperwork ready to go and all but the last passenger and cargo door closed – we were now 8 tons overweight for takeoff. We reviewed our calculations, looked at alternate runways, did some what-if’s with the wind. We were already planning to run the air-conditioning off the auxiliary power unit (APU) to maximise thrust from the engines – there was literally nothing further we could do.

I found Misha and discussed the situation with her. We decided to commence offload of our freight. There were issues here – some of the freight was high priority, there were going to be balance problems. We had about 10 staff on board the aircraft who could also be offloaded. Thus the offload would be in three stages – Freight, High Priority Freight, Staff & Staff Bags (the last two not necessarily in that order).

While this kept Misha busy – Gareth, Ben, Tian and I now had to determine what conditions we were going to use for departure – and therefore what limiting weight was going to be imposed on the cargo load. As we struggled with our crystal ball each time we picked a scenario that seemed conservative, we were looking at offload a portion of our revenue passenger’s bags – and perhaps some of the passengers – to deal with the situation.

At one point Gareth looks at me and says “I’ll ask the tower what the maximum temperature will be today.” Right.

Despite the dizzying force of my subsequent withering gaze of disdain, eternal optimist that he is he jumped on the radio and asked Ground Control what the maximum temperature was going to be. “Forty Two Degrees, Insha’Allah, Captain.“, was the answer. It’s 41 outside at this point, and about 12pm local time.

Gareth looked at me encouragingly – 42 we can cope with.

I passed my hand across the flight deck through space and time and intoned the words “It will not go above 42 degrees.” After a lack of reaction from Gareth, I followed up with “The force gives power over weak minds, Luke.” Gareth’s turn for a withering gaze.

Let me finish off this little bit with a picture of OMAA Airport Temperatures for the day in question. That tall bar in the middle – that’s when we took off.

Too Much Fuel

I must point out here that our problem was not just the weight of the freight and passengers – but also the fuel. We had calculated a required fuel load based on Zero Fuel Weight ZFW (aircraft + load) of 219.6 Tons. We were now busy offloading cargo to achieve a ZFW of 209.1. Thus the fuel we required could similarly be dropped by about 6 tons – except that it was already on board the aircraft. If we got to the point where we’d offloaded the cargo and the anticipated conditions were such that we still could not take off – we would have to consider de-fuelling.

While the word “defuelling” seems a simple alteration of the more familiar “refuelling” the actual process is far from similar. Depending on AirlineSOPs, local conditions and the availability of equipment, de-fuelling can have the following characteristics:

– All passengers disembarked prior to de-fuelling commencement until completion;
– Separate truck specifically reserved for defuelling purposes (if available);
– Typically the truck does not have the facility to pump fuel off – the aircraft needs to do the pumping and generally manages about 125 kg / minute.
– The fuel cannot usually be used by another airline and must be kept for your airline the next time you refuel.
– Local variations apply.

To say the re-fueller/engineer was disenchanted with the concept of de-fuelling our aircraft was an understatement. He seemed a fairly taciturn individual right up to that point where I asked him about de-fuelling. From that point on he just kept smiling at me.

There are two ways to defuel. The first is into a truck. The second is to start the engines, taxi out and stop somewhere, burning fuel until you’re down to the required weight. During a taxi the engines burn fuel at about 2 tons per hour. If necessary you can increase thrust a little while holding the brakes and perhaps double that flow rate. Neither of these are great options – best choice is not to let yourself get trapped into the situation in the first place …

The Passengers

We hadn’t forgotten our passengers through all this. During the delay I made two Passenger Address’s explaining situation and updating as we went along; the crew and the entertainment system kept the passengers busy and satisfied as best could be achieved; at one point as we waited with nothing to do I walked through the cabin talking to passengers answering questions. There were issues with connections and certainly some disgruntled passengers but all told our Cabin Crew worked really hard on service recovery. I stood near the door after the end of the flight and for the most part got smiles from our glad to be in Sydney passengers.

The Staff Travel Passengers

In a situation like this, the aircraft loadsheet marks some the passengers as PAD – Passengers Available for Disembarkation. Essentially this is the staff of the airline, their families and friends who can be offloaded in order to preserve the dispatch of the flight, the existence of revenue passengers onboard, and various other reasons. Misha calculated out staff pax at 700kg on our flight including their bags. I knew that a decision time was coming and we discussed a possible offload of them. This would require finding those passengers – and their baggage strewn throughout the loading pallets in the hold. I decided that the time it would take to accomplish this was no more that the time it would take to burn off the equivalent fuel, and kept the staff on board. I was fully cognizant that I might come to regret that decision …

As an aside, I also considered offloading some water. The aircraft carries about 1.5 tons of potable water. Typically on a long full flight there’s almost a ton left. I’ve used this technique in the past to carry an additional passenger or two when we’ve had empty seats but we’ve been performance limited. Again in this case – it seemed more practical and less risk to burn the fuel on taxi. I may never be allowed to vote Green again.

Decision Time

As the cargo had come off – including some re-arranging of passenger baggage from the Aft to Forward hold for balance purposes – the temperature was increasing still. The wind was still reported as 5 knots variable, but also “Becoming” a 6 knot wind from the other direction. The sea breeze was kicking in, resulting in a Northerly that would force a change of runway (which didn’t help performance) but a potential increase in headwind component. We were now 90 minutes passed our scheduled departure time – it was 12:30 and we were still not at the peak heat of the day. Misha had confused us several times with a varying range of Zero Fuel Weights depending on what was offloaded and what was kept. I couldn’t blame her – we had flight plans and takeoff calculations flying around the flight deck like no man’s business.

Misha confirmed that at ZFW 209.1 we had all pax (staff and revenue) and their bags on board. No freight – including the high priority freight. Based on the amount of fuel still on board we were now – and depending on which set of imaginary numbers representing the temperature and wind we’d see at the runway – at least 1500 kg overweight still.

I decided we’d push back and taxi out. If the wind had not picked up producing a headwind, we would wait somewhere and burn off the ton of fuel. If the temperature increased, we would need to burn more.

Push Back

Of course nothing is that simple. Now that we were no longer a flight in quandry, but a flight trying to push back – the real world intrudes on our flight once again. There was a now disparity in the passenger numbers to sort out, paperwork to finish, a loadsheet to chase from Ops, a NOTOC to revise (no hazardous cargo onboard anymore), passengers to update (who for some reason would not take their seats) – and after two hours of a quiet, Abu Dhabi airport decides this was the time to ramp up activity. We sat on stand, fully ready to go for an additional 15 minutes waiting for push back.

Because of a runway closure – it was a long taxi out to our departure runway. As we finally pushed back and started engines, I could hear Ben behind me checking the ATIS airport weather. I snuck a glance back – Not good. No wind and the temperature was now 43 degrees. If it went to 44 without a wind shift we’d be parked by the runway for at least an hour, burning through fuel.

Another consideration was the APU to Pack takeoff. The procedure was designed to be enacted prior to pushback and once engines were started, one airconditioning pack would shut down and the other would run off the APU until after takeoff. Single Pack combined with our long taxi would result in a very warm cabin. Thus we would have to disable the APU to pack for a while and the re-engage it approaching the runway, re-entering our takeoff performance calculations as as we did so. Less than ideal.

But not such an obstacle really, since we were taxi-ing out with no clear idea of which runway we would depart from, what the temperature and wind would be, and how long it would be before we could go. Everything would need to be done at the holding point in the end. Hopes and dreams were all we had really.

Saved by the Wind

Approaching the intersection at which we would have to choose a runway – we contacted Tower for an update on winds and temps.

“Temperature? 43 Degrees Captain. Wind? 300/6, Runway 31R in use.”

The wind had now swung to favour the other runway. We’d checked figures for RW31R but it hadn’t helped quite enough. However the combination of runway and headwind was helping. We turned right and continued along the inner taxiway – leaving the outer for aircraft that actually could takeoff.

Once halted clear of the runway, we made the necessary aircraft and flight management computer changes for the new runway, updated the departure briefing, and asked again about the wind.

“Wind is 310/8 Captain. Temperature 43 degrees.”

Success – we calculated the figures and our limiting takeoff weight exactly matched our current aircraft weight. We expedited onto the runway and took off for Sydney.

Postscript

With all the additional fuel on board, we contact Ops and gained approval to increase speed and burn some of it – we had literally dozens and dozens of passengers with connections to all over Australia. We kept an eye on the weather in Sydney (which was a waste of time because it only degenerated to Rain Showers and a 600 ft cloud base once we’d commenced descent) and tore through time and space at Mach .855 most of the way (I’ve done Mach 86-88 on the 7773ER – but that requires a LOT of fuel, which even we didn’t have).

Having shaved perhaps 40 minutes off the flight time, we then held for 35 minutes on the descent (round and round and round) and flew at minimum speed for the rest of the way to the runway.

Lessons Learnt

Gareth and I discussed this at length, and I’ve been thinking about it ever since. I’m still hesitant to accept at ETD-00:30 or even ETD-00:60 that it’s reasonable/practical to plan on a 5 or more degree temperature rise over the next 30/60 minutes. Each degree of temperature you’re conservative on (read wrong about) means 1 or 2 tons of revenue cargo not carried. By the nature of the situation, you have to be conservative – else you end up in the situation we found ourselves.

Certainly the next time (Monday 22nd August – anyone want to change their travel plans now?) I’ll be far more reticent to accept a load anywhere near what we calculate to be the current or likely limit at takeoff. However, temporary gun-shyness does not an operational plan make. I know the situation is being reviewed by Flight Ops and I expect some kind of recommendation will be made shortly.

In summary:

It gets hot in Abu Dhabi in the Summer.

Between the hours of 11:00-13:00 you have to plan on a continually increasing temperature, perhaps even precipitously so.

Don’t count on the wind in these conditions.

Be proactive about cargo offload.

De-Fuelling is not an option to keep in your back pocket – it’s an absolute last resort that may not even be there when you go to use it. If you think you’re likely to need it – get it arranged early.

Sometimes you have to decide, sometimes you have to decide early, and operational efficiency and the profit margin need to take a second place to the requirement to get the job done.

The 777 has three fuel tanks (simplified version). A large Center Tank and two smaller main tanks (one in each wing). When refueling, the Mains are filled first, then fuel is pumped into the Center tank (simplified version) until either you have enough fuel, or it’s full. There are two center tank fuel pumps and their job is to … pump fuel out of the center tank to the engines. With me so far?

Note – as pointed out (below), in fact the 777 Refuelling System doesn’t wait for full mains before pumping fuel into the center. The point however is that for dispatch purposes – the mains are supposed to be full before you start accepting fuel in the center tank. A total fuel figure is programmed by the refuelling into the refuelling panel, and the software schedules fuel into all the tanks to maintain a CoG range, as well as expedite the refuelling process.

So far so good, except that as you get down to the bottom of the tank, the two Center Tank Fuel pumps can’t quite get at all the fuel. So they’re switched off with just over 1 ton of fuel to go. From this point the Main Tanks take over, each one feeding the onside engine, until you land. Or run out of fuel – but for the most part, land.

But what about the fuel left in the Center tank – typically about 1.3 tons?

That’s the job of the Center Tank Fuel Scavenge System. Once sufficient fuel has been used from the Mains (actually once LOTS of fuel has been used out of the Mains) the Scavenge system kicks in, pumping that 1.3 tons into the Main tanks where it’s used by the engines.

That’s simple enough. I might add that none of the scavenge system is visible on the flight deck, apart from the fact that the 1.3 tons left in the center tank once you turn the pumps off magically disappears later on in flight. At least, that’s what should happen.

And then the other day, we were cruising along and got …

Practices & Techniques : EICAS [] FUEL SCAVENGE SYS Checklist

Boeing have confirmed that intermittent failures of the Fuel Scavenge System are caused by the collection of ice in the scavenging system in flight. The result is the loss of the system and the associated FUEL SCAVENGE SYS alert message. All pretty straight forward. Of course the failure of the fuel scavenge system potentially results in the inability to access up to 1.3 tons of centre tank fuel, which may well impact on your ability to continue onto destination, but I digress.

The checklist begins by asking you :

Centre Tank Fuel Available – Yes / No?

The answer to this is patently clear to the Thinking Pilot (how many times have we told you not to do that …) – of course Centre Tank Fuel is unavailable – you can’t get it out of the centre tank without the Scavenge System – and it’s failed. So you click No and you’re on your merry way.

In fact the questions is asking you if :

Center Tank Fuel Indication is Available – Yes / No?

You can verify this by taking an overview of the checklist.

If you can tell how much (now unavailable) fuel is in the centre, the checklist directs you to add this value to the FMC Reserves, giving you an earlier indication of INSUFFICIENT FUEL and a smaller FMC HOLD AVAIL time when holding. That’s a sensible, conservative use of the available information.

If you can’t tell how much fuel was in the centre, the checklist assumes the worst and requires the crew to increase the Reserves figure by the most that could be contained in the center tank at this point – 1300 kgs.

It’s worth noting that our experience on the line is that the fuel often becomes available on descent as the ice melts.

Despite my attempt at humor (above), the thinking pilot walks a fine line between reacting and following a checklist – while maintaining the big picture of what the checklist is trying to achieve and why.

Often we are taught not to second guess a checklist – for example turning on hydraulic pumps to a system that has no fluid (“Just do it – don’t get creative.“) While this is one of those cases where being aware of the nature of the problem helps interpret correctly a poorly worded checklist question – the better pilot maintains the big picture of the nature of any problem and keeps in mind the how and why of what a NNM checklist is trying to achieve.

The Flaps are high lift, trailing edge devices designed to increase the lift on a wing that’s designed for high speed / high altitude flight, not this low speed lifting 350 tons off the ground manoeuvre that we insist on performing at the beginning of every flight.

Sometimes they fail and one of the possible failures is a FLAPS DRIVE message that leaves them stuck in the current position. When you run the Non Normal (NNM) checklist – the question is asked of the crew; what position are they in? This should be a simple question …

The last six months of phase training has included this failure and I’ve watched crew confronted with the same scenario deal with it in several different ways – with several different outcomes, I might add. Time to put pen to paper … so to speak.

Practices & Techniques : 6.10 FLAPS DRIVE – Where are the Flaps?

In the event of a FLAPS DRIVE failure, the checklist asks the crew to confirm the position of the Flaps. This sounds simple, but can be made complex by the situation … and the crew …

Flaps Drive is the response of the FSEU to either a failure of the flap extension system – or the detection of flap asymmetry. Typically the FSEU doesn’t act to prevent the commencement of an asymmetry – it acts to contain the increase of a detected asymmetric condition. Asymmetry can be caused by either:

Failure of the flaps to respond to a command to move; or

Failure of the flaps to respond to a command to stop moving.

When asked to look at the position of the Flaps, crew have several things they could consider:

Expanded EICAS Flap Position indicator;

Flap Lever position (combined with where the lever was before the failure occurred);

PFD Flap Speed Limit indication.

This last one bears a little discussion. The speed limit indication markings on the PFD (red square dots at the top of the speed tape) indicate the flap limit speed for the current flap position (not current flap selection). The sensors for the left and right indication limit speed detections take their inputs from different flaps; hence it’s possible during a Flaps Drive failure to have two different speed limit indications. This the PFD speed limit can be another indication of Flap position.

Question : Which indicated speed limit should you respect?

Answer : Both of them, of course.

Scenario : Takeoff at Flap 15, Failure occurs during retraction to Flap 5. Where are the Flaps?

A good look at the expanded Flap Indicator gives the information required. Magenta “5” indicates the commanded flap position by the flap lever is Flap 5 – the magenta colour indicates that the flaps are NOT at 5. If the flaps were detected at commanded position, the indication would be green. Amber indication reflects the existence of the current Flaps Drive failure. The Flaps aren’t going anywhere.

During takeoff, the Flap Lever was at 15, and now it’s at 5. Therefore the flaps are somewhere between 15 and 5. Unless … If the failure was uncommanded movement – that is, the flaps were retracted to 5 and one of the flaps failed to respond to the command to stop moving – where would that flap be now? Would this flap position at less than 5 be indicated on the expanded display? Hmmm.

Finally – in this particular scenario, one of the PFD speed limits reflects 245 knots – Flaps 5; the other reflects a higher speed – Flaps something less than 5.

Solution : The checklist doesn’t offer you Flap 5. It says “5 or less” and this is the correct response. Speed selected is based on Flaps Up and you’ll fly your approach with the excess speed associated with a midrange slats only extension.

The (probably) incorrect choice of “between 5 and 20” has you on approach assuming Flaps 5, which may be slightly slower than the minimum recommended speed – but it in all likelihood well within the margin of safety.

While most of the world seems to use Jeppesen, I’ve been exclusively using LIDO now (across two airlines) for perhaps 10 years. While it took some getting used to, I’ve come to much prefer them. As an information junkie, I like the amount of information that is hidden away in plain sight right in front of you, if only you look through the Legends and Tables (LAT) section for the decode of all the intricate colors and symbols.

But as with everything new – it’s a process of discovery and once again I’ve been taken by surprise by something that seems unique to LIDO. Being European, they’re based on JAR and one aspect that has come to light recently is the visibility requirement required to commence an non-precision approach. I’ve always operated on the assumption that if the reported visibility at the bottom of the approach meets the needs promulgated on the approach plate – I’d have a fair chance of landing off the approach. As it turns out – this is not the case for NPA based on JAR OPS compliant minimas. Almost without exception – if the visibility at the bottom of the approach matches the chart, you’ll not have the visibility to see either the approach lights, or (in their absence) the runway.

Interestingly the minima’s published in LIDO charts against Australia approaches (which are are still PANS OPS 4 based) reflect the higher visibility requirements, and in all cases you can see the lights/runway.

I’ve spent some weeks chasing this down through friends overseas in teaching organisations in the Uk. Without exception, they’re surprised by discrepancy and unable to explain it. At this point, I guess all that remains is to document it so that crew are aware that off the bottom of a JAR NPA – they may not have the visual reference to safely continue the approach to the runway.

The table below compares some of our Australia NPA’s against their JAR equivalents – the issues are obvious.

Practices & Techniques : 13.26 Visual Reference at the Minima (NPA)

The visibility required to commence a non-precision approach does not guarantee sufficient visual reference at the minima to continue to a landing. This is particularly the case for NPA’s based on JAR/TERPS.

Given that the crew will disconnect the AP and manoeuvre visually from the MDA to the runway, crew should ensure that adequate visual reference exists to do so at the MDA.

It’s not unusual – especially during Line Training (instructors beware) for your student to generate an EICAS MAIN GEAR STEERING alert during the initial takeoff run. This results from advancing thrust prior to the main articulated gear achieving a lock during the initial take-off roll.

Practices & Techniques : Main gear steering and Thrust Application

Main gear steering engages when the CM1 tiller is beyond approximately 13° and remains engaged until the CM1’s tiller has returned to approximately 9° – after this point main gear locking takes approximately 5 seconds. Anytime a thrust lever is advanced beyond 60% N1 with the main gear steering unlocked, a CONFIG GEAR STEERING Warning message is generated on EICAS. Note that rudder pedal steering alone generates up to 7° of steering and will not unlock main gear steering.

As crew become more confident with the aircraft, the occasional takeoff configuration warning is generated during thrust application on takeoff, when the main gear steering hasn’t been given sufficient time to align and lock. This is generally best avoided – don’t rush into TOGA when a sharp turn has been required during line up.

As Boeing’s first Fly-By-Wire aircraft (although not necessarily fly-by-wire by the Airbus definition) the 777 introduced a flight control augmentation system that the first fly by wire Airbus aircraft did not – Thrust Assymetry Compensation, or TAC.

The basic problem is clear. During an engine failure on a twin wing-mounted engine aircraft there is an assymetry between the left and right sides – that is, typically one of the engines is producing lots and lots of thrust; the other is producing none at all (and in fact may well be producing extra drag with windmilling fan blades, etc). A pilot therefore needs to counter the quite strong tendency of the aircraft to yaw towards the failed engine or else lose control of the aircraft altogether. Sufficient rudder pedal input on the flight deck is required to deflect the rudder on the tail to offset the asymmetry. A badly handled engine failure (apart from the obvious loss of control issue) can result in poor climb performance – or none at all. The loss of an engine in today’s big twins typically results in a loss of 50% of available thrust – and 80% of available performance.

Simple in concept – the TAC provides an input to the rudder (eventually) which assists the pilot in maintaining control of the aircraft. This lowers workload on the pilot and aids in maximising the performance of the critical after takeoff engine climb out phase. What could be simpler?

Not the Rudder

The first thing that needs to be said, is that TAC typically does not provide a rudder input. In fact TAC drives the Rudder Trim control, which in turn drives the rudder pedals on the bottom of the pilot’s feet, which drives the rudder. This is a crucial distinction since it means that normally all TAC input to the flight controls is felt directly by the pilot through the aircraft’s controls. This is the major distinction between Airbus and Boeing in this regard.

How Does it Work?

Contrary to common belief – TAC does not detect the asymmetric yaw of the aircraft and counter it. TAC works strictly on engine parameters, calculating thrust produced by both engines in order to determine any disparity. Should that disparity increase beyond a certain threshold (nominally about 10% of max thrust) then TAC begins to feed in rudder trim. The larger the disparity, the larger the trim/rudder input. There is no inertial involvement in the TAC calculation – that is, the IRS doesn’t detect Yaw and provide this information to the TAC. Apart from the result of thrust calculations – TAC is also advised if the thrust computation is valid – but more on this later.

What about Takeoff?

You may have noticed the hole in this. Could you deal with the sudden loss of thrust during an engine failure on takeoff – with only the Rudder Trim? I think not, and neither can/does TAC.

In response to a sudden loss of thrust during takeoff, TAC commands a high rate rudder input direct to the flight control surfaces – this rudder deflection is not fed back through to the rudder pedals. At the same time the TAC commands a high rate rudder trim input (remember there are two rates of trim input on the 777 – half twist is half rate trim, full twist is full rate trim command) which moves the rudder pedals until the amount of rudder commanded by the rudder pedals (as felt by the pilot) is the same as is being commanded by the TAC direct to the rudders as a result of the thrust discrepancy.

As such it’s important for pilot’s to realise this when experiencing an engine failure on takeoff with the TAC working. Instinctively (I hope) all pilots will apply rudder to keep the aircraft straight on the runway during an engine failure – TAC or no TAC. At this time, they are operating in concert with the TAC, which is fine. However once airborne, pilots will need to make a conscious decision to assess whether the TAC is working, and release the rudder (slowly, just in case).

TAC Failure

Unfortunately TAC can and does fail – including during engine failures. In fact if a TAC is going to fail during any engine failure – it will be during the more destructive ones. As counter-intuitive as this may seem, there’s a reason for it.

Of course it fails all the time in the simulator and there’s a very good reason for that – so you can practice manual rudder control during engine failures!

Occasionally during catastrophic engine failures, there are short periods of time when the engine parameters feed into the on board computers are invalid. When this is sensed by the TAC – it fails. Since TAC feeds in rudder pressure based on calculated thrust difference – if it can’t calculate thrust on an engine, it can’t safely feed in rudder.

The good news is that once the Fuel Control Switch has been move to Cutoff (engine secure) – TAC can be cycled and will return. It knows now exactly how much thrust is coming from that damaged engine – None.

TAC fails for at least the following reasons:

Rudder Trim Failure

Loss of thrust data from 2 of 3 channels of the EDIU

Loss of Left AND Right Engine running data (you’ve got bigger problems!)

R/L1/V ACE’s failed/direct mode or the PFC not in Normal mode

TAC Switch OFF or Failed

Trimming on TAC

It’s a common error for crew to occasionally trim on top of TAC. This should clearly be avoided, but it’s not a train smash. Any time you find that you’ve trimmed on TAC – use the Trim Cancel Switch to remove all pilot inputs – this will not affect TAC operation. Don’t try and wind off the trim you think you wound on.

The rudder trim inputs by the Pilot and the TAC are not cumulative – it’s a case of who does most wins. If you trim more than the TAC would, your trim affects the aircraft. If you apply less trim than the TAC – TAC is trimming the aircraft. However in this latter case, as soon as thrust comes off the live engine, TAC will reduce trim input – but pilot trim input will remain.

How Much Trim?

It’s a common belief that TAC applies slightly inadequate trim in order to leave the pilot with some feeling as to the asymmetric nature of the flight, and there is some justification for this belief based on documentation in the FCOM and FCTM. However if you manually trim the aircraft yourself (No TAC) then you’re aiming for Control Wheel Neutral (no aileron deflection, assessed through the aileron trim indication on the control wheel), a slight angle of bank towards the live engine, and a small slip on the balance indicator. This is the aircraft in trim with minimum drag for efficient engine out flight.

If this sounds familiar – it’s how you’ve been trimming out twin engine aircraft since you did your first multi engine conversion in the dim dark past …

The funny thing is – if you leave TAC alone in steady state flight and let it do it’s job – this is the flight configuration it establishes. Believe what you will …

Summary

In summary – TAC usually works and works well. It doesn’t preclude the pilot from making inputs during engine failures – far from it, the design actually encourages the pilot to fly the aircraft and merely assists if the job isn’t quite being done well enough. Most pilots can fly quite well when the TAC fails and only realise later on that it happened that way. Perhaps the most common error is forgetting about the TAC and trimming on top – which is one reason why the Trim Cancel switch is there.

TAC Fun Facts

TAC is not functional on takeoff until after 70 Knots CAS

If the TAC is switched off – any trim applied by the TAC remains behind

If the TAC fails – any TAC trim applied is removed (Trim Centered)

TAC is limited to about 60% of available rudder

TAC is not active if any reverser is deployed

Thrust difference of about 6000lbs (10%) is required to engage TAC

TAC then remains engaged until about a 3% difference in calculated thrust

I was recently asked to confirm that 5 knots is added to the Vref Speed on final approach when an unusual Vref is specified by the Non Normal Checklist. I eventually found a reference …

– – – – – – – – – – – – – – – – – – – –

Practices & Techniques : NNM Vref & Speed Additives

During training crew often ask if 5 knots is added when using a Vref speed specified by a NNM checklist (such as Vref30 + 30) as is normal practice during NM operations.

The FCTM is clear on this – 5 knots is added, as are corrections for steady/gusting headwinds during manual thrust or 10 knots for manual landings with auto throttle engaged in high or gusting wind conditions.

The next phase of refresher training includes dispatch without the benefit of Electronic Checklist (ECL). This is going to such fun to watch …

– – – – – – – – – – – – – – – – – – – –

Practices & Techniques : Dispatch without ECL

When the ECL is failed or disabled …

EICAS does not display checklist icons [] beside alert messages.

Crew are required to use the paper checklist in the QRH for Normal and Non Normal checklists.

When the QRH inhibits a checklist (“Do not accomplish the following checklists:”) this needs to be noted down by the crew for the follow up EICAS Review.

When a QRH NNM references a Note (“Note: Use Flap 20 and …”) these need to be collected by the crew – either written down or ideally the page in the QRH marked for later reference.

Note that pressing the CHKL switch displays a CHECKLIST DISABLED message on the lower MFD.

In the event of a significant failure with multiple EICAS Alerts, crew will need to prioritise the messages using Warning/Caution/_Advisory status without the assistance of checklist icons [] on EICAS. For each message, the QRH will need to be consulted to see if there’s a NNM checklist associated with the alert, unless a previous checklist has advised “Do not accomplish …”.

The EFIS [CHKL] button -> CHECKLIST DISABLED feature can be used to reduce the chance of forgetting a Normal checklist. The PM should still press the [CHKL] button as part of the standard flows (see below), and the CHECKLIST DISABLED message then serves as a prompt for the need to accomplish a NM checklist. Similarly when a NNM checklist is held (eg: Fuel Jettison) the CHKL / CHECKLIST DISABLED can be used to remind the crew of an outstanding NNM.

After extended use with ECL, using a paper checklist requires set of CRM skills that may well be rusty in crew. Care needs to be taken to work methodically through NNM’s and care taken to ensure NM checklists are remembered and actioned.

Recently a crew in the sim elected to hold until the completion of the Fuel Imbalance checklist before commencing an Approach. Since fuel balancing can take quite some time, they were in for a long wait.

This is however a refreshing change from the more traditional approach of the crew who decide to ignore the fuel imbalance checklist because they’ve been told in the past that “Fuel Imbalance is not a Limitation – the 777 can land with ANY fuel imbalance“. Somewhere in the middle must be the correct technique …

– – – – – – – – – – – – – – – – – – – –

Practices & Techniques : Landing with a Fuel Imbalance

There is no restriction on commencing/continuing an Approach and Landing while balancing fuel with the Fuel Imbalance checklist in progress. Indeed this is to be expected when balancing fuel prior to approach. This is however one of the very few times when a NNM checklist is not completed prior to landing.

It’s worth noting that the AFM contains limitations on Fuel Imbalance dependant on total fuel quantity. These certificate limitations on takeoff and landing with a fuel imbalance are not required knowledge (and therefore not included in the FCOM) because Boeing have taken steps to ensure crew deal appropriately with a Fuel Imbalance limitation exceedence – by prompting the crew through EICAS for the Fuel Imbalance checklist. Thus crew who ignore the Fuel Imbalance checklist “It’s not a Leak”; “It’s not a limitation” are in fact not responding appropriately.

Of course the CM1 can always elect to delay initiation or halt completion of the Fuel Imbalance checklist when commencing the approach/landing (or something else) is the higher priority for flight safety. See SOP Guide EICAS/ECL “How NOT to do a Checklist” for a discussion of this issue and Fuel Imbalance specifically.

The choice of whether to continue flap retraction after a SLATS DRIVE failure is an interesting one. Crew need to carefully consider the requirement to retract in association with the weight of the aircraft, proximity of the minimum manoeuvring speed, etc.

– – – – – – – – – – – – – – – – – – – –

Background

The last phase included a departure from Abu Dhabi (AUH) at heavy weight, with a Slats Drive failure. For most of the six months of training, the crew looked at their situation (Slats failed half out, Flaps still at 5) and elected to retract the flap. As the minimum maneuver speed rapidly increased, but the Flap/Slat limit speed failed to move – crews found themselves stuck with AIRSPEED LOW and a flap limit speed exceedence – all at the same time. It was lovely to watch the reactions of the crew at this point, especially since …

Of course having taken action without thinking clearly about it, the next reaction was to re-extend the flap in order to return to better speed margins. After the flap lever moved, the limiting speed would come down until a minor flap limit speed exceedence became a major one, with the AFDS/Autothrottle refusing to allow a speed reduction until the flaps were fully out and the minimum maneuver speed reduced.

It would all be a lot funnier if I hadn’t done exactly the same thing the first time I was given this failure scenario …

– – – – – – – – – – – – – – – – – – – –

Practices & Techniques : 5.31 Slats Drive & Flap Retraction

When a SLATS DRIVE failure occurs during takeoff – particularly at heavy weight – crew need to carefully consider continued flap retraction as an increasing minimum manoeuvre/stick shaker can combine with the flap/slat limit speed to leave the crew with no room to manoeuvre. Either AIRSPEED LOW or Flap Limit speed exceedences are likely. In a clash, the AFDS will exceed the flap limit speed, rather than fly a speed below minimum manoeuvre speed.

The recent phase training combined Engine Failure with Flaps/Slats Drive/Control failures introduced the issue of entering a reference speed when to different checklist are specifying two different Vref settings. Another item for the P&T.

– – – – – – – – – – – – – – – – – – – –

Practices & Techniques : Multiple NNM’s and Flap/Vref settings

When dealing with multiple NNM’s, crew may be confronted by conflicting requirements with respect to selecting a landing flap and a Vref speed. A specific example would be an Engine Failure combined with a Slats Drive malfunction.

In all circumstances crew can nut out the correct Approach Flap / Vref Speed / Go Around Flap setting and estimate a landing distance appropriately through common sense and an understanding of the requirements driving Approach Flap, Approach Speed and Missed Approach Flap requirements.

In this example, Flaps 20 will be the landing flap. The conflict in Vref is settled by choosing the most conservative (highest) Vref speed (Vref 30+30). Since Vref 30+30 is greater than Vref 20, Flaps 5 to improve climb performance in the missed approach is available – and preferred.

Recently I had a philosophical discussion on board with a crew about the use of VNAV without LNAV engaged. I was surprised to discover that they were unaware of any of the potential pitfalls associated, so I add a section to the P&T.

I should say right now that I’m not actually happy with what I’ve written yet – it needs some series simplification, not unusual for anything I write the first time.If you read this and have thoughts on it – please comment below.

Practices & Techniques : VNAV without LNAV, without … VNAV

LNAV/VNAV work best when engaged together. Assuming a correctly programmed FMC, LNAV takes care of the lateral track, accounting for all sorts of turn constraints, flyby and flyover waypoints, calculating turning radii, all while providing accurate distance/speed data for the calculation of fuel, time and descent path. Meanwhile VNAV – when following the programmed LNAV track and assuming reasonably accurate wind data – will calculate the most efficient descent path and keep the aircraft to it. Speed/Altitude constraints At, Above, Below or a combination thereof are complied with irrespective of the MCP altitude setting – when a constraint can’t be met the crew (for the most part) are informed in a timely fashion. LNAV and VNAV work great in harmony together. And then there’s what happens when you split them up …

LNAV without VNAV

LNAV without VNAV is not a train smash. For the most part LNAV works fine on its own – however it’s been observed that crew sometimes forget their vertical profile is no longer being guarded by the LEGS page constraints – particularly when the engaged LNAV-FLCH climb/descent happens to comply with the calculated VNAV path. If the MCP altitude selector is not set correctly, and compliance with vertical constraints not monitored, altitude exceedences and off path deviations can result.

VNAV without LNAV

VNAV without LNAV seldom makes sense – particularly when the aircraft is in VNAV PATH. In this case the calculated descent path is being maintained (VNAV PTH) based on a projected lateral path that the aircraft is no longer following. Inevitably either more or less track miles are involved in the calculated descent and VNAV PTH makes less and less sense. In addition the aircraft may level off unexpectedly for altitude constraints on a flight leg that bears no resemblance to the actual lateral tracking of the aircraft. Updates and changes to the LEGS page can further corrupt the VNAV PTH calculation. It is highly unusual for VNAV PTH to be the correct vertical mode when not following the associated LNAV track.

VNAV SPD without LNAV is somewhat better in that at least the aircraft is usually descending in IDLE (or a fixed thrust setting) and the implication is that the PF is monitoring vertical path. Speed Control (and the option of additional thrust when the auto throttle is in HOLD) is at the behest of the PF – in this case one remaining trap here is that the VNAV PTH can re-engage by itself with (or without) LEGS page changes and now you’re in VNAV PTH without being on the LNAV track.

With pilots come from a number of other aircraft types and several different airlines, including a domestic fleet, standardisation can be a challenge. The use of Flaps on approach has been in particular an interesting issue, which is hopefully address clearly in the following article.

One of my first tasks when I arrived at V Australia in early June 2008 was to watch simulator transition training being conducted at our new simulator in Silverwater, Sydney.

The students were straight off the street pilots who had come from regional airlines – in most cases it was their first jet, their first “real” airline, and in some cases, their first multi-crew flight deck.

The instructors were Americans owned by Alteon – A Boeing training subsidiary – most of whom were very experienced ex-aviators from the halcyon days of US Aviation, but they were slowly being replaced by external recruits – most of the experienced ex-aviators from Australian airlines – who were seeing the 777 for the first time.

One of the aspects of the training that struck me most was the stark difference coming from an airline with a long standing embodiment of standard knowledge, standard practices and training standards – to a completely new organisation. I generated literally pages of notes from each of those sessions, the vast majority of those observations of shorfalls referred to items that I would have previously considered axiomatic, but I now came to realise simply weren’t.

I realised right away that this missing reservoir was going to be a huge gap in our training, and set about creating that knowledge. One of my bugbears in the past had been the nebulous nature of this knowledge, passed as it was from instructor to student and from instructor to instructor – but never written down. I realised that this was my chance to correct that. The early incarnations of this were the Common Errors document, which morphed into the Procedures and Techniques document, and finally (after the objections of one of our trainers) it became the SOP Practices And Techniques document – that I’m still working on today.

In the early days, in order to communicate to crew the ongoing changes to this document during our training intensive startup phase – I wrote about each new paragraph/section on Virginetics, our Crew website. Often some very interesting discussions resulted – so I though I might now try blogging about the development of this document in the public domain.

Thus “P&T Updates” will now commence for a blog series, and we’ll see where the discussion leads us …