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

[Shames, Peter M (312B)]

John, et al,

It may come as a surprise, but I am actually glad that you guys recognized this situation and arrived at a very similar conclusion to what I am proposing.   I'm attaching the materials on SANA name and number registry management policies that we just discussed in the CESG this morning.

My recommendation, from a CESG / SEA level, is the following:

  *   Adopt the SANA Spacecraft registry, as suggested below in your note
  *   And, require that every S/C that is tracked by a CCSDS member agency have a unique OID assigned (see pg 9 & 14 in the attached)
  *   And add the OID to the SANA spacecraft registry, along with the S/C name, alias(es), and SCID (if one is assigned)

You guys in CSS started this whole OID thing.  I really believe that you (and the rest of CCSDS) should leverage this to create unique OIDs for all sorts of items, including S/C, antennas, ground stations, agencies, other service providers, and any other objects that must be referenced.  See page 18 in the attached for an first cut at what this might look like.  Note the addition of a registry of "organizations" (including agencies, observers, service providers), and a related set of registry entries for elements owned and operated by these organizations.

Let's use and extend what we already have instead of creating new registries willy-nilly.

The CESG has agreed at a first level that this makes sense, especially the whole agency / organization / PoC part.  I am on the hook to write up the changes to the SANA, SCID, and MACAO docs.  I'd be happy to work with you guys to make sure that this makes sense to you.  I'll also be meeting next week with both the SANA Operator and the CCSDS Secretariat to see if can't get to one and only one authoritative set of each of these registries instead of 10 (or 4) of them.

Thanks, Peter



From: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Date: Monday, June 1, 2015 at 11:01 AM
To: "Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>" <Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>>
Cc: SMWG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>, Wolfgang Hell <Wolfgang_._Hell at t-online.de<mailto: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/d31bda49/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CCSDS SSG Name & Number Registries v11.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 356215 bytes
Desc: CCSDS SSG Name & Number Registries v11.pptx
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150601/d31bda49/attachment.pptx>