• Federal Highway Administration >
• Publications >
• Research Publications >
• 95176 >
• Sec2.Cfm >
• Development of Human Factors Guidelines for Advanced Traveler Information Systems and Commercial Vehicle Operations: Task Analysis of ATIS/CVO Functions

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

CHAPTER 2. TASK ANALYSIS PROCEDURE

The task analysis undertaken in conjunction with Task E followed a relatively classical task analysis technique. Since a task analysis can be performed in a multitude of ways, the specific procedure used represented a compromise between utilizing specific techniques that might have been of greater value in the determination of specific human factors issues and the more readily acceptable techniques having a greater application to the range of issues that must be considered in this project. The approach used included the following:

• Develop a hierarchical listing of tasks associated with driving and ATIS functions.
• Develop descriptions of each task that characterize the task according to issues of potential importance to human factors design guidelines.
• Identify and characterize the driving tasks of importance to use of ATIS.
• Select from among all ATIS functions those that appear to be most representative of normal uses that will be made of ATIS.
• Select scenarios that represent potential "real–world" use of the most significant ATIS functions.

HEIRARCHIAL TASK DESCRIPTION

OPERATIONAL SEQUENCE DIAGRAM (OSD)

TASK CHARACTERIZATION

DRIVING FUNCTIONS

FUNCTION SELECTION

SCENARIO SELECTION

HIERARCHICAL TASK DESCRIPTION

One of the first things that needs to be done in a task analysis is to decide which tasks will be considered as part of the analysis. The basis for task descriptions was the information gathered during earlier tasks in the project and the information–collection activities undertaken during this task. Before developing a task list, the various functions associated with driving and ATIS were identified. Since Task C had identified the tasks associated with ATIS in both private and commercial operations, the results of this task were used to identify ATIS functions. Sources of information on driving functions and tasks were gathered primarily from previous driving task analyses (McKnight & Adams, 1970), to which functions were added for CVO operations based on discussions with people familiar with such operations.

Once functions were identified, the tasks necessary to carry out each function were developed. Tasks required to accomplish functional goals can be described at varying levels of detail. In order to keep the analysis within reasonable bounds, several rules were used to decide when the tasks had been broken down to an adequate level of detail. These rules were:

• Functions would be described by as few tasks as could reasonably achieve the intended purpose of the function.

• Tasks would be divided into subtasks and task activities only to the level necessary to describe the basic task type required, human limitations involved, and significant important issues related to the task.

• Tasks would not be divided below the level where task allocation between human and machine is likely to depend on a specific engineering design or a specific phase of IVHS development.

By using these rules, the expectation was to develop a task list and subsequent task characterization. Both the task list and task characterization would then focus on human factors design issues facing the development of the ATIS, thus possibly avoiding the inherent problems associated with developing detailed task descriptions that would reflect the technology currently available or expand the analysis to the broad range of future possibilities that might be afforded by future technologies.

Once the tasks, subtasks, and task activities were identified for each function, they were arranged in a hierarchical fashion. Figure 1 illustrates the hierarchy for the tasks involved in the IRANS function of pre–drive route and destination selection.

The hierarchical task list reflects the minimum detail (in terms of tasks, subtasks, and activities) necessary to adequately describe the performance of a function. Where possible, the sequence of tasks is maintained. In many cases, however, the order in which specific tasks would be performed is dependent entirely on system design. Therefore, while the order of task presentation may indicate temporal relationships, no attempt should be made to interpret the information presented for a specific function based solely on the order of the presentation. Appendix C contains this hierarchical task listing, which is organized around the driving functions presented at the start of the appendix. For each driving function, the appendix includes a complete list of its associated tasks arranged in an outline format:

• The first level represents tasks (e.g., 1.3 Auxiliary Systems).
• The second level represents subtasks (e.g., 1.3.1. Climate Control).
• Subsequent levels represent major task activities (e.g., 1.3.1.1 Set climate controls as necessary). Each driving function is also accompanied by a figure that shows the key tasks, the associated goals, and the function they serve.

After the hierarchical task list was developed for each function, the list was reviewed by a panel of human factors and CVO experts to determine if the tasks sufficiently described the tasks necessary for successful performance of a function in order to proceed with the detailed characterization of each task. The results of the panel discussion are reflected in the hierarchical task listings presented in appendix C and the detailed task analysis in appendix D.

Top

OPERATIONAL SEQUENCE DIAGRAM (OSD)

Following the development of hierarchical task descriptions for each of the functions, operational sequence diagrams (OSDs) were developed for each scenario. The OSD provides a graphical method of task analysis aimed at "describ[ing] clearly the functions of the system integrating all potential hardware requirements" (Walley & Shepherd, 1992, 18ff.). Using standardized operation symbols (figure 2), the OSD provides a way to plot the sequential flow

of information, decisions, and actions during the performance of a task or sequence of tasks (Meister, 1985). In addition to characterizing task performance, OSDs are useful (Baker, Johnson, Malone, & Malone, 1979) for:

• Evaluating human–machine interfaces and function allocations.
• Identifying critical task situations.
• Identifying overload and underload situations.
• Identifying critical decision/action points.
• Developing workspace design and evaluation criteria.
• Identifying points of high error likelihood.
• Developing operational procedures.

