Crew Module

IDAC models three types of operators: Decision Maker, Action Taker, and Consultant. The first two types of operator are modeled explicitly in the current ADS code. The Decision Maker and Action Taker working as a team to solve the faced problem. The Consultant is not activated in the current ADS code due to lack of knowledge on modeling the Consultant’s role. However, the ADS code keeps the necessary components ready for activating the Consultant.

Three classes (i.e., OperatorDM, OperatorAT, and OperatorCT)are declared to model the three types of operator (i.e., Decision Maker, Action Taker, and Consultant). All the three classes are inherited from a common class Operator. The modeling components for an operator include:

• Short term memory (i.e., Working memory and Intermediate memory)
• Long term memory (i.e., operator’s knowledge base)
• Performance Influencing Factors (PIFs)
• Event Symptom matrix.
• Rules of Behavior

The Short Term memory (STM) includes IDAC’s Working Memory and Intermediate Memory. The amount of information within the STM during the course of an event would change. The long term memory (or knowledge base) stores the system related knowledge the operator possesses. Since IDAC does not model learning effects, the amount of information within the long term memory is constant during an event. The Performance Influencing Factors models the operator’s psychological responses to the situation. A Bayesian Belief Net type of PIF modeling approach is under developing. The PIF component is currently not available. The Event-Symptom Matrix represents operator’s confidences in various system state related symptoms and events. The Event-Symptom Matrix is similar to the PIFs that represent some part of the operator’s psychological and cognitive state. The IDAC’s Rules of Behavior guiding how information is processed within memory and how PIFs affecting information processing (consequently decision making) as well as inter-influence among PIFs. In the ADS code, the Rules of Behavior is represented by the functions of the classes declared for modeling other components (i.e., memory and PIFs). Therefore, the Rules of Behavior is discussed within the sections in which the corresponding operator modeling components are discussed.

Figure 26 shows the class hierarchical structure of modeling an operator and the key modeling attributes. The common components are declared in class Operator. The PIF shown in the class Operator of Figure 26 does not exist in the current version of ADS code.

Figure 26 The class hierarchy of operator modeling and key attributes

10.1 Overview of IDAC Memory Model

Figures 27 shows the information flow among these memories modeled in IDAC namely: Working Memory, Intermediate Memory, and Knowledge Base. Working Memory stores the information related to current cognitive activities and has a very small storage capacity. Such characteristics could make the content of Working Memory change frequently. Information could be retrieved from the Intermediate Memory and Knowledge Base to be processed in the central executive component (paths 1 and 4 in Figure 27) and overflow information is moved to Intermediate Memory (path 2 in Figure 27).

Figure 27 IDAC memory structure and their information transmission paths. Where 1: Information in the Intermediate Memory is retrieved to the Working Memory. 2: Working Memory overflow information is moved to the Intermediate Memory. 3: Information in the Intermediate Memory becomes knowledge stored in Knowledge Base. 4: Knowledge Base information is retrieved to the Working Memory.

The Intermediate Memory has a larger information storage capacity in comparison with Working Memory. Intermediate Memory stores the overflow information from Working Memory. With appropriate stimuli, information in Intermediate Memory can be recalled later to Working Memory. In other words, perceived information is not necessarily forgotten even when it is not related to current cognitive activity; instead, it could be stored in Intermediate Memory. Such information could decay (forgotten eventually) or be stored in Knowledge Base (path 3 in Figure 27) and become part of knowledge or experience.

The Knowledge Base contains an operator’s knowledge about the system and its response to accidents. It has unlimited information storage capacity, and the stored information has a long decay time. The stored information includes knowledge (knowing that…) and intuitive experience (knowing how …) [5]. More specifically, the four types of knowledge identified in [6] are covered including episodic knowledge (which stores specifics of past events), stereotypic knowledge (which stores “typical” and “textbook” scenarios), mental model of system (which stores engineering knowledge of how the system works,) and procedural knowledge (which stores strategies to deal with events.)

Within the ADS code, the IDAC Working Memory and Intermediate Memory are represented as short term memory. Among the four information flow paths between different types of memory shown in Figure 27, the Path 3 (information flow from the intermediate memory into knowledge base that represents operator’s learning) is not in current ADS code. This might not be necessary due to the fact that the accident time duration is short enough to neglect the effect of operator learning.

10.2 Short Term Memory

In the IDAC model, operator’s short term memory (STM) includes Working Memory and Intermediate Memory. Given any time moment, the operator’s decision is always based on the information within his/her Working Memory. The amount of information stored in the STM during an event changes. In the IDAC code, the amount of information in the STM increases along scenario progressing since currently IDAC does not model “forgetting”. During the course of an event, the states of the perceived information could change from time to time (e.g., from active to inactive). This models that the operator’s attention is not evenly distributed to all information perceived.

Composition Components

The IDAC STM (represented by class ShortTermMemory) contains three key components include:

class ShortTermMemory

• list<InfoChunkMental *> grouped_info;
• InfoChunk perceived_info;
• CommunicationPlace new_info;

The ShortTermMemory:: perceived_info contains all information perceived (e.g., alarms) or generated (e.g., diagnoses or goals) by the operators. The ShortTermMemory::grouped_info contains a list of information chunks that the operator has generated. The ShortTermMemory:: new_info is a temporary information holding place. It contains the operator newly perceived information for further processing. The process of how these three modeling components work together is discussed in Section 10.2.2.

IDAC uses information chunk (the class InfoChunkMental in the ADS code) as the container unit for information stored in the operator’s STM. An information chunk can be seen as an information container that contains a number pieces of information which have some commonalities.

The operator’s STM is represented by a list of information chunks (i.e., objects of InfoChunkMental in ADS programming terminology). Each InfoChunkMental contains an attribute “double priority” to indicates the priority level of the object. The InfoChunkMental object with the highest priority level is in the Working Memory; others are in Intermediate Memory. This priority indicator is re-evaluated every time step. The function for calculating the priority level is InfoChunkMental::calculatePriority().

The class InfoChunkMental is declared as below:

class InfoChunkMental : public InfoChunk, public StateOfActivation

The StateOfActivation indicates the state of the InfoChunkMental object (i.e., an information chunk). The optional states include:

• VNONE: has not been activated (i.e., the information chunk has not been performed)
• VACTIVATED: the information chunk is currently on processing
• VPAUSE: the information chunk is temperately interrupted due to the operator is working on other high priority objects. Once the operator returning to the information chunk, the state of this information chunk will be changed to VACTIVATED again.
• VSUCCEED: this information chunk has been performed successfully. This typically means that the problem associating to the information chunk has been solved.
• VFAILED: this information chunk has been given up for some reasons.

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

A few number types of information could exist in an information chunk including the specific system related information perceived by the operator, the operator’s conclusions on the system state, and the goals, strategies, and actions which the operator has performed for the tasks relating to the information chunk could exist in an information chunk. The size of each type of information within an information chunk could change dynamically. In order to model such complex organism, an object of InfoChunkMental consists fifteen arrays that contain different types of information:

1. vector<DecisionGoal *> goal;
2. vector<DecisionStrategy *> strategy;
3. vector<DecisionSubGoal *> subgoal;
4. vector<DecisionDiagnosis *> diagnosis;
5. vector<DecisionActionObjective *> action_objective;
6. vector<DecisionActionPack *> action_pack;
7. vector<DecisionAction *> action;
8. vector<DecisionProcedureStep *> procedure_step;
9. vector<DecisionProcedureStep *> instinctive_response_procedure;
10. vector<MentalAlarm *> perceived_alarms;
11. vector<MentalComponentState *> perceived_component_state;
12. vector<MentalParameterValue *> perceived_parameter_value;
13. vector<MentalParameterTrend *> perceived_parameter_trend;
14. vector<ExpectedMentalBelief *> mental_belief;
15. list<int> related_subsystem;

