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

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.

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.

This is a legacy issue during XTCE 1.0 modifications for XTCE 1.1

This appears to have been addressed in XTCE 1.1. The issue probably came over with the database transition incorrectly.

. 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 ...).

This is a legacy issue during XTCE 1.0 modifications for XTCE 1.1

This issue appears to have been addressed per the request of the submitter during XTCE 1.1 development and as such is not in scope for XTCE 1.2. This probably is here because of the issues database being brought forward.

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.

This is a legacy issue during XTCE 1.0 modifications for XTCE 1.1

It appears that this issue was corrected in XTCE 1.1 and is probably here because of a database transition issue. Propose to close without change in the context of XTCE 1.2.

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.

Agree with the description

It is correct that the CommandContainerSet has "CommandContainer" elements that are simply SequenceContainers in nature. It cannot have Arguments because arguments are local to a MetaCommand. They are of somewhat limited value because they can only contain parameters, but they can be used as base containers in many MetaCommands, to provide parameter entries for "system generated fields", such as header items for the command that would not be part of the operator driven set of Arguments to provide. The author of the comment was able to determine the utility of the CommandContainerSet from the existing specification and schema. Since we agree with the author of the question, we close without change.

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...

Repeating arguments for memory loads

Extension of the argument concept to cover repeating argument blocks is not in the scope of the original RFP. There is a workaround that utilizes aggregrate parameter types instead of arguments.

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...

Merge with 14455 resolution.

A resolution of 14455 would conflict with a resolution for this issue, and 14455 is the preferred approach to array sizing.

– 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."

No Xpath for cross-references

Requiring an Xpath definition for the cross-references would break existing XTCE exchange implementations and would not necessarily reduce the amount of code required to implement an export or import tool.

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

Use nested command containers

A metacommand container can contain nested containers, thus allowing more than one “command” in a single packet. XTCE does not specify the transfer protocol layer that might control packet splitting and reassembly onboard

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

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

Add an optional shortDescription attribute to the SequenceEntryType. As an optional description, it will not affect the upward (1.1 to 1.2) interpretation of existing XTCE documents. The attribute can easily be stripped from a 1.2 document for processing by a 1.1 compatible tool. A 1.1 tool using schema-based parsing will ignore the optional field, when updated with the 1.2 schema.

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.

Programming construct does not fit current data model, defer to future revision

Not all ground systems support the union construct in the decommutated data. By specifying overlapping locationInContainer positions, the effect of the union can be achieved in XTCE. This feature request is being deferred to a future revision.

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

Significant data model change, defer to future version

This would be a significant change in the data model in order to support a capability that is already supported via the ParameterType inheritance mechanism. The requested feature can be handled by the database modeling tools and still exchanged using the mechanism in XTCE. The requested feature is being deferred for consideration in a future revision.
What is called a mission phase here is called a context in XTCE. XTCE has a very robust capability to describe different alarms or calibrations in different Contexts.
Calibration and Alarm Sets are used in many ground systems that employ a relational data model. In actual space systems, calibrations and alarm sets are shared by Parameters when the Parameters of the same 'type'. For example, all voltage Parameters on a SpaceSystem will all have the same calibrations when the same voltage transducer is used. Because XTCE parameters are all declared from ParameterTypes, it is very easy to define a single 'VoltageType' with the calibration in the VoltageType and instantiate many Voltage Parameters.

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

No Data Available

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... ?

No Data Available

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

No Data Available

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.

No Data Available

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?

No Data Available

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>

No Data Available

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.

No Data Available

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.

No Data Available

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).

No Data Available

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

No Data Available

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>

No Data Available

CommandContainerSet does not have argumentRefEntry

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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

No Data Available

This rate will be used to generate an alarm if certain telemetry containers do not arrive at the anticipated rate. This rate could also be used by simulators (for generating telemetry) or as guides for generating forward link containers

No Data Available

Within a MetaCommand, the uniqueness of argument names can be enforced by the schema language and should be.

No Data Available

The normative XML schema component of the specification is broken into separate W3C schemas. While this is a valid approach by the W3C schema specification, many (most?) of the currently available XML validation tools do not gracefully handle multiple schemas. This change will have no effect on compliant XML documents

No Data Available

