Error when ingesting EnumerationAlarms from XTCE

[rjler]

Summary

I'm getting the Missing:taxonomy spinner when I try to ingest my XTCE.

I believe I've tracked down to the object-provider.js code:

From object-provider.js

#convertToLimits(defaultAlarm) {
        if (defaultAlarm?.staticAlarmRange) {
            return getLimitFromAlarmRange(defaultAlarm.staticAlarmRange);
        } else {
            throw new Error(`Passed alarm has invalid object syntax for limit conversion`, defaultAlarm);
        }
    }

I did some research and found this issue: Limits should be fetched from the mdb and not the parameter archive #190

In the comments, scottbell implies the only alarm types the plugin will accept are defaultAlarm with staticAlarmRange. (i.e After discussion, we decided to go with the assumption we'll have a defaultAlarm with a staticAlarmRange. )

My XTCE has several parameters with EnumerationAlarms in the format shown below. Using the developer tools, I believe I've track it to these EnumerationAlarms causing the issue.

From my XTCE:

<xtce:EnumeratedParameterType name="MY_EnumParam_Type">
                <xtce:UnitSet/>
                <xtce:IntegerDataEncoding sizeInBits="8" encoding="unsigned"/>
                <xtce:EnumerationList>
                    <xtce:Enumeration value="0" label="INVALID"/>
                    <xtce:Enumeration value="1" label="VALID"/>
                    <xtce:Enumeration value="2" label="UNKNOWN"/>
                </xtce:EnumerationList>
                <xtce:DefaultAlarm>
                    <xtce:EnumerationAlarmList>
                        <xtce:EnumerationAlarm alarmLevel="warning" enumerationLabel="INVALID"/>
                    </xtce:EnumerationAlarmList>
                </xtce:DefaultAlarm>
            </xtce:EnumeratedParameterType>

Expected vs Current Behavior

1) Can you verify this is the expected behavior ? 2) If so, any plans to incorporate other alarm types ?

[ozyx]

Hi @rjler ! Thanks for raising this issue. I believe your assumption is correct, but I'll deflect confirmation to folks who are more knowledgeable in this area-- @shefalijoshi @akhenry @scottbell , is it true we only support static alarm ranges at the moment?

[akhenry]

The dictionary should still load if non-supported alarm types are present in the XTCE, so this is a bug at the very least.

Static alarm definitions are used for for drawing limit lines in plots, and in that case only static alarms are support.

Real-time evaluation of alarms such as that which is used for LAD Tables, alphanumeric elements, telemetry tables, plot legends, and our Fault Management screen may work with other alarm types because we're not explicitly retrieving static alarm definitions in those cases, we're parsing the alarm monitoring results provided by Yamcs. It's untested though, because we don't have a requirement for supporting other alarm types right now.

So, to answer some specific points:

I'm getting the Missing:taxonomy spinner when I try to ingest my XTCE

This is a bug, we will fix it. Sorry about that.

Can you verify this is the expected behavior

Yes and no 😄 Yes in that we don't explicitly support this alarm type. No in that the application should at least load correctly, that is unexpected.

Any plans to incorporate other alarm types ?

Not right now, no. This may change over the next year or so though, as one of our larger missions is about to start working with alarms and fault management in earnest, and new requirements may emerge there.

[akhenry]

Marking this as a critical bug. Open MCT should not choke on unsupported XTCE, it should log a warning to the JavaScript console and the application should load as usual.

[shefalijoshi]

Testing instructions: For an enumerated parameter, configure the viper XTCE (or quickstart using xtce.xml.zip) that includes a default alarm of EnumationAlarm type for the CCSDS_Group_Flags_Type parameter. For example:

<DefaultAlarm>
    <EnumerationAlarmList>
        <EnumerationAlarm alarmLevel="warning" enumerationLabel="Continuation"/>
    </EnumerationAlarmList>
</DefaultAlarm>

Load Open MCT. The dictionary and rest of the app should load successfully.

Note: If you're using quickstart to test this, make sure you run ./mvnw compile before you run ./mvnw yamcs:run

[davetsay]

@shefalijoshi , @unlikelyzero , im not sure how to test this from the instructions. Is modifying viper XTCE done before or after deployment? Feel free to assign back to me to test after adding instructions.

[davetsay]

verified (using quickstart)

I get the warning an not a breaking console error with alarm set (with a negative test in master).