XML Telemetric & Command Exchange Format Avatar
  1. OMG Specification

XML Telemetric & Command Exchange Format — Open Issues

  • Acronym: XTCE
  • Issues Count: 83
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
XTCE12-502 Usage of readOnly is not clear per documentation XTCE 1.0 open
XTCE12-1 TimeAssociation should be settable at the Container XTCE 1.0 open
XTCE12-416 Member location within AggregateDataType XTCE 1.0 open
XTCE12-6 ContainerType issue XTCE 1.0 open
XTCE12-7 toString/NumberFormat needs default settings XTCE 1.0 open
XTCE12-5 initialValue attribute only exists for a ParameterType or ArgumentType XTCE 1.0b1 open
XTCE12-4 CommandContainer under the MetaCommand XTCE 1.0b1 open
XTCE12-3 Package Identification: MessageKeys or Inheritance XTCE 1.0b1 open
XTCE12-2 CommandContainer issue XTCE 1.0b1 open
XTCE12-162 MS-003 Meaning not clear. XTCE 1.0 open
XTCE12-188 HVM-004 Data Encoding definitions XTCE 1.0 open
XTCE12-158 Should use type[FixedFrameSyncStrategyType] in type [FixedFrameStreamType] XTCE 1.0 open
XTCE12-160 V-003 Schema file identification XTCE 1.0 open
XTCE12-161 DC-013 Parameter encoding information XTCE 1.0 open
XTCE12-159 MS-001 Missing page numbering XTCE 1.0 open
XTCE12-155 MM-001 What missions need XTCE 1.0 open
XTCE12-156 MP-001 Terminology XTCE 1.0 open
XTCE12-154 TH-001 Some Typos XTCE 1.0 open
XTCE12-157 MK-005 Should use type[ContextCalibratorType] in … XTCE 1.0 open
XTCE12-150 OnBoard Software XTCE 1.0 open
XTCE12-152 CalibratorType XTCE 1.0 open
XTCE12-151 Section: 7 XTCE 1.0 open
XTCE12-153 MK-002 Type of element[MessageRef] is undefined XTCE 1.0 open
XTCE12-146 6 - Add ToString to Boolean or remove Boolean in favor of Enumerated Types XTCE 1.0 open
XTCE12-145 - Add separate CalibratorSet to XTCE XTCE 1.0 open
XTCE12-147 1 - Support ability to describe redundant or complimentary data XTCE 1.0 open
XTCE12-148 OnBoard Memory XTCE 1.0 open
XTCE12-149 CommandContainerType XTCE 1.0 open
XTCE12-141 8 - Add activity field to Alarms to indicate what the alarm will trigger XTCE 1.0 open
XTCE12-144 5 - Align XTCE and CCSDS Navigation Schemas (types) XTCE 1.0 open
XTCE12-143 4 - Separate XTCE Schema into constituent parts XTCE 1.0 open
XTCE12-142 3 - Use UML Instance diagrams for XTCE document example XTCE 1.0 open
XTCE12-138 9 - Add filtering of value threshold to maintain telemetry at certain rates XTCE 1.0 open
XTCE12-140 7 - Use UUIDs instead of current XTCE Referencing mechanism XTCE 1.0 open
XTCE12-173 DC-027 Line 3 XTCE 1.0 open
XTCE12-174 DC-032 Line 3 XTCE 1.0 open
XTCE12-178 DC-034 Line 10 XTCE 1.0 open
XTCE12-175 DC-018 Line 10 XTCE 1.0 open
XTCE12-177 DC-029 Line 1 XTCE 1.0 open
XTCE12-180 DC-011 Figure text. XTCE 1.0 open
XTCE12-182 DC-005 Figure XTCE 1.0 open
XTCE12-184 DC-025 Encoding information XTCE 1.0 open
XTCE12-183 DC-026 Encoding area XTCE 1.0 open
XTCE12-190 DC-017 Assembly / dissembly information. XTCE 1.0 open
XTCE12-191 DC-028 ArgumentList XTCE 1.0 open
XTCE12-195 "Parameter Processing" box XTCE 1.0 open
XTCE12-198 "Foreword", line 2. XTCE 1.0 open
XTCE12-166 DC-033 Line 6 XTCE 1.0 open
XTCE12-168 DC-024 Line 6 XTCE 1.0 open
XTCE12-167 DC-030 Line 5 XTCE 1.0 open
XTCE12-169 DC-016 Line 4. XTCE 1.0 open
XTCE12-171 DC-020 Line 4 XTCE 1.0 open
XTCE12-170 DC-008 Line 4 XTCE 1.0 open
XTCE12-176 DC-010 Line 1 XTCE 1.0 open
XTCE12-186 DC-021 Assembly / dissembly of streams XTCE 1.0 open
XTCE12-200 DC-004 "Philosophy", line 2 XTCE 1.0 open
XTCE12-164 DC-012 Line 5 XTCE 1.0 open
XTCE12-181 DC-015 Figure label. XTCE 1.0 open
XTCE12-163 MP-004 Logarithmic calibrations XTCE 1.0 open
XTCE12-179 MS-006 Footing of Figure 1 is missing. XTCE 1.0 open
XTCE12-185 MP-007 Dynamic telemetry check types XTCE 1.0 open
XTCE12-189 MS-009 De-calibration of cmd parameters? XTCE 1.0 open
XTCE12-172 DC-023 Line 3. XTCE 1.0 open
XTCE12-165 DC-009 Line 6 XTCE 1.0 open
XTCE12-187 MK-007 Don't need element[ChangePerSecondAlarmConditions] XTCE 1.0 open
XTCE12-192 MK-010 All ParameterType and ArgumentType should have alarm element XTCE 1.0 open
XTCE12-208 lack of Union construct (MER + ASIST) XTCE 1.0b1 open
XTCE12-209 XTCE issue: dimensionList in arrayParameterRef should be optional XTCE 1.0b1 open
XTCE12-210 inability to describe sets of limits (alarms) and conversions (polynomials) XTCE 1.0b1 open
XTCE12-211 repeat of arguments issue XTCE 1.0b1 open
XTCE12-212 XTCE issue - add shortDescription to EntryList entries XTCE 1.0b1 open
XTCE12-193 AO-006 Additional examples (2) XTCE 1.0 open
XTCE12-194 MK-003 A mistake of type[ContainerSegmentRefEntryType]'s annotation XTCE 1.0 open
XTCE12-199 MK-001 A mistake of attribute[messageRef]'s annotation XTCE 1.0 open
XTCE12-196 "Foreword", 2nd last line XTCE 1.0 open
XTCE12-197 Contents" XTCE 1.0 open
XTCE12-202 "Command Processing" box XTCE 1.0 open
XTCE12-201 Spec too complex? XTCE 1.0 open
XTCE12-203 USE CCSDS examples how to use the standard XTCE 1.0 open
XTCE12-206 too much leeway how to use the standard XTCE 1.0 open
XTCE12-204 Propose that XCTE ( at this point ) will be limited to exchange data XTCE 1.0 open
XTCE12-205 Xpath: XTCE 1.0b1 open
XTCE12-207 command side unable to describe "packed commands" XTCE 1.0b1 open

