A direct methodology to establish design requirements for human–system interface (HSI) of automatic systems in nuclear power plants

Annals of Nuclear Energy 63 (2014) 326–338

Contents lists available at SciVerse ScienceDirect

Annals of Nuclear Energy journal homepage: www.elsevier.com/locate/anucene

A direct methodology to establish design requirements for human–system interface (HSI) of automatic systems in nuclear power plants Nuraslinda Anuar, Jonghyun Kim ⇑ KEPCO International Nuclear Graduate School, 1456-1, Shinam-ri, Seosaeng-myeon, Ulju-gun, Ulsan, Republic of Korea

a r t i c l e

i n f o

Article history: Received 10 April 2013 Received in revised form 17 June 2013 Accepted 16 July 2013

Keywords: Automation Human–system interface design guidelines Itemized Sequence Diagram Human–system interaction

a b s t r a c t This paper suggests a systematic approach to establish design requirements for the human–system interface (HSI) between operators and automatic systems. The role of automation in the control of a nuclear power plant (NPP) operation is to support the human operator and act as an efficient team player to help reduce the human operator’s workload. Some of the problems related to the interaction between the human operator and automation are out-of-the-loop performance, mode errors, role change to supervisory role and final authority issues. Therefore, the design of HSI is critical to avoiding breakdowns in communication between the human operator and the system. In this paper, the design requirements for human–system interface of automatic systems are constructed with the help of a tool called Itemized Sequence Diagram (ISD). Eight levels of automation (LOA) are initially defined in the function allocation and an ISD is drawn for each of the LOA for task allocation. The ISD is a modified version of sequence diagram, which is widely used in systems engineering as well as software engineering. The ISD elements of arrows, messages, actors and alternative boxes collectively show the interactions between the control agents, which are decomposed into four different roles: information acquiring, plant diagnosing, response selecting and response implementing. Eleven design requirements to optimize the human–automation interaction are suggested by using this method. The design requirements produced from the identified interaction points in the ISD are rationalized and how each requirement addresses the issues related to automation is discussed. We also identify which requirements address which of the stated automation issues and at which operational process stage each requirement applies to. Finally, the strengths of the proposed methodology and its implication on the HSI design are discussed in comparison with the methodology used to produce the existing guidelines or guidance. Ó 2013 Elsevier Ltd. All rights reserved.

1. Introduction Automation plays a huge role in nuclear power plants (NPPs) and other complex industrial processes that require a high degree of accuracy, or involve tasks that are beyond the capabilities of humans in terms of the time taken to execute certain task. Most of the control systems in the NPP have automatic features: the pressurizer pressure control, reactor control system, safe shutdown system, engineered safety features actuation system, steam generator level control system and so on. The need to improve reliability and safety of the operation of a NPP has led to an increased demand for using automation in the overall NPP operation. Nevertheless, maximizing the use of automation will not serve as the silver bullet to prevent accidents from happening. Despite

the advantages of utilizing automation in NPP operations, there are open issues concerning the use of automation. One of the main issues is the interaction between the human operator and the automation,1 which has shown to be problematic due to the inadequate design of system for the human–system interface (HSI) (Kim and Seong, 2009). The development and introduction of automation in industrial processes are intended to improve the precision and economy of operations. However, the inclusion of automation as one of the team members in the operation has proven to cause some unexpected problems. This is mainly due to the fact that an automated system is partially autonomous and mostly inadequately designed to support the human operator in critical conditions (Sarter et al., 1997). HFE issues in the use of automation have been frequently raised in the literature. Those issues are well summarized in (Kim and

⇑ Corresponding author. Tel.: +82 52 712 7311. E-mail addresses: [email protected] (N. Anuar), [email protected] (J. Kim). 0306-4549/$ - see front matter Ó 2013 Elsevier Ltd. All rights reserved. http://dx.doi.org/10.1016/j.anucene.2013.07.022

1

The word ‘‘system’’ and ‘‘automation’’ are used interchangeably in this paper.

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338

Seong, 2009; Sarter et al., 1997; Lee, 2006). The important issues related to the human–system interaction in automation are introduced as follows. One important aspect that has contributed to automation issues is the problem of understanding automation behavior (Sarter et al., 1997). The use of automation in NPP operation has resulted in coordination and communication demands. Inefficient interaction between the human operator and the system can result in difficulty for human operator when taking over control of the operation because of a lack of understanding of automation behavior. This situation is also known as the out-of-the-loop (OOTL) performance problem (Kaber and Endsley, 1997). The OOTL performance problem is also related to a lack of information on automation activities. The lack of observability of the system may also result in loss of situation awareness (Skjerve et. al, 2011). This issue becomes apparent when an operator’s intervention into the process control is necessary, e.g., in response to an abnormality in an automated action. The second issue is that designers tend to make the system have multiple modes, causing increased complexity and longer time constant feedback loops. This issue becomes more probable as systems become more advanced and are capable of executing more simultaneous tasks. This increased autonomy may produce a situation in which mode changes can occur based on situation and system factors without any direction from operators. This may in turn result in an increased possibility of mode errors for operators (Lee, 2006). The third issue is the change of the operator’s role from a manual controller to a supervisor. Creating autonomous machine agents does not eliminate tasks from operators, but changes the operator’s role in the control process. When the automation no longer handles the situation, the operator needs to take over the control from the automatic systems. In order for the transfer to be smooth, the operator needs to be aware of the problem and to fully understand the evolution of automation’s execution. However when the system is automated, the main tasks of operators are changed to supervising and coordinating the automated machine agents that were previously on manual mode. Therefore, automation does not really reduce the workload of operators but instead, requires the operators to have new roles, namely supervising and coordinating (Sarter et al., 1997). The fourth issue is the authority of ultimate decision. This is noteworthy especially in NPPs, since an operation may directly or indirectly influence the safety of the NPP. It is desirable that the authority of operational decision that may affect safety to be assigned to operators in the NPPs. This issue is also related to the LOA of the system, since the LOA determines who has the authority for the instruction, redirection, and override, if necessary, between the operator and the automation (Kim and Seong, 2009). The issues addressed above are not independent of each other (Lee, 2006) and one problem may lead to another. For instance, a lack of information on automation activities, i.e., the first issue, may increase the possibility of mode error, i.e., the second issue, because it makes the operator become unaware of the mode change and the activities executed by automation. It has been reported that inadequate design of the HSI for automatic systems may cause an undesired event in NPPs (Anuar et al., 2012; OPIS, 2004). However, the existing human factors engineering (HFE) guidelines that are widely used in the NPP design (U.S. NRC, 2002; EPRI, 2005) do not sufficiently deal with the HSI design for automatic systems. The guidelines do not explicitly say when each guideline is appropriate and which level of automation (LOA) each guideline applies to. Therefore, designers can have difficulties in applying these guidelines to the HSI design. This paper suggests a method for establishing HFE design requirements for the HSI design of automation that address the

