[Css-csts] mandatory vs. "as needed" nature of monitored parameters

[John Pietras]

CSTS and CSSMWG colleagues ---
In our joint discussion of the Monitored Data CSTS registered parameters* (and parameters of Functional Resources in general) in Cleveland, one issue that was raised but I'm not sure was resolved was whether the parameters in the "standard" set are (a) mandatory for all implementations of MD-CSTS or (b) the ones that are to be used if an implementation supports any of those specific parameters.
[*This note also applies to registered events and directives, but for simplicity I'll just talk about parameters.]

My recollection is that in prior discussions the CSTSWG, and Wolfgang in particular, had adopted the idea that the parameters would *not* be mandatory for all implementations - each parameter of the "standard" set is one that multiple Agencies use, but not necessarily all of them. If your Agency (network) does report that parameter, then the standard identifier (and accompanying definition) is the one that should be used, but if your Agency does not report the parameter then your Agency would not treat it as one of its published parameters. (For the record, I also agree with this approach). However, at the Cleveland meeting, Peter Shames in particular thought that the standard set should be mandatory for all implementations of MD-CSTS.

The final resolution of this issue has implications for the crossSupportResources branch of the CCSDS OID registration tree: how it is interpreted and indeed whether it is sufficient.

Here's a text depiction of the crossSupportResources branch of the CCSDS OID registration tree, as described in Annex C of the latest (December 2012) draft of the CSTS SFW:
iso
3. identified organization
   112. standards producing organization
        4. CCSDS
           ...
           4. cross support
              1. csts
                 ...
              2. crossSupportResources
                 1. crossSupportFunctionalities
                    ...
                    n. <functional resource type n>
                       1. parametersId
                       2. eventsId
                       3. directivesId
                    m. <functional resource type m>
                       ...
                    ...
                 2. agenciesFunctionalities
                    ...
                    X. <Agency X>
                       ...
                       s. <functional resource type Xs>
                          1. parametersId
                          2. eventsId
                          3. directivesId
                       t. <functional resource type Xt>
                          ...
                       ...
                   Y. <Agency X>
                      ...
                   ...

The intention is that the standard Functional Resource Types and their standard parameters be registered under the crossSupportFunctionalities branch, and Agency-specific FR Types and parameters be registered under the agenciesFunctionalities branch. This is pretty straightforward for functional resource types that are purely Agency-specific - they are to be registered under the agenciesFunctionalities and their associated parameters with them.

What is not obvious is what is to be done when an Agency wants to add its own parameters, events, or directives to a standard FR Type - i.e., an FR Type that is already registered under crossSupportFunctionalities, and I think that the resolution may depend at least in part on the mandatory vs. only-if-you-need-it interpretation of the FR Types and parameters that are registered under the crossSupportFunctionalities branch. If the only-if-you-need-it interpretation holds, then even if only a single Agency wants to add a new parameter for an existing FR Type, then that Agency could petition CCSDS to add it to the standard set of parameters for that FR Type under crossSupportFunctionalities. Since no other Agency would be compelled to support the reporting of that parameter there would be no problem.

If, however, the crossSupportFunctionalities branch is interpreted to contain mandatory parameters (that is, if a parameter is in this branch then it *must* be supported by any and every implementation), then obviously an Agency (or subset of CCSDS Agencies) can't put its (their) non-universally-mandatory parameters under this branch. One possible approach is to allow agencies to specify "synonymous" FR Type identifiers under their Agency branches. For example, Agency X  could define a synonymous RAF TS Provider Type node {agenciesFunctionalities   <X>   <RAF TS Provider>} and add a new parameter, say totalNumberOfFlywheelFrames. Any implementation that is aware of this parameter could refer to the totalNumberOfFlywheelFrames parameter using the Parameter Name:
[[{crossSupportFunctionalities <RAF TS Provider}, <FR Instance No. Z>], {agenciesFunctionalities   <X>   <RAF TS Provider>  totalNumberOfFlywheelFrames }],
where

-           [{crossSupportFunctionalities <RAF TS Provider}, <FR Instance No. Z>] is the Functional Resource ID of instance Z of the standard RAF TS Provider Functional Resource Type, and

-          {agenciesFunctionalities   <X>   <RAF TS Provider>  totalNumberOfFlywheelFrames } is the Parameter Identifier as registered under Agency X's synonymous RAF TS Provider Functional Resource Type.

Note that there is nothing that syntactically relates the OIDs of {crossSupportFunctionalities <RAF TS Provider} and
{agenciesFunctionalities   <X>   <RAF TS Provider>}; that fact that {agenciesFunctionalities   <X>   <RAF TS Provider>} really refers to the same FR Type as {crossSupportFunctionalities <RAF TS Provider} must be recorded by some means that is outside the OID registry itself. However, we already have to do something similar for FR Types that use parameters, events, and directives that are defined in the CSTS SFW and registered under the
{csts    framework   frameworkIdentifiers} branch (see Annex C).

To summarize, we (CSSA) need to decide whether the registration of FR Types and their respective parameters under the crossSupportFunctionalities branch implies that those FR Types and parameters (and their respective OIDs) are mandatory for every implementation of the MD-CSTS, or only that the defined OID is required to be used if an implementation in fact supports that FR Type or parameter. One of the consequences of the decision is how Agency-specific parameters for standard FR Types are to be registered on the CCSDS OID tree.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20121228/5e6cb4ab/attachment.html