Having just read Capt. Richard de Crespigny’s new book on the dramatic QF32 events (and their handling) that unfolded on the 4th November 2010, I felt a need not only to compliment everything that he, his crew and complementary organisations achieved in getting so many to live to tell the tale, but in also in his taking the time and effort to personally tell the tale in this book! I am overwhelmed by it all and the heroic achievements.
However I also have some questions, that I know he would appreciate having a systems engineering & software development orientation too. These questions relate to follow-up engineering enhancements to mitigate some of the risks and problems identified in the book into the future.
I recall I wrote in a suggestion arising from the events where Air France A332 over the Atlantic on Jun 1st 2009, entered high altitude stall and impacted the ocean. In that case the flight recorder could not be retrieved from the depths for a long time even though its locator beacon could be detected. My suggestion then was that they improve the design to modulate the black box recorder’s beep with some of the most crucial information – particularly that information pertaining at the time it entered an alternate mode and that had not already been transmitted (and auto-acknowledged as received) prior to impact. They did not get back to me then as no doubt higher priority and more immediate concerns were fully occupying their attention.
In the case of the QF32 crisis events in November 2010, I wonder what engineering initiatives have since been proposed? For example, has a line-of-sight laser modulated communication and control channel with or to outboard subsystems on the wings been considered? This would not be the first time that hardware C&C lines been severed in catastrophic event sequences and such a backup channel would be far less prone to physical damage in the intermediate structures. Have alternate methods for shutting down engines effectively been proposed? Have additional external cameras been proposed? Have dependencies in the APUs operation being re-engineered or that at least proposed? Even beyond such changes, that of course would take significant time to properly research, engineer, implement and test properly, there is the purely software and procedural domain of ECAM logic and performance planning software… This is software that prioritises malfunctions and checklists to cope and a separate software application that helps set parameters for landing a compromised plane. Capt. de Crespigney relates in the book several instances where the common sense and engineering insight of he and his team picked up system recommendations that, in the complex web of failed subsystems on the day, were contra-indicated or might have made matters worse. It seems to me that failure modeling to test and enhance such logic might well take many years of ongoing effort. I would love to know if the prominent ones detailed in the book have yet been implemented?
On a personal level, I got an unexpected emotional shock to read about Capt. de Crespigney’s wife – Coral. There is a possibility that I have met her many years ago. A girl by that name who I had met at dances years before in Canberra, came up to me with two of her girlfriends on a wharf in Corfu, Greece way back in 1978 I think. She asked me if I was from Australia and when I said yes, asked me did I not remember her. My replied was “not unless your name is Coral”. They had been on a trip on the Trans-Siberian Railway right across the Soviet Union where, I remember being told, squash balls came in handy because all the sink plugs had been nicked. It can be a small world!