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

[Shames, Peter M (312G)]

Dear SM colleagues,

Aside from my SEA AD role, for the last few years my other "day job" has been participting in (and leading part of) the SCaN Network Integration Project (SNIP, and the trade studies that preceeded it).  We frequently would get dragged into cirumlocutions related to the peculiarities of the SN / TDRS architecture.  These issues are common with other space data relay architectures, so we should seek some common approach that works.  For example, SNIP now uses the term "user mission platform" instead of "spacecraft" because the TDRS down-looking apertures can track things like balloons and surface craft in addition to spacecraft.  They only do this for a small fraction of the time, and they are the only NASA network that does it, but we had to change the term.  The issue of where a ground station (GS) is located (for purposes of figuring out where to connect for SLE & CSTS services) and where the actual aperture is loctaed (for purposes of spacecraft pointing) must be sorted out, but I suggest that you strive to find some simple, broadly applicable, terminology and information structures that can be generally applied and avoid circumlocutions.

For example:

  *   All GS have apertures, by definition.  For any that are located on the Earth (or directly on some other planet) they will have a "fixed" location that varies with planetary rotation, nutation, and crustal shifts.  These can all be modelled.  For all relay spacecraft, TDRS included, the actual aperture that a user spacecraft communicates with also have a "well known" location, but that will vary based on the orbit and attitude of the relay spacecraft.  These can also be modelled.  In all cases the user spacecraft has to know where the service aperture is located, how to track it, and when it will be visible.
  *   We are doing space communication, we can use the term "spacecraft".  If a few odd "spacecraft" happen to be balloons, or ships, or other locations on the surface of the Earth (McMurdo) I suggest that we treat these as exceptions rather than coming up with some unwieldy term that renders obscure the bulk of what we are doing.  Call them spacecraft or use the somewhat unweildy, but relatively accurate, terms defined in the SCCS ADD / ARD.
  *   From the point of view of the service providers data is data.  It may be frames, or files, or network datagrams/bundles, but it is just data in those well specified and standardized forms.  The types of the data (aside from these distinctions), or the meaning of the data, is essentially something we do not care about … that is the user's business.  So the MOIMS and MO guys will really care about the structure, meaning, format, contents, etc, etc, of these data structures, but the CSS, SIS, SLS guys should more or less be agnostic about any of this.  The only exception to this that I can think of are those situations where the service providers are themselves the source of data, such as radiometrics, D-DOR, and antenna pointing, or specialized data types like radar, radio astronomy, or radio science.  These do have their own standardized data types and we do care about the formats because in these cases we are a part of the data source – data sink exchange and not just a data transport agent.

I hope this helps.

Regards, Peter



From: <Chamoun>, Jean-Pierre Chamoun <jean-pierre.chamoun at nasa.gov<mailto:jean-pierre.chamoun at nasa.gov>>
Date: Thursday, August 14, 2014 6:59 AM
To: "Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>" <Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>>, SMWG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Cc: Erik Barkley <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>
Subject: [Smwg] Re: Comments on comment on comments about simple schedule

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<mailto: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/e2ed3ee8/attachment.html>