1. OMG Mailing List
  2. XTCE Revision Task Force

Closed Issues

  • Issues resolved by a task force and approved by Board
  • Name: xtce-rtf
  • Issues Count: 159

Issues Summary

Key Issue Reported Fixed Disposition Status
XTCE12-396 Calibrator selection using raw value XTCE 1.1 $issue.fixedSpecification.name Deferred closed
XTCE11-370 ESA-035 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-369 9 -- Expand explanatory for certain terms, Data Type and Data Encoding Type XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-368 6 - Add Delta Alarms to XTCE XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-337 ESA-052 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-336 ESA-051 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-335 ESA-050 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-334 ESA-049 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-333 ESA-047 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-347 ESA-070 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-346 ESA-066 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-345 ESA-064 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-344 ESA-063 XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-360 NASA-007 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-359 NASA-005 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-358 NASA-003 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-357 NASA-002 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-356 INPE-011 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-355 INPE-010 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-365 Division symbol XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-364 NASA-012 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-363 NASA-011 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-362 NASA-009 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-361 NASA-008 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-354 INPE-008 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-353 INPE-005 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-352 INPE-004 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-351 INPE-002 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-343 ESA-062 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-342 ESA-061 XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-341 ESA-060 XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-340 ESA-059 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-339 ESA-058 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-338 ESA-057 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-350 ESA-076 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-349 ESA-074 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-348 ESA-073 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-325 ESA-030 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-324 ESA-029 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-323 ESA-028 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-322 ESA-027 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-321 ESA-024 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-320 ESA-021 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-332 ESA-046 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-331 ESA-044 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-330 ESA-043 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-329 ESA-037 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-328 ESA-036 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-327 ESA-033 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-326 ESA-031 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-319 ESA-003 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-318 JPL-031 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-317 JPL-028 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-316 JPL-027 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-315 JPL-025 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-312 JPL-022 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-311 JPL-021 XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-310 JPL-020 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-309 JPL-019 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-308 JPL-018 XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-307 JPL-017 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-306 JPL-015 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-305 JPL-014 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-304 JPL-013 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-303 JPL-012 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-302 JPL-011 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-301 JPL-010 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-288 INPE-001 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-287 ESA-079 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-286 ESA-078 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-285 ESA-077 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-284 ESA-075 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-283 ESA-072 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-256 Change service set to either accept Messages or Container references XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-255 10 - Add indicator of operational status to XTCE (JPL-004) XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-254 8 - Expand explanatory material related to "Figure 3" XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-253 7 - Expand explanatory material related to "Figure 2" XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-252 5 -- Expand explanatory material related to "Figure 6" XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-251 4 -- Expand explanatory material related to "Figure 4" XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-232 NumericAlarmConditionTy XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-231 ToString and Booleans XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-230 SplineCalibrator XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-229 CalibratorType (03) XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-228 CalibratorType (02) XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-227 CalibratorType XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-226 sizeInBits XTCE 1.0b1 XTCE 1.1 Resolved closed
XTCE11-225 Ref rules should be spelled out XTCE 1.0b1 XTCE 1.1 Duplicate or Merged closed
XTCE11-250 Expand explanatory material related to "Figure 2" XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-249 Expand explanatory material XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-248 1 - move initialValue and UnitSet to ParameterSet (ESA-08) XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-247 NameType XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-246 Aliases XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-245 SpaceSystemType XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-224 Clarification is needed on Ref names "local" to a spaceSystem XTCE 1.0b1 XTCE 1.1 Duplicate or Merged closed
XTCE11-223 Container/Argument/Stream/Type/etc XTCE 1.0b1 XTCE 1.1 Duplicate or Merged closed
XTCE11-222 proper reference formed weak XTCE 1.0b1 XTCE 1.1 Resolved closed
XTCE11-221 XTCE Command "Permissions" model may not be generic enough XTCE 1.0b1 XTCE 1.1 Resolved closed
XTCE11-220 JWST, non-CCSDS header commands, routing info XTCE 1.0b1 XTCE 1.1 Duplicate or Merged closed
XTCE11-219 JPL MER schema supports "hardware commands XTCE 1.0b1 XTCE 1.1 Duplicate or Merged closed
XTCE11-218 Variable length command packets must be supported XTCE 1.0b1 XTCE 1.1 Resolved closed
XTCE11-217 no tracking mechanism per PARAMETER for changes (no change log) XTCE 1.0b1 XTCE 1.1 Resolved closed
XTCE11-216 lack of clean way to describe multiple documentary type items XTCE 1.0b1 XTCE 1.1 Duplicate or Merged closed
XTCE11-244 Parameters XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-243 BlockMetaCommandType XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-242 CommandContainer/Entry XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-241 Argument set XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-240 Algorithm for derived XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-239 ParameterType XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-314 JPL-024 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-313 JPL-023 XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-282 ESA-069 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-281 ESA-068 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-280 ESA-067 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-279 ESA-065 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-278 ESA-056 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-277 ESA-055 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-294 JPL-001 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-293 INPE-013 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-292 INPE-012 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-291 INPE-007 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-290 INPE-006 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-289 INPE-003 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-300 JPL-009 XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-299 JPL-008 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-298 JPL-007 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-297 JPL-006 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-296 JPL-005 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-295 JPL-002 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-276 ESA-054 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-275 ESA-042 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-274 ESA-025 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-273 ESA-023 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-272 ESA-022 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-271 ESA-020 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-270 ESA-019 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-269 ESA-018 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-268 ESA-017 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-267 ESA-013 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-266 ESA-012 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-265 ESA-010 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-238 UnitSet XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-237 ArgumentType / ValidRange XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-236 Command verifiers XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-235 Verifiers XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-234 Command/Parameter XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-233 MetaCommand XTCE 1.0 XTCE 1.1 Duplicate or Merged closed
XTCE11-264 ESA-002 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-263 NASA-013 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-262 1 - Add ability to describe general equations in Calibrator area XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-261 6 - Figures 2-10 not referenced in text XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-260 5 - Expand explanatory material in Figure 1 XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-259 4 -- Add a name/short description to the argument's valid range set XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-258 Expand explanatory material for XTCE types XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-257 2 - Add Aggregate (similar to C-structure) type to XTCE XTCE 1.0 XTCE 1.1 Resolved closed
XTCE11-215 lack of clean way to describe "system variables", XTCE 1.0b1 XTCE 1.1 Resolved closed
XTCE11-214 command side seems to be missing the ability to have repeat arguments (MER) XTCE 1.0b1 XTCE 1.1 Resolved closed
XTCE11-213 lack of delta limits (MER + JWST) XTCE 1.0b1 XTCE 1.1 Resolved closed
XTCE11-212 includeCondition in commandContainer issue XTCE 1.0b1 XTCE 1.1 Resolved closed
XTCE11-211 proposed schema change for documentation issue XTCE 1.0b1 XTCE 1.1 Resolved closed

Issues Descriptions

Calibrator selection using raw value

  • Key: XTCE12-396
  • Status: closed  
  • Source: Northrop Grumman ( Joseph Vlietstra)
  • Summary:

    We use a piece-wise polynomial calibration to approximate the Steinhart-Hart equation for thermistor response.
    That is, one polynomial is used when the temperature is low (and A/D counts are high) and another polynomial is used when the temperature is high.
    The switch point between the two polynomial calibrators is expressed in raw A/D counts.

    Using a ContextCalibrator (as currently defined) doesn't help as much as one would expect. ContextCalibrator context selection can use the raw value of a parameter instance (via useCalibratedValue=false) to determine context. The problem is that a specific parameter must be referenced in the match criteria; there is no mechanism to specify/reference generic input to the calibrator. This means we need to specify a separate parameter type for each thermistor parameter in order to specify the switch point. This creates an enormous amount of redundant declarations (the polynomials and switch points are identical for each parameter type, only the name of the parameter instance is changed) and somewhat circular logic (behavior of the parameter type is dependent on the parameter instance).

    Should have a mechanism to directly reference the raw counts at the parameter type level.

  • Reported: XTCE 1.1 — Mon, 5 Dec 2016 22:15 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:
  • Updated: Tue, 6 Dec 2016 17:42 GMT

ESA-035

  • Key: XTCE11-370
  • Legacy Issue Number: 10244
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Change "provides dereference to the fact that" to "refers to the fact that"
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 06:46 GMT

9 -- Expand explanatory for certain terms, Data Type and Data Encoding Type

  • Key: XTCE11-369
  • Legacy Issue Number: 10161
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    9 – Expand explanatory for certain terms, Data Type and Data Encoding Type, in the XTCE specification (ESA-045)

    Extended in XTCE 1.1

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 06:46 GMT