327

existing automation issues relating to the interaction between the human operator and the system. The design requirements are identified by using a systematic approach, namely, function allocation and task allocation. Fig. 1 shows the steps of the proposed approach. For the function allocation, we define a set of LOAs through the four operational process stages in the control operation of a NPP: information acquisition, plant condition diagnosis, response selection and response implementation. This is to identify which control agent is responsible for each of the stages in each LOA. For task allocation, we use an Itemized Sequence Diagram (ISD) to model the interactions between the human operator and automation for each LOA. Then, the design requirements for the HSI of automation are suggested by referring to the produced ISD. How the suggested design requirements address the HFE issues of interaction related to automation is discussed in Section 5. The strengths of the suggested approach (function allocation by defining LOA and task allocation by using ISD) are also discussed in the Discussion section, as some of the missing information in the existing guidelines is identified. 2. Defining the levels of automation: function allocation The LOAs that are relevant to the automatic system and automatic operation in NPPs are defined as a result of performing function allocation. Functions and tasks that are required of human operators and automatic systems are different depending on the LOA applied. Accordingly, the HSI design in the main control room differs according to the LOA adopted in the systems, because different functions and tasks require different types of information and control to be provided to the operator. The aim of defining the LOA is to identify functions and high level tasks that need to be assigned to each of the control agents, namely the human operator and the automation. 2.1. Operational process stages The control process of NPPs can be divided into four different stages. In general, the control process starts with information acquisition, plant condition diagnosis, response selection and response implementation. Each of these functions can have different levels of automation (Sheridan and Verplank, 1978). Information acquisition could involve raw information or/and processed information. The operator can obtain raw information directlyfrom the process system or obtain processed information through the HSI. The automation can obtain the raw information from the process system and then display the processed information on the interface to the operator. The activities included in the information acquisition stage are collecting process parameters, grouping the information, marking the necessary information and recognizing the required parameter values. Plant condition diagnosis also can be done by either human operator or the automation. The human operator uses cognitive abilities to evaluate the plant condition. Diagnosis by automation requires an algorithm that is able to carry out the cognitive activities, evaluate the plant conditions and suggest its results to the operator. In this operational process stage, the main activity is to compare the process values or stability parameters with those of the required values to ensure that the systems are in a stable condition. For example, in the control of the steam generator level, the control agent has to check if there is any difference between the level readings of the two steam generators because both steam generators are required to have the same required level. Should there be any discrepancies, the control agent should diagnose the situation and try to determine the cause of the discrepancy and take the next necessary action.

328

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338

Fig. 1. A summary of procedure of how the requirements were established.

Following the diagnosis, the operator or automation then needs to select the appropriate response. For operators, the response comes from a list of procedures that must be followed to ensure that a certain goal is achieved safely. On the other hand, automation can suggest to the operator the procedure that would be necessary to cope with the instability. Therefore, the main activity in the response selection stage is to figure out which procedure should be selected based on the diagnosis results from the previous stage. The human operator has the final authority to choose the necessary response and automation serves as a support by suggesting the relevant response to the human operator. In the response implementation stage, the execution of the steps that are listed in the chosen response could either be done by the human operator or the automation. In the modern control room, the execution of the selected response can be done by the human operator through soft controls, where the control input entry is done with software as the delivery medium instead of using the traditional hard-wired devices (switches, buttons, etc.) that represent only a single function (Stubler et. al, 2000). The implementation of the selected response can be done by automation with the consent of the human operator. Therefore, the main activity in the response implementation stage is the execution of the required steps as laid out by the selected procedure in the previous stage. 2.2. Level of automation classification This paper focuses on the interaction between a human and automation in systems operation. According to Endsley’s taxonomy, control processes can be done by (1) a human, (2) automation, or (3) a combination of human and automation. By having these three possible control agents, Endsley came up with ten distinctive levels of automation (Kaber and Endsley, 2003). The definition of LOA starts from the information acquisition stage; therefore a human as the only control agent in the information acquisition stage is not considered in our work. This allows for the ten LOA defined by Endsley to be reduced to a smaller number, which is eight. These eight levels have a human operator as the control agent that has the final authority over the decision making of control process in the NPP. The process of defining the LOAs starts from the information acquisition stage, which is assigned to a human and a computer as the control agents. The level of automation is further divided into a few groups by assigning either a human or a human and automation as the control agent in the plant condition diagnosis stage. Logically, the human cannot make a selection if he/she does not make any plant condition diagnosis. Therefore, in the diagnosis stage, a human operator must be present as a control agent. Fig. 2 shows the decision framework based on (Lin et al., 2008) that is used to determine the LOAs. The optimization between human actions and automation to achieve desired level of safety may be attained by first defining the safety functions of the system of interest. For the safety func-

