Skip to main content

FRI3D Plant Database

Fire PRA Logic for Circuit Analysis and more#

Task 9 of Nuclear Regulatory guideline 6850 outlines the process for a circuit analysis. This information typically consists of fire zones, scenarios, raceways, cables, components and basic events, with how they are linked together.

The Fire PRA Logic is hierarchical

Database Tables#

The logic database is just an Microsoft access database and this database can be constructed There is no reference integrity in the database, so it is easy to make errors or changes that cause unseen issues, such as spelling a name incorrectly. When importing a model in FRI3D, possible issues like this are logged for the user to check. Current versions allow for more than just fire modeling, but here, we list key tables and fields for the fire modeling used by FRI3D.

  • Zones – The “Zone” field in this table is the name of the zone and all zones referenced in other tables should exist in this table; if they do not, a warning is given when importing into FRI3D. If plant information DB is loaded, then all the zones should also exist in that DB. Note—UNL is commonly used as a zone for all unknown location items and is likely included in most scenarios.

  • Scenarios – These lists all of the current fire scenarios along with data such as the severity factor and CCDP. When loaded into FRI3D these are considered existing plant scenarios, and if a component name is listed in the description, then that component and associated source is assigned as part of the scenario. The “Scenario” field is the name of the scenario, and the “Zone” field is a comma separated field for the zones used in that scenario.

  • Raceways – The “Raceway” field in this table is the name of the raceway; all raceways referenced in other tables should exist in this table; if they do not, a warning is given when importing into FRI3D. Note—there are different types of raceways, but they are not distinguished in the FRANX DB.

  • Cables – The “Cable” filed is in this table is the name of the cable; all cables referenced in other tables should exist in this table; if they do not, a warning is given when importing into FRI3D.

  • Components – The “Component” filed is in this table is the name of the component; all components referenced in other tables should exist in this table; if they do not, a warning is given when importing into FRI3D.

  • Zone_to_Raceway – This is the mapping of what is in a zone. While it says “to raceway,” the “ToEvent” column may be a raceway, cable, component, or basic event name. The “ToType” indicates what item type it is (see ToType below). Often you will have both raceways and component in this field.

  • Raceway_to_Cable – This is the mapping of what is in a raceway. Typically, the “ToEvent” items are cable names; however, technically it is possible to have other items here.

  • Cable_to_Component – This is the mapping of what is connected to a cable. Usually, the “ToEvent” items are components; however, sometimes these are basic event names.

  • Component_to_BE – This is the mapping of components to the basic event names in the PRA model. It is critical that these names are correct, as there is no way for to verify if the names exist or are correct in the PRA model, and so no warnings are provided.

Database Entries#

The “ToType” property is in all of the to relation tables. This refers to the type of item. There have been several changes or additions to the options of this field. Currently, FRI3D recognizes the following and is not case sensitive:

  • Basic Events – [“0,” “BASICEVENT”, “BASIC EVENT,” “BE,” “EVENT”]
  • Component – [“1,” “COMPONENT,” “COMP”]
  • Cable – [“2,” “CABLE”]
  • Raceway – [“3,” “RACEWAY”]
  • Zone – [“6,” “ZONE”].

What's next?#

Reach out

If you need help after reading this doc, email us info@centroidlab.com for an answer. .