[Smwg] RE: Comments on comment on comments about simple schedule
Marcin.Gnat at dlr.de
Marcin.Gnat at dlr.de
Thu Aug 14 06:14:19 UTC 2014
Hi JP and Erik,
Just few of "my stones in the garden" (see below again in red).
From: 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
Thanks very much for the comments on the simple schedule and test report. Please see my comments just on that subject embedded below.
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.
* 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?".
* 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.
* 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SMWG