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

[Shames, Peter M (312B)]

Folks,

>From the recent CESG meeting I have the action to update the SCID (and MACAO) registry documents.  One intent on my part, aside from creating agency, member, affiliate, point of contact, representative registries that could be re-used as needed, was also to add unique OIDs for all of the objects that get registered, whether organizations, persons, facilities, or spacecraft.

A part of that is to propose that each requrest for a SCID registration would also assign an OID.  The SCIDs must be "relinquished" when the S/C is no longer in operation.  The OID would be permanently assigned.  Furthermore, I am proposing that we can assign an OID without assigning a SCID.  This handles those situations you identifid and also would allow us to register things like CubeSats that do not use CCSDS space link protocols, but still may use CCSDS agency space comm assets.

Does this make sense to you guys?

See attached DRAFT edits to the SCID and MACAO docs that include these features and updates to the (largely existent) SANA registry definitions..

Regards, Peter



From: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Date: Tuesday, June 2, 2015 at 7:11 AM
To: "Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>" <Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>>
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: RE: [Smwg] CSS User Registry should not be limited to Spacecraft Idenfier registry

Marcin,
The problem with using the SANA SCID registry for the spacecraft names for the ‘user’ parameter of the Simple Schedule is not that some missions don’t want (or are too lazy) to register their missions there, it is that the purpose of the SANA SCID registry is to assign CCSDS Spacecraft Identifiers (those relatively small integer values that appear in the CCSDS transfer frame headers). In order to get your spacecraft into the SANA SCID registry, your spacecraft has to use CCSDS space link protocols in the first place. NASA, for one still supports a number of missions that don’t use CCSDS space link protocols (for a variety of reasons).  Those missions couldn’t register their S/C in the SCID registry if they wanted too (the “SCID space” is too small for CCSDS to allocate them to missions that don’t actually use them). But that still doesn’t mean that the networks supporting those missions can’t use CCSDS Service Management interfaces (e.g., the Simple Schedule).

In any case, I don’t think that your proposed solution solves the problem either. Even if some SC names were not registered with SANA, they would have to be “registered” in some way – e.g., in some form of a service agreement (not necessarily one that conforms to the (eventual) CCSDS Service Agreement Info Entity). A SANA registry is just a convenient place to collect all of those names in a common place so that they can be used consistently and authoritatively whenever a CCSDS standard service needs to use a spacecraft name.

However, I agree that creating a separate SC Name registry opens up the possibility of multiple registries with inconsistent contents (some registered in one but not the other, different spellings, etc.). I think a better solution would be to alter the SANA CCSDS SCID registry into a SANA Spacecraft Name and SCID registry that allows for the registration of SC names and *optionally* CCSDS SCIDs. That would create a single authoritative source for all SC names, and if some of those also happen to use/need CCSDS SCIDs those will be there too. Or a relational database approach could be applied to those registries that work of various subsets of related date (in this case, related by spacecraft name).

I haven’t yet read the email that Erik sent out about the new proposals for SANA registries – perhaps some of these issues will be addressed there.

Talk to you soon in the WebEx.

Best regards,
John

From: Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de> [mailto:Marcin.Gnat at dlr.de]
Sent: Tuesday, June 02, 2015 9:38 AM
To: John Pietras
Cc: smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>; Wolfgang_._Hell at t-online.de<mailto:Wolfgang_._Hell at t-online.de>; Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>
Subject: RE: [Smwg] CSS User Registry should not be limited to Spacecraft Idenfier registry

Hi John,

Especially in the latter case you shown, creating another registry does not necessarily help, because it still may happen that someone didn’t registered there (didn’t wanted, or being too lazy ;-)), exactly as at S/C ID Registry the problem is.

My simple proposal would be eventually (if we are going to change anything) to rather go for another special keyword (like “NONREGISTERED” or “OTHER”) which should be followed by in such a case obligatory extension attribute i.e.:

-user=”NONREGISTERED”
–nonreguser=”Cool S/C Name which is not registered in SANA”

In other cases than “NONREGISTERED” this attribute would be optional.

We can than cover Non-SANA Spacecraft and we do not generate extra registries.

Regards
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 John Pietras
Sent: Montag, 1. Juni 2015 20:02
To: Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>
Cc: CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>); 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

________________________________
NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible.
Spam<https://filter.gst.com/canit/b.php?i=01OzpI007&m=0bd598c2cf8d&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01OzpI007&m=0bd598c2cf8d&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01OzpI007&m=0bd598c2cf8d&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150602/1af90c57/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/applefile
Size: 445 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150602/1af90c57/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 320x0b6c1_mods_2-1Jun15.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 122177 bytes
Desc: 320x0b6c1_mods_2-1Jun15.docx
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150602/1af90c57/attachment.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 630x0b1_mods-1Jun15.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 385285 bytes
Desc: 630x0b1_mods-1Jun15.docx
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150602/1af90c57/attachment-0001.docx>