[Smwg] Comment on comments about simple schedule

Wed Aug 13 22:04:05 UTC 2014

JP,

Thanks very much for the comments on the simple schedule and test report. Please see my comments just on that subject embedded below.

Best regards,

-Erik

From: Chamoun, Jean-Pierre (GSFC-458.0)[SGT INC] [mailto:jean-pierre.chamoun at nasa.gov]
Sent: Wednesday, August 13, 2014 7:44 AM
To: Barkley, Erik J (3970); CCSDS Service Mgmt WG
Subject: Re: [Smwg] Telecon reminder, proposed agenda

My comments for the agenda items:

Simple schedule & test report:

  *   The test and test report seem adequate to prove the usability of the proposed format.  My only comment is that using the SN as an example of a simple schedule of services (not just an example of unused time) would be useful.
I think this tends to come down to a matter of resources. Technically, CCSDS requires that to implementations be provided that demonstrate interoperability. Presumably we have met that criteria even though it did not involve the SN as to a significant extent. I do agree that it would be better to use an SN example that isn't just simply about the unused time.  I can also say the same thing about the DSN. However we are somewhat fortunate in that I have fairly ready access to the folks that work on the DSN scheduling system and they have already in effect done a third prototype such that it looks quite feasible for the DSN to users as a publication format. Perhaps there may be sufficient resources to put together a trial example for the SN?  As an FYI, I think that the DSN "prototype" was essentially to take our current XML format and do a stylesheet transformation into the CCSDS format and note where things were missing, etc. I don't know if it's feasible to do something like this in the SN but I thought I would just mention the local approach.

  *   The simple schedule does not include service package status (does it?) but it would seem necessary at least for tentative SP.  Or state that only confirmed SP are included but this might be limiting.
The intention is that the schedule will indicate "provisional" in the status if everything listed on the schedule is not fully committed to be in service production. That does not mean that there cannot be subsequent changes to an official non-provisional schedule but there is clear metadata to indicate that we know up front that the schedule has  a "trial" or "best guess" set of commitments.  So if this is not explicit, then I think we need to make it explicit in the book. As a matter of approaching this in CCSDS, my suggestion is that this can be filed as a RID as part of agency review if necessary.

  *   Service type seems very specific.  What about science data service that are not not offline telemetry? Should Service type be more generic like , return, forward, etc?  Or we can just add science to the enum list.
This may be a good question to bring up as part of agency review. My sense is that we as CCSDS are essentially codifying services that are well-known with regard to CCSDS and in particular I'm referring to the set of services defined in the IOAG service catalog 1. Certainly the DSN does all kinds of "interesting" things utilizing the DSN as the front line instrument, i.e. not just as a communications system (e.g., radio astronomy, solar system radar, etc.). My first take is that we could probably consider adding something as a bilaterally agreed definition for other services that are not in the "standard" list. And it may be that extension to enumeration lists may be something we want to classify as an overall part of our extensibility model.

  *   Did we consider making simple schedule just and abstraction or high level structure of the Service Package set?  This way a mission can select how much or how little of a service package to include in the schedule.  This would allow for a single implementation by the provider/user for a schedule of services that can be more or less complex as needed.
I do recall that we touched upon this notion during the development of the draft recommendation to date. I will add that it's a bit difficult to state unused time as an abstraction of a service package set, although I suppose we could do the very quintessential computer science/somewhat mathematical thing and call this the "null service package set" :-)  but I think we then rapidly lose our managerial if not implementation audience!
Trajectory Prediction:

  *   From Erik, Existing trajectory and new trajectory are associated with apply new trajectory of the service package -> could be omitted
  *   From Erik, trajectory prediction should include Extensible formats
  *   From Erik, trajectory prediction should include Extensible usage

     *   From Erik - Is the this trajectory an extension, or new, or?  May not be needed but could be.

        *   JPC - This may be handled by the versioning discussion we had.

     *   From Erik - Multiple relative trajectories used to specify the service trajectories (how)

  *   JPC - Should trajectories including discontinuities (e.g. Maneuvers) be identified at the higher level of the structure or in the data. Does it matter if trajectories with maneuvers are  provided as extension or separate trajectories?  Because maneuvers may not always take place, should we guide users to submit them as separate trajectories so that they can be more easily retracted by using the replace trajectory?

