nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Trigger "Evaluate Fault Tree" from inside a script

medini_1052680584

Dear ANSYS Team,

Is it possible to start an "Evaluate Fault Tree" from inside a script?

(For example, within a Script I search for a certain Event and, if found, the Evaluate Fault Tree is started on that Event?)

In one of our analyses we need to start such an Evaluation for dozens of smaller trees. The cutset-Analysis resulting of each Evaluation is then assessed with another script.

Thanks!

Best regards, Andre Taurines

Find more posts tagged with

medini

medini legacy

Accepted answers

All comments

medini_1023641097

Hello Andre,

sorry, but calling "Evaluate Fault Tree" from a batch script is currently not possible in medini.

Best regards

Nino

medini_1036016653

Dear ANSYS medini team,

I would like to propose this as a feature request. Ideally we can trigger an "evaluate fault tree" and pass the options which are otherwise set by the user on the GUI (like Cut Set Order (CSO)). The resulting CutSet Analysis Model (CSAM) shall be returned as an object. Using another function call it shall be possible to store that object as a CutSet Analysis Model.

Currently, medini v2020R2 takes a very long time in preparing the graphical representation of the table. This process needs to be awaited twice: Once for the inital display and a second time, once the CSAM is saved with a name.

As an example, in our project such a CSAM for a single safety goal consists of about 300.000 CutSets for CSO=4. Calculation is rather fast, but the interaction with the user interface is inconvenient as it takes several minutes each. As described in https://medini.freshdesk.com/support/discussions/topics/1000101952 we are currently considering to prune CSAMs to speed up (especially preliminary) analysis.

Best regards

Peter

medini_1036016653

May I kindly request for an updated response from ANSYS? This limitation of the API is proving more and more difficult for us. It consumes a few hours to regenerate CutSet Analysis Models for our safety goals of interest.

Thank you,

Peter

medini_1024169437

Hi Peter, very strange, I was more then sure that I have answered this question, sorry about that.

So while I fully understand the pain here, I am not sure about the proposed solution, as the user would have to run scripts instead of an integrated feature, right? Wouldn't it be better to have the feature described in the other article (the one, that a user can reduce the cut set based on thresholds) in the normal cut set analysis?

Besides, I already tried to reveal that API at scripting level and failed for several reasons. So if you see this idea as a short term solution, I'm afraid, it wont work.

Happy Scripting

Jan

medini_1036016653

Hi Jan,

in principle, I'm all in favor of needing no scripts and having a one-click integrated solution. Today's situation is very much different though. In our projects we execute roughly 10-15 scripts to fully couple FMEDA to FTA, propagate some properties, *manually* create CutSet Analysis models (CSAMs), *manually* save them, *manually* set an profile property on each of them, then finally run another 5-10 scripts to bring the classification information back to FMEDA (and do some other calculations along).

The first two *manual* steps are the ones that are extremely tedious, especially when conducted more than once a week.

If there were an API available to say "Evaluate Fault Tree..." (passing the settings) and to say "save with name", then we could create a "one script" solution, that simply executes all of the subsequent scripts.

"Simply" is of course how it shall in the end look like to the end user.

Today we are in a situation where the user must have a significant skill level to understand what steps to execute in what sequence, in which conditions (sometimes time-consuming steps/scripts can be saved). I'd like this very much to be resolved, possibly with a later release. Even an experimental API (that may break) would be fine for me.

Thank you for your efforts!

Best regards

Peter

medini_1024169437

Ok, got it. Unfortunately I already tried to expose that part of the tool and ... failed. The feature is not prepared to be used from a script so the tool runs into a deadlock.

So in any case, we would have to change a few things in the base implementation.

I will think of some intermediate steps and how to offer that.

Jan

medini_1036016653

Hi Jan, that is highly appreciated. Thank you and best regards, Peter

medini_1036016653

Hi Jan,

sorry for pestering. This aspect proves to be very inconveniet for us, as we have to repeatedly evaluate more than a dozen top level events.

Initiating evaluate fault tree and saving the resulting analysis model would be a big time saver.

Thank you for reconsidering again. Please mark this a feature request for an upcoming release.

Best regards

Peter

medini_1024169437

Hi Peter,

sorry for the long silence. This request is a bit tricky, as you know we usually expose dedicated internal features via separate script libraries if possible. However, this area was never really mean to to be scripted, so we have 2 problems, there is lots of user interaction (difficult to handle) and secondly we need some adjustments to at least expose it in a library.

This cannot be done for general purpose scripting, all I can think of is that some scripting experts do individual testing whether its possible to automate these parts on a nightly build until its stable. What do you think?

Note that "evaluation of fault tree" and "saving of cut sets" are two individual construction areas

Happy Scripting

Jan

medini_1036016653

Hi Jan,

I fully understand that it is tricky and involves two separate steps ("doing the analysis" and "saving the result").

For now I ask for this to be considered at all to be improved from API point of view.

I'm happy to support testing of nightlies. We could employ a beta for intermediate analysis and do the final analysis of a project with a regular release. I see no harm in doing that. It would still reduce the time burden on our side significantly.

Best regards

Peter

medini_1036016653

I'd like to add:
* We need to do this let's say for 20 Safety Goals, which is already troublesome.

* We intend to do this for proving the system safety architecture by doing a HW-FTA DFA that starts by analyzing each CutSet of the System FTA. This means about one hundred of small trees need to be analyzed. (Idea is to check if a dual pont failure from System FTA still is a dual point failure from HW perspective. Prove there are nodependent failures / common cause failures)

medini_1024169437

