Skip to contentUnited States Department of Transportation - Federal Highway Administration FHWA Home
Research Home
Report
This report is an archived publication and may contain dated technical, contact, and link information
Publication Number: FHWA-RD-95-176
Date: November 1996

Development of Human Factors Guidelines for Advanced Traveler Information Systems and Commercial Vehicle Operations: Task Analysis of ATIS/CVO Functions

 

CHAPTER 5. DISCUSSION AND RECOMMENDATIONS

 

DISCUSSION

RECOMMENDATIONS CONCERNING HUMAN FACTORS DESIGN GUIDELINES

RECOMMENDATIONS CONCERNING EMPIRICAL RESEARCH

 

DISCUSSION

The scenario task characterization process involved the systematic integration of task analysis information into operational sequence diagrams (OSDs). This process, as could be anticipated (e.g., Meister, 1985, p. 68; Baker, Johnson, Malone, & Malone, 1979), focused the attention of the task analysis participants on ATIS/CVO–related design issues. Among the most prominent of these were issues related to: (1) adverse user responses to ATIS/CVO features, and (2) molecular and molar system architecture. Considerations of these are followed by a general discussion of the identified issues and recommendations for addressing them in future work.

User Responses to ATIS/CVO Features

The task analysis process repeatedly suggested opportunities for users to respond to ATIS/CVO in ways that could have adverse consequences. Most prominent among these were opportunities for users to overrely on the system functions:

  • Blindly rely on/follow system recommendations.
  • Experience transitioning difficulties when the system is inadequate for problems at hand.

The first of these overreliance problems, it is important to note, has long been known to happen with the introduction of work–aiding automation. Kletz (1985), illustrating a simple example, considers the result of providing an automated flow–cutoff valve. Pertinently, this addition was made after a tank overflow incident when an inattentive worker failed to observe that an indicator had reached "full." This intuitively attractive automation initially appeared to provide for reducing the probability of an overfill (as the system would serve as a backup for the worker). Workers, however, began to divert their attention to other matters as they relied on the automated cutoff.

More relevant blind–following of automation can be found in other domains, particularly commercial aviation (e.g., Bittner, Kantowitz, & Bramwell, 1993). Based in part on these examples of "blind–following," the potential for their occurrence with ATIS/CVO appears certain (unless otherwise addressed). In Scenario P6 (appendix D), for example, the task analysis team observed the possibility of a driver blindly following routes selected by IRANS into high–crime areas of an unfamiliar city. Blind–following is one user response that points toward careful considerations of the appropriate way to automate functions (cf., Kantowitz, 1993).

Transitioning difficulties, the second of the overreliance problems, can be as problematical as the first. Bittner, Kantowitz, and Bramwell (1993), again in the context of automated cockpits, point out numbers of incidents where the transition from automation to manual task accomplishment proved difficult. Among the difficulties noted were problems of even deciding when to stop relying on dysfunctional automation. Analogous ATIS/CVO failures, it is noteworthy, were not specifically addressed during the present task analysis because of the astronomical numbers of modes of possible occurrence. Other transitioning difficulties occurred when pilots were required to become more involved in the control task after a long period where automation carried the decision–making load (i.e., transitioning from low workload to high workload). Alertness entering a city after driving a long open–road stretch using IRANS could, analogously, be more of a problem than currently is the case (given IRANS reductions in the navigational workload). These transitioning difficulties also require early consideration in future ATIS/CVO developments because of their profound safety implications. Fortunately, there is existing guidance for such user–centered considerations (e.g., Kantowitz, 1993).

System Architecture Issues

The task analysis process repeatedly revealed both molecular and molar architecture issues. Most prominently among the molecular issues were those concerning the nature of interfaces and coordination between ATIS/CVO elements. Regarding the interface issue, some task analysts (based in part on system proposals) could envision interfaces with linear key–entry input approaches. Others, in contrast, could envision more graphical trackball or analogous entry methods. Regardless of the arguments for and against one entry method versus another, analysts agreed that:

  • Different interface natures would call on different user capabilities.
  • The nature of interfaces should be common across all of the elements of ATIS/CVO.

Clearly, resolving the nature of the ATIS/CVO interfaces is a major issue for their successful implementation and remains to be addressed in future work. The results of the present task analysis efforts should prove useful in future work aimed at resolving the interface issue, as they were conducted at the level just above where the interface nature is specified.

The task analysis process repeatedly identified a second molecular issue regarding the coordination between ATIS/CVO elements. Illustrating this, for example, are the transitions between IMSIS and IRANS in Scenario P6 (appendix D). If, as could be the case, the information from IMSIS (e.g., potential places to spend the night) could not readily be transferred to IRANS, then the driver would have to externally record the relevant information and reenter it into IRANS (for assistance in navigating). This, of course, would require a good deal of driver effort and thereby severely reduce the utility of IMSIS and IRANS. However, the results of the present task analysis efforts should also prove useful in future work aimed at ensuring coordination across system interfaces. The transitions between ATIS/CVO elements (e.g., IMSIS to IRANS) are clearly seen in the scenario descriptions (OSDs) and could be used to identify information that should be passed between system components.

