Keywords

1 Introduction

The work presented here represents one component of a larger effort to dynamically model human actions and their consequences on the plant. Specifically, this work consists of developing the timing components for a virtual operator completing procedure steps in a computation-based human reliability analysis (CoBHRA) approach developed for nuclear process control. This CoBHRA framework is called Human Unimodel for Nuclear Technology to Enhance Reliability (HUNTER) [1]. HUNTER relies on a virtual operator that interfaces with a realistic plant model capable of accurately simulating plant thermohydraulic physics behaviors [1, 2]. Ultimately, the virtual operator will consist of comprehensive cognitive models comprised of artificial intelligence, though at this time a much more simplified operator model is used to capture the diagnosis and action behaviors of a typical operator. HUNTER is a merger between an area where HRA has previously been represented—probabilistic risk models—and an area where it has not—realistically simulated plant models through mechanistic thermohydraulic multi-physics codes. Through this approach, it is possible to evaluate a much broader spectrum of scenarios, both those based on previous experience and those that are unexampled, i.e., have not been assessed with static human reliability analysis (HRA).

A significant influence on plant behavior and performance comes from the human operators who use that plant. The computational engine of the virtual plant model therefore needs to interface with a virtual operator that models operator performance at the plant. In current nuclear power plants (NPPs), most plant actions are manually controlled from the control room by reactor operators (ROs) or locally at the physical plant systems by field operators. Consequently, in order to have a non-idealized model of plant performance to support HUNTER, it is necessary to account for those human actions that ultimately control the plant. A high fidelity representation of an NPP absolutely requires an accurate model of its human operators in order to faithfully represent real world operation.

While it is tempting simply to script human actions at the NPP according to operating procedures, there remains considerable variability in operator performance despite the most formalized and invariant procedures to guide activities [3]. Human decision making and behavior are influenced by a myriad of factors at and beyond the plant. Internal to the plant, the operators may be working to prioritize responses to concurrent demands, to maximize safety, and/or to minimize operational disruptions. While it is a safe assumption that the operators will act first to maintain safety and then electricity generation, the way they accomplish those goals may not always flow strictly from procedural guidance. Operator expertise and experience may govern actions beyond rote recitation of procedures. As a result, human operators may not always make decisions and perform actions in a seemingly rational manner. Modeling human performance without considering the influences on the operators will only result in uncertain outcomes. To create the procedure step and timing based virtual operator model, the procedure steps were broken into subcomponents using an approach based on the task analysis technique called Goals, Operators, Methods, and Selection rules (GOMS). The approach, when adapted to HRA, is called GOMS-HRA [4].

2 GOMS-HRA Based Virtual Operator Model Development

Traditional HRA methods quantify tasks at an overall task level, which is adequate for static HRA purposes. However, computation-based HRA requires subtask level quantifications in order to model the virtual operator’s actions in order to more accurately represent the scenario as it unfolds. Computation-based HRA affords a higher resolution of analysis and therefore it requires a finer grained quantification of operator tasks. To address this finer grained analysis, GOMS-HRA was created by categorizing subtasks as GOMS primitives and linking them to HEPs associated with each subtask [4]. These GOMS primitives were then assigned completion times based on empirical simulator studies and the subsequence timings for each subtask could then be mapped onto procedures steps to create a virtual operator model with variable completion times for each procedure step.

2.1 Goms-Hra

The GOMS model is a human cognitive model that provides analysts with a formal description of user behaviors as the user works with a human-machine interface (HMI) [5]. The GOMS acronym stands for Goals, Operators, Methods, and Selection Rules. Goals refer to the high-level objective users are attempting to accomplish, Operators are the individual actions that the user can make, Methods are collections of operators and consist of the steps and/or subgoals the human completes to move towards achieving the Goals, and Selection rules represent decisions the human makes to select particular methods and operators. GOMS is particularly useful for characterizing a user’s procedural knowledge as they complete procedural tasks as evidenced by its extensive use in human factors. GOMS is categorized as a form of task analysis since the methods and operators form a hierarchical structure that can be used to complete subgoals and ultimately achieve the overall task goal. By categorizing particular types of actions, GOMS affords predictive capabilities that can be used to evaluate existing systems and model user interactions with human-computer interfaces. System designers have used GOM’s predictive abilities to supplant user studies, though this use has been criticized for being time-consuming and overly laborious [6]. With the advent of discount usability methods centered on streamlined and cost-efficient data collection for user studies [7], the popularity of GOMS modeling as an alternative to such studies has subsided.

