[Css-csts] parameter labels and event labels

[John Pietras]

CSTSWG colleagues ---
Last month, I wrote a new normative annex that I have proposed for inclusion in the CSTS SFW Red Book. That annex (which I put in as Annex D) provides some normative definitions regarding Functional Resource Types, FR Identifiers, parameter identifiers, parameter names, and how they relate to parameter list contents. IN that annex, I had specified that a parameter list (either named or the default list) logically consisted of one or more parameter list records, where a parameter list record was defined as the combination of parameter identifier and Functional Resource Type (where Functional Resource Type is a published identifier, which in turn is, an ISO Object Identifier). At a previous time, our concept was that a parameter list would contain parameter names, but since parameter names include (by definition) the Functional Resource Instance Number (which is only instantiated by Service Management when the Service Package is scheduled) it became necessary to define lists (which exist before and outside of any scheduled Service Package) in terms of things without Functional Resource Instance Numbers. Thus the [parameter identifier : Functional Resource Type] pairs that constitute the list records are used to identify all instances of the parameter type represented by the Parameter Identifier for all instances of the Functional Resource Type that are configured to execute as part of the Service Package.

This month (January), I started updating the draft Monitored Data CSTS Red Book to reflect the various changes that have occurred in the CSTS SFW since the last MD-CSTS draft was produced. Most of those changes have to do with the intermediate evolution of concepts and terminology related to Functional Resource, Parameter Names, etc.  While going through the updating process, I realized that the [parameter identifier : Functional Resource Type] pair had broader applicability than just defining the contents of a parameter list. I realized that SANA will have to register these pairs regardless of whether they are used in the construction of parameter lists. That is because it is not always sufficient to just use the parameter identifier to determine the Functional Resource Type with which that parameter identifier is associated. Specifically, when a framework parameter identifier (or framework event identifier) is "attached" to a Functional Resource Type, this relationship must be identified in terms of both the framework identifier and the FR Type.

Given this more-general use of the [parameter identifier : Functional Resource Type] pair, the term "parameter list record" is inadequate because it implies that it is only used for lists. I am proposing a new term - parameter label - for this pair. Similarly, I propose event label as the name for the [event identifier : Functional Resource Type] pair.

The effects on the CSTSSFW itself are minor - essentially addition of these label definitions (and one for directive label for future use) and replacing in a few places phrases such as "the combination of a Parameter Identifier and a Functional Resource Type" with the more-compact "parameter label". I've made these changes in another draft of the CSTS SFW, this one titled "921x1r2[Draft 201301] - Return Services-JVP+YD+labels". It contains all changes of the past few draft updates. I've uploaded it to the CWE at URL http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/CSTS%20Framework%20and%20Concept/921x1r2%5BDraft%20201301%5D%20-%20Return%20Services-JVP+YD+labels.doc.

Best regards,
John


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130122/0cfc0e40/attachment.html