6 - Add Delta Alarms to XTCE

  • Key: XTCE11-368
  • Legacy Issue Number: 10158
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    6 - Add Delta Alarms to XTCE (ESA-016)

    Delta Alarms support added in XTCE 1.1, in the ChangeAlarm area

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 06:46 GMT

ESA-052

  • Key: XTCE11-337
  • Legacy Issue Number: 10254
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Describe MatchCriteria class and how criteria are to be explicitly specified.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-051

  • Key: XTCE11-336
  • Legacy Issue Number: 10253
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Define the relationship between messages, containers and services.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-050

  • Key: XTCE11-335
  • Legacy Issue Number: 10252
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Describe all the elements shown in Figure 5.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-049

  • Key: XTCE11-334
  • Legacy Issue Number: 10251
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Replace sentence "Sequence Containers are a simple yet very powerful means define [sic] TDM
    telemetry streams (to any commutation level), packetized streams or many other package formats." with sentences moved from paragraph 2 "A SequenceContainer may represent a packet, frame, a subframe, or any other grouping/structure of data items. The simple form of a Sequence element is an ordered set of Parameter References or other Container References." Change "Sequence element" to "Sequence Container"
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-047

  • Key: XTCE11-333
  • Legacy Issue Number: 10250
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Clarify types in Figure 4.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-070

  • Key: XTCE11-347
  • Legacy Issue Number: 10264
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Modify "that provides positive indication on the successful execution of a command" to "that provides positive indication on the processing stage of a command." Modify "command completion" to "command processing". Modify "Execution" to "Executed" and "Complete" to"Succeeded". Modify "multiple completion verifiers" to "multiple command verifiers", and "completed verifiers are added" to "command verifiers are added". Clarify "All others will replace a verifier defined in a Base MetaCommand" Ideally, allow variable number of verifiers each with variable value (name).

    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-066

  • Key: XTCE11-346
  • Legacy Issue Number: 10263
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Include description of ParametersToSuspendAlarmsOnList and capabilities to initiate alarm based on command parameters.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-064

  • Key: XTCE11-345
  • Legacy Issue Number: 10262
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Describe all elements shown in Figure 9 in text.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-063

  • Key: XTCE11-344
  • Legacy Issue Number: 10261
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Precisely define each encoding type.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

NASA-007

  • Key: XTCE11-360
  • Legacy Issue Number: 10277
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    68 elements/attributes have <documentation xml:lang="en">...
    216 elements/attributes have <documentation>...
    Do you wish to specify a language or not?
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

NASA-005

  • Key: XTCE11-359
  • Legacy Issue Number: 10276
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    The <documentation> entries for parameterNameKey, parameterTypeNameKey, etc., are sentence fragments. The <documentation> for all other elements are complete sentences (with capitalization and periods).
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

NASA-003

  • Key: XTCE11-358
  • Legacy Issue Number: 10275
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    This diagram shows that NameDescriptionType is child of DescriptionType.
    This is true but no other class diagram shows this inheritance so Figure 4
    appears to be inconsistent. It may be help to have a small paragraph
    discussing the relationship between DescriptionType, NameDescriptionType, and
    OptionalNameDescriptionType near the beginning of the document.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

NASA-002

  • Key: XTCE11-357
  • Legacy Issue Number: 10274
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Phrase "containing the '/', '.', and ':' chararacters as these are reserved." is a bit stilted. Compare with phrase on Page 14 Line 1: "cannot contain spaces, '.', '/', '[' or ']' as these are
    reserved characters.".
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-011

  • Key: XTCE11-356
  • Legacy Issue Number: 10273
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    From: "… begin with a capitol letter. "

    To: "… begin with a capital letter. "
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-010

  • Key: XTCE11-355
  • Legacy Issue Number: 10272
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    It is advised that the document should properly contain, possibly, in its Section 5, the definition of the following acronyms:

    PCM (referred in: page 8 - Section 1, second paragraph)
    UTF (referred in: page 21 - annex A - section A.2),
    TDM (referred in: page 6 - Introduction, page 14 - ContainerSet and page 21 - annex A),
    SAX (referred in: page 21 - annex A),
    DOM (referred in: page 21 - annex A)
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Division symbol

  • Key: XTCE11-365
  • Legacy Issue Number: 10440
  • Status: closed  
  • Source: OS/COMET Product Group ( Brad Kizzort)
  • Summary:

    The enumerated symbol used for division in the MathOperatorsType should match the "/" used conventionally in programming languages rather than the "\".

  • Reported: XTCE 1.0 — Fri, 3 Nov 2006 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

NASA-012

  • Key: XTCE11-364
  • Legacy Issue Number: 10281
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    TYpo "... begin with a capitol letter."
    Text changes necessary. Fixed
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

NASA-011

  • Key: XTCE11-363
  • Legacy Issue Number: 10280
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    EnumerationAlarmType has <appinfo source="An additional check needs to be ..."
    The source attribute should point to URI not string.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

NASA-009

  • Key: XTCE11-362
  • Legacy Issue Number: 10279
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Typo in documentation for AutoInvert "for some number of bitss. ..."
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

