[cssm] Small input to our discussion yesterday on SACP and FRM parameters

[Marcin.Gnat at dlr.de]

Dear Erik,

Yes, this what you describe works for "unregistered" parameters, or in other words mine version of Configuration Profile with bilaterally defined parameters.
As soon we shall use FRM parameters with their complex types (which are currently totally neglected by SM- schemas) this does not work (or as John already mentioned, everybody would be responsible for internally "somehow" matching between FRM actual parameter and its complex type and the relatively simple parameter-value pair of AbstractParameter-Type).

Well, anyway... As said, for now I think it's just good to know that. Let's see how we can cope with all that in future.

Marcin

From: Barkley, Erik J (US 3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Sent: Mittwoch, 22. April 2020 18:23
To: Gnat, Marcin; smwg at mailman.ccsds.org
Subject: RE: Small input to our discussion yesterday on SACP and FRM parameters

Dear Marcin,

My understanding is that the "resName" identifies (via the "nickname") which resource we are talking about, the "name" in the AbstractParameter class is then which (configuration) parameter of the resource and the value, which can be anything we need is the value of this parameter for this service package.  Seems to me we have everything we need...?

Best regards,

-Erik

PS:  Colin,  I noted that in the CDE book (just concluded for polling) Figure 3-5 is suppose to be the modResResult UML class diagram but appears to be the AbstractParamter class diagram.




From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of Marcin.Gnat at dlr.de
Sent: Wednesday, April 22, 2020 02:56
To: smwg at mailman.ccsds.org
Subject: [EXTERNAL] [cssm] Small input to our discussion yesterday on SACP and FRM parameters

Dear all,

I just checked in SMURF, and unfortunately it seems that the respecification of Configuration Profile parameters (with famous ModResParm ;-) ) won't work for FRM-Based Parameters.

[cid:image001.png at 01D61955.4BA22380]

I just wanted to note that, at the same time not having any solution (yet). I need to brainstorm on whole topic a bit.
In other words, ModResParm works for my ConfigurationProfiles with "unregistered" parameters (which are also based on AbstractParmeter), but not for FRM stuff.

Maybe (MAAAAYBE!) as already shortly brought up, some solution would be in putting FRM definitions (in some form, maybe as reference only) into CDE, but one would need to analyze that.

Btw. Similar problem arises within Event Sequence later on....

I do not think we need to rework SMURF now (Colin, stay cool ;-). As long we do not have full singing and dancing ConfigurationProfiles and FRM-world, this seems to be almost academic problem. And assuming the SMURF can be released in 1-2 years (optimistic guy I am), we will need another 3-4 to get SACP and FRM out. Until than we can provide SMURF update as well... (in general we everybody know, that updates of our first books will become inevitable as progressing).

Best Regards
Marcin

PS: this is how I imagine "singing and dancing ConfigurationProfiles":
[Minion Happy Dance Daylight Savings Blank Template - Imgflip]


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200423/5aa96674/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 228118 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200423/5aa96674/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 9372 bytes
Desc: image002.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200423/5aa96674/attachment-0001.jpg>