search

osate / osate2

Open Source AADL2 Tool Environment
http://osate.org
Eclipse Public License 2.0
36 stars 8 forks source link

Expand displayed probability in FTA table #2359

Closed sprocter closed 3 years ago

sprocter commented 4 years ago

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

sprocter commented 4 years ago

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 commented 4 years ago

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

yoogx commented 4 years ago

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: https://github.com/osate/osate2/issues/1651 that might interfere

oloESK commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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.