[Smwg] Draft Presentation for the Trajectory Prediction Data Format Recommended Standard
John Pietras
john.pietras at gst.com
Fri Aug 8 16:29:08 UTC 2014
It just occurred to me that some of our newer WG members may have never read the Concept Green Book for version 1 SCCS-SM, Space Communication Cross Support-Service Management-Operations Concept (http://public.ccsds.org/publications/archive/910x14g1.pdf). Section 3.7 of that Green Book lays out the various use cases and scenarios for trajectory predictions, and provides the background for the presence and use of the various parameters of the Trajectory Prediction operation. I think that this is very useful reading to understand how the Blue-1 TP operations (which are our starting point for the current work in this area) came into being. (I'm a bit embarrassed that I had not thought to mention this book sooner.)
Best regards,
John
From: smwg-bounces at mailman.ccsds.org [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Barkley, Erik J (3970)
Sent: Thursday, August 07, 2014 8:07 PM
To: Reinert, Jessica M (312G-NASA)
Cc: CCSDS Service Mgmt WG
Subject: RE: [Smwg] Draft Presentation for the Trajectory Prediction Data Format Recommended Standard
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> [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
________________________________
Spam<https://filter.gst.com/canit/b.php?i=01MA0fR0P&m=654b918650ee&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01MA0fR0P&m=654b918650ee&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01MA0fR0P&m=654b918650ee&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20140808/effbd129/attachment.html>
More information about the SMWG
mailing list