inability to describe sets of limits (alarms) and conversions (polynomials) and then select a set per parameter depending on mission phase (JWST)

JWST hold conversion and limits in a seperate file that are grouped. Certains "sets" can be used for different mission phases such as test, on-orbit and so on, or for any reason deemed appropriate. XTCE allows one to specify at MOST one of each of these per parameterType

MER supports a Union construct because their abstract data types live past decomm. ASIST also supports the same idea – that an abstract data type onboard the spacecraft MAY live past decomm. Although it is possible to let multiple parameters overlap, in a sense allowing for a Union in XTCE. The issue arises that validating software cannot differentiate this with a bug in a container specification. A union tag or element of some sort is needed.

Documentation of readOnly attribute says the following per XTCE 1.1:
A Parameter marked as 'readOnly' true is constant and non-settable

It is not clear if this is intended to include "is constant". Constants should be defined per the dataSource property with a value of "constant" per the dataSource property's documentation.

It is not clear if a readOnly item is settable by any means (even the C2 software itself) or is it just read-only to any clients or external applications.

If it is intended to only influence clients and external applications, the documentation should be updated to be:
A Parameter marked as 'readOnly' true is non-settable

Propose to improve the readOnly attribute annotation to be more clear

We initially attempted to improve the documentation on the readOnly attribute in the ParameterProperties element. This did not quite meet the mark and the improvement was not as clear as it could be.

Propose to modify the current XTCE 1.2 proposal annotation from:

<attribute name="readOnly" type="boolean" use="optional" default="false">
<annotation>
<documentation xml:lang="en">A Parameter marked as 'readOnly' true is constant and non-settable. Note that a slight conceptual overlap exists here between the 'dataSource' and this attribute. When the 'dataSource' is 'constant', then 'readOnly' should be 'true'. Application implementations may choose to implicitly enforce this. Some implementations have both concepts of a Parameter that is settable and a Constant in a different part of the data model.</documentation>
</annotation>
</attribute>

To an update documentation element of:

<attribute name="readOnly" type="boolean" use="optional" default="false">
<annotation>
<documentation xml:lang="en">A Parameter marked as 'readOnly' true is non-settable by users and applications/services that do not represent the data source itself. Note that a slight conceptual overlap exists here between the 'dataSource' attribute and this attribute when the data source is 'constant'. For a constant data source, then 'readOnly' should be 'true'. Application implementations may choose to implicitly enforce this. Some implementations have both concepts of a Parameter that is settable or non-settable and a Constant in different parts of their internal data model.</documentation>
</annotation>
</attribute>

Description Kevin Rice 2007-10-22 21:34:53 BST
Time Association needs to apply to any parameter in a Packet/Container. The
XTCE parameter/parameterproperties/timeassociation can be used to capture an
"offset" time from a packet time stamp. In CCSDS world, most telemetry
packets are time stamped – and sometimes those time stamps are adjusted by
some offset or delta for each telemetry parameter in the packet (in effect each
parameter is timetagged). Since the same parameter may exist in more than one
packet and have different offsets – the XTCE approach is limiting in this
regard since only one offset can captured per parameter, not at the
packet/container level. XTCE should modify its container entryList area so
that TimeAssociation can be captured per packet entry.

Propose to include the TimeAssociation proposal at SequenceEntry type

The working group created a proposal to include updates to the SequenceEntryType to incorporate TimeAssociation element options.

The existing TimeAssociationType gets some minor updates to the documentation. Replace the existing schema type:

<complexType name="TimeAssociationType">
<annotation>
<documentation xml:lang="en">Telemetry parameter instances are oftentimes "time-tagged" with a timing signal either provided on the ground or on the space system. This data element allows one to specify which of possibly many AbsoluteTimeParameters to use to "time-tag" parameter instances with. </documentation>
<appinfo>The parameter ref must be to an AbsoluteTime Parameter</appinfo>
</annotation>
<complexContent>
<extension base="xtce:ParameterInstanceRefType">
<attribute name="interpolateTime" type="boolean" default="true">
<annotation>
<documentation xml:lang="en">If true, then the current value of the AbsoluteTime will be projected to current time. In other words, if the value of the AbsoluteTime parameter was set 10 seconds ago, then 10 seconds will be added to its value before associating this time with the parameter.</documentation>
</annotation>
</attribute>
<attribute name="offset" type="double">
<annotation>
<documentation xml:lang="en">The offset is used to supply a relative time offset from the time association and to this parameter</documentation>
</annotation>
</attribute>
<attribute name="unit" type="xtce:TimeAssociationUnitType" default="si_second">
<annotation>
<documentation>Specify the units the offset is in, the default is si_second.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>

With the following new content for this schema type:

<complexType name="TimeAssociationType">
<annotation>
<documentation xml:lang="en">Describes a time association consisting of an instance of an absolute time parameter (parameterRef) and this entry. Because telemetry parameter instances are oftentimes "time-tagged" with a timing signal either provided on the ground or on the space system. This data element allows one to specify which of possibly many AbsoluteTimeParameters to use to "time-tag" parameter instances with. See AbsoluteTimeParameterType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ParameterInstanceRefType">
<attribute name="interpolateTime" type="boolean" default="true">
<annotation>
<documentation xml:lang="en">If true, then the current value of the AbsoluteTime will be projected to current time. In other words, if the value of the AbsoluteTime parameter was set 10 seconds ago, then 10 seconds will be added to its value before associating this time with the parameter.</documentation>
</annotation>
</attribute>
<attribute name="offset" type="double">
<annotation>
<documentation xml:lang="en">The offset is used to supply a relative time offset from the time association and to this parameter</documentation>
</annotation>
</attribute>
<attribute name="unit" type="xtce:TimeAssociationUnitType" default="si_second">
<annotation>
<documentation xml:lang="en">Specify the units the offset is in, the default is si_second.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>

