[Smwg] Re: Comments on comment on comments about simple schedule

Thu Aug 14 13:59:13 UTC 2014

Erik and Marcin,

Thanks for your comments to my comments.  I added some additional thoughts in green.

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

From: "Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>" <Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>>
Date: Thursday, August 14, 2014 2:14 AM
To: "Chamoun, Jean-Pierre (GSFC-450.3)[SGT INC]" <jean-pierre.chamoun at nasa.gov<mailto:jean-pierre.chamoun at nasa.gov>>, "smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>" <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Cc: "Barkley, Erik J (JPL-3970)[Jet Propulsion Laboratory]" <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>
Subject: RE: Comments on comment on comments about simple schedule

Hi JP and Erik,

Just few of “my stones in the garden” (see below again in red).

Marcin

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: Donnerstag, 14. August 2014 00:04
To: Chamoun, Jean-Pierre (GSFC-458.0)[SGT INC]; CCSDS Service Mgmt WG
Subject: [Smwg] Comment on comments about simple schedule

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.
In general (having another implementation for SN – like it would be for ESA or whatever other use) I agree 110% with Erik. In a case however, you’d  ask for SN schedule example to show the complexity of User Management – Provider Management – Provider G/S - Provider Relay S/C – User Relay S/C -> we decided as I remember, we do not get into that with Simple Schedule. SN is just treated as “ground stations which by accident are just orbiting the Earth”, and so in schedule operational sense they are set equal with normal ground station.
[JPC]: I'll see if if I can get a hold of an SN schedule and see what is missing (John Pietras may have already done this in the past?).  Knowing what is missing for the SN and DSN would give us insight as to whether the extensibility of this format allows the incorporation of these SN and DSN items .   As for treating the TDRS as a ground station that makes sense since they are equivalent.  However, I noted in my comments to the planning aids document that we should start to define a more generic term for the antenna that communicates with the user platform.  Ground station is applicable to ground networks but in service catalog 2 ( and for the SN) space based relays would require a different term.

  *   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.
Also I remember we said, the schedule file is being used in many cases to trigger specific mission planning activities, and as such a status “tentative” or “maybe” is not really useful, and actually needs to be treated as either “rejected” or at least “no answer yet at all”. The problem is here, missions (especially Earth Observation but not only) need clear statement (Boolean ;-)) – ether they got the requested pass, or not. On the other hand, for high level of station utilization, station providers would like to “overbook” their capacities, and thus provide the status “yeah, principally you can have this pass, so please do not go away, but in case our better customer comes and wants this, we will kick you out, okay?”.
[JPC]: Marcin, I am not sure I understand your explanation correctly.  This is what I think you are saying: tentative SP are not to be included in the simple schedule. Is this correct?   Erik, if I understood you correctly you that think that if there is a tentative SP included in the simple schedule, then the schedule as whole would be marked "Provisional".   Please let me know If I misunderstood either of you but it may be that we need some clarification to the book?

  *   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.
I would ask here, how the science data differs from telemetry or offline telemetry? For me (and I think also for providers of ground station services, which is our focus here) the question what data is in the telemetry (is it science or housekeeping) is irrelevant. I provide a service of delivering “some” data from spacecraft over ground station to the user. What’s inside – I do not care. But in general terms (in case one finds really some service – like science – which differs significantly for the provider) I agree again with Erik.
[JPC]:  No real strong opinion here.  The way Service Type are define today is fine with me. What caught my eye is that we differentiate between telemetry and offline telemetry (they are both just returns).  So I thought if we are categorize returns we might as well add Science as a type of return service (since it is the one that pays the bills…. Ok, not really).

  *   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!
Again here we’ve had that, and we said it’s “simple” schedule, and the notion of use of such schedule is slightly different than rest of SM stuff.  Also for the sake of acceptance, it’s better to keep it simple and somehow “disconnected” from the Big Bad Wolf (Service Management) so that agencies which do not have already existing complicated systems like maybe SN and DSN could easily adopt to this format (like DLR).
[JPC]:  Maybe when we refine the format for the list of SPs, we can see we can define it to have some minimal representation that fits into the simple schedule (?).

<cut>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20140814/942e9b84/attachment.html>