${taskforce.name} Avatar
  1. OMG Task Force

XML Telemetric & Command Exchange Format 1.3 (XTCE) RTF — Open Issues

  • Key: XTCE13
  • Issues Count: 84
Create Issue
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
XTCE13-184 Add ArgumentRef to the Verifier Condition element in MetaCommand XTCE 1.2 open
XTCE13-125 Access to command arguments in transmission constraints and command verifiers XTCE 1.2 open
XTCE13-107 Revert change to CalibratorType base type XTCE 1.2 open
XTCE13-72 CNES CCSDS -- Want ArgumentEntryRef in CommandContainerSet/CommandContainer XTCE 1.2 open
XTCE13-65 lost annotation in 1.2 inputAlgorithmType schema type rework XTCE 1.2 open
XTCE13-30 String Encoding Length descriptions needs further clean up XTCE 1.2 open
XTCE13-24 List and List> clean up needed XTCE 1.1 open
XTCE13-127 Variable string size specification enforces one of DynamicValueType or DiscreteLookupListType XTCE 1.2 open
XTCE13-176 Yamcs supports json syntax for array and aggregate parameter/args initial value XTCE 1.2 open
XTCE13-23 Missing a number of changes and enumerations in ErrorDetectCorrectType children XTCE 1.1 open
XTCE13-177 SpaceSystem can mean multiple things XTCE 1.2 open
XTCE13-162 BinaryEncoding Extension of SequenceContainer Requires SizeInBits Element XTCE 1.2 open
XTCE13-135 ParameterToSet/Derivation is set to abstract and should not be XTCE 1.2 open
XTCE13-128 Data encodings: FromBinaryTransformAlgorithm/ToBinaryTransformAlgorithm SizeInBits should be optional XTCE 1.2 open
XTCE13-114 BaseConditionsType too broad XTCE 1.2 open
XTCE13-109 Dynamic look up should have integer and float forms XTCE 1.2 open
XTCE13-143 Clarify RepeatEntry's values and what they mean XTCE 1.2 open
XTCE13-142 Simplify/align alarm severities across OMG specifications XTCE 1.2 open
XTCE13-141 Add an optional attribute to ComparisonList to make it all ORs XTCE 1.2 open
XTCE13-140 Reconsider if Specific Color Names Should be Referenced XTCE 1.2 open
XTCE13-129 Non-ASCII characters in XSD annotations cause tooling issues XTCE 1.2 open
XTCE13-155 ArgumentType References Mixed with ParameterTypes in Key XTCE 1.2 open
XTCE13-145 clarify semantics of context cals (possibly same as context alarms) XTCE 1.2 open
XTCE13-139 Clarify Behavior of Context Alarms Only Containing a Match XTCE 1.2 open
XTCE13-73 rangeForm annotation needs work XTCE 1.2 open
XTCE13-138 Change Alarm Element Bad Attributes XTCE 1.2 open
XTCE13-137 FixedValueEntry, maybe it's not as good as it could be XTCE 1.2 open
XTCE13-136 RelativeTime's ChangePerSecondRangeAlarm should be a TimeChangesPerSecondAlarmType XTCE 1.2 open
XTCE13-134 Possible typo of word "difference" instead of "different" XTCE 1.2 open
XTCE13-130 Invalid schema exception with xerces parser XTCE 1.2 open
XTCE13-124 FromBinaryTransformAlgorithm/ToBinaryTransformAlgorithm should be allowed for all data encodings XTCE 1.2 open
XTCE13-74 Is rangeForm specialization needed for Change and Multi band alarms? XTCE 1.2 open
XTCE13-126 reference to aggregate members and arrays XTCE 1.2 open
XTCE13-116 Possible typo of word "encoded" as "endcode" XTCE 1.2 open
XTCE13-115 Disallow duplicate labels in the EnumerationList XTCE 1.2 open
XTCE13-113 parametertype and argumenttype type hiearchies still need work XTCE 1.2 open
XTCE13-112 LinearAdjust -- slope should default to 1 XTCE 1.2 open
XTCE13-111 CustomAlgorithm needs a language/implementation field XTCE 1.2 open
XTCE13-110 Discrete lookup list has no default (or i don't get it) XTCE 1.2 open
XTCE13-108 BinaryContextAlarmList should be ContextAlarmList XTCE 1.2 open
XTCE13-34 ArgumentInputSetType is inconsistent with InputSetType XTCE 1.2b1 open
XTCE13-33 Inconsistency in Argument Types with respect to FixedIntegerValueType XTCE 1.2b1 open
XTCE13-32 needs to be updated for items that no longer support hex, octal, binary XTCE 1.2b1 open
XTCE13-39 Inconsistent time unit data types XTCE 1.2 open
XTCE13-37 Incorrect MetaCommandRef element definition XTCE 1.2 open
XTCE13-71 CNES CCSDS -- unit set "form" question XTCE 1.2 open
XTCE13-67 CustomAlarmType has wrong parent XTCE 1.2 open
XTCE13-29 ByteOrderList is invalid for Containers XTCE 1.1 open
XTCE13-25 Add event message support XTCE 1.1 open
XTCE13-17 Checkwindow not tied to context XTCE 1.1 open
XTCE13-28 Clean up semantics of "OO-Include Condition" XTCE 1.1 open
XTCE13-13 CustomAlgorithm should be "typed" reference to AlgorithmSet XTCE 1.1 open
XTCE13-70 CNES CCSDS -- inside/outside range support in ValidRange XTCE 1.2 open
XTCE13-68 CNES CCSDS -- Time ParameterType inheritance may need to be repolled XTCE 1.2 open
XTCE13-91 MemberType and ComparisonType annotation misses fix to value formatting XTCE 1.2 open
XTCE13-31 ServiceRef construction error XTCE 1.2 open
XTCE13-21 inability to describe sets of limits (alarms) and conversions (polynomials) XTCE 1.0b1 open
XTCE13-9 Need support for mask alarm XTCE 1.1 open
XTCE13-36 RelativeTimeAgumentType is misspelled XTCE 1.2b1 open
XTCE13-69 CNES CCSDS -- RelativeTimeAgument typo XTCE 1.2 open
XTCE13-35 ArgumentAssigmentList in the MetaCommandStep is misspelled XTCE 1.2b1 open
XTCE13-66 Unecessary Sequence of choice in AlarmType XTCE 1.2 open
XTCE13-10 Re-architect XTCE alarm model XTCE 1.1 open
XTCE13-19 Move Alarms outside of Type Area XTCE 1.1 open
XTCE13-16 AbsoluteTime should have Alarms XTCE 1.1 open
XTCE13-2 Expand features to include common industry encodings in StreamsSet XTCE 1.1 open
XTCE13-5 Add gap entry to container entry list XTCE 1.1 open
XTCE13-40 Duplicated BaseCalibratorType extension XTCE 1.2 open
XTCE13-27 Cleanup Container EntryList element by deprecating IndirectParameterRefEntry XTCE 1.1 open
XTCE13-18 Message/IncludeCondition/BaseContainer similarity XTCE 1.1 open
XTCE13-15 Add forward/reverse calibrator metadata XTCE 1.1 open
XTCE13-1 Type inheritance missing from Absolute and Relative time data types XTCE 1.1 open
XTCE13-11 Should RestrictionCriteria should be assignment not operators for Commanding? XTCE 1.1 open
XTCE13-8 Add ArgumentTypeSet to MetaCommand XTCE 1.1 open
XTCE13-14 Expand NameReference semantics XTCE 1.1 open
XTCE13-38 Missing default value of dataSource attribute XTCE 1.2 open
XTCE13-26 Re-evaluate the characterWidth attribute in String types XTCE 1.1 open
XTCE13-20 lack of Union construct (MER + ASIST) XTCE 1.0b1 open
XTCE13-22 Spelling error for Arguments in XTCE 1.2 proposed XTCE 1.1 open
XTCE13-4 Provide way to categorize all elements with @name into one or more groups XTCE 1.1 open
XTCE13-3 Add switch entry to container entry list XTCE 1.1 open
XTCE13-12 Add OCL specific Algorithm to XTCE XTCE 1.1 open
XTCE13-7 Elevate annotation specifying time string formats to an attributes XTCE 1.1 open
XTCE13-6 Add variable to containers XTCE 1.1 open

Issues Descriptions

Add ArgumentRef to the Verifier Condition element in MetaCommand

  • Key: XTCE13-184
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Noticed in YAMCS example. YAMCS says XTCE should support ArgumentRefs in MetaCommand/Verifiers. For example from the YAMCS website:

    <xtce:MetaCommand name="cmd_with_verifier4">
    <xtce:ArgumentList>
    <xtce:Argument name="arg1" argumentTypeRef="u32" />
    </xtce:ArgumentList>
    <xtce:CommandContainer name="cmd_with_verifier4">
    <xtce:EntryList>
    <xtce:ArgumentRefEntry argumentRef="arg1" />
    </xtce:EntryList>
    </xtce:CommandContainer>
    <xtce:VerifierSet>
    <xtce:CompleteVerifier>
    <xtce:BooleanExpression>
    <xtce:Condition>
    <!-- This is not valid according to XTCE but we think it should be made part of the standard.
    It achieves the same as the example above without using the false /yamcs/cmd/arg parameter reference. -->
    <xtce:ArgumentInstanceRef argumentRef="arg1" />
    <xtce:ComparisonOperator>==</xtce:ComparisonOperator>
    <xtce:ParameterInstanceRef parameterRef="local_para1" />
    </xtce:Condition>
    </xtce:BooleanExpression>
    <xtce:CheckWindow timeToStartChecking="PT0S" timeToStopChecking="PT1S" />
    </xtce:CompleteVerifier>
    </xtce:VerifierSet>
    </xtce:MetaCommand>
  • Reported: XTCE 1.2 — Thu, 12 Dec 2024 22:19 GMT
  • Updated: Thu, 19 Dec 2024 01:15 GMT

Access to command arguments in transmission constraints and command verifiers

  • Key: XTCE13-125
  • Status: open  
  • Source: Space Applications Services ( Nicolae Mihalache)
  • Summary:

    Sometimes the constraints and/or verifies associated to a command may depend on the value of the arguments of the command sent. For example setting a thermostat to a certain setpoint may have a constraint which will only allow a given setpoint in a specific operational mode.
    A verifier can compare the setpoint sent as command argument with the setpoint known in the spacecraft and received as a TM parameter.

    To achieve this, arguments references should be allowed in the definition of the constraints/verifiers.

    In practice:

    • TransmissionConstraintType should extend the ArgumentMatchCriteriaType (instead of MatchCriteriaType)
    • CommandVerifierType should allow elements of type ArgumentInputAlgorithmType , ArgumentBooleanExpressionType and ArgumentComparisonType (instead of the non argument variety)

    All the Argument* types are superset of the corresponding non-argument types so by doing this change, the schema will be backward compatible.

    Note: a similar request could be argued for ParametrToSetType to allow setting a parameter to a value computed based on the user defined argument of the command. However since there is no ArgumentMathOperationType, no easy solution can be immediately seen without adding extra types.
  • Reported: XTCE 1.2 — Thu, 22 Apr 2021 08:17 GMT
  • Updated: Thu, 19 Dec 2024 01:15 GMT

Revert change to CalibratorType base type

  • Key: XTCE13-107
  • Status: open  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    XUSP 1.2 changed the base type of CalibratorType from OptionalNameDescriptionType to the new BaseCalibratorType. This change eliminated the previous support for <LongDescription> and <AliasSet>. These elements are supported in the XUSP 1.0 profile and are used in existing databases.
  • Reported: XTCE 1.2 — Wed, 25 Mar 2020 20:07 GMT
  • Updated: Thu, 19 Dec 2024 01:15 GMT

CNES CCSDS -- Want ArgumentEntryRef in CommandContainerSet/CommandContainer

  • Key: XTCE13-72
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    "The issue is declared Closed.
    The problem has not been fixed. It is still impossible to reference an argument in a CommandContainerSet/CommandContainer/RefEntry."
  • Reported: XTCE 1.2 — Wed, 2 Oct 2019 14:54 GMT
  • Updated: Thu, 19 Dec 2024 01:15 GMT

lost annotation in 1.2 inputAlgorithmType schema type rework

  • Key: XTCE13-65
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Much of the annotation is gone in InputAlgorithmType in 1.2 in its major elements. These were turned into schema types for 1.2, and somehow the annotation was not copied over from 1.1.
  • Reported: XTCE 1.2 — Fri, 27 Sep 2019 15:07 GMT
  • Updated: Thu, 19 Dec 2024 01:15 GMT

String Encoding Length descriptions needs further clean up

  • Key: XTCE13-30
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The current schema improves upon XTCE 1.1 but still has issues. Firstly it lacks overall clarity and simple syntax. Second it appears to give 2 ways to describe an overall "string box" and dynamic part which may be confusing to some (we should favor one over the other). See for example Fixed plus one of the TerminatingChar or LeadingSize, or Variable/DynamicValue and maxSizeInBits. Also maxSizeInBits is required and this may be a problem in some scenarios. Finally the choice of syntactic element does make it possible to say that variable length has a dynamic look up terminatingChar and LeadingSize.

    The overall use cases of support are:

    • fixed string
    • fixed box, variable string
    • variable string but overall max size (simlar to above)
    • variable string unlimited

    Here's a longer write up:

    1) Fixed string, like as in literally:

    StringDataEncoding/SizeInBits/Fixed/FixedValue

    2) Fixed string BOX but variable inside that...

    StringDataEncoding/SizeInBits/Fixed/FixedValue AND one of Fixed/LeadingSize or Fixed/TerminatingChar

    3) Fixed string BOX but variable inside that... yeah we can say this two ways then:

    StringDataEncoding/Variable/@maxSizeInBits=sizeOf(StringBox) AND one of DynamicValue or DiscreteValue to look up the length from it, and then optionally either LeadingSize or TerminationChar or both even too

    This one is terribly confusing...

    4) Variable and Max size

    StringDataEncoding/Variable/Dynamic|Discrete plus required maxSizeInBits and then optionally either LeadingSize or TerminationChar too

    5) Variable but no max size stated in source material

    StringDataEncoding/Variable/Dynamic|Discrete set maxSizeInBits to ginormous and probably just ignore and then optionally either LeadingSize or TerminationChar too

    So #1 and #2 make sense but are a tad unwieldy syntax wise... well we are probably a little stuck there in regard to "backwards compatibility". This is probably the most used, these two.

    I think #4 makes sense – although mixing in the leading size or termination char seems either just plain confusing or weird...

    #5 is unfortunate but making @maxSizeinBits optional seems quick fix OR the workaround isn't necessarily bad.

    The "let's set everything" #3 isn't great but could be factored away in documentation
  • Reported: XTCE 1.2 — Mon, 14 May 2018 17:31 GMT
  • Updated: Thu, 19 Dec 2024 01:15 GMT

