[Smwg] SPDF: second WG review - now referencing the correct version

Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] wesley.m.eddy at nasa.gov
Tue Apr 16 13:25:17 UTC 2019

Hi John et al, in going through my open issues, one that I noticed that I haven't followed up on is your observation below.  Have you (or anyone else) had further thoughts on this, and whether it's a feature or a bug?

From: John Pietras <john.pietras at gst.com>
Sent: Tuesday, January 8, 2019 5:39 PM
To: Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] <wesley.m.eddy at nasa.gov>
Cc: CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>
Subject: RE: SPDF: second WG review - now referencing the correct version


The values of the ServiceTypes attribute of the Space Link Service Profile are taken from the ServiceType parameter of the Simple Schedule Format. Thus we have a consistent set of "service" names across the CSSM books.

Note that the serviceTypes attribute of the Space Link Service Profile is plural, not singular. This was necessary because some Space Link Service Profiles may provide multiple service types. In particular, the Online Real-Time Tracking Space Link Service Profile can provide the APA-AZ/EL, APA-X/Y, DOPPLER, and RANGING services simultaneously. All of these services are potentially delivered to the user through one instance of the CSTS Tracking Data service. Consider a Service Package that collects APA-AZ/EL and RANGING data and delivers it through a single instance of TD-CSTS. As currently written, the singular serviceType parameter value of the SPDF would require that the SPDF have two OnlineServiceDetails components: one for the APA service and one for the RANGING service. That's okay as far as the Configuration Profile and Space Link Service Profile are concerned, but the fact that the SPDF allows each of these services to have different timing information raises interesting questions. E.g., it implies that antenna angle data and ranging data can be scheduled for different sub-periods of the overall service package. Off the top of my head this seems like a useful capability but I wonder if it might have some hidden issues.

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

More information about the SMWG mailing list