SystemReliability.txt

Purpose

SystemReliability.txt identifies conditional hardware failure events. A conditional hardware failure is a demand failure — it is triggered not by elapsed time, but by a change in a component's state. Specifically, the failure event fires when the associated component state transitions to ON (integer code 3022, VON).

The failure state applied to the hardware controller (i.e., the control value set when the failure mode activates) is specified by the failure_value or failure_state field in ControlPanel.txt, not in this file.

Two branches per event

Unlike initiating events (which produce only a failure branch), each conditional failure event generates two branches: a success branch (no failure) and a failure branch. If the operator attempts recovery, two more branches are generated — one for successful recovery and one for permanent failure — for a total of up to three branches per event.

One activation per event

Each conditional hardware failure event is activated only once per simulation run, at the first time the associated component state is set to ON.

---

Comparison with Initiating Events

Characteristic	Initiating Event	Conditional Failure
Input file	Initiating_Event.txt	SystemReliability.txt
Activation	Simulation time	Component state = ON (3022)
Initial branches generated	One (failure only)	Two (success and failure)
Recovery possible	Yes	Yes
Max total branches	3	3

---

Probability Distributions

Failure probability is sampled from a Beta distribution (Equation 19):

$$p(x)=\frac{\mathrm{\Gamma }(\alpha +\beta )}{\mathrm{\Gamma }(\alpha )\mathrm{\Gamma }(\beta )}{x}^{(\alpha -1)}(1-x{)}^{(\beta -1)}$$$$\overline{p}=\frac{\alpha }{\alpha +\beta }\text{(mean value)}$$

Recovery probability is sampled from an identical Beta distribution (Equation 20) using alpha_rec and beta_rec.

To improve simulation reproducibility, select α and β values that minimize variance. Distributions p(x, α=1, β=1) and p(x, α=100, β=100) have the same mean (0.5), but the latter has more than an order of magnitude lower variance.

Dummy recovery values

When recovery is not physically realistic, use recognizable dummy values (e.g., alpha_rec = 1.0, beta_rec = 1.0) or set an effectively zero recovery probability (e.g., alpha_rec = 1.0, beta_rec = 1e6).

---

Input File Format

The file has three sections, read in order, and all three headers must be present even when a section is empty. Each event is one line of six fields (the parser is token-based, so line breaks and other whitespace are interchangeable):

System_Reliability             number_of_reliability_events
component_state_name_1         control_name_1    alpha_fail    beta_fail    alpha_rec    beta_rec
.
.
component_state_name_n         control_name_n    alpha_fail    beta_fail    alpha_rec    beta_rec

System_Operation_Reliability   number_of_operation_events
component_state_name_1         control_name_1    failure_rate    delta_t    intervals    alpha_rec    beta_rec
.
.

System_Reliability_FT          number_of_fault_tree_events
component_state_name_1         control_name_1    fault_tree_top_node_1
.
.

The count is not a filter — trailing rows break the later sections

The reader consumes exactly number_of_reliability_events rows and then expects the next section header. Rows left below the count are not skipped: the first of them is read as if it were that header, which fails, and the parser prints

WARNING: SystemReliability.txt: malformed or unexpected content where
readSystemOperationReliabilityInfoFromFile expected a section header —
remaining failure models NOT loaded.

to the console and to err messages.txt, then loads nothing further. The shipped tests/BV4 file is in exactly this state: System_Reliability 0 followed by 14 rows, so none of its events load and neither of the later sections is reached. To disable events without deleting them, move them below the count and keep the remaining section headers, or comment the file down to what you want read.

---

Parameter Reference

Parameter	Format	Range	Description
number_of_reliability_events	Integer	> 0	Number of failure events to read. Events beyond this count are ignored. Set to 0 to disable all events without deleting them.
component_state_name	String	must match ControlPanel.txt component	Name of the component state that triggers the failure event when set to ON (3022). No spaces; use _.
control_name	String	must match ControlPanel.txt controller	Controller whose value is set to the failure_value/failure_state when the failure branch is activated. No spaces; use _.
alpha_fail	Double	> 0.0	α parameter of the failure Beta distribution (Equation 19).
beta_fail	Double	> 0.0	β parameter of the failure Beta distribution.
alpha_rec	Double	> 0.0	α parameter of the recovery Beta distribution (Equation 20).
beta_rec	Double	> 0.0	β parameter of the recovery Beta distribution.

