|
Article Excerpt
INTRODUCTION
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 (Hischhorn, 1984; Norman, 1990: Parasuraman, Molloy, Mouloua, & Hilburn. 1906).
The human factors response to automation has been hesitant, perhaps on account of the discomforting discrepancy between the advantages and disadvantages just noted. Automation technology seems to possess a momentum that cannot be deterred, not to mention controlled. The warnings of human factors professionals examining automation effects seem to go unheeded by control engineers swept up in the wave of microprocessor and software innovations that sometimes overwhelm concerns for human limitations. Control systems automation is the epitome of a technology-driven enterprise. To be sure, it has been very effective in achieving some of its goals. For this reason, it is difficult to question its application. However, a number of authors have pointed out that automation introduces problems of its own (e.g., Wiener & Curry, 1980). How can engineers be convinced that automation technology is a tool and not a panacea for human-machine interaction problems (Billings, 1997)? The ironic solution that we adopt in this article is to use automation designers' own language--control theory--to point out the role of human factors considerations in the design of automation.
Reviews of the evolution of automation in complex systems and of the empirical research on human interaction with automation are already available in the literature (Billings, 1997: Moray. 1986: Mouloua & Parasuraman, 1994; Parasuraman & Mouloua, 1996: Parasuraman & Riley, 1997; Sheridan, 1987, 2002; Wickens, Mavor, Parasuraman, & McGee, 1998; Wiener, 1985). The novel contribution of this article is a domain-independent, control-theoretic framework to investigate human factors issues in automation. We demonstrate that the framework provides critical insight into evaluating the design of existing automation interfaces in nuclear power plants. We also show the value of this generic framework by using it to critically review the literature dealing with mode proliferation, mode transitions, mode awareness, and mode error. Finally, the control-theoretic framework is used to propose a set of design principles that augment existing guidelines to more effectively contribute to the design process.
A CONTROL-THEORETIC FRAMEWORK FOR STUDYING AUTOMATION
Definitions
The following definitions will be employed in this article. In a departure from the journal's usual editorial style, these terms, and a few others, are capitalized throughout the manuscript to ensure that their use is not confused with other uses of the same or similar terms with which the reader may be familiar.
System: Plant + Controllers + Instrumentation + Interface.
Plant: Final Control Components + Process.
Final Control Components: controllable equipment that is used to influence a Process.
Process: the entity being controlled.
Controller: the automated means by which action is exerted on the Final Control Components.
Instrumentation: the means by which data about the Plant and Controllers are gathered.
Interface: Displays + Controls.
Displays: the devices through which Operators obtain information about the System.
Controls: the devices through which Operators take Action on the System.
Human Operator: the human actor who interacts with the System to achieve goals.
Note that the Human Operator has not been included within our definition of System, not because the Operator is outside our scope of analysis but because there is value in distinguishing the Human Operator from the System for the purposes of this article. Although the boundaries defined here can be difficult to establish in practice, they are conceptually useful because they facilitate an understanding of the nature of different types of Human-System interactions. The relationships among the defined terms, and the problems to which they are applicable, should become clearer as we place them in the context of a negative feed-back loop.
Negative Feedback Loop
Figure 1 presents a simple but conceptually powerful model of an automated System based on a standard negative feedback control loop (adapted from Wade, 1994). In this figure, boxes represent elements in the feedback loop and arrows denote signals between elements. The elements in the loop were defined previously, whereas the signals are defined in Table 1. The lower portion of Figure 1 is a traditional regulatory feedback loop composed of three distinct elements (the upper portion of the loop will be described later). If all of these elements are working as planned, then the behavior of the feedback loop can be described in a relatively straightforward fashion. Tracing through the diagram from left to right, the comparator subtracts the Feedback signal from the Set Point (i.e., the goal) to create an Error signal. This Error signal is sent to an automatic Controller that generates (via programmed logic) a Demand signal that is sent to the Final Control Components. The Final Control Components (e.g., a valve) map this Demand signal onto a change in the state of the Manipulated Variable (e.g., valve position), which then influences the Process itself, causing the Controlled Variable (e.g., flow rate) to change as well. The Instrumentation (e.g., a flow meter) gathers information about the Controlled Variable and feeds it back to the comparator.
[FIGURE 1 OMITTED]
The upper portion of Figure 1 serves as a placeholder for the Interface and the Human Operator, two elements that play a key role in feedback control loops that are not fully automated. Moving from right to left, Sensed data signals are fed into the Displays element and Displayed to the Human Operator. The Operator takes Action by manipulating the Controls in the Interface, which generates a Command signal. The connections between the upper portion of the figure and the rest of the feedback control loop (i.e., which signals serve as inputs and which as outputs) cannot be described generically because there is no process that is agreed upon by automation designers for identifying which connections are required. Connecting the upper and lower portions of Figure 1 involves making a set of design decisions (see Table 1). One of the contributions of this article is to propose how these decisions might be made.
Thus far, our discussion of the negative feedback loop has been abstract because control theory is a generic language for describing the behavior of dynamic systems. In fact, this is one of its primary advantages. It provides a well-defined set of concepts that are applicable to diverse application domains. In process control, aviation, and elsewhere, both qualitative and quantitative applications of control theory have been a feature of human factors for decades (e.g., Rouse, 1980; Sheridan & Ferrell, 1974). However, the framework may be of limited value in the treatment of asynchronous control problems, such as those encountered in tactical decision making, which may not be well characterized by a standard negative feedback control loop. Also, the mathematical formalisms of control theory are not yet sophisticated enough to comprehensively account for human cognitive processes (Bainbridge, 1981). Nevertheless, as we will show in the remainder of this article, the qualitative application of control-theoretic concepts can provide a valuable and unique set of insights that have not yet been fully drawn in the literature.
Implications
Although control engineers will find our feedback model oversimplified, it serves to make five important points. First, four different elements must be distinguished conceptually: the automation, which is the Controller, the Final Control Components that the automation acts on, the Process itself, and the Interface that (nominally) allows the Human Operator to monitor and manipulate the rest of the elements. Frequently, researchers do not discriminate clearly and consistently among these elements. A common approach is to use the catch-all label, system. In some cases, system seems to mean automation, whereas in other cases it seems to include the Final Control Components and the Process together. Furthermore, in some cases, it seems that authors inadvertently switch between these two uses of the term system in the same publication. We say that this seems to be the case because we can make only inferences based on the surrounding text; a definition of system is rarely given.
The second implication is that a failure can occur in different System elements. For example, it is possible for malfunctions to occur in the Controller, the Final Control Components, or the Process. These are qualitatively different events that may require different types of Operator Actions (e.g., turning off the automation vs. isolating the failed component vs. shutting down the Process). If only the catch-all term system is used, then it will be possible to say merely that there is a problem "somewhere." It will not be possible to localize the problem to a particular element and act accordingly.
Third, if it is important for the Operators to discriminate among the different types of failures just described, then all of the signals in the lower portion of Figure 1 should be available in the Interface (although not necessarily always or simultaneously). For example, to determine if there is a problem with the Controller, Operators should know what the current Error signal is, know what the current Demand signal is, and then use their knowledge of how the Controller is supposed to work to determine if the Demand is what it should be, given the current input to the Controller. If any one of these elements is not displayed or known, then the problem is formally underdetermined and, thus, cannot be solved, whether it be by a human or machine actor. The use of a normative model (in this case, of the Controller) to check if the System element is behaving as expected is known as analytical redundancy, a well-accepted technique in control theory (Frank, 1990). The same general approach can be applied to other System elements. For example, if the Demand signal being fed to the Final Control Components by the Controller and the actual value of the Manipulated Variable are known, then knowledge of how the Final Control Components are supposed to work can be used to see if these elements are responding as they should. This type of analytical redundancy comparison can also be made for the Process by comparing the current Controlled Variable value with the expected value, given the current Manipulated Variable acting as a signal input to the Process.
If any one of these signals is not available, then it will not be possible to determine precisely where the problem is. Note that this is not an empirical issue. There is no need to conduct experiments because the problem is not an incompatibility with human capabilities and limitations; rather, the problem is that human or machine actors would be faced with an underdetermined task (Degani & Heymann, 2002). For example, if the Controlled Variable does not match the goal Set Point, one cannot know if it is because (a) the Controller is sending appropriate Demand signals but the Final Control Components are not responding as they should (e.g., an actuator failure); (b) the Final Control Components are functioning properly and are merely reacting to inappropriate Demand signals from a faulty Controller (e.g., faulty control logic); or (c) both the Controller and Final Control Components are behaving properly, but there is a fault in the Process (e.g., a leaky tank). Later in this article, we show that some automation interfaces suffer from this problem. Thus the control-theoretic framework in Figure 1 has important implications for design.
Fourth, the same Plant can be regulated by one of many different Controllers. Thus, the design of the Controller need not be taken as a given but can, instead, be seen as an element that should be specified by taking into account, among other things, human factors considerations (Leveson & Palmer, 1997: Riley, 1996, 2001; Vicente & Rasmussen, 1990). This perspective differs from lime traditional view that time design of automatic Controllers is strictly a technical issue that must be resolved before human factors professionals can start their job of Interface design (see Vicente, Christoffersen, & Hunter, 1996).
Fifth, and finally, the internal structure of the Controller is different from the internal structure of the Final Control Components or of time Process. Thus when researchers recommend that Interfaces be designed so as to make the "system" transparent, it is not clear what this really means. For example, a visualization of the Controller will look very different from a visualization of the Process. After all, the former is the element doing the controlling, whereas the latter is time element being controlled.
In summary, the control-theoretic framework in Figure 1, although simple, leads to...
|
