QF32

Home > Other > QF32 > Page 17
QF32 Page 17

by Richard de Crespigny


  By the time we’d been in the air for an hour, the ECAM had identified about 100 significant errors and checklists and given us actions to try and fix them. ECAM then helped us secure systems that we could not reset or fix: Engine 2 was shut down, hydraulic pumps were turned off and pneumatic leaks were isolated. ECAM presented lots of errors in the fuel system but no remedies.

  By inverting our logic and looking at what was working, we were able to build our basic Cessna aircraft from the ground up with sufficient bits to build a basic fuel system, flight controls, brakes, landing gear and electrical supplies. This process took over an hour, but I am convinced it was time well spent.

  Alerts kept appearing on the ECAM, but we’d been through the biggest items and attempted fixes.

  Some non-critical problems could not be fixed. One of the two cooling systems for the racks of computers underneath the flight deck had failed. If we had lost the backup cooling system, then I would have expected most of our computer systems to fail. The landing gear was also degraded and we’d lost one of the two landing gear systems. If we lost both, we’d still be able to lower the landing gear by gravity, but we would have had no sensors to confirm the gear was down and locked.

  Some critical problems could not be fixed. The fuel leaks and compromised flight controls and brakes posed a serious threat to safety. We flew on regardless, aware that we’d have to find methods later to mitigate these failures.

  We shut down systems to prevent them overheating, and then we couldn’t get some redundant systems restarted. The auto-thrust had failed early and we’d never get that back. We’d lost both channels of our ground proximity warning system (GPWS) – an essential warning, when flying in cloud or at night, that will prevent you from flying into the ground. We’d also lost one of our three air data and inertial reference units (ADIRU), which would probably confuse many aircraft systems and stop the APU generator connecting to the aircraft. Both satellite phones were failed because the left wing was unpowered, so our radio connection to Qantas in Sydney was lost and was never recovered. The cabin was a mess; with cabin lights flickering continually, alarms sounding and the control panels blanking.

  Network cables, generator feed lines and critical wires were not just cut, they had probably shorted, which must have confused the associated systems. The generator feed cables were isolated quickly, but they might have arced with other wires and parts of the wing, which would have posed a risk of fire.

  Rethinking the state of the plane to establish what worked came down to the two most basic requirements: fuel and control surfaces. Did we have sufficient fuel to keep us in the air? Did we have enough control surfaces working to control the aircraft and land in one piece? I didn’t want to express it like that when we were all holding our nerves, so I didn’t say it to Changi. I have seen a transcript of my radio calls to Singapore ATC and their responses. It was a revelation because both parties sounded quite calm but deliberate. We were very busy, and so I told ATC only what they needed to know and no more. I didn’t want to tell an ‘outsider’ how bad it was and engender panic when we had not even completed the five phases of our ECAM checklists. If I started listing the problems and telling them we’d be coming in heavy, I would be articulating what everyone on the flight deck was thinking – that we were in serious trouble – and I didn’t think it was time for that. It was time to keep fighting, to have full control of the plane and to stay positive, and for this reason I kept my responses simple and vague to Changi ATC, just telling them: ‘Qantas 32. We have one engine failed, fuel and hydraulic fluid leaking from the wing and extensive checklists. We need another 30 minutes in the hold. Please advise fire services that we’ll be stopping at the end of the runway.’

  We ended up holding for about one hour and ten minutes.

  I declared a PAN, not a mayday. A PAN implies an emergency where immediate assistance is not required. A mayday call means there is grave and imminent danger, and immediate assistance is required. I was happy to retain the PAN, and the crew agreed with me. Losing an engine is not a critical problem on a four-engine aircraft and doesn’t necessarily warrant a mayday. We practise engine failures of the worst kind every three months in the simulator, and aircraft performance is always calculated on being able to lose an engine during take-off or at any stage of flight and being able to safely land at an acceptable airport. This would also be my fourth real engine failure. I was not ready to elevate the emergency to a mayday based upon the other failures either. ECAM identified many failures, but also gave us the processes to fix the errors or to mitigate the resulting threats. I didn’t know the true state of the aircraft or our options until the five ECAM phases and our threat and error management were completed. When these processes were finished, I was happy that the aircraft we had built ‘from the ground up’ in my mind was sound and acceptable.

  I also didn’t declare a mayday because I didn’t think I was going to die. I hadn’t stopped to think of my wife Coral and my children Alexander and Sophia. I felt confident we would get Nancy-Bird safely on the ground.

  Little did we know that Changi ATC’s repeated calls and requests for information were triggered by what they were hearing from CNN and Reuters, due to the Batam Island debris.

  Afterwards I would find out that at this time, Alan Milne, the Qantas head of maintenance operations, was in the Integrated Operations Centre with three colleagues, standing around a TV screen watching CNN showing pictures of the engine nacelle taken by residents of Batam Island. Alan recalls it as being a quiet time, thinking the worst but hoping for the best, until that ‘Oh shit’ moment when the camera revealed an image of the turbine disk. At least Alan could see from the Qantas ‘AirCom’ computer displays that we were holding at 7400 feet.

  We were flying at a steady altitude, so he figured we had control of the aircraft, but he knew little else. Then Alan’s mind fast-forwarded to thinking about our eventual arrival. His mind froze when he thought of us on the ground and making the life-and-death decision whether to evacuate the passengers down the slides onto the runway or to keep them on board. Alan remembered an A330 Qantas captain who was in the same situation in Osaka only a few years earlier who made the decision to evacuate the passengers and crew. The captain made the correct decision for those circumstances, but a few passengers were injured during the evacuation, with one passenger breaking his hip. Alan didn’t want us to be faced with the same decision and evacuate unnecessarily, so he put his immediate attention to ensuring stairs and buses would be in position for our arrival.

  While the situation was critical and the flight deck was tense, we were still not panicking. I don’t think it’s fair to expect passengers to be calm and cooperative only to discover later that the pilots were beside themselves with fear. It wasn’t that way for us; we didn’t have the luxury of time to reflect and panic. We remained 100 per cent focused on what lay in front of us and what we had to do. Every word uttered was definite, measured, almost robotic. We were following SOPs and, although the checklists didn’t stop coming, we crosschecked and verified the bad news ECAM was reporting with what we could deduce from the synoptic displays before we actioned any checklist. The ECAM was making sense and guiding us through the mechanical Armageddon, and we felt in control. It was an eerie flight deck, with the continual warning ‘beeps’ every time the flight warning computers registered the next incoming failure, sometimes interrupting with a new higher priority procedure. The system displays and the overhead panel were a sea of red as Matt read the latest alerts and paced his way through the checklists.

  Months later, when I presented the QF32 story, I would play the soundtrack of the cockpit aural warnings to illustrate to the audience what happens when the ECAM starts issuing piercing alerts and won’t shut up. I haven’t seen an audience yet that can handle the noise for more than 30 seconds before people screw up their faces and demand that someone switch the sound off. We endured it for much longer – it was like being in a military stress experiment.
