[cssm] Updates:- Abstract Event Definition Book, Service Management Common data Entities Book, SMURF Book, UML Model, XML Schema.
Marcin.Gnat at dlr.de
Marcin.Gnat at dlr.de
Thu Feb 27 07:06:06 UTC 2020
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.
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
Cc: 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...?
From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of Marcin.Gnat at dlr.de
Sent: Tuesday, February 25, 2020 04:43
To: Colin.Haddow at esa.int
Cc: 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.
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.
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.
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,
Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
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...
More information about the SMWG