[Smwg] CSS User Registry should not be limited to Spacecraft Idenfier registry

[Barkley, Erik J (3970)]

John,


We will need to have this discussion in a broader context of what is being proposed as the new SANA registry management policy that the SE Area is working on.  That is on the agenda for the telecon tomorrow.  It likely to result in changes in the SANA considerations section which may have a bearing on the concerns you have listed.  Hopefully this will not swamp the entire telecon tomorrow :)

Best regards,

-Eirk

From: smwg-bounces at mailman.ccsds.org [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Monday, June 01, 2015 11:02 AM
To: Colin.Haddow at esa.int
Cc: CCSDS SMWG ML (smwg at mailman.ccsds.org); Wolfgang_._Hell at t-online.de
Subject: [Smwg] CSS User Registry should not be limited to Spacecraft Idenfier registry

Colin,
As currently defined in E2.3 of the Simple Schedule book, the content of the 'user' column CSS User Registry is confined to:

-          UNALLOCATED

-          PROVIDER-CSSS, or

-           "any value contained in the SANA Spacecraft Identifiers Registry (http://sanaregistry.org/r/spacecraftid/spacecraftid.html) column 'Spacecraft Name'".

While Wolfgang and I were discussing the 'spacecraftName' component of the CSTS Service Instance Identifier (see the email that I sent out earlier today) this morning, Wolfgang made a point that upon further consideration raises an issue for the Simple Schedule book. That point is that not all spacecraft that are supported by CCSDS member agencies have CCSDS-assigned SCIDs (he mentioned Russian spacecraft as an example).

Wolfgang's concern focused on tying the CSTS SII to the existing SANA SCID registry, but this also applies to the Simple Schedule, assuming that that we would promote the use of the Simple Schedule to report the schedules for spacecraft that don't have CCSDS SCIDs.

So I think that we're going to have to loosen up the specification of the allowable contents of the 'user' column of the CSS User Registry.

This issue has triggered several more thoughts. As currently constructed, the CSS User Registry must be constantly updated to copy the spacecraft names from the SANA SCID registry. Ignoring for the moment the issue of some desirable SC names not appearing in the SANA SCID registry in the first place, wouldn't it be simpler (that is, easier to maintain) to simply specify in the definition of the Simple Schedule 'user' parameter that it's allowed values are

-          UNALLOCATED

-          PROVIDER-CSSS, or

-           "any value contained in the SANA Spacecraft Identifiers Registry (http://sanaregistry.org/r/spacecraftid/spacecraftid.html) column 'Spacecraft Name'"
without creating a separate registry?

Of course, we do have the possibility of needing to register names that don't appear in the SANA SCID registry, so we do need the some sort of registry for those names. However, by including UNALLOCATED and PROVIDER-CSSS in the CSS User Registry, this registry is constrained to be used *only* for the 'user' parameter of the Simple Schedule. If we have another Info Entity with a parameter populated by spacecraft names but not UNALLOCATED or PROVIDER-CSSS (perhaps Service Agreement, for example), we'd have to create another registry that copies almost all of the contents except the Simple Schedule 'user' parameter-specific UNALLOCATED and PROVIDER-CSSS values. An alternative approach would be to define a CSS Spacecraft Name registry that contains only that (spacecraft names), and defines the allowed values in the Simple schedule 'user' parameter as:

-          UNALLOCATED

-          PROVIDER-CSSS, or

-           "any value contained in the SANA CSS Spacecraft Name Registry"

That is, distinguish the spacecraft Name registry (which will vary over time but could be used for multiple purposes) from the Simple Schedule 'user' parameter-specific values.

My apologies for raising these concerns in the 11th hour, but the need to support spacecraft that don't use CCSDS SCIDs is an issue that does need to be addressed. The rest of the comments are observations on what might be better ways to proceed but aren't critical to the correctness or applicability of the Simple Schedule specification.

Best regards,
John

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