Discussions
Categories
Groups
Documentation
Knowledge base
Developer portal
App catalog
The Hub
GitHub
Home
Newly Imported
User Forums
How it Works
Profiling fields and scope
medini_1050701002
Hello everyone, Quick question: are there a fundamental drawback at defining profiling fields at FMEA level? i.e. defining a failure mode related field in "FMEA Worksheet - Failure (derived FMEA only)" instead of in "Design - Failure Mode". Thank you, Adrien
Find more posts tagged with
medini
medini legacy
Accepted answers
All comments
medini_1024169437
I would not say that there is any drawback. Its just a difference, whether you define it a failure mode or FMEA level. In first case for example, the attribute is shared by all FMEA, in the later its individual per FMEA. Another difference: if its at failure mode, its kept if you remove the FMEA, in later case its deleted if you remove the FMEA. So you need to consider which level the information really belongs to I guess. Regards Jan
medini_1050701002
Would Medini ever have the functionality of forwarded fields? Let me explain: our analysts like the view from the FMEA sheets to add/remove failure modes to the model. Some characteristics of the failure modes (e.g. custom fields, kind) are not available directly but we can use custom FMEA profiling to show these fields. A functionality that would be interesting would be to add fields in the FMEA that are direct copies of fields of the model and are modifiable in line. Examples of this already exist but they are restricted to fields that medini implements natively. e.g. the "failure rate distribution (in%)" from the 1629 FMECA template. Here, the % are directly modifiable in the FMEA and these modification will also be made in the model.
medini_1024169437
I think this is a valid topic for the future, so the answer is definitely yes. There are a few things to consider though which I would like to raise. Lets assume *all* attributes of all connected elements in the sheet are there in addition, so component, cause, effect at least. The will blow up the table by a huge set of (maybe optional) columns. Question would be more how to get this under control nicely. Jan
medini_1050701002
If I were to implement that I'd make it entirely optional by introducing a fifth option in the profiling field creation ("String", "Reference", "Derived", "Date", "Forwarded") in order to avoid unecessary cluttering. In that creation wizard you'd have to select a field from a list of the available fields of the contextual element. Have a nice day, Adrien
medini_1024169437
Thanks Gerard, got your idea. I probably was thinking more generic because the wish to edit properties of "referenced" elements is also outside of FMEA/DC sometimes requested, for example Safety Goals referenced in the HARA may show additional columns to edit attributes of the goal. Anyway, FMEA/DC is special with its proxy objects and may need special solutions. Jan
Quick Links
All Categories
Recent Posts
Activity
Unanswered
Groups
Help
Best Of