tions definition, function allocation needs to consider several aspects to increase the plant safety. The function allocation is governed by regulatory constraints (e.g., 10 CFR 50), which take into account the error and reliability probabilities in the NPP operation. Along with the need to comply with these constraints, function allocation is also performed based on the reference plant, in which the operating experience can be examined for further improvement of the HSI design (O’Hara et al., 2002). The capability of human and automatic systems for performing the safety functions should also be taken into account by distinguishing what are the tasks that humans are better at and what are those that machines are better at. It is important to understand that automation can only be fully utilized in the implementation stage and manual action by a human operator must exist in stages that require cognitive activities such as diagnosis and response selection stages. This is because of the fact that some functions or tasks require certain level of reliability, consistency and accuracy that is almost impossible for human operator to perform, and that the system can only be programmed to a certain extent that human reasoning is much superior and effective in some situations. Therefore, optimization of human actions and automation is then possible by applying these rules of function allocation in order to ensure acceptable level of safety. This paper has identified a set of LOAs based on the previously discussed procedure. In the high level definition, there are three main groups of levels of automation: human dominance, automation support and full automation. Table 1 shows the LOAs in each group and each of the LOAs is briefly described as follows. Manual Control has both human and automation as the control agents in the information acquisition stage. In the rest of the consequent stages, human is the only control agent for this LOA. Automation’s role in this LOA is to only provide the processed information to the human operator in the information acquisition stage. Action Support has the combination of human and automation as the control agents in the implementation stage, and Batch Processing has the automation as the control agent in the implementation stage. The control agent for the plant condition diagnosis and response selection stages for both Action Support and Batch Processing LOA is the human operator. Both human and automation are the control agents in all of the stages in Blended Operation. Blended Decision Making is similar to Blended Operation, except for the implementation stage where the control agent is automation. Human and automation have the responsibility in the control of operation in diagnosis and implementation stages and only the human is responsible in the response selection stage for Shared Control. The same goes for Decision Support, except for the implementation stage where only automation has the responsibility in the control. In Full Automation, automation is the only control agent that is responsible for making decisions and executing tasks. However, all

329

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338

Fig. 2. The process of defining the levels of automation using LOA decisions framework.

Table 1 The levels of automation defined in this paper. Group

Level of automation

Information acquisition

Plant condition diagnosis

Response selection

Response implementation

Human Dominance

Manual Control Action Support Batch Processing Blended Operation Blended Decision Making Shared Control Decision Support Human/Automation

Human/Automation Human/Automation Human/Automation Human/Automation Human/Automation Human/Automation Human/Automation Automation

Human Human Human Human/Automation Human/Automation Human/Automation Human/Automation Automation

Human Human Human Human/Automation Human/Automation Human Human Automation

Human Human/Automation Automation Human/Automation Automation Human/Automation Automation

Automation Support Automation Support

Full Automation

the control process activities by automation are subject to the consent of the human operator. Hence, the human operator must monitor automation throughout the entire control process.

3. Modeling human–system interaction with the ISD: task allocation After the LOAs have been determined and defined, an Itemized Sequence Diagram (ISD) is constructed for each of the LOAs. An ISD is a modified and more detailed version of the existing sequence diagram, which is one of the Unified Modeling Languages (UML) created by Object Management Group (OMG) (Micskei and Waeselynck, 2008). As an illustration, this section uses Blended Operation LOA for the process of design requirements establishment because this LOA contains the largest number of interactions between the human operator and automation compared to the other LOAs. This can be confirmed by looking at Table 1, which shows that Blended Operation LOA has both human and automation as the control agents for all of the operational process stages.

3.1. Introduction to ISD The basic elements in a sequence diagram are the actors, arrows, messages and alternative boxes. Actors are entities thathave certain roles in a particular process. The arrows represent the information being exchanged between the actors. Messages are the labels of the arrows, which usually start with a verb, describing a task that is related to the information being exchanged. An alter-

native box contains a process or an interaction that is optional or abnormal to the control process of interest. In general, there are four actors in modeling the operation of a NPP, namely, the human operator, the system (automation), the interface and the process system. Two of the actors are the control agents, which are human operator and automation. It is worthwhile to note that an actor is not necessarily a control agent, but a control agent is always an actor in the model. The typical sequence diagram shows the flow of information between the four actors as depicted in Fig. 3. However, in the ISD of the human–system interaction in an automatic system, each of the control agents is divided into four smaller roles: information acquiring, plant diagnosing, procedure selecting and procedure implementing. Compared to the typical sequence diagram, the ISD contains ten actors; eight of them are control agents as shown in Fig. 4. Color coding is introduced for the purpose of grouping the actors according to the control agent role that they play. The vertical bars represent the activated role that actors play and vertical lines mean that the actor of that particular role is not activated in the process. Red bars belong to ‘‘human operator’’ actor, green bar belongs to the ‘‘interface’’ actor, blue bars belong to ‘‘automation’’ actor, and purple bar belongs to ‘‘process system’’ actor, An example of an ISD is presented here for the interaction between a human operator and automation in the control of a pressurizer pressure. An increase in pressure can be achieved by supplying electrical power to the heater inside the pressurizer, while the decrease in pressure can be achieved through water spray nozzles in the upper part of the pressurizer and by cutting the power supply to the heater.

