Practical Aspects of Prototyping Instrument Clusters

This paper describes an ongoing effort to develop computer-simulated instrumentation for the UMTRI Driver Interface Research Simulator. The speedometer, tachometer, engine and fuel gauges, along with warning lights are back projected onto a screen in front of the driver. The image is generated by a Macintosh running LabVIEW. Simulated instrumentation (instead of a production cluster) was provided so that new display designs can be rapidly generated and tested. This paper addresses the requirements for prototyping software, the advantages and disadvantages of the packages available, and the UMTRI implementation of the software, and its incorporation into the driving simulator. WHAT TOPICS DOES THIS PAPER COVER? For the last three years, a team of engineers and scientists at UMTRI has been developing a family of low-cost driving simulators based on a network of Macintosh computers (MacAdam, Green, and Reed, 1993). For one of the simulators in the family, the Driver Interface Research Simulator, computergenerated instrumentation was provided instead of a cluster from an existing vehicle. This feature was incorporated into the simulator to facilitate the testing of a wide range of new technologies and interface designs. The development effort included selection of display hardware, a review of alternative rapid prototyping programs, and installation of the display system in a driving simulator. Lessons learned from this effort pertain to prototyping software, instrumentation design, and driving simulator development. This information should prove useful to those involved in instrumentation prototyping for human factors, safety, and marketing evaluations, as well as instrumentation engineers and developers of driving simulators. The remainder of this paper addresses five questions: 1. Why should instrumentation be prototyped? 2. What are the requirements for prototyping software for automotive displays? 3. What are the advantages and disadvantages of the packages available? 4. How were speedometer/tachometer clusters implemented in LabVIEW? 5. How was the computer-generated instrument cluster incorporated into the UMTRI Driver Interface Research Simulator? WHY SHOULD INSTRUMENTATION BE PROTOTYPED? In recent times, automotive product development has become increasingly focused on satisfying customer desires. Automotive manufacturers can no longer assume that customers will buy anything they produce. With this emphasis on quality and customer satisfaction, attention to human factors engineering/ergonomics has increased. Designing products that are safe and easy to use is very important. How, then, is ease of use achieved? In their seminal paper, Gould and Lewis (1985) identify three key principles--(1) early focus on users and tasks, (2) empirical measurement, and (3) iterative design. While these principles seem simple and obvious, designers and engineers do not think of them when asked to identify the steps in developing a system for users. (See Gould and Lewis, 1985 for the survey data supporting this claim.) These principles are viewed as accepted practice by computer user-interface designers. What do these principles mean? Early focus on users and tasks refers to collecting data on the physical and mental capabilities of the people for whom the system is being designed, identifying exactly what users will do, and, where possible, collecting data and directly observing people using current or similar applications. Empirical measurement refers to quanitifying the performance of users and the application, both existing and new. Measures may include task completion times, learning times, error counts, ratings of customer satisfaction, the number of requests for help in using an application, willingness to pay estimates, and many others. It is difficult to make something easy to use if ease of use cannot be measured. Hence, tools for developing interfaces must have features that allow for timing and recording user interaction. Iterative refers to the idea that no matter how much up-front planning occurs and how detailed the specifications, it is unlikely the product design will be good enough the first time. The quality of the design is proportional to the number of times through the design, test, redesign loop. For iterative design to occur, the first design must be tested very early in the product development cycle. This, in turn, requires products that can be readily fashioned into a form for user testing, and once testing is complete, be rapidly modified to incorporate feedback from testing. Thus, for iterative design to occur, rapid prototyping tools are required. Within the human factors community, HyperCard and SuperCard, both Macintosh applications, are the most popular choices for prototyping interactive control-panel interfaces (Green, Boreczky, and Kim, 1990). These applications have been used to prototype the TravTek driver interfaces (Carpenter, Fleischman, Dingus, Szczublewski, Krage, and Means, 1991), the interfaces developed by UMTRI (Green, Williams, Hoekstra, George, and Wen, 1993; Paelke and Green, 1993; Serafin, Wen, Paelke, and Green, 1993), for the ADVANCE project, and for the ongoing destination entry experiments in the FAST TRAC project. In addition to automotive work, SuperCard has been an important prototyping tool in the development of the space station. Toolbook is the most popular application for the Windows environment. WHAT ARE THE REQUIREMENTS FOR PROTOTYPING SOFTWARE FOR AUTOMOTIVE DISPLAYS? Displays to Be Simulated The displays to be simulated include speedometers, tachometers, fuel gauges, engine temperature gauges, oil pressure gauges, electrical system gauges, the vehicle and trip odometers, and ISO symbols for warnings. For the speedometer-tachometer cluster, all of the control panel elements of importance are displays, though most clusters have a trip reset button, whose operation (for studies of display legibility) is not critical to simulate. Other instrumentation (text-based warning displays) may also be present in new and high-line vehicles. Table 1 shows the display specifications for the speedometer/tachometer cluster. Except for the speedometer (which may be numeric), all of the displays are moving pointer, fixed scale indicators. From these specifications, the prototyping requirements shown in Table 2 emerge for moving pointer displays. The most important requirement is to be able to show circular and arc-type displays. Table 1. Display Specifications for the Speedometer/Tachometer Cluster. Moving pointer displays Scale type Scale range Scale markings Scale numbering Special markings Speedometer circular, horizontal, large arc (GM clusters), some odd shape scales (slope up, then horizontal) 0-120 typical, may go to 200 every 5, 2.5, 1 mi/hr, other combinations sometimes used 5s (5, 15, 15, ) or 10s (0, 10, 20, ) 0 to 5 or 10 mi/hr may not be shown* highlight 55, idle marks Tachometer circular 0-7000 typical may be every 1000, 500, or 250 usually 1000s red line Fuel gauge circular, arc, horizontal, vertical emptyfull 1/2s, 1/4s, may be low level mark lots of variety (E-F, E-1/2-F, 0-F, etc.) low fuel Engine temperature gauge circular, arc, horizontal, vertical 0 160 deg. F ends of normal shown cold to hot, or temperatures given ends of normal range Oil pressure circular, arc, horizontal, vertical 0-x ends of normal shown no consistent practice ends of normal range Electrical system circular, arc, horizontal, vertical 0-16 volts ends of normal shown, may be at odd values no consistent practice ends of normal range Table 2. Summary of Moving Pointer Display Requirements