Deathbed Confession of an Airbus - July, 2009

[allardjd 1,853]

John’s Corner

 

by John Allard

 

Deathbed Confession of an Airbus

 

We live in a highly automated and very computerized world. That becomes more true every day, nowhere more so than at Airbus Industries. Much has been made of Airbus’ propensity for automating everything in sight to a fair-thee-well. Many are critical of it. There’s very little to argue against the fact that Airbus’ and Boeing’s philosophies are quite different in this respect, thought both companies’ aircraft are highly automated.

 

I’ve read a number of articles, blogs and widely circulated e-mails recently, many by real-world pilots, who decry the Airbus way of doing things and in some cases, the use of fly-by-wire in general. Many pilots hate the concept of being isolated from the actual physical control surfaces of their aircraft by a black box (or two or three or more) whose functions include preventing them from doing certain things with the airplane. The argument is that at times, perhaps in circumstances unforeseen by the designers and programmers, it may be necessary for the pilots to do those prohibited things. In those cases, because the software inhibits or even ignores certain of their control inputs, it would be impossible for them to do so.

 

Boeing seems to have maintained a philosophy for keeping the pilot more in the loop and retaining for him the capability to ultimately make the decisions of how the aircraft is to be configured and controlled. Make no mistake - there are many things that the Boeings will not permit the pilot to do and the list probably gets longer in each new model. None the less, in general, the guys in the front office of a Boeing have a much greater span of control in the details of flying the airplane than their cousins who have an Airbus strapped to their butts.

 

A reasonable case can be made that electro-mechanical devices are capable of flying airplanes more precisely than people can, at least in certain circumstances. A relatively rudimentary auto-pilot is a good example. In their most basic form auto-pilots do not even require a microprocessor – they’re just a simple controller with one or more sets of inputs, outputs and feedback loops. They are designed to sense deviation from set-points (altitude, heading, airspeed, glide slope, CDI, etc.) and to make an adjustment to an actuator to correct the deviation. The most simple and primitive of autopilots can generally make a monkey of the most experienced pilot when it comes to precisely holding a heading or an altitude or a speed or an attitude, even though we persist in referring to the device itself as, “the monkey”.

 

Add a microprocessor or two and some decent software and the sky’s the limit, so to speak. That’s happening throughout aviation today – Airbus has no monopoly on that, though have certainly taken the concept further than their competition in Chicago (it’s so hard not to say Seattle any more). The modern Boeing airliner is full of microprocessors and they manage all kinds of things for the aircrew. The fundamental parting of the ways is that in the Boeing, the computers do not (yet) have the capability to override the pilot’s inputs to the flight controls and the Airbus does. There lies the difference. It is sometimes said that in the future, the aircrew of an Airbus will only consist of a pilot and a dog. The pilot’s job will be to feed the dog – the dog’s job will be to bite the pilot if he tries to touch anything.

 

It has been stated that there have been cases where the Airbus flight control computers have prevented pilots from doing the right thing in unusual circumstances and that is almost certainly true. There is a fairly unassailable record that a few crashes have resulted from such situations – the computer had prevented the pilot from saving the airplane and some lives in a few isolated cases. That’s a serious charge and there’s little doubt that it has some basis in fact.

 

Why do they persist then? Isn’t the concept fatally flawed? Shouldn’t this entire business of fly-by-wire be abandoned, at least in non-military applications? In my opinion, no, it should certainly not be prohibited nor abandoned.

 

While I offer no preference one way or the other between the Boeing and Airbus aircraft control philosophies, the technocrat in me bristles at the idea of prohibiting or severely inhibiting the use of a promising technology. Microprocessors, computers and software are here to stay. They already control all manner of things in our everyday lives, some of which are every bit as vital as driving airliners. Within the context of aviation itself, air traffic control comes to mind as one place where computers perform vital functions that, if done incorrectly might result in the deaths of people in airplanes. Some aircraft systems put the computer in charge of something vital; FADEC (Full Authority Digital Engine Control) amounts to fly-by-wire throttles. Navaids of certain kinds employ hardware that is operated by software – GPS could not exist without it. Cat. III approaches and Autoland would not be possible. There are hundreds more examples in aviation, in medicine, in utilities, in industry, in transportation, in food processing. Computers are widely used to control vital life-sustaining or potentially deadly processes and mostly do it quite well.

 

