sdarg/jreliability

Java-based System Reliability Evaluation Library

JReliability - The Java-based Reliability Library

JReliability allows to derive several reliability-related measures like Mean-Time-To-Failure (MTTF) or Mission-Time (MT) of complex systems that are modeled using Boolean functions, efficiently encoded in Binary Decision Diagrams (BDDs).

Usage

JReliability is meant to be used as library. Nonetheless, there is a small demo application you can use to get an initial idea and to demonstrate the included viewers.

Linux/Unix

Run:

./start.sh

Windows

Run:

./start.bat

Developer

JReliability uses Gradle. Run

./gradlew tasks

to show all available tasks.

Use

./gradlew eclipse

to create the required .project and .classpath files to import the project in Eclipse.

Use

./gradlew run

to execute the demo application.

Contributing

1. Fork it!
2. Create your feature branch: git checkout -b my-new-feature
3. Commit your changes: git commit -am 'Add some feature'
4. Push to the branch: git push origin my-new-feature
5. Submit a pull request :D

History

JReliability was formerly hosted at https://sourceforge.net/projects/jreliability/

Credits

Brought to you by

• Michael Glaß
• Felix Reimann
• Martin Lukasiewycz
• Faramarz Khosravi
• Henning Oehmen

License

JReliability uses LGPLv3.

jreliability's Issues

GitHub Actions

Switch from Travis CI to GitHub Actions.

Rounding in approximations

Consider the calculation of getY() in FailureRate. Due to the approximative way we calculate the density, small values in the density function (derived from the reliability function) are not >0 but approximated to 0.0. FailureRate handles this scenario by knowing that as long as reliability != 1, the density cannot be 0.0 for our assumptions and, thus, returns Double.NaN.
I fear this might not be consistently integrated in all classes where this error might occur and the question is where to resolve this issue. I think the better place to resolve this would be the functions that do the approximation, i.e., DensityFunction in this case.
Question to discuss: Do we want to rely on propagating Double.NaN values or should we throw exceptions?

Adress codacy (PMD) issues

Check JReliability wrt. codacy issues and resolve them.

org.jreliability.function.common.ReliabilityFunctionType never used

Is it still used? Someone thinks we need this?
@michaelhglass could you check this please?

How to deal with empty Terms and/or Zero/One BDDs

We have a rich processing chain that directly derives reliability functions from terms and/or BDDs. However, if we pass e.g. a zero or a one BDD, the functions will typically observe a system that fails at time 0 or will never fail. Both situations are against the assumption of a reliability function to be 1 at time 0 and 0 at infinity. We need to think about a concept to resolve this throughout JReliability.

Code formatter and license

• Application of the Opt4J-style code formatter across the project
• Typo in license (mentions Opt4J instead of JRealibility)

Use travis to deploy releases to Maven

Version bump to Java 21 LTS

We should bump to Java 21 LTS for future stability. Adresses #86.

• Java 21 LTS
• Gradle 8.5
• Mockito 5.10
• Jacoco 0.8.11
• JUnit 5.x (5.10 currently)

Jitpack

Switch from Maven to Jitpack

Website Rework and Deployment

• host website in master branch
• rework website due to new build, JitPack etc.
• include action to deploy homepage to gh-pages for releases

Parallel Reliability Function Evaluation

Certain analysis techniques may be able to tell in advance which y-values they want to derive from a ReliabilityFunction using getY(double x). In these cases, certain analysis techniques can highly benefit from a parallel evaluation/execution of getY(double x) such as the newly implemented stochastic logic.
I suggest to provide an additional interface to ReliabilityFunction as follows:
public List getY(List xs);
and provide an abstract class SequentialFunction that automatically redirects the getY(List xs) to a sequential execution of getY(double x).

Tutorial

The tutorial is from 2008 and in some parts completely outdated. Not sure of the PDF is the best way to provide the tutorial, but this needs rework desperately.

native libs broken with gradle build

The native libs are not correctly packaged yet with gradle and cannot be found by the class loader.
Tests for Buddy, Cudd and other native libs fail.

Enforce camelCase/PascalCase code style

In JReliability, we have several acronyms as part of class and Method names like TMR, but recently we have some more less common acronyms such as BAGT.
Currently:

• BAGTImportanceMeasure
  camel/PascalCase:
• BagtImportanceMeasure
• BorgonovoAlieeGlassTeichImportanceMeasure
  Both rather long variants look quite strange and in theory we could configure checkstyle to allow acronyms of length n.

What's your opinion @SDARG/jreliability? Strict camelCase/PascalCase which makes live easier as a rule or trying to decide on our own which acronym can directly go into a class/method name. I would like to resolve this before the next (urgent) release to avoid further code refactoring once and for all.

I would opt for strict.

Java9 streaming API for functions

We should check at least how to design SequentialFunction and Function with streaming API.

Gradle Update

• Gradle 4.1 seems to create strange situations with the newest Eclipse versions as well as installed JVMs > Java 9
• Suggest to update to Gradle 4.8

Add codacy badge to README.md

Update Java and Gradle

• Update JReliability to Java 11 and Gradle 6.6.1
• Considers switch to Jitpack instead of Maven

Semantic versioning (SemVer 2.0.0)

• Respect semantic versioning in future releases: https://semver.org
• Correct build.gradle to form proper version names
• git tags with semantic versioning and leading "v" e.g. git tag v1.2.3 -m "Release version 1.2.3

Incorrect Weibull reliability function?

Hello. I was just browsing through the source code of WeibullReliabilityFunction and believe it's not implemented correctly. This is completely outside my area of expertise and I have not downloaded or tried using jreliability so I'm likely wrong.

getY is implemented as follows:

Math.exp(-(Math.pow((alpha * x), beta)));

and is documented as:

R(x) = 1 - F(x) = e^-((alpha * x)^beta))

According to: http://reliawiki.org/index.php/The_Weibull_Distribution
...the reliability function should be:

R(x) = 1 - F(x) = e^-((x/alpha)^beta))

Math.exp(-(Math.pow((x/alpha), beta)));