[cssm] [EXTERNAL] FW: D-DOR FRM definition
Shames, Peter M (US 312B)
peter.m.shames at jpl.nasa.gov
Mon May 17 23:55:36 UTC 2021
Dear All,
This may strike you all as strange, but I am pleased to see that you are digging into all of these related topics with an aim to bring clarity. What we tried to do in creating the set of SANA registries, specifically the Service Site & Aperture (SS&A) and related, was to create a framework that you all (CSS area and others who are affected) could refine to meet your collective needs for capturing the necessary data and identifiers. We created unique identifiers (OIDs) for all objects nd created fields for various names and abbreviations that we believed would be useful and aligned, as best we could tell, with the intentions of the several different Working Groups in SLS, SIS, CSS, and SEA areas.
We populated these registries with the information that we had in hand (Spacecraft SCIDs, IOAG RF assets, Orgs, Contacts, and such CSS OIDs as existed). We asked the Agencies to update their information in these registries, typically with little actual response.
And then we waited for you guys to figure out what you really wanted these registries to contain.
Because we (CCSDS as a whole) had originally taken the “let a thousand flowers bloom” approach to creating registries there was not a culture of consistent use of registries, names, terms, across all WG. In reality, there was not a consistent use of these elements even within any given area, witness the plethora of identical terms in the SANA Terminology registry, in some cases, and the absence of other terms. Go to the Terms registry (https://sanaregistry.org/r/terms/) and search for “packet” or “frame”, or “aperture”, or “antenna”. One point I am making is that we (collectively) need to clean up our act. The SANA framework is there to support this, but we collectively need to do the work.
That includes, IMHO, getting this business of definitions (aperture, antenna, station) sorted out and getting clear about what we want as some sort of “canonical names” as well as, if it is necessary, real abbreviated names.
I’ll make the following assertions, which I believe are factual (i.e. observable). Some will be judgements, i.e. things that I believe to be true which may not be. It is all up for discussion.
1. The necessary SANA registries, Terms, Agencies, Contacts, SS&A, SCID, etc all exist (fact)
2. The fields in these registries are (mostly) well enough defined (judgement)
3. The Terms we need mostly exist (fact)
4. The Terms need to be cleaned up and normalized for clarity (judgment)
5. Some Terms that we need are not yet defined in the SANA Terms registry (fact)
6. Terms registry maintenance is out of date with the current publications (judgement, but likely provable as fact by examination of the Terms and current publications)
7. The SS&A registry is also out of date (observable fact)
8. The SS&A registry contains “abbreviations” that are not always abbreviated (fact)
9. We do not have a rule for SS&A abbreviations, nor for canonical names, nor for “DDOR 4-character ‘STATION’ names” (fact)
10. We do not have definitions for aperture, antenna, and station that describe how they are related nor how they related to aperture arrays (fact)
11. We have a framework for authentication of users and authorization of user access, given different roles, but it is not (quite) finished, more on that in a minute.
12. I could go on, but I hope you get the idea
We have a framework, and more than a framework in place, but there is a lot of data update work to be done. A lot of that must be done by the WG that care about it. At this point, given accurate inputs, the SANA Operator will do the updates. In some cases, like the FRM, there is a lot of work for you guys to do to figure out just what it is that you want to CM and how you want to do it. It’s not an easy problem given that you are essentially tracking three areas worth of standards.
On the topic of the authorization framework, there has been progress. I spoke to Marc about this the end of last week. They have implemented it and are testing it. They elected, wisely I think, to implement a generic role / authorization approach that can easily be extended and reused. This sounds easy, but it is not, largely because of some of the ways that we, CCSDS, have decided to use it.
Why is this complicated, you might ask? I did. Here is the answer:
1. We have roles, Agency Representative (AR) for SCID assignment, AR for SS&A updates for some network owned by some agency.
2. Then we have a SCID assignment AR “Charlie” who works for agency X. And then Agency Y says “we also want Charlie to be our AR”. But Charlie is not a member of Agency Y, only of Agency X, how does that work?
3. And we have a SS&A AR named “Fred” for agency P, making assignments in the SS&A registry for network K. But Fred really works for a different center in Agency P, so he is a member of P.Q, but P “owns” network K. How does that work?
4. So the nice clean assumption “this guy works for that agency” model breaks down in reality when agencies elect to do things differently. The SANA guys have had to implement a more generalized framework that covers these variations, and that has taken time and involves a lot of testing.
The good news is that this is now implemented and they think they will be done with this is a couple of weeks. The bad news is that they also, now, need to rectify this whole “SLE claimed 1.3.112.4.3 OID subtree but never filled the registry” problem. It’s all manageable, it just takes time.
Just like making standards, I guess.
Cheers, Peter
From: SMWG <smwg-bounces at mailman.ccsds.org> on behalf of John Pietras <john.pietras at gst.com>
Date: Wednesday, May 12, 2021 at 7:36 AM
To: SMWG <smwg at mailman.ccsds.org>
Subject: [EXTERNAL] [cssm] FW: D-DOR FRM definition
From: John Pietras
Sent: Tuesday, April 27, 2021 6:29 PM
To: SMWG <smwg-bounces at mailman.ccsds.org>
Subject: D-DOR FRM definition
CSSMWG colleagues ---
Attached is the FRM HTML DOCX file that contains the “approved” Tier-1 FRM definitions and the draft Tier-2 FRM definitions. The Tier-2 definitions include the DdorRawDataCollection FR. On the first page, the link can be found on the Physical Channel: Delta-DOR Raw Data Collection line. This FR performs the reception of the radio waveform through the generation of the D-DOR Raw Data file.
As I said in today’s WG meeting, I have not yet reviewed this FR definition. However, Wolfgang has told me that he organized it around the information that appears in the Delta Raw Data Files that the FR produces.
As with all of the FRs, the parameters that are proposed as configuration parameters have the Configured attribute set to ‘true’.
NOTE – there are some issues with the limits and data types used by the D-DOR file format with respect to the data that’s available in the SANA Service Sites and Apertures registry. Ideally, the D-DOR files would be able to use those SANA values directly. The email below summarizes the issues that Wolfgang and I uncovered regarding this.
Best regards,
John
From: Wolfgang Hell [mailto:wo_._he at t-online.de]
Sent: Friday, March 5, 2021 9:55 AM
To: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>; Shames, Peter M (313B) (peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>; Border, James S (335D) (james.s.border at jpl.nasa.gov<mailto:james.s.border at jpl.nasa.gov>) <james.s.border at jpl.nasa.gov<mailto:james.s.border at jpl.nasa.gov>>
Cc: Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>; Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>; Pham, Timothy T (3300) (timothy.t.pham at jpl.nasa.gov<mailto:timothy.t.pham at jpl.nasa.gov>) <timothy.t.pham at jpl.nasa.gov<mailto:timothy.t.pham at jpl.nasa.gov>>
Subject: Re: SANA Service Sites and Aperture registry and Delta-DOR raw data files
Dear John, Peter, and Jim,
This is to thank John for his concise description of the issues that we have uncovered. In addition to what he has addressed in his email below, I would like to mention that CCSDS 506.1-B-1 needs to identify the observed objects which are either a spacecraft or a quasar. For the spacecraft ID we have the same constraint as for the station ID (four ASCII characters) and as a consequence the pertinent SANA registry cannot be used as source for this ID. If an update of CCSDS 506.1 is envisaged, this issue could be resolved on that occasion as well as the station ID problem.
The quasar IDs are those of the JPL maintained quasar catalog and as far as I can tell any agency acquiring DDOR raw data is using that catalog. In other words for that point we do not have a problem in CCSDS 506.1, but I'm wondering if it would not be better (if acceptable to JPL) to have this catalog under the auspices of a standardization body such as CCSDS for instance by converting this catalog to a SANA registry.
Best regards,
Wolfgang
Am 04.03.2021 um 16:41 schrieb John Pietras:
Peter and Jim,
As a consequence of Wolfgang Hell’s development of the definition of the functional resource representing the reception and processing of D-DOR data into raw data files, Wolfgang and I have uncovered several issues regarding the SANA Service Sites and Apertures (SS&A) registry, some of which relate to information in D-DOR raw data file headers.
Let’s start with the D-DOR-specific issues first. CCSDS 506.1-B-1 stipulates (a) that the Observation Header of the Observation File contains two “STATION” (transmit and receive), each of which contains ”4 ASCII characters”, and (b) the Header of the Product File contains a 16-bit unsigned integer “STATION ID” field. Currently, it appears that the values that are used to populate these fields are bilaterally agreed, although the SANA Considerations paragraph (B2) states “Conventions for Spacecraft and Station IDs may be collected in a future SANA registry.”
The SANA SS&A would seem to be the logical registry to cover the “Station ID” aspects. Currently the SANA SS&A registry specifies/registers:
1. A “Name” for each site. These names are geographical in nature, e.g., the name of the (closest) town, or the island on which the site resides. These names *are not unique* - e.g., there are 3 sites name “Kiruna” – one each owned by CNES,ESA, and JAXA;
2. An “Abbreviation” for the Name. As currently used in the SS&A registry, these really aren’t abbreviations at all – most are longer than the corresponding name. But they *are* unique. For the 3 sites named Kiruna, CNES site has the abbreviation “Kiruna”, ESA has “Kiruna0”, and JAXA has “Kiruna01”. So rather than “Abbreviation” this attribute would more properly be called something like “Distinguished Name” or “Globally-Unique Name”;
3. An Object Identifier (OID) for the site under the CCSDS Service Sites and Apertures node (1.3.112.4.9). The “label” for the OID is the so-called “abbreviation” for the site name. E.g., for the JAXA Kiruna site named “Kiruna”, the abbreviation “Kiruna01” is the label for the OID for the JAXA Kiruna site;
4. Under each site, one or more apertures, each of which has
1) A name
2) A so-called Abbreviation
3) An OID. As with the site-level OIDs, the labels for the OIDs are the Abbreviations.
Now back to CCSDS 506.1-B-1. “Station” is not defined, but from the context of the example in Annex E, where two STATION fields are populated with “DS24” and “DS25”, I interpret “station” to most closely map to “aperture”. From the current contents of the SS&A registry, it’s clear that many of the aperture names/abbreviations are not strictly 4 characters: some are 3, and many are more than 4. So “out of the box” the aperture names/apertures can’t be used directly in the Observation Header. One could consider changing the STATION fields in the Observation Header to be longer or variable length, but perhaps the simpler approach would be to add an (optional) attribute for those apertures that are used to support D-DOR operations. Similarly, an unsigned integer Station ID attribute could be added to register the values used in the Headers of the Product Files.
CCSDS 506.1-B-1 was published in 2013, and there is no indication on ccsds.org that it has been certified beyond its nominal 5-year “freshness” date. Before the book is updated or re-affirmed, the discrepancies between it and the SANA SS&A registry should be resolved so that that registry can be cited in the blue book (at least for matters concerning Station IDs).
The remainder of my comments on the SS&A registry are more general. As background, my plunge into this registry was motivated by the need to conform the presence of OIDs for the sites and apertures. CSS Area products, and CSTS products in particular, make use of the OIDs to identify these entities. I found that finding these OIDs wasn’t as straightforward as I might have hoped.
When one goes to the Service Sites and Apertures registry page, one sees
[cid:image001.png at 01D74B3D.73B6FF60]
What I did initially was scroll down the list of sites to find the ESA site with the name “Kiruna”*, and hit the Details button. That resulted in multiple pages of data (includingthe OID for ESA), but no OIDs for the site itself or its aperture(s.)
However, if one clicks on the OID Tree at the top of the page, one *does* get the site and aperture OIDs:
[cid:image002.png at 01D74B3D.73B6FF60]
To get the “right” Kiruna (in this case, the ESA Kiruna), one has to use the “abbreviation” (which, as noted above, therefore should be more properly called something like “distinguished name”) to know which site one is looking for. Of course, none of this is explained anywhere.
I think that for completeness the site and aperture OIDs should also be displayed in the Details for each site.
Finally,on the left side of each site entry in the main table is an arrow. If you click on that arrow you get another listing:
[cid:image003.png at 01D74B3D.73B6FF60]
[cid:image004.png at 01D74B3D.73B6FF60]
In this case, “Kiruna” is identified as/associated with a city. But If I look at the Wallops Island “arrow”, it doesn’t give a city but just a State/region (VA), even though it also has a “City “ listing under the “Details” view. The logic of why different things are displayed for different sites in the “arrow” view are not at all obvious.
In summary, I would suggest that:
1. The Station identifiers that are used in the D-DOR raw data files be accommodated by the SS&A registry, either by changing the D-DOR raw data file blue book to use registry names and identifiers or by adding the D-DOR identifier to the SS&A registry as optional atrtributes;
2. The Details view should also display the site and aperture OIDs; and
3. The title “Abbreviation” be replaced with something that more accurately describes the contents, like “distinguished name” or “globally-unique name”, and that they be more reader-friendly (e.g., “Kiruna_ESA”, Kiruna_CNES”, and “Kiruna-JAXA”).
Best regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210517/7ecdbdd8/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 30905 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210517/7ecdbdd8/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 29052 bytes
Desc: image002.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210517/7ecdbdd8/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 18143 bytes
Desc: image003.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210517/7ecdbdd8/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 44708 bytes
Desc: image004.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210517/7ecdbdd8/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SanaCandidateRegistryTier1And2_210315.frm.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 499205 bytes
Desc: SanaCandidateRegistryTier1And2_210315.frm.docx
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210517/7ecdbdd8/attachment-0001.docx>
More information about the SMWG
mailing list