330

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338

Fig. 3. The typical sequence diagram for Blended Operation level of automation.

Fig. 4 shows the ISD for the interaction between human operator and automation in the control of a pressurizer pressure. This example models the interaction between the control agents in the following situation. The system would increase the pressurizer pressure from 1000 psi to 1500 psi after the operator inputted the setpoint of 1500 psi to the system. The operator then inserts a new setpoint of about 1300 psi to the interface and automation would then need to reduce the pressure to 1300 psi. The ISD in Fig. 4 starts with the process system providing current pressure of 1000 psi to the interface, which would then deliver the information to the operator. The arrow from the process system is labeled with ‘‘sends current pressure 1000 psi’’ and the arrowhead points to the interface. This shows that the process system provides some specific information to the interface. Next, from the interface, the arrow is labeled with the same message and the

arrowhead points to the operator of the information-acquiring role. The parties involved in a particular process can be determined by identifying the actor at the beginning and the endpoint of the arrow that carries the message on the type of task that is being executed. For example, the arrow labeled with ‘‘sends D pressure needed’’ that connects automation of diagnosing role to automation of response implementing role. In this particular process, we can know that there is an interaction or an exchange of information between the two roles that automation plays, which are diagnosing and response implementing roles. Generally, the sequence of reading a sequence diagram would be from the top to the bottom, following the direction of the arrows. Usually the arrows that are situated at the top would mean that the activity is done prior to those below them. However, in

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338

331

Fig. 4. The Itemized Sequence Diagram for pressurizer pressure control.

some situations, two adjacent arrows that have the same starting point could mean that the activity is done at the same time. For example, there are two arrows that are labeled ‘‘sends current pressure 1000 psi’’, one points towards the interface,

and the other points towards the automation of information acquiring role. This does not mean that the information is provided to the operator first, and then to the system. However for the arrow with ‘‘sends current pressure 1500 psi’’ message

332

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338

from the process system to interface, the task is done at a much later time compared to the task represented by ‘‘sends current pressure 1000 psi’’ arrow. This is because they are not adjacent to each other and that there are other interactions going on between the two arrows. By following the direction of the arrows in the alternative box in Fig. 4, it can be seen that the control process starts with the process system sending current pressure measurement to the operator through the interface. The operator then inputs a setpoint of 1500 psi to automation, and automation of diagnosing role evaluates how much pressure is needed and sends the information to automation of implementing role. A signal is then sent from automation to the process system to power up the heater in the pressurizer. The process system then provides the status of heater and current pressure to the operator through the interface. There are also alternative boxes in the ISD, which show the sequence of activities for optional tasks or abnormal situations. These optional tasks are usually for the purpose of monitoring automation, in which the operator requests the technical basis of automation actions in order to validate the actions. An alternative box could also show the activity sequence when instability or automation failure occurs. In the case of the pressurizer pressure control example, the alternative box encapsulates the interactions when the operator introduces a new constraint to the control process, which is a lower pressure setpoint. The arrows and the labels of the arrows define the tasks for each of the control agents. When drawing and labeling the arrow, the objective of drawing the ISD should be kept in mind, which is the optimization of the human and automation interaction in the control process of the NPP operation. Questions such as ‘‘how to make sure that the operator will not get confused by automation action?’’ or ‘‘what should be done to avoid miscommunication between the control agents?’’ definitely help in drawing the arrows and labeling them. Hence, task allocation can then be done by completing the ISD, as the task allocation information is contained in the arrows and their labels in the ISD. The ISD is drawn to reflect how the interaction between control agents should ideally be. If the actual interaction in the control room were to be modeled, it would then not be possible to derive the correct and useful design requirements for the HSI design because there are flaws in the actual human–system interaction. Since ISD is not a simulation tool, it cannot be tested for correctness. In fact, it is actually a design tool that is used in the design phase, which has the function requirements as the input items. These function requirements are derived from user requirements, which are the high-level requirements that need to be fulfilled in product development (Hull et al., 2011). There are two possible ways to verify the correctness of the ISD model. One of the ways is by performing traceability analysis in which the ISD is checked against the function requirements that the ISD model was built upon. Another way to verify the correctness is by moving onto the next phase, which is the design implementation phase, and build the prototype based on the ISD so that testing activities can be conducted. The feedback from the tests can then be used to verify the correctness of the ISD model.

Since the human operator is not the only control agent in the Blended Operation LOA, another arrow is drawn from the process system to automation, and the self-directed arrow is drawn to automation, before another arrow that represents the processed information is drawn from automation to the interface. An arrow is then drawn from the interface to the human operator to represent the processed information. In the plant diagnosis stage, an arrow from automation of acquiring role is drawn to automation of diagnosing role with ‘‘uses info to diagnose’’ label. A self-directed arrow is then drawn on the vertical bar of diagnosingautomation to represent the diagnosing process. The result of the diagnosis is then used to assess the responses, which is represented by the arrow from diagnosing automation to selecting automation. This arrow is labeled with ‘‘assesses the responses’’ and another arrow with a message of ‘‘displays diagnosis’’ is drawn pointing to the operator through the interface. A similar process of drawing the arrows is done for human operator role of diagnosing. Basically, the same procedure is done for the rest of the stages. In between each of operational process stages, an alternative box of ‘‘automation monitoring’’ is inserted to model the interaction activities when operator requires the technical basis of automation actions from the system. At the end of the ISD, another alternative box that contains the interaction between actors in times of instability or automation failure is also included. This involves the interaction during control mode change in the control process. The final completed ISD for Blended Operation LOA is shown in Fig. 5.