Then update the existing SequenceEntryType content from:

<complexType name="SequenceEntryType" abstract="true">
<annotation>
<documentation xml:lang="en">An abstract type used by sequence containers. An entry contains a location in the container. The location may be either fixed or dynamic, absolute (to the start or end of the enclosing container, or relative (to either the previous or subsequent entry). Entries may also repeat.</documentation>
</annotation>
<sequence>
<element name="LocationInContainerInBits" type="xtce:LocationInContainerInBitsType" minOccurs="0"/>
<element name="RepeatEntry" type="xtce:RepeatType" minOccurs="0">
<annotation>
<documentation xml:lang="en">
May be used when this entry repeats itself in
the sequence container. If not supplied, the
entry does not repeat.
</documentation>
</annotation>
</element>
<element name="IncludeCondition" type="xtce:MatchCriteriaType" minOccurs="0">
<annotation>
<documentation xml:lang="en">
This entry will only be included in the sequence
when this condition is true. If no
IncludeCondition is given, then it is will be
included. A parameter that is not included will
be treated as if it did not exist in the
sequence at all.
</documentation>
</annotation>
</element>
</sequence>
<attribute name="shortDescription" type="string" use="optional"/>
</complexType>

To the new definition that also incorporates annotation improvements to enhance clarity of the usage:

<complexType name="SequenceEntryType" abstract="true">
<annotation>
<documentation xml:lang="en">Defines an abstract schema type used to create other entry types. Describe an entry’s location in the container (See LocationInContainerInBitsType). The location may be fixed or dynamic, absolute or relative. Entries may be included depending on the value of a condition (See IncludeConditionType), and entries may also repeat (see RepeatEntryType). The entry’s IncludeCondition resolves to true, it is fully-resolved when its size is computable after RepeatEntry has been accounted for and then offset by LocationInContainer. See EntryListType, IncludeConditionType, RepeatEntryType and LocationInContainerInBitsType.</documentation>
</annotation>
<sequence>
<element name="LocationInContainerInBits" type="xtce:LocationInContainerInBitsType" minOccurs="0">
<annotation>
<documentation xml:lang="en">The start bit 0 position for each container is local to the container, but does include space occupied by inherited containers. When a container is "included", as opposed to inherited, then the interpreting implementation takes into account the start bit position of the referring container when finally assembling the start bits for the post-processed entry content. The default start bit for any entry is 0 bits from the previous entry, making the content contiguous when this element is not used.</documentation>
</annotation>
</element>
<element name="RepeatEntry" type="xtce:RepeatType" minOccurs="0">
<annotation>
<documentation xml:lang="en">May be used when this entry repeats itself in the sequence container. When an entry repeats, it effectively specifies that the same entry is reported more than once in the container and has the same physical meaning. This should not be construed to be equivalent to arrays.</documentation>
</annotation>
</element>
<element name="IncludeCondition" type="xtce:MatchCriteriaType" minOccurs="0">
<annotation>
<documentation xml:lang="en">This entry will only be included in the sequence when this condition is true, otherwise it is always included. When the include condition evaluates to false, it is as if the entry does not exist such that any start bit interpretations cannot take into account the space that would have been occupied if this included condition were true.</documentation>
</annotation>
</element>
<element name="TimeAssociation" type="xtce:TimeAssociationType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Optional timing information associated with this entry.</documentation>
</annotation>
</element>
<element name="AncillaryDataSet" type="xtce:AncillaryDataSetType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Optional ancillary data associated with this element.</documentation>
</annotation>
</element>
</sequence>
<attribute name="shortDescription" type="xtce:ShortDescriptionType" use="optional">
<annotation>
<documentation xml:lang="en">Optional short description for this entry element.</documentation>
</annotation>
</attribute>
</complexType>

Description Kevin Rice 2008-03-20 19:13:40 GMT
toString/NumberFormat - element is required if toString is in use. Almost all
attributes are optional but defaults should be

provided for "most common" likely format...

Provide default values for all attributes

Provide default values for all attributes in NumberFormatType based on the default values from Java NumberFormat and DecimalFormat.

AggregateDataType assumes each member immediately follows the previous member in the telemetry stream (no gaps). If there are unused bits in the stream, a dummy parameter must defined to account for the unused bits.

Aggegrate data layout may be accomplished via existing container

Use existing SequenceContainer capability (e.g., LocationInContainerInBits) to specify how members of an aggregate data type are received in a telemetry stream.

ContainerType needs optional SizeInBits element to support calculating locations of list entries that use the end of the container (e.g. referenceLocation="containerEnd"). Note that an IntegerValueType element is preferred over an integer attribute since it supports fixed, dynamic and conditional values.

A SizeInBits element was added in XTCE 1.1

This appears to have been corrected in XTCE 1.1 and this issue was brought over in error.

We have discussed two different methods for the identification of container instances: Inheritance and a Combination of Message Key and Choice. The schema now allows for either, but could be simplified by eliminating one or the other. Lockheed recommends eliminating the MessageKey method in favor or inheritance.

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

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

. In version 1.11 of the schema there was an initialValue attribute for a
Parameter in the ParameterSet but this was removed in 1.12. Now the
initialValue attribute only exists for a ParameterType or ArgumentType. I
think it would make more sense if the initialValue was a Parameter attribute
and not a ParameterType attribute since there could be multiple instances of
the same ParameterType. Right now each of these instances would have the
same initialValue but I think what you really want is for each instance to
be able to define its own intialValue if it has one. Right now if you have
a Type but you want to have different initalValues for it you have to create
multiple Types and I think this makes more work than is really necessary.

Noted. I think this is going to be an ongoing debate amoung XTCE
enthusiasts. Right now the Parameter in ParameterSet is very simple; it is
not 'type' aware. One of the problems we'd have in giving it an initial
value is that we couldn't type check it by the XML validator. Because
ParameterType in ParameterTypeSet knows it's type it can type check (i.e.,
the initialValue for an IntegerParameterType will only accept an integer,
the initialValue for a StringParameterType accepts a string ...).

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

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

