Issue 8703: XTCE issue - add shortDescription to EntryList entries
Issue 8704: XTCE issue: dimensionList in arrayParameterRef should be optional
Issue 8875: proposed schema change for documentation issue
Issue 8885: includeCondition in commandContainer issue
Issue 8886: repeat of arguments issue
Issue 8905: lack of delta limits (MER + JWST)
Issue 8906: command side seems to be missing the ability to have repeat arguments (MER)
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 8910: lack of clean way to describe "system variables",
Issue 8911: lack of clean way to describe multiple documentary type items
Issue 8912: no tracking mechanism per PARAMETER for changes (no change log)
Issue 8913: Variable length command packets must be supported
Issue 8914: JPL MER schema supports "hardware commands
Issue 8915: JWST, non-CCSDS header commands, routing info
Issue 8916: XTCE Command "Permissions" model may not be generic enough
Issue 8923: proper reference formed weak
Issue 8924: Container/Argument/Stream/Type/etc
Issue 8925: Clarification is needed on Ref names "local" to a spaceSystem
Issue 8926: Ref rules should be spelled out
Issue 8927: Xpath:
Issue 8928: sizeInBits
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 9199: CalibratorType
Issue 9200: CalibratorType (02)
Issue 9201: CalibratorType (03)
Issue 9202: SplineCalibrator
Issue 9203: ToString and Booleans
Issue 9204: CalibratorType
Issue 9205: NumericAlarmConditionTy
Issue 9206: CommandContainerType
Issue 9207: MetaCommand
Issue 9208: Command/Parameter
Issue 9209: Verifiers
Issue 9210: Command verifiers
Issue 9211: ArgumentType / ValidRange
Issue 9212: UnitSet
Issue 9213: ParameterType
Issue 9214: Algorithm for derived
Issue 9215: Argument set
Issue 9216: CommandContainer/Entry
Issue 9217: BlockMetaCommandType
Issue 9218: Parameters
Issue 9219: SpaceSystemType
Issue 9220: Aliases
Issue 9221: OnBoard Memory
Issue 9222: OnBoard Software
Issue 9223: NameType
Issue 10153: 1 - move initialValue and UnitSet to ParameterSet (ESA-08)
Issue 10154: Expand explanatory material
Issue 10155: Expand explanatory material related to "Figure 2"
Issue 10156: 4 -- Expand explanatory material related to "Figure 4"
Issue 10157: 5 -- Expand explanatory material related to "Figure 6"
Issue 10158: 6 - Add Delta Alarms to XTCE
Issue 10159: 7 - Expand explanatory material related to "Figure 2"
Issue 10160: 8 - Expand explanatory material related to "Figure 3"
Issue 10161: 9 -- Expand explanatory for certain terms, Data Type and Data Encoding Type
Issue 10162: 10 - Add indicator of operational status to XTCE (JPL-004)
Issue 10163: Change service set to either accept Messages or Container references
Issue 10164: 2 - Add Aggregate (similar to C-structure) type to XTCE
Issue 10165: Expand explanatory material for XTCE types
Issue 10166: 4 -- Add a name/short description to the argument's valid range set
Issue 10167: 5 - Expand explanatory material in Figure 1
Issue 10168: 6 - Figures 2-10 not referenced in text
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 10178: 1 - Add ability to describe general equations in Calibrator area
Issue 10179: NASA-013
Issue 10180: ESA-002
Issue 10181: ESA-010
Issue 10182: ESA-012
Issue 10183: ESA-013
Issue 10184: ESA-017
Issue 10185: ESA-018
Issue 10186: ESA-019
Issue 10187: ESA-020
Issue 10188: ESA-022
Issue 10189: ESA-023
Issue 10190: ESA-025
Issue 10191: ESA-042
Issue 10192: ESA-054
Issue 10193: ESA-055
Issue 10194: ESA-056
Issue 10195: ESA-065
Issue 10196: ESA-067
Issue 10197: ESA-068
Issue 10198: ESA-069
Issue 10199: ESA-072
Issue 10200: ESA-075
Issue 10201: ESA-077
Issue 10202: ESA-078
Issue 10203: ESA-079
Issue 10204: INPE-001
Issue 10205: INPE-003
Issue 10206: INPE-006
Issue 10207: INPE-007
Issue 10208: INPE-012
Issue 10209: INPE-013
Issue 10210: JPL-001
Issue 10211: JPL-002
Issue 10212: JPL-005
Issue 10213: JPL-006
Issue 10214: JPL-007
Issue 10215: JPL-008
Issue 10216: JPL-009
Issue 10217: JPL-010
Issue 10218: JPL-011
Issue 10219: JPL-012
Issue 10220: JPL-013
Issue 10221: JPL-014
Issue 10222: JPL-015
Issue 10223: JPL-017
Issue 10224: JPL-018
Issue 10225: JPL-019
Issue 10226: JPL-020
Issue 10227: JPL-021
Issue 10228: JPL-022
Issue 10229: JPL-023
Issue 10230: JPL-024
Issue 10231: JPL-025
Issue 10232: JPL-027
Issue 10233: JPL-028
Issue 10234: JPL-031
Issue 10235: ESA-003
Issue 10236: ESA-021
Issue 10237: ESA-024
Issue 10238: ESA-027
Issue 10239: ESA-028
Issue 10240: ESA-029
Issue 10241: ESA-030
Issue 10242: ESA-031
Issue 10243: ESA-033
Issue 10244: ESA-035
Issue 10245: ESA-036
Issue 10246: ESA-037
Issue 10247: ESA-043
Issue 10248: ESA-044
Issue 10249: ESA-046
Issue 10250: ESA-047
Issue 10251: ESA-049
Issue 10252: ESA-050
Issue 10253: ESA-051
Issue 10254: ESA-052
Issue 10255: ESA-057
Issue 10256: ESA-058
Issue 10257: ESA-059
Issue 10258: ESA-060
Issue 10259: ESA-061
Issue 10260: ESA-062
Issue 10261: ESA-063
Issue 10262: ESA-064
Issue 10263: ESA-066
Issue 10264: ESA-070
Issue 10265: ESA-073
Issue 10266: ESA-074
Issue 10267: ESA-076
Issue 10268: INPE-002
Issue 10269: INPE-004
Issue 10270: INPE-005
Issue 10271: INPE-008
Issue 10272: INPE-010
Issue 10273: INPE-011
Issue 10274: NASA-002
Issue 10275: NASA-003
Issue 10276: NASA-005
Issue 10277: NASA-007
Issue 10278: NASA-008
Issue 10279: NASA-009
Issue 10280: NASA-011
Issue 10281: NASA-012
Issue 10440: Division symbol
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...
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>
Resolution: A new Element "AncillaryData" was added to "NameDescriptionType" to address this issue. NameDescription Type is the base type for Parameter, ParameterType, ArgumentType, Argument, ContainerType, Algorithm … basically all significant elements. AncillaryData is itself contained within a 'Set' and is unbounded. AncillaryData is named (so that each organization may uniquely name their set of AncillaryData, has a mimeType and an optional href to point to possible external data. AncillaryData may be used for very simple data like CVS tags to complex data like sound files or even external applications.
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>
Resolution: The Container inheritance feature can be used to implement this requested feature.
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.
Delta limits compare deltas between instances of a parameter and issue an alarm outside a certain threshold
This issue is a duplicate of issue 10158 which is resolved.
CommandContainerSet does not have argumentRefEntry
Resolution: Duplicate of 8886 which is deferred, since an expression of the desired capability is possible in XTCE using parameter references. Originally it was thought CommandContainerSet should have argumentRefs, however this was a misunderstanding of the area
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.
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
Resolution: For variables that are unique to a particular T&C system, there is no value in capturing them in XTCE, because XTCE is targeted to be an Exchange format. XTCE authors recommend using a T&C specific data store. Other items that are operator-set or derived on the ground may be defined as parameters without assigning them to a Container.
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.
Merged with issue 8875 to provide a more robust documentation capability.
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.
Resolution: New AncillaryData capability added for issue 8875, supports documentation of changes within a parameter. Individual parameter storage in a version control system with a merge process or include skeleton is also possible.
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
Resolution: Not sure what change is requested, since XTCE has a superset of the needed functionality. Disposition: Closed
JPL MER schema supports "hardware commands" which are non-CCSDS format commands between or two the low-level onboard hardware
Resolution: XTCE is capable of defining either CCSDS commands or non-CCSDS commands. XTCE has been expanded to support additional documentation of named elements per issue 8875. Disposition: Duplicate
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).
Resolution: Capability is covered with changes resulting from issue 8875 Disposition: Duplicate
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.
Resolution: This is related to issue 8908 in that it is simply a nomenclature issue; what is called a mission phase or flight rules or ground rule here (and in many Boeing missions) is in XTCE called a '.Context'. XTCE has a very robust capability to describe different Command 'Significance' in different Contexts. Close, no change. Disposition: Closed
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.
Resolution: This is true, and the documentation for references needs to be strengthened both in the schema and in the accompanying documentation. Revised Text: Replace: <simpleType name="NameReferenceType"> <annotation> <documentation xml:lang="en" >Used when referencing a directory style "NameType". No characters are prohibited.</documentation> </annotation> <restriction base="string"/> </simpleType> With: <simpleType name="NameReferenceType"> <annotation> <documentation xml:lang="en">Used when referencing a directory style "NameType". All characters are legal. All name references use a Unix 'like' name referencing mechanism across the SpaceSystem Tree (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage) where the '/', '..' and '.' are used to navigate through the hierarchy. The use of an unqualified name will search for an item in the current SpaceSystem first, then if none is found, in progressively higher SpaceSystems. A SpaceSystem is a name space (i.e., a named type declared in MetaCommandData is also declared in TelemetryMetaData - and vice versa).</documentation> </annotation> <restriction base="string"/> </simpleType> Disposition: Resolved
Container/Argument/Stream/Type/etc... -- ALL refs (anything that's a sibling of NameReferenceType?) *should* follow the same format
Resolution: Merged with issue 8923 (cleanup of parameterRefType documentation) Disposition: Duplicate
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... ?
Resolution: Merged with issue 8923 (cleanup of parameterRefType documentation) Disposition: Duplicate
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
Resolution: Merged with issue 8923 (cleanup of parameterRefType documentation) Disposition: Duplicate
-- 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."
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?
Resolution: sizeInBits has value where the Parameter does not originate from a telemetered source (i.e. it is a derived Parameter or is simply used on the T&C side only). While the name 'sizeInBits' is duplicative of the Encoding sizeInBits, since their contexts are different, no name change seems necessary. Disposition: Closed
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