Of the breadth of OSD applications, our intent in using them was: (1) to characterize the interactions between ATIS and CVO features of IVHS, and (2) to identify critical situations, decision/action points, and other aspects that should be examined further as ATIS/CVO systems are developed. Characterizations of the interactions between system features, it should be noted, are integral to the later Detailed Task Analysis (appendix D). More specifically, each scenario analyzed in appendix D includes an OSD that illustrates driver interaction with different subsystems (IRANS, IMSIS, ISIS, IVSAWS, and CVO–specific) and the external environment. Broad considerations related to the critical feature–interactions can be found in chapter 5 (Recommendations). The OSDs should also provide a framework for other developmental applications as these critical–feature interactions are dealt with and ATIS/CVO systems are moved toward broad system use.

Top

TASK CHARACTERIZATION

Although the development of a task list that adequately identifies the tasks necessary to achieve the purpose of a system function is important, it does not provide adequate information to the analyst to consider the requirements of a particular task or the implications of a task to human factors design guidelines. To do this part of the analysis, it is necessary to develop an understanding of the characteristics of each task. The next step in the analysis process, therefore, was the preparation of elements that would provide an adequate characterization or description of each task.

Since the major purpose of the ATIS project is the development of human factors design guidelines, the areas considered for the characterization concentrated on those things that would be important to determining the guidelines. Following traditional task description approaches, a variety of possible task characteristics was considered. Some were rejected (e.g., display indications, control actions) because they involved assumptions about the design of the systems, which the analysts were reluctant to make. Others were rejected (e.g., feedback, time available) because they required that the analysts make assumptions about the order of task completion or time required of a specific task that are not known at this time. The following categories were selected to characterize each task:

• Purpose– –the purpose or goal of performing the task.
• Initiating Condition– –the situation or condition that causes the driver or system to start performing the task.
• Decision Element (Task Type)– –the type of action performed.
• Task Performance Considerations– –considerations that must be made when designing the system to ensure successful performance by drivers on the task.

In addition to these categories, space was provided for other comments that the analyst believes are important to an understanding of the task within the context of the task analysis. Once the decision had been made to characterize the tasks using these four categories, taxonomies were selected or developed that would provide reasonable boundaries to the description of the tasks and allow comparisons of characteristics across tasks. Appendix D includes a detailed task characterization based on these four categories. Furthermore, the taxonomies that define each of these categories help identify constraints on task sequences and pertinent human limits associated with specific driving and ATIS tasks.

Characterizing the Purpose for the Function or Task

The reason for characterizing a task by its purpose is that by doing so the analyst will have an idea of the relationship between the task, the function that it supports, and the other tasks that are involved in the same function. To support such an understanding of task relationships, the taxonomy used to describe the purpose categories is described in table 9.

Characterizing the Initiating Conditions

The initiating conditions to start a task are essentially demands for task action. The description of the initiating condition, therefore, tells the analyst something about the sequence of events that precedes starting the task, the system demand characteristics

associated with the task, and the urgency with which the task must be undertaken. A taxonomy was developed to describe the range of possible initiating conditions associated with the use of ATIS. Table 10 describes this taxonomy.

Characterizing Task Activities

One of the more important ways of characterizing a task is to identify the type of actions performed. Task C of the ATIS project reported the use of a taxonomy of decision elements that described the important actions necessary for each ATIS function. This same taxonomy works equally well in describing task activities and was adopted for use in this task as well. Table 11 provides a brief description of each of the decision elements (Lee et al., 1993).

When performing a characterization of the various tasks associated with ATIS/CVO systems, characterization of individual tasks was based on the most significant or highest level cognitive task performed by an operator. While it is recognized that complete decomposition of a task to the level that identifies individual decision elements might be desirable in identifying the relationship between human limitations and potential task requirements, such a detailed decomposition of tasks for conceptual systems would be overly ambitious and requires the analysts to make major assumptions about design configurations.

Characterizing Task Performance Considerations

One of the most important products of a task analysis is the identification of system design considerations that would affect the performance of human operators on a specific task.

Task F of the ATIS project identified the physiological and cognitive characteristics of drivers that would influence the use of ATIS. Based on the physiological and cognitive characteristics of drivers developed in Task F and others who deal with human error, a listing was developed to indicate the significant system design considerations that would influence human performance on the task. Table 12 provides a brief description of the task performance considerations commonly associated with each decision element. The basis for each of these considerations is as follows:

• Audio signals must not be masked by background noise (Detect). Human beings have both a limited range of normal hearing (approximately 20 to 22,000 Hz) and a limited ability to discriminate between competing tones. Both of these limitations are differentially affected by conditions such as age; prior exposure to damaging levels of noise, fatigue, and illness; and certain drugs. For an audio signal to be detected, it must be within the limits of perception (i.e., be loud enough and within the frequency band available to human hearing) and be separate from other noises that would hide or confuse the signal. For example, an audio signal lower in amplitude than the background noise created by the noise of the engine would not be detected easily by the operator. Likewise, an audio signal that was approximately the same frequency as that produced by a cooling fan in the cab of a truck would not be noticed by the driver unless it was of significantly higher amplitude than the noise produced by the fan.

