A reader wrote to me, who has been very interested in FBW (Fly by Wire) planes for a number of years. He described himself as an an old burned out computer programmer, though he's written for Scientific American on self healing flight systems, so he was far from a novice in the field.
Here's my answer:
Perhaps we should differentiate between the internal simplicity of the system and the apparent simplicity of it to the user.
After all, the Airbus FBW system comes down to just a stick, and a set of rudder pedals, the same controls used for airplanes dating back 100 years.
The interface is simple and familiar. The transition from control wheel to sidestick is fairly natural.
Pilots are also used to certain behavior from the machine. Even there, what those behaviors are may differ depending on the pilot's past experience. Not every pilot has the same training and experience.
Some of the natural characteristics of an airplane's natural behavior may be viewed as negative (at least by engineers).
There are characteristics that present a danger at the edges of the normal envelope (stall, overspeed, structural limits, and attitudes that present an increased danger of loss of control). There is also a historical accident record and various human factors studies from which to draw design goals and decisions.
It is interesting to note the similarities and differences between the approaches that Boeing and Airbus designers each took to answer the same realities of aerodynamics and human interfaces.
For example, both eventually chose a g-load demand (C*) pitch command law , and rate of roll demand law for roll ("eventually" because the 777 was direct in roll, but 787 is roll-rate demand). However, Boeing chose to mimic the historical and natural aerodynamic pitch stability in speed (C*U pitch law) (for a positively static stable airplane) while Airbus apparently viewed the constant use of pitch trim for the pilot as additional workload that could be eliminated.
The Airbus design is more simple to operate (i.e., no trim switch or constant trimming necessary) while the internal functions to carry it out are arguably more complex. Therefore, which is the simpler system? Einstein is perhaps the right person to be able to address the paradox.
A similar design philosophy juxtaposition occurs with the thrust levers: moving vs. non-moving. One is arguably simpler on its face, yet has different internal functionality not necessarily carried forward from a pilot's past history. The other mimics more historical behavior, yet requires the use of additional switches to make selections (e.g. climb thrust). The historical (moving) thrust levers are also an extension of the past systems that were simply conventional thrust levers driven by a very simplistic analog computer and motor -it was all it could do. The non-moving design is easily looked at as a fresh (clean sheet of paper) design given the current state of system capabilities.
There are similar differences in the flight management / autoflight systems. Each must address the functionalities required of the real world ATC environment, and many functions are similar. But, like two word processing programs, the path to the goal is often provided by two different approaches to organizing the interface (in this case the FMS interface). Personal bias and paradigms of how the system is organized cannot help but play a part in each person's evaluation of which system is "better."
The answer may depend on your point of view.
It is interesting to have operated several generations of navigation systems (the earlier ones cannot by any measure be called flight management systems) and see the evolution of one to the next as system capacity and functionality increased.
Still, often times the demands of the real world are not met by the design of the system and user feedback is an important element in the continual design evolution. For example, the original FMS design used by Airbus did not allow for a change in the descent speed basis once the descent had begun (this is what the idle descent VNAV path is based on); but often times ATC will change that speed in the descent. Pilots then either have to trick the system into letting them change the planned speed, or know that the resulting path information is now incorrect. Operator feedback to the manufacturer asked for the ability to change that speed at any time.
>>I think one reason for our differences is that you're looking at these things like a pilot and I'm looking at them as an old burned out computer programmer !<<
Yes, that is indeed an issue and a problem! For the system is for the PILOT to use! Yet, in many cases is build using the perceptions of the engineer ( who does not use the airplane daily in the ATC environment). It must also be within the constraints of the engineer's abilities , which includes the computational abilities of the machine. There are also (apparently ) artificial limitations in the design that allow the pilot to do only certain things to keep the design interface from being overly complex. But, limiting the types of entries possible for creating a waypoint (for example), while seemingly reducing the number of formats a pilot must know also requires additional time and complexity when the desired point cannot be created with the toolbox provided and an alternative solution or manual operation has to be employed.
I once worked with a software engineer who was making flight simulators. He was designing the instructor interface, but had never even sat in on a real instruction session to see exactly how the instructor actually worked. Therefore his perceptions of what would be "cool" and functional was often not quite right.
I ended up having a lot of influence on the design and prototyped some functionality myself which was then incorporated into the interface.
The successful design required knowing not only what was needed, but what was possible. The designer has his preconceptions of what the user needs. and the user might not even know enough to be able to ask for a certain functionality, not realizing what was even possible.
>Simple computer systems are the easiest to work with, get to market quicker and are easier to maintain than more complex systems.<<
Simpler systems, however, may take more effort to operate in a demanding environment. Are cars better without anti-skid braking systems? Certainly those without are simpler. But even there, where there is only just a simple brake pedal control, the way to use that control is different in the modern (better/safer version) than it was historically , due to the previous design's limitations. Drivers must be educated on it. Eventually new drivers will assume it was always like that - perhaps the future of fly-by-wire.
A great analogy perhaps can be seen in the evolution of the phone. I recall that in the 60's the phone company had to run ads showing people how to use a push-button phone. They had to sell the idea and how to use it (and it wasn't a slam dunk sale either). Now if you show a 6 year old a rotary phone, they don't even know what it is, or have any idea how to use it (nor do they know why we say "dial" a phone number.)
But there had to be a paradigm shift in the whole phone system for that to work. The switching had to go from counting clicks to decoding tones. Which was simpler?
He said that:
"over the years I've honed a very strong belief in user interfaces that match an Einstein saying - 'everything should be as simple as it can be, but no simpler'. Simple computer systems are the easiest to work with, get to market quicker and are easier to maintain than more complex systems.
"over the years I've honed a very strong belief in user interfaces that match an Einstein saying - 'everything should be as simple as it can be, but no simpler'. Simple computer systems are the easiest to work with, get to market quicker and are easier to maintain than more complex systems.
Using that approach, I see flight systems as unnecessarily complex. Plus I believe that when a crisis arises, a simple system has a better chance of helping the pilot save the day. ( Although I note that you have several examples of Boeing planes which crashed without the "benefit" of a computer. )
I just like simple systems....
Here's my answer:
Perhaps we should differentiate between the internal simplicity of the system and the apparent simplicity of it to the user.
After all, the Airbus FBW system comes down to just a stick, and a set of rudder pedals, the same controls used for airplanes dating back 100 years.
The interface is simple and familiar. The transition from control wheel to sidestick is fairly natural.
Pilots are also used to certain behavior from the machine. Even there, what those behaviors are may differ depending on the pilot's past experience. Not every pilot has the same training and experience.
Some of the natural characteristics of an airplane's natural behavior may be viewed as negative (at least by engineers).
There are characteristics that present a danger at the edges of the normal envelope (stall, overspeed, structural limits, and attitudes that present an increased danger of loss of control). There is also a historical accident record and various human factors studies from which to draw design goals and decisions.
It is interesting to note the similarities and differences between the approaches that Boeing and Airbus designers each took to answer the same realities of aerodynamics and human interfaces.
For example, both eventually chose a g-load demand (C*) pitch command law , and rate of roll demand law for roll ("eventually" because the 777 was direct in roll, but 787 is roll-rate demand). However, Boeing chose to mimic the historical and natural aerodynamic pitch stability in speed (C*U pitch law) (for a positively static stable airplane) while Airbus apparently viewed the constant use of pitch trim for the pilot as additional workload that could be eliminated.
The Airbus design is more simple to operate (i.e., no trim switch or constant trimming necessary) while the internal functions to carry it out are arguably more complex. Therefore, which is the simpler system? Einstein is perhaps the right person to be able to address the paradox.
A similar design philosophy juxtaposition occurs with the thrust levers: moving vs. non-moving. One is arguably simpler on its face, yet has different internal functionality not necessarily carried forward from a pilot's past history. The other mimics more historical behavior, yet requires the use of additional switches to make selections (e.g. climb thrust). The historical (moving) thrust levers are also an extension of the past systems that were simply conventional thrust levers driven by a very simplistic analog computer and motor -it was all it could do. The non-moving design is easily looked at as a fresh (clean sheet of paper) design given the current state of system capabilities.
There are similar differences in the flight management / autoflight systems. Each must address the functionalities required of the real world ATC environment, and many functions are similar. But, like two word processing programs, the path to the goal is often provided by two different approaches to organizing the interface (in this case the FMS interface). Personal bias and paradigms of how the system is organized cannot help but play a part in each person's evaluation of which system is "better."
The answer may depend on your point of view.
 |
