[Smwg] Re: Teleconference notes, 28 April 2014

Tue Oct 7 15:48:22 UTC 2014

From: <Chamoun>, "Chamoun, Jean-Pierre (GSFC-450.3)[SGT INC]" <jean-pierre.chamoun at nasa.gov<mailto:jean-pierre.chamoun at nasa.gov>>
Date: Wednesday, May 14, 2014 6:08 PM
To: "Barkley, Erik J (JPL-3970)[Jet Propulsion Laboratory]" <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>
Cc: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: [Smwg] Re: Teleconference notes, 28 April 2014

Erik,

This is how I understand your notes below:

  1.  a request would reference trajectory ID "T-N".
  2.  the user can send updates to that trajectory by sending "T-N.01" (initial), "T-N.02"(update 1), "T-N.03"(update 2), etc.
  3.  the CSSS provider knows to use the most recent version of T-N for the requested service (should make sure that the version numbers increase with receipt time to avoid confusion)
  4.  older versions of the same trajectory are [or can be] considered obsolete once a new version has been received and validated
  5.  users can submit an alternate trajectory for the same time frame by using a different ID such as "T-C01"
  6.  they can also send updates to the alternate trajectory by sending "T-C01.01" (initial), "T-C01.02"(update 1), "T-C01.03"(update 2), etc.
  7.  users can specify the use of alternate trajectories when submitting a service package request by specifying different scenarios (at least one for each different trajectory alternative).

Did I understand these correctly? If so, I think this addresses the need for alternative trajectories.

Best regards,
--
Jean-Pierre Chamoun
NASA Goddard Space Flight Center
Space Network Ground System Sustainment (SGSS)
Code 458 Building 12 Room N204
Greenbelt, Maryland  20771

Tel: 301-286-5053
email: jean-pierre.chamoun at nasa.gov<mailto:jean-pierre.chamoun at nasa.gov>

From: <Barkley>, "Erik J (3970)" <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>
Date: Tuesday, May 13, 2014 8:21 PM
To: "Chamoun, Jean-Pierre (GSFC-450.3)[SGT INC]" <jean-pierre.chamoun at nasa.gov<mailto:jean-pierre.chamoun at nasa.gov>>
Cc: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: RE: Teleconference notes, 28 April 2014

JP,

The scenarios outlined sound very much like those that were considered during production of Blue-1.

