C++ Python CMake Other
Clone or download
rakhimov Replace waffle.io w/ GitHub Projects
[skip ci]

GitHub Projects is a good-enough integrated solution
for a simple progress management.
Latest commit 0921c00 Jul 25, 2018
Failed to load latest commit information.
.travis Run pylint 2.0 separate from prospector on Travis-CI Jul 23, 2018
cmake Remove unused LibFindMacros.cmake module Dec 6, 2017
doc Switch from Landscape.io to Codacy Jul 24, 2018
gui GUI: Rename config -> project in MainWindow Jul 23, 2018
input Convert TwoTrain/config.xml into project.xml Feb 24, 2018
scripts Fix pylint 2.0 warnings Jul 23, 2018
share Add version attribute to Project file Feb 24, 2018
src Refactor ext::linear_{set,map}::emplace Mar 16, 2018
tests Add more tests for Extern{Function,Expression} Mar 6, 2018
.appveyor.yml Exclude travis branch from Appveyor CI Jul 23, 2018
.clang-format Run clang-format on core & test Google-style code Nov 27, 2017
.clang-tidy Add configuration for clang-tidy Jan 12, 2018
.codecov.yml GUI: Include GUI code coverage to lcov reports Dec 19, 2017
.coveragerc Add Python test coverage reporting on Codecov Feb 4, 2016
.cppdep.yml Update configurations for cppdep 0.2.1 Feb 4, 2017
.gitignore Replace Nose w/ Pytest in scripts & docs Jan 10, 2018
.gitmodules Remove GoogleTest git submodule Jan 12, 2018
.landscape.yml Remove Python 2 from Prospector python-target May 29, 2018
.style.yapf Add yapf configuration Nov 28, 2017
.travis.yml Switch to Python 3 on Travis CI May 29, 2018
CMakeLists.txt GUI: Require humanity-icon-theme on GNU/Linux Mar 2, 2018
CODE_OF_CONDUCT.md Update the covenant code of conduct to version 1.4 Feb 1, 2016
CONTRIBUTING.md Update the GUI documentation May 24, 2017
CPPLINT.cfg Add CPPLINT.cfg to deal w/ false-positives Feb 9, 2018
Dockerfile Upgrade Dockerfile w/ Ubuntu 17.10 for C++17 Jan 5, 2018
ICLA.md Update "How to Contribute". May 25, 2015
LICENSE Update the license and references to the project. May 24, 2015
README.rst Replace waffle.io w/ GitHub Projects Jul 25, 2018
crowdin.yml Update Crowdin configuration file Aug 29, 2017
requirements-dev.txt Lint Python code w/ yapf on Travis-CI Nov 28, 2017
requirements-tests.txt Replace Nose w/ Pytest in scripts & docs Jan 10, 2018



https://travis-ci.org/rakhimov/scram.svg?branch=develop 'Build status' https://codecov.io/github/rakhimov/scram/coverage.svg?branch=develop https://api.codacy.com/project/badge/Grade/7067af3e78774325bb33894deac23b9c

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-PSA Model 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 development for 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.

Building and Installing

Git Submodules

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.

git submodule update --init --recursive


Package Minimum Version
CMake 3.8
boost 1.61
libxml2 2.9.1
Python 3.4
Qt 5.9.1

Optional Dependencies

Package Minimum Version
TCMalloc 1.7
JEMalloc 3.6
Humanity Icons 0.6.13


Package Minimum Version
GCC/G++ 7.1
Clang/LLVM 5.0
Intel 18.0.1

Installing Dependencies


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:

sudo apt-get install -y cmake lib{boost-all,xml2,google-perftools,qt5{svg,opengl}5}-dev qt{base,tools}5-dev{,-tools} humanity-icon-theme


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:

brew install cmake boost libxml2 gperftools qt5


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:

pacman --noconfirm -S mingw-w64-x86_64-{gcc,make,cmake,boost,libxml2,qt5}

SCRAM installation and executables must be run inside of the MSYS2 shell.

Installing SCRAM

The project is configured with CMake scripts. CMake generates native "makefiles" or build system configurations to 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).

.../scram/build$ cmake .. -DCMAKE_INSTALL_PREFIX=path/to/installation/directory -DCMAKE_BUILD_TYPE=Release

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:

.../scram/build$ cmake -L

.../scram/build$ ccmake .

.../scram/build$ cmake-gui .

An example build/install instruction with the CMake generated Makefiles:

.../scram/build$ make install

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.

Running SCRAM and Tests

This guide assumes that 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.

To run SCRAM

Example configuration and input files are provided in the input directory.

scram path/to/input/files

On command line, run help to get more detailed information:

scram --help

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

To launch the GUI front-end from the command-line:


The command can also take project configuration and/or input files:

scram-gui path/to/input/files

scram-gui --project path/to/project/file

scram-gui path/to/input/files --project path/to/project/file

To run tests

To run the unit and benchmark tests:


To test the tools in the scripts directory:

.../scram/scripts$ python -m pytest test/

To test the command-line call of SCRAM:

.../scram/tests$ python -m pytest test_scram_call.py

To run performance tests

A set of performance tests is provided to evaluate the running times on the host machine and 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):

scram_tests [.perf]

To run GUI tests

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 directory for the compiled scramgui_test${CASE_NAME} binaries to run.

All Qt Tests are also manually registered with CTest so that it is possible to run all the GUI tests at once:

.../scram/build$ ctest --verbose

To run fuzz testing

The main goal of SCRAM fuzz testing is to discover defects in its analysis code. It is recommended to build SCRAM with assertions preserved and 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:

fuzz_tester.py -n 1000 -j 4

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.

fuzz_tester.py --help

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.

Cross Validation

The Fuzz tester can check the results of qualitative analysis algorithms implemented in SCRAM. If there is any disagreement between various algorithms, the run is reported as failure.

fuzz_tester.py --cross-validate

Documentation Building

Documentation is generated with the configurations on the gh-source branch. The raw documentation files are in the doc directory.

Note to a User

The development may follow the Documentation Driven Development paradigm for some new features. Therefore, some documentation may be ahead of the actual development and 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, scram-users@googlegroups.com).

For latest releases and information about SCRAM, feel free to subscribe to the announcements (https://groups.google.com/forum/#!forum/scram-announce, scram-announce+subscribe@googlegroups.com).

How to Contribute

Please follow the instructions in CONTRIBUTING.md.

CII Best Practices Open HUB Metrics Crowdin Zenodo DOI