[Smwg] "user friendly" Functional Resource Nickname and parameter classifier

John Pietras john.pietras at gst.com
Fri May 4 14:44:53 UTC 2018


SMWG colleagues ---
In Gaithersburg one of the things that we discussed with respect to the Configuration Profiles work was the addition of a "user friendly" "nickname" for Functional Resource (FR) instances. Formally, FR Instances are named in terms of the combination of the FR Type (an Object Identifier (OID)) and the FR Instance Number (FRIN). It was pointed out that using OIDs and numerical indices to identify FR instances is not very "user friendly". In response to this observation, I am adding the frNickname parameter to the FunctionalResource abstract class. The frNickname parameters will be populated by the Mission, using names that are most meaningful to that Mission. E.g., Forward401SpaceLinkCarrierTransmission FR instance #2 could be assigned the frNickname "X-band transmitter".

Similarly, the parameters are formally identified by OIDs which are equally "unfriendly" to human eyes. Fortunately, in the case of the parameters, each parameter is also formally assigned a string-valued classifier (it is the classifiers that appear as the "names" of the parameters in the Space Link Service Profiles and Configuration Profiles).

I bring this up now because it will impact the SMURF book.

In order for these nicknames and classifiers to be most useful for SM purposes, they should also be usable in Service Package Requests, Service Package Results, and (presumably) in Event Sequences. Putting them into Event Sequences should be relatively easy, since the details of those data structures have yet to be worked out. They will also be available by default in Service Package Results since the nicknames will just be an additional parameter of each FR instance that is reported back in verbose mode, and the classifier is an attribute of each parameter.

This leaves the SMURF Service Package Request. In this case, the nicknames would come into play when respecifying the values of configuration parameters. This is done using the objects (instantiations) of the OIDParameter class. Per the current SMURF, the FR instances are identified using the frType and frInstanceNumber parameters of the OIDParameter class. The frNickname should be able to be used instead of the frType:frInstanceNumber combination to identify the FR instance. One possible way to do this would be to replace the current individual frType and frInstanceNumber parameters with a single frName parameter of complex type FrName:

[cid:image002.png at 01D3E394.863EBD80]

Similarly, instead of the OIDParameter class offering the OID-valued parameterId parameter as the only way of "naming" the parameter to be respecified, the classifier should be able to be reused instead. Again, since this would be an either/or situation, a choice-valued parameter of type FrParameterNameType could be used instead of the current parameterId:
[cid:image001.png at 01D3E394.EEB6D1E0]

Best regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20180504/eff34a53/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 4229 bytes
Desc: image002.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20180504/eff34a53/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3209 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20180504/eff34a53/attachment-0001.png>


More information about the SMWG mailing list