Issues Descriptions

Usage of readOnly is not clear per documentation

  • Key: XTCE12-502
  • Status: open  
  • Source: Real Time Logic Inc. ( Justin Boss)
  • Summary:

    Documentation of readOnly attribute says the following per XTCE 1.1:
    A Parameter marked as 'readOnly' true is constant and non-settable

    It is not clear if this is intended to include "is constant". Constants should be defined per the dataSource property with a value of "constant" per the dataSource property's documentation.

    It is not clear if a readOnly item is settable by any means (even the C2 software itself) or is it just read-only to any clients or external applications.

    If it is intended to only influence clients and external applications, the documentation should be updated to be:
    A Parameter marked as 'readOnly' true is non-settable

  • Reported: XTCE 1.0 — Thu, 21 Dec 2017 20:36 GMT
  • Updated: Thu, 4 Jan 2018 18:16 GMT

TimeAssociation should be settable at the Container

  • Key: XTCE12-1
  • Legacy Issue Number: 14464
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Description Kevin Rice 2007-10-22 21:34:53 BST
    Time Association needs to apply to any parameter in a Packet/Container. The
    XTCE parameter/parameterproperties/timeassociation can be used to capture an
    "offset" time from a packet time stamp. In CCSDS world, most telemetry
    packets are time stamped – and sometimes those time stamps are adjusted by
    some offset or delta for each telemetry parameter in the packet (in effect each
    parameter is timetagged). Since the same parameter may exist in more than one
    packet and have different offsets – the XTCE approach is limiting in this
    regard since only one offset can captured per parameter, not at the
    packet/container level. XTCE should modify its container entryList area so
    that TimeAssociation can be captured per packet entry.

  • Reported: XTCE 1.0 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Sun, 19 Nov 2017 00:25 GMT

Member location within AggregateDataType

  • Key: XTCE12-416
  • Status: open  
  • Source: Northrop Grumman ( Joseph Vlietstra)
  • Summary:

    AggregateDataType assumes each member immediately follows the previous member in the telemetry stream (no gaps). If there are unused bits in the stream, a dummy parameter must defined to account for the unused bits.

  • Reported: XTCE 1.0 — Tue, 10 Jan 2017 21:45 GMT
  • Updated: Thu, 6 Apr 2017 00:55 GMT

ContainerType issue

  • Key: XTCE12-6
  • Legacy Issue Number: 7659
  • Status: open  
  • Source: Command and Control Technologies ( Greg Hupf)
  • Summary:

    ContainerType needs optional SizeInBits element to support calculating locations of list entries that use the end of the container (e.g. referenceLocation="containerEnd"). Note that an IntegerValueType element is preferred over an integer attribute since it supports fixed, dynamic and conditional values.

  • Reported: XTCE 1.0 — Tue, 24 Aug 2004 04:00 GMT
  • Updated: Thu, 6 Apr 2017 00:55 GMT

toString/NumberFormat needs default settings

  • Key: XTCE12-7
  • Legacy Issue Number: 14497
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Description Kevin Rice 2008-03-20 19:13:40 GMT
    toString/NumberFormat - element is required if toString is in use. Almost all
    attributes are optional but defaults should be

    provided for "most common" likely format...

  • Reported: XTCE 1.0 — Thu, 17 Sep 2009 04:00 GMT
  • Updated: Fri, 13 Jan 2017 00:40 GMT

initialValue attribute only exists for a ParameterType or ArgumentType

  • Key: XTCE12-5
  • Legacy Issue Number: 7981
  • Status: open  
  • Source: Real Time Logic Inc. ( Gerry Simon)
  • Summary:

    . In version 1.11 of the schema there was an initialValue attribute for a
    Parameter in the ParameterSet but this was removed in 1.12. Now the
    initialValue attribute only exists for a ParameterType or ArgumentType. I
    think it would make more sense if the initialValue was a Parameter attribute
    and not a ParameterType attribute since there could be multiple instances of
    the same ParameterType. Right now each of these instances would have the
    same initialValue but I think what you really want is for each instance to
    be able to define its own intialValue if it has one. Right now if you have
    a Type but you want to have different initalValues for it you have to create
    multiple Types and I think this makes more work than is really necessary.

    Noted. I think this is going to be an ongoing debate amoung XTCE
    enthusiasts. Right now the Parameter in ParameterSet is very simple; it is
    not 'type' aware. One of the problems we'd have in giving it an initial
    value is that we couldn't type check it by the XML validator. Because
    ParameterType in ParameterTypeSet knows it's type it can type check (i.e.,
    the initialValue for an IntegerParameterType will only accept an integer,
    the initialValue for a StringParameterType accepts a string ...).

  • Reported: XTCE 1.0b1 — Wed, 15 Dec 2004 05:00 GMT
  • Updated: Sat, 22 Oct 2016 00:26 GMT

