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; } } }

Moving of Failure Modes

medini_1036016653

Dear all,

I implemented a script that is applied to a system model, consisting of elements that contain failure modes.

Failure modes are automatically grouped by some naming convention. "ports" are created and failure modes are moved into that port. This operation is realized by

// move to port
theTarget.failures.add(fm);
theTarget.name = signal;
c.failures.remove(fm);

whereas "theTarget" is the port the failure mode "fm" is moved to. The moving operation is realized by "add"ing the failure mode to the array and "remove"ing it from the element's "c" array of "failures".

The result looks fine and as expected in the model browser.

Unfortunately the moved failure modes disappear from a DC worksheet (FMEDA) that is linked with the system model.

Any ideas what I made wrong/what steps are missing?

It seems to me that the DC worksheet looses "the connection" to the programatically created failure mode

I hope my description is clear enough. If necessary, I can provide an example project.

Kind regards

Peter

Find more posts tagged with

medini

medini legacy

Accepted answers

All comments

medini_1036016653

Could the synchronization of the DC worksheet, as described here, be of help?

medini_1036016653

... does not seem to help :-/

medini_1036016653

ah, I'm on to something...

so I created a new DC worksheet and it also does not show the failure modes, so I started looking at the ports -- it seems there is a subtle difference in the metamodel wherease some ports show the "safety" tab in properties and others don't:

theTarget = Factory.createElement(c, Metamodel.sysml.SysMLPort);

This is the port created by the script. I now noticed from the diagnosis "what is this?" window that this results in an element of type "SysMLFlowPortUsage", whereas the script currenlty creates "SysMLFlowPort".

Let me check, if I can "bend" the factory, so it creates the other type....

medini_1036016653

theTarget = Factory.createElement(c, Metamodel.sysml.SysMLPortUsage);

... is the solution to my problem. Although now another kink showed up. No further assistance is needed for now. Thank you.

medini_1036016653

Jan,

hopefully you are still reading this. The is an inconsistency in the factory for creating ports "SysMLPortUsage".

It has to be requested to the factory with

Factory.createElement(c, Metamodel.sysml.SysMLPortUsage);

although the factory then creates a type "SysMLFlowPortUsage" of the meta model via

var port = SysmlFactory.eINSTANCE.create(Metamodel.sysml.SysMLFlowPortUsage);

This itself is fine but lead my script to fail, because it searched for existing ports via the requested type "SysMLPortUsage" (lacking "Flow"). I hope you see the issue.

As a solution you might want to add another entry point to the factory

if (type == Metamodel.sysml.SysMLFlowPortUsage) {
 return __createPortUsage(scope);
}

Hope that helps.

Kind regards

Peter

medini_1024169437

Hi Peter,

just reading the complete thread just now, did not see it before.

Will come up with an answer 7 comment later the day or tomorrow.

Regards

Jan

medini_1024169437

Hi Peter,

you are right, the factory is not fully consistent. Back in the first release there was a decision to offer creation for SysMLPort and SysMLPortUsage hiding the fact that we "only" support Flow Ports. So you basically could work with Metamodel.sysml.SysMLPort and Metamodel.sysml.SysMLPortUsage because they are the base classes for the FlowPorts but I will add the proposed missing stuff.

Thanks Jan

medini_1024169437

Peter,

please find attached an update. I have not yet updated the script overview table but will do that after we have settled that. Second reason is that we were working on 2020 R1 extensions already but kept backward compatibility, so should work with 2019 RX as well.

Regards Jan

medini_1036016653

Dear Jan,

thank you for the update. I'll stick to my workaround until I find further need of adapation, although this should ease usage for new scripters.

The important aspect for me is that I have the "prediction" attributes (e.g., failure rate, mode (sum of failure modes!)) available in the created ports and thus need to use "SysMLFlowPortUsage".

Kind regards

Peter

medini_1024169437

Ok, perfect. You will see an update in the library table, once this has stabilized.

Jan