<
br />   We wanted to continue through the checklists, but I was very conscious of our fuel situation and how long we could remain safely airborne. We had a maximum of two and a half hours in the air before Engine 1 failed, and that became our mantra: we have two and half hours, we have options! We have time to run the checklists, we have time to stabilise this plane, understand it, then configure and get it into shape. We have time to plan a landing. We have time, we have time . . . but that was two and a half hours maximum. Fuel was pouring out of the left wing at an unknown rate so this time could be slashed. If Engine 1 ran out of fuel we’d have to reconfigure for a slightly more complex two-engine-out approach and landing.

  I was growing tired of being reactive to the ECAM and I wanted something positive to focus on. There were too many alerts, too many things broken and not much to be achieved by dwelling on them. If you lose half your ailerons, you can’t just sulk that it’s not perfect. I remembered back to my brother’s Arial Red Hunter bike in the Victorian bush; I was too small to both start the huge motorbike and keep it upright, so I’d start it on the rear wheel stand and rock it until it rolled off the stand, and I’d be off. My goal was to ride the bike – not to complain about what didn’t work.

  It was 50 minutes into our flight. We’d attended constantly to the ECAM and attempted to make the fixes on the alerts for failed and degraded systems. I considered that process to be ECAM phase 1 – fixing the broken items or shutting them down, and stabilising the aircraft to remain safely in flight. But we had to move on from chasing the ECAM; we had to move on to phase 2.

  ECAM’s phase 2 is all about ‘what’. What is the state of the affected systems after the checklists have been run? ECAM now displays the diagnostic displays for the degraded systems. For a simple engine failure ECAM would only show a few displays: the hydraulics, electrics and pneumatics. However, in our case the failures had bridged so many systems that ECAM presented almost every system synoptic display. As Matt pressed the ‘tick’ pushbutton we were taken on a tour of all the failed systems. The aircraft was making sense to us and it was at this stage I was able to gain confidence in my inverted logic. Fuel: it was a mess, but we had more than two hours before Engine 1 would fail. Hydraulics: two out of eight hydraulic pumps working – fine. Electrics: the left wing was electrically dead, but the right wing was fine, and we had started the APU to provide two more generators when needed. Wheels: the brakes were a mess and hydraulics were shot, the auto-brakes had failed, some anti-skid modules were inoperative and brake-control systems had degraded to the emergency brake mode . . . forget that! But if I put my foot on the brakes, they would work. Flight control: the enormous outer ailerons had failed, and they were slipstreaming in the air, both sitting at about 70 per cent up. We must have been losing a lot of lift. Stop that! We have two small high-speed ailerons and one medium-sized aileron – not much so I’d better do a control-check and be smooth on the approach. We knew the aircraft pretty well at this 50-minute mark, but it was a relief to have ECAM get us to the point where it had done all it could be expected to do, and all that was left was for it to say, ‘I’m done, handing over – now it’s your turn!’

  ECAM phase 3 could be described as housekeeping. Phase 3 is identical for every ECAM checklist, containing procedural checks that might provide a remedy. We pondered whether any of our failed systems could be reset. We have about 60 reset switches located on the overhead panel, their purpose being to reboot computers – much like on a PC. I asked if anyone wanted to investigate resetting any systems. There was a long pause; resets take a long time, they would probably not work, the aircraft was extensively damaged, and we wanted to get on the ground.

  Next, I asked Matt to run the abnormal checklist for overweight landing as we would be landing 40 tonnes over our maximum landing weight. This checklist would change some of our procedures to mitigate the threats.

  The combination of a fuel imbalance and a reduced roll capability was a definite concern. Along with the issue of fuel generally was the problem of how it was distributed in the fuel tanks and the effect an imbalance would have on the centre of gravity. The large outer ailerons on the left and right wings, and the mid aileron on the left wing, were failed, reducing our roll authority, particularly in strong crosswinds or turbulent conditions. Together, these two failures combined to reduce our lateral control of the aircraft.

  We were also inhibited by our control of the engines. Engine 2 was failed, Engines 1 and 4 degraded, and Engine 3 was also degraded but not quite as severely. Having failures in all three remaining engines did not spell disaster in itself, but at a time when we had centre-of-gravity imbalances and only 35 per cent of our roll control surfaces working, it was a complication we didn’t need. It wasn’t that we lacked the skills on QF32, it was more that since we had one failed and three degraded engines we didn’t have large margins of error. If we set our thrust incorrectly we might cause a yaw motion that induced a roll motion that absorbed more of our limited roll control – not ideal. During a go-around, if we moved the thrust too far forward we thought we might over-temp and blow up another two engines, and then we’d be left trying to fly overweight and on only one remaining engine – impossible!

  We had multiple failures affecting control of the aircraft, so I configured the plane for cruising as best as I could. None of the engines was operating normally, the auto-thrust was failed and we had limited roll capability. Losing auto-thrust meant I had to control the thrust manually, and this task would be made harder every time I added thrust to enter a turn in the holding pattern. Any thrust imbalance would yaw the aircraft and consequently cause it to roll. So I set Engines 1 and 4 to a mid-thrust level, then took my hands off those thrust levers and controlled the speed by varying the thrust on inboard Engine 3. This worked well, the speed was easy to control accurately and I could shift more attention to managing other issues.

  My method wasn’t perfect and you certainly wouldn’t want to fly for twelve hours across the Pacific with the aircraft in this trim state. But it was a safe fix needing little brain space and monitoring while we worked out how we were going to get Nancy-Bird and her passengers safely to ground.

  CHAPTER 21

  It Won’t Do It!

  With ECAM phases 1, 2 and 3 completed, we’d come to a point where we had tried everything to fix the aircraft. Now it was time to take stock of what was remaining and seriously look at what we could do about landing.

  In phase 4, ECAM transitions from trying to fix the errors to accepting the failures and providing advice to mediate the threats. Normally ECAM would display a maximum of two or three INFO (information and guidance) items in the case of an engine failure. On our flight, Matt read out an eye-watering two pages, each page displaying fourteen INFO items. It must be an Airbus record.

  In the second part of phase 4, ECAM displays a list of redundant systems that have failed. (Redundant systems by definition have backup systems, so they should be resilient to simple failures.)

  In the four years I’d been flying the A380, I don’t think I’d ever seen more than two or three failed systems in this list. On QF32 we had an unprecedented large number of failed systems. Matt started reading through the list of failed systems, one item after another. I mentally tracked each failure before acknowledging it – a sign for Matt to announce the next item. Then Matt started reading page 2 – page 2! I’d never seen two pages of faults, and it was taking Matt a long time to read through the list. As I heard each failure announced only to be followed by another, I felt that pile-driver again pushing me deeper into my seat. I was trying to fly the aircraft, monitor our environment and, at the same time, listen to Matt’s calls, but I was becoming fatigued. I’d seen the failures before in earlier parts of the ECAM and I had already decided it was better to think of what was working rather than what had failed. Then Matt called, ‘Press “More” for the next more page.’ I thought, What? Another MORE page?

  Matt’s voice was hoarse, he was tired and, l
