[cssm] Updates:- Abstract Event Definition Book, Service Management Common data Entities Book, SMURF Book, UML Model, XML Schema.
Colin.Haddow at esa.int
Colin.Haddow at esa.int
Fri Feb 28 09:17:08 UTC 2020
Hi Erik,
with respect to the "UNR::" I agree with you, it makes
sense to use this as a generic "escape clause" for unregistered values.
Will you do the tweaks to the books or do you want me to do it ?
Cheers for now,
Colin
---------------------------------------------------------------------------------------------------------
Dr. Colin R. Haddow,
HSO-GDI, 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
---------------------------------------------------------------------------------------------------------
From: <Marcin.Gnat at dlr.de>
To: <erik.j.barkley at jpl.nasa.gov>
Cc: <smwg at mailman.ccsds.org>, <Colin.Haddow at esa.int>
Date: 28/02/2020 07:16
Subject: RE: [cssm] Updates:- Abstract Event Definition Book,
Service Management Common data Entities Book, SMURF Book, UML Model, XML
Schema.
Hi Erik,
Thanks for the quick reply?
I agree on the the ?station? with you. Unfortunately I used that term in
the common sense (like coming from ?ground station? which typically
denotes the site).
But you are right. There is ?site? and there are ?stations? and/or
?apertures? within the site.
Cheers
Marcin
From: Barkley, Erik J (US 3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Sent: Donnerstag, 27. Februar 2020 20:35
To: Gnat, Marcin
Cc: smwg at mailman.ccsds.org; Colin.Haddow at esa.int
Subject: RE: [cssm] Updates:- Abstract Event Definition Book, Service
Management Common data Entities Book, SMURF Book, UML Model, XML Schema.
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
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??
Best regards,
-Erik
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.
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
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
---------------------------------------------------------------------------------------------------------
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).
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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200228/fd592a3e/attachment-0001.htm>
More information about the SMWG
mailing list