CommandContainer under the MetaCommand

  • Key: XTCE12-4
  • Legacy Issue Number: 7979
  • Status: open  
  • Source: Real Time Logic Inc. ( Gerry Simon)
  • Summary:

    In the CommandContainer under the MetaCommand, inside the EntryList,
    there is a division between groupings of the Parameter/ContainerRefEntries
    and the FixedValue/ArgumentRefEntries. The problem is what this does is
    make you have to define ALL your ParameterRefEntries and ContainerRefEntries
    BEFORE defining any FixedValues or ArgumentRefs inside a CommandContainer.
    For example, the following sequence of entries would be illegal for a
    CommandContainer:
    FixedValueEntry-ContainerRefEntry-ParameterRefEntry-ArgumentRefEntry.
    Unless there is a legitimate reason for the separation, I think the
    FixedValueEntry and the ArgumentRefEntry needs to be added to the same
    grouping that the ParameterRefEntry/ContainerRefEntry is in.

    You're probably right. We simply extended the EntryListType to create a
    CommandEntryList type. While this keeps the schema simpler, it does make
    the XML documents messier. We usually opt for better XML over better
    Schema.

  • Reported: XTCE 1.0b1 — Wed, 15 Dec 2004 05:00 GMT
  • Updated: Sat, 22 Oct 2016 00:26 GMT

Package Identification: MessageKeys or Inheritance

  • Key: XTCE12-3
  • Legacy Issue Number: 8057
  • Status: open  
  • Source: Real Time Logic Inc. ( Gerry Simon)
  • Summary:

    We have discussed two different methods for the identification of container instances: Inheritance and a Combination of Message Key and Choice. The schema now allows for either, but could be simplified by eliminating one or the other. Lockheed recommends eliminating the MessageKey method in favor or inheritance.

  • Reported: XTCE 1.0b1 — Fri, 31 Dec 2004 05:00 GMT
  • Updated: Sat, 22 Oct 2016 00:26 GMT

CommandContainer issue

  • Key: XTCE12-2
  • Legacy Issue Number: 7980
  • Status: open  
  • Source: Real Time Logic Inc. ( Gerry Simon)
  • Summary:

    Another question involving the CommandContainer. In the CommandMetaData
    there are two ways to create a CommandContainer: inside a MetaCommand or
    inside the CommandContainerSet. For some reason the CommandContainer inside
    the MetaCommand has an ArgumentRefEntry and a FixedValueEntry but the
    CommandContainer inside the CommandContainerSet does not. The reason they
    are different is that the CommandContainer inside the MetaCommand is of
    CommandContainerType, but the CommandContainer inside the
    CommandContainerSet is of SequenceContainerType. Is this an error in the
    schema or is there a reason that these CommandContainers are of different
    types?

    The reason why there's a CommandContainer inside the CommandContainerSet is
    so containers that are used/re-used by many commands could be defined there.
    Since these Containers are not associated with any particular MetaCommand
    and arguments are local to a MetaCommand, it would be a mistake to allow
    them to contain arguments - we wouldn't know which argument to use.

  • Reported: XTCE 1.0b1 — Wed, 15 Dec 2004 05:00 GMT
  • Updated: Sat, 8 Oct 2016 00:25 GMT

MS-003 Meaning not clear.

  • Key: XTCE12-162
  • Legacy Issue Number: 9064
  • Status: open  
  • Source: Anonymous
  • Summary:

    Source: Michael Staub michael.staub@dlr.de
    Description : Reword: "The space industry is fragmented between Packet telemetry

    and
    commanding and Time Division Multiplexing (TDM) telemetry and commanding."
    Resolution:
    Title: MS-001 Missing page numbering
    Source: Michael Staub michael.staub@dlr.de
    Description : Add page numbering to document.

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

HVM-004 Data Encoding definitions

  • Key: XTCE12-188
  • Legacy Issue Number: 9038
  • Status: open  
  • Source: es ( Hans van der Meij)
  • Summary:

    Source: Hans.van.der.Meij Hans.van.der.Meij@es
    Description : In a number of places in the schema it is possible to define similar/equal properties
    of a parameter type.

    E.g. for an IntegerParameterType definition, the sizeInBits and the signed-ness
    can be be defined as attributes, and it is possible to define this type of information
    in the IntegerDataEncoding child.

    Please clarify which is the preferred way to specify this type of information and
    what is provided by XTCE to avoid ambiguities and inconsistencies.

    In any case, it is recommended to either update the specification to take out the
    flagged redundancies or to update the text to clearly define the intended use.
    Resolution: The document will be edited to clarify the differences between the two proprieties.
    The Integer parameter type describes how to handle the parameter in the ground
    software, while the Encoding integer type describes how the parameter is encoded
    in either the TM or TC.

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

Should use type[FixedFrameSyncStrategyType] in type [FixedFrameStreamType]

  • Key: XTCE12-158
  • Legacy Issue Number: 9069
  • Status: open  
  • Source: Anonymous
  • Summary:

    Source: Makoto Kawai kawai.makoto@jaxa.jp
    Description : Currently, the definition of element[SyncStrategy] in type

    [FixedFrameStreamType]
    is described by complexContent. To make the structure more simple, I
    recommend to use type[FixedFrameSyncStrategyType] in
    type[FixedFrameStreamType].

    From: "<element name="SyncStrategy"> ... </element>" To: "<element
    Resolution: Agree (with discussion). Suggest instead simply deleting
    FixedFrameSyncStrategyType (since it is would be used at most once).

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

V-003 Schema file identification

  • Key: XTCE12-160
  • Legacy Issue Number: 9067
  • Status: open  
  • Source: Anonymous
  • Summary:

    Source: Gert Villemos gev@terma.com
    Description : The schema file should be clearly identifiable, i.e. the XTCE

    document version
    referenced and/or the schema file version number changed.
    Resolution: Add version number to document

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

DC-013 Parameter encoding information

  • Key: XTCE12-161
  • Legacy Issue Number: 9066
  • Status: open  
  • Source: Anonymous
  • Summary:

    ource: D.Campbell dave.campbell@scisys
    Description : Lines 5-7. What is the information which states how encoding should

    be
    performed? The text mentions the "Encoding area" - where / what is this? What
    constraints are there / what documents specify how the encoding is to be
    performed? Should this information be included in this standards document?
    Different agencies may misinterpret how to use the encoding information unless its
    use is also standardised in some document.
    Resolution: Add clarifications to the text

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

MS-001 Missing page numbering

  • Key: XTCE12-159
  • Legacy Issue Number: 9065
  • Status: open  
  • Source: Anonymous
  • Summary:

    Source: Michael Staub michael.staub@dlr.de
    Description : Add page numbering to document.

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

