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

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

No Data Available

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

No Data Available

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

Extended in XTCE 1.1

No Data Available

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

No Data Available

Clarify types in Figure 4.
RID STATE: FIXED

No Data Available

Precisely define each encoding type.
RID STATE: FIXED

No Data Available

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

No Data Available

"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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

"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

No Data Available

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

No Data Available

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

No Data Available

Define term "anonymous type"
RID STATE: FIXED

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

From: "… begin with a capitol letter. "

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

RID STATE: FIXED

No Data Available

Precisely define each encoding type.
RID STATE: FIXED

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

"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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

Extended in XTCE 1.1

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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

Expanded in XTCE 1.1

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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)

No Data Available

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.

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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

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.

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

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