[CESG] RE: CESG Telecon issue - return off-line radiometric service / Action CMC-A-2015-05-05

[Gian.Paolo.Calzolari at esa.int]

Dear All,
      I think - irrespective from terminology and rough indications for the
future given by IOAG and SCCS-ARD (with SCCS-ARD of course ahead because more
recent) - CCSDS is going the right direction with a basicIOAG-ARD alignment
and good "investigation" from CSSS Area toward a goof Terrestrial Generic
File Transfer (TGFT).

As I see it, IOAG named three services (Validated Data Radio Metric, RAW Data
Radio Metric, and Delta DOR) and the need is for services being able to
deliver file containing the following type of data:
1) Validated radiometric data; i.e. traditional and Pseudo-Noise ranging
results as well as correlated Delta-DOR data. This data are formatted as
Tracking Data Messages (TDM).
2) Raw radiometric data;  i.e. traditional and Pseudo-Noise ranging data.
This data are formatted as Tracking Data Messages
3) Delta-DOR raw data  or Open Loop Recording data. This data are formatted
according to [DDRXF] CCSDS 506.1-B Delta-DOR Raw Data Exchange Format – Blue
Book.


Now I see the following commonalities/remarks for services 1, 2, 3 above
a) All 3 services transfer files
b) For two services the file contents are formatted TDM
c) For one service the file contents are formatted "Delta-DOR Raw Data
Exchange Format"
d) The files formatted "Delta-DOR Raw Data Exchange Format" are normally
quite big
e) The file requestor needs to request a given file (e.g. data type, date,
time range, etc.)
f) the file sender needs to give information about the file being sent  (e.g.
data type, date, time range, etc.)

I think that items e and f are just what Erik called the thin profile needed
on top of TGFT"

Any further comment?

Ciao

Gian Paolo




From:       "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>
To:         "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>, "CCSDS
            Engineering Steering Group - CESG Exec" <cesg at mailman.ccsds.org>,
Cc:         Tom Gannett <thomas.gannett at tgannett.net>, "Tai,      Wallace S
            \(9000\)" <wallace.s.tai at jpl.nasa.gov>
Date:       12/06/2015 00:48
Subject:    [CESG] RE: CESG Telecon issue - return off-line radiometric
            service
Sent by:    cesg-bounces at mailman.ccsds.org



Peter,

I think what we have concluded (re the CMC actions  for CSS area) is in line
with the ARD and what you have pointed out.    A minor note is that the term
that the CSS Area is using is Terrestrial Generic File Transfer (TGFT),
rather than GFT.

-Erik

From: cesg-bounces at mailman.ccsds.org [mailto:cesg-bounces at mailman.ccsds.org]
On Behalf Of Shames, Peter M (312B)
Sent: Monday, June 08, 2015 5:07 PM
To: CCSDS Engineering Steering Group - CESG Exec
Cc: Tom Gannett; Tai, Wallace S (9000)
Subject: [CESG] CESG Telecon issue - return off-line radiometric service

Dear CESG colleagues,

During the CESG telecon we had a discussion of the return off-line
radiometric service.  I asserted that there was already a template for this
provided in the recently approved SCCS-ARD document, CCSDS 901.1-M-1.

Please take a look at that document, especially Sec 6.2.2.2.33-36 and figure
6-9, on pg 6-17.    See also 4.2.2.2.9 and 4.2.3.2.11.

In these requirements the term "CSTS Transfer File service" is used, since
that is what was in vogue at the time that the spec was written.  The term
that is now in vogue is GFT, but it is essentially the same thing by a
different name.  In the SCCS-ARD it is flagged as a [Future] spec, with the
agreement that these kinds of specs may change as they get finalized.    I
think that this is all entirely consistent with what Eric described in his
recent note re this topic.  Of course, either of these names is somewhat
disjoint from what the IOAG has used, but they are consistent in content and
function to what was described in the original IOAG Service Catalog 1.

The text relating to the inclusion of these [Future] specs states this (Sec
1.3.2):

     Future CCSDS requirements (e.g., service interfaces, protocols, or data
     formats) that are planned, but still under development, are included for
     completeness so that the directions of CCSDS are clear; these are marked
     ‘[Future]’ to avoid ambiguity.


And


     Any requirements marked ‘[Future]’ should not be relied upon in the
     design of current real SCCS systems. This Recommended Practice will be
     updated periodically. When updates of this document are published, any
     requirements now marked ‘[Future]’ whose conditions are met will be
     reviewed and evaluated for inclusion as full requirements.
I believe that this is all workable.  It better be, it's what we all agreed
to publish.

Regards, Peter
 _______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/cesg

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.