[cssm] Updates:- Abstract Event Definition Book, Service Management Common data Entities Book, SMURF Book, UML Model, XML Schema.

Thu Feb 27 19:34:37 UTC 2020

Hello Marcin,

Okay, perhaps we can be reasonably fast on agreeing on not stopping an update that has already been applied ;-)  The use case you have cited makes sense to me.  Note that I had to do a tiny translation effort re "station", as indicated below* -- but I think the update is fine.

Colin,

Any thoughts on the use "UNR::" as more generic practice?

Best regard,
-Erik

*A minor note in terms of terminology from the heavily influenced DSN perspective.  Each aperture is in fact, for us, considered to be a "station" (and this is reflected by our DSS abbreviation for Deep Space Station). I think probably the rationale is that there is more than just the aperture to make tracking happen - certainly there is a fair amount of various bits and pieces of hardware in terms of microwave mirrors, low-noise amplifiers, az/el drive motors, etc.  What is a "site" for us is a Deep Space Communications Complex (DSCC).  So relative to SANA Sites and Apertures registry, for DSN, the DSCC is the site and DSS is the aperture. And I think in the example you cited, Svalbard would be the SANA Site and each antenna would then be the individual apertures.

From: Marcin.Gnat at dlr.de <Marcin.Gnat at dlr.de>
Sent: Wednesday, February 26, 2020 23:06
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Cc: smwg at mailman.ccsds.org; Colin.Haddow at esa.int
Subject: [EXTERNAL] RE: [cssm] Updates:- Abstract Event Definition Book, Service Management Common data Entities Book, SMURF Book, UML Model, XML Schema.

Hi Erik,

Well, maybe not so fast with stopping an update ;-).

As you noticed yourself, the registry is not normative on UML diagram. But also registry is a registry, and of course there is no reason to register an antenna with no apertureRef.

On the other hand we have our system for actual booking, and there is very strong use case in SMURF for ServicePackage request (and the same for the PlanningInformation request) where users request a support on specific station, but do not want to decide on specific antenna (assuming they all or most of the antennas fulfill the requirements) in order to increase a chance of getting confirmation. We use this possibility in our daily scheduling all the time (especially with stations like Svalbard where they have multiple antennas). This topic will increase I assume with new space, where as far I know it is typical to decide on provider side on assigned assets.

So, said all that, I do not think there is any inconsistency between registry and SM/UML.

Best Regards
Marcin