In the CommandContainer under the MetaCommand, inside the EntryList,
there is a division between groupings of the Parameter/ContainerRefEntries
and the FixedValue/ArgumentRefEntries. The problem is what this does is
make you have to define ALL your ParameterRefEntries and ContainerRefEntries
BEFORE defining any FixedValues or ArgumentRefs inside a CommandContainer.
For example, the following sequence of entries would be illegal for a
CommandContainer:
FixedValueEntry-ContainerRefEntry-ParameterRefEntry-ArgumentRefEntry.
Unless there is a legitimate reason for the separation, I think the
FixedValueEntry and the ArgumentRefEntry needs to be added to the same
grouping that the ParameterRefEntry/ContainerRefEntry is in.

You're probably right. We simply extended the EntryListType to create a
CommandEntryList type. While this keeps the schema simpler, it does make
the XML documents messier. We usually opt for better XML over better
Schema.

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

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

Another question involving the CommandContainer. In the CommandMetaData
there are two ways to create a CommandContainer: inside a MetaCommand or
inside the CommandContainerSet. For some reason the CommandContainer inside
the MetaCommand has an ArgumentRefEntry and a FixedValueEntry but the
CommandContainer inside the CommandContainerSet does not. The reason they
are different is that the CommandContainer inside the MetaCommand is of
CommandContainerType, but the CommandContainer inside the
CommandContainerSet is of SequenceContainerType. Is this an error in the
schema or is there a reason that these CommandContainers are of different
types?

The reason why there's a CommandContainer inside the CommandContainerSet is
so containers that are used/re-used by many commands could be defined there.
Since these Containers are not associated with any particular MetaCommand
and arguments are local to a MetaCommand, it would be a mistake to allow
them to contain arguments - we wouldn't know which argument to use.

Agree with the description

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

The are no OBSW space element, specific additional information such as OBSW version,
memory that is read, write, unreadable, protected, constant, variable, start address, etc.

This may be out of scope of XTCE, but another very common database exchange on modern
missions. OBSW memory map and execution information, which should ideally be included as a very specific space system element. And is the OBSW version that is valid for the database release.

Should be considered as a future specification

AncillaryData may provide enough flexibility to hold some FSW information. However it will be system unique and should be used with care. Otherwise, FSW info is out of the intial scope of XTCE (command & telemetry) and would require new revisions and probably a new RFP from the OMG to address it.

There are no specific descriptions of onboard memory possible, i.e. block size, addressing technique, etc as per tables 12, 13 of the ECSS. This I would expect at the space-system
description level?

Onboard memory is a very specific type of space system element, for which a lot of specific data is always needed, and it would be worth making specific entry types appropriate to onboard memory system elements. This to include Memory ID, Accessibility (read,write), smallest addressable unit, addressing technique, block length, subblock symbolic name, subblock offset, subblock length, etc

Should be considered as a future specification

Onboard memory handling between different spacecraft and ground systems has been even more varied than commands and telemetry. To the extent that onboard memory locations can be named and brought down as "software telemetry" they are supported by XTCE, however, an exchange format for memory definitions beyond telemetry parameter definition is out of the current scope. It is possible that this could be addressed by a future specification, but there are also numerous specifications for memory data for ordinary ground-based computer systems (Motorola S-records, Intel Hex format, Unix STABs, etc.) that may be applicable.

SCOS 2K uses another type of calibrators that is not supported by XTCE. XTCE should provide a way to support a kind of logarithmic (or custom) calibrator. The calibration is defined by the following equation: Y = 1/

. Ln is the natural log (base e), and Ai are coefficients stored for the calibrations. Of course such a
calibrator will need, as others, a short description and a name. If this thought as not generic
enough, then XTCE should give a way to describe non standard calibrators. For example, coefficient, base, exponent in a term sum used as a calibrator.

Specification allows custom calibration types

The MathOperationCalibrator was included to cover conversions that are not a simple linear or polynomial conversion. Since only one known system supports the logarithmic conversion, it can use this element. SCOS 2000 converters could recognize the internal conversion from the sequence of ln() operators and use the internal conversion type rather than a custom derivation. Other systems that do not implement the logarithmic conversion will only be able to support it through a custom derivation. An XTCE example of the formula above with coefficients, -5, 1, .1, .01, .001, is shown below.
<xtce:FloatParameterType name="LnConvertedType"
shortDescription="Example of natural log conversion using RPN calibrator">
<xtce:UnitSet /><xtce:IntegerDataEncoding sizeInBits="16">
<xtce:DefaultCalibrator>
<xtce:MathOperationCalibrator>
<xtce:ThisParameterOperand/>
<xtce:Operator>ln</xtce:Operator>
<xtce:ValueOperand>4</xtce:ValueOperand>
<xtce:Operator>y^x</xtce:Operator>
<xtce:ValueOperand>.001</xtce:ValueOperand>
<xtce:Operator>*</xtce:Operator>
<xtce:ThisParameterOperand/>
<xtce:Operator>ln</xtce:Operator>
<xtce:ValueOperand>3</xtce:ValueOperand>
<xtce:Operator>y^x</xtce:Operator>
<xtce:ValueOperand>.01</xtce:ValueOperand>
<xtce:Operator>*</xtce:Operator>
<xtce:Operator>+</xtce:Operator>
<xtce:ThisParameterOperand/>
<xtce:Operator>ln</xtce:Operator>
<xtce:ValueOperand>2</xtce:ValueOperand>
<xtce:Operator>y^x</xtce:Operator>
<xtce:ValueOperand>.1</xtce:ValueOperand>
<xtce:Operator>*</xtce:Operator>
<xtce:Operator>+</xtce:Operator>
<xtce:ThisParameterOperand/>
<xtce:Operator>ln</xtce:Operator>
<xtce:ValueOperand>1.0</xtce:ValueOperand>
<xtce:Operator>*</xtce:Operator>
<xtce:Operator>+</xtce:Operator>
<xtce:ValueOperand>-5.0</xtce:ValueOperand>
<xtce:Operator>+</xtce:Operator>
<xtce:Operator>1/x</xtce:Operator>
</xtce:MathOperationCalibrator>
</xtce:DefaultCalibrator></xtce:IntegerDataEncoding>
</xtce:FloatParameterType>