Table 9. Purpose categories used to characterize functions and tasks.

Table 10. Taxonomy of initiating conditions.

Table 11. Summary of decision–making elements that describes driver interaction with ATIS/CVO systems

Table 12. Summary of decision-making elements and human task performance considerations.

• Audio signals must be distinct enough in onset, frequency, amplitude, and duration to exceed a driver's threshold of noticeability (Detect). The human auditory system is widely adaptable to accommodate normal changes in the environment. The rate of change, frequency, amplitude, and duration with which the change occurs must exceed this normal accommodation in order to be detected as a signal of interest. Signals that fall below this threshold are accommodated as normal conditions by the individual.

• Visual signals must be sufficiently large to be seen by the driver (Detect). Human beings have an ability to detect visual objects that represent approximately 0.05 degrees of the visual field. The specific size required for detection varies depending on the context of the signal (e.g., number, complexity, and proximity of other visual signals).

• Visual signals must lie within the normal or peripheral scan of the driver (Detect). To be detected, a visual signal must lie within the normal view of the driver or within the peripheral scan of the driver. The size of the signal, illumination requirements, color contrast, and movement effects of the signal will depend upon where within the visual scan the signal occurs.

• Visual signals should not be apportioned between different displays (Detect). Human beings rely on visual signals that are associated with one another in a single portion of the visual field. As a consequence, they are generally unable to readily detect signals that are presented on different displays. An example of such a signal in a car might be one where a head–up display would flash to indicate a warning, the color of the instrument panel would indicate the severity of the warning condition, and the text on a display beside the dash would indicate the specific condition.

• Workload must be low enough to allow driver to make selection (Input Select). When workload is high, the individual will focus on those signals interpreted to be relevant to specific tasks, usually selected on the basis of either order of presentation or for their obvious survival benefit. In periods of high workload, signals that are not perceived within as pertaining to one of these two conditions will be ignored. For example, a signal indicating that a left turn should be initiated is not likely to be noticed if, at the same time, a driver receives information on the name of the cross–street and the special sale going on at the nearby mall.

• Required input to be selected must not be masked by other tasks (Input Select). Human beings have a limited ability to attend to several different things at once. To be selected for attention, a signal must compete with other tasks that the operator is doing at the same time. When another task has similar characteristics to the signal task, there is a likelihood that the driver will ignore one or the other. For example, a synthesized voice signal notifying a driver of an engine overheating, followed by a flashing annunciator light notifying the driver of a transmission problem, might result in the driver dealing with the engine condition without noticing the transmission condition.

• Relevant signals/information must be distinct from irrelevant information (Filter). Human beings pay selective attention to signals and information based on a perception of the relevance of the information available to what is needed. If insufficient clues are available to determine which information is relevant, the driver will be unable to make a meaningful selection of the information. For example, if an IVSAWS provided warning of an emergency vehicle within a certain radius, but provided no indication of the direction or distance of the vehicle, the driver would not be able to use the information to determine what actions he or she should take, since the emergency vehicle could easily be on another street or moving away.

• Relevant signals/information that need to be considered must be similar to one another (Filter). Human beings organize information elements based upon categorical relationships or learned associations among the information elements. For goal–relevant information to be filtered from non–relevant information, the relevant information should be presented within a structure that reflects meaningful distinctions between the information elements. In a practical way, this means that choices should be made between information elements that have already been organized into familiar groups or categories. For example, when presenting a list of possible restaurants on an IMSIS, the list normally would not consist of all restaurants within a 20–mi (32.2–km) radius. Rather, the various restaurants can be organized according to criteria that are likely to be of interest to the user when making a decision about a restaurant, such as cost, distance, or type of food.

• Information presentations that require memorization must not exceed short–term memory capabilities (Search). Human beings have a limited capacity to retain individual items in short–term memory from which the items can be transferred to long–term memory for comparison with expectations and decision making. The practical limit for human beings to search a list of items is approximately five to nine individual items. Beyond that number, individuals usually must go through multiple selection processes to reduce the items down to a reasonable number of choices.

• Information presented must be consistent with user's knowledge base (Identify/Interpret). Human beings identify and interpret signals based on their experience with similar signals in the past. To adequately interpret a signal, a driver must have encountered the signal or similar signals before. Signals for which the driver has no similar experience may cause alarm, but will not be labeled and processed as goal–oriented behavior. For example, the appearance of a new type of highway sign on the road with the word SLOW written in the center surrounded by a circle with a diagonal slash through it would very likely result in some portion of drivers going slower.

• Information presented must be consistent with user's understanding of system goals (Interpret). Human beings organize their interpretation of events based on mental models of the outcome (goals) and the way a system will operate. If the system provides information that is inconsistent with such a model, the driver will doubt the system or will be unable to properly interpret the signals presented. For example, an IMSIS might use the driver's date of birth to determine the appropriateness of a particular hospital within its data base. If, when seeking information about hospitals in the area, the system responded with a listing headed by the statement, "You are 57 years old today," the driver would likely be doubtful and, therefore, not be able to properly interpret the system output, particularly if he or she knew of a hospital nearby that was not listed.