NASA-008

  • Key: XTCE11-361
  • Legacy Issue Number: 10278
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Typo in documentation for QueuedVerifier "<documentation>A verifyer ..."
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-008

  • Key: XTCE11-354
  • Legacy Issue Number: 10271
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Exchange the columns of the table referenced in section 3: the first column should come naturally first, containing the name of the recommendation, and the second column should come in second place, containing the corresponding URL e-address.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-005

  • Key: XTCE11-353
  • Legacy Issue Number: 10270
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Paragraph 1

    From: "Purpose: This specification is an information model and data for spacecraft telemetry and commanding data. For a given mission … at each step in the lifecycle."
    To:
    "Purpose: This recommendation is aimed to the specification of an information model for spacecraft telemetry and commanding data. This model will allow a spacecraft operator to transition a spacecraft mission from one ground system to another by simply moving a compliant, already existing command and telemetry database to another ground system, which equally supports this same model." Dismembering the rest of the 1st. paragraph to become the second, additional paragraph, with the same original content, as:"For a given mission … at each step in the lifecycle." Original paragraph 3 :"Ideally, a spacecraft operator … telemetry database specification."is proposed to be completely deleted.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-004

  • Key: XTCE11-352
  • Legacy Issue Number: 10269
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Paragraph 1From: " This XML Telemetric and Command Exchange (XTCE) data specification answers the need for an information model and data exchange format for telemetry and commanding in all phases of the spacecraft, payload, and ground segment lifecycle: system design, development, test, validation, and mission operations." To: "This XML Telemetric and Command Exchange (XTCE) data specification presents a robust information model and data exchange format for telemetry and commanding in all phases of the spacecraft, payload, and ground segment lifecycle: system design, development, test, validation, and mission operations."
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-002

  • Key: XTCE11-351
  • Legacy Issue Number: 10268
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    From "Parameters may be or variable length." to "Parameters may be of variable length."

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-062

  • Key: XTCE11-343
  • Legacy Issue Number: 10260
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Describe all elements shown in Figure 8 in text.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-061

  • Key: XTCE11-342
  • Legacy Issue Number: 10259
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Clarify "data type" and "data encoding type" in Figure 8.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-060

  • Key: XTCE11-341
  • Legacy Issue Number: 10258
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Discuss and depict relationships between Parameter used for telemetry and Parameter used for
    command, command interlock, verifier, or parameter to set.

    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-059

  • Key: XTCE11-340
  • Legacy Issue Number: 10257
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Add definitions of parameter segment, stream segment and container segment to text.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-058

  • Key: XTCE11-339
  • Legacy Issue Number: 10256
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Describe in text all classes, associations and attributes in Figure 7.
    Fixed in the new document.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-057

  • Key: XTCE11-338
  • Legacy Issue Number: 10255
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Describe all elements of Figure 6 in text.
    Fixed in the new document.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-076

  • Key: XTCE11-350
  • Legacy Issue Number: 10267
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Describe all elements shown in Figure 10 in text
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-074

  • Key: XTCE11-349
  • Legacy Issue Number: 10266
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Describe how transmission constraints are to be explicitly specified.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-073

  • Key: XTCE11-348
  • Legacy Issue Number: 10265
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Add description of difference between a Parameter (page 17) and a ParameterToSet
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Wed, 6 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-030

  • Key: XTCE11-325
  • Legacy Issue Number: 10241
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    "Satellite commands are transmitted from the ground system directly to the spacecraft or through ground equipment." should be added
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-029

  • Key: XTCE11-324
  • Legacy Issue Number: 10240
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    "All measurements on board the spacecraft are transmitted to the ground system in a telemetry stream" should be modified to "Measurements collected on board the spacecraft may be transmitted to the ground system in a telemetry stream". "Telemetry as used here refers to these measurements whether on-board the spacecraft or transmitted to the ground system." should be modified to "Telemetry as used here refers to those measurements that are transmitted from the spacecraft directly or through ground equipment".
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-028

  • Key: XTCE11-323
  • Legacy Issue Number: 10239
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Change "This specification addresses only the definition of TM/TC data, and not the transfer of live or historical TM/TC data." to "This specification addresses only the definition of TM/TC data in the ground segment, and not the transfer of live or historical TM/TC data."

    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-027

  • Key: XTCE11-322
  • Legacy Issue Number: 10238
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    "and operation" should be appended to "The scope of this specification is limited to satellite telemetry and commanding data constructs necessary to support satellite and payload data design:"
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-024

  • Key: XTCE11-321
  • Legacy Issue Number: 10237
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Label all arrows in figure.figure 1 are not labeled.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-021

  • Key: XTCE11-320
  • Legacy Issue Number: 10236
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    "Very robust" should be deleted.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-046

  • Key: XTCE11-332
  • Legacy Issue Number: 10249
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Precisely define each encoding type.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-044

  • Key: XTCE11-331
  • Legacy Issue Number: 10248
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Clarify "string conversion specifications and calibrations."
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-043

  • Key: XTCE11-330
  • Legacy Issue Number: 10247
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Modify text to specify that parameter can be member of multiple ParameterSets.
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-037

  • Key: XTCE11-329
  • Legacy Issue Number: 10246
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Define term "anonymous type"
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-036

  • Key: XTCE11-328
  • Legacy Issue Number: 10245
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    The symbols and concepts used in the class diagrams to present the XTCE specification need to be referenced. The symbols and concepts also need to be explained (e.g. classes/objects, associations, multiplicity, aggregation, inheritance, attributes, operations).
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-033

  • Key: XTCE11-327
  • Legacy Issue Number: 10243
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    "IEEE Std 1000" should be corrected to "IEEE Std 100-1996". Also [1972] should be updated to
    [1996] : definition has not been modified. Fixed in the new document
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-031

  • Key: XTCE11-326
  • Legacy Issue Number: 10242
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Add quotes and reference to source of command definition (similar to telemetering definition above). Add reference to "CCSDS Telemetry and Commanding Packaging format".
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-003

  • Key: XTCE11-319
  • Legacy Issue Number: 10235
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Remove paragraph as defaults have been removed from the Schema
    RID STATE: FIXED

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-031

  • Key: XTCE11-318
  • Legacy Issue Number: 10234
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    1. System Engineering items, such as spacecraft mode phases, command classes/categories/themes & descriptions (i.e. this is a motor command, camera command etc)
    RID RESPONSE:
    Please revew the XTCE 'Contexts' alarms, calibrators and command area-in addition TCE Commands may be grouped by sub-system (e.g., motor, camera, etc.)
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-028

  • Key: XTCE11-317
  • Legacy Issue Number: 10233
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Future examples should demonstrate onboard EH&A and Event Reporting (EVR) translation to an XTCE compliant XML document. Telemetry contains EH&A and EVR information. This information can be translated into an XTCE compliant document when downlink is complete.EH&A is Engineering, Housekeeping and Accountability data. It is usually data from sensor XYZ (thermocouples, currents, voltages). EVR are basically ERROR/EVENT log messages. Usually these are captured in an XML file that is leveraged by ground or flight software in some way. For instance the types of events or types of EH&A data are captured in an xml file that sits on the ground and is used to parse telemetry OR this XML file is translated to C code modules that are embedded in the flight code.
    RID RESPONSE:
    This is already covered in XTCE telemetry. Please review if this is not the case. Although SOLM is on progress, and as a metamodel may accommodate further needs.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-027

  • Key: XTCE11-316
  • Legacy Issue Number: 10232
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    1. Extract common metadata and other generic items that can be reused in other CCSDS schemas, and add provisions for those that are missing (time and location representation).
    RID RESPONSE:
    The time and location issue has been discussed in RID JPL-020.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-025

  • Key: XTCE11-315
  • Legacy Issue Number: 10231
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    3. Add provisions to the command schema to accommodate flight software developers (see Section A.above) and system integrators (automatic code generation, command and code documentation).
    RID RESPONSE:
    AncillaryDataSet has been added that may help in this area-it allows for "tag/text" type descriptions to be created. However, nothing specific to flight software has been added, work in this area could be attmpted in the future however. This is also similar to JPL-019, suggest merging.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-022

  • Key: XTCE11-312
  • Legacy Issue Number: 10228
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    6. Elaborate on the "fixed" uplink bit-stream format … information from constant updates, as telemetry channel/evr/product information is changed, and unmanageably large file sizes.I think this has to do with Custom Stream sets. The concern is how does XTCE affect the file sizes of elemetry streams. Does XTCE impose an overhead on this? Using XTCE to generate telemetry stream would be interesting … is it efficient?
    RID RESPONSE:
    It would only DESCRIBE a telemetry stream and what it can describe about streams themselves is pretty minimal. Unless I misunderstand things I don't think there should be any problems here.There is no overhead imposed by XTCE, it is just the description of data..
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-021

  • Key: XTCE11-311
  • Legacy Issue Number: 10227
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    9. Ensure that all the sub-schemas have the same namespace.
    RID RESPONSE:
    Merge this with other RIDs (JPL-016, etc…) on seperating out the schema
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-020

  • Key: XTCE11-310
  • Legacy Issue Number: 10226
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    The common data definitions should be refactored to extract common metadata items that can be reused
    in other CCSDS schemas. These common metadata items are:
    A. Time formats
    a. UTC Time format
    b. Spacecraft clock (SCLK) time format
    c. Earth receive time (ERT) format
    d. GMT time format
    e. Time Period format
    B. Basic types
    C. Algorithms
    D. Units types
    E. Coordinate formats
    a. Cartesian formats for reference frame formats
    b. J2000 + other celestial body formats
    RID RESPONSE:
    None of these specific time formats are part of XTCE now, but should be definable in an valid XTCE XML document.XTCE doesn't know anything about specific formats in CCSDS and was designed to be general enough to describe them (should it fail then that's a valid criticism for schema change). If it would be helpful, CCSDS could supply base XTCE documents for those specific format for missions that could be downloaded from the CCSDS web site.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-019

  • Key: XTCE11-309
  • Legacy Issue Number: 10225
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    4. FSW information such as:
    (a) FSW command-message method name
    (b) FSW data structure mapping information
    (c) FSW enumerated data mapping information
    (d) FSW data type information
    (e) FSW argument name
    (f) FSW include file names
    RID RESPONSE:
    This is related to several other RIDs. At the moment there is nothing specific about FSW in XTCE, however AncillaryData may be useful for capturing this information.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-018

  • Key: XTCE11-308
  • Legacy Issue Number: 10224
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Monolithic Schema results in - Huge, unmanageable XML files
    RID RESPONSE:
    BUT it should be noted. XTCE doesn't require that document be MONOLITHIC. It is true that the Schema is in one document. But one can save each indiviual parameterType in your document to a separate file if that's what you wish to do. Each of those would be a valid XTCE document because much of the top-levels of the schema are optional.So, it possible split up any XTCE document into several "parts" if that's needed.It should be noted that XML does tend greatly increase the size of documents but that at the moment the large size of desktop memory for cost, seems to put this issue into something that is easily managed.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-017

  • Key: XTCE11-307
  • Legacy Issue Number: 10223
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Also, the Schema need arrays in telemetry, one option is "repeat array until end of packet". It also needs to define a type/length/value structure definition in telemetry.
    RID RESPONSE:
    This is related to JPL-005 and at least on other.XTCE has an array-type. XTCE also allows one to specify that a container parameter repeats some number of times. That number of time can be looked up in other location.However, it does not allow "Repeat until 'end of container'"-that's an interesting idea and seem like it could be easily added if there's broad consensus for its usefullness.A representive specific Schema Change would have to be developed and submitted.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-015

  • Key: XTCE11-306
  • Legacy Issue Number: 10222
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    It ignores the flight software developer as a principle user of a command and telemetry database.
    RID RESPONSE:
    "Ignores the flight software developer" is a non specific, non-constructive comment. Please recommend specific changes or enhancements.
    This is only true for certain types of missions. The scope of XTCE is clear: telemetry and
    commanding, alarms and calibrator for them, services, some (minimal) stream info and alrgorthm with a
    heavy bent towards mission ops. Flight software needs were not really formally discussed and viewed
    pretty much as out of scope.
    Future work in this area would be welcome.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-014

  • Key: XTCE11-305
  • Legacy Issue Number: 10221
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    the namespace of all space domain entities belongs to the CCSDS.
    RID RESPONSE:
    I'm not sure namespace really matters other than ensuring that it's unique Your comment about CCSDS owning all space domain entities is - to say the least - adversarial.
    The namespace was set at the OMG over five years ago.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-013

  • Key: XTCE11-304
  • Legacy Issue Number: 10220
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    15. A way to specify "meta" framing in commands

    I believe the general idea is that the metadata segment provided with the command container type could also be framed in various ways. Metadata could also contain custom information such as the command name, command priority, size of packet or any housekeeping information such as transaction IDs. My guess is that this metadata could used for command filtering, accountability and traceability and there could be layers of metadata. My reading of this is that user may want some flexibility on how to use and where to place metadata …
    RID RESPONSE:
    It will be checked again with the author. But all what has been described is covered by XTCE. How
    this is covered is in the Magenta Book, and also will be explained and followed up by Kevin.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-012

  • Key: XTCE11-303
  • Legacy Issue Number: 10219
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    14. Need repeats blocks in commands, with a length
    RID RESPONSE:
    This is the same JPL-005
    XTCE commands have the following underlying Model. Arguments are something set by a human at an "ops console". Command-parameters are set by machine. In XTCE, the repeat of Argument type isn't currently supported because of this division. If the repeat is needed, a command parameter should be defined and used for this purpose.If repeat of human-settable arguments is needed, this would be a schema change.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-011

  • Key: XTCE11-302
  • Legacy Issue Number: 10218
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    13. Not specified how to plug in external algorithms/code

    The element is <element name="CustomAlgorithm"type="xtce:InputOutputTriggerAlgorithmType"/>. The question is HOW do you plug in these external algorithms? It should be included in the tutorial.
    RID RESPONSE:
    Algorithms are explained in the Magenta Book. The explanations there will be reviewed, but the RID
    does not apply to XTCE schema.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-010

  • Key: XTCE11-301
  • Legacy Issue Number: 10217
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    12. Table lookup algorithm

    There should be more information on how to use these algorithms, what they look like (type syntax
    etc). <complexType name="AlgorithmSetType" mixed="false">
    <annotation>
    <documentation>An unordered collection of algorithms</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="CustomAlgorithm" type="xtce:InputOutputTriggerAlgorithmType"/>
    <element name="MathAlgorithm" type="xtce:MathAlgorithmType"/>
    </choice>
    </complexType>
    CATEGORY OF REQUESTED CHANGE SUPPORTING ANALYSIS RID RESPONSE:
    Algorithms are explained in the Magenta Book. The explanations there will be reviewed, but the RID
    does not apply to XTCE schema.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-001

  • Key: XTCE11-288
  • Legacy Issue Number: 10204
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    From "… be able to transition a spacecraft mission …" to "… be able to move a spacecraft mission
    …"

    RID RESPONSE:
    We believe transition a mission by moving a database reads better
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-079

  • Key: XTCE11-287
  • Legacy Issue Number: 10203
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Please remove default values. When values are not set (when it is not desirable to set them, or not useful), then they are set to default after the validation of the XTCE file. This is clearly not wanted, as it adds info that is not wanted. Please, do not put defaults everywhere, only when necessary.
    For instance, that case happens for boolean parameters, when suddenly a True/False association appears and lead to a new calibration generation because the attributes are not nul. Although in principle there is no calibration.
    RID RESPONSE:
    Closed - I withdraw this rid, this is a problem relevant to specific implentation of XML parses, schema is ok.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-078

  • Key: XTCE11-286
  • Legacy Issue Number: 10202
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    To be used within ESA projects, any data exchange mechanism shall ensure the integrity of the data that is exchanged. The proposed XTCE standard does not comply with this basic requirement and as
    such cannot be used to safely transfer data.
    RID RESPONSE:
    · XML schema provides type checking thru schema validation, may be somewhat helpful here
    · any translation should document what "falls out" if anything to another user, that seems unavoidable

    With appropriate guidelines, magenta book, and maybe one for PUS or E70-31, XTCE can be used
    without any ambiguity in the data contained.
    We don't agree with the basic assertion : "The proposed XTCE standard does not comply with this
    basic requirement (ensure the integrity of the data that is exchanged) and as such cannot be used to
    safely transfer data". We don't understand the supporting analysis "does not guarantee unicity of their
    content interpretation". If all the world used SCOS, then XTCE does not have value - all the world
    does not use SCOS. If a new schema is created for every supplier/customer contract, then we don't
    have a standard exchange format.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-077

  • Key: XTCE11-285
  • Legacy Issue Number: 10201
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Include statement of precedence between schema defined in Annex A and specification document body.
    RID RESPONSE:
    The introduction in overview states "normative portion of this specification is presented as a single
    XML schema .." 6.3 states the schema is the normative specitication. The UML is automatically generated from the schema.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-075

  • Key: XTCE11-284
  • Legacy Issue Number: 10200
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Allow variable number of significance levels each with variable value (name).
    RID RESPONSE:
    As the goal is a standard exchange, the six level of significance can be exchanged and should be sufficient This conversation has become muddled, each command can have six significance level (none, watch, distress, warning, critical, severe). Are more than six levels required? The current six map directly to
    the six levels of alarm severity.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-072

  • Key: XTCE11-283
  • Legacy Issue Number: 10199
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Explain exact meaning of verifier stages.
    RID RESPONSE:
    Related to RID-70. XTCE does not currently have any mechanism to specifiy expection reaction to a
    command that is 'interuppted'. Each verifier type is associated with a command processing 'state' and
    is explained (though with brevity) in the document.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Change service set to either accept Messages or Container references

  • Key: XTCE11-256
  • Legacy Issue Number: 10163
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    1 - Change service set to either accept Messages or Container references (ESA-004)

    Schema changed in XTCE 1.1

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

