view, the requirements should be configuration managed (changed only by program directive) in response to known unknowns and unknown unknowns. Wherever possible, the user pilots of the helicopters should be consulted early in development and kept aware of the developing interface. A representative sample of the user community, environmental conditions, and missions should be included in a simulation program.
Creating a pilot-vehicle interface specification early in the program will address many of the questions and issues of cockpit development that have been raised in this chapter. Mission and task analysis are a requirement of most major development programs, as well as generating human engineering design approaches. The human engineering approach proposed here is cost-effective because it centers on the continued iteration of analyses already conducted during the early stages of most programs. Eventually the display formats, control methods, and menu structure will have to be documented for testing, and for development of training courses and devices. Although the effort shifts from an after-the-fact documentation to a design driver, it is not a new, unfunded activity. No new tasks are being defined by this approach, although some tasks are in more detail earlier in the program than previously. The human factors engineer must broaden his or her outlook and repertoire of skills, but the benefit is that the interface has the attributes and characteristics desired by design rather than by luck.
Helicopters present many of the same issues to the human factors engineer as do fixed-wing aircraft, but helicopters do have unique challenges. These issues are related mostly to how helicopters generate and control lift and to what is done with the unique flight capabilities. Human factors engineers have always had an important role in designing a low-workload, high-situation-awareness cockpit, and that role will be more important in the computer age. Mission equipment development is now as expensive as airframe development, with a large portion of that cost due to software. Human factors engineers must understand how computerized systems are developed and join in the process if acceptable cockpit workload and situation awareness are to be maintained in the face of ever-increasing capabilities and expanding missions. Just as in airframe development, oversights in requirements and confusions in meaning can have very serious impacts on cost and schedule of software-intensive systems. Like an airframe, software must have the inherent risks in the proposed design reduced by a systematic program of test and design maturation. This process of software requirement decomposition and verification will benefit from the participation of human factors engineers and will result in increased responsibilities for them. No new technological breakthroughs are required; the tools for design and test are available, but must be used in new ways.
Table 17.1 provides a list of references useful in the area of helicopter human factors. The list is composed primarily of military specifications (MIL-SPECs). MIL-SPECs have been condemned in recent years as the source of unnecessary cost and waste in defense procurement, and it may well be the case that elimination of chocolate chip cookie
Questia, a part of Gale, Cengage Learning. www.questia.com
Publication information: Book title: Handbook of Aviation Human Factors. Contributors: Daniel J. Garland - Editor, John A. Wise - Editor, V. David Hopkin - Editor. Publisher: Lawrence Erlbaum Associates. Place of publication: Mahwah, NJ. Publication year: 1999. Page number: 423.
This material is protected by copyright and, with the exception of fair use, may not be further copied, distributed or transmitted in any form or by any means.