In modern industries, when something bad happens, there is generally a very rigorous attempt made to understand why, to extract lessons learned and to make changes to whatever it was that led to the event. My own career in commercial nuclear power has given me insight into the process and I know it to exist as well in aviation. Accident and event investigations are driven by a formalized process that is specifically directed at understanding causal factors so that they may be reduced or eliminated in the future. It lies at the center of the entire process. You didn’t think that governments spend all that money investigating aviation accidents just to satisfy our curiosity, did you? No, there’s a strong and valid reason why that very expensive investigative effort is made.

 

Following each crash, to a greater or lesser extent, those lessons learned are extracted and made available to those who are designing and building and maintaining the aircraft and to those who are hiring and training the pilots. Sometimes it is left to the companies themselves whether and how to react; sometimes it is mandated. In any case, the details of the accident investigations may lead to all manner of improvements in the hardware, in the procedures and in the training of the operators. Of late, improvement of the software can be added to that list. If an Airbus flight control computer prevents a pilot doing something necessary and an adverse event occurs or almost occurs, it’s a safe bet that the software will be improved – re-configured to take into account that newly-realized scenario. After each event, aviation becomes safer than before as the lessons learned are applied. It’s always been so – for powered flight it began with two guys who built bicycles and airplanes in Dayton.

 

As an anecdote illustrating where automation made a positive contribution, I offer a small but important detail of the US Air Flight 1549 ditching in the Hudson River last winter. Our new hero, “Sully” Sullenberger managed the impeccable placement of the big jet into the river, setting it down without splitting it open. Sully deserves every bit of the praise he’s received, but he had some help. As he approached the water, he knew that he needed to set the plane down at the lowest possible airspeed without letting it stall. The slower the speed at impact, the less violent it would be for the passengers and the better the chance of the airframe remaining intact. As events transpired, he managed it – touching down so slowly that the fragile airframe lost no major components save one engine. The fuselage and both wings stayed together and retained enough integrity to serve as lifeboat for the passengers and crew. They were cold and wet, but they weren’t treading water, much less fighting their way out of mangled, sinking wreckage.

 

So how did Sully manage that meticulous, miraculous touchdown? How did he keep the “bus” at the lowest possible airspeed and still avoid the stall that would have killed them all? He did it by holding the Airbus side-stick controller full aft – right to the stops. The fly-by-wire flight control computers, which are between the pilot’s controls and the control surfaces, were programmed to not let the aircraft stall – not by Sully, but by the designers of the Airbus. Sully was, in effect, saying to the black boxes, “raise the nose”; the software was saying, “yes, but don’t stall”. The flight control system did both, with life-saving precision. Sully had to do no more than that – just hold the stick fully back and the system finessed the rest. There can be no doubt Captain Sullenberger had a few dozen other tasks on his plate at the same time and he handled them masterfully. The little black chips did their part of the job though, and allowed him some attention for some of those other things. Sometimes automation helps, even in an emergency.

 

All that brings me to Air France flight 447, in pieces in the South Atlantic a few hours out of Rio. How does all the preceding talk about Airbus automation relate to that? Do I think that an excess of automation doomed AF 447? No, I do not think that – there’s no significant data available to support or refute it – only some tenuous sniffs and isolated facts that could be interpreted to point either way. I do think, however, that MORE automation might have provided us a better picture of what truly did happen – a picture we may possibly never have available to us because of the circumstances of the deadly event.

 

As I write this, the Cockpit Voice Recorder and the Flight Data Recorder have not yet been located. The “pingers” are within eight days of their design endurance in the water. After that, the odds against locating, much less recovering them become astronomically higher. Lives have been lost but what’s in those boxes lying on the ocean bottom could save other lives. There is vitally important information in them that exists nowhere else on the planet – if they can’t be recovered, that information is lost to us. Yet more lives may be forfeit in the future for lack of that information.

 

The Air France A330 gave some tantalizing clues to its demise that fateful night. It sent approximately four minutes of data indicating problems with some of its systems. It’s the tip of the iceberg, but certainly has provided some clues and some food for speculation. Perhaps most important is the suggestion that the airspeed data from the pitot tubes was “unusable”. The pitots originally installed in the A330s were already suspect and Airbus had recommended replacement – the old type was still installed on the flight 447 aircraft. While not a smoking gun, it was enough of a clue that A330 operators have turned up the heat on the replacement of the suspect sensors and it is being pursued with a new vigor borne of the possibility that it was those which brought down the French flight.

 

