Procedures

Procedures (Operating Procedures and Other)

The content of operating procedures is modeled by the class Procedures. The object of this class is declared as Procedures All_procedure which is a global object. An operating procedure is hierarchically modeled. A procedure step (represented by class ProcedureStep) is the constructing unit for building a procedure. The hierarchical modeling structure and constitutional modeling elements are discussed. The procedures described here apply for both written procedure and memorized procedures.

******Notes: relate to ADD GUI *************************************

Current ADS GUI was constructed partially based on the previous version of ADS. This results in that some user input information into the GUI actually not used in the ADS code. These include:

• The Action Package ID, Required Time, Complexity, and Cost in editing a procedure step
• The Type and Perform Method in editing an action
• The Perform Method in editing an expectation (associating to an action)

Even these parameters are not used in the simulation, these parameters are read by ADS code. Thus, the user still need to enter correct format of data into the GUI.

******************************************************

Procedure Structure

The ADS procedure design is based on the Westinghouse procedure structure. Figure 17 shows a sample Westinghouse procedure step. Each procedure consists a number of such procedure steps. The sample procedure step shown in Figure 17 consists four instructions (i.e., instruction a, b, c, and d). Each instruction can be divided into two parts: “Action/Expected Response” and “Response Not Obtained”. The part on the left (i.e., Action/Expected Response) is the main instruction. The operator is expected to follow the instructions in sequence. Once the last of instruction is completed, the next procedure step is entered. If the operator does not observe the expected system response or symptoms listed in the instruction, the operator should follow the instruction shown in the “Response Not Obtained” column. Figure 18 shows a flow chart of procedure following.

Figure 18 shows the ADS modeling of the procedural flow. The procedure is described below:

• At Block 1 of Figure 18, the operator follows the instruction either changing a system state or checking system information. For example, the Instruction ‘a’ in Figure 17 asks the operator to check the PZR level.
• At Block 2, the operator determine whether the expected system state is as expected. Following the same example, the operator determine whether the PZR water level is less than 25%. If the water level is less than 25% then goes to Instruction ‘b’ (i.e., following Blocks 3 and 4), otherwise go to “Step 17” (Block 6).
• If every expected system symptom is perceived, the operator continues following instructions b, c, and d. When instruction ‘d’ (i.e., Stop RCS depressurization) is performed, the operator enters next procedure step.

Westinghouse EOP procedure step.

Figure 18 the flow of procedure following modeled in the IDAC model

Procedure Model

Procedures, ProcedureStep, and ProcedureStepUnit

The content of operating procedures is modeled by the class Procedures. The object of this class is declared as Procedures All_procedure which is a global object. An operating procedure is hierarchically modeled. A procedure consists a number of steps, and the class ProcedureStep is used to model a procedure step. Each procedure step consists a number of instructions (including the “action/expected response” and “response not obtained”) which is modeled by the class ProcedureStepUnit. Table 7 shows the classes matching to the hierarchical component of real procedures.

Table 7 The corresponding IDAC classes to the hierarchical decomposition components of real procedures

Level	IDAC Class	Corresponding Procedure Element
1	Procedures	All procedures including paper and mental procedures
2	ProcedureStep	A procedure step
3	ProcedureStepUnit	An instruction of a procedure step. An instruction typically contains an action and associated expectations of system responses.

Figure 19 provides an overview of the IDAC modeling on operating procedures. As shown in Figure 19, the class Procedure consists a vector of pointer pointing to a list of ProcedureStep. The object Procedure also contains a map (i.e., procedure_map as shown in Figure 19) which use the combination string procedure name and step name, both of which are string, to identify a specific procedure step. The combined string of the procedure name and step name of a procedure step is unique.

The class ProcedureStep contains a vector of pointers pointing to the instructions (modeled by class ProcedureStepUnit) within this procedure step. Each ProcedureStepUnit consists pointers to

• a pointer to the object ProcedureActionUnit which models the action shown in Block 1 of Figure 18
• a vector of expectations which model the expectation (Block 2 in Figure 18). Each expectation is modeled by the class ExpectationORUnit. The constitutional components of the ExpectationORUnit contains AND/OR logics that could model complex expectation statement described in procedures.
• a pointer to the “Response not obtained” (or “non-response action”). Since there are several types of response for the “non-response action” (e.g., procedure step and action to change system state), the declaration of “non-response action” is declared as a void pointer.

Figure 19 The structure of IDAC modeling on operating procedures