• Motor actions required must be within human capabilities (Code). Human beings have limited capabilities for motor actions. These include limitations in the time necessary to respond to a signal (reaction time), to coordinate fine motor activities, and to maintain continuous controls within specified limits. These limitations vary from individual to individual depending on a wide variety of conditions, such as hand preference and genetic background. They also vary within individuals depending on conditions such as age, state of health, fatigue, and use of certain drugs. They are also affected by a variety of different environmental conditions, such as the presence of vibration, the need to perform controls while the arm is fully extended, the size of the control and its proximity to other controls, and the wearing of gloves.

• System input requirements must be compatible with user's knowledge base (Code). The information required of a system needs to be something that is known by the driver. The greater the capabilities of the system, the more knowledge the driver needs to effectively employ it. For example, a data base that holds only the location of restaurants in a local area might not require a driver to know the city in which the desired restaurant lies; however, to effectively use a nationwide data base, the driver would generally need to know that information. Similarly, a system that required a driver to enter the present latitude and longitude to update an IRANS would be dependent on the ability of the driver to obtain this information.

• System input requirements must not require user translation (Code). Human beings are limited in their ability to convert information from one unit of measure to another. For example, location information should not require that the driver enter offsets from map reference points (e.g., two blocks north and one block west of the junction of highways 305 and 27).

• System input actions must not exceed short–term memory limitations (Code). Human beings have a limited capacity to remember long lists of numbers and items. In coding information into a system, an operator is often required to observe one number or item, such as an address in a list, and to retain it in memory long enough to enter the information into the system. A good example of this problem is when someone uses a long distance calling card to make an unassisted international telephone call. The likelihood of successfully entering the appropriate company access code, telephone number, and charge card number on the first try is less than certain.

• System requirements must allow adequate time for necessary execution (Plan). Human beings require finite amounts of time to consider alternatives and to formulate decisions. The amount of time required depends on other tasks that need to be done, the amount of information that must be considered, and the willingness of the individual to act on incomplete information regarding likely outcomes. To successfully formulate plans, drivers must have sufficient notification of the need to plan so that they can consider the situation and its likely outcome.

• System must provide necessary information for user to make informed choices (Plan). Human beings involved in planning require information upon which to make judgments about the likely effect of their plans. For example, a driver planning a cross–country trip might need to know the distance and estimated travel times for alternative route segments before deciding where to spend the night.

• System must allow sequential or organizational entry of planning information to avoid short–term memory limitations (Plan) . Human beings organize information according to several different possible structures. These include temporal or sequential association and similarity of the type of information. To effectively overcome short–term memory limitations, such organized information allows a driver to enter information in "chunks."

• System requirements must limit user demands on short–term memory (Compute). Human beings have a limited ability to retain multiple items in short–term memory. When computations are required of the driver, the number of items that the driver needs to use in the computation are limited. For example, a CVO system might require that the system know the total weight of the vehicle. If the vehicle has been weighed, this would require that the driver compute the total weight by adding the weight on each axle. If the axle weights were not known, the driver would need to compute the weight of the tractor empty, plus fuel capacity, minus fuel used, plus trailer weight empty, plus cargo. A system that would allow each of these weights separately would reduce the possibility of computation error.

• System requirements must minimize user demands on long–term memory (Compute). In computation, long–term memory (i.e., knowledge) provides a driver with the rules that are applied to information in short–term memory in order to arrive at a solution. Computational performance by human beings is at least partially dependent on how complex these rules are. Simple rules (i.e., limited demands on long–term memory) generally result in better performance than do more complicated rules. The difference can be illustrated by the difference in accuracy for a driver computing following distance based on a mnemonic, "One car length for every 10 miles per hour of speed," as opposed to one that says, "The following distance should be 17.5 feet times the speed, rounded to the nearest 10 miles per hour."

• System must provide output of recommendations in appropriate detail for user to identify compatibility with major constraints (Test). When testing possible alternatives, human beings make comparisons between the alternative and a series of expected features. If the system does not express the alternative in a way that allows such a comparison, a test cannot be made. For example, one of the criteria that a driver might have for selecting a proposed route through a city might be that it avoids certain areas of the city. If the output of the system was presented as street names and turn points, a driver would probably be unable to determine if this criteria had been met. If the route was shown as a map overview with major sections labeled, the driver would be better able to test the route to see if it was compatible with his or her requirements.

• System must provide output of recommendations without exceeding short–term memory limitations (Test). Human beings have a limited capacity to retain items in short–term memory for comparison with criteria held in long–term memory. The exact limits of such memory will depend on a number of individual and situational variables, such as age, workload, recall delay, the driver's familiarity with the information items, and the meaningfulness of the information items. If the system presentation of a recommendation involves the need to make more comparisons of information with criteria than can be held in short–term memory at that particular time, the driver will be unable to effectively test the recommendation.

• System must avoid presenting recommendations in such a high level of detail as to significantly increase driver workload (Test) . Human beings make tests of possible alternatives based on a limited number of comparisons with criteria selection or rejection of the alternative. If a system provides too much information at too rapid a rate, the individual will not be able to effectively select the salient information from that which is unimportant. An example of such a possibility would be a system that presented a turn–by–turn recommendation for a dynamic route change while a driver was approaching an accident scene.