4. Design requirements for the HSI of automation in NPPs This section suggests the design requirements for the HSI of automation in NPPs by applying the proposed systematic approach. The points of interaction between the human operator and the automatic system are identified in the ISD, which are located on the HSI (green vertical bar in Fig. 5). The information that is required at the points of interaction has been identified to be the focus for the construction of the requirements. Based on the flow of information through the interface, requirements that are deemed to optimize the interaction and communication between the human operator and the systems were established and rationalized. The graphical summary of the procedure on how the requirements were established is shown in Fig. 1. In order to accomplish the objective of ensuring that the interaction between the human operator and automation is as efficient as possible, the following requirements are constructed based on the discussed existing pitfalls of automation and the ISD, which describes the processes in the operation of the NPP. The rationale and how the requirements were established are also discussed. Table 2 shows the summary of which requirement is applicable to which LOA and Fig. 6 shows the interaction points at which each requirement is derived from.

3.2. The procedures of drawing an ISD

4.1. The HSI for automation should be designed in such a way that human operator would have easy and supported access to raw information and processed information

The modeling of human–system interaction by means of an ISD is described as follows. The ISD for a LOA is drawn by first choosing a LOA. Blended Operation is chosen for the purpose mentioned previously. The flow of information starts from the process system in the information acquisition stage; hence an arrow that represents raw information is drawn from the process system to the interface. Another arrow that represents raw information is then drawn from the interface to the human operator.

This requirement is applicable to all LOAs. The raw information or measurements from the process system may be needed for two purposes. First, this raw information is fundamentally important for the operator to monitor and control the system. Second, the operator may use the raw information to verify the processed information by the automatic system. In the ISD (Figs. 5 and 6), this raw information is depicted by the direct arrow from the process system to the operator through the HSI.

333

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338

Fig. 5. The Itemized Sequence Diagram for Blended Operation level of automation.

Table 2 The summary of the requirements and the applicable LOA for each requirement. Number

Requirement

Applicable LOAs All

2

The HSI for automation should be designed in such a way that human operator would have easy and supported access to raw information and processed information The HSI should provide the automation diagnosis results to the operator

3

The HSI should display the suggested response

4 5 6

The HSI should show the technical basis of each of automation’s activities to the operator whenever requested The HSI should allow for the human operator to input the request for additional information to automation The HSI should receive a response selection or change in response selection by the operator and send the selection to the system The HSI should send automation’s request for human operator approval to implement some tasks, receive the approval and send the approval to the system The HSI should display the progress and status of implementation The HSI should display the stability parameters for automation failure detection and the possible need for manual control notification The HSI should provide the means for take-over from automatic control to manual control The HSI should present the current control mode and the transition between automatic control and manual control to the human operator

1

7 8 9 10 11

All except for manual control, action support and batch processing Blended operation, blended decision making and full automation All All All except for full automation Action support, blended operation and shared control All All All except for manual control All except for manual control

334

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338

Fig. 6. The interaction points at which each requirement is derived from.

The processed information supports the human operator by reducing the workload of the human operator, since the human operator would not need to process the raw information manually and just uses the processed information to diagnose and monitor plant conditions. Automatic systems may gather and integrate the information that is spread in many places in the plant. This processed information is either provided for the information acquisition stage for operators or used for the subsequent process stage. The information processing by automation is represented by the self-directed arrow on the information acquiring role of the automation in the ISD. The HSI needs to present the information processed by automation to the operator. The delivery of processed information through the HSI is shown by the ‘‘displays processed info’’ arrow from automation to the HSI and then from the HSI to the human operator, as shown in Fig. 5 or Fig. 6. The HSI may be designed to either continuously display the raw and processed information or provide the information when the operator requests for it. For the latter design, the HSI should then allow the operator to request for the information to be displayed.

4.2. The HSI should provide the automation diagnosis results to the operator This requirement is applicable to all LOAs except for Manual Control, Action Support and Batch Processing. In addition to processing raw information, the automation diagnosis can support the operator’s diagnosis activity. The diagnosis results can be used for either as guidance and suggestion for the human operator or for verification by checking if the human operator’s diagnosis result is similar to that of the automation. The automation diagnosis results need to be displayed to operators. Whether the results should be displayed always or only by request from operators depends on the purpose of acquiring the information. The information flow on automation diagnosis is shown in Fig. 5 or Fig. 6 with the arrows from diagnosing role of automation to the interface and finally to the human operator, labeled ‘‘displays diagnosis.’’ This shows that the HSI should be designed to act as an intermediate point for automation to send its diagnosis results to the human operator.

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338

4.3. The HSI should display the suggested response This requirement applies to Blended Operation, Blended Decision Making and Full Automation LOA. In those LOAs, the automatic system chooses adequate responses based on its diagnosis results. The HSI ability to display the suggested response or procedure provides the support for the human operator in selecting a suitable response based on diagnosis results. This requirement is represented by the flow of the selected (suggested) procedure from the selecting role of automation to the human operator through the interface in the ISD (Figs. 5 and 6). This shows that the HSI design should display the suggested procedure either by default or by request from the human operator.