The Keystroke-Level Model (KLM) [8] is the simplest instantiation of the GOMS model. The KLM provides timing data for individual actions at the most fundamental level for interacting with a computer system. As such, this resolution of subtask decomposition into individual actions makes it possible to map human actions and predict how long certain activities, or collections of actions, will take to complete. This approach proved useful for routine and repetitive tasks like call center operations, where each scripted action was decomposed into its basic elements and then translated into its overall duration. Thus, it was possible to determine processes or even software use sequences that were inefficient. Through using the KLM, human factors researchers have been able to optimize human-computer interfaces. Indeed, such optimizations became the poster child of human factors, because it was easy to map the repetitive tasks to cost and thereby achieve cost savings with more efficient processes and interfaces. Usability engineering still lives under the shadow of the easy cost savings realized through KLM, whereas it can be difficult to cost-justify other human factors methods in comparison.

2.2 Defining GOMS-HRA Task Level Primitives

NPP operators activities are procedural in nature and therefore, the GOMS-HRA is well suited to serve as the foundation for the virtual operator model used in HUNTER. To populate the model with suitable operators, we examined HRA error taxonomies and selected the Systematic Human Error Reduction and Prediction Approach (SHERPA) [9] to derive Operators. In HRA, SHERPA is often used in conjunction with hierarchical task analysis to cluster subtasks into meaningful tasks suitable for defining human failure events [10].

The GOMS-HRA Operators generally distinguish between control room actions and field actions, the latter of which may be performed by ROs working as balance-of-plant operators or by technicians and field workers. Table 1 below depicts the task level primitives derived from the SHERPA error taxonomy.

Table 1. GOMS Operators used to define Task Level Primitives
Full size table

These Operators, derived from the SHERPA error taxonomy, can serve as the task level primitives which can be mapped onto the procedure steps followed by the operators to providing timing information relevant to Human Error Probabilities (HEPs).

2.3 Assigning Timing Values to the GOMS-HRA Task Level Primitives

Task primitive completion times were quantified based on empirical data collected during a series of operator-in-the-loop studies conducted as part of a separate control room modernization project [11]. The empirical data consists of simulator logs recorded by an observer shadowing a crew of operators during a series of turbine control scenario simulations. The simulator logs provided a detailed account of each procedure step, relevant actions, completion times for those actions, and crew communications. The simulator logs contained a total of 283 observations spanning five separate scenarios, each of which lasted approximately half an hour. Though the scenarios were specific to turbine control, the task primitive timing data extracted from the simulator logs represent universal actions that are applicable throughout the entirety of the main control room interfaces.

3 Operator Timing Station Blackout Example

A station blackout (SBO) represents a time sensitive worst case scenario in which offsite power and the diesel generators fail. This forces the plant to rely on battery backup power until these other two more reliable power sources can be restored to maintain the necessary cooling to prevent core damage. The station blackout scenario used to illustrate the GOMS-HRA method contains procedure steps containing specific verb terminology. Procedure writing guidelines suggest following the convention of consistently using a single verb to denote a particular action. Operators are trained to interpret the verb during training so that each procedure step is clearly defined and intuitive for the operator to complete. We followed the standard conventions to define each verb used in each procedure step of the Post Trip Actions (PTA) and Station Blackout procedures [12, 13] used in this example. Defining the verbs with standardized definitions enables the HRA task primitives to map onto each specific procedure step and provide timing data. Each verb represents a single primitive or a series of combined primitives required to complete the procedure step. At each step in the procedure, the realistic plant model is provided with the appropriate timing and Human Error Probability (HEP) data to more accurately reflect the true nature of the event in contrast to more traditional state HRA approaches.

The procedure level primitive (PLP) used within each procedure step represents a cluster of actions that must occur in the proper sequence in order for the operator to successfully complete the step [14]. These procedure level primitives can be decomposed into sequences of task level primitives (TLPs) for complex mappings. To check a value in a procedure step, a series of activities is performed. After reading and interpreting the procedure step, the operator walks to the board and looks for the required information. If the expected value or state is observed, the operator verbally conveys the value or state to the RO and the sequence of primitives concludes. If the expected value or state is not observed, the operator then must take corrective actions by setting a state or specific value and waiting for those actions to take effect. The sequence of task level primitives repeats until the desired value or state is achieved and the step is concluded. The task level primitives were mapped following this method for each procedure step in order to support the estimation completion times for each step.

Each action verb contained within a procedure step is decomposed into one or more task level primitives. Some procedure level primitives are comprised of multiple task level primitives, while others represent a single action. The procedure level primitives, i.e. action verbs, are generically defined in order to support mapping onto any procedure steps used in the main control room. The action verbs or procedure level primitives can be further broken down into task level primitives depending upon the context of the action verb for a given procedure step.

