[Smwg] Draft Presentation for the Trajectory Prediction Data Format Recommended Standard

[Barkley, Erik J (3970)]

Jessica,

Thanks for putting the first draft/cut together of the presentation. A couple of comments that may help to answer some of your questions:


1)      The business about existing trajectory reference and new trajectory reference have to do with the apply-new-trajectory operation in the current 1 specification. And in fact those were operations related to the application of a new trajectory to a service package  -- i.e., they are service package related items and really not trajectory related items. For the purpose of developing an extensible specification with regard to handling input of trajectory predictions I think then that this kind of stuff can be safely omitted from a the future trajectory prediction book. It seems like it will have to be dealt with by the service package request book.  (But let's see what the WG has to say.)



2)      It strikes me that there probably are two main aspects for extensibility with regard to trajectory predictions. The first one, which I think is the easiest to deal with, is with regard to allowing different formats to be specified. So in that regard the bilateral format definition probably stays in here and is part of a general extension point with regard to expressing data formats. The other extensibility point is more about the implied usage of the trajectory data. I think there are two sub-cases here:



a.       The extended trajectory prediction operation in the current blue-1. This may indeed need more of an examination/cross-check as perhaps it goes away since we are not doing a trajectory prediction handling service. Then again we may need something in here to at least indicate the relationship of the information even though we don't really state how you do the extension (good discussion for the working group I think).

b.      The other sub-case is where bits and pieces of trajectories are "layered" to achieve an effective/net trajectory prediction. The classic example here is a mission or a flight dynamics operation that will tell you what the spacecraft trajectory is relative to a satellite/moon of a planet and another trajectory segment will tell you the orbit of the moon to the planet and another trajectory segment will tell you the orbit of the planet with regard to the solar system barycenter such that you can finally figure out where it is you really point your antenna, etc.   I think this is likely to be good extension point from a data format perspective.


Best regards,

-Erik

From: smwg-bounces at mailman.ccsds.org [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Reinert, Jessica Mae (GRC-LSA0)
Sent: Tuesday, August 05, 2014 8:38 PM
To: CCSDS Service Mgmt WG
Subject: [Smwg] Draft Presentation for the Trajectory Prediction Data Format Recommended Standard

Greetings,

It's a bit tardy, but here's my first cut at the draft materials for the Trajectory Prediction Data Format Recommended Standard. I ended up having quite a few questions, and made notes of a lot of them right on the UML diagram that was generated. I also included a few on a separate slide. I look forward to getting your feedback on the attached materials.

Regards,

Jessica

Jessica Reinert
Systems Definition and Communications Branch
NASA Glenn Research Center
Phone: 216-433-6249

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