4.4. The HSI should show the technical basis of each of automation’s activities to the operator whenever requested This requirement is applicable to all LOAs. The human operator needs to check if the processed information, diagnosis or response selection is done correctly by automation from time to time. The ability of the HSI to provide the human operator with the technical basis of automation’s results on analyses or diagnoses supports the human operator in ensuring the system’s reliability and observability. The ability for automation to provide the technical basis of its analysis results allows the human operator to understand the behavior of automation. Understanding automation’s behavior is helpful to the human operator in managing any instability or automation failure as necessary. In the ISD (Figs. 5 and 6), the operator’s request for the technical basis of each of automation’s activities is represented by the alternative boxes, labeled ‘‘automation monitoring (optional).’’ The HSI should be designed to support the function of the receiving human operator’s request for the technical basis and displaying the requested technical basis. Table 3 shows examples of information that might be supplied to the human operator, based on the ISD of Blended Operation LOA.

4.5. The HSI should allow for the human operator to input the request for additional information to automation In connection with Requirement 4, the HSI should provide the means for the operator to request additional information from automation. This requirement is applicable to all LOAs.

335

4.6. The HSI should receive a response selection or change in response selection by the operator and send the selection to the system This requirement is applicable to all LOAs except Full Automation. It is assumed that the ultimate decision in operation, i.e., response selection, is the responsibility of human operators, once the operators are involved in the operation. This assumption was made by taking intoaccount the actual operation practice in NPPs. Based on this assumption, the HSI needs to receive input selections by a human operator to instruct the automation on the responses that need to be taken to achieve the goal of the selected response. The interface also must be able to send the selection to the system in order for the system to process the selection and execute the necessary next step to achieve the required goal. This requirement is shown in the ISD (Figs. 5 and 6) as the operator inputs the selected procedure (response) to the interface and the interface then conveys the selection to the system to be processed. 4.7. The HSI should send automation’s request for human operator approval to implement some tasks, receive the approval and send the approval to the system This requirement is applicable to Action Support, Blended Operation and Shared Control LOA. In the LOA where the human operator has the ultimate authority over the process control, the automatic system may require the operator’s approval for further implementation of some responses, e.g., safety-important actions. To support this activity, the HSI must ensure that the request for approval and the approval for implementation are being communicated between human operator and the automatic system. This also avoids the problem of loss of situation awareness as the human operator is always consulted before the system implements certain tasks. The ISD (Figs. 5 and 6) shows the request for approval from the human operator for implementation being sent by the system through the interface. The approval is then sent by the human operator to the system through the interface before the system begins executing the task. This shows the importance of the HSI in being an intermediary to ensure that approval is being communicated between the control agents. 4.8. The HSI should display the progress and status of implementation This requirement is applicable to all LOAs. The progress and status of an activity assists the human operator in monitoring the implementation activity. A lack of information about automation activities may cause loss of awareness of the status or behavior

Table 3 The information required for monitoring or verifying automation activities. Process stage

Information

Example

Information acquisition

The process of raw measurements from process system, in terms of how the raw measurements are being processed The process of how the diagnosis is made

The calculation of the difference between SG level of each SG is shown, including the readings from all channels of the interested parameters

Plant diagnosis

Response selection Response implementation

The basis of response selection (the criteria that resulted in the particular response to be chosen) The basis of implementation

The logic or steps of how the diagnosis result is achieved, for example for a loss of feedwater, the corresponding parameters and the setpoints, such as steam flow, SG level, etc. are shown, as well as the criteria of coming to the conclusion during diagnosis The diagnosis result and the goal that needs to be achieved to deal with the diagnosis are shown The reason for the implementation, for example when automation reduces the feedwater flow through economizer valve, the HSI should be able to show the reason why the automation acts such way, along with the diagnosis result and the selected procedure to support the basis of implementation

336

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338

of automation. The display of every automation activity lessens the burden of the human operator to figure out what is going on at the moment or what the automation was implementing when the intervention by operator was necessary. It is important to have a HSI that supports the human operator in verifying the automation activities to ensure that unforeseen events are dealt with sufficiently. This requirement is represented by the arrow labeled as ‘‘displays activities’’ from the implementing role of automation to the interface in Fig. 5 or Fig. 6. It shows the flow of information on the progress of automation’s activity through the interface. Therefore, the HSI must show the progress or status of automation’s activity to the human operator. 4.9. The HSI should display the stability parameters for automation failure detection and the possible need for manual control notification This requirement is applicable to all LOAs. In order to detect automation failure and intervene into the control process, the human operator needs to know the stability parameters to be controlled. The information for stability assists the human operator in diagnosing the plant conditions and making the decision when taking over the control. For example, a reported event due to the failure of a channel could have been prevented if the human operator were guided correctly by the HSI in inputting the correct required value of the channel’s unavailability constant (OPIS, 2004). The display of possible need for manual control notification helps human operator to mentally prepare in advance for the manual control. Sometimes it would be resistive for the operator to take over control when it is required because automation would be working most of the time. This issue of over-trust can be reduced by having this clear and salient indication on the need for manual control. This notification on the need for manual control also helps to inform human operator when it is necessary for human operator to take over control of the process. The flow of information on stability parameters is shown in the ISD (Figs. 5 and 6) alternative box, labeled as ‘‘sends stability parameters.’’ This shows how the HSI should be designed so that the stability parameters can be communicated to the human operator to detect automation failure. The arrow labeled with ‘‘displays the possible need for manual control notification’’ shows that a clear indicator, which would alert human operator to the possible need for manual control, is necessary to support human operator in the control process. 4.10. The HSI should provide the means for take-over from automatic control to manual control This requirement is applicable to all LOAs except for the Manual Control LOA. When the process is unstable or when automation fails or is not working properly, the operator’s intervention into the control process is necessary. Therefore, it is important that the HSI can support the transition from automatic to manual control. The HSI should then be designed to be able to receive the request for manual control and send the request to the system. In the alternative box for an instability event in Fig. 5 or Fig. 6, this requirement is represented by arrows labeled ‘‘requests for manual control.’’ 4.11. The HSI should present the current control mode and the transition between automatic control and manual control to the human operator This requirement is applicable to all LOAs except for the Manual Control LOA. It is important that the human operator be informed of the current control mode, i.e., automatic or manual, and the

