Discussions
Categories
Groups
Documentation
Knowledge base
Developer portal
App catalog
The Hub
GitHub
Home
Newly Imported
Restricted
ZF
Keep recent Failure Model of FTA Event
medini_1024120963
Status : open Priority : Trivial, #43 Schedule : (according to Project Owner) Current state :not working Critisism on current state : If you use a different failure model than exponential you have to change this for every new event that you create manually. This can cause huge effort, if you have to change this manually. Objective of the change : efficient workflow Proposed change : There shall be a way of creating new events with the last failure model used, if user requires to keep the failure model of the recent failure model also for the next created event. May it be a key binding or checkbox .... Original Author : Peter Ploß a parent node: FTA no93
Find more posts tagged with
medini
medini legacy
Accepted answers
All comments
medini_1036016653
low priority from my point of view
medini_1024120963
Hi Peter, from our point of view the initial settings for the kind of failure model based on the SysML Element make sense. e.G. 1. If events are derived from SysML elements/failure modes really only the exponential model makes sense (as long as they have a failure rate) 2. For SM only the time independent makes sense 3. For new events from the palette, we cannot create create something useful, because all probability models need to get some parameters. Can you please explain the details of your use case?
medini_1036016653
Hi Joel, sometimes we are in a discussion and quickly draft our idea in a temporary diagram. Then, it might be the case that we want to assign failure rates to all of the base events. This is currently click-intensive (as described above). bye Peter
medini_1024120963
Hi Peter, I understand your point that this is clicking intensive. The topic I need evidence about is why are different failure models required and how often is this the case. Our Dev Team wants to understand this use case so they may come up with sth. better to use. BR Joël
medini_1036016653
Hi Joël, it really depends on what is to be modelled. In my experience, most of the time we are in a discussion we want to assign some failure rate (like 10 FIT). At earlier stages of our analysis we were sometimes drafting ideas with safety mechanisms and wanted to model a factor like "* (1-DC)" by by an AND-gate followed by an event with "fixed" probability (like 0.1 to represent SM with DC=90%). Anyhow, the most flexible and still robust approach would be that the GUI remembers the failure rate type of the last manually created event and takes this as a template for the next to be craeted element: - if I had last created event "A" and set it its probability to "fixed" and would now create some other event "B", then it would default to type "fixed". - if I had last created event "C" and set it its probability to "rated" and would now create some other event "D", then it would default to type "rated". I hope my suggestion can be understood well and does not impose restrictions. Best regards Peter
Quick Links
All Categories
Recent Posts
Activity
Unanswered
Groups
Help
Best Of