The system by which the Airbus transmitted its systems data is known as ACARS, or Aircraft Communications Addressing and Reporting System. ACARS is old technology, first introduced as far back as 1978. It is routinely used by commercial aircraft for the automated transmission of operational information between aircraft in transit and company ground facilities. The most common use is for OOOI events, Out of the gate, Off the ground, On the ground and Into the gate messages.

 

In the more advanced aircraft, to the extent that systems automation allows it, ACARS is also used for transmitting systems data to company facilities, alerting the maintenance staff to failures, problems or anomalies that might require attention at a subsequent stop. It was that kind of information that the doomed AF A330 was sending as it was coming unglued over the mid-Atlantic.

 

In more normal circumstances, the timely receipt of such information while the AC is still in flight permits the maintenance organizations to hit the ground running. They have a better chance at having the right people, the correct parts, the necessary test equipment and tooling or whatever else might be needed at the gate when the AC arrives. In many cases, this can make the difference between the next flight being delayed or not. It’s a good, solid system that helps keep the utilization factor of those very expensive assets as high as possible.

 

So, given the widespread existence of ACARS in commercial aircraft today and an even more capable replacement (ATN; Aeronautical Telecommunications Network) on the horizon, and ever more computerized and self-aware aircraft emerging, I’d like to proffer a suggestion. What if, instead of sending those few snippets of questionably relevant systems data AF 447 had instead transmitted some or all of the data contained in the Cockpit Voice Recorder and/or Flight Data Recorder? What if it had been able to make a true deathbed confession?

 

I used the term self-aware in the preceding paragraph to mean an aircraft that is capable of monitoring its own flight parameters and systems functions in an integrated and fairly intelligent way. Most large modern aircraft can do that already – it’s not a bad description of what’s captured by the Flight Data Recorder.

 

Given the centralized mass of data that the Airbus computers had available, it does not require a great leap to visualize software that would also be capable of recognizing when the aircraft is in extremis. It would be quite feasible to devise a list of parameters which would, if some were out of normal limits, signify that the aircraft was in serious danger. The list is long, the parameters easily monitored – cabin pressure; engine power; fuel quantity; rate of descent; control movements; g-loading; airspeed; attitude; altitude; ground proximity; position. None of those is very hard to monitor nor would it be particularly difficult to craft a program that could determine when the aircraft is not operating “normally”.

 

My proposal is that such a system be developed and mated up with the CVR and FDR, perhaps by just providing a buffer to which the data that is already being sent constantly to the recorders would be written in parallel. If the calamity detecting function that I envision were to sense that a disaster was in the making, it could shift into a “deathbed mode” and use ACARS or whatever other system replaces it to begin dumping FDR and CVR data at whatever rate was available, via radio or satellite. One assumes that bandwidth is not infinite and there must certainly be limits to how much can be sent – still, some is better than none. Depending upon the nature of the problem it might not be possible to send all of it. Some scheme of prioritization would need to be devised and certainly the final few moments of data would be lost if the worst occurred.

 

Never the less, would that not be better than what Air France and Airbus and the French and Brazilian governments are faced with now? They’re spending enormous amounts of time and money trolling the ocean for a sniff of two five pound devices under four miles of water. That which they seek will become nearly impossible to find in another week or so when the pingers go silent. People’s lives may well depend on them being found and it is quite possible that they never will be.

 

When a 777 pancakes short of a runway or when an ice-laden Dash 8 stalls and falls vertically on a house, recovery of the recorders is not such a Herculean task. Water recoveries are more arduous and difficult and in some cases, perhaps impossible. High speed, high angle impacts, intense fires or in-flight breakups further lessen the probability of the recorders being found and recovered or of the data being intact, readable and useful. Over-ocean accidents present major additional challenges, not least setting the 30-day clock ticking, after which the recorders go silent and stealthy, sleeping with the fishes and with their invaluable data for eternity.

 

The potential downside of false alarms caused by a self-triggered system seems relatively benign. Certainly there might be times when the doomsday data might be transmitted by accident with the resultant flurry of concern. Still, for most flights, most of the time, it would take no more than an ATC voice query to affirm that all is well – or is not. If over-ocean and out of radar and normal voice radio coverage, that same ACARS system also permits text messages between crew and ground facilities. It should never be a matter of more than a few minutes to determine if an airborne alarm is valid. If not, there’s little harm done by puking out the recorder data, just in case. The only ill effect is to cycle the system unnecessarily.

 

