Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand displayed probability in FTA table #2359

Closed
sprocter opened this issue Jun 9, 2020 · 7 comments · Fixed by #2452
Closed

Expand displayed probability in FTA table #2359

sprocter opened this issue Jun 9, 2020 · 7 comments · Fixed by #2452
Assignees
Milestone

Comments

@sprocter
Copy link
Contributor

sprocter commented Jun 9, 2020

Summary

Once the model is instantiated and the generation of FTA for given state is completed, the table contains numeric values in the truncated (short) format that rounds up the entries in "Specified probability" column resulting in precision loss or even complete degradation. Here are couple of examples from FaultTreeTable:

  1. original 27.182477e-6 becomes 2,70E-05
  2. original 99.9985e-2 becomes 1,00E+00
  3. original 99.9973625723e-2 becomes 1,00E+00
    etc.

See full discussion on the OSATE mailing list

Expected and Current Behavior

Expected & Current Behavior: Occurrence probabilities are shown in the graphical and table view with a single digit after the decimal point. In the actual fault tree representation the values are stored with greater precision. (see the EMV2 docs)

Desired Behavior: Additional digits of precision are displayed.

Steps to Reproduce

This issue shows up in the tutorial when using the associated aadl model

Environment

  • OSATE Version: 2.7.1
  • Operating System: Mac OS 10.15.5
@sprocter
Copy link
Contributor Author

sprocter commented Jun 9, 2020

This should be (🤞) a straightforward modification to the formats used in FaultTreeUtils

Question for @jjhugues and / or Oleg and / or @lwrage: How many decimal places is appropriate? Is there a non-obvious reason the original implementation rounded to one decimal place?

@stevevestal
Copy link

Scientific notation is useful here, e.g., 2.5E-4, 5.2E-6, might be representative failure probabilities.

@yoogx
Copy link

yoogx commented Jun 9, 2020

The representation should be configurable. I thought someone proposed a patch that was not integrated to control the representation, but could not find it.

Note that we also have this issue pending: #1651 that might interfere

@oloESK
Copy link

oloESK commented Jun 9, 2020

Agree with yoogs, it would be great to have it configurable (up to 10^-9, ASIL D). In projects where system components are described with mixed orders of magnitude, the truncation eliminates entire sense to work with csv-exported data further...it is definitely an issue for the data export.

Moreover, in exact data representation (in properties) the actual assigned value is subject to random fluctuation with an order of around 10^-17. E.g. instead of 0.4, there is a value 0.40000000000000002220446049250313080847263336181640625. What is that?

The representation should be configurable. I thought someone proposed a patch that was not integrated to control the representation, but could not find it.

Note that we also have this issue pending: #1651 that might interfere

@lwrage
Copy link
Contributor

lwrage commented Jun 15, 2020

@yoogx There was a PR. I requested changes but the author didn't respond. The implementation was done in a bad way, i.e., essentially setting a global variable to pass a parameter into the analysis.

@lwrage
Copy link
Contributor

lwrage commented Jun 15, 2020

@oloESK the error regarding 0.4 is a result of conversion between decimal and binary representation. Some numbers with a finite decimal representation have no finite binary representation, e.g, 0.4 in decimal is 0.011001100110... in binary.

@lwrage
Copy link
Contributor

lwrage commented Jun 15, 2020

The number of significant digits could be a preference setting associated with the FTA.

The precision is used only for formatting when the fault tree is displayed. The internal fault tree contains the probability as a double with maximum precision.

@lwrage lwrage added this to the 2.8.1 milestone Jun 15, 2020
@lwrage lwrage assigned asazonova and unassigned sprocter Aug 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants