Hardware Reliability Module
The Hardware Reliability module (declared in ADS as HWReliabilityModule System_reliability) registers a list of components when any of these components is demanded would generate two branches: success and fail on demand. The user is able to provide a constant failure probability for each specified component. The constant failure probability could be entered either by providing a value directly or calculated by a fault tree which represent the effects of its support system. In current ADS model, only the failure on demand is considered but not failure during operation.
Generate Component Failure Branches
Each component failure opportunity is represented by an object declared from the class HWReliabilityUnit. The declaration of this class is summarized as below:
class HWReliabilityUnit :
public BranchSystemAction,
public StateOfActivation
{
int initial_component_state;
DisplayComponentState *corresponding_component_pt;
}
The StateOfActivation controls the component failure would be activated once maximum per sequence. The BranchSystemAction stores data to be sent to the Control Panel Module, consequently the System Module, to change the system state. The initial_component_state provides a basis for comparison on state change. If the current state differs from the state specified in initial_component_state is identified in ADS as a component state change. The pointer corresponding_component_pt points to the component in the Control Panel associating to the object.
As mentioned in the discussion of the input file SystemReliability.txt for entering the hardware reliability data (specified in HWReliabilityModule::readInfoFromFile()), only four values are entered for each HWReliabilityUnit. Using the example context shown below these four values include:
- the component ID specified in the control panel (i.e., the “HPI_ON” in the example). This must be a component specified in the control panel. When the state of this component changed, the hardware reliability branch is generated. The branches are generated once only of a simulation.
- the corresponding control ID specified in the control panel (i.e., the “X_HPI” in the example). This must be an existing control element specified in the control panel.
- a dummy value. This value was originally to be passed to RELAP5 for control when the component value occurs. However, since the value already specified in other place in the GUI input (explain later), the ADS code does not use this dummy value.
- the probability component failure when demanded.
----Example content of SystemReliability.txt Begin----------
System_Reliability 1
HPI_ON X_HPI -1.0 0.01
----Example content of SystemReliability.txt End----------
Tables 5 (the bottom row in Figure 15) and 6 (the first row in Figure 16) show examples of ADS GUI entry for a component state and an interactive control (i.e., to interactive with RELAP5). The interpretation of this entry is the following:
- (Table 5) When the component “HPI_ON” changes its state, two branches will be generated for hardware failure on demand
- (Table 5) The component “HPI_ON” state change is determined by the value of the system component “LT_1660” (a logic trip). When the value of LT_1660 is greater than 0.01 then the state of the HPI_ON is ON. These are specified by the “Relational Operator” and “Threshold Value”. When the logic trip 1660 is false, the value of LT_1660 is “-1.0”; when the logic trip 1660 is true, the value of LT_1660 is the time at which the logic trip changes to true.
- (Table 5) The failure state of component “HPI_ON” is set to be OFF.
- (Table 6) When the HPI_ON component state changes, two branches are generated (i.e., success and fail). The success branch will do nothing to the component. However in the failure, since the “state when fail” of HPI_ON is set to be OFF, this results in a valve specified in X_HPI for “Off/Close” (i.e., -1.0 in Table 6) to be passed to RELAP5 to model the HPI fails on demand.
As a result, when the component “HPI_ON” fails, its value state is “OFF” (shown in the State When Fail in Table 5). The value “-1.0” (shown in the “off/Close” column of Table 6) is passed to X_HPI to interact with RELAP5.
Table 5 An example entry for an ADS component state related parameters (input file)
| Display Name | System Name | System Parameter Name | Time for Checking | State when Fail | Relational Operator | Threshold Value |
|---|---|---|---|---|---|---|
| HPI_ON | LT_1660 | Trip_time | 20.0 | OFF | GREATER_THEN_ON | 0.01 |
Table 6 An example entry for an ADS interactive control related parameters (input file)
| Display Name | System Name | Time | On/Open | Off/Close | Neutral Control | State When Fail |
|---|---|---|---|---|---|---|
| X_HPI | IC_812 | 20.0 | 1.0 | -1.0 | 0.0 | OFF |
Operator Act on a Failed Component
When a control panel control is failed and the operator acts on the control such situation in ADS is treated as the operator intend to perform recovery action on a failed component. This will generates two branches: successful recovery and fail recovery. Since there is no external place now for the analyst to specify the branch probabilities fixed values (0.6 for successful recovery and 0.4 for fail recovery) are specified in the source code (see the function ControlPanel::executeRequestToPlant()).
An example of using such function is that the HPI is specified possible fail when activated. After the HPI activated, the KB_ODM(OAT)_HardWired_Diagnosis.txt could set the operator to check the HPI flow rate. Following the HPI failure branch, the operator perceives that there is no HPI flow. Another mental belief could set in the KB_ODM(OAT)_HardWired_Diagnosis.txt to act on the HPI again. This action is seen as recovery action and would generates two branches: successful and fail recoveries. Example input of such implementation is shown below:
==== In the KB_ODM(OAT)_HardWired_Diagnosis.txt ======
chk_HPI_Succed
0.6
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_Alarm 0
MB_HPI_Fail
0.7
Number_of_expected_alarm_state 1
A_HPI_INJ 3022
Number_of_expected_component_state 0
Number_of_expected_parameter_value 1
FT_711 3010 1.0 0.0
Number_of_manipulative_control 0
Number_of_mental_belief 0
MPBG_HPI_Fail_handle_procedure 0
=====The procedure step: MPBG_HPI_Alarm 0 ==================
MPBG_HPI_Alarm 0 "See procedure description"
1 1.0 1 1.0
1
A_RX_TRIP 3090 0.0 0.0 3077 0.0
1
FT_711 3045 20.0 0.0 3077 3045 3006 1.0 0.0 3045
3110
MPBG_HPI_Activation 0
NONE 0
==== The procedure step: MPBG_HPI_Fail_handle_procedure 0 =====
MPBG_HPI_Fail_handle_procedure 0 "see procedure description"
1 1.0 1 1.0
1
X_HPI 3098 20.0 0.0 3077 1.0
0 3045
NONE 0
=== Within the SystemReliability.txt =================
System_Reliability 1
HPI_ON X_HPI -1.0 0.01
Using the above input as an example, after HPI_ON (i.e., an indication of HPI activation), two branches, HPI successful on and fail to on with corresponding probabilities 0.99 and 0.1 respectively, are generated. A alarm A_HPI_INJ is activated when HPI is demanded. This will activate the mental belief “chk_HPI_Succed” resulting in the operator following the mental procedure “MPBG_HPI_Alarm 0”.
The “MPBG_HPI_Alarm 0” asks the operator to check FT_711 (i.e., HPI flow rate). If FT_711 is greater than 1.0 then the HPI is successfully on, otherwise the HPI is fail on demand. In the situation in which the HPI fails on demand, the mental belief “MB_HPI_Fail” is activated that causes the operator to follow the mental procedure “MPBG_HPI_Fail_handle_procedure 0”.
The “MPBG_HPI_Fail_handle_procedure 0” asks the operator to act on the X_HPI again. Since prior to acting on X_HPI the control X_HPI whose functional state is set to failed due to the setting in the SystemReliability.txt, the operator acts on X_HPI is similar to the activity of trying to recover a failed HPI. As a result, two branches are generated for successful and fail recoveries.
Memory Control
The Hardware Reliability Module locates memory for each objects (i.e., HWReliabilityUnit) it declared. All the memory is removed when the object of the Hardware Reliability Module is destroyed or by calling the function HWReliabilityModule::clearForRestart.