Abstract
Objective:
I introduce the automation-by-expertise-by-training interaction in automated systems and discuss its influence on operator performance.
Background:
Transportation accidents that, across a 30-year interval demonstrated identical automation-related operator errors, suggest a need to reexamine traditional views of automation.
Method:
I review accident investigation reports, regulator studies, and literature on human computer interaction, expertise, and training and discuss how failing to attend to the interaction of automation, expertise level, and training has enabled operators to commit identical automation-related errors.
Results:
Automated systems continue to provide capabilities exceeding operators’ need for effective system operation and provide interfaces that can hinder, rather than enhance, operator automation-related situation awareness. Because of limitations in time and resources, training programs do not provide operators the expertise needed to effectively operate these automated systems, requiring them to obtain the expertise ad hoc during system operations. As a result, many do not acquire necessary automation-related system expertise.
Conclusion:
Integrating automation with expected operator expertise levels, and within training programs that provide operators the necessary automation expertise, can reduce opportunities for automation-related operator errors.
Application:
Research to address the automation-by-expertise-by-training interaction is needed. However, such research must meet challenges inherent to examining realistic sociotechnical system automation features with representative samples of operators, perhaps by using observational and ethnographic research. Research in this domain should improve the integration of design and training and, it is hoped, enhance operator performance.
Introduction
The implementation of automation in sociotechnical systems has enhanced system operations, but with the implementation, operators have committed automation-related errors that have led to accidents. Although rare, such accidents suggest that aspects of automated systems can compromise system safety.
Flight crews of highly automated aircraft committed an automation-related error, failing to monitor airspeed, in at least three separate aviation accidents across an approximately three-decade period. On February 28, 1984, a McDonnell-Douglas DC-10-30 ran off the runway after landing at New York’s John F. Kennedy International Airport, at an airspeed considerably higher than the pilots had selected (National Transportation Safety Board, 1984). The aircraft was destroyed and 11 passengers and crew received minor injuries in the accident. The airplane was equipped with an autothrottle that controlled engine thrust and was integrated with an autopilot that adjusted the airplane’s pitch to enable it to maintain selected air and vertical (i.e., climb and descent) speeds. Although the pilots had selected an approach speed of 155 knots, the speed appropriate for the airplane’s weight and landing configuration, the aircraft was actually flown 30 knots higher and could not be stopped on the available runway upon landing. Investigators determined that a malfunction in the aircraft’s autothrottle led to the excessive airspeed, but the flight crew did not monitor the airspeed during the approach and landing and did not realize that the airspeed was high. Investigators attributed the accident, in part, to the pilots’ “overreliance on the autothrottle speed control system which had a history of recent malfunctions” (National Transportation Safety Board, 1984, p. 47).
Nearly 30 years later, on July 6, 2013, an accident with an identical operator error occurred, also involving a highly automated air transport aircraft (National Transportation Safety Board, 2014). The airplane, a Boeing 777-200ER, crashed while on approach to San Francisco International Airport, destroying it and injuring 52 of those onboard, three of them fatally. Just before the airplane struck the runway edge, airspeed had deteriorated to about 20 knots less than the pilot-selected airspeed of 132 knots. Only seconds before the accident, when it was too late, the pilots recognized the low airspeed. Investigators learned that Boeing had not informed its customers of a particular autothrottle operating mode. The pilots were unaware that the autothrottle mode that was engaged was different from the one they had selected, that it did not maintain a minimum safe airspeed, and that the airspeed they had selected was no longer being maintained. Investigators determined that the accident was caused, in part, by “the flight crew’s inadequate monitoring of airspeed” (National Transportation Safety Board, 2014, p. 129).
In the interim, at least one other landing accident occurred in which pilots of a highly automated aircraft did not effectively monitor the airspeed. On February 25, 2009, a Boeing 737-800 crashed while on approach to Amsterdam (Dutch Safety Board, 2010). The airplane was destroyed and the three pilots (one was serving as a safety pilot), a flight attendant, and five of the 117 passengers aboard were killed in the accident. The selected approach airspeed was 144 knots, but the autothrottle malfunctioned and the pilots were unaware that the airspeed had deteriorated to 107 knots, also until it was too late to avoid the accident. Investigators concluded that the accident occurred, in part, because of a crew “failure of monitoring the airspeed” (Dutch Safety Board, 2010, p. 7).
Airspeed, with altitude and position, is critical to safe flight. Only minimal variations from reference speed are acceptable at any point but especially on approach and landing, when even small variations from the reference airspeed can be catastrophic. Airspeeds even a few knots higher can, as in the New York accident, lead to an inability to stop the aircraft on the runway, and airspeeds a few knots lower can, as in the San Francisco and Amsterdam accidents, lead to an aircraft stall and/or an excessive descent rate.
Although pilots are trained and checked regularly on their airspeed control, the errors in the three accidents, committed across an approximately 30-year period, indicate that these automated systems, if not others as well, are susceptible to repeated automation-related errors. Given the extensive research in operator–automation interaction conducted even before the 1984 accident—and the prominent role that lessons from aviation accidents play in pilot training, procedures, and oversight—the repeated nature of the errors suggests that perhaps a different perspective on the existing research is in order. Although investigators in the discussed accidents cited contemporary research on automation use and drew lessons from each, the airspeed monitoring error of the New York accident was subsequently repeated.
I argue that the system flaws illustrated in these accidents are the result, in part, of the failure of system designers to recognize and address the effects of the interaction of automation, operator expertise level, and operator training on automated system operations. Automated systems in sociotechnical systems are not operated in isolation but in complex enterprises with fixed constraints. By not addressing expected operator expertise levels when designing automated systems, not considering training constraints in automation system design, and not addressing automation-related expertise issues when developing training programs, automation-related operator errors have been allowed to continue.
To examine these deficiencies, I review literature on automation design and use, expertise, and operator training. Thereafter, I discuss the nature of the interaction of these three elements and how their interaction affects system safety and suggest design, training, and expertise metrics that should be considered when developing new systems. Finally, I suggest avenues of research to help understand how addressing system design and training, with defined operator expertise levels, can enhance operator interaction with highly automated systems.
Automation and Sociotechnical Systems
Sociotechnical Systems
Sociotechnical systems, such as air transportation, maritime operations, chemical processing, and the like, are “integrated human and machine entities that, when functioning as an integrated, coordinated unit, can address a wide range of problems that are too complex to be addressed by individuals or machines working alone” (Gorman, Cooke, & Salas, 2010, p. 143). These systems are typically dynamic, and system states can change independently of operator action as, for example, when on occasion an aircraft or vessel encounters adverse weather (see Cellier, Eyrolle, & Marine, 1997; Durso & Dattel, 2006). Operators must anticipate and respond to system changes, whether expected or not, to effectively operate them. Their complexity typically calls for operator teams rather than operators working individually. Operators also receive extensive training and operate under regulatory oversight and enforcement. Automation is particularly well suited to sociotechnical system operations because of the economic benefits of its use, the complexity of the processes involved, the accuracy and reliability of the automation, and the considerable consequences that can result from operator errors.
Automation
Definitions of automation have tended to coalesce around Parasuraman and Riley’s (1997), “the execution by a machine agent (usually a computer) of a function that was previously carried out by a human” (p. 231). As an increasing number of cognitive tasks are allocated to automation, companies can reduce the number of operators needed (Wiener & Curry, 1980). For example, whereas three pilots were needed to operate older air transport aircraft (four in some Soviet-designed aircraft), two are now needed for newer aircraft, even as aircraft size and passenger capacity have increased. In the marine and aviation systems, where operators had once devoted considerable effort to navigation, they now primarily delegate navigation to the automation, monitoring the systems to verify that the selected courses and tracks are being maintained.
Automation can function as a single subsystem or as a constellation of subsystems operating interdependently. Contemporary automated systems typically perform four functions: They acquire information, analyze information, select actions based on that analysis, and implement the action, as needed (Sheridan & Parasuraman, 2005). The degree and the level at which the four functions are conducted vary across systems, along with their degree of independence from the operators. Operators can be informed of system status changes or not, and the automation can change operating modes with varying levels of agreement with and/or input from the operator (Parasuraman, Bahri, Deaton, Morrison, & Barnes, 1992; Parasuraman, Sheridan, & Wickens, 2000; Taylor, Reinerman-Jones, Szalma, Mouloua, & Hancock, 2013). Operating mode changes may occur without the operator being informed, depending on the phase of operation, the task complexity involved, and the like (Sarter & Woods, 1995). Nevertheless, operators are responsible for supervisory control (Sarter & Woods, 1995; Sheridan & Parasuraman, 2005), that is, overseeing the automated processes to ensure system performance within acceptable parameters.
The high degree of reliability and accuracy of automation, with the number and complexity of subsystems that automation can monitor and control, has increased operational efficiency. For example, because automated navigation and track control are so accurate and reliable, aircraft can maintain oceanic tracks with little deviation, thereby allowing more aircraft to operate on the tracks than before with confidence that aircraft will not deviate from them and threaten safety. Nonetheless, negative effects of automation have also been identified (e.g., Christoffersen & Woods, 2002; Mosier et al., 2013; Parasuraman & Riley, 1997; Sarter & Woods, 1995; Wiener & Curry, 1980; Wood, 2003). As Jamieson and Vicente (2005) wrote,
The use of automation in complex sociotechnical systems has proved to be a double-edged sword. It is a technology that, perhaps more so than any other, speaks with a forked tongue to system designers. On the one hand, it promises unprecedented reliability, reduced workload, improved economy, and fewer errors. On the other hand, it whispers of less tangible, but no less real, costs to operators in terms of skill degradation, mental isolation, and monitoring burdens (Hirschhorn, 1984; Norman, 1990; Parasuraman, Molloy, Mouloua, & Hilburn, 1996). (p. 12)
Because a full discussion of the potentially adverse effects of automation is beyond the scope of this paper, I briefly address research on operator–automation interaction in sociotechnical systems. Wiener and Curry (1980) described the deleterious effects of extended operator reliance on automation on manual skills because, they argued, extended automation use can lead to a decrease in operator skill in manually performed tasks. Bainbridge (1983) described several “ironies” associated with automation, suggesting that, for example, were an anomaly to take place, it would occur at a point when operators would most need their manual skills, skills that would likely have degraded after extended periods of relying on automation to perform what had been manual tasks. Further, operators in those situations would have had limited experience recognizing and responding to automated system faults and little knowledge of the processes behind the automated systems to enable them to respond effectively to an anomaly. Molloy and Parasuraman (1996) pointed out that operator vigilance in monitoring automated systems is “a role for which humans are poorly suited” (p. 311), and as a result, operators may fail to detect a systems anomaly.
Much of the research on the effects of automation on skill retention has focused on manual skills, but researchers have found effects on cognitive skills as well. For example, Casner, Geven, Recker, and Schooler (2014) demonstrated that, after extended use of automated systems, pilots’ manual operating skills were largely not degraded. However, some cognitive skills necessary for awareness and prediction of near-term flight paths had deteriorated. Researchers have also described a unique error, automation bias, that results from extended operator use of and reliance upon automation (e.g., Mosier & Skitka, 1996; Mosier, Skitka, Heers, & Burdick, 1998; Parasuraman & Riley, 1997; Skitka & Mosier, 2000). Extended automation use can lead operators to assume consistent accuracy and infallibility of the automation, to the detriment of their vigilance in monitoring automated systems. Operators could then commit errors by deferring to the automation decisions that are needed in response to certain system states, even when automation-suggested actions may be inappropriate. Operators could also commit omission errors by incompletely diagnosing the system, relying on automation-performed diagnosis instead.
Parasuraman and Manzey (2010) described automation complacency, wherein operators are less than vigilant in recognizing automated system failures, typically during high-workload periods, when they may delegate cognitive tasks to automation that they could better perform themselves. This error results, they suggest, from the effects of cognitive effort and extended operator use of highly reliable automated systems (see also Wickens, Clegg, Vieane, & Sebok, 2015).
Operator workload alteration resulting from automation, increasing during high-workload operating phases and decreasing during low-workload phases, can make tasks more, not less, demanding, a result of “clumsy automation” (Mosier et al., 2013; Sarter & Woods, 1995; Wiener, 1989). As Woods (1996) explained, clumsy automation is
a form of poor coordination between the human and machine in the control of dynamic processes where the benefits of the new technology accrue during workload troughs and the costs or burdens imposed by the technology (i.e., additional tasks, new knowledge, forcing the user to adopt new cognitive strategies, new communication burdens, new attentional demands) occur during periods of peak workload, high criticality or high tempo operations (see also Cook & Woods, 1994; Sarter & Woods, 1994b). (p. 10)
Norman (1990) attributed automation-related errors primarily to insufficient operator feedback from automated systems. Designers, he believed, needed to provide operators with considerably more system-related information than had been previously recognized to enable them to effectively analyze and respond to unexpected system states. Amalberti and Wilbaux (1994) similarly attributed many of the operator errors unique to automated systems to “incorrect system design.”
Degani, Barshi, and Safto (2013) attributed an accident of a highly automated aircraft to shortcomings in the presentation of system information that led the pilots to misunderstand system alerts and fail to recognize that the airplane was leaking fuel, until it exhausted its fuel supply while airborne. Degani et al. argued that critical fuel information was ineffectively integrated and failed to match the pilots’ mental models of the fuel system. Rather than receiving information in a single display identifying the anomaly as a fuel leak, the pilots had to alternate among multiple display pages of information to recognize that the airplane was leaking fuel; the system had instead presented information revealing a fuel load imbalance. The pilots had to manually calculate fuel quantities and fuel balances to recognize that a fuel leak was causing the imbalance, and then they had to calculate the amount of fuel remaining. Following fuel exhaustion, the pilots were able to safely glide the airplane to a nearby airport, avoiding a potentially catastrophic accident.
As automation-related errors have been introduced into sociotechnical system operations, the nature of the errors that have contributed to accidents has changed as well (e.g., Coury, Ellingstad, & Kolly, 2011; Kirwan, 2001). As Amalberti and Wilbaux (1994) predicted,
The relationship between system design, human-error and the risk of accident[s] is not linear from great risks to no risk. Obvious bad system-design and/or unadapted regulations or training will cause numerous human-errors and will increase the risk of accident[s]. (p. 314)
Some have pointed out that in delegating tasks to automation, operators can become “out of the loop” of system monitoring because of insufficient or inadequate system-related information (see also Jamieson & Vicente, 2005), thereby increasing the likelihood that they will miss critical information. In a related manner, Endsley and Kiris (1995) and Endsley and Kaber (1999) noted that decreased operator vigilance—from complacency in monitoring highly reliable systems, insufficient feedback regarding system state, and reduced manual skills from extensive reliance on automation—has led to reduced operator situation awareness of present and near-term system states during system anomalies. Nikolec and Sarter (2007), using experienced pilots of automated air transport aircraft, found that the pilots had difficulty readily diagnosing and responding to simulated anomalies in the aircraft they operated.
Sarter and Woods (1995) described how the proliferation of systems with automated functions that lack, among other elements, salient feedback has created systems that are opaque to their users, particularly during high-workload operating phases. “During this high-tempo phase of flight,” they wrote, “with a large number of concurrent tasks, the crew now has another set of cognitive tasks to perform: monitoring and interpreting mode annunciations relative to expected behavior” (Sarter & Woods, 1995, p. 8; see also Mosier et al., 2013).
Salas, Rosen, Burke, Goodwin, and Fiore (2006) suggested that automation can degrade team performance, a result of reduced operator awareness of (a) the information their fellow team members’ receive and/or of (b) the automation-related actions of their fellow team members. Salas, Cooke, and Rosen (2008) observed that with increasing automation,
the mere insertion of technology into a system does not guarantee that it will augment team performance or even be used by the team. Just as training must be well designed to be effective, technology also must be guided by a thorough understanding of team needs and capabilities. (pp. 542–543)
Sarter and Woods (1995) attributed automated operator-related errors, in part, to inadequate training. “Buggy mental models,” they wrote, “can also result from an inappropriate approach to training that does not acknowledge the need for exploration and experimentation in the process of learning how these new systems work and how to work these systems” (Sarter & Woods, 1995, p. 13).
The research on adverse effects of automation on operator performance points to breakdowns in operator situation awareness regarding aspects of either the system state, the automation state, or both. Similar breakdowns could be seen in the aviation accidents cited whereby the pilots lost situation awareness regarding airspeed and the automation mode governing airspeed. Other accident investigations have addressed operator awareness of automated navigation state (Aeronautica Civil of the Government of Colombia, 1996; His Majesty’s Government of Nepal, 1993) and of altitude, airspeed, and vertical speed (Accident Investigation Commission, 1996; Bureau d’Enquêtes et d’Analyses pour la Sécurité de l’Aviation Civile, 2012).
Studies on automation-related mental models, automation complacency, automation bias, and automation surprises illustrate what may be particularly insidious effects of automation, those involving cognitive skill degradation, particularly those skills necessary for system situation awareness. Absent effective ongoing situation awareness, operators may lose the ability to recognize the situation they are encountering or, perhaps worse, be unable to diagnose the cause of a situation they may yet encounter. A recent accident in Amsterdam involving a hard landing in an Embraer E-190, a highly automated air transport aircraft, in which the pilots were unaware of the flight mode that the autopilot had engaged, illustrates this point (Dutch Safety Board, 2016). As the investigators found,
the crew were incorrectly under the impression that they had configured the aircraft for an automation landing. The [flight mode annunciator] system [displaying automation mode] was not designed to draw the pilots’ attention to the fact that they have to switch off the automatic pilot at low altitude above the runway, in accordance with the procedure for a manual landing. . . . The way in which the interface between an automated system and its human user is designed can affect whether or not unintended system settings are noticed. (pp. 20, 22)
Considerable research has been directed at the design of automation interfaces and its effects on operator automation-related situation awareness. Rasmussen and Vicente (1989) and Vicente (2002) suggested that automated system data presentations do not match operator cognitive needs, particularly during nonroutine and unanticipated system operating conditions, leading to data misinterpretation or delayed interpretation. They proposed interfaces that present readily interpretable data through ecological interface design (or EID), based on Rasmussen’s (1983) taxonomy of operator system interaction. Vicente maintained that such designs can enhance performance, particularly with expert operators. Furukawa and Parasuraman (2003) demonstrated that EID displays were better at enhancing general aviation pilots’ and college students’ performance than were non-EID displays. For any interface to be effective, Vicente wrote, it must be
implemented as part of an integrated approach to systems design. The interface, decision support, automation, training, selection, alarms, procedures, and team collaboration all need to be designed in a coordinated manner using a common philosophy. (Vicente, 2002, p. 74)
Lewis and Rieman (1994), referring to human–computer interface (HCI) albeit not specifically within sociotechnical systems, proposed methodologies to guide the development of interfaces through “task-centered user interface design.” Goodman, Stolterman, and Wakkary (2011), suggesting that a “disconnect” between HCI designers and interface users may be due to a lack of research to guide theory on design practices. They called for empirically grounded descriptions of design practice to develop frameworks to assist designers. Degani and Heymann (2002) proposed a methodology to enhance HCI by addressing four elements critical to operator interaction with automation: (a) the machine’s behavior, (b) task specifications, (c) the operator’s mental model of the machine’s behavior, and (d) the user interface.
It has been argued that designers have created systems based on the capabilities of the technology, not on the needs of the operators, resulting in systems with operational capabilities so complex that, in some cases, they provide more functionalities than operators can reasonably be expected to master. As Sarter and Woods (1995) wrote over two decades ago,
The flexibility of more advanced technology allows automation designers to develop much more complicated, mode-rich systems. Modes proliferate as designers provide multiple levels of automation and various optional methods for many individual functions. The result is numerous mode indications distributed over multiple displays, each containing just that portion of the mode status data corresponding to a particular system or subsystem. (p. 7)
Jamieson and Vicente (2005) attributed shortcomings in HCI to engineers who were “swept up in the wave of microprocessor and software innovations that sometimes overwhelm concerns for human limitations . . . the epitome of a technology-driven enterprise” (p. 12). They proposed a “control-theoretic framework” with, among other elements, designers and stakeholders working with human factors engineers to develop designs that enhance operator system mental models. Similarly, Taylor et al. (2013) argued that, when designing systems, designers need to adopt a theory of cognitive processing to maintain an accurate portrayal of operator mental states to help match automation level to operator needs.
Sheridan and Parasuraman (2000) suggested different design considerations to assist operators to detect and respond to failures, from automating whatever is technically feasible and automating boring or unpleasant operator tasks to altering the level of automation according to operator situational needs. Instead of relying on traditional methods, they proposed an economic-analytic approach, applying an expected-value analysis to determine the cost/benefit of allocating a task to the automation so that task allocation is based on the financial rewards.
As automation functionality has increased, automation system complexity has likewise grown. Designers have not met alterations in operator state, say, in terms of fatigue, workload, and the like by corresponding alterations in system state. Rather, evidence suggests that designers have taken advantage of technological capabilities by adding automation functionalities to enhance operational efficiency rather than to enhance operator automation-related performance. The considerable research on adaptive automation, automation complacency, automation bias, user interface, and accident reports describing operator failures to heed critical performance parameters suggests that technology needs have taken precedence over operator needs in system design.
In sum, although automation has enhanced system efficiency and safety by its high degree of accuracy and reliability, and its ability to manage and control numerous complex subsystems, it has also altered the tasks of operators, their workload, and the nature of system-related information presentation. It has provided capabilities that can exceed operator mastery, thus detracting from operator effectiveness, and interfaces that detract, rather than enhance, operator ability to recognize and comprehend the meaning of the information presented. Consequently, new types of operator automation-related errors have been introduced into sociotechnical systems. On occasion, these errors have led to accidents in which operators have lost situation awareness regarding key elements of system operation and/or automation state. An overview of studies of automation is presented in Table 1.
Automation-Related Studies
Expertise
Endsley (2006), referring to a magazine account of the now-retired hockey player Wayne Gretzky, noted that
the critical attribute that placed him head and shoulders above his contemporaries was mental—his ability to understand what was happening in the game and to anticipate where the puck would be. This superior situation awareness allowed him to be “ahead of the game” and outmatch bigger, faster, and better players. (p. 633)
Many of Gretzky’s skills made him, by many accounts, among the greatest hockey players of all time, not the least of which was his superior Level 3 situation awareness (Endsley, 1995), that is, his ability to accurately predict where the puck (and players) would be in the near future, which, with his physical abilities, allowed him to anticipate situations (and respond by scoring more goals) with greater facility than could others. Although athletic expertise has been widely recognized in the literature, expertise in sociotechnical system operations calls for unique skills. Relatively little research has been conducted to determine the expertise needed to operate automated systems.
Ericsson and Charness (1994), defined expert performance as “consistently superior performance on a specified set of representative tasks for the domain that can be administered to any subject” (p. 731). Ericsson, Prietula, and Cokely (2007) describe three criteria for determining expertise: performance that (a) is consistently superior to that of others, (b) leads to concrete results, and (c) can be replicated and measured in a laboratory.
In an early study of expertise and cognitive performance, Chase and Simon (1973) found that after briefly viewing a chess board, an expert chess player—that is, one who had reached the level of a master—performed no better than a novice at recalling positions of chess pieces placed randomly on the board. By contrast, when piece locations matched those of actual matches, the expert could reconstruct the locations with little difficulty; the novice’s performance by contrast was no different. Chase and Simon suggested that experts form memories of chess piece placement, not from individual piece locations but from patterns of the pieces, through what they termed “perceptual chunking,” thereby allowing experts to exceed basic short-term memory limitations. Chi, Feltovich, and Glaser (1982) similarly compared performance of experts, PhD physics candidates, in sorting physics problems with that of novices, undergraduates who had completed an introductory mechanics course. Experts grouped the physics problems largely by general physics principles, displaying a deeper understanding of the topic, and “saw” different features of the problems than did novices. Novices, by contrast, tended to group the problems according to more superficial terms, primarily by their concrete features. Hmelo-Silver and Pfeffer (2004) showed that experts had a more elaborate system of concepts, principles, and their interrelationships than did novices.
Glaser (1990) explained that experts and novices differ in the way they access knowledge as well as in their knowledge structure. Novices can access information but are unable to apply it to needed situations, whereas experts access information that is functional and bound to conditions of applicability, enabling them to apply it as needed. Experts also gain automaticity in their ability to apply their knowledge to solve problems (see also Smith, 2003). Bransford, Brown, and Cocking (1999) suggested that, in addition to their ability to discern meaningful patterns of information, experts, unlike novices, can also flexibly retrieve critical aspects of their knowledge with little effort.
Endsley (2006), referring to sociotechnical system operators, maintained that novices lack the knowledge to differentiate between information important to a particular situation and information that is not. “Without knowledge of the underlying relationships among system components,” she wrote, “novices do not realize what information to seek out following receipt of other information” (Endsley, 2006, p. 638) Further, Endsley suggested that by structuring knowledge into mental models of systems, experts can match system information to existing mental models to help understand current system state and predict future states. In abnormal situations, experts also have superior strategies of gathering information and planning for contingencies.
Fadde (2009) observed that the predominant feature of experts’ advantage over novices is their speed of recognizing circumstances rather than the accuracy of their recognition (see also Day & Goldstone, 2012). Durso and Dattel (2006) maintained that this superior feature of experts’ performance is particularly useful in potentially hazardous situations, where experts are superior to novices in hazard perception and recognition. This performance may be attributed, they suggested, to experts’ superiority in managing resources compared with that of novices.
Cellier et al. (1997) observed that the quality and quantity of the patterns of experts’ system knowledge are critical dimensions of their expertise. With their mental models, experts demonstrate superior system diagnoses over that of novices, who tend to address already existing anomalies, and can conduct anticipatory monitoring of dynamic system states. Although automaticity and speed are critical to this process, Endsley (2006) warned that because of their high levels of automaticity, experts need to be alert to the possibility of overlooking critical cues in abnormal situations.
Salas, Rosen, et al. (2006) defined expert teams as groups of interdependent members, each of whom possesses unique expertise, which together leads to high levels of team and task outcomes. Expert teams provide synergy that leads to superior team performance over that expected of individual members. Teams can flexibly apply their knowledge structures to novel situations, and they possess adaptive expertise, that is, the ability to develop new procedures based on their knowledge to enable them to respond to novel situations (see also Smith, Ford, & Kozlowski, 1997).
Ericsson and Charness (1994) considered expertise to be domain specific, with experts possessing unique cognitive structures or mental models. Like Endsley (2006), they argued that experts can analyze a current situation and from that anticipate and plan for future events. They believed that people gain expertise in work settings by deliberate practice—considerable, specific, and deliberate efforts sustained over time—with assistance from expert teachers or coaches. In fields such as the performing arts, they estimated that it can take from 10 to as many as 15 to 25 years to attain expertise.
Birney, Beckmann, and Wood (2012) suggested that expertise researchers consider factors external to cognitive structures, arguing that expertise development is influenced by factors such as motivation and self-regulatory elements in addition to deliberate practice. They termed the result “flexible expertise.”
In summary, experts can more readily identify and interpret data relevant to current and unexpected situations than can novices. They can anticipate and respond to future states, largely by relying on and applying mental models to existing situations, more readily than can novices. Expertise is generally obtained by deliberate practice, that is, specific efforts to advance skills in a particular domain, over an extended period of time. An overview of studies of expertise is presented in Table 2.
Expertise-Related Studies
Note. LOFT = line-oriented flight training.
Training
Research on training has generally paralleled research on expertise, with much of the literature addressing both training/instructional theory and theories of expertise. Glaser (1990) described the influence of learning theory on research in expertise, observing that “the objectives of instruction are based on current knowledge of the characteristics of competent performance on a task” (p. 29). To Glaser, learning theory should be consistent with such research to help learners transition from initial knowledge acquisition to achieving expertise, whereby knowledge can be readily applied in “autonomous phases.” Researchers tended to agree, he said, that “useful knowledge” is acquired by active application toward specific goals during problem solving. Cannon-Bowers, Tannenbaum, Salas, and Converse (1999) suggested that training needed to integrate theory into application, and they proposed a method to do so.
Koedinger, Corbett, and Perfetti (2012) wrote that
learning is robust when it lasts over time (long-term retention), transfers to new situations that differ from the learning situation along various dimensions (e.g., material content, setting, cf., Barnett & Ceci, 2002; Chen & Klahr, 2008), or accelerates future learning in new situations (Bransford & Schwartz, 1999). (p. 761)
They described the KLI framework—integrating knowledge, learning, and instruction—to bring this result about. The framework is based on cognitive load theory, an approach to training that matches information and tasks to learner expertise level to minimize avoidable loads on working memory and to maximize schema acquisition (Kalyuga, Chandler, & Sweller, 1998; Paas, Renkl, & Sweller, 2003). Kalyuga et al. (1998) determined that instructional methods should change as learners gain expertise, to maximize training efficiency and minimize the cognitive load on the learners, to avoid impeding learning effectiveness.
Researchers have suggested that as students gain expertise, they transition through several stages, from novices acquiring knowledge about the domain to experts who have developed automaticity in recognizing and responding to scenarios within the domains. Smith (2003) observed,
The cognitive theory and research indicate that expertness in the workplace develops through a series of stages from novice to expert, with an attendant development and refinement of schema and the strategic deployment of knowledge. Expertness is characterized by automaticity and an ability to solve problems in new situations through the strategic application of existing knowledge. Such expertness develops through a range of learning activities, including practice, demonstration, and mentoring by expert others. (p. 80)
Ericsson (2006) described three phases of training through which people gain expertise. First they achieve proficiency at a functional level as they strive to understand the requirements of the activity and avoid mistakes. Second, often reached after 50 hr of training, people perform at an acceptable level, and third, skills become automated and people execute them smoothly and with little effort. Beyond this level, however, years of experience are needed to reach the highest levels of performance (see also Gist, 1997; Smith, 2003).
McLaughlin, Rikers, and Schmidt (2008) suggested that the relative diagnostic superiority of expert medical clinicians to that of novices results from both analytic information processing, which is addressed in clinical training, and the automatic processing of contextual information, which is, by contrast, acquired over time. Seeking an efficient method to train to achieve diagnostic expertise and recognizing that no single approach would be most effective, they suggested that clinicians be trained in both analytic and automatic processing. Similarly, Hmelo-Silver (2004) described a training program that seeks to enhance medical students’ problem-solving abilities by focusing on investigating and resolving specific medical issues.
Ehrenstein, Walker, Czerwinski, and Feldman (1994), examining training for automaticity, suggested that training research address the dependence of automatic performance on initial conditions and focus on optimizing performance through practice in transfer to altered conditions. The extent of improvement, they noted, largely depends on the degree to which stimulus features resemble the response set. More recently, Day and Goldstone (2012) recommended that training developers focus on surface commonalities between cases to achieve knowledge transfer from the training environment to novel situations. Because transfer is often largely a perceptual process, they argued that training should emphasize both perceptual learning (to assist in recognizing structural similarities) and perceptual processes.
Smith et al. (1997), recognizing that technology has changed work environments from predictable to more unpredictable, called for workers to acquire “adaptive expertise” so that they can use their existing knowledge to respond to new unstructured and ill-defined problems, similar to Rasmussen’s (1983) knowledge-based skill level. They suggested applying cognitive research on expertise to provide workers with the detailed and organized knowledge about a task domain and the metacognitive awareness (i.e., knowledge and regulations of one’s own cognition; Schraw, 1998) for planning, monitoring, and evaluating so they would recognize when adaptability was needed (see also Bransford et al., 1999). Training in adaptive expertise calls for a deep knowledge of the task domain and skills in metacognition, through discovery learning and error-based training, so that learners can practice different strategies, linked to their existing knowledge, to effectively respond to novel situations. Schraw (1998) argued that metacognition is essential for successful learning because it enables students to better manage their cognitive skills and identify and address skill weaknesses. Metacognitive skills, he suggests, can be directly addressed by stressing its importance, improving knowledge and regulation of cognition, and creating environments that promote metacognition.
Training in Sociotechnical System Operations
Training in sociotechnical system operations has incorporated lessons learned from system accidents. For example, training to improve operator team performance, known as CRM or crew resource management in aviation and BRM or boat resource management in marine operations, was largely developed in response to several high-profile aviation accidents in which team errors in recognizing and responding to relatively minor system faults led to catastrophic accidents. Over the years, researchers have devoted considerable efforts to optimizing CRM, leading to improved program quality. Nevertheless, the effects of CRM training on system safety have not been established (see O’Connor et al., 2008; Salas, Fowlkes, Stout, Milanovich, & Prince, 1999; Salas, Wilson, Burke, & Wightman, 2006).
Airline pilot training has also changed to incorporate CRM elements into aircraft training. Whereas pilots had once been trained as individuals, many airlines integrate aircraft training with crew or team performance training, recognizing that actual line operations are conducted by two-person teams. This type of training, known as line-oriented flight training (LOFT; Federal Aviation Administration, 2004), regards CRM as fundamental to operator performance rather than as a set of skills taught within a stand-alone curriculum, as had been the case.
Flin, Slaven, and Stewart (1996) studied decision making of offshore installation managers (OIMs), those in charge of offshore drilling platforms, in response to emergencies. They found that the OIMs used recognition-primed decision making (RPD; Klein, 1993), decision making characterized by rapid assessment and response to dynamic situations, to respond. Although the authors believed that training in RPD should not be undertaken because it is a skill that develops “as a function of expertise” (Flin et al., 1996, p. 275), RPD principles, they suggested, can be used to train people to recognize critical situational cues.
Fadde (2009) argued that expertise, because it is domain specific, lacks a common literature to which instructional designers across domains can refer. Nonetheless, he believed that instructional programs can be developed by using techniques such as cognitive task analysis. In applying RPD to domains such as air traffic control, he maintained that recognition distinguishes experts from novices, and he outlined an approach to train for expertise in RPD across domains.
McKinney and Davis (2005) evaluated deliberate practice in training military pilots in decision making in crisis or emergency situations. Using a retrospective technique to evaluate performance in actual scenarios, they compared the efficacy of the pilots’ decision making in responding to mechanical malfunctions to which they had been previously exposed with malfunctions for which they had not been so trained. Deliberate practice had a positive effect on decision making in response to practiced scenarios, but no effect was found in their responses to unpracticed scenarios. Nonetheless, the authors suggested that deliberate practice can assist operators in the recognition phase of decision making.
Casner, Geven, and Williams (2013), using airline pilots, also studied the effects of training on pilots’ responses to abnormal events. Like McKinney and Davis (2005), they found superior pilot responses to abnormal events for which they had been trained, compared with those for which the pilots had not been. However, the effectiveness of pilots’ responses was reduced considerably when they were presented with scenarios different from those they had expected. “Airline training events,” they wrote, are
highly scripted and predictable exercises that call into question the extent to which pilots’ abilities to recognize and respond to abnormal events, in all the forms in which they might present themselves during a real flight, are being honed and tested. (Casner et al., 2013, p. 477)
They suggested modifying pilot training to reduce predictability and to reduce the extent to which training is directed to performance on specific tests.
Schaafstal, Schraagen, and van Berlo (2000) described a technique, “structured troubleshooting,” to train naval weapons engineers to diagnose and correct—that is, troubleshoot—weapon system malfunctions. Believing that troubleshooting is primarily a diagnostic task, they modified training, which had been component oriented and based largely on technical documents, to be functionally oriented, stressing systematically applying diagnostic and repair knowledge. Naive learners trained in the traditional component-centered training performed substantially worse than those receiving “structured troubleshooting” training (see also Swezey, Perez, & Allen, 1991).
Although research in training to optimize operator performance in anomalous or unexpected situations has been conducted, little research has addressed training in response to automation-related anomalies. In general, operator training has largely focused on improving the delivery or efficiency of training to enhance general rather than automation-related operator performance. The Federal Aviation Administration’s (2013) comprehensive review of operator interaction with automated systems, with pilots of highly automated air carrier aircraft (it had conducted an earlier review after several high-profile pilot automation-related accidents; Federal Aviation Administration, 1996), showed that pilot responses to system failures remained a concern. It determined that
many training programs and trainees are focused on passing tests/checkrides. . . . [A] challenge is how to reach at least the required level of proficiency during the training program, and realizing that much knowledge and skill development will continue after pilots begin flying the line. As line operations cannot be controlled, the training received is necessarily less structured and more variable than that which would be presented in a training center. In many cases the pilots train themselves during unsupervised line operations. (Federal Aviation Administration, 2013, pp. 69, 71, 75)
In sum, training research describes stages of learning through which students transition from novice to expert. Experts form cognitive structures or mental models of domain knowledge with which they can automatically recognize and respond to novel situations. Deliberate practice can help students progress beyond high levels of achievement, which for some fields can require 10 or more years. Training sociotechnical system operators can enhance their ability to recognize and respond to unusual or unexpected situations, but training for this skill has been faulted for being too structured and predictable and less than fully effective in providing the expertise needed. Little research has been directed at training in responding to automation-related anomalies. An overview of studies of training is presented in Table 3.
Training-Related Studies
Note. CRM = crew resource management.
Discussion
Sociotechnical Systems, Operator Expertise, and Training
The repeated commission of identical automation-related operator errors indicates that deficiencies in automated systems persist and that their underlying causes have not been addressed. Researchers have identified adverse effects of automation that can lead to skill degradation (Bainbridge, 1983; Wiener & Curry, 1980), out-of-the-loop performance (Endsley & Kaber, 1999; Endsley & Kiris, 1995), difficulty recognizing and responding to system anomalies (Bainbridge, 1983), automation complacency (Parasuraman & Manzey, 2010), automation bias (Mosier & Skitka, 1996), and mode unawareness (Sarter & Woods, 1995, 1997), among other effects.
Over three decades ago, in an effort to address some of these outcomes, investigators of the 1984 DC-10-30 accident concluded that
there is an ever-increasing need to reemphasize to crews the need to effectively monitor critical flight instruments and systems. This requirement may be satisfied in part by [the] introduction of procedures and training specifically designed to enhance crew awareness of excursion from programmed performance. (National Transportation Safety Board, 1984, p. 40)
That the factors influencing the error that led to this suggestion have not, in the intervening years, been effectively addressed in the commercial aviation sector is evident in the subsequent accidents cited. Bainbridge’s (1983) discussion of degraded manual skills and inappropriate operator response to automation anomalies from extended automation use, among other insights, was manifested by the pilot errors in the 1984 accident and the two subsequent under-speed landing accidents cited.
But these accidents and their identical operator errors reveal something beyond altered operator–system relationships and automation design. For one, there is little agreement on methods to mitigate the effects of extended automation use on manual operating skills and on needed design improvements to operator–automation interfaces to enhance operator automation-related situation awareness. Some companies, in an effort to enhance operator automation-related performance, have attempted to adjust their operating procedures, as the National Transportation Safety Board had suggested in 1984, but there has been little research to establish how extensively operators should interact with automated systems to retain both the necessary automation-related situation awareness during system anomalies and the manual and cognitive skills they need to effectively respond to them. Some companies want their systems operated exclusively through the automation, whereas others do not. The airline involved in the San Francisco accident had its pilots use automation to the fullest extent possible, thereby, investigators believed, contributing to the accident pilots’ ineffective monitoring when the airspeed fell below that expected (National Transportation Safety Board, 2014), a belief supported by research on out-of-the-loop performance and degraded manual skills with extended automation use.
Further, as Degani et al. (2013) found, the presentation of automation-related information has been less than optimal. In unexpected situations, operators have to expend considerable effort to diagnose the cause of the situations encountered during times when workload requirements are such that they could least afford such effort.
The similarity of the errors in these automation-related accidents suggests, among other factors, the following:
Automated system functionalities that exceed operator needs
Interfaces that fail to effectively inform pilots of critical information
Training that fails to address demonstrated operator automation-related errors
Inadequate operator knowledge of system functionalities
Automation-related expertise levels among operators in sociotechnical systems, and in most systems requiring high levels of training, have not been established; operators are considered to be either qualified or unqualified in system operations, not necessarily automation operations. In initial training, operators typically transition from novice to qualified, with deliberate practice employed in actual or simulated systems to bring them to qualification level but not beyond.
Sociotechnical system operators typically achieve expertise when they can effectively conduct system operations unassisted. The training needed to reach this level is predicated upon available instructional/practice time, demonstration of proficiency, or both, depending on the system, the company, and the regulator. Once an operator is deemed qualified, companies rely on procedures and oversight, such as line operations safety audit (LOSA) in commercial aviation (International Civil Aviation Organization, 2002) safety management systems or other methods in other systems, to ensure that operators perform as required. However, as the Federal Aviation Administration’s (2013) review of automated aircraft found, operator training in aviation—a dynamic, sociotechnical system with highly automated subsystems—is largely directed at enabling operators to pass the checks needed to qualify to operate the system, not to gain automation expertise. There is little reason to believe that the required automation-related expertise level is different in other systems.
However, automated systems present challenges in that designers, companies, and, often, regulators must select between emphasizing operational skills and automation-related skills in operator training; training time and resource constraints rarely allow both. Because operational skills are considered critical, correctly so in most cases, proficiency in operating skills and not in automation skills primarily determines qualification. Expertise in automation skills, if obtained, is largely achieved after training, during actual system operations (Federal Aviation Administration, 2013).
In general, because of constraints, training either explicitly addresses automation-related design shortcomings by presenting “workarounds” to enable effective operator interaction with them or avoids them entirely, as illustrated by the failure of the designer and training developers to address the consequences of the operating mode that the B-777 pilots unexpectedly encountered in the San Francisco accident. But with the increasing functionality and complexity of automated systems, operators rarely complete training with the expertise needed to recognize and respond to the full automated capabilities of their systems. It appears that the discrepancy between the automation-related skills and knowledge addressed in training, and the expertise operators need to fully master automated system operations, has increased as automated system complexity and functionality have grown.
This automation-related system deficiency will likely continue until operators can acquire the necessary expertise, if not through training then through operating experience. However, in the absence of formal system training, some operators will be considered qualified without having acquired this expertise, such as was seen, for example, in the 2006 accident of a cruise vessel carrying 4,000 passengers and crew. Investigators determined that the captain and staff captain, the most senior licensed operators on the vessel, were unfamiliar with features of a highly automated integrated navigation system (INS), comparable to aircraft flight management systems, after they had completed INS training. They failed to recognize that the sea state did not match the requirements of the operating mode that they had selected and entered into the system, and they did not understand the need for the two to match. When they later transferred bridge control to another crewmember, he was out of the loop and unable to recognize and effectively respond to the effects of the operating mode that the senior crewmembers had executed, larger-than-expected bidirectional heading changes. As investigators wrote,
The Safety Board found shortcomings in training that may have contributed to the errors in INS use. . . . For example, under the current system, completing INS training does not assure mastery of the system because students are not required to demonstrate mastery of an INS at the completion of many formal INS training programs. Given the amount of information an INS can present and its many control and display options, a crewmember that completes INS training and then does not use the system on a vessel for several years may not remember much of the class material or be able to apply it. (National Transportation Safety Board, 2008, p. 48)
The mismatch between automated system capabilities, training to provide expertise in those capabilities, and training resources has largely led, among other things, to the following:
Priority given in training to system operations at the expense of automation operations
Automation expertise gained ad hoc, in real time, and in regular operations not conducive to training or to expertise acquisition
Limited opportunity for risk-free practice in diagnosing automated system anomalies or in responding to unexpected automation-related situations
Little assessment of operator automation-related situation awareness and diagnostic performance
Operators with automation knowledge and operating skills that may be inaccurate
Teams of operators with unequal automation-related expertise
Jamieson and Vicente (2005) suggested that human factors specialists contribute to automated system design to ensure, for example, that designs can enable operators to be consistently informed of operating mode changes to address some automation-related shortcomings (Sarter & Woods, 1995, 1997). However, even with human factors input into systems design, consequences of the automation-by-expertise-by-training interaction will continue to be unaddressed through system functionalities that exceed the expertise level that operators need or can master through their training. “If automation is to be used appropriately,” as Parasuraman and Riley (1997) wrote, “potential biases and influences on this decision should be recognized by training personnel, developers, and managers” (p. 238).
Further, as Casner et al. (2013) found, sociotechnical systems often present operators with a limited number of scenarios in training to prepare them to correctly diagnose and respond to anomalies, and when faced with scenarios not addressed in training, operators have difficulty diagnosing the situations. Because many, if not most, of the presented scenarios in training do not address automation anomalies, even should the automation functionalities match operator expertise levels, opportunities for operator errors when interacting with automated systems will likely continue to be unaddressed absent increases in training resources necessary to enable operators to master the automated systems.
As automated system functionality, complexity, and opacity have increased (Jamieson & Vicente, 2005), demands on training programs to enable operators to effectively master the automated systems have increased as well, but training resources have failed to match those demands. System designers and training developers may be working more, not less, independently of each other (Bauer, Newman, & Kientz, 2014), further exacerbating the automation-by-expertise-by-training interaction. Unless designers, trainers, regulators, and companies can address this interaction, operators are likely to continue to commit automation-related errors.
Metrics to Address the Automation-by-Expertise-by-Training Interaction
The expertise operators need to effectively operate sociotechnical systems is not analogous to that of Wayne Gretzky; they do not need to perform at the highest echelons of performance. Rather, they must have sufficient expertise to (a) operate systems effectively through routine and nonroutine operating phases and (b) diagnose the causes of and effectively respond to unexpected system phases and system failures. Designers that provide operators the automation-related functionalities to accomplish these skills effectively and efficiently will have met the design requirements for safe system operations.
However, the ironies that Bainbridge (1983) identified, the system opacity and mode awareness issues that Sarter and Woods (1995) pointed out, the feedback limitations that Norman (1990) and Jamieson and Vicente (2005) described, and the diagnostic difficulties Degani et al. (2013) identified suggest limitations in operators’ ability to obtain and maintain automation-related situation awareness. Without expertise in system monitoring, diagnosis, decision making, and executive control that Cellier et al. (1997) proposed, operators’ ability to obtain and maintain automation-related situation awareness will not be met. Providing automation functionalities beyond those operators’ need for safe and efficient system operations does not address this expertise and may actually detract from operator performance.
Addressing design shortcomings will mitigate many of the automation-related deficiencies that researchers and accident investigators have described. But the shortcomings will not be fully mitigated without designers and trainers collaborating on designs that operators can reasonably expect to master, that is, effectively operate unsupervised, through available training resources. Training programs that, as the Federal Aviation Administration (2013) described, expect that “much knowledge and skill development will continue after pilots [complete training and] begin flying the line” (p. 71) almost assure that operators will not have the necessary automation-related expertise, at the level needed for safe operations, after completing training.
Although operator-automation skill deficiency can be mitigated, up to a point, by forming operator teams according to automation expertise, to counterbalance those with weak automation skills with those possessing strong skills, such counterbalancing poses challenges. Researchers and system operators have not yet agreed upon acceptable levels of operator automation-related expertise to allow effective counterbalancing. Further, if such a metric was agreed upon, small companies with an insufficient number of available personnel to enable effective counterbalancing would likely have difficulty forming operator teams based on such criteria, and both large and small companies may be constrained by regulatory or employee contractual requirements to form such teams. Finally, without additional research, it is possible that the effects of such teaming on other team skills may create team deficiencies in other areas.
I suggest that to mitigate the automation-by-expertise-by-training interaction designers, training developers, regulators, and companies need to answer three questions:
What automation functionalities can designers provide?
Of those, what automation functionalities will operators need to master to effectively operate the system through the automation?
Of those, what automation functionalities can operators master through the available training resources?
To answer these, I recommend that in the earliest stages of automated equipment design, designers, trainers, companies, and regulators, establish the following automation-related metrics:
System automation functionalities
Operator expertise level necessary to identify, diagnose the causes of, and effectively control the system through the automation functionalities identified in (1)
Training resources sufficient to provide operators the knowledge and skills to achieve (2)
Operator automation-related knowledge and skills gained from participating in the training developed in (3) (see Figure 1)
The automation-by-expertise-by-training interaction.
As Figure 1 illustrates, automation functionalities matching the defined operator automation expertise levels should enable operators to effectively manage the system through the automation functionalities upon training completion. Expertise levels beyond what training programs can provide call for either increased training resources or functionality decreases. Unless the three elements are in balance regarding automation functionalities, necessary operator competencies, and available training resources, operators will not achieve automation mastery.
Developing and implementing these metrics require collaboration at the earliest stages of system design. The design process needs to be iterative, whereby, following expertise-level determination, both designers and trainers consider the expertise levels that can be achieved through the available training resources. As data are obtained, training resources can be increased or decreased and/or functionalities decreased to enable operators to become qualified in automation use.
Both the accident literature and the research literature suggest that operators use only a few of the available automation capabilities needed to achieve an acceptable level of operational efficiency, reliability, and safety (e.g., National Transportation Safety Board, 2008). Collaboration between designers, trainers, and customers (and regulators) should result in systems with functionalities that match the expertise levels operators need to master automated operations, so that operators can recognize and correctly respond to the situations encountered. The results of this collaboration should, in addition, avoid expecting operators to master automation functionalities after completing training, which increases the likelihood that automated features will be misused in system operations (Parasuraman & Riley, 1997) when such misuse can be most consequential.
Further, establishing, up front, operator automation-related expertise levels should be based upon the skill requirements of the “typical” operator that can be reasonably met during training. Major airframe designers in early phases of airframe (and engine) design currently collaborate with launch customers, who provide operational and maintenance personnel to work with designers. However, the expertise levels of the persons they provide may exceed those of the ultimate users because airlines tend to send management pilots and management maintenance personnel to such collaborative efforts. Many system operators may not have the same expertise as the management personnel, and hence, agreed-upon design features may call for expertise surpassing that of the “typical” operator.
Available protocols to determine expertise levels can be used to ensure that operators demonstrate adequate automation-related proficiency, at the defined expertise level, upon completing training. Expert panels, surveys, questionnaires, ethnographic studies, and empirical research can be used to determine the expertise level operators need to master the automation functionalities necessary for automated system operations. In addition, reliable and valid testing protocols have been used over time to assess effectively professional competency (Menges, 1975). Likewise, existing protocols can effectively discern whether operators can demonstrate the knowledge and skills needed to effectively operate automated systems. Regulators would then need to have these protocols applied to automated system operations.
Future Research
Research into the automation-by-expertise-by-training interaction is needed to define the metrics and establish the products of this interaction. At present, the suggested metrics have not been identified, and research is needed to do so. For example, regulators (or companies in systems in which the regulators have not done so) have determined the expertise that sociotechnical system operators need to demonstrate to effectively operate their systems. But there are few, if any, standards established for the skills needed for automated system operation at the expert or “qualified” level. The discrepancy between the expertise levels needed to operate systems through the automation and the automation capabilities the systems provide also has not been established. Researchers should, hopefully, identify automation capabilities needed for effective system operation but that remain within identified expertise levels.
Considerable research, as noted, has been directed at operator training, particularly in addressing unexpected situations. Nonetheless, although training directed at diagnosing automation-related anomalies has been undertaken, there is little consensus on the most effective way to achieve automation-related diagnosis mastery. Research and accident investigations (e.g., National Transportation Safety Board, 2012) have demonstrated that repeatedly presenting operators with similar anomalies in training may not necessarily prepare them to respond to other anomalies. Expecting operators to recognize, diagnose, and respond to automation-related anomalies, when little training has been directed at this skill, provides little reassurance that opportunities for errors in recognizing and responding to automation-related anomalies will be mitigated.
Further, the interaction of training needs with system functionality has not been studied. As the Federal Aviation Administration (2013) noted, designers have tended to favor the addition of features, with operators expected, during system operations, to master features not addressed in training. Yet, little research has been conducted to guide designers, regulators, and companies to determine the training resources needed to provide an acceptable level of automation expertise. Such research can help gauge the types and duration of training programs that enable novice operators to reach identified expertise levels of automation mastery.
Because operators are expected to recognize and respond to both automated and non-automated system anomalies, interfaces and functionalities that enhance system situation awareness need to be identified as well. While research has addressed optimizing operator-system interfaces, there is little agreement on interface design to enhance operator automation-related situation awareness.
A difficulty with conducting such research, however, is the limited availability of realistic automated system simulators. Consequently, semirealistic training scenarios using systems that can approach but may not replicate aspects of system operations under study may need to be used. Regardless, such research should employ subjects with backgrounds similar to those of the operators who will interact with such systems; otherwise, generalizability of the findings to sociotechnical system operations will be limited.
Given the potential challenges to using actual or simulated automated systems in empirical studies, researchers may find ethnographic research using observations of system operations and structured interviews of operators, designers, and trainers to be productive (e.g., Mumaw, Roth, Vicente, & Burns, 2000). Such an approach should recognize and address capabilities of automated systems, the needs of operators, and the constraints of operator training. Examining the efficacy of operator training to master various automation designs also calls for long-term studies to demonstrate the strength and duration of identified design and training effects. However, as Charness and Tuffiash (2008) observed,
It can be costly to make the necessary links between cross-sectional studies that identify skill differences (via novice-expert comparisons) and training studies that can be used to verify that the observed differences are essential to expert performance and that the appropriate skills and knowledge structures can be imparted efficiently. Longitudinal training studies may take more time and money than most engineering or usability labs can afford. Such problems pose significant challenges. (p. 431)
Studies in automation–operator interactions have addressed numerous design and automation issues that have contributed to operator errors. Over several decades, the work of accident investigators suggests that many of the research findings have not been incorporated into either design or training. Because much of the research has examined automation features and training programs independently, there has been little examination of how automation is used in actual system operations, the skill levels of the typical users in those operations, and the training program features that can best enable operators to meet those skill levels upon completing training. Better design and training integration, with clear delineation of necessary expertise levels, should lead to a decrease in automation-related operator errors.
Key Points
Despite considerable research in automation, identical automation-related operator errors continue to occur in sociotechnical systems. Designers continue to develop automated systems with functionalities that exceed those operators’ need to effectively operate the systems and with interfaces that hinder operator interpretation of automation-related information. Sociotechnical system operator training is too constrained in time and resources to provide operators the expertise needed to master the full extent of system automated capabilities. The interaction of system design and training, with the lack of identification of system capabilities necessary for expertise needed for effective automated system operation, has led to an automation-by-expertise-by-training interaction. This interaction has enabled automation-related operator errors to continue to be committed.
Footnotes
Acknowledgements
I thank Loren Grof and Evan Byrne for constructive comments on an early draft of this paper. The views expressed in this paper are those of the author and not necessarily those of the National Transportation Safety Board. This work is in the public domain of the United States because it is a work of the U.S. federal government under Title 17, Chapter 1, § 105, of the U.S. Code (as amended). I participated in the National Transportation Safety Board’s investigations of the Crown Princess accident and the pipeline rupture in Marshall, Michigan, as well as in its support of Aeronautica Civil of Colombia’s investigation of the Boeing 757 accident in Cali, Colombia.
Author Note:
The author of this article is a U.S. government employee and created the article within the scope of his employment. As a work of the U.S. federal government, the content of the article is in the public domain.
Barry Strauch is a national resource specialist–human factors at the National Transportation Safety Board. He received a PhD in educational psychology from Pennsylvania State University in 1975.