Newcomer understanding the context of different models

[D L]

While starting to learn about SCRAM by trial and error I have tried running CEA9601 model (see recent threads). 

I managed to complete test by setting --limit-order 3 as advised.

But it would help my understanding if there were accompanying notes in each model explaining to newcomers the usage of various input models found in SCRAM repo.

Autogenerated
Baobab
BSCU
CEA9601
Chinese
core
EventTrees
HIPPS
Lift
ne574
SmallTree
Theatre
ThreeLevels
ThreeMotor
TransTest
TwoTrain


I should explain the context of my research.

I am exploring building failure trees where the estimates of probabilities for each failure tree node in the failure tree are derived from inputs from a collaborating group of users - not from a sole source. Such estimates from domain experts might be conflicting and so a distribution of opinion needs to be captured. 

How can such multiple estimates be entered into SCRAM? 

Which of the above models most closely matches this scenario of multi user estimates?

[Olzhas Rakhimov]

Hello,

On Sat, Jul 8, 2017 at 6:12 AM, D L <dl6...@gmail.com> wrote:

While starting to learn about SCRAM by trial and error I have tried running CEA9601 model (see recent threads). 

I managed to complete test by setting --limit-order 3 as advised.

But it would help my understanding if there were accompanying notes in each model explaining to newcomers the usage of various input models found in SCRAM repo.

Autogenerated
Baobab
BSCU
CEA9601
Chinese
core
EventTrees
HIPPS
Lift
ne574
SmallTree
Theatre
ThreeLevels
ThreeMotor
TransTest
TwoTrain

​Yes, the tutorial like examples would be helpful for newcomers,

but SCRAM project expects users to be already familiar with the analysis practice.

It doesn't intend to educate.

http://www.openreliability.org project does have tutorials that new users can find helpful.

I believe it is better to keep these concerns separate.

SCRAM is about implementing algorithms, analysis techniques, and heuristics.

​

​These inputs are primarily to test/validate the ​implementation.

They are not even required to make sense for practitioners or be realistic (some input is autogenerated/random).

I should explain the context of my research.

I am exploring building failure trees where the estimates of probabilities for each failure tree node in the failure tree are derived from inputs from a collaborating group of users - not from a sole source. Such estimates from domain experts might be conflicting and so a distribution of opinion needs to be captured. 

How can such multiple estimates be entered into SCRAM? 

Which of the above models most closely matches this scenario of multi user estimates?

​Take a look at fuzzy logic (Fuzzed). SCRAM currently doesn't support it.

​Regards,

Olzhas Rakhimov​

[D L]

Advancing my understanding a bit further  ...

Is there a list of "pre SCRAM" tools which export opsa-mef files?

That is to create the input files presented to SCRAM engine?

I have researched a number of proprietary front end tools which use opsa-mef format.

I know that XML editors can output the required format but I'm referring to the design of tree at the beginning of this analytical process. 

[Jacob Ormerod]

I have written a tutorial and packages in R that could help you if you like, please check out www.openreliability.org

The FaultTree package provides a method for preparing fault trees by a scripting method and displaying them as SVG graphics. An add-on package FaultTree.SCRAM permits writing out a developed tree using a function ftree2mef(). I took the process a little further and have functions that call for cutsets, probability, importance and uncertainty directly from the R environment. But if you don't care to use those, you are free to just get the opsa-mef format file and call SCRAM yourself.

--
You received this message because you are subscribed to the Google Groups "SCRAM Support and User Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scram-users...@googlegroups.com.
To post to this group, send email to scram...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scram-users/4eb4d4b2-2b98-4327-b018-cf86d0197f12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Olzhas Rakhimov]

Hello D,

On Tue, Jul 18, 2017 at 2:15 AM, D L <dl6...@gmail.com> wrote:

Advancing my understanding a bit further  ...

 

Is there a list of "pre SCRAM" tools which export opsa-mef files?

That is to create the input files presented to SCRAM engine?

​​​I would not like to promote proprietary/closed-source software here,

so no, there's not going to be such a list coming from SCRAM.

In fact, it doesn't even matter. There's no such thing as 'pre-SCRAM'.

The Model Exchange format is a declarative-modeling language on its own

that doesn't care how, where, for what tool it is being generated.

SCRAM and other tools support it.

Anything that talks the MEF understands SCRAM, and vice-versa.

​That is the essential feature/promise of the MEF.

It is amazing and incredibly fortunate that we have this standard.

I have researched a number of proprietary front end tools which use opsa-mef format.

I know that XML editors can output the required format but I'm referring to the design of tree at the beginning of this analytical process. 

​Even though I understand the need for such 'design of tree' tools,

I find these tools/approaches outdated and ridiculous (SCRAM GUI, included).​

The fault-tree/event-tree are very low-level, unmaintainable, rigid, error-prone, hard-to-verify,
'archaic', and sometimes limited, not-expressive-enough, formalisms to describe models.

As a programmer, I consider these languages as assembly languages (great to speak for engines but not humans).

Thanks to advances in computational power,

