2
Model Overview

The key assumptions and basic structure of the task load model are outlined in this chapter as well as methods used to convert its task load output into estimates of positions to traffic (PTT). The chapter concludes with committee observations about the model’s assumptions and structure and about the methods employed for PTT conversion. These observations are explored in more depth in the following chapters.

MODELING R-SIDE TASKS ONLY

Aircraft typically pass through multiple en route sectors during a flight. The more aircraft transiting the sector, the more work is created for controllers, thereby consuming controlling capacity. The volume of traffic alone, however, is not the only factor demanding controller time. The complexity of the traffic activity along with the associated controller procedures and technologies are important factors. The amount of time from when an aircraft enters a sector to when it exits a sector is typically less than 15 minutes. During this time, some aircraft may cruise directly through the sector, requiring the controller to monitor the flight to ensure safe vertical and horizontal separation from other aircraft. Other activity may require additional actions by the controller, such as performing clearances for aircraft transitioning to lower or higher altitudes and adjusting headings in response to weather, traffic congestion, or crossing traffic. Thus, both the volume and the complexity of the aircraft affect the time demands on controllers.

As explained in Chapter 1, an en route sector may be staffed by a lone R-side (lead) controller or an R-side and a D-side (associate) controller working as a team. When traffic is very heavy, a third controller (T-side)



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 18
2 Model Overview The key assumptions and basic structure of the task load model are out- lined in this chapter as well as methods used to convert its task load out- put into estimates of positions to traffic (PTT). The chapter concludes with committee observations about the model’s assumptions and struc- ture and about the methods employed for PTT conversion. These obser- vations are explored in more depth in the following chapters. MODELING R-SIDE TASKS ONLY Aircraft typically pass through multiple en route sectors during a flight. The more aircraft transiting the sector, the more work is created for con- trollers, thereby consuming controlling capacity. The volume of traffic alone, however, is not the only factor demanding controller time. The complexity of the traffic activity along with the associated controller pro- cedures and technologies are important factors. The amount of time from when an aircraft enters a sector to when it exits a sector is typically less than 15 minutes. During this time, some aircraft may cruise directly through the sector, requiring the controller to monitor the flight to ensure safe vertical and horizontal separation from other aircraft. Other activity may require additional actions by the controller, such as per- forming clearances for aircraft transitioning to lower or higher altitudes and adjusting headings in response to weather, traffic congestion, or crossing traffic. Thus, both the volume and the complexity of the aircraft affect the time demands on controllers. As explained in Chapter 1, an en route sector may be staffed by a lone R-side (lead) controller or an R-side and a D-side (associate) controller working as a team. When traffic is very heavy, a third controller (T-side) 18

OCR for page 18
Model Overview 19 may be in position as well, although this setup is not a normal (planned- for) configuration. The lead controller is in charge of communicating with pilots, monitoring the radar screen to maintain safe separation, coordinat- ing with other controllers, and other services only provided by the R-side controller. When working alone, the lead controller also has the responsi- bility to receive and process flight-plan information and to plan and orga- nize the flow of traffic within the sector, which are considered D-side services. When an associate controller is present, the D-side services are no longer the responsibility of the lead controller. The addition of the second controller therefore frees up more time for the lead controller to focus attention on R-side services. This division of responsibilities allows for more traffic to be handled by a two-controller team than by a single controller. The Center for Advanced Aviation System Development (CAASD) task load model was originally developed for the purpose of assessing the maximum number of flights that can safely traverse a sector during a time period. For the reasons explained earlier, a two-controller team can han- dle more traffic than a single controller because the lead controller can devote all of his or her controlling time to the R-side tasks that accom- pany all flights. Thus for assessing the maximum throughput capacity of a sector, it is necessary to assume that two controllers are in position— one handling exclusively R-side tasks and the other handling exclusively D-side tasks. Given this assumption, it is not necessary to model the D-side task load to assess sector traffic capacity. Traffic capacity is simply a func- tion of the controlling time available to the lead controller to perform more R-side tasks. Once the lead controller’s time is fully occupied with R-side tasks, the sector will have reached its maximum traffic capacity. The assumption that two controllers are in position and that traffic capacity is solely a function of the controlling time available to the lead con- troller caused CAASD to structure the task load model so that it only esti- mates R-side task load. This modeling limitation, as will become evident later, has important implications for the model’s ability to predict PTT. OVERVIEW OF MODEL STRUCTURE Figure 2-1 shows the basic structure of the task load model. Box 1 in the fig- ure lists eight of the nine major R-side tasks in the model. To determine when these tasks must be performed—or when they are triggered—the