From: Barkley, Erik J (US 3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Sent: Mittwoch, 26. Februar 2020 23:42
To: Gnat, Marcin; Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>
Cc: smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>
Subject: RE: [cssm] Updates:- Abstract Event Definition Book, Service Management Common data Entities Book, SMURF Book, UML Model, XML Schema.

Dear Colin, Marcin,

Well, perhaps not so fast now with Marcin's suggested update of the ApertureLocation class definition.  In the SANA considerations section of the CDE we have this:

"...Although the registry allows for Site Name records with no Aperture Name field records, for effective use with this Recommended Practice, any referenced Site Name needs to contain at least one Aperture Name field...."

So, okay this is effectively a rule on the SANA registry and of course it is not normative on the UML class diagram.  But I am curious as to where in CSSM we plan to use an ApertureLocation with only a siteRef and no apertureRef - I guess it could be for the (what I expect to be relatively rare) request for an off-line service package where maybe only the siteRef really matters ?

Also, Colin, spelunking in the SANA registries section, there is the unregistered values escape clause (which I think is good) but it only says this applies to the originating organization and user parameters. Would there be any reason why we would not allow for a siteRef or an apertureRef to be of the form "UNR::NewExperimentalAntenna-01", for example? I suspect this may in fact have been carried over from original write up in the SSF book, but perhaps I'm not recalling the reason for restricting unregistered values as indicated here. It seems to me use of "UNR::" to indicate/allow (presumably temporary) use of unregistered values should be a general practice...?

Best regards,
-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org>> On Behalf Of Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>
Sent: Tuesday, February 25, 2020 04:43
To: Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>
Cc: smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>
Subject: [EXTERNAL] Re: [cssm] Updates:- Abstract Event Definition Book, Service Management Common data Entities Book, SMURF Book, UML Model, XML Schema.

Dear Colin,

I just reviewed the docs (it took me only one month, haha), and I spotted one small thing:

  *   In the Common Data Entities Book, the figure showing class diagram of the ApertureLocation is not in line with the actual table explaining it below (the change was due to RID 4, which was I believ from me). So the table says correctly, that the siteRef is obligatory and the apertureRef is optional. Unfortunately the diagram shows the opposite and I think this is a typo.
     *   By the way, I just noticed, that also in the SMURF there is a diagram on contraints (Figure 3-9) where there is the same mistake.
  *   The formatting of the table 3-7: when listing future possible values, there are some missing "-" in front of two lower entries.

Except that, I reviewed the constraints again (as desired). The basic constraints seem to fine for me (see only comment above). I think we can live with that for the moment. I hope we will get also some feedback on that out of our prototyping (by the way, I did not hear anything from Anthony since last teleconference).
Also the other constraints seem to be okay, I think for DLR primarily the classes StandingOrder and PassDailyTime (when used together) and the AdditionalUser will be of some interest. For other classes I can imagine they may be useful for other agencies and for example for deep space missions. As far I can use my imagination, for such use cases they seem to okay. I won't have however any easy way to verify that.

Best Regards
Marcin

From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>
Sent: Donnerstag, 23. Januar 2020 14:54
To: CCSDS Service Mgmt WG
Subject: [cssm] Updates:- Abstract Event Definition Book, Service Management Common data Entities Book, SMURF Book, UML Model, XML Schema.

Dear all,
                  I've just uploaded the following updates to CWE;

  *   Abstract Event Definition Book:                        Contains all RID updates + changes to schema naming convention + SANA Registry paths. Subject to AD review should be ready for publication.
  *   Service Management Common Data Entities Book:        Contains all RID updates + changes to schema naming convention + SANA Registry paths. Subject to AD review should be ready for publication.
  *   SMURF Book                                        Contains changes to Basic start and duration constraints as discussed at last telecon (i.e. merge into one constraint), change use of start and end time to optional in ICS table + changes to schema naming convention + SANA Registry paths. Does not  (yet) contain any updates at the individual request type level stating how the start and end times in the header should be used. I think this update is perhaps best left until we're a bit further into the prototyping.
  *   XML Schemas:                                        Contains the schemas updated for the new naming convention and changes to the above books.
  *   UML Model                                                Contains the UML model consistent with the changes to the above books.
  *
These can be found at the following URLs

  *   Abstract Event Definition Book:                        https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Magenta/Abstract%20Event%20Definition/Red%20Book/Drafts/902x13r1_01.1%20-%20Abstract%20Event%20Definition.doc
  *   Service Management Common Data Entities Book        https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Magenta/Service%20Management%20Common%20Data%20Entities/Red%20Book/Drafts/902x12r1_01.1%20-%20Service%20Management%20Common%20Data%20Entities.doc
  *   SMURF Book                                        https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Service%20Management%20Utilization%20Request%20Format/White%20Book/Drafts/902x9w0_10%20-%20Service%20Management%20Utilization%20Request%20Formats.doc
  *   XML Schemas                                        https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Schemas/902Schema%2020200123.zip
  *   UML Model                                                https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/UML%20Model/902UmlModel%2020200123.zip
Note that I've not updated the CPIF with the new schema naming convention and SANA Registry paths. As thats currently out for Agency review that should be handled via a RID.

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>
---------------------------------------------------------------------------------------------------------

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or

protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received

this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect

personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200227/fb063cdb/attachment-0001.htm>