[Smwg] Input for AI 2015-1208-1 (return Trajectory Prediction data)

Barkley, Erik J (3970) erik.j.barkley at jpl.nasa.gov
Fri Jan 29 23:07:27 UTC 2016

CSSM Colleagues,

I have taken a look at both ETP and QTP operations of SM B1 with regard to information returned relative to these operations.  The action, which states "Determine how to define the return Trajectory Prediction format as a result of the TP request (the information entities, XML format, header, etc.)", is a little off the mark from my perspective as the question arose in the context of the of the discussion around the creation of the SMURF at the Darmstadt meetings. Essentially the issue was to double check and follow-up if there was still a need for the trajectory prediction book authored in the CSS area given that we were essentially killing it for the submission of trajectory predictions as it was deemed that the current navigation working group standards are sufficient for that purpose. So it's not really question of how to define the return prediction format but rather whether or not it is needed such that to continue carrying a trajectory prediction book/project or not.

In taking a look at the ETP and QTP operations the key items of note in the return are the trajectory data itself and an indication of whether or not there are any discontinuities for the extension of the trajectory (ETP operation) and the remaining storage size at the service provider for both the ETP and QTP operations. My thinking is that

a)      For  the trajectory prediction data, the same argument as the submission holds - the NAV WG definitions suffice

b)      For the indication of (dis)continuity and storage size remaining, these in and of themselves do not really necessitate a trajectory prediction book per se. It could certainly be done that way but I see these kinds of information as truly being part of management service and so if we truly need these levels of details I believe they can be safely deferred and tucked into the eventual management service book. I also see no harm if we decide that in fact it really does not belong in a management service book but in fact we do have to have some exceedingly thin (probably one or two pages) specification for this return information that there is no urgent need for it to be specified at this time.

In general, this may mean adding to the list of recognized information entities in the service management header, but this is going to be defined as what the soon-to-be-published RMP (Registry Management Policy) defines as a "local" registry and so it should not be any kind of issue to add to the list as needed.

So essentially my conclusion is that there is no need to alter the plan for elimination of the trajectory prediction book and that we can proceed safely on the current course.

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20160129/c2a555fa/attachment.html>

More information about the SMWG mailing list