MM-001 What missions need

  • Key: XTCE12-155
  • Legacy Issue Number: 9073
  • Status: open  
  • Source: Anonymous
  • Summary:

    Source: Mario Merri Mario.Merri@esa.int
    Description : In an ideal world, the Project Manager of a new space mission would

    like to have a
    simple life and put a single requirement to the Spacecraft Prime Contractor that
    reads something like: "It shall be possible to export the operational database into
    XTCE (ref. .)".

    To have project managers buying in XTCE, we should be able to demonstrate the
    goodness of the requirement above and explain that the Prime Contractor will have
    to produce a simple tool to translate from their internal DB format into XTCE.
    Therefore, the questions are:

    a) are the XTCE specifications enough to unambiguosly develop the software tool
    that translates into XTCE?

    b) Where should a new mission start from? (missions tend to re-use what has
    been done by other mission before. In the absece of a predecessor is there any
    help that we coulf provide to missions?)

    Clarification and possibly real-mission examples should be provided to clarify the
    above.
    Resolution: Update introductory section and consider development of associated

    tools (e.g.
    validator).

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

MP-001 Terminology

  • Key: XTCE12-156
  • Legacy Issue Number: 9071
  • Status: open  
  • Source: Anonymous
  • Summary:

    ource: M. Pecchioli mauro.pecchioli@esa.i
    Description : There are many specific (and non-obvious) terms used in this

    standard. They
    should be introduced and explained clearly in Section 4. Unfortunately, in the
    current version of the standard, only the obvious terms (telemetering and
    command) are defined. In the state where it is, the standard cannot be really
    understood and thus reviewed without a very significant effort.
    Resolution: CLARIFICATION Add additional terms

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

TH-001 Some Typos

  • Key: XTCE12-154
  • Legacy Issue Number: 9070
  • Status: open  
  • Source: Anonymous
  • Summary:

    Source: Thomas Huang txh@mipl.jpl.nasa.gov
    Description : There are a few minor cosmetic errors
    In the Green Book - Page 15 - <TAG>data<\TAG> should be <TAG>data</TAG> -
    Page 22 - missing '/' before SpaceSystemV1.0.xsd in xsi:schemaLocation - Page
    36 - same problem as in Page 22.

    In the Red Book - Page 13 references 'Appendix A'. I think it should be 'Annex A'.

    • Page 24 - sub-heading 6.1.3.2.6 used twice (for Interlock and Verifiers) - Page

    25

    • perhaps a page and/or section break before '6.2 The Schema'. - Page 70 -
      perhaps a page/or section break before 'Annex B'.
  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

MK-005 Should use type[ContextCalibratorType] in …

  • Key: XTCE12-157
  • Legacy Issue Number: 9068
  • Status: open  
  • Source: Anonymous
  • Summary:

    Description : Currently, element[ContextCalibrator] in element

    [ContextCalibratorList] in
    type[IntegerDataEncodingType], [FloatDataEncodingType] and
    [StringDataEncodingType] are defined by complexContent. To make the structure
    more simple, I recommend to use type[ContextCalibratorType] in
    type[IntegerDataEncodingType], [FloatDataEncodingType] and
    [StringDataEncodingType].

    From: "<element name="ContextCalibrator" maxOccurs="unbounded"> ...
    </element>" To: "<element name="ContextCalibrator"
    type="xtce:ContextCalibratorType" maxOccurs="unbounded"/>"
    Resolution: Good input. Fix schema and associated documentation.

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

OnBoard Software

  • Key: XTCE12-150
  • Legacy Issue Number: 9222
  • Status: open  
  • Source: Anonymous
  • Summary:

    The are no OBSW space element, specific additional information such as OBSW version,
    memory that is read, write, unreadable, protected, constant, variable, start address, etc.

    This may be out of scope of XTCE, but another very common database exchange on modern
    missions. OBSW memory map and execution information, which should ideally be included as a very specific space system element. And is the OBSW version that is valid for the database release.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

CalibratorType

  • Key: XTCE12-152
  • Legacy Issue Number: 9204
  • Status: open  
  • Source: Anonymous
  • Summary:

    SCOS 2K uses another type of calibrators that is not supported by XTCE. XTCE should provide a way to support a kind of logarithmic (or custom) calibrator. The calibration is defined by the following equation: Y = 1/

    {A0 + A1 ln(x) + A2 ln2(x) + A3 ln3(x) + A4 ln4(x)}

    . Ln is the natural log (base e), and Ai are coefficients stored for the calibrations. Of course such a
    calibrator will need, as others, a short description and a name. If this thought as not generic
    enough, then XTCE should give a way to describe non standard calibrators. For example, coefficient, base, exponent in a term sum used as a calibrator.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