The first fourteen items are declared within the InfoChunk. The fifteenth item is declared in the InfoChunkMental. The modeling explanations and options for the first seven above listed items can be seen in Section 3 of [7]. Items 7 and 8 stores the written procedures and mental procedure respectively which the operator has taken. Items 10 to 13 are the system generated information perceived by the operator. Item 14 is the operator’s conceptualized beliefs on system states during the course of an event. Item 15 is the sub-system(s) associating to this information chunk. In current IDAC code, an information chunk is formed either based on similarity in diagnosis or related-subsystem. The attributes of system information and operator’s knowledge base provide information for associating different pieces of information.

Information Registering Process

As mentioned in Section 10.2.1 the ShortTermMemory ::grouped_info, ShortTermMemory::perceived_info, and ShortTermMemory:: new_info are the three key modeling components in the IDAC code for operator STM. Such modeling is with consideration of saving computer memory and enhancing simulation speed

The ShortTermMemory:: perceived_info contains all information perceived (e.g., alarms) or generated (e.g., diagnoses or goals) by the operators. Each piece of information is declared as an object with memory declared for the object. The ShortTermMemory::grouped_info contains a list of information chunks that the operator has generated. In stead of locating memory for each object contained in all information chunks, these information chunks only declare pointers that point to the corresponding objects declared in ShortTermMemory:: perceived_info. This practice reduces the required computer memory and enhances the simulation speed. The ShortTermMemory:: new_info is a temporary information holding place. It creates pointers pointing to the newly generated information shown in the Communication Place (the white board discussed in Section 7.2.4 and Section 12) that are relevant to the operator. The contents within the ShortTermMemory:: new_info is re-generated each time step and wiped out (i.e., pointers are removed) when these information has been processed by the operator.

Figure 28 shows the process by which information is registered in the operator’s STM. The function performing the process is OperatorDM/AT::oneThroughProcessForBlockI(), and the process is explained as the following:

1. The newly generated information by system and crew are posted in the CommunicationPlace. The operator checks the CommunicationPlace to check whether there is information relevant to the operator (performed by the function OperatorAT/DM::identifyRelevantInformation()). If there is information relevant to the operator, the ShortTermMemory:: new_info would generate a pointer pointing to each piece of relevant information.
2. [these filters are NOT implemented according to “ 10.6.1 Information Pre-Processing_”_
   The newly relevant information stored in ShortTermMemory:: new_info has to pass the internal filters (i.e., quantitative filter and attention filter) prior to be perceived by the operator. The functions for internal filters include Operator::attentionalFilter() and Operator::quantificationFilter(). The information within the ShortTermMemory:: new_info may be reduced due to the internal filtering. The remaining information is the information to be perceived by the operator.
3. If the type of the incoming information is alarms, parameter values, or component states, the ADS code would check the Operator.memory.perceived_info to determine whether the same information has been perceived. If the information has been perceived before, only the state/value and the perceiving time of the information in the operator’s memory would be updated (i.e, no object will be generated for the incoming information). Otherwise, a corresponding object will be generated and stored in the Operator.memory.perceived_info to register the information. Other types of information remaining in the ShortTermMemory::new_info is copied to its corresponding arrays in ShortTermMemory::perceived_info (performed by the function OperatorDM/AT::infoChunking() ). For those information belonging to the operator internal cognitive products (e.g., goals, strategies, mental beliefs) represent the operator intentional activities. As a result, pointers are added into the Working Memory (represented by one of the InfoChunkMental within ShortTermMemory::grouped_info with highest priority). The perceived system information is compared with existing information chunks within STM. If the information is relevant to an information chunk, a pointer is generated in the information chunk and pointing to the piece of information stored in ShortTermMemory::perceived_info.
4. If the newly perceived information does not relate to any of existing information chunks, a new information chunk is generated to hold this information. A number of function are provided for chunking or/and generating new information chunk for various types of information within STM that include:
   • ShortTermMemory::checkAndGenerateInfoChunkMentalForDiagnosis
   • ShortTermMemory::checkAndGenerateInfoChunkMentalForRelatedParameterTrend
   • ShortTermMemory::checkAndGenerateInfoChunkMentalForRelatedParameterValue
   • ShortTermMemory::checkAndGenerateInfoChunkMentalForRelatedComponentState
   • ShortTermMemory::checkAndGenerateInfoChunkMentalForRelatedAction
   • ShortTermMemory::checkAndGenerateInfoChunkMentalForRelatedAlarm

Figure 28 The process of operator information perception. The blocks with a star ‘*’ inside means only pointer is created by not locating memory for the pointed objects. Otherwise, memory is located for the objects.

Memory Management

The stars ‘*’ shown in the arrays of Figure 28 indicate that the corresponding arrays declares pointers only that pointing to the corresponding objects declared in other place. The arrays without stars indicate these arrays locate memory for the objects to which their pointers are pointing to. This representation is explained in Figure 29.

In Figure 29, Containers A and B have the same declarations of an array of pointers (i.e., vector<Obj *> X). Container B uses “new” command to creates Obj1 and Obj2, and uses “B_array.push_back” command to create pointers pointing to Obj1 and Obj2. Container A only use “A_array.push_back” command to create pointers pointing to Obj1 and Obj2. As a result, when the Container B is destructed, the memory declared for Obj1 and Obj2 needs to be removed. It is not required and should not be used when destructing Container A. Since both Containers A and B use push_back command to declare their pointers, the memory located for these pointers would be managed by the C++ program.

Figure 29 Container B declares memory for Obj1 and Obj2, and pointers pointing to these two objects. Container A only declares memory for pointers pointing to these two objects. When destructing Container B, the memory located for Obj1 and Obj2 needs to be removed. Destructing Container A should not remove memory located for Obj1 and Obj2.

Three memory removal functions are declared for ShortTermMemory for different purpose. These are summarized in Table 9. As mentioned earlier, ShortTermMemory::grouped_info and ShortTermMemory::new_info declare pointers only. The ShortTermMemory::perceived_info declares memory for pointers. Table 10 shows two different types of memory declaration for the ShortTermMemory. Such declarations are used for saving information for restart purpose.

Table 9 Different types of memory removal function of ShortTermMemory

Functions	Declared Objects	Objects and pointers	Pointers only
Nominal State	grouped_info		X
new_info		X
perceived_info	X
clearShortTermMemoryForRestart()	grouped_info		X
new_info		X
perceived_info	X
clearShortTermMemoryFromRestartInfo()	grouped_info	X
new_info		X
perceived_info	X
clearShortTermMemoryFromRestartNodeInfoMultiProcessors()	grouped_info	X
new_info	X
perceived_info	X
copyShortTermMemoryFromRestartInfo()	grouped_info		X
new_info		Do Nothing
perceived_info	X
copyShortTermMemoryToRestartInfo	grouped_info	X
new_info		Do nothing
perceived_info	X

10.3 Knowledge Base

The operator’s knowledge contains fix size of information during an event. The operator’s knowledge is modeled by the class KB. Two types of knowledge base are modeled currently:

• Relation between system information and perception of system states
  • Modeled by KB::hard_wired_diagnosis
  • Declared as vector<KBHardWiredUnit *> KB::hard_wired_diagnosis
• Relation between system information and system hardware structure
  • Modeled by KB:: system_decomposition
  • Declared as vector<KBSystemDecompositionUnit *> KB::system_decomposition

Hard Wired Diagnoses

The hard-wired diagnosis (i.e., a mental belief) consists of an array of KBHardWiredUnit objects. Each KBHardWiredUnit object represents a system state that the operator perceived, and the attribute “confidence_level” is used to represent the operator’s confidence in the system state. The input parameters for calculating the confidence_­level, and their containers and calling function for determining whether the expectations matched include:

• Alarms
  • vector<KBExpectedAlarmStateUnit *> expected_alarm_state
  • KBExpectedAlarmStateUnit::checkForMatch()
• Components’ states
  • vector<KBExpectedComponentStateUnit *> expected_component_state
  • KBExpectedComponentStateUnit::checkForMatch()
• Parameters’ values
  • vector<KBExpectedParameterValueUnit *> expected_parameter_value
  • KBExpectedParameterValueUnit::checkForMatch()
• Parameters’ trend [this is not used.]
  • vector<KBExpectedParameterTrendUnit *> expected_parameter_trend
  • KBExpectedParameterTrendUnit::getExpectedTrend()
• Operator’s actions
  • vector<HardWiredControlActivity *> expected_control;
  • HardWiredControlActivity::checkForMatch()
  • Note: comparing whether an action is matched is determined by the value passed from ADS to RELAP5. The expectation is matched when the absolute value of the difference between the expected value and the simulation value is less than 1E-3.
• Operator’s beliefs on certain system state
  • vector<HardWiredMentalBelief *> expected_mental_belief;
  • HardWiredMentalBelief::checkForMatch()

The confidence_­levels of KBHardWiredUnit are updated only when the operator perceives new information. The function knowledge_base.KBcalculateHardWiredConfidence()is call from OperatorDM(or AT)::oneThroughProcessForBlockI(). For example, if at a given time step the operator perceives a new parameter value, the newly perceived parameter’s name and perceived value are compared with every unit of KB:: expected_parameter_value of every KBHardWiredUnit to recalculate the confidence level (i.e., performed by OperatorDM/AT::knowledge_base::KBcheckHardWiredMatchForParameterValue() called within OperatorDM::infoChunking()).

The process for updating the confidence level of each Hardwired Diagnosis in every time step is described below (using the Decision Maker as an example):

1. KB::KBcheckHardWiredMatchForControl(),

KB:: KBcheckHardWiredMatchForMentalBelief(),

KB:: KBcheckHardWiredMatchForAlarmState(),

KB::KBcheckHardWiredMatchForComponentState(),

KB::KBcheckHardWiredMatchForParameterValue() are called within the OperatorDM::infoChunking() of OperatorDM::oneThroughProcessForBlockI() for each corresponding newly perceived information to calculate effect of the incoming information on all of the operator’s hard wired diagnses.

1. KBHardWiredUnit::checkForControl(),

KBHardWiredUnit::checkForMentalBelie(),

KBHardWiredUnit::checkForAlarmState(),

KBHardWiredUnit::checkForComponentState(), and

KBHardWiredUnit::checkForParameterValue() are called by the corresponding functions listed in STEP 1 for all the newly perceived information to update the value of the numerimator for calculating the confidence level of each KBHardWiredUnit.

1. HardWiredControlActivity::checkForMatch(),

HardWiredMentalBelief:: checkForMatch(),

KBExpectedAlarmStateUnit:: checkForMatch(),

KBExpectedComponentStateUnit::checkForMatch(), and

KBExpectedParameterValueUnit:: checkForMatch() are called by the functions shown in STEP2 to assess the change in the numerator of the equation that calculates the confidence level of each KBHardWiredUnit. Note: since the same piece of information may be perceived in the earlier time step the new information perception would revise the numerators based on the previous state of the expectation. As a result, the possible return values of the above five equation could be an integer between -2 and 2. (See any of the above five functions for detail).

1. KBHardWiredUnit::calculateConfidenceLevel() is called by KB::KBcalculateHardWiredConfidence() which in turen is called by OperatorDM::oneThroughProcessForBlockI() to calculated the confidence level of each KBHardWiredUnit based on the new numeriators updated in STEP3. The confidence is calculated based on the proportial number of of matched expectation to the toal number of expectations. Since the functions in STEP 3 allows negative number in the return value, it is possible that the confidence value calculated is negative. But at the end of function set the confidence level as zero if the confidence level is negative.

In order to model the communication of the same type of information between different modules, IDAC created a number of variations for containing the same type of information in different modules. Also, in order to accommodate the fact that the current GUI does not provides trend input in the control panel the ADS internally splits the storage place for control parameter values and parameter trends into two different objects (i.e., DisplayParameterValueRate and DisplayParameterValue). This results in the value observed from a DisplayParameterValue represents the value of a physical parameter; however, the value observed from a DisplayParameterValueRate represents the rate of change of a physical parameter.

Figure 30 shows the class hierarchical structure relating to parameter values and changing rates. Various types of class on the upper portion of Figure 30 storing same type of information are used for different purposes. For example, ProcedureExpectedParameterValueUnit is used for storing the expected system state instructed by procedures; DecisionExpectedParameterValue is used to store the expected system state in the operator’s memory; the BranchExpectedParameterValue is used to store the branch probabilities information in addition to storing the expected system state; and the DisplayParameterValue is used to represent the parameter values shown in the control Panel.

************Notes: parameters’ values v. Rate of change of Parameters’ values**

Separating parameters’ values from their rates of change only inside the program. A ADS GUI user , not ADS programmer, only distinguish them at setting the display value within the control panel. When a parameter name is started by “RATE_” indicates that the rate of change of the parameter is the desired value; otherwise, the value of the parameter is of interest. Different objects are created (i.e., DisplayParameterValue and DisplayParameterValueRate) for these two types of information. The attribute SystemDisplay::type_of_display distinguishes these two types of parameters with values VDISPLAY_PARAMETER_VALUE and VDISPLAY_PARAMETER_TREND, respectively. The SystemDisplay is a common inheritance of DisplayParameterValue and DisplayParameterValueRate . The ADS code bases on the attribute (i.e., SystemDisplay::type_of_display) to separate parameter values and rate of changes at other occurrences (e.g., ProcedureExpectedParameterValueUnit vs. ProcedureExpectedParameterTrendUnit). On the surface, the users rather than the programmers do not need to know the distinction.

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

Figure 30 The class hierarchical structure for parameter value and parameter changing rate

Mental Beliefs vs. Diagnoses

In the ADS code, two types of representation are used to represent the operator’s perception of the plant state: Mental Belief and Diagnosis. The Mental Belief and Diagnosis are similar concept; however, they are treated differently in the ADS code. In general, Mental Beliefs are the operator’s perception of plant state and are treated as the symptoms relating to current task. Each task is represented by an InfoChunkMental within the Operator.memory.grouped_info. Perceiving a new Mental Belief will not generate a new InfoChunkMental into the Operator.memory.grouped_info. On the other hand, a Diagnosis is treated as a separate task. Perceiving a new Diagnosis will generate a new InfoChunkMental into the Operator.memory.grouped_info.

The Operator.memory.grouped_info represents the operator’s short term memory which includes the Working Memory and Intermediate Memory. At each time step, the priority levels of all InfoChunkMental objects within the Operator.memory.grouped_info are reevaluated. The one with the highest priority is designated as in the Working Memory; others are in the Intermediate Memory. The operator’s decision is based on the information relating to the Working Memory (i.e., the InfoChunkMental object with the highest priority).

Currently, the Mental Beliefs are generated by the operator’s beliefs of plant state specified in the KB_ODM_HardWired_Diagnosis.txt and KB_OAT_HardWired_Diagnosis.txt. The activation of a Mental Belief is based on whether its confidence level is above a certain threshold. The confidence level of a Mental Belief is reevaluated every time step based on the proportional information match specified in the above two files.

Once a Mental Belief is activated, there is a certain percentage of probability that the operator would act on the mental procedure specified corresponding to the Mental Belief in the KB_ODM(OAT)_HardWired_Diagnosis.txt. This is to model the uncertainty that even the operator has a perception of plant state the operator may or may not do something.

If the specified mental procedure do not exist (i.e., no corresponding text file in the ../input/crew/procedures directory) the ADS code treats the situation that the operator would have no response to perceiving the mental belief. The activation and procession of the Mental Beliefs within the ADS code are described in the following section.

***Note on Mental Procedure ****************

In order to distinguish the mental procedure from paper procedure, the ADS use the header “MPBG_” at the beginning of each mental procedure.

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

Currently whenever operator perceives a diagnosis a InfoChunkMental with the diagnosis is added into the Operator.memory.grouped_info. However, currently there is no mechanism to generate diagnoses in the ADS code. The idea is that a diagnosis is generated whenever there is a event within the event-symptom matrix (i.e., Kevin’s task) is activated. Since the events in the matrix can be roughly divided into two levels based on the specifics of the event (e.g., Events LOCA and SGTR are subset of the event “primary mass imbalance”) the rule for calculating the priorities of InfoChunkMental objects must be revisited.

Mental Belief Activation Process

The Decision Maker is used as an example to describe the activation process of an operator’s mental belief.

1. The function knowledge_base.KBcalculateHardWiredConfidence() in OperatorDM::oneThroughProcessForBlockI() recalculate the confidence levels of all mental beliefs specified in the KB_ODM_HardWired_Diagnosis.txt
2. The function Operator::checkAndActivateHWKB() in OperatorDM::oneThroughProcessForBlockI() activates the first mental belief in the list whose confidence level is above the threshold value set in Operator:: threshold_value_for_HWKB_confidence. Only one mental belief maximum would be activated within a time step. If simultaneous more than one mental beliefs whose confidence levels are above the threshold in a time step, only one would be activated at this time step. The other mental beliefs will be activated later.
3. The Operator::checkAndActivateHWKB() generates mental belief branches. The branch goes through the process of Branch_center, CommandControlCenter, and Communication_Place as described in Section 11 to be perceived by the operator.
4. The OperatorDM::identifyRelevantInformation() perceives the mental belief
5. The OperatorDM::infoChunking() registers the mental belief in the operator’s short term memory. At the same time, memory.perceived_info.addNewInstinctiveResponseProcedure() adds a object DecisionProcedureStep into the memory.perceived_info with state_of_activation set to VNONE.
6. The memory.perceived_info.isThereMentalProcedureWaitingForExecution() in OperatorDM::oneThroughProcessForBlockD() check whether there is mental procedure to be performed. Any mental procedure with state of activation is VNONE, VACTIVE, or VPAUSE is identified as a mental belief waiting to be performed.
7. OperatorDM:: performAMentalProcedure() executes the mental procedure. When the state-of-activation of the mental procedure is VNONE (i.e., indicating the mental procedure is just generated and has not been executed) a instinctive_response_procedure branch is generated. The instinctive_response_procedure goes through the Branch_center, CommandControlCenetr, and Communication_place then be perceived by the Decision Maker.
8. In OperatorDM::infoChunking() determine whether the instinctive_response_procedure exists in the ShortTermMemory::perceived_info. If the object already exists then its state-of-activation is changed from VNONE to VACTIVE. Otherwise, a new object is created and added into the ShortTermMemory::perceived_info and whose state-of-activation is set to VACTIVE. An object of pointer is created in the working memory to pointing to the instinctive_response_procedure object.
9. OperatorDM::performAMentalProcedure() executes the mental procedure (i.e., a procedure step) associated with current mental procedure.
10. The mental procedure is performed by ProcedureStep::oneThroughProcessForInstinctiveResponseProcedure(). Once the procedure step is completed, the stat-of-activation of the instinctive_response_procedure object within ShortTermMemory::perceived_info is set to VDONE.

Operator Maneuver Control

This section describes an important operator control behavior modeled in ADS. The operator’s maneuver controls is used to model the behavior of an operator constantly monitor a parameter (e.g., RCS subcooling) and adjust one or several controls (e.g., HPI flow rate) to bring the system to a certain state (e.g., subcooling maintained at about 50 F). Such activities requires operator’s attention, but not all of the operator’s attention, for a certain period of time. Modeling such behavior is complex since the task would in parallel competing with the operator’s other task. As a result, the problem is simplified to that the operator is turn on a automatic system control. The automatic system control would monitor the specified parameters and interact with the plant based on rules set for the automatic control including the frequency of acting on the plant and the duration of the control.

The maneuver control is modeled by Operator:: maneuver_action. This allows modeling of different maneuver patterns of operators for the same purpose. The control patterns for Decisin Maker and Action Taker are stored in ..input/crew/DecisionMaker/ODM_ ManeuverActions.txt and ..input/crew/ActionTaker/OAT_ ManeuverActions.txt, respectively. The same control name can exist in both files. In other words, the two operators can have the maneuver controls named identically. But, the name of each maneuver control should be unique within the same file.

The activation of a maneuver control (e.g., maintain RCS at 50 degree subcooling) is treated same as a regular operator action (e.g., turn off a pump). However, after a maneuver control is started, it is performed based on the rules set for the operator who is executing the control.

The Action Taker’s main responsibilities are to follow the Decisin Maker’s instruction. As a result, the Action Taker only starts a maneuver control whenever he is free (i.e., within the intervals between complte an instruction and the arrival of Decision Maker’s next commands).

The maneuver controls are distinguished from regular operator actions by having the name header “MANEUVER_”. All actions with such name header are treated as maneuver action and the ADS will search the controlling rules from the above two files. The definitions for all maneuver controls must exist. If the ADS can not find the specified maneuver control during simulation, the simulation sequence will be terminated.

The follows use an example to describe the activation and control flow of a maneuver control initiated by an activated mental belief from simulation (or user) perspective. However, as mentioned earlier a maneuver control can be initiated from a paper procedure or mental procedures.

1. Edit a mental belief to activate a mental procedure which contains a maneuver action. E.g.,

MB_HPI_SCM_35

1.0

Number_of_expected_alarm_state 1

A_HPI_INJ 3022

Number_of_expected_component_state 0

Number_of_expected_parameter_value 0

Number_of_manipulative_control 0

Number_of_mental_belief 0

MPBG_HPI_SCM_35 0

1. Based on the mental belief “MB_HPI_SCM_35” specified in Item 1, once the alarm A_HPI_INJ activated, the mental procedure “MPBG_HPI_SCM_35 0” is activated (specified in Operator::checkAndActivateHWKB). The follows show the mental procedure.

MPBG_HPI_SCM_35 0 "maintain RCS subcooling at 50 F"

1 1.0 1 1.0

1

MANEUVER_Throttle_HPI_to_35_SCM 3115 20.0 0.0 3077 1.0

0 3045

MPBG_IR 200

1. The above mental procedure “MPBG_HPI_SCM_35 0” asks the operator to perform the action “MANEUVER_Throttle_HPI_to_35_SCM”. ADS recognizes that this is a maneuver action by the action’s name header “MANEUVER_”. Note: all maneuver actions must be named with such header or the simulation sequence will terminated due to ADS could not find the control name from the list of regular actions (e.g., X_HPI).

In the ADS code, the type_of_action of the maneuver action is specified as “VCONTROL” which is different from the “VACTION” set for nominal controls. (see ProcedureStepUnit::readInfofromFileAction).

1. Each operator has his own set of maneuver controls. The maneuver controls for an operator is specified in ..input/crew/<Operator>/<Operator Brief>_ManeuverActions.txt. For example, the Decision Maker’s maneuver controls are specified in ..input/crew/DecisionMaker/ODM_ ManeuverActions.txt.

Different operators can have same name for a maneuver control but the same maneuver controls’ names should not be repeated for the same operator. For example, both Decision Maker and Action Taker can have a maneuver control named as “MANEUVER_control_A”. But neither Decision Maker nor Action Taker should have two maneuver controls have the same name. The following is an example to describe the format of a maneuver control “MANEUVER_Throttle_HPI_to_35_SCM”.

Maneuver_name MANEUVER_Throttle_HPI_to_35_SCM

Interactive_control_and_control_range X_HPI 0.0 1.0

Targeted_parameter_name SCM_113

LB_target_HB_of_the_target_parameter 30.0 35.0 40.0

Targeted_parameter_rate_name RATE_SCM_113

Rate_boundary -1.0 1.0

Ratio_control_table_3_by_3

Change_rate_less_than_LB 50.0 25.0 0.0

Change_rate_in_between 25.0 0.0 -25.0

Change_rate_greater_than_UB 0.0 -25.0 -50.0

Maneuver_time_interval 10.0

Maneuver_total_duration 300.0

• • The first line specifies the name of the action.
    • The second line indicate the name of control in the control panel by which the operator perform the maneuver control. The two values follow the control are the control range of the control.
    • The third line specifies the targeted parameter to be controlled.
    • The fourth line specifies the lower bound, targeted value, and upper bound of the targeted parameter. These value combining with the changes rate specified in Lines five and six are used to guide the actions to be performed to the system.
    • The fifth line specifies the parameter indicating the change rate of the targeted parameter (i.e., the parameter specified in Line three)
    • The sixth line specify the lower bound and upper bound for the change rate
    • Line seven to nine provide a 3-by-3 table to guide the control activities. The values shown in these three lines are in percentage. They can be represented by the following table:

Table 10 The structure and example entries of the 3 by 3 matrix for maneuver control

	X < LB targeted value	LB targeted value <= X <= UB targeted value	X > UB targeted value
Y < LB change Rate	50.0	25.0	0.0
LB change Rate <= Y <= UB Change Rate	25.0	0.0	-25.0
Y > UB Change Rate	0.0	-25.0	-50.0

Where X and Y are the observe values of the targeted parameter and the corresponded change rate, respectively.

Assume a situation in which both the observed values of the targeted parameter and corresponding change rate are less than their lower bound value. This will result in an increase of 50% of the range between the current setting and the bound to the control value applied to the control (i.e., X_HPI). For example, if current value of X_HPI is 0.7, the final control value is 0.85 (= 0.7 + (1.0 -0.7) * 0.5).

• • Line ten specifies the time interval in seconds between two manueuver actions
    • Line eleven specifies the total duration for this maneuver control. Once the duration is exceeded the maneuver activity is aborted.

1. A maneuver control needs to go through the Branch Center, Command Control Center, and Communication Place to take effect. Currently, a maneuver action is either started by an action in paper procedures or in mental procedures. From programming perspective, they are initiated by ProcedureStepUnit::executeAction.

Within the function “ProcedureStepUnit::executeAction” the sender and “intended_receiver” of an action is specified. For a regular action, if the sender is Action Taker then the receiver is the Plant. If the sender is Decision Maker then the receiver is the Action Taker. For a maneuver action, if the maneuver control is initiated by a paper procedure (i.e., Decision Maker reads procedure and monitors Action Taker executing the instruction), the sender and receiver are Decision Maker and Action Taker respectively. If the maneuver action is activated from a mental procedure then both the sender and receiver are set to the operator who initiates the maneuver action.

The sender and receiver for an action are listed in the Table 11 (see ProcedureStepUnit::executeAction for coding details). Thus, the paper procedure instructed action will use Action Taker’s specifications (i.e., in ..input/crew/ActionTaker/OAT_ ManeuverActions.txt) to perform the maneuver action. The mental procedure initiated maneuver action will use the corresponding operator’s specifications.

Table 11 The sender and intended receiver of an action generated in various conditions

| | Maneuver Action | | Regular Action | | | --- | --- | | --- | | --- | --- | | From

Paper Procedure | From

Mental Procedure | From

Paper Procedure | From

Mental Procedure | | Action Taker | -- (Note: OAT does

not read procedure) | Sender: OAT

Receiver: OAT | -- (Note: OAT does

not read procedure) | Sender: OAT

Receiver: Plant | | Decision Maker | Sender: ODM

Receiver: OAT | Sender: ODM

Receiver: ODM | Sender: ODM

Receiver: OAT | Sender: ODM

Receiver: OAT |

At this point, the maneuver control is treaded same as a regular operator action. Later, when the maneuver enters constant maneuver adjustment stage, the action is carried out through the hardware failure mechanism but with sender indicating the operator who performs it. This is necessary since currently IDAC assumes that an operator only can perform an activity within a time step but multiple system failures or/and automatic responses can happen within a time step. This allow later the operator action and the maneuver activities can occurred at the same time step.

1. If the sender and receiver of an action are ODM and OAT correspondingly (i.e., an action the Decision Maker asks the Action Taker to perform), once receives the information from the Communication Place the Action Taker remembers that the action is asked by the Decision Maker. As a result, a copy of the action is generated in the OperatorAT:: ordered_action (see OperatorAT::infoChunking for programming details). After this point, the Action Taker knows that there is an Decision Maker’s command to be performed. The action is carried out by the Action Taker (sender: Action Taker; and receiver: Plant) by the function OperatorAT::performFollowInstructionStrategy() which is called by OperatorAT::oneThroughProcessForBlockD(). Later when the Action Taker receives the action feedback from the Plant the Action Taker would inform the Decision Make that the action has been performed (see OperatorAT::infoChunking).
2. Once the maneuver action is received by the Control Panel (i.e., the receiver is VPLANT), even the intended receiver is the plant the Control Panel will do nothing on the action except change the sender of the action to Plant and intended_receiver to the operator who sends the action to the plant (see ControlPanel::executeRequestToPlant). The actual action is performed in Operator::checkAndExecuteManeuverAction called within in the OperatorDM(or AT)::oneThroughProcessForBlockI()detects the maneuveraction and set the state_of_activation of the corresponding ManeuverProcedureUnit to VACTIVE (see ManeuverAction::activateManeuverUnit).

Once the maneuverProcedureUnit is activated, the automatic maneuver process is started to perform control (see Operator. maneuver_action.checkAndExecuteManeuverUnit and ManeuverActionUnit::executeManeuverControl). The action executed through the the Hardware Reliability mechanism but with the sender as the operator (i.e., OAT or ODM) and the receiver as the Plant (i.e., VPLANT).

1. Once the total duration is exceed, the state_of_activation of the maneuverProcedureUnit is set to VDONE.
2. The mechanism of maneuver control handling allows an operator “simultaneously” performing several maneuver controls.

The following provides more specific maneuver control modeling flow from the programmer’s perspective. Figure 31 shows the initial distinction between regular actions and maneuver actions followed by three conditions by which actions are executed. The programming flow of these three conditions are described below:

Figure 31 Three types of sender/receiver combination for operator actions.

Siutation 1:

1. (OperatorDM::performFollowProcedureStrategy)

ODM reads the procedure instruction and passes the action

command to Action Taker

2. (OperatorAT:InfoChunking) Action Taker receives the commaond

from Communication Place and make a copy stored in

OperatorAT: ordered_action

3. (OperatorAT::performFollowInstructionStrategy) the ordered_action

is executed with sender: OAT and receiver: Plant

4. (ControlPanel::executeRequestToPlant) Plant (Control Panel) do

nothing since the action name started with "MANEUVER_" but

replies to OAT that the info has been received. This is done by

change the sender and receiver of the action object to Plant and

OAT respectively.

5. (Operator::checkAndExecuteManeuverAction called within

OperatorAT::oneThroughProcessForBlockI) the

Operator::maneuver_action.activateManeuverUnit activates the

corresponding ManeuverActionUnit by changing its

state_of_activation to VACTIVE.

6. (OperatorAT::infoChunking) detects this is a command originated by

ODM so a reply is sent out (to Branch_Center).

7. (OperatorDM::infoChunking) receives the OAT's reply to the maneuver action

then the ODM's Operator::pause_activity is set to false in order to continue

activities.

8. Every time step Operator::maneuver_action.checkAndExecuteManeuverUnit

is called to check and execute a single regular action of the maneuver control

through HardwareReliability (Sender: the operator, receiver: plant)

9. (ControlPanel::executeRequestToPlant) the Hardware Reliability section

executes the single regular action.

Situation 2:

1. (Operator::checkAndActivateHWKB) The operator generates

a mental belief

2. (OperatorAT/DM:InfoChunking)

Operator::memory.perceived_info.addNewInstinctiveResponseProcedure

addes an mental procedure into memory. The state_of_activation of the

instinctive response procedure is set to be VACTIVE.

3. (nfoChunk::isThereMentalProcedureWaitingForExecution) called by

OperatorDM::oneThroughProcessForBlockD() detects the IR procedure

to be performed

4. (Operator::performAMentalProcedure) alled by

OperatorDM::oneThroughProcessForBlockD() executes the action

5. (ControlPanel::executeRequestToPlant) Plant (Control Panel) do

nothing since the action name started with "MANEUVER_" but

replies to OAT that the info has been received. This is done by

change the sender and receiver of the action object to Plant and

OAT respectively.

6. (Operator::checkAndExecuteManeuverAction called within

OperatorAT::oneThroughProcessForBlockI) the

Operator::maneuver_action.activateManeuverUnit activates the

corresponding ManeuverActionUnit by changing its

state_of_activation to VACTIVE.

7. Every time step Operator::maneuver_action.checkAndExecuteManeuverUnit

is called to check and execute a single regular action of the maneuver control

through HardwareReliability (Sender: the operator, receiver: plant)

8. (ControlPanel::executeRequestToPlant) the Hardware Reliability section

executes the single regular action.

Situation 3 (for commands initiated from the Decision Maker only):

1. (OperatorDM::performFollowProcedureStrategy)

ODM reads the procedure instruction and passes the action

command to Action Taker

2. (OperatorAT:InfoChunking) Action Taker receives the commaond

from Communication Place and make a copy stored in

OperatorAT: ordered_action

3. (OperatorAT::performFollowInstructionStrategy) the ordered_action

is executed with sender: OAT and receiver: Plant

4. (ControlPanel::executeRequestToPlant) Plant (Control Panel) executes

the action and replies to OAT that the info has been received. This is done by

change the sender and receiver of the action object to Plant and

OAT respectively.

5. (Operator::checkAndExecuteManeuverAction called within

OperatorAT::oneThroughProcessForBlockI) the

Operator::maneuver_action.activateManeuverUnit activates the

corresponding ManeuverActionUnit by changing its

state_of_activation to VACTIVE.

6. (OperatorAT::infoChunking) detects this is a command originated by

ODM so a reply is sent out (to Branch_Center).

7. (OperatorDM::infoChunking) receives the OAT's reply to the maneuver action

then the ODM's Operator::pause_activity is set to false in order to continue

activities.

8. Every time step Operator::maneuver_action.checkAndExecuteManeuverUnit

is called to check and execute a single regular action of the maneuver control

through HardwareReliability (Sender: the operator, receiver: plant)

9. (ControlPanel::executeRequestToPlant) the Hardware Reliability section

executes the single regular action.

System Decomposition

The KBSystemDecompositionUnit provides a mean for chunking different pieces of information based on the system hardware structure in which the information is associated. Such relationship is established in the file ../input/crew/DecisionMaker (or ActionTaker)/ KB ODM (or OAT) System decomposition. The calling functions include:

• ShortTermMemory::checkAndGenerateInfoChunkMentalForRelatedAlarm
• ShortTermMemory::checkAndGenerateInfoChunkMentalForRelatedAction
• ShortTermMemory::checkAndGenerateInfoChunkMentalForRelatedComponentState
• ShortTermMemory::checkAndGenerateInfoChunkMentalForRelatedParameterValue
• ShortTermMemory::checkAndGenerateInfoChunkMentalForRelatedParameterTrend

Memory Management

The KB declares the memory for each object it created. The memory is released when the KB object is deleted or by calling the function KB::clearKB().

Table 12 The memory management of various functions of KB

Functions	Declared Objects	Objects and Pointers	Pointers Only
Nominal State	hard_wired_diagnosis	X	--
system_decomposition	X	--
system_decomposition_map	--	X
clearKB()	hard_wired_diagnosis	X	--
system_decomposition	X	--
system_decomposition_map	--	X
clearKBForRestart()	hard_wired_diagnosis	X
system_decomposition	--	--
system_decomposition_map	--	--
copyKB()	hard_wired_diagnosis	X	--
system_decomposition	X	--
system_decomposition_map	--	X
copyKBForRestart()	hard_wired_diagnosis	X	--
system_decomposition	--	--
system_decomposition_map	--	--

The function clearKB is called when the KB object is destroyed.

10.4 Event Symptom Matrix

Function	Declared Objects	Objects and Pointers	Pointers Only
clearEventSymptomMatrix()	symptoms	X
events	X
copyEventSymptomMatrix	symptoms	X
events	X

The clearEventSymptomMatrix() is called when the EventSymptomMatrix object is destroyed.

10.5 PIFs

The Operator::Temp_PIF contains three parameters which would affect the operators’ confidences in the events and symptoms developed by Kevin). These parameters are:

• SPDS_value;
• SPDS_rate;
• time_constraint_load;

The first two parameters (i.e., SPDS_value and SPDS_rate) are the value and rate of change of the safety parameter display, respectively. Currently their values are identical as the ones calculated in the ControlPanel. safety_par_display_system. As a result, all operators have the same values of SPDS_value and SPDS_rate.

The value of time_constraint_load is a function of the time constraint loads of a set of important parameters. The time constraint load of a parameter in turn is a function of the time to reaching the individual parameter’s threshold. There are two types of thresholds (i.e., normal threshold and accident threshold). The use of which threshold for calculating the time constraint load is dependent on the operator’s goal. Currently, the final time constraint load of an operator is the maximum time constraint load of these important parameters.

In this model, it is assumed that the operator would scan these key parameter every constant time lapse. As a result, the operator’s time constraint load would not change until the operator scan these parameters again. In order to separate the functions belonging to the ControlPanel from the Operator, the complete process for updating an operator’s time constrain load is executed in three functions.

As shown in Figure 31, if it is time to update the three PIFs’ values the control panel model modules calls the function TimeConstrainedModule::controlPanelUpdateTimeConstrainedValues() to update the parameters data to be used for calculation and calculate the times to reaching the thresholds of normal operation and accident situation. If it’s not time to update the three PIFs, there is no change in the parameters’ values nor times to thresholds. A flag (i.e., parameter flag_time_for_update) is set to indicate whether the values have been changed. If the flag flag_time_for_update is TRUE, the operators’ time constraint loads have to be evaluated otherwise their time constraint loads remain the same values as of the previous time step.