change of control, so as to avoid any conflict in the control input such as the setpoint or to prevent the human operator from entering input that could be contradictory to what automation is doing. The human operator would also be able to predict automation’s behavior by knowing the transition of operation modes. This also helps to avoid the OOTL problem in the human operator’s supervisory task on automation’s activities. This HSI ability to inform the human operator of the control change confirms that the control transition requested by the human operator has been completed and the operator needs to submit to manual control. The operator must be informed of the change of control before, during and after the transition takes place. The need for this requirement is represented by the arrows labeled ‘‘turns over control’’ (Figs. 5 and 6). This shows how important it is that the change in control is made known to the human operator. One of the possible ways of implementing this requirement in the HSI is by text display that tells the human operator that a mode transition is currently taking place and also when the turnover of the control has been completed. 5. Discussion The set of requirements was constructed with the objective of augmenting the interaction between the human operator and the system in controlling the operation of the NPP. The ISD has been used to identify the important interaction points and the types of information that are being exchanged between the two control agents. The requirements were established with the issues of automation as the motivation to ensure that the interaction between the human operator and the system is as efficient as possible. 5.1. Automation issues addressed by the design requirements Some important issues in the human–system interaction of automation in NPPs have been previously discussed. The issue of OOTL performance has been addressed by almost all of the requirements. The roots of OOTL performance include the lack of information and observabilility for the operators, and also the loss of situation awareness. These problems are considered in all of the requirements except for Requirements 6, 7 and 10. These requirements (that address OOTL performance issue) involve the necessary information, such as the stability parameters, status or progress display, which needs to be communicated to the operators through the HSI, thus providing the observability of NPP operation. The issue of mode errors, on the other hand, has been addressed by Requirements 6, 8, 10 and 11. These requirements were constructed withthe intention of reducing the possibility of mode errors in NPP operation. This encompasses the aspect of status display, response selection and control change procedure. Requirements 5, 8, 9 and 11 address the issue of operator’s role change to supervisory role, which creates the new problem of the need to understand automation operation while having to monitor, coordinate and make decisions at the same time. This involves the aspect of requesting and obtaining additional information and displaying the progress, stability parameters and control mode status. The availability of this information supports human operators in playing the role of a supervisor for automation actions in the operation. Finally, the issue of authority was addressed by Requirements 2, 3, 6, 7, 8 and 10, which cover the final authority concern. This comprises the information needed to make the final call for any control decisions especially in the diagnosing, selecting and implementing stages, and the procedure to get operator’s consent

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338 Table 4 The automation issues that have been addressed by the requirements. Automation issues

Requirements encompassing the issues

Out-of-the-loop performance Mode error Role change to supervisor Authority

All except for requirements 6, 7 and 10 Requirements 6, 8, 10 and 11 Requirements 5, 8, 9 and 11 Requirements 2, 3, 6, 7, 8 and 10

prior to any significant activities. These requirements ensure that the ultimate authority lies in the hands of the human operator and automation plays the important role of supporting the human operator in assuring the safety of the NPP operation. Table 4 lists which requirements address the discussed automation issues.

5.2. Implication of proposed methodology on HSI design The Electric Power Research Institute (EPRI) produced a report in 2005 that presents the guidance for the design and use of automation in NPPs. Even though the results of our work are generally the same as those of the EPRI report, there are a few differences, especially in terms of the methodology used for function and task allocation. One most striking difference is the use of the ISD for function and task allocation instead of using operating experience and an evaluation method through a set of pre-determined scenarios. Another difference between the work in the EPRI report and our work is in terms of how the requirements were established. The EPRI report uses the results from the evaluation methodology, which is done iteratively through a set of scenarios, while the requirements resulted from this work were produced by identifying the information and the interaction between the human operator and automation at the interface in the ISD. One of the strengths of the proposed approach is the use of the ISD to construct the design requirements, which is a very concrete tool for identifying the points of interaction between the human operator and automation and allocating tasks to the control agents. The process of drawing the ISD is done with the goals of improving the interaction between the control agents; hence an almost ‘‘ideal’’ interaction is described through the flow of arrows, allowing for the construction of design requirements for the HSI of automatic systems in NPPs. The approach employed in this paper presents the usefulness of the ISD, which is not being used to produce the existing guidelines or guidance, as a helpful tool for performing task allocation and constructing design requirements. Another strength of the proposed approach is that the ISD clearly indicates which requirement is applicable to which LOA. This is useful for the designer to refer to only the necessary requirements when designing for the HSI. This methodology also shows when the requirement is applicable to, i.e. at which stage of the operational process stage the requirement is applicable to. Therefore, the results from this paper provide this necessary information, which is not presented in the existing guidelines or guidance.

