• Federal Highway Administration >
• Publications >
• Research Publications >
• 95197 >
• Sec7.Cfm >
• Development of Human Factors Guidelines for Advanced Traveler Information Systems and Commercial Vehicle Operations: Comparable Systems Analysis

Development of Human Factors Guidelines for Advanced Traveler Information Systems and Commercial Vehicle Operations: Comparable Systems Analysis

CHAPTER 7. THE TravelPilot SYSTEM

BACKGROUND INFORMATION

GENERAL SYSTEM DESCRIPTION AND OBJECTIVES

USER INTERFACE

DESIGN GUIDELINES USED

LESSONS LEARNED

BACKGROUND INFORMATION

The in–vehicle component of the TravelPilot system evolved from an earlier ETAK product called Navigator. The Navigator was intended to provide information regarding the current position of a vehicle and a destination referenced to the road system. The TravelPilot then evolved as a product for commercial applications that featured route selection and two–way communications to a dispatch centerðCfunctions that were not available in the consumer–targeted Navigator system.

The Navigator relied solely on dead reckoning to determine the location of the vehicle. Inputs to the dead–reckoning algorithms include heading from a non–gimballed, solid–state (fluxgate) compass and two wheel rotation sensors, one on each non–driven wheel. Systems currently in the prototype stage also rely on dead reckoning, but can be augmented with GPS. In addition, the Navigator, like other ETAK positioning systems (including the TravelPilot) use proprietary map–matching techniques to compute the position of the vehicle.

In the case of TravelPilot, ETAK and Blaupunkt (a subsidiary of Bosch) provided the in–vehicle positioning and mapping system and the in–vehicle display to a system Integrator company (i.e., PRC). TravelPilot was a second–generation product for the after–market. It is primarily a Bosch product. Blaupunkt was primarily responsible for display design, including modifications between the Navigator system and the TravelPilot system. ETAK performed the initial design of the hardware and pilot production. Since then, many of the hardware details have been changed by Bosch. Currently, the device is produced entirely in Germany. The TravelPilot is currently in its fourth version.

TravelPilot by ETAK is currently installed and used in trucks of the Seattle Fire Department. This on–board display system provides a communications link between emergency response vehicles (e.g., fire engines) and the Seattle Fire Department Dispatch Center. Because of the similarities between the Navigator and the TravelPilot systems, the lessons learned developing the Navigator also apply to the TravelPilot system and are included here.

Top

GENERAL SYSTEM DESCRIPTION AND OBJECTIVES

The primary objective of this application of TravelPilot is to enhance the effectiveness of the Seattle Fire Department's emergency response capability. Specifically, many calls require immediate emergency response where every minute can make the difference between life and death. In the case of cardiac arrest, the goal is for emergency response to arrive 4 to 6 minutes after the call was placed. This requirement stresses the need to quickly dispatch the closest available vehicle to the scene of the accident. The dispatchers also have the responsibility of managing the vehicles so that they may respond to emergencies around the city. This becomes difficult when severe emergencies (large fires) demand resources from across the city. In this situation, dispatchers must balance the immediate needs associated with the emergency with the need to accommodate other calls throughout the city.

A secondary objective of this system is to support record keeping that spans many functions of the fire department. The record–keeping system automates report filing, tracks response time of emergency crews, and tracks hazardous waste. The hazardous waste tracking includes identifying permits and fees required, and maintaining a record of the type, amount, and location of the material so that dispatchers and drivers are warned of dangerous materials before they arrive at the scene.

The TravelPilot system links emergency dispatchers with emergency response vehicles. Thus, the system includes units located in each vehicle and units with which dispatchers control several response vehicles/crews. The in–vehicle system provides drivers with location information regarding the emergency site and enables them to send and receive messages from the emergency dispatchers. For example, when the computer–aided dispatch sends a vehicle to an emergency, the TravelPilot in–vehicle system automatically receives a message from the dispatch center specifying the address and location. This is displayed in the vehicle on a simple map display. When the driver leaves the station, the TravelPilot automatically notifies the dispatch center that the driver has left. Thus, the TravelPilot system provides drivers with location information and it enables them to communicate their location and status to dispatchers more easily than is possible with standard radio communication. In addition, the system aids dispatchers in monitoring the status of vehicles and in dispatching the appropriate type and quantity of emergency vehicles. Furthermore, the system helps identify specific vehicles based on their location and operational status. The ATIS functional characteristics that apply to TravelPilot are listed in table 6.

Table 6. Comparison of TravelPilot functions with those from ATIS/CVO systems.

Top

USER INTERFACE