Each object of ProcedureStepUnit contains a StateOfActivation (declared as a public member of ProcedureStepUnit) to indicate the state of the ProcedureStepUnit (i.e., instruction). The optional states include:

• VNONE: has not been activated (i.e., the instruction has not been performed)
• VACTIVATED: the instruction is currently on processing
• VPAUSE: the instruction is temperately interrupted due to the operator is working on other high priority task. Once the operator returning to the procedure, the state of this instruction will be changed to VACTIVATED again.
• VSUCCEED: this instruction has been completely performed.
• VFAILED: this instruction has been given up due to expectation of this instruction is not perceived.

The values of the above states (e.g., VNONE, VACTIVATED, VPAUSE, VSUCCEED, and VFAILED) can be seen in TermConversions.h.

Actions

The action portion of a procedural step instruction (as shown in Block 1 of Figure 18) could have several options (see function ProcedureStepUnit::readInfofromFile) including

• Procedure transfer: this option is similar in an procedural instruction instructs the operator to enter another procedure step without performing action. The need for this option could be due to the procedures in the control room is updated when better task flow is conformed. This could result in removal of some steps. In order to limit the impact, the content of some of these removed steps may be changed to “Go to Procedure X Step Y”. Encountering such situation, even the operator does nothing, this option slows down the procedural following pace.
• Do_And_Return: this option would trigger the operator to follow certain memorized procedure step (specified by class ProcedureProcedureStepInfo). After the memorized procedure step is completed, the operator would return to the previous procedural step which he/she was following prior to entering the memorized procedure. Since the memorized procedure is specified by class ProcedureStep, each memorized procedure also has information for next procedure and next step. If the procedure step indicated by the next procedure and next step exist, the operator would enters the procedure step after current procedure step is completed. This continues until the procedure step indicated in the next procedure/net step does not exist. At this moment, the operator
• Others: this includes other types of actions or checking for system related information. Within ADS GUI, the user can select any type of action (e.g., checking for system information and acting on changing the system state). Two alternatives for operator actions: actions to check system state and actions to change system state.
  • Action to change system state: an object ProcedureActionUnit is generated to store the action related information. The operator will carries the action and check for the expectations associating to the action.
  • Action to check system information: Since the action on checking for system state is modeled in the expectation statement associated with EXPECTATION, GUI should not allow the user to select any type of control panel information other than controllers. In order to prevent repeating time delay on checking for system information, the ADS internally converting the user entered information (from GUI) to “WAITING”. Such option is used to model the operator simply spending time on the procedural step without doing anything. This option can be used to account for the time operator spends in the steps whose components to be acted are not modeled.

******Notes: relate to ADS GUI **************************************

• Using current ADS GUI to edit an action of a procedure step, the object of the action (i.e., the “Name” list within in an ADS GUI “Edit Action” pop-up window) is expected to be an “interactive control variable”(typically named as “X_<name>”). Current ADS GUI provides options of “Procedure transfer”, “Do and return”, and all control panel information including parameters’ states, components’ states, alarms, and controls. The control panel information except the controls actually should not appear among the options. ADS code correct this internally. ADS code checks whether the selected element is an control, if it is a control the ADS does what is specified. If it is not an control the “waiting” option is assigned to replace the selected element. This results the operator would idle for the amount of time specified (i.e., specified with the Required Time option) then continues whatever next activities specified.
• Due to possible confusion in associating components with their corresponding operating method (e.g., pump vs. on/off/trip) the Type option within the ADS GUI “edit action” window is not used in the ADS code. Instead, the “Control Value” within the edit screen is used to pass to RELAP5 to change the corresponding component’s state.

**********************************************************

Expectations

As shown in the Block 2 of Figure 18, each action, in most cases, would be followed by some expectations on system response. Sometimes the expectation is simple such as the instruction ‘a’ of the sample procedure step shown in Figure 17 (i.e., expecting the PZR level is less than 25%); sometimes there is no expectation associating to an action e.g., the instruction ‘b’ shown in Figure 17; sometimes there are more than one expectation and related by AND/OR logics. The IDAC model is capable of modeling all above three types of expectation.

IDAC uses a two dimensional expectation links to model all types of expectation (i.e., no expectation, single expectation, and multiple expectations linked by AND/OR logics) as shown in Figure 20. The two dimensions are modeled in two layers: first expectations connected by AND gates, and second expectations connected by OR gates. These two-layer modeling is explained later of this section. Constructing such structure is coded in the expectation body of ProcedureStepUnit::readInfofromFile.