10 - Add indicator of operational status to XTCE (JPL-004)

  • Key: XTCE11-255
  • Legacy Issue Number: 10162
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    10 - Add indicator of operational status to XTCE (JPL-004)

    Not completed

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

8 - Expand explanatory material related to "Figure 3"

  • Key: XTCE11-254
  • Legacy Issue Number: 10160
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    8 - Expand explanatory material related to "Figure 3" in the non-normative part of the XTCE specification (ESA-040)

    Expanded in XTCE 1.1

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

7 - Expand explanatory material related to "Figure 2"

  • Key: XTCE11-253
  • Legacy Issue Number: 10159
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    7 - Expand explanatory material related to "Figure 2" in the non-normative part of the XTCE specification (ESA-034)

    Extended in XTCE 1.1, this is similar to ESA-039

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

5 -- Expand explanatory material related to "Figure 6"

  • Key: XTCE11-252
  • Legacy Issue Number: 10157
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    5 – Expand explanatory material related to "Figure 6" in the non-normative part of the XTCE specification (ESA-053)

    Expanded in XTCE 1.1

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

4 -- Expand explanatory material related to "Figure 4"

  • Key: XTCE11-251
  • Legacy Issue Number: 10156
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    4 – Expand explanatory material related to "Figure 4" in the non-normative part of the XTCE specification (ESA-041)

    Expanded in XTCE 1.1

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

NumericAlarmConditionTy

  • Key: XTCE11-232
  • Legacy Issue Number: 9205
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Alarms in XTCE are only available for parameters of type integer or float. In SCOS 2K, alarms
    are defined for any type of parameter. Moreover alarms in S2K can be of several types: soft limit - hard limit- delta check - status consistency (linke to relevant telemetry parameter) - event generation - or application specific. For this reason a attribute or element describing the type of the alarm (proprietary list or constrained value list) would be the best.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ToString and Booleans

  • Key: XTCE11-231
  • Legacy Issue Number: 9203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Boolean parameter can have a textual calibration in XTCE. For Boolean there is no ToString
    element but two attributes: oneStringValue and zeroStringValue. Even if this solution is
    acceptable it contradicts other textual calibrations (ToString elements) and cause problems for conversions. It is absolutely necessary to have these two attributes? Would not it be possible to use the ToString element for Boolean parameters? Moreover, for boolean parameters, the unit set is always empty it does not have any sense (a boolean can only be a flag..).

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