CNES remarks and recommendations for the XTCE norm CNES (French Space Agency) has led a study to determine if and how the XTCE standard can be used in the context of the Myriade project. (Myriade is a microsatellites family, initiated by Demeter, Parasol …). Some files produced by the actual Myriade data base (called BDMS)for the CCC Control Center have been translated in XTCE. Here are the results of this study : About Telemetry : We have chosen the decommutation plan which is one of the most representative file among those who are exported from the system data base. In this file we have chosen a significant TM packet (called ECU) with a structure containing a discriminating element (part of the telemetry depends on the value of a parameter called a "selector"). The complexity is to separate the data from the processes in the BDMS to define the best implementation with theXTCE norm. We see that the data in the XTCE file must be processed in order to obtain the expected file (addition of ground calculated parameters, renaming of some parameters, calculation of the offset, ...). For the XTCE norm itself, we can notice that there are two ways to define conditional structure. We think that, at least, a way to use XTCE must be recommended in order to obtain a homogenous implementation in different projects. About Telecommands We encountered some difficulties in trying to implement the example of TC with the XTCE norm. We found a lot of similarities in the definitions of types included in the TelemetryMetaDataType and the CommandMetaDataType elements. In some cases, these similarities present slight differences, which are obviously not enough justified with sufficient explanations (ie the definition of the CommandContainer is different coming from CommandMetaData/MetaCommandSet/MetaCommand or coming from CommandMetaData/CommandContainerSet), and therefore resulted in some confusions. The structure of nested types is not easy to assimilate. Some information seem to be redundant inside a type. It would be useful to have more explanations of this case. At first, the information provided by the TC example and the elements defined in the XTCE norm didn’t fit. We finally carried out a way to proceed, nevertheless, there is no evidence that our solution is the best one. The point that is not resolved is how to implement the variable argument. Conclusion of the study Within the framework of this study, the scope of TM/TC implemented with XTCE clearly appeared as limited. We focused our study on a subset of one TM packet, and also on one specific TC. As a result, the first step can be consider positive. However, in the absence of a more exhaustive study which encompass more possibilities of XTCE, the overall feasibility is still pending. The most important problem of the norm is that it is very complex, and difficult to learn, even for engineers experimented in XML, and data base schemas. Its complexity comes from its genericity. We think that there are too many ways to define a TM packet with this norm to be sure that every project will define its telemetry using the same philosophy. In the SpaceSystem schema which describes the norm, the <Annotation> sections are very succinct and sometimes not sufficient. So, in order to help users to understand the schema, the chapter 6 (The Specification) of the XTCE norm should contains more in-depth explanations. Moreover, the standard is far from being user friendly due to excessive offered possibilities in terms of implementation. We did not find any example corresponding to our needs. The available documentation is surely not designed for an easy learning. Of course, a tutorial is to be issued. A solution to reduce the learning effort could be to define a smaller kernel of the norm, with some possible extensions for some specific use. One important lack of the norm seems to be that it does not enable a user to define its own tags and attributes in order to complete the description. This could be the solution to avoid changing the norm each time a particular need appears in a project. Another important remark we have to make is about the state of XTCE. The norm has changed a lot between the OMG version of 2004 and the referenced CCSDS red book. It seems not to be still defintly defined. This fact is very important because if we want to use the norm in an operational context, with have to be sure that there will not have big changes before starting the development of tools based upon the norm. Tools are mandatory to use this norm because it is quite impossible to create a full XTCE file with a simple XML editor. When the norm will be approved, the XML-oriented database can be the next step in the XTCE deployment. It could be interesting to have a generic code that enables the updates of a database by reading a XTCE file and enables the extractions from a database to produce some XTCE files. Xavier Passot CNES DCT/SB/CC With Erwann Poupart (CNES DCT/PS) and Frederic Berriri (CS/SI)

Future XTCE profile specifications and validation tools

Good examples would enhance the specification, but at this point the examples are emerging from the communities of use (CCSDS, US Government) and are probably most appropriate to be included in those specifications, since they will differ by community.

Source: Mario Merri Mario.Merri@esa.int
Description : In an ideal world, the Project Manager of a new space mission would

like to have a
simple life and put a single requirement to the Spacecraft Prime Contractor that
reads something like: "It shall be possible to export the operational database into
XTCE (ref. .)".

To have project managers buying in XTCE, we should be able to demonstrate the
goodness of the requirement above and explain that the Prime Contractor will have
to produce a simple tool to translate from their internal DB format into XTCE.
Therefore, the questions are:

a) are the XTCE specifications enough to unambiguosly develop the software tool
that translates into XTCE?

b) Where should a new mission start from? (missions tend to re-use what has
been done by other mission before. In the absece of a predecessor is there any
help that we coulf provide to missions?)

Clarification and possibly real-mission examples should be provided to clarify the
above.
Resolution: Update introductory section and consider development of associated

tools (e.g.
validator).

Future XTCE profile specifications and validation tools

Some communities of use (US Government and CCSDS) are establishing more specific restrictions that will either be published as companion specifications in OMG or as standalone specifications within the community of use. The creation of a validation tool would be appropriate for the community of use to verify that a valid XTCE document meets the more stringent restrictions.

Source: Hans.van.der.Meij Hans.van.der.Meij@es
Description : In a number of places in the schema it is possible to define similar/equal properties
of a parameter type.

E.g. for an IntegerParameterType definition, the sizeInBits and the signed-ness
can be be defined as attributes, and it is possible to define this type of information
in the IntegerDataEncoding child.

Please clarify which is the preferred way to specify this type of information and
what is provided by XTCE to avoid ambiguities and inconsistencies.

In any case, it is recommended to either update the specification to take out the
flagged redundancies or to update the text to clearly define the intended use.
Resolution: The document will be edited to clarify the differences between the two proprieties.
The Integer parameter type describes how to handle the parameter in the ground
software, while the Encoding integer type describes how the parameter is encoded
in either the TM or TC.

Add clarifying information in section 6.1.2.1.

In section 6.1.2.1 in the next to last paragraph (paragraph before reference to Figure 4) add clarifying information.

ource: Makoto Kawai kawai.makoto@jaxa.jp
Description : Type of element[MessageRef] in element[MessageRefSet] in type

[ServiceType] is
undefined.

To change as below.

From: "
<element name="MessageRef" maxOccurs="unbounded"/>"

To: "
<element name="MessageRef" type="xtce:MessageRefType"
maxOccurs="unbounded"/>"

Corrected in Version 1.1

This issue appears to have been written against version 1.0. The deficiency was corrected by the version 1.1 RTF with the resolution of issue 10162.

ource: M. Pecchioli mauro.pecchioli@esa.i
Description : There are many specific (and non-obvious) terms used in this

standard. They
should be introduced and explained clearly in Section 4. Unfortunately, in the
current version of the standard, only the obvious terms (telemetering and
command) are defined. In the state where it is, the standard cannot be really
understood and thus reviewed without a very significant effort.
Resolution: CLARIFICATION Add additional terms

Variation in terminology

There is considerable variation in terminology and definitions, depending on the community of use. There are other efforts to assemble ontologies for space systems. Including one in this specification would be duplicative and not necessarily definitive.

Source: Thomas Huang txh@mipl.jpl.nasa.gov
Description : There are a few minor cosmetic errors
In the Green Book - Page 15 - <TAG>data<\TAG> should be <TAG>data</TAG> -
Page 22 - missing '/' before SpaceSystemV1.0.xsd in xsi:schemaLocation - Page
36 - same problem as in Page 22.

In the Red Book - Page 13 references 'Appendix A'. I think it should be 'Annex A'.

• Page 24 - sub-heading 6.1.3.2.6 used twice (for Interlock and Verifiers) - Page

25

• perhaps a page and/or section break before '6.2 The Schema'. - Page 70 -
  perhaps a page/or section break before 'Annex B'.

Corrected in a previous revision.

This issue appears to have been written against the adopted specification and was resolved in the finalization to publish version 1.0.

Source: Makoto Kawai kawai.makoto@jaxa.jp
Description : Currently, the definition of element[SyncStrategy] in type

[FixedFrameStreamType]
is described by complexContent. To make the structure more simple, I
recommend to use type[FixedFrameSyncStrategyType] in
type[FixedFrameStreamType].

From: "<element name="SyncStrategy"> ... </element>" To: "<element
Resolution: Agree (with discussion). Suggest instead simply deleting
FixedFrameSyncStrategyType (since it is would be used at most once).

Corrected in a previous revision.

This issue appears to have been written against the adopted specification and was resolved in the finalization to publish version 1.0.

Description : Currently, element[ContextCalibrator] in element

[ContextCalibratorList] in
type[IntegerDataEncodingType], [FloatDataEncodingType] and
[StringDataEncodingType] are defined by complexContent. To make the structure
more simple, I recommend to use type[ContextCalibratorType] in
type[IntegerDataEncodingType], [FloatDataEncodingType] and
[StringDataEncodingType].

From: "<element name="ContextCalibrator" maxOccurs="unbounded"> ...
</element>" To: "<element name="ContextCalibrator"
type="xtce:ContextCalibratorType" maxOccurs="unbounded"/>"
Resolution: Good input. Fix schema and associated documentation.

Corrected in a previous revision.

This issue appears to have been written against the adopted specification and was resolved in the finalization to publish version 1.0.

Source: Gert Villemos gev@terma.com
Description : The schema file should be clearly identifiable, i.e. the XTCE

document version
referenced and/or the schema file version number changed.
Resolution: Add version number to document

Corrected in Version 1.1

This issue appears to have been written against a draft prior to schema version 1.1. The version number appears in a documentation element near the beginning of the schema and should be updated with each new specification version.

ource: D.Campbell dave.campbell@scisys
Description : Lines 5-7. What is the information which states how encoding should

be
performed? The text mentions the "Encoding area" - where / what is this? What
constraints are there / what documents specify how the encoding is to be
performed? Should this information be included in this standards document?
Different agencies may misinterpret how to use the encoding information unless its
use is also standardised in some document.
Resolution: Add clarifications to the text

Merge with other parameter encoding issue

Duplicate of parameter encoding issue already resolved.

Source: Michael Staub michael.staub@dlr.de
Description : Add page numbering to document.

Corrected in a prior revision

This issue appears to have been written against a draft prior to version 1.1. All pages of the specification document have proper numbering

Source: Michael Staub michael.staub@dlr.de
Description : Reword: "The space industry is fragmented between Packet telemetry

and
commanding and Time Division Multiplexing (TDM) telemetry and commanding."
Resolution:
Title: MS-001 Missing page numbering
Source: Michael Staub michael.staub@dlr.de
Description : Add page numbering to document.

Corrected in Revision 1.1

This issue appears to have been written against a draft prior to version 1.1. The wording of the paragraph in version 1.1 is clearer.

8 - Add activity field to Alarms to indicate what the alarm will trigger (ESA-015)