• System must provide adequate information for user to predict outcome of each option being considered (Decide/Select). Although human decision making involves many different possible approaches, it can be thought of as a weighing of costs and benefits to determine which of several alternatives will result in the greatest benefit at the least cost. To effectively decide on a course of action, a driver must have information concerning these costs and benefits. Without this information, the driver is only involved in guessing or risk taking.

• System recommendations must be consistent with driver's experience (Decide/Select). Drivers make decisions on recommendations based on their assessment of the likelihood that a given recommendation will have the desired outcome. Since decision making is a human process and not a machine process, drivers select or approve a particular recommendation based partly on the information associated with the recommendations (e.g., estimated travel time, predicted road conditions) and partly on their prior experiences with similar decisions (e.g., the last trip over a similar route took 3 h longer than expected, it feels like it's going to rain today).

• System recommendations must not violate known conditions or limitations (Decide/Select). The driver's confidence in a system recommendation depends in part on the perceived plausibility that the recommendation is an appropriate one. If a recommendation includes items that the driver knows are not possible (e.g., travel over a bridge that is under construction, travel the wrong way down a one–way street), he or she is likely to reject the recommendation altogether.

• System requirements must not exceed driver's response capabilities (i.e., reaction time, precision, and tracking) (Control). Drivers have limited ability to respond to system–required control actions. These include limitations in the time necessary to respond to a signal (reaction time), to coordinate fine motor activities, and to maintain continuous control within specified limits. These limitations vary from individual to individual depending on a wide variety of conditions, such as hand preference and genetic background. In addition, they vary within individuals depending on conditions such as age, state of health, fatigue, and use of certain drugs. They are also affected by different environmental conditions, such as the presence of vibration, the need to perform controls while the arm is fully extended, the size of the control and its proximity to other controls, and the wearing of gloves.

• System must provide driver with indications of action completion (Control). Human beings require indications that necessary control inputs have been accepted by the system in order to know when to stop making the input.

• System must provide driver with indications that the system is responding to input (Control). Human beings require periodic information on system functioning to know that a control action has not only been accepted by the system, but that the system is appropriately using the input.

• System must provide driver with indications of present state or condition (Monitor). Human beings need periodic information that a system is performing properly and doing what it is intended to do. For example, when using a passive warning system such as IVSAWS, a driver will not have confidence in the system unless he or she has some indication that the system is on and that it is capable of receiving the necessary trigger conditions to issue a warning.

• System must provide driver with indications of progress toward a planned goal (Monitor). Human beings involved in the use of automated systems such as IRANS may substitute instructions provided by the system for monitoring normal position and navigation tasks. Since they become dependent on the system to guide them, they need to have indications from the system that tell them how the planned route is progressing.

Top

DRIVING FUNCTIONS

Identifying driving functions is a critical step in performing a task analysis of ATIS, whose primary purpose is to provide a broad perspective to guide the selection of which driving tasks to include in the task analysis. The driving functions aggregate many individual tasks to show how the individual tasks interact at a more global level. This more global perspective helps to focus the analysis on important issues and to define the scope of analysis.

In a hierarchical task description, the highest level of description defines driving in terms of general functions. Subfunctions and tasks associated with a common goal make up these general functions. For example, the tasks of steering wheel manipulation, accelerator control, and brake application support the subfunctions of maintaining speed, changing speed, and adjusting vehicle position relative to the roadway and other vehicles. These subfunctions all serve the general function of speed and position control. In many instances, subfunctions consist of sets of tasks associated with components of the ATIS. Task C described components of ATIS, and the task analysis identified tasks associated with those components. These ATIS–specific tasks form the basis of many subfunctions that support various driving functions. Thus, driving functions include subfunctions and tasks related specifically to driving and to the various components of ATIS. Appendix C provides a comprehensive listing of driving/ATIS/CVO tasks and begins with a listing of these driving functions. These functions can be used as an index to the listing of individual tasks, because appendix C contains a list of tasks associated with each function or system functional characteristic. In this way, appendix C provides a convenient catalog of tasks accessible through the index of driving functions.

Selection of Driving Functions

Table 13 shows the ATIS components associated with each driving function for private drivers, and table 14 shows this information for commercial drivers. Since these functions represent the highest level of a hierarchical description of driving tasks, a complex set of tasks is associated with each driving function in these tables. In addition, each function consists of driving–specific tasks and may also include tasks specific to interaction with ATIS. The selection of driving functions depended on two criteria. First, the scope of the task description must include tasks associated with all the ATIS functional characteristics identified in Task C. This ensures that the task description represented by the functions in tables 13 and 14 completely describe how drivers will interact with a potential ATIS and show all the ATIS elements described in Task C. Second, the driving functions must go beyond describing only the tasks associated with ATIS; they should also describe crucial driving tasks that may interact with ATIS–specific tasks. Driving functions that include all potential ATIS elements and a representative set of important driving–specific tasks help to ensure that the task analysis will address issues important to the design and implementation of ATIS.

Table 13. Driving functions and the associated ATIS functional characteristics for private drivers.

Table 14. Driving functions and the associated ATIS functional characteristics for commercial drivers.