it makes much more sense now to move on to higher level modeling languages and formalisms.

These languages (e.g., OpenModelica, AADL, Altarica) can generate the lower level descriptions
(Boolean formulas, Markov-chains, State-transition-diagram, Bayes-networks, what-not).

Moreover, you can design a domain-specific-language
that is more descriptive and convenient for your particular application and users in your domain.

These domain-specific-languages can be as simple as R or Python modules.

I believe the fault-tree or event-tree analysis is not enough and not the end in itself,

but more power comes from combination/composition with variety of data-analysis tools and techniques

that, for example, Python or R packages already provide.

I doubt any gui-based (rigid) application can match the visualization and analysis freedom provided by R or Python.

In a sense, developing a GUI-application for fault-tree or event-tree is futile right from the beginning.

Sadly, that's where SCRAM GUI is headed as many users seem to be stuck in it.

Regards,

Olzhas Rakhimov

[D L]

Thank you for your helpful replies which did advance my understanding. 

 I respond in sequence of posts received.

Jacob.

When I first visited openreliability.org it seemed to be biased towards Windows users (I am on Ubuntu 16.04).

http://www.openreliability.org/faulttree-users-tutorial/start-faulttree-on-r/

“this introduction will be made from a Windows user perspective.”

However I updated RStudio to 1.0.143 in Ubuntu 16.04 and succeeded in running the test FaultTree scripts. The output html renders interactive SVG. I see that you use D3.js which is compatible with my plans.

I then went on to test EventTree package (which seems to be more relevant to my development) and hit a problem while following this tutorial:

https://github.com/jto888/EventTree/

I get as far as ...

generate the html to the default drive

etree2html(etree1)

but when I try the final command ...

view in browser from default drive

browseURL(etree1)

I see this error in RStudio console ...

Error in browseURL(etree1) : 'url' must be a non-empty character string

I am trying to troubleshoot this script but I am starting as a newcomer to RStudio.

I am following tutorials such as this ..

http://web.cs.ucla.edu/~gulzar/rstudio/basic-tutorial.html

I would welcome advice on how to troubleshoot the above error which is a roadblock.

[D L]

Olzhas.

I do agree with your observations.

“it makes much more sense now to move on to higher level modeling languages and formalisms.”

"Moreover, you can design a domain-specific-language
that is more descriptive and convenient for your particular application and users in your domain."

And ..

"In a sense, developing a GUI-application for fault-tree or event-tree is futile right from the beginning.
Sadly, that's where SCRAM GUI is headed as many users seem to be stuck in it."

I have to agree that that scram-gui does not fit into my application development plan.

...

In my case I am researching the application of fault tree analytical methods to business enterprise processes rather than analysing reliability of engineering plants.
So lower level analytical processes will be incomprehensible to users. A more domain specific language is needed.

In past years in business and  industry I have seen fault tree analytics applied to business sectors. The challenge is to define (as you write) a “domain specific language” so that data captured from business users rather than reliability engineers can be converted into lower level scripts for analysis and feedback.

That is why I considered using xforms in an earlier thread as the user front end data capture.

I have briefly looked at the modelling languages you listed in your post but I am rather put off by the use of desktop tools with Eclipse. In my case I need to elicit opinions from a a network of users.

My line of thought is to create a web based front end (you have written that you prefer a desktop approach) which hides from business users the “hieroglyphics” of FTA and ETA calculations leaving the lower level engine(s) to conduct the calculations of critical paths.

I hope that I have gained enough insights to proceed to design/build a prototype which I will refer to when proven.

[Jacob Ormerod]

DL,

Believe it or not you are the first to note the problems with the EventTree demonstration script. I have fixed them now on github.

Yes, many reliability/safety engineers will generally come from a Windows background. These are not software developers, rather folks that are finally bold enough to explore beyond the shrink-wrap world of commercial software.

I run an Ubuntu 16.04 virtual machine on Windows and have used this particularly in association with learning, understanding, and now building SCRAM core sources. I have stored my notes on this and had planned on posting some HowTo's related.

The EventTree package for R is quite rudimentary. I wrote the basic scripting to R dataframe object quickly almost 2 years ago now. The graphics was my first exploration into D3.js last year then work on the EventTree was suspended as I developed FaultTree.

Olahas and I began collaboration of sorts in December 2016. And I generated the FaultTree.SCRAM package with a concerted effort over a few months ensuing, motivated because we had a user preparing a significant academic proposal  for the Resilience Center at Colorado State University using FaultTree.

I find R to be an excellent environment for prototyping applications. The EventTree package is an example of something very simple that could be implemented in other languages quite easily.  About a year ago I did spend some time initiating a port of the concept to PHP using MySQL as a web server-side application. I didn't pursue it longer than a week or two however.

--
You received this message because you are subscribed to the Google Groups "SCRAM Support and User Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scram-users...@googlegroups.com.
To post to this group, send email to scram...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scram-users/d2c55dbc-1bc0-4d28-850a-74784edb826d%40googlegroups.com.