Defer (further discussion needed)

Future replacement specification

Linkage of operations procedures/activities to alarms was not in the original RFP requirements and was not addressed by any of the submissions, therefore this is an enhancement request that could be considered in a future RFP/RFC.

5 - Align XTCE and CCSDS Navigation Schemas (types) (JPL-029)

Defer (possible future work area)

Future replacement specification

The CCSDS Navigation schema has progressed with their own element types. There is limited overlap between the two specifications, and a unification of element types would be an enhancement request to the XTCE specification. This enhancement could be considered in a future RFC/RFP.

3 - Use UML Instance diagrams for XTCE document example (ESA-038)

Defer (more appropriate for XTCE CCSDS Green/Magenta Books, future work area)

Future XTCE profile specifications and validation tools

Good examples would enhance the specification, but at this point the examples are emerging from the communities of use (CCSDS, US Government) and are probably most appropriate to be included in those specifications, since they will differ by community.

2 - Add separate CalibratorSet to XTCE as many legacy system hold calibrators in tables (ESA-006)

Defer (breaks current XTCE model, complexity)

Not essential to information exchange

Systems that use a table of calibrations/conversions referenced by individual parameters can generate that table from an XTCE document by reading and identifying duplicate calibrators when inserting them into the table. Requiring that structure in the XTCE schema is not essential to the information exchange.

1 - Support ability to describe redundant or complimentary data (ESA-001)

Defer (complexity)

Should be considered as a future specification

General relationships between command and telemetry items falls more in the realm of ontologies, and is out of scope of the original XTCE RFP.

A fixed value cannot be added to a container created in the ContainerSet but only to a
container created in the MetaCommand object. In SCOS 2K, fixed values would be added in
the Meta Command and this cannot be done. Add the Fixed Area support to container defined with the MetaCommand would help

Specification allows fixed values in CommandContainers

XTCE does support the required functionality of a fixed value, and combinations of containers can support the desired structure. The element FixedValueEntry is available in the MetaCommand/ CommandContainer/EntryList but not in the CommandContainerSet.
One possible workaround would be to carefully "divide" a container between metacommand and command container. In other words given a container that consists of 11 parameters, let the 6th one be fixed. Simply create two containers, the 1st contains the first 5 parameters. This would be ref'd in MetaCommand area. Then define the 6th FIXED value, and finally Ref the 2nd set of parameters in 2nd container in the metacommand entry list.

Source: D.Campbell dave.campbell@scisys
Description : From: "Element and Type names begin with a capitol letter."
To: "Element and Type names begin with a capital letter."
Resolution: Fix text and associated schema annotation

Corrected in Revision 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : From: "a TransmissionContraintList"
To: "a TransmissionConstraintList"
Resolution: Fix text

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : From: "overidden"
To: "overridden"
Resolution: Fix text

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

ource: D.Campbell dave.campbell@scisys
Description : From: "the UML refenceces"
To: "the UML references"
Resolution: Fix Schema annotation and text

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : Is this a typo?
From: "minorFrame 20"
To: "minorFrame 8"
Resolution: Fix text 6.2.2.3

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : No label or Figure number
Resolution: Fix text

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : Lines 8. "All of the encoding information is in the Encoding area." What is this,
where is it defined, and why is it not included in the list of terms?
Resolution: Fix text

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : From: "Most Arguments, are"
To: "Most Arguments are"
Resolution: Fx text

Corrected in Revision 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : From: "is is possible"
To: "it is possible"
Resolution: Fix

Corrected in Revision 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : From: "a Parameter it is not the value itself."
To: "a Parameter is not the value itself."
Resolution: Fix text

Corrected in a prior revision

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : From: "The collection of messages to search thru"
To: "The collection of messages to search through"
Resolution: Fx text

Corrected in Revision 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : From: "RF hardware and other many other assets"
To: "RF hardware and many other assets"
Resolution: Fix text

Corrected in Revision 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : From: "user access our confirmations"
To: "user access confirmation"
Resolution: Fix text - actually should read "user access or confirmations"

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : "CommandMetaDataType" lists its attributes, but the attributes in
"TelemetryMetaDataType" are missing.
Resolution: Correct UML figure

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

9 - Add filtering of value threshold to maintain telemetry at certain rates (ESA-048)

Defer (additional discussion, future work area)

Add optional change filtering attribute to numeric parameters

Exchange information for this functionality (change threshold) can be incorporated by adding an optional attribute to the IntegerDataEncodingType and FloatDataEncodingType without breaking existing export and import implementations.

7 - Use UUIDs instead of current XTCE Referencing mechanism (ESA-005)

Defer (complexity, no agreement on approach, further consideration needed)

Future replacement specification

UUIDs may be a useful way to coordinate separate development of related XTCE documents. This was not one of the requirements in the original RFP, and was not addressed by any of the submissions, therefore this is an enhancement request that could be considered in a future RFP/RFC.

6 - Add ToString to Boolean or remove Boolean in favor of Enumerated Types (ESA-007)

Defer (no agreement on approach)

Not essential to information exchange

While there is overlap between the concepts, Boolean and enumerated types are both supported in most programming languages because of implied differences in meaning. For that reason, XTCE will continue to support Booleans as a separate data type. Booleans can be implemented as an enumerated type by ground systems, but for a round-trip exchange, the True/False enumerations would have to be recognized as an XTCE Boolean.

4 - Separate XTCE Schema into constituent parts (JPL-016,022,026,030)

Defer (possible future work area

Future replacement specification

During the combination of the original submissions and finalization, the schema was separated into related sections. XML tool support was poor at the time for schemas with includes. While tool support has improved, splitting the specification at this time would break existing implementations and is considered an enhancement request for future RFPs/RFCs, but is out of scope for the XTCE 1.x specifications

The following command makes use of a repeat block of arguments:

ack_packets ( num_acks, ack_block )

Ack_block consists of three arguments: pkt_start, pkt_end and pkt_time

This would be a perfectly valid command:

ack_block[0].pkt_start = 1
ack_block[0].pkt_end = 1
ack_block[0].pkt_time = 00:00:00

ack_packets ( 1, ack_block )

This is not capturable in XTCE because there is no mechanism for having REPEATS of ARGUMENTS.

There are workarounds but there are less than ideal, they are:

– use an array, this is problematic because the types of each sub-field may be different (see above, pkt_time is a TIME type)
– treat them as parameters... which they are not...

Repeating arguments for memory loads

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

Specifying array dimension sizes in arrayParameterRef should be optional. In telemetry arrays often include an on the fly 'count' in the data packet. Therefore this may come in conflict with the fixed sizes in the dimension list.

The other option is to clearly state in the annotation that the dimensionList is mearly an hint to the run-time software and more more processing will need to be done to ascertain the true size.

Finally, a further option would be to have the dimensionList optionally look up the dimension size using a InstanceRef to another parameter in the data stream...

Merge with 14455 resolution.

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

Source: D.Campbell dave.campbell@scisys
Description : From: "While, the basic"
To: "While the basic"

Corrected in previous revision

This appears to have been an issue against the adopted specification draft. It does not apply to either of the formally published revisions 1.0 or 1.1.

Source: D.Campbell dave.campbell@scisys
Description : Should "deramdomization" be de-randomisation" with an 'n' and an 's'?
Resolution: Not sure about the 's'

Typo corrected in previous revision

See issue 10237 in RTF Report dtc/06-12-02 for disposition (typo corrected in previous revision)

Source: D.Campbell dave.campbell@scisys
Description : From: "in all phases of the a spacecraft"
To: "in all phases of the spacecraft"
Resolution: Fx

Corrected in previous revision

This appears to have been an issue against the adopted specification draft. It does not apply to either of the formally published revisions 1.0 or 1.1.

Description : From: "support of all phases of the satellite"
To: "support all phases of the satellite"

Corrected in previous revision

This appears to have been an issue against the adopted specification draft. It does not apply to either of the formally published revisions 1.0 or 1.1.

MK-007 Don't need element[ChangePerSecondAlarmConditions] intype[NumericAlarmConditionType]
Source: Makoto Kawai kawai.makoto@jaxa.jp
Description : Currently, element[ChangePerSecondAlarmConditions] is defined in
element[ConditionalAlarm] in type[NumericAlarmConditionType], but Change rate
evaluation cannot apply to Conditions. To change as below.

From:
"<element name="ConditionalAlarm"> <annotation>
<documentation>…</documentation> </annotation>
<complexType>
<sequence>
<element name="StaticAlarmConditions"
type="xtce:AlarmConditionsType" minOccurs="0"/>
<element name="ChangePerSecondAlarmConditions"
type="xtce:AlarmConditionsType" minOccurs="0"/>
</sequence>
</complexType>
</element>"

To: "
<element name="ConditionalAlarm"> <annotation>
<documentation>…</documentation> </annotation>
<complexType>
<sequence>
<element name="StaticAlarmConditions"
type="xtce:AlarmConditionsType" minOccurs="0"/>
</sequence>
</complexType>
</element>"
Resolution: To be even clearer, we should change "StaticAlarmConditions" to simply
"AlarmConditions". Fix schema and supporting documentation

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

Source: Michael Staub michael.staub@dlr.de
Description : Is command parameter processing intentionally left out? On the other hand, TM
calibration is mentioned. The same is valid for command packetization.
Resolution: but for command arguments
Title: GV-007 Dependencies or aggregation
Source: Gert Villemos gev@terma.com
Description : The UML diagrams seems to use dependencies (arrow) instead of aggregation (line
with diamond). From the context, aggregation is meant. It is not clear whether the
UML diagrams are intended only to illustrate the definition or actually be formal
Resolution: Notation was decided by the tool that was used to do reverse engineering (from
XML Schema to UML). It is agreed that the suggested representation is more
correct.

ACTION GV-007-01: Gert Villemos to provide updated UML diagrams for XTCE.
Due 30May05

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : Lines 2-4. Same query as for DC-013 and DC-017. The types listed do NOT
contain "the knowledge for how to assemble, disassemble and process spacecraft
uplink and downlink streams" - they may hold the constraint or type information
required by the assembly / disassembly methods, but they do not define the
knowledge of how to do this. There needs to be another document which does
Resolution: Propose revised text 6.1.2.5

Examples developed by communities of use

Good examples would enhance the specification, but at this point the examples are emerging from the communities of use (CCSDS, US Government) and are probably most appropriate to be included in those specifications or related tutorial documentation, since they will differ by community.

Source: D.Campbell dave.campbell@scisys
Description : Lines 2-3. Same query as for DC-013. How is this information used to assemble an
uplink / disassemble a downlink? And where are these methods of assembly /
disassembly defined? More information in this document or inclusion of a reference
to the relevant document would be useful.
Resolution: The XTCE powerpoint tutorial contains the best explanatory information on XTCE.
Text should be updated to add clarity to the assembly/disassembly mechanisms.

Examples developed by communities of use

Good examples would enhance the specification, but at this point the examples are emerging from the communities of use (CCSDS, US Government) and are probably most appropriate to be included in those specifications or related tutorial documentation, since they will differ by community.

ource: M. Pecchioli mauro.pecchioli@esa.i
Description : It seems that logarithmic calibrations are not supported by the

standard. I think
this should be added.

-----Added after meeting with clarification by MP of 18Apr05:

What we support in S2K is the following:

In the case of parameters associated to a logarithmmic calibration, the engineering
value ‘Y’ corresponding to the raw value ‘X’ of a parameter is calculated using

the
following formula:
Y = 1 / [A0 + A1*ln(X) + A2*ln2(X) + A3*ln3(X) + A4*ln4(X)]
Resolution: Question: Would a polynomial approximation be close enough? What

forms of
logarithmic calibration are required: natural, base 10 other. What direction of
conversions are required?

Discussion: what is ln2 (a base 2 log or the second natural log?)

Merge with Calibrator Issue

XTCE12-152 contains a better description of the missing calibration capabilities.

Source: D.Campbell dave.campbell@scisys
Description : From: "markup documentation,"
To: "markup documentation)"
Resolution: Fix text

Corrected in a prior revision

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : This should explain how MetaCommand arguments are used compared to
Command arguments and how they relate to each other, if at all.
Resolution: Clarify text

Corrected in previous revision

This appears to have been an issue against the adopted specification draft. The schema annotation describes the purpose of the MetaCommand arguments.

Source: Makoto Kawai kawai.makoto@jaxa.jp
Description : Alarm element is just defined in Integer and Float type in ParameterType,
ArgumentType in type[ParameterTypeSetType] and element[ArgumentTypeSet],
but all ParameterType and ArgumentType (especially, enumerated type) are to
have alarm element.
Resolution: Agree, but implementation of Alarm for non-numeric types needs to be discussed

Duplicate of current and previously corrected issues

See issues 14461 and 14466 for more specific alarm element issues. EnumeratedAlarmType already added during finalization.

Source: Makoto Kawai kawai.makoto@jaxa.jp
Description : The annotation of type[ContainerSegmentRefEntryType] is to be changed as
below.

From: "An Entry ... order=0" To: "An Entry ... portion of a container. It is assumed

Does not add to clarity

The annotation was reviewed and is correct in the existing schema. The suggested change does not add to the clarity.

Source: D.Campbell dave.campbell@scisys
Description : "MessageSet" is not shown in Figure 1 or Figure 7.
Resolution: Figure 7 does not show a MessageSet because it is not part of
CommandMetaData (whether it should be is another discussion).

Revise Section 6.1.3

Remove the erroneous reference to MessageSet in section 6.1.3. It is not a part of CommandMetaData.

Source: D.Campbell dave.campbell@scisys
Description : Lines 6-7. Same query as for DC-013, DC-017, DC-021. An argument may "include
information about how the value is encoded for transmission", but there’s nothing
in the document to define how this information should be used. So where is that
defined? "All of the encoding information is in the Encoding area." What is this,
where is it defined, and why is it not included in the list of terms?
Resolution: Text should be updated for clarification

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

Source: M. Pecchioli mauro.pecchioli@esa.i
Description : It seems that only alarms based on static definition of the allowed value ranges are
supported. Spacecraft control systems also require the support of checks against
a dynamic reference, either maintained based on commanding activities (this is
known as Status Consistency Checks in SCOS-2000) or maintained using
telemetry data (this is known as Delta checks in SCOS-2000). Provision for this
type of checks (against a 'moving' reference) shall also be made in XTCE.
Resolution: XTCE does support a form of Delta Range checks called "ChangePerSecond".
Question to RID author: "is this what you are looking for, or are you looking for
something else?" Status consistancy checks should be added to the schema. It
is believed that XTCE does support the RID authors's requirements for Delta
checks.

Add clarification for Delta checks.

Alternatives for Dynamic Alarm Checking

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : From: "Most Parameters, are"
To: "Most Parameters are"
Resolution: Fix text

Corrected in Revision 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : From: "the organization of the data may be organized hierarchical structure"
To: "the data may have a hierarchical structure"
Resolution: Fix text

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

Footing of Figure 1 is missing.
Source: Michael Staub michael.staub@dlr.de
Description :
Resolution: Add footing

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

Source: D.Campbell dave.campbell@scisys
Description : From: "Figure 3 ParameteTypeSet"
To: "Figure 3 ParameterTypeSet"

Corrected in XTCE version 1.1

No change dispositions from original poll 2.

– Xpath: xpath is the XML answer to unix-style paths but includes MATCHING, the ability really to get some chunk of any XML document using an Xpath expression. We should consider Xpath as the format for Refs... but there needs to be a technical debate.

"... A reference to a Parameter. Uses Unix ‘like’ naming across the
> SpaceSystem Tree (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage). To
> reference an individual member of an array use the zero based bracket
> notation commonly used in languages like C, C++, and Java."

No Xpath for cross-references

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

command side unable to describe "packed commands" where multiple commands are packed into a single packet (MER)

It isn't clear metacommand which itself represents a command in XTCE can package more than one command. Essentially this is multiple commands stuffed in a single packet

Use nested command containers

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

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

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

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

Should "deramdomization" be de-randomisation" with an 'n' and an 's'?

Typo corrected in previous revision

See issue 10237 in RTF Report dtc/06-12-02 for disposition (typo corrected in previous revision)

Too complex, ( I have some examples from the ASIST meeting ).

Future model-based specifications

There is substantial variation in the capabilities and features of existing ground and space systems. The increasing complexity of space-systems, as they transition to greater reliance on software, makes it difficult to reduce complexity and still span the variation in systems. Community of use-based limitations are emerging which simplify the application of XTCE, and these should result in new companion specifications. Eventually a new specification for software-based ground-space interfaces, based on other OMG software communication specifications, e.g. CORBA, DDS, IDL, will be required to satisfy more complex systems.

USE CCSDS examples how to use the standard ( we can provide data set with tlm & commnad)

Examples of use will be defined by the community

Good examples would enhance the specification, but at this point the examples are emerging from the communities of use (CCSDS, US Government) and are probably most appropriate to be included in those specifications, since they will differ by community.

Ambiguity - The is too much leeway how to use the standard, and things are left for interpretation. The standard allows / calls for users to add thier own items when they are missing. Need to tighten the standard so things will be done consistently