Identifying the driving functions of interest both limits the scope of the task analysis and indicates important interactions and issues. For this analysis, the driving functions included in the analysis were selected to address critical issues associated with ATIS–specific tasks and the interaction of information provided by ATIS and driving tasks. Specifically, the driving functions can be grouped into pre–drive and drive activities to highlight critical differences between tasks performed while the vehicle is motionless and those performed while it is moving. This distinction illustrates which ATIS–specific tasks compete with the drivers' attention to the dynamic control of a vehicle. Another critical issue that the selection of driving functions emphasizes is the interaction between driving functions associated with primary driving functions and functions associated with ancillary tasks. The ancillary functions include critical tasks (such as responding to emergencies) and interacting with other in–vehicle systems (such as adjusting climate controls, the radio, or scanning the ATIS listing of upcoming restaurants). Thus, the driving functions focus on the task analysis so that it is not a broad description of driving, but a description of driving and ATIS–specific tasks relevant to the design of ATIS.

Drive and Pre–Drive Driving Functions

The detailed description of the tasks associated with particular scenarios (appendix D) will reveal how ATIS may augment current driving tasks. In this comparison, the distinction

between pre–drive tasks and driving tasks is particularly important. Pre–drive functions refer to sets of tasks completed while the vehicle is motionless. In this situation, the driver is primarily concerned with system configuration, inspection of the vehicle, and planning. As such, the driver has a single focus with minimal distractions. For example, the driver can focus attention on trip planning (e.g., finding information using the telephone directory, a map, or an ATIS) without the need to attend to other tasks concurrently. This contrasts with the tasks associated with the drive functions. In this instance, drivers must spread their attention across multiple tasks simultaneously. For example, drivers may need to assimilate information simultaneously from road signs while maneuvering through traffic and monitoring the ATIS for route guidance information. Additional tasks associated with pre–drive ATIS interactions are less likely to overwhelm the driver, compared to additional tasks ATIS may impose when the driver is also concerned with controlling the vehicle. Describing the driving–specific tasks will help to reveal important design differences between components of ATIS used before driving and those used while the vehicle is moving.

Primary and Ancillary Driving Functions

The distinction between primary driving and ancillary driving tasks may help show how an ATIS must integrate with drivers' tasks. Primary driving functions are those that are central to driving and without which moving a vehicle to a destination safely would not be possible. More specifically, the primary driving functions fall into three broad categories: navigation and routing, guidance and maneuvers, and control. Each of these groups of functions identifies tasks that a driver must perform. For instance, a driver must identify and follow a route, maneuver to change lanes and to turn from one street to another, and maintain control of the speed and position of the car relative to the roadway and other vehicles.

Ancillary driving tasks differ from primary tasks in that they are not a required aspect of routine driving. Ancillary driving functions include emergency response and monitoring and operating vehicle systems. In contrast with primary driving functions, the tasks associated with ancillary functions are of secondary importance to driving; however, they may go concurrently with driving. For example, a driver may adjust the radio (a task associated with the function of vehicle system operation and monitoring) while maneuvering the vehicle onto an entrance ramp. ATIS has the potential to increase the number of ancillary tasks and augment the driver's capability to cope with the primary driving tasks. In addition, an ATIS may automate many of the primary and ancillary tasks; thus, it is unclear whether ATIS will increase or decrease the driver's workload and efficiency. By identifying primary and ancillary driving functions and their associated tasks, a task analysis can determine how the tasks that are automated, added, or augmented by ATIS will interact with a driver's ability to attend to the primary task of driving. If many primary tasks are unchanged by ATIS, but more ancillary tasks are added, driver overload may become a serious threat.

In general, identifying driving functions was used to define the breadth of the analysis and to indicate which driving–specific tasks should be described in greater detail. In this way, the driving functions helped to guide the task analysis.

Top

FUNCTION SELECTION

Task C identified a set of 19 functional characteristics for the private vehicle operations and as many as 26 for the CVOs. Creating a detailed task analysis for each functional characteristic and all its potential interrelationships with other functional characteristics would have generated an enormous amount of data that might obscure important relationships between ATIS/CVO functional characteristics and their associated tasks. As a consequence, an analysis examined interrelationships between functional characteristics to identify those that are most central to ATIS/CVO usage and those that form closely linked groups. This analysis identified interrelationships between functions by examining the information flows that link ATIS/CVO functional characteristics. For example, the functional characteristic pre–drive route and destination selection provides destination and route information to route guidance. Functions central to the operation of ATIS/CVO provide or require information from several other functional characteristics. The potential importance of these functions highlights the need to include them in any analysis. Identifying groups of functions, linked by information flows, reveals sets of functions that should be examined together. Detecting functional characteristics that appear central to ATIS/CVO systems and identifying those that form highly coupled groups provide a strong basis for validating and revising the scenarios created in Task B. These revised scenarios focus the task analysis on important ATIS/CVO functional characteristics and on important groupings of these functional characteristics.

