“Hold 250 knots IAS in the climb until reaching 10,000 feet and thereafter maintaining a constant .65 Mach until reaching assigned cruise altitude.”
“After reaching level flight, maintain climb power until reaching .77 Mach, then trim the aircraft and reduce power to cruise setting before engaging the autopilot”
The words of the pilot’s handbook describe the process of flying a heavy jet transport category aircraft to cruise altitude in a deceptively straightforward and uncomplicated manner. This is a great oversimplification of what is really taking place in the cockpit.
Pilots do not just control airplanes. In fact, a system engineering analysis of aircraft operation would discover that the pilot is an integral part of the aircraft control loop. This means that the pilot is receiving information from the aircraft and providing both information and commands to the aircraft in a continuous process.
In system engineering terms, the pilot is connected to the aircraft physically through a two-way broadband bus that carries data, commands, and perhaps status messages. All this is accomplished using the senses of sight, sound, tactile pressure, the balance sensors in the inner ear and the motive force of hands and feet. Much of this interchange goes beyond written procedures, has subliminal clues, and normally has to be learned by repetitive exposure to the various conditions actually encountered in flight.
Another way to say this is that the pilot feels the aircraft actions through the controls and responds with other actions that modify the operating state. The interaction is so intricate, persistent, and has so many channels of information being exchanged that it is seldom discussed or fully explained in any formal training.
Lets go back and examine the climb profile again. As the pilot makes attitude and power adjustments in the process of climbing to cruise altitude, he or she is consciously evaluating the feel of the controls and the way the airframe responds to gusts and control inputs. Is the climb faster than normal, are the engines all putting out equal thrust, is there any vibration or noise that is unexplained? Apart from these items, the airplane feels truly alive and soon has a predictable aerodynamic feel even though in modern aircraft it is provided by a system of springs and bob-weights.
How does a user interface (UI) in a typical IT system compare with this? Basically, we can name only three common features: visual, hand inputs, and limited sound. The biggest disparity, however, is in the data rates. Nothing in our normal IT environment short of emerging simulation equipment comes even close to providing the complexity of the interface between pilot and airplane.
The aircraft is now approaching the planned cruise Mach number. If the throttles are reduced upon reaching this speed and the autopilot applied, we may be wasting fuel and all successful pilots try to hoard fuel as insurance against uncertainties.
It is possible to establish an important and subtle aircraft state that will reduce the appetite of those roaring turbines.
It’s the step.
Just like a nudge of encouragement we give to living creatures, the pilot carefully places the aircraft into a state where the fuel flow is minimized to that last decimal point. It is accomplished by accelerating slightly past the cruise speed, trimming the aircraft into level, un-accelerated flight and gently reducing power and airspeed to the desired cruise Mach number. The effectiveness of this technique varies with each aircraft and even within the same model and there are even some theorists who vehemently deny its validity. Pilots don’t care much for the theorists because they know from experience that the aircraft will reveal when it is on the step by the way it holds the cruise speed and self corrects when gusts cause momentary excursions.
Information systems operators are just beginning to find their step. The UI or human-machine interface is developmentally many years behind the aviation example. We are still typing in commands, overloading the human side of the UI and generally ignoring the advantages of increasing both bandwidth and machine to human communication rates. Protocols and languages cannot be directly shared and feedback mechanisms even when they are provided are vexingly complicated.
It’s time that we get serious about the costs and performance penalties we incur by ignoring UI designs.
Fortunately help is on the way. The Carnegie Mellon University has published what is a call for action in several DoD sponsored studies.
Consider putting your next IT design on the digital step by visiting one or more of Carnegie Mellon’s sites that address UI.