Newsgroups: sci.aeronautics.airliners Path: news From: rdd@cactus.org (Robert Dorsett) Subject: Seeking pointers on switch design. Message-ID: Approved: kls@ohare.Chicago.COM X-Original-Message-Id: <9211241115.AA16994@cactus.org> Sender: kls@ohare.Chicago.COM Date: Tue, 24 Nov 92 05:15:42 CST I'm looking for pointers to articles on the human-factors ramifications of switch design. I've noticed an interesting difference between Airbus and Boeing switch philosophy. Boeing seems to build the "on" state into the switch. It might be a white bar, indicating a closed circuit or open valve on a placarded systems a subdued "on" function description, with an "engage" bar, etc. But the philosophy seems to be: "default" state == off (dark indicator), pilot action to turn it on (white indicator), operational state = on (white indicator) until pilot turns it off again or an abnormal state occurs (colored indicator, annunciator). This doesn't violate the "dark cockpit" philosophy, since only one color (white) is used for selects, and abnormal states are clearly detectable. Airbus (in the A320, and presumably the A340 and A330), on the other hand, seems to use smart-logic to default to an "on" state which is completely dark. The switches, when pressed, then show an *abnormal* state, like turning a fuel pump off. Nearly all of the switches also have a "failure" state-flag, showing an amber or red fault message. There are also systems with "mixed" switch formats. For instance, since a fuel pump state is normally on, a switch, when pressed, turns it off and indicates an off state. But crossfeed valve switches, when pressed, show an "ON," followed by "OPEN," state, which seems more "positive." So the Airbus philosophy seems to be: initialize switch states at boot time (on, no indicator), pilot action to turn it off (illuminated, abnormal state), operational state = dark until pilot triggers a disconnect. Seems to me that Boeing's the correct approach: a thou-shalt-not, drilled into me at an early point, was never to use double-negatives to prompt user actions ("Do you not want to save the file? Y/N") . An action should ideally be expressed in *positive* terms. And the interface should be consistent across all systems and within systems. On the other hand, Airbus' design can be rationalized in that if the computers do *all* routine management, as they do, then bringing the pilots in the loop at initial start-up is an invitation for error: in this model, pilot involve- ment is an *abnormal* event, and signs of that involvement should be highlighted. This raises interesting implications of the pilots being out of the loop TOO long, perhaps never dealing with a system or mentally "reviewing" that system for several flights, as would be the case with more "hands-on" initialization and management. This could be the reason behind Airbus's pre-flight "walk-through," in which each switch illuminates in sequence, requiring the pilot to depress it to extinguish the light. Comments? References? --- Robert Dorsett rdd@cactus.org ...cs.utexas.edu!cactus.org!rdd