| Which of these depictions is simpler? |
Still, often times the demands of the real world are not met by the design of the system and user feedback is an important element in the continual design evolution. For example, the original FMS design used by Airbus did not allow for a change in the descent speed basis once the descent had begun (this is what the idle descent VNAV path is based on); but often times ATC will change that speed in the descent. Pilots then either have to trick the system into letting them change the planned speed, or know that the resulting path information is now incorrect. Operator feedback to the manufacturer asked for the ability to change that speed at any time.
>>I think one reason for our differences is that you're looking at these things like a pilot and I'm looking at them as an old burned out computer programmer !<<
Yes, that is indeed an issue and a problem! For the system is for the PILOT to use! Yet, in many cases is build using the perceptions of the engineer ( who does not use the airplane daily in the ATC environment). It must also be within the constraints of the engineer's abilities , which includes the computational abilities of the machine. There are also (apparently ) artificial limitations in the design that allow the pilot to do only certain things to keep the design interface from being overly complex. But, limiting the types of entries possible for creating a waypoint (for example), while seemingly reducing the number of formats a pilot must know also requires additional time and complexity when the desired point cannot be created with the toolbox provided and an alternative solution or manual operation has to be employed.
I once worked with a software engineer who was making flight simulators. He was designing the instructor interface, but had never even sat in on a real instruction session to see exactly how the instructor actually worked. Therefore his perceptions of what would be "cool" and functional was often not quite right.
I ended up having a lot of influence on the design and prototyped some functionality myself which was then incorporated into the interface.
The successful design required knowing not only what was needed, but what was possible. The designer has his preconceptions of what the user needs. and the user might not even know enough to be able to ask for a certain functionality, not realizing what was even possible.
Simpler systems, however, may take more effort to operate in a demanding environment. Are cars better without anti-skid braking systems? Certainly those without are simpler. But even there, where there is only just a simple brake pedal control, the way to use that control is different in the modern (better/safer version) than it was historically , due to the previous design's limitations. Drivers must be educated on it. Eventually new drivers will assume it was always like that - perhaps the future of fly-by-wire.
A great analogy perhaps can be seen in the evolution of the phone. I recall that in the 60's the phone company had to run ads showing people how to use a push-button phone. They had to sell the idea and how to use it (and it wasn't a slam dunk sale either). Now if you show a 6 year old a rotary phone, they don't even know what it is, or have any idea how to use it (nor do they know why we say "dial" a phone number.)
But there had to be a paradigm shift in the whole phone system for that to work. The switching had to go from counting clicks to decoding tones. Which was simpler?