General Description

Driver Interface

There is no auditory component to this system. A monochrome CRT located on the vehicle's dash is used to display the text–based menus and messages, and the maps showing the current position of the vehicle and the destination. The CRT is approximately 11.4 cm measured diagonally. The CRT is covered with a sheet of treated lexan. This sheet protects the occupant in the event the CRT is broken. It also is used to mitigate the effects of glare and reflection off the screen. The screen displays information in green characters and symbols on a black background.

The graphic display consists of a simplified road map of Seattle, centered on the driverð=s location and oriented in the direction of travel (i.e., heading up). The driver can select from a variety of map scales, including low–resolution views that display a large portion of the city and high–resolution views that display only a small part of the city. At the bottom of the map graphic is a text message sent by the dispatcher; generally, this message contains the address of the destination. At the top of the map display is a status line that provides information regarding map scale, straight–line direction to destination, distance to destination, direction of north, and unit status.

Buttons along each side of the CRT control the display and allow the driver to enter a menu system that guides the driver through a variety of screen configurations and message choices. Thus, the screen can contain text and graphics (a heading–up map with icons representing the current vehicle position and the destination). The functions of the buttons along the two sides of the display depend on the system state and change with menu selections. For instance, if the map is shown and the "MEN" button at the top of the left row of buttons is pressed, the display changes to show a text description of the standard system menu functions. Pressing this button again engages the "Select Destination" function. Other buttons also change function in a similar way as the driver engages different functions of the system.

Dispatcher Interface

Dispatchers interact with a different part of the system and their interface is substantially more complicated. The room that houses the dispatchers consists of five self–contained workstations that have identical capabilities. From each of these five workstations, dispatchers can receive telephone calls, enter information into the computer system, communicate with drivers, and monitor driver and vehicle status and position. The controls and displays that face the dispatcher include banks of buttons for manually alerting fire stations, multiple radio control channels for communicating directly with drivers, and a keyboard and two 33–cm displays for interacting with the computer–aided dispatch and automatic vehicle location functions. The dispatchersð= room also includes two large–screen monitors (approximately 122 cm diagonally) that display position information of emergency vehicles on a simplified map of Seattle.

Visual Information Display

Driver Information

The primary driver information display is the in–vehicle map. Their own vehicle position is fixed at a point in the middle of the screen laterally and approximately two–thirds of the way down the screen from the top edge (figure 54). Text, when displayed on the map, appears on the bottom of the screen.

The distance between the "own vehicle" symbol and the top edge of the screen defines the scale of the map display. For example, if the user selected an 8–km scale, then the distance between the vehicle symbol and the top edge of the screen would correspond to 8.0 km. If a 1.6–km scale were selected, then this distance would reflect 1.6 km. More detail is shown on the larger map scales (e.g., 0.8–km scale) than on the smaller scales (e.g., 16.1–km scale). When a destination is entered, the largest map scale (i.e., the scale showing the smallest geographic area) that allows both the destination and the own vehicle position to be displayed is automatically selected. There are some situations in which the destination may be farther away from the own vehicle than the scale would suggest. For example, the destination could be more than 8–km away when the 8–km scale is selected. This occurs when the destination is outside a circle centered on the own vehicle, but within the rectangular limits of the screen. The destination will normally be in the upper–left or upper–right corner of the screen in these situations.

As the scale of the map is changed, the level of detail also changes. At the largest scales, a small geographic area is displayed and all of the roads are depicted. As the scale is reduced, the amount of area depicted increases and the level of detail is reduced. At small scales, the road that the own vehicle is on may be removed from the map, particularly if the road is a "minor" one. The map is always displayed in a "heading–up" mode. There is no provision for presenting the map in a "north–up" orientation.

Not all of the roads are labeled. There is a provision for cycling through the streets, putting names on a different subset of the streets displayed on each cycle. (The "STR" button on the left side of the map display performs this function.) ETAK has developed a patented technique of dynamic labeling. This technique does not clip the labels at the screen edge, and does not allow labels to overwrite one another. In addition, the letters in the labels are always parallel to the street that they name, regardless of the orientation of the street. In addition the labels are always read left to right. This last constraint results in some labels being read from bottom to top, while others are read from top to bottom, depending on the orientation of the road on the screen.

