[Smwg] RE: CCSDS - Creation of new registries.
Barkley, Erik J (3970)
erik.j.barkley at jpl.nasa.gov
Wed Jun 17 17:18:27 UTC 2015
Peter,
Thanks very much for sending along the asset database information. Interesting to note that the name or ID if the antenna is not unique. And in fact at least for the case of the NASA DSN antennas that I'm able to see in here none of the familiar DSS identifiers are called out at least in what shows up in the PDF (it appears that they are just identified as "DSN"). This will not be of use to the schedule services book. Obviously having an object identifier attached to each record would be useful from an overall information modeling point of view as we could probably get down to a globally unique record identifier for each information entity registered in the entire set of CCSDS registries. However, as has been noted in other conversation threads, related to this presenting operational folks with a string of digits that extends across the screen for a meters worth of printed characters is not going to be terribly conducive to operations. What is your take upon the schedule of services now putting further restrictions on existing information and registries? The use case here is for a schedule item to identify, for example, that Mars Express (local identifier "MEX" - we may also need to consider tweeking the GSCID registry) will be tracking on DSS35 and not just "DSN". I do think that these kind of concerns (essentially intersection of use case vs information modeling) are going to be the tricky bits of business with more of a global registry approach. An obvious solution for the SoS book is to define a new parameter to this registry and its entry form which would be something like "Schedulable Identifier". But I'm not sure that is the best approach - yes it would tie the OID, but now you have two identifiers -- although the current identifier scheme really does not appear to be a strict identifier as such and perhaps this parameter/attribute should be renamed - it seems rather free-wheeling in its semantics at the moment. Thoughts?
-Erik
From: Shames, Peter M (312B)
Sent: Wednesday, June 17, 2015 8:52 AM
To: Barkley, Erik J (3970); colin.haddow at esa.int
Cc: Space Assigned Numbers Authority; CCSDS Service Mgmt WG; Brian Oliver; Kelvin Nichols
Subject: FW: CCSDS - Creation of new registries.
Importance: High
Hi Erik,
I'm glad to hear that your assessment aligns with mine. All of those fields are in what I proposed back in March, and they were drawn from the original SCID and MACAO books, plus the new OID entries. I agree that we do need to work the overall OID structure, and I did take a cut at that back in March as well. I'll fiddle with it a little more today and send it along.
Meanwhile, back on May 14, I sent you the info that I had access to re the RF assets registry that has been created. I am attaching it again here for your benefit and of the rest of the team. The first file is just the first few columns of the registry. The second file is a list of all the fields in the registry. They do not explicitly identify the ground station site (GSS), but they do provide the Lat / Lon and country.
I would suggest that we ask them to add any fields we need or, alternatively, that we create our own GSS registry and point the antenna entries at theirs. After looking at the fields that are provided you may find that there are others you need. If so I'd propose adding them rather than creating another separate registry.
Regards, Peter
From: <Barkley>, Erik Barkley <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>
Date: Tuesday, June 16, 2015 at 5:35 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, "colin.haddow at esa.int<mailto:colin.haddow at esa.int>" <colin.haddow at esa.int<mailto:colin.haddow at esa.int>>
Cc: Space Assigned Numbers Authority <info at sanaregistry.org<mailto:info at sanaregistry.org>>, SMWG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>, Brian Oliver <briano at aiaa.org<mailto:briano at aiaa.org>>, Kelvin Nichols <kelvin.nichols at nasa.gov<mailto:kelvin.nichols at nasa.gov>>
Subject: RE: CSSM SoS book and in-progress new CCSDS registration policy -- analysis and comment
2) RF Assets - SoS is currently assuming a hierarchical relationship such that a groundstation can have one or more antennas. As far as I know I do not have permission to look into this RF Assets registry but I tend to doubt that it has the organization assumed by the SoS. It's probably quite possible to revisit the SoS definition but if it's possible to take a look into how the RF communications asset registry is organized that would be appreciated.
From: <Shames>, Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Date: Thursday, May 14, 2015 at 9:12 AM
To: "colin.haddow at esa.int<mailto:colin.haddow at esa.int>" <colin.haddow at esa.int<mailto:colin.haddow at esa.int>>, Erik Barkley <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>
Cc: Space Assigned Numbers Authority <info at sanaregistry.org<mailto:info at sanaregistry.org>>
Subject: Re: CCSDS - Creation of new registries.
Colin, et al,
I just got access to the existing SANA RF Comm Asset database. I have attached a listing of the first part of the entries and also a listing of the column headers (fields) that are included. See if this meets your needs for an available information set to use as part of the CSSM work.
Regards, Peter
From: <Shames>, Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Date: Wednesday, May 13, 2015 at 12:05 PM
To: "colin.haddow at esa.int<mailto:colin.haddow at esa.int>" <colin.haddow at esa.int<mailto:colin.haddow at esa.int>>, Erik Barkley <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>
Cc: Space Assigned Numbers Authority <info at sanaregistry.org<mailto:info at sanaregistry.org>>
Subject: Re: CCSDS - Creation of new registries.
Colin, et al,
I understand the sense of urgency to create this new Simple Schedule document and the associated registries. That said, I am really concerned that we create yet more registries of type "orginating organization" and "user" and "station and antenna" when perfectly servicable registries of exactly these types already exist. Furthermore, the existing registries already provide name, address, PoC, phone, email, etc, etc fields instead of what are really rather vague "a string of text between 1 and 1024 characters in length" types of specifications.
Instead of just continuing down this path, and thereby perpetuating and worsening an already poor situation, I have an alternative proposal. The SANA is designed to allow registries to be modified by newly published Blue or Magenta Books.
I believe that it is in your power to make your standard state something like the following:
1) Change Sec E2.2 of the Simple Schedule (henceforth SS) to state the following:
* The SCCS SM originating Organization shall be one of the organizations registered in the CCSDS Organizations registry (http://sanaregistry.org/r/organizations/organizations.html
* If an Organization does not exist in the Organization registry the identified Agency Head of Delegation or Organization official Point of Contact may request of the SANA that it be added, using the existing SANA procedures for that registry
* The CCSDS Organizations registry shall be modified to add a boolean attribute indicating that the Organization may be of type "serviceProvider"
* For all Organizations that indicate that they offer services this attribute shall be set "TRUE", otehrwise it shall be set "FALSE"
* Addition of any new organization shall require sponsorship by the CCSDS Member Agency for it's country of origin or by the Secretariat if there is no CCSDS Member agency for it's country of origin.
* The Agency Head of Delegation or Organization official Point of Contact shall be added to the CCSDS Contacts registry (http://sanaregistry.org/r/contacts/contacts.html)
* The Agency Head of Delegation or Organization official Point of Contact may appoint an Agency Representative (AR) as the point of contact for SCCS SM requests.
* The SCCS SM AR shall be added to the CCSDS Contacts registry (http://sanaregistry.org/r/contacts/contacts.html)
* The CCSDS Contacts registry shall be modified to add a boolean attribute indicating that the person may be of type "serviceProviderContact"
* For all Contacts that are identified as a serviceProviderContact this attribute shall be set "TRUE", otherwise it shall be set "FALSE"
2) Change Sec E2.3 of the SS to state the following:
* The SCCS SM "user" shall be the Spacecraft Name of one of the spacecraft registered in the CCSDS SCID registry (http://sanaregistry.org/r/spacecraftid/spacecraftid.html<http://sanaregistry.org/r/organizations/organizations.html>, or the field "UNALLOCATED" or the field "PROVIDER-CSSS".
* If the user spacecraft does not exist in the Spacecraft registry the identified SCID Agency Representative shall request of the SANA that one be assigned, following the SCID request procedures
* If there is not a current SCID Agency Representative, or if the user agency is not yet registered, the SCID registration procedures must be followed to create these entries
3) Change Sec E2.4 of the SS to state the following:
* The SCCS SM "stationAndAntennaRef" shall use the Station Name and the Antenna Name of one of the communication assets registered in the CCSDS RF Communication Assets registry http://sanaregistry.org/cgi/registry-auth?id=rf_assets.
* If the Station Name or Antenna Name does not exist in the RF Communication Assets registry the identified Assets Agency Representative shall request of the SANA that one be assigned, following the Agency Assets request procedures
* If there is not a current Assets Agency Representative, or if the user agency is not yet registered, the Agency (SCID) registration procedures must be followed to create these entries
NOTE: At the present time the RF Communication Assets registry is under development and it is locked for access. This registry should be completed and at least the fields for station and antenna names (and probably sizes and frequency coverage) made available to any registered user. The full registry should be open to any registered service provider organization (see Sec E3.2).
As best I can tell all of the fields that you need, save those two attribute fields, are already in the identified registries. All of the procedures for registering agencies, agency (or org) HoD or PoC, and for registering Agency Representatives are already in place as part of the SCID registries. All that is needed for E2.2 and E2.3 is to add the identified attribute fields that they need.
For E2.4 there is already a registry that exists , but is under construction. We will have to negotiate with the IOAG to gain access, but it is hosted on the CCSDS provided SANA site, and they support the CCSDS service and SM standards, so standing in the way of this, modulo dealing with any security concerns, seems really counter productive.
Are you willing to move in this direction? It will help you (I think) and will also get this ball moving in the right direction.
And I think that the SANA Operator guys will be more than willing to help out.
Best regards, Peter
On 5/13/15, 10:24 AM, "Space Assigned Numbers Authority" <info at sanaregistry.org<mailto:info at sanaregistry.org>> wrote:
Dear Dr. Haddow,
We would like to know when will the book be submitted for publication.
Thank you.
--
Best regards,
Audric Schiltknecht
Space Assigned Numbers Authority
Le 2015-05-08 à 05:23, colin.haddow at esa.int<mailto:colin.haddow at esa.int>
<mailto:colin.haddow at esa.int> a écrit :
Hi Marc,
I'm currently working on the CCSDS Simple Schedule Format
Book (CCSDS 902.1) and in the context of this book we would like the
following registries set up in SANA;
CSS Originating Organization
The registry named 'CSS Originating Organization' consists of a
list of
organizations along with a description:
|--------------------------+-----------------------------------------------|
| |
|
| |
|
| originatingOrganization | a string of between 1 and 1024
characters in |
| : | length.
|
|--------------------------+-----------------------------------------------|
| |
|
| |
|
| Description: | a string of text of between 1
and 1024 |
| | characters in length
describing the |
| | originatingOrganization.
|
|--------------------------+-----------------------------------------------|
CSS User
The registry named 'CSS User' consists of a list of users along
with a
description:
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| user: | a string of between 1 and 1024
characters in |
| | length.
|
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| description: | a string of text of between 1
and 1024 |
| | characters in length describing the
user. |
|-------------------------+-----------------------------------------------|
The initial registry should be filled with the following values:
|
|
user | Description
-------------------------+-----------------------------------------------
|
|
UNALLOCATED | Indicates that the time is
unallocated.
-------------------------+-----------------------------------------------
|
|
PROVIDER-CSSS | Indicates that the time is allocated
for the
| Provider CSSS.
CSS Station and Antenna Reference
The registry named 'CSS Station and Antenna Reference' consists of a
list of
station references with associated antenna references along
with a
description:
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| stationRef: | a string of between 1 and 1024
characters in |
| | length.
|
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| antennaRef: | a string of between 1 and 1024
characters in |
| | length.
|
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| description: | a string of text of between 1
and 1024 |
| | characters in length
describing the |
| | stationRef and antennaRef.
|
|-------------------------+-----------------------------------------------|
In addition we'd also like the following registry created in SANA to hold
related XML schema files;
SCCS-SM Information Entity XML Schemas
The registry named 'SCCS-SM Information Entity XML Schemas'
consists of a
list of XML schema files with references to the CCSDS books where
these are
defined and a description of the schema.
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| file | The schema file [Type: FILE]
|
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| reference: | A string*16 containing the
reference number |
| | of the appropriate book where the
schema is |
| | defined.
|
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| description: | a string of text of between 1
and 1024 |
| | characters in length describing the
schema |
|-------------------------+-----------------------------------------------|
If you require any more information in setting up these registries
please do
not hesitate to contact me.
Thanks in advance.
Cheers for now,
Colin
---------------------------------------------------------------------------------------------------------
Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.
Phone; +49 6151 90 2896
Fax; +49 6151 90 3010
E-Mail; colin.haddow at esa.int<mailto:colin.haddow at esa.int> <mailto:colin.haddow at esa.int>
---------------------------------------------------------------------------------------------------------
This message and any attachments are intended for the use of the
addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in
whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and
delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the
sender.
Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150617/04a46381/attachment.html>
More information about the SMWG
mailing list