Issues for XTCE Revision Task Force

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 8875: proposed schema change for documentation issue (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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:
Revised Text: This revision was significantly affected by the changes for issue 9200, and is incorporated into that revision.
Actions taken:
June 23, 2005: received issue
April 19, 2007: closed issue

Discussion:

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.

Issue 8885: includeCondition in commandContainer issue (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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:
Revised Text:
Actions taken:
June 28, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  The Container inheritance feature can be used to implement this requested feature.

Issue 8905: lack of delta limits (MER + JWST) (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 21, 2005: received issue
April 19, 2007: closed issue

Discussion:

This issue is a duplicate of  issue 10158 which is resolved.

Issue 8906: command side seems to be missing the ability to have repeat arguments (MER) (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

CommandContainerSet does not have argumentRefEntry

Resolution:
Revised Text:
Actions taken:
June 21, 2005: received issue
April 19, 2007: closed issue

Discussion:

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

Issue 8910: lack of clean way to describe "system variables", (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

 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:
Revised Text:
Actions taken:
June 21, 2005: received issue
April 19, 2007: closed issue

Discussion:

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.

Issue 8911: lack of clean way to describe multiple documentary type items (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
June 21, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Merged with issue 8875 to provide a more robust documentation capability.

Issue 8912: no tracking mechanism per PARAMETER for changes (no change log) (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

 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:
Revised Text:
Actions taken:
June 21, 2005: received issue
April 19, 2007: closed issue

Discussion:

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.

Issue 8913: Variable length command packets must be supported (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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:
Revised Text:
Actions taken:
June 21, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Not sure what change is requested, since XTCE has a superset of the needed functionality.  Disposition:	Closed

Issue 8914: JPL MER schema supports "hardware commands (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 22, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

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

Issue 8915: JWST, non-CCSDS header commands, routing info (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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:
Revised Text:
Actions taken:
June 22, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Capability is covered with changes resulting from issue 8875  Disposition:	Duplicate

Issue 8916: XTCE Command "Permissions" model may not be generic enough (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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:
Revised Text:
Actions taken:
June 22, 2005: received issue
April 19, 2007: closed issue

Discussion:

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

Issue 8923: proper reference formed weak (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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:
Revised Text:
Actions taken:
July 6, 2005: received issue
April 19, 2007: closed issue

Discussion:

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

Issue 8924: Container/Argument/Stream/Type/etc (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
July 6, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Merged with issue 8923 (cleanup of parameterRefType documentation)  Disposition:	Duplicate

Issue 8925: Clarification is needed on Ref names "local" to a spaceSystem (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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:
Revised Text:
Actions taken:
July 6, 2005: received issue
April 19, 2007: closed issue. duplicate

Discussion:

Resolution:  Merged with issue 8923 (cleanup of parameterRefType documentation)  Disposition:	Duplicate

Issue 8926: Ref rules should be spelled out (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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:
Revised Text:
Actions taken:
July 6, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Merged with issue 8923 (cleanup of parameterRefType documentation)  Disposition:	Duplicate

Issue 8928: sizeInBits (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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:
Revised Text:
Actions taken:
July 9, 2005: received issue
April 19, 2007: closed issue

Discussion:

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

Issue 9199: CalibratorType (xtce-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Critical
Summary:

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.

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  This is related to separate calibration and alarm sets. A schema change will be submitted by ESA on another issue.  Disposition:	Duplicate

Issue 9200: CalibratorType (02) (xtce-rtf)

Nature: Enhancement
Severity: Critical
Summary:

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

Issue 9201: CalibratorType (03) (xtce-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Duplicate of issue 8908, part of that issue is deferred.  Disposition: Duplicate

Issue 9202: SplineCalibrator (xtce-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Unsigned integer values are allowed to be prefixed with 0x or 0o in order to indicate a hexadecimal or octal value, respectively.  The assumed radix is decimal.  Disposition: Closed

Issue 9203: ToString and Booleans (xtce-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Issue is a duplicate of 10174 which is deferred.  Disposition: Duplicate

Issue 9205: NumericAlarmConditionTy (xtce-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Critical
Summary:

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.

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Alarms have been defined for all parameter-types in telemetry.    Revised Text:  Changes were affected by Validity issue 10185 and are shown in that section.  Disposition: Resolved

Issue 9207: MetaCommand (xtce-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  This sort of "flag" information is very specific to particular implemenations and as such no clear way is given in XTCE to handle it.  The preferred way at this time is to hold that information in a system unique document, or in a system unique way in XTCE.  In either case, that type of information must be documented before given to another party.  Duplicate of 8910 which was closed with no changes.  Disposition: Duplicate

Issue 9208: Command/Parameter (xtce-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

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

Resolution:
Revised Text: Existing schema text <complexType name="MetaCommandType" mixed="false"> <annotation> <documentation xml:lang="en">A type definition used as the base type for a CommandDefinition</documentation> </annotation> <complexContent mixed="false"> <extension base="xtce:NameDescriptionType"> <sequence> <element name="BaseMetaCommand" minOccurs="0"> <annotation> <documentation xml:lang="en">The MetaCommand is derived from this Base. Arguments of the base MetaCommand are further specified.</documentation> </annotation> <complexType> <sequence> <element name="ArgumentAssignmentList" minOccurs="0"> <complexType> <sequence> <element name="ArgumentAssignment" maxOccurs="unbounded"> <complexType> <attribute name="argumentName" type="xtce:NameReferenceType" use="required"/> <attribute name="argumentValue" type="string" use="required"/> </complexType> </element> </sequence> </complexType> </element> </sequence> <attribute name="metaCommandRef" type="xtce:NameReferenceType" use="required"/> </complexType> </element> <element name="SystemName" type="string" minOccurs="0"> <annotation> <documentation xml:lang="en">Optional. Normally used when the database is built in a flat, non-hierarchical format</documentation> </annotation> </element> <element name="ArgumentList" minOccurs="0"> <annotation> <documentation xml:lang="en">Many commands have one or more options. These are called command arguments. Command arguments may be of any of the standard data types. MetaCommand arguments are local to the MetaCommand.</documentation> </annotation> <complexType> <choice maxOccurs="unbounded"> <element name="Argument" maxOccurs="unbounded"> <annotation> <appinfo>Need to ensure that the named types actually exist</appinfo> </annotation> <complexType> <complexContent> <extension base="xtce:NameDescriptionType"> <attribute name="argumentTypeRef" type="xtce:NameReferenceType" use="required"/> Insert attribute <attribute name="initialValue" type="string"> <annotation> <documentation xml:lang="en">Used to set the initial calibrated values of Arguments. Will overwrite an initial value defined for the ArgumentType. For integer types base 10 (decimal) form is assumed unless: if proceeded by a 0b or 0B, value is in base two (binary form, if proceeded by a 0o or 0O, values is in base 8 (octal) form, or if proceeded by a 0x or 0X, value is in base 16 (hex) form. Floating point types may be specified in normal (100.0) or scientific (1.0e2) form. Time types are specified using the ISO 8601 formats described for XTCE time data types. Initial values for string types, may include C language style (\n, \t, \", \\, etc.) escape sequences. Initial values for Array or Aggregate types may not be set.</documentation> </annotation> </attribute> End of insertion </extension> � More Existing schema text <complexType name="ParameterSetType"> <annotation> <documentation xml:lang="en">Used by both the TelemetryMetaData and the CommandMetaData components each may be built independently.</documentation> </annotation> <choice maxOccurs="unbounded"> <element name="Parameter"> <annotation> <appinfo>Need to ensure that the named types actually exist</appinfo> </annotation> <complexType> <complexContent> <extension base="xtce:NameDescriptionType"> <sequence> <element name="ParameterProperties" type="xtce:ParameterPropertiesType" minOccurs="0"/> </sequence> <attribute name="parameterTypeRef" type="xtce:NameReferenceType" use="required"/> Insert attribute <attribute name="initialValue" type="string" use="optional"> <annotation> <documentation xml:lang="en">Used to set the initial calibrated values of Parameters. Will overwrite an initial value defined for the ParameterType. For integer types base 10 (decimal) form is assumed unless: if proceeded by a 0b or 0B, value is in base two (binary form, if proceeded by a 0o or 0O, values is in base 8 (octal) form, or if proceeded by a 0x or 0X, value is in base 16 (hex) form. Floating point types may be specified in normal (100.0) or scientific (1.0e2) form. Time types are specified using the ISO 8601 formats described for XTCE time data types. Initial values for string types, may include C language style (\n, \t, \", \\, etc.) escape sequences. Initial values for Array or Aggregate types may not be set.</documentation> <appinfo>The value type must match the Parameter type</appinfo> </annotation> </attribute> End of insertion </extension> </complexContent> </complexType> </element> <element name="ParameterRef" type="xtce:ParameterRefType"> <annotation> <documentation xml:lang="en">Used to include a Parameter defined in another sub-system in this sub-system.</documentation> </annotation> </element> </choice> </complexType>
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Add Boolean flag to determine if initialValue is calibrated or not.  Add "typeless" initialValue to parameter so initialValue can be stored as String.  ESA submitting proposed Schema change

Issue 9209: Verifiers (xtce-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Critical
Summary:

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

Resolution:
Revised Text: Combined with issue 9210 for resolution. Revised text is shown there.
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  CommandVerifierType was changed to be an extension of the OptionalNameDescriptionType so that it would allow an optional name and short description.

Issue 9210: Command verifiers (xtce-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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.

Resolution:
Revised Text: Replace <complexType name="CommandVerifierType"> <annotation> <documentation>A command verifier is used to check that the command has be successfully executed. Command Verifiers may be either a Custom Algorithm or a Boolean Check or the presence of a Container for a relative change in the value of a Parameter. The timeToWait is a time period where the verification must test true.</documentation> </annotation> <choice> <element name="Comparison" type="xtce:ComparisonType"/> <element name="ComparisonList"> <annotation> <documentation>All comparisons must be true</documentation> </annotation> <complexType> <sequence> <element name="Comparison" type="xtce:ComparisonType" maxOccurs="unbounded"/> </sequence> </complexType> </element> <element name="BooleanExpression" type="xtce:BooleanExpressionType"/> <element name="ContainerRef" type="xtce:ContainerRefType"> <annotation> <documentation>When verification is the existance of a Container</documentation> </annotation> </element> <element name="ParameterValueChange"> <annotation> <documentation>Used to look for relative change in a Parameter value. Only usefull for numeric Parameters</documentation> </annotation> <complexType> <sequence> <element name="ParameterRef" type="xtce:ParameterRefType"/> <element name="Change"> <complexType> <attribute name="value" type="decimal" use="required"/> </complexType> </element> </sequence> </complexType> </element> <element name="CustomAlgorithm" type="xtce:InputAlgorithmType"/> </choice> <attribute name="timeToWait" type="xtce:RelativeTimeType" use="required"> <annotation> <documentation>Specifies how much time to provide for the verification. </documentation> </annotation> </attribute> </complexType> With <complexType name="CommandVerifierType"> <annotation> <documentation xml:lang="en">A command verifier is used to check that the command has been successfully executed. Command Verifiers may be either a Custom Algorithm or a Boolean Check or the presence of a Container for a relative change in the value of a Parameter. The CheckWindow is a time period where the verification must test true to pass.</documentation> </annotation> <complexContent> <extension base="xtce:OptionalNameDescriptionType"> <sequence> <choice> <element name="ComparisonList"> <annotation> <documentation xml:lang="en">All comparisons must be true</documentation> </annotation> <complexType> <sequence> <element name="Comparison" type="xtce:ComparisonType" maxOccurs="unbounded"/> </sequence> </complexType> </element> <element name="ContainerRef" type="xtce:ContainerRefType"> <annotation> <documentation xml:lang="en">When verification is a new instance the referenced Container</documentation> </annotation> </element> <element name="ParameterValueChange"> <annotation> <documentation xml:lang="en">Used to look for relative change in a Parameter value. Only useful for numeric Parameters</documentation> </annotation> <complexType> <sequence> <element name="ParameterRef" type="xtce:ParameterRefType"/> <element name="Change"> <complexType> <attribute name="value" type="decimal" use="required"/> </complexType> </element> </sequence> </complexType> </element> <element name="CustomAlgorithm" type="xtce:InputAlgorithmType"/> <element name="BooleanExpression" type="xtce:BooleanExpressionType"/> <element name="Comparison" type="xtce:ComparisonType"/> </choice> <choice> <element name="CheckWindow"> <complexType> <attribute name="timeToStartChecking" type="xtce:RelativeTimeType"/> <attribute name="timeToStopChecking" type="xtce:RelativeTimeType" use="required"/> <attribute name="timeWindowIsRelativeTo" default="timeLastVerifierPassed"> <simpleType> <restriction base="string"> <enumeration value="commandRelease"/> <enumeration value="timeLastVerifierPassed"/> </restriction> </simpleType> </attribute> </complexType> </element> <element name="CheckWindowAlgorithms"> <annotation> <documentation xml:lang="en">Used when times must be calculated</documentation> </annotation> <complexType> <sequence> <element name="StartCheck" type="xtce:InputAlgorithmType"/> <element name="StopTime" type="xtce:InputAlgorithmType"/> </sequence> </complexType> </element> </choice> </sequence> </extension> </complexContent> </complexType> Insert after complexType ParameterToSetType <simpleType name="VerifierEnumerationType"> <annotation> <documentation xml:lang="en">An enumerated list of verifier types</documentation> </annotation> <restriction base="string"> <enumeration value="release"/> <enumeration value="transferredToRange"/> <enumeration value="sentFromRange"/> <enumeration value="received"/> <enumeration value="accepted"/> <enumeration value="queued"/> <enumeration value="executing"/> <enumeration value="complete"/> <enumeration value="failed"/> </restriction> </simpleType>
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  CustomAlgorithm and CheckWindow elements were added to the CommandVerifierType

Issue 9211: ArgumentType / ValidRange (xtce-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Critical
Summary:

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)

Resolution:
Revised Text: Insert after � CommandDefinitionType � as first complexType in Command schema <complexType name="ArgumentTypeSetType"> <annotation> <documentation xml:lang="en">Holds the list of argument type definitions. </documentation> </annotation> <choice maxOccurs="unbounded"> <element name="StringArgumentType" type="xtce:StringDataType"/> <element name="EnumeratedArgumentType" type="xtce:EnumeratedDataType"/> <element name="IntegerArgumentType"> <complexType> <complexContent> <extension base="xtce:IntegerDataType"> <sequence> <element name="ValidRangeSet" minOccurs="0"> <annotation> <documentation xml:lang="en">Numerical ranges that define the universe of valid values for this argument. Used to further bound argument values inside the ValidRange for the overall Data Type</documentation> </annotation> <complexType> <sequence> <element name="ValidRange" type="xtce:IntegerRangeType" maxOccurs="unbounded"/> </sequence> <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/> </complexType> </element> </sequence> </extension> </complexContent> </complexType> </element> <element name="BinaryArgumentType" type="xtce:BinaryDataType"/> <element name="FloatArgumentType"> <complexType> <complexContent> <extension base="xtce:FloatDataType"> <sequence> <element name="ValidRangeSet" minOccurs="0"> <annotation> <documentation xml:lang="en">Numerical ranges that define the universe of valid values for this argument. Used to further bound argument values inside the ValidRange for the overall Data Type</documentation> </annotation> <complexType> <sequence> <element name="ValidRange" type="xtce:FloatRangeType" maxOccurs="unbounded"/> </sequence> <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/> </complexType> </element> </sequence> </extension> </complexContent> </complexType> </element> <element name="BooleanArgumentType" type="xtce:BooleanDataType"/> <element name="RelativeTimeAgumentType" type="xtce:RelativeTimeDataType"/> <element name="AbsoluteTimeArgumentType" type="xtce:AbsoluteTimeDataType"/> <element name="ArrayArgumentType" type="xtce:ArrayDataTypeType"/> <element name="AggregateArgumentType" type="xtce:AggregateDataType"/> </choice> </complexType> Insert after � CommandDefinitionType � as first complexType in Command schema
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  ValidRangeSet added.

Issue 9212: UnitSet (xtce-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Duplicate of issue 10153.  Disposition:	Duplicate

Issue 9213: ParameterType (xtce-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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.

Resolution:
Revised Text: Existing schema text <complexType name="BaseDataType" abstract="true"> <annotation> <documentation xml:lang="en">An abstract type used by within the schema to derive other data types by the ground system. </documentation> </annotation> <complexContent> <extension base="xtce:NameDescriptionType"> <sequence> <element name="UnitSet"> <complexType> <sequence> <element name="Unit" type="xtce:UnitType" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> </element> <choice minOccurs="0"> <element name="BinaryDataEncoding" type="xtce:BinaryDataEncodingType"/> <element name="FloatDataEncoding" type="xtce:FloatDataEncodingType"/> <element name="IntegerDataEncoding" type="xtce:IntegerDataEncodingType"/> <element name="StringDataEncoding" type="xtce:StringDataEncodingType"/> </choice> </sequence> The following attribute is inserted into complexType BaseDataType <attribute name="baseType" type="xtce:NameReferenceType"> <annotation> <documentation xml:lang="en">Used to derive one Data Type from another - will inherit all the attributes from the baseType any of which may be redefined in this type definition. </documentation> <appinfo>Must be derived from a like type (e.g,, String from String). No circular derivations. </appinfo> </annotation> </attribute> End of insertion </extension> </complexContent> </complexType>
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Added "baseType" to allow inheritance mechanism of types

Issue 9214: Algorithm for derived (xtce-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Definition of a schema for complex derivation algorithms was intentionally left out of the XTCE specification.  It is possible to use a simple algorithm (arithmetic combination of two parameters) or reference a named algorithm that is externally defined.

Issue 9215: Argument set (xtce-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: ArgumentArrayType was superseded by the ArgumentTypeSetType changes in issue 9211.
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  ArgumentArrayType is now spelled correctly

Issue 9216: CommandContainer/Entry (xtce-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text: Changes for initial values of parameters and arguments were affected by the resolutions of issues 10153 and 9208. Revised text is shown there
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Added initialValue override for Parameter and Argument.

Issue 9217: BlockMetaCommandType (xtce-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Duplicate of issue 10186 which is closed without change.  Command sequences (beyond simple sequences that can be defined within a container) are to be considered by other specifications.  Disposition:		Duplicate

Issue 9218: Parameters (xtce-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Duplicate of 10169 which is deferred due to complexity.  Disposition: Duplicate

Issue 9219: SpaceSystemType (xtce-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Duplicate of issue 10162 which is resolved.  Disposition:	Duplicate

Issue 9220: Aliases (xtce-rtf)

Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  There are intentionally no restrictions on alias naming.  Enforcement of a particular alias naming scheme however is system dependent and not related to definition exchange other than the documentation of the naming scheme which is allowed in the SpaceSystem definition.

Issue 9223: NameType (xtce-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 1, 2005: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  The NameDescriptionType (see issue 9200) has been included in almost all the major elements.  If any are missing, they need to be added.  This type is now in Calibrator for example.  Any other areas should be submitted with proposed Schema change.

Issue 10153: 1 - move initialValue and UnitSet to ParameterSet (ESA-08) (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: <element name="Parameter"> <annotation> <appinfo>Need to ensure that the named types actually exist</appinfo> </annotation> <complexType> <complexContent> <extension base="xtce:NameDescriptionType"> <sequence> <element name="ParameterProperties" type="xtce:ParameterPropertiesType" minOccurs="0"/> </sequence> <attribute name="parameterTypeRef" type="xtce:NameReferenceType" use="required"/> <attribute name="initialValue" type="string" use="optional"> � </element>
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  initialValue of type "string" created in ParameterSet area, overrides an initialValue supplied in the ParameterType area, format flexible for ParameterType.

Issue 10154: Expand explanatory material (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Replace: Figure 1 CommandMetaData With: Figure 2 CommandMetaData UML Class Diagram Replace: 6.1.3.1 ArgumentTypeSet An ArgumentTypeSet is an unordered collection of ArgumentTypes. ArgumentTypes (very similar to ParameterTypes) are the MetaData for Command Arguments; ArgumentTypes are instantiated to create Arguments. ArgumentType contains the description of something that can have a value and is used as an operator supplied option to a Command (Command Argument). Information contained in ArgumentType includes the data type, description, valid range, engineering units and string conversion specifications and calibrations. Most Arguments, are sent via a data link and must also include information about how the value is encoded for transmission. This information includes size in bits, byte order, data type, and parity checks. All of the encoding information is in the Encoding area With: 6.1.3.1 ArgumentTypeSet ArgumentTypes serve the same function for Arguments as ParameterTypes to Parameters and are closely related, both in terms of content and function: a command argument must also have an ArgumentType defined in the command ArgumentTypeSet area. An ArgumentTypeSet is an unordered collection of ArgumentTypes. ArgumentTypes (very similar to ParameterTypes) are the MetaData for Command Arguments; ArgumentTypes are instantiated to create Arguments. ArgumentType contains the description of something that can have a value and is used as an operator supplied option to a Command (Command Argument). Information contained in ArgumentType includes the argument's data type, description, valid range, engineering units and string conversion specifications and calibrations. Most Arguments are sent via a data link and must also include information about how the value is encoded for transmission. This information includes size in bits, byte order, data type, and parity checks. All of the encoding information in ArgumentType is in one of four different 'DataEncoding' elements. XTCE supports four different types of DataEncodings: IntegerDataEncoding, FloatDataEncoding, StringEncoding and BinaryDataEncoding. Note that the data encoding element only speaks to how the Command argument is transmitted, not how it is handled on the SpaceSystem or ground.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:   Non-normative portion of XTCE 1.1 specifications extended

Issue 10155: Expand explanatory material related to "Figure 2" (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Figure 2 was replaced with more complete UML diagram and associated with subsections by class name as part of issue 10159.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:   Explanatory non-normative text extended in XTCE 1.1

Issue 10156: 4 -- Expand explanatory material related to "Figure 4" (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: With: A ParameterTypeSet is an unordered collection of ParameterTypes. ParameterTypes are the MetaData for Parameters; ParameterTypes are instantiated to create Parameters. ParameterType is the description of something that can have a value (a Parameter). Information contained in ParameterType includes the data type, description, alarm limits, engineering units and string conversion 'ToString' specifications. Parameters may be of variable length. Most Parameters are telemetered parameters (a.k.a measurands) and must also include information about how the Parameter value is encoded for transmission. This information includes size in bits, byte order, data type, calibrations and parity checks. All of the encoding information is in one of four different 'DataEncoding' elements. XTCE supports four different types of encodings: IntegerDataEncoding: specifies the bit order, size in bits, the encoding (unsigned, signMagnitude, twosCompliment, onesCompliment, BCD, or packedBCD). The byte order in the case of multi byte integers can also be specified, along with error detection (CRC or Parity checks). FloatDataEncoding: specifies the bit order, size in bits, the encoding (IEEE754_1985 or MILSTD_1750A). The byte order in the case of multi byte floats can also be specified, along with error detection (CRC or Parity checks). StringEncoding: specifies the bit order, the encoding (UTF-8 or UTF-16), the size in bits or variable size determined by either a termination character, or a leading size parameter, along with error detection (CRC or Parity checks). BinaryDataEncoding: specifies the bit order, the size in bits, and two algorithms to convert to and from the endcode value, along with error detection (CRC and Parity checks). Note that the data encoding type only speaks to how the Parameter (or Command argument) is transmitted, not how it is handled on the SpaceSystem or ground. Figure 9 presents the UML representation of the Parameter Type Set, and therefore all available data types. Encoding data types are children of these elements and not depicted in that figure.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:   Explanatory non-normative text extended in XTCE 1.1

Issue 10157: 5 -- Expand explanatory material related to "Figure 6" (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

5 -- Expand explanatory material related to "Figure 6" in the non-normative part of the XTCE specification (ESA-053)    Expanded in XTCE 1.1

Resolution:
Revised Text: 6.1.2.5 StreamSet Replace: A StreamSet is an unordered collection of Streams. Spacecraft uplinks and spacecraft downlinks are digital streams of data and are there are a number of processing functions that are done on the stream level. The stream section contains the knowledge for how to assemble, disassemble and process spacecraft uplink and downlink streams. With: A StreamSet is an unordered collection of Streams. Spacecraft uplinks and spacecraft downlinks are digital streams of data and there are a number of processing functions that are done on the stream level. The StreamSet in a SpaceSystem XTCE document can contain all of the information on how to assemble, disassemble and process spacecraft uplink and downlink streams for that SpaceSystem. There are three possible Streams types: VariableFrameStream for streams containing variable length streams, FixedFrameStream for streams containing fixed length streams and a custom stream that can be used to define any other kind of stream needed (The name of a Custom Algorithms are given for processing these streams).
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:   Explanatory non-normative text extended in XTCE 1.1

Issue 10158: 6 - Add Delta Alarms to XTCE (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

6 - Add Delta Alarms to XTCE (ESA-016)    Delta Alarms support added in XTCE 1.1, in the ChangeAlarm area

Resolution:
Revised Text: Before: <element name="ChangePerSecondAlarmRanges" type="xtce:AlarmRangesType" minOccurs="0"> <annotation> <documentation>ChangePerSecondAlarmRanges are used to trigger alarms when the parameter value's rate-of-change passes some threshold value. An alarm condition that triggers when the value changes too fast (or too slow)</documentation> </annotation> </element> After: <element name="ChangeAlarmRanges" minOccurs="0"> <annotation> <documentation xml:lang="en">ChangeAlarmRanges are used to trigger alarms when the parameter value's rate-of-change is either too fast or too slow. The change may be with respect to time (the default) or with respect to samples (delta alarms) - the changeType attribute determines this. The change may also be ether relative (as a percentage change) or absolute as set by the changeBasis attribute. The alarm also requires the spanOfInterest in both samples and seconds to have passed before it is to trigger. For time based rate of change alarms, the time specified in spanOfInterestInSeconds is used to calculate the change. For sample based rate of change alarms, the change is calulated over the number of samples specified in spanOfInterestInSeconds.</documentation> </annotation> <complexType> <complexContent> <extension base="xtce:AlarmRangesType"> <attribute name="changeType" default="changePerSecond"> <simpleType> <restriction base="string"> <enumeration value="changePerSecond"/> <enumeration value="changePerSample"/> </restriction> </simpleType> </attribute> <attribute name="changeBasis" default="absoluteChange"> <simpleType> <restriction base="string"> <enumeration value="absoluteChange"/> <enumeration value="percentageChange"/> </restriction> </simpleType> </attribute> <attribute name="spanOfInterestInSamples" type="positiveInteger" default="1"/> <attribute name="spanOfInterestInSeconds" type="decimal" default="0"/> </extension> </complexContent> </complexType> </element>
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:    Delta Alarms support added in XTCE 1.1, in the ChangeAlarm area  add the following type of alarm;    	delta-check alarm with the following data:  	* Validity condition (to know if the test is applicable)  	* The delta threshold (raw or calibrated value of the threshold)  	* An indication to say if this is a minimum or a maximum delta check (attribute)  	* As required in JM-013, a label to indicate the activity triggered by a positive alarm

Issue 10159: 7 - Expand explanatory material related to "Figure 2" (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

7 - Expand explanatory material related to "Figure 2" in the non-normative part of the XTCE specification (ESA-034)    Extended in XTCE 1.1, this is similar to ESA-039

Resolution:
Revised Text: Previous figure: Figure 3 SpaceSystem New figure and footnote: Figure 4 SpaceSystem UML Class Diagram 'AnonymousType' is used in the UML whenever a new complexType is generated inside an Element definition (without a named ComplexType).
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:   Figure replaced and section names match class names

Issue 10160: 8 - Expand explanatory material related to "Figure 3" (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

8 - Expand explanatory material related to "Figure 3" in the non-normative part of the XTCE specification (ESA-040)    Expanded in XTCE 1.1

Resolution:
Revised Text: Replace: Figure 5 Telemetry MetaData With: Figure 6 Telemetry MetaData UML Class Diagram
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Figure replaced, additional explanations added with revised text in issues 10250, 10251, 10255, 10256, & 10260.

Issue 10161: 9 -- Expand explanatory for certain terms, Data Type and Data Encoding Type (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: The changes for this issue are incorporated within the changes for issue 10156.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:   Explanatory text extended in XTCE 1.1

Issue 10162: 10 - Add indicator of operational status to XTCE (JPL-004) (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

10 - Add indicator of operational status to XTCE (JPL-004)    Not completed

Resolution:
Revised Text: Replace <complexType name="SpaceSystemType" mixed="false"> <annotation> <documentation>SpaceSystem is a collection of SpaceSystem(s) including space assets, ground assets, multi-satellite systems and sub-systems. A SpaceSystem is the root element for the set of data necessary to monitor and command an arbitrary space device - this includes the binary decomposition the data streams going into and out of a device.</documentation> </annotation> <complexContent mixed="false"> <extension base="xtce:NameDescriptionType"> <sequence> <element name="Header" type="xtce:HeaderType" minOccurs="0"/> <element name="TelemetryMetaData" type="xtce:TelemetryMetaDataType" minOccurs="0"/> <element name="CommandMetaData" type="xtce:CommandMetaDataType" minOccurs="0"/> <element name="ServiceSet" minOccurs="0"> <annotation> <documentation>A service is a logical grouping of container and/or messages.</documentation> </annotation> <complexType> <sequence> <element name="Service" type="xtce:ServiceType" maxOccurs="unbounded"/> </sequence> </complexType> </element> <element name="Defaults" minOccurs="0"> <annotation> <documentation>Defaults has default data encoding for ParameterTypes and ArgumentTypes and default parameter time association that will be applied to all Parameters within this SpaceSystem. These defaults may be overidden by sub-SpaceSystems or by the Types or Parameters themselves. Defaults simply provides a means to avoid repeating attributes such as 'bit order' for every Type definition.</documentation> </annotation> <complexType> <sequence> <element name="DefaultDataEncoding" type="xtce:DataEncodingType" minOccurs="0"> <annotation> <documentation>Since the data encoding (bit order and byte order) is normally the same throughout a spacesystem, using this element allows that data encoding to be specified as a default.</documentation> </annotation> </element> <element name="ParameterTimeAssociation" type="xtce:TimeAssociationType" minOccurs="0"> <annotation> <documentation>Default time to associate each ParameterInstance with.</documentation> </annotation> </element> </sequence> </complexType> </element> <element ref="xtce:SpaceSystem" minOccurs="0" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType> With <complexType name="SpaceSystemType" mixed="false"> <annotation> <documentation xml:lang="en">SpaceSystem is a collection of SpaceSystem(s) including space assets, ground assets, multi-satellite systems and sub-systems. A SpaceSystem is the root element for the set of data necessary to monitor and command an arbitrary space device - this includes the binary decomposition the data streams going into and out of a device.</documentation> </annotation> <complexContent mixed="false"> <extension base="xtce:NameDescriptionType"> <sequence> <element name="Header" type="xtce:HeaderType" minOccurs="0"/> <element name="TelemetryMetaData" type="xtce:TelemetryMetaDataType" minOccurs="0"/> <element name="CommandMetaData" type="xtce:CommandMetaDataType" minOccurs="0"/> <element name="ServiceSet" minOccurs="0"> <annotation> <documentation xml:lang="en">A service is a logical grouping of container and/or messages.</documentation> </annotation> <complexType> <sequence> <element name="Service" type="xtce:ServiceType" maxOccurs="unbounded"/> </sequence> </complexType> </element> <element ref="xtce:SpaceSystem" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="operationalStatus" type="token" use="optional"/> </extension> </complexContent> </complexType>
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  A tag will be added at the space system level, to identify the current operational status

Issue 10163: Change service set to either accept Messages or Container references (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

1 - Change service set to either accept Messages or Container references (ESA-004)    Schema changed in XTCE 1.1

Resolution:
Revised Text: Before <complexType name="ServiceType"> <annotation> <documentation xml:lang="en">Holds a set of services, logical groups of containers OR messages (not both).</documentation> </annotation> <complexContent> <extension base="xtce:NameDescriptionType"> <sequence> <element name="MessageRefSet" minOccurs="0"> <complexType> <sequence> <element name="MessageRef" maxOccurs="unbounded"/> </sequence> </complexType> </element> <element name="ContainerRefSet"> <complexType> <sequence> <element name="ContainerRef" type="xtce:ContainerRefType" maxOccurs="unbounded"/> </sequence> </complexType> </element> </sequence> </extension> </complexContent> </complexType> After <complexType name="ServiceType"> <annotation> <documentation xml:lang="en">Holds a set of services, logical groups of containers OR messages (not both).</documentation> </annotation> <complexContent> <extension base="xtce:NameDescriptionType"> <choice> <element name="MessageRefSet"> <complexType> <sequence> <element name="MessageRef" type="xtce:MessageRefType" maxOccurs="unbounded"/> </sequence> </complexType> </element> <element name="ContainerRefSet"> <complexType> <sequence> <element name="ContainerRef" type="xtce:ContainerRefType" maxOccurs="unbounded"/> </sequence> </complexType> </element> </choice> </extension> </complexContent> </complexType>
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Schema changed in XTCE 1.1  Change the cardinality of the containerrefset in services

Issue 10164: 2 - Add Aggregate (similar to C-structure) type to XTCE (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

  2 - Add Aggregate (similar to C-structure) type to XTCE (ESA-014)    Schema support added in XTCE 1.1, see AggregrateType in ParameterType area

Resolution:
Revised Text: Insert after complexType AbsoluteTimeDataType <complexType name="AggregateDataType"> <annotation> <documentation>Contains multiple values (as members) of any type</documentation> </annotation> <complexContent> <extension base="xtce:NameDescriptionType"> <sequence> <element name="MemberList"> <annotation> <documentation>Order is important only if the name of the AggregateParameter or Aggregate Argument is directly referenced in SequenceContainers. In this case the members are assued to be added sequentially (in the order listed here) into the Container.</documentation> </annotation> <complexType> <sequence> <element name="Member" maxOccurs="unbounded"> <annotation> <documentation>Each member of the Aggregate Data has a name and a reference to another DataType. The other DataType may be any other DataType. Circular references are not allowed.</documentation> <appinfo>ensure no circular references</appinfo> </annotation> <complexType> <attribute name="name" type="xtce:NameType" use="required"/> <attribute name="typeRef" type="xtce:NameReferenceType" use="required"/> </complexType> </element> </sequence> </complexType> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="ArrayDataTypeType"> <annotation> <documentation xml:lang="en">An array of values of the type referenced in 'arrayTypeRef' and have the number of array dimensions as specified in 'numberOfDimensions' </documentation> </annotation> <complexContent> <extension base="xtce:NameDescriptionType"> <attribute name="arrayTypeRef" type="xtce:NameReferenceType" use="required"/> <attribute name="numberOfDimensions" type="positiveInteger" use="required"/> </extension> </complexContent> </complexType>
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  proposed AggregateParameterType with XML example has been created.

Issue 10165: Expand explanatory material for XTCE types (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

3 - Expand explanatory material for XTCE types ParameterToSet and MetaCommand/Verifiers (ESA-071)    Expanded in XTCE 1.1

Resolution:
Revised Text: Before: The ParameterToSetList is an ordered collection of ParametersToSet. A ParameterToSet is a Parameter whose value will be set after the Command has reached a certain stage. New Parameters to Set are appended to the Base Command list After: The ParameterToSetList is an ordered collection of ParametersToSet. A ParameterToSet is a Parameter whose value will be set after the Command has reached a certain state - as determined by the MetaCommand verifiers. New Parameters to Set are appended to the Base Command list.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Agree, greater elaboration could be useful.   The Parameters should be set to new values in the order presented (to ensure any triggers are executed appropriately). The RID is accepted, and changes will be done shortly.

Issue 10166: 4 -- Add a name/short description to the argument's valid range set (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

4 -- Add a name/short description to the argument's valid range set (ESA-011)    Added OptionalNameDescriptionType to support this in XTCE 1.1

Resolution:
Revised Text: <complexType name="OptionalNameDescriptionType"> <annotation> <documentation xml:lang="en">The type definition used by most elements that have an optional name with optional descriptions. </documentation> </annotation> <complexContent> <extension base="xtce:DescriptionType"> <attribute name="name" type="xtce:NameType" use="optional"/> </extension> </complexContent> </complexType>
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Will make this an OptionalNameDescriptionType.Schema changed in XTCE 1.1

Issue 10167: 5 - Expand explanatory material in Figure 1 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

5 - Expand explanatory material in Figure 1 (ESA-026)    Expanded in XTCE 1.1

Resolution:
Revised Text: Figure 7 - Telemetric and Command Processing Meta Data Encapsulated in XTCE XML
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Telemetry streams and command streams are shown and captioned.

Issue 10168: 6 - Figures 2-10 not referenced in text (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

6 - Figures 2-10 not referenced in text (INPE-009)    References inserted in XTCE 1.1

Resolution:
Revised Text: References were added in the text updates for issues 10156 and 10251 for Figures 4 & 5.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Text Revised for Figures 4 & 5.  All figures appear in a section related by name to the figure.

Issue 10178: 1 - Add ability to describe general equations in Calibrator area (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Summary of Non-RID Requests    1 - Add ability to describe general equations in Calibrator area    General MathOperationCalibrator added to Calibration area, MathOperationType changed to support equations, effects other areas of schema where "MathOperation"s are used

Resolution:
Revised Text: Replace: <complexType name="CalibratorType"> <annotation> <documentation xml:lang="en">Calibrators are normally used to convert to and from bit compacted numerical data</documentation> </annotation> <choice> <element name="SplineCalibrator"> <annotation> <documentation xml:lang="en">A calibration type where a segmented line in a raw vs calibrated plane is described using a set of points. Raw values are converted to calibrated values by finding a position on the line coorosponding to the raw value. The algorithm triggers on the input parameter.</documentation> </annotation> <complexType> <sequence> <element name="SplinePoint" type="xtce:SplinePointType" minOccurs="2" maxOccurs="unbounded"/> </sequence> <attribute name="order" type="positiveInteger" default="1"/> <attribute name="extrapolate" type="boolean" default="false"/> </complexType> </element> <element name="PolynomialCalibrator" type="xtce:PolynomialType"> <annotation> <documentation>A calibration type where a curve in a raw vs calibrated plane is described using a set of polynomial coefficients. Raw values are converted to calibrated values by finding a position on the curve corresponding to the raw value. The first coefficient belongs with the X^0 term, the next coefficient belongs to the X^1 term and so on. </documentation> </annotation> </element> </choice> <attribute name="name" type="string" use="optional"/> </complexType> With: <complexType name="CalibratorType"> <annotation> <documentation xml:lang="en">Calibrators are normally used to convert to and from bit compacted numerical data</documentation> </annotation> <complexContent> <extension base="xtce:OptionalNameDescriptionType"> <choice> <element name="SplineCalibrator"> <annotation> <documentation xml:lang="en">A calibration type where a segmented line in a raw vs calibrated plane is described using a set of points. Raw values are converted to calibrated values by finding a position on the line corresponding to the raw value. The algorithm triggers on the input parameter.</documentation> </annotation> <complexType> <sequence> <element name="SplinePoint" type="xtce:SplinePointType" minOccurs="2" maxOccurs="unbounded"/> </sequence> <attribute name="order" type="positiveInteger" default="1"/> <attribute name="extrapolate" type="boolean" default="false"/> </complexType> </element> <element name="PolynomialCalibrator" type="xtce:PolynomialType"> <annotation> <documentation xml:lang="en">A calibration type where a curve in a raw vs calibrated plane is described using a set of polynomial coefficients. Raw values are converted to calibrated values by finding a position on the curve corresponding to the raw value. The first coefficient belongs with the X^0 term, the next coefficient belongs to the X^1 term and so on. </documentation> </annotation> </element> <element name="MathOperationCalibrator"> <complexType> <complexContent> <extension base="xtce:MathOperationType"/> </complexContent> </complexType> </element> </choice> </extension> </complexContent> </complexType> Replace: <complexType name="MathOperationType"> <annotation> <documentation xml:lang="en">A simple math operation</documentation> </annotation> <sequence> <choice> <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType"/> <element name="Value" type="string"> <annotation> <documentation>Value is assumed to be of the same type as the Parameter</documentation> </annotation> </element> </choice> <sequence minOccurs="0"> <element name="Operator" type="xtce:MathOperatorsType"/> <choice> <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType"/> <element name="Value" type="string"> <annotation> <documentation>Value is assumed to be of the same type as the Parameter</documentation> </annotation> </element> </choice> </sequence> </sequence> </complexType> With: <complexType name="MathOperationType"> <annotation> <documentation xml:lang="en">Postfix (aka Reverse Polish Notation (RPN)) notation is used to describe mathmatical equations. It uses a stack where operands (either fixed values or ParameterInstances) are pushed onto the stack from first to last in the XML. As the operators are specified, each pops off operands as it evaluates them, and pushes the result back onto the stack. In this case postfix is used to avoid having to specify parenthesis. To convert from infix to postfix, use Dijkstra's "shunting yard" algorithm.</documentation> </annotation> <choice maxOccurs="unbounded"> <element name="ValueOperand" type="double"> <annotation> <documentation xml:lang="en">Use a constant in the calculation</documentation> </annotation> </element> <element name="ThisParameterOperand"> <annotation> <documentation xml:lang="en">Use the value of this parameter in the calculation</documentation> </annotation> </element> <element name="ParameterInstanceRefOperand" type="xtce:ParameterInstanceRefType"> <annotation> <documentation xml:lang="en">Use the value of another Parameter in the calculation</documentation> </annotation> </element> <element name="Operator" type="xtce:MathOperatorsType"> <annotation> <documentation xml:lang="en">Binary operators: +, -, *, /, %, ^ operate on the top two values in the stack, leaving the result on the top of the stack. Unary operators: 1/x, x!, e^x, ln, log, and trigonometric operators operate on the top member of the stack also leaving the result on the top of the stack. 'ln' is a natural log where 'log' is a base 10 logarithm. Trigonometric operators use degrees. 'swap' swaps the top two members of the stack.</documentation> </annotation> </element> </choice> </complexType>
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  General MathOperationCalibrator added to Calibration area, MathOperationType changed to support equations, effects other areas of schema where "MathOperation"s are used.

Issue 10179: NASA-013 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Summary of Close RIDs  NASA-013: The non normative document (accompanying text) must stipulate the following: The use of XTCE is advocated as being appropriate for data exchange across organizational or product  boundaries, but is not required to be adopted as a recommended practice for the internal technical specification of command or telemetry data dictionaries or data streams within a particular system or product  RID RESPONSE:  The OMG cannot mandate the use of any specification - all OMG specifications are recommendations.  We suggest that this language be place in the XTCE Green book or Magenta book.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  The OMG cannot mandate the use of any specification - all OMG specifications are recommendations We suggest that this language be place in the CCSDS XTCE Green book or Magenta book.  Close

Issue 10180: ESA-002 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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). These models relate to the various developments of the final satellite. The Flight model is the complete satellite ready for launch, however there will be a number of engineering models, development models, breadboards and test facilities that are also built and tested during the satellite development and require a database exchange. These databases can be sent individually in a self contained database, or can be sent combined in a mission database which therefore needs the means to differentiate between what is valid for what model. This is further complicated with onboard software versioning which can also be included in the model list.  RID RESPONSE:  Recommend simply using SpaceSystem name attribute or XML file name to separate models.    According to another RID, a tag will be added at the space system level for the operational level of the   system (testing, operational, etc..)  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Recommend simply using SpaceSystem name attribute or XML file name to separate models.  According to another RID, a tag will be added at the space system level for the operational level of the system (testing, operational, etc.., issue 10162)   Close

Issue 10181: ESA-010 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

In SCOS-2000 calibrations curves are allowed to be described by one point only. In XTCE, a spline is   obviously defined by two points miminum. Please relax the constraint to two points  RID RESPONSE:  [ESA] close, withdraw  Boston: agree close  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Closed, withdrawn after discussion with ESA at Boston meeting.

Issue 10182: ESA-012 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

The MAP ID is situated in the segment (packet application data field). In ECSS there is a need for associating a label to the value of the MAP ID, describing the priority of it. In XTCE while describing a container, which could include the parameter MAP ID there is only the possiblity to include the value of the MAP itself (1-64). We would like to add the label high priority, low priority with the   MAP ID.  In ECSS, there is a list of MAP id associated to APID, with default MAP for such a process. This data can be recovered from browsing through all containers and extracting apid, map id values. But maybe a simpler way must exist?  Jennifer/Kevin/Gerry-reviewd, agree  Gerry recommends using AncillaryData.  Close/No-change.  Boston: close  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Closed, withdrawn after discussion with ESA at Boston meeting.

Issue 10183: ESA-013 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

ECSS E70-31 has dedicated table to create generic commands. In particular for CPDU, On/off devices, register loads and sensors data. Although dedicated commands could be written down as a whole, they may be sufficiently generic to be included in XTCE. From another point of view, with a good reuse of command structure, such commands can be easily formatted in XTCE. However some defaults values like cpdu duration units and cpdu max instr will have to fit somewhere. The best place would be at the space system default level (currently this kind of information could only fit in the space system ancillary data set.).  RID RESPONSE:  Discuss.  Recommend  creating a base command from which specific commands are inherited.  [ESA] ok with Gerry response  Jennifer/Kevin/Gerry-reviewed, agree  Boston: close

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Closed, withdrawn after discussion with ESA at Boston meeting.

Issue 10184: ESA-017 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  It is from our side believed that delta-check alarms and expected state check alarms are sufficiently generic and well spread to be included in XTCE.  Therefore we ask to add the following type of alarm;  expected check alarm with the following data:  �	Validity condition (to know if the test is applicable)  �	A list of expected values  �	As required in JM-013, a label to indicate the activity triggered by a positive alarm  	  [Ian] can you check is that can match to the ParameterToSetList in the MetaCommand element. What is missing for me is the reporting data referenced (namely where to find the parameter name to be setted by the telecommand). If this does the job then no RID to be raised.  RID RESPONSE:  [ESA] on ESA side, this is covered by StaticAlarmRange  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Closed after discussion at Boston meeting, this is covered by StaticAlarmRange.

Issue 10185: ESA-018 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  As a valid range set has been introduced instead of one unique range, it is now needed to have a validity condition that tells if the current range is applicable or not.  RID RESPONSE:  Conceivably, valid range could change with context, however, this seems obscure enough that the RTF   should consider whether the additional schema complexity is worth the cost.  Recommend Deferral.  [ESA] withdraw, this is being addressed  Boston: close  RID STATE:	CLOSE

Resolution:
Revised Text: Replace: <complexType name="BinaryDataType"> <annotation> <documentation>Contains an arbitrarily large binary value </documentation> </annotation> <complexContent> <extension base="xtce:BaseDataType"> <attribute name="initialValue" type="hexBinary"/> </extension> </complexContent> </complexType> With: <complexType name="BinaryDataType"> <annotation> <documentation xml:lang="en">Contains an arbitrarily large binary value </documentation> </annotation> <complexContent> <extension base="xtce:BaseDataType"> <attribute name="initialValue" type="hexBinary"> <annotation> <documentation xml:lang="en">Extra bits are truncated from the MSB (leftmost)</documentation> </annotation> </attribute> </extension> </complexContent> </complexType> Replace: <complexType name="EnumeratedDataType"> <annotation> <documentation>Contains an enumerated value - a value that has both an integral and a string representation.</documentation> </annotation> <complexContent> <extension base="xtce:BaseDataType"> <sequence> <element name="EnumerationList"> <complexType> <sequence> <element name="Enumeration" type="xtce:ValueEnumerationType" maxOccurs="unbounded"/> </sequence> </complexType> </element> </sequence> <attribute name="initialValue" type="string"/> </extension> </complexContent> </complexType> With: <complexType name="EnumeratedDataType"> <annotation> <documentation xml:lang="en">Contains an enumerated value - a value that has both an integral and a string representation.</documentation> </annotation> <complexContent> <extension base="xtce:BaseDataType"> <sequence> <element name="EnumerationList"> <complexType> <sequence> <element name="Enumeration" type="xtce:ValueEnumerationType" maxOccurs="unbounded"/> </sequence> </complexType> </element> </sequence> <attribute name="initialValue" type="string"> <annotation> <documentation xml:lang="en">Initial value is always given in calibrated form.</documentation> </annotation> </attribute> </extension> </complexContent> </complexType> Replace: <complexType name="FloatDataType"> <annotation> <documentation>Contains a floating point value</documentation> </annotation> <complexContent> <extension base="xtce:NumericDataType"> <attribute name="initialValue" type="decimal"/> <attribute name="sizeInBits" default="32"> <simpleType> <restriction base="positiveInteger"> <enumeration value="32"/> <enumeration value="64"/> <enumeration value="128"/> </restriction> </simpleType> </attribute> </extension> </complexContent> </complexType> With: <complexType name="FloatDataType"> <annotation> <documentation xml:lang="en">Contains a floating point value</documentation> </annotation> <complexContent> <extension base="xtce:NumericDataType"> <sequence> <element name="ValidRange" type="xtce:FloatRangeType" minOccurs="0"> <annotation> <documentation xml:lang="en">The Valid Range bounds the universe of possible values this Parameter may have.</documentation> </annotation> </element> </sequence> <attribute name="initialValue" type="double"> <annotation> <documentation xml:lang="en">Initial value is always given in calibrated form</documentation> </annotation> </attribute> <attribute name="sizeInBits" default="32"> <simpleType> <restriction base="positiveInteger"> <enumeration value="32"/> <enumeration value="64"/> <enumeration value="128"/> </restriction> </simpleType> </attribute> </extension> </complexContent> </complexType> Replace: <complexType name="BooleanDataType"> <annotation> <documentation>Contains a boolean value</documentation> </annotation> <complexContent> <extension base="xtce:BaseDataType"> <attribute name="initialValue" type="boolean"/> <attribute name="oneStringValue" type="string" default="True"/> <attribute name="zeroStringValue" type="string" default="False"/> </extension> </complexContent> </complexType> With: <complexType name="BooleanDataType"> <annotation> <documentation xml:lang="en">Contains a boolean value</documentation> </annotation> <complexContent> <extension base="xtce:BaseDataType"> <attribute name="initialValue" type="string"> <annotation> <documentation xml:lang="en">Initial value is always given in calibrated form. </documentation> <appinfo>Initial value must match either the oneStringValue or the zeroStringValue</appinfo> </annotation> </attribute> <attribute name="oneStringValue" type="string" default="True"/> <attribute name="zeroStringValue" type="string" default="False"/> </extension> </complexContent> </complexType> Replace: <complexType name="IntegerDataType"> <annotation> <documentation>Contains an integral value</documentation> </annotation> <complexContent> <extension base="xtce:NumericDataType"> <attribute name="initialValue" type="integer"> <annotation> <documentation>base 10 integer value</documentation> </annotation> </attribute> <attribute name="sizeInBits" type="positiveInteger" default="32"/> <attribute name="signed" type="boolean" default="true"/> </extension> </complexContent> </complexType> With: <complexType name="IntegerDataType"> <annotation> <documentation xml:lang="en">Contains an integral value</documentation> </annotation> <complexContent> <extension base="xtce:NumericDataType"> <sequence> <element name="ValidRange" type="xtce:IntegerRangeType" minOccurs="0"> <annotation> <documentation xml:lang="en">The Valid Range bounds the universe of possible values this Parameter may have.</documentation> </annotation> </element> </sequence> <attribute name="initialValue" type="xtce:FixedIntegerValueType"> <annotation> <documentation xml:lang="en">Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation> </annotation> </attribute> <attribute name="sizeInBits" type="positiveInteger" default="32"/> <attribute name="signed" type="boolean" default="true"/> </extension> </complexContent> </complexType> Replace: <complexType name="NumericDataType"> <annotation> <documentation>An abstract type that is a super type of either an Integer or Float Data type.</documentation> </annotation> <complexContent> <extension base="xtce:BaseDataType"> <sequence> <element name="ToString" type="xtce:NumberToStringType" minOccurs="0"/> <element name="ValidRange" minOccurs="0"> <complexType> <complexContent> <extension base="xtce:DecimalRangeType"/> </complexContent> </complexType> </element> <element name="DefaultCalibrator" type="xtce:CalibratorType" minOccurs="0"/> <element name="ContextCalibratorList" minOccurs="0"> <complexType> <sequence> <element name="ContextCalibrator" type="xtce:ContextCalibratorType" maxOccurs="unbounded"/> </sequence> </complexType> </element> </sequence> <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/> </extension> </complexContent> </complexType> With: <complexType name="NumericDataType"> <annotation> <documentation xml:lang="en">An abstract type that is a super type of either an Integer or Float Data type.</documentation> </annotation> <complexContent> <extension base="xtce:BaseDataType"> <sequence> <element name="ToString" minOccurs="0"> <complexType> <complexContent> <extension base="xtce:NumberToStringType"/> </complexContent> </complexType> </element> </sequence> <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/> </extension> </complexContent> </complexType> Replace: <complexType name="RelativeTimeDataType"> <annotation> <documentation>Used to contain a relative time value. Used to describe a relative time. Normally used for time offsets. A Relative time is expressed as PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision. For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, one would write: P1Y2M3DT10H30M. One could also indicate a duration of minus 120 days as: -P120D. An extension of Schema duration type. </documentation> </annotation> <complexContent> <extension base="xtce:BaseTimeDataType"/> </complexContent> </complexType> With: <complexType name="RelativeTimeDataType"> <annotation> <documentation xml:lang="en">Used to contain a relative time value. Used to describe a relative time. Normally used for time offsets. A Relative time is expressed as PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision. For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, one would write: P1Y2M3DT10H30M. One could also indicate a duration of minus 120 days as: -P120D. An extension of Schema duration type. </documentation> </annotation> <complexContent> <extension base="xtce:BaseTimeDataType"> <attribute name="initialValue" type="duration"/> </extension> </complexContent> </complexType> Replace: <complexType name="StringDataType"> <annotation> <documentation>Contains a String Value</documentation> </annotation> <complexContent> <extension base="xtce:BaseDataType"> <sequence> <element name="SizeRangeInCharacters" type="xtce:IntegerRangeType" minOccurs="0"/> <element name="DefaultCalibrator" type="xtce:CalibratorType" minOccurs="0"/> <element name="ContextCalibratorList" minOccurs="0"> <complexType> <sequence> <element name="ContextCalibrator" type="xtce:ContextCalibratorType"/> </sequence> </complexType> </element> </sequence> <attribute name="initialValue" type="string"/> <attribute name="restrictionPattern" type="string"/> <attribute name="characterWidth"> <simpleType> <restriction base="integer"> <enumeration value="8"/> <enumeration value="16"/> </restriction> </simpleType> </attribute> </extension> </complexContent> </complexType> With: <complexType name="StringDataType"> <annotation> <documentation xml:lang="en">Contains a String Value</documentation> </annotation> <complexContent> <extension base="xtce:BaseDataType"> <sequence> <element name="SizeRangeInCharacters" type="xtce:IntegerRangeType" minOccurs="0"/> </sequence> <attribute name="initialValue" type="string"> <annotation> <documentation xml:lang="en">Initial values for string types, may include C language style (\n, \t, \", \\, etc.) escape sequences.</documentation> </annotation> </attribute> <attribute name="restrictionPattern" type="string"> <annotation> <documentation xml:lang="en">restriction pattern is a regular expression</documentation> </annotation> </attribute> <attribute name="characterWidth"> <simpleType> <restriction base="integer"> <enumeration value="8"/> <enumeration value="16"/> </restriction> </simpleType> </attribute> </extension> </complexContent> </complexType> Replace: <complexType name="ContextAlarmType"> <annotation> <documentation>Context alarms are applied when the ContextMatch is true. Context alarms override Default alarms</documentation> </annotation> <complexContent> <extension base="xtce:NumericAlarmConditionType"> <sequence> <element name="ContextMatch" type="xtce:MatchCriteriaType"/> </sequence> </extension> </complexContent> </complexType> With: <complexType name="AlarmType" abstract="true"> <annotation> <documentation xml:lang="en">Alarms associated with numeric data types</documentation> </annotation> <choice minOccurs="0"> <element name="AlarmConditions" type="xtce:AlarmConditionsType"> <annotation> <documentation xml:lang="en">A MatchCriteria may be specified for each of the 5 alarm levels. Each level is optional and the alarm should be the highest level to test true.</documentation> </annotation> </element> <element name="CustomAlarm" type="xtce:InputAlgorithmType"> <annotation> <documentation xml:lang="en">An escape for ridiculously complex alarm conditions. Will trigger on changes to the containing Parameter. </documentation> </annotation> </element> </choice> <attribute name="minViolations" type="positiveInteger" default="1"> <annotation> <documentation xml:lang="en">Number of successive instances that meet the alarm conditions for the Alarm to trigger.</documentation> </annotation> </attribute> </complexType> Replace: <complexType name="DecimalRangeType"> <annotation> <documentation xml:lang="en">A range of numbers. "minInclusive", "minExclusive", "maxInclusive" and "maxExclusive" attributes are borrowed from the W3C schema language.</documentation> </annotation> <attribute name="minInclusive" type="decimal"/> <attribute name="minExclusive" type="decimal"/> <attribute name="maxInclusive" type="decimal"/> <attribute name="maxExclusive" type="decimal"/> </complexType> With: <complexType name="BinaryAlarmConditionType"> <annotation> <documentation xml:lang="en">Alarm conditions for Binary types</documentation> </annotation> <complexContent> <extension base="xtce:AlarmType"/> </complexContent> </complexType> <complexType name="BooleanAlarmType"> <annotation> <documentation xml:lang="en">Alarm conditions for Boolean types</documentation> </annotation> <complexContent> <extension base="xtce:AlarmType"/> </complexContent> </complexType> <complexType name="FloatRangeType"> <annotation> <documentation xml:lang="en">A range of numbers. "minInclusive", "minExclusive", "maxInclusive" and "maxExclusive" attributes are borrowed from the W3C schema language.</documentation> </annotation> <attribute name="minInclusive" type="double"/> <attribute name="minExclusive" type="double"/> <attribute name="maxInclusive" type="double"/> <attribute name="maxExclusive" type="double"/> </complexType> <complexType name="EnumerationAlarmType"> <annotation> <documentation xml:lang="en">Alarm conditions for Enumerations</documentation> <appinfo>An additional check needs to be performed to ensure that the enumeration values in the alarms are legal enumeration values for the Parameter</appinfo> </annotation> <complexContent> <extension base="xtce:AlarmType"> <sequence> <element name="EnumerationAlarmList"> <complexType> <sequence> <element name="EnumerationAlarm" maxOccurs="unbounded"> <complexType> <attribute name="alarmLevel" type="xtce:AlarmLevels" use="required"/> <attribute name="enumerationValue" type="string" use="required"/> </complexType> </element> </sequence> </complexType> </element> </sequence> <attribute name="defaultAlarmLevel" type="xtce:AlarmLevels" default="normal"/> </extension> </complexContent> </complexType> Replace: <complexType name="IntegerRangeType"> <annotation> <documentation xml:lang="en">An integral range of numbers. "min", and "max".</documentation> </annotation> <attribute name="min" type="integer"/> <attribute name="max" type="integer"/> </complexType> With: <complexType name="IntegerRangeType"> <annotation> <documentation xml:lang="en">An integral range of numbers. "min", and "max".</documentation> </annotation> <attribute name="minInclusive" type="xtce:FixedIntegerValueType"/> <attribute name="maxInclusive" type="xtce:FixedIntegerValueType"/> </complexType> Replace: <complexType name="NumericAlarmConditionType"> <annotation> <documentation>Alarms associated with numeric data types</documentation> </annotation> <choice> <sequence> <element name="StaticAlarmRanges" type="xtce:AlarmRangesType" minOccurs="0"> <annotation> <documentation>StaticAlarmRanges are used to trigger alarms when the parameter value passes some threshold value</documentation> </annotation> </element> <element name="ChangePerSecondAlarmRanges" type="xtce:AlarmRangesType" minOccurs="0"> <annotation> <documentation>ChangePerSecondAlarmRanges are used to trigger alarms when the parameter value's rate-of-change passes some threshold value. An alarm condition that triggers when the value changes too fast (or too slow)</documentation> </annotation> </element> </sequence> <element name="ConditionalAlarm"> <annotation> <documentation>A MatchCriteria may be specifiec for each of the 5 alarm levels. Each level is optional and the alarm should be the highest level to test true.</documentation> </annotation> <complexType> <sequence> <element name="StaticAlarmConditions" type="xtce:AlarmConditionsType" minOccurs="0"/> <element name="ChangePerSecondAlarmConditions" type="xtce:AlarmConditionsType" minOccurs="0"/> </sequence> </complexType> </element> <element name="CustomAlarm" type="xtce:InputAlgorithmType"> <annotation> <documentation>An escape for ridiculously complex alarm conditions. Will trigger on changes to the containing Parameter. </documentation> </annotation> </element> </choice> <attribute name="minViolations" type="positiveInteger" default="1"> <annotation> <documentation>Number of successive values of the Parameter for the Alarm to trigger.</documentation> </annotation> </attribute> </complexType> With: <complexType name="NumericContextAlarmType"> <annotation> <documentation xml:lang="en">Context alarms are applied when the ContextMatch is true. Context alarms override Default alarms</documentation> </annotation> <complexContent> <extension base="xtce:NumericAlarmType"> <sequence> <element name="ContextMatch" type="xtce:MatchCriteriaType"/> </sequence> </extension> </complexContent> </complexType> <complexType name="NumericAlarmType"> <annotation> <documentation xml:lang="en">Alarms associated with numeric data types</documentation> </annotation> <complexContent> <extension base="xtce:AlarmType"> <sequence> <element name="StaticAlarmRanges" type="xtce:AlarmRangesType" minOccurs="0"> <annotation> <documentation xml:lang="en">StaticAlarmRanges are used to trigger alarms when the parameter value passes some threshold value</documentation> </annotation> </element> <element name="ChangeAlarmRanges" minOccurs="0"> <annotation> <documentation xml:lang="en">ChangeAlarmRanges are used to trigger alarms when the parameter value's rate-of-change is either too fast or too slow. The change may be with respect to time (the default) or with respect to samples (delta alarms) - the changeType attribute determines this. The change may also be ether relative (as a percentage change) or absolute as set by the changeBasis attribute. The alarm also requires the spanOfInterest in both samples and seconds to have passed before it is to trigger. For time based rate of change alarms, the time specified in spanOfInterestInSeconds is used to calculate the change. For sample based rate of change alarms, the change is calulated over the number of samples specified in spanOfInterestInSeconds.</documentation> </annotation> <complexType> <complexContent> <extension base="xtce:AlarmRangesType"> <attribute name="changeType" default="changePerSecond"> <simpleType> <restriction base="string"> <enumeration value="changePerSecond"/> <enumeration value="changePerSample"/> </restriction> </simpleType> </attribute> <attribute name="changeBasis" default="absoluteChange"> <simpleType> <restriction base="string"> <enumeration value="absoluteChange"/> <enumeration value="percentageChange"/> </restriction> </simpleType> </attribute> <attribute name="spanOfInterestInSamples" type="positiveInteger" default="1"/> <attribute name="spanOfInterestInSeconds" type="decimal" default="0"/> </extension> </complexContent> </complexType> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="StringAlarmType"> <annotation> <documentation xml:lang="en">Alarm conditions for Strings</documentation> </annotation> <complexContent> <extension base="xtce:AlarmType"> <sequence> <element name="StringAlarmList"> <complexType> <sequence> <element name="StringAlarm" maxOccurs="unbounded"> <annotation> <documentation xml:lang="en">Pattern may be a regular expression</documentation> </annotation> <complexType> <attribute name="alarmLevel" type="xtce:AlarmLevels" use="required"/> <attribute name="matchPattern" type="string" use="required"/> </complexType> </element> </sequence> </complexType> </element> </sequence> <attribute name="defaultAlarmLevel" type="xtce:AlarmLevels" default="normal"/> </extension> </complexContent> </complexType> <complexType name="TimeAlarmType"> <annotation> <documentation xml:lang="en">Alarms associated with time data types</documentation> </annotation> <complexContent> <extension base="xtce:AlarmType"> <sequence> <element name="StaticAlarmRanges" minOccurs="0"> <annotation> <documentation xml:lang="en">StaticAlarmRanges are used to trigger alarms when the parameter value passes some threshold value</documentation> </annotation> <complexType> <complexContent> <extension base="xtce:AlarmRangesType"> <attribute name="timeUnits" type="xtce:TimeUnits" default="seconds"/> </extension> </complexContent> </complexType> </element> <element name="ChangePerSecondAlarmRanges" minOccurs="0"> <annotation> <documentation xml:lang="en">ChangePerSecondAlarmRanges are used to trigger alarms when the parameter value's rate-of-change passes some threshold value. An alarm condition that triggers when the value changes too fast (or too slow)</documentation> </annotation> <complexType> <complexContent> <extension base="xtce:AlarmRangesType"> <attribute name="timeUnits" type="xtce:TimeUnits" default="seconds"/> </extension> </complexContent> </complexType> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="TimeAlarmConditionType"> <annotation> <documentation xml:lang="en">Alarm conditions for Time types</documentation> </annotation> <complexContent> <extension base="xtce:AlarmType"/> </complexContent> </complexType> <complexType name="TimeContextAlarmType"> <annotation> <documentation xml:lang="en">Context alarms are applied when the ContextMatch is true. Context alarms override Default alarms</documentation> </annotation> <complexContent> <extension base="xtce:TimeAlarmType"> <sequence> <element name="ContextMatch" type="xtce:MatchCriteriaType"/> </sequence> </extension> </complexContent> </complexType> Insert before complexType AlarmConditionsType <simpleType name="AlarmLevels"> <annotation> <documentation xml:lang="en">An enumerated list of the possible alarm levels</documentation> </annotation> <restriction base="string"> <enumeration value="normal"/> <enumeration value="watch"/> <enumeration value="warning"/> <enumeration value="distress"/> <enumeration value="critical"/> <enumeration value="severe"/> </restriction> </simpleType> Insert before complexType UnitType <simpleType name="TimeUnits"> <annotation> <documentation xml:lang="en">base time units. days, months, years have obvoius ambiguity and should be avoided</documentation> </annotation> <restriction base="string"> <enumeration value="seconds"/> <enumeration value="picoSeconds"/> <enumeration value="days"/> <enumeration value="months"/> <enumeration value="years"/> </restriction> </simpleType>
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Closed after discussion at Boston meeting

Issue 10186: ESA-019 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

The support of command sequences is not satifactory for ESA, and ESA would like to have command sequences in XTCE. Is there any work ongoing on that side for XTCE, or is it intended to leave complicated command sequences (Block Meta Command) out of XTCE. ESA could propose a model for the command sequence support.  RID RESPONSE:  Yes,  in fact the OMG/SDTF is currently reviewing a proposed specification for a very robust command sequence model.   This model would augment XTCE.   Recommend closure.  Status: reviewd and closed  Type: Schema Change  	  Boston.  No changes to XTCE.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Yes,  in fact the OMG/SDTF is currently reviewing a proposed specification for a very robust command sequence model.   This model would augment XTCE but is a separate specification.   Closed after discussion at Boston.

Issue 10187: ESA-020 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  An analysis is on-going for two satellites database (Metop and Herschel-Planck) and more RIDs are expected in the next weeks.  RID RESPONSE:  Status:  comment, Closed  Boston: close  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Not an issue with the XTCE specification

Issue 10188: ESA-022 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  Change "Interface design to satellite systems" to "Ground interface design to satellite systems"  RID RESPONSE:  Recommend not changing as telemetric and command processing DO NOT have to be performed on   the ground.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Recommend not changing as telemetric and command processing DO NOT have to be performed on the ground.  Close

Issue 10189: ESA-023 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  Change "XTCE provides a standard format for defining the Telemetric and Telecommand (TM/TC) data required to perform the processing shown in figure 1." to  "XTCE provides a standard format for defining the Telemetric and Telecommand (TM/TC) data required to perform the ground processing shown in Figure 1."  RID RESPONSE:  While the processing depicted  is normally accomplished on the ground, it does not have to be - consider a space station controlling another space asset.   Recommend not changing as telemetric and command processing DO NOT have to be performed on   the ground.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  While the processing depicted is normally accomplished on the ground, it does not have to be - Closed

Issue 10190: ESA-025 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  Change caption from "Telemetric and Command Processing Meta Data Encapsulated in XTCE XML" to "Telemetric and Command Ground Processing Meta Data Encapsulated in XTCE XML"  RID RESPONSE:  See remark in ESA-23  Recommend not changing as telemetric and command processing DO NOT have to be performed on   the ground.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Recommend not changing as telemetric and command processing DO NOT have to be performed on the ground.  Close

Issue 10191: ESA-042 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  Include AlarmLimitSet  RID RESPONSE:  Covered by the magenta book.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Recommended practice that is covered by the magenta book.  Closed

Issue 10192: ESA-054 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  Correct inconsistencies between StreamSetType in Figures 3 and 6.  RID RESPONSE:  We believe they do match.  Figure 6 simply has its aggregation shown as separate classes rather than attributes.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  We believe they do match.  Figure 6 simply has its aggregation shown as separate classes rather than attributes.  Close

Issue 10193: ESA-055 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  Delete use of word Frame in stream types.  RID RESPONSE:  In the context of Streams 'Frame' does have a real meaning and we do need to name Streams that are   marked on fixed or variable boundaries with some type of 'Frame Sync Marker'  It could be argued that frame should have been called 'Container'.  Recommend new names instead of   simply dropping 'Frame'.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  In the context of Streams 'Frame' does have a real meaning and we do need to name Streams that are marked on fixed or variable boundaries with some type of 'Frame Sync Marker' It could be argued that frame should have been called'Container'.    Close

Issue 10194: ESA-056 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  Remove PCM from name PCMStreamType.  RID RESPONSE:  XTCE does not include analog modulation schemes, but clearly does begin with PCM streams (nrzl, nrzm, nrzs, �).  This is important to do because it's possible for a container etc. to include segments of streams encoded with varying PCM types.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  XTCE does not include analog modulation schemes, but clearly does begin with PCM streams (nrzl, nrzm, nrzs, ...).  This is important to do because it's possible for a container etc. to include segments of streams encoded with varying PCM types.  Close

Issue 10195: ESA-065 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  Modify text to specify that parameter can be member of multiple ParameterSets.  RID RESPONSE:  Ref'ing in XTCE is liberal.  That is MetaCommand in another MetaCommandSet can be Ref'd into   another.  If not this needs to be explicitly captured in terms of "Ref Scoping". The Description does   not match the supporting analysis.  There already is a MetaCommandRef in MetaCommand in MetaCommandSet.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Ref'ing in XTCE is liberal.  That is MetaCommand in another MetaCommandSet can be Ref'd into another.  Closed

Issue 10196: ESA-067 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  Modify Figure 9 to depict relationship between interlocks and constraints.  RID RESPONSE:  Even though an Interlock is a type of contraint, we were unable to use this relationship in the realization of Interlock in the W3C schema and since the UML was generated automatically from the schema, this relationship does not appear in the UML.  As we'd prefer to keep the UML generation completely autogenerated.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Even though an Interlock is a type of contraint, we were unable to use this relationship in the realization of Interlock in the W3C schema and since the UML was generated automatically from the schema, this relationship does not appear in the UML.  As we'd prefer to keep the UML generation completely autogenerated, close.

Issue 10197: ESA-068 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  Delete ", but not on Command instances of this MetaCommand; Interlocks apply instead to the next command. " Modify "An Interlock will block successive commands until this command has reached a certain stage (through verifications)." to "An Interlock will block the command until a previous command has reached a certain stage (through verifications)."  RID RESPONSE:  The proposed wording change would change the meaning of Intelock in XTCE.  The proposed changes are not what was intended to be the definition of an Interlock.  The proposed definition of Interlock would be a type of TransmissionConstraint.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  The proposed wording change would change the meaning of Interlock in XTCE.  The proposed changes are not what was intended to be the definition of anInterlock  Close

Issue 10198: ESA-069 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  The proposed wording change would change the meaning of Intelock in XTCE.  The proposed changes are not what was intended to be the definition of anInterlock  Close

Issue 10199: ESA-072 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  The verifier changes were addressed in issue 10264  XTCE does not currently have any mechanism to specifiy expected reaction to a command that is 'interrupted'.  Close

Issue 10200: ESA-075 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  As the goal is a standard exchange which variable numbers would increase complexity of exchange, six levels of significance can be exchanged and should be sufficient . Closed.

Issue 10201: ESA-077 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

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

Issue 10202: ESA-078 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  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".  If a new schema is created for every supplier/customer contract, then we don't have a standard exchange format. Closed

Issue 10203: ESA-079 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Closed - Issue withdrawn after discussion this is a problem relevant to specific implementation of XML parses, schema is ok.

Issue 10204: INPE-001 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  We believe transition a mission by moving a database reads better  Close

Issue 10205: INPE-003 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  This entire sentence was modified as a result from a previous RID  Close

Issue 10206: INPE-006 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  The figure does say spacecraft or ground equipment. Closed

Issue 10207: INPE-007 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  As a result of an earlier RID this section has already be extensively re-written.  Close

Issue 10208: INPE-012 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Please read the support documentation of XTCE (Magenta Book and Green Book).  A growing body of examples is becoming available.  Specification is sufficient, it is expected that more documentation on appropriate use will be developed.  Close.

Issue 10209: INPE-013 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

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

Issue 10210: JPL-001 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  SpaceSystem/Header/HistorySet provides a simple mechanism for capturing history change.  Close

Issue 10211: JPL-002 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Spacecraft IDs are perfectly accomodated in the SpaceSystem's AliasSet .  Close

Issue 10212: JPL-005 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

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

Issue 10213: JPL-006 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

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

Issue 10214: JPL-007 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  There are several documenation entities in XTCE,  LongDescription, shortDescription, AncillaryDataSet, and Header all provide opportunties to document items.  Close

Issue 10215: JPL-008 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  This is the same RID SOURCE:JPL-006, Issue 10213  Close

Issue 10216: JPL-009 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Duplicate of issue 10158, ESA-016  Close

Issue 10217: JPL-010 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Algorithms are explained in the Magenta Book. The explanations there will be reviewed, but the RID does not apply to XTCE schema.  Close

Issue 10218: JPL-011 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Algorithms are explained in the Magenta Book. The explanations there will be reviewed, but the RID does not apply to XTCE schema.  Close

Issue 10219: JPL-012 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Duplicate of issue 10212 (JPL-005).  Close.

Issue 10220: JPL-013 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  All that has been described is covered by XTCE. Recommended practices are covered in the CCSDS Magenta Book.  Close

Issue 10221: JPL-014 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  The namespace was set at the OMG over five years ago.  Close

Issue 10222: JPL-015 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Future work in this area would be welcome, but is not within the scope of the current XTCE specification.  Close

Issue 10223: JPL-017 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  XTCE has an array-type.  XTCE also allows one to specify that a container parameter repeats some number of times.   That number of times 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 usefulnes

Issue 10224: JPL-018 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Duplicate of issue 10172 which was deferred. Close.

Issue 10225: JPL-019 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  This is related to several other RIDs.  At the moment there is nothing specific about Flight Software in XTCE, however AncillaryData may be useful for capturing this information.  Close

Issue 10226: JPL-020 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  The common data definitions should be refactored to extract common metadata items that can be reused  in other CCSDS schemas. These common metadata items are:  A.	Time formats  a.	UTC Time format  b.	Spacecraft clock (SCLK) time format  c.	Earth receive time (ERT) format  d.	GMT time format  e.	Time Period format  B.	Basic types  C.	Algorithms  D.	Units types  E.	Coordinate formats  a.	Cartesian formats for reference frame formats  b.	J2000 + other celestial body formats  RID RESPONSE:  None of these specific time formats are part of XTCE now, but should be definable in an valid XTCE XML document.XTCE doesn't know anything about specific formats in CCSDS and was designed to be general enough to describe them (should it fail then that's a valid criticism for schema change).  If it would be helpful, CCSDS could supply base XTCE documents for those specific format for missions that could be downloaded from the CCSDS web site.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  XTCE does not pre-define specific formats, such as CCSDS.  It was designed to be general enough to describe CCSDS formats as well as time-division-multiplexed formats.  Reuse can be guided by the related CCSDS Magenta Book  Close

Issue 10227: JPL-021 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  9.	Ensure that all the sub-schemas have the same namespace.  RID RESPONSE:  Merge this with other RIDs (JPL-016, etc�) on seperating out the schema  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Duplicate of issue 10172. Close

Issue 10228: JPL-022 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  6.	Elaborate on the "fixed" uplink bit-stream format � information from constant updates, as telemetry channel/evr/product information is changed, and unmanageably large file sizes.I think this has to do with Custom Stream sets. The concern is how does XTCE affect the file sizes of elemetry streams. Does XTCE impose an overhead on this? Using XTCE to generate telemetry stream would be interesting � is it efficient?  RID RESPONSE:  It would only DESCRIBE a telemetry stream and what it can describe about streams themselves is pretty minimal.  Unless I misunderstand things I don't think there should be any problems here.There is no overhead imposed by XTCE, it is just the description of data..  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  XTCE onlys describes the command and telemetry streams, it not used for sending telemetry or commanding.  While the size and overhead of an exchange format is a consideration, it is not critical to the functionality, and the widespread availability of XML based tools to manipulate the data is a more important consideration.  Close

Issue 10229: JPL-023 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  8.	Include (using XML include command) all these schemas in a one container schema such as SpaceSystem.xsd  RID RESPONSE:  Merge this with the other RIDs (JPL-016, JPL-22) on seperating the schema  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Resolution:  Duplicate of issue 10172. Close

Issue 10230: JPL-024 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

DESCRIPTION OF REQUESTED CHANGE  4.	Ensure the command schema is useful for mission operations (ingest by command sequencing engine, command scripting).  RID RESPONSE:  The OMG sees this addition as a separate standard  Similar to previous RIDS.  Please follow (and contribute!) to the OMG SOLM specificaton.  RID STATE:	CLOSE

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Future work in this area would be welcome, but is not within the scope of the current XTCE specification.  Close

Issue 10231: JPL-025 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  AncillaryDataSet has been added that may help in this area-it allows for "tag/text" type descriptions to be created.  Nothing specific to flight software has been added. Close

Issue 10232: JPL-027 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Duplicate of 10226. XTCE does not pre-define specific formats, such as CCSDS.  It was designed to be general enough to describe CCSDS formats as well as time-division-multiplexed formats.  Reuse can be guided by the related CCSDS Magenta Book.  The time and location issue is a duplicate of issue 10173.  Close

Issue 10233: JPL-028 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Events can be described in XTCE.  An event report from the spacecraft must be in a defined format, identifiable by the ground software, which should be describable as a Container in the same way as other telemetry.  Close

Issue 10234: JPL-031 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Please revew the  XTCE 'Contexts' alarms, calibrators and command area.  In addition, XTCE Commands may be grouped by sub-system (e.g., motor, camera, etc.)  Close

Issue 10235: ESA-003 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Revised Text:  6.1.6	Defaults  Defaults has default data encoding for ParameterTypes and ArgumentTypes and default parameter time association that will be applied to all Parameters within this SpaceSystem.  These defaults may be overidden by sub-SpaceSystems or by the Types or Parameters themselves.  Defaults simply provides a means to avoid repeating attributes such as 'bit order' for every Type definition.  ----  Removed

Issue 10236: ESA-021 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Before: Satellite design and development is performed today through the use of a number of disparate tools and techniques. Interface design to satellite systems and to the payloads the satellites are housing is still a manual and time-consuming effort. Data design, both telemetry and commanding, is still performed multiple times by multiple contractors during the lifecycle of the satellite, well before the satellite is ever deployed for mission operations. The standardization of satellite telemetry and command data for spacecraft health and safety, as well as payload interfaces will reduce the cost of these implementations as well as decrease the schedule of development, integration, and test of the satellite and its component systems. This specification can also be used to support multiple, heterogeneous missions, facilitating interoperability between ground control systems, simulators, testing facilities, etc. At the heart of the specification is a very robust information model for telemetry and commanding that will support of all phases of the satellite, payload, and ground segment lifecycle: system design, development, test, validation, and mission operations After: Satellite design and development is performed today through the use of a number of disparate tools and techniques. The interface design for spacecraft systems and spacecraft payloads is still a manual and time-consuming effort. Data design, both telemetry and commanding, is still performed multiple times by multiple contractors during the lifecycle of the satellite - well before the satellite is ever deployed for mission operations. The standardization of satellite telemetry and command data for spacecraft health and safety, as well as payload interfaces, will reduce the cost of these implementations as well as decrease the schedule of development, integration, and test of the satellite and its component systems. This specification can also be used to support multiple, heterogeneous missions, facilitating interoperability between ground control systems, simulators, testing facilities, and other types of spacesystems.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Fixed

Issue 10237: ESA-024 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Fixed

Issue 10238: ESA-027 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	"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

Resolution:
Revised Text: Before: The scope of this specification is limited to satellite telemetry and commanding data constructs necessary to support satellite and payload data design After: The scope of this specification is limited to the satellite telemetry and commanding meta-data constructs necessary to perform satellite and payload data processing. This specification includes the meta-data needed to:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Fixed

Issue 10239: ESA-028 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	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

Resolution:
Revised Text: Before: The specification addresses only the definition of TM/TC data, and not the transfer of live or historical TM/TC data. After: This specification addresses only the definition of TM/TC data, but is not a specification for the transfer of live or historical TM/TC data - this is a meta-data specification, not a data specification.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Fixed

Issue 10240: ESA-029 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

"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

Resolution:
Revised Text: Before: Telemetry as used here refers to these measurements whether on-board the spacecraft or transmitted to the ground system. After: Telemetry as used here refers to these measurements originating from both the spacecraft and from systems (such as ground system components) used to support the spacecraft.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10241: ESA-030 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Text replace in command definition in section 4 of the document: Before: Messages that instruct an action on a remote system. Spacecraft commanding usually implies coding and packaging of the command information, validation and verification, as well as authorization to perform. Telemetry and Commanding data are necessarily related to one another, with some command information originating from telemetry and commands relating to particular telemetry measurements. Therefore, the ability to relate individual telemetry with one another and to commands is a very important part of this specification. Packaging of both telemetry and commands can be performed in a number of ways. The most common way to package data for transmission is to use the CCSDS Telemetry and Commanding Packaging format. After: Commands are messages which initiate actions on a remote system. Commands as used here may mean both commands destined for the spacecraft and to the systems used to support the spacecraft. Spacecraft commanding usually implies coding and packaging of the command information, validation and verification, as well as authorization to perform. Telemetry and Commanding data are necessarily related to one another, with some command information originating from telemetry and commands relating to particular telemetry measurements. Therefore, the ability to relate individual telemetry with one another and to commands is a very important part of this specification.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10242: ESA-031 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	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

fixed

Issue 10243: ESA-033 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

"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

Resolution:
Revised Text: From: (from IEEE Std 1000 [1972]) To : (IEEE Std 100-1996 [1996])
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10244: ESA-035 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: From: This name provides deference to the fact that a spacecraft operations center must control antennas, recorders, ground processing equipment, RF hardware and other many other assets that may use this data specification; each of these objects is a 'SpaceSystem'. To: This name reflects that a spacecraft operations center must control antennas, recorders, ground processing equipment, RF hardware and many other assets that may use this data specification; each of these objects is a 'SpaceSystem'.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10245: ESA-036 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Class diagrams are updated and explained as a result of issues 10250, 10251, 10255, 10256, & 10260, revised text/diagrams are shown there.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Issue 10246: ESA-037 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	Define term "anonymous type"  RID STATE:	FIXED

Resolution:
Revised Text: Issue referenced old version of Figure 2, this has been removed in the UML diagrams in the XTCE 1.1 specification.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Issue 10247: ESA-043 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Text inserted in section 6.1.3: Parameters are scoped to the Space System basis, so elements defined in the telemetry part can be reused in the command part and vice versa
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Issue 10248: ESA-044 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: A ParameterTypeSet is an unordered collection of ParameterTypes. ParameterTypes are the MetaData for Parameters; ParameterTypes are instantiated to create Parameters. ParameterType is the description of something that can have a value (a Parameter). Information contained in ParameterType includes the data type, description, alarm limits, engineering units and string conversion 'ToString' specifications. Parameters may be of variable length. Most Parameters are telemetered parameters (a.k.a measurands) and must also include information about how the Parameter value is encoded for transmission. This information includes size in bits, byte order, data type, calibrations and parity checks. All of the encoding information is in one of four different 'DataEncoding' elements. XTCE supports four different types of encodings:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Issue 10249: ESA-046 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Precisely define each encoding type.  	RID STATE:	FIXED

Resolution:
Revised Text: Revisions included in issue number 10250
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Issue 10250: ESA-047 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Clarify types in Figure 4.  		RID STATE:	FIXED

Resolution:
Revised Text: Replace: 6.1.2.1 ParameterTypeSet A ParameterTypeSet is an unordered collection of ParameterTypes. ParameterTypes are the MetaData for Parameters; ParameterTypes are instantiated to create Parameters. ParameterType is the description of something that can have a value (a Parameter). Information contained in ParameterType includes the data type, description, alarm limits, engineering units and string conversion specifications and calibrations. Most Parameters, are telemetered parameters (a.k.a measurands) and must also include information about how the Parameter value is encoded for transmission. This information includes size in bits, byte order, data type, and parity checks. All of the encoding information is in the Encoding area. Figure 8 ParameteTypeSet With: 6.1.2.1 ParameterTypeSet A ParameterTypeSet is an unordered collection of ParameterTypes. ParameterTypes are the MetaData for Parameters; ParameterTypes are instantiated to create Parameters. ParameterType is the description of something that can have a value (a Parameter). Information contained in ParameterType includes the data type, description, alarm limits, engineering units and string conversion 'ToString' specifications. Parameters may be of variable length. Most Parameters are telemetered parameters (a.k.a measurands) and must also include information about how the Parameter value is encoded for transmission. This information includes size in bits, byte order, data type, calibrations and parity checks. All of the encoding information is in one of four different 'DataEncoding' elements. XTCE supports four different types of encodings: IntegerDataEncoding: specifies the bit order, size in bits, the encoding (unsigned, signMagnitude, twosCompliment, onesCompliment, BCD, or packedBCD). The byte order in the case of multi byte integers can also be specified, along with error detection (CRC or Parity checks). FloatDataEncoding: specifies the bit order, size in bits, the encoding (IEEE754_1985 or MILSTD_1750A). The byte order in the case of multi byte floats can also be specified, along with error detection (CRC or Parity checks). StringEncoding: specifies the bit order, the encoding (UTF-8 or UTF-16), the size in bits or variable size determined by either a termination character, or a leading size parameter, along with error detection (CRC or Parity checks). BinaryDataEncoding: specifies the bit order, the size in bits, and two algorithms to convert to and from the endcode value, along with error detection (CRC and Parity checks). Note that the data encoding type only speaks to how the Parameter (or Command argument) is transmitted, not how it is handled on the SpaceSystem or ground. Figure 9 presents the UML representation of the Parameter Type Set, and therefore all available data types. Encoding data types are children of these elements and not depicted in that figure. Figure 9 ParameterTypeSet UML Class Diagram
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10251: ESA-049 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: 6.1.2.3 ContainerSet Before: A ContainerSet is an unordered collection of SequenceContainers. SequenceContainers are defined in the packaging section. The packaging section contains the information required to assemble an uplink from its component parts and disassemble a downlink from its component parts. The packaging section has been created to be extremely generic so that it may be used to define TDM telemetry streams, packetized streams or any other package format. A SequenceContainer contains (in the EntryList) an ordered list of raw parameters, parameter segments, stream segments, containers, or container segments. SequenceContainers may inherit from other sequence containers. The inheritance aspect of SequenceContainers is useful not only for minimizing the effort required to describe a family of SequenceContainers, but is also a very powerful and expressive means of container identification - the process of distinguishing one container from others (e.g. minorFrame 20 is a type of minorFrame where the minor frame counter equals 8). SequenceContainer inheritance may be arbitrarily deep. Figure 10 ContainerSet A SequenceContainer may represent a packet, a frame, a sub-frame 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. After: 6.1.2.3 ContainerSet A ContainerSet is an unordered collection of SequenceContainers. 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. A SequenceContainer contains (in the EntryList) an ordered list of raw parameters, parameter segments, stream segments, other containers, or container segments. Figure 5 is the Container UML class diagram. 6.1.2.3.1 BaseContainer SequenceContainers may inherit from other sequence containers by pointing to the parent container using the 'BaseContainer' element. The inheritance aspect of SequenceContainers is useful not only for minimizing the effort required to describe a family of SequenceContainers, but is also a powerful and expressive means of container identification - the process of distinguishing one container from others (e.g. minorFrame 20 is a type of minorFrame where the minor frame counter equals 20). 'RestrictionCriteria' in the BaseContainer element is used as a constraint to identify a SequenceContainer subtype from its BaseContaner. In the example above, the RestrictionCriteria is 'minor frame counter equals 20. RestrictionCriteria is a type of MatchCriteria. SequenceContainer inheritance may be arbitrarily deep. Figure 11 Container UML Class Diagram A SequenceContainer may represent a packet, a frame, a sub-frame 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.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10252: ESA-050 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Changes were incorporated at same time as issue 10251 and are shown in that issue.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Issue 10253: ESA-051 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Issue resolved at the same time as issue 10254, changed text is shown there

Issue 10254: ESA-052 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: 6.1.2.4 MessageSet Before: A MessageSet is an unordered collection of Messages. Messages are an alternative method of uniquely identifying containers within a Service. A message provides a test in the form of MatchCriteria to match to a container. A simple example might be: When minorframeID=21, the message is the 21st minorframe container. The collection of messages to search thru will be bound by a Service. After: A MessageSet is an unordered collection of Messages. Messages are an alternative method of uniquely identifying containers within a Service. A message provides a test in the form of MatchCriteria to match to a container. A Match Criteria is a simple or complex comparison of elements in a container against preset values. A simple example might be: When minorframeID=21, the message is the 21st minorframe container. The collection of messages to search through will be bound by a Service. A service is a set of messages and/or containers is used to filter containers. This mechanism can be used to sort containers, for instance all containers with a field X equal to a supplied value will be given the name of a service. These containers will be found according to a generic container or a message (the message itself refers to a container).
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Issue 10255: ESA-057 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: A StreamSet is an unordered collection of Streams. Spacecraft uplinks and spacecraft downlinks are digital streams of data and there are a number of processing functions that are done on the stream level. The StreamSet in a SpaceSystem XTCE document can contain all of the information on how to assemble, disassemble and process spacecraft uplink and downlink streams for that SpaceSystem. There are three possible Streams types: VariableFrameStream for streams containing variable length streams, FixedFrameStream for streams containing fixed length streams and a custom stream that can be used to define any other kind of stream needed (The name of a Custom Algorithms are given for processing these streams).
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Fixed - updated text and associated diagram

Issue 10256: ESA-058 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

6.1.3.6	AlgorithmSet  An AlgorithmSet is an unordered collection of Algorithms.  In spacecraft ground systems, it is necessary to perform some specialized processing to process the telemetry, and preprocess commands.  There are a number of predefined algorithms and the algorithm section makes it possible to reference externally defined algorithms for arbitrarily sophisticated data processing.  6.1.3.6.1	MathAlgorithm  A Math Algorithm is a simple mathematical operation with two operands (each of which may be a fixed or a parameter instance value) and an operand.   6.1.3.6.2	SimpleAlgorithm  A simple algorithm only has an optional Algorithm Text (for pseudo code) and Set of names to external algorithms (which be really be Java class files, DLLs, scripts, etc.).  There is a set of external algorithms so one XTCE file can be used across multiple platforms.    6.1.3.6.3	InputAlgorithm  An InputAlgorithm is a type of SimpleAlgorithm that also has a set of inputs.  These inputs may be named Parameter Instances or constants.  6.1.3.6.4	InputOutputAlgorithm  An InputOutputAlgorighm is a type of InputAlgorithm that also has a set of outputs.  These outputs are named ParameterRefs.    6.1.3.6.5	InputOutputTriggerAlgorithm  An InputOutputTriggerAlgorithm is a type of InputOutputAlgorithm that also has a set of Triggers. Triggers are used to 'fire' the algorithm and may be either periodic, or event based (new parameter or container instance).

Issue 10257: ESA-059 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: A SequenceContainer contains (in the EntryList) an ordered list of raw parameters, parameter segments, stream segments, other containers, or container segments.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10258: ESA-060 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Issue is a duplicate of 10154 and is resolved.

Issue 10259: ESA-061 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Issue is a duplicate of 10260 and is resolved.

Issue 10260: ESA-062 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Figure 8 replaced and revised descriptions as a result of 10154.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Figure 8 replaced and revised descriptions as a result of 10154.

Issue 10261: ESA-063 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	Precisely define each encoding type.  	RID STATE:	FIXED

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue; Duplicate or Merged

Discussion:

Disposition:  Duplicate 10161,10249

Issue 10262: ESA-064 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Replace: 6.1.3.2 MetaCommandSet A MetaCommandSet contains an unordered collection of MetaCommands. MetaCommands are descriptions of commands. MetaCommands have a name, a BaseMetaCommand, an ArgumentList, a CommandContainer, a TransmissionContraintList, a DefaultSignificance, a ContextSignificanceList, an Interlock, Verifiers, and a ParameterToSetList. Figure 12 MetaCommandType 6.1.3.2.1 BaseMetaCommand The MetaCommand is derived from this Base. Arguments of the base MetaCommand are further specified in this MetaCommand. 6.1.3.2.2 ArgumentList An ArgumentList is an ordered collection of Arguments. Many commands have one or more options. These are called command arguments. Command arguments may be of any of the standard data types. MetaCommand arguments are local to the MetaCommand. 6.1.3.2.3 CommandContainer A Command Container tells how to package this command - very similar to SequenceContainers, but CommandContainers may also have arguments and fixed values in the sequence. Each MetaCommand may have one CommandContainer. 6.1.3.2.4 TransmissionConstraintList TransmissionConstraintList is an ordered list of TransmissionConstraints. A CommandTransmission constraint is used to check that the command can be run in the current operating mode and may block the transmission of the command if the constraint condition is true. 6.1.3.2.5 DefaultSignificance and ContextSignificanceList Some Command and Control Systems may require special user access our confirmations before transmitting commands with certain levels. The Significance includes the name of the SpaceSystem at risk, and a significance level. MetaCommands will also inherit any Significance defined in the Base MetaCommand. Significance levels are: none, watch, warning, distress, critical and severe. Additionally, is is possible to change or have different significance levels set as driven by the operating context of the SpaceSystem. 6.1.3.2.6 Interlock An Interlock is a type of Constraint, but not on Command instances of this MetaCommand; Interlocks apply instead to the next command. An Interlock will block successive commands until this command has reached a certain stage (through verifications). Interlocks are scoped to a SpaceSystem basis. 6.1.3.2.6 Verifiers A Command Verifier is a conditional check on the telemetry from a SpaceSystem that provides positive indication on the successful execution of a command. There are eight different verifiers each associated with difference stages in command completion: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple completion verifiers. Completed verifiers are added to the Base MetaCommand verifiers. All others will replace a verifier defined in a Base MetaCommand. 6.1.3.2.7 ParameterToSetList The ParameterToSetList is an ordered collection of ParametersToSet. A ParameterToSet is a Parameter whose value will be set after the Command has reached a certain stage. New Parameters to Set are appended to the Base Command list With: 6.1.3.2 MetaCommandSet A MetaCommandSet contains an unordered collection of MetaCommands. MetaCommands are descriptions of commands. MetaCommands have a name, a BaseMetaCommand, an ArgumentList, a CommandContainer, a TransmissionConstraintList, a DefaultSignificance, a ContextSignificanceList, a ParametersToSuspendAlarmsOnList, an Interlock, Verifiers, and a ParameterToSetList. Figure 13 MetaCommandType UML Class Diagram 6.1.3.2.1 BaseMetaCommand The MetaCommand is derived from this BaseMetaCommand. Arguments of the BaseMetaCommand are inherited by this MetaCommand, and may be further specified in this MetaCommand. 6.1.3.2.2 ArgumentList An ArgumentList is an ordered collection of Arguments. Many commands have one or more options. These are called command arguments. Command arguments may be of any of the standard data types. MetaCommand arguments are local to the MetaCommand. In XTCE, command arguments are variable inputs to a command either supplied by an operator or automation software. 6.1.3.2.3 CommandContainer A Command Container tells how to package this command and is very similar to a Telemetry SequenceContainer. CommandContainers, however, may also have arguments and fixed values in the sequence. Each MetaCommand may have one CommandContainer. CommandContainers may also be constructed using inheritance. Just like SequenceContainers, the function of RestrictionCriteria is to constrain the values of one or more entries from the parent Container. 6.1.3.2.4 TransmissionConstraintList TransmissionConstraintList is an ordered list of TransmissionConstraints. A CommandTransmission constraint is used to check that the command can be run in the current operating mode and may block the transmission of the command if the constraint condition is true. The TransmissionConstraint element uses the MatchCriteria Schema Type to determine if the Constraint is in effect or not. The MatchCriteria allows one to set up comparisons between parameters and expected values, or define a customAlgorithm for the comparison. DefaultSignificance and ContextSignificanceList Some Command and Control Systems may require special user access confirmations before transmitting commands with certain levels. The Significance includes the name of the SpaceSystem at risk, and a significance level. MetaCommands will also inherit any Significance defined in the Base MetaCommand. Significance levels are: none, watch, warning, distress, critical and severe. Additionally, it is possible to change or have different significance levels set as driven by the operating context of the SpaceSystem. 6.1.3.2.6 ParametersToSuspendAlarmsSet Sometimes it is necessary to suspend alarms - particularly 'change' alarms for commands that will change the value of a Parameter. Each Parameter in the list will have all its alarms suspended for the given suspension time starting after the given verifier occurs. The attributes for ParameterToSuspendAlarmsOn specify a time to suspend (suspenseTime), and the 'state' of the command which will cause the suspension to occur (verifierToTriggerOn). 6.1.3.2.7 Interlock An Interlock is a type of Constraint, but not on Command instances of this MetaCommand; Interlocks apply instead to any Commands that may follow instances this MetaCommand. An Interlock will block successive commands until this command has reached a certain stage (through verifications). Interlocks are scoped to a SpaceSystem basis. 6.1.3.2.8 Verifiers A Command Verifier is a conditional check on the telemetry from a SpaceSystem that that provides positive indication on the processing state of a command. There are eight different verifiers each associated with difference states in command processing: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple 'complete' verifiers. 'Complete' verifiers are added to the Base MetaCommand 'Complete' verifier list. All others will overide a verifier defined in a Base MetaCommand. 6.1.3.2.9 ParameterToSetList The ParameterToSetList is an ordered collection of ParametersToSet. A ParameterToSet is a Parameter whose value will be set after the Command has reached a certain state - as determined by the MetaCommand verifiers. New Parameters to Set are appended to the Base Command list.
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10263: ESA-066 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Fixed  Revised Text:  Included in text revisions for 10262.

Issue 10264: ESA-070 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	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

Resolution:
Revised Text:
Actions taken:
September 1, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Fixed  Revised Text:  Included in text revisions for issue 10262.

Issue 10265: ESA-073 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Fixed  Revised Text:  Included in text revisions for issue 10262.  Disposition: Resolved

Issue 10266: ESA-074 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Fixed  Revised Text:  Included in text revisions for issue 10262.  Disposition: Resolved

Issue 10267: ESA-076 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Replace: 6.1.4 ServiceSet ServiceSet is an unordered collection of Services. A service is a logical grouping of containers and/or messages. ServiceType ContainerRefSet_AnonymousType {sequenceOrder=3} -ContainerRef : ContainerRefType [*]{sequenceOrder=1} NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} MessageRefSet_AnonymousType {sequenceOrder=1} -MessageRef [*]{sequenceOrder=1} {sequenceOrder=4} -ContainerRefSet 0..1 {sequenceOrder=2} -MessageRefSet 0..1 {XMLattributes=base=xtce:NameDescriptionType} Figure 14 ServiceType With: 6.1.4 ServiceSet ServiceSet is an unordered collection of Services. A service is a logical grouping of containers and/or messages. Figure 15 ServiceType UML Class Diagram XTCE 1.1 RTF OMG Issue No: 10267 Document dtc/2006-12-01 Page 211 Services allow one to logically group XTCE containers. For example, your SpaceSystem may have a �memory dump service� and all the XTCE containers associated with that �service� may be grouped by listing them in a �service�. The ServiceType allows one to specify Messages or Containers. Note that these two are related but separate in this entity. In XTCE Messages are constructed using aggregate techniques, whereas if Containers are specified here they should be the one�s associated with inheritance. Services are optional and may not be useful for your SpaceSystem.
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Fixed

Issue 10268: INPE-002 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: From: Parameters may be or variable length To: Parameters may be of variable length This RID actually refers to a draft version of the 1.1 specifications, not 1.0
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

Resolution:  Fixed

Issue 10269: INPE-004 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	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

Resolution:
Revised Text: 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.
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10270: INPE-005 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	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

Resolution:
Revised Text: Ideally, a spacecraft operator should be able to transition a spacecraft mission from one ground system to another by simply moving an already existing command and telemetry database compliant with this specification to another ground system which equally supports this specification. In addition, standardization will enable space or ground segment simulators to more easily support multiple heterogeneous missions.
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Issue 10271: INPE-008 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	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

Resolution:
Revised Text: W3C Recommendation - Extensible Markup Language (XML) 1.0 (Second Edition, 6 October 2000) http://www.w3.org/TR/RECxml W3C Recommendation - XML Schema Part 0: Primer (2 May 2001) http://www.w3.org/TR/xmlsc hema-0/ W3C Recommendation - XML Schema Part 1: Structures (2 May 2001) http://www.w3.org/TR/xmlsc hema-1/ W3C Recommendation - XML Schema Part 2: Datatypes (2 May 2001) http://www.w3.org/TR/xmlsc hema-2/
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10272: INPE-010 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	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

Resolution:
Revised Text: Added: Prefixes and Postfixes Meta � Is a description. For example a MetaCommand is a command description PCM � Pulse Code Modulation Set �an unordered collection, for example a MetaCommandSet is an unordered collection of command descriptions List �an ordered collection, for example an ArgumentList is an ordered collection of arguments. Ref �a reference (by name) to an object defined elsewhere in the XML document, for example an ArgumentRef is a named reference to an Argument defined elsewhere. SAX � Simple API for XML TDM � Time Division Multiplexed UCS � Universal Character Set UTF � UCS Transformation Format W3C � World Wide Web Consortium
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

Fixed - Expanded acronym definitions

Issue 10273: INPE-011 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

From: "� begin with a capitol letter. "   	   	To:      "� begin with a capital letter. "  	RID STATE:	FIXED

Resolution:
Revised Text: Element and Type names begin with a capital letter.
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10274: NASA-002 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Replace: Note on Names Parameter, and MetaCommand and other major entity names within this database may be any length but are prohibited from containing the �/�, �.�, and �:� characters as these are reserved. The �/� is used as the SpaceSystem separator (Unix and HTTP style). The �:� is reserved for future use as a selector for data from other SpaceSystems. The �.� is reserved as an attribute selector. With: Note on Names Parameter, and MetaCommand and other major entity names within this database may be any length but may only contain numeric, a-z letters, underscores, hyphens, or backslashes. The characters �/�, �.�, �[�, �]� and �:� are expressly reserved. The �/� is used as the SpaceSystem separator (Unix and HTTP style). The �:� is reserved for future use as a selector for data from other SpaceSystems. The �.� is used to select members of aggregate Parameters and Argurments. The square brackets are reserved for array indexes. Names are case sensitive
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10275: NASA-003 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

Fixed � Full Schema-Type inheritance chain no longer fully shown because it is not  relevant

Issue 10276: NASA-005 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	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

Resolution:
Revised Text: <key name="parameterNameKey"> <annotation> <documentation xml:lang="en">This key ensures a unique parameter name at the system level.</documentation> </annotation> <selector xpath="xtce:TelemetryMetaData/ParameterSet/* | xtce:CommandMetaData/ParameterSet/*"/> <field xpath="@name"/> </key> <key name="parameterTypeNameKey"> <annotation> <documentation xml:lang="en">This key ensures a unique parameter type name at the system level.</documentation> </annotation> <selector xpath="xtce:TelemetryMetaData/ParameterTypeSet/* | xtce:CommandMetaData/ParameterTypeSet/*"/> <field xpath="@name"/> </key>
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10277: NASA-007 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

	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

Resolution:
Revised Text: All <documentation> elements were changed to include English language attribute. Example before <documentation>Command Meta Data contains information about commands</documentation> Example after <documentation xml:lang="en">Command Meta Data contains information about commands</documentation>
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10278: NASA-008 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: <element name="QueuedVerifier" minOccurs="0"> <annotation> <documentation xml:lang="en">A verifer that means the command is scheduled for execution by the SpaceSystem.</documentation> </annotation> <complexType> <complexContent> <extension base="xtce:CommandVerifierType"/> </complexContent> </complexType> </element>
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10279: NASA-009 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: <element name="AutoInvert" minOccurs="0"> <annotation> <documentation xml:lang="en">After searching for the frame sync marker for some number of bits, it may be desirable to invert the incoming data, and then look for frame sync. In some cases this will require an external algorithm</documentation> </annotation> <complexType> <sequence> <element name="InvertAlgorithm" type="xtce:InputAlgorithmType" minOccurs="0"/> </sequence> <attribute name="badFramesToAutoInvert" type="positiveInteger" default="1024"/> </complexType> </element>
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10280: NASA-011 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: <complexType name="EnumerationAlarmType"> <annotation> <documentation xml:lang="en">Alarm conditions for Enumerations</documentation> <appinfo>An additional check needs to be performed to ensure that the enumeration values in the alarms are legal enumeration values for the Parameter</appinfo> </annotation>
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10281: NASA-012 (xtce-rtf)

Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Element and Type names begin with a capital letter
Actions taken:
September 6, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed

Issue 10440: Division symbol (xtce-rtf)

Click here for this issue's archive.
Source: OS/COMET Product Group (Mr. Brad Kizzort, bkizzort(at)peraton.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: MathOperatorsType modified. Supersedes changes already incorporated for issue 9200. Revised Text: Replace: <simpleType name="MathOperatorsType"> <annotation> <documentation xml:lang="en">Mathematical operators</documentation> </annotation> <restriction base="string"> <enumeration value="+"/> <enumeration value="-"/> <enumeration value="mult"/> <enumeration value="div"/> <enumeration value="mod"/> <enumeration value="exp"/> <enumeration value="bitor"/> <enumeration value="bitand"/> <enumeration value="bitxor"/> </restriction> </simpleType> With: <simpleType name="MathOperatorsType"> <annotation> <documentation xml:lang="en">Mathematical operators</documentation> </annotation> <restriction base="string"> <enumeration value="+"/> <enumeration value="-"/> <enumeration value="*"/> <enumeration value="/"/> <enumeration value="%"/> <enumeration value="^"/> <enumeration value="y^x"/> <enumeration value="ln"/> <enumeration value="log"/> <enumeration value="e^x"/> <enumeration value="1/x"/> <enumeration value="x!"/> <enumeration value="tan"/> <enumeration value="cos"/> <enumeration value="sin"/> <enumeration value="atan"/> <enumeration value="acos"/> <enumeration value="asin"/> <enumeration value="tanh"/> <enumeration value="cosh"/> <enumeration value="sinh"/> <enumeration value="atanh"/> <enumeration value="acosh"/><enumeration value="asinh"/> <enumeration value="swap"/> </restriction> </simpleType>
Actions taken:
November 3, 2006: received issue
April 19, 2007: closed issue

Discussion:

fixed