List and List> clean up needed
  • Key: XTCE13-24
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    After jaxb runs on the current XTCE 1.2 (after ballot 28) schema. The following methods show weaknesses in the schema type hierarchy (below). It's been shown they schema types can be meaningfully tweaked and these items will map cleanly. It also suggest but is not clear the order of the items in some the lists may not be enforced. for two of the items below this would be bad. this is conjecture however.

    >> ArgumentInputSetType.java: public List<Object> getInputParameterInstanceRefOrInputArgumentInstanceRef() {
    >> InputSetType.java: public List<Object> getInputParameterInstanceRefOrConstant() {
    >> ParameterSetType.java: public List<Object> getParameterOrParameterRef() {
    >>
    >> ArgumentComparisonCheckType.java: public List<JAXBElement<?>> getRest() {
    >> ComparisonCheckType.java: public List<JAXBElement<?>> getRest() {
    >> MathOperationCalibratorType.java: public List<JAXBElement<?>> getValueOperandOrThisParameterOperandOrOperator() {
    >> MetaCommandSetType.java: public List<JAXBElement<?>> getMetaCommandOrMetaCommandRefOrBlockMetaCommand() {
    >>
  • Reported: XTCE 1.1 — Wed, 14 Feb 2018 17:43 GMT
  • Updated: Thu, 19 Dec 2024 01:15 GMT
  • Attachments:

Variable string size specification enforces one of DynamicValueType or DiscreteLookupListType

  • Key: XTCE13-127
  • Status: open  
  • Source: Space Applications Services ( Nicolae Mihalache)
  • Summary:

    In addition to the clarity issues highlighted by XTCE13-30, the current definition of StringDataEncoding has a major drawback for variable strings: the VariableStringType enforces one of DynamicValueType or DiscreteLookupListType.

    However the size of the string can be very well determined by the other two methods LeadingSize or TerminationChar. Usage of LeadingSize/TerminationChar in combination with the enforced DynamicValueType/DiscreteLookupListType does not make sense when the string fills completely the allocated buffer and so the size of the string determines the size of the buffer.

    In my opinion having a variable size buffer with a variable string inside that buffer is much less common (never heard of it in fact) than having a fixed size buffer with a variable string inside or a variable string with no buffer (the buffer is the string).

    Suggest to make the DynamicValueType/DiscreteLookupListType optional.
  • Reported: XTCE 1.2 — Fri, 30 Apr 2021 07:34 GMT
  • Updated: Fri, 13 Dec 2024 00:40 GMT

Yamcs supports json syntax for array and aggregate parameter/args initial value

  • Key: XTCE13-176
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Maybe we should align with yamcs

    initial value

    Initial (default) value given to a parameter or command argument.

    Note that this value can be overwritten for specific parameters, or command arguments using a column of the same name in the Commands and Parameters sheets.

    The value must be understandable for the used engineering type.

    For binary, use a hexadecimal notation.

    For booleans, use a value of true or false.

    For arrays, specify a value in JSON format: [-3, -2.4, 5].

    For aggregates, specify a value in JSON format:

    {member1: 1, member2: 2}

    .
  • Reported: XTCE 1.2 — Thu, 7 Nov 2024 16:04 GMT
  • Updated: Fri, 13 Dec 2024 00:35 GMT

Missing a number of changes and enumerations in ErrorDetectCorrectType children

  • Key: XTCE13-23
  • Status: open  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The reworked XTCE 1.2 from the proposed BitBucket schema has additional checksums (also hashes) and a new XOR element. In addition, there is a missing @parameterRef that should appear to specify the parameter that holds the value. Some systems do not store that so it can be optional.
  • Reported: XTCE 1.1 — Sat, 5 Aug 2017 18:04 GMT
  • Updated: Tue, 10 Dec 2024 23:51 GMT

SpaceSystem can mean multiple things

  • Key: XTCE13-177
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    SpaceSystem in XTCE could mean a system/subsystem, a spacecraft, or perhaps a constellation of spacecraft. There should be a tag/attribute that specifies what the SpaceSystem represents. This would help with interpretation by implementing software.
  • Reported: XTCE 1.2 — Mon, 18 Nov 2024 16:40 GMT
  • Updated: Mon, 9 Dec 2024 19:35 GMT

BinaryEncoding Extension of SequenceContainer Requires SizeInBits Element

  • Key: XTCE13-162
  • Status: open  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Within the SequenceContainer element, there is a child element of BinaryEncoding that optionally provides some additional information to use for processing the SequenceContainer content. The BinaryEncoding element requires specifying the SizeInBits element, when that element is not always needed. Being required also presents a problem when using the ErrorDetectCorrect element in a non-deterministic length container.
  • Reported: XTCE 1.2 — Fri, 19 Jul 2024 01:58 GMT
  • Updated: Wed, 16 Oct 2024 00:41 GMT

ParameterToSet/Derivation is set to abstract and should not be

  • Key: XTCE13-135
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    ParameterToSet/Derivation is a MathOperationType which is abstract. Which means you cannot make an instance of it.

    A simple fix is to make a DerivationType extending MathOperationType.
  • Reported: XTCE 1.2 — Wed, 21 Jun 2023 19:32 GMT
  • Updated: Wed, 16 Oct 2024 00:41 GMT

Data encodings: FromBinaryTransformAlgorithm/ToBinaryTransformAlgorithm SizeInBits should be optional

  • Key: XTCE13-128
  • Status: open  
  • Source: Space Applications Services ( Nicolae Mihalache)
  • Summary:

    In data encoding definitions (currently only BinaryDataEncoding but see my other issue XTCE13-124), XTCE should allow the algorithm used in ToBinaryTransformAlgorithm and FromBinaryTransformAlgorithm to determine the size of the data on the wire.

    Thus the SizeInBits which is currently mandatory should be made optional when an algorithm is used.
  • Reported: XTCE 1.2 — Mon, 3 May 2021 14:17 GMT
  • Updated: Wed, 16 Oct 2024 00:41 GMT

BaseConditionsType too broad

  • Key: XTCE13-114
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Our for a list<element> in the BooleanExpression which made a base type called – BaseConditionsType is a little too broad because it include sub-type now only relevant on the command side.

    we should probably have a ArgumentBaseConditionsType.

    The children of it now are:

    ANDedConditionsType
    ArgumentANDedConditionsType
    ORedConditionsType
    ArgumentORedConditionsType
    ComparisonCheckType
    ArgumentComparisonCheckType
  • Reported: XTCE 1.2 — Fri, 10 Jul 2020 17:33 GMT
  • Updated: Wed, 16 Oct 2024 00:41 GMT

Dynamic look up should have integer and float forms

  • Key: XTCE13-109
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Dynamic lookup is sprinkled about the text to (only?) retrieve a numeric value but perhaps there should be an integer and float form. For example in calculating a dynamic array index, would it make sense if the referred to parameter is a float? we can agree any non-numeric is a error. If it's a float or integer, the slope and intercept are doubles – suggesting a double result. Well that may produce a fractional value of an array index – that doesn't make sense. one can round or chop as one sees fits but that's not documented. in this case integer only dynamic value would make more sense – the slope and intercept would be int/long and it would be in error to ref anything but an integer parameter type. other cases may allow for either data type. [edit] Discrete lookup DOES NOT have the same issue – it's value is a float. It however does need a default. I made an issue for that.
  • Reported: XTCE 1.2 — Thu, 9 Jul 2020 19:22 GMT
  • Updated: Wed, 16 Oct 2024 00:41 GMT

Clarify RepeatEntry's values and what they mean

  • Key: XTCE13-143
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Firstly because repeat is optional, it seems intuitive that this is the same as repeat=0. And that intuitively means the entry repeats 0 times, which means it appears 1 time in the container entry list. Likewise a repeat=1, means the entry appears 2 times and forth. This to me makes sense but maybe it doesn't.
    The syntax right now is broad and would allow all sort of values including negative ones. It's not clear that that would be anything but an error.
    Given all that we should say something about this in the annotation at the very least. And since FixedValue is a long we could change it to positive-only or perhaps non-negative. The DiscreteLookup value's type could also be modified (we'd have to make a "PositveOnlyDiscreteLookup" or some such). The last is a DynamicLookup and that would have to be enforced outside the syntax, we could imply it by calling it "PositiveOnlyDynamicLookup" or similar.
    Finally add annotation.
  • Reported: XTCE 1.2 — Wed, 17 Apr 2024 18:43 GMT
  • Updated: Tue, 30 Jul 2024 00:57 GMT

Simplify/align alarm severities across OMG specifications

  • Key: XTCE13-142
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    To align with other specifications within the OMG and AstroUXDS guidance, deprecate the watch and severe alarm severity levels.
  • Reported: XTCE 1.2 — Wed, 20 Mar 2024 20:36 GMT
  • Updated: Tue, 30 Jul 2024 00:57 GMT

Add an optional attribute to ComparisonList to make it all ORs

  • Key: XTCE13-141
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    For some reason this idea flew into my funnel this morning. I was looking at the ComparisonList and noticed the annotation to it said there's an implied 'and' between all the comparisons in the list.
    I then thought: Why not add an attribute to override that to set to it all ORs? Why would that be a bad thing?
    Unable to come up with any reason that this would be a bad thing, I decided it must be a good thing and that a good thing should be an issue.
    The main reason to support the OR case is that it's simply a little easier to build out the comparisonlist than the booleanexpression. And one assumes that if it's a good thing to have an ANDed ComparisonList for convenience, that it seems like symmetrically speaking it would be a good thing to have ORed ComparisonList for conveniences as well. Basically this is just a suggested small change for the convenience purposes.
  • Reported: XTCE 1.2 — Wed, 7 Feb 2024 16:02 GMT
  • Updated: Tue, 30 Jul 2024 00:57 GMT

Reconsider if Specific Color Names Should be Referenced

  • Key: XTCE13-140
  • Status: open  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Given that alarm consequence/significance labels are concepts and colors are implementations, should the XTCE schema refer to the colors by name? Perhaps it should refer to implementation of suggest AstroUX as a reference?
  • Reported: XTCE 1.2 — Thu, 7 Dec 2023 21:23 GMT
  • Updated: Tue, 30 Jul 2024 00:57 GMT

Non-ASCII characters in XSD annotations cause tooling issues

  • Key: XTCE13-129
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    Remove use of non-ASCII characters to improve tooling ease of use. These characters are utilized within Annotation fields.

    Symbols to change:
    ‘
    ’ '
    “
    ”
    –

    Also, in ArgumentAssignmentListType, add a single quote before "power on"
  • Reported: XTCE 1.2 — Tue, 15 Jun 2021 18:11 GMT
  • Updated: Tue, 30 Jul 2024 00:57 GMT

ArgumentType References Mixed with ParameterTypes in Key

  • Key: XTCE13-155
  • Status: open  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The name constraint for ArgumentType elements enforces uniqueness with ParameterType elements that appear in the CommandMetaData.

    <key name="argumentTypeNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique argument type name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:CommandMetaData/xtce:ArgumentTypeSet/|xtce:CommandMetaData/xtce:ParameterTypeSet/"/>
    <field xpath="@name"/>
    </key>

    This does not make sense because "argumentTypeRef" is distinct from "parameterTypeRef" in all cases.
  • Reported: XTCE 1.2 — Sun, 2 Jun 2024 20:05 GMT
  • Updated: Tue, 25 Jun 2024 00:36 GMT

clarify semantics of context cals (possibly same as context alarms)

  • Key: XTCE13-145
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Clarify that the list of contexts is in a specific ordering, and that as it stands now the <xsd:sequence> is in an order and that's the ordering. Or, consider adding a required "ordering" attribute to enforce the order. Or perhaps that subtly changes the semantics and we don't want to do any of it in which case we might say that...
  • Reported: XTCE 1.2 — Wed, 24 Apr 2024 15:59 GMT
  • Updated: Tue, 25 Jun 2024 00:36 GMT

Clarify Behavior of Context Alarms Only Containing a Match

  • Key: XTCE13-139
  • Status: open  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    It is unclear in the documentation how it should be handled when a parameter defines a context alarm for which only a match element is provided. This is valid in the schema.
  • Reported: XTCE 1.2 — Thu, 7 Dec 2023 16:20 GMT
  • Updated: Tue, 25 Jun 2024 00:36 GMT

rangeForm annotation needs work

  • Key: XTCE13-73
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The rangeForm annotation is vague and needs improvement. There are two places it occurs – one at the attribute level with another brief mention at the schema type:
    "A value of outside specifies that the most severe range is outside all the other ranges: -severe -critical -distress -warning -watch normal +watch +warning +distress +critical +severe. A value of inside "inverts" these bands: -green -watch -warning -distress -critical severe +critical +distress +warning +watch. The most common form used is "outside" and is the default."

    The key problem is the term "inverts" is not really defined and so the entire explanation is overly general.
  • Reported: XTCE 1.2 — Thu, 3 Oct 2019 14:35 GMT
  • Updated: Tue, 25 Jun 2024 00:36 GMT

Change Alarm Element Bad Attributes

  • Key: XTCE13-138
  • Status: open  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Not sure that specifying range form in a change alarm makes sense as the min/max are relative to the value itself. In addition, both exclusive and inclusive range values are allowed and that doesn't seem to make sense for exclusive.
  • Reported: XTCE 1.2 — Wed, 6 Dec 2023 18:28 GMT
  • Updated: Tue, 25 Jun 2024 00:36 GMT

FixedValueEntry, maybe it's not as good as it could be

  • Key: XTCE13-137
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    FixedValueEntry has a hard coded hexBinary value that's supposed to be in "spacecraft order". There's a now optional name in 1.2.

    ITOS and ASIST capture the same info slightly differently. The value is in human-readable form, (e.g "5331" or whatever it is that you can read and understand). But Bit/Byte order are provided as modifiers to the field/entry definition so that the software will do the right thing and encode it properly for the final destination on the spacecraft. ITOS/ASIST require the name and other associated the meta data for these fields.

    So there's similarities overall between them but the encoding aspect is the key difference.

    The upsides to their approach are (there may be more):

    • when you see the definition, it makes some sense to you
    • the software takes care of the encoding and in a way it is then documented as to what is the both the value is and how it's going to be encoded for the final destination.

    The downsides are (could be more):

    • well something will have to be done to see the final bit values ...
    • there's more to write out to build the definition

    Is there a case to be made to change, or modify the existing fixedvalueentry? What would the approach be?

    1) maintain pure backwards compatibility: add a second variation "uservalueentry" that supplies it as described above and includes a local bit/byteorder
    2) modify fixedavalueentry itself and keep a kind of conceptual compatibility...

    What do you think?
  • Reported: XTCE 1.2 — Tue, 14 Nov 2023 16:15 GMT
  • Updated: Tue, 25 Jun 2024 00:36 GMT

RelativeTime's ChangePerSecondRangeAlarm should be a TimeChangesPerSecondAlarmType

  • Key: XTCE13-136
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    RelativeTimeParamaterType static and change alarms are both TimeAlarmRangesType. At the very least it would be clearer if the ChangePerSecondRangeAlarm is its own type.
    A simple solution would be to create a new type (TimeChangePerSecondRangeAlarmType) and have it extend TimeAlarmRangesType.
    (Assuming that it's correct that both of these should describe alarms in the same using same underlying type.)
  • Reported: XTCE 1.2 — Mon, 17 Jul 2023 16:11 GMT
  • Updated: Tue, 25 Jun 2024 00:36 GMT

Possible typo of word "difference" instead of "different"

  • Key: XTCE13-134
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    "There are eight different verifiers each associated with difference states in command processing"
  • Reported: XTCE 1.2 — Wed, 21 Sep 2022 20:59 GMT
  • Updated: Tue, 25 Jun 2024 00:36 GMT

Invalid schema exception with xerces parser

  • Key: XTCE13-130
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    We have experienced the following error with the Xerces XML parser:

    Exception thrown at 0x00007FFB902D4F69 in InstallDB4.exe: Microsoft C++ exception: xercesc_3_0::InvalidDatatypeValueException at memory location 0x000000000014D5A0.

    It seems to be driven by this line:
    <attribute name="idlePattern" type="xtce:FixedIntegerValueType" default="0x0"/>

    Changing the default value to "0" seems to make the problem go away.

    Can we change the line instead to:
    <attribute name="idlePattern" type="xtce:FixedIntegerValueType" default="0"/>
  • Reported: XTCE 1.2 — Thu, 20 Jan 2022 13:58 GMT
  • Updated: Tue, 25 Jun 2024 00:36 GMT

FromBinaryTransformAlgorithm/ToBinaryTransformAlgorithm should be allowed for all data encodings

  • Key: XTCE13-124
  • Status: open  
  • Source: Space Applications Services ( Nicolae Mihalache)
  • Summary:

    Currently the FromBinaryTransformAlgorithm/ToBinaryTransformAlgorithm are allowed only for BinaryDataEncodingType with the comment "Used to convert binary data from an application data type to binary data". However the binary data encoding is used to encode/decode binary data, so not any application data (float, integer, time,...).

    We believe it is more beneficial to allow these algorithms to all data encoding types.

    For example a FromBinaryTransformAlgorithm attached to a IntegerDataEncoding can extract a varint like the ones used in protobuf (https://developers.google.com/protocol-buffers/docs/encoding#varints).

    Similarly a ToBinaryTransformAlgorithm attached to a FloatDataEncoding can be used to encode a floating point number in an exotic format; for example bfloat16 is commonly used in AI chips (https://en.wikipedia.org/wiki/Bfloat16_floating-point_format)
  • Reported: XTCE 1.2 — Thu, 22 Apr 2021 07:57 GMT
  • Updated: Tue, 25 Jun 2024 00:36 GMT

Is rangeForm specialization needed for Change and Multi band alarms?

  • Key: XTCE13-74
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    RangeForm now appears in Static, Change and the multi band. It's not clear these all make sense to me.

    In the static ranges – having the red be the most severe inner band and green "good" on the outside does make sense although I get the impression the use cases are less in number than the standard way folks think of limits. (you're going too fast! not – you're not going fast enough!)

    In the change alarm, which I think of mainly as deltas – again intuitively checking for big changes make sense. Unwanted big jumps are intuitive. But unwanted little jumps? That is big jumps are good? Is there a real use case – perhaps we can jam it into the annotation.

    Finally for the multirange alarm. The rangeForm is at each band. I suspect but don't know that this was to change the range set meaning...
    Intuitively "inside" would be something like this: [min, max] – where x is between them is "ok" ...

    And "outside" would be (-inf, min] and [max, inf) ... that is ranges point 'away'...

    But maybe not – who knows!? Given that though the default is "outside" when perhaps most would want it to be "inside" etc...

    I just wonder if we have done this correctly or its slipped through and is overly general because we inherited the various types, etc...
  • Reported: XTCE 1.2 — Thu, 3 Oct 2019 14:46 GMT
  • Updated: Tue, 25 Jun 2024 00:36 GMT

reference to aggregate members and arrays

  • Key: XTCE13-126
  • Status: open  
  • Source: Space Applications Services ( Nicolae Mihalache)
  • Summary:

    The XTCE spec is not very clear on how the aggregate members can be referenced (for example in match criterias). The doc of AggregateParameterType reads:
    "Each member may be addressed by the dot syntax similar to C such as P.voltage if P is the referring parameter and voltage is of a member of P’s aggregate type. See MemberType, MemberListType, DataEncodingType, NameReferenceType, and AggregateDataType".

    However the definition of "NameReferenceType" is silent about aggregates and the "." (dot) character is not allowed to be used in a reference (except in the "./" where it denotes "current space system). The reference suggested above "P.voltage" is invalid.

    In some examples over the internet references to aggregate members are found using standard "/" separator. However this is problematic because a reference like "/A/B/C" is ambiguous, could translate into:
    A (space system)/B(space system)/C(parameter name)
    or
    A(space system)/B(parameter name)/C(aggregate member name)

    Suggest to allow dot notation to reference aggregate members. Similarly allow "[idx]" to reference array indices.

    For example a reference "/A/B.C[3]" can be unambiguously understood as:
    A(space system)/B(parameter name).C(aggregate member name of type array) [3] (index in the C array)

    Perhaps NameReferenceType can be made less restrictive or another type can be defined and used in the ParameterRefType definition.
  • Reported: XTCE 1.2 — Fri, 23 Apr 2021 07:38 GMT
  • Updated: Wed, 27 Sep 2023 19:25 GMT

Possible typo of word "encoded" as "endcode"

  • Key: XTCE13-116
  • Status: open  
  • Source: CACI ( Zebulun Barnett)
  • Summary:

    Appears to be a typo in the BinaryDataEncoding description in the ParameterTypeSet section. "...specifies the bit order, the size in bits, and two algorithms to convert to and from the endcode
    value, along with error detection (CRC and Parity checks).
  • Reported: XTCE 1.2 — Thu, 3 Sep 2020 19:40 GMT
  • Updated: Tue, 1 Dec 2020 00:50 GMT

Disallow duplicate labels in the EnumerationList

  • Key: XTCE13-115
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The EnumerationList should probably have a key to disallow the duplicate labels. (similar to the @name keys)
  • Reported: XTCE 1.2 — Wed, 15 Jul 2020 17:45 GMT
  • Updated: Tue, 1 Dec 2020 00:50 GMT

parametertype and argumenttype type hiearchies still need work

  • Key: XTCE13-113
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    This is more for discussion. our syntax is ok but when the schema types that control the syntax in parameter/argument type are manifest into classes, the result is less than ideal.

    Firstly all our parametertype/argumenttypes have NameDescriptionType as the root. It might for example make sense to have as a root "DataType" or something of that nature – and maybe to then ScalarDataType and ComplexDataType which seems natural.

    Secondly we now have split the parameter type and argument types because we had to support looking up parameters and arguments in the latter. And these appear deep in the syntax trees. More ideally we'd just bolt on those latter in the hierarchy so as to show more schema types.

    Finally somehow array and aggregate didn't get the message – and the time types have their own data encoding syntax.

    The result is this:

    BaseDataType – all the scalars on the parameter type side have this as a parent.

    XXXDataType – next up the various scalars have this interim schema type. This is a vestige from 1.1. So for example IntegerDataType.

    BaseTimeDataType – absolute and relative use this though.

    ArrayDataTypeType and AggregateDataType – array and aggregate follow this line

    Then on the argument side, this is mirrored but with "argument" stuck in front of it all:

    ArgumentBaseDataType, ArgumentBaseTimeDataType – oddly Array and Aggregate on this side have ArrayDataTypeType and AggregateDataType as parents.

    In the end we up with lots of "root" schema types that are all children of NameDescriptionType – BaseDataType, BaseTimeDataType, ArgumentBaseDataType, ArgumentTimeBaseDataType, ArrayDataTypeType and AggregateDataType.

    There's no DataType, ScalarDataType or ComplexDataType which might more natural organize it.

    Conclusion: this could all be better.
  • Reported: XTCE 1.2 — Fri, 10 Jul 2020 11:28 GMT
  • Updated: Tue, 1 Dec 2020 00:50 GMT

LinearAdjust -- slope should default to 1

  • Key: XTCE13-112
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    This seems an old issue. Slope is optional and intercept is optional. But intercept defaults to 0. Slope has no default. The generated classes then return a Double and double. Seems like slope=1 by default would be a good thing.

    Btw there's a related issue of having this return doubles when they are only being used in non-float number evaluation.
  • Reported: XTCE 1.2 — Thu, 9 Jul 2020 20:39 GMT
  • Updated: Tue, 1 Dec 2020 00:50 GMT

CustomAlgorithm needs a language/implementation field

  • Key: XTCE13-111
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Perhaps this is more about discussion first but a language/implementation (& version?) attribute would help custom algorithm be useful – and perhaps resolvable by your code.

    For example, since most of the implementations of xtce are java – there are many jvm languages that could run as embedded "script" through the custom algorithm – if we but only knew which one to run!

    For example so called "space python" could be run on jython…

    We use gradle at work, and I'm so used to it forking of JVMs in other languages to do things – I'm thinking, let's give it a go! (we use a plugin that is in written python and is run by gradle on as jython on another jvm)
  • Reported: XTCE 1.2 — Thu, 9 Jul 2020 19:39 GMT
  • Updated: Tue, 1 Dec 2020 00:50 GMT

Discrete lookup list has no default (or i don't get it)

  • Key: XTCE13-110
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The discrete lookup list, also sprinkled about the syntax tree retrieves the specified numeric value if its condition evaluates to true. for particular discrete in the list. there are several kinds of conditions. The text isn't completely clear but it seems the first discrete lookup in the list that evaluates to true – returns that value. But what happens if none eval to true? it seems that default value is warrented.

    Note: the value is a long. Therefore it does not have same problem as dynamic lookups double data types for integer syntax items.
  • Reported: XTCE 1.2 — Thu, 9 Jul 2020 19:31 GMT
  • Updated: Tue, 1 Dec 2020 00:50 GMT

BinaryContextAlarmList should be ContextAlarmList

  • Key: XTCE13-108
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Type in element name in BinaryParameterType. Possibly a duplicated but I couldnt find it.
  • Reported: XTCE 1.2 — Tue, 21 Apr 2020 16:48 GMT
  • Updated: Tue, 1 Dec 2020 00:50 GMT

ArgumentInputSetType is inconsistent with InputSetType

  • Key: XTCE13-34
  • Status: open  
  • Source: Peraton ( Victoria Vickers)
  • Summary:

    The InputSetType has a InputParameterInstanceRefType as well as a ConstantType.
    The ArguementInputSetType has a InputParameterInstanceRefType as well as a InputArgumentInstanceRefType.
    The inconsistency causes some confusion as to usage.
  • Reported: XTCE 1.2b1 — Wed, 17 Oct 2018 13:24 GMT
  • Updated: Tue, 1 Dec 2020 00:50 GMT

Inconsistency in Argument Types with respect to FixedIntegerValueType

  • Key: XTCE13-33
  • Status: open  
  • Source: Peraton ( Victoria Vickers)
  • Summary:

    For instance the documentation for the the ArgumentIntegerDataType says that it is identical to the IntegerDataType. However the initialValue attribute is types as a FixedIntegerValueType whereas the initialValue attribute for the IntegerDataType is typed as long.
  • Reported: XTCE 1.2b1 — Mon, 15 Oct 2018 15:26 GMT
  • Updated: Tue, 1 Dec 2020 00:50 GMT

needs to be updated for items that no longer support hex, octal, binary

  • Key: XTCE13-32
  • Status: open  
  • Source: Peraton ( Victoria Vickers)
  • Summary:

    Items that previously were typed as FixedIntegerValueType but were changed to become long need to be revisited to update the documentation annotation. For instance IntegerDataType initialValue attribute documentation:
    "Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively."
    Such forms no longer validate against the schema.
  • Reported: XTCE 1.2b1 — Mon, 15 Oct 2018 15:19 GMT
  • Updated: Tue, 1 Dec 2020 00:50 GMT

Inconsistent time unit data types

  • Key: XTCE13-39
  • Status: open  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    XTCE v1.2 added "unit" attribute to TimeAssocationType and added a specialized data type (TimeAssociationUnitType) that is inconsistent with the existing data type (TimeUnitsType)
  • Reported: XTCE 1.2 — Fri, 22 Feb 2019 21:51 GMT
  • Updated: Wed, 1 Jul 2020 00:35 GMT

Incorrect MetaCommandRef element definition

  • Key: XTCE13-37
  • Status: open  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    Draft version of XTCE v1.2 defined <MetaCommandRef> element as:
    <element name="MetaCommandRef" type="xtce:MetaCommandRefType">
    <complexType name="MetaCommandRefType">
    <annotation>
    <documentation>Describe a reference to a MetaCommand . See NameReferenceType.</documentation>
    </annotation>
    <attribute name="metaCommandRef" type="xtce:NameReferenceType" use="required"/>
    </complexType>

    Published version of XTCE v1.2:
    <element name="MetaCommandRef" type="xtce:NameReferenceType">

    Published version is inconsistent:

    • The attribute "metaCommandRef" is used several other places
    • This is the place where a name reference is element text content instead of an attribute.
  • Reported: XTCE 1.2 — Fri, 22 Feb 2019 21:26 GMT
  • Updated: Wed, 1 Jul 2020 00:35 GMT

CNES CCSDS -- unit set "form" question

  • Key: XTCE13-71
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    "A new attribute UnitFormType allows to specify a unit for calibrated values and another unit for uncalibrated values.

    Why is this attribute defined with 3 enumerations? ‘raw’, ‘uncalibrated’ and ‘calibrated’?
    "
  • Reported: XTCE 1.2 — Wed, 2 Oct 2019 14:49 GMT
  • Updated: Wed, 1 Jul 2020 00:35 GMT

CustomAlarmType has wrong parent

  • Key: XTCE13-67
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The CustomAlarmType appears to extend BaseAlarmType, where as it should just be an extension of InputAlgorithmType (or similar). The result is there are three name attributes to fill in if you want to do so.

    In fact because the AlarmType is the base for all the various DefaultAlarms, the CustomAlarm should probably extend a stubby version of InputAlgorithm without a name or description attribute.
  • Reported: XTCE 1.2 — Tue, 1 Oct 2019 18:42 GMT
  • Updated: Wed, 1 Jul 2020 00:35 GMT

ByteOrderList is invalid for Containers

  • Key: XTCE13-29
  • Legacy Issue Number: 14517
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2009-09-10 22:59:58 BST
    ByteOrderList is not valid for container and is part of the BinaryEncoding
    element.

    Ignore or remove from future version.
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Wed, 1 Jul 2020 00:35 GMT

Add event message support

  • Key: XTCE13-25
  • Legacy Issue Number: 19388
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Even message support is need in XTCE. Adding an EventSet to TelemetryMetaData would be an appropriate location.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Updated: Fri, 10 Apr 2020 00:21 GMT

Checkwindow not tied to context

  • Key: XTCE13-17
  • Legacy Issue Number: 14458
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2007-10-22 21:09:15 BST
    CheckWindow has no way to vary window size based on context
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Fri, 10 Apr 2020 00:21 GMT

Clean up semantics of "OO-Include Condition"

  • Key: XTCE13-28
  • Legacy Issue Number: 14509
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2008-05-28 21:45:18 BST
    In EntryList, a containerRef that's to an abstract container has special
    meaning. perhaps it warrants it own entry to clear up the semantics.
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Fri, 10 Apr 2020 00:21 GMT

CustomAlgorithm should be "typed" reference to AlgorithmSet

  • Key: XTCE13-13
  • Legacy Issue Number: 14505
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2008-05-28 21:35:39 BST
    CustomAlgorithm which appears in many places in the schema should be a
    namereference to AlgorithmSet. To enforce the proper semantics the Ref should
    "name" which algorithm type it referes to such as "InputAlgorithmRef" or
    "InputOutputAlgorithmRef", etc...
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Fri, 10 Apr 2020 00:21 GMT

CNES CCSDS -- inside/outside range support in ValidRange

  • Key: XTCE13-70
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    "The issue is partially fixed. The new attribute rangeForm shall be also used in ValidRange and not only in AlarmRangesType.

    The use of this new attribute allows to simplify the definition of ranges (in replacing minInclusive, maxInclusive, minExclusive and maxExclusive with min & max)."
  • Reported: XTCE 1.2 — Wed, 2 Oct 2019 14:45 GMT
  • Updated: Fri, 25 Oct 2019 00:57 GMT

CNES CCSDS -- Time ParameterType inheritance may need to be repolled

  • Key: XTCE13-68
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    An issue marked as deferred in 1.1, made into 1.2.

    "Type inheritance missing from Absolute and Relative time data types

    The status of this issue is ‘Deferred’ but the proposed change has been implemented in 20180204-SpaceSystemV1.2.xsd"
  • Reported: XTCE 1.2 — Wed, 2 Oct 2019 14:40 GMT
  • Updated: Fri, 25 Oct 2019 00:57 GMT

MemberType and ComparisonType annotation misses fix to value formatting

  • Key: XTCE13-91
  • Status: open  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    In the MemberType element, the initialValue attribute missed the annotation fix to remove the "0b" and "0x" stuff from previous discussions and resolution in XTCE 1.2.
  • Reported: XTCE 1.2 — Sat, 12 Oct 2019 19:45 GMT
  • Updated: Fri, 25 Oct 2019 00:57 GMT

ServiceRef construction error

  • Key: XTCE13-31
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The service ref now require content and an attribute – this clearly the result of an "oops" during clean up of 1.2.

    Basically it should NOT extend NameDescriptionType.

    <complexType name="ServiceRefType">
    <annotation>
    <documentation xml:lang="en">A reference to a Service</documentation>
    </annotation>
    <simpleContent>
    <extension base="xtce:NameReferenceType">
    <attribute name="serviceRef" type="xtce:NameReferenceType" use="required"/>
    </extension>
    </simpleContent>
    </complexType>
  • Reported: XTCE 1.2 — Mon, 14 May 2018 17:35 GMT
  • Updated: Fri, 25 Oct 2019 00:57 GMT

inability to describe sets of limits (alarms) and conversions (polynomials)

  • Key: XTCE13-21
  • Legacy Issue Number: 8908
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    inability to describe sets of limits (alarms) and conversions (polynomials) and then select a set per parameter depending on mission phase (JWST)

    JWST hold conversion and limits in a seperate file that are grouped. Certains "sets" can be used for different mission phases such as test, on-orbit and so on, or for any reason deemed appropriate. XTCE allows one to specify at MOST one of each of these per parameterType
  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Updated: Fri, 25 Oct 2019 00:57 GMT

Need support for mask alarm

  • Key: XTCE13-9
  • Legacy Issue Number: 19371
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A mask alarm applies to numerics and enums – although usage in floats is discouraged. It defines 16-states which map 1 to 1 with values (say 1-16), it's a 16-bit mask – each bit is either a care or don't care. If set to 1, it's a care bit. If the value associated with that bit appears, it is in alarm. If the mask bit is set to 0, it's a don't care bit – and the value associated with it will not trip an alarm. When used with enums it's almost like an enum alarm list,except the states can go "past" the range of values given in the enum list itself. For example, suppose an enum had the values of OPEN=1, SHUT=2. The mask could be 0xfffffffc - as one and two are allowed and valid. And any other value would be in alarm. Because there's only two enum values and each of these is green but any other value is read, it is hard to completely simulate this alarm with the enum alarm list. It's possible to use a condition perhaps in this one example but the current syntax requires the enum alarm list. Further transferring this information through to another party will be hard in that case. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Updated: Fri, 25 Oct 2019 00:57 GMT

RelativeTimeAgumentType is misspelled

  • Key: XTCE13-36
  • Status: open  
  • Source: Peraton ( Victoria Vickers)
  • Summary:

    <element name="RelativeTimeAgumentType" type="xtce:RelativeTimeArgumentType">
    RelativeTimeAgumentType should have an "r" in it.
  • Reported: XTCE 1.2b1 — Thu, 18 Oct 2018 19:22 GMT
  • Updated: Tue, 15 Oct 2019 00:00 GMT

CNES CCSDS -- RelativeTimeAgument typo

  • Key: XTCE13-69
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    "Some typos have been fixed (twosComplement instead of twosCompliment & onesComplement instead of onesCompliment) but one is still present in the schema: RelativeTimeAgumentType instead of RelativeTimeArgumentType."
  • Reported: XTCE 1.2 — Wed, 2 Oct 2019 14:43 GMT
  • Updated: Tue, 15 Oct 2019 00:00 GMT

ArgumentAssigmentList in the MetaCommandStep is misspelled

  • Key: XTCE13-35
  • Status: open  
  • Source: Peraton ( Victoria Vickers)
  • Summary:

    This should be ArgumentAssignmentList, with an "n".
  • Reported: XTCE 1.2b1 — Thu, 18 Oct 2018 17:03 GMT
  • Updated: Tue, 15 Oct 2019 00:00 GMT

Unecessary Sequence of choice in AlarmType

  • Key: XTCE13-66
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Just a typo in the schema construction, should just be optional choice.

    <sequence>
    <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>
    </sequence>
  • Reported: XTCE 1.2 — Tue, 1 Oct 2019 18:22 GMT
  • Updated: Tue, 15 Oct 2019 00:00 GMT

Re-architect XTCE alarm model

  • Key: XTCE13-10
  • Legacy Issue Number: 19369
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    XTCE alarms are associated with data types and come in a default and context set form. A variety of alarm types are associated with each data type, some specific to it (such enum alarms). However this is too restrictive to meet the needs of many of organizations. Specifically the following is requested: allow set of alarms without a required context by data type. Original reporter is JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Updated: Tue, 15 Oct 2019 00:00 GMT

Move Alarms outside of Type Area

  • Key: XTCE13-19
  • Legacy Issue Number: 14454
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2007-10-22 21:04:10 BST
    Move Alarms outside of Type area. Alarms may change a lot and it may be easier
    to have them set in the Parameter area, further alarms and calibrators, as well
    as the time types reference Parameters directly which seems inconsistent with
    them being in types.

    C-S/CNES
    Ludovic Faure
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Tue, 15 Oct 2019 00:00 GMT

AbsoluteTime should have Alarms

  • Key: XTCE13-16
  • Legacy Issue Number: 14466
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2007-10-22 21:37:38 BST
    AbsoluteTimeParameterType do not have alarm elements associated with it. In
    the current schema this may be by design – an example of a usage for an
    alarming absolute time could be helpful. JWST claims to alarm on occurrences
    of reverse time which in fact would probably be a packet ordering issue.
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Tue, 15 Oct 2019 00:00 GMT

Expand features to include common industry encodings in StreamsSet

  • Key: XTCE13-2
  • Legacy Issue Number: 19386
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Added specific support for reed-solomon and turbo encoding, among others in the stream set. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Updated: Tue, 15 Oct 2019 00:00 GMT
  • Attachments:

Add gap entry to container entry list

  • Key: XTCE13-5
  • Legacy Issue Number: 19384
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A gap entry is an addressing mechanism to move the address pointer relative or absolutely as specified in the gap entry. This is an alternate approach to XTCE's location in container element. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Updated: Tue, 15 Oct 2019 00:00 GMT

Duplicated BaseCalibratorType extension

  • Key: XTCE13-40
  • Status: open  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    XTCE 1.2 defined as base data type for calibrators (BaseCalibratorType).
    This data type is used an extension twice for each calibrator:

    • Once in CalibratorType
    • Again in the child element (e.g., PolynomialCalibratorType)
  • Reported: XTCE 1.2 — Fri, 22 Feb 2019 21:58 GMT
  • Updated: Tue, 20 Aug 2019 00:03 GMT

Cleanup Container EntryList element by deprecating IndirectParameterRefEntry

  • Key: XTCE13-27
  • Status: open  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The IndirectParameterRefEntry is a clever construct that has the potential to be useful, although I am not aware of anyone who has used it.

    I suggest that we consider removing it because it is a limited case of the more general case solved by the IncludeCondition element. The IncludeCondition can provide this functionality and a lot more. As a result, this element is effort for implementers that doesn't add anything really "new". In addition, it leaves a case where the need is addressed in more than 1 way - which is generally not the best idea.
  • Reported: XTCE 1.1 — Tue, 30 May 2017 23:44 GMT
  • Updated: Tue, 20 Aug 2019 00:03 GMT

Message/IncludeCondition/BaseContainer similarity

  • Key: XTCE13-18
  • Legacy Issue Number: 14460
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2007-10-22 21:11:43 BST
    Message, IncludeCondition and BaseContainer do similar things and should be
    unified
    Comment 1 Kevin Rice 2007-10-22 21:21:03 BST
    Message, IncludeCondition and BaseContainer do similar things and should be
    unified
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Tue, 20 Aug 2019 00:03 GMT

Add forward/reverse calibrator metadata

  • Key: XTCE13-15
  • Legacy Issue Number: 14473
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2007-10-22 21:48:47 BST
    Some organizations wish to capture counts to units on the telemetry side & then
    units to counts on command side (often called reverse or inverse calibrators).
    In some cases they may wish to both for various reasons, often in testing
    scenarios to validate their operation calibration. XTCE does not provide an
    easy way to mark a calibrator as either 'reverse' or 'forward'.
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Tue, 20 Aug 2019 00:03 GMT

Type inheritance missing from Absolute and Relative time data types

  • Key: XTCE13-1
  • Legacy Issue Number: 19633
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Absolute and Relative time should have a "baseType" similar to the other scalar data types. This is probably an oversight.

  • Reported: XTCE 1.1 — Mon, 6 Oct 2014 04:00 GMT
  • Updated: Tue, 20 Aug 2019 00:03 GMT

Should RestrictionCriteria should be assignment not operators for Commanding?

  • Key: XTCE13-11
  • Legacy Issue Number: 14506
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2008-05-28 21:39:55 BST
    RestrictionCriteria seems incorrect for commands. the value checked are
    inserted to form the command, operators seem a little strange, maybe only '=='
    makes sense, etc...
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Tue, 20 Aug 2019 00:03 GMT

Add ArgumentTypeSet to MetaCommand

  • Key: XTCE13-8
  • Legacy Issue Number: 19377
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Allow for local argument types to be defined in MetaCommand, helps avoid collisions with arguments in other commands of the same name but different properties.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Updated: Tue, 20 Aug 2019 00:03 GMT

Expand NameReference semantics

  • Key: XTCE13-14
  • Legacy Issue Number: 14489
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2008-03-04 22:57:09 GMT
    Expand NameReference concept to allow specifying items in precise locations
    such as TelemetryMetaData, CommandMetaData, etc...
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Tue, 20 Aug 2019 00:03 GMT

Missing default value of dataSource attribute

  • Key: XTCE13-38
  • Status: open  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    Draft version of XTCE v1.2 defined dataSource attribute as:
    <attribute name="dataSource" type="xtce:TelemetryDataSourceType" default="telemetered">

    Published version is v1.1:
    <attribute name="dataSource" type="xtce:TelemetryDataSourceType" use="optional">
  • Reported: XTCE 1.2 — Fri, 22 Feb 2019 21:37 GMT
  • Updated: Wed, 12 Jun 2019 00:17 GMT

Re-evaluate the characterWidth attribute in String types

  • Key: XTCE13-26
  • Status: open  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    I am not sure that this attribute makes sense in the String data type definitions. The character encoding (@encoding) element really should capture the knowledge here, but there could be a nuance I am unsure about.

    Check on this in the committee meeting. Propose to remove the attribute.
  • Reported: XTCE 1.1 — Sat, 9 Sep 2017 18:22 GMT
  • Updated: Wed, 12 Jun 2019 00:17 GMT

lack of Union construct (MER + ASIST)

  • Key: XTCE13-20
  • Legacy Issue Number: 8909
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    MER supports a Union construct because their abstract data types live past decomm. ASIST also supports the same idea – that an abstract data type onboard the spacecraft MAY live past decomm. Although it is possible to let multiple parameters overlap, in a sense allowing for a Union in XTCE. The issue arises that validating software cannot differentiate this with a bug in a container specification. A union tag or element of some sort is needed.
  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Updated: Wed, 12 Jun 2019 00:17 GMT

Spelling error for Arguments in XTCE 1.2 proposed

  • Key: XTCE13-22
  • Status: open  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Reported by Michel Sibon of Thales. There is a spelling error of the word "Agument" in RelativeTimeArgumentType in XTCE 1.2 proposed. It has been present for some time because it is also reflected in the xtcetools schema file that was based on an early XTCE 1.2 releae schema.

    <element name="RelativeTimeAgumentType" type="xtce:RelativeTimeArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a duration in time.</documentation>
    </annotation>
    </element>

    The text above is from the RTF report version of the file.
  • Reported: XTCE 1.1 — Tue, 20 Mar 2018 12:18 GMT
  • Updated: Wed, 12 Jun 2019 00:17 GMT

Provide way to categorize all elements with @name into one or more groups

  • Key: XTCE13-4
  • Legacy Issue Number: 19381
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Outside of the SpaceSystem and systemName, a general mechanism for categorizing @name elements into one or groups is needed. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Updated: Wed, 12 Jun 2019 00:17 GMT

Add switch entry to container entry list

  • Key: XTCE13-3
  • Legacy Issue Number: 19385
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A switch entry is similar to the switch/case statement provided in most programming languages, and would improve upon the include condition currently found in XTCE. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Updated: Wed, 12 Jun 2019 00:17 GMT

Add OCL specific Algorithm to XTCE

  • Key: XTCE13-12
  • Legacy Issue Number: 14507
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2008-05-28 21:41:50 BST
    OCL is an OMG standard that adds a constraint language to UML or any model.
    It's related to RestrictionCriteria. Would a specific XTCE Algorithm for OCL
    be useful?
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Wed, 12 Jun 2019 00:17 GMT

Elevate annotation specifying time string formats to an attributes

  • Key: XTCE13-7
  • Legacy Issue Number: 19376
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The annotation below would be better served as an optional attribute with the specified format as the default. From a telemetry stantpd this would be interpreted as optional display info, and from an argument standpt the user input string format. "Used to contain an absolute time. Contains an absolute (to a known epoch) time. Use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported. "

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Updated: Wed, 12 Jun 2019 00:17 GMT

Add variable to containers

  • Key: XTCE13-6
  • Legacy Issue Number: 19382
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Variables are local values created from bit/sub-bits specified in the entry list of container. They are similar to parameters but exist only within the scope of the container they are defined – they are of type integer. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Updated: Wed, 12 Jun 2019 00:17 GMT