Reason: The auto-generated documentation may be generated by anyone and makes the non-normative specification difficult to manage and extraordinarily large. UML diagrams in the document serve the same purpose

No Data Available

Currently an Empty UnitSet is required for all data types even when there are no units. This adds significant extra text to an XML document that validates to the XTCE schema.

No Data Available

If items like Parameters, and MetaCommands, Containers, and Algorithms were given a unique id then references to those objects could be guaranteed to be correct by the XML parsers

No Data Available

BaseDataType/Enumerated has no holder for allowed name/value pairs

No Data Available

Reed Solomon Encoding and Decoding has no algorithm in the text. Suggest providing pseudocode for CCSDS Reed Solomon. Suggest adding that missions may enter their own pseudocode if they wish.

No Data Available

Early reviewers of the specification have consistently complained that the specification is too complex – particularly in the packaging section and that the annotations that accompany the scheme are oftentimes incomplete, contain typos, or vague.

No Data Available

Add array types as one of the fundamental types in XTCE. This addition, once thought to be a ‘nice’ enhancement is now considered essential

No Data Available

Add time encoding Summary: provide a general mechanism to describe parameters and arguments that are encoded for transmission containing absolute and relative time values.

No Data Available

Remove DwellSet replace with indirect parameterRef Summary: DwellSet as currently implimented is not sufficient for all types of telemetry dwell. A Container Entry type where the entry is given indirectly will simplify the schema and provide a more general Dwell telemetry description

No Data Available

Change BusAttribute to DataEncoding, have Float, Integer, Enumerated … inherit from AbstractDataType, and make SpaceSystemType, BaseAlgorithmType, ContainerNameType … all inherit from NameDescriptionType

No Data Available

Ability needed to define a relative time offset within TimeAssociation Summary: The ‘TimeAssociationType’ provides a means for ParameterInstances to be tied to a time value, but this time association also needs to have an optional relative time offset.

No Data Available

The StringDataType needs a character width attribute to be used by the ground software when it is necessary to handle multi-byte characters.

No Data Available

Parameters that are in multiple sub-systems Summary: ITOS frequently has parameters that are considered members of multiple sub-systems, the adopted XTCE format only allows Parameters to be members of a single sub-system

No Data Available

‘shortDescription’ size restriction in the NameType is too short. Summary: 'shortDescription’ size restriction in the NameType is too short

No Data Available

‘SizeRange’ in StringDataType is ambiguous ‘SizeRange’ in StringDataType is ambiguous because it’s unclear if the size is in characters, or bytes, or bits or something else. This Element name violates one of the XTCE conventions “Hints on units (for values with units) are provided in the names of attributes”.

No Data Available

Missing ‘label’ in RangeEnumeration Summary: The label in the ToStringCalibrator for RangeEnumeration is missing

No Data Available

‘minViolations’ is misspelled The attribute ‘minViolations’ in the complex type NumericAlarmContions is spelled minVioatons’. This change will only impact XML documents that use the misspelled ‘minVioatons’ attribute.

No Data Available

Signed/Unsigned attribute for IntegerDataType Summary: The Integer Data Type requires an attribute to indicate whether this Data should be treated as a signed or unsigned integer. Missions may need the extra bit for large data values.

No Data Available

Make capitalization of Elements and Attributes consistent. According to the formatting rules at the top of the schema, all schema attributes should begin with a lower case letter and all Elements should begin with an upper case letter. This rule is mostly, but not always applied.

No Data Available

BaseDataType/Any should be reserved to describe any parameter that can be of any datatype. As it is, it is fixed to be a SourceParameterRef only

No Data Available

Have all FrameTypes inherit from a single BaseFrameType. This will simplify the schema and any auto generated code generated from the schema. Any XML documents compliant with the schema will not change as a result of this schema change

No Data Available

Have all Algorithm Types inherit from a single BaseAlgorithmType. This will simplifiy the schema and will make code auto-generated code from the schema simpler. XML documents compliant with the schema will not change as a result of this schema change.

No Data Available

Drop obsolete FormatType. This Element/Complex type is no longer used and is now orphaned

No Data Available

Remove obsolete and unreferenced FixedFrameSync Element. This element is no longer used and is now orphaned

No Data Available