Section: 7

  • Key: XTCE12-151
  • Legacy Issue Number: 9083
  • Status: open  
  • Source: Anonymous
  • Summary:

    CNES remarks and recommendations for the XTCE norm CNES (French Space Agency) has led a study to determine if and how the XTCE standard can be used in the context of the Myriade project. (Myriade is a microsatellites family, initiated by Demeter, Parasol …). Some files produced by the actual Myriade data base (called BDMS)for the CCC Control Center have been translated in XTCE. Here are the results of this study : About Telemetry : We have chosen the decommutation plan which is one of the most representative file among those who are exported from the system data base. In this file we have chosen a significant TM packet (called ECU) with a structure containing a discriminating element (part of the telemetry depends on the value of a parameter called a "selector"). The complexity is to separate the data from the processes in the BDMS to define the best implementation with theXTCE norm. We see that the data in the XTCE file must be processed in order to obtain the expected file (addition of ground calculated parameters, renaming of some parameters, calculation of the offset, ...). For the XTCE norm itself, we can notice that there are two ways to define conditional structure. We think that, at least, a way to use XTCE must be recommended in order to obtain a homogenous implementation in different projects. About Telecommands We encountered some difficulties in trying to implement the example of TC with the XTCE norm. We found a lot of similarities in the definitions of types included in the TelemetryMetaDataType and the CommandMetaDataType elements. In some cases, these similarities present slight differences, which are obviously not enough justified with sufficient explanations (ie the definition of the CommandContainer is different coming from CommandMetaData/MetaCommandSet/MetaCommand or coming from CommandMetaData/CommandContainerSet), and therefore resulted in some confusions. The structure of nested types is not easy to assimilate. Some information seem to be redundant inside a type. It would be useful to have more explanations of this case. At first, the information provided by the TC example and the elements defined in the XTCE norm didn’t fit. We finally carried out a way to proceed, nevertheless, there is no evidence that our solution is the best one. The point that is not resolved is how to implement the variable argument. Conclusion of the study Within the framework of this study, the scope of TM/TC implemented with XTCE clearly appeared as limited. We focused our study on a subset of one TM packet, and also on one specific TC. As a result, the first step can be consider positive. However, in the absence of a more exhaustive study which encompass more possibilities of XTCE, the overall feasibility is still pending. The most important problem of the norm is that it is very complex, and difficult to learn, even for engineers experimented in XML, and data base schemas. Its complexity comes from its genericity. We think that there are too many ways to define a TM packet with this norm to be sure that every project will define its telemetry using the same philosophy. In the SpaceSystem schema which describes the norm, the <Annotation> sections are very succinct and sometimes not sufficient. So, in order to help users to understand the schema, the chapter 6 (The Specification) of the XTCE norm should contains more in-depth explanations. Moreover, the standard is far from being user friendly due to excessive offered possibilities in terms of implementation. We did not find any example corresponding to our needs. The available documentation is surely not designed for an easy learning. Of course, a tutorial is to be issued. A solution to reduce the learning effort could be to define a smaller kernel of the norm, with some possible extensions for some specific use. One important lack of the norm seems to be that it does not enable a user to define its own tags and attributes in order to complete the description. This could be the solution to avoid changing the norm each time a particular need appears in a project. Another important remark we have to make is about the state of XTCE. The norm has changed a lot between the OMG version of 2004 and the referenced CCSDS red book. It seems not to be still defintly defined. This fact is very important because if we want to use the norm in an operational context, with have to be sure that there will not have big changes before starting the development of tools based upon the norm. Tools are mandatory to use this norm because it is quite impossible to create a full XTCE file with a simple XML editor. When the norm will be approved, the XML-oriented database can be the next step in the XTCE deployment. It could be interesting to have a generic code that enables the updates of a database by reading a XTCE file and enables the extractions from a database to produce some XTCE files. Xavier Passot CNES DCT/SB/CC With Erwann Poupart (CNES DCT/PS) and Frederic Berriri (CS/SI)

  • Reported: XTCE 1.0 — Wed, 19 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

MK-002 Type of element[MessageRef] is undefined

  • Key: XTCE12-153
  • Legacy Issue Number: 9072
  • Status: open  
  • Source: Anonymous
  • Summary:

    ource: Makoto Kawai kawai.makoto@jaxa.jp
    Description : Type of element[MessageRef] in element[MessageRefSet] in type

    [ServiceType] is
    undefined.

    To change as below.

    From: "
    <element name="MessageRef" maxOccurs="unbounded"/>"

    To: "
    <element name="MessageRef" type="xtce:MessageRefType"
    maxOccurs="unbounded"/>"

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

6 - Add ToString to Boolean or remove Boolean in favor of Enumerated Types

  • Key: XTCE12-146
  • Legacy Issue Number: 10174
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    6 - Add ToString to Boolean or remove Boolean in favor of Enumerated Types (ESA-007)

    Defer (no agreement on approach)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

- Add separate CalibratorSet to XTCE

  • Key: XTCE12-145
  • Legacy Issue Number: 10170
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    2 - Add separate CalibratorSet to XTCE as many legacy system hold calibrators in tables (ESA-006)

    Defer (breaks current XTCE model, complexity)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

1 - Support ability to describe redundant or complimentary data

  • Key: XTCE12-147
  • Legacy Issue Number: 10169
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    1 - Support ability to describe redundant or complimentary data (ESA-001)

    Defer (complexity)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

OnBoard Memory

  • Key: XTCE12-148
  • Legacy Issue Number: 9221
  • Status: open  
  • Source: Anonymous
  • Summary:

    There are no specific descriptions of onboard memory possible, i.e. block size, addressing technique, etc as per tables 12, 13 of the ECSS. This I would expect at the space-system
    description level?

    Onboard memory is a very specific type of space system element, for which a lot of specific data is always needed, and it would be worth making specific entry types appropriate to onboard memory system elements. This to include Memory ID, Accessibility (read,write), smallest addressable unit, addressing technique, block length, subblock symbolic name, subblock offset, subblock length, etc

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

CommandContainerType

  • Key: XTCE12-149
  • Legacy Issue Number: 9206
  • Status: open  
  • Source: Anonymous
  • Summary:

    A fixed value cannot be added to a container created in the ContainerSet but only to a
    container created in the MetaCommand object. In SCOS 2K, fixed values would be added in
    the Meta Command and this cannot be done. Add the Fixed Area support to container defined with the MetaCommand would help

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

8 - Add activity field to Alarms to indicate what the alarm will trigger

  • Key: XTCE12-141
  • Legacy Issue Number: 10176
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    8 - Add activity field to Alarms to indicate what the alarm will trigger (ESA-015)

    Defer (further discussion needed)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

5 - Align XTCE and CCSDS Navigation Schemas (types)

  • Key: XTCE12-144
  • Legacy Issue Number: 10173
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    5 - Align XTCE and CCSDS Navigation Schemas (types) (JPL-029)

    Defer (possible future work area)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

