Control Panel Module
The Control Panel Module (the global object Indicator created from class ControlPanel) is the interface for the crew and hardware reliability modules to interact with the plant. The types of data in the Control Panel include parameter value, changing rate of parameter value, component state, controls, and alarms. Recently the safety parameter display system (SPDS) and a factor would be used for calculating operator time-constraint-load also are added (i.e., for SPDS) and on the process of been added (i.e., for the factor affecting time-constraint load) into the Control Panel Module.
Each type of information declared in the Control Panel Module is represented by corresponding classes contained within the Control Panel Module currently including (see declaration in the ControlPanel.h):
- ControlPanelDisplay indicators
- ControlPanelAlarm alarms
- ControlPanelControl controls
- SPDS safety_par_display_system
The object Indicator includes the information of physical parameter values, changing rate of the physical parameter values, and component states. The object alarms contains three types of alarms. The object controls contains two types of control that are the channels for the Crew and Hardware reliability modules to interact with the plant. The object safety_par_display_system models the safety parameter display system. It generates an indicating value for the state of system criticality and the changing rate of the value. These objects are discussed in the following subsections.
The analyst has to base on the data available to construct the data required within the Control Panel Module. Within the Control Panel Module, there is an order for information update. The data within the object Indicators and controls are updated directly based on the information in the System Module. The alarms and safety_par_display_system objects base on the data within the object Indicator to update their data.
Communication Between System Module and Control Panel Module
In order to increase the efficiency of updating parameter values within the Control Panel module, maps are constructed for searching the elements within the objects indicators, controls, and alarms. One map for each object. Each map element contains the identification of an element and a pointer pointing to the element and the corresponding element contains a pointer pointing to the map element in the System Module (as shown in Figure 11). Such modeling have the following benefits:
- high efficiency in data search due to the use of maps and pointers
- minimize the use of memory
- ease memory control since all maps contains pointers only. The memory of these maps is automatically released when their corresponding containers (i.e., objects) are destructed.
As shown in Figure 12, on the upper portion shows the seven vectors declared in the System Module and the map (i.e., system_map) containing pointers pointing to the corresponding elements of the System Module (Line 1 in Figure 12). The bottom half of Figure 12 shows three objects of the Control Panel Module. Within each object is a number of vectors that store different types of information, and a map to facilitate searching for a specific element.
The Path 2 in Figure 12 shows that an display_map element points to its corresponding object in the ControlPanel::indicators (explained in Table 3). Path 3 shows the object of the ControlPanel::indicators contains a pointer pointing to an element of the System_module. Which is established by using the system_map to identify the corresponding element in the System Module (Paths 3_1 and 3_2 shown in Figure 12). This is within the ID of the System Module element is one attribute of the ControlPanel::indicators object. The corresponding pointer used in Paths 2, 3, and 1 as described are shown as below:
Table 3 The objects and parameters involved for updating ControlPanelDisplay
| Path | Pointer/Function involved | Explanation |
|---|---|---|
| 2 | map<string, SystemDisplay *> ControlPanelDisplay::display_map | The SystemDisplay* pointer SystemDisplay* points to its corresponding element in the ControlPanel:: indicators |
| 3 | THElement* SystemDisplay :: ptr_to_corresponding_TH_element | The ptr_to_corresponding_TH_element pointer points to the corresponding object within the System Module |
| 3_1 | SystemDisplay:: getCorrespondingSystemName() | This function obtain the ID of the corresponding element of the System Module to be used to locate the element. |
| 3_2 | THElement * SystemModule:: getComponentFromSystemMap(string) | This function is used to return the pointer pointing to the element whose ID is indicated by the string. |
Figure 13 shows the class hierarchy of the objects declared in ControlPanel::indicators and key information for identifying the corresponding object in the System Module. The top four classes circled by bold square are declared in ControlPanel::indicators. They are inherit the classes SystemDisplay and DisplayElement. These two basic class contain attributes to locate the corresponding object in the System Module.
The data update of the ControlPanel::controls is similar to what described for updating the ControlPanel:: indicators. The reader can refer what is discussed above to identify the pointers and functions involved.
Figure 12 The information search path for the Control Panel Module
Figure 13 The class hierarchy of the objects declared in ControlPanel::indicators and key information for identifying the corresponding object in the System Module.
Path 4 indicates the use of an alarm ID to locate the corresponding alarm object declared in ControlPanel::alarms. The class AlarmControlPanelUnit is a common properties of the three types of alarms declared in the ControlPanel::alarms. A pointer “SystemDisplay* AlarmControlPanelUnit::ptr_to_corresponding_indicator” of AlarmControlPanelUnit points to the corresponding object within the ControPanel::indicators. The function “SystemDisplay *ControlPanelDisplay::getDisplayFromMap(string)” is used to specify the pointer within the alarm element to point to the corresponding object within the ControlPanel::indicators. Figure 14 shows the class hierarchy of the alarm objects declared in the ControlPanel::alarms.
Figure 14 The class hierarchy of the objects declared in ControlPanel::alarms and key information for identifying the corresponding object in the ControlPanel::indicators
Update Control Panel Module
The ControlPanel::oneThroughProcess() consists a list of function calling activities that would advance the Control Panel to the next time step. These activities include:
- ControlPanel::updateDisplay()
This functions calls ControlPanel::indicators.updateAllDisplayValueAndState() to update the states of all parameters (including changing rate) and components.
- ControlPanel::checkForNewAlarms()
- ControlPanel::safety_par_display_system.updateAllSPDSValueAndRate()
- ControlPanel::executeRequestToPlant()
ControlPanel::updateDisplay
The function ControlPanel::updateDisplay() is pretty much discussed in Section 7.1. This section will not repeat what has been discussed in Section 7.1.
One thing needs to mention is how an object of DisplayParameterValueRate is updated. In the ControlPanel.txt which specifies the input information for the Control Panel module has the items declared as DisplayParameterValue and DisplayParameterValueRate within the same section. The only distinction is that all the items’ ID started with “RATE_” (note: must be capital characters) is recognized as an object of DisplayParameterValueRate, otherwise the item is recognized as a DisplayParameterValue. (See the function ControlPanelDisplay::readInfoFromFile() for detail). The two types of object are stored in inserted in their corresponding vectors (i.e., vector<DisplayParameterValue *> parameter_value_array and vector<DisplayParameterValueRate *> parameter_trend_array within ControlPanelDisplay). As a result, inside the program these two types of information are treated separately.
The linear regression method is used to calculate the changing rate of a parameter. As a rest, the result of a DisplayParameterValueRate is the changing rate (in the unit of per minute) of the parameter. Currently the ADS takes a number of consecutive data points to perform regression calculation. The number of data point is specified in DisplayParameterValueRate::num_of_item_for_cal_rate. The time difference between two consecutive data is a time step (i.e., about a second).
Each DisplayParameterValueRate object contains two deques (a deque is a type of array) to store the raw data for calculating changing rate:
- deque<double> par_history;
- deque<double> time;
At the simulation initialization process, after the DisplayParameterValueRate reads in the first value from the System Module, it immediately inserts the same values into the par_history a number of times. The number of repeat insert is defined by DisplayParameterValueRate::num_of_item_for_cal_rate. The same number of value in time by decreasing a second for each insert into the time deque. This initializes the raw data for calculating the rate of change (see the function DisplayParameterValueRate::addAValueIntoParHistory() for details).
After the deques for raw data been initiated, at every time step the new data set (i.e., value, and time) are inserted into the end of the deques par_history and time. Then the first values of these two deques are popped up to remain the size of deques in constant. Then the function DisplayParameterValueRate::calculateRateOfChange() is called to calculate the rate of change with use of linear regression.
ControlPanel::checkForNewAlarm
ADS uses alarms for two purposes. One purpose is regular alarms that alter the operators about the plant anomalies. The second purpose is to terminate a sequence based on the conditions set to activate the alarm. This simulates a sequence is terminated by extreme parameter values. The second type of alarm requires the alarm ID started with “A_ENDSEQ_” (see ControlPanel::checkForNewAlarms() for details).
The function updateDisplayedAlarmState() declared by each type of alarm object in ControlPanel::alarms provides the logics to determine whether the alarm be activated.
ControlPanel:: safety_par_display_system.updateAllSPDSValueAndRate
The safety_par_display_system is used as an indication of the current plant state of criticality to model the Safety Parameter Display System in the control room. Two values are generated in safety_par_display_system: SPDS_value and SPDS_rate. The later is simply the changing rate of the SPDS_value. Linear regression is use to calculate the changing rate.
Calculation of the SPDS_value and SPDS_rate is based on a few selected parameters within the ControlPanel::indicators. These parameters are identified in SPDS_input.txt which is stored in the directory “../input/Indicators /”.
Since the function for calculating the SPDS_value has not settled at this time, this section does not provide detail discussion of the calculation. The programmer can looks into the SPDSUnit::calculateSPDSUnitValue() for up-to-date information.
ControlPanel::executeRequestToPlant
This function performs activities of providing system information requested by the operators (i.e., parameters value/rate, component state, and alarm) and acting on the system due to hardware failures or crew actions. Currently the SPDS information has not been added into this function. However, another mechanism for delivering the SPDS information to operator might be needed since we are assuming the operator is constantly monitoring the SPDS. In this case, a function can be added into ControlPanel::executeRequestToPlant to deliver the SPDS information to the CommunicationPlace (discussed in Section ?) every constant time interval to be perceived by the operators.
In order to model crew-crew communication, crew-system interaction, and system failure, the ADS uses an object CommunicationPlace for communication. It’s easier to think the CommunicationPlace as a white board. At every time step, all communication information is placed in the white board. Each piece of information placed in it contains two attributes: sender and intended receiver. Within a time step, every module of ADS come to check the information contained within this white board and based on the sender and received to determine the information to be perceived. Each module has their only rules that specify how to response to these information.
The sender and intended receiver approach provides a flexible modeling framework. It allows adding additional modeling components and revising the information processing rules for an individual object without affecting other objects. Currently the objects modeled in the communication loop include: Decision Maker, Action Taker, Hardware Reliability, and Control Panel. The Consultant is currently not modeled in the ADS code. Within the sender and intended receiver framework, all the four participating objects are treated equally as a communication agent.
A communication loop could requires a few pivotal events shown in the DDET. For example, a communication loop such as the Decision Maker asks the Action Taker to check a parameter value would include the four interactions as shown in Table 4. More detailed discussing in how the communication is processed within ADS is in Section 11.
Table 4 Four interactions for completing a communication loop of the Decision Maker asks the Action Taker to check for a certain parameter state and report back.
| Seq. | Sender | Intended Receiver | Message |
|---|---|---|---|
| 1 | Decision Maker | Action Taker | Check the state of parameter A; There is time delay for the Action Taker to carry out the Decision Maker’s command. |
| 2 | Action Taker | Control Panel | Control Panel will response the request immediately; If this communication is for information, the Control Panel will send the requested information to the CommunicationPlace; If this communication is an action to change the system state, the Control Panel will carry out the command. |
| 3 | Control Panel | Action Taker | The information is obtained by the Action Taker. |
| 4 | Action Taker | Decision Maker | The Action Taker replies the requested information to the Decision Maker. |
Within the ControlPanel::executeRequestToPlant function, first the actions to plants are checked. This includes the action from the crew and due to hardware failure (i.e., by Hardware Reliability module). The CommunicationPlace stores each type of communication separately. The former types of actions (i.e., crew action to plant) are by checking whether in the CommunicationPlace exists the action command whose intended received is “Plant” (i.e., the Control Panel from programming perspective). The second type of action (i.e., plant state change due to hardware failure) is by checking whether there is hardware reliability related actions within the CommunicationPlace. After the actions to changing plant state has been checked, the requests for checking component state, physical parameters, and alarms are checked in ControlPanel::executeRequestToPlant.
Memory Control
The Control Panel module locates memory for all objects declared within this module. When restarting from a node, first, all memory located for the Control Panel is released by calling the function ControlPanel::clearControlPanel or ControlPanel::clearForRestart. After all memory is released, the Control Panel object copies content from the RestartNodeInfo by calling ControlPanel::copyControlPanel.