Planning

  *   The Event Auxiliary Data in Fig.4-1 has a list of very specific parameters but is not comprehensive(?)
  *   Table 4-2: Should relative event times be supported?  (e.g to orbit start or other events?)
  *   Table 4-3: recommend creating a column for optional/mandatory (in addition to or instead of  including it in the description)
  *   Table 4-3: Does event angle and event distance need reference points identified in a separate parameter?  Seems ambiguous.
  *   Table 4-3: I don't think event duration should be combined with OWLT, since they are not necessarily related.
  *   Is celestial body related to the orbit #?  I.e., is this orbit around this celestial body?  May be confusing.  Consider renaming?
  *   May want to consider adding an optional "relative to" attribute to every parameter object? (e.g. Table 4-4)
  *   Table 4-5.  We may want to think about generic name for the antenna site providing the service to the user.  Ground station is specific to ground based networks but not for space based relays.  How about "network [service] antenna"?
  *   Table 4-5:  AOS/LOS may need to be clarified to be the start/end of service, not just the expected Acquisition times.  Similarly, Coms Start/End could be clarified as start and stop of line of sight [?] or usable line of sight[?] to the ground station.
  *   Table 4-5: what about adding a parameter to identify if it is a full occultation or tentative or partial/intermittent?  This way these parameters could be used for any events that other completely inhibit a signal or partially (not just line of sight blockage)?  We could also just create a separate set of par maters since occultation is widely popular already for a very specific event.

--
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, August 12, 2014 6:51 PM
To: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: [Smwg] Telecon reminder, proposed agenda

CSSM Colleagues,

A reminder that our next teleconference/Webex is scheduled for Wednesday, August 13th.    The proposed agenda is:

1.       Action Items review
2.       WG inputs re schedule of services test report
3.       Updates/progress reports on CESG poll condition removals
a.       Inputs, if any on service component terminology
4.       Review/discuss of trajectory prediction extensibility model
5.       Review/discuss inter-recommendations concerns/approach
6.       Further discussion on service package request components (left over from last telecom)
7.       Update on planning information draft, if any
8.       Update on GFT concept, if any
9.       Planning for London Meetings
10.   Other Items you would like to address

Best regards,

-Erik

-----Original Appointment-----
From: Colin Haddow/esoc/ESA [mailto:Colin.Haddow at esa.int]
Sent: Wednesday, April 02, 2014 7:56 AM
To: Colin Haddow/esoc/ESA; smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>
Subject: [Smwg] Rescheduled: CSSM WebEx (13 Aug 16:30 CEDT)
When: Wednesday, August 13, 2014 4:30 PM-6:30 PM W. Europe.
Where:

Colin Haddow invites you to an online meeting using WebEx.

Meeting Number: 164 616 205
Meeting Password: CCSDS123

-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://esa-meeting.webex.com/esa-meeting/j.php?J=164616205&PW=NMmUzODQ2NDRm
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: CCSDS123
4. Click "Join".
5. Follow the instructions that appear on your screen.

-------------------------------------------------------
Audio conference information
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code.
Call-in toll-free number (UK): 0800-051-3810
Call-in toll number (UK): +44-203-478-5289
Global call-in numbers: https://esa-meeting.webex.com/esa-meeting/globalcallin.php?serviceType=MC&ED=7725123&tollFree=1
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

Access code:164 616 205

http://www.webex.com

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.
<< File: ATT00001.htm >>  << File: ATT00002.htm >>  << File: c151005.ics >>  << File: ATT00003.txt >>

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