Talk:Fault tree analysis Jump to. SAPHIRE is software, so it most definitely doesn't belong. RIAC is an organization, so it most definitely doesn't belong. (as does CAFTA from EPRI). RIAC (now DSIAC) is a DoD-sponsored organization that has published works on reliability and safety for decades. It is well known to professionals who.
From Wikipedia, the free encyclopedia
Fault tree analysis (FTA) is a failure analysis in which an undesired state of a system is analyzed using boolean logic to combine a series of lower-level events. This analysis method is mainly used in the field of safety engineering to quantitatively determine the probability of a safety hazard.
History
Fault Tree Analysis (FTA) was originally developed in 1962 at Bell Laboratories by H.A. Watson, under a U.S. Air ForceBallistics Systems Division contract to evaluate the Minuteman IIntercontinental Ballistic Missile (ICBM) Launch Control System. [1][2][3][4] Following the first published use of FTA in the 1962 Minuteman I Launch Control Safety Study, Boeing and AVCO expanded use of FTA to the entire Minuteman II system in 1963-1964. FTA received extensive coverage at a 1965 System Safety Symposium in Seattle sponsored by Boeing and the University of Washington. Boeing began using FTA for civil aircraft design around 1966.[5][6][7][8] In 1970, the U.S. Federal Aviation Administration (FAA) published a change to 14 CFR 25.1309 airworthiness regulations for transport aircraft in the Federal Register at 35 FR 5665 (1970-04-08). This change adopted failure probability criteria for aircraft systems and equipment and led to widespread use of FTA in civil aviation.
Within the nuclear power industry, the U.S. Nuclear Regulatory Commission began using probabilistic risk assessment (PRA) methods including FTA in 1975, and significantly expanded PRA research following the 1979 incident at Three Mile Island.[9] This eventually led to the 1981 publication of the NRC Fault Tree Handbook NUREG–0492[10], and mandatory use of PRA under the NRC's regulatory authority.
Fault Tree Analysis (FTA) attempts to model and analyze failure processes of engineering and biological systems. FTA is basically composed of logic diagrams that display the state of the system and is constructed using graphical design techniques. Originally, engineers were responsible for the development of Fault Tree Analysis, as a deep knowledge of the system under analysis is required.
Often, FTA is defined as another part, or technique, of reliability engineering. Although both model the same major aspect, they have arisen from two different perspectives. Reliability engineering was, for the most part, developed by mathematicians, while FTA, as stated above, was developed by engineers.
Fault Tree Analysis usually involves events from hardware wear out, material failure or malfunctions or combinations of deterministic contributions to the event stemming from assigning a hardware/system failure rate to branches or cut sets. Typically failure rates are carefully derived from substantiated historical data such as mean time between failure of the components, unit, subsystem or function. Predictor data may be assigned. Assigning a software failure rate is elusive and not possible. Since software is a vital contributor and inclusive of the system operation it is assumed the software will function normally as intended. There is no such thing as a software fault tree unless considered in the system context. Software is an instruction set to the hardware or overall system for correct operation. Since basic software events do not fail in the physical sense, attempting to predict manifestation of software faults or coding errors with any reliability or accuracy is impossible, unless assumptions are made. Predicting and assigning human error rates is not the primary intent of a fault tree analysis, but may be attempted to gain some knowledge of what happens with improper human input or intervention at the wrong time.
FTA can be used as a valuable design tool, can identify potential accidents, and can eliminate costly design changes. It can also be used as a diagnostic tool, predicting the most likely system failure in a system breakdown. FTA is used in safety engineering and in all major fields of engineering.
Methodology
FTA methodology is described in several industry and government standards, including NRC NUREG–0492 for the nuclear power industry, an aerospace-oriented revision to NUREG–0492 for use by NASA[11], SAEARP4761 for civil aerospace, MIL–HDBK–338 for military systems[12] for military systems. IEC standard IEC 61025[13] is intended for cross-industry use and has been adopted as European Norme EN 61025.
Since no system is perfect, dealing with a subsystem fault is a necessity, and any working system eventually will have a fault in some place. However, the probability for a complete or partial success is greater than the probability of a complete failure or partial failure. Assembling a FTA is thus not as tedious as assembling a success tree which can turn out to be very time consuming.
Because assembling a FTA can be a costly and cumbersome experience, the perfect method is to consider subsystems. In this way dealing with smaller systems can assure less error work probability, less system analysis. Afterward, the subsystems integrate to form the well analyzed big system.
An undesired effect is taken as the root ('top event') of a tree of logic. There should be only one Top Event and all concerns must tree down from it. Then, each situation that could cause that effect is added to the tree as a series of logic expressions. When fault trees are labeled with actual numbers about failure probabilities (which are often in practice unavailable because of the expense of testing), computer programs can calculate failure probabilities from fault trees.
A fault tree diagram
The Tree is usually written out using conventional logic gate symbols. The route through a tree between an event and an initiator in the tree is called a Cut Set. The shortest credible way through the tree from fault to initiating event is called a Minimal Cut Set.
Some industries use both Fault Trees and Event Trees (see Probabilistic Risk Assessment). An Event Tree starts from an undesired initiator (loss of critical supply, component failure etc) and follows possible further system events through to a series of final consequences. As each new event is considered, a new node on the tree is added with a split of probabilities of taking either branch. The probabilities of a range of 'top events' arising from the initial event can then be seen.
Classic programs include the Electric Power Research Institute's (EPRI) CAFTA software, which is used by many of the US nuclear power plants and by a majority of US and international aerospace manufacturers, and the Idaho National Laboratory's SAPHIRE, which is used by the U.S. Government to evaluate the safety and reliability of nuclear reactors, the Space Shuttle, and the International Space Station. Outside the US, the software RiskSpectrum is a popular tool for Fault Tree and Event Tree analysis and is licensed for use at almost half of the worlds nuclear power plants for Probabilistic Safety Assessment.
Analysis
Many different approaches can be used to model a FTA, but the most common and popular way can be summarized in a few steps. Remember that a fault tree is used to analyze a single fault event, and that one and only one event can be analyzed during a single fault tree. Even though the “fault” may vary dramatically, a FTA follows the same procedure for an event, be it a delay of 0.25 msec for the generation of electrical power, or the random, unintended launch of an ICBM.
FTA analysis involves five steps:
Comparison With Other Analytical Methods
FTA is a deductive, top-down method aimed at analyzing the effects of initiating faults and events on a complex system. This contrasts with Failure Mode and Effects Analysis (FMEA), which is an inductive, bottom-up analysis method aimed at analyzing the effects of single component or function failures on equipment or subysystems. FTA is very good at showing how resistant a system is to single or multiple initiating faults. It is not good at finding all possible initiating faults. FMEA is good at exhaustively cataloging initiating faults, and identifying their local effects. It is not good at examining multiple failures or their effects at a system level. FTA considers external events, FMEA does not.[14] In civil aerospace the usual practice is to perform both FTA and FMEA, with a Failure Mode Effects Summary (FMES) as the interface between FMEA and FTA.
Alternatives to FTA include Dependance Diagram (DD), also known as Reliability Block Diagram (RBD) and Markov Analysis. A Dependence Diagram is equivalent to a Success Tree Analysis (STA), the logical inverse of an FTA, and depicts the system using paths instead of gates. DD and STA produce probability of success (i.e., avoiding a top event) rather than probability of a top event.
![]() See alsoReferences
![]() External links
SCRAM is a Command-line Risk Analysis Multi-tool.
This project aims to build a command line tool for probabilistic risk analysis.SCRAM is capable of performing event tree analysis, static fault tree analysis,analysis with common cause failure models,probability calculations with importance analysis,and uncertainty analysis with Monte Carlo simulations.This tool can handle non-coherent fault trees, containing NOT logic.
SCRAM input and report files are based on the Open-PSAModel Exchange Format.For the current status of the Open-PSA MEF features in SCRAM,please see the MEF Support documentation.
A complementary GUI front-end is under developmentfor visualization and manipulation of risk analysis models and reports.
To explore the performance of SCRAM or research fault trees,a fault tree generator script is provided,which can create hard-to-analyze fault trees in a short time.
The documentation contains a full description of SCRAM,its current capabilities, and future additions.The latest stable release is packaged for quick installation on various platforms.
Table of Contents
Some dependencies are provided with git submodules (e.g., Catch2).In order to initialize all the submodules,this repository must be cloned recursively with
git clone --recursive ,or the following commands must be executed after a normal clone.
Python and GCC/G++ compiler are assumed to be available on the system.The process is tested on Ubuntu 17.10 using
apt-get as the package manager:
If on a Mac system, homebrew is a good package manager to use.It is assumed that some dependencies are provided by Xcode (e.g., Python, llvm/clang, make).The following instructions are tested on OS X 10.12:
MSYS2/Mingw-w64 is the recommended platform to work on Windows.Assuming MSYS2 is installed on the system,the following instructions will install SCRAM dependencies:
SCRAM installation and executables must be run inside of the MSYS2 shell.
The project is configured with CMake scripts.CMake generates native 'makefiles' or build system configurationsto be used in your compiler environment.If there are dependency issues, CMake output should guide with errors.The configuration and build must happen out-of-source (e.g., in
build sub-directory).
For Mingw-w64 on Windows, specify
-G 'MSYS Makefiles' generator flag.To build tests, specify -DBUILD_TESTING=ON option.
Various other project configurations can be explored with CMake or its front-ends.For example:
An example build/install instruction with the CMake generated Makefiles:
The main and test binaries are installed in
installation/directory/bin .The input files and schema are copied in installation/directory/share/scram/ .
Other tools, such as the fault tree generator,can be found in the
scripts directory.These tools do not require compilation or installation.
This guide assumesthat SCRAM installation directories are in the global path.If this is not the case,
path/to/installation/directory/bin/ must be prepended to the command-line calls.However, if SCRAM executables are not in the path,some system tests and scripts cannot be initiated.
Example configuration and input files are provided in the
input directory.
On command line, run help to get more detailed information:
Various other useful tools and helper scripts,such as the fault tree generator,can be found in the
scripts directory.Help prompts and the documentation have more details how to use these tools.
To launch the GUI front-end from the command-line:
The command can also take project configuration and/or input files:
To run the unit and benchmark tests:
To test the tools in the
scripts directory:
To test the command-line call of SCRAM:
A set of performance tests is providedto evaluate the running times on the host machineand to help developers check for regressions.More details can be found in performance test source files.
To run all performance tests (may take considerable time):
Unfortunately, Qt Test does not automatically register or manage all its test cases,nor does it provide a single test driver.Each test case is a separate binary with its own commands and reports.Take a look at
path/to/installation/directory/bin directoryfor the compiled scramgui_test${CASE_NAME} binaries to run.
All Qt Tests are also manually registered with CTestso that it is possible to run all the GUI tests at once:
The main goal of SCRAM fuzz testingis to discover defects in its analysis code.It is recommended to build SCRAMwith assertions preservedand sanitizers enabled, for example,address sanitizer in GCC and Clang
-fsanitize=address .
In order to speed up the fuzz testing,SCRAM may be built with optimizations but
NDEBUG undefined.Additionally, multiple SCRAM instances can be run at once.
An example command to run SCRAM 1000 times with 4 parallel instances:
The fuzz tester can be guided with options listed in its help prompt.Some options can be combined,and some are mutually exclusive.The priorities of mutually exclusive options and combinations are hard-coded in the script,and no error messages are produced;however, information messages are given to indicate the interpretation.
Fuzzing inputs and configurations are auto-generated.The fuzz tester collects run configurations, failures, and logs.The auto-generated inputs are preserved for failed runs.
The Fuzz tester can checkthe results of qualitative analysis algorithms implemented in SCRAM.If there is any disagreement between various algorithms,the run is reported as failure.
Documentation is generated with the configurations on the gh-source branch.The raw documentation files are in the
doc directory.
The development may followthe Documentation Driven Development paradigm for some new features.Therefore, some documentation may be ahead of the actual developmentand describe features under current development or consideration.
For any questions, don't hesitate to ask the user support mailing list(https://groups.google.com/forum/#!forum/scram-users, [email protected]).
For latest releases and information about SCRAM,feel free to subscribe to the announcements(https://groups.google.com/forum/#!forum/scram-announce,[email protected]).
Please follow the instructions in CONTRIBUTING.md.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |