[cssm] Updates to UML Model, Schemas and New Examples after FRM splinter meeting of 16th July

Thu Jul 18 18:52:29 UTC 2024

Hi Erik,
            one of things I had in mind when producing the new examples was to get a feel for the actual data content and the conclusion I've sort of come to, particularly with respect to the config profile, is that all the pieces are more or less there, but might still need some shuffling around to make it all fit together logically. There are definitely some places where there is some data duplication which it would be better if we can get rid of.

I'm also still a little uneasy about not having an explicit mapping between frin and frNickName. Currently its only implicit with the frNickName being specified in the sm stratum classes and the frin in the fr stratumParameter classes, but maybe thats just me.

With respect to the parameters used in the functional resources in the config parameter example, they were pretty much chosen at random, although I tried to make sure there were defined as "configurable" in the text describing then in the relevant scheme files, but I might accidently have included some that were only for monitoring purposes. I was going a bit cross-eyed switching between the various different schema files involved when setting up the example. I know this may well be creating a rod to beat my own back, but after going through the exercise of creating the example there is defiantly documentation needed that describes the FRM schemas.

For the service agreement I think it needs careful examination to see that the required data is all present and we also need to be clear in describing what the actual parameters are for. When I was creating the service agreement example I must admit there were a few places where I wasn't completely clear on what the values specified should be or exactly what was meant. I think some clarification from Marcin would be useful as I created the service agreement UML model from his presentation from, I think, the meeting in Den Haag.

Anyway hopefully they provide some food for thought.

Cheers for now,

Colin

Dr. Colin R. Haddow

Scotty Consulting UG

________________________________
From: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Sent: 18 July 2024 20:26
To: Colin Haddow <Scotty.Consulting at Scotty-Enterprizes.com>; CCSDS Service Management W/G <smwg at mailman.ccsds.org>
Subject: RE: Updates to UML Model, Schemas and New Examples after FRM splinter meeting of 16th July

Colin,

Thanks very much for the update and producing the instance illustrative examples.  I think the illustrative examples very helpful and will definitely help in working toward a good understanding as to how the FRM is applied in a managed service context.

I think this exposes some aspects that might be of concern (which in itself is good – don't get me wrong!):

  1.  The service management header for all messages includes, if I remember correctly, a space user node, which is essentially a spacecraft identifier. It may be that we should think about generating the MD CSTS service management instance information based on the service management header rather than have that contained in the configuration profile as suggested by the configuration profile example. Otherwise we have the situation where the service management header could identify spacecraft A  and the configuration profile for the MD CSTS instance configuration could indicates spacecraft B. Not the best situation for guarding against potential sources of errors.
  2.  I realize that this is just an illustrative example but I will take the opportunity to again note that the user is very unlikely to configure antenna azimuth and elevation type parameters. Really this should just be the concern of the provider and so we need to perhaps double our efforts to start looking at the filtering whereby functional resources or specific parameters that do not make sense for exposure in the managed service context are "weeded out".  In general, I am not sure what if any apertureStratum information would be stated – presumably it is the provider’s job to work out during service level agreement negotiations, etc. sufficient gain for a given frequency, EIRP, coding scheme, and things like slew rates, etc. for apertures it can provide, and subsequently assign appropriate antennas/apertures in satisfaction for scheduled services.  I think this is really were some of the notable differences between the FRM in the abstract and it’s application in a managed service context start to emerge.
  3.  physicalChannelStratum is called out many times.  The practical application I see for real world operations is that a profile will apply to a given carrier and that the carrier is essentially the physical channel stratum on which the services (e.g., telemetry, ranging) operate. So this might argue for a somewhat different organization, but still making use of the underlying FRs and their parameters.   I plan to address this at the next splinter session, so just a comment for now.

Best regards,

-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of Colin Haddow via SMWG
Sent: Thursday, July 18, 2024 7:46
To: CCSDS Service Management W/G <smwg at mailman.ccsds.org>
Subject: [EXTERNAL] [cssm] Updates to UML Model, Schemas and New Examples after FRM splinter meeting of 16th July

Dear all,

              I've updated the UML model and associated schemas to include the changes discussed at the FRM splinter meeting. The UML diagram for the config profile is now as shown below;

[cid:image001.jpg at 01DAD8FA.37E30760]

In addition I've created 2 illustrative XML examples, one for the Service Agreement and the other for the Config Profile. These are not intended to be realistic, but merely serve to illustrate the type of data this is required in the Config Profile and the Service Agreement. The config profile contains 32 Functional Resouces, one of each that can be created at the various strata, each Functional Resource only has one parameter defined tho'. The examples are named;

  *   Example-902x05w01-ConfigProfile-Illustrative.xml
  *   Example-902x05w01-ServiceAgrmnt-Illustrative.xml

And can be found in GitHub at the following URL;

  *   https://github.com/CCSDS-CSSM/902Repository/tree/CRH-WorkInProgress<https://urldefense.us/v3/__https:/github.com/CCSDS-CSSM/902Repository/tree/CRH-WorkInProgress__;!!PvBDto6Hs4WbVuu7!NRB_G4_lPQodilt9lQQpqmjcPhegHojMaOaFpCBPbfTIbF_0T9aTessWeJBsHxmBVoPM7_OFHXR6OG4U_fPndX8HsQ$>

For those of you that don't have the Eclipse IDE installed and still want to have a look at the latest schemas and/or XML examples I've uploaded a zip file containing all the required schemas and XML examples to CWE. This can be found at the following URL;

  *   https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Schemas%20and%20UML%20Model/902Schema%2020240718.zip<https://urldefense.us/v3/__https:/cwe.ccsds.org/css/docs/CSS-SM/CWE*20Private/Book*20Production/Schemas*20and*20UML*20Model/902Schema*2020240718.zip__;JSUlJSUl!!PvBDto6Hs4WbVuu7!NRB_G4_lPQodilt9lQQpqmjcPhegHojMaOaFpCBPbfTIbF_0T9aTessWeJBsHxmBVoPM7_OFHXR6OG4U_fORfi_OFg$>

Cheers for now,

Colin

Dr. Colin R. Haddow

Scotty Consulting UG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20240718/dcb8f82c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 388745 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20240718/dcb8f82c/attachment-0001.jpg>