Constructing the expectation structure shown in Figure 20 starts from the number of expectation linked by AND logic. The number is explicitly shown in the text file of each procedures i.e., the n_expectation declared in ProcedureStepUnit::readInfofromFile.

Each logic connected by AND gate is result of one or more than one expectations linked by OR gates. As a result, the result of a AND gate is represented by an array of expectations rather than a single expectation. The final result of all expectations declared in a ProcedureStepUnit is indicated by the attribute ProcedureStepUnit::expectation (declared as vector<ExpectationORUnit *> expectation within ProcedureStepUnit). The final result of a logic connected by AND gate is declared as ExpectationORUnit. Each ExpectationORUnit contains a number of expectations connected by OR gates. In IDAC, the ExpectationORUnit is declared as a class which contains an array of expectations (i.e., ExpectationORUnit::expectation_OR). The ExpectationORUnit:: expectation_OR is declared as “vector<ExpectationElement *> expectation_OR” within ExpectationORUnit.

The number of expectation within a ExpectationORUnit::expectation_OR is not explicitly indicated in the procedure text files (i.e., the ZProcedure_*.txt files within ../input/crew/procedures directory). Instead, a parameter int ProcedureExpectORLink:: or_link (explained later in this section) is used to indicate whether current expectation is linking to another expectation by an OR gate. When the value of ProcedureExpectORLink:: or_link is VYES (i.e., 3002) another expectation is linked to the current expectation by an OR gate. Table 8 provides a summary of the characteristics of the expectation linked by AND/OR gates.

Table 8 The AND and OR gates modeled in the IDAC model

Gate	IDAC Modeling
AND Gate	- Attribute: ProcedureStepUnit::expectation - Declaration: vector<ExpectationORUnit *> expectation - Explanation: AND gate is used to connect the elements within the ProcedureStepUnit::expectation - The total number of AND gates is explicitly specified within the procedure text files. - Function that assesses the result: ProcedureStepUnit::executeExpectation. It requires all expectations’ states to be true (i.e., VSUCCEED) in order to be true since they all are connected by AND gates.
OR Gate	- Attribute: ExpectationORUnit::expectation_OR - Declaration: vector<ExpectationElement *> expectation_OR - Explanation: OR gate is used to connect the elements within the ExpectationORUnit::expectation_OR - The procedure text files do not provide a single value to indicate the total number of OR gate. Instead, these is an attribute (i.e., or_link) within each expectation to indicate whether these is an expectation connecting to the current expectation by OR gate. - Function that assesses the result: ExpectationORUnit::assessExpectation; When any of expectations within the ExpectationORUnit::expectation_OR is true would set the top event (logic) state as true since they are all connected by OR gates. see the else if(exp_state == VSUCCEED){ this->setStateOfActivation(VSUCCEED); found_exp = true; } Within ExpectationORUnit::assessExpectation()

The upper part of Figure 20 provides an example for explaining the IDAC model on the logics for expectation. There are two expectations linked by AND gates (i.e., the Expectations 0 and 1). The Expectation 0 is the result of Expectations 0-0 and 0-1 which are linked by an OR gate. The Expectation 1 is the result of Expectations 1-0 and 1-1 which are linked by an OR gate, too. The Expectations 0 and 1 each is represented by a ExpectationORUnit which contains the vector<ExpectationElement *> expectation_OR to indicate all the expectations (e.g., Expectations 0-0 and 0-1 or Expectation 1-0 and 1-1 for Expectation 1) linked by Or gates for calculating the result of ExpectationORUnit (i.e., Expectation 0 or 1). The logic connection shown on the upper part of Figure 20 can be translated to the fault tree shown in the bottom part of Figure 20.

There are four types of expectation currently modeled in IDAC model. Each type of expectation is modeled by a class declared in the ADS code:

• ProcedureExpectedAlarmStateUnit (i.e., for alarm state)
• ProcedureExpectedComponentStateUnit (i.e., for component state)
• ProcedureExpectedParameterValueUnit (i.e., for parameter value and trend)
• ExpectedMentalBelief (i.e., for operator’s believes)

All the above four classes inherit class expectationElement, as a result, pointer of expectationElement is used in ExpectationORUnit to point to the expectations linked by OR gates. Also, all the above four classes consist the class ProcedureExpectORLink which contains the attribute (i.e., int or_link) to determine whether there is an OR gate linked expectation to the current expectation. For convenience, the consisting classes of the above four classes are listed below:

• class ProcedureExpectedAlarmStateUnit :
  • public KBExpectedAlarmStateUnit,
  • public Timer,
  • public ProcedureExpectORLink