Changes like this come slowly, but I think inevitably it will happen. It seems likely that non-voice air to ground communication capability will grow significantly over the next decade or so. Ultimately the voice based, human operated ATC system is going to give way to a new generation of transponders that will know where they are via GPS and which will automatically re-transmit that position information to whatever passes for ATC on the ground. Computers will unravel the data and will give whoever or whatever is controlling the traffic a picture of who is where and whither bound. Radar will no longer be needed. With that kind of capability being developed, it’s not such a great leap to have AC made capable of transmitting their vital signs if they are out of normal limits. It’s all child’s play in that brave new world we’re building. It will take some time, but it will come and we’ll be better off for it.

 

[ddavid 149]

Thanks for that, John - compelling reading covering most of the angles. I've wondered about this aspect of searching for black boxes since reading Michael Criichton's Airframe. And then there's the problem of mid-ocean ATC - or lack of it. With the intrinsic value of any passenger aircraft higher, in human life terms at least, than practically any other of man's endeavours, why can its progress not be continuously monitored? Let's face it, were not back in the days of Apollo when Jodrell Bank and Woomera (or whatever) needed to be emplyed as a 'relay' station, are we? Maybe your 'wish' will come true with the so-called 'new generation' of GPS satellites - let's hope so, eh?

Thanks again for compiling and sharing! :smile:

Cheers - Dai.

[rob16584 42]

Another fantastic and very thought provoking article John, I've enjoyed this one the most so far.

I think that as technology continues to progress at this amazing pace that it is inevitable that computers/automation will play an even bigger role in aviation. Maybe in the future the only 'real' way to fly without complex computers would be to fly something like a Cessna.

What amazes me though, that with all these techical advances that no-one has yet developed a black box that can actually float on water. Surely it would be much easier and cheaper (used in the loosest possible terms) to locate a floating object than one burried miles under the surface????

[allardjd 1,853]

I suspect that there is a reluctance to spend big money on something that is used/needed so seldom. Crashes are thankfully infrequent. Crashes where the CVR and FDR are unrecoverable are only a small percentage of those, so the need does not present itself very often. Having said that, the need to recover the recorders from this specific AC is strong and it looks as if it may not be possible at all... unless the US Navy SOSUS system has heard something and at the approriate time the US Government will pass a note to somene in Europe that says, "Look here...".

 

During the cold war it was said that a Soviet submarine sailor couldn't break wind without someone sitting at a console in the US hearing it. Once heard, they could run an acoustic analysis that would reveal what region of the USSR the cabbage came from and how long it had been since he'd last changed his underwear.

 

John

[mutley 4,498]

John,

Thanks for a very thought provoking piece. A lot of what I wanted to say by way of thanks has already been posted here.

I have to agree with your sentiments in that we have to embrace and educate these computers to take the ultimate decisions with every possible scenario known.

Sure, there is always going to be the X factor, the event that no-one could have predicted, or, a sequence of events that in theory could not happen that we could not predict.

Most of what we get back from micro-processors is what we already know, but (usually) in a fraction of a second. What we have to develop more is the fuzzy logic aspect of decision making which is not quite so precise, but may offer a get out from the narrow focussed decision decided on by the PC.

A superb, 5 star post John, this one, with your permission will be published on the main site?

Regards

[allardjd 1,853]

Quote

this one, with your permission will be published on the main site?

 

Mut,

 

I'd be honored, of course.

 

You know, after writing and polishing this one, I didn't expect it to be well received - too technical, too obtuse, too... whatever. I'm never able to figure out ahead of time what the readers are going to find interesting and what will be ho-hum.

 

Interesting that another Airbus (Yemeni A310 this time) is in the water a day after this article was published, though near land this time. I saw one reference that said "deep water", but probably not four miles deep. Also, the location will be better known and this one does not appear to have come apart at altitude and scattered itself to the four winds as AF 447 did, so the odds of recovering the recorders look much better this time.

 

John

[allardjd 1,853]

Airbus Wants to Replace Black Boxes with Real Time Data

[mutley 4,498]

Airbus Wants to Replace Black Boxes with Real Time Data

[ddavid 149]

Ten-Four, John!

Cheers - Dai.