6. Conclusions The issues of automation have been addressed earlier and a set of requirements has been constructed in the hope of solving the existing unresolved issues. It is very important to maintain the role of automation in being a supportive team player that helps improve the precision of operation and reduce unnecessary or unfeasible work for the operator in controlling a NPP operation. Therefore, the key to successful and efficient dynamics between

337

the human operator and automation is an adequate design for the interface between them. Eleven design requirements that encompass the interaction between human operator and automation were suggested by utilizing the ISD as a tool to identify the human–automation interaction points. Each of the requirements was rationalized and the requirements were shown to address some of the discussed automation issues, as summarized in Table 4. It is important to keep in mind that the requirements are meant to ensure that interaction between humans and automation is improved so that the chance for communication breakdown that could cause an accident or reactor trip can be minimized. Efficient design of the HSI system will contribute to the safety and economy of a NPP operation, and the production of the design requirements was an effort to further improve the human–system interaction. The strength of the EPRI report’s methodology is that the function allocation goes through an evaluation for a set of scenarios. A benefit may be gained by integrating the proposed methodology with that of the EPRI report. The task allocation results from the use of the ISD can be evaluated through predefined scenarios, from which a stronger set of guidance can be produced. The integration of the proposed methodology with that of EPRI report could result in the identification of new issues that would call for the establishment of new guidance. For example, Requirement 10 states that the HSI should provide the means for take-over from automatic control to manual control and that was not mentioned in the EPRI report. The proposed methodology’s strength of associating the stage and which LOA the requirement is applicable to will provide traceability of the HSI design. There is not much opportunity for the automation designer to meet the operators and explain the design motives; hence operators sometimes have trouble understanding why a particular design was designed in such a way. Therefore, this methodology will function as a way for the operators to trace the design motives of the designer and further understand the HSI system design. This will then contribute to a more efficient use of the automatic systems and bring the NPP operation a step closer to a safer level. Acknowledgment This work was supported by the Nuclear Research & Development program of the Korea Institute of Energy Technology Evaluation and Planning (KETEP) grant funded by the Korea government Ministry of Knowledge Economy (No. 20111510100010). References Anuar, N., Kim, D. Y., Kim, J. H., ‘‘Availability Verification of Information for Human– System Interface in Automatic SG Level Control Using Activity Diagram’’, Korean Nuclear Society (KNS), Autumn Meeting, Gyeongju, Korea, October 25 -26, 2012. Electric Power Research Institute (EPRI), 2005. Guidance for the Design and Use of Automation in Nuclear Power Plants: Technical Report, October 2005. Hull, E., Jackson, K., Dick, J., 2011. Requirements Engineering, third ed. Springer. Kaber, D.B., Endsley, M.R., 1997. Out-of-the-loop performance problems and the use of intermediate levels of automation for improved control system functioning and safety. Process Safety Prog. 16 (3), 126–131. Kaber, D.B., Endsley, M.R., 2003. The effects of level of automation and adaptive automation on human performance, situation awareness and workload in a dynamic control task. In: Theoretical Issues in Ergonomics Science. Taylor & Francis, pp. 1–40. Kim, J.H., Seong, P.H., 2009. Human factors engineering in large-scale digital control systems. In: Reliability and Risk Issues in Large Scale Safety-Critical Digital Control Systems. Springer, London, pp. 163–191. Lee, J.D., 2006. Human factors and ergonomics in automation design. In: Handbook of Human Factors and Ergonmics, third ed. John Wiley & Sons, Inc., pp. 1570– 1577 (chapter 60). Lin, C.J., Yenn, T.-C., Jou, Y.-T., Yang, C.-W., Cheng, L.-Y., 2008. A model for ergonomic automation design of digitalized human–system interface in nuclear power plants. In: 2nd International Conference on Applied Ergonomics, July 14–17, 2008, Las Vegas, USA.

338

N. Anuar, J. Kim / Annals of Nuclear Energy 63 (2014) 326–338

Micskei, Z., Waeselynck, H., UML 2.0 Sequence Diagrams’ Semantics, 09389, August 2008. O’Hara, J.M., Brown, W.S., Lewis, P.M., Persensky, J.J., Human–System Interface Design Review Guidelines, U.S. NRC, NUREG-0700, Rev. 2, May 2002. Operational Performance Information System for Nuclear Power Plant (OPIS), Nuclear Event Evaluation Database (NEED), ‘‘Reactor Trip due to the Power Supply Failure of the CEAC’’, 2004, in: Event by Cause: Human, Event number: Ulchin-4-2004-01, . Sarter, N.B., Woods, D.D., Billings, C.E., 1997. Automation surprises. In: Salvendy, G. (Ed.), Handbook of Human Factors and Ergonomics. John Wiley & Sons, New York, pp. 1926–1943 (chapter 57).

Sheridan, T.B., Verplank, W.L., 1978. Human and computer control of undersea teleoperators. In: Technical Report, Man–Machine Systems Laboratory, Department of Mechanical Engineering, MIT, Cambridge, MA, 1978. Skjerve, A.B., Skraaning Jr., G., Saarni, R., Strand, S., 2011. Can human operators and high-level automatic systems work together? In: Simulator based Human Factor Studies Across 25 Years. Springer-Verlag London Limited, pp. 215–229 (chapter 14). Stubler, W.F., O’Hara, J.M., Kramer, J., 2000. Soft Controls: Technical Basis and Human Factors Review Guidance, NUREG/CR-6635 (BNL-NUREG-52565), Brookhaven National Laboratory, 2000.