To the left and right of the map display are short labels for the function buttons that are used to control the display. As mentioned earlier, these labels, and consequently the functions of the buttons, change as the operator selects different functions. The labels to the right of the map control the map scale and those to the left provide access to text screens containing menus of system functions. The buttons on the left also control the level of detail in the map display; street names can be removed to reduce display clutter. The status screen (figure 55), selected from one of the left buttons when the map is displayed, re–labels the function buttons with a short abbreviation of the text messages that the unit sends when the buttons are depressed in the "status" mode. For example, pressing a button on the left side marked "STA" sends a message to the dispatchers that the unit is available at the station. When activated, the "RSP" button on the right notifies the dispatchers that the unit is responding to the incident.

Destinations are typically received by dispatch and subsequently issued to one or more specific emergency vehicles, yet the system does allow the driver to select a destination when necessary. This procedure is based on text–based menu screens from which a driver chooses various categories of destinations. The driver may choose among the following options:

• Select Destination:

  • Street address.

  • Stored address.

  • Street name.

  • Intersection.

  
  
• Stored Locations:

  • The system allows the operator to maintain a set of stored locations, which can be an address or point on a map, that have been assigned a mnemonic name. Stored locations can be added, deleted, or sorted. These locations can be entered into the system as a street address, any location on the map, the current destination, a street name, or an intersection.

  • The system allows the operator to maintain a set of stored locations, which can be an address or point on a map, that have been assigned a mnemonic name. Stored locations can be added, deleted, or sorted. These locations can be entered into the system as a street address, any location on the map, the current destination, a street name, or an intersection.

Dispatcher Information

The information display for the dispatchers consists of two standard CRT's located at each workstation and two large monitors mounted at either end of the room. One CRT in each workstation displays the history of the incident and provides the dispatcher with a command line that can be used to enter information into the system (Data Entry CRT). The other CRT in each workstation displays the status of incidents and vehicles, and of the resources available to the dispatcher (Status CRT). The information on the Status CRT includes incidents that have been entered into the computer but are waiting to have emergency crews dispatched. The information also includes active incidents, which includes any incident for which crews have been dispatched. The display also shows the available vehicles and those that are classified as being on special status (in the shop for repair, out of service to conduct inspections or ceremonies and other special events).

When the dispatcher receives an emergency call, information concerning the incident is entered into the computer and simultaneously displayed on the Data Entry CRT by using the keyboard. This information includes an address and a type code that describes the type of accident or incident. For example, the type of code would differentiate between a house and an office building fire, and a heart attack. The system does not directly support the dispatcher in entering the type code; they must remember the appropriate code or find it in a separate paper–based index. After the incident has been entered into the computer, the CRT displaying the status of the vehicles and incidents adds it to the queue. In addition, the computer–aided dispatch system pairs an appropriate response (an appropriate set of vehicles selected from a location near the accident) with the incident. The information specifying the type and number of emergency vehicles appears as alphanumeric codes. The information appearing on the Status CRT appears on the status displays of all the dispatchers.

The two large monitors at each end of the room display map information concerning the location of the incident and the movement of emergency vehicles to the incident. This information can be manipulated by any of the dispatchers using the command line interface associated with the Data Entry CRT. For example, dispatchers can display parts of the map associated with each of the incidents. The operators can also specify the scale and detail included in the view (e.g., removing street names to reduce clutter).

Auditory Information Display

We are not aware of any auditory display associated with the in–vehicle portion of TravelPilot. There are conventional voice radio communication systems in the vehicles equipped with TravelPilot.

User Input (Controls)

There are six buttons arranged vertically on either side of the CRT. These buttons appear to be about 9.5 mm in diameter. The buttons are separated by about 12.7 mm (the size and separation are estimated, not measured).

The buttons along the side of the display are the primary controls available to the user. The physical characteristics of the button were described in the General Description section above. The function of each button is labeled by text on the screen adjacent to the button. Buttons that are not active have no label. Similarly, functions that do exist in the system but are not available from the current page are not displayed. If the user wants or needs to use this control, the system, or vehicle (if there is a motion interlock), must be put in the correct configuration. No system aids have been identified that assist the operator in configuring the system or vehicle.

Some features are not available when the vehicle is in motion. For example, a destination cannot be entered by the driver when the vehicle is in motion. Sensors attached to the wheel report vehicle motion. The driver need not put the transmission in "park" as is the case on another of the systems (e.g., TravTek) reviewed here. Other functions, such as being able to change the scale of the map, are available while in motion. There is an override that allows entry of a destination while in motion as part of the Navigator system. This is intended to allow a person other than the driver to enter a destination while in motion. We were not able to confirm whether this optional feature was provided in the systems used by the Seattle Fire Department. (This override feature is provided in response to user specifications.)

Communications Systems