ike me, he had also inverted his logic. Finally, as he called out more inoperative systems on page 3, his voice broke and he added, ‘Whatever.’

  We had a list of failures of redundant systems that spanned three pages, each page containing two columns – another Airbus record that will hopefully never be challenged. I agreed with Matt: the list of what was not working for our landing was well established. We’d just spent the last 55 minutes trying to fix all these systems. We created a new term in the Airbus lexicon that day: ‘ECAM fatigue’. Mark could sense the stress and mental exhaustion in Matt’s eyes, so passed him a fresh bottle of water.

  We progressed to the next stage of the landing prep: phase 5, and the LDPA. The LDPA is an acronym for LanDing Performance Application; a Java program that runs on our two laptops. These laptops are stored either side of the two pilots and are connected to the aircraft’s networks by a 2 metre–long umbilical cord.

  The pilot enters the airport, runway, weather conditions and aircraft status, then the LDPA calculates the landing performance. It sounds simple, but it’s a very complex calculation. Luckily ECAM was designed to support the LDPA. ECAM presented a list entitled ‘ALERTS IMPACTING LDG PERF’. This list contains the names of the failures that affect our landing performance that must be entered into the LDPA. For a normal engine failure that we practise in the simulator, we might see one item in this list. But we were in for another shock that day. I’m sure I must have sighed and sunk yet lower in my seat as I viewed the list in front of us. It wasn’t just a few items, the list once again extended over two pages!

  We needed a break. Matt was exhausted, I was eager to talk to ATC and the passengers, and ECAM phase 5 was now a ten-minute computer exercise. I asked Dave and Harry – two expert A380 pilots to calculate our LDPA performance.

  While Dave and Harry went to work on the laptops, I handed the flying of the aircraft over to Matt. He needed to rest his voice, and flying the aircraft would be the ideal way to relax. I explained that controlling the thrust and speed would be easy if he just varied the thrust on Engine 3. I then asked Mark to monitor Matt and the aircraft.

 

‹ Prev