4 - Separate XTCE Schema into constituent parts

  • Key: XTCE12-143
  • Legacy Issue Number: 10172
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    4 - Separate XTCE Schema into constituent parts (JPL-016,022,026,030)

    Defer (possible future work area

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

3 - Use UML Instance diagrams for XTCE document example

  • Key: XTCE12-142
  • Legacy Issue Number: 10171
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    3 - Use UML Instance diagrams for XTCE document example (ESA-038)

    Defer (more appropriate for XTCE CCSDS Green/Magenta Books, future work area)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

9 - Add filtering of value threshold to maintain telemetry at certain rates

  • Key: XTCE12-138
  • Legacy Issue Number: 10177
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    9 - Add filtering of value threshold to maintain telemetry at certain rates (ESA-048)

    Defer (additional discussion, future work area)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

7 - Use UUIDs instead of current XTCE Referencing mechanism

  • Key: XTCE12-140
  • Legacy Issue Number: 10175
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    7 - Use UUIDs instead of current XTCE Referencing mechanism (ESA-005)

    Defer (complexity, no agreement on approach, further consideration needed)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Updated: Fri, 15 Jan 2016 05:04 GMT

DC-027 Line 3

  • Key: XTCE12-173
  • Legacy Issue Number: 9053
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "a TransmissionContraintList"
    To: "a TransmissionConstraintList"
    Resolution: Fix text

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-032 Line 3

  • Key: XTCE12-174
  • Legacy Issue Number: 9052
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "overidden"
    To: "overridden"
    Resolution: Fix text

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-034 Line 10

  • Key: XTCE12-178
  • Legacy Issue Number: 9051
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    ource: D.Campbell dave.campbell@scisys
    Description : From: "the UML refenceces"
    To: "the UML references"
    Resolution: Fix Schema annotation and text

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-018 Line 10

  • Key: XTCE12-175
  • Legacy Issue Number: 9050
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : Is this a typo?
    From: "minorFrame 20"
    To: "minorFrame 8"
    Resolution: Fix text 6.2.2.3

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-029 Line 1

  • Key: XTCE12-177
  • Legacy Issue Number: 9048
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "user access our confirmations"
    To: "user access confirmation"
    Resolution: Fix text - actually should read "user access or confirmations"

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-011 Figure text.

  • Key: XTCE12-180
  • Legacy Issue Number: 9046
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : "CommandMetaDataType" lists its attributes, but the attributes in
    "TelemetryMetaDataType" are missing.
    Resolution: Correct UML figure

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-005 Figure

  • Key: XTCE12-182
  • Legacy Issue Number: 9044
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : No label or Figure number
    Resolution: Fix text

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-025 Encoding information

  • Key: XTCE12-184
  • Legacy Issue Number: 9043
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : Lines 6-7. Same query as for DC-013, DC-017, DC-021. An argument may "include
    information about how the value is encoded for transmission", but there’s nothing
    in the document to define how this information should be used. So where is that
    defined? "All of the encoding information is in the Encoding area." What is this,
    where is it defined, and why is it not included in the list of terms?
    Resolution: Text should be updated for clarification

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-026 Encoding area

  • Key: XTCE12-183
  • Legacy Issue Number: 9042
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : Lines 8. "All of the encoding information is in the Encoding area." What is this,
    where is it defined, and why is it not included in the list of terms?
    Resolution: Fix text

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-017 Assembly / dissembly information.

  • Key: XTCE12-190
  • Legacy Issue Number: 9036
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : Lines 2-3. Same query as for DC-013. How is this information used to assemble an
    uplink / disassemble a downlink? And where are these methods of assembly /
    disassembly defined? More information in this document or inclusion of a reference
    to the relevant document would be useful.
    Resolution: The XTCE powerpoint tutorial contains the best explanatory information on XTCE.
    Text should be updated to add clarity to the assembly/disassembly mechanisms.

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-028 ArgumentList

  • Key: XTCE12-191
  • Legacy Issue Number: 9035
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : This should explain how MetaCommand arguments are used compared to
    Command arguments and how they relate to each other, if at all.
    Resolution: Clarify text

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

"Parameter Processing" box

  • Key: XTCE12-195
  • Legacy Issue Number: 9029
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : Should "deramdomization" be de-randomisation" with an 'n' and an 's'?
    Resolution: Not sure about the 's'

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

"Foreword", line 2.

  • Key: XTCE12-198
  • Legacy Issue Number: 9028
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "in all phases of the a spacecraft"
    To: "in all phases of the spacecraft"
    Resolution: Fx

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-033 Line 6

  • Key: XTCE12-166
  • Legacy Issue Number: 9062
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "Element and Type names begin with a capitol letter."
    To: "Element and Type names begin with a capital letter."
    Resolution: Fix text and associated schema annotation

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-024 Line 6

  • Key: XTCE12-168
  • Legacy Issue Number: 9060
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "Most Arguments, are"
    To: "Most Arguments are"
    Resolution: Fx text

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-030 Line 5

  • Key: XTCE12-167
  • Legacy Issue Number: 9058
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "is is possible"
    To: "it is possible"
    Resolution: Fix

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-016 Line 4.

  • Key: XTCE12-169
  • Legacy Issue Number: 9057
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "a Parameter it is not the value itself."
    To: "a Parameter is not the value itself."
    Resolution: Fix text

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-020 Line 4

  • Key: XTCE12-171
  • Legacy Issue Number: 9056
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "The collection of messages to search thru"
    To: "The collection of messages to search through"
    Resolution: Fx text

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-008 Line 4

  • Key: XTCE12-170
  • Legacy Issue Number: 9055
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "RF hardware and other many other assets"
    To: "RF hardware and many other assets"
    Resolution: Fix text

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-010 Line 1

  • Key: XTCE12-176
  • Legacy Issue Number: 9049
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "the organization of the data may be organized hierarchical structure"
    To: "the data may have a hierarchical structure"
    Resolution: Fix text

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-021 Assembly / dissembly of streams

  • Key: XTCE12-186
  • Legacy Issue Number: 9037
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : Lines 2-4. Same query as for DC-013 and DC-017. The types listed do NOT
    contain "the knowledge for how to assemble, disassemble and process spacecraft
    uplink and downlink streams" - they may hold the constraint or type information
    required by the assembly / disassembly methods, but they do not define the
    knowledge of how to do this. There needs to be another document which does
    Resolution: Propose revised text 6.1.2.5

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-004 "Philosophy", line 2

  • Key: XTCE12-200
  • Legacy Issue Number: 9030
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "While, the basic"
    To: "While the basic"

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-012 Line 5

  • Key: XTCE12-164
  • Legacy Issue Number: 9059
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "Most Parameters, are"
    To: "Most Parameters are"
    Resolution: Fix text

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:21 GMT

DC-015 Figure label.

  • Key: XTCE12-181
  • Legacy Issue Number: 9045
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "Figure 3 ParameteTypeSet"
    To: "Figure 3 ParameterTypeSet"

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:20 GMT

MP-004 Logarithmic calibrations

  • Key: XTCE12-163
  • Legacy Issue Number: 9063
  • Status: open  
  • Source: Anonymous
  • Summary:

    ource: M. Pecchioli mauro.pecchioli@esa.i
    Description : It seems that logarithmic calibrations are not supported by the

    standard. I think
    this should be added.

    -----Added after meeting with clarification by MP of 18Apr05:

    What we support in S2K is the following:

    In the case of parameters associated to a logarithmmic calibration, the engineering
    value ‘Y’ corresponding to the raw value ‘X’ of a parameter is calculated using

    the
    following formula:
    Y = 1 / [A0 + A1*ln(X) + A2*ln2(X) + A3*ln3(X) + A4*ln4(X)]
    Resolution: Question: Would a polynomial approximation be close enough? What

    forms of
    logarithmic calibration are required: natural, base 10 other. What direction of
    conversions are required?

    Discussion: what is ln2 (a base 2 log or the second natural log?)

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:15 GMT

MS-006 Footing of Figure 1 is missing.

  • Key: XTCE12-179
  • Legacy Issue Number: 9047
  • Status: open  
  • Source: Anonymous
  • Summary:

    Footing of Figure 1 is missing.
    Source: Michael Staub michael.staub@dlr.de
    Description :
    Resolution: Add footing

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:14 GMT

MP-007 Dynamic telemetry check types

  • Key: XTCE12-185
  • Legacy Issue Number: 9041
  • Status: open  
  • Source: Anonymous
  • Summary:

    Source: M. Pecchioli mauro.pecchioli@esa.i
    Description : It seems that only alarms based on static definition of the allowed value ranges are
    supported. Spacecraft control systems also require the support of checks against
    a dynamic reference, either maintained based on commanding activities (this is
    known as Status Consistency Checks in SCOS-2000) or maintained using
    telemetry data (this is known as Delta checks in SCOS-2000). Provision for this
    type of checks (against a 'moving' reference) shall also be made in XTCE.
    Resolution: XTCE does support a form of Delta Range checks called "ChangePerSecond".
    Question to RID author: "is this what you are looking for, or are you looking for
    something else?" Status consistancy checks should be added to the schema. It
    is believed that XTCE does support the RID authors's requirements for Delta
    checks.

    Add clarification for Delta checks.

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:14 GMT

MS-009 De-calibration of cmd parameters?

  • Key: XTCE12-189
  • Legacy Issue Number: 9039
  • Status: open  
  • Source: Anonymous
  • Summary:

    Source: Michael Staub michael.staub@dlr.de
    Description : Is command parameter processing intentionally left out? On the other hand, TM
    calibration is mentioned. The same is valid for command packetization.
    Resolution: but for command arguments
    Title: GV-007 Dependencies or aggregation
    Source: Gert Villemos gev@terma.com
    Description : The UML diagrams seems to use dependencies (arrow) instead of aggregation (line
    with diamond). From the context, aggregation is meant. It is not clear whether the
    UML diagrams are intended only to illustrate the definition or actually be formal
    Resolution: Notation was decided by the tool that was used to do reverse engineering (from
    XML Schema to UML). It is agreed that the suggested representation is more
    correct.

    ACTION GV-007-01: Gert Villemos to provide updated UML diagrams for XTCE.
    Due 30May05

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:14 GMT

DC-023 Line 3.

  • Key: XTCE12-172
  • Legacy Issue Number: 9054
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : "MessageSet" is not shown in Figure 1 or Figure 7.
    Resolution: Figure 7 does not show a MessageSet because it is not part of
    CommandMetaData (whether it should be is another discussion).

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:13 GMT

DC-009 Line 6

  • Key: XTCE12-165
  • Legacy Issue Number: 9061
  • Status: open  
  • Source: scisys ( Dave Campbell)
  • Summary:

    Source: D.Campbell dave.campbell@scisys
    Description : From: "markup documentation,"
    To: "markup documentation)"
    Resolution: Fix text

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:12 GMT

MK-007 Don't need element[ChangePerSecondAlarmConditions]

  • Key: XTCE12-187
  • Legacy Issue Number: 9040
  • Status: open  
  • Source: jaxa.jp ( Makoto Kawai)
  • Summary:

    MK-007 Don't need element[ChangePerSecondAlarmConditions] intype[NumericAlarmConditionType]
    Source: Makoto Kawai kawai.makoto@jaxa.jp
    Description : Currently, element[ChangePerSecondAlarmConditions] is defined in
    element[ConditionalAlarm] in type[NumericAlarmConditionType], but Change rate
    evaluation cannot apply to Conditions. To change as below.

    From:
    "<element name="ConditionalAlarm"> <annotation>
    <documentation>…</documentation> </annotation>
    <complexType>
    <sequence>
    <element name="StaticAlarmConditions"
    type="xtce:AlarmConditionsType" minOccurs="0"/>
    <element name="ChangePerSecondAlarmConditions"
    type="xtce:AlarmConditionsType" minOccurs="0"/>
    </sequence>
    </complexType>
    </element>"

    To: "
    <element name="ConditionalAlarm"> <annotation>
    <documentation>…</documentation> </annotation>
    <complexType>
    <sequence>
    <element name="StaticAlarmConditions"
    type="xtce:AlarmConditionsType" minOccurs="0"/>
    </sequence>
    </complexType>
    </element>"
    Resolution: To be even clearer, we should change "StaticAlarmConditions" to simply
    "AlarmConditions". Fix schema and supporting documentation

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:08 GMT

MK-010 All ParameterType and ArgumentType should have alarm element

  • Key: XTCE12-192
  • Legacy Issue Number: 9034
  • Status: open  
  • Source: jaxa.jp ( Makoto Kawai)
  • Summary:

    Source: Makoto Kawai kawai.makoto@jaxa.jp
    Description : Alarm element is just defined in Integer and Float type in ParameterType,
    ArgumentType in type[ParameterTypeSetType] and element[ArgumentTypeSet],
    but all ParameterType and ArgumentType (especially, enumerated type) are to
    have alarm element.
    Resolution: Agree, but implementation of Alarm for non-numeric types needs to be discussed

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 07:02 GMT

lack of Union construct (MER + ASIST)

  • Key: XTCE12-208
  • Legacy Issue Number: 8909
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    MER supports a Union construct because their abstract data types live past decomm. ASIST also supports the same idea – that an abstract data type onboard the spacecraft MAY live past decomm. Although it is possible to let multiple parameters overlap, in a sense allowing for a Union in XTCE. The issue arises that validating software cannot differentiate this with a bug in a container specification. A union tag or element of some sort is needed.

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:58 GMT

XTCE issue: dimensionList in arrayParameterRef should be optional

  • Key: XTCE12-209
  • Legacy Issue Number: 8704
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Specifying array dimension sizes in arrayParameterRef should be optional. In telemetry arrays often include an on the fly 'count' in the data packet. Therefore this may come in conflict with the fixed sizes in the dimension list.

    The other option is to clearly state in the annotation that the dimensionList is mearly an hint to the run-time software and more more processing will need to be done to ascertain the true size.

    Finally, a further option would be to have the dimensionList optionally look up the dimension size using a InstanceRef to another parameter in the data stream...

  • Reported: XTCE 1.0b1 — Tue, 26 Apr 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:58 GMT

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

  • Key: XTCE12-210
  • Legacy Issue Number: 8908
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

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

    JWST hold conversion and limits in a seperate file that are grouped. Certains "sets" can be used for different mission phases such as test, on-orbit and so on, or for any reason deemed appropriate. XTCE allows one to specify at MOST one of each of these per parameterType

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:57 GMT

repeat of arguments issue

  • Key: XTCE12-211
  • Legacy Issue Number: 8886
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    The following command makes use of a repeat block of arguments:

    ack_packets ( num_acks, ack_block )

    Ack_block consists of three arguments: pkt_start, pkt_end and pkt_time

    This would be a perfectly valid command:

    ack_block[0].pkt_start = 1
    ack_block[0].pkt_end = 1
    ack_block[0].pkt_time = 00:00:00

    ack_packets ( 1, ack_block )


    This is not capturable in XTCE because there is no mechanism for having REPEATS of ARGUMENTS.

    There are workarounds but there are less than ideal, they are:

    – use an array, this is problematic because the types of each sub-field may be different (see above, pkt_time is a TIME type)
    – treat them as parameters... which they are not...

  • Reported: XTCE 1.0b1 — Tue, 28 Jun 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:57 GMT

XTCE issue - add shortDescription to EntryList entries

  • Key: XTCE12-212
  • Legacy Issue Number: 8703
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Items in entryList should each have their own optional shortDescription attribute for documentation at each entry of the container itself.

  • Reported: XTCE 1.0b1 — Tue, 26 Apr 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:57 GMT

AO-006 Additional examples (2)

  • Key: XTCE12-193
  • Legacy Issue Number: 9033
  • Status: open  
  • Source: Anonymous
  • Summary:

    Source: Amalaye Oyake amalaye.oyake@jpl.na
    Description : 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.
    Resolution: It is generally agreed that a CCSDS green book (or equivalent) should be written for
    XTCE, however, no timelime has been established.

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT

MK-003 A mistake of type[ContainerSegmentRefEntryType]'s annotation

  • Key: XTCE12-194
  • Legacy Issue Number: 9032
  • Status: open  
  • Source: Anonymous
  • Summary:

    Source: Makoto Kawai kawai.makoto@jaxa.jp
    Description : The annotation of type[ContainerSegmentRefEntryType] is to be changed as
    below.

    From: "An Entry ... order=0" To: "An Entry ... portion of a container. It is assumed

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT

MK-001 A mistake of attribute[messageRef]'s annotation

  • Key: XTCE12-199
  • Legacy Issue Number: 9031
  • Status: open  
  • Source: Anonymous
  • Summary:

    Source: Makoto Kawai kawai.makoto@jaxa.jp
    Description : The annotation of attribute[messageRef] in type[MessageRefType] is to be
    changed as below.

    From: "name of container"
    To: "name of message"

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT

"Foreword", 2nd last line

  • Key: XTCE12-196
  • Legacy Issue Number: 9027
  • Status: open  
  • Source: Anonymous
  • Summary:

    Description : From: "support of all phases of the satellite"
    To: "support all phases of the satellite"

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT

Contents"

  • Key: XTCE12-197
  • Legacy Issue Number: 9026
  • Status: open  
  • Source: Anonymous
  • Summary:

    Contents listing is incomplete - "Foreword", "Introduction" and section "1 Scope"
    are all missing

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT

"Command Processing" box

  • Key: XTCE12-202
  • Legacy Issue Number: 9025
  • Status: open  
  • Source: Anonymous
  • Summary:

    Should "deramdomization" be de-randomisation" with an 'n' and an 's'?

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT

Spec too complex?

  • Key: XTCE12-201
  • Legacy Issue Number: 8962
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Too complex, ( I have some examples from the ASIST meeting ).

  • Reported: XTCE 1.0 — Fri, 5 Aug 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT

USE CCSDS examples how to use the standard

  • Key: XTCE12-203
  • Legacy Issue Number: 8961
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    USE CCSDS examples how to use the standard ( we can provide data set with tlm & commnad)

  • Reported: XTCE 1.0 — Fri, 5 Aug 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT

too much leeway how to use the standard

  • Key: XTCE12-206
  • Legacy Issue Number: 8960
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Ambiguity - The is too much leeway how to use the standard, and things are left for interpretation. The standard allows / calls for users to add thier own items when they are missing. Need to tighten the standard so things will be done consistently

  • Reported: XTCE 1.0 — Fri, 5 Aug 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT

Propose that XCTE ( at this point ) will be limited to exchange data

  • Key: XTCE12-204
  • Legacy Issue Number: 8959
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    Propose that XCTE ( at this point ) will be limited to exchange and not to all mission data

  • Reported: XTCE 1.0 — Fri, 5 Aug 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT

Xpath:

  • Key: XTCE12-205
  • Legacy Issue Number: 8927
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    – Xpath: xpath is the XML answer to unix-style paths but includes MATCHING, the ability really to get some chunk of any XML document using an Xpath expression. We should consider Xpath as the format for Refs... but there needs to be a technical debate.

    "... A reference to a Parameter. Uses Unix ‘like’ naming across the
    > SpaceSystem Tree (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage). To
    > reference an individual member of an array use the zero based bracket
    > notation commonly used in languages like C, C++, and Java."

  • Reported: XTCE 1.0b1 — Wed, 6 Jul 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT

command side unable to describe "packed commands"

  • Key: XTCE12-207
  • Legacy Issue Number: 8907
  • Status: open  
  • Source: NASA ( Kevin Rice)
  • Summary:

    command side unable to describe "packed commands" where multiple commands are packed into a single packet (MER)

    It isn't clear metacommand which itself represents a command in XTCE can package more than one command. Essentially this is multiple commands stuffed in a single packet

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Updated: Fri, 27 Nov 2015 06:56 GMT