Since the purpose of the emergency response dispatch system is to communicate information from the dispatchers to the drivers, a critical element of this system is the communication system. The communication requirements involve both information from the dispatchers to the drivers, and information from the drivers to the dispatchers. Specifically, drivers must know where and when they are to respond to incidents. Likewise, dispatchers must efficiently allocate a limited resource (emergency response vehicles and crews). This implies that dispatchers must be able to track the location and status of vehicles under their purview.

Traditionally, dispatchers and vehicles transferred vital information using voice communication over standard radio frequencies and hardwired alarms at the stations. The TravelPilot augments this communications channel by enabling the dispatch system to track the location and status of vehicles without voice communication over radio channels. An Automatic Vehicle Location (AVL) system monitors vehicle location and status, and transmits that information to the dispatch center automatically. This information is broadcast over an RF channel, received by a radio tower, and forwarded to the dispatch center by a telephone line. In a similar manner, information such as messages deploying vehicles to an incident is transferred from the dispatch center to a broadcasting tower through a dedicated telephone line. The broadcast center forwards this information to the vehicles through an RF transmission. The drivers and dispatchers also communicate by voice using a standard radio.

The voice communication takes place in two phases. In the first phase, dispatchers send a message that informs the crew of the general area of the incident and sends them on their journey. During the journey, a second message provides specific information regarding the exact location of the incident and detailed information regarding what the crew is to expect.

Cognitive Demands

Attentional Demands on Drivers

The cognitive demands associated with the TravelPilot system in the vehicles should not affect drivers because they are not meant to observe or manipulate the device while driving. However, the passenger could use the device to provide the driver with more precise location information and better directions when traveling in unfamiliar areas. In addition, the system can help reduce the workload associated with reporting the unitð=s status to the dispatcher. Conversely, the system also imposes significant cognitive demands on the vehicle operators that would not have occurred otherwise. For example, accessing the functions of the TravelPilot requires navigation through a structured menu system. This task may impose demands on long–term memory in terms of remembering the menu structure and the commands to invoke specific functions. The cognitive demands associated with learning system functions are illustrated by the training requirements. The vehicle crews participated in 8 hours of training before the system was fielded and then received another 2 hours of on–road training when the system was installed. In addition, efficient operation of the system requires that operators understand the factors that cause the location estimation ability of the device to become miscalibrated. Likewise, drivers must know how to re–calibrate the system. Otherwise, the system generates erroneous information for the vehicle operators and the dispatchers.

Cognitive Demands on Dispatchers

The system eliminates many error–prone and repetitive tasks for dispatchers (e.g., manually looking up address to determine appropriate station for response). In addition, the system provides dispatchers with the capability to manage the emergency vehicle in ways that were not possible before. For example, the system keeps an electronic log of all responses. This log includes response times and incident types. These data can be analyzed to obtain measures of system performance. In addition, the system is able to pair a set of vehicles with an incident type. For example, the system would automatically assign a different set of vehicles to a two–alarm fire, a minor brush fire, or a cardiac arrest report. Previously, the dispatcher had little support in matching incident type with an appropriate response. In addition to selecting the appropriate type or set of vehicles, the system also identifies specific vehicles for the response by using AVL to first determine if any emergency vehicles might be available and already near the scene of the incident. If no vehicles are in the immediate proximity of the incident, then the system identifies vehicles in nearby stations. In this way, the system minimizes the cognitive load on the dispatcher, while enabling the dispatcher to match the emergency response centersð= limited resources to the emergency response needs of the city.

Although the system reduces the cognitive load of the dispatcher in many ways, the new technology also introduces some new demands and potential problems for the dispatchers. For example, although the system automatically identifies sets of emergency response vehicles, the dispatcher has the ultimate responsibility for ensuring that the most appropriate team has been selected. Since the computer–aided dispatch system may not have access to the current state of all vehicles (drivers forget to place them out of service when they go to the shop for maintenance), the group of vehicles the system recommends may not actually be available. Similarly, in some circumstances, the algorithm used to select vehicles may not accurately choose the best set of vehicles. Specifically, if the system is not able to find a vehicle already in the vicinity of the incident, it selects a group of vehicles from the nearest station. However, the algorithm does not verify that those vehicles are near the station. For instance, the needed vehicle may be available, but it may be returning from a call across town. In this situation, the computer provides a poor selection of vehicles because it fails to select the closest available vehicles. Since the computer makes these types of mistakes, the system introduces a substantial cognitive load associated with monitoring the feasibility of the computer recommendations.