Ok, got it. Peter, lets use the branched version (from 20.2) where we have already tested some other features if you agree.

We can use that one and drive things further.

Ultimately I see that having that scriptable is only one solution, it might be also a valid (even better solution) to compute all

FTA in a certain package with option "Auto Save", wouldn't it? Is that a feasible approach or have you individual options per FTA?

Regards

Jan

medini_1036016653

Dear Jan,

branching of from 20.2 is a good proposal, I happily agree on.

While "all in one" sounds nice on first sight, I fear it might not be "the right thing" due to:

- performance issues (waiting for several hours, even only one fault tree got adapted)

- how to indicate a fault tree that shall be analyzed? (top leven event is not precise enough for our modeling, due to extensive use of transfer gates so dinstinguish different (system) levels)

At least right now we have the same settings for all safety goals, but I can't guarantee this holding true in general.

In my imagincation I would only have to define a structure with the settings that I would typically manually set in the GUI. That is passed to FTA_evaluateFaultTree(listOfTopLevelEvents, settinsg_eFT, bSave), which then returns a list/array of CutSet Analysis Models, which are already saved, if bSave = true.

Doesn't that sound super easy? :-)

Best regards

Peter

medini_1024169437

Hi Peter,

valid points, I see. Your API proposal matches my vision so we are good here either.

Maybe one alternative would be that the script gets the result and has to decide whether to save it and trigger another "saveCutSetsModel"

function. That could be then wrapped by a utility script.

I made some progress and made the probability calculation scriptable, for cut set calculation

I at least managed to pass the options via script and to trigger it, though I face difficulties with the

operations, saving is open too, just to inform you on the progress.

Happy Scripting

Jan

medini_1036016653

Hi Jan,

indeed, separating "saveCutSetsModel" matches my initial proposal, as the manual workflow is also two steps. Wrapping it in a utility script that allows to conduct both actions is fine to me.

Anyhow, thank you for the update.

Best regards

Peter

medini_1024169437

Hi Peter,

yet another short update. I bypassed (well, solved) all problems and I am confident to have an initial version ready soon, maybe tomorrow.

Currently the "options" are hardcoded in the script, should be no problem for you to take it from there and write some wrapper around it that allows you to pass the options individually.

I'll keep you posted.

Happy Scripting

Jan

medini_1036016653

Hi Jan,

great news! Sure, hardcoded settings are no obstacle. Thank you for fighting your way through the difficulties!

Best regards

Peter

medini_1024169437

Hi Peter,

find attached the latest version of the fta.js library and some sample code, you should be able to quickly see how it works. If you want to change the options, you have to edit fta.js - or maybe implement some parameter to the API. My idea was to pass an anonymous object but did not manage to finish it.

Happy Scripting

Jan

medini_1036016653

Hi Jan,

thank you, quick questions/comments for confirmation (that might help others):
* saveAnalysisModel(): scope is the target FTA model, where the CutSet Analysis Model "model" shall be stored. I'll have to see how to handle this, as looking for "Metamodel.projectmodel.PJPackage" and a name is fragile for my use case. Possibly using mediniGetContainer() iteratively, starting from "node" until the first "PJPackage" is identified is one way. Checking now in "Diagnose -> what is this?" suggets that "node.model" is more direct.
* calculateCutSts(): I see the options being hardcoded. I'll let you know, if I implement an extension to the API.

In any case: Thank you very much Jan!! This API looks exactly like what I had in mind and even goes one (sensible) step further by introducing "calculateEventProbability()".

I'll report back.

Best regards

Peter

medini_1024169437

Hi Peter,

thanks for the feedback, I see that I made a mistake. Scope is misleading and in my tests I indeed used a package

but saved cut-set analyses typically appear "under" their FTA models which is a technical trick we use that is not easy to

script.

I did not see that and have to fix it. So please, for initial testing use any named package,

once I have a solution the target will be automatically selected by passing in the FTA model.

Hope that's okay

Jan

medini_1036016653

Hi Jan,

certainly. I wanted to give quick initial feedback, based on screening the supplied code. Actual implementation has to wait a little bit.

Happy scripting

Peter

medini_1024169437

OK, then please wait a bit further with texting until I fixed this.

Jan

medini_1024169437

Hi Peter,

a corrected version attached. There is no scope parameter anymore, the scope is of course extracted from the cut-set model itself. I also managed to expose the options, see the sample code.

Happy Scripting

Jan

medini_1036016653

Hi Jan,

this looks neet! I'll give it a try.

bye, Peter

medini_1059007410

Hi,

as there were quite some changes in the Calculate Probability features with 2022R1, we've updated the library and example file for script-based FTA calculations. Tested with 2022R1 and 2021R2.2. Enjoy!

Happy Scripting,

Nils

medini_1036016653

Thank you Nils for the update. We shall consider this on migration to the latest release.

medini_1061008150

Hi
Jan, hi Nils,

thank you very much for providing this
script. It worked well in 2022R1.

We recently upgraded to 2023R2. Unfortunately, the script now throws the following
error:

"Failed to execute Java Script: This
script requires a special hook in medini to operate - but the hook is missing
(***\..\.lib\fta.js#130)".

Would you be so kind and upgrade it to include
the new calculation features of 2023R2?

Thank you very much in advance.

Best regards,

David

medini_1024169437

Hi David, sorry for the delay, yes, we actually already did that upgrade, the interface has slightly changed. I will try to upload a newer version asap.

Happy Scripting

Jan

medini_1024169437

Here we go...

medini_1061008150

Hi Jan,

no worries at all. Thank you very much for your quick reply and the update of the file!

Best regards,
David