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

[Barkley, Erik J (3970)]

Gian Paolo,

Yes, I think this is essentially correct.   Of course, as you noted in your email to me, we understand that we shall not produce a "goof" but rather a "good" TGFT :-) 

Best regards,

-Erik

-----Original Message-----
From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] 
Sent: Friday, June 12, 2015 9:47 AM
To: Barkley, Erik J (3970)
Cc: CCSDS CESG --; Tom Gannett
Subject: Re: [CESG] RE: CESG Telecon issue - return off-line radiometric service / Action CMC-A-2015-05-05

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.