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

[John Pietras]

Carver,
The Cross Support Services Area needs to arrive at a consensus on whether the parameters, events, and (eventually) directives registered under the crossSupportFunctionalities branch will be mandatory for all implementations or just "standard" in the sense that if a Complex is capable of reporting a given parameter then that is the OID (and name, type, and units definition) that is to be used.

As I stated in my note (below), I believe that the consensus interpretation among those of us who have been working most closely with the Functional Resource concepts has been that the parameters, etc., are *not* mandatory on all implementations. However, that position was challenged at the Cleveland meeting, although we never did discuss it to a final conclusion (which is the reason that I sent my email on Friday). I propose that the prior consensus interpretation be affirmed. In terms of the registration tree, this would mean that a common parameter, event, or directive that is registered under the crossSupportFunctionalities branch be one that is to be used *if an Agency supports that  parameter (etc.)* but not mandatory if that Agency would not otherwise use that parameter.

To make this actionable, I request that anyone (in particular in the CSTSWG and CSSMWG) who has an opinion on this issue and would like to share it to please do so in an email to the membership of the CSTSWG and CSSMWG by 15 January. Depending on the responses, we can determine how to proceed after that.

SUPPORTING INFORMATION
The motivation for taking the position that the common parameters list not be mandatory was that if we *did* require that the registered parameters, event, and directives be mandatory, it would (a) take a lot longer for all Agencies to agree on that mandatory list and (b) the list would be only a minor subset of the parameters that Wolfgang Hell has catalogued. This is because while there are many parameters that many (even most) Agencies support, relatively few are supported by all Agencies. We preferred to take the approach of defining the greatest number of common parameters possible, so that if an Agency happens to support such a parameter, there would already be a standard specification for it. In this sense, "common" means "common to at least several CCSDS Agencies",  not " common to *all* CCSDS Agencies".
Note 1 - this approach is very similar to that taken in the SCCS-SM Service Specification, which defines 25 operations, only 3 of which are mandatory for an implementation to be minimally compliant with the standard).
Note 2 - this approach does not rule out eventually going further and mutually agreeing on a mandatory subset. What it is saying is that *for now* we are trying to just collect as many common (to several Agencies) parameters as possible.

Both the Cross Support Transfer Service Specification Framework (CSTS SFW) and the Monitored Data CSTS (MD-CSTS) Draft Recommended Standards are affected to varying degrees by how this issue is resolved. Both the CSTS SFW and MD-CSTS are planned to have Red Books issued this spring, ideally before the Bordeaux meeting, so resolution should be reached within the next month. These books are being written by the CSTSWG, so nominally it would be a CSTSWG decision to make. However, it will also affect Service Management, so the CSSMWG will also have to be part of the consensus.

Best regards,
John

From: Audain, Carver G. (GSFC-5810) [mailto:carver.g.audain at nasa.gov]
Sent: Monday, December 31, 2012 10:00 AM
To: John Pietras
Subject: Re: [Smwg] mandatory vs. "as needed" nature of monitored parameters

John,

What would the next step be on this topic?

Carver

From: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Date: Friday, December 28, 2012 1:49 PM
To: "CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>)" <css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>>, "CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>)" <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: [Smwg] mandatory vs. "as needed" nature of monitored parameters

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/20121231/8bb64369/attachment-0001.html