The introduction of the new system also changed the processing of aid requests and the interaction among the dispatchers. In the previous system, dispatchers used a card file of addresses to identify the appropriate station from which to dispatch vehicles. In the current system, the computer does this task automatically. While the previous system forced dispatchers to perform a tedious and somewhat time–consuming task, performing this task had a side benefit of increasing the awareness of dispatchers of the other calls that the center had received. When an incident was reported, this information quickly became shared knowledge; and when an incident generated multiple calls, the dispatchers were able to identify multiple aid requests associated with the same incident. Now that the dispatchers do not rely on the same common resource (the card file of addresses), multiple reports of the same incident may be entered into the system. This results in added workload as the multiple entries must be filtered so that dispatchers do not mistakenly send multiple responses to a single incident.

More generally, introducing the computer–aided dispatch generates additional cognitive demands associated with simply interacting with the system. Often the command line interface can frustrate dispatchers because it requires memory of precise syntax. For infrequently used commands, this becomes problematic. These demands may reduce dispatcher efficiency, especially when workload demands are already high and the added burden of remembering and entering the precise data or syntax can severely degrade dispatcher performance. In addition, the barrier that the command line interface imposes can inhibit the users so that they fail to use the system to its full potential. For example, the dispatch center has two monitors at either end of the room. These monitors display a city map and provide an overview of the situation by displaying the real–time location of the emergency response vehicles and the incident. The operators do not use this map, in part, because the command line interface makes changing scales and views awkward. Thus, the characteristics of the computer interface may reduce dispatcher efficiency and inhibit their use of the full capability of the system.

Top

DESIGN GUIDELINES USED

Human Factors Design Guidelines

Development of the Navigator began in 1983 and required more than 2 years to bring to market. Roughly 2,000 Navigator systems were sold as after–market equipment through an ETAK dealer network in California. The size of the design team ranged between 15 to 35 people. The members of the Navigator design team had backgrounds in computer science, engineering, navigation, and cartography. Human factors guidelines were consulted in the development of the Navigator. The areas where the input was useful are exemplified by the selection of font size and reach envelopes for installation position guidelines. Unfortunately, the titles of the specific human factors references and guidelines were not available.

The interview with the principal engineer from the system integrator, PRC, suggested that their group has little knowledge of human factors or ergonomics. However, for many of their objectives, they feel no need for human factors guidelines. Much of their concern focuses on a systems perspective that addresses information requirements and system architecture specifications. PRC focuses on the content of displays and not their form; they identify what to display, not how to display it. Conversely, their role in system development spans the spectrum from specifying the size and location of information on the screen to training the operators after the system is installed. They do not currently employ human factors specialists or use any human factors guidelines.

This lack of understanding of the scope of human factors is commonplace in the engineering community. Clearly, human factors practitioners contribute to a systems perspective, information requirements, the content of screens, and operator training.

Other Guidelines

The Navigator was evaluated by an outside agency (Failure Analysis Associates, Inc.). This evaluation focused primarily on crashworthiness and liability issues, rather than usability testing or Human Factors issues such as glance frequency and duration.

A variety of standards and guidelines were used in developing the Navigator. Standards were used to determine the location of the device within the vehicles. Society of Automotive Engineers (SAE) standards were mentioned as being used specifically. Examples of areas in which standards were used to guide the design include ruggedization and moisture resistance. The design team also relied on standards concerning crashworthiness. Standards and conventions from cartography were examined in the development of the dynamic labeling algorithm. Notably, the decision to position labels parallel to roads to minimize the difficulty of associating a name with a road, rather than keeping all text horizontal to improve readability, was decided based on the cartographic literature.

More generally, the process used for system development does not seem to rely on any formal guidelines developed by any discipline. The single exception lies in the use of DOD engineering benchmarks for architecture and performance standards. In this instance, these standards were employed as a checklist to ensure product quality, rather than a tool that guides the design process. PRC employs methods and techniques that have been developed and tailored to the needs of emergency dispatcher centers. The methods and techniques focus on identifying user needs and then constructing a system to meet those needs. They elicit user needs through an intensive process of interviews with all potential users, including managers, drivers, dispatchers, and administrators. PRC uses people with domain expertise (e.g., experienced dispatchers and former police officers) and technical expertise (e.g., system engineering and computer science) to bridge the gap between defining user requirements, conceptual development, and operational implementation.

In addition to the methods that PRC has developed to gather and process information regarding user needs, they use several other tools to guide the software development process. Since each emergency dispatch installation is unique they do not install ready–made systems, rather they provide custom–designed solutions to the client's problems. However, since they install many similar systems, they are able to develop custom–designed software from a collection of relatively generic modules that can be tailored to specific needs. To aid in this process, PRC uses a variety of Computer–Aided Software Engineering (CASE) tools. These tools can aid in the understanding of complex workflow and data modeling problems.

Other Sources of Design Guidance

ETAK has, almost since its inception, required all staff working on vehicle navigation to have a device in their personal vehicle and to keep logs of the use of the system, particularly errors and anomalies. All staff members are required to personally install the system in their own vehicle. The result is that they have lots of documented on–the–road mileage using their systems in a wide variety of vehicles.

ETAK has performed evaluations of concepts and design options using non–staff members. In particular, they have brought in subjects who were not experienced with the use of navigation devices and tasked them to drive to various locations. Subjective data were normally obtained. In some instances, they placed video cameras into cars to monitor the amount of time the driver spent looking away from the road. The purpose was to measure the time drivers looked at the display instead of the road (e.g., at stop lights or while in stop–and–go traffic), and to see if that amount of time and pattern were subjectively acceptable to drivers. No results of this effort are available.

ETAK reportedly tested novice users from various categories of the driving population. Age and gender were two of the factors used to stratify subjects.

Failure Analysis Associates, Inc., analyzed the Owner's Manual and the User's Manual prepared for the Navigator. The emphasis was on the adequacy of the warning labels.

Effectiveness of Human Factors Guidelines Used By System Designers

Human factors guidelines were useful in the interface aspects of the design. Selection of font size is an example. Human factors guidelines were not available (or were not found) on which to base other design decisions. Examples reported include:

• Map Orientation (heading up vs. north up).
• Map Presentation vs. "Guidance" Information Displays (e.g., turn arrows).
• Dynamic Map Scaling.
• Dynamic Labeling Techniques.
• Adaptive Displays.
• Fail–Safe Design.

The human factors literature used by ETAK in the development of the Navigator was inadequate to guide design decisions regarding map display features (e.g., area fills) that facilitate "situational awareness" or enhance "spatial awareness." As an example, no information was reportedly found that indicated whether coding notable regions, such as a body of water, in addition to the road network, would result in easier navigation to a destination.

Top

LESSONS LEARNED

[TP 01] HFE GUIDELINES USED FOR FONT SIZE

• Human Factors Engineering (HFE) guidelines were consulted in the development of the Navigator, particularly for the selection of font size, and reach envelopes for installation position guidelines. The titles of the specific human factors references and guidelines were not available.

• Engineers/designers used existing human factors guidelines only for font size and reach envelope recommendations in the design of the interface.

[TP 02] HUMAN FACTORS IS NOT RECOGNIZED BY INDUSTRY MANAGERS

• The interview with the principal engineer from PRC (the system developer/integrator for TravelPilot) suggests that their group has little knowledge of, or perceived need for, human factors or ergonomics.

[TP 03] THE SYSTEM EVALUATION CRITERIA EXCLUDED HUMAN FACTORS

• The Navigator was evaluated by an outside agency that focused on crashworthiness and liability issues, rather than usability testing or human factors issues.

[TP 04] SAE STANDARDS WERE USED IN THE DESIGN PROCESS

• A variety of standards and guidelines were used in developing the Navigator. Society of Automotive Engineers (SAE) standards were used to determine the location of the device within the vehicles, and for criteria for ruggedization and moisture resistance. The design team also used standards on crashworthiness. Standards and conventions from cartography were used in the development of the dynamic labeling algorithm.

• Engineering design guidelines other than human factors were integrated into the design process.

[TP 05] AN ENGINEERING APPROACH TO SYSTEM DEVELOPMENT WAS USED

• The process used for development of the TravelPilot system did not rely on any formal guidelines other than SAE and DOD engineering benchmarks for architecture and performance standards.

• The TravelPilot developer relied on people who have domain expertise (e.g., experienced dispatchers, former police officers) and technical expertise (e.g., system engineering, computer science) to bridge the gap between defining user requirements, conceptual development, and operational implementation.

[TP 06] CASE DESIGN TOOLS WERE USEFUL

• A variety of Computer-Aided Software Engineering (CASE) tools were used. These tools can help to understand complex workflow and data modeling problems.

[TP 07] IN-HOUSE STAFF USABILITY TESTING CAN PRODUCE VALUABLE INFORMATION

• ETAK has historically required all staff working on vehicle navigation to install a device in their own personal vehicle and to keep logs of the use of the system, particularly errors and anomalies.

• This policy fosters personal experience with the technology developed and can lead to early design improvements.

[TP 08] INFORMAL DRIVER STUDIES CAN PROVIDE INSIGHTS INTO DESIGN ISSUES