SplineCalibrator

  • Key: XTCE11-230
  • Legacy Issue Number: 9202
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In SCOS 2000, a calibrated value has an engineering format and a radix attached to itself.
    These concepts are not supported by XTCE. For a proper conversion it is interesting to have an engineeringFormat attribute, and a rawRadix attribute. The engineering format can be signed/unsigned integer or real. The radix is only applicable to unsigned integer parameter value and can be decimal, hexadecimal or octal.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

CalibratorType (03)

  • Key: XTCE11-229
  • Legacy Issue Number: 9201
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Calibrators (either text, polynomial or spline) may be reused between parameters, and they
    always have to be defined in relation to a parameter type. This may imply copy paste work during conversions. It should be easier and clearer to define calibrators in a separated set, at the telemetry or/and command level, and to references them when needed. This solution would have the avantage to shorten the length of the XTCE file, and avoid copy past of similar contents.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

CalibratorType (02)

  • Key: XTCE11-228
  • Legacy Issue Number: 9200
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Spline calibrators and polynomial calibrators, as well as all other calibrators should have a short description attribute for documentation and human readable information storage. A name attribute would allow to keep original calibrator ids during conversion

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

CalibratorType

  • Key: XTCE11-227
  • Legacy Issue Number: 9199
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Textual calibrations are not represented as calibrators. It would be interesting to put the textual calibrator in the same set as spline calibrator. Actually, the textual calibration is represented by a ToString element. At least this element should have a name, a short description attribute such that there will still be a possibility to recover original names. The best solution would be to integrate ToString element, enhanced with name and short description attributes, to the normal set of calibrators.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

sizeInBits

  • Key: XTCE11-226
  • Legacy Issue Number: 8928
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    sizeInBits is a an attribute in most of the parameterType elements and is an attribute that specifies the HOST SIDE storage length.

    Further into the decode area there is another sizeInBits which is the "on the wire" size ...

    Two questions really:

    1 – Does it really make sense to specify host storage sizes for a parameter? It seems to me that this is not important for exchange as long as the host can HOLD parameter, it doesn't really matter how they do it... (they may not even hold parameters in a standard built-in type in their language but use some other construct)

    2 – If the decision is made to keep it, would help to have a slight name change in one vs the other to help clarify its intended use?

  • Reported: XTCE 1.0b1 — Sat, 9 Jul 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Ref rules should be spelled out

  • Key: XTCE11-225
  • Legacy Issue Number: 8926
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Ref rules should be spelled out then! Ex. Is it legal to ref a container in the command area with one defined in telemetry? Is it legal to ref a metacommand/commandcontainer in another metacommand/commandcontainer? Is the RULE really that you add "just enough" path information to fix up name collisions in your document? OR are we forcing everyone to build all the refs with paths? What about relative paths? We should be clear as a bell on all

  • Reported: XTCE 1.0b1 — Wed, 6 Jul 2005 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Expand explanatory material related to "Figure 2"

  • Key: XTCE11-250
  • Legacy Issue Number: 10155
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    3 - Expand explanatory material related to "Figure 2" in the non-normative part of the XTCE specification (ESA-039)

    Extended in XTCE 1.1

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Expand explanatory material

  • Key: XTCE11-249
  • Legacy Issue Number: 10154
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    2 - Expand explanatory material on the differences between Telemetry and Command Parameters in XTCE (ESA-032)

    Non-normative portion of XTCE 1.1 specification extended

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

1 - move initialValue and UnitSet to ParameterSet (ESA-08)

  • Key: XTCE11-248
  • Legacy Issue Number: 10153
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Schema Change in XTCE 1.1: initialValue of type "string" created in ParameterSet area, overrides ParameterType area, format flexible for ParameterType.

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

NameType

  • Key: XTCE11-247
  • Legacy Issue Number: 9223
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Aliases, Long Description and Short Description are not available with all major data types, i.e. Calibration curve.

    For consistency all the important data types should be able to have alias, long description and short description associated to them, even if they are not all necessarily populated.
    Depending upon the database providers so rather than others will be populated

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Aliases

  • Key: XTCE11-246
  • Legacy Issue Number: 9220
  • Status: closed  
  • Source: Anonymous
  • Summary:

    : Aliases do not seem to inherit through the space-system elements like names, i.e.
    Sat1/power/bat1/voltage may have alias of 012 within the bat1 alias set and should have
    something like S1PB1012 within the system alias set, so that it is unique within the subsystem
    and whole system?

    Aliases may inherit names through the space system elements, however for this to happen
    the alias for each system element needs to be available. So an alias entry needs to be
    provided for each system-element unique in its hierachical position. I.e. B1 for battery1, P for
    Power, etc. This could be an alias list at each space system element.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

