Support system fault trees (.fta)

Purpose

Support systems are the plant services other equipment depends on — emergency AC power, service water, instrument air. They are not modelled in RELAP5, so their state does not come from a thermal-hydraulic channel. Instead each support system is a fault tree: a logic diagram over component failures whose top event is "this support system has failed".

Two things bind a tree to the simulation:

1. A display item in Section 4 of ControlPanel.txt, which is what the crew can look at and what procedures can check. E-0 Step 3 of the reference model ("Verify Emergency AC Buses Energized") is exactly such a check.
2. A .fta file in Input/SupportSystemsReliability/, whose top node name matches the display item's name.

The support-system reliability module creates one unit per declared display, quantifies its tree, and drives the display state from the result. Hardware fault trees work the same way through Section 3 of SystemReliability.txt, except their .fta files live in Input/HardwareReliability/.

Not quantified in the shipped builds

Support-system fault trees do not currently affect a run. SupportSystemReliabilityUnit::updateFailureProbability() only calls a solver inside #ifdef ENABLE_HCL, the constructor wiring that would load the .fta files is commented out, and the macOS and HPC builds set ENABLE_HCL=OFF. The failure probability is therefore always 0.0, the display never changes state, and no branch is generated. A procedure step that checks a support-system display still runs; it simply always sees the healthy state.

A replacement quantifier that needs neither HCL nor SMILE now exists and is tested (src/FaultTree/, see Fault tree quantification), but it is not yet wired into the engine. Treat this page as the format reference and as preparation, not as a working channel.

The shipped .fta files are placeholders

Reference cases ship Diesel Generator.fta and Emergency AC Buses.fta. Neither is usable content. The diesel tree is a two-event toy (Train A at 0.3, Train B at 0.2, values an order of magnitude off real demand-failure data), and the emergency AC tree is the GeNIe demo car-brakes model — its nodes are "Brakes malfunction", "Master cylinder failure" and "Bad mechanic". Author real trees before drawing any conclusion from them.

---

File format

.fta files are XML written by GeNIe. A diagram holds one top node, and gates nest inside their parents:

<ftaDiagram id="FTADiagram0" missionTime="0">
  <ftaNode id="FTANode0" type="0" failureProbability="0" k="1">
    <node name="Diesel Generator Top Node" description="" x="561" y="173" />
    <ftaNode id="FTANode1" type="2" failureProbability="0.3" k="1">
      <node name="Train A" description="" x="471" y="285" />
      <parent ref="FTANode0" />
    </ftaNode>
    <ftaNode id="FTANode2" type="2" failureProbability="0.2" k="1">
      <node name="Train B" description="" x="651" y="285" />
      <parent ref="FTANode0" />
    </ftaNode>
  </ftaNode>
  <diagram name="Diesel Generator" description="" author="" />
</ftaDiagram>

This tree reads: the diesel generator fails when both trains fail, so the top event probability is 0.3 × 0.2 = 0.06.

Node types

The type attribute selects the gate:

type	Meaning	Notes
0	AND gate	Fails when every input fails.
1	OR gate	Fails when any input fails.
2	Basic event	Quantified by the failureProbability attribute.
3	Basic event	Handled identically to 2.
4	Transfer gate	Pulls in another diagram, named by <transferUpFTADiagram ref="...">.
5	Transfer-up marker	Bookkeeping GeNIe writes for itself. Carries no logic and is ignored.
6	K/N gate	Fails when at least k inputs fail; k comes from the k attribute.
7	NOT gate	Fails when its single input does not. Exactly one input.

The k attribute is present on every node GeNIe writes but only means anything on a type 6 gate. failureProbability only means anything on a basic event. locked, failureRate, basicEventType, testInterval, mttr, and the x and y coordinates are editor state and are not read.

Node identity and repeated events

A node is identified by its <node name>, not by its XML id. A node that appears in several places in the file is defined once and shared everywhere else. That is how a common-cause event is expressed: give the same event the same name under each gate it feeds, and GeNIe writes it as several <ftaNode> elements (plus <clone ref> markers) that collapse back to one event on load.

This matters for the numbers, not just the bookkeeping. Consider a top event OR(AND(A, B), AND(A, C)) where A feeds both gates, with P(A) = 0.5, P(B) = 0.4, P(C) = 0.3. The correct answer is P(A) × P(B or C) = 0.29. Treating the two AND gates as independent gives 0.32. The quantifier evaluates the tree as a network so the shared dependence is accounted for rather than counted twice.

What is rejected

The reader refuses a tree rather than quantifying something ambiguous:

• an unknown type value;
• the same input wired into one gate twice (idempotent for AND and OR, and it silently changes what k means on a K/N gate) — note that an event feeding several different gates is the normal shared case and is fully supported;
• a k that is larger than the gate's input count, or smaller than 1;
• a failureProbability outside [0, 1], or one that does not parse;
• a gate with no inputs, or a NOT gate without exactly one input;
• an input or transfer reference that names a node the file does not define;
• a cycle;
• a basic event linked to a Bayesian network variable (<linkedBBN>), which belonged to the old hybrid model and has no equivalent yet.

---

Declaring the display

A tree only reaches the simulation if a display is declared for it. In ControlPanel.txt:

Control_Panel_Support_System_State    2
FTANode6                              OFF
FTANode0                              OFF

The name must match the fault tree's top node, and the second column is the state shown on failure (the healthy display is the complement).

Every panel item needs a decomposition entry

Any item added to ControlPanel.txt, including a support-system display, also needs a matching line in bothKB_ODM_System_Decomposition.txt and KB_OAT_System_Decomposition.txt:

FTANode0    900    999

Without it every sequence dies at about 0.5 s with checkCompletenessOfSystemDecomposition err.

---

Authoring notes

• One diagram per file, one top node per diagram.
• Name the top node for the system, not for the GeNIe node id. FTANode0 is what the reference files happen to use; Emergency_AC_Buses is a better name and works identically as long as the ControlPanel entry matches.
• Use no spaces in the top node name if you intend to reference it from ControlPanel.txt or SystemReliability.txt: those readers are token-based and split on whitespace. Names deeper inside the tree may contain spaces.
• Keep gates narrow. A gate is expanded into a table over its inputs, and the quantifier refuses gates wider than 20 inputs. Nest instead.