Issue 8703: XTCE issue - add shortDescription to EntryList entries
Issue 8704: XTCE issue: dimensionList in arrayParameterRef should be optional
Issue 8886: repeat of arguments issue
Issue 8907: command side unable to describe "packed commands"
Issue 8908: inability to describe sets of limits (alarms) and conversions (polynomials)
Issue 8909: lack of Union construct (MER + ASIST)
Issue 8927: Xpath:
Issue 8959: Propose that XCTE ( at this point ) will be limited to exchange data
Issue 8960: too much leeway how to use the standard
Issue 8961: USE CCSDS examples how to use the standard
Issue 8962: Spec too complex?
Issue 9025: "Command Processing" box
Issue 9026: Contents"
Issue 9027: "Foreword", 2nd last line
Issue 9028: "Foreword", line 2.
Issue 9029: "Parameter Processing" box
Issue 9030: DC-004 "Philosophy", line 2
Issue 9031: MK-001 A mistake of attribute[messageRef]'s annotation
Issue 9032: MK-003 A mistake of type[ContainerSegmentRefEntryType]'s annotation
Issue 9033: AO-006 Additional examples (2)
Issue 9034: MK-010 All ParameterType and ArgumentType should have alarm element
Issue 9035: DC-028 ArgumentList
Issue 9036: DC-017 Assembly / dissembly information.
Issue 9037: DC-021 Assembly / dissembly of streams
Issue 9038: HVM-004 Data Encoding definitions
Issue 9039: MS-009 De-calibration of cmd parameters?
Issue 9040: MK-007 Don't need element[ChangePerSecondAlarmConditions]
Issue 9041: MP-007 Dynamic telemetry check types
Issue 9042: DC-026 Encoding area
Issue 9043: DC-025 Encoding information
Issue 9044: DC-005 Figure
Issue 9045: DC-015 Figure label.
Issue 9046: DC-011 Figure text.
Issue 9047: MS-006 Footing of Figure 1 is missing.
Issue 9048: DC-029 Line 1
Issue 9049: DC-010 Line 1
Issue 9050: DC-018 Line 10
Issue 9051: DC-034 Line 10
Issue 9052: DC-032 Line 3
Issue 9053: DC-027 Line 3
Issue 9054: DC-023 Line 3.
Issue 9055: DC-008 Line 4
Issue 9056: DC-020 Line 4
Issue 9057: DC-016 Line 4.
Issue 9058: DC-030 Line 5
Issue 9059: DC-012 Line 5
Issue 9060: DC-024 Line 6
Issue 9061: DC-009 Line 6
Issue 9062: DC-033 Line 6
Issue 9063: MP-004 Logarithmic calibrations
Issue 9064: MS-003 Meaning not clear.
Issue 9065: MS-001 Missing page numbering
Issue 9066: DC-013 Parameter encoding information
Issue 9067: V-003 Schema file identification
Issue 9068: MK-005 Should use type[ContextCalibratorType] in …
Issue 9069: Should use type[FixedFrameSyncStrategyType] in type [FixedFrameStreamType]
Issue 9070: TH-001 Some Typos
Issue 9071: MP-001 Terminology
Issue 9072: MK-002 Type of element[MessageRef] is undefined
Issue 9073: MM-001 What missions need
Issue 9083: Section: 7
Issue 9204: CalibratorType
Issue 9206: CommandContainerType
Issue 9221: OnBoard Memory
Issue 9222: OnBoard Software
Issue 10169: 1 - Support ability to describe redundant or complimentary data
Issue 10170: - Add separate CalibratorSet to XTCE
Issue 10171: 3 - Use UML Instance diagrams for XTCE document example
Issue 10172: 4 - Separate XTCE Schema into constituent parts
Issue 10173: 5 - Align XTCE and CCSDS Navigation Schemas (types)
Issue 10174: 6 - Add ToString to Boolean or remove Boolean in favor of Enumerated Types
Issue 10175: 7 - Use UUIDs instead of current XTCE Referencing mechanism
Issue 10176: 8 - Add activity field to Alarms to indicate what the alarm will trigger
Issue 10177: 9 - Add filtering of value threshold to maintain telemetry at certain rates
Issue 8703: XTCE issue - add shortDescription to EntryList entries (xtce-rtf)
Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, kevin.rice@gst.com Kevin.Rice@gst.com)
Nature: Uncategorized Issue
Severity:
Summary:
Items in entryList should each have their own optional shortDescription attribute for documentation at each entry of the container itself.
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...
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...
Resolution: Use parameters in the command area instead of arguments as a workaround. This feature may be considered for a future revision.
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
Resolution: XTCE is not constrained to one command per packet. A packed command packet could be composed of any number of arbitrary CommandContainers. XTCE lacks rules on when to transmit a packed Command Container, but the utility of adding those rules to the exchange format has to be traded against additional complexity.
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
Resolution: There are really two separate issues here: 1) the need different alarms and calibrations in different phases and 2) the desire to use alarm or calibrator sets and refer to these sets in each parameter - to reduce redundancy. Each of these sub-issues is addressed below: 1. Alarms and Phases. This is simply a nomenclature issue; what is called a mission phase here (and in many Boeing missions) is in XTCE called a '.Context'. XTCE has a very robust capability to describe different alarms or calibrations in different Contexts. Close, no change. 2. Calibration and Alarm Sets. 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 Space System will all have the same calibrations when the same voltage transducer is used throughout the space system - as is usually the case. 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 from the Voltage 'Type'. Using this declaration technique XTCE offers a very natural means to declare Calibration and Alarm sets once. This seems to be a recurring issue and will be addressed in a future ESA Schema change submission. Ultimate this is an issue of compactness and modularity. If typical parameter types can be set to one of several calibrations during the lifetime of a mission for example, one would be forced to create a new parameter-type for each one - that is if that calibrator is likely to change a fairly regular basis ( meaning that simply deleting the old information and updating isn't a good solution). This has the tendency then to explode the type area. In addition, the sets are a convenient place to group all the Alarms and Calibrators in use by the system.
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.
Resolution: ASIST noted that Unions could be 'faked' using the locationInContainer mechanism and at this point doesn't seem to want anything more. This may not be true in the future however. The problem with this is deriving unions from the entryLists then, you have to analyze the locationInContainer area and find overlaps, then one has decide whether the overlapping parameters are unions or just typos. Deferred is fine for now.
-- 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."
Propose that XCTE ( at this point ) will be limited to exchange and not to all mission data
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
USE CCSDS examples how to use the standard ( we can provide data set with tlm & commnad)
Too complex, ( I have some examples from the ASIST meeting ).
Should "deramdomization" be de-randomisation" with an 'n' and an 's'?
Contents listing is incomplete - "Foreword", "Introduction" and section "1 Scope" are all missing
Description : From: "support of all phases of the satellite" To: "support all phases of the satellite"
Source: D.Campbell dave.campbell@scisys Description : From: "in all phases of the a spacecraft" To: "in all phases of the spacecraft" Resolution: Fx
Source: D.Campbell dave.campbell@scisys Description : Should "deramdomization" be de-randomisation" with an 'n' and an 's'? Resolution: Not sure about the 's'
Source: D.Campbell dave.campbell@scisys Description : From: "While, the basic" To: "While the basic"
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"
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
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.
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
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
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.
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
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.
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
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
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.
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
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
Source: D.Campbell dave.campbell@scisys Description : No label or Figure number Resolution: Fix text
Source: D.Campbell dave.campbell@scisys Description : From: "Figure 3 ParameteTypeSet" To: "Figure 3 ParameterTypeSet"
Source: D.Campbell dave.campbell@scisys Description : "CommandMetaDataType" lists its attributes, but the attributes in "TelemetryMetaDataType" are missing. Resolution: Correct UML figure
Footing of Figure 1 is missing. Source: Michael Staub michael.staub@dlr.de Description : Resolution: Add footing
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"
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
Source: D.Campbell dave.campbell@scisys Description : Is this a typo? From: "minorFrame 20" To: "minorFrame 8" Resolution: Fix text 6.2.2.3
ource: D.Campbell dave.campbell@scisys Description : From: "the UML refenceces" To: "the UML references" Resolution: Fix Schema annotation and text
Source: D.Campbell dave.campbell@scisys Description : From: "overidden" To: "overridden" Resolution: Fix text
Source: D.Campbell dave.campbell@scisys Description : From: "a TransmissionContraintList" To: "a TransmissionConstraintList" Resolution: Fix text
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).
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
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
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
Source: D.Campbell dave.campbell@scisys Description : From: "is is possible" To: "it is possible" Resolution: Fix
Source: D.Campbell dave.campbell@scisys Description : From: "Most Parameters, are" To: "Most Parameters are" Resolution: Fix text
Source: D.Campbell dave.campbell@scisys Description : From: "Most Arguments, are" To: "Most Arguments are" Resolution: Fx text
Source: D.Campbell dave.campbell@scisys Description : From: "markup documentation," To: "markup documentation)" Resolution: Fix text
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
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?)
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.
Source: Michael Staub michael.staub@dlr.de Description : Add page numbering to document.
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
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
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.
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).
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'.
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
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"/>"
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).
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)
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.
Resolution: Submit potential new calibrator as a Schema modification Disposition: Deferred
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
Resolution: Please expand upon the problem described. The element FixedValueEntry is available in the MetaCommand/ CommandContainer/EntryList but not in the CommandContainerSet. One possible workaround would be to carefully "divide" a container between metacommand and command container. In other words given a container that consists of 11 parameters, let the 6th one be fixed. Simply create two containers, the 1st contains the first 5 parameters. This would be ref'd in MetaCommand area. Then define the 6th FIXED value, and finally Ref the 2nd set of parameters in 2nd container in the metacommand entry list.
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
Resolution: Onboard memory handling between different spacecraft and ground systems has been even more varied than commands and telemetry. To the extent that onboard memory locations can be named and brought down as "software telemetry" they are supported by XTCE, however, an exchange format for memory definitions beyond telemetry parameter definition is out of the current scope. It is possible that this could be addressed by a future specification, but there are also numerous specifications for memory data for ordinary ground-based computer systems (Motorola S-records, Intel Hex format, Unix STABs, etc.) that may be applicable. deferred
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.
Resolution: AncillaryData may provide enough flexibility to hold some FSW information. However it will be system unique and should be used with care. Otherwise, FSW info is out of the intial scope of XTCE (command & telemetry) and would require new revisions and probably a new RFP from the OMG to address it. Disposition: Deferred
1 - Support ability to describe redundant or complimentary data (ESA-001) Defer (complexity)
Resolution: A true general relationship description could become very complex. This is deferred
2 - Add separate CalibratorSet to XTCE as many legacy system hold calibrators in tables (ESA-006) Defer (breaks current XTCE model, complexity)
Resolution: Although the issue is identified. No satisfactory solution could be found to resolve the problem. This has been deferred to a further release
3 - Use UML Instance diagrams for XTCE document example (ESA-038) Defer (more appropriate for XTCE CCSDS Green/Magenta Books, future work area)
Resolution: This topic has been deferred to a future release
4 - Separate XTCE Schema into constituent parts (JPL-016,022,026,030) Defer (possible future work area
Resolution: Originally XTCE started this way, then merged to allow for unification of concepts, and types, and because of better XML tool support for combined documents. It may be time to split it apart again but this is a large task, and is deferred.
5 - Align XTCE and CCSDS Navigation Schemas (types) (JPL-029) Defer (possible future work area)
Resolution: SIG group at CCSDS is working on this topic. As the schema produced by the Navigation Working Groups is less mature than XTCE, the coordination will be done later (not relevant now..). Revised Text: Disposition: Deferred
6 - Add ToString to Boolean or remove Boolean in favor of Enumerated Types (ESA-007) Defer (no agreement on approach)
Resolution: No agreement on how to proceed among active members Revised Text: Disposition: Deferred
7 - Use UUIDs instead of current XTCE Referencing mechanism (ESA-005) Defer (complexity, no agreement on approach, further consideration needed)
Resolution: In order to allow multiple XTCE SpaceSystems to be developed independently and combined without namespace collision concern, use the hierarchical XTCE structure. UUID creation would require a master UUID authority to ensure uniqueness. Revised Text: Disposition: Deferred
8 - Add activity field to Alarms to indicate what the alarm will trigger (ESA-015) Defer (further discussion needed)
Resolution: This field is more appropriate for linkage to procedures rather than associated with the command and telemetry definitions. Future specifications may appropriately address linkage or system responses to alarms and system events, e.g. SOLM. ESA & NASA agreed to defer. Revised Text: Disposition: Deferred
9 - Add filtering of value threshold to maintain telemetry at certain rates (ESA-048) Defer (additional discussion, future work area)
Resolution: This idea is good, but the clarifications came too late for an implementation. Defer to future release. Revised Text: Disposition: Deferred