Most prominent of the molar design issues were those concerning overall system architecture. First, much as it was clear that the nature of interfaces should be common across all of the elements of ATIS/CVO, it was also clear that the overall architecture needs to be consistent. Changes in architecture, albeit with nominally consistent interfaces, can be expected to result in subtle differences in the way that users must interact with separate system elements. From cockpit automation experiences, such subtleties have been found to lead to hazardous conditions (particularly if not consistent across differing vehicle models used by an operator) Bittner, Kantowitz, & Bramwell, 1993. Second, in addition to overall system consistency, it was also clear that there is a requirement for overall hierarchical information resolution/integration across the various components. For example, to begin to appreciate this second requirement, consider the relatively simple problems of overlapping information regarding an approaching intersection:

  • ISIS provides sign–notification information (e.g., cross–street name).
  • IRANS provides present location information (i.e., conflicting cross–street name) from a different data base.

Compounding this, moreover, may be a further cacophony of additional overlapping and related intersection information; for example:

\
  • IVSAWS warning of a construction area and an accident at the construction site.
  • IRANS providing information regarding an associated traffic backup (resulting from the accident).
  • IVSAWS alerting of an on–coming emergency vehicle (ambulance in response to accident injuries).

Clearly, handling this bulk of information in a way that will not overwhelm drivers is a challenging issue. Consequently, not broadly addressing this second issue could, like the first, result in a significant reduction in the utility of ATIS/CVO. These two molar architecture issues together have an impact on the molecular issues discussed earlier and should be considered as part of future ATIS/CVO developmental efforts.

Conclusions

The scenario task characterization process, as seen above, has led to the identification of a number of significant issues affecting the future success of ATIS/CVO. Among these were issues regarding adverse user responses to ATIS/CVO features and molecular and molar system architecture. Although not commonly documented, such issue identification results from the task characterization processes were expected (Meister, 1985; Baker, Johnson, Malone, & Malone, 1979). Indeed, the task characterization team strove to capture these significant issues as they emerged, in keeping with the unique system requirements concerns (e.g., Bittner, Kantowitz, & Bramwell, 1993).

Efforts were also made during task analysis team deliberations to capture recommendations for addressing issues as they emerged. For example, after delineating the issue of information coordination between ATIS/CVO elements, further considerations were captured on how transitions (apparent in the OSDs) could be employed to identify information requiring such coordination.

 

Top

 

RECOMMENDATIONS CONCERNING HUMAN FACTORS DESIGN GUIDELINES

The results of the task analysis highlighted several areas that should be addressed in the human factors design guidelines for ATIS. These were gleaned primarily from the summary analysis that was done of all the task analyses. They are as follows:

  • Access to functions and features should be based on an assessment of the combined workload requirements of each feature and the likely driving conditions that would encourage use of the function.

  • Both the information requested of the system and the display provided when making system recommendations should be compatible with other demands on the driver at the time, even though this might mean that system recommendations would be less than optimal.

  • Use of preference profiles for individuals and situations should be encouraged to reduce setup time for the driver.

  • Preferences set by the driver should be designed to require drivers to select a preference rather than exclude a preference. This would reduce the number of features, notifications, and warnings presented to the driver.

  • Setup features that involve entry of specific information by the driver, such as street names and addresses, should include checking functions that will assist the driver in identifying errors and correcting the entry. Since the driver may or may not have precise information available when initiating the system, this checking function should provide logical alternatives to an error, when available.

  • Setup features for IRANS should include the ability to enter and retain short lists of destinations and routes frequently used (e.g., work, home, etc.).

  • Destination selection should include the possibility of the driver using successive approximation approaches to destination selection. Such an approach would allow the driver to receive guidance to a general area (e.g., a downtown district) and then to use IMSIS broadcast services or the services directory to select a final destination.

  • Route review and approval requirements should be supported by a display that depicts the whole or large parts of the recommended route on a single display.

  • Alternative methods for entering destination information (e.g., bar coding of business cards, cross–referenced with telephone numbers and pre– loaded smart cards) other than direct entry by the driver should be supported and encouraged.

  • A standard taxonomy of IMSIS categories should be developed and used throughout the data bases.

  • System design should include positive indications to the driver that a change of function (e.g., shift from planning to route guidance, or change in destination routing) has occurred following driver actions that initiate such a change.

  • Provisions should be made in the system to allow the driver to not only review a proposed route, but to review the assumptions made by the system to establish that route.

 

Top

 

RECOMMENDATIONS CONCERNING EMPIRICAL RESEARCH

The task analysis helped identify areas where insufficient information is available on the way that drivers are likely to perform using ATIS/CVO. The following issues are considered important areas for future research concerning ATIS/CVO use:

  • The effect of ATIS/CVO route guidance instructions on maintenance of driver vigilance for obstacles and recognition of inappropriate instructions (e.g., directed the wrong way on a one–way street) is unknown.

  • Navigation strategies used for ATIS route guidance that focus on the destination are different than those normally used by drivers who tend to focus on the successive process of approaching a destination by using a series of recognizable waypoints. How the prolonged use of destination–focused approaches will affect driver reliance, comfort, and use of ATIS/CVO needs to be explored both in terms of driver acceptance and driver stress.

  • Under some conditions, ATIS/CVO requirements are likely to exceed the availability of the driver to do them (e.g., a driver is unable to make a required turn due to traffic). Since efficient use of ATIS will depend on an understanding of the best strategies for recovering from this type of event, it is important to understand how drivers deal with such events now and how ATIS might be used to improve such strategies.

  • ATIS/CVO devices may require significant visual attention, leading drivers to attend to in–vehicle sources of information at the expense of environmental information. The time and attention demands of various ATIS tasks must be quantified relative to that required for driving. The task analysis illustrated that little is known about the time and attention requirements of ATIS devices.

 

Top

 

FHWA-RD-95-176

 

Previous | Table of Contents | Next

ResearchFHWA
FHWA
United States Department of Transportation - Federal Highway Administration