• class ProcedureExpectedComponentStateUnit :
  • public KBExpectedComponentStateUnit,
  • public Timer,
  • public ProcedureExpectORLink
• class ProcedureExpectedParameterValueUnit :
  • public KBExpectedParameterValueUnit,
  • public Timer,
  • public ProcedureExpectORLink
• class ExpectedMentalBelief :
  • public KBElement,
  • public ExpectationElement
  • public Timer
  • public ProcedureExpectORLink

Figure 21 shows the class inheritance of these four types of expectation. It shows that they all contain the following fore classes:

• KBElement
• ExpectationElement
• Timer
• ProcedureExpectORLink

Figure 20 A two dimensional vector to model AND/OR gates

Figure 21 The class inheritance of the four types of expectations associated with an action within the procedures

Follow Procedures Model

The IDAC models two types of procedure: written procedures and mental procedures. Both of these two types of procedures are coded using the same format and stored in the text files within the directory ../input/crew/procedures. Making the mental procedures distinguished from the written procedures is that ADS refers to all the procedures referred by the operator direct matching knowledge base are all mental procedures. All other procedures are paper written procedures. The reason for having such distinction is that there are different mechanisms on how they work.

The mechanism for following written procedures is coded in bool OperatorDM::performFollowProcedureStrategy(). Within the following written procedure strategy, the operator follow the instruction of the entry procedure step. The entry procedure is default as the first procedure step indicated within the “coded steps” section within the file procedures.txt located in ../input/crew/procedures directory. The operator follows the instruction of this procedure step. The procedure step could instructs the operator to follow other procedure steps. If the instructed procedure steps exist, the operator will continue follow these procedures. In the situations the procedure step the operator should follow does not exist (i.e., have not been coded) the ADS would terminate current sequence due to no written procedure is available.

The mechanism for following mental procedures is coded in bool Operator::performAMentalProcedure(). The activation of following a mental procedure is due to the confidence of a piece of the Hard Wired Diagnoses (i.e., coded in ../input/crew/Decision Maker or Action Taker) exceeds a threshold (Need to be revised). Then the operator immediately follows the mental procedure associated with the hard wired diagnosis. ADS treats such situation as the operator has a new diagnosis. As a result, the procedure step associated with the diagnosis represents the expected operator immediate response. There are two situations:

• If the procedure step (e.g., PS_1) exists, the operator will follow the procedure step. At the end of PS_1 has information linking to the next procedure step (e.g., PS_2). If the PS_2 exist, the operator would continues follows PS_2 instruction. This process continues until the referred procedure step does not exist. In such situation, the operator will follow the rules described in the next bullet.
• If such procedure step does not exist (i.e., has not been coded or no operator immediate response is expected) the ADS code marks the state of the newly generated diagnosis as “DONE” (i.e., by function wm::setStateOfActivation(VDONE)) and continues the activities taking place prior to the diagnosis activated. This is done by calling the function memory.activatePausedInfoChunk() which checks all info chunks within the short term memory whose state is “PAUSED”. The state of the info chunk is changed to ACTIVE. This means that the simulation sequence will not be terminated for not finding the corresponding procedure step.

All the procedure steps (including written and mental procedures) that have been performed are stored in the operator’s memory in the form of class DecisionProcedureStep which only contains information of procedure name and step name but not the detailed instruction. The IDAC stores these two types of procedure step (i.e., written procedures and mental procedures) in different locations. The performed written procedure steps are stored in InfoChunk::procedure_step, and the performed mental procedure steps are stored in InfoChunk:: instinctive_response_procedure. The InfoChunk is part of working memory which in turn is part of the operator’s short term memory (i.e., working memory and intermediate memory). The class InfoChunk is discussed in detail in Section xx.

Following procedures start at the function OperatorDM::performFollowProcedureStrategy() whose processing flow is shown in Figure 22.

Figure 22 The process of OperatorDM::performFollowProcedureStrategy()

Figure 23 The processing flow for a procedural step instruction modeled by ProcedureStepUnit simulated by ProcedureStepUnit::executeAction().

Figure 24 The simulation flow for the operator to check the expectations of a procedural step unit (i.e., ProcedureStepUnit::executeExpectation).

Figure 25 The ADS information processing for determining the value of a parameter ProcedureStepUnit::executeExpectation().

Memory Control of Procedures Model

The procedures are self destructive. All the memory located for procedures will be released when the procedure object is destructed. The memory also can be released by calling the function Procedures::clearProcedures().