[Css-csts] FW: possible RID on TD-CSTS?

[John Pietras]

CSTSWG colleagues -

My proposal and Wolfgang's response.

Best regards,
John

From: Wolfgang Hell [mailto:wo_._he at t-online.de]
Sent: Wednesday, June 28, 2017 10:10 AM
To: John Pietras; Margherita.di.Giulio at esa.int
Subject: Re: possible RID on TD-CSTS?

Dear John,

While I understand where you would be going with your candidate RID, I'm afraid that I'm not the right person to ask if that makes sense. The reason I'm stating this is that at the time the TD-CSTS was proposed, ESA flagged that they do not see an operational need for such "real" real-time capability. In case the latency of the delivery of radiometric observables is critical, TDMs extending only over a short time interval, e.g. a few seconds are used by ESA (and sent by means of file transfer, but that is a secondary aspect). The push for the TD-CSTS as it stands now came mostly from JAXA and JPL as well as from some people in CNES. If what you propose covers their needs (which apparently differ from the needs of the Flight Dynamics folks in ESA), I don't think that we would object making that change because at least at first glance the necessary change appears to be minor and one has the additional benefit of the option to use XML formatting in addition to ASCII.

If we really will take that step, coming from the above sketched ESA needs, let me fly another idea by you. Given that we then always transfer complete TDMs, shall we retain the restriction to the atomic segments? Would it then make sense to permit TDMs containing all observables falling into a time period of selectable length? With that in place TD-CSTS could support also what ESA does now based on transfer of very small files. I'm not pushing this idea, it is just a thought in case we change the data unit carried by the TRANSFER-DATA invocation anyway. I'm aware that such change would be more involved than what you are considering for the moment.

Whatever may come out of this, I (and I assume CSTS as a whole) greatly appreciate your willingness to contribute to this using your private time.

Best regards,
Wolfgang

Am 27.06.2017 um 16:19 schrieb John Pietras:
Dear Margherita and Wolfgang,
Well, it looks like the TD-CSTS is finally going to be submitted for Red-1 review. I am contemplating submitting a RID, but I want to fly the idea by the two of you first, to see if you think the idea has merit and any chance of being accepted. I have been thinking about this for several months but did not want to say anything out of concern that it would delay the issuance of Red-1, and I really think that we need to get this book out as a Red Book ASAP.

Let me give you the background for my proposed RID. As you know, the current (almost) Red Book works on a model in which all of the tracking data of interest from a space link session (pass) constitutes a single (virtual?) Tracking Data Message (TDM). This TDM is incrementally built up by the TD-CSTS provider sending a real-time Atomic Segment in each Transfer Data invocation. There are several reasons why I took this approach when I took over the development of the TD-CSTS spec (9 years ago!), principally (a) initially, I thought that a lot of the metadata could be established once at the beginning of the TDM and would not have to be repeatedly re-sent, and (b) there was no alternative standard tracking data service on the planning horizon, and so this approach combined the ability to get incremental real-time tracking data updates with producing a single TDM that represented the whole pass.

Since then, both of these assumptions have lost validity. In exploring further the way TDMs express metadata, it became obvious that most of the metadata would have to be repeated in each Atomic Segment. Years ago I proposed to the NavWG some changes to the TDM format that would allow most if not all of the metadata to be stated once at the beginning of the TDM, but those proposals were not considered. The result is TD-CSTS Atomic Segments that each have almost the full content of a TDM (the only thing missing is the tiny bit of TDM Header info).

Regarding the lack of alternative standard tracking data transfer services, we now of course are talking about using File Transfer to move TDMs that cover full space link sessions. So we no longer have to rely on the TD-CSTS to synthesize TDMs that cover full passes. TD-CSTS can focus on delivering real-time tracking data incrementally.

I also began to think about the ability of TD-CSTS to support the XML version of TDMs. The XML TDM constitutes a single XML document, and by design XML validation cannot cope with little bits and pieces  of XML documents (e.g., the elements representing individual Atomic Segments). So if and when CCSDS ever desires to use TD-CSTS to transfer XML-formatted TDMs, the current model will have to change in any event.

I think that you can see where I am going with this - I would like to propose what I think is a minor change to the specification to have each incremental Transfer Data invocation constitute a TDM in its own right. This approach would smoothly and naturally extend to the XML versions of TDMs. The main effect on the current TD-CSTS would be to remove the small bit of TDM Header information from the START positive return and add it instead to each TRANSFER-DATA invocation.

I would be willing to write up a detailed RID identifying all of the necessary changes, but only if there is a reasonable chance that it would be accepted. If the two of you think that it would be a no-go from the start (e.g., for political reasons) then I won't bother. I realize that once I get into the details of the RID there may be aspects that come out as undesirable, so I am not insisting now that if I write the RID that it be accepted - I realize that it might still be rejected. I just want to know that it will not be dead on arrival.

If the two of you think that this is a good idea and would support it, then I still think that I'd "walk it up the line" a bit to see if it would get support higher up before I commit to spending the time (my own time, since my tasking no longer includes CSTS support). I would fly the idea by Erik and David Berry (of the NavWG). If they would both be supportive, then I would write the RID.

Finally, even if you are not convinced that I should write the RID, others may write RIDs that outright suggest a full-TDM-per-Transfer Data-invocation, or raise issues that would be solved by such an approach. If that's the case, I volunteer draft an update with the necessary changes.

Best regards,
John




________________________________

Spam<https://filter.gst.com/canit/b.php?c=s&i=01TCebqtK&m=12e18761310d>
Not spam<https://filter.gst.com/canit/b.php?c=n&i=01TCebqtK&m=12e18761310d>
Forget previous vote<https://filter.gst.com/canit/b.php?c=f&i=01TCebqtK&m=12e18761310d>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20170713/754b39a7/attachment.html>