The initial step for this function selection was to identify information flows that link each functional characteristic with other functional characteristics, either within one particular system (e.g., IRANS) or with the components of the other systems. Task C became the principal source of reference to accomplish this identification. By reviewing the description of each functional characteristic and the tables showing the interaction of a particular function with other functional characteristics, as well as the tables labeled "information flow and current sources supporting subsystem functional characteristics" (Lee et al., 1993), it was possible to generate a set of interrelationships between the various functions. For each functional characteristic, a chart was drawn depicting the various links between a particular function and other functions. Figure 3 shows one example of these charts. Upon completion of all the charts, each one was reviewed systematically to identify inconsistencies in the interaction patterns across the various functional characteristics. The information in these charts was then combined into a large matrix that shows the information flows among all the ATIS/CVO functional characteristics. Appendix B shows a matrix for both private and commercial ATIS/CVO systems.

These charts and the accompanying matrices served as the basis for several analyses. These analyses, reported in detail in appendix B, served two purposes: (1) to identify functional characteristics that are central to ATIS/CVO operation, and (2) to identify clusters of functional characteristics that form meaningful groupings based on the information that links them. To analyze the relationships among functional characteristics, a number of techniques traditionally used to examine social networks were adopted (Borgatti, Everett, & Freeman, 1992). These analyses include a frequency count that tabulates the number of times each function requires or provides information to other functions, a network analysis measure of centrality, and a cluster analysis that identifies groups of functional characteristics linked by information flows. Appendix B includes a summary of the frequency counts, estimates of centrality for each functional characteristic, and matrices showing groups of highly coupled functional characteristics. The results of these analyses form a strong basis for identifying which functional characteristics or groups of functional characteristics the scenarios need to include. The next section, Scenario Selection, shows how these functional characteristics and combinations of functional characteristics guide the selection of scenarios for the detailed task analysis.

Top

SCENARIO SELECTION

The analysis of the information flows between functional characteristics helped to focus the task analysis by generating a subset of functional characteristics that, based on the information flow analysis, represented the most important aspects of ATIS/CVO systems. Tasks B and C provided a set of private and commercial scenarios that could form the basis for placing the tasks associated with ATIS/CVO use in the actual driving context. The previously generated scenarios and the analysis of information flow made it possible to select and, in some cases, modify scenarios that were representative of the combinations of functions that hold the greatest potential interest (see appendix B for a detailed discussion of the selection process). Generally, scenarios were selected to include functional characteristics that were determined to be central to ATIS/CVO, and to include combinations of functional characteristics that corresponded to highly coupled groups of functional characteristics. In addition, scenarios were selected to examine interactions between diverse functional characteristics and to investigate instances in which the driver may experience high workload.

Appendix B describes in detail the rationale used to choose each scenario. This description accounts for how the results of the information flow analysis guided the selection of particular scenarios. In addition, appendix B identifies each functional characteristic that occurs in each scenario and explains its importance given the context of each particular scenario. Appendix B summarizes each scenario in a table (see appendix B, tables 32 to 44) that includes the following information: (1) purpose, (2) summary, (3) systems involved (IRANS, IMSIS, ISIS, IVSAWS, and CVO–specific), and (4) functional characteristics that occur. The following scenarios are the output of the selection process described in appendix B, and they provide the basis for the detailed task analysis.

• Private Driving Scenario P1

  A driver vacationing with his family in an urban setting arrives at the airport in mid–afternoon and rents a car with an IRANS device installed. The family's plan is to go directly to their hotel located in the city 10 miles (16.1 km) from the airport. The weather is good, but there is a substantial level of congestion on the major highways between the airport and the hotel due to normal commuting traffic. After receiving a brief orientation on using IRANS at the rental office, the driver identifies his destination on the IRANS and requests the fastest route. The IRANS recommends a route that the driver accepts and he begins his trip to the hotel.

• Private Driving Scenario P2

  A real estate salesperson is meeting a couple at their residence. She plans on showing them several houses in a suburban area of a major city. She has selected houses in several different neighborhoods spaced around one side of the city. The neighborhoods can be reached by either highways or arterials. It is evening, there is a heavy rain, and there is an accident on one of the highways that could be taken. Two neighborhoods that would be reasonable starting points for the evening's viewing are approximately equidistant from the clients' current residence. The salesperson would like to go to the neighborhood that can be most easily reached first. Prior to picking up her clients, she enters the addresses of all of the houses in the IRANS. During the drive to her clients' house, she monitors the traffic congestion in the planned area of travel. When she arrives at the clients' residence, she requests a comparison of travel times and selects the route that is predicted to take the least time. She then reviews current traffic congestion. Finally, she picks up her clients and drives them to the first house.

• Private Driving Scenario P6

  A driver is on an extended driving vacation. He has stopped approximately 50 miles (80.5 km) from his destination to review motel options for the evening at his destination point. He accesses the IMSIS directory for the town he will be staying in, reviews several alternative motels, and selects three that are located in one specific area and that look interesting. Before proceeding toward his destination, he makes a reservation using ATIS.

• Private Driving Scenario P8

  A business traveler is driving in the suburbs of a major city he is not familiar with during a heavy snowstorm at dinner time. He has selected a 20– mile (32.2–km) drive, recommended by ATIS, from his hotel to his first destination, which is predominantly on arterial roads. In fact, the drive is not a straight line, but rather a series of turns to various arterial roads (no highways). The heavy snow is making visibility poor and the roads icy. He requests that the ATIS provide him with street signs and interchange graphics as well as stop signs and lane–use control information. Halfway to his destination, he is informed of an accident and of his need to select an alternate route. As he is examining two alternatives, the ATIS warns him of an approaching emergency vehicle. He slows down, pulls over, and enters his route choice. After the emergency vehicle passes, he continues traveling to his destination.

• Private Driving Scenario P14

  A driver commutes between her home and the office. The commute requires coordination between three different modes of transportation. She drives the first 10 miles (16.1 km) and then has to decide between taking the ferry across the Bay or driving around the Bay Area. Once she is on the other side of the Bay, she has to drive for another 5 miles (8.0 km) to a park–and–ride lot where she takes a bus to the office. However, she can choose to reject the bus option and drive an additional 10 miles (16.1 km) if the traffic is light. It is a cold winter day and the roads are icy. She needs to get to work in the shortest amount of time possible. She uses the ATIS to plan her trip to the office and to coordinate the travel between the different modes of transportation. After taking the ferry and paying the toll, and while traveling to the bus stop, her ATIS informs her of icy conditions on the road and of bus delays. She selects an alternate route and continues her drive to work.

• Private Driving Scenario P16

  A driver uses the ATIS to travel from her hotel to a restaurant on the outskirts of town. While traveling, she receives notification that the engine's temperature is increasing. Fearing engine damage, she pulls off the road. The driver then identifies a service station close by. She requests the assistance of a tow truck and cancels her dinner reservation. She also communicates with her friend to inform her of the misadventure with the vehicle and to ask to be picked up at the service station.

• Private Driving Scenario P20

  It is Friday afternoon and a driver is following the IRANS guidance in traveling back to her hotel from an appointment with a client. As she drives, she receives the broadcast signal of a nearby winery. She debates between continuing to her hotel or visiting the winery. She uses the ATIS to verify if the winery is open and makes a reservation for the next guided tour. Moments later, she requests a dynamic route change to proceed toward the winery.

• Private Driving Scenario P22

  A driver travels on a secondary road where there are numerous speed changes due to the presence of several small towns. As he is driving, the IVSAWS detects a malfunction of the car's brakes. The driver takes notice of the message and continues to his destination. Later on, he receives another message of road construction ahead. The driver applies the brakes, but it is too late; the car collides with a construction vehicle merging from the side of the road. The ATIS activates the aid request to provide assistance to the driver, who is unconscious.

• Commercial Driving Scenario C4

  A young interstate truck operator is traveling at night on a narrow, two–lane road. As he is traveling, his IVSAWS provides advance warning of the road closure due to a new construction zone ahead. Because the road closure occurs just prior to a planned refueling stop, the driver uses his ATIS to determine the nearest service station. Having selected one, he requests a dynamic route change to proceed to the station and the help of the ISIS to provide speed limit transitions, street signs, and merge signs.

• Commercial Driving Scenario C11

  An experienced interstate truck operator is passing between two States at nighttime. Prior to reaching the inspection point, her weigh–in– motion (WIM) system advises her to move to the right–hand lane, where her vehicle is weighed while traveling at normal speeds. Simultaneously, a sensor reads the truck's electronic credentials to validate safety records and debit the trucking company's account for road taxes. Finally, the driver's electronic credentials are verified to ensure that her driver's license and permits are up to date and that her operating hours have been within the legal limits. The driver receives notification that all transactions have been performed successfully, and she proceeds at normal speed past the inspection point.

• Commercial Driving Scenario C12

  It is Friday evening, during rush hour traffic, just before a holiday. The commute is slow because it is snowing and several accidents obstruct the traffic circulation. A central dispatcher for medical aid vehicles in a large metropolitan area is working her normal evening shift. She receives two concurrent emergency calls for aid required at a freeway accident and at a private residence. The dispatcher enters the locations of the emergencies into her routing system and the system determines the appropriate medical aid vehicle stations to call and the appropriate routes to take, based on the fastest predicted travel time under current traffic and road conditions. Upon receipt of that information, she informs the appropriate drivers of the new destination and route to take. The drivers enter the routing into their ATIS and activate IVSAWS to provide them with updated road condition information. As one of the drivers is driving to the residential call, he is informed of severe icing along the route. He requests a route change from his ATIS and continues to the residence.

• Commercial Driving Scenario C13

  A central dispatcher coordinates the progress of 20 separate vans that provide door–to–door airport transportation in one suburban section of a major metropolitan area. Service is provided on demand so that calls are responded to within a specified period of time. If the caller is not picked up within the specified time, the cost of the ride is reduced by 50 percent and a report must be filed by the driver and dispatcher. A dispatcher is also rewarded for making the maximum use of available vans, as determined by the fleet routing system. The dispatcher prepares the first pickup schedule of the day and transmits this information to the drivers.

• Commercial Driving Scenario C15

  An interstate truck operator is traveling on the interstate early Sunday morning. As he is driving, his "cargo/vehicle condition monitoring" informs him of a malfunction with one of the trailer's axles. The driver pulls over, checks it, and determines that help is needed. Using the ATIS, he selects a service station that is open at that time and requests their assistance.

Top

FHWA-RD-95-176