Enabling and disabling events

To activate only one failure event, move it to the top of the list and set number_of_reliability_events = 1. All events beyond that count are ignored without modification — but see the warning above about keeping the later section headers reachable.

---

Execution

A demand opens two alternatives, one with the component working and one with the failure applied (the named controller is driven to its failure state). The running sequence continues with one of them; the other is opened as a child sequence that restarts from the branch point with its own alternative applied. See How a Branch Alternative Executes.

---

Section 2 — System_Operation_Reliability

Failures that accumulate while a component runs, rather than on demand. The first section asks "did it start?"; this one asks "did it keep going?". The failure probability comes from a failure rate applied over an interval instead of a Beta distribution.

Parameter	Format	Range	Description
number_of_operation_events	Integer	≥ 0	Number of running-failure events to read. 0 is valid, and the header is still required.
component_state_name	String	must match ControlPanel.txt component	Component whose running state is monitored.
control_name	String	must match ControlPanel.txt controller	Controller driven to its failure state when the failure branch is taken.
failure_rate	Double	> 0.0	Failure rate λ, per unit of simulation time.
delta_t	Double	> 0.0	Length of one exposure interval. The failure probability over an interval is 1 - exp(-λ·Δt).
intervals	Integer	> 0	Number of exposure intervals to spread the mission over. Each interval is a separate opportunity to branch, including intervals that fall after the last demand event of Section 1.
alpha_rec, beta_rec	Double	> 0.0	α and β of the recovery Beta distribution, as in Section 1.

---

Section 3 — System_Reliability_FT

Failures quantified from a fault tree rather than from a distribution on the row. The row names the tree's top node; the tree itself is a .fta file in the same Input/HardwareReliability/ directory.

Parameter	Format	Range	Description
number_of_fault_tree_events	Integer	≥ 0	Number of fault-tree-driven events to read. 0 is valid, and the header is still required.
component_state_name	String	must match ControlPanel.txt component	Component whose state change demands the system.
control_name	String	must match ControlPanel.txt controller	Controller driven to its failure state when the failure branch is taken.
fault_tree_top_node	String	must match a <node name> in a .fta file	Top event of the tree that supplies the failure probability.

Fault-tree events do not quantify in the shipped builds

HWReliabilityFTUnit::updateFailureProbability() only calls the solver inside #ifdef ENABLE_HCL, and the macOS and HPC builds set ENABLE_HCL=OFF, so the probability stays 0.0 and the failure branch is never taken. Use Section 1 or Section 2 for anything that has to run today. The replacement quantifier is described in Support system fault trees; the same .fta format and the same limitation apply to both.

---

Sample Input

System_Reliability             2
Main_Steam_Isolation           X_SGTR_SG_A        50000.0     5.0    100000.0    9.0
Reactor_Trip                   X_MD_AFW_Pump_A    100000.0    1.0    1.0         1.0
System_Operation_Reliability   0
System_Reliability_FT          0

The two empty section headers are not decoration: without them the parser reads the end of the file where it expects System_Operation_Reliability and reports the malformed-file warning above.

What this sample does

Two conditional failure events are defined:

Event 1: Main_Steam_Isolation → X_SGTR_SG_A

When the Main_Steam_Isolation component state is first set to ON, two sequence branches are generated:

• Branch 1: No failure (steam generator tube rupture does not occur).
• Branch 2: The controller X_SGTR_SG_A is set to its failure state (ON, IC_836 = 1.0), initiating a tube rupture in the RELAP model.

Mean failure probability = α / (α + β) = 50000 / (50000 + 5) ≈ 0.9999.

Event 2: Reactor_Trip → X_MD_AFW_Pump_A

When Reactor_Trip is first set to ON, two branches are generated:

• Branch 1: No failure (motor-driven AFW pump A operates normally).
• Branch 2: Controller X_MD_AFW_Pump_A is set to its failure state (OFF, IC_828 = 0.0).

Mean failure probability = 100000 / (100000 + 1) ≈ 0.99999.

INFO

The ControlPanel.txt file must define the failure_value or failure_state for each referenced controller. In this example:

Control Name	Failure State	Interactive Control	ON value	OFF value
X_SGTR_SG_A	ON	IC_836	1.0	-1.0
X_MD_AFW_Pump_A	OFF	IC_828	1.0	0.0

The RELAP input deck must include logic to respond to these interactive variable values.