• ETAK has performed evaluations of navigation concepts and design options using non-staff members. They measured the time drivers spent looking away from the road, when they looked at the display instead of the road (e.g., at stop lights or while in stop-and-go traffic), and to see if that amount of time and pattern were subjectively acceptable to drivers.

• Effort was placed on methods for "knowing the user" and their driving behaviors that seemed to lead to a better design early in the development process.

[TP 09] EVALUATIONS OF MANUALS NOT CENTERED ON USABILITY

• An evaluation of the Owner's Manual and the User's Manual was performed that focused on the adequacy of the warning labels rather than on the usability or instructional value of the manuals.

[TP 10] MANY DESIGN FEATURES AND CRITERIA ARE PRIMARILY BASED ON COST

• Cost is the biggest constraint for the consumer versions of navigation systems. In current dollars, ETAK believes that there is a market below the $1000 level. However, they could not reach this level with the technology in the Navigator. Cost may not be as big a constraint in the CVO product line where companies, rather than individuals, are the targeted buyers and can see fleet-wide cost benefits.

[TP 11] LIMITED EFFECTIVENESS OF HFE GUIDELINES PERCEIVED

• Human factors guidelines were used only in certain aspects of the design, such as character size. Human factors guidelines were not available (found) on which to base many of the other design decisions, such as map orientation (heading up vs. north up); map presentation vs. "guidance" information displays (e.g., turn arrows); dynamic map scaling; dynamic labeling techniques; adaptive displays; and fail-safe design.

• Designers believed that existing human factors guidelines had limited effectiveness in vehicle system applications.

[TP 12] HUMAN FACTORS LITERATURE HAS MANY LIMITATIONS

• The human factors literature used by ETAK in the development of the Navigator was inadequate to guide design decisions regarding map display features that facilitate "situational awareness" or enhance "spatial awareness." As an example, no information was reportedly found that indicated whether coding notable regions, such as a body of water, in addition to the road network, would result in easier navigation to a destination.

• Designers believed that existing human factors guidelines had limited effectiveness in vehicle system applications.

[TP 13] MAP ORIENTATION PREFERRED HEADING UP

• ETAK has a strong, general preference for maps to be displayed in heading-up mode. This design decision was made based on in-house experience with prototypes, and after having novice users test prototypes with both heading-up and north-up options. No formal experimentation was performed.

• Map-based displays should be presented in a heading-up mode unless drivers choose another option.

[TP 14] SIZE OF MAP SCALES CAN VARY GREATLY

• Route guidance provided by TravelPilot is limited to showing the position of the driven vehicle in relation to the road network. At some scales, the road that the vehicle is on may not be displayed on the same screen as the destination.

• ETAK reports that map scales that do not depict the destination simultaneously with the vehicle position are acceptable to the drivers, but scale selection should be chosen by the driver.

[TP 15] ACCURACY OF VEHICLE LOCATION IS CRITICAL TO USER ACCEPTANCE

• TravelPilot used dead reckoning with a magnetic compass, and appeared to be quite susceptible to problems of calibration. Problems with calibration can mislead the dispatchers as to the vehicle location and the problems make the navigation information relatively useless. The Global Positioning System (GPS) circumvents many of the problems that plague the dead-reckoning system.

• Accurate navigation information must be presented to drivers to instill trust in the in-vehicle system.

[TP 16] ETA DATA NEEDED IN CVO APPLICATIONS

• The dispatcher's objective is to get a vehicle to the site as rapidly as possible and avoid sending more units than are needed. Dispatchers sometimes dispatch multiple emergency vehicles simultaneously to the scene, originating from opposite sides of the destination. Once it becomes evident as to which vehicle will be on the scene first, the one that would arrive later is called off. Dispatchers need accurate Estimated Time of Arrival (ETA) data to support effective decisions. Real-time traffic and vehicle information is an important element needed to achieve accurate ETA.

• Accurate ETA based on real-time traffic and vehicle information should be made available to emergency vehicle dispatchers.

[TP 17] DATA STORAGE DIFFICULTIES CAN AFFECT SYSTEM DESIGN

