[Ccsds-omg-liaison] Re: XTCE Reference Implementation?

Wed Feb 9 11:30:31 EST 2005

Adrian,

I am aware of the following prototypes/developments:

1) ESA/ESOC has developed a prototype that has been used to convert the
SCOS-2000 operational DB into XTCE and back into the SCOS-2000 operational
DB. The purpose of the exercise was to verify the exchange mechanism and no
loss or misinterpratation of data.

Contact person: Mario Merri (Mario.Merri at esa.int)
Documentation: This work is documented in the attached document
(See attached file: OMG Space DTF Compliance report.doc)

2) EADS is using XTCE in the context of the Scaleable Monitoring & Control
System (SMACS)of ISS/Columbus Mission Control Centre. Additionally, in Spring
2005, EADS are planning a prototype for storing XTCE data in an open source
XML Database which allows to browse, access and report the data via a web
portal. Finally, the XTCE based Unified Synoptic System (USS) has been
awarded by ESA to EADS. Development has started last year and the first
version will be delivered in March 2005, second version Sept 2005 and final
in May 2006.
Contact person: Uwe Brauer (Uwe.Brauer at space.eads.net)
Documentation: This work is documented in the attached material
(See attached file: XTCE Application at EADS-ST.zip)

3) Harris Corporation is implementing a translator to allow XTCE input to its
ground system product.  That implementation is currently at an alpha release
level, with product release scheduled for later this year.  It is being
developed in conjunction with satellite database releases in XTCE format from
two different vendors.  However, I don't think those implementations meet the
requirement for "independent", since Harris is providing guidance and
feedback to those satellite groups.
Contact person: Brad Kizzort (bkizzort at harris.com)
Documentation: Available from Brad

Additionally, there are several independent XTCE efforts, including work
within NASA Goddard, Lockheed (USAF/CERES), and Command & Control
Technologies (USAF).  All of these groups have been feeding their issues and
observations during implementation back to the issues list at OMG. We will
collect the various experience.

Given the above, I think that there is enough prototypeing material to
kick-off the CCSDS public review.

Regards,

__Mario

                      "Adrian J. Hooke"                                                                                     
                      <adrian.j.hooke at jp         To:      CCSDS-OMG-LIAISON <ccsds-omg-liaison at mailman.ccsds.org>           
                      l.nasa.gov>                cc:      Takahiro Yamada <tyamada at pub.isas.ac.jp>, Mario.Merri at esa.int,    
                                                 CCSDS Document Rapporteur <Stephen.Harris at btas.com>                        
                      04/02/2005 16:22           Subject: XTCE Reference Implementation?                                    

At 09:07 PM 2/3/2005, Takahiro Yamada wrote:
            c) The XTCE specification consists of:
               - an English specification (English)
               - a machine-interpretable XML schema
               - a PPT format tutorial
            d) The first two (specification) documents need to be
            encapsulated within a CCSDS "Red Book" (Draft Standard) and the
            tutorial within a CCSDS draft Green Book (Report). The Red Book
            then needs to be sent out for expedited CCSDS Agency formal
            review:
      A question. Are there already two independent implementations or plans
      for implementation?

++++++++++++++++++

Takahiro: that's a very good question, which I forgot to ask during the
teleconference. The SM&C-WG and SDTF people should answer it. The CCSDS
requirements are listed below. The XTCE specification is being proposed as an
Issue-1 Red Book andf so Mario should specifically address this when
transmitting the document to the CESG.

///adrian
++++++++++++++++++

CCSDS Draft Standard (Red Book)

Elevation to Draft Standard is a major advance in status, indicating a strong
belief that the specification is mature and will be useful. A second explicit
CESG and CMC approval action is required to move a Proposed Standard to the
Draft Standard level. A Draft Standard must be well understood and known to
be quite stable, both in its semantics and as a basis for developing an
implementation.  It will generally go through several "Issues" during which
time it will progressively become more mature. Every time that an Issue of a
Draft Standard is published, it automatically triggers a formal Agency review
and the results of that review must be satisfactorily incorporated before a
new Issue can be published. Since formal Agency reviews consume resources, a
"review budget" must be agreed by the CESG and the CMC prior to publishing
the first Issue of a Draft Standard; this budget identifies how many review
cycles can be consumed without re-authorization by the CMC. Each separate
Issue must clearly state the status of the specification and must indicate
the risks associated with implementing it in its current state.

At some point in the evolution of a Draft Standard that is intended to result
in a change to mission support infrastructure, at least one hardware or
software prototype (or other implementation) must exist which demonstrates
and exercises all of the options and features of the specification in an
operationally relevant environment, either real or simulated. This point may
be Issue-1, or it may be a later Issue depending on circumstances, but for
most documents the implementation must exist prior to issuing a "final" Draft
Standard. The WG Chair is responsible for documenting the specific
implementation(s) that qualify the specification, along with reports relevant
to their testing, or for justifying why such implementation is either
inappropriate or should otherwise be waived.  The documentation of the
qualifying implementation must include clear statements about its ability to
support each of the individual options and features.  If patented or
otherwise controlled technology is required for the implementation, it must
be demonstrated that the licensing process and fees are fair and
non-discriminatory

In its final stages of Issue, a Draft Standard is normally considered to be a
final specification, and changes are likely to be made only to solve specific
problems encountered.  In most circumstances, it is fairly safe for users to
deploy implementations of the final Issue of a Draft Standard into a
disruption sensitive operational environment.

CCSDS Recommended Standard (Blue Book)

Generally, only a specification for which significant implementation
experience has been obtained may be elevated to the CCSDS Recommended
Standard level. (Exceptions include things like prescriptive Reference
Models, which are not intended to be directly implemented in hardware or
software.)  A CCSDS Recommended Standard is characterized by a high degree of
technical maturity and by a generally held belief that the specified protocol
or service provides significant benefit to the international space mission
community.

Converting a CCSDS Draft Standard to a CCSDS Recommended Standard is always
preceded by a successful final formal Agency review. With a few exceptions
(for which waivers must be sought), conversion of a Draft Standard to a
Recommended Standard also requires that at least two independent and
interoperable prototypes or implementations must have been developed and
demonstrated in an operationally-relevant environment, either real or
simulated. In cases in which one or more options or features have not been
demonstrated in at least two interoperable prototypes or implementations, the
specification may advance to the CCSDS Recommended Standard level only if
those options or features are removed. The WG Chair is responsible for
documenting the specific implementations that qualify the specification for
CCSDS Recommended Standard status, along with reports relevant to their
testing, or for justifying why such implementation is either inappropriate or
should otherwise be waived.  The documentation of qualifying implementations
must include specific statements about its ability to support each of the
individual options and features. If patented or otherwise controlled
technology is required for the separate implementations, they each must also
have resulted from separate exercise of the licensing process and it must be
demonstrated by the WG chair that the licensing process and fees are fair and
non-discriminatory.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OMG Space DTF Compliance report.doc
Type: application/msword
Size: 390144 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/ccsds-omg-liaison/attachments/20050209/db986d9f/OMGSpaceDTFCompliancereport-0001.doc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XTCE Application at EADS-ST.zip
Type: application/zip
Size: 2116844 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/ccsds-omg-liaison/attachments/20050209/db986d9f/XTCEApplicationatEADS-ST-0001.zip