[CESG] FW: [Smwg] Re: My comments of latest draft of charter

[Shames, Peter M (313B)]

The SM WG standards are specifically focused upon the unambiguous, interoperable, and cross supportable exchange of requests for communication network TT&C and related services.  This is intended to be a single, common, interface for users to request provided services from the space communications networks.  The content of the standards have, to date, specified the information content, syntax, and semantics of these exchanges.  They have also identified specific abstract service interface behaviors in the exchange of these requests and responses.  They do not specify any required service or transport implementation, the binding to date are at the level of XML message / document exchanges.  There is no requirement as yet to use any specific message or transport mechanisms, but a normative binding to some existing widely adopted standard, such as secure HTML and RESTful services may well occur in the future.  None of this imposes any constraints on how these service providing (or user client) elements are implemented internally.

The SM&C suite of standards, which is very broad in its coverage, is intended to standardize the implementations of mission operations systems, defining an abstract message bus, multiple encodings, and multiple underlying transport mappings.  On top of this there is a set of common services and a set of mission operations services that are described but not yet defined.   The SM&C services are intended to be built in an integrated fashion, utilizing the MAL and other lower level common services.  As such the SM&C is trying to define a lot of the characteristics of how mission operations systems are implemented internally.  The several different MAL encodings and underlying transport bindings mean that individual implementations may not interoperate unless there are translating bridges implemented to translate between one set of encodings / bindings and another.   There is not a single binding, but multiple ones, and the designed framework is intended to be pervasive throughout and within the implemented systems.

Any SM&C MO systems that are fielded will need to interface to the cross support transfer service interfaces (CSTS & SLE) that have already been fielded by most of the IOAG agencies.  The SLE/CSTS services are intended to provide high performance interfaces for the reliable transfer of telemetry and command data, and radiometric, monitor & control data, along with the necessary annotations and performance information.   These are designed for interoperability and cross support using defined and unambiguous bindings on top of TCP/IP.  I should note that in the early days of SLE there were two different transport bindings, one to TCP/IP and another to ISO 8473, along with the necessary bridge / translation plumbing. This was soon abandoned in favor of the single, more pragmatic, TCP/IP binding in use today.

The Service Management (SM) request interfaces are designed to provide the means for users of the SLE/CSTS transfer services to plan, schedule, request, configured, monitor and manage these services.  As such these must conform to the functionality designed in the CSTS / SLE services and also must be defined in an unambiguous, interoperable, and cross supportable fashion.  This should not be bound to the internals of either the service provider nor service user implementations.  Rather it should be an interoperable and cross supportable interface that places no other demands on the internals of these provider and user systems.

As such, attempting to bind the SM interoperability and cross support interfaces to a framework that is intended to assert design and implementation constraints on the user and provider systems seems like a very poor choice.  The simple choice of adopting existing, open, widely used and implemented, HTTP / REST and XML or similar interfaces is a much more prudent and pragmatic choice.  Forcing adoption of the SM&C approach should be avoided for these interoperability and cross supportable interfaces since it would place requirements on internal implementations that need not be levied.

Regards, Peter Shames

________________________________________________________

Peter Shames
CCSDS System Engineering Area Director

Jet Propulsion Laboratory, MS 301-490
California Institute of Technology
Pasadena, CA 91109 USA

Telephone: +1 818 354-5740,  Fax: +1 818 393-6871

Internet:  Peter.M.Shames at jpl.nasa.gov
________________________________________________________

We must recognize the strong and undeniable influence that our language exerts on our ways of thinking and, in fact, delimits the abstract space in which we can formulate - give form to - our thoughts.

Niklaus Wirth



From: <Hooke>, Adrian Hooke <Adrian.J.Hooke at jpl.nasa.gov<mailto:Adrian.J.Hooke at jpl.nasa.gov>>
Date: Wednesday, 18 July 2012 7:59 AM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Subject: [CESG] FW: [Smwg] Re: My comments of latest draft of charter

CESG: comments?

///adrian

-----Original Message-----
From: smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org> [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>
Sent: Wednesday, July 18, 2012 7:52 AM
To: Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>
Cc: Margherita.di.Giulio at esa.int<mailto:Margherita.di.Giulio at esa.int>; Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>; smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>
Subject: [Smwg] Re: My comments of latest draft of charter

Colin,

if I may add to your comments, I find the charter's Goals very fuzzy and overlapping with the SM&C. For instance, the SM&C WG has already defined an "extensible framework ...". So why not re-using it? and why not mentioning it in the section "Survey of Similar Work Undertaken in Other Bodies"?

Either it is very clear that you are addressing a very limited and confined set of services which (for some reason that you will have to explain) requires a specific service framework or we are again going in the direction of creating overlapping (and possibly contradicting) standards.

Ciao

__Mario


  From:       Colin Haddow/esoc/ESA

  To:         smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>

  Cc:         Mario Merri/esoc/ESA at ESA, Nestor Peccia/esoc/ESA at ESA, Margherita di Giulio/esoc/ESA at ESA

  Date:       18/07/2012 16:06

  Subject:    My comments of latest draft of charter
Dear all (in particular Erik),
                                                     please find attached my comments on the latest draft of the new charter.

Cheers for now,

Colin

[attachment "CCSDS SM Recharter 02072012 CRH Comments.docx" deleted by Mario Merri/esoc/ESA]

---------------------------------------------------------------------------------------------------------

Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.

Phone; +49 6151 90 2896
Fax;      +49 6151 90 3010
E-Mail;  colin.haddow at esa.int<mailto:colin.haddow at esa.int>
---------------------------------------------------------------------------------------------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20120718/01518e8a/attachment.htm