To answer the question: “how does the user differentiate between an update to a version of a specific  trajectory that has been sent previously and an alternate trajectory (for an alternate scenario) that covers the same time frame as a trajectory that was sent previously”, if different trajectory IDs are used (say, “T-N” (or nominal/normal)  and “T-C01 (for ”contingency 1”), then updates to T-N and T-C01 would in themselves be pretty clear, but I think this is where version number could potentially come in (so that we have T-N.01, T-C01.01, etc. as an example).

If we allow for different versions numbers then I think things would be clear as to which was the latest trajectory for which scenario.  If service requests are being used the requests (based on Blue-1 definition) can refer to the different trajectories by identifier and presumably the above could in fact be trajectory Ids, essentially taking version into the identifier format, such that version number are not needed.  However, that implies that more of the service management recommendations are being essentially "co-implemented" which is probably not an assumption that we want to make. And if each version had its own identifier we do have the potential to encourage (although we are not writing a service specification at this time) more of a "cleanup" set of tasks as the number of trajectory files may have more of a tendency to "proliferate". So bottom line, I think it is worthwhile considering adding trajectory version as a piece of metadata. As a side note, I will note that I had communication from John indicating that he had talked lately with the navigation working group chair and the notion of trajectory version was apparently well received. Let's discuss this just a bit more to confirm at the telecon tomorrow.

Best regards,

-Erik

From: Chamoun, Jean-Pierre (GSFC-458.0)[Affiliate] [mailto:jean-pierre.chamoun at nasa.gov]
Sent: Friday, May 02, 2014 12:40 PM
To: Barkley, Erik J (3970); John Pietras
Cc: CCSDS Service Mgmt WG
Subject: Re: Teleconference notes, 28 April 2014

Good afternoon,

My understanding of the discussion is more along the lines of what John describes, which I agree seems like it could be handled by a unique trajectory identifier as long as there isn't already some priority/organization/handling of the trajectory associated with the unique identifier or the order in which the trajectory is received.  In other words, how does the user differentiate between an update to a version of a specific  trajectory that has been sent previously and an alternate trajectory (for an alternate scenario) that covers the same time frame as a trajectory that was sent previously.  For example, in SGSS, each set of trajectory sent to the SN is tagged with a unique ID.  However, the system also tags the latest received trajectory for a given timeframe as the "active" trajectory.  So there is no way to differentiate an updated trajectory from an alternate trajectory.

The benefit of being able to send concurrent trajectories for different scenarios is primarily to expedite the re-planning of a mission's schedule after a "last minute" decision is made to pursue an alternate scenario that results in a different trajectory.    A mission could always just send this new trajectory prediction after they have decided to pursue the alternate scenario, but this would likely be done under a compacted time table (i.e. last minute) and there is little room for errors or connectivity problems etc.  This is why having the ability to send it ahead of time would be useful.  For SGSS, this need arises in the context of launch slips to alternate launch windows.  Other uses could include allowing users a way to provide trajectories based on different maneuver burn times and allowing them to choose the one that they actually will execute at the last minute.  This may be useful in cases where a collision avoidance maneuver is waiting for last minute updates to determine how to best maneuver out of the way, or when a mission is performing a series of maneuvers and they have the flexibility to burn on any number of consecutive orbits.  Contingency situations are also a possibility, but as we have discussed, you can't always predict how the anomaly unfolds so your predicted contingency trajectory may not be any better than the trajectory that is currently active.

I feel like I used the word "trajectory" too many time in this email…

Best regards,
--
Jean-Pierre Chamoun
NASA Goddard Space Flight Center
Space Network Ground System Sustainment (SGSS)
Code 458 Building 12 Room N204
Greenbelt, Maryland  20771

Tel: 301-286-5053
email: jean-pierre.chamoun at nasa.gov<mailto:jean-pierre.chamoun at nasa.gov>

From: <Barkley>, "Erik J (3970)" <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>
Date: Thursday, May 1, 2014 1:58 PM
To: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>, "Chamoun, Jean-Pierre (GSFC-450.3)[SGT INC]" <jean-pierre.chamoun at nasa.gov<mailto:jean-pierre.chamoun at nasa.gov>>
Cc: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: RE: Teleconference notes, 28 April 2014

John,

That is not quite my recollection.  If we are dealing with concurrent times for contingency situations we have the trajectory identifier which can be used to distinguish and associate the particular trajectories with the different contingencies. As I recall the question is really whether or not we would have an updated version of a specific trajectory for a specific trajectory identifier.  Technically I believe this can all be handled via trajectory identifiers, but I think the question of versioning such that an update to a trajectory with the same identifier can be handled may be of use to our agencies. My suggestion is that since the question was raised by JP, let’s ask if he can clarify the question.  With regard to the grade of the trajectory, that is a good comment and I will see what the navigation working group chair (David Berry) has to say about that.

JP,

Any comments about the specific scenario you had in mind with regard to trajectory versioning?

Best regards,

-Erik

From: John Pietras [mailto:john.pietras at gst.com]
Sent: Thursday, May 01, 2014 7:00 AM
To: Barkley, Erik J (3970); CCSDS Service Mgmt WG
Subject: RE: Teleconference notes, 28 April 2014

Erik,
Regarding item 2f in the Notes (about whether or not trajectories need to be “versioned”, my recollection from the discussion is that what this referred to some way of labelling different trajectories for concurrent times to cover contingency situations (e.g., one of the uses of the trajectoryId in SCSS-SM B-1). If this is the correct and common understanding I suggest modifying or augmenting the notes to make that clear (the term “version” can be interpreted lots of ways).

My further recollection was that your action in this regard was to discuss with David Berry whether this trajectory/version identification is of sufficiently general usefulness that it should be included in the ODM and XML Nav formats. Is that the general understanding?

Finally, although we didn’t say this during the meeting, I’d also recommend that while you are talking with David, you also discuss the general usefulness of identifying the grade of the trajectory prediction (e.g., acquisition, scheduling,  sequence of events, long-range planning), with an eye toward having the NavWG include an optional ODM keyword/XML schema type.

Best regards,
John

From:smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org> [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Barkley, Erik J (3970)
Sent: Tuesday, April 29, 2014 9:08 PM
To: CCSDS Service Mgmt WG
Subject: [Smwg] Teleconference notes, 28 April 2014

CSSM Colleagues,

Attached are the notes from the teleconference on 28 April 2014. Corrections appreciated. The notes have also been uploaded to the teleconference folder on CWE.

Our next telecon is scheduled for 14 May 2014.

Best regards,

-Erik

________________________________

Spam<https://filter.gst.com/canit/b.php?i=01LU1bqhU&m=19e9b219cb95&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01LU1bqhU&m=19e9b219cb95&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01LU1bqhU&m=19e9b219cb95&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20141007/7fa3e33d/attachment.html>