Figure 31 provides a clear functional flow to update the operator’s time constraint load. The block by block explanation is not necessary to be documented in this manual.

Figure 32 Function flow for calculating operator’s time constraint load

No additional memory is located for the PIFKevin except the ones managed by C++.

10.6 Operator

10.6.1 Information Pre-Processing

Figure 31 summarizes the activities of information pre-processing. The diagram shows the process after the incoming information has passed through the external filter (e.g., excessive background noise or visual obstacles). According to the process model:

1. [this filtering mechanism is NOT implemented]
   the non-intentionally gathered information [information that is not actively gathered by the operator] (e.g., an alarm coming to the operator’s attention) has to pass the internal filter to be perceived. Information filtering refers to the mechanism through which the incoming information is reduced, modified, or distorted as a result of cognitive and non-cognitive factors. These include the inherent limitations in the capacity and capability of the operator’s sensory organs and in subsequent mental processing, as well as the effects of PIFs in changing such capacities and capabilities. As a result, external information may not be detected and registered mentally in totality. Examples of factors affecting internal information filtering are altered attention, low alertness, and limited information processing capacity of Working Memory.
2. if the incoming information is intentionally gathered, then the information bypasses the internal filter and is perceived by the operator;
3. the perceived information is temporarily stored in Working Memory which is the basis for retrieving more information from Intermediate Memory and Knowledge Base. Information comprehension and retrieval are typically based on the salient properties of the perceived information such as immediate meaning, importance (e.g., as represented by alarm priority), and relation to the tasks at hand;
4. These salient properties would determine whether the incoming information would form a “calling condition” [8] with the memorized information to retrieve more information from the operators’ Knowledge Base;
5. Information relating and grouping is a process through which various pieces of information are related and grouped (by invoking similar properties) into new, and perhaps more concise, chunks. These chunks may imply different understanding of the external world which will be interpreted and analyzed in the diagnosis and decision-making process (the D-block).

