Problem with String compares in M2Doc

Question

Hi all,

I am having a problem with report scripting. I am currently trying to create a table where all components with failure kind "dangerous" and "diagnostic dangerous" are listed. We already have the following working code to create such a table where all components with failure type "dangerous" are listed:

{ m:for cmp | dc::DCComponentEntry.allInstances() }
{ m:if cmp.element.label = FMEDA.oclAsType(dc::DCWorksheet).components.oclAsType(dc::DCComponentEntry)->at(1).element.label }
{ m:if cmp.failureModes.user_failure_kind.toString()->includes('dangerous') }
{ m:for failures | cmp.failureModes}
{ m:if failures.user_failure_kind.toString()=('dangerous') }

[Table with components]

I am now trying to also include "diagnostic dangerous" but I came about a very odd problem. When I change 'dangerous' to 'diagnostic dangerous' it still only lists the components with the failure kind 'dangerous' and not the components with 'diagnostic dangerous'.

{ m:for cmp | dc::DCComponentEntry.allInstances() }
{ m:if cmp.element.label = FMEDA.oclAsType(dc::DCWorksheet).components.oclAsType(dc::DCComponentEntry)->at(1).element.label }
{ m:if cmp.failureModes.user_failure_kind.toString()->includes('diagnostic dangerous') }
{ m:for failures | cmp.failureModes}
{ m:if failures.user_failure_kind.toString()=('diagnostic dangerous') }

[Table with components]

I don't know what the problem could be. I also tested changing "dangerous" to "safe" and "test" and it did not change the output (I am in the right document though, as other changes had an effect). This is also the only code with open if statements at this point in the document, so it can't be interference from previous code. The if statements and for loops are closed after the table. So if the if statements simply evaluated to false, the table shouldn't appear at all.

Has anyone come across this before or any idea what the problem is?

Many thanks and kind regards,

Maria

medini_1059007410 · Answer

Hi Maria,

Your line 3 filters for any components, which have any failure mode with a "diagnostic dangerous" failure kind (amongst others, if more of them are selected).

If you are just interested in the components, for which this is true, you are done and wouldn't need lines 4 and 5. Each table row would then be for a component.

If you want to list failure modes within such a component table row, then you could have sub-tables (table within a cell) surrounded by your line 4&5 statements - that would then go through all failure modes of the component and only list the FMs with "diagnostic dangerous" failure kind selected. The comparison would be the same as in line 3 (just that you start with "failures" instead of "cmp.failureModes", again using ".includes()", as you will get a collection from the multi-selection).

Alternatively to a sub-table, you could insert a comma/newline separated list in one of your cells, e.g. for all failure modes

{m:cmp.failureModes.element.label->sep(',
')}

or only for the failure modes with "diagnostic dangerous" failure kind:

{m:cmp.failureModes->select(fm | fm.user_failure_kind->includes('diagnostic dangerous') ).element.label->sep(',
')}

Regards,

Nils

medini_1071314001 · Answer

Hi Nils,

Thanks for the reply and the tips.

The "user_failure_kind" is indeed a string property with multiple inputs you can choose from in the FMEDA with a drop down menu. Do you know how to compare the chosen option with a string?

About the table with the components, I just wrote this as an abbreviation for a lot of AQL code in a table. Basically the table is supposed to get filled with the componens that are selected with the if statements above it.

Thanks and kind regards,

Maria

medini_1059007410 · Answer

Hi Maria,

That sounds odd. I didn't have a chance to test it on my side yet, but a few comments, which might help:

1) You do not need "oclAsType" in M2Doc, as the language is actually AQL, not OCL. AQL is implicitly aware of the types, different to OCL.

2) Is "user_failure_kind" a string property with multiple predefined inputs? If no, ok, but if yes, then your line 5 comparison will cause issues (direct comparison between string and a list).

3) If "user_failure_kind" is any kind of string property, then I would guess that you do not need "toString()" - but I'm not sure if there are unforeseen issues without, haven't tested.

4) Line 5 comparison is probably more robust via failures.user_failure_kind.equals('diagnostic dangerous')

5) You say you have a table with components, but you already loop over the failure modes of the components. Is that intended?

Regards,

Nils