• The original data media (1983-85) used by ETAK for navigation systems was audio cassette tape. This was the only media that could withstand the heat and vibration of the automotive environment at that time. The main problem with audio tape was that it took a long time to access the data (45 seconds). In the mid 1980's, Winchester drives (hard disks) began to be rugged enough for use in vehicles. The switch to hard disks eliminated the problems associated with using a sequential access device, which resulted in speed improvements. Also, in the mid-1980's, compact discs (CD's) first began to show promise for use in holding digital applications other than music in automobiles. Access time is still an issue with the CD's, particularly since the amount of data on a CD can be around 500 megabytes.

• The system response time can be reduced by limitations in the data storage medium and technology.

[TP 18] MAP DATABASE LIBRARIES NEED TO BE UP-TO-DATE

• ETAK has performed field data capture for the 40 largest cities in the United States that provide high levels of detail (e.g., one-way streets, center islands) along with the layout of the road network.

• Future ATIS system designs also should account for database update procedures and cost.

[TP 19] MAP DATABASE SIZE IMPLICATIONS

• ETAK provides the map database used in the TravelPilot. The database is contained on a compact disc (CD). Current storage capacity is adequate for all of the roadways in a region, but addition of other information (e.g., restaurants, speed limits, etc.) can reduce the amount of space available for the roadways.

• To address the size limitation, the CD in the ATIS system, as in the TravelPilot system, should be easily exchanged by the driver. This allows use of the vehicle positioning and map display capabilities in other locales. However, the data-link capabilities require significant, perhaps unique, infrastructure that may not be available in all areas. These issues are being addressed in the Intelligent Transportation Systems (ITS) national architecture development by FHWA.

[TP 20] VEHICLE LOCATION ACCURACY IS CRITICAL

• ETAK believes that the requirement for maintaining an accurate position without realigning the system is more strenuous in the case of ATIS consumer devices than in CVO systems. Their rationale is that commercial users are more likely to monitor the performance of the system and take care to remove small errors frequently. Consumers are likely to let errors accumulate during their routine commuting and will be put-off when they try to use the system on the weekend to navigate to an unfamiliar destination and see an erroneous position indicated.

• Vehicle location discrepancies and system errors may be less tolerated in passenger vehicles than in commercial vehicles.

[TP 21] MAGNETIC DISTURBANCES CAN IMPACT VEHICLE LOCATION ACCURACY

• The position of the vehicle can be corrupted by magnetic disturbances in TravelPilot. If a magnet is brought into close proximity to the compass, the system needs to be re-initialized. An example of a situation where a magnet would be close to the car occurs when a car is taken in for service. The "cones" with numbers on them that many service shops use to identify cars are attached on the hood or top of vehicles with magnets. These are strong enough to disrupt the system. Also, some of the fender aprons used to protect the paint from scratches when a mechanic is working on the engine are held in place magnetically.

• ATIS system users should be made aware of circumstances that affect system accuracy and should provide feedback as to when accuracy has been degraded.

[TP 22] MESSAGE-RECEIVED FEEDBACK IS DESIRED

• Originally drivers were required to send messages to dispatchers regarding their position or status, and TravelPilot provided the driver with no feedback as to whether the dispatcher received the information. This lack of feedback can lead to serious misunderstandings because, with unreliable communication channels, it is likely that a message occasionally will be lost. Currently, the system has been modified so that when a dispatcher reads a message, feedback will be provided notifying the driver that the message was received.

• Feedback regarding whether a message has been received needs to be provided to the sender (i.e., driver or dispatcher).

[TP 23] VEHICLE IDENTIFICATION SEQUENCE CAN BE CONFUSING

• In the original TravelPilot system, the emergency response vehicles were ordered and presented to the dispatchers alphabetically, according to their alphanumeric code. This led to substantial confusion when dispatchers needed to coordinate the arrival of the vehicles to the incident. To solve this problem, the system was changed so that the vehicles were ordered by proximity to destination, with the lead vehicle first.

• Dispatched vehicles' identification sequences should be presented to dispatchers in order of proximity (e.g., lead vehicle first) rather than alphabetically.

[TP 24] CUSTOMER-DRIVEN APPROACH TO ATIS SYSTEM DESIGN IS COMMON

• A common approach to the development and continued market success of an engineering product is to promote close ties with the customer. This approach tends to replace human factors engineering with customer-to-design engineer communication regarding user-requirements and prototype evaluation.

[TP 25] TRAINING REQUIREMENTS NEED TO BE DIRECTLY ADDRESSED

• The TravelPilot training program may have been insufficient. Users received an initial 8 hours of training and a written technical description of the system. The fire department felt that the 8 hours of training were not sufficient and they developed a 2-hour on-road training session to better familiarize the drivers with the system. In addition, they rewrote the technical description of the system in a way that was more comprehensible to the drivers. Rewriting the manual and adding a new training session illustrates the relatively large investment needed to teach people how to use this equipment.

• Instructional materials and training development need to be included in the ATIS/CVO system development process.

Top

FHWA-RD-95-197