[Ccsds-omg-liaison] XTCE Reference Implementation?

[Adrian J. Hooke]

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/20050204/0b82d6a9/attachment.html