Information prioritization ranks the information chunks based on their urgency and importance. The chunk with highest priority is stored in Working Memory and is the basis for activities in D-block. Other chunks are moved to Intermediate Memory. Figure 33 The flow of information pre-processing

The above process is modeled by the functions contained in the function OperatorDM/AT::oneThroughProcessForBlockI(). The specific functions are:

• OperatorDM/AT::receiveNewInformation(): identifies the information relevant to the operator and processes them. The information remains after this function will be perceived by the operator (i.e., registered in the operator’s memory). This function includes the following three subsequent functions:
  • OperatorDM/AT::identifyRelevantInformation(): identifies the information relevant to the operator to be processed further. Corresponding pointers are generated in the ShortTermMemory::new_info (as shown in Figure 28) pointing to these new information (i.e., in the CommunicationPlace) to be processed further.
  • Operator::attentionalFilter(): an internal filer that screens out the incoming information depending on whether the operator’s attention is located. This function currently is not implemented.
  • Operator::quantificationFilter(): an internal filter that screens out the incoming information based on short term memory capacity. This function currently is not implemented. George Miller’s 7 ± 2 would be a possible basis for this model. [Note: the function would be better named “capacityFilter”
• If the operator perceives any information indicating the system is in abnormal state the following functions will be performed:
  • OperatorDM/AT::infoChunking(): checks whether the newly perceived information is relating to the information registered in the STM by checking whether the subsystems associated with the incoming information also associates with each information chunk in the STM. If there is a common associated subsystem, the corresponding information chunk is adding a pointer that points to the new information. If there is no relation, a new information chunk (in class InfoChunkMental) is created that has a pointer pointing to the new information. The information-subsystem relations are established in the file ../input/crew/DecisionMaker (or Action Taker)/ KB ODM (or OAT) System decomposition.txt.
  • Operator::KB:: KBcalculateHardWiredConfidence(): all the hard-wired diagnoses specified in the file ../input/crew/DecisionMaker(or ActionTaker)/ KB_ODM(or OAT)_HardWired_Diagnosisbased.txt based on the information registered in the STM.
  • Operator:: EventSymptomMatrix::updateBothRationalConfidence: the rational confidences of the symptoms and events are updated based on the information registered in STM. The rational confidences of symptoms are based on the relations specified in the file ../input/crew/DecisionMaker (or ActionTaker) /KB_ODM_HardWired_Diagnosis.txt.
  • Operator::ShortTermMemory::calculatePriorityAndSetStateOfActivation(): calculates the priorities for all info chunks in STM. The info chunk with highest priority (with largest value) is in the Working memory. Other info chunks are in the Intermediate Memory.

The information chunking is an important mechanism for grouping different pieces of information together based on their common characteristics. Currently the attributes based for grouping include:

• the system hardware geographical location associated with each piece of information as indicated in the file ../input/crew/DecisionMaker (or Action Taker)/ KB ODM (or OAT) System decomposition.txt. The information is shown in the control panel and including the following types of information:
  • Alarm: see function ShortTermMemory:: checkAndGenerateInfoChunkMentalForRelatedAlarm
  • Operator action: see function ShortTermMemory:: checkAndGenerateInfoChunkMentalForRelatedAction
  • Perceived Component state: see function ShortTermMemory:: checkAndGenerateInfoChunkMentalForRelatedComponentState
  • Perceived parameter value: see function ShortTermMemory:: checkAndGenerateInfoChunkMentalForRelatedParameterValue
  • Parameter trend: see function ShortTermMemory:: checkAndGenerateInfoChunkMentalForRelatedParameterTrend
• Diagnosis see function ShortTermMemory::checkAndGenerateInfoChunkMentalForDiagnosis

Other types of information not listed above (e.g., goal, strategy, procedure applying) are placed in the information chunk of the working memory at the time of the information perceived. The working memory is the information chunk with the highest priority at the time of determination.

The flow of information chunking in the ADS code is shown in Figure 32 and explained below. At the binning of simulation, prior to perceiving any system abnormal symptom, the operator’s STM has an info chunk with content of goal of normal operation and strategy of wait and monitor. When an operator perceived a piece of information, if the information (i.e., info_i) is the one shown in the control panel then the info_i related sub-systems will be retrieved from the operator’s KB (i.e., the one indicated in the file ../input/crew/DecisionMaker (or Action Taker)/ KB ODM (or OAT) System decomposition.txt). The sub-systems are compared with the subsystems contained in the info chunks of the STM. Since prior to info_i there is no abnormal symptom perceived, a new info chunk is created. The newly generated info chunk would have higher priority than the one of normal operation. When the operator perceives more information, each piece of perceived information will be compared with the info chunks in the STM. If the information is relating to any exist info chunk, relationship will be established between the information and the info chunk. If the information does not relate to any info chunk, a new info chunk is created for the new information. As a result, the number of info chunk within STM would increase along the course of an event. At any point of time, the info chunk with the highest priority is the Working Memory. The rest are the Intermediate Memory.

Figure 34 The information chunking flow

10.6.2 Diagnosis and Decision Making

Currently most of the rules-of-behavior described in Section 3.5 of [7] are not implemented in the ADS code. This is due to software revision, preparing for implementing the new models of operator knowledge and PIFs’ effects, and focusing on modeling the operators’ behavior within the context of following operating procedures.

Currently, the operators only have two optional goals: “Normal Operation” and “Maintain Global Safety Margin” (see Section 3 of [7] for terminology explanation). The implemented strategy include:

• Follow written procedure
• Follow oral instruction
• Direct matching
• Instinctive response

A mechanism with use of “mental beliefs” concept is currently implemented in the ADS code to model operator’s heuristics. The metal beliefs could be used to represent different levels of operator’s perception of the plant state. These mental beliefs can be constructed in the form that they relate to each other to form different levels of abstraction of the system state.

Each mental belief is represented by an object created from the class KBHardWiredUnit. The constitutional elements of a mental belief include alarms, component states, parameter values, parameters states, operator actions, and other mental beliefs. They are modeled by the following elements in the KBHardWiredUnit:

• vector<KBExpectedAlarmStateUnit *> expected_alarm_state;
• vector<KBExpectedComponentStateUnit *> expected_component_state;
• vector<KBExpectedParameterValueUnit *> expected_parameter_value;
• vector<KBExpectedParameterTrendUnit *> expected_parameter_trend;
• vector<HardWiredControlActivity *> expected_control;
• vector<HardWiredMentalBelief *> expected_mental_belief;

See Section 10.3.1.(hard wired diagnosis) for more information.

Each mental belief is associated with a mental procedure. A generic threshold is applied to activating a mental belief based on its confidence which is calculated based on the proportional information matching of its constitutional elements.

**** Note********************************************************

The ADS code internally use different classes for parameter values and parameter trends. The user use the name header “RATE_” to distinguish one from another. As a result, the expected_parameter_trend in KBHardWiredUnit is redundant and should not be used to keep the simplicity. Using the expected_parameter_value instead.

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

******Note Procedure step handling ************************************

All procedure steps (including paper written procedures and memorized (mental) procedures are stored in the folder ../input/crew/procedures. IDAC use a header "MPBG_" for all mental procedures to distinguish one from another. As a result, all mental procedural steps’ names must start with “MPBG_”.

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

10.6.3 Action Executing

Currently the ADS models operator’s action execution is always following the decisions that the operator has made. Cognitive oriented EOOs or EOCs are the main interest of ADS code. Slip type of errors currently is not of interest of the ADS code and is not modeled. Modeling slip type of errors need information of plant information displays, control design, and work place design. When applying to ADS to a specific plant in detail, such information and modeling may be necessary.

10.6.4 Action Taker Specific

In order to model the Action Taker put the commands received from the Decision Maker as high priority task, additional information containers is created in the class OperatorAT. These containers temperately store the commands received from the Decision Maker. Once the command is performed, the corresponding object is removed and memory released.

• list<BranchAction *> ordered_action;
• list<BranchExpectedAlarmState *> ordered_alarm_state;
• list<BranchExpectedComponentState *> ordered_component_state;
• list<BranchExpectedParameterTrend *> ordered_parameter_trend;
• list<BranchExpectedParameterValue *> ordered_parameter_value;

Removing the located memory in the above containers can be done by calling the function OperatorAT::clearOrderedItems(). The memory is taken cared by calling the corresponding memory removal functions.

Table 11 lists the main and sub-sequential memory management function for the Decision Maker and Action Taker. The more specific memory management at the class Operator is shown in Table 12.

Table 13 The main and sub sequential memory management function of the Decision Maker and Action Taker.

Main functions for memory management	Sunsequential memory management functions
OperatorAT::clearOperatorATFinal()	Operator::clearOperatorFinal()
OperatorAT::clearOrderedItems()
OperatorAT::clearOperatorATFromRestartNodeInfoMultiProcessors()	Operator::clearOperatorFinal()
OperatorAT::clearOrderedItems()
OperatorAT::copyOperatorATFromRestartInfo()	Operator::copyOperatorFromRestartInfo()
OperatorAT::copyOrderedInfo()
OperatorAT::copyOperatorATFromRestartInfoMultiProcessor	Operator::copyOperatorFromRestartInfoMultiProcessor()
OperatorAT::copyOrderedInfo()
OperatorDM::clearOperatorDMFinal()	Operator::clearOperatorFinal()
OperatorDM::clearOperatorDMForRestart()	Operator::clearOperatorForRestart()
OperatorDM::clearOperatorDMFromRestartInfo()	Operator::clearOperatorFromRestartInfo();
OperatorDM::clearOperatorDMFromRestartNodeInfoMultiProcessors()	Operator::clearOperatorFromRestartNodeInfoMultiProcessors();

Table 14 The specific memory management of different memory management function of the class Operator

			Objects and Pointers	Pointers Only
clearOperator Final	Memory. clearShortTerm MemoryForRestart()	grouped_info		X
new_info		X
perceived_info	X
knowledge_base. clearKB()	hard_wired_diagnosis	X	--
system_decomposition	X	--
system_decomposition_map	--	X
diagnosis_matrix. clearEventSymptomMatrix()	symptoms	X
events	X
PIFKevin	--	--	--
clearOperator ForRestart	memory.clearShortTermMemoryForRestart()	grouped_info		X
new_info		X
perceived_info	X
knowledge_base. clearKBForRestart()	hard_wired_diagnosis	X
system_decomposition	--	--
system_decomposition_map	--	--
diagnosis_matrix. clearEventSymptomMatrix()	symptoms	X
events	X
PIFKevin	--	-
clearOperator FromRestartInfo()	memory.clearShortTermMemory FromRestartInfo()	grouped_info	X
new_info		X
perceived_info	X
knowledge_base.clearKB ForRestart()	hard_wired_diagnosis	X
system_decomposition	--	--
system_decomposition_map	--	--
diagnosis_matrix. clearEventSymptomMatrix()	symptoms	X
events	X
PIFKevin	--	--	--
clearOperatorFromRestartNodeInfoMultiProcessors
copyOperator FromRestartInfo	memory. copyShortTermMemory FromRestartInfo	grouped_info		X
new_info	--	--
perceived_info	X
knowledge_base. copyKBForRestart	hard_wired_diagnosis	X	--
system_decomposition	--	--
system_decomposition_map	--	--
diagnosis_matrix.copyEventSymptomMatrix	symptoms	X
	events	X
temp_PIFs.copyPIFKevin	--	--	--
copyOperator ToRestartInfo	memory. copyShortTermMemory ToRestartInfo	grouped_info	X
new_info		--
perceived_info	X
copyKBForRestart	hard_wired_diagnosis	X	--
system_decomposition	--	--
system_decomposition_map	--	--
diagnosis_matrix.copyEventSymptomMatrix	symptoms	X
events	X
temp_PIFs.copyPIFKevin	--	--	--