SpaceSystemType

  • Key: XTCE11-245
  • Legacy Issue Number: 9219
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Defining the model type to which space elements are applicable, i.e. SVF, EM, PFM, etc are
    not available.
    For each system element include a list where the models for which this system element are
    valid are include. All elements of that system element are then valid for all the models in the
    list (Engineering model, thermal model, flight model, system verification facility, etc).

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarification is needed on Ref names "local" to a spaceSystem

  • Key: XTCE11-224
  • Legacy Issue Number: 8925
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Clarification is need on Ref names "local" to a spaceSystem and in one area (telemetry/command) vs when crossing "bounderies". For example, is a simple name sufficient in ParameterEntryRef in the TelemetryMetaData/ContainerSet when refering to a parameter in same TelemetryMetaData/ParameterSet area? How 'bout when crossing from the command area to the telemetry area? Certainly when crossing over to another spaceSystem... ?

  • Reported: XTCE 1.0b1 — Wed, 6 Jul 2005 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Container/Argument/Stream/Type/etc

  • Key: XTCE11-223
  • Legacy Issue Number: 8924
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Container/Argument/Stream/Type/etc... – ALL refs (anything that's a sibling of NameReferenceType?) should follow the same format

  • Reported: XTCE 1.0b1 — Wed, 6 Jul 2005 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

proper reference formed weak

  • Key: XTCE11-222
  • Legacy Issue Number: 8923
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    the documentation on how a proper reference is formed is weak. As best as I can tell, the text quoted below is the ONLY place the "Unix-style" reference is mentioned in the entire XTCE document under parameterRefType. This annotation only shows up sporadically parameterRefTYpe is often extended or is an attribute.

  • Reported: XTCE 1.0b1 — Wed, 6 Jul 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

XTCE Command "Permissions" model may not be generic enough

  • Key: XTCE11-221
  • Legacy Issue Number: 8916
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    XTCE seems to mostly view command issuance from an uplink side, however MER and JWST seems to include mission phase, flight rules, ground rules and command restrictions together before a command may sent. In addition there is the concept of forbidden commands in MER which means they may never be sent. JWST has a similiar concept although in each case these forbidden commands may actual be sent somehow. XTCE may need expansion in this area.

  • Reported: XTCE 1.0b1 — Wed, 22 Jun 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JWST, non-CCSDS header commands, routing info

  • Key: XTCE11-220
  • Legacy Issue Number: 8915
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    JWST supports non-CCSDS header commanding similiar to JPL hardware commands in that they are (often) sent between processes or sub-systems onboard (precisely how this works is vague). XTCE should be able to support non-header command construction easily as it doesn't know anything about headers per se, but this needs to be verified. However capturing the ROUTING information for the command is not so clear. In the case of JPL, information is captured as to which software module should process the command (task i believe, although it may be function itself – kr).

  • Reported: XTCE 1.0b1 — Wed, 22 Jun 2005 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL MER schema supports "hardware commands

  • Key: XTCE11-219
  • Legacy Issue Number: 8914
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    JPL MER schema supports "hardware commands" which are non-CCSDS format commands between or two the low-level onboard hardware

  • Reported: XTCE 1.0b1 — Wed, 22 Jun 2005 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Variable length command packets must be supported

  • Key: XTCE11-218
  • Legacy Issue Number: 8913
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    MER allows variable length command packet at the TAIL of a packet only. XTCE seems to support variable length packets at any location and is a super set of this functionality

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

no tracking mechanism per PARAMETER for changes (no change log)

  • Key: XTCE11-217
  • Legacy Issue Number: 8912
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    no tracking mechanism per PARAMETER for changes (no change log) (MER + JWST)

    JWST uses CVS to check-in individual parameter description files, one per telemetry point. MER uses a change-log mechanism built into the Schema itself, although it does not capture the exact delta between changes. XTCE doesn't preclude the use of the former but doesnt support the latter either.

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

lack of clean way to describe multiple documentary type items

  • Key: XTCE11-216
  • Legacy Issue Number: 8911
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    lack of clean way to describe multiple documentary type items usually of the form "tag: data" in the text such as:
    SoftwareDeveloper: <your name here> (JWST+ MER)

    Compared to these two missions, XTCE seems lean on documentation areas. Allowing LongDescription to be unbounded and adding a 'name' attribute would help mitigate this issue.

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Parameters

  • Key: XTCE11-244
  • Legacy Issue Number: 9218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    At present there is no entry type available to define the complementary or redundant data. I.e. TM parameter Battery1TempA has redundancy parameter Battery1TempB, and TC
    Battery1Disconnect has complementary TC Battery1Connect.
    For Telecommands and Telemetry Parameters & Packets a list should be added where can be added the names of the redundant or complementary data related to that data. A list is needed as there might be multiple entrys of each.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

BlockMetaCommandType

  • Key: XTCE11-243
  • Legacy Issue Number: 9217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Block meta command, namely command sequences support, is not satisfactory for SCOS ASCII MIB. There is not enough details, and sequences cannot be described in XTCE.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

CommandContainer/Entry

  • Key: XTCE11-242
  • Legacy Issue Number: 9216
  • Status: closed  
  • Source: Anonymous
  • Summary:

    When building a command, SCOS has a second possiblity to set default values. Default
    values cannot be set while the command is being built (in the entry list). SCOS supports the
    following at this stage: the default value, the type of the default value (calibrated or not).

    Dynamic default values (through telemetry parameters look up) are also possible in SCOS, but cannot be represented in XTCE. To do this, a reference to a TM parameter should exist for the command argument

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Argument set

  • Key: XTCE11-241
  • Legacy Issue Number: 9215
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A spelling mistake must be corrected in the Argument Definition. It concerns ArgumentArrayType (and is actually ArgumementArrayType).

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Algorithm for derived

  • Key: XTCE11-240
  • Legacy Issue Number: 9214
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the schema it is not very clear where to add the algorithm used to compute derived
    parameters. As the derived attribute is set in parameter properties, the only place to add the algorithm is under this element. But the only reference or implementation of an algorithm in the parameter properties is under validity condition/ custom algorithm which is not really the best place. Has the derived algorithm been forgotten by the author or where is it? In relation to SCOS this is where the content of synthetic parameter is copied (the expression for the
    derivation).

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ParameterType

  • Key: XTCE11-239
  • Legacy Issue Number: 9213
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It would be great to define PUS (C-Telemetry and telecommand packet utilization, ECSS-E-70- 41A, 30 Jan 2003, chapter 23 ) parameter types and then extends these types for the need of the database. This means that there should be a way to derive parameter types, or extend them (the same concept exists already for containers). With this extension, the parameter type set would be much smaller than now and simpler to understand.
    A way to provide this is to add an attribute to a parameter type that allows to reference another parameter type.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-024

  • Key: XTCE11-314
  • Legacy Issue Number: 10230
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    4. Ensure the command schema is useful for mission operations (ingest by command sequencing engine, command scripting).
    RID RESPONSE:
    The OMG sees this addition as a separate standard
    Similar to previous RIDS. Please follow (and contribute!) to the OMG SOLM specificaton.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-023

  • Key: XTCE11-313
  • Legacy Issue Number: 10229
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    8. Include (using XML include command) all these schemas in a one container schema such as SpaceSystem.xsd
    RID RESPONSE:
    Merge this with the other RIDs (JPL-016, JPL-22) on seperating the schema
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-069

  • Key: XTCE11-282
  • Legacy Issue Number: 10198
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Interlock Scope
    DESCRIPTION OF REQUESTED CHANGE
    Modify "Interlocks are scoped to a SpaceSystem basis" to "Multiple types of interlocks can be specified, each specific to a distinct SpaceSystem state".
    RID RESPONSE:
    Related to RID-068. Proposed wording would change the meaning of interlock scope. Currently,
    XTCE Interlocks, (or Constraints, or Verifiers) do not have Context (state) differentiation.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-068

  • Key: XTCE11-281
  • Legacy Issue Number: 10197
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Delete ", but not on Command instances of this MetaCommand; Interlocks apply instead to the next command. " Modify "An Interlock will block successive commands until this command has reached a certain stage (through verifications)." to "An Interlock will block the command until a previous command has reached a certain stage (through verifications)."
    RID RESPONSE:
    The proposed wording change would change the meaning of Intelock in XTCE. The proposed changes are not what was intended to be the definition of an Interlock. The proposed definition of Interlock would be a type of TransmissionConstraint.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-067

  • Key: XTCE11-280
  • Legacy Issue Number: 10196
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Modify Figure 9 to depict relationship between interlocks and constraints.
    RID RESPONSE:
    Even though an Interlock is a type of contraint, we were unable to use this relationship in the realization of Interlock in the W3C schema and since the UML was generated automatically from the schema, this relationship does not appear in the UML. As we'd prefer to keep the UML generation completely autogenerated.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-065

  • Key: XTCE11-279
  • Legacy Issue Number: 10195
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Modify text to specify that parameter can be member of multiple ParameterSets.
    RID RESPONSE:
    Ref'ing in XTCE is liberal. That is MetaCommand in another MetaCommandSet can be Ref'd into
    another. If not this needs to be explicitly captured in terms of "Ref Scoping". The Description does
    not match the supporting analysis. There already is a MetaCommandRef in MetaCommand in MetaCommandSet.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-056

  • Key: XTCE11-278
  • Legacy Issue Number: 10194
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Remove PCM from name PCMStreamType.
    RID RESPONSE:
    XTCE does not include analog modulation schemes, but clearly does begin with PCM streams (nrzl, nrzm, nrzs, …). This is important to do because it's possible for a container etc. to include segments of streams encoded with varying PCM types.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-055

  • Key: XTCE11-277
  • Legacy Issue Number: 10193
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Delete use of word Frame in stream types.
    RID RESPONSE:
    In the context of Streams 'Frame' does have a real meaning and we do need to name Streams that are
    marked on fixed or variable boundaries with some type of 'Frame Sync Marker'
    It could be argued that frame should have been called 'Container'. Recommend new names instead of
    simply dropping 'Frame'.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-001

  • Key: XTCE11-294
  • Legacy Issue Number: 10210
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    6. Change history
    RID RESPONSE:
    SpaceSystem/Header/HistorySet provides a simple mechanism for capturing history change.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-013

  • Key: XTCE11-293
  • Legacy Issue Number: 10209
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    The summary does not contain the list of all the figures of the document.
    RID RESPONSE:
    The Table of contents was generated from the OMG template format which was in turn generated from the ISO PAS format; neither include a list of figures or tables.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-012

  • Key: XTCE11-292
  • Legacy Issue Number: 10208
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Considering the difficulty of checking the schema, it is recommended the inclusion of an additional annex for serving as a guide for its use. It is advised that such an annex could consider how the XCTE schema could, for instance, instanciate a CCSDS TM source packet file. And or, consider including some of the examples that can be drawn from the contents of the files which were pointed by the editor in his request for this review.
    RID RESPONSE:
    If an end-user decides to extend or use XTCE in a unique manner, that information will need to be
    documented for another party. Please read the support documentation of XTCE (Magenta Book and
    Green Book)
    A growing body of examples is becoming available.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-007

  • Key: XTCE11-291
  • Legacy Issue Number: 10207
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Paragraph 2, item 4, says the specification supports: Data representation definition
    Paragraph 3, item 5, says the specification does NOT supports: Data representation (visualization properties) The text does not clarify the precise meaning of data representation, in both cases. These two items, in separate, should precisely describe the difference in data representation, each of them actually are intended to support.
    RID RESPONSE:
    As a result of an earlier RID this section has already be extensively re-written.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-006

  • Key: XTCE11-290
  • Legacy Issue Number: 10206
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Delete the satellite picture inset in Figure 1, considering that the specification may be also equally applied to a Ground Equipment which, in turn, is not represented by a picture, in the same figure.
    RID RESPONSE:
    Yes, but the figure does say spacecraft or ground equipment.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

INPE-003

  • Key: XTCE11-289
  • Legacy Issue Number: 10205
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    From "… very powerful means define TDM telemetry streams…" to "… very powerful means to define TDM telemetry streams…"
    RID RESPONSE:
    This entire sentence was modified as a result from a previous RID
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-009

  • Key: XTCE11-300
  • Legacy Issue Number: 10216
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    11. Alarm on change, or on delta change (ESA-0016)
    RID RESPONSE:
    XTCE telecon: new proposal. To be accepted by KR, GS, JM
    The alarm on change is a bit general, and is then generally covered by XTCE already.
    Refer to ESA016, this one is considered duplicate of ESA016
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-008

  • Key: XTCE11-299
  • Legacy Issue Number: 10215
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    10. Would need to kludge for "fixed" area's in commands (aka not set by parameter)

    RID RESPONSE:
    This is the same RID JPL-006
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-007

  • Key: XTCE11-298
  • Legacy Issue Number: 10214
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    9. Documentation entities
    RID RESPONSE:
    There are several documenation entities in XTCE, LongDescription, shortDescription, AncillaryDataSet, and Header all provide opportunties to document items.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-006

  • Key: XTCE11-297
  • Legacy Issue Number: 10213
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    8. Fill arguments
    RID RESPONSE:
    Fill can be specified by using the BinaryParameterType or BinaryArgumentType to specify a fixed size block of bits, and that block can be referenced in the container (thru parameter/argument) as is necessary to specify a fill area.
    Closed by AO
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-005

  • Key: XTCE11-296
  • Legacy Issue Number: 10212
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    7. Repeated arguments
    RID RESPONSE:
    This needs to be combined with another RID of similar issue. In XTCE, arguments are deemed as input from the user. The command parameter is machine set. Command parameters are repeatable, but arguments are not. If you need to repeat something on the command-size, use the parameters in that section to defined them and then use the RepeatEntry element in EntryList/ParameterRef/RepeatEntry to specify repeats.
    Closed by AO
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

JPL-002

  • Key: XTCE11-295
  • Legacy Issue Number: 10211
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    2. Definition of all the legal Spacecraft IDs

    The spacecraft id or SCID is an integral part of most space databases. Is there an element for this in XTCE? I can't seem to find it. Also what if someone wants to use a SCID that is already taken? XTCEcould have a documentation note for users to check a list hosted by CCSDS???
    RID RESPONSE:
    Spacecraft IDs are perfectly accomodated in the SpaceSystem's AliasSet. Even more than one spacecraft id can be accomodated in the AliasSet. The correct namespace has to be used and can SpacecraftID1, SpacecraftID2 and so o
    it reflects current information etc. The current tag author, name, date, comments etc. I think FSW also
    .
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-054

  • Key: XTCE11-276
  • Legacy Issue Number: 10192
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Correct inconsistencies between StreamSetType in Figures 3 and 6.
    RID RESPONSE:
    We believe they do match. Figure 6 simply has its aggregation shown as separate classes rather than attributes.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-042

  • Key: XTCE11-275
  • Legacy Issue Number: 10191
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Include AlarmLimitSet
    RID RESPONSE:
    Covered by the magenta book.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-025

  • Key: XTCE11-274
  • Legacy Issue Number: 10190
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Change caption from "Telemetric and Command Processing Meta Data Encapsulated in XTCE XML" to "Telemetric and Command Ground Processing Meta Data Encapsulated in XTCE XML"
    RID RESPONSE:
    See remark in ESA-23
    Recommend not changing as telemetric and command processing DO NOT have to be performed on
    the ground.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-023

  • Key: XTCE11-273
  • Legacy Issue Number: 10189
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Change "XTCE provides a standard format for defining the Telemetric and Telecommand (TM/TC) data required to perform the processing shown in figure 1." to "XTCE provides a standard format for defining the Telemetric and Telecommand (TM/TC) data required to perform the ground processing shown in Figure 1."
    RID RESPONSE:
    While the processing depicted is normally accomplished on the ground, it does not have to be - consider a space station controlling another space asset.
    Recommend not changing as telemetric and command processing DO NOT have to be performed on
    the ground.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-022

  • Key: XTCE11-272
  • Legacy Issue Number: 10188
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    Change "Interface design to satellite systems" to "Ground interface design to satellite systems"
    RID RESPONSE:
    Recommend not changing as telemetric and command processing DO NOT have to be performed on
    the ground.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-020

  • Key: XTCE11-271
  • Legacy Issue Number: 10187
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    An analysis is on-going for two satellites database (Metop and Herschel-Planck) and more RIDs are expected in the next weeks.
    RID RESPONSE:
    Status: comment, Closed
    Boston: close
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-019

  • Key: XTCE11-270
  • Legacy Issue Number: 10186
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    The support of command sequences is not satifactory for ESA, and ESA would like to have command sequences in XTCE. Is there any work ongoing on that side for XTCE, or is it intended to leave complicated command sequences (Block Meta Command) out of XTCE. ESA could propose a model for the command sequence support.
    RID RESPONSE:
    Yes, in fact the OMG/SDTF is currently reviewing a proposed specification for a very robust command sequence model. This model would augment XTCE. Recommend closure.
    Status: reviewd and closed
    Type: Schema Change

    Boston. No changes to XTCE.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-018

  • Key: XTCE11-269
  • Legacy Issue Number: 10185
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    As a valid range set has been introduced instead of one unique range, it is now needed to have a validity condition that tells if the current range is applicable or not.
    RID RESPONSE:
    Conceivably, valid range could change with context, however, this seems obscure enough that the RTF
    should consider whether the additional schema complexity is worth the cost. Recommend Deferral.
    [ESA] withdraw, this is being addressed
    Boston: close
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-017

  • Key: XTCE11-268
  • Legacy Issue Number: 10184
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    DESCRIPTION OF REQUESTED CHANGE
    It is from our side believed that delta-check alarms and expected state check alarms are sufficiently generic and well spread to be included in XTCE. Therefore we ask to add the following type of alarm; expected check alarm with the following data:
    · Validity condition (to know if the test is applicable)
    · A list of expected values
    · As required in JM-013, a label to indicate the activity triggered by a positive alarm

    [Ian] can you check is that can match to the ParameterToSetList in the MetaCommand element. What is missing for me is the reporting data referenced (namely where to find the parameter name to be setted by the telecommand). If this does the job then no RID to be raised.
    RID RESPONSE:
    [ESA] on ESA side, this is covered by StaticAlarmRange
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-013

  • Key: XTCE11-267
  • Legacy Issue Number: 10183
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    ECSS E70-31 has dedicated table to create generic commands. In particular for CPDU, On/off devices, register loads and sensors data. Although dedicated commands could be written down as a whole, they may be sufficiently generic to be included in XTCE. From another point of view, with a good reuse of command structure, such commands can be easily formatted in XTCE. However some defaults values like cpdu duration units and cpdu max instr will have to fit somewhere. The best place would be at the space system default level (currently this kind of information could only fit in the space system ancillary data set.).
    RID RESPONSE:
    Discuss. Recommend creating a base command from which specific commands are inherited.
    [ESA] ok with Gerry response
    Jennifer/Kevin/Gerry-reviewed, agree
    Boston: close

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-012

  • Key: XTCE11-266
  • Legacy Issue Number: 10182
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    The MAP ID is situated in the segment (packet application data field). In ECSS there is a need for associating a label to the value of the MAP ID, describing the priority of it. In XTCE while describing a container, which could include the parameter MAP ID there is only the possiblity to include the value of the MAP itself (1-64). We would like to add the label high priority, low priority with the
    MAP ID.
    In ECSS, there is a list of MAP id associated to APID, with default MAP for such a process. This data can be recovered from browsing through all containers and extracting apid, map id values. But maybe a simpler way must exist?
    Jennifer/Kevin/Gerry-reviewd, agree
    Gerry recommends using AncillaryData. Close/No-change.
    Boston: close
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-010

  • Key: XTCE11-265
  • Legacy Issue Number: 10181
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    In SCOS-2000 calibrations curves are allowed to be described by one point only. In XTCE, a spline is
    obviously defined by two points miminum. Please relax the constraint to two points
    RID RESPONSE:
    [ESA] close, withdraw
    Boston: agree close
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UnitSet

  • Key: XTCE11-238
  • Legacy Issue Number: 9212
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The parameter unit in XTCE is attached to the parameter type. In SCOS, it is not easily
    possible to define them here and it would be easier to place the unit in the parameter definition (because SCOS uses PUS based parameter types). With the unit in the parameter properties, the parameter type set will be shorter, and would then describe only PUS parameter types for example. Actually there is one parameter type per parameter instance, which is not ideal

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ArgumentType / ValidRange

  • Key: XTCE11-237
  • Legacy Issue Number: 9211
  • Status: closed  
  • Source: Anonymous
  • Summary:

    XTCE allows a single valid vange for argument value. SCOS 2K allows multiple valid ranges
    for argument values and these cannot be represented in XTCE. For example, if there are two discrete ranges for the argument then XTCE fails to represent this.
    Moreover in SCOS, range set are caracterized by a name, a short description, a flag
    identifying the expression used (calibrated or not), a radix (flag identifying the radix used for the range values specified in value list, applicable for unsigned integer values, can be decimal - hexadecimal or octal)

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Command verifiers

  • Key: XTCE11-236
  • Legacy Issue Number: 9210
  • Status: closed  
  • Source: Anonymous
  • Summary:

    SCOS 2K allows tolerance (range check) during the command verification check. The tolerance check is not supported by XTCE. Basically a plus/minus value added to the value to be checked is the tolerance valid range. This can be represented in XTCE either by a valid range (that exists already for other elements, with min and max values) or by a unique attribute (tolerance) that will be added or deduced to/from the value to check.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Verifiers

  • Key: XTCE11-235
  • Legacy Issue Number: 9209
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Command verifiers should have name and short attributes if possible. They could even be
    defined in a set, and integrated into a command through the use of references (this would even be faster and shorten the length of XTCE, and improve XTCE reuse as well). Those fields are needed because in SCOS 2K verifiers are labelled with a description and an id (ie. Name).

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Command/Parameter

  • Key: XTCE11-234
  • Legacy Issue Number: 9208
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is possible to set a default value (i.e. initial value) for a command parameter in XTCE, but in SCOS 2K, the default value is sometime expressed in the engineering format. And XTCE
    does not support the engineering format for the default value. XTCE should allow default value in engineering (calibrated) format and give a way to deduce the format of the default value

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

MetaCommand

  • Key: XTCE11-233
  • Legacy Issue Number: 9207
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A TC & TM database may contain specific information about telecommands. In particular, the source of the telecommand can be indicated (like if it has been produced by a planning software or smth else).

    SCOS has a flag to say if the current command can be executed alone, manually, or only as
    part of a command sequence. This flag cannot be translated in XTCE.
    The priority of the command cannot be represented (only the criticality). This is a new potential attribute for the metacommand element

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ESA-002

  • Key: XTCE11-264
  • Legacy Issue Number: 10180
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    For each system element include a list where the models for which this system element are valid are include. All elements of that system element are then valid for all the models in the list (Engineering model, thermal model, flight model, system verification facility, etc). These models relate to the various developments of the final satellite. The Flight model is the complete satellite ready for launch, however there will be a number of engineering models, development models, breadboards and test facilities that are also built and tested during the satellite development and require a database exchange. These databases can be sent individually in a self contained database, or can be sent combined in a mission database which therefore needs the means to differentiate between what is valid for what model. This is further complicated with onboard software versioning which can also be included in the model list.
    RID RESPONSE:
    Recommend simply using SpaceSystem name attribute or XML file name to separate models.
    According to another RID, a tag will be added at the space system level for the operational level of the
    system (testing, operational, etc..)
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

NASA-013

  • Key: XTCE11-263
  • Legacy Issue Number: 10179
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Summary of Close RIDs
    NASA-013: The non normative document (accompanying text) must stipulate the following: The use of XTCE is advocated as being appropriate for data exchange across organizational or product boundaries, but is not required to be adopted as a recommended practice for the internal technical specification of command or telemetry data dictionaries or data streams within a particular system or product
    RID RESPONSE:
    The OMG cannot mandate the use of any specification - all OMG specifications are recommendations.
    We suggest that this language be place in the XTCE Green book or Magenta book.
    RID STATE: CLOSE

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

1 - Add ability to describe general equations in Calibrator area

  • Key: XTCE11-262
  • Legacy Issue Number: 10178
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Summary of Non-RID Requests

    1 - Add ability to describe general equations in Calibrator area

    General MathOperationCalibrator added to Calibration area, MathOperationType changed to support equations, effects other areas of schema where "MathOperation"s are used

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

6 - Figures 2-10 not referenced in text

  • Key: XTCE11-261
  • Legacy Issue Number: 10168
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    6 - Figures 2-10 not referenced in text (INPE-009)

    References inserted in XTCE 1.1

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

5 - Expand explanatory material in Figure 1

  • Key: XTCE11-260
  • Legacy Issue Number: 10167
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    5 - Expand explanatory material in Figure 1 (ESA-026)

    Expanded in XTCE 1.1

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

4 -- Add a name/short description to the argument's valid range set

  • Key: XTCE11-259
  • Legacy Issue Number: 10166
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    4 – Add a name/short description to the argument's valid range set (ESA-011)

    Added OptionalNameDescriptionType to support this in XTCE 1.1

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Expand explanatory material for XTCE types

  • Key: XTCE11-258
  • Legacy Issue Number: 10165
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    3 - Expand explanatory material for XTCE types ParameterToSet and MetaCommand/Verifiers (ESA-071)

    Expanded in XTCE 1.1

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

2 - Add Aggregate (similar to C-structure) type to XTCE

  • Key: XTCE11-257
  • Legacy Issue Number: 10164
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    2 - Add Aggregate (similar to C-structure) type to XTCE (ESA-014)

    Schema support added in XTCE 1.1, see AggregrateType in ParameterType area

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

lack of clean way to describe "system variables",

  • Key: XTCE11-215
  • Legacy Issue Number: 8910
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    lack of clean way to describe "system variables", typically flags for tuning of T&C system processing (JWST, some MER)

    System specific tunable variables that are not telemetry, often simple boolean switches

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

command side seems to be missing the ability to have repeat arguments (MER)

  • Key: XTCE11-214
  • Legacy Issue Number: 8906
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    CommandContainerSet does not have argumentRefEntry

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

lack of delta limits (MER + JWST)

  • Key: XTCE11-213
  • Legacy Issue Number: 8905
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Delta limits compare deltas between instances of a parameter and issue an alarm outside a certain threshold

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

includeCondition in commandContainer issue

  • Key: XTCE11-212
  • Legacy Issue Number: 8885
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    In metacommand container/commandContainer - the includeCondition only allows parameterRef, it should also allow argumentRef.

    Here is an example from a simulated MER command that uses either an ARM or Elbow argument depending on the proceeding argument which is the motor_id... the arguments are different units as well.


    <CommandContainer name="CMD-MOTOR_Container">
    <EntryList>
    <ArgumentRefEntry argumentRef="motor_id"/>
    <ArgumentRefEntry argumentRef="distanceArm">
    <IncludeCondition>
    <Comparison parameterRef="motor_id" value="0"/>
    </IncludeCondition>
    </ArgumentRefEntry>
    <ArgumentRefEntry argumentRef="distanceElbow">
    <IncludeCondition>
    <Comparison parameterRef="motor_id" value="1"/>
    </IncludeCondition>
    </ArgumentRefEntry>
    </EntryList>
    </CommandContainer>

  • Reported: XTCE 1.0b1 — Tue, 28 Jun 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

proposed schema change for documentation issue

  • Key: XTCE11-211
  • Legacy Issue Number: 8875
  • Status: closed  
  • Source: NASA ( Kevin Rice)
  • Summary:

    JPL MER & JWST schemas have numerous ways to capture various types of documentation – these include but are not limited to developer information, flight software information, document info and so forth. At this time XTCE has a LongDescription and ShortDescription and a few specialized areas of documentation – that are simply not sufficient to capture the full scope of info held in the other schemas. While it would be nice to specifically put elements into XTCE to allow the capture of this information in a formal way, there is at this time no agreement on what that would exactly be.

    Most of the information in question is of the form "tag: data" – where the tag is simply the label for the data – such as "Developer: T.Hacker". As such a simpler solution at the moment would be to extend the XTCE LongDescription to be unbounded and add an attribute to it to hold the tag information. Because this element is part of a base type in XTCE used by most of the major types – it will give users a large number of areas in which to capture their varied documentation. In time as agreement is reached on specific types of documentation, the schema can be extended more formally..

    — Proposed Schema change to XTCE —

    <element name="LongDescription" minOccurs="0" maxOccurs="unbounded">

    <annotation>

    <documentation>The Long Description is intended to be used for explanitory descriptions of the object and may include HTML markup. Long Decriptions are of unbounded length. Multiple long descriptions may be used to hold tagged information.</documentation>

    </annotation>

    <complexType>

    <simpleContent>

    <extension base="string">

    <attribute name="name" type="string"/>

    </extension>

    </simpleContent>

    </complexType>

    </element>

  • Reported: XTCE 1.0b1 — Thu, 23 Jun 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT