XTCE 1.3 RTF Avatar
  1. OMG Issue

XTCE13 — Alarm Usability Problem Detected in Final Draft

  • Key: XTCE13-193
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Somewhere in the XTCE 1.3 evolution, we lost the optional flag on the choice for AlarmConditions and CustomAlarm within the AlarmType. Lets restore that because these are fallback possibilities that are used if the user does not leverage the more specific alarm definitions provided in the concrete alarm types.

  • Reported: XTCE 1.2 — Tue, 11 Feb 2025 17:42 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Restore the optional flag inside AlarmType

    We wish to restore this to the XTCE 1.2 optional nature so that backwards compatibility is not broken.

    Current AlarmType Definition Post Ballot 15:

    <complexType name="AlarmType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Defines a base schema type used to build up the other data type specific alarm types. The definition includes a count to go into alarm (minViolations - the counts to go out of alarm is the same), a condition style alarm and a custom alarm. See AlarmConditionType, CustomAlgorithmType, BinaryAlarmConditionType, BooleanAlarmType, BinaryContextAlarmType, EnumerationAlarmType, NumericAlarmType, StringAlarmType, TimeAlarmType, TimeAlarmConditionType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseAlarmType">
    <choice>
    <element name="AlarmConditions" type="xtce:AlarmConditionsType">
    <annotation>
    <documentation xml:lang="en">A MatchCriteria may be specified for each of the 5 alarm levels. Each level is optional and the alarm should be the highest level to test true.</documentation>
    </annotation>
    </element>
    <element name="CustomAlarm" type="xtce:CustomAlarmType">
    <annotation>
    <documentation xml:lang="en">An escape for ridiculously complex alarm conditions. Will trigger on changes to the containing Parameter.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="minViolations" type="xtce:PositiveLongType" default="1">
    <annotation>
    <documentation xml:lang="en">The number of successive instances that meet the alarm conditions for the alarm to trigger. The default is 1.</documentation>
    </annotation>
    </attribute>
    <attribute name="minConformance" type="xtce:PositiveLongType" default="1">
    <annotation>
    <documentation xml:lang="en">Optionally specify the number of successive instances that do not meet the alarm conditions to leave the alarm state. If this attribute is not specified, it is treated as being equal to minViolations (symmetric).</documentation>
    </annotation>
    </attribute>
    <attribute name="disabled" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">The initial state of this alarm definition as delivered. When true, this leaves the alarm definition empty for the parameter and also short circuits the remaining context matches and the default so no alarm is active on the parameter.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Corrected AlarmType (just the choice now has minOccurs="0"):

    <complexType name="AlarmType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Defines a base schema type used to build up the other data type specific alarm types. The definition includes a count to go into alarm (minViolations - the counts to go out of alarm is the same), a condition style alarm and a custom alarm. See AlarmConditionType, CustomAlgorithmType, BinaryAlarmConditionType, BooleanAlarmType, BinaryContextAlarmType, EnumerationAlarmType, NumericAlarmType, StringAlarmType, TimeAlarmType, TimeAlarmConditionType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseAlarmType">
    <choice minOccurs="0">
    <element name="AlarmConditions" type="xtce:AlarmConditionsType">
    <annotation>
    <documentation xml:lang="en">A MatchCriteria may be specified for each of the 5 alarm levels. Each level is optional and the alarm should be the highest level to test true.</documentation>
    </annotation>
    </element>
    <element name="CustomAlarm" type="xtce:CustomAlarmType">
    <annotation>
    <documentation xml:lang="en">An escape for ridiculously complex alarm conditions. Will trigger on changes to the containing Parameter.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="minViolations" type="xtce:PositiveLongType" default="1">
    <annotation>
    <documentation xml:lang="en">The number of successive instances that meet the alarm conditions for the alarm to trigger. The default is 1.</documentation>
    </annotation>
    </attribute>
    <attribute name="minConformance" type="xtce:PositiveLongType" default="1">
    <annotation>
    <documentation xml:lang="en">Optionally specify the number of successive instances that do not meet the alarm conditions to leave the alarm state. If this attribute is not specified, it is treated as being equal to minViolations (symmetric).</documentation>
    </annotation>
    </attribute>
    <attribute name="disabled" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">The initial state of this alarm definition as delivered. When true, this leaves the alarm definition empty for the parameter and also short circuits the remaining context matches and the default so no alarm is active on the parameter.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT