[Ccsds-omg-liaison] XTCE Reference Implementation?

[Kizzort, Brad]

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.  
 
There are several independent XTCE efforts, but I am not up-to-date on their
status, 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.
 
Brad Kizzort
Systems Engineer
Harris Corporation
OMG SDTF Co-chair
 

-----Original Message-----
From: Adrian J. Hooke [mailto:adrian.j.hooke at jpl.nasa.gov]
Sent: Friday, February 04, 2005 10:23 AM
To: CCSDS-OMG-LIAISON
Cc: Takahiro Yamada; CCSDS Document Rapporteur; Mario.Merri at esa.int
Subject: [Ccsds-omg-liaison] 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 --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/ccsds-omg-liaison/attachments/20050207/22265bd4/attachment.htm