OCR for page 18
3 1 Task Time Assignment Eight Triggered R-Side Tasks Times for most delay tasks (most composed of subtasks) 2 (based on consultations with Assigned times and R-Side Task Trigger Data Entry operational experts) schedules can vary Exit Traffic operations and by flight type: Flash through Times for subtasks flight-planning data Nonradar arrival – Nonmilitary for other triggered tasks – Propeller Nonradar departure (modeled using GOMS) Separation event data – Military Transition – International Spacing and delay data Separation assurance Subtask scheduling Delay (7 types): (based on consultations with – Low – Shortcut operational experts) – Medium – Reroute – High – Hold – Diversion Model Output Current Use R-side task workload 4 Hand-off, delay, PTT estimation R-Side Task Load Computation separation – Sums times spent on R-side tasks during 15-minute period Transits Possible (assumes task times are fixed and no multitasking) Future Uses – Adds time for monitoring task per aircraft calculated based on composition of the task load during the period Traffic characteristics Capacity analysis Traffic flow analysis; other FIGURE 2-1 General structure of task load model.

OCR for page 18
Model Overview 21 model requires information on the volume and type of traffic in a sector. As shown in Box 2, the model relies on traffic operations and flight-planning data to simulate—or re-create—the traffic activity that occurred in the sec- tor during past time periods. The traffic operations and flight-planning data, for instance, are used to indicate when a flight entered a sector, an event that triggers an entry task. When a task is triggered, the model associates it with it a series of actions—or subtasks—that the lead controller is presumed to have per- formed, such as identifying the aircraft, establishing a clearance plan, and accepting the hand-off. For most of the triggered tasks, the task execution times are derived from a modeling process using Goals, Operators, Meth- ods, and Selection Rules (GOMS) procedures (Box 3 in Figure 2-1). By using GOMS, each subtask is divided into its most basic operators, such as entering a keystroke or scanning a radar screen. Each operator is assigned an estimated execution time. The operator times are summed to calculate the total time required to perform the subtask. The subtasks are then scheduled across the total period of time it takes to complete the task. For some tasks involving certain types of flights—military, propeller, and international flights—the model increases the computed task times by 25 percent to reflect the assumed additional complexity of this traffic. Of the eight triggered tasks, only the delay tasks (with the exception of the shortcut) are not divided into subtasks that use GOMS-derived times. The traffic operations and flight-planning data that trigger a delay event are used to separate the delay task into the following seven types: shortcut, low delay, medium delay, high delay, reroute, diversion, and hold. The shortcut task time of 11 seconds is derived from GOMS. Task times ranging from 25 to 75 seconds are assigned to each of the other six types of delay. According to CAASD, these delay task times were developed through consultations with operational experts. Finally, task times are assigned for monitoring, which is the ninth modeled R-side task (Box 4). It is assumed that all flights are monitored by the controller using the radar screen, and thus the model assigns a monitoring task time to each flight that transits a sector. The assigned time can differ for each flight, depending on how long the aircraft stays in the sector and the other tasks it triggers. Monitoring times range from 0.2 to 0.8 seconds for every minute an aircraft is in the sector. The lower

OCR for page 18
22 Air Traffic Controller Staffing in the En Route Domain per-minute times are assigned to those flights that also trigger the delay tasks, under the assumption that a certain amount of screen monitoring is already included in the calculated delay task time (and thus avoid double counting of monitoring time). For modeling ease, the model assumes that all of these task times are independent of one another and that tasks are performed sequentially by controllers rather than concurrently via multitasking. Total R-side task load is thus estimated by simply summing all of these times spent on tasks to generate 1-minute task loads averaged over 15-minute periods on a rolling basis. CONVERTING R-SIDE TASK LOAD INTO PTT Estimating PTT requires information on when the total R-side and D-side task load fully occupies the controlling time available to the lead controller. At that point a second controller is presumably needed to handle any more traffic. If both R-side and D-side task load is modeled, converting the task load output into PTT is a fairly straightforward process—when total modeled task load exceeds the assumed controlling time available to the lead controller, a second controller is required and PTT increases from 1 to 2. Yet as explained earlier, the CAASD model only computes R-side task load. Consequently, the total task load is not known, and therefore it is not possible to know when the R-side and D-side task load together are occupying all of the controlling time available to the lead controller. Thus CAASD had to develop methods for convert- ing this limited R-side task load into estimates of PTT. How these con- versions were originally made and how they are currently being made are summarized next. Single Threshold for Conversion The original method used to convert the modeled R-side task load into PTT was to assume that when a specific amount of task load is reached, an associate controller is needed to assist the lead controller. Specifically, the modelers assumed that if total R-side task load exceeded 600 seconds during a 15-minute period, the second controller was needed if the sec- tor experienced any more traffic. According to CAASD, this 600-second