3.1 Defining Nominal Timing Data for HEPs

In order to analyze a specific scenario, such as the station blackout event, and calculate the nominal HEP and task timing values, the procedure must be evaluated at the procedure level and then at the task level. The procedures included in this simulation are based on the post trip action and station blackout procedures from a nuclear utility. To protect the proprietary procedures, the procedure text cannot be publicly disseminated. Since the procedure steps cannot be shared, an example procedure step in Table 2 serves to provide an overview of how a step is mapped to the procedure level and task level primitive. For example, procedure step 2 of the post trip action (PTA) procedure contains two procedure level primitives, which are determine and verify. Determine is an abstract procedure level primitive that can be decomposed into three verify substeps. These substeps of procedure step 2 are mapped onto the task level primitive of verify, which corresponds to the task level primitive, CC, or looking for required information on the control boards.

Table 2. Example mapping of procedure step to procedure and task level primitives for a post-trip action (PTA) procedure.
Full size table

To reiterate the process, two mappings are involved:

  • The plant procedures are classified in terms of procedure level primitives

  • These procedure level primitives are comprised of task level primitives from GOMS-HRA.

Because there is a high degree of nuclear industry consensus on terminology in operating procedures, the procedure level primitives represent commonly and consistently deployed types of activities. It is therefore possible to create a universal mapping of GOMS-HRA task level primitives to the procedure level primitives. This universal mapping affords the opportunity for reuse of the building blocks in HUNTER across different analyses.

The procedures used in this station blackout example are an approximation of the actual series of events that would unfold during the scenario. Though this reduces some of the realism captured in the simulation, it was necessary due to the procedures’ proprietary nature. Furthermore, this is the first attempt at performing an integrative HRA model with dynamic HEPs and corresponding thermohydraulic computations, which was made possible by restricting the scope of the simulation to these the post trip actions (PTA) and station blackout (SBO) procedures. To illustrate this analysis further, SBO procedure step 5a stating “Ensure letdown is isolated” will be described at each stage of the analysis process (see Tables 3 and 4). The procedure level primitive in this step is defined as the verb, Ensure. Ensure could be decomposed into different task level primitives, so the context of the procedure step, in this case letdown isolation, must be evaluated to determine which of the task level primitives are applicable. In this instance, the valve positions are a status indicator with a simple state control as opposed to a continuous numerical value setting. As a result, this procedure level primitive translates to the task level primitives of CC (look for required information on the control board) and AC (perform physical actions on the control board).

Table 3. SBO Step 5 showing mapping of Ensure procedure level primitive.
Full size table
Table 4. Average, 5th percentile and 95th percentile time (seconds) for completing each GOMS task level primitive as calculated by mapping the task level primitives to the empirical simulator log data for completing procedure steps.
Full size table

The procedure steps for the PTA and SBO procedures were mapped to procedure and task level primitives as shown in Table 3. Following the analysis of the procedures to map procedure level and task level primitives, timing data were estimated for each procedure step as derived from GOMS-HRA (see Table 4). Additionally, the procedure steps were aligned with the two primary events in which the loss of offsite power occurs and the loss of diesel generators, and loss of battery during the station blackout event. By aligning the procedure steps to the primary events of the scenario, the simulation can be repeated with slight variations on the timing for the operator to expeditiously complete procedure steps. This provides insight into the effects of the operators taking longer or shorter to complete task and can aid the identification of key steps that either lead to success if completed swiftly or place the plant in danger of core damage if completed too slowly. The different timings modelled in each repetition of the same scenarios simulation are drawn from the empirically calculated values for each task primitive as depicted in Table 4. For example, the amount of time to complete a physical action on the control board, Ac, took on average 18.75 s, but could be vary in the completion time used for a given simulation run between 1.32 and 65.26 s in order to capture the variability in the amount of time operators empirically require to complete this task level primitive.

4 Conclusions

The development of the virtual operator with a variable timing component for completing procedure steps adds a level of fidelity to HUNTER that was nonexistent before. The effort to map the procedure steps with procedure level and task level primitives was substantial. Mapping the procedure steps with procedure and task level primitives is time consuming. Future steps involve automating this process with statistical techniques to extract the verbs used in a plants entire catalogue of procedures and create a larger database of procedure primitives and their associated task level primitives in order to apply this method to other scenarios. This process also requires more empirical data on actual operator timing to further enhance the accuracy of the timing data used to assign timing values for each task level primitive. Though expanding the database for automated procedure mapping of procedure and task level primitives represents a substantial research endeavor, it is quite advantageous due to the enormous benefit of being able to model unexampled events and more accurately conduct HRA.