OCR for page 18
Model Overview 23 threshold was initially developed after consultations with operational experts in which lower time thresholds (e.g., 500, 540, and 550 seconds) were considered. These lower thresholds imply that more D-side task load is associated with traffic than is implied by the 600-second cutoff. For various reasons explained further in this report, CAASD was not sat- isfied with the PTT estimates produced by applying a single (600-second) threshold across all en route sectors. In particular, managers and con- trollers consulted in several of the en route centers expressed concern that using a single threshold neglected the variability in D-side task load that occurs across sectors and centers because of variability in traffic complex- ity. The staff in centers having more nonradar and international traffic pointed out that the D-side controller has a significant role in managing this traffic, for instance, by having to perform manual hand-offs. They claimed that in these cases the D-side task load is higher in relation to the modeled R-side task load than is implied by a single 600-second threshold. Responding to these specific concerns, the model developers added new triggers for international and nonradar tasks and created rules that led to lower conversion thresholds when these tasks contributed a cer- tain amount of the R-side task load in a sector. These adjustments led to the addition of a second controller at a lower R-side task load when the traffic consisted of a significant amount of international and nonradar flights. Fuzzy Logic Modeling for PTT Conversion Even after making these rule-based adjustments to the task load conver- sion process, model developers were concerned that the generated PTT values still did not fully account for how variability in traffic complexity affects total (R-side and D-side) controller task load, and thus PTT. The rule-based adjustments only accounted for the effect of two types of air- craft traffic activity—international and nonradar flights. The model developers, however, were interested in estimating how all variability in traffic complexity affects total task load and resultant PTT. To account for more of this traffic complexity, CAASD turned to fuzzy logic modeling as another way to infer total task load from the modeled R-side tasks. On the basis of consultations with operational

OCR for page 18
24 Air Traffic Controller Staffing in the En Route Domain experts, the model developers characterized each modeled task accord- ing to its perceived complexity, that is, the extent to which it generates more or less D-side work in addition to the modeled R-side task load. Although the D-side tasks were never identified explicitly, three of the R-side tasks—entry, exit, and monitoring—were characterized by the experts as basic tasks that are accompanied by relatively little D-side activ- ity. Three other tasks—transition, separation, and delay—were charac- terized as complex, generating a moderate amount of D-side work. Several other tasks, including those involving international and nonradar flights, were characterized as “other” and assumed to have the greatest amount of D-side task load. By characterizing and weighting the com- plexity of each modeled task in this manner, and then using fuzzy logic rules and algorithms to imply a total task load for different combinations of R-side tasks, this conversion method was viewed as providing a more traffic-dependent and realistic set of PTT values. KEY POINTS FROM OVERVIEW The specific elements of the task load model and PTT conversion meth- ods are elaborated on in the remainder of this report: the following is a summary of the basic model structure and assumptions as outlined in this overview chapter. • The task load model uses an array of traffic operations and flight- planning data to simulate traffic activity experienced in each of the en route sectors. By quantifying both the volume and type of traffic activ- ity in each sector, the simulations provide a more complete picture of the traffic demand on controller time than is possible through simple counts of traffic alone. • The task load model was originally developed to estimate the through- put capacity of en route sectors, believed to be a function of the lead controller’s available time to perform R-side tasks. Because two con- trollers are needed to maximize throughput in a sector, the model assumes that two controllers are in position at all times, with the lead controller performing all R-side tasks and the associate controller per- forming all D-side tasks. The assumption that the lead controller is dedicated to R-side work, coupled with sector traffic capacity as a func-

OCR for page 18
Model Overview 25 tion of R-side task performance, has led to a model that only estimates R-side task load. • To compute task load, the times spent on individual tasks are summed, and thus assumed to be independent of one another and performed sequentially rather than concurrently. Model task times are generated primarily through GOMS modeling and from informa- tion obtained from consultations with subject matter experts. • To model PTT, which is an estimate of whether one or more controllers are required to work the traffic, requires information on total controller task load. Because the model only estimates R-side task load, various methods are employed to infer total task load. The method now being used, which employs fuzzy logic modeling, weights each R-side task according to its perceived D-side complexity. Although the D-side tasks are neither measured nor identified, these complexity